Auto-modules vs. the unnamed module

[mark.reinhold at oracle.com]

2017/4/27 8:16:50 -0700, Andrew Dinn <adinn at redhat.com>:
> On 27/04/17 15:58, Ceki Gulcu wrote:
>> Please forgive my possibly silly question but can someone kindly explain
>> the advantages of placing a non-modular artifact on the module path
>> instead of the class path? In other words, why should the user prefer a
>> non-modular artifact to act as an auto-module instead of its packages
>> being merged with the unnamed module?
>> 
>> If there are no major advantages for placing an non-modular artifact on
>> the module path instead of the class path, then auto-modules serve no
>> real purpose and otherwise just increase entropy.
>> 
>> What am I missing?
> 
> I am no expert but here is how I believe it works:
> 
> Assume you have a jar A containing a library and you want to
> re-implement it as a Jigsaw module.
> 
> Assume also that your library relies on library code in soeone else's
> jar B which they have not implemented as a Jigsaw module.
> 
> So, you add module restrictions to A and try to deploy the code.
> 
> If you add jars A and B to the class path then the module spec you
> provided in jar A will be ignored. Essentially, it will not operate as a
> module.
> 
> If you add jar A to the module path and leave jar B in the classpath
> then jar A cannot resolve classes in jar B. Modules can 'see' other
> classes in the module path but not classes in the class path.
> 
> So, you have to add jar B to the module path. It gets treated as an
> 'export everything to everyone' module i.e. all packages are exported to
> anyone who wants them. It will also be provided with a defaulted module
> name (not that the name makes much difference -- as we will see in a
> minute). So, because jar B is in the module path your jar A can now
> reference classes in jar B without suffering a reference failure.

Good summary, so far.  Automatic modules enable top-down migration,
so that you can modularize your own components before all of their
dependencies have been modularized (which, in some cases, might
never happen).

> What is more, because all jar B's packages are opened to every module,
> your classes in jar A will not be stopped by module restrictions from
> accessing the classes in jar B. That includes the ability to use
> reflection (and setAccessible) on non-public classes. Jar A doesn't need
> to import packages from jar/module B. It gets them for free.

It's true that code in A doesn't need to do anything special to gain
deep reflective access to elements of B, but A's module declaration
will have to say `requires B`, and any source code in A that refers
to elements of B will have to `import` the necessary packages (or
else use fully-qualified type names everywhere, ugh).

> To me this rather undermines the seriousness of the many claims that
> automatic module naming is going to break everything. Once B is
> modularised A needs to be rebuilt to explicitly import the packages it
> exports.

No, A will already have required B, at the module level, and imported
any necessary packages, at the class/interface level.

Module A will need to be revised and rebuilt if the modularization of
B changes B's name, or does not export all of B's packages, or does not
`requires transitive` some other (perhaps formerly) automatic module.

A second advantage of the ability to put non-modular artifacts on the
module path is that it's a stepping stone to full modularization.  To
make a JAR file work on the module path you'll have to fix, e.g., any
existing split-package problems, which is a prerequisite to making it
an explicit module.

- Mark