[prev in list] [next in list] [prev in thread] [next in thread] 

List:       openjdk-jigsaw-dev
Subject:    Re: Java Modules and Multi-Release Jar
From:       Ralph Goers <rgoers () apache ! org>
Date:       2018-09-30 17:07:34
Message-ID: 1DF4F2AF-A3EA-4624-AFB1-960487FE0FDE () apache ! org
[Download RAW message or body]



> On Sep 30, 2018, at 12:34 AM, Alan Bateman <Alan.Bateman@oracle.com> wrote:
> 
> On 29/09/2018 20:25, Ralph Goers wrote:
> > Following advice I received on this list, the Log4j API jar is defined as a \
> > multi-release jar with the module-info.java file placed in META-INF/versions/9. \
> > This should work fine, yet we continue to have users who are complaining about \
> > various tools, such as Javadoc and Eclipse, that can't handle it properly. One \
> > user has gone so far as to suggest we include the automatic module name in \
> > MANIFEST.MF in addition to the module-info.java file. When I look at \
> > https://docs.oracle.com/javase/9/docs/api/java/lang/module/ModuleFinder.html#of-java.nio.file.Path…- \
> > <https://docs.oracle.com/javase/9/docs/api/java/lang/module/ModuleFinder.html#of-java.nio.file.Path%E2%80%A6-> \
> > I can clearly see that what we are doing should be working. 
> > My question is, if I follow this user's suggestion it will mean that applications \
> > that correctly support multi-release jars will treat Log4j API as an explicit \
> > module while applications that don't will treat it as an automatic module. I \
> > haven't seen any documentation on what the consequences of this would be. To me \
> > it seems like a bad idea but I have nothing I can point to as to why it would be. \
> > Does anyone have any pointers? 
> > FWIW, it seems like the bug I created for Javadoc is marked as fixed for Java 12, \
> > so I would assume when Eclipse fixes its problems this would cease to be an \
> > issue.
> I assume the issue with javadoc and modular multi-release JARs is JDK-8208269 [1]. \
> Are you able to test the Eclipse tool with a JDK 12 EA build? If it indeed a \
> javadoc only bug then we should try to get the fix into a JDK 11 update. 
> I don't recall the discussion here that lead to the advice to put the \
> module-info.class in META-INF/versions/9 - if you can find the mail thread or even \
> the subject line of the discussion then it would help provide the context. In \
> general, the reason to use a MR JARs is where you are targeting a range of JDK \
> releases and you want to take advantage of newer APIs on newer releases. Yes, it is \
> possible to have the module-info.class in the versioned section for the super \
> advanced case where code in META-INF/versions/10 or META-INF/versions/11 has \
> additional dependences or makes use of services that the code in the base section \
> doesn't but I suspect that isn't the case here. Whether the module-info.class is in \
> the top-level directory or META-INF/versions/9 shouldn't matter of course, except \
> when running into libraries or tools that can't handle MR JARs. 
> The Automatic-Module-Name attribute should be ignored if it present in an explicit \
> module. It may get you past some issue now but I assume will cause confusion in \
> another context. 
> -Alan
> 
> [1] https://bugs.openjdk.java.net/browse/JDK-8208269 \
> <https://bugs.openjdk.java.net/browse/JDK-8208269>

To follow up with the main part of my question, if some tooling thinks it is an \
automatic module when it is an explicit module what problems might that cause? For \
example, the Log4j API uses the ServiceLoader to locate the Log4j implementation. \
That is explicitly declared in module-info.java. We also declare what packages are \
exposed. I am assuming the tool might think all the packages are exposed as an \
automatic module but then have it fail at runtime because they aren't.  I can see \
that ModuleFinder says it first checks for a module-info.class and only if it doesn't \
find one looks for the manifest header. Is that the only code that cares about \
module-info or might something else handle it differently?

Ralph


[prev in list] [next in list] [prev in thread] [next in thread]