Sword still hanging over Jigsaw’s head: Public Review Ballot for JSR 376 closes today
© Shutterstock / Bulgn
The finish line is almost in sight but it could turn out to be an illusion as the Public Review Ballot for JSR 376 closes today. Mark Reinhold, the Specification Lead for this JSR, wrote an open letter to the JCP Executive Committee in which he explained why “a vote against this JSR due to lack of consensus in the EG is a vote against the Java Community Process itself.”
All 23 representatives of organizations and individual members voted in the “Public Review Ballot” on the acceptance of JSR 376 and now decision day is finally here. As JAXenter wrote in early May, it is fairly uncommon for members of Java Community Process Executive Committee to publicly announce their decisions ahead of a vote. It’s even more unusual for them to speak up so late in the game.
Is the present Specification for this JSR perfect? No, of course not. It does, however, reflect years of development, testing, and refinement with active feedback from many developers.
Could we make the Specification better if we spent more time on it? Yes, of course we could. What we have now does not solve every practical modularity-related problem that developers face, but it meets the agreed goals and requirements and is a solid foundation for future work.
Should we further delay this JSR—possibly for years—in order to gain “closer consensus” by pursuing a different goal that will likely result in a design so bloated and complex that no working developer would ever use it? I do not see how that could possibly be in the best interest of the Java community.
Although Red Hat Middleware’s decision to vote “no” is not surprising (Reinhold assumes that “they pursued this alternate goal in order to preserve and protect their home-grown, non-standard module system, which is little used outside of the JBoss/Wildfly ecosystem”), IBM’s position is because they have said “very little during the course of this JSR.”
IBM’s recent position appears rooted in a vague desire for “closer consensus” amongst EG members. I would prefer more consensus too, but that is not possible given Red Hat Middleware’s position. I can only conclude that IBM has decided that their interests are best served by delaying this JSR and, also, JSR 379 (Java SE 9)—which is regrettable.
Broad consensus — The apple of discord?
Reinhold opined that “a vote against this JSR due to lack of consensus in the EG is a vote against the Java Community Process itself” and emphasized that the reason why the Process gives Specification Leads “broad decision powers is to prevent EG members from obstructing progress in order to defend their own narrow interests.” In short, the Process “does not mandate consensus.”
We should only move to Proposed Final Draft when the EG reaches broad consensus that we are ready to do so, and that decision should be based upon the merit of the specification. Multiple EG members have said that we are not ready yet.
Although Ellison acknowledged that “not all objections will be fully resolved to everyone’s satisfaction, he expected to see consensus on how to move forward especially where the EG objection is that such decisions are likely to be detrimental to the Java community.”
These proposals require a 2/3 majority to be passed. IBM and Red Hat are not alone in their public disagreement and another postponement of Java 9 should not be excluded just yet.
Scott Stark of Red Hat, who posted an open letter detailing objections to Project Jigsaw from both Red Hat and Maven developers, expressed concern that “there will likely be two worlds of Java software development: the Jigsaw world, and the ‘everything else’ world.” His prediction might be right after all.