accumulo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mike Miller <>
Subject [DISCUSS] Guava Dependencies
Date Mon, 18 Sep 2017 18:12:58 GMT
Recently tickets have been opened dealing with Guava in Accumulo (see
ACCUMULO-4701 through 4704), in particular the use of Beta classes and
methods.  Use of Guava comes with a few warnings...

>From the Guava README:

*1. APIs marked with the @Beta annotation at the class or method level are
subject to change. They can be modified in any way, or even removed, at any
time. If your code is a library itself (i.e. it is used on the CLASSPATH of
users outside your own control), you should not use beta APIs, unless you
repackage them (e.g. using ProGuard).2.Deprecated non-beta APIs will be
removed two years after the release in which they are first deprecated. You
must fix your references before this time. If you don't, any manner of
breakage could result (you are not guaranteed a compilation error).*

I think it is worth a discussion on how to handle Guava dependencies going
forward across the different versions of Accumulo.  The goal would be to
allow use of a newer version version of Guava in client applications with
the current supported versions of Accumulo.

Ideally, we could just eliminate any use of Beta Guava code.  But there are
Beta classes that are very useful and some which we already have integrated
into released Accumulo versions.

There seem to be 3 ways to handle Guava dependencies:
1 - jar shading
2 - copy Guava code into Accumulo
3 - replace Guava code with standard Java

We may have to handle it differently with each version of Accumulo.  For
example, 1.8 has more widespread use of Beta annotated code than 1.7.

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message