On Fri, Mar 23, 2018 at 7:51 AM, Stephen Colebourne <scolebou...@joda.org> wrote: > One approach is to say that modular jar files are always treated as > named modules: > > - a modular jar on the class-path is treated as being named, not part > of the unnamed module It is therefore encapsulated, but depends on the > unnamed module (class-path), so does not have full reliable > configuration. There is the potential for some incompatibility with > this change where code that uses the modular jar now can't access the > encapsulated packages, but this is a Good thing (as the library author > specifically coded for that encapsulation). Any incompatibilities are > smaller than JPMS has already caused, and could be managed with the > existing command line flags. I would hope this does not require a JVM > spec change to achieve.
This would cause problems for containers which do not use JPMS yet (which is to say: containers); such frameworks may behave poorly (having an expectation that they were loaded as JPMS modules) or fail to load (if there is some kind of hypothetical enforcement at a JVM level). > A second approach is to say that the module author must mark modules strict: > > - a module author could mark a module as "strict" in module-info.java > so that it is not permitted to be on the class-path. This does not > force the whole application to move to the module-path - only strict > modules and their dependencies would need to move. At runtime, if a > strict module is found on the class-path an error occurs. I suspect > this requires a JVM spec change, so may be harder. I don't think this would resolve the container problem, though it would allow containers to refuse to load such JARs. I'm not sure that's a net improvement for users though. > Ultimately, the requirement is that library authors who go to the > effort of adding module-info.java should see some benefits in doing > so, where today they only have increased cost through running as both > an unnamed and named module. I agree, we've effectively doubled the testing effort for frameworks due to JPMS, and tripled in the case where frameworks must include MR JAR supplements for 8 vs 9+. In a word, this sucks. -- - DML
