create methods

All of Guava’s collection implementations contain one or more static create methods, these do what you’d expect, and generally offer a slightly more concise way of instantiating the collection classes. Here are two different ways of creating a ArrayListMultimap

Keypress wise you’re not really saving a great deal using the guava methods, so I guess this is a matter of taste as much as anything else. Personally I think the Guava way reads much better, although I think I’d go without the static imports.

Good so far, but hardly earth shattering, what next?

Immutable collections

These are essentially collection objects that you can’t change once they’ve been created, and are useful for all sorts of reasons. Guava provides Immutable implementations for most of the regular Collection interfaces: ImmutableList, ImmutableSet, and ImmutableMap , and also immutable implementations of some of the Guava collection interfaces ( ImmutableMultimap etc.)

My main use for them is creating static constants. For example lets say you need to hardcode a Set of Strings for some purpose. One way to do this might be, eg.

…but that’s starting to look a bit unwieldy, and the unmodifiable methods have one other problem. They only return an unmodifiable view of the collection, if you have a reference to the original collection, you can still alter it!

Whilst this may not be a problem in the last example, I still think a much better way of doing this is to use an ImmutableSet

So, any other advantages of using Immutable collections?

Well there’s several. They can simplify logic considerably, especially in multi-threaded environments. If threads only have read access to an object, them you don’t need to worry about complicated thread synchronization logic

They are also slightly more efficient to use once they’ve been created. If a collection knows beforehand what it needs to store, and there’s never going to be any changes, you can make various time and space savings. For example, most implementations of ArrayLists or HashMaps, will leave some unused space for new objects, so they don’t have to constantly resize themselves. If you know there’s never going to be any new objects, there’s no need for this.

Finally you could also use them as hash keys. If the contents of a collection can’t change, then neither will it’s hashcode!

Any disadvantages?

There is of course one big disadvantage of Immutable objects, which is pretty obvious. You can’t change them! If you need to alter the collection, you’ll first need to take a copy of it. In certain situations – ie where concurrency is a concern – you may in fact want to take this approach. However this is going to be impractical where collections contain many many objects and you’ll probably want a good old fashioned mutable collection (complete with synchronization code if required).

The only other thing to be aware of is, just because your collection is immutable, it doesn’t mean the objects contained in them automatically are. If you can get a reference to an object in an immutable collection, then there’s nothing to stop you changing any mutable state on that object! As a consequence it’s best practice to make sure anything you keep in an immutable collection is immutable itself!

Newsletter

Join them now to gain exclusive access to the latest news in the Java world, as well as insights about Android, Scala, Groovy and other related technologies.

Email address:

Recent Jobs

No job listings found.

Join Us

With 1,240,600 monthly unique visitors and over 500 authors we are placed among the top Java related sites around. Constantly being on the lookout for partners; we encourage you to join us. So If you have a blog with unique and interesting content then you should check out our JCG partners program. You can also be a guest writer for Java Code Geeks and hone your writing skills!

Disclaimer

All trademarks and registered trademarks appearing on Java Code Geeks are the property of their respective owners. Java is a trademark or registered trademark of Oracle Corporation in the United States and other countries. Examples Java Code Geeks is not connected to Oracle Corporation and is not sponsored by Oracle Corporation.