announcing Guava 12.0-rc1

[Charles Fry]

[bcc:guava-announce]

Chris just uploaded Guava 12.0-rc1 to Maven. You can install it using maven as com.google.guava:guava:12.0-rc1 and com.google.guava:guava-gwt:12.0-rc1, or you can download it by hand from:

 http://search.maven.org/#search%7Cga%7C1%7Cg%3A%22com.google.guava%22

Please try upgrading and let us know how it goes. If no upgrade problems are reported then we'll do the final 12.0 release in the next few weeks.

Release notes can be found at:

 http://code.google.com/p/guava-libraries/wiki/Release12

JDK6: Note that release 12.0 is our first release to require JDK6. Users requiring JDK5 compatibility may continue to use Guava 11.0.2. We will not be maintaining a JDK 1.5 backport, but if anyone wants to do so, we will link to it.

OSGi: We are working to get OSGi support into the final release 12.0.

We strongly encourage you to install and test this release candidate; please report any issues you encounter doing so. And enjoy the new functionality. :-)

Charles

[Tim Peierls]

Is it just me, or is FluentIterable the coolest thing since ... um ... MapMaker? It makes it that much more tempting to overlook the caveats in http://code.google.com/p/guava-libraries/wiki/FunctionalExplained -- I know I'm being bad, but I've been writing fewer for-loops and loving it.

--tim

Charles

--
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")

[Louis Wasserman]

Personally, I'm inclined to give TypeToken that title, but FluentIterable is also pretty cool.

Speaking of the wiki, the new articles I'd prepared for release 12 are starting to go up as of today.

Louis Wasserman
wasserm...@gmail.com
http://profiles.google.com/wasserman.louis

[Adrian Cole]

+1 FluentIterable is ubercool. in jclouds, we have multi-step
transforms, collection-changing requirements. It was harder to follow
all these before. I'm gonna start using FluentIterable once this
release progresses.

Right now, we are on 12.0-rc1 and a-ok.

Thanks!
-A

[Michał Minicki]

Hi. Where can I find some information on what has changed with "Added Cache.putAll"? I don't see any reference to this method on CachesExplained page:

http://code.google.com/p/guava-libraries/wiki/CachesExplained 

Regards,

Michał

[Louis Wasserman]

Heh.  You should probably check the Javadoc first. http://docs.guava-libraries.googlecode.com/git-history/release12/javadoc/com/google/common/cache/Cache.html#putAll(java.util.Map)

Louis Wasserman
wasserm...@gmail.com
http://profiles.google.com/wasserman.louis

2012/4/3 Michał Minicki <mar...@aie.pl>

--

[Kevin Bourrillion]

Yeah, that really is all there is to it.  It's like multiple puts.  We added it to make it feasible for even your remote caches to implement Cache if they so desire.

--
Kevin Bourrillion @ Google

Java Core Libraries Team
http://guava-libraries.googlecode.com

[Michał Minicki]

Oh, thanks. I was kind of hoping for something different.

I really like the idea of the self contained cache loading that Guava provides. It feels so "right" not to put anything into cache from outside. But there's this one issue I'm having. 

There are cases where I would like to pre-populate the cache on application start and would very much like to do it in in bulk, loading everything in one go (with a single API call); and only then start loading missing values using CacheLoader, as those are being added at runtime in remote system. And if I'm right (and there's a big possibility that I'm wrong), the only way to put starting values into the cache right now is to put them from outside, from the cache's client. While breaking this clean loading logic into different places :(

But that's probably not a best place for such discussion. The announcement thread, that is.

Regards,

Michał

--
Pozdrawiam,
Michał Minicki

[Louis Wasserman]

I think that's deliberate, just because "pre-loading" logic will frequently be different than the cache's normal logic.

[Kevin Bourrillion]

I'm pretty sure this is the second time this particular question has come up ... can someone find the first?

[Jesper de Jong]

Why does FluentIterable have a deprecated method? FluentIterable is new in version 12.0, so it's strange that it has a deprecated method in its first release.

Is the deprecated method going to be removed before the final release of version 12?

regards

Jesper

Op vrijdag 30 maart 2012 19:28:50 UTC+2 schreef Charles Fry het volgende:

[Colin Decker]

The Javadoc for the deprecated method indicates why it's there. Say you have some method that returns an Iterable, and your code wraps it in a FluentIterable using FluentIterable.from(Iterable). If you later change that method to return FluentIterable instead, your call to FluentIterable.from becomes redundant. Since FluentIterable.from(FluentIterable) is marked as deprecated, there will be something to indicate places where you're making an unnecessary call. So basically, it's there to help you catch places where you're doing something you shouldn't. (Ordering.from does the same thing.)

-- 

Colin

--

[Kevin Bourrillion]

Surprising, isn't it?  It's deprecated on purpose.  It might seem weird, but we've found that it really does serve a purpose.  Some users decide to change APIs that used to return Iterable so that they return FluentIterable instead, and often several of the callers were chaining that into a FluentIterable themselves.  This is a harmless way to let them know they can simplify their code.

As a general rule, deprecation is not always a sign of brokenness, or a promise to remove something. It simply means "there's a better way to do what you're trying to do."

[Jesper de Jong]

Interesting idea, Kevin.

Jesper

Op woensdag 4 april 2012 16:20:23 UTC+2 schreef Kevin Bourrillion het volgende:

Surprising, isn't it?  It's deprecated on purpose.  It might seem weird, but we've found that it really does serve a purpose.  Some users decide to change APIs that used to return Iterable so that they return FluentIterable instead, and often several of the callers were chaining that into a FluentIterable themselves.  This is a harmless way to let them know they can simplify their code.

As a general rule, deprecation is not always a sign of brokenness, or a promise to remove something. It simply means "there's a better way to do what you're trying to do."

[Dimitris Andreou]

Also have a look here:

http://docs.guava-libraries.googlecode.com/git/javadoc/com/google/common/collect/Ordering.html#from(com.google.common.collect.Ordering)

[Charles Fry]

http://code.google.com/p/guava-libraries/issues/detail?id=775

http://stackoverflow.com/questions/7915016/pre-load-values-for-a-guava-cache

[yanivi]

On Friday, March 30, 2012 1:28:50 PM UTC-4, Charles Fry wrote:

[bcc:guava-announce]

Chris just uploaded Guava 12.0-rc1 to Maven. You can install it using maven as com.google.guava:guava:12.0-rc1 and com.google.guava:guava-gwt:12.0-rc1, or you can download it by hand from:

 http://search.maven.org/#search%7Cga%7C1%7Cg%3A%22com.google.guava%22

Please try upgrading and let us know how it goes. If no upgrade problems are reported then we'll do the final 12.0 release in the next few weeks.

Release notes can be found at:

 http://code.google.com/p/guava-libraries/wiki/Release12

JDK6: Note that release 12.0 is our first release to require JDK6. Users requiring JDK5 compatibility may continue to use Guava 11.0.2. We will not be maintaining a JDK 1.5 backport, but if anyone wants to do so, we will link to it.

Our projects (http://code.google.com/p/google-api-java-client/, http://code.google.com/p/google-oauth-java-client/, and http://code.google.com/p/google-http-java-client/) do need a JDK 1.5 backport.  We have this requirement because we want to support Android FroYo (and probably also Eclair).  How do you envision the JDK 1.5 backport will work?  Who will own the JDK 1.5 backport in an official capacity?  At the very minimum, do you agree to at least perform critical bug fixes to release 11 if they are reported by users?

-- Yaniv

[Kevin Bourrillion]

On Tue, Apr 10, 2012 at 6:22 AM, yanivi <yan...@google.com> wrote:

Our projects (http://code.google.com/p/google-api-java-client/, http://code.google.com/p/google-oauth-java-client/, and http://code.google.com/p/google-http-java-client/) do need a JDK 1.5 backport.  We have this requirement because we want to support Android FroYo (and probably also Eclair).  How do you envision the JDK 1.5 backport will work?  Who will own the JDK 1.5 backport in an official capacity?

I don't really know the answers to these questions.  To be honest, I was expecting an outcry about this decision when we announced it Jan 5, but when it never came we thought we had perhaps dodged a bullet.

My guess is that someone (clones or branches or whatever the right git terminology is) the whole guava tree, and hacks the sixisms back out of it again, and creates a new artifactId called "guava5" or even "guava-five", whose releases would track official guava releases with identical numbering but potentially trailing days to weeks behind.

 

At the very minimum, do you agree to at least perform critical bug fixes to release 11 if they are reported by users?

If that truly alleviated the need to have a backport, I would certainly consider it... but I'm doubtful it would.

The irony might not have escaped readers' notice that this request is now coming on behalf of three Google projects for reasons of compatibility with another Google project :-), so it probably makes sense for us to go off and sort out whether we (Google) really do want to own this backport after all. :-)  Will update here later.

--

Kevin Bourrillion @ Google

http://goto/javalibraries

[Chris Povirk]

[bcc:guava-announce]

I have uploading 12.0-rc2 with some fixes and some documentation
improvements. You can see a full list of changes at
http://code.google.com/p/guava-libraries/source/list?name=release12
(look for anything during April), but the major changes are:

- CacheBuilder users who use the Cache stats() method must now opt in
by calling recordStats(). (Users who do not use stats may see
performance improvements.)

- The release now has OSGi metadata.

http://repo1.maven.org/maven2/com/google/guava/guava/12.0-rc2/
http://code.google.com/p/guava-libraries/wiki/Release12

[Adrian Cole]

Thank you!

This is in jclouds 1.5.0-alpha.4 and we are immensely thankful for the
TypeToken type. Consider this a vote in favor of releasing guava 12!

-A