Hacker News Reader

Comment by kodablah | Hacker News Reader

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?

View on HN

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

There were concerns raised by the Eclipse JDT team (ecj authors) - starting here: http://mail.openjdk.java.net/pipermail/jigsaw-dev/2017-May/0...

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"?

edit: seems there's something about it here:http://mail.openjdk.java.net/pipermail/jigsaw-dev/2017-May/0...

Fixed link: http://mail.openjdk.java.net/pipermail/jigsaw-dev/2017-May/0...

Hi Mike, yep - you've found one of the relevant threads.

I do not speak for the GP comment.
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.

I am not part of LJC nor do I speak for the LJC but I found the following thread very revealing:
http://mail.openjdk.java.net/pipermail/jigsaw-dev/2017-May/0...

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.

Reply on news.ycombinator.com