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.

Re:Only makes sense for niches

[lgw]

Reading comprehension skills, do you have them?

He uses Aspect Oriented Programming, so code is impossible to read and thus he doesn't practice reading comprehension much. (Also, Kirk could kick Picard's ass, and EMACS > VI).

Re: Only makes sense for niches

[WarJolt]

AOT makes sense for certain application. Also AOT doesn't mean AOT only. If you want to use it with a tracing JIT I see no reason why these technologies are incompatible.

The problem I have with Java is that with some java programs it takes less time for an equivalent C program to compile and run than an that java program to do all of its dynamic linking and finally run. You don't have to do AOT, but all those string compares during loading really slows things down. Each symbol has to be looked up and compared.

With native libraries often times shared libraries are already in memory. The libraries are simply mapped into a processes address space. In java land each time you load a library it takes up its own space and that overhead is not shared by multiple processes. It seems silly that these processes can't share their compilation efforts.

We have a ways to go with runtimes. The first step is oracle admitting they are the problem.

Bullshit or bafflegab.

[BarbaraHudson]

The proposal summary notes that Java classes would be compiled to native code prior to launching the virtual machine.

If it's all compiled to native code ahead of starting the JVM, what do you need the JVM for? Their use of "native code" here is not what we usually mean. It's just "ahead-of-time" compiled libraries, same as the Android ART.

fantastic!

[Gravis Zero]

Oracle is just a misstep or two away from fully ruining Java. You couldn't ask for a better enemy.

Re:fantastic!

[gweihir]

Indeed. I hope they press on vigorously, because Java becoming unusable would be one of the best things that could happen to the IT world.

Great, now I need a new Java joke

[Anonymous Coward]

I guess this means my favorite Java joke won't work anymore:
Knock knock.
Who's there?
.
.
.
.
.
.
Java

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:Garbage

[binarylarry]

Or you could find developers that know what they're doing?

Re: A real Java compiler?

[lgw]

C++ just requires a thin C layer around the object oriented calls

Ah, yes, the "thin layer" that means you don't work directly with STL vectors, strings and maps, and, well, objects. Also, no exceptions. Bridging between an OOP language and an OOP language via C code means you need two awkward transitions between C-style code and OOP code.

I've done that far to many times. It can be quite constraining for your C++ code, depending on what kind of problem you're trying to solve. Also, that kind of marshaling is expensive. I've worked on plenty of Java codebases where 90% of CPU time was various serialization and deserialization code.

Well, better than nothing, but JNI was really intended to allow small chunks of C code to either do a bit of expensive calculation, or be a custom driver, or just wrap a system call that Java didn't, but in any case be a synchronous part of a Java function call. Much like C# with it's built-in marshaller, which punishes you for doing anything beyond wrapping system calls that the .NET runtime doesn't.

Java 16

[thinkwaitfast]

Java 16 will will be written entirely in executable machine code and will compile to source code.