splitio / java-client

Java SDK client for Split Software
https://split.io
Other
25 stars 18 forks source link

Unexpected package "javax.annotation" bundled in jar. #510

Open AlexanderGunnarssonMW opened 4 weeks ago

AlexanderGunnarssonMW commented 4 weeks ago

We are having classpath collisions due to classes such as javax.annotation.Nullable being bundled into the java-client.jar. Manually downloading and inspecting jars from mvn repository, I see that this started appearing between 4.4.0 and 4.4.1 and still exist in the latest release.

$ unzip -l java-client-4.4.0.jar | grep javax
<no output>

$ unzip -l java-client-4.4.1.jar | grep javax
        0  2017-03-31 10:55   javax/
        0  2017-03-31 10:55   javax/annotation/
      518  2017-03-31 10:55   javax/annotation/CheckForNull.class
      526  2017-03-31 10:55   javax/annotation/CheckForSigned.class
      607  2017-03-31 10:55   javax/annotation/CheckReturnValue.class
        0  2017-03-31 10:55   javax/annotation/concurrent/
...

I don't understand how the changes between these versions would cause this, but I believe the right solution is that they should not be bundled. We get the same classes from com.google.code.findbugs:jsr305, a dependency of guava.

chillaq commented 3 weeks ago

Hi @AlexanderGunnarssonMW , The only version change in your diff is Snakeyaml package to version 1.26, however, when I download snakeyaml-1.26.jar, I don't see javax in its classes.

What version of Guava are you using? Our latest SDK uses Guava 32.0.1-jre, which compiles fine without issues on our end.

Thakns Bilal

AlexanderGunnarssonMW commented 3 weeks ago

We are using a different guava version, but 32.0.1-jre also depends on jsr305 which includes these javax classes so it should be the same. Our application compiles and starts, but we are developing on a framework that detects "jar hell" and refuses to start when the same class is provided by two separate jars. I believe it would have worked if the framework did not reject this.

Our solution for now is to exclude the transient jsr305 dependency, and use the classes from java-client.jar which works as they appear to be identical. But I still think it's incorrect for them to be bundled in the jar, it does not bundle any other dependency. I don't suspect the snakeyaml version changed caused it, the only remaining candidate would be the changes under maven-shade-plugin.

chillaq commented 3 weeks ago

Hi @AlexanderGunnarssonMW , it is probably the maven-shade-plugin, as it creates a large jar file given no overlap within the artifacts included.

I will check internally to see if we can remove those additional apache and google artifacts.

Thanks Bilal