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/M

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/012524.html 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).