Alternatives for naming automatic modules, and a proposal (#AutomaticModuleNames)
David M. Lloyd
david.lloyd at redhat.com
Tue Apr 25 13:10:06 UTC 2017
On 04/25/2017 07:08 AM, Stephen Colebourne wrote:
> On 24 April 2017 at 19:54, <mark.reinhold at oracle.com> wrote:
>> An explicit module that depends upon one or more modules that are
>> automatic today is, itself, no more stable than those automatic modules.
>> It could be broken when those automatic modules are modularized
>> explicitly, and if it `requires transitive` an automatic module then any
>> modules that depend upon it could be broken when that automatic module
>> is modularized explicitly.
> I find this to be a completely artificial pure view of the world. Most
> projects do not have internal packages, and if they do, most end-users
> do not use them. When developers upgrade an artifact in Maven, they
> expect to have incompatibilities, so a smaller set of packages is just
> fine. Its a normal part of software development today, not an
> Frankly though, if you think automatic modules are as bad as you make
> out, you should simply remove them.
I still agree with this point. This is a solution looking for a
> Unfortunately, the concept of bottom-up full modularization simply
> won't work, no matter how much the Jigsaw team hopes it will. The
> process would take forever, may not be possible for some projects,
> will be side-tracked into the release cycles of larger projects, be
> blocked by dead projects and for many other reasons just stall. I'd
> also note that everyone outside Oracle has given the same message.
> The only approach that makes any sense to migration is to drop the
> artificial purity goal. We already have build tools (Maven, Gradle)
> that manage versions, locking them in to form a working graph of
> Worrying about getting incomplete "impure" modules in Maven Central is
> simply the wrong concern. If we keep the current design, and insist on
> no automatic module dependencies in Maven Central, then JPMS will
> simply not be adopted outside a few private niches.
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.
Just the fact that there is the *very idea* of a "fit"/"non-fit" for
JPMS is sad though. It should have been the ubiquitous thing that
everyone was expecting. But denying multiple versions? Blowing up on
run time cycles? Reneging on the idea of being the basis of Java EE 9?
These are things that people will not be expecting.
More information about the jigsaw-dev