Revised proposal for #AutomaticModuleNames

[mark.reinhold at oracle.com]

2017/5/4 14:21:38 -0700, Stephen Colebourne <scolebourne at joda.org>:
> On 4 May 2017 at 18:38, mark.reinhold at oracle.com wrote:
>> ...
>> 
>>  - Define a JAR-file manifest attribute, `Automatic-Module-Name`, whose
>>    value is used as the name of the automatic module defined by that JAR
>>    file when it is placed on the module path, as previously suggested
> 
> This is a step forward wrt automatic modules.
> 
>>    If a JAR file on the module path does not have such a
>>    manifest attribute then its automatic-module name is computed using
>>    the existing filename-based algorithm.
> 
> Which we all agree is almost guaranteed to be wrong.

... but it's better than any of the alternatives.

>>  - To increase awareness of when automatic modules are used, and of the
>>    consequences of their use, suggest that Java language compilers issue
>>    two new types of warnings, and implement these warnings in the RI:
> 
> Perhaps these should be reconsidered? If the module depends on an
> automatic module with a module name in the manifest, it can be
> considered reasonably stable. Whereas anything depending on a filename
> derived module name is unstable. That isn't being captured by the
> warnings.

Named automatic modules still have unstable APIs, so I don't think the
warnings need to be changed.  Maybe they could distinguish "unstable
name and API" vs. "unstable API only", but the opt-out warning for a
`requires transitive` directive that refers to an automatic module, even
if named, should be retained since that module's API is unstable.

>> In related threads on jigsaw-dev both Stephen Colebourne [e] and Robert
>> Scholte [f] suggest a new kind of explicit module, variously called
>> "partial" or "incomplete" or "soft", which can read all unnamed modules
>> so that dependencies that have not yet been modularized can be left on
>> the class path.  This is an attractive notion on the surface, and in fact
>> one that we partly implemented in the prototype code base over two years
>> ago, using the term "loose".  We didn't pursue it then, however, and I
>> don't think it's worth pursuing now, for two reasons:
>> 
>>  - If "partial" (or whatever) modules were to replace automatic modules
>>    then application developers would have to wait until all of their
>>    dependencies have been at least "partially" modularized before they
>>    can even begin to experiment with modularizing their own code.
> 
> This seems demonstrably false.
> 
> module com.foo.application {
>   requires com.foo.lib;
> }
> partial module com.foo.lib {
>   exports com.foo.lib;
>   // TODO: requires guava
>   // TODO: requires joda-beans
> }
> modulepath = application
> classpath = guava, joda-beans
> 
> The application developer can write the module declarations above, and
> use them even though all the external dependencies are yet to be
> modularised. It seems clear to me that the application developer has
> modularised their application, even if not completely.

By "modularizing" in the above point I meant "completely modularizing",
but you're right: Application developers could start by writing their
own partial modules.  Is that really the best way, though, to encourage
everyone to approach modularization?

A useful aspect of the present design is that an explicit module is a
complete module.  If you've written a `module-info.java` file for your
component then you're done.  If explicit modules can be either partial
or complete then I worry that many people will partially modularize a
component but then never come back to completely modularize it.

I also think it's essential for a developer new to all of this to be
able to experiment immediately with both strong encapsulation
(`exports`) and reliable configuration (`requires`).  A story that says
"write a partial module now, come back and make it complete later on
after all of its dependencies have been (perhaps partially) modularized"
is a story in which you won't be able to write and debug your `requires`
directives until all of your dependencies have been (at least partially)
modularized.  That could be a pretty long story.

- Mark