Add runtime dependency for JSR305 and export annotations

[matthiasblaesing]

The annotations defined in the Common Annotations module depend
on the annotations defined in JSR305. If they are not present, a
warning is generated from javac.

[svenreimers]

Should we create a separate library wrapper jar to for jsr305 and make the commons annotations depend on it? Maybe more modular as a result. If we choose the existing approach a user always needs to depend on the NetBeans abstraction and cannot chose the original library as a dependency. Any thoughts?

[JaroslavTulach]

The problem with JSR-305 is that it is dormant. It will never become a Java standard and its use of javax. packages may thus be unjustified.

When solving this with Petr Hejl we decided not to expose the JSR-305 annotation during runtime and use those annotations only internally, during compile time.

[JaroslavTulach]

Spotbugs (the successor of FindBugs) no longer recommends those annotations. As such it may not be the right time to add such dormant project to the NetBeans Platform.

[matthiasblaesing]

I'm not sure what to make with this. It is a fact, that the JSR305 classes (or at least the symbols) already leaked out of the module. Javac might have been more forgiving in the past, but it is not anymore.

I see two options:

• rip the Common Annotations dependency out of the modules and then remove the module altogether and get rid of the annotations
• update Common Annotations to not carry the JSR305 annotations

One questions remains: Do we gain anything or would it make more sense to keep the library and at least satisfy javac?

[jlahoda]

Spotbugs (the successor of FindBugs) no longer recommends those annotations. As such it may not be the right time to add such dormant project to the NetBeans Platform.

If only all was so simple. I did some experiments, and seems SpotBugs still requires the nullness annotations to be meta-annotated using the JSR305 annotations. (Otherwise it simply ignores the annotations.) So, if we remove the meta-annotations, SpotBugs won't work on NetBeans classfiles (not a big deal for me, btw, but I suspect someone would like that to work).

At the same time, I think it makes sense to have @nonnull, etc. annotations, and I agree with Jaroslav that adding jsr305 into the API of the platform does not sound very appealing.

Not sure what is the best way out of this - will try to think about that. In the worst case, we can drop (either manually or at build time) the javax.annotation meta-annotation from our annotations, and accept SpotBugs won't work on NetBeans classfiles.

[gilbertoca]

@matthiasblaesing @geertjanw There is a started work in the https://github.com/eclipse-ee4j/common-annotations-api project to absorb JSR-305 into common-annotations-api project. Maybe a collaborative effort would help?