Why would I add a JSR305 artifact to use Guava 14+?

Question

When searching for information about stackoverflow, I saw a question similar to mine, but with no real answer here .

I need to migrate my maven project from guava 11.0.2 to guava 14 or higher (I need RangeSet ). I updated my maven pom with the dependency:

<dependency> <groupId>com.google.guava</groupId> <artifactId>guava</artifactId> <version>14.0</version> </dependency> 

Then I started the maven build and got this error:

 [ERROR] xxx.java: cannot find symbol [ERROR] symbol : class Nonnull [ERROR] location: package javax.annotation 

I took a closer look and these annotations come with JSR305 , which guava 11.0.2 depends on, since the mvn repository reports this.

I find it strange that guava 14 also depends on JSR305 as mvn repository reports.

If I add a JSR dependency to my pom, then compiling just works just fine:

 <dependency> <groupId>com.google.code.findbugs</groupId> <artifactId>jsr305</artifactId> <version>1.3.9</version> <scope>provided</scope> </dependency> 

But why should I add this dependency to my pom if guava already depends on it? This seems more like a workaround than a solution, and I would rather understand and make things clean.

Thanks for participating.

Answer 1

The reason you need to add it as a dependency is because Guava 14 defines the dependency in its pom as follows:

 <dependency> <groupId>com.google.code.findbugs</groupId> <artifactId>jsr305</artifactId> <version>1.3.9</version> <scope>provided</scope> </dependency> 

An important part of your problem is the <scope>provided</scope> .

On the maven website, they report the following regarding provided dependencies:

assuming : This is very similar to compile , but indicates that you expect the JDK or container to provide a dependency at runtime. For example, when creating a web application for Java Enterprise Edition, you must depend on the servlet API and its associated Java EE APIs in the provided scope, since the web container provides these classes. This scope is accessible only on the way to compilation and testing and is not transitive.

So, mainly because Guava installed this as a provided dependency, they expect someone to consume Guava to provide this dependency, which is exactly what you needed to do.

In Guava 11.0.2, this was a normal compile dependency, so you did not need to provide it in your own project.

This change was made in Guava 13. From the release notes :

Made findbugs a dependency provided to prevent conflict conflicts when using findbugs 2.0. A side effect of this change is that projects that relied on Guava to provide access to JSR-305 annotations “for free” will be violated if they do not provide their direct dependence on this bank (or its equivalent). Projects should always be directly dependent on JSR-305 (based on best practice), but this change makes this mandatory.