Google recently open-sourced a series of libraries it uses in internal Java projects. The aim of the Guava libraries is to enrich the core JDK 1.6 APIs, providing missing functionality for common use-cases. In its current release, Guava includes three packages: com.google.common.primitives, com.google.common.io, and com.google.common.util.concurrent. Additional libraries will also be made available for networking-related tasks, collections, and reflection.
Since the main goal of the Guava libraries is to provide features for common use-cases that are not part of the JDK, it addresses programming issues as fundamental as working with primitive values. For example, a series of classes in the library provide rich interfaces for String and character manipulation, such as matching String patterns or joining Strings together by a common pattern. The primitives package also provides APIs to make it easier to work Ints, Bytes, and other Java primitive values.The io sub-package, in turn, provides convenient utilities to work with byte and character streams, as well as for reading and writing files.
The Guava APIs work on JDK 1.6, but they may also be used on other Java platforms, such as Android and the Google App Engine.
Most of the Commons components tend to support back to JDK 1.4 or 1.3 and since Apache Commons has a much longer history, there are more of them to choose from.
And "like Guava" they are "also" Apache 2.0 licenced.
The main thing Guava introduces is an unwanted dependency on JDK 1.6
Unless you need something specific in it and you don't mind the JDK 1.6 constraint - then I would suggest avoiding it.
Commons has a lot of poorly implemented crap, too.
Code review is pretty much non-existent there.
What do I think of the Guava project?
It's interesting to see what Google engineers put out. You then know exactly where you stand among the alleged best of the best.
I also think this is good for Google in general. New hires can more quickly dive right in if they know Google's core APIs and ideas (i.e., MapReduce). This is what Google wants. It takes time to learn APIs, and so it only makes sense to open source stuff that is not critical to operations.
> The main thing Guava introduces is an unwanted dependency > on JDK 1.6 > > Unless you need something specific in it and you don't > mind the JDK 1.6 constraint - then I would suggest > avoiding it.
For those who have already moved on to require Java 6 (Sun ends Java 5 support next month after all except for those who pay for extended support), having libraries that exclude pre-Java-6 cruft is a real bonus.
It's way past time for developers to be requiring Java 6. Even the ever so slow to update IBM produced a version of WebSphere that supports Java 6 some time ago. If you're still using something that does not support Java 6, then it's time to update to a later version that does.
> It's way past time for developers to be requiring Java 6. > Even the ever so slow to update IBM produced a version of > f WebSphere that supports Java 6 some time ago. If you're > still using something that does not support Java 6, then > it's time to update to a later version that does.
P.S. Yes, I do know that Java ME is stuck back in a pre-Java-5 world. This is purely utterly ridiculous. Sure, I understand cell phone companies won't update existing phones to contain new JVMs, but people update (churn) phones pretty quickly. The issue is that those driving Java ME, most especially including the handset folk, clearly have no interest in biting the bullet and doing what it takes (including updating the ME standard) to get Java ME phones that ship today to be compatible with today's version of Java. No wonder Google had to introduce Android -- Java ME is an anachronism. Google wants to use the latest and greatest Java version and libraries which leverage it *everywhere* (remember WORA). The ME spec folk don't seem to care that they're creating an isolated backwards technical space.
> It's interesting to see what Google engineers put out. > You then know exactly where you stand among the alleged > d best of the best.
I took a look at the ByteStreams copy method and it will likely perform slowly on may stream classes. In informal testing, I've found the approach they use (single byte) to be about 30 times slower for disk IO than a buffered approach.
> > It's interesting to see what Google engineers put out. > > You then know exactly where you stand among the alleged > > d best of the best. > > I took a look at the ByteStreams copy method and it will > likely perform slowly on may stream classes. In informal > testing, I've found the approach they use (single byte) to > be about 30 times slower for disk IO than a buffered > approach.
I thought static analysis tools Google uses would check this. I guess they don't use PMD or something equivalent. Well, that's revealing. I would expect big companies to have somebody whose full-time job is incorporating this stuff.
Previous Topic
