How to name modules, automatic and otherwise

[Robert Scholte]

On Fri, 17 Feb 2017 00:19:43 +0100, Stephen Colebourne  
<scolebourne at joda.org> wrote:

> On 16 February 2017 at 16:48,  <mark.reinhold at 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