7 ms·

Reasons to use Guava

haasted 15y ago
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.
- ooohhhddeeaarrr 15y ago
  If I were writing the code to use, I would do exactly that. Since it was a explanatory tutorial, I wanted people to see what was happening. Later on I've used static imports after explaining what classes they need to look at for the code. I totally understand your point of view though.
- guard-of-terra 15y ago
  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/ru/yandex/bolts/collection/example/ListFExample.java#cl-22 https://bitbucket.org/stepancheg/bolts/src/tip/src/main/java... some examples in tests
  - michaelcampbell 15y ago
    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 15y ago
      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.
latch 15y ago
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?
- netmau5 15y ago
  The important algorithms are in the core library. This is a more friendly API to use both collections and operations on them. And while I love what Guava brings to the table, I do not agree with bringing API candy into base Java. When it comes to heavily used things like collections, this is obviously a gray area. My preference is that they obsolete the need for several of these things at the grammar-level with list/map syntax and [real] closures.
- Nitramp 15y ago
  - 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 15y ago
    Bear in mind the in-progress modularity JSR (http://jcp.org/en/jsr/detail?id=294 http://jcp.org/en/jsr/detail?id=294) that might help this problem. Also, some people won't want everything that Guava provides.
- nvarsj 15y ago
  A lot of the most useful stuff in Guava is coming in JDK8 - most of the collection/functional APIs. Still, I'm surprised by your observation. What are you coming from that has a more comprehensive standard library? All I can think of is possibly .NET.
power 15y ago
And one reason not to: http://code.google.com/p/guava-libraries/issues/detail?id=364 http://code.google.com/p/guava-libraries/issues/detail?id=36... 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.
- efsavage 15y ago
  While a silent unilateral change is bad form, as is requiring an upgrade for a minor feature like this, Java 6 is almost 5 years old now...
- eneveu 15y ago
  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 http://code.google.com/p/guava-libraries/issues/detail?id=32
  - eneveu 15y ago
    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=364#c7 http://code.google.com/p/guava-libraries/issues/detail?id=36...
gren 15y ago
Well, I recommend to move to scala language instead :)
- rlmw 15y ago
  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 15y ago
    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 15y ago
      Exactly!
  - gren 15y ago
    Sorry to have been so prompt. What I meant was "if you want more than that, I would recommand Scala". Scala is close to Java because it compiles to JVM and you can use Java libraries in scala (so that's not a big deal to switch to it). You can nearly code in scala like in Java with some syntax improvment and in a functional way.
- SWengineer 15y ago
  I'd have to agree. One of the main benefits touted for guava in this article is the ability to use java libs with cleaner syntax. Scala already enables us to do that, and a lot more. I've coded java for the last 12 years, but have to admit there's no denying that there are cleaner ways of getting things done in Scala, Ruby, Python etc. of those 3 scala is the only one fast enough to be taken seriously.
kjetil 15y ago
Java 7 also adds java.util.Objects, which contains hashcode() and other useful methods: http://download.oracle.com/javase/7/docs/api/java/util/Objects.html http://download.oracle.com/javase/7/docs/api/java/util/Objec...
- deleted 15y ago
  [deleted]
- eneveu 15y ago
  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...
s1rech 15y ago
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.
- Moocar 15y ago
  I'm a big fan of the functional stuff. Writing transform statements using for loops is painful and error prone in comparison to a quick anonymous function using Collections2. Yes, it looks ugly, but at least there's less duplication, and if you're using code completion in an IDE (which you are, because it's java), it's actually faster to write.
- latchkey 15y ago
  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.
  - russell 15y ago
    I just wrote a 300 line Java class to replace a 30 line Python script, so I don't think the criticism is unwarranted. (Python is not an official production language. And no, it's not a hidebound corp. Proposed changes need proof)
    - latchkey 15y ago
      Show me the source of both of them.
  - jshen 15y ago
swah 15y ago
Once again, I'm faced with a choice of language before starting a project... I kinda hate having this choice.
afsina 15y ago
Guava is cool. But Java7 makes some of it's packages or classes redundant. Good stuff anyway.
nfriedly 15y ago
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 15y ago
  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.1/javadoc/com/google/common/base/Charsets.html http://docs.guava-libraries.googlecode.com/git-history/v10.0... ). Java 7 also brings java.nio.charset.StandardCharsets ( http://download.oracle.com/javase/7/docs/api/java/nio/charset/StandardCharsets.html http://download.oracle.com/javase/7/docs/api/java/nio/charse... ), but Guava will do for now :)
nvarsj 15y ago
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!

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.

ooohhhddeeaarrr 15y ago
If I were writing the code to use, I would do exactly that. Since it was a explanatory tutorial, I wanted people to see what was happening. Later on I've used static imports after explaining what classes they need to look at for the code. I totally understand your point of view though.
guard-of-terra 15y ago
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/ru/yandex/bolts/collection/example/ListFExample.java#cl-22 https://bitbucket.org/stepancheg/bolts/src/tip/src/main/java... some examples in tests
- michaelcampbell 15y ago
  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 15y ago
    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.

latch 15y ago

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?

netmau5 15y ago
The important algorithms are in the core library. This is a more friendly API to use both collections and operations on them. And while I love what Guava brings to the table, I do not agree with bringing API candy into base Java. When it comes to heavily used things like collections, this is obviously a gray area. My preference is that they obsolete the need for several of these things at the grammar-level with list/map syntax and [real] closures.
Nitramp 15y ago
- 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 15y ago
  Bear in mind the in-progress modularity JSR (http://jcp.org/en/jsr/detail?id=294 http://jcp.org/en/jsr/detail?id=294) that might help this problem. Also, some people won't want everything that Guava provides.
nvarsj 15y ago
A lot of the most useful stuff in Guava is coming in JDK8 - most of the collection/functional APIs. Still, I'm surprised by your observation. What are you coming from that has a more comprehensive standard library? All I can think of is possibly .NET.

power 15y ago

And one reason not to: http://code.google.com/p/guava-libraries/issues/detail?id=364 http://code.google.com/p/guava-libraries/issues/detail?id=36... 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.

efsavage 15y ago
While a silent unilateral change is bad form, as is requiring an upgrade for a minor feature like this, Java 6 is almost 5 years old now...
eneveu 15y ago
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 http://code.google.com/p/guava-libraries/issues/detail?id=32
- eneveu 15y ago
  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=364#c7 http://code.google.com/p/guava-libraries/issues/detail?id=36...

gren 15y ago

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

rlmw 15y ago
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 15y ago
  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 15y ago
    Exactly!
- gren 15y ago
  Sorry to have been so prompt. What I meant was "if you want more than that, I would recommand Scala". Scala is close to Java because it compiles to JVM and you can use Java libraries in scala (so that's not a big deal to switch to it). You can nearly code in scala like in Java with some syntax improvment and in a functional way.
SWengineer 15y ago
I'd have to agree. One of the main benefits touted for guava in this article is the ability to use java libs with cleaner syntax. Scala already enables us to do that, and a lot more. I've coded java for the last 12 years, but have to admit there's no denying that there are cleaner ways of getting things done in Scala, Ruby, Python etc. of those 3 scala is the only one fast enough to be taken seriously.

kjetil 15y ago

Java 7 also adds java.util.Objects, which contains hashcode() and other useful methods: http://download.oracle.com/javase/7/docs/api/java/util/Objects.html http://download.oracle.com/javase/7/docs/api/java/util/Objec...

deleted 15y ago
[deleted]
eneveu 15y ago
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...

s1rech 15y ago

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.

Moocar 15y ago
I'm a big fan of the functional stuff. Writing transform statements using for loops is painful and error prone in comparison to a quick anonymous function using Collections2. Yes, it looks ugly, but at least there's less duplication, and if you're using code completion in an IDE (which you are, because it's java), it's actually faster to write.
latchkey 15y ago
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.
- russell 15y ago
  I just wrote a 300 line Java class to replace a 30 line Python script, so I don't think the criticism is unwarranted. (Python is not an official production language. And no, it's not a hidebound corp. Proposed changes need proof)
  - latchkey 15y ago
    Show me the source of both of them.
- jshen 15y ago

swah 15y ago

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

afsina 15y ago

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

nfriedly 15y ago

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 15y ago
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.1/javadoc/com/google/common/base/Charsets.html http://docs.guava-libraries.googlecode.com/git-history/v10.0... ). Java 7 also brings java.nio.charset.StandardCharsets ( http://download.oracle.com/javase/7/docs/api/java/nio/charset/StandardCharsets.html http://download.oracle.com/javase/7/docs/api/java/nio/charse... ), but Guava will do for now :)

nvarsj 15y ago

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!