JPMS Module Path question

[Alex Buckley]

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.

Alex