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

[mark.reinhold at oracle.com]

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