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

[Remi Forax]

----- Mail original -----
> De: "David M. Lloyd" <david.lloyd at redhat.com>
> À: "Brian Fox" <brianf at infinity.nu>
> Cc: "jigsaw-dev" <jigsaw-dev at openjdk.java.net>
> Envoyé: Mardi 25 Avril 2017 16:38:54
> Objet: Re: Alternatives for naming automatic modules, and a proposal (#AutomaticModuleNames)


[...]

> 
> 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).

yes, 
you need a way to merge an artifact descriptor and its corresponding non-modular jar before the VM checks the modules configuration.

as you said, adding an assembly step after the modules being resolved and downloaded locally and before the VM is started is a solution.
At that point, you can either rename the automatic modules and put the internal dependencies of that module in the classpath or you can rewrite the module infos by doing a static analysis (+ some manual info because of the reflection).

> 
> --
> - DML

Rémi