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

[Remi Forax]

----- Mail original -----
> De: "mark reinhold" <mark.reinhold at oracle.com>
> À: "Brian Fox" <brianf at infinity.nu>
> Cc: jigsaw-dev at openjdk.java.net
> Envoyé: Lundi 24 Avril 2017 20:54:18
> Objet: Re: Alternatives for naming automatic modules, and a proposal (#AutomaticModuleNames)

> 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.

It will be worst than that.

People want module resolution to be magic, it's what Maven or Gradle provide,
specifies your direct dependencies, we will care about the rest.

If build tools are not able to see existing plain old jars as modules, people will write plugins to work aroud that,
after all, Maven at its core is a tool that patch the deficiency of the classpath by linearizing the graph of dependencies,
so plugins will patch the non modular jars to make them modular and nobody will care how this is done.

In my opinion, having a tool that automatically modularize a bunch of jars is far worst that having authors of modules to delay the time to go full module.


Now about the stability of an automatic module. I don't think we have to care about that.
When migrating to the module world, either it's easy to wrap an existing code into a module and everybody is happy,
or it's hard and people will make a breaking change, create a new name (like common-collection4), and wrap the updated API into a new module.
Unlike with the JDK, as Brian said, people are used to upgrade (not update) their dependencies.


I believe that we should provide a way to be able to require a non modular jar with a stable name, so new project library or application will be able to use old jars as module rapidly,
otherwise it will be the bazaar, by maybe the bazaar can be great, like introducing lambdas in java 8 had the side effect to trigger a rewrite of ArrayList and HashMap,
new tools may rise from the bazaar.

> 
> - Mark

Rémi