sbaudoin/yamllint

Don't use JSR-305 dependency

Closed this issue · 1 comments

From rsocket/rsocket-java#423

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.

Spotbugs appears to be a suitable alternative.

Will just get rid of JSR305 and Findbugs. Thanks for pointing out. The API will lack understandability, though.