Guava and JDK 8 / Java 8

[Gerrit]

Browsing the latest JDK 8 Javadoc snapshots, I noticed that some of Guava's classes will have analogous classes in Java 8:

===============

com.google.common.base.Function -> java.util.function.Function

com.google.common.base.Supplier -> java.util.function.Supplier

void com.google.common.util.concurrent.ListenableFuture addListener(Runnable listener, Executor executor) method -> CompletableFuture<Void> java.util.concurrent.CompletableFuture.thenRunAsync(Runnable action, Executor executor) (.... instead of returning a void, this returns a CompletableFuture<Void> ).

com.google.common.util.concurrent.ListenableFuture.addListener(someRunnable, MoreExecutors.sameThreadExecutor() ) -> java.util.concurrent.CompletableFuture.thenRun( someRunnable )

com.google.common.util.concurrent.Futures.addCallback(..) -> doesn't exist

com.google.common.util.concurrent.SettableFuture.set(T) -> java.util.concurrent.CompletableFuture.complete(T)

boolean com.google.common.base.Predicate.apply(T) -> boolean java.util.function.Predicate.test(T)

com.google.common.base.Predicates.and/or/not -> java.util.function.Predicate.and/or/negate

com.google.common.base.Optional -> java.util.Optional

com.google.common.base.Joiner -> java.util.StringJoiner (roughly)

==========

As a future user of both Guava and Java 8, I'd like to know:

• should I prefer to use the Java 8 classes instead of the Guava classes?
  
• are there any other classes that I haven't listed above and that exist in both Guava and Java 8?
  
• what is the Guava teams' plan for these classes once Java 8 is released? Will the Guava classes be deprecated?

Thanks!

[Konrad Malawski]

Hi Gerrit,
Once you're on JDK8 - obviously default to their classes. Then, fallback to guava once you notice it's not enough :-)

Guava wasn't really designed with lambdas in mind, the streams and bulk operations api on the other hand was (well, as they come in together with lambdas in 8). For example: I'd go with eights' `stream()` instead of guavas `FluentIterable` etc.

The same applies currently, even before 8. Know the JDK and Guava well and select what better suits the task at hand :-)

I hope that helps to clarify a bit.

--
Cheers,
Konrad Malawski

--
--
guava-...@googlegroups.com
Project site: http://guava-libraries.googlecode.com
This group: http://groups.google.com/group/guava-discuss
 
This list is for general discussion.
To report an issue: http://code.google.com/p/guava-libraries/issues/entry
To get help: http://stackoverflow.com/questions/ask (use the tag "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/44b2c8e6-7b6c-468a-bd69-08342f6705ac%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[Louis Wasserman]

We don't have a plan yet, though we're planning to start thinking about one sometime this quarter.  It's clear that major parts of Guava will need to be redesigned to account for what is and isn't readable and efficient in Java 8.  It's not a simple matter of deprecating classes whose functionality is duplicated, but figuring out what design patterns work best with the new syntax -- and while we're at it, making sure all the Guava collections can be used efficiently with the new Streams API, and so on.  There's also the issue that Google won't be able to adopt Java 8 immediately, and Android and GWT users may also have compatibility issues.

All of that is pretty tricky, but we're definitely going to be thinking about it in the next few months.

--

--
guava-...@googlegroups.com
Project site: http://guava-libraries.googlecode.com
This group: http://groups.google.com/group/guava-discuss
 
This list is for general discussion.
To report an issue: http://code.google.com/p/guava-libraries/issues/entry
To get help: http://stackoverflow.com/questions/ask (use the tag "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/44b2c8e6-7b6c-468a-bd69-08342f6705ac%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

--
Louis Wasserman

[Tim Peierls]

The good news for users is that lambdas should work with both the Guava (for Java 7) and Java 8 flavors, so you should be able to mix the use of both in the same source file without importing either.

--tim

To view this discussion on the web visit https://groups.google.com/d/msgid/guava-discuss/CAGB9EW9CA34k1M%2BMOr5H%2BomanJGHZEmxokT%2BDGiNHqtUHcb2TA%40mail.gmail.com.

[pnie...@gmail.com]

Any news on this? Will Guava evolve to make the most out of Java 8?

Cheers,

Peter

[Louis Wasserman]

"Will Guava evolve to make the most out of Java 8?"

Well, yeah.  =P  We've been doing a fair amount of experimentation.  We've even found a couple bugs in JDK8 in the process that have since been fixed (https://bugs.openjdk.java.net/browse/JDK-8030814, http://osdir.com/ml/core-libs-dev/2013-11/msg00685.html) and some shortcomings in its APIs that we'll have to work around (http://stackoverflow.com/q/20075860/869736).

There are still lots of details to be hammered out, but of course Guava is going to evolve to take Java 8 into account.

To view this discussion on the web visit https://groups.google.com/d/msgid/guava-discuss/c5fbdd5a-1052-4242-a6c1-61b9c524d183%40googlegroups.com.

For more options, visit https://groups.google.com/groups/opt_out.

--
Louis Wasserman

[e271...@gmail.com]

One year and three months later, any updates on this thread?

[phra...@gmail.com]

Hi,

Is there any work-in-progress for harmonizing Guava with Java 8?

Thanks,

  Viktor

[Eric Edens]

Viktor, what'd you have in mind?

--
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/41dba731-538d-4bdc-9a6c-2fbd196c02a8%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[phra...@gmail.com]

Hi Eric,

I would expect a backwards-incompatible fork, with some of the following:

- removal of redundant classes (eg. Optional, Predicate, Function) – replacing with the java-supplied ones where applicable

- harmonization with new Stream APIs (eg. collectors for Guava collections)

- functional interfaces where applicable (eg. CacheLoader)

- rethink further overlapping functionality (eg. NIO)

- update internal implementation to Java 8 level

a more backwards-compatible transition path could be provided, e.g. guava Function could extend java.util.Function – but I don't think it's worth the bother, due to other impedance mismatches.

Regards,

  Viktor

[Nathan Bryant]

At the office, we have 1 or 2 third-party libraries in the tree that depend on (older versions of) Guava. I'll have enough trouble with those, as it is, if I ever want to update to a version of the JDK6-Guava that removes an API that those use...

It seems that everybody feels that Guava-8 should drop a lot of baggage, and that is fine, but pease package-rename for JDK8.

To view this discussion on the web visit https://groups.google.com/d/msgid/guava-discuss/7af23d91-56a5-47d7-9920-76a49007a4c6%40googlegroups.com.

[Viktor Szathmáry]

Agreed, it should be in a different package. What I was wondering about if there’s an existing effort in some branch somewhere, or should we just fork the project? :)

Thanks,

 Viktor

You received this message because you are subscribed to a topic in the Google Groups "guava-discuss" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/guava-discuss/fEdrMyNa8tA/unsubscribe.
To unsubscribe from this group and all its topics, send an email to guava-discus...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/guava-discuss/5599B48B.5090108%40optonline.net.

[Louis Wasserman]

Are you all looking for https://code.google.com/p/guava-libraries/source/checkout?repo=jdk8-experimental ?

To view this discussion on the web visit https://groups.google.com/d/msgid/guava-discuss/etPan.5599b6bd.4a1a81ab.151%40phrakmac.local.

[phra...@gmail.com]

Hi Louis,

Thanks, that's a good starting point – that branch seems like a weekend-spike, not a maintained fork. Based on this, is it safe to assume that Google doesn't maintain an internal Java8 fork of Guava? Since there has been no visible progress on this for a year, what's your take on a community fork to proceed with this (potentially merging some of the commits linked, but releasing in a different namespace, not com.google)?

Regards,

  Viktor

[Louis Wasserman]

The short answer is that that we don't think it'd solve anything like you think it would.  Let me see if I can unpack that, though.

What you're looking at is about the extent of our internal fork at the moment, though there has been some progress that hasn't been mirrored out.  

Internally, Google is in the process of preparing for Java 8 -- in fact, the team behind Guava is a large part of that process.  Much of that is invisible, little but necessary stuff like eliminating test dependencies on hash ordering, or making sure tools like Error Prone built into our whole build system are working fine.  Some of it you might have seen in commits to normal Guava, like here.

To be clear, I don't think there's any real chance we could make a backwards-incompatible Guava work, even in a new package.  That sort of migration is extremely difficult or impractical for large codebases -- specifically including Google's own rather large codebase, but many other large codebases depend on Guava externally.  What we're thinking of is more along the lines of a Guava built as a transition phase -- e.g. c.g.c.base.Function extending j.u.f.Function, and then release migration tools based on Error Prone and Refaster to rewrite Function implementations to lambdas, and to rewrite methods accepting c.g.c.b.Function to j.u.f.Function, and then a Guava release deprecating c.g.c.b.Function over the course of several releases.  That said, we are essentially certain there will be a Guava-for-Java-8 coming down the road.

Additionally, for reference, we're making many of the decisions for what Guava-for-Java-8 will look like right now.  Which collectors we'll provide for e.g. ImmutableMap, for example.  Those decisions aren't always obvious, and it seems likely a community fork would diverge from them.

So given all that, it seems like creating a community fork of Guava for Java 8 would just create the exact same problem a second time: two different libraries, very similar but with just enough impedance mismatch to make migration between them difficult. 

I get that this is depressing in the interim.  As far as the gaps you mentioned go, and how to deal with them for now -- I believe there might be some existing external libraries providing e.g. Collectors for Guava types, but frankly I'd recommend a minimal straightforward implementation of your own: e.g. Collectors.collectingAndThen(Collectors.toList(), ImmutableList::copyOf), which is easier for us to provide migration tools for.  For CacheLoader, which you mentioned, there is a static factory CacheLoader.from(Function).  If you have specific feature requests for how you'd like us to rethink NIO-related issues, please do file feature requests on GitHub.  We are paying attention to Java 8 related feature requests.

To view this discussion on the web visit https://groups.google.com/d/msgid/guava-discuss/948db52c-b0c5-4a23-8bef-aca9a54ac1b6%40googlegroups.com.

[phra...@gmail.com]

Hi Louis,

Thanks for the explanation! The incremental migration approach you describe sounds like will take a while... Even then, at some point you'll need to have a java8-only release (when g.Function extends java.util...). Do you have a feel for when that might happen?

Regards,

  Viktor

[Michał Minicki]

I personally think a migration version wouldn't provide much and would be just a general waste of time/resources. Why not just announce an end of life for the legacy 1.x version of Guava (which generally works for old Java version) and focus on releasing a new 2.x backwards incompatible version requiring Java 8? Maybe even in a separate Java package so the two versions could co-exists with each other to make the migration less painful. People who are on pre-Java 8 could still use the old lib; they would just not get any updates/features anymore. 

Furthermore, I think it's a good time to start thinking about how would you like to modularize/release Guava using Java 9 modularization feature. This might affect the overall choice and/or design as well.

Mike

[Joachim Durchholz]

Am 07.07.2015 um 02:12 schrieb Michał Minicki:
> Why not just announce an end of
> life for the legacy 1.x version of Guava (which generally works for old
> Java version) and focus on releasing a new 2.x backwards incompatible
> version requiring Java 8?

I guess I'm battering a wide-open door here, so just for the record:
IMHO, Guava 1.x should continue to "just work" for Java 8, and a certain
amount of work should be invested into that (not necessarily inside
Google). 1.x certainly wouldn't be the best way to do things under Java
8, it would merely allow people to transition from Java 7 to Java 8
without having to transition Guava at the same time, and make their life
much easier.

[David Beaumont]

The trouble is that while "just working" is great for old libraries, it's going to be a mess for new code.

If I write my library depending on your library which uses the "old" Guava, am I stuck with the old Guava too?

It's "sticky" and carries around essentially out of date classes and idioms (Predicates, Functions).

Guava shouldn't (in my mind) just be some libraries you can use, it should enshrine best practice.

It's a very tough problem, for sure, but we'll get there.

David

--
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/559B7755.80805%40durchholz.org.

For more options, visit https://groups.google.com/d/optout.

--

David Beaumont :: Îñţérñåţîöñåļîžåţîờñ Libraries :: Google
Google Switzerland GmbH., Brandschenkestrasse 110, CH-8002, Zürich - Switzerland
Tel +41 44 668 1800 :: Fax +41 44 668 1818

[Joachim Durchholz]

Am 07.07.2015 um 12:00 schrieb David Beaumont:> The trouble is that

while "just working" is great for old libraries, it's
> going to be a mess for new code.
>
> If I write my library depending on your library which uses the "old"
> Guava, am I stuck with the old Guava too?

That's why Michal was advocating making it so that Guava and
Guava-for-Java-8-onwards can coexist.
It would need facades for mutable types, and converters for immutable
ones. Which isn't going to be easy where the concepts behind the
interfaces are different - though in that case, you might want to give
it a different class name anyway.

[David Beaumont]

The issue I have with that is that it encourages runtime type conversion, when migrating code properly would not. There are lots of types to be converted and it's not obvious to me that a facade would always be an acceptable approach.

Obviously the issue here is how many of the libraries you are using are actively maintained and/or you have source code for. Google is lucky in that it has the ability to refactor just about all its source code for things like this. Other projects probably don't have that luxury.

It's a bigger issue at public API boundaries than for internal code (in theory you can fix internal code via bytecode rewriting).

I don't have great answers here, and the trouble is, I'm not sure there are any.

David

--
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/559BB286.70108%40durchholz.org.

For more options, visit https://groups.google.com/d/optout.

[Joachim Durchholz]

Am 07.07.2015 um 13:14 schrieb 'David Beaumont' via guava-discuss:
> The issue I have with that is that it encourages runtime type conversion,
> when migrating code properly would not.

Ah, but "properly" is context-dependent.
E.g. for safety-critical code, "don't change unless you need to" is
"proper".
For large code bases, it's "convert it in a piecemeal fashion" (that's
the use case I was thinking about initially).

> There are lots of types to be
> converted and it's not obvious to me that a facade would always be an
> acceptable approach.

I think a facade or converter is neede only if data was constructed
using guava-old and which needs to be inspected or modified using
guava-new. I guess in many cases handed-over data will be used only for
its standard stream or collection interfaces, which is enough of a facade.
Actually that would be a good test to see how universal Guava actually
is - is it good enough that people don't need to peek into its internals
when passing data from an old to a new, incompatible incarnation?

The most common case would be software that's in transition, some parts
already converted to guava-new, others still at guava-old.
For that scenario, incompatible classes need to have different qualified
names, otherwise there'll be collisions.

> Obviously the issue here is how many of the libraries you are using are
> actively maintained and/or you have source code for.

Even an actively maintained library is going to have the same kind of
transitioning problems.

For an unmaintained library, you're stuck anyway. Guava incompatibility
might require upgrading or dropping the library, but the root problem
would be that the library is unmaintained - any dependency could cause
the change.

Still if might be necessary to keep old and new Guava so that at least
they don't disrupt each other.

> Google is lucky in
> that it has the ability to refactor just about all its source code for
> things like this. Other projects probably don't have that luxury.

The biggest factor is usually lack of resources. You can't just rewrite
an external library - in fact the reason why you're using it is that you
didn't have the resources to write it yourself in the first place.
("Resource" might be "manpower" or "ability", I have seen both happen.)

If Google isn't using external libraries much, then this is indeed luxury.

> It's a bigger issue at public API boundaries than for internal code (in
> theory you can fix internal code via bytecode rewriting).

I suppose that's harder than just upgrading the code.
Rewritten bytecode carries a big price tag in terms of differences
between Java source and what actually happens, and lots of ensuing
surprises.
I wouldn't want to do that for any mission-critical parts of the
software, unless everybody involved has a very clear understanding of
what the bytecode rewrite does. This means everybody needs to quite
clear about what bytecode is (suprisingly unknown to junior developers),
and what a rewrite can and cannot do (often unknown even to seniors
unless they had reason to acquire that kind of specialist knowledge).

> I don't have great answers here, and the trouble is, I'm not sure there are
> any.

I'm thinking along the lines of priorities.
Top priority is to make 100% sure that old and new can coexist.
Facades and converters can come as people demand them. Or maybe that can
be done outside the community, with maybe a helping hand from Google as
resources allow and people are running into standard traps. Though if
Google isn't going to use that transition helper stuff internally, maybe
Google isn't even the best place to ask for help at; I'm not sure how
much commitment Google has to easing pains that cannot happen inside of
Google (any commitment in that area would certainly beyond the call of
duty IMHO).

Just my thoughts.
Jo

[Michał Minicki]

I think we're overdramatizing here a bit. 

I have recently went through something similar, changing Guava to Java 8 Optionals on a moderately big codebase. It's not that hard, you simply replace imports and then have a couple of method renames. I would expect Guava 2.x to be pretty much compatible with 1.x as the design is mostly good. I expect having differences similar to what we have between Joda-Time and new Java 8 Date and Time. 

When it comes to collections, you don't need converters at all. Almost all collections in Guava can be created by passing another collection in. Does it matter what the collection specific type is? No. You can simply pass a collection from Guava 1.x, Guava 2.x, standard java collections, or whatever else you want. Here's your converter. 

If you have a code base using other classes, like Splitters, Joiners, FluentIterables, you can still keep using them (or convert to Java 8). No biggie.

There probably will be some edge cases which will not be that simple to migrate but you don't have to switch to newer Guava version if you don't want to. Old one will work just as well as it does today.

Regards,

Mike

[Louis Wasserman]

I've somewhat lost track of what people are talking about, but:

> I personally think a migration version wouldn't provide much and would be just a general waste of time/resources. Why not just announce an end of life for the legacy 1.x version of Guava (which generally works for old Java version) and focus on releasing a new 2.x backwards incompatible version requiring Java 8?

Our impression so far is essentially just the opposite.  Most of Guava is still just as useful in Java 8 as it is in earlier versions of Java: collection types like Multiset and Multimap, the immutable collections, hashing, math, reflection.  In short, we feel like creating a new incompatible version of Guava adds lots of work -- especially for massive codebases like Google's -- for relatively little gain.  

I think the future we expect to see is a "master" version of Guava that requires Java 8, and has Collectors and c.g.c.base.Function extending j.u.f.Function, but is essentially a superset of today's Guava, possibly with some deprecations.  We might have one or more other flavors of Guava generated from that master version, e.g. a Java 6/7 compatible subset that looks basically like today's Guava.  (This might possibly be an Android-optimized flavor.)  No facades or converters necessary; all alternate Guava flavors providing a compatible subset of the APIs provided in the master version.  (Much like our GWT support now, in many ways.)

--

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/b3d04b29-7a08-4dfb-8775-16f8b9d2043f%40googlegroups.com.

[Joachim Durchholz]

Am 07.07.2015 um 21:32 schrieb 'Louis Wasserman' via guava-discuss:
> I've somewhat lost track of what people are talking about, but:

I guess we all got worried because it was hinted that a
Java-8-compatible Guava would not be able to be both great and
backwards-compatible.

> Our impression so far is essentially just the opposite. Most of Guava is
> still just as useful in Java 8 as it is in earlier versions of Java:
> collection types like Multiset and Multimap, the immutable collections,
> hashing, math, reflection. In short, we feel like creating a new
> incompatible version of Guava adds lots of work -- especially for massive
> codebases like Google's -- for relatively little gain.

Ah, that's laying some speculation and upcoming worries to rest.

I'm not sure who brought this up, but somebody did mention that future
Guavas would have to be incompatible because there are so many great
features in Java 8 that would be ineffective without that.

> I think the future we expect to see is a "master" version of Guava that
> requires Java 8, and has Collectors and c.g.c.base.Function extending
> j.u.f.Function, but is essentially a superset of today's Guava, possibly
> with some deprecations.

Now that's laying my concerns to rest :-)
(Okay, version upgrades to libraries usually do require some work on the
caller's side. I'm not expecting miracles.)

> We might have one or more other flavors of Guava
> generated from that master version, e.g. a Java 6/7 compatible subset that
> looks basically like today's Guava. (This might possibly be an
> Android-optimized flavor.) No facades or converters necessary; all
> alternate Guava flavors providing a compatible subset of the APIs provided
> in the master version. (Much like our GWT support now, in many ways.)

Sounds sweet.
Looking forward :-)

Regards,
Jo

[Louis Wasserman]

I'm not sure who brought this up, but somebody did mention that future
Guavas would have to be incompatible because there are so many great
features in Java 8 that would be ineffective without that.

I'm not certain what you have in mind here, but I think there are two kinds of "incompatibility" that people are using in this discussion and distinguishing them is important:

• A Guava that won't work without Java 8.  This is clearly necessary for the "master flavor" of Guava, and I think we're all on the same page here: without this, we can't provide Collectors, etcetera.  That said, we expect to continue to provide a Guava flavor that doesn't depend on Java 8.
  
• A Guava that is incompatible with previous versions of Guava.  We don't think we'll have to go this far, and plan to minimize any incompatibilities as much as possible.  I'm not aware of any "great feature in Java 8 that would be ineffective" that would require this.

[Michał Minicki]

Louis, of course, I'm not going to dispute that. You certainly know better what will work for you and what won't.

What I'm saying is that the moment you add Collectors (or any other Java 8 only feature to Guava), it will require Java 8 runtime. Sure, you can go through hoops (like Spring does) to make it backwards compatible, but is it worth it? That's my only concern.

Having a separate "2.x" kind of release would allow you to drop unnecessary classes (like a Function), implement internals based on new Java 8 features, and drop Guava backwards compatibility. Not having full backwards compatibility is a huge gain, in my opinion, as you would be able to correct interfaces and other small architectural issues, like adding Optional return values to pre-optional classes and start returning Java 8 Optionals at the same time. You wanted people migrate to FluentIterable in favor of Lists, Sets, etc? Here's your chance to drop those utility classes. 

If you leave an option for both versions to co-exist then it should be pretty much painless to migrate gradually (that's directly in contrast to what you have just said about migration pains). And as you said, old projects can just stay on pre Java 8 Guava as it is still just as useful as it was before. 

Then again, having to support multiple flavors of Guava feels like a lot of work to me ;)

And BTW: Thanks for all your efforts. I love Guava and I can't imagine programming without it any more!

Mike 

[Benjamin Manes]

I think the Guava team has the right approach. The majority of issues is bridging, which community extensions like Guavate help deal with. When the changes are more invasive to optimize for a platform then the community should offer an alternative, like Square's Otto. It would be nice to see a gradual transition start to take place, but it can't abandon users on Android or who similarly cannot upgrade soon.

The only area where I feel limited by Guava's compatibility requirement is that guava-testlib has not been updated to include Java 8 coverage. This component has less adoption so a direct upgrade would have a smaller impact by not affecting most users. If Guava took Spring's approach then there may not be any user perceived pain whatsoever.

Otherwise I think the community should push forward with Java 8 and, when Guava is ready to join us, Google can absorb the best that we've produced.

-Ben

To view this discussion on the web visit https://groups.google.com/d/msgid/guava-discuss/c98250cb-f977-472e-b946-51f51ba13a80%40googlegroups.com.

[Thomas Broyer]

Beware of cross compilation, Animal Sniffer gives you a false feeling of confidence: see http://developer-blog.cloudbees.com/2014/12/beware-siren-target-call.html and http://www.draconianoverlord.com/2014/04/01/jdk-compatibility.html as examples.

[Louis Wasserman]

If you leave an option for both versions to co-exist then it should be pretty much painless to migrate gradually (that's directly in contrast to what you have just said about migration pains). And as you said, old projects can just stay on pre Java 8 Guava as it is still just as useful as it was before.

I think the issue here is that we have very different experiences of what constitutes migration pains.

In our experience, the intermediate state between two incompatible versions of closely related libraries is migration pain.  The pain is felt by developers on projects wondering "which Guava versions are my users expecting?  Which Guava versions are my dependencies using?"  This results in a large amount of frustration spread across a huge number of people.  Every time you need an adapter or wrapper -- every time you have to even wonder if you need an adapter or wrapper or the like -- that's migration pain.

In contrast, the benefit of the backward-compatible approach means that we can flip the Java 8 switch, making everything use Java 8, and swap in Guava-for-Java-8, and at that point developers can just start casually using Java 8 -- and mixing it freely with Guava -- anywhere in their code, maybe just on whatever code they happened to be writing that day.  They don't need to worry about what any other code in the codebase is doing, they can just casually use Java 8 and mix it with Guava right there.  There's no need to rewrite components of the codebase, it just works. 

The benefits you describe, such as they are, aren't worth the pain here. We can still deprecate APIs that should not be used in Java 8, and if there are any APIs we consider unwanted in all Java versions, we can still delete those after a normal deprecation cycle.

We are confident that backwards compatibility with previous Guava versions is the best way forward for us and for our users.  I'm hesitant to estimate a timeframe for an official release, largely because we're somewhat constrained by the rest of Google.  You should see more work on the prototype I linked to, though at some point we'll probably move that to Github.  (In particular, Ben, I definitely think the experimental fork can include fairly thorough tests for the new Java 8 methods.  I don't know if that'll help without an official release, though.)

[jgm...@gmail.com]

https://github.com/airlift/airlift/blob/master/concurrent/src/main/java/io/airlift/concurrent/MoreFutures.java is a useful utility class for adapting between CompletableFuture and ListenableFuture and addressing shortcomings in CompletableFuture. Similar features in a Java 8-minimum Guava would be useful.

[Michał Minicki]

Thanks for the reply, Louis.

I totally understand the problem and I think we will just have to agree to disagree. Or partly disagree as I think the approach you guys want to take is different but as good as any.

Just to wrap it up. I personally prefer not to have backwards compatibility, like with Jackson 1.x vs Jackson 2.x for instance, than to keep it like Java where even after 10 years you still can't have runtime generics because you constrained yourself unnecessarily. There are of course examples which are on the worse side, like Apache Tapestry major version upgrades or maybe even Python 2 vs 3; but this is a pain I can accept as I understand why I'm suffering. However, being forced to have two incompatible Optional classes (Guava vs Java 8) makes me want to hurt myself (partly because I have to use fully qualified names whenever I have both). And as hopeful as I am, I can't see a future where you decide to start returning Java 8 Optionals on FluentIterable any time soon, so (for the time being) I will have to make adapters you wanted to spare me from creating ;)

Having said that, I can't wait for the Guava-for-Java-8 and it's collectors! Hope it happens sooner rather than later.

Best regards,

Mike