Why doesn't java have a compiler without bytecode?

Question

Possible duplicate:
Why is Java not compiled anymore?

I know that Java is a byte code compiled, but when using JIT it will compile "hot spots" for native code. Why is it not possible to compile the program into native code?

Answer 1

It is possible to compile Java source code files in binary code, which it is called GCJ and comes from the Free Software Foundation.

It is not officially supported by Sun / Oracle, but I used the compiler and it does a great job;)

Answer 2

Java, as a language, can be implemented, like any language, in various ways. This includes full interpretation, bytecode compilation, and native compilation. See Java Language Specification

The VM specification defines how byte code should be loaded and executed. It defines the format of the compiled class and execution semantics, for example. a problem with threads and the so-called "memory model". See Java VM Specification

While orignally intended for sharing, language and virtual machine are separate specifications. You can compile a different language for Java bytecode and run it on top of the JVM. And you can implement the Java language in many ways, especially without a VM, as long as you follow the expected semantics.

Of course, both of them are still connected, and some aspects of Java can be difficult to support without interpreting the bytecode at all, for example. custom ClassLoader that return a bytecode (see ClassLoader.defineClass ). I think that bytecode should be immediately included in native code or maybe not supported at all.

Answer 3

What root platform code should be compiled?
Windows, Mac, Linux?
What if the developer works on a different platform, how will the application work? What if the application platform changes, either in the server room or on the desktop?

I don't see the benefits, the JVM currently seems to be fast enough for very general purposes.

Answer 4

There are several products for compiling java programs for native code, but they are imperfect and are not at all like a JIT compiler. Some differences:

• Write Once Run Everywhere - it will work only for the purpose for which you compile it.
• Dynamic code - you cannot load jars or other Java code at runtime, which is often a feature of application servers, GUI developers, etc.
• Runtime profiling - many of the actions of the JIT compiler involve understanding what the code does at runtime, rather than what it could do with static analysis, which means that JIT can outperform the originally compiled application in the right circumstances.
• Unable to support all Java features. Things like reflection will not be very significant in a compiled program.
• Large footprint - when it is compiled into native code, all the libraries that the JVM gives you must be packaged, which causes a very large footprint. The difficult problem is to find out what can be ignored.

Thus, for a certain subset of applications, you can compile your own code, but as virtual machines become faster and faster, and problem number 5 above has not been improved (although the Jigsaw project should help with this), this is not a very convincing option for real world applications.

Answer 5

Because it’s enough to compile the bytecode. If you compile your own code, you will also compile all the libraries. And this is a real problem from two points of view: 1. licensing - most of the code will not be changed 2. you recompiled the megatons of the code :-)

Answer 6

It was Sun's decision to prevent this, because they wanted to position Java as inherently multi-platform. Thus, they wanted to make sure that any compiled Java application would work on any platform using the JVM. This prevents the presence of Java files available online that do not run on certain hardware or operating systems.