JBoss Developer Blogs

Red Hat has voiced their concerns in the following document, linked in their comment: https://developer.jboss.org/blogs/scott.stark/2017/04/14/critical-defi… Found a follow up in this blog post: https://blog.plan99.net/is-jigsaw-good-or-is-it-wack-ec634d36dd6f Interesting to see Twitter voting No as well, with the comment "Our main concern is that it is likely that this JSR will prove disruptive to Java developers, while ultimately not providing the benefits that would be expected of such a system".

I feel like some of these complaints, such as (edit: some of) those by redhat, could have actually been mentioned even before any development on jigsaw began. It's a bit odd to me that these really large complaints come out now, instead of much earlier in the stage of JDK9. Maybe even before any work would have been done on red hat. Such as noted here https://developer.jboss.org/blogs/scott.stark/2017/04/14/critical-defi… > Fragmentation of the Java community That seems like a valid concern, which could have been made much earlier. Or maybe they have but people decide to push on with jigsaw anyway? I did not really follow JDK9 development all that much, apart from the occasional blog. But it just feels to me like at least _some_ of these issues should have been raised much earlier.

On 2017-05-03 Red Hat voted No with the following comment: Red Hat is voting NO on this JSR. The Red Hat middleware team, other members of the EC and Java community members, have mentioned publicly and in more detail our concerns (here https://developer.jboss.org/blogs/scott.stark/2017/04/14/critical-defi… and here https://developer.jboss.org/servlet/JiveServlet/download/38-155022/JSR… We have also discussed with our own OpenJDK team, which made good counter arguments to several of the concerns, but in the end we believe a NO vote is the correct course of action. In previous votes and comments on the EG list we have articulated the view that from a middleware/SE developer perspective we believe that Jigsaw does not fulfil its original goals of being a module system which can be used by the likes of Java EE. We understand that after inception the original goals of the EG were initially changed to try to focus it on a module system to be used solely to modularise the JVM and that caused some architecture and implementation approaches which made it difficult for it to be a module system to be used by SE and EE developers. Unfortunately during the lifetime of the EG the goal appeared to switch back to trying to make it a module system for Java developers but previous implementation decisions appear not to have been revisited or could not be changed and as a result the expectations around Jigsaw have…

Now that is a trip down memory lane. Back in 1994 I was working on a strong capabilities security model for Java with a cryptographic signature based class loader. Amongst the challenges of doing such a system was having a strong versioning system, clear and enforced lines between public and private interfaces, and a dynamic bytecode editing system which would actually elide capabilities from the class being loaded that weren't authorized (system is no good if reflection can show you things you aren't supposed to see right?) Reading that proposal I can see that Jigsaw has run up against and is trying to 'create' some (but not all of course) very similar features on which to host a module system. And some of the very same arguments come up against them. In particular this statement from the recommendation[1]: 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. Is nearly a word for word echo on the reasons why my 'overly complicated and invasive' security requirements would all the people writing Java code that really didn't care all the much about such strong security guarantees. I don't have a position one way or the other, I've been out of the Java world for a long time now, but it really struck me like Deja Vu to read that objection. [1]…

Why Red Hat voted no: https://developer.jboss.org/blogs/scott.stark/2017/04/14/critical-defi…

Here is maybe some reasoning behind the no votes Concerns Regarding Jigsaw(JSR-376, Java Platform Module System) https://developer.jboss.org/blogs/scott.stark/2017/04/14/critical-defi…

The link in the mail https://developer.jboss.org/blogs/scott.stark/2017/04/14/critical-defi… contains much more detailed discussion on Jigsaw concerns by "members of the Red Hat middleware team, Apache Maven chair, Paremus, Sonatype, as well as other Java Executive Committee(EC) members"