> On Sep 30, 2018, at 12:34 AM, Alan Bateman <alan.bate...@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
