Christoph Engelbert on Hazelcast's decision in the Jigsaw ballot

Decision day coming soon for Java 9: Several other JCP Executive Members will vote “no”

Hartmut Schlosser

© Shutterstock / Hayati Kayhan

What will the future of Java 9 look like? Despite criticism from experts regarding the module system Jigsaw, Oracle opened the ballot for JSR 376. Red Hat and IBM announced that they will be voting “no”. We asked Christoph Engelbert, representative of Hazelcast at the JCP executive committee, why Hazelcast has decided not to support the Jigsaw draft.

Java 9 and the Jigsaw vote – Background information

We covered this part before: Oracle called on the JCP (Java Community Process) executive committee to vote on the Java 9 Module System draft (JPMS – JSR 376). All 23 representatives of organizations and individual members can now vote in the “Public Review Ballot” on the acceptance of JSR 376 until May 8.

Both Red Hat and IBM announced that they will vote “no” so everyone is now curious about how other members of the committee will decide in the light of the lack of consensus within the JPMS expert group. Discussions intensified around some technical decisions concerning the Jigsaw specification. As a result, Red Hat, Apache, Maven and others demand another postponement of Java 9 if necessary.

Christoph Engelbert represents Hazelcast at the JCP executive committee and will vote in the ballot. We talked to him about the current state and his views on the debate.

Criticism of Jigsaw – is there something to it?

JAXenter: The module system Jigsaw is currently under criticism. IBM and Red Hat already announced that they will vote “no” in the current ballot on the JPMS Public review. What’s your take on that? 

Christoph Engelbert: In my opinion, there are several reasons why both companies want to vote against the JPMS. Most important is surely the lack of consensus within the expert group (EG). Some issues that were brought forward were shot down or pronounced invalid by Oracle. Many of those points actually do not touch on the JVM internal use case, but rather concern external libraries and frameworks.

Some issues that were brought forward were shot down by Oracle.

Other reasons relate to the “rejected” issues mentioned before —  certain technical decisions, e.g. the question of why module metadata is stored as bytecode instead of putting it into the MANIFEST, as it is done in OSGi.

JAXenter: Do you understand the criticism from a technical point of view? In your opinion, what are the most important arguments against the current Jigsaw draft?

Christoph Engelbert: I partially understand the criticism. However, some of the things criticized are very complex issues that are only important to some users who are trying to implement special use cases. I don’t really understand those anymore and so I have to trust the comments from the community and other EG members.

However, I do believe that it is extremely unsatisfying and even dangerous if certain members of an expert group are considered to be substandard members and that currently seems to be the case.

Furthermore, there are many discussions going on about the naming conventions of modules, e.g. it being explicitly forbidden to include typical versioning name patterns (like 2.0.0) in a module name because module names shall be listable as java identifier, the official explanatory statement says. As the case might be, I believe the reason for this is the fact that modules are compiled to bytecode.

Aside from these issues, there are plenty of others more still to be solved. They include the parameter —permit-illegal-access for this reason, so you can make things work But this again will throw many warnings into the logfile and customers won’t be getting in touch with Oracle about these warnings, but rather with e.g. Hazelcast. I expect our support team to be handling propositions like “What did you do? Why is it broken now?”.

On a personal note, my biggest concern is the manner in which the JPMS is presented. It doesn’t help most applications and libraries. Multi-release JARs – JARs running in Java 8 and 9 – are unnecessary intricacies in the build process. The feature everyone believes they will get, namely multi-version-support, is not a part of Jigsaw in the end.

There is a nice example for this last aspect to be found in the comments on the German JAXenter website. Someone said about the upsides of Jigsaw in the comments section that you can now import different versions of a library without any conflict with Jigsaw. Many believe this but sadly it isn’t true.

Oracle’s position in the debate

JAXenter: It seems that Mark Reinhold claims that goals which are now discussed have never been intended to be met in Jigsaw. He wrote to the mailing list:

“We do not have consensus in this EG on moving forward to Public Review. That is only because some members continue to insist that we must address goals that were neither mentioned in the original JSR submission nor recorded in the agreed requirements.”

What is your take on that?

Christoph Engelbert: I think the answer to this is an easy one. You can just go and use the Wayback Machine and take a look at the old versions of requirements. Nevertheless, I cannot say much in this respect without sailing too close to the wind. I believe in the goodness in people and tend to think those requirements really did not exist 12 years back ;)

Luckily, the world did not keep on turning since then.

JAXenter: In any case, the criticism does arrive late – Java 9 should be released in July this year. Even more, some of the aspects have already been discussed in the expert group – resulting in a different decision. It does seem a bit like IBM, Red Hat, Maven and the others behave like sore losers, harming the whole project by this, doesn’t it?

Christoph Engelbert: The discussions about those problems haven’t started a few months ago. Just take a look at the efforts to fix some major issues with libraries like ByteBuddy or mocking frameworks. That has seemingly been going on forever!

Do IBM and the others present themselves as sore losers here? I don’t think so. Many of the issues being discussed now are relevant to real world usage and need to be addressed. The trouble with this JPMS is that it isn’t just affecting some small, defined area, but actually almost all applications. Many of the changes are highly drastic and bring along corresponding restrictions.

An example: Some small change applies to the dynamic addition of Java Agents, which won’t be possible just like that anymore – rendering most debugging/tracing tools at least partially useless. However, this change has been discussed in abundance, and most are okay with the result.

It’s true though: People started to get vocal extremely late, probably because everyone hoped that Oracle could still be convinced to turn around. Therefore, I do think that both sides are responsible for this.

What does it mean for Java 9?

JAXenter: How should things proceed now, what do you think? Postpone Java 9, adjust Jigsaw? Is a scenario in which the release date is not changed while still carrying out all the adjustments to Jigsaw still possible? In a completely different fashion?

Christoph Engelbert: This is probably the most difficult question. I think there will still be several other JCP executive members voting “no” on JSR 376, including us. The current state of affairs is delicate. I had a discussion on the topic with some interested members of the German-speaking Java community. It was quite easy to gather the right people because there has been a Slack group for this community as of late.

Several other JCP executive members will vote “no”, including us!

It isn’t that easy to envision how to proceed though. If the EG voting results are overall positive, JSR 376 will be released in the current version. If the ballot results are negative, there will be a chance for rework – with consequences for the release date. Certainly there won’t be enough time to remove Jigsaw again anyway, so it “must” be released one way or the other.

The key question will be how Oracle reacts to a negative ballot result. Let’s just hope for the best :)

Hartmut Schlosser
Hartmut Schlosser is an editor for JAXenter and a specialist in Java Enterprise-Technologies, Eclipse & ALM, Android and Business Technology. Before working at S&S Media he studied Computer Science, Music, Anthropology and French Philology.

comments powered by Disqus