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

[Juergen Hoeller]

A related note from a Spring perspective:

If automatic module names for third-party dependencies are not to be baked
into higher-level module descriptors, we'll have to wait for all of our
(optional) dependencies to ship module descriptors first, which
single-handedly moves our target date to 2019, possibly into Spring 6
(instead of 5.x). Spring is a typical example for the end of the food chain
here: Such aggregated open source application platforms can only be
properly modularized at the very end of the Jigsaw community adoption
process.

For the time being, we'll have to keep focusing on the use of our framework
jars as automatic modules... which works fine for us so far. Even if the
lack of transitive dependencies is a bit of a nuisance, there is enough
value for somebody choosing to adopt Jigsaw at the application level. I
don't see automatic module names in application descriptors as a big deal
here; application developers need to be prepared to adapt to the eventual
naming policies chosen in the community's modularization efforts.

We might ship some aggregator modules with Jigsaw metadata (i.e. empty jars
with just a module-info descriptor, aggregating a selection of automatic
framework modules including transitive dependencies as well as selected
third-party modules) if there is enough demand over the next two years...
That's the best we can do towards idiomatic use of Jigsaw at the
application level in this multi-year period where the underlying open
source library landscape isn't fully modularized yet.

Juergen


On Mon, Apr 24, 2017 at 8:54 PM, <mark.reinhold at oracle.com> wrote:

> 2017/4/24 10:39:25 -0700, Brian Fox <brianf at infinity.nu>:
> > On Mon, Apr 24, 2017 at 12:14 PM, mark.reinhold at oracle.com wrote:
> >> The problem with any approach that allows you to give a stable name to
> >> what is otherwise an automatic module is that the API of that module is
> >> inherently unstable.  If and when the module is completely modularized
> >> then its API will almost certainly change, which in turn will require
> >> incompatible changes to any previously-published fully-modularized
> >> modules that depend upon it.
> >
> > I don't quite follow, why does modularizing a module imply its public api
> > will change?
>
> The effective API of a module is determined by the packages that it
> exports and, also, by the packages exported by the modules it depends
> upon, directly and indirectly, via `requires transitive` clauses.  The
> effective API of an existing library that's used as an automatic module
> is inherently unstable in two ways:
>
>   - When you modularize the library explicitly, with a `module-info.java`
>     file, you'll have to decide which packages to export.  Packages that
>     are meant only for internal use should not be exported, but when your
>     library was used as an automatic module those packages were exported.
>     If you choose not to export those packages when you modularize then
>     code in other modules that references types in those packages will
>     break.
>
>   - When you modularize the library explicitly you'll also have to decide
>     which modules it requires transitively.  This will almost certainly
>     further reduce the number of packages accessible to modules that use
>     your module, and perhaps dramatically so: When your library was an
>     automatic module it transitively required every other automatic
>     module observable at compile time or run time, thus making every
>     package of every automatic module accessible to modules that use your
>     module.  Even worse, this set of packages depended upon the context
>     in which the library was used; you can't compute it just by examining
>     the library and its known dependencies.
>
> 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.
>
> If we define a way to give stable names to automatic modules, as the
> `Module-Name` manifest attribute would do, then that would tend to
> encourage the publication of named automatic modules and, further, the
> publication of explicit modules that depend upon them.  All of these
> modules would rest on shaky ground, if not actual quicksand.
>
> If we encourage developers at large to take this approach then I worry
> that many will give up in frustration when they try to modularize their
> named automatic modules, later on, with explicit `module-info.java`
> files.  We'd wind up, in the long run, with public repositories that
> contain lots of named automatic modules but few actual explicit modules,
> when what we want to see is lots of explicit modules.  The best way to
> attain that long-term goal is to minimize the chances for pain and
> confusion along the way, and if that means a slower pace of migration
> then so be it.
>
> - Mark
>