On Fri, 17 Feb 2017 00:19:43 +0100, Stephen Colebourne
<scolebou...@joda.org> wrote:
On 16 February 2017 at 16:48, <mark.reinh...@oracle.com> 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
itself.
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
specified:
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
}
what I like about this idea is that people are forced to define the
'from', making it less likely to have collisions, even when the result is
something like com.mycompany.mainlib.
What is required is that the first two requirements (base and willow) must
be transformed to their FQN by the compiler.
Assume 'requires base' is actually 'requires base from com.thatcompany'
and mainlib is used together with bootlib, which also has 'requires base'
(but in fact from com.bootcompany).
At this time base will become ambiguous, unless the correct "from" was
appended during compilation.
This proposal would likely prevent quite some collisions.
thanks,
Robert
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
problem.
Stephen
