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.
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.
regards,
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
