4

Possible Duplicate:
Why isn't more Java software compiled natively?

I know that Java is byte code compiled, but when using the JIT, it will compile the 'hotspots' to native code. Why is there not an option to compile a program to native code?

Community
  • 1
  • 1
kmdent
  • 1,577
  • 16
  • 32
  • 4
    Because then it wouldn't be a Java program anymore. it'd be a native app that happens to use the Java libraries in the background. – Marc B Nov 01 '11 at 19:40
  • 4
    The GCJ Compiler can compile Java source to native code: http://gcc.gnu.org/java/ – bdk Nov 01 '11 at 19:40
  • @MarcB, I don't really get your comment. You mean it wouldn't be bytecode anymore? (A bytecode program isn't more of a Java program than an assembly program is a C++-program.) – aioobe Nov 01 '11 at 19:45
  • The whole point of bytecode is that it's portable. You can take that bytecode and run it anywhere you have a JVM. once you compile to native, it's no longer bytecode - it's x86/mips/arm/whatever assembler, and is no longer portable. Since the whole premise of Java is portability, once you remove it, it's basically no longer Java. – Marc B Nov 01 '11 at 19:46
  • 2
    @MarcB: Bytecode, or portability, is an implementation detail. If a compiler accepts any program conforming the JSP and outputs a program (be it written in machine code for the JVM or machine code for the CPU that's actually running your physical computer), it's a compiler for the Java language. Sure, you probably lose interop with the popular JVMs and you lose a vital property of other implementations, but the Java language is not defined by its implementation or portability. –  Nov 01 '11 at 20:21
  • @denian, JSP -> JLS I suppose ;-) (if you remove / readd, I'll upvote it again ;-) – aioobe Nov 01 '11 at 20:40
  • @bdk the GCJ compiler can compile a subset of Java programs to native code and execute them correctly to an unknown extent, as it has never been subject to the Java Compatibility Test Suite, which it would fail miserably. – user207421 Nov 01 '11 at 22:25

6 Answers6

5

There is an option to compile Java source code files in binary code it is called GCJ and come from Free Software Foundation.

It is not officially supported by Sun/Oracle but i've used the compiler and it do a great job ;)

Community
  • 1
  • 1
aleroot
  • 71,077
  • 30
  • 176
  • 213
  • GCJ is a dead project if I'm correct. Plus, the performance of the native code isn't good. See my question here: http://stackoverflow.com/questions/3032727/java-jre-vs-gcj – Martijn Courteaux Nov 01 '11 at 19:45
  • There is also a commercial implementation is called JET : http://www.excelsior-usa.com/jet.html However i've used GCJ sometimes and it is not too bad – aleroot Nov 01 '11 at 19:46
3

Java, as a language, can be implemented, like any language, in many ways. This include full interpretation, bytecode compilation, and native compilation. See Java language specification

The VM specification defines how bytecode should be loaded and executed. It defines the compiled class format, and the execution semantics, e.g. threading issue, and what is called the "memory model". See Java VM specification

While orignally meant to go together, the language and the VM are distinct specifications. You can compile another language to Java bytecode and run it on top of the JVM. And you can implement the Java language in different way, notably without a VM, as long as you follow the expected semantics.

Of course, both are still related, and certain aspects of Java might be hard to support without bytecode interpretation at all, e.g. custom ClassLoader that return bytecode (see ClassLoader.defineClass). I guess the bytecode would need to be JIT'ed immediatly into native code, or maybe are not supported at all.

reevesy
  • 3,452
  • 1
  • 26
  • 23
ewernli
  • 38,045
  • 5
  • 92
  • 123
1

Which platform native code should it compile to?
Windows, Mac, Linux?
What if the developer works on a different platform than the application is going to run on? What if the application platform changes, either in the server room or on the desktop?

I don't see the benefit, the JVM's nowadays seem to be to be fast enough for very general purpose needs.

crowne
  • 8,456
  • 3
  • 35
  • 50
1

There are several products out there to compile java programs to native code, however they are imperfect, and not at all like the JIT compiler. Some differences include:

  1. Write Once Run Everywhere - it will only work on the target you compile it for.
  2. Dynamic code - you cannot load jars or other Java code at runtime, which is often a feature of application servers, GUI builders and the like.
  3. Runtime profiling - a lot of JIT compiler action involves understanding what the code is doing at runtime, not what it could potentially do under a static analysis, meaning that JIT can outperform a natively compiled application in the right circumstances.
  4. Cannot support all Java features. Things like reflection aren't going to be very meaningful in a compiled program.
  5. Large footprint - when it is compiled to native code, all of the libraries the JVM gives you have to be bundled into the package, causing a very large footprint. It is a tricky problem to figure out what can be left out.

So it is possible, for a certain subset of applications, to compile to native code, but as VMs have gotten faster and faster, and issue #5 above has not really been improved (although project Jigsaw should help with that), it is not a very compelling option for real world applications.

Yishai
  • 90,445
  • 31
  • 189
  • 263
0

Because it is enough to have byte-code compiled. If you would compile your own code - you had also compile all libraries. And it is real problem from two point of view: 1. licensing - most of the code wouldn't be changed 2. you had 'recompile' megatons of code :-)

Max
  • 842
  • 5
  • 16
  • No, you wouldn't have to recompile tons of code. Only the code that has been changed have to be recompiled. Of course they have to be linked again. – Martijn Courteaux Nov 01 '11 at 19:48
  • Recompile tons of code was a shorthand - it means if you want compile your code to native, probably you want to run your application on native processor - without usage of jvm. ANd if it is true, you must compile-in jvm, default libraries, and other libraries. (if the will be nod compiled, how do you know which class will be excepted. If you left one, you must ensure way that they will be loaded if necessary, ....... etc, etc.) – Max Nov 01 '11 at 19:53
0

This was a decision made by Sun to not allow this because they wanted to position Java as being inherently multi-platform. As such, they wanted to ensure that any Java application compiled would run on any platform with a JVM. This prevents there from being Java binaries available on-line which don't run on certain hardware or operating systems.

Keith Irwin
  • 5,628
  • 22
  • 31