Proposal: #AutomaticModuleNames

[mark.reinhold at oracle.com]

2017/4/6 11:24:57 -0700, Brian Fox <brianf at infinity.nu>:
> ...
> 
> The vision that I had behind the Module Name was simply that we could make
> it easy for module authors starting nearly immediately to choose their
> module name. (There is disagreement within Maven committers over defaulting
> this, so I seem to be in the minority of this and I think you don't have to
> be afraid because of that.) We can make choosing and declaring a name easy,
> maybe even required very soon for library authors. That means that we can
> start to build up the very metadata that is missing and forcing you to lean
> only on filename as the default. We can do so starting now, and by the time
> jigsaw starts to hit critical mass, there will hopefully be very few
> important libraries that aren't already properly named _by their authors_
> as you intend.
> 
> The bar to picking a good name is clearly much lower than fully
> modularizing...especially if you are barred or shamed into doing so before
> all your dependencies have. If you both require that someone is fully ready
> to modularize their own library (and their users are equally ready and
> willing to upgrade to Java9) and after their dependencies have gone first
> before you let someone declare their chosen name in a stable way... well
> you're going to be waiting a long time. Maybe forever.
> 
> On the contrary, if people start declaring their Module-Name now, and the
> rule against automodule dependencies is redefined such that it's ok to lean
> on something with a Module-Name, it becomes very easy and very quick for
> the ecosystem to get to a sane building point for full modularization.
> 
> Without the Module-Name metadata or some equivalent, you are effectively
> barring all the build systems from helping with the conversion to achieve
> the very goal of this entire process.

Build systems and artifact repositories can help, but in a different way
than you propose.

Even if I did trust every tool maintainer not to abuse the `Module-Name`
attribute then I'd still think that giving stable names to automatic
modules is a fundamentally bad idea.  The APIs of automatic modules are
inherently unstable, so it's risky to publish an explicit module, i.e.,
one with a `module-info.class` file, that depends upon automatic modules.
Giving stable names to automatic modules would just encourage that.

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.
Once all of your dependencies have been modularized then it's safe to
publish your explicit modules, if desired.

The modularization of a large repository of actively-used existing
libraries is, by contrast, better done from the bottom up.  If a library
is modularized explicitly, and it depends upon some other libraries that
have not yet been modularized and thus can only be used as automatic
modules, then it's likely to break when those libraries are modularized.
If this library is widely used in modular form then its users will be
stuck with a broken module until its maintainer repairs the problem, and
that repair may in turn require non-trivial changes to user modules.

Bottom-up modularization will take time, and in the case of repositories
as large as Maven Central it will never be complete since, inevitably,
some libraries are abandoned over time.  Available data suggest, however,
that library popularity is a long-tail distribution, so many projects
across the ecosystem should be able to modularize once the most popular
libraries, and their dependencies, have modularized.

Artifact repositories and build tools can be a big help in this process.
If I maintain a library and want to modularize it and publish it as an
explicit module then I need to wait until all of its dependencies have
been modularized, as you correctly pointed out.  If Maven Central and
other repositories could track and publish the modularization status of
every project then a build-tool plugin could tell me when it's safe to
modularize my library.  That plugin could even have a default setting
that reports a fatal error if I try to publish a library that has
non-modular dependencies.  Repositories such as Central could enforce
this constraint as part of their submission requirements.

You wrote that it's impractical to block the publication of libraries
that depend upon automatic modules, but it's not obvious to me why that's
so.  A library is either modularized or not, and all of its dependencies
are either modularized or not.  Version ranges in dependencies complicate
the problem, but if we assume that once a library is modularized then it
will remain modularized forever then it should suffice to check just the
earliest version of each of a library's dependencies.  Is there some
other complexity that I'm missing here?

- Mark