How to name modules, automatic and otherwise

[Stephen Colebourne]

On 17 February 2017 at 00:15, Stephan Herrmann
<stephan.herrmann at berlin.de> wrote:
>> 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
>> }
>
>
> From here, wouldn't it be trivial to change Mark's counter example:
>
>     module com.bar:foo.data {
>         exports com.bar.foo.data;
>         requires org.hibernate:hibernate.core;
>         requires org.hibernate:hibernate.jcache;
>         requires org.hibernate:hibernate.validator;
>     }
>
> into a positive example:
>
>     import org.hibernate:*;
>     module com.bar:foo.data {
>         exports com.bar.foo.data;
>         requires hibernate.core;
>         requires hibernate.jcache;
>         requires hibernate.validator;
>     }

There is a subtle difference through. With the two layouts above, the
groupId is always specified. With what I suggested, the groupId is
late binding in the common case, giving a degree of flexibility to
find the matching module.

    module com.bar:foo.data {
        exports com.bar.foo.data;
        requires hibernate.core;
        requires hibernate.jcache;
        requires hibernate.validator;
    }

ie. this looks for hibernate.core on the module path and might find it
from group org.hibernate or from another group. Finding it twice =
error. This flexibility may be good or bad depending on how you view
the world.

BTW, one advantage of groups over reverse DNS is that it forces a
consistent naming scheme on everyone, whereas the current proposal
could well result in a mismash of styles.

Stephen