[slf4j-dev] [JIRA] (SLF4J-418) Add JSR 305 to SLF4j

[QOS.CH (JIRA)]

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

Sebastian Davids commented on SLF4J-418:
----------------------------------------

Guava is not using jsr305 anymore:

https://github.com/google/guava/issues/2960

> Add JSR 305 to SLF4j
> --------------------
>
>                 Key: SLF4J-418
>                 URL: https://jira.qos.ch/browse/SLF4J-418
>             Project: SLF4J
>          Issue Type: Bug
>          Components: Core API
>    Affects Versions: 2.0, 1.8.0-alpha2
>            Reporter: Erik Pragt
>            Assignee: SLF4J developers list
>              Labels: kotlin
>
> A few years ago, attempts have been made to implement JSR 305 in SLF4j. This was rolled back due to a Scala compiler issue, which, 5 years later, still hasn't been fixed. In the meantime, other libraries, like Guava, most of Square's libraries ([https://medium.com/square-corner-blog/rolling-out-nullable-42dd823fbd89)], the Spring framework, etc, have implemented JSR 305. JSR 305 is now supported by tools like Findbugs, and languages like Kotlin, and IDEs like Eclipse and IntelliJ make use of this meta information to detect bugs. 
> I hope that by now, we can also add JSR 305 information into SLF4j. If the Scala issue is still an issue, it seems that this issue should either be fixed by Lightbend, or they will run into issues with other frameworks anyway. Anyhow, IMO, it seems the Scala compiler should not be a reason to withhold this change from happening. 
> The main motivation is that it will make programming in Kotlin easier (right now, types from SLF4j are platform types, and the compiler has no information if this is a nullable or non-nullable type, making SLF4j harder to use), but, as a side effect, it will help IDEs and other tooling.
>  
>  



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