Migrate off of jsr305

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

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 Guava 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 and a legacy JDK module java.xml.ws.annotation. If one wants to create a modular JDK9 application with two dependencies to conflicting JAR-s, Java refuses to compile and run it because of a package split. Example:

• Guava -> forces us to require jsr305 automatic module,
• Dagger -> forces us to require either java.xml.ws.annotation or jsr250 automatic module.

All of the modules use javax.annotation.

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:

https://github.com/spotbugs/spotbugs/pull/180

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

[kevinb9n]

Everyone: I’m sorry the state of things re: nullness annotations is such a disaster. For better or worse, all I can tell you is that cpovirk and I (and many others) are working on the long term solution: a proper artifact that will be embraced by all major tools, with clear, strong specifications. Alas, this will take time to come to fruition and in the meantime things will continue to be a mess.

We don’t have public materials you can review yet at this time.

[cpovirk]

Nullability annotations update:

• We have our domains registered, and we’re serving a stub page from one of them.
• We don’t yet have real content for that page.
• We don’t yet have the GitHub project opened up for public access. (Last I heard, we had an informal approval from the person we needed but hadn’t gotten that officially written down.)