Doesn’t this kind of error only happen when a second module exports the same _class_? What is the problem with another class being defined in the same package, given that package B isn’t going to access that new class at all?
- Russ > On Mar 9, 2016, at 4:37 PM, Alex Buckley <alex.buck...@oracle.com> wrote: > > Presumably you would count the equivalent scenario on JDK 8 -- my package A > is in Alex.jar on the classpath and your package A is in Paul.jar on the > classpath -- as a security issue too, because some of my classes may > substitute for yours (or some of yours for mine, depending on how the > classpath is constructed). > > On JDK 9, we do the "substitution" cleanly. Package A is not split. That > avoids one category of error (ClassCastException). What about poor package B > that finds itself accessing a different package A than it was compiled with? > Well, since package A is exported by a named module, it's reasonable to > assume that the named module "owns" package A [*], and that the developer of > package B co-bundled some version of package A without renaming it. Dangerous > in JDK 8, dangerous in JDK 9. (We're trying to encapsulate the internals of a > module, which is different from trying to isolate modules from each other.) > > [*] Advanced scenario: the named module exporting A is actually an automatic > module which happened to co-bundle package A. By placing this JAR on the > modulepath to form an automatic module, it dominates the JAR left on the > classpath which also co-bundled package A. > > Alex > > On 3/9/2016 1:17 PM, Paul Benedict wrote: >> 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 >> <mailto: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 >> >>
