Guava 23.5 released

[Colin Decker]

Guava 23.5 was released November 22, 2017. The Maven version numbers are 23.5-jre and 23.5-android.

See the release notes for more information.

[martin...@gmail.com]

Hi, congratulations on the new release ;-)

I see that a new dependency (checkerframework) was added, is this one necessary (or will be) in runtime ? 

If not, I would like to exclude them in my maven project, but I don't see documentation on what can be safely excluded or not.

Martin

[Stephen Colebourne]

Agreed, it would be good to know what is and is not optional from the dependencies. Specifically, checkerframework, but information on the others too. Guava is supposed to be a low level library, and adding lots of dependencies goes against the spirit of that.

Stephen

[Thomas Broyer]

From the release notes linked from the OP: “Added a dependency on, but did not begin using, the Checker Framework.”

FWIW, all dependencies are small and only annotations that (I believe) are not used at runtime.

• Animal Sniffer annotations (which is actually only a single annotation) has class retention; this is clearly a compile-time-only annotation; could be marked <optional>true</optional>
• JSR 305 annotations are good for development but not really needed at runtime (unless something else makes use of them; e.g. Dagger or Guice vs. @Nullable, or Error Prone vs. many of those annotations)
• Error Prone annotations are only useful is the downstream project uses Error Prone; but Error Prone will actually fail if the dependency is missing (might also be the case of JSR 305 annotations BTW).
• I'm not familiar with the Checker Framework (but I think one idea is to migrate from the "non standard" JSR 305 annotations to the Checker Framework ones, for better Java 9 support, as JSR 305 creates a split package; see https://github.com/google/guava/issues/2960 for instance, and notice the move from JSR 305 @Immutable to Error Prone's version https://github.com/google/guava/commit/901e985598a30fadb194603d6a17142cca00614b; though note that current org.checkerframework:checker-qual also contains javax.annotation among other "third party" packages)

Given they're small and only annotations, they're mostly harmless. But given they're mostly used at compile-time (though notice that some of them are required to compile downstream projects when using Error Prone as the compiler), they could be marked as <optional>true</optional> (and then people using Error Prone would have to declare them explicitly).

I, for one, prefer having the dependencies "always on" rather than marked as optional. YMMV.

[Colin Decker]

+Chris Povirk 

I believe the dependency should be optional, but isn't declared as such due to it causing other issues (see #2721 and #2824 among others). I agree the current situation doesn't seem ideal.

--
guava-...@googlegroups.com
Project site: https://github.com/google/guava
This group: http://groups.google.com/group/guava-discuss
 
This list is for general discussion.
To report an issue: https://github.com/google/guava/issues/new
To get help: http://stackoverflow.com/questions/ask?tags=guava
---
You received this message because you are subscribed to the Google Groups "guava-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to guava-discus...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/guava-discuss/1e3b98f1-daf0-4c83-8cb5-9a5c1e70ec10%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Chris Povirk]

Thanks for all the comments here.

Yes, as Colin says, everything should be safe to omit at runtime, but "optional" doesn't mean what we want here (and ditto for "provided"). I just posted on an existing Maven feature request for a scope that means "compile-time, including compile-time for users of the library, but not runtime." The existing posts that requested the feature made a bad case for it, so we can hope that, with a good case for it, Maven might add it, even though the bug is currently closed.

The dependencies will continue to be safe to omit at runtime even when we actually start putting Checker Framework annotations on our code. I believe that the Checker Framework has some "actual classes," not just annotations, so we'll have to make sure we never use them. Ideally we'll write a test for that.

We should document that the annotations dependencies are safe to exclude. I'll take care of that.

 

note that current org.checkerframework:checker-qual also contains javax.annotation among other "third party" packages)

Hmm, what you do mean by this? I don't see any javax.annotation classes in the checker-qual jar (2.0.0 or 2.2.2), nor do I see a transitive reference from either pom, whether I examine it manually or look at the output of `mvn dependency:tree`.

[Stephen Colebourne]

My view is that the current approach is prioritising the few above the many. The "many" are those consuming Guava as a simple library who don't want the dependencies and have no need to see/use the annotations - they are just annoying cruft (that we have to exclude, others will just accept). The "few" are those willing to take extra steps already when compiling against Guava, for whom the annotations are required. Prioritising the needs of the "many" would mean declaring the dependencies as optional in Maven, and providing documentation as to what extra dependencies are needed if problems occur.

Stephen

[Chris Povirk]

My thinking has been that the failure mode is better this way:

Your jar is big, you go looking for the commit that made it bigger, you see that it's the Guava upgrade, and you look up whether it's safe to exclude the dependencies.

In comparison:

Your compile fails with an error about a class that your source code doesn't refer to, starting with an innocuous-looking commit. Eventually you figure out that you need to add a particular dependency to your compile. Later, you repeat again with a new dependency and a new compile.

It's bad either way; we're just trying to be bad in obvious ways.

Maybe Maven will add the feature we need someday. Someone could also try asking the Checker Framework for a nullness-only artifact.

[Thomas Broyer]

Wrt checker-qual, I was looking at the javadoc at https://checkerframework.org/api/ and http://javadoc.io/doc/org.checkerframework/checker-qual/2.2.0

[Chris Povirk]

On Mon, Nov 27, 2017 at 5:33 PM, Thomas Broyer <t.br...@gmail.com> wrote:

Wrt checker-qual, I was looking at the javadoc at https://checkerframework.org/api/ and http://javadoc.io/doc/org.checkerframework/checker-qual/2.2.0

Huh. As best as I can tell, that's a quirk of however they do their Javadoc generation -- probably building a single Javadoc site for checker + checker-qual + checker-compat-qual and then serving it for all 3.

[Chris Povirk]

Huh. As best as I can tell, that's a quirk of however they do their Javadoc generation -- probably building a single Javadoc site for checker + checker-qual + checker-compat-qual and then serving it for all 3.

(And checker itself, which we don't depend on, does contain the javax.annotation classes.)

[Joachim Durchholz]

Am 27.11.2017 um 22:24 schrieb Stephen Colebourne:
> The "many" are those consuming Guava as a simple library who don't
> want the dependencies and have no need to see/use the annotations - they
> are just annoying cruft (that we have to exclude, others will just
> accept).

I think I'm one of the "many" in that frankly, I don't care too much
about indirect dependencies - Maven keeps track of them for me, and I
get annoyed only if there's a version conflict.
Then there's the case of an indirect dependency that comes with a CVE or
a memory leak or similar nasties, but that's merely a matter of
submitting a bug report and getting the thing fixed before delivering
any software that uses it - so it's not a big deal above and beyond what
we "many" already have to do.

Of course there's the point were indirect dependencies start to
proliferate, but I think you worry too much - very few Java libraries
worry too much about the dependencies they use, and the Java library
ecosystem still works.
I guess the main point is that library makers dislike relying on
external dependencies because it's outside of their control, yet they
need them to make their own code work. I.e. the list of external
dependencies is kept to a minimum.

[Chris Povirk]

We should document that the annotations dependencies are safe to exclude. I'll take care of that.

Noted in https://github.com/google/guava/wiki/UseGuavaInYourBuild#what-about-guavas-own-dependencies, and linked from the main Guava page.