Proposal: #AutomaticModuleNames (revised)

mark.reinhold at oracle.com mark.reinhold at oracle.com
Sun May 7 22:52:46 UTC 2017


2017/5/7 11:50:05 -0700, Robert Scholte <rfscholte at apache.org>:
> With the support of the Automatic-Module-Name attribute in the MANIFEST  
> file all library developers can help their users to provide the intended  
> module name.
> However, for library developers depending on jars that will never become a  
> module it is very frustrating that they can never distribute their jar as  
> a modular jar, unless they shade+relocate those classes or switch to other  
> libraries. Especially for library developers it is a matter of "all or  
> nothing", and the attribute will help with the active projects if they are  
> willing to provide this attribute. But if you depend on just 1 automodule  
> WITHOUT the attribute, you're forced (adviced) to not add a module  
> descriptor. Those are the consequences of these decisions.

Understood and agreed.

The advice to avoid depending upon automatic modules in a published
explicit module should perhaps have an exception to say that it's okay
for such an explicit module to depend upon an abandoned library as an
automatic module.

> I still think that the loose/soft modules is a better fit for the  
> community and maybe it is better to not support both automatic modules and  
> loose/soft modules.

I tried to explain my view on loose/soft/partial modules in the revised
proposal.  I elaborated further over on the jigsaw-dev list, so for the
EG record I'll repeat those thoughts here:

It's true that application developers could get started by writing their
own partial modules, but I don't think that's the best way 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.

>                     Knowing that the decision to have automatic modules is  
> not part of any discussion anymore, the Automatic-Module-Name attribute is  
> a minimum requirement to help migrating.
> 
> I agree on the recommendation to use reverse DNS for modules names.

Given that you appear satisfied with this proposal, I'll mark it as
closed in the issue list.  Thanks for all your help with this topic.

- Mark


[1] http://mail.openjdk.java.net/pipermail/jpms-spec-experts/2017-May/000687.html


More information about the jpms-spec-observers mailing list