Oracle Formally Proposes That Java Adopt Ahead-of-Time Compilation (infoworld.com)

An anonymous Slashdot reader quotes InfoWorld: Java applications will get faster startup times thanks to a formal proposal to include ahead-of-time compilation in the platform. The draft Java Development Kit proposal, authored by Vladimir Kozlov, principal technical staff member at Oracle, is targeted for inclusion in Java 9, which is expected to be available next summer. "We would love to see this make it into JDK 9, but that will of course depend on the outcome of the OpenJDK process for this JDK Enhancement Proposal," said Georges Saab, vice president of software development in the Java platform group at Oracle, on Thursday. Ahead-of-time compilation has been a stated goal for Java 9 to address the issue of slow startup...

The proposal summary notes that Java classes would be compiled to native code prior to launching the virtual machine. The ultimate goal is to improve the startup time of small or large Java applications while having "at most" a limited impact on peak performance and minimizing changes to the user workflow.
Tests indicates some applications perform better while some actually perform worse, so it's being proposed as an opt-in feature where dissatisfied users "can just rebuild a new JDK without ahead-of-time libraries."

Comments

Only makes sense for niches

[angel'o'sphere]

Penty of Enterprise software relies on byte code morphing/instrumentation and all things we get from Aspect Oriented Programming. Ahead of time compilation makes only sense in Applications that don't use such featers and should be simply part of the build process if developrs chose so and not necessarily a "language feature".
After all there are plenty of third party AoT Conpilers for the JVM.

Garbage

[speedplane]

I wish they'd spend more time on improving their garbage collectors than compilation time. It can take 30 seconds to a minute to garbage collect 25GB of memory, a huge problem for servers. The G1 garbage collector (G1GC) is promising, but it's still far to buggy to use in production. If this GC issue does not get fixed, I could see it incentivizing server software to switch to C/C++.

Re:A real Java compiler?

[BitZtream]

This is about "ahead of time" compilation, otherwise known as "compilation", which third-party tools [stackoverflow.com] have done forever. Linking to C in Java is its own world, and I don't know how practical C++ is.

The stack overflow you link to has nothing to do with AOT. They all use a standard JVM and JARs, just all packaged into a single exe file. Its still JIT for the ones that include the JRE bits, the others just download and install a JRE for you. Using C and C++ code from Java is non-trivial but easy enough.

It's dead easy to bridge between C++ and C# at runtime using Managed C++ (or whatever they call it these days). The C# marshaller, the built-in way to get C objects from C# code, is slow painful garbage that no one should use, but it's easy to do the conversion in C++ and either object conversion or using objects directly is very fast that way.

Its just as easy in Java, except better hidden, cause you're not supposed to do it, in order to keep the 'cross platform' nature of Java at its core. Microsoft wants you to bind your C# apps to the Windows platform so they encourage the use of P/Invoke to work around unimplemented features of the framework. Its handy, but goes against one of the core tenets of Java.

You can compile C# to a proper EXE or DLLs easily enough and it will happily load C/C++ DLLs. The reverse is a bitch though - I've heard it's possible (the .NET runtime is also just DLLs), but I never got it to work properly.

Technically, what you compile C# (and all .NET) to isn't actually executable either. Its byte code as well, that can be easily and quickly turned into cached binaries that are essentially AOT compiled ... but thats stored in a different director on the machine and isn't the exe you run, mono will do actual full AOT with the right options, but by default doesn't either. Full AOT takes away several features of the .NET framework, just like it would with the JRE. They'd be implemented in an entirely different way. .NET dlls are just OLE components at their hearts, you've probably heard of OLE as one of the other names it goes by: DDE, OLE2, ActiveX, COM, DCOM. These are ALL THE SAME THING in different revisions, with more features in the later ones. .NET being the latest. Loading and running .NET assemblies is only slightly more difficult than loading an ActiveX in C or C++. Its non-trivial, and you won't find a ton of examples, but its not black magic. Its no more difficult than getting an XPCOM or Corba object to load, and Mozilla can even do that properly so lets not act like its rocket science.

You can (awkwardly) run C code from Java, including loading DLLs, but I've never heard it's possible to do the reverse. What can C code do with a JAR?

You would embed the JVM in your application or a plugin for your application and execute the JAR from there, the same way you do with .NET runtime objects. Not really rocket science here either, though again it is non-trivial.

Its the same as loading pretty much any interpreted language from C or C++, just different libraries and function calls. You do realize that the 'java' command is a C application that loads a bunch of Java libraries and execute JAR files right?

Linking all three would be a bragworthy project, but I think Java is just missing the key concept here.

Its been done: https://www.ikvm.net/

Run .NET code in java, run Java code in .net. Its big, its bulky, it works pretty well, but I don't recommend doing it for weekend fun.