4 ms·
See http://mail.openjdk.java.net/pipermail/jpms-spec-experts/2017-May/000687.html http://mail.openjdk.java.net/pipermail/jpms-spec-experts/201... - I think this
by karianna 9y ago
See http://mail.openjdk.java.net/pipermail/jpms-spec-experts/2017-May/000687.html http://mail.openjdk.java.net/pipermail/jpms-spec-experts/201... - I think this is a decent compromise and a majority of the Maven folsk seem to agree. We're hoping to take it for a test drive this Saturday at another Hackday.
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.
- pas 9y agoThanks! Yes, probably doing this incrementally (or at least as separately from "user land" as possible) would have been much better. Though, this gives full program optimization via jlink, and probably modularizing rt.jar would have needed serious platform/syntax changes anyway. What would you prefer instead?
- karianna 9y agoI'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.