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

[Jochen Theodorou]

On 25.04.2017 16:38, David M. Lloyd wrote:
[...]
> 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).

Did you ever think what that means for build times?

If the build tools have to become so powerful to handle all the module 
aspects that the can do dependencies and all that, I really expect them 
to change over to java compilation without the module aspect and at it 
later on when creating a module jar only

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

And let´s not forget about those applications that won´t work as named 
module... after all your read - ability is quite different then.

And another thought... if I make a library, that depends on an automatic 
module... for me that would mean in consequence to employ package 
rewriting and make a fat jar. Otherwise... how can I every know anything 
about the version of the dependency

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

agreed

bye Jochen