2017/5/4 14:21:38 -0700, Stephen Colebourne <scolebou...@joda.org>:
> On 4 May 2017 at 18:38, mark.reinh...@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
