[slf4j-dev] [JIRA] (SLF4J-407) Jigsaw modules contain clashing package

QOS.CH (JIRA) noreply-jira at qos.ch
Fri Oct 20 18:27:00 CEST 2017


    [ https://jira.qos.ch/browse/SLF4J-407?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18954#comment-18954 ] 

Ralph Goers commented on SLF4J-407:
-----------------------------------

When looking at this for Log4j I came to the conclusion that when using ServiceLoader to locate an implementation it is not necessary to require a specific module name. The only issue that comes into play would be if SLF4J has packages that it wants to only be available to an implementation. In that case, you can require that the implementation use --add-exports to export the SLF4J package(s). Then the SLF4J binding would probably need to also export them to the chosen module at runtime.

In other words, I think the module-info.java file in 1.8 right now is fine.

> Jigsaw modules contain clashing package
> ---------------------------------------
>
>                 Key: SLF4J-407
>                 URL: https://jira.qos.ch/browse/SLF4J-407
>             Project: SLF4J
>          Issue Type: Bug
>          Components: Implementations
>    Affects Versions: 1.8.0-alpha2
>            Reporter: Stephen Colebourne
>            Assignee: Ceki Gülcü
>             Fix For: 1.8.0-beta1
>
>
> Looking at the slf4j-jdk14 and slf4j-nop artifacts, they both appear to contain the package `org.slf4j.impl`. Jigsaw will refuse to load two modules that contain the same package, so this will be a problem.
> I know that SLF4J does not intend users to load both of these modules at the same time. But the current setup means that it will be the JPMS runtime that rejects it, meaning that there is no chance for SLF4J to output a helpful message (as I believe it does today).
> The solution to this would appear to be to move the `org.slf4j.impl` package to `org.slf4j.jul.impl` and `org.slf4j.nop.impl`. As the impl package is not exported, this should not affect any user code (except code that would have been affected anyway).
> I imagine this affects other slf4j artifacts.
> I also note that [this module-info.java|https://github.com/qos-ch/slf4j/blob/1_8_0-SNAPSHOT/slf4j-jdk14/src/main/java/module-info.java] exports the `org.slf4j.jul` package, which seems unnecessary (simple and nop do not export their package).
> See [here|http://blog.joda.org/2017/04/java-se-9-jpms-module-naming.html] for more information on naming.



--
This message was sent by Atlassian JIRA
(v7.3.1#73012)


More information about the slf4j-dev mailing list