Need to recompile a Java Applet as an Executable
in [Java Programming]
|
Prev: How to get an include-path of jni.h that is able to be differenton different platforms.
Next: Read utf-8 file return utf-16 coding hex string ?
From: Paul Cager on 29 Jan 2010 07:25 On Fri, 2010-01-29 at 03:33 -0800, Sanny wrote: > > Sanny wrote: > > > I have a Java Applet which is quite slow. > > [...] > There is nothing wrong with the java code. I know some expressions in > C are working 10-20 times faster. Secondly "C" allows the use of > pointers and Assembly language programming. > > Also I can configure Compilation in "C" such that it do not do error > checking at runtime speeding it up further. Have you _measured_ where the CPU time is being spent? I've not heard of a Java program where the runtime checks make any noticeable difference. Are you familiar with the way JVMs JIT code? Quite often checks are simply optimised away. > In Java String Operations are 100 times slower than in "C". As copying > a string takes lots of time in Java. I'm not really sure how to reply to this. Why do you think string operations are 100 times slower? E.g. in general Java's string.length() is a lot quicker that C's strlen(string). [...] > > If you want cross-platform support, write the whole thing in Java, > > figure out why your program is so slow, and fix it using only Java. > > Its not Slow exactly. But I want it to be more fast. As C/ C++ > routines are much faster as I can use Assembly language programming.
From: Lew on 29 Jan 2010 08:49 Sanny wrote: > Will a firefox [sic] browser run an ActiveX on Non Windows OS? ActiveX is inherently Windows-only. -- Lew
From: Nigel Wade on 29 Jan 2010 09:08 On Fri, 29 Jan 2010 08:49:26 -0500, Lew wrote: > Sanny wrote: >> Will a firefox [sic] browser run an ActiveX on Non Windows OS? > > ActiveX is inherently Windows-only. It's inherently Internet Explorer on Windows. It is not supported in Firefox on any platform. http://support.mozilla.com/en-US/kb/ActiveX -- Nigel Wade
From: Thomas Pornin on 29 Jan 2010 11:11 According to Sanny <softtanks22(a)hotmail.com>: > There is nothing wrong with the java code. I know some expressions in > C are working 10-20 times faster. I know some where carefully optimized C code can be about 8 to 10 times faster than optimized Java code, but they are pretty specific and involve multiplications of 64-bit values for which the full 128-bit result is needed. In that case, the C version takes an edge only if it runs on a platform with a native 64x64->128 multiplier _and_ the code uses some platform-specific inline assembly (which is not portable, not standard, and actually not C). On all other instances I have come across, the speedup offered by C over Java on pure computational, fit-in-L1-cache-and-no-IO work, is typically between 2x and 3x (3x for array-intensive work, because of array length checks upon access), never above 4x. If you get more speedup with C or assembly, and are not playing with big integer arithmetics, then there is something wrong with your Java code. And of course, on any practical application, there are I/O bottlenecks everywhere, which reduce even further the speedup allowed by use of C. > In Java String Operations are 100 times slower than in "C". Definitely, there is something wrong with your Java code. > One more reasion to use "C" is to have my code encrypted. Java Code is > available to all so others can easily hack the java code. While > cracking an Activex is I suppose impossible. Sorry to break your dreams, but no layer of encryption will gain you anything here. Regardless of how you do it, the code will have to be decrypted at some point for the processor to run it, at which point any decent debugger may grab it. There is no solution to this, except using specific, shielded, tamper-resistant hardware. For a PC, this is under somewhat rampant development, and certainly not widespread. See: http://en.wikipedia.org/wiki/Trusted_Platform_Module http://en.wikipedia.org/wiki/Trusted_Computing_Platform_Alliance As for whether JNI can be used in Java applets: the answer is yes, but it requires some special rights which the JVM will not grant to the applet unless it is cryptographically signed (and the user has the option to refuse the grant). Also, you need to embed the DLL, dump it on a convenient place on the disk, and load it from there. This is doable but cumbersome. --Thomas Pornin
From: Antoninus Twink on 29 Jan 2010 14:31
On 29 Jan 2010 at 8:01, Nick Keighley wrote: > this isn't on topic on comp.lang.c how C or C++ "links" with java is > outside the scope of the C or C++ language. Utter nonsense. |