Conflicting javax.annotation version

[kameshsampath]

In relation to the question posted here https://stackoverflow.com/questions/44878002/jsr305-osgi-exports-brave, its observed that brave bundler adds the following export version of the package
javax.annotation;version='[3.0.0,4)' which causes conflict with most of the OSGi containers - currently using brave with JBoss Fuse 6.3 which has karaf container 2.4.x. After some analaysis i found that the dependency:

  <dependency>
      <groupId>com.google.code.findbugs</groupId>
      <artifactId>jsr305</artifactId>
      <version>3.0.2</version>
      <!-- eventhough annotations are runtime retention, we do not look them up reflectively -->
      <scope>provided</scope>
    </dependency>

was adding the Export-Package header with javax.annotation;version='[3.0.0,4)'.

I tried to change the dependency to a servicemix bundle,

 <dependency>
          <groupId>org.apache.servicemix.bundles</groupId>
          <artifactId>org.apache.servicemix.bundles.jsr305</artifactId>
          <version>3.0.2_1 </version>

          <!-- eventhough annotations are runtime retention, we do not look them up reflectively -->
          <scope>provided</scope>
</dependency>

Then I saw the header to be Export-Package header with javax.annotation;version="[1.1,2)", which is available in most of the containers and brave bundle gets wired properly.

Is it possible to update the JSR305 to servicemix dependency bundle ?

What kind of issue is this?

• Bug report. If you’ve found a bug, spend the time to write a failing test. Bugs with tests
  get fixed and stay fixed. If you have a solution in mind, skip raising an issue and open a
  pull request instead.

[codefromthecrypt]

Suppose so. Mind pinging someone who has been involved with OSGi related work here (hint search issues or git history and you should find someone)

[kameshsampath]

@adriancole the standard versions that are exported is javax.annotation;version="[1.1,2)" thats the case until JDK 9. So it it OK if I can send a PR with service mix bundle for JSR 305 which adds the right export?

[codefromthecrypt]

I'm not the best to decide.. please actively notify the person who setup OSGi. Probably @cschneider and/or @iocanel should be on-board with this, and if they are, I am :)

[cschneider]

I saw the question on stack overflow too. Will help to solve it.

[kameshsampath]

thanks @adriancole - no worries

[kameshsampath]

thanks @cschneider #452, thats the smallest of change i did and I see the deployment in to Karaf (Jboss Fuse 6.3) happening smoothly.

Any thoughts ?

[cschneider]

@kameshsampath I was not yet able to reproduce the problem. I installed brave core 4.4.1-SNAPSHOT.
It does not seem to have any imports of javax.annotation.

[kameshsampath]

did you try 4.4.0 @cschneider ?

[kameshsampath]

@cschneider - when I install 4.4.0 i got this error when deploying my feature
Error executing command: Could not start bundle mvn:io.zipkin.brave/brave/4.4.0 in feature(s) brave-core-1.0.0: Unresolved constraint in bundle io.zipkin.brave [506]: Unable to resolve 506.0: missing requirement [506.0] osgi.wiring.package; (&(osgi.wiring.package=javax.annotation)(version>=3.0.0)(!(version>=4.0.0))).

bnd print -m ~/Downloads/brave-4.4.0.jar

[MANIFEST brave-4.4.0]
Bnd-LastModified                         1497939029571
Build-Jdk                                1.8.0_111
Built-By                                 ubuntu
Bundle-Description                       Brave
Bundle-DocURL                            http://zipkin.io/
Bundle-License                           http://www.apache.org/licenses/LICENSE-2.0.txt
Bundle-ManifestVersion                   2
Bundle-Name                              brave
Bundle-SymbolicName                      io.zipkin.brave
Bundle-Vendor                            OpenZipkin
Bundle-Version                           4.4.0
Created-By                               Apache Maven Bundle Plugin
Export-Package                           brave;version="4.4.0";uses:="brave.propagation,brave.sampler,javax.annotation,zipkin,zipkin.reporter",brave.propagation;version="4.4.0";uses:="javax.annotation",brave.sampler;version="4.4.0";uses:="brave.propagation,javax.annotation",brave.internal;braveinternal=true;mandatory:=braveinternal;version="4.4.0";uses:="brave,brave.propagation,javax.annotation,zipkin,zipkin.reporter"
Import-Package                           brave.internal;version="[4.4,5)";braveinternal=true,brave.propagation;version="[4.4,5)",brave.sampler;version="[4.4,5)",javax.annotation;version="[3.0,4)",zipkin;version="[1.24,2)",zipkin.internal;version="[1.24,2)",zipkin.reporter;version="[0.10,1)"
Manifest-Version                         1.0
Originally-Created-By                    Apache Maven Bundle Plugin
Require-Capability                       osgi.ee;filter:="(&(osgi.ee=JavaSE)(version=1.8))"
Tool                                     Bnd-3.3.0.201609221906

[cschneider]

I just also tried brave-core 4.4.0. It installed fine on karaf 4.1.1. I do no see any import of javax.annotation.
Can you describe how to reproduce the problem?
You can also join https://gitter.im/openzipkin/zipkin then we can chat directly.

[kameshsampath]

@cschneider - you need to be on 2.4.0, which is part of JBoss Fuse 6.3 (https://developers.redhat.com/products/fuse/download/) and here the package exports

JBossFuse:karaf@root> packages:exports | grep javax.annotation
     0 javax.annotation; version=1.0.0
     0 javax.annotation.processing; version=1.0.0
    60 javax.annotation; version=1.2.0
    60 javax.annotation.security; version=1.2.0
    60 javax.annotation.sql; version=1.2.0

[cschneider]

Ok .. now I got it .. I never installed the module brave .. only brave-core.

[kameshsampath]

but wondering why "annotations" need to be part of the exports as they are more compile time right ? but as I tried and part of my PR moving to servicemix bundle the problem went away

[robinst]

jsr305 also causes problems on Java 9 if a project is also using jax-ws:

the unnamed module reads package javax.annotation from both java.xml.ws.annotation and jsr305

The problem is that both modules have a package called javax.annotation, which Java 9 doesn't like. I would suggest replacing them with something else that doesn't use that package. There's some discussion of other choices here: https://stackoverflow.com/questions/4963300/which-notnull-java-annotation-should-i-use

[codefromthecrypt]

@raphw can we borrow an opinion on this one. We currently use the following for Nullable/ParametersAreNonnullByDefault There's definitely different, possibly valid, alternatives

    <!--
     For javax.annotation.ParametersAreNonnullByDefault and javax.annotation.Nullable
     This is added as a root-level dependency to prevent javadoc from failing.
     servicemix is used as it is OSGi friendly
     -->
    <dependency>
      <groupId>org.apache.servicemix.bundles</groupId>
      <artifactId>org.apache.servicemix.bundles.jsr305</artifactId>
      <version>3.0.2_1</version>
      <!-- eventhough annotations are runtime retention, we do not look them up reflectively -->
      <scope>provided</scope>
    </dependency>

[raphw]

I would suggest you to switch to compile-time only annotations and to not export the bundle. With these annotations being included in so many different packaging formats, they are more trouble than they are worth it.

[codefromthecrypt]

I would suggest you to switch to compile-time only annotations and to not export the bundle. With these annotations being included in so many different packaging formats, they are more trouble than they are worth it.

Funny, we used to do that, but some concerns about kotlin and intellij led to a reverse to use standard ones...

[raphw]

What concerns did you have? I do not think that this information is normally useful at runtime. Unless you have a good use case, I recommend to get rid of it.

[codefromthecrypt]

What concerns did you have? I do not think that this information is normally useful at runtime. Unless you have a good use case, I recommend to get rid of it.

This was mainly for IDE code inspection, not particularly for runtime inspection. Reasons enumerated by @swankjesse https://medium.com/square-corner-blog/non-null-is-the-default-58ffc0bb9111 If we got rid of it, choices are to revert completely (ex remove all annotations and replace with comments), make an internal nullable again (source retention) and/or open an IDEA bug on how to achieve code inspection without adding a runtime dep.

[codefromthecrypt]

one reasonable option is to remove the nullable thing and punt to docs both for zipkin and brave. Reason is that these aren't common-use libraries such as an http library is. optimizing to not taint classpath could outweigh benefits of null analysis for those developing tracing libraries...

[codefromthecrypt]

Meh cant simply yank.. need to keep or replace as autovalue reads these to construct null enforcing things

[codefromthecrypt]

starting to fix this here openzipkin/zipkin#1768

[codefromthecrypt]

openzipkin/zipkin-reporter-java#73 for reporter 2.x

[codefromthecrypt]

here's the one here (needs a dependency update) #517