One of the more timely presentations at the 2017 Emerging Technologies for the Enterprise (ETE) Conference was Oracle JVM runtime lead Karen Kinnear’s presentation – Java Futures: Modules and More. Much has happened since her presentation surrounding, namely the events before and after the…
One of the more timely presentations at the 2017 Emerging Technologies for the Enterprise (ETE) Conference was Oracle JVM runtime lead Karen Kinnear’s presentation – Java Futures: Modules and More. Much has happened since her presentation, namely the events before and after the May 8,2017 JSR 376 public review ballot vote.
Kinnear introduced the Java 9 goals including enhanced developer productivity and improved Java APIs for the cloud. After a review of the Java 9-specific JEPs, she focused on the new Java Platform Module System (JPMS) , also known as Project Jigsaw and JSR 376.
Kinnear encouraged attendees to keep three questions in mind with regard to modules:
Modules can be integrated into existing applications, maintained Kinnear, and she demonstrated the interaction and accessibility between modules and packages, emphasizing the distinction between a module path and a class path. She discussed how developers can migrate to Java 9, particularly when there are incompatible changes, all the while maintaining backward compatibility.
Mark Reinhold, chief architect of the Java Platform Group at Oracle, described the goals of JPMS in his March 2016 white paper; to provide:
Much has happened since Kinnear’s presentation at ETE.
Scott Stark, VP of architecture for JBoss at Red Hat, described his concerns regarding JPMS, notably what Red Hat believed to be a failure to meet major JSR submission goals. Stark summarized:
The Jigsaw implementation is a new module system which has worked successfully for modularising Java itself, but is largely untried in wider production deployments of any real applications on top of the JVM. Many application deployment use cases which are widely implemented today are not possible under Jigsaw, or would require a significant re-architecture.
IBM and Red Hat had publicly stated they will *not* vote in favor of JPMS in its current form.
Despite the lack of consensus, Reinhold submitted JSR 376 for public review, stating this was “in the best interest of the wider Java ecosystem to proceed so that we can deliver on our actual committed goal.” On the day of the public review ballot vote, he also sent an open letter to the executive committee (EC) encouraging them to vote in favor of JSR 376. Despite his efforts, however, JSR 376 failed to pass the public review ballot.
Tony Printezis, JVM/GC engineer at Twitter, explained Twitter’s reasoning for voting “no” on May 8. After discussing the benefits of JPMS and Java 9, he said:
Our main concern with the JPMS is that it is likely to prove disruptive to Java developers, while not providing the immediate benefits that would be expected of such a system. We are worried that this will delay wide-scale adoption of this important technology. We hope that if the JPMS accomplishes some of its original goals more comprehensively it can address real pain points that Java developers have today. In particular: collisions in non-exported package names are arguably incompatible with the “non-interference” and “strong encapsulation” goals of this JSR. But if modules were more thoroughly isolated, it would be sufficient to allow build systems to support multiple copies of the same package by hiding them in modules as non-exported packages. Such tangible and immediate benefits could offset all the hard work developers will have to do to modularize their source code and would encourage more rapid adoption of JPMS.
In an interview with InfoWorld, Reinhold defended JPMS:
A top misconception is that the Maven build system will not work with Java 9. “That’s not true. Maven works fine on Java 9.” But there have been problems with Maven plugins, including a minor problem with the Surefire testing plugin, he acknowledged.
Also, there has been some chatter that developers’ favorite libraries, frameworks, and tools will not work with Java 9. Reinhold acknowledged this might be true today for some elements, but he said there is a good chance they will work in the production release. He noted that the maintainers of such projects have had a lot of early access to Java 9, so they can prepare for its release. That’s why projects such as Spring Boot and Hibernate Validator work with Java 9 now, he said.
A third misconception Reinhold cited is that people seem to believe they cannot use Java 9 until they convert all their code to modules and convert their frameworks and libraries too. “That’s not true, ” he said. Developers can still use the Java class path in Java 9 for the Java runtime to search for classes and resource files. It’s just that with Java 9’s modules, developers no longer need the class path.
Martijn Verburg, co-founder of the London Java Community and CEO of jClarity, spoke to InfoQ regarding the JSR 376 vote. When asked about the benefits of a modularized JVM, Verburg said:
It provides an awful lot more security around the core usage of Java; It hides a bunch of Java APIs that are internal or not safe to use for a day-to-day Java developer; There is a missing gap there in that some of the functionality needs to have safe counterparts provided. There’s a strong commitment to creating a smaller Java at runtime, since Java is split into a set of smaller modules. The jlink tool, which is coming in Java 9, will allow applications to be deployed on a much smaller runtime, such that only install what they actually need. The classic example is that any server-side application will not need any client-side GUIs, like AWT or Swing. That will allow Java to start faster and run things on smaller devices, as well as faster deployments to cloud infrastructure.
Tim Ellison, senior technical staff member at IBM, recently described how to build consensus on JSR 376. He stated:
We look forward to seeing this revised specification being re-presented to the JCP EC, and expect the EC to support the Expert Group in their conclusion. Of particular interest to IBM is the compatibility and migration story for enterprise applications moving to Java 9. There have been important changes relating to migration and the default behavior of JPMS that we believe will be valuable in this area.
JSR 376 is now set to move to a Proposed Final Draft Specification. There may be minor modifications before it is declared a final specification, but the process it has undergone demonstrates that the JCP works to produce a powerful new language feature for Java.
