I recently got back from JavaOne, where there was a surprising amount of good stuff in the technical sessions, including a number of very well-prepared presentations on Java 9 modularity and the best way to migrate existing code to Java 9. We also got a hint of Oracle’s plans for Java EE. On the other hand, there was disappointingly little on what we might expect regarding the longer-term future of Java, two or more versions down the road.

Java 9 and modules

To me, the most interesting thing discussed at JavaOne was the upcoming release of Java 9. While Java 9 contains a number of new APIs, by far the most important new feature is the addition of modules (also known as “Project Jigsaw”). Modules are a way of much more closely controlling the encapsulation of APIs so that Java code can only access APIs explicitly exported by a module. Modules also specify what other modules they require, which allows for compile-time and run-time checks to determine whether all the required components are present. Finally, modules are a much more straightforward and reliable alternative to the traditional Java classpath, and allow us to avoid “classpath hell.”

The Java 9 JDK is actually built around this modular framework: The JDK itself is broken down into a set of modules. This allows us to package much smaller and more narrowly targeted JREs (although the term Java Runtime Environment is no longer used). This is a very cool new feature that allows an application to be packaged with those Java features — and only those Java features — that it needs in order to run.

The Java folks did a very good job making the modularity features backward-compatible. You can use the traditional classpath if you want, or you can mix new-style modules and the old-style classpath. You can use jar files built to this new modular framework, or you can use old-fashioned jar files in the old-fashioned classpath. You can also put modular jar files in the classpath (the modular features will be ignored), and you can even put old-fashioned non-modular jar files in the module path along with all the other modules. (The jar file is treated as a special kind of module.) While the rules describing these interactions are a little involved, in reality you don’t need to think about the rules: Things just work pretty much as you’d expect them to.

While Java 9 will likely not be available until next July, all indications are that JNBridgePro will work with Java 9 with minimal changes. We plan to go further than that, though. By the time Java 9 is released, we expect to have explicit support for modularity built into the proxy generation tool.

Multi-release jar files

Another Java 9 feature of interest to us, and related to modularity, are multi-release jar files. These allow developers to write code using Java 9 APIs while allowing the jar files to also work with earlier versions of Java. This is accomplished by putting the Java 9 code inside a special Java 9-specific corner of the jar file, which is ignored by Java 8 and earlier. In the past, when we’ve made use of APIs only available in newer versions of Java while also supporting older versions, we’ve used reflection and late binding to probe the availability of an API at run time. If it’s available, we’ll use it; if not, we won’t. Multi-release jar files are much cleaner, and I expect that we’ll be using them going forward when we want to take advantage of new language features while remaining compatible with older Java versions.

The future of Java EE

The other big JavaOne announcement that everyone was waiting for concerns the future of Java EE. I have to point out that we have no dog in this fight: Whatever direction Java EE takes, JNBridgePro and the adapters will support it. However, many people were concerned because very little new Java EE code had been checked in by Oracle in months, and were afraid that Java EE would be shelved, despite Oracle’s claims that Java EE was still being developed. Oracle’s Java EE announcement at JavaOne did indicate that they want to take Java EE in a different direction, simplifying the platform, focusing on the cloud and on containerization, and moving away from the need for an application server. However, Oracle offered very few details on how this would be accomplished, and suggested that a lot of it would be up to the community. Until we get more details and more evidence of direction from Oracle, there’s really no way to know what the next Java EE will look like. Oracle said that they hope for a release of Java EE 8 sometime in 2017, but that might not be realistic.

Nothing about Java 10?

One of the most interesting things at most JavaOne conferences are hints of where Java will go next. To that end, this year’s JavaOne conference was a disappointment. There was almost nothing about what we might be seeing in Java 10. These hints are usually given in the keynote and in the Oracle kiosks on the exhibit floor, but the Oracle exhibits on the floor had almost no technical content, much less sneak peeks into Java 10. In the keynote (which also had very little technical content, and which had astonishingly bad production values for a major conference keynote), the only statements of what’s to come in Java 10 were that it would likely include type inferencing in the style of C#’s var declarations. I was hoping for more.

In summary, there was a lot of good stuff in the technical sessions, particularly about Java 9 and its modularization capability and multi-release jar files. Java EE 8 lives, but it remains a work in progress, and we’ll need to wait a bit before we learn more. As for Java 10, and the longer-range future of Java, there was surprisingly little, and that was a disappointment.

Did you attend JavaOne? Let us know your impressions!