The Problems Facing the JPMS's Adoption
The Problems Facing the JPMS's Adoption
Will Jigsaw be complete before the Java 9 launch? Probably not, says Java EE Guardian Reza Rahman. Let's examine how and why things went wrong.
Join the DZone community and get the full member experience.Join For Free
FlexNet Code Aware, a free scan tool for developers. Scan Java, NuGet, and NPM packages for open source security and open source license compliance issues.
The EC's "No" vote on the Java Platform Module System took plenty of people by surprise last month. Concerns wth the JPMS ranged from its implementation to fears over the perceived impact it would have on the community, as proposed.
Among plenty of onlookers, Reza Rahman of the Java EE Guardians has been keeping an eye on the proceedings as they've developed, both before and after the vote.
"I'm by no means a modularity expert," he says, adding, "I've been keeping track at a higher level." His main foci have been at the architect level and the impact the modularity debate will have on Java EE 9, as the Java EE 8 spec won't rely on the system.
But given his reach within the industry, and his wealth of contacts, he's at an informational crossroads.
Of course, as Rahman says, "Java modularity is nothing new."
Chief Architect of the Java Platform Group Mark Reinhold discussed it as far back as Java 7, when it was originally supposed to be delivered. Of course, aside from .NET and its DLLs, Java is the last mainstream programming language that doesn't have a modularity system.
Part of the problem is that trying to modularize the JDK means going back through decades of development, back to Java's very inception in the 1990s. Since then, we've seen modular-ish systems spring up — Maven, for instance.
As Rahman sees it, there are two primary goals that the JPMS hopes to address:
Modularizing the JDK: Today, the JRE sits at a robust 150MB — not to mention the JDK, which is around 500MB. That's, obviously, quite large. Of course, attempting to modularize it is "a complicated piece of work," as Rahman puts it, given how far back it goes.
The broader implications: Of course, ideally, a fully formed JPMS would be something that the ecosystem at large could leverage. But that's not easy either. As complicated as modularizing the JDK would be in and of itself, making sure it plays well with application servers (not to mention applications themselves), build tools, etc. All of those components "need to work with the modularity system, or at least recognize the modularity system," Rahman says.
Given the monumental size of the task ahead of them, "the JDK team was kind of set up for failure," as Rahman sees it. "Basically, for the JDK team, it was too large a scope of work."
The team focused almost exclusively on the first goal mentioned above — modularizing the JDK. But even then, as the focus shifted throughout the process, it became clear that the JDK team was, of course, focused on the JDK — and not so fully on the components listed in Goal No. 2, like build tools.
Furthermore, throughout the voting period, members of the Executive Committee pointed out problems with the JPMS. We're not going to delve into everything here, but you can see the famed 34-page document that Red Hat's Middleware Team put out in April for yourself.
IBM's Tim Ellison followed up by saying, "I believe that document demonstrates there is still work required to bring the community closer to an agreement on the proposed standard. Even where the technical issues have already been discussed in the EG, it is incumbent upon this group to make best efforts to understand and resolve any differences. If people feel that their argument has not been considered, then it is not surprising that frustration ensues. I am personally disappointed that the move to call the Public Review ballot was made despite explicit objection from a number of EG members."
For his part, Mark Reinhold disagreed with the assessment, saying, "This document does not raise any substantive technical issues that have not already been discussed in the JSR 376 EG."
Part of the problem," Rahman says, "was that they got a bit blindsided in the Expert Group."
Ideally, all these problems would have resolved at the EG level before the EC even considered a vote. According to conversations Rahman has had, concerns were raised at the EG level, but they either weren't prioritized highly or weren't taken seriously. Similarly, toward the end of the process, when similar concerns were raised by the EC members themselves, the JDK team was more focused on pushing ahead and didn't communicate well, he says. In the end, modularity was possible, but it couldn't be applied to the entire ecosystem.
"It's very easy to under-standardize, instead of over-standardize," Rahman says.
As for the vote itself, that's just how democracy works. A "No" vote is just how this particular JSR played out. It's the whole point of the system — there can't be any dictators on these decisions, Rahman says.
Indeed, Oracle's response to those who said they would be voting against the JSR before the deadline passed seemed to fly in the face of the entire process. For instance, The Register quoted Reinhold as saying that a "No" vote would be "a vote against the Java Community Process itself."
Of course, the entire point of the JCP balloting process is to make sure the wider community is ready to adopt new components. Then again, given how heavily involved Reinhold has been in modularizing Java, Rahman says, it makes sense he would push for acceptance. "I can understand a response like that," he says.
At the same time, Oracle still needed to acknowledge that, from a technical standpoint, the JPMS didn't make sense. Without acknowledging those flaws, the EC members were in a position of voting their consciences, resulting in a 13-10 refusal.
Speaking from a Java EE standpoint, Rahman says he's most concerned with how the JPMS, as it's written, would (or wouldn't) mesh with Java EE.
"The way it’s proposed, it’s very difficult to leverage in Java EE without completely rewriting Java EE," Rahman says. The same goes for Maven, OSGi, and JBoss modules. It's simply not possible as written.
Then there are the procedural problems. As Rahman sees it, the JPMS needed a much wider audience to review it from a much earlier time. "This wouldn't have happened if, for example, there were many people reviewing this from the start," he says. "Part of the problem here is that you need a lot more eyeballs on this."
But while Oracle could have handled things better, Rahman expressed even more disappointment in the community at large. After all, it's hard to fault the JDK team for focusing more on the JDK than anything else. Meanwhile, in Rahman's eyes, most of the community was content to sit back and watch everything unfold.
And while he and others have been heavily involved in past projects, there needs to be a broader group involved, he says. Longtime champions eventually want to move on with their own projects. For example, Rahman says that he doesn't have time anymore to look at OpenJDK lists. At the same time, there's a desperate need for well-versed individuals to get involved. Vendors have partially filled the gap, but he would like to see more people without any sort of axe to grind or other priorities to get involved.
As it is... not so much.
"We have a bunch of complainers," Rahman says.
For plenty of Java users, he adds, the second something changes, the world is ending. Furthermore, few people want to get down into the trenches and actually contribute to projects. No one wants to stay objective, and people are too content to be passive.
"People outside the ecosystem see this behavior and take away bad impressions of Java," Rahman says.
Anyone with a real interest in the JPMS (or any other JSR), should get involved with OpenJDK and join mailing lists, he adds, in order to give back to Java.
So, what does the "No" vote really boil down to?
From a Java EE perspective, "Java EE 8 is not impacted by this," Rahman says. "Java EE 8 is not impacted by Java 9."
But Java EE 9 might be.
On top of that, fixing the problems with the JPMS is going to be difficult. We're a few days away from the end of the 30-day extension that the vote afforded. At the same time, the problems brought to light throughout the process might just be too much to handle in a month's time. Yes, there's been success in modularizing the JDK, but now there's a need to step back and consider use cases.
Rahman isn't particularly optimistic about that part. "Thirty days is not enough to do that, I think," he says. "Obviously, something went wrong."
As presented, he adds, it shouldn't have gone to the EC level at all. To fix the problems with the JPMS, Rahman focused on three steps:
Ensure everyone knows about the technical issues preventing its adoption.
Have detailed, requirement-level conversations across all the stakeholders.
Go back to the drawing board to hammer out the design problems.
"The one thing they could do is scale back the scope of modularity," Rahman says. But even that isn't easy. Even leaving capabilities out could create more complications, as the team would have to address anything they take out. "It's not an easy thing to do," Rahman adds.
And that brings us to Java 9.
Given just how much work needs to be done to persuade the "No" votes to change their minds, Rahman says, it's unlikely the JPMS will be ready for next month's July launch. Whether that means a delay in the language or putting off the JSR for another version remains to be seen.
And who knows? Maybe the JCP can pull a rabbit out of its hat and get everything ready in time.
Opinions expressed by DZone contributors are their own.