Hi all, I'm the EC representative for the London Java community (~6000 Java developers, have lots of global outreach programmes etc) - here's our more detailed post on why we voted "No". https://londonjavacommunity.wordpress.com/2017/05/09/explana... - Happy to answer further questions although I've probably found this thread too late :-)
Thanks for the post (you're not too late at all). I do have a couple of questions if you don't mind:
"For our membership, interoperability with the Maven build ecosystem and the ability to build an alternative compiler implementation (i.e. Eclipse’s ejc compiler) is paramount."
Do you believe that package manager interoperability (even if it is the de-facto one) is the responsibility of the JDK? Assuming not, do you believe that Maven would be unable to work with the module system as proposed? If so, why?
Also, and forgive me if I missed it discussed elsewhere, but what is hindering other JVM implementations with the current spec. If anything, I would think one could argue there are too many features for easy independent implementation as opposed to not enough.
Finally, do you believe those two issues warranted a no? If there were an option for "mostly-expecting-couple-of-future-features", would y'all have chosen that?
We believe that that the Java specification for a new module system does need to have an interoperability story with the package management system that Gradle/Maven provides. In particular, the module system needs to be able to bridge/utilise the packages provided by Maven Central (>1 Million IIRC) and allow the Java ecosystem to transition over time. A hard 'break' from the Maven Central world would have meant two separate Java's (a bit like Python 2/3), which for us meant a No vote. These issues are being ironed out, but they weren't at the time of the voting period, so we erred on the side of caution
We think those issues will be resolved, but we'd prefer to see them resolved before voting yes. In particular:
The grammar for the module-info.java with its "restricted keywords" is highly problematic, since the language it defines is not processable by established compiler technology. Hacks are possible, but they are costly and prevent established error recovery techniques from working.
The JCP's mandate is to ensure that competing implementations can be built and at time of spec submission this was very unclear (better now).
Could you elaborate on "not processable by established compiler technology"? The module spec grammar looks like a conventional programming language grammar and javac can apparently process it just fine. Is this an odd way of saying "it doesn't look like Java therefore it can't be integrated with a Java compiler"?
JDK has a pretty clear social contract to not break the world. Of course, they can reneg; but if you gratuitously break stuff like hosted JVM languages and the de-facto package manager, people are going to reconsider your platform.
This is correct and possibly seems crazy from some other language communities :-), but Java is fairly venerable (20 yrs) and is a backbone platform for many risk averse entities and this strong social contract has I believe added to its longevity and relevance.
Ah, yes, specification details and wording/specificity. Always important when supporting independent implementations, but seems a bit pedantic to warrant a complete "no", but as others in their "no" mention, I would expect it to be remedied before the next ballot.
Could you link to the relevant discussion about Maven and AutoNaming? Has that been resolved? (If yes do you think it's a good resolution?) Do you think the goal of JSR is (was?) sane and relevant to the complete java ecosystem? Was it too much or too little?
I think the JSR did over reach itself. Hindsight is a wonderful thing but I think if the scope had been to just modularise Java itself and then have a separate JSR for a user space module system on top of that, it would have worked out better.
I'll prefix this with "I'm not a language design or modularity design expert". I personally would have preferred that JPMS was treated as an internal JVM/API concern. This still would have meant changes for IDE and tools vendors (rt.jar going away required rework for sure) but would have given more flexible options for a user space modular system to be build on top.
An example is that the Module definition file (Module-info.java) is in Java source code. Despite the compile time benefits (performance, security etc) this brings, it really locks down how user level module systems need to interact with this. I personally would have gone for a straight XML/JSON/Manifest.MF/YAML/Whatever format which wasn't tied to the Java compiler so tightly.
Would it be fair to summarize your objection as procedural rather than substantive? Read that as you expect this to pass in its current form with no changes.
No, there are still substantive issues on the table, we just expect that they'll be cleared up in the next 30 days. But since this is so deeply fundamental to the core platform we're only going to vote yes when we're really certain. If it was a library JSR (say a new Collections implementation) then we may have been more lenient.
if it wasn't just policits why did you vote "no"?
Why didn't you reach out to the developers way before the vote, it's unclear to me, since JDK 9 builds were available as early as middle of 2016 and even then, building jdk9 should be possible by somebody with a voting right. Also a lot of stuff was discussed on the development list.
it's not like everything was uploaded a week before the vote.
We have been in close contact with the developers throughout - we're the Java User Group that runs the Adopt a JSR and Adopt OpenJDK programmes that test these things out as early as we're able. The blog post details one of our global hack days for example.
