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 <[email protected]
<mailto:[email protected]>> 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
