Question:
Is there anyway to compile Java source code into machine specific binary code (as opposed to bytecode)?
apple guava
2009-04-29 23:10:22 UTC
For quite sometime I was pleased with the idea that Java applets run cross platform. Then I realised it's able to do this because of JVM which I think really sucks because everything I do is at best what JVM is capable of doing. Everything goes through JVM. If JVM can't do it, Java can't do it. If JVM can do it, good, applet runs slowly through JVM. Still sucks for slowness and indirectness.

My question is: is there anyway to compile Java source code into machine specific binary code (as opposed to bytecode)? Thanks.
Five answers:
femtorgon2
2009-04-29 23:47:37 UTC
Java is problematic that way. There are nifty benefits, but a decent share of nasty detractions to go with it.

There are indeed various projects out there to allow you to compile Java to native:

http://gcc.gnu.org/java/

http://www.excelsior-usa.com/jet.html

And a few more listed here:

http://www.thefreecountry.com/compilers/java.shtml



And of course, there is also the other answer: C++

Knowing Java, C++ isn't hard to learn, and if your concerned with speed, no Java native compiler is going to produce the sort of speed and efficiency that you can get from good C or C++ code.



EDIT:

You mean, can you have your cake and eat it too? Not really, no. Not to my knowledge anyway.
2016-11-04 01:08:20 UTC
Compile Java To Native Code
2009-04-30 00:53:38 UTC
Java isn't really all that slow, it's been optimized a number of times to make it quite quick. I've never had it slow enough that I would choose C over it, and I've done some fairly intense math with it (it did get slow when I had to use longs with those intense calculations, though).



My advice is to see if you can find a better algorithm, how you implement your code will affect the speed much more than the JVM.



(As a side note, Strings are immutable, so if your program is heavy on it's use and manipulation of strings, then this could slow your program down significantly, I have encountered this situation a few times, in which case I ended up using character arrays where I could, and avoiding the Scanner class where I knew how)
rk
2009-04-29 23:55:17 UTC
The strength of java is its portability, which is achieved through JVM and bytecode.

To achieve this portability, some extra efforts are needed to be done by Java and this makes the program run slower.

The compilers developed by SUN use the JVM and Bytecode to ensure portability.

If you do not want this portability, perhaps you can look for other compilers which convert java code into native machine code, but these codes are not portable. But they will be faster since unwanted intermediate conversions are skipped, since portability need not be maintained.



One such compiler that can be used for portable code and also for native code is given in the following link.



http://gcc.gnu.org/java/
?
2016-05-25 01:14:57 UTC
Yes, as microprocessors are built using transistors and logic gates which can only possibly work on binary (base 2), all bibles in electronic format must be processed in binary, regardless of whether they are encoded in ASCII, unicode, extended ASCII, or anything else.


This content was originally posted on Y! Answers, a Q&A website that shut down in 2021.
Loading...