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

[Stephen Colebourne]

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.

On another thread you wrote:
On 24 April 2017 at 16:46,  <mark.reinhold at oracle.com> wrote:
> Automatic modules are best viewed as a transitional tool that allows you
> to modularize an isolated, unpublished set of components in a top-down
> fashion over time.  You can use existing published JAR files, from Maven
> Central or elsewhere, as automatic modules.  The names and APIs of those
> automatic modules are unstable and will change as they are modularized
> explicitly, but in an isolated set of components you can easily adjust
> your own `module-info.java` files as needed to cope with those changes.

And for what benefit? Why would a company put itself through the pain
of relying on potentially thousands of external dependencies via
automatic modules, taking a hit every time one gets converted to a
real module. Where is the payback for that company? What is the
benefit they gain? If this is the only use case for automatic modules,
then they should be dropped.

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.

For example, there are 42 separate projects at Apache Commons, some of
which have multiple release streams - thats an awful lot of work
you're expecting unpaid volunteers to do, particularly when each has
to be released in order. (A typical release at Apache Commons is a
multi-week affair, so even if Apache Commons had the energy to release
everything, it would take all their energy for well over a year.)
There are even 11 different Joda projects to work on, with active ones
depending on less active ones, I would be forced to do artificial
releases just to satisfy a bottom-up migration.

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
artifacts. When a version is changed, sometimes things break, and we
fix them. This is all normal software development. It is not something
for JPMS to try and fight or fix.

As discussed before, removing automatic modules and allowing modules
to have partially specified dependencies [1] 1b allows projects to
migrate to modules immediately. This would be a huge win. Any project
that is interested could write module-info immediately, even if all it
was doing was specify the exported packages. They would release within
their normal release cycles, and depend on whatever other modules are
already released at the time of release. As more and more modules
become available, the partial requirements will turn to complete
requirements, and thus explicit modules.

Plus, it is really easy for the build tool to work with. If the jar
has a module-info it goes on the modulepath, otherwise it goes on the
classpath. And AFAICT it would just work.

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.

Stephen

[1] http://mail.openjdk.java.net/pipermail/jigsaw-dev/2017-March/011686.html