Revised proposal for #AutomaticModuleNames

[Nicolai Parlog]

 Hi Stephen,

the shim only works partially. Qualified exports/opens for example
will not get past it. I did not yet investigate further to see whether
other problems occur.

However much we try module names will never be 100% stable and
providing an aliasing mechanism would solve this as well as other
problems (e.g. dropping in a replacement). But maybe that's something
for Java 9.1 or 10. ;)

 so long ... Nicolai



On 12.05.2017 17:23, Stephen Colebourne wrote:
> On 5 May 2017 at 15:41,  <mark.reinhold at oracle.com> wrote:
>> I suspect what you really mean is "Never publish JARs that refer
>> to automatic modules that do not have `Automatic-Module-Name`
>> attributes". In general that's good advice.  It might even be
>> reasonable for managers of artifact repositories to insist upon
>> it, although I now understand that that could be problematic for
>> a repository as popular as Maven Central.
> 
> I think this is the tricky part. Lets review where we are.
> 
> Firstly, we now have super-package reverse-DNS names and MANIFEST 
> entries. Both of these are a very good thing.
> 
> Secondly, a module with a module-info can now depend on three
> things: - an explicit module with a module-info  (good) - an
> automatic module with MANIFEST entry  (good) - an automatic module
> with name implied from filename  (not good)
> 
> Thirdly, given the nature of Maven Central, it is not realistic to 
> prevent modules with dependencies on names implied from filenames 
> getting into Central.
> 
> My remaining concerns with automatic modules are primarily about
> this last point - we have to accept that there will be modules with
> "bad dependencies" in Maven Central. For example, the graph will
> end up with a dependency on "guava" that breaks when Guava is
> properly modularized and uses "com.google.common" as the module
> name. The result is a graph that does not resolve. While I and
> others will try and communicate this issue to the community, I
> would prefer that the issue simply could not occur.
> 
> 
> However, it has been pointed out to me off-list that there is a way
> to workaround the name change that I had not fully appreciated
> before.
> 
> Given this broken module graph state:
> 
> module com.foo.application { requires guava; } module
> com.google.common { }
> 
> it is possible to fix it by introducing an additional module as
> follows:
> 
> module guava { requires transient com.google.common; }
> 
> With this additional "renaming shim module" in the graph,
> everything now works again.
> 
> Given that there is a potential workaround, I am not as concerned
> as I previously was about this issue.
> 
> 
> Ideally, the creation of this "renaming shim module" should be part
> of the JDK (effectively it is a kind of alias, and the JDK is best
> placed to manage this). However, it should also be possible for
> tools like Maven to provide the shim dynamically when needed. It
> would even be possible to release such a shim module to Maven
> Central and depend on it in the usual way.
> 
> While this is still a workaround to an issue I wish didn't exist
> in the first place, it is a viable solution that I think allows
> automatic modules to proceed as is (given the JSR/release timeline
> pressure).
> 
> Stephen
> 

-- 

PGP Key:
    http://keys.gnupg.net/pks/lookup?op=vindex&search=0xCA3BAD2E9CCCD509

Web:
    http://codefx.org
        a blog about software development
    https://www.sitepoint.com/java
        high-quality Java/JVM content
    http://do-foss.de
        Free and Open Source Software for the City of Dortmund

Twitter:
    https://twitter.com/nipafx