Unnamed module and duplicate package

[David M. Lloyd]

One case to consider is javax.transaction.xa, which is part of the JDK 
and also in the JTA API along with javax.transaction.

On 03/09/2016 05:13 PM, Alex Buckley wrote:
> Paul, thank you for asking. The module system's treatment of the unnamed
> module vis-a-vis named modules is probably the biggest factor affecting
> usability of the module system. This is true almost by definition
> because at JDK 9 GA the only named modules in the world will be the
> JDK's while every other class will be in the unnamed module of the
> application class loader.
>
> So please, ask more questions about the unnamed module. I am especially
> interested to know if anyone has JARs that contain javax packages (or
> heaven forbid, sun or com.sun packages) found in the JDK -- such JARs
> are a mortal danger to interop between unnamed and named modules.
>
> Alex
>
> On 3/9/2016 1:47 PM, Paul Benedict wrote:
>> Thank you Alex. Since it's roughly the same as JDK 8, then it's also not
>> worse. I defer to your explanation on that point.
>>
>> Cheers,
>> Paul
>>
>> On Wed, Mar 9, 2016 at 3:37 PM, Alex Buckley <alex.buckley at oracle.com
>> <mailto: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>
>>         <mailto: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
>>
>>
>>

-- 
- DML