Guavate - Guava and Java 8

[Stephen Colebourne]

For my day job I put together a Guavate class to straddle the boundary between Java 8 and Guava:
 https://github.com/OpenGamma/OG-Commons/blob/master/collect/src/main/java/com/opengamma/collect/Guavate.java
Its not a jar file and not on maven central, but feel free to use it under the Apache 2 license conditions.

I'm sure that the Guava team will do a good job when a Java 8 version is finally produced, but in the meantime I hope this helps someone.

Stephen

[Louis Wasserman]

Hi Stephen,

We have an internal fork of Guava that is intended to fill this role -- aid Guava users wanting to transition to Java 8 APIs -- that we're working on getting out into the wild very soon.  That's going to be an experimental, unsupported fork not necessarily kept in sync with upstream Guava.  Right now I'm just wrestling with the scripts to keep external and internal codebases in sync and to strip out stuff we're not ready to expose, but that's the only real blocker right now.

Notable features include

• c.g.c.base.Function extends j.u.f.Function and so on,
• our APIs accept j.u.f.Function and return c.g.c.base.Function,
• our Collection implementations have efficient stream() implementations,
• our immutable collection types have Collectors,
• our unsigned arithmetic utilities forward to the new ones in Java 8

and a scattering of other things.

Hopefully when that is out, it might help fill your needs, or at least give you an idea of what Guava will look like in the future.

--
--
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?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/2599e123-8b71-4381-85f6-ed2fd8faf2a9%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
Louis Wasserman

[Louis Wasserman]

And there we go: it's on Google Code at https://code.google.com/p/guava-libraries/source/browse/?repo=jdk8-experimental.

Right now it's a subset of Guava -- just base, collect, math, and primitives -- and not up to date, not maintained, and generally shouldn't be depended on in production; it's just intended to provide some idea of what the transitional stage of Guava will look like.  But within those constraints, please do feel free to play around with it and provide feedback.

On Tue, Jul 8, 2014 at 10:27 AM, Louis Wasserman <lowa...@google.com> wrote:

Hi Stephen,

We have an internal fork of Guava that is intended to fill this role -- aid Guava users wanting to transition to Java 8 APIs -- that we're working on getting out into the wild very soon.  That's going to be an experimental, unsupported fork not necessarily kept in sync with upstream Guava.  Right now I'm just wrestling with the scripts to keep external and internal codebases in sync and to strip out stuff we're not ready to expose, but that's the only real blocker right now.

Notable features include

• c.g.c.base.Function extends j.u.f.Function and so on,
• our APIs accept j.u.f.Function and return c.g.c.base.Function,
• our Collection implementations have efficient stream() implementations,
• our immutable collection types have Collectors,
• our unsigned arithmetic utilities forward to the new ones in Java 8

and a scattering of other things.

Hopefully when that is out, it might help fill your needs, or at least give you an idea of what Guava will look like in the future.

--
Louis Wasserman

[Stephen Colebourne]

Thanks for putting this live. Obviously for now, we'll keep on using
our own tool until any Guava release.

In terms of your collectors, I note that you collect to a standard JDK
collection and then copyOf to an immutable one. By contrast, I collect
to the immutable builder and then build that. Did you try the
performance of both before choosing your option (I've just assumed the
builder is faster).

I also wondered if you have considered making the builder implement
Collector. I'm not sure that is the right option, but it would be
relatively natural:

stream.collect(ImmutableList.builder());

I also note the painful deprecated methods like toImmutableMap() on
ImmutableBiMap. Perhaps a separate utility like Collectors in the JDK
(or Guavate in my case) might be a better home than putting the
methods on each class.


One final thought. The JDK StringJoiner isn't that good, but it does
beat Guava's Joiner in having a prefix and suffix built in. Any chance
of adding those to Guava?

Stephen

[Nabeel Memon]

Any ETA on release? It's really much awaited.

[Kevin Bourrillion]

Note that at present, Guava is on JDK 6 and we have until recently been maintaining a JDK 5 backport.  An actual release that requires JDK 8 may be quite a few steps away at this point. And that event may usher in the most chaotic and user-infuriating period in Guava's history due to all the version conflicts out there in the wild.

--

--
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?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/9257e3e8-bb84-44fb-9507-5b84c52a2b47%40googlegroups.com.

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

--

Kevin Bourrillion | Java Librarian | Google, Inc. | kev...@google.com

[aman...@gmail.com]

Hi,

Do you have a place where you centralize the features you want to include in the Guava fork for Java 8 ?
I would like to propose/discuss some features:
- remove the Guava Optional type (which is confusing with the JDK one),
- make a version of CacheBuilder that use functional interfaces instead of the CacheLoader abstract class.

I am eager to see a release of this fork :)

Aurélien

[Nathan Bryant]

Ok, looks like it's it's backwards incompatible. That's fine, and probably a feature rather than a bug. But there are enough third-party libraries out there using Guava that, for some projects, migrating their own stuff from Guava6 to Guava8 might not happen right away. Is it possible to make Guava8 package-renamed?

To view this discussion on the web visit https://groups.google.com/d/msgid/guava-discuss/5c25a6f9-a677-4701-8fe0-a691755b179f%40googlegroups.com.

[Kevin Bourrillion]

On Tue, Sep 9, 2014 at 1:45 AM, <aman...@gmail.com> wrote:

- remove the Guava Optional type (which is confusing with the JDK one),

This is not going to happen for a very long time.  When it does, any library wishing to be compatible with both JDK 7 and JDK 8 will be completely out of luck for an Optional type.  We are beginning to scope out what a migration tool should do, though, to help those who can convert.

- make a version of CacheBuilder that use functional interfaces instead of the CacheLoader abstract class.

You can usually use CacheLoader.from(k -> computeValue(k)) (or CacheLoader.from(KeyType::computeValue)).

 

To view this discussion on the web visit https://groups.google.com/d/msgid/guava-discuss/5c25a6f9-a677-4701-8fe0-a691755b179f%40googlegroups.com.

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