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

[Stephen Colebourne]

Just to add a note that came up in a twitter conversation.

Modules are not artifacts. [1]
ergo, module names are usually not artifact names
yet, automatic module names are derived from artifact names

Its no wonder that I have seen lots of confusion between modules and
artifacts, Jigsaw itself is mixing the two concepts!

Stephen

[1] http://blog.joda.org/2017/04/java-se-9-jpms-modules-are-not-artifacts.html


On 25 April 2017 at 13:08, 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