Twitter’s Vote on JSR 376 (Java Platform Module System)

Almost all of Twitter’s services run on the Java Virtual Machine platform. We have a team of engineers who work on performance improvements to our own custom version of the OpenJDK JVM. We are also active participants in the development of the Java platform and are members of the Java Community Process (JCP) Executive Committee (EC), helping provide oversight and stewardship of the Java platform and its evolution. A recent discussion over JSR 376 (Java Platform Module System) within the JCP EC has resulted in a fair amount of controversy amongst the group participants, and given the public nature of this discussion we wanted to provide context to Twitter’s vote on the specification.

We see the introduction of the Java Platform Module System (JPMS) in Java 9, proposed as JSR 376, as a desirable and important addition to the Java platform. It has several features that we particularly like:

• We believe that the enforcement of the dependency rules at compile- and run-time will ultimately lead to software that is better structured and, ultimately, easier to maintain and evolve.
• We strongly support the stronger encapsulation that the JPMS provides, which prevents code from accessing classes / packages that are not exported by the module. This will lead to more reliable, predictable, and more importantly, more secure code in the long-term. In fact, this feature was long overdue.
• We see the ability to create compact runtime images as a very powerful tool that can open up very interesting opportunities not easily feasible today, such as whole-image static analysis / optimizations, image AOT compilation, etc.

We also appreciate that retrofitting a mature and widely-used language like Java with a module system 20 years later is an enormous and very difficult task. We would like to thank the Spec Lead, the Expert Group (EG), and everyone involved for their dedication and hard work in making it a reality.

Our main concern with the JPMS is that it is likely to prove disruptive to Java developers, while not providing the immediate benefits that would be expected of such a system. We are worried that this will delay wide-scale adoption of this important technology. We hope that if the JPMS accomplishes some of its original goals more comprehensively it can address real pain points that Java developers have today. In particular: collisions in non-exported package names are arguably incompatible with the “non-interference” and “strong encapsulation” goals of this JSR. But if modules were more thoroughly isolated, it would be sufficient to allow build systems to support multiple copies of the same package by hiding them in modules as non-exported packages. Such tangible and immediate benefits could offset all the hard work developers will have to do to modularize their source code and would encourage more rapid adoption of JPMS.

For the above reason, Twitter voted No on JSR 376. We hope that the Spec Lead and the EG will work together over the next few weeks to address our concern, as well as all the other issues brought up by the rest of the JCP Executive Committee members who also voted No. We are looking forward to be in a position to vote Yes in the JSR 376 reconsideration ballot.

Thanks to Stu Hood, John Coomes, Moses Nakamura, Nick Howard, Christian Thalinger, and Steve Cosenza for their contributions to this decision and blog post.