JPMS Module Path question
alex.buckley at oracle.com
Thu Jun 15 18:49:09 UTC 2017
On 6/15/2017 4:19 AM, Peter Kriens wrote:
> Ok, thanks. That is a crystal clear answer, I see the module path is a searchable repository.
> Puzzled then. Though JPMS now solves the problem of split packages and shadowing of classes it now introduces the shadowing of modules? Isn’t this the exact problem they called DLL hell :-(
It's true that modular JARs on the module path may not be observable due
to "shadowing", but because they're not observable they cannot pollute
the readability graph with their exports, so it's incomparable to
anything involving JARs on the class path. In more detail:
- [CLASS PATH] JAR Hell is what happens when multiple JARs that
"export" a given package are "observed" and "read" by a given consumer.
The identity of a JAR is immaterial, so each JAR on the class path is
just as worthy of being "observed" and "read" as every other JAR on the
class path. If there are 1000 JARs on the class path, then all will be
"observed" and "read". Unhappy consequence: split packages.
- [MODULE PATH] If JPMS resolution succeeds, then one modular JAR that
exports a given package is read by a given consumer. The identity of a
modular JAR is material, so the consumer specifies ('requires') a
modular JAR on the module path that they wish to be observed and read.
If there are 1000 modular JARs on the module path, then only one with
the specified identity will be observed and read; that's in the
definition of observability. Happy consequence: no split packages.
More information about the jpms-spec-observers