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.reinh...@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
