Will Jigsaw lead to the fragmentation of the Java community?
Two boys in school image via Shutterstock
The countdown to the Java 9 release has begun — in just 100 days, we’ll be able to take it for a spin. However, some of the members of the Java Platform Module System expert group claim that we shouldn’t pop the champagne just yet. Is Jigsaw really that flawed or is it a worthy opponent to JBoss Modules and OSGi?
When Mark Reinhold, the Chief Architect of the Java Platform Group at Oracle announced in a message on the OpenJDK mailing list that the schedule for Java 9 would be delayed to July 2017, he claimed that Project Jigsaw, the most important feature of the release, “needs more time.”
As the release date approaches, some people seem to have doubts about Project Jigsaw and the changes it brings along. Red Hat’s Scott Stark along with other Java Executive Committee(EC) members revealed in an open letter that they have some concerns about the JSR-376 Java Platform Module System specification and the Jigsaw implementation of that specification. According to the document, “Jigsaw should not be considered an acceptable complete solution on its current merits.”
They claim that although “many of the issues could be fixed in a short amount of time, others might require a bit more time to get right.” As a result, they think that “a small delay is worth the cost if the alternative is rushing a solution that doesn’t cover all use cases. It might also be possible to add additional hooks that could be leveraged by third-party code to improve the experience.”
Is Jigsaw really the boogie man?
According to the JPMS open letter, “the patterns introduced within Jigsaw are (in some cases) going to be extremely difficult to fix even in a later release, and will create backwards- and forwards-compatibility problems that will be very difficult to unwind.”
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.
Furthermore, they say that the lack of sufficient interoperability capabilities and unnecessary restrictions will lead to the fragmentation of the Java community.
There will likely be two worlds of Java software development: the Jigsaw world, and the “everything else” world (Java SE Classloaders, OSGi, Java EE, etc). A library developer will either need to pick which world to support or deal with the burdens of a hybrid strategy. The lack of equivalent use-case coverage will discourage migration, prolonging the impact.
Long story short, Jigsaw presumably fails to offer the following benefits:
Mike Hearn, Lead platform engineer at R3 CEV, was one of the people included in the letter (due to having written an email with suggestions, he says) but that doesn’t mean he fully agrees with the content of the letter, especially since some of the people included in the open letter work on Jigsaw’s competitors [like JBoss Modules and OSGi].
Hearn wrote in a blog post that “we have to cut the Oracle team some slack because they’re attempting to build a module system for the masses.”
I am unconvinced this process would be easier if Jigsaw was simply a clone of OSGi or JBoss Modules. To get developers to modularise their apps it isn’t enough to simply make a module system.
How much of this is fact?
According to the open letter, “the proposed Jigsaw implementation is a cleanroom invention of a module system which is wholly untried in any real application deployment situation. Many use cases which are widely implemented today are not possible under Jigsaw or would require a significant re-architecture.” However, this part made Hearn uneasy because calling Jigsaw a “cleanroom” implies that “it was developed in isolation from the outside world.” In reality, Project Jigsaw has had “a multi-year development and feedback period in which the views of other module system creators have been led to substantial design changes again and again.”
Furthermore, the authors state that using binary module descriptors is a mistake because these formats “are considered an architectural regression. Text-based descriptor formats are easier to read, modify, and programmatically manipulate using standard tools.” Hearn claims that this is simply a personal opinion and opines that “text-based configuration formats and protocols have a host of downsides that are simply ignored here.”
Other “myths” debunked by Hearn include versioning and the kill switch which are not as problematic as one would think after reading the open letter. The document also fails to mention the new [major] features Jigsaw brings to the table.
Although Hearn agrees that “modularising the Java ecosystem will take years and involve breaking more than a few eggs along the way,” the situation is not as bad as it sounds — Project Jigsaw should be given a fair chance.
Head on over to Mike’s blog and read his post. Let us know what you think of this discussion about Project Jigsaw in the comments below!