But isn't what your proposing a security issue? Let's say my package A is in the unnamed module and your package A is in a named module. You basically took over my code; your classes will be substituted for mine.
Cheers, Paul On Wed, Mar 9, 2016 at 2:38 PM, Alex Buckley <alex.buck...@oracle.com> wrote: > On 3/9/2016 10:36 AM, Paul Benedict wrote: > >> From the doc: >> "If a package is defined in both a named module and the unnamed module >> then >> the package in the unnamed module is ignored. This preserves reliable >> configuration even in the face of the chaos of the class path, ensuring >> that every module still reads at most one module defining a given package. >> If, in our example above, a JAR file on the class path contains a class >> file named com/foo/bar/alpha/AlphaFactory.class then that file will never >> be loaded, since the com.foo.bar.alpha package is exported by the >> com.foo.bar module." >> >> I would like some clarification. Correct me if wrong, but I think this >> entire paragraph is really meant to be about the perspective from a >> modularized JAR? If a module has package A, and the unnamed module has >> package A, then of course the module's package A should win. >> >> However, if it is meant to be absolute language, then I disagree. >> >> The unnamed module should be coherent among itself. If the unnamed module >> has package B and relies on classes from package A, it should still be >> able >> to see its own package A. I don't think modules should be able to impact >> how the unnamed module sees itself. That's a surprising situation. >> > > The unnamed module is not a root module during resolution. If your main > class is in the unnamed module (i.e. you did java -jar MyApp.jar rather > than java -m MyApp), then the module graph is created by resolving various > root modules (what are they? separate discussion) and only then is the > unnamed module hooked up to read every module in the graph. > > Hope we're OK so far. > > If some named module in the graph exports package A (more than one module > exporting A? separate discussion), then since the unnamed module reads that > named module, the unnamed module will access A.* types from that named > module. > > It's hard to imagine the unnamed module NOT accessing A.* types from that > named module. Primarily, we need to avoid a split package situation where > code in the unnamed module sometimes accesses A.* types from the named > module and sometimes from the unnamed module. > > You might say, OK, let code in the unnamed module exclusively access A.* > in the unnamed module rather than exclusively access A.* in the named > module. Then you have two problems: > > 1. There are issues for named modules in the same class loader as the > unnamed module -- such named modules MUST get A.* from the named module > rather than the unnamed module, and the class loading mechanism is > incapable of switching based on accessor. It'll be common for named modules > to exist in the same class loader as the unnamed module, as modular JARs on > the modulepath and non-modular JARs on the classpath all end up in the > application class loader (modular JARs as named modules; non-modular JARs > jointly as the unnamed module). > > 2. While the module system is sure that package A exists in the named > module, how would the module system possibly know that package A exists in > the unnamed module? Scanning every class file in every non-modular JAR on > the classpath at startup sounds bad. > > Alex >
