Proposal: #AutomaticModuleNames

Brian Fox brianf at
Thu Apr 6 18:24:57 UTC 2017

On Thu, Apr 6, 2017 at 5:21 PM, <mark.reinhold at> wrote:

> 2017/4/6 1:01:35 -0700, Remi Forax <forax at>:
> > 2017/4/4 16:53:30 -0700, mark.reinhold at
> >> 2017/4/4 3:33:28 -0700, Remi Forax <forax at>:
> >>> 2017/4/3 9:30:15 -0700, mark.reinhold at
> >>>> ...
> >>>>
> >>>> - Do not implement the previous suggestion to define a `Module-Name`
> >>>>  manifest attribute [4][5].  It would be confusing, because it would
> >>>>  establish two ways to name a module, one of which is rooted in the
> >>>>  past.  It would also make it easy for people other than the author
> >>>>  of a module, e.g., tool maintainers [6], to try to establish the
> >>>>  module's name via the default effect, a move to which many module
> >>>>  authors would understandably object.
> >>>>
> >>>> ...
> >>>
> >>> Yes, the idea of using the "Module-Name" manifest attribute is an idea
> >>> of the past, but it's a quick fix that library author can use to
> >>> reserve the name of their module before anyone choose a name.
> >>
> >> There's another quick fix: If you don't like the automatic-module name
> >> of your library then rename its artifact to have an automatic-module
> >> name that you do like.  It's fairly straightforward to rename artifacts
> >> in Maven [b].
> >
> > yes, but that not the point, the point is to have a stable name.
> Agreed -- an automatic module name computed from the name of your
> artifact, even if it's a name that you like, is not quite as stable
> as the value of a `Module-Name` attribute would be.  Still, it is
> a way to help prepare your users for the future.
> >>> Creating a module-info only works if all your dependencies are modular
> >>> too, that's why we have automatic module.
> >>>
> >>> ...
> >>>
> >>> Perhaps a middle ground is to allow 'Module-Name' in 9 and emit a
> >>> warning like --permit-illegal-access if an automatic module with a
> >>> "Module-Name" is used in 10.
> >>
> >> People really hate warning messages today, as they should.  I can see
> >> using them for things that are dangerous from the very start, such as
> >> breaking encapsulation globally.  If, however, we use them for things
> >> that are acceptable now but become unacceptable in some later release,
> >> such as the `Module-name` attribute, then we risk teaching people over
> >> time to ignore all warning messages.  I'd rather not reduce the value
> >> of warning messages in general just to support this attribute for a
> >> couple of releases.
> >
> > ok, so let add Module-Name in the spec, having stable name is really
> > something important, and as i said, it rewards people that migrate
> > soon to the modular world.
> I completely agree that having stable names is important, but I'm also
> firmly convinced that they should be chosen consciously and with due
> care by module authors and maintainers -- and no one else.
> The trouble with the `Module-Name` attribute is that it makes it too
> easy for people other than module authors and maintainers to establish
> the stable names of modules.  That's inappropriate, and we should not
> enable it.

You're clearly referring to build tools here. Our users are your users and
therefore our interests should be absolutely aligned. Our users won't
tolerate the build tool doing something completely stupid.

The ability for build tools to adequately support the jigsaw efforts will
be key to driving adoption, so lets take a step back and analyze the

It's hopefully not controversial and we should be able to agree that in an
ideal world, filename is not the best default module name...however for a
legacy jar without any other mechanism, you feel there's there's no other
choice. In other words, there's no metadata that can be convincingly used
to indicate the author's intended module name.

We disagree on the priority of a "beautiful" name vs a properly name spaced
and unique one. You prefer the former, I prefer the later (although
generally I am a neat-nick on naming, it's just a case of priority for me
in this case). Fine, set that aside for now.

The guidance in your last proposal was to block publishing of libraries
that depend upon automodules. This is largely impractical in the real
world, but lets just assume there's a way to dis-incent library creators
from depending upon an automodule. The problem with this is that no library
creator can ever fully modularize until ALL OF his/her dependencies have
also done so.

With an ecosystem that has transitive dependencies sometimes dozens to
hundreds of layers deep and with some of those very deep dependencies quite
stable and infrequently updated, this will take an eternity before the
ecosystem can get over this hump.

*The build tools can help this migration from the old world to the new one,
but you must let us help.*

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.

> As to encouraging people to migrate to the modular world sooner rather
> than later, just adding a `Module-Name` attribute doesn't really count
> as migration.  Actual migration requires you to write a proper module
> declaration, and if the only way to claim a stable name is to do that
> then this seems likely to encourage more developers to do so.
> - Mark

More information about the jpms-spec-experts mailing list