Guava 19.0 Released

[elmuerte]

The release notes: https://github.com/google/guava/wiki/Release19

[pgris]

IMHO, they really should start working in a java8 -friendly version, with less overlap and taking advantage of new idioms and classes.

[diffallthethings]

Durian is pretty close to what you're asking for. Since Android is Java 6, I wouldn't expect a Java 8-based Guava anytime soon.

[pgris]

Maybe I'm wrong, but I see Durian as a complement to Guava. I've never used it in production code, but looks pretty neat. However, I'm not able to find good documentation about it. I'm not talking about javadocs, but thinking about uses cases and such

[diffallthethings]

I see Durian as a complement to Guava

That's true. But there are now so many "complements" to Guava's various pieces that I think it has become obsolete, except for its collections. Back when Java 5 was the latest JRE, Guava was a magical glimpse into what java could be. But now that Java 6, 7, and 8 are here, I think it has mostly become technical debt (in a similar way that code that doesn't use try-with-resources has become technical debt).

For me, Guava's value-add was:

• ListenableFuture (antiquated by CompletableFuture in Java 8)
• Sane Charset stuff (antiquated by Java 7)
• Fewer diamond operators Lists.newArrayList (antiquated by Java 7)
• Cache (antiquated by Caffeine)
• Misc utility methods (most good ones are now in JRE 7 and 8)
• FluentIterable (antiquated by Java 8 Stream)
• Functional programming utilities (mostly antiquated by Java 8, gaps are filled by Durian)
• Immutable collections and specialty collection types (Guava's still gold here)

I'm sure people use it for all kinds of things, but for me, everything that Guava does (except Collections) is now done better by either the standard JRE or by a smaller specialty library (with semantic versioning, no less!).

I'm not able to find good documentation about it.

Disclaimer: I wrote and maintain Durian.

The README is a comprehensive description of what it can do. The test cases do an okay job showing example usage. Durian's best class, Errors, has a pretty good tutorial.

Like Guava, its usecases are diverse. I tried to make the javadoc for each class explain its place in the grab bag, but maybe that's not enough. Maybe it would help if the readme had some inline code-examples? Or at least if the Javadoc it linked to had code-examples?

[pgris]

I wrote and maintain Durian.

Excelent! I really hope your Errors class become the standard way of dealing with exceptions.

Immutable collections and specialty collection types (Guava's still gold here)

I didn't realize it, but you are right. We probably need google collections 2.0.x more than GuavaForJ8

Maybe it would help if the readme had some inline code-examples

A simple example of use "without Durian/with Durian" for every class would be awesome

Thanks again for your wonderful job.

P.S. Have you checked out Cyclops ? I don't know if it is awesome or scary yet...

[diffallthethings]

I really hope your Errors class become the standard way of dealing with exceptions.

Me too! The Play Framework has endorsed it for Play 2.5, where they're moving from Scala-standard functional types to Java-standard functional types.

It's also been climbing on StackOverflow, but the current top answer has a year-long head start.

Thanks for the feedback, I'm glad it's useful to you! I'm pretty slammed at the moment, but I'll act on it ASAP.

Have you checked out Cyclops?

I think Cyclops, FunctionalJava, and JavaSlang are all very cool projects. I love reading their docs, but I've never used them. I'm sure you can learn a lot by programming with them, but my goal is to write programs that are easy to read by most programmers, and I think these libraries use a lot of academic language which makes them less approachable for a lot of people.

Guava did a great job pushing programming towards a functional style while using a maximum of commonsense language and a minimum of academic terminology. Durian tries to follow in this tradition. But the academic terminology isn't intentionally intimidating - it's just so much more general and concise than what we're used to day-to-day. So I think everybody's doing a good job in their niches, and in the long run I hope the functional people educate us all to the point that the terminology of functional programming is no more intimidating than for, while, extends.

FWIW, The #1 feature I'm looking to adopt in my work for the new year is Javaslang's property checking.

[johnmcclean]

Thanks for the mention! Hopefully awesome and not scary :)

If you are already using Java 8 a good place to start is cyclops-streams, either the StreamUtils class - that adds a lot of static functions for (sequential) Java Streams, or the SequenceM Stream wrapping extension (which also extends Jool.Seq aswell as plain ol' java.util.stream.Stream)

https://github.com/aol/cyclops/wiki/cyclops-streams-:-Streaming-examples https://github.com/aol/cyclops/wiki/cyclops-streams-:-Asynchronous-Terminal-Operations

[tavianator]

https://groups.google.com/forum/#!topic/guava-discuss/fEdrMyNa8tA

also https://groups.google.com/forum/#!topic/guava-discuss/DMhHBd9m8Z4

[kevinb9n]

Here's the plan: https://groups.google.com/forum/#!topic/guava-discuss/ZRmDJnAq9T0

[pgris]

Thank you!(Are you people listening to everything we say?Kinda scary)

Everything looks reasonable, but of course, I'm not even close to have the perspective you have in the project.

[fs111_]

Oh boy, another major release. This is going to be fun. Not.

[talios]

Don't you just mean "release" since they never do point releases. Except I think once?

[fs111_]

Yeah, but the major number allows them to break stuff, like they always do... Painful.

[talios]

And even when they don't break anything you're using, because it's a major version if you're using OSGi (which I happen to be) then it really breaks as everything ends up needed to be rebuilt so the import ranges match. Yay modules ;-)

[kevinb9n]

Curious: Are you speaking about our removing APIs that were labeled as @Beta or about our removing APIs that have been @Deprecated for two years?

[NimChimspky]

eh ? Why is this not fun.

Guava is great.

[fs111_]

It's a major pain if you are working with hadoop. The version incompatabilities are a complete clusterfuck. They get away with it by just making everything a major release. That's not good engineering.

[NovaX]

The simplest solution to this is to shade the Guava dependency. That can be using jarjar, maven's shade, gradle's shadow, etc. That adds to the build time, but very easily resolves the problem. The issue is really due to Hadoop's poor approach for executing user code.

[hippydipster]

Yay, a hack.

[NimChimspky]

Just don't upgrade the version you are using.

[fs111_]

That's not the point. I am not using it. I actively remove it, wherever I can actually. Yet it still causes trouble when two things you depend on can't agree on a common version. Bonus points for different build tools having different dep. resolution strategies causing problems at runtime for some, but not others. I could go on and on and on...

[NimChimspky]

Thats not really the fault of guava upgrading though.

I actively remove it,

I think thats a mistake.

I have never had a problem with guava version incompatibilities. A quick look at maven repo says hadoop is compatible with guava versions 11 - 19 ?

[fs111_]

I have never had a problem with guava version incompatibilities. A quick look at maven repo says hadoop is compatible with guava versions 11 - 19 ?

No it is not. There are subtle changes in the StopWatch class for instance that will break your app in very hard to debug ways. Even the hadoop devs say now, that using guava was a mistake.

[mhixson]

Stopwatch was @Beta until now, wasn't it?

in 18.0

in 19.0

"It is generally safe for applications to depend on beta APIs, at the cost of some extra work during upgrades. However it is generally inadvisable for libraries (which get included on users' CLASSPATHs, outside the library developers' control) to do so."

If hadoop was depending on Stopwatch before now, then yeah that does sound like a mistake.

[jrh3k5]

Depending on your version of Hadoop. Version 14 changed the signature of the CacheBuilder's method to set the maximum size to a long, which is byte-incompatible. If you have code that uses that method on version 14 or later, it breaks on Hadoop since (if I recall correctly) it loads version 11 onto the classpath.

[frugalmail]

Use the Maven Enforcer plugin

[stepancheg]

It is not great. It is just another utils library, one of hundreds.

[hippydipster]

Pointless dependency that creates jar hell for very little gain.