Dear Members of the JCP Executive Committee:
I am the Specification Lead for JSR 376, the Java Platform Module System.
The goal of this JSR is to design a module system that is approachable by all developers for use in their own code yet scalable to the modularization of the Java SE Platform itself, as stated in the JSR submission which the EC approved in December 2014.
The present draft Specification achieves that goal, as further expressed in a set of requirements agreed to by the JSR 376 Expert Group in April 2015. The Specification reflects input not only from the EG but, also, from an active community of developers that includes the maintainers of some of the most widely-used open-source Java libraries, frameworks, and tools. We are still working on a few minor open issues, but I am confident that we can resolve them in short order. Just yesterday I posted a revised proposal for the automatic-modules issue raised by some of the core Maven developers, and they have responded positively.
The Public Review Ballot for this JSR will close in a few days. Red Hat Middleware has indicated, as you know, that they will not support this JSR. That is disappointing, but not surprising.
Red Hat Middleware initially agreed to the goals and requirements of the JSR, but then worked consistently to undermine them. They attempted to turn this JSR into something other than it was intended to be. Rather than design one module system that is both approachable and scalable they instead wanted to design a “meta” module system via which multiple different module systems could interoperate on an intimate basis. I can only assume 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.
Designing a “meta” module system would be an interesting project, but it would be even larger in scope and much more difficult than this JSR. By focusing on an audience of module-system experts it would likely result in a design that is far from approachable by all developers. That is why I repeatedly pointed out to Red Hat Middleware that many of the features they advocated were out of scope, but they chose not to accept those decisions.
IBM has declared publicly that they will cast an explicit vote against this JSR. That is disappointing also — and surprising.
IBM has said very little during the course of this JSR. After they announced that they would vote against it they later sent a list of specific issues to the EG, but only in response to a request from another EG member. None of those issues is new, many of them were discussed long ago, and IBM was silent during most of the discussions.
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.
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. It is time to ship what we have, see what we learn, and iteratively improve. Let not the perfect be the enemy of the good.
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.
As you consider how to cast your vote I urge you to judge the Specification on its merits and, also, to take into account the nature of the precedent that your vote will set.
A vote against this JSR due to lack of consensus in the EG is a vote against the Java Community Process itself. The Process does not mandate consensus, and for good reason. It intentionally gives Specification Leads broad decision powers, precisely to prevent EG members from obstructing progress in order to defend their own narrow interests. If you take away that authority then you doom future JSRs to the consensus of self-serving “experts.”
Many failed technologies have been designed in exactly that way.
That is not the future that I want for Java.
Respectfully yours,
Mark Reinhold