Alternatives for naming automatic modules, and a proposal (#AutomaticModuleNames)
David M. Lloyd
david.lloyd at redhat.com
Tue Apr 25 14:38:54 UTC 2017
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
> 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).
More information about the jigsaw-dev