Live data from Hacker News

Reasons to use Guava

insightfullogic.com

41–50 of 50 posts

Re: Reasons to use Guava

#41
post #14

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.

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…

This whole "with IDEs, you don't need to type that much" argument is starting to sound like a broken record. First off, it's good you don't need to type that much with modern IDEs because they all suck at keeping up with a programmer typing at a decent clip.

As others have pointed out, it's not about how much typing you need to do. It's about how quickly you can form, in your head, a conceptual model of what you see on screen and how accurate that model is. While dog-slow IDEs, half-assed Java-style static typing, etc may help you with that, Java's verbosity certainly does not.

Re: Reasons to use Guava

#42
post #39

Earlier quoted context omitted.

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.

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…

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

Have you ever tried Play?

Re: Reasons to use Guava

#43
post #4

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?

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.

Re: Reasons to use Guava

#44
post #42
post #39

Earlier quoted context omitted.

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…

All of your complaints are about frameworks and tools, not the language itself. Have you ever tried Play?

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

Re: Reasons to use Guava

#45
post #44
post #42

Earlier quoted context omitted.

All of your complaints are about frameworks and tools, not the language itself. Have you ever tried Play?

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

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.

Re: Reasons to use Guava

#46
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!

Re: Reasons to use Guava

#47
post #45
post #44

Earlier quoted context omitted.

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

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.

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...

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.

Re: Reasons to use Guava

#48

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.

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... ). Java 7 also brings java.nio.charset.StandardCharsets ( http://download.oracle.com/javase/7/docs/api/java/nio/charse... ), but Guava will do for now :)

Re: Reasons to use Guava

#49
post #8

And one reason not to: 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.

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

Re: Reasons to use Guava

#50
post #49
post #8

And one reason not to: 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.

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-libr…

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...
Post reply on HN