
Reasons to use Guava - ooohhhddeeaarrr
http://insightfullogic.com/blog/2011/oct/21/5-reasons-use-guava/
======
s1rech
I am a fan of Guava, not just as a very useful library, but as a way to read
really good Java code. Check the source out, it is imo a must if you are a
java dev.

One thing I'm not a fan of is the functional stuff. The idea is good, but java
is just too verbose. Without real lambdas, like C# has now, it ends up being
not so useful.

~~~
latchkey
The whole Java is too verbose argument is starting to sound like a broken
record. With an IDE and tools like ProjectLombok around, you don't need to
type much more than most other languages. I code a lot in CoffeeScript and
Java and I type less in Java because at least it has static types and code
completion. Try renaming a method or variable in CoffeeScript. ;-) ctrl-space
(code completion) and annotations are your friends. Obviously Java8 makes the
whole argument go away and now that the multi-year stalemate on Java7 is over,
we know that Sunacle is focused on getting Java8 out as well.

~~~
jshen
It isn't about how much you type, but how much noise your brain has to parse
when you read it later.

~~~
hello_moto
My brain has to either parse or guess every time I read JS or Ruby code due to
lack of information located near the subject code.

Obviously this is a neverending debate.

~~~
latchkey
Agreed. I spend way more time in the debugger in CoffeeScript than I do with
Java, simply because I have no idea what type of object I'm dealing with at
that particular instant. I also tend to write pages of Java code and it runs
the first time because I can read it and see exactly what it is doing before
it runs. The compiler also tells me what typos I have in my code before I even
have to run it.

~~~
jshen
I don't buy this for a second for many reasons. First, in Java I have to deal
with a lot of other headaches. Heaven forbid I have to customize maven! Or,
I'm using some annotation based framework, let's say jax-rs, and I'm trying to
figure out why the annotations I'm putting on something aren't having the
effect I think they should be having. Then there is the fact that my java
project will likely have more lines of xml than lines of code in the
equivalent ruby project.

But, at the end of the day I'll bet money that I can write a non trivial
website faster with rails using notepad than the vast majority of java people
can with their favorite IDE and java framework.

~~~
trimbo
All of your complaints are about frameworks and tools, not the language
itself.

Have you ever tried Play?

~~~
jshen
I have tried play, and my comment with a link is about the languages.

~~~
trimbo
Sorry, I'm not groking what you mean. You mentioned problems with Maven, Jax-
RS, and XML, then countered that with Rails in notepad.

None of these is a language, they are all frameworks and tools.

~~~
jshen
Sorry, I wrote more than one comment in this thread and was referring to one
of the others. Java is much more verbose and I believe that has a negative
impact. Here's the example I used earlier:
[http://jaydonnell.com/blog/2011/08/07/is-your-idea-
clearly-e...](http://jaydonnell.com/blog/2011/08/07/is-your-idea-clearly-
expressed-in-your-code/)

That same code in C# would be nearly as concise as the ruby code. But there is
more to it than just this. I've seen large Java projects that can't decide if
they want to use interfaces or abstract classes. I don't think this is
something one should spend much time on, but you're forced to in Java.

I've also see large java projects where they have some public interface that a
bunch of other people are building off of, and after a couple years they
realize they need to add a method to it. Ruh roh, what now? Again, why is this
so painful?

Obviously these aren't problems in ruby because you can change classes at
will. This scares some people, but I've done a LOT Of ruby and haven't had any
serious problems with it. If you really like static typing then scala solves
these problems as well and keeps the static typing.

Oh, another problem I've had in java are two frameworks butting heads over
which is in the drivers seat as far as annotation based dispatch. Look back at
the early days of combining guice with jax-rs.

------
kjetil
Java 7 also adds java.util.Objects, which contains hashcode() and other useful
methods:

[http://download.oracle.com/javase/7/docs/api/java/util/Objec...](http://download.oracle.com/javase/7/docs/api/java/util/Objects.html)

~~~
eneveu
It's going to be a mess with imports for those who need to use both
com.google.common.base.Objects and java.util.Objects...

------
latch
I don't follow Java development, but I have worked in it occasionally, and
every time I do something in it, I'm inevitably surprised by having to use one
of this commons libraries for something basic.

Is there a reason some of this stuff isn't added to the base framework?

~~~
Nitramp
\- Java has historically included things in its standard library that
(presumably) everyone regrets nowadays, like CORBA support. The standard JRE
is already overweight. Also keep in mind that size matters for Java - in
theory, it's a client side environment that's downloaded and installed by
consumers (of course, in practice nobody does that anymore).

\- The standard library has to be implemented by all JVM vendors, so adding
lots of stuff to it that can also easily be shipped as a library creates a lot
of unnecessary effort.

\- Changes to the Java standard library have to go through a committee process
(JCP); again, it's probably just not worth the effort.

~~~
rlmw
Bear in mind the in-progress modularity JSR
(<http://jcp.org/en/jsr/detail?id=294>) that might help this problem. Also,
some people won't want everything that Guava provides.

------
haasted
Adding to #1 :

Using static imports to import the newHashMap() method can make the statement
even shorter :

    
    
      final Map<String, Map<String, Integer>> lookup = newHashMap();
    

This serves to make the code far more readable.

~~~
guard-of-terra
In bolts, it's

    
    
      Map<String, Map<String, Integer>> lookup = Cf.hashMap();
    

Which is as short and also doesn't require static imports.

Bolts are the state of art FP library for java.

[https://bitbucket.org/stepancheg/bolts/src/tip/src/main/java...](https://bitbucket.org/stepancheg/bolts/src/tip/src/main/java/ru/yandex/bolts/collection/example/ListFExample.java#cl-22)
some examples in tests

~~~
michaelcampbell
Sadly not in maven repo yet so my company can't use it. I have played around
some with functional java (functionaljava.org) and Op4j. Have you compared
bolts to either of those?

~~~
guard-of-terra
As far as I know, functional java was used as inspiration, but bolts were much
more suitable for day to day tasks (a lot of pragmatic code already there).

No idea about the recent development in fj, they probably made some
improvements in the meantime, too.

------
power
And one reason not to: [http://code.google.com/p/guava-
libraries/issues/detail?id=36...](http://code.google.com/p/guava-
libraries/issues/detail?id=364)

Java 6 source was introduced without explicit intention and once detected was
not addressed. Many companies would not use something whose vital dependencies
change on a whim or oversight. A lot of shops are still using Java 5 compilers
and have no immediate plan to upgrade. Some cannot upgrade conveniently.

~~~
eneveu
Your comment might be misunderstood. While Guava now requires Java 6 to
compile, it is not required to run it. Guava is still targeting Java 5. You
can use it by declaring a Maven dependency or by adding the latest Guava jar
to your project libraries... But yeah, it forces you to upgrade your compiler.

There is an issue to create a Java 5 backport branch when Guava moves to Java
6: <http://code.google.com/p/guava-libraries/issues/detail?id=32>

~~~
eneveu
Kevin Bourrillion (Guava lead developer) just made an insightful reply on this
subject in the issue tracker:

    
    
      > Saw this bug referenced as "a reason not to use Guava." 
      > Does everyone understand that Guava is still perfectly
      > *usable* on JDK 5, it just can't be *built* using JDK 5,
      > and that part of the reason for that is *compiler bugs*
      > in JDK 5 whose fixes in 6 were never backported?
    

[http://code.google.com/p/guava-
libraries/issues/detail?id=36...](http://code.google.com/p/guava-
libraries/issues/detail?id=364#c7)

------
nfriedly
We've started using Guava recently and one of my favorite changes is that you
no longer need try/catches around string conversions in case the OS doesn't
support utf-8.

~~~
eneveu
Yes. Passing Charset arguments as String not only forces you to deal with the
checked UnsupportedEncodingException, but it's also brittle: it's easy to make
a typo (is it "utf8", "utf-8", "UTF8", or "UTF-8"?) and get a runtime failure.

Guava solves this problem by defining standard Charset constants in
com.google.common.base.Charsets ( [http://docs.guava-
libraries.googlecode.com/git-history/v10.0...](http://docs.guava-
libraries.googlecode.com/git-
history/v10.0.1/javadoc/com/google/common/base/Charsets.html) ). Java 7 also
brings java.nio.charset.StandardCharsets (
[http://download.oracle.com/javase/7/docs/api/java/nio/charse...](http://download.oracle.com/javase/7/docs/api/java/nio/charset/StandardCharsets.html)
), but Guava will do for now :)

------
nvarsj
Adding to the OP:

Immutable collections, e.g. ImmutableMap.of(key, value). These tend to be
faster than their mutable counterparts.

MapMaker - really handy for building caches and computing maps. Possibly the
most useful thing in guava for simplifying non-trivial Java programs.

Suppliers#memoize - lazy loading without the ugly DCL code that usually goes
with it.

Good libraries make a language much more enjoyable to work in. Thanks Google!

------
swah
Once again, I'm faced with a choice of language before starting a project... I
kinda hate having this choice.

------
afsina
Guava is cool. But Java7 makes some of it's packages or classes redundant.
Good stuff anyway.

------
gren
Well, I recommend to move to scala language instead :)

~~~
rlmw
I don't really see what this has to do with the article itself. It's totally
ridiculous to compare learning a new language, developer tools etc. with
adding a single library to a project. Also, Scala is specifically designed to
bring many benefits at the language and library level that Guava won't.

I really find this kind of Snark disappointing on HN, and one of the many
examples of a decline in the quality of comments that PG has talked about.

~~~
erwanl
I agree with him - what Guava brings (functional programming, better safety in
types) is something that is better done at language level like in Scala.

Either you like Java and you don't need Guava, or you want functional
programming and other goodness and for that Scala is a better language.

~~~
gren
Exactly!

