Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ


Choose your language

InfoQ Homepage News Oracle Defends the Java Module System

Oracle Defends the Java Module System

Leia em Português

This item in japanese

One of the more timely presentations at the 2017 Emerging Technologies for the Enterprise (ETE) Conference was by Oracle JVM runtime lead, Karen Kinnear - 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:

  • Is there anything missing?
    • The module system will detect missing modules when building the module graph.
  • Are there any conflicts?
    • Conflicts between packages are also detected when building the module graph.
  • Is it safe to change an internal API?
    • The module system ensures that internal APIs cannot be accessed from outside the module.

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, as providing:

  • Reliable configuration
    • to replace the brittle, error-prone classpath mechanism with a means for program components to declare explicit dependences upon one another.
  • Strong encapsulation
    • to allow a component to declare which of its public types are accessible to other components, and which are not.

Community Responses

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.

The Aftermath of “No” Vote

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 attempted to clarify some misconceptions surrounding JPMS. On the common objection that the Maven build system will not work with Java 9, Reinhold said it wasn't true; “Maven works fine on Java 9.” But he acknowledged that there have been problems with Maven plugins, including a minor problem with the Surefire testing plugin.

On the concerns 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, according to InfoWorld.

And on the belief among development teams that they would not be able to use Java 9 until they convert all their code, frameworks and libraries to modules. He again said that's not true. Quoting Reinhold:

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. Credit to Oracle as the specification leader and those in the Expert Group who dedicated their time to reaching this milestone.

Reinhold recently proposed a schedule change to the GA release of Java 9. He stated:

In order to be ready for all possible outcomes I suggest that here in the JDK 9 Project we continue to work toward the current goal of producing an initial Release Candidate build on 22 June [6], but adjust the GA date in order to accommodate the additional time required to move through the JCP process. To be specific, I propose that we move the GA date out by eight weeks, from 27 July to 21 September.

The next JSR 376 public review vote is scheduled for Monday, June 26, 2017. Stay tuned!


Editor’s Note

Michael Redlich has been an active participant in ETE since 2008 as an attendee, a speaker, and more recently, as a member of the ETE Steering Committee since 2013.

Rate this Article