How to name modules, automatic and otherwise

Stephen Colebourne scolebourne at
Thu Feb 16 23:19:43 UTC 2017

On 16 February 2017 at 16:48,  <mark.reinhold at> wrote:
>  This can be done very simply, with a single new JAR-file manifest `Module-Name` attribute

I welcome this.

> The reversed domain-name approach was sensible in the early days of Java,
> before we had development tools sophisticated enough to help us deal with
> the occasional conflict.  We have such tools now, so going forward the
> superior readability of short module and package names that start with
> project or product names is preferable to the onerous verbosity of those
> that start with reversed domain names.

What tools?

With short identifiers clashes are inevitable. Because the module name
is baked inside the module in binary format, the only way to resolve
the clash is to rewrite the module. The Java platform has not demanded
anything like this before, and I can't see how it meets the reliable
configuration requirement. Rewriting modules as part of the build
system is a red line for me. I need to be able to see that the module
on the module path is the same bits as that from the source of jars.

The standard case to consider is as follows:

- In 2017, a company creates an internal foundation library called
"willow" and it becomes very popular within the company and is used
100s of times
- In 2018, an unrelated open source project starts up with the name
"willow" and becomes very popular. Both now publish modules with the
name "willow" (one privately, one publicly).
- In 2019, the company wants to use the open source "willow" library
(directly or indirectly), but can't due to name clash
- In 2020, the company wants to open source their "willow" library,
but can't due to name clash

The plan outlined, favouring short IDs, provides no solution to this
problem that I can see. There simply isn't the breadth of identifier
to avoid clashes like this (you can't possibly predict the future
where you might need to coexist with an open source module that
doesn't even exist yet). Proposal (A) only tackles automatic modules,
and not the bigger problem where names are baked into the module

The simplest and most consistent option is reverse DNS everywhere.
Everyone understand it and few will object!

An alternative option would be that open source can use short names,
but companies "must" use reverse DNS. But this is far from ideal given
how projects move from private to public, or how companies merge.

Another alternative is some form of group, that may or may not map
onto maven's group, where most of the time it does not have to be

module mainlib from com.mycompany {
  requires base;  // implicit, favours group 'com.mycompany' if there is a clash
  requires willow;  // uses 'com.mycompany' because there is a clash
  requires willow from org.joda;  // explicitly specified, but only
needed to resolve a clash

With this approach, the clash can be resolved, but only needs to be by
the first module in the graph to pull both in. Any transitive use of
the two willow modules would be fine.

In summary, I recognise the desire for short, pretty identifiers.
However, I remain of the opinion that they are highly dangerous for
the wider ecosystem without some additional ability to qualify them.
The are many more private jars than public jars, and the clashes seen
today on Maven Central are just the tip of the iceberg of this


More information about the jigsaw-dev mailing list