Announcing Guava 18.0-rc1

[Colin Decker]

Guava 18.0-rc1 is now available in Maven Central as com.google.guava:guava:18.0-rc1. See the release notes for information on what's in this release: https://code.google.com/p/guava-libraries/wiki/Release18

Note that as of 18.0, we will no longer be releasing JDK5 backports.

Please try upgrading and testing this release candidate and let us know how it goes.

Enjoy!

- Colin Decker

[Osvaldo Doederlein]

Some comments based on my limited testing (just recompiled existing code with 18.0rc1, not attempt at new APIs):

- Deprecation of Iterators.emptyIterator() results in more code than expected because the suggested replacement, ImmutableSet.of().iterator(), doesn't work well with Java's limited type inference. In practice I have to write ImmutableSet.<SomeType>of().iterator(). Still the deprecation seems sensible, it's a trivial utility and not terribly often used, maybe only improve the javadoc for replacement code so people won't copy-paste the suggested snippet then scratch their heads when it doesn't compile?

- Why not deprecating the entire Objects class already? Now with toStringHelper() moved to MoreObjects, every method here is deprecated or "should treat as deprecated", which is kinda painful but necessary since JDK 7 introduced its own Objects class. The current library already causes my project build to spit hundreds of warnings because I use ToStringHelper extensively, it can't get any uglier than that for non-migrated code / code that opts to run with v18 but keep build compatibility with 17.

--
--
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/CAPmOpX4N0Ecx0UyzAQQdD_heDHYoLxGryktR_LXP1SnTzXeU1g%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

--

Osvaldo Doederlein |

Software Engineer, Doubleclick Ad Exchange |

opi...@google.com

[Colin Decker]

On Sun Aug 10 2014 at 6:17:02 PM 'Osvaldo Doederlein' via guava-discuss <guava-...@googlegroups.com> wrote:

Some comments based on my limited testing (just recompiled existing code with 18.0rc1, not attempt at new APIs):

- Deprecation of Iterators.emptyIterator() results in more code than expected because the suggested replacement, ImmutableSet.of().iterator(), doesn't work well with Java's limited type inference. In practice I have to write ImmutableSet.<SomeType>of().iterator(). Still the deprecation seems sensible, it's a trivial utility and not terribly often used, maybe only improve the javadoc for replacement code so people won't copy-paste the suggested snippet then scratch their heads when it doesn't compile?

Good suggestion... updated the Javadoc.

 

- Why not deprecating the entire Objects class already? Now with toStringHelper() moved to MoreObjects, every method here is deprecated or "should treat as deprecated", which is kinda painful but necessary since JDK 7 introduced its own Objects class. The current library already causes my project build to spit hundreds of warnings because I use ToStringHelper extensively, it can't get any uglier than that for non-migrated code / code that opts to run with v18 but keep build compatibility with 17.

We can't deprecate Objects completely because Guava still supports JDK 6. If you're on JDK 7, there's basically no reason to use our Objects class, but on JDK 6 there are still useful methods there. And we don't want to just move those methods to MoreObjects, because MoreObjects is specifically intended to be the class that does *not* duplicate functionality that's already in java.util.Objects. It's a bit awkward, but it meets the needs of both JDK 6 and JDK 7 users... any other approach we took would have had other issues.

 

To view this discussion on the web visit https://groups.google.com/d/msgid/guava-discuss/CAFGi0fFc-NB-f-Z89tbu7%2B_v%2B2pp23a-uyhQ3xUTdPUwQve_LQ%40mail.gmail.com.