On 04/25/2017 07:08 AM, Stephen Colebourne wrote:
On 24 April 2017 at 19:54, <mark.reinh...@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
