Migrate off javax annotations and JSR305

[Lambeaux]

Description

During the Guava upgrade, a ton of javax.annotation conflicts arose that required exclusions to avoid classpath contention. While reasonably safe in a lot of circumstances, these kinds of failures are not being reported correctly by the Karaf feature service and make working with dependencies and dependency upgrades very difficult.

Guava is already considering an alternative, the checker framework, (google/guava#2960). It has come under scrutiny as well (google/guava#3031) but a lot of these concerns are mitigated by proper packaging of artifacts (https://github.com/typetools/checker-framework/blob/1f48ddb600620454731170eb2628e5f7efa93c3e/checker/build.xml#L517). Indeed, there is an annotations-only artifact available from maven central (https://search.maven.org/artifact/org.checkerframework/checker-qual/2.11.0/jar).

Some options for us that include @Nullable as part of the package:

• Checker Framework (https://github.com/typetools/checker-framework/tree/master/checker/src/main/java/org/checkerframework/checker/nullness/qual).
• Spotbugs (https://github.com/spotbugs/spotbugs/tree/master/spotbugs-annotations/src/main/java/edu/umd/cs/findbugs/annotations).

We could optionally enhance our static analysis with error-prone, although this would not serve as a drop-in replacement for what we need now (https://github.com/google/error-prone/tree/master/annotations/src/main/java/com/google/errorprone/annotations).

Expected behavior:

• Remove the need for excluding the javax.annotation import wherever possible, and allow third-party dependencies to have it at runtime.
• Deploy an annotation-only artifact into Karaf so our bundles can wire up to the new annotations at runtime; the goal being to remove the amount of variability of our manifests that we're deploying and more rigorously manage / track our absolutely necessary exclusions.

Version

N/A at this time.

Additional Information

Note that our provided scope listed in dependency management for the servicemix JSR305 dependency is not honored by the bundle plugin. Even directly specified in the leaf pom, it still goes ignored. At one point I could of sworn this was working, but I don't entirely recall.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs within 7 days. Thank you for your contributions.