Mark Reinhold, chief architect of the Java Platform Group at Oracle, has confirmed that Java Modules, more commonly know as Jigsaw, will be submitted for public review, despite IBM and Red Hat's publicly expressed concerns. In a thread on the OpenJDK mailing list he wrote:
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. It is, however, in the best interest of the wider Java ecosystem to proceed so that we can deliver on our actual committed goal. I have therefore submitted the specification for Public Review despite this lack of consensus.
In response IBM’s Tim Ellison has provided some additional background information as to why IBM will be voting no, in a fairly lengthy message outlining his and others' concerns.
While I understand the desire to keep the process moving along, I believe there is value in listening to the collective wisdom of the EG and respecting their opinion. It should not come as a shock that executive committee representatives talk to the EG members and support their position as to whether the specification is ready to proceed.
It is worth reading the entire comment, but amongst the issues he lists a number of technical concerns, including:
Insufficient isolation - non-exported (private) packages in a module should be strictly an implementation detail. The fact that JPMS defaults to a single class loader per layer means private packages can cause surprising conflicts when being loaded at the same time.
Automatic module names - modules' dependencies are expressed as module names, so implementers providing a standard API must all use the same module name. However, automatic module names are based upon jar file names which are implementation details. We need to decide if module names are shorthand for a set of APIs, or a specific implementation.
Access restrictions break libraries doing reflection - a module must know a priori if it will be open to reflection, and know the reflector's module name. This will break dependency injection etc.
With regards the final point we spoke to Antoine Sabot-Durand, the specc lead for CDI 2.0, currently in public review. As a RedHat employee he, of course, supports Red Hat's & IBM's position, saying
Jigsaw should only have a limited impact on CDI specification, but when it comes to implementation, impact would be huge (reflection parts, proxies handling, class loading). From what I understood Java 9 provides a new Layer API that may solve some class loading and visibility issues, but doc lacks examples and switching to Layers may represents a huge amount of work without no clear guarantee.
However Spring Framework project lead Juergen Hoeller who told us that, with Spring Framework 5.0 RC1 or 4.3.8 running against the latest JDK 9 build 167:
- Open modules do not have to know the reflector's name; they may just optionally limit their exposure to specific modules. An application module can easily declare itself as generally open, or declare specific packages as generally open, to any other module. This is convenient enough and certainly not a design flaw in Jigsaw from my perspective.
- Reflection on exported types works fine without an open declaration; just populating a non-public field or invoking a non-public method eventually fails. This means that we can introspect any exported class for annotations... and as long as we just find such annotations on public constructors/methods, we can perform dependency injection on them in any case - even without an open declaration.
- For dealing with *non-public* members of its classes, a module indeed needs to declare itself or at least the affected packages as open. This affects injection on private fields and data binding to private fields, as well as Spring's use of CGLIB for @Configuration classes and non-interface AOP proxies... which is why we recommend (but do not require) open declarations for use with Spring.
All in all, the use of current Spring Framework jars as "automatic modules" on the Jigsaw module path is a smooth enough experience out of the box, with no custom command line flags needed for Spring's purposes. Applications may declare module dependencies on "spring.context" etc in their own module descriptors, following Jigsaw's automatic module naming conventions. As long as such jar-based module names are alright for the time being (I quite like them for Spring's jars and common third-party libraries), Spring-based applications can opt for a fine Jigsaw setup experience already.
That said, Hoeller also stated that he expected most Spring-based applications to remain on the classpath even when upgrading to JDK 9, primarily for easier integration with third-party libraries such as Hibernate.
New Java standards are adopted by a 2/3 majority vote of the 25-member Java Community Process Executive Committee. InfoQ spoke to Christoph Engelbert from Hazelcast, another Expert Group member, who indicated that Hazelcast is also likely to vote no, telling us
I think the situation is extremely complicated as both sides might be correct about different points. One of the issues Mark Reinhold mentioned is that certain features weren’t requirements originally. While this is most probably correct, to still enforce it means that the world didn’t change during the years of development. That, obviously, is also not correct.
In general, we at Hazelcast, see the missing consensus of the JSR376 Expert Group (EG) and the way it was handled by the Spec Leads as extremely problematic. We haven’t cast our vote yet but based on discussions with the community and EG members we will probably vote "no".
Don’t get me wrong, I mean Jigsaw is an important feature, but it needs some more time or a way to really shut it off. The "big Kill-Switch" is nice but activating it means you get warnings on stdout and those warnings will not show up at the Oracle bug trackers but with our support team (at least for our users and customers). That is the second reason we are most probably going to cast a negative vote.
We understand what this means to the release date but we think a better consensus is important and part of being an Executive Member is to keep the Java ecosystem in shape. In the current state, Jigsaw might still be an issue to a lot of libraries, frameworks as well as applications.
However InfoQ has also learnt that another Expert Group member, Azul Systems, is likely to vote in favour. CTO Gil Tene told us
We are a bit torn on this. I agree with some (not all) of the objections about Jigsaw as a useful module system for Java developers. In my opinion, the lack of support for multiple-versions of the same module existing in a single application alone limits its usefulness outside of the JDK due to practical common case concerns in the real world (my applications uses maven central packages A and B, both of which depend on module C, but A wants C.1.1.0 and B wants C.1.2.1).
However, I believe we will be voting "yes" in spite of all the objections. Much of them arise from dysfunctional communications and overblown expectations. In spite of the valid objections and wishes for Jigsaw (as planned for Java SE 9) to be much more than it is, I can't justify rejecting it as a module system for primarily in-JDK functional purposes (which is how I look at it from a critical Java SE 9 point of view). IMO, the Jigsaw we now have will see limited use outside of the JDK, especially when it comes to libraries and reusable code posted in the wild. The JDK itself never has to deal with the multi-version problem, for example, so Jigsaw as it stands will work there just-fine. My expectation is that the "real Jigsaw" (Jigsaw 2.0?) with wider benefits for non-JDK developers will arrive later. Java 10? or 11? Hopefully not never.... But the in-JDK Jigsaw is close to done and ready to go, and I cannot justify holding back Java SE 9 in the hopes of completely re-doing it, or addressing some of the big ticket items thereby delaying the overall train.
The majority of people we contacted told us they were yet to reach a settled position. Martijn Verburg, for example, representing the LJC, told us
It is extremely rare for a Spec Lead and an Expert Group to disagree so whole heartedly on the submission of a JSR for review. In the ~5 or so years I've been on the EC, I don't recall this situation ever having occurred before.
Voting closes on the 8th of May and the JCP Executive Committee .is currently debating the various positions put out by the Spec Lead and Expert Group members as well as taking into account commentary from members of the wider Java community. They'll be meeting F2F for two days just before the end of the vote and this will be an important topic on the agenda. The London Java Community certainly sees the EC as being fairly representative of the broader Java community, and feel that it is well placed to evaluate whether or not Jigsaw in its current form will be beneficial or harmful to Java and the ecosystem.
Modularisation is hard and the Jigsaw team have put in a tremendous amount of well thought out design and implementation work and in particular we'd certainly hate to see the work done on modularising Java itself be delayed. However, if the broader ecosystem refuses to support the current design / implementation, then it will fail to gain broad adoption and will at the very least cause a lot of frustration in the ecosystem.
Interestingly on the comment thread for our original post on this story, Red Hat's David Lloyd suggested it might be possible to incur a small, further delay and reach a solution
I think a few weeks delay to discuss, introduce, and test the changes required to bring this up to a minimum acceptable state is probably the best (and most realistic) option for everyone.
We'll see what happens next week when the vote closes on 8th May.
