Alternatives for naming automatic modules, and a proposal (#AutomaticModuleNames)

[David M. Lloyd]

On 04/25/2017 09:15 AM, Brian Fox wrote:
>
> On Tue, Apr 25, 2017 at 9:10 AM, David M. Lloyd <david.lloyd at redhat.com
> <mailto:david.lloyd at redhat.com>> wrote:
>
>     I agree with everything except for this last point.  I think that,
>     given the amount of evangelism over the past 5 or so years, people
>     will adopt JPMS whether or not it is a fit for their use case.
>     Different shops will use different tooling in different ways to work
>     around these problems; I expect that automatic modules will probably
>     be mostly ignored except for "hello world" type cases in any event
>     though.
>
>
> How would shops do this if everything they need from the ecosystem is
> itself unmodularized? Maybe app authors will do so and take the pain
> begrudgingly, but all the libraries that make Java such a powerful
> ecosystem probably won't because they'll be caught between downstream
> and upstream users.

I think that Maven- and Gradle-based tooling will appear to fill this 
need.  The only correct solution (automatic modules or not) to 
modularizing arbitrary groups of artifacts will likely involve a 
separate assembly step which will inevitably include writing or 
rewriting module descriptors.  I expect that the tooling will use the 
artifact dependency graph, module descriptors and/or other metadata 
present on the artifacts, and some manual configuration as input, and 
then produce as output a collection of corrected/re-written module JARs 
(and probably a complete wiring report that can be checked over by human 
eyes, probably with admonitions relating to potential or definite problems).

I really don't see any other way things could possibly work consistently 
for any application which uses external JARs.  Automatic modules are 
just going to be a stumbling block to reaching this conclusion.

OSGi, by the way, avoids this situation somewhat more effectively than 
Jigsaw can, mainly because of three factors: resolving by package 
instead of by bundle name, performing the bulk of resolution work at run 
time, and by the simple fact that it is less invasive towards 
reflection, thus there is more "wiggle room".

This isn't to say that OSGi is an ideal solution of course, but I just 
wanted to point out why the OSGi ecosystem can generally get away with 
publishing artifacts containing descriptor information, while Jigsaw 
probably won't be able to (or at least, not as cleanly).

-- 
- DML