JDK9: Don't use JSR-305 dependency

[zyxist]

There are several issues with using jsr305.jar by RSocket.

JSR-305 is dormant, has been for a long while and shows no hope of ever producing an agreed set of annotations in our lifetime. Further more these annotations use javax. packages which it is not possible to use according to the Oracle Java binary licence, so applications can not use and ship these dependencies along with a JRE without violating the Oracle licence agreement.

F. JAVA TECHNOLOGY RESTRICTIONS. You may not create, modify, or change the behavior of, or authorize your licensees to create, modify, or change the behavior of, classes, interfaces, or subpackages that are in any way identified as "java", "javax", "sun", “oracle” or similar convention as specified by Oracle in any naming convention designation.

The JSR-305 group has not defined any official releases according to its jsr page so the only implementations is a seemingly random implementation provided by the FindBugs team. Even if the team where experts on the JSR (which some where) they are not official as there has been no vote and are not available from the JSR hompage - so the javax package name restriction still applies.

Using jsr305 causes additional issues, if RSocket is used in a modular JDK9 applications, because it puts the annotations into javax.annotation package, which is also used by a couple of other JAR-s (including the officially released JSR-250) and a legacy JDK module java.xml.ws.annotation. If one wants to create a modular JDK9 application that depends on both JSR-305 and JSR-250, Java 9 refuses to compile it.

Findbugs has been rebooted as Spotbugs and they are going to make a switch from JSR-305 to their own internal annotations in version 4.0.0 that do not break anything:

spotbugs/spotbugs#180

I think RSocket should consider switching to them in order not to pollute application dependencies with jsr305 JAR.

[yschimke]

I think rsocket-java is small enough that we can follow the lead of Kotlin and more widely adopted libraries like those from square

https://github.com/Kotlin/KEEP/blob/41091f1cc7045142181d8c89645059f4a15cc91a/proposals/jsr-305-custom-nullability-qualifiers.md
https://kotlinlang.org/docs/reference/java-interop.html
https://medium.com/square-corner-blog/rolling-out-nullable-42dd823fbd89

It seems it is viable to choose an alternative, but I would rather follow the lead of other projects rather than forge a new path.

[zyxist]

@yschimke -> the links you provided are not an alternative, because they seem to be all based on jsr305.jar, which causes technical (and legal) issues. I know that it is widely used, but it doesn't mean that it's right.

If you use modules with Java 9, two modules can't use the same package - things don't compile if you try to do it. There is an officially released JSR-250 that has the rights to use javax.annotation package. jsr305.jar is not official, and technically speaking, if you are using it, you are violating Java license.

[yschimke]

Yep, I'm not actually disagreeing with you, I haven't researched the issue and you obviously have. All I'm suggesting is before rsocket-java moves, you should probably get our upstream dependencies to remove it.

e.g. https://github.com/reactor/reactor-core/blob/master/build.gradle

After reactor-core removes it we can drop it also. Please reopen this issue once you work through this with projects like reactor-core.