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

[David M. Lloyd]

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
> aberration.
>
> 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 
matching problem.

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

-- 
- DML