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.buck...@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
