Auto-modules vs. the unnamed module

Andrew Dinn adinn at
Thu Apr 27 15:16:50 UTC 2017

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

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.

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.

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. And so on up the line. Maybe I have got something wrong here.
Perhaps an expert might like to comment.


Andrew Dinn
Senior Principal Software Engineer
Red Hat UK Ltd
Registered in England and Wales under Company Registration No. 03798903
Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander

More information about the jigsaw-dev mailing list