Reasons to use Guava
insightfullogic.com
insightfullogic.com
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.
Obviously this is a neverending debate.
http://jaydonnell.com/blog/2011/08/07/is-your-idea-clearly-e...
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.
Have you ever tried Play?
None of these is a language, they are all frameworks and tools.
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.
The fact that you need an IDE to handle all the boilerplate for you should indicate the language is too verbose. In fact I feel like that's what it means for a language to be too verbose.
You should read this: http://steve-yegge.blogspot.com/2007/12/codes-worst-enemy.ht...
Correct. You don't actually need an IDE to write Java but unless you have one you're going to be writing a lot of boilerplate by hand. That is the point I am making. The language is verbose whether or not you have an IDE. The IDE simply helps you manage that verbosity.
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.
List<String> strings = transform(list("hello", "world"),
function(s, s.toUpperCase()));
assertEquals(list("HELLO", "WORLD"), strings);
It's really difficult to design a good API and Guava didn't get to be like this overnight. It was used internally at google for years then spent years as a pre-1.0 open source project.
On thr other hand, I always have to pause and think a littlr bit longer when using the Guava PreConditions.checkArgument call (even the author of Guava admitted that too)
http://download.oracle.com/javase/7/docs/api/java/util/Objec...
Is there a reason some of this stuff isn't added to the base framework?
- 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.
Using static imports to import the newHashMap() method can make the statement even shorter :
final Map<String, Map<String, Integer>> lookup = newHashMap();
Map<String, Map<String, Integer>> lookup = Cf.hashMap();
Bolts are the state of art FP library for java.
https://bitbucket.org/stepancheg/bolts/src/tip/src/main/java... some examples in tests
No idea about the recent development in fj, they probably made some improvements in the meantime, too.
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.
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
> 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?
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 :)
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!
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.
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.
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.