Unnamed module and duplicate package

[Alex Buckley]

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
>
>
>