EC Rejects Jigsaw

In a 13-10 vote that concluded on May 8, the Public Review Ballot for JSR #376 (formally known as the Java Platform Module System) failed to pass the JCP executive committee's muster. Perhaps the central component of Project Jigsaw, it is now delayed for up to 30 days, an extension afforded by the "No" vote.

The Ayes

Most of the "Yes" votes were made without comment. Those voters included Oracle, Intel, NXP Semiconductors, Goldman Sachs, Azul Systems, Gemalto M2M GmbH, and MicroDoc. The three remaining ayes — V2COM, SouJava, and Fujitsu Limited — touched on the chaotic past few weeks that Jigsaw has had under public review.

Fujitsu and V2COM

"There are a lot of concerns, but we hope EG members will resolve them by the next ballot," according to Fujitsu.

V2COM agreed, saying, "V2COM shares other EC members' concerns, but we believe that all major concerns can be addressed between this ballot and the next ballot."

SouJava

Meanwhile, SouJava went into more detail about its yes vote, intimating that they were, in fact, nearly against the measure. "As others have said, we agree there has been a tremendous achievement in this effort by the team, in something many believed would never succeed," they said. "But the uneasiness of a specification that was not agreed by the EG it was ready for public review led the discussions inside SouJava towards a NO vote."

So, what changed their minds?

"The movement of the Spec Lead in the last few weeks changed the general sentiment, and we are thankful for the effort of solving the issues. We agree with the London Java Community and others that the specification AS WAS SUBMITTED for public review is lacking. We understand that the Spec Lead should focus on an initial release that will be improved later, and we were even willing to accept some compromising on the tooling issues."

But they're keeping their eyes on the situation, particularly regarding independent implementations. They also stated that without satisfaction for those concerns, SouJava will flip from a yes to a no.

"But if the specification does not support independent implementations, it's a bigger problem. Independent implementations are the primary objective of the JCP, and we do not intend to keep the yes vote if the situation persists."

The Nays

In all, 13 EC members voted against Jigsaw as it stands now. As per the chart above, Credit Suisse, the Eclipse Foundation, Ivar Grimstad, Hazelcast, HPE, IBM, Werner Keil, the London Java Community, Red Hat, SAP, Software AG, Tomitribe, and Twitter all voted against the JSR.

Their reasons and rationales were nearly as countless as the stars, but we'll summarize some of the highlights here.

Red Hat

We'll start with Red Hat.

In April, the Red Hat Middleware Team compiled a 34-page document citing a variety of concerns and problems they had with Jigsaw. These ranged from the eminently practical ("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") to wider concerns over its effect on the ecosystem and the community at large ("Due to lack of one to one mapping of use cases (or sufficient interoperability capabilities) and other restrictions, we are concerned that there will likely be two worlds of Java software development: the Jigsaw world, and the “everything else” world (Java SE Classloaders, OSGi, JBoss Modules, Java EE, etc)").

Here's a visual breakdown from their findings of the problems facing Jigaw and its modularity.

While acknowledging that the original goals were changed to focus on modularizing the JVM, Red Hat stated that throughout the process, the focus seemed to switch back and forth between modularizing the JVM and creating a module system for developers.

"In previous votes and comments on the EG list, we have articulated the view that from a middleware/SE developer perspective, we believe that Jigsaw does not fulfill its original goals of being a module system which can be used by the likes of Java EE," according to Red Hat.

Regardless, Red Hat said they were still hopeful about the future.

In conclusion, they stated, "We believe that a more considered evaluation of all input and consensus gathering should not take too much time and would result in something which would be better received by the entire Java ecosystem."

IBM

IBM also detailed why they voted against Jigsaw.

"The JSR 376 Expert Group and the public have raised a number of reasonable issues and concerns with the current public review draft of the specification that warrant further discussion and resolution," according to the voting log. "We advocate work continuing amongst all members of the Expert Group to address the issues documented on the mailing lists. IBM would like to see closer consensus amongst the entire Expert Group before this specification proceeds to the next step."

Werner Keil

Werner Keil also lent his support against the measure in its current form. "I understand IBM's and others reason for their 'No' vote and heard many similar concerns by e.g. the OSGi community or contributors behind major build systems like Maven, Gradle, or Ant."

He added that most of their concerns have yet to be answered by the expert group or Spec Lead, and he questioned whether the JSR was ready yet.

SAP SE

SAP joined many other voters, yes and no alike, in celebrating the progress that has been made to the JPMS so far. "We absolutely recognize the tremendous achievements and the great work that has been carried out until now — by the expert group members as well as (and especially) by the spec lead himself."

But that being said, "While the JPMS is in pretty good shape for the modularization of the Java platform itself, we think that there are still some rough edges for libraries and frameworks outside the Java platform which should be addressed and agreed upon before the final approval of the specification."

And finally, they ended their voting summary with an admonishment of how various parties have behaved in the past few weeks and hoped to see more cooperation in the future.

"Finally, we adjure all members and the spec lead to come back to the table and communicate directly to each other instead of blaming each other through blogs and open letters!" they said.

What Happens Next?

Most of the rest of the no votes echoed similar sentiments to those stated above, but you can read the vote log here for the full details. In any event, Project Jigsaw is on hold for the time being. The ballot, which was not approved by the EC due to the failed vote, will remain where it is for up to 30 days while the expert group works on tackling the issues.

And that probably isn't too far off-track.

Several voters explained that they were close to voting "Yes," but that there are simply too many unresolved issues to go forward at this point.

In fact, a few of the "No" votes were counting on this extra time to hammer out the problems, especially considering the risk of failing at the next level of balloting.

"The risk of passing this JSR through to the next stage is that should it fail the Final Approval Ballot, the spec lead and EG have only 30 days to resolve all issues or the specification fails permanently per JCP rules," according to Tomitribe's vote explanation.

And regardless of the problems facing Jigsaw, no one on the committee seemed to want that to happen.

Java 9's release date is still, officially, July 27.