31

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 easablity of extension is good enought?

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

yura
  • 14,489
  • 21
  • 77
  • 126

4 Answers4

26

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.

Kevin Wright
  • 49,540
  • 9
  • 105
  • 155
  • 5
    +1 "No immutable collection interface in the standard library." Guava must implement mutable interfaces and return exceptions on the mutable methods, leading to possible runtime exceptions...ughh – Daniel Canas Jul 06 '11 at 17:25
  • 4
    +1 I think you spotted one the biggest differences. While Guava immutability is checked at runtime, Scala immutability is checked at compile time. – paradigmatic Jul 06 '11 at 19:44
  • Why do you think third-party libraries are so averse to using (non-beta) Guava types in their APIs? What's the down-side, given how strict Guava is about backward compatibility? – Kevin Bourrillion Jul 12 '11 at 08:02
  • guava is still a fairly recent library, by Java standards, so many APIs will predate Guava. A more common technique is to use Java collection interfaces for the boundary of a system and a defensive `copyOf` operation. If the collection being copied is also immutable, then this becomes a highly efficient no-op. – Kevin Wright Jul 12 '11 at 08:34
  • 1
    This is an old thread but it should be added that with the new "functional" features of java 8, many of the Guava methods will be superseded by those. The guys at Google are aware of it although I don't know what their strategy is to integrate the two. – Giovanni Botta Nov 19 '13 at 21:45
  • guava has the concept of Table and Multiset which does not exist yet in scala, so it has its added value. – Jas Jan 14 '14 at 11:17
  • 1
    @Jas - Table looks an awful lot like a Map with a tuple for the key, though I can see why it's needed given Java's lack of tuples. As for `Multiset`; Scala has a mutable version only, many have criticized this fact. – Kevin Wright Jan 15 '14 at 11:27
7

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.

paradigmatic
  • 40,153
  • 18
  • 88
  • 147
4

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.

Landei
  • 54,104
  • 13
  • 100
  • 195
3

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

Adam Gent
  • 47,843
  • 23
  • 153
  • 203
  • 1
    Scala lists are strict, the lazy ones are streams. It seems to me, that filters are also common in Scala but hidden in for-expression guards. Is it what you meant ? – paradigmatic Jul 06 '11 at 15:55
  • @paradigmatic Yes that is what I mean. Most languages differentiate between lists, lazy lists, and streams/iterators. Scala and Haskell kind of blur the line at times. This is mostly good its just that its unfamiliar to me. – Adam Gent Jul 06 '11 at 15:57
  • 4
    The for-comprehensions try to return the kind of collection you put in. Using them on an Iterator will usually return a filtered/mapped iterator. – ziggystar Jul 06 '11 at 16:10
  • 2
    "big changes" is an understatement. Scala 2.8 collections were re-written from the ground up. They're a completely different beast and are *much* more powerful and flexible. – Kevin Wright Jul 06 '11 at 17:12
  • @Kevin Wright I have to say so far it looks like one of the most powerful collection implementations I have seen. I feel ignorant not knowing how much better it is now. I'm contemplating deleting my post. – Adam Gent Jul 06 '11 at 18:05
  • 1
    @Adam: Please don't delete your post. The dialog is helpful for those of us starting in Scala. – chaotic3quilibrium Jul 07 '11 at 00:15
  • Scala collections, on the trade-off of power vs api surface, strongly lean to the first (a great choice in scala, can't be replicated in java), whilw guava on the latter. Scala's List is curiously overvalued, it's merely a persistent *stack*, which has some very valid but also very rare usages in java, where basically nobody uses it (I do), so it is very unlikely to find its way to guava. – Dimitris Andreou Jul 09 '11 at 18:58