Modularization is slated to be the key feature in Java SE (Standard Edition) 9, due in late July. But Java participants Red Hat and IBM have raised concerns that the base module plan could lead to incompatibilities with applications and enterprise Java.
In a recent bulletin, Scott Stark, vice president of architecture for Red Hat’s JBoss group, outlined a litany of issues Red Hat and other Java Executive Committee members have with JSR (Java Specification Request) 376, pertaining to the Java Platform Modular System, a central component of the Project Jigsaw module Java effort.
“The Jigsaw implementation is a new module system which has worked successfully for modularizing Java itself but is largely untried in wider production deployments of any real applications on top of the JVM,” Stark said. “Many application deployment use cases which are widely implemented today are not possible under Jigsaw or would require a significant re-architecture.”
JSR 376 is expected to provide a basis for Java Enterprise Edition 9, due in late 2018. Stark has his doubts, however. “The limitations in Jigsaw almost certainly prevent the possibility of Java EE 9 from being based on Jigsaw, as to do so would require existing Java EE vendors to completely throw out compatibility, interoperability, and feature parity with past versions of the Java EE specification.” Stark said that in some cases, the implementation of Jigsaw contradicts years of modular application deployment best practices already commonly employed by the ecosystem.
Key design points of Jigsaw are predicated on a reductive approach to forward compatibility, Stark said. This works with modularizing Java itself but becomes “restrictive for broader use cases that application deployments have.”
Modular Java, due with Java Development Kit (JDK) 9 on July 27, has been positioned as helping Java better scale to smaller systems. The module system in it was based on JSR 376. “By enforcing the philosophies that make sense for modularization and encapsulation of the Java platform itself into the application domain, the specification actually reduces the ability for application developers to easily adapt to this particular implementation of a module system,” said Stark.
Stark argues that Jigsaw’s implementation will require millions of authors and users in the Java ecosystem to face major challenges to their applications and libraries, especially if they deal with services, class loading, or reflection. As is, the plan results in a new, untested, and unproven architecture for deploying applications in a modular manner. There could be two worlds of Java software development: one for Jigsaw and one for everything else, covering Java SE Classloaders, OSGi, Java EE, and more, according to Stark.
Patterns introduced within Jigsaw could be difficult to fix even in a later release while creating backward- and forward-compatibility problems, Stark said. “The result will be a weakened Java ecosystem at a time when rapid change is occurring in the server space with increasing use of languages like Go.”
In his approximately 9,500-word critique on Jigsaw, Stark also raises issues with service loading, including extensibility and customization. Jigsaw substantially changes the behavior of the ServiceLoader API and could impact compatibility, he said. He also mentioned stability as an issue, with Jigsaw not specifying the order in which services are returned within a layer. He credited Apache Maven Chairman Robert Scholte; Neil Bartlett, of Paremus; Brian Fox, of Sonatype; and several Red Hat employees as helping with his analysis of Jigsaw.
IBM’s Tim Ellison, in a post to an openjdk mailing list late last week, said Stark’s concerns demonstrate “there is still work required to bring the community closer to an agreement on the proposed standard.” IBM will vote no on JSR 376, he said. (Oracle representatives on Monday were unable to provide a response to an inquiry about the issues raised by Red Hat and IBM.)
Due to its complexity, modularity already was deferred from Java SE 8, released in March 2014, to Java SE 9. And Java SE 9 itself was delayed by this same complexity.