开发者

Google guava vs Scala collection framework comparison

There are a lot of common concepts:

  • immutable collection,
  • collection view,
  • strict/non strict collection,
  • collection builders

same patterns in Guava and Scala Collection API. So what is the difference? Is both library are consistent with patterns? Is e开发者_运维问答asablity of extension is good enought?

So I would like to hear comparison of those frameworks from someone who use them both.


Google Guava is a fantastic library, there's no doubt about it. However, it's implemented in Java and suffers from all the restrictions that that implies:

  • No immutable collection interface in the standard library
  • No lambda literals (closures), so there's some heavy boilerplate around the SAM types needed for e.g. predicates
  • lots of duplication in type specifications, especially where generics are involved

Guava also has to exist in the presence of Java's standard collection library, so it's rare that 3rd party libraries will expose guava-compatible function literals or make use of guava-specific collection types. This causes an impedance mismatch for every third party library that you use. For example, you'll typically want to convert returned collections from such libraries to the appropriate guava immutable collection - especially if working in a multithreaded environment.

Scala collections have a design that is far better integrated into the language, you'll find them widely used throughout the scala standard library and through 3rd party products implemented in Scala. Scala collections are also immutable by default, so you end up with far safer code that doesn't require an extra layer of defensive wrapping.

If you can use Scala, then do so, it has many advantages beyond just the collections framework. If you have to use Java, then Guava is a good choice, especially given that Scala collections aren't particularly easy to use without the language features that Scala provides.

In a mixed project, Guava collections are prefectly usable from within Scala, but the language also provides mechanisms allowing you to use Java collections (including Guava's, which expose the same interfaces) as though they were Scala's own collections.


I use guava in all my java projects now. It gives a nice functional touch to java collections with similar patterns.

However, writing closures in java mean defining lots of anonymous class directly which is verbose and boring.

Scala collections are still superior in term of design (with the cascade of partial implementations due to traits) and functionalities. It is easy to create your own collection and gain all the advantages of scala collections by just implementing a small set of methods.


The others already answered your question, but I think you missed an interesting alternative, the Functional Java Library. It ignores the Java Collection API, and provides immutable collections that look and behave like simplified Scala collections.


I have used Scala, Google collections and F#. Lately I have been using Google collections Iterators and remiss of the power of F# sequence expressions. It seems Scala prefers non-strict (lazy) lists over iterators/sequences.

In F# and Google collections (see google Iterators) you can transform and filter iterators creating a nice push pipeline of work that is represented as stream of objects. Its not that you can't do this in Scala its just not common. F# has a cool pipe operator for filtering iterators (sequences).

For example I would expect Scala's yield expression to generate an iterator like Python (or F# sequence blocks) instead it returns a list.

Both are very similar and Scala has huge advantages in terms of speed and syntax but when using them I feel (my opinion):

  • Google collections is Map and Iterator focused.
  • Scala is very List focused.

NOTE it appears Scala 2.8 has made some big changes in its collections (I used an older version of Scala).

0

上一篇:

下一篇:

精彩评论

暂无评论...
验证码 换一张
取 消

最新问答

问答排行榜