Java modularity's future takes a hit as Project Jigsaw (JPMS) is voted down

Java Jigsaw’s missing pieces

Part of the Project Jigsaw melodrama came from the fact that both IBM and Red Hat had announced before the JCP vote on Java modularity that they were not going to support JPMS, which is bit of a break from traditional decorum. JCP members don’t typically announce their intentions before a vote happens. Having said that, very few JCP projects are as contentious as Java’s Jigsaw.

“There is still work required to bring the community closer to an agreement on the proposed standard,” said IBM’s Tim Ellision in an April 28th, community email reply to Mark Reinhold, the JCP lead and the highly respected Chief Architect of the Java Platform Group at Oracle. “IBM is also voting ‘no’ which reflects our position that the JSR is not ready at this time to move beyond the Public Review stage and proceed to Proposed Final Draft.” The word ‘also’ in Ellision’s quote refers to Red Hat’s prior announcement that they were not satisfied with the way the Java modularity puzzle was coming together.

“Project Jigsaw’s implementation will eventually require millions of users and authors in the Java ecosystem to face major changes to their applications and libraries,” was Scott Stark’s April 14th bloodletting on what Red Hat perceived as some of the Java Platform Module System’s shortcomings. “Jigsaw’s implementation will eventually require millions of users and authors in the Java ecosystem to face major changes to their applications and libraries, especially if they deal with services, class loading, or reflection in any way.”

All of this public consternation resulted in an impassioned plea from Reinhold to move the Java modularity project forward, despite some of the existing hesitation. “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” said Reinhold. “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.”

Ulterior motives and Project Jigsaw

Seldom spoken in these public discussions is that there are often very private motives behind the JCP wranglings of the big players. Red Hat has their own, open source modularity project which they use in their Wildfly server. JBoss modules has always competed with Jigsaw. IBM’s WebSphere has always had a long history of supporting OSGi. Who knows how these private interests compete with a company’s public ones.

Falling into the ‘no good deed goes unpunished’ category, many of the JCP committee members who voted in favor of Java modularity found themselves in the unusual position of having to defend the fact that they wanted to move Project Jigsaw forward. Azul’s CTO Gil Tene took to Twitter to defend his company’s ‘yes’ vote. “Can a better module system be built? Yes. So can a much better generics systems. And a better way to do Lambda expressions. And…(sic),” tweeted Tene. “Some will adopt JPMS as it is. Many others won’t until it gets better. And that’s OK.”  Personally, I’m kicking myself a little bit because I had Tene on the phone a few weeks ago talking about the Azul’s Falcon LLVM compiler, and I should have asked him more about the JCP vote. We did speak about project Jigsaw, but it was more in terms of JVM performance and improved startup times, as opposed to the upcoming vote.

Gil Tene defends Azul’s ‘yes’ vote on JPMS

Java modularity and the OSGi spec

A number of years ago, way back in 2011 to be exact, Peter Kriens was OSGi’s Technical Director, and he penned a few interesting articles about implementing modular systems in Java, many of which sparked intense debate in the TSS forums. We spoke a few times about Project Jigsaw, and while our conversations took place far too far back in the past for me to quote him accurately on anything, the impression he always gave me was that tackling the classloader issue in Java was an incredibly complicated task, that people who try to implement modularity in Java will run into far more unanticipated complications than they could ever have imagined, and that the purveyors of Project Jigsaw were just a little bit naive about how easy or hard it would be to build a system of modularity right inside the JDK. Six years later, it would appear that many of Kriens’ consternations have been borne out.

Classloaders are a mess in Java. Their existence is understandable given the evolution of the JDK, but what was fine back in 1996 is a bit of an embarrassment as we do software development in 2017. I’ve got complete faith in a guy like Mark Reinhold to get the Java Platform Module System back on track. Hopefully that will happen sooner rather than later.

You can follow Cameron McKenzie on Twitter: @cameronmcnz

Interested in more opinion pieces? Check these out:

• Why the Amazon S3 outage was a Fukushima moment for cloud computing
• Software ethics and why ‘Uber developer’ stains a professional resume
• It was more than user input error that caused the Amazon S3 outage
• Don’t let fear-mongering drive your adoption of Docker and microservices?
• Stop adding web UI frameworks like JSR-371 to the Java EE spec