Unnamed module and duplicate package

[Russell Gold]

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.buckley at 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.buckley at oracle.com
>> <mailto:alex.buckley at 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
>> 
>>