Guava Beta Checker 1.0 released

68 views
Skip to first unread message

Colin Decker

unread,
Dec 21, 2017, 12:56:43 PM12/21/17
to guava-discuss
Hi Guava users,

As we've mentioned a number of times before, we've been planning on releasing a plugin for Error Prone that allows projects depending on Guava to check, at compile time, that they aren't using any @Beta-annotated Guava APIs. It is especially important that other libraries (i.e. any code that gets used on a classpath outside of its creator's control) that depend on Guava not use @Beta APIs, since they are subject to change (as mentioned in the important warnings at the bottom of the Guava README).

I'm happy to announce that the plugin is now available in Maven Central as com.google.guava:guava-beta-checker:1.0. Instructions for using it with Maven, Gradle and Bazel are available in the README over at the GitHub project. The plugin check takes into account both elements (e.g. methods and classes) that are directly annotated with @Beta as well as elements that are defined within an @Beta-annotated type but not directly annotated themselves. With the plugin enabled, attempting to compile code using @Beta APIs will fail with a compiler error pointing out the offending APIs at the locations they are used.

If you maintain a library that depends on Guava, please try it out and let us know if you have any questions! Avoiding use @Beta APIs in your libraries will help your users by helping to prevent diamond dependency issues with other libraries that use Guava. Also note that we will be working to get more libraries out of @Beta soon; if there's a particular API you'd like to be able to use, please let us know to help us prioritize.

Thanks,
Colin Decker and the Guava team

Andrew Gaul

unread,
Feb 27, 2018, 1:33:17 AM2/27/18
to guava-discuss
The beta checker looks great!  Could you allow filing issues against this repository?  I want to file a feature request to allow user-specified suppressions for various interfaces.  Apache jclouds has made some poor choices by using @Beta code and it will take us some time to unwind this.  In the mean time I would like to limit new dependencies on @Beta code.  In terms of @Beta promotion, we would like to see HostAndPort, Invokable, and TypeToken which are hard to work around otherwise.  Hashing and HashCode would be nice to have as well.
Reply all
Reply to author
Forward
0 new messages