On Fri, Mar 23, 2018 at 8:49 AM, Stephen Colebourne <scolebou...@joda.org> wrote: > On 23 March 2018 at 13:17, David Lloyd <david.ll...@redhat.com> wrote: >> 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). > > The classes in the modular jar file would still be in the same > classloader (because same classloader module loading is the standard > strategy). Other than encapsulating internal packages, the container > really shouldn't see any changes should it? At some point containers > will support JPMS anyway.
The container won't see any changes, but the framework will if the container is not creating a JPMS module for it. At some point, containers _may_ support JPMS. However, this seems to be turning into quite a technical challenge in practice. And until there are some implementations supporting JPMS, there will be no specs for supporting JPMS (at least, unless the world has gone mad, which perhaps it has). -- - DML
