With the impending arrival of Java SE (Standard Edition) 9 this summer, developers will get more than modularity, which has been the most highly touted feature of the upgrade. They'll also get an experimental implementation of AOT (ahead-of-time) compilation, which is intended to improve application startup times with limited impact on peak performance.
Java ME (Micro Edition) has long supported AOT, but Java SE has not—a decision that Java's former owner, Sun Microsystems, made many years ago.
Like Java 9's new modularity, AOT is drawing some mixed reviews from developers.
The Java Enhancement Proposal for AOT says it's about compiling classes to native code before launching the virtual machine. Because Java programs can become so large, it takes a long time for the current JIT (just-in-time) compilation to warm up completely, so infrequently used Java methods may not get compiled at all.
But AOT may not turn out to be the blockbuster some in the Java community had hoped. "Given the experimental status—and the limitations in the initial release—for JDK 9, it is unlikely to have any intended, or actual, impact on the general developer population on the JVM," said Viktor Klang, CTO at Lightbend, which develops software infrastructure using Java and the Scala language for the JVM.
The official AOT proposal notes that AOT compilation of any JDK modules, classes, or user code is experimental and not supported in the release. "Performance testing shows that some applications benefit from AOT-compiled code, while others clearly show regressions," the proposal says. As such, developers are advised to use AOT as an opt-in feature and to do AOT compilation only in trusted environments. Furthermore, JDK 9's AOT is restricted to Linux x64 systems running 64-bit Java with either Parallel or G1 garbage collection.
To use the AOT'd java.base module during this experimental period, users must compile the module and copy the resulting AOT library into the JDK installation directory or specify it on the command line.
Still, AOT "will give an opportunity for experts to find possible use cases and see where it could provide measurable benefits in practice," Klang noted. Dmitry Leskov, director of marketing at Java technology vendor Excelsior, is more positive about the long-term potential of AOT. "Now that AOT is kosher, more developers will become interested in it and if there will be enough interest from Oracle customers, more positives may come in the future," he said.
"One of the benefits will be reduced JVM startup times, which means more people may use Java to build command-line tools, similar to what's available in static typed languages," said Beiyang Lu, CTO at code intelligence provider Sourcegraph.
AOT's faster startup time and smaller code footprint should especially benefit cloud and hosted services, Klang said. "In the times of distributed, reactive microservices-based architectures, short-running services will profit immediately from more aggressive optimizations that on a JIT-compiled run only kick in after a minute or two." Desktop Java apps will see similar startup improvements, Klang said, such as for command-line utilities and build tools.
Open source developer Carlos Ballesteros Velasco, who has worked on the Jtransc effort related to AOT, has reservations about whether AOT was still bounded to JVM. He cited iOS development in particular, because iOS doesn't allow JIT compilation except in Apple's own JavaScript engine.
Pure AOT also does not let developers generate code dynamically, which is useful in some cases like fast evaluation at runtime, making some reflection faster, or running dynamically typed languages on the top of the JVM much faster than interpreting it, Velasco said.
Excelsior's Leskov said that Oracle should have delayed AOT's debut. "This first public release is way too limited in terms of features, benefits, and platform support while coming with enormous overheads, so it may cause more harm than good, discrediting the idea," he said. "Perhaps it would have been a better option to let it mature a bit in the comfort of OpenJDK and ship a more solid version with Java 10." (Oracle did exactly that with modularity, deferring it from Java 8 to Java 9.)