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

[Brian Fox]

I completely agree with Stephen.

While it's technically true you can consider all the exports to be part of
the API, the reality is that most libraries aren't used that way. In fact,
there are commonly accepted tools to detect when you are depending on a
transitive dependency that isn't explicitly declared by you because it is
dangerous. Someone who does this, or is using internal classes doesn't have
a leg to stand on when (not if) they change. As Stephen said, this is just
normal development practices.

The commons example is a great one that shows why the current approach of
enforcing a bottoms up migration just won't work. It won't end up being a
migration, it's going to be a segmentation of the entire Java ecosystem
that will either kill it, or basically stagnate everyone on Java 8 or
legacy non-modules for far longer than the JVM team will want to support.



On Tue, Apr 25, 2017 at 8:08 AM, Stephen Colebourne <scolebourne at joda.org>
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.
>
> 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
>