2017/4/27 8:16:50 -0700, Andrew Dinn <ad...@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
