Unnamed module and duplicate package

[David M. Lloyd]

I presume this wouldn't happen if the packages were sealed though, 
whether in Java 8 or earlier or under the unnamed module in Java 9.  Right?

On 03/09/2016 03: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>
> 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
>>

-- 
- DML