You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@jclouds.apache.org by Inbar Stolberg <in...@gmail.com> on 2014/09/03 18:40:38 UTC
Guava versions
Hey all
I know I've been bombarding the forum lately so sorry and thank you for all
the quick replies.
Regarding guava.
Jclouds is using guava 1.7 and is keeping up to date with the guava
versions the problem is not every one does and guava versions are not
backward compatible.
I am using casandara which the latest official release supports guava 1.5
So to make Cassandra and jclouds work in the same module I needed to
downgrade jclouds to 1.6 (meddling in the code) and upgrade Cassandra to a
nun official release version.
I believe this gap will increase over time. And basically it means jclouds
won't provide backward compatibility due to third party jars.
Can any of the devs respond to this issue?
Thanks in advance
Regards inbar
Re: Guava versions
Posted by Andrew Phillips <an...@apache.org>.
> Can any of the devs respond to this issue?
jclouds uses Guava pretty heavily, including some of the newer
features that were added in more recent releases (Andrew G can
probably provide much more technical detail here). In some instances,
such as fixing JCLOUDS-427 [1], we actually *depend* on newer Guava
versions.
In short, from what I know, sticking to older Guava versions is not
really an option for new jclouds major versions going forward.
Which leaves two questions for me: support for older Guava versions by
supporting older jclouds major releases, and looking for the
conflicting projects/products to work with newer Guava versions.
For the former: we have historically tried to support the current
major version and the former major version (which means 1.8.x and
1.7.x for now). Support for the prior major version tends to be
limited to critical fixes rather than ongoing backporting of
everything that's making it onto master.
So you should still be able to use an older version of Guava by
sticking to an older jclouds major version, but you are unlikely to be
able to make use of significant new jclouds features. From what I can
see, we simply don't have the bandwidth in the active developer
community to handle all the backports and minor releases for older
versions.
Which leaves the final point: is there some way to "encourage" the
projects you are using that are stuck on older versions to upgrade? It
does seem to me that they're slightly more responsible for causing
this problem than jclouds is. I know that is easy to say and doesn't
help resolve the issue, but if we can help by adding our voice to
"Upgrade Guava version please" discussions I'm happy to pitch in.
In the case of Cassandra, by the way, I'm glad to see this discussion
is already happening:
https://issues.apache.org/jira/browse/CASSANDRA-6639
Regards
ap
[1] https://issues.apache.org/jira/browse/JCLOUDS-427
Re: Guava versions
Posted by Inbar Stolberg <in...@gmail.com>.
Thanks for the quicks response Andrews ;)
I will most defiantly use the 1.8 commit to downgrade the guava version.
I do understand the need to be up to date. Regarding Cassandra it seems
they are moving at a much slower paste using guava than you guys.
>From what you both said though I would like to suggest that while moving
ahead with guava versions (or any third party package) it will be greate to
check their backward compatibility and if there is none than maybe create
backward compatibility patch such as Andrew Gaul did for a few versions
(giving time for the other sources to move ahead and catch up...) Andrews
commit and my issue for example..
Thank you
Very much guys
On Wednesday, September 3, 2014, Andrew Gaul <ga...@apache.org> wrote:
> On Wed, Sep 03, 2014 at 07:40:38PM +0300, Inbar Stolberg wrote:
> > Regarding guava.
> > Jclouds is using guava 1.7 and is keeping up to date with the guava
> > versions the problem is not every one does and guava versions are not
> > backward compatible.
> > I am using casandara which the latest official release supports guava 1.5
> > So to make Cassandra and jclouds work in the same module I needed to
> > downgrade jclouds to 1.6 (meddling in the code) and upgrade Cassandra to
> a
> > nun official release version.
> > I believe this gap will increase over time. And basically it means
> jclouds
> > won't provide backward compatibility due to third party jars.
> > Can any of the devs respond to this issue?
>
> Historically jclouds uptakes new versions of Guava when Google releases
> them since they provide some desired functionality. Recently we have
> emphasized *forward* compatibility with Guava versions, removing uses of
> deprecated methods before future Guava releases remove them. We should
> also avoid use of @Beta annotated interfaces although we currently lack
> a way to enforce this. *Backward* compatibility could be an interesting
> goal; for example I made small changes to 1.8.x to allow compatibility
> with Guava 16[1]. If someone in the community wants to build on this
> commit we can include it in then next 1.8.x release. However, I would
> like to continue to eagerly upgrade Guava versions on master.
>
> [1]
> https://github.com/andrewgaul/jclouds/commit/bfcccd1d56df2a2c8b9bfcdc4720cfff4235d7f0
>
> --
> Andrew Gaul
> http://gaul.org/
>
Re: Guava versions
Posted by Andrew Gaul <ga...@apache.org>.
On Thu, Sep 04, 2014 at 08:49:26PM +0300, Inbar Stolberg wrote:
> Is it agreed that those should be avoided/removed in future releases?
> Also if there is a patched version for 1.8 with guava 15 or 17 without
> @Beta interfaces pls let me know.
Google's generous and well-communicated compatibility guarantees do not
apply to @Beta APIs; use of these undermines jclouds goal of
forward-compatibility with Guava. That being said, jclouds benefits
from a lot of these interfaces instead of reimplementing equivalent
functionality.
I do not plan to work on Guava backward compatibility; please send pull
requests if you want to include this functionality. Note that we would
need to provide this across all the jclouds repositories, including
labs. Also note that Guava 15 TypeToken is incompatible with Java 7 so
going further back than Guava 16 is likely impossible:
https://issues.apache.org/jira/browse/JCLOUDS-427
--
Andrew Gaul
http://gaul.org/
Re: Guava versions
Posted by Inbar Stolberg <in...@gmail.com>.
Is it agreed that those should be avoided/removed in future releases?
Also if there is a patched version for 1.8 with guava 15 or 17 without
@Beta interfaces pls let me know.
Inbar
On Thursday, September 4, 2014, Andrew Gaul <ga...@apache.org> wrote:
> On Wed, Sep 03, 2014 at 01:21:02PM -0700, Andrew Gaul wrote:
> > On Wed, Sep 03, 2014 at 12:54:56PM -0700, Andrew Gaul wrote:
> > > We should also avoid use of @Beta annotated interfaces although we
> > > currently lack a way to enforce this.
> >
> > I experimented with Overstock's library-detectors[1] and jclouds has
> > thousands of uses of Guava @Beta interfaces, most significantly
> > TypeToken in core and Futures in async providers. I opened an issue[2]
> > to allow us to disable warnings for some of these.
> >
> > [1] http://overstock.github.io/library-detectors/
> > [2] https://github.com/overstock/library-detectors/issues/1
>
> I hacked library-detector up enough[3] to determine that jclouds uses many
> Guava @Beta interfaces in core alone:
>
> com.google.common.base.CharMatcher
> com.google.common.base.Suppliers.supplierFunction
> com.google.common.base.Throwables.getCausalChain
> com.google.common.base.Ticker
> com.google.common.cache.Cache
> com.google.common.cache.LoadingCache
> com.google.common.collect.Lists.charactersOf
> com.google.common.eventbus.AsyncEventBus
> com.google.common.eventbus.DeadEvent
> com.google.common.eventbus.EventBus
> com.google.common.hash.HashCode
> com.google.common.hash.HashingInputStream
> com.google.common.io.BaseEncoding
> com.google.common.io.ByteSource.read
> com.google.common.io.ByteStreams
> com.google.common.io.CharStreams
> com.google.common.io.Closeables
> com.google.common.io.Closer
> com.google.common.io.CountingOutputStream
> com.google.common.io.FileBackedOutputStream
> com.google.common.io.Files
> com.google.common.net.HostAndPort
> com.google.common.net.InetAddresses
> com.google.common.net.InternetDomainName
> com.google.common.net.MediaType
> com.google.common.reflect.AbstractInvocationHandler
> com.google.common.reflect.Invokable
> com.google.common.reflect.Parameter
> com.google.common.reflect.TypeParameter
> com.google.common.reflect.TypeToken
> com.google.common.util.concurrent.Futures
> com.google.common.util.concurrent.ListenableScheduledFuture
> com.google.common.util.concurrent.ListeningScheduledExecutorService
> com.google.common.util.concurrent.SimpleTimeLimiter
> com.google.common.util.concurrent.TimeLimiter
>
> [3] https://github.com/overstock/library-detectors/pull/2
>
> --
> Andrew Gaul
> http://gaul.org/
>
Re: Guava versions
Posted by Andrew Gaul <ga...@apache.org>.
On Wed, Sep 03, 2014 at 01:21:02PM -0700, Andrew Gaul wrote:
> On Wed, Sep 03, 2014 at 12:54:56PM -0700, Andrew Gaul wrote:
> > We should also avoid use of @Beta annotated interfaces although we
> > currently lack a way to enforce this.
>
> I experimented with Overstock's library-detectors[1] and jclouds has
> thousands of uses of Guava @Beta interfaces, most significantly
> TypeToken in core and Futures in async providers. I opened an issue[2]
> to allow us to disable warnings for some of these.
>
> [1] http://overstock.github.io/library-detectors/
> [2] https://github.com/overstock/library-detectors/issues/1
I hacked library-detector up enough[3] to determine that jclouds uses many
Guava @Beta interfaces in core alone:
com.google.common.base.CharMatcher
com.google.common.base.Suppliers.supplierFunction
com.google.common.base.Throwables.getCausalChain
com.google.common.base.Ticker
com.google.common.cache.Cache
com.google.common.cache.LoadingCache
com.google.common.collect.Lists.charactersOf
com.google.common.eventbus.AsyncEventBus
com.google.common.eventbus.DeadEvent
com.google.common.eventbus.EventBus
com.google.common.hash.HashCode
com.google.common.hash.HashingInputStream
com.google.common.io.BaseEncoding
com.google.common.io.ByteSource.read
com.google.common.io.ByteStreams
com.google.common.io.CharStreams
com.google.common.io.Closeables
com.google.common.io.Closer
com.google.common.io.CountingOutputStream
com.google.common.io.FileBackedOutputStream
com.google.common.io.Files
com.google.common.net.HostAndPort
com.google.common.net.InetAddresses
com.google.common.net.InternetDomainName
com.google.common.net.MediaType
com.google.common.reflect.AbstractInvocationHandler
com.google.common.reflect.Invokable
com.google.common.reflect.Parameter
com.google.common.reflect.TypeParameter
com.google.common.reflect.TypeToken
com.google.common.util.concurrent.Futures
com.google.common.util.concurrent.ListenableScheduledFuture
com.google.common.util.concurrent.ListeningScheduledExecutorService
com.google.common.util.concurrent.SimpleTimeLimiter
com.google.common.util.concurrent.TimeLimiter
[3] https://github.com/overstock/library-detectors/pull/2
--
Andrew Gaul
http://gaul.org/
Re: Guava versions
Posted by Andrew Gaul <ga...@apache.org>.
On Wed, Sep 03, 2014 at 12:54:56PM -0700, Andrew Gaul wrote:
> We should also avoid use of @Beta annotated interfaces although we
> currently lack a way to enforce this.
I experimented with Overstock's library-detectors[1] and jclouds has
thousands of uses of Guava @Beta interfaces, most significantly
TypeToken in core and Futures in async providers. I opened an issue[2]
to allow us to disable warnings for some of these.
[1] http://overstock.github.io/library-detectors/
[2] https://github.com/overstock/library-detectors/issues/1
--
Andrew Gaul
http://gaul.org/
Re: Guava versions
Posted by Andrew Gaul <ga...@apache.org>.
On Wed, Sep 03, 2014 at 07:40:38PM +0300, Inbar Stolberg wrote:
> Regarding guava.
> Jclouds is using guava 1.7 and is keeping up to date with the guava
> versions the problem is not every one does and guava versions are not
> backward compatible.
> I am using casandara which the latest official release supports guava 1.5
> So to make Cassandra and jclouds work in the same module I needed to
> downgrade jclouds to 1.6 (meddling in the code) and upgrade Cassandra to a
> nun official release version.
> I believe this gap will increase over time. And basically it means jclouds
> won't provide backward compatibility due to third party jars.
> Can any of the devs respond to this issue?
Historically jclouds uptakes new versions of Guava when Google releases
them since they provide some desired functionality. Recently we have
emphasized *forward* compatibility with Guava versions, removing uses of
deprecated methods before future Guava releases remove them. We should
also avoid use of @Beta annotated interfaces although we currently lack
a way to enforce this. *Backward* compatibility could be an interesting
goal; for example I made small changes to 1.8.x to allow compatibility
with Guava 16[1]. If someone in the community wants to build on this
commit we can include it in then next 1.8.x release. However, I would
like to continue to eagerly upgrade Guava versions on master.
[1] https://github.com/andrewgaul/jclouds/commit/bfcccd1d56df2a2c8b9bfcdc4720cfff4235d7f0
--
Andrew Gaul
http://gaul.org/