Java Modules and Multi-Release Jar
Alan Bateman
Alan.Bateman at oracle.com
Sun Sep 30 07:34:32 UTC 2018
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
More information about the jigsaw-dev
mailing list