In part one, two and three of this blog series we have covered the Google Guava library and the Google Collections library, and how you as a Java developer can benefit from using these libraries to reduce the amount of boilerplate code in your projects. In the final blog post of this series I will walk you through the über collection “Multimap” – which you will all fall in love with and become addicted to;) We will take a look at how you can use Google Collections to do validation with the use of Preconditions, but first, let’s take a look at how we can perform Set and Map operations such as intersections, union and difference.

Set intersections, unions and map operations
Something that tends to be quite the hassle (and messy to write) is to do stuff like intersections, unions or diff on two sets. You often end up having to loop over the sets and well, you don’t want to write that code over and over again. With the Sets class provided by Google Collections, you get stuff like this out of the box (and completely free!

        HashSet setA = newHashSet(1, 2, 3, 4, 5);
        HashSet setB = newHashSet(4, 5, 6, 7, 8);

        SetView union = Sets.union(setA, setB);
        System.out.println("union:");
        for (Integer integer : union)
            System.out.println(integer);        

        SetView difference = Sets.difference(setA, setB);
        System.out.println("difference:");
        for (Integer integer : difference)
            System.out.println(integer);       

        SetView intersection = Sets.intersection(setA, setB);
        System.out.println("intersection:");
        for (Integer integer : intersection)
            System.out.println(integer);

From the Public Object blog:

“Unlike the traditional approach, these methods don’t do any copies! Instead, they return views that delegate to the provided sets. In the occasional case when the copy is worthwhile, there’s a handy method immutableCopy to give you one.”

Similarly, for maps, we have:

MapDifference differenceMap = Maps.difference(mapA, mapB);

and with that MapDifference, we can do stuff like:

differenceMap.areEqual();
Map entriesDiffering = differenceMap.entriesDiffering();
Map entriesOnlyOnLeft = differenceMap.entriesOnlyOnLeft();
Map entriesOnlyOnRight = differenceMap.entriesOnlyOnRight();
Map entriesInCommon = differenceMap.entriesInCommon();

Thank you, Google Collections

Validation with Preconditions
Bent André, a colleague and newest addition to the Codemunchies clan,  introduced me to this concept earlier this summer, but it wasn’t until recently that I discovered that Google Collections actually included some of this stuff (we had our own implementation of a similar concept).

So, what is this concept? Well, validation is definitely something we do a lot, and it usually looks like something along these lines:

        if (count <= 0) {
            throw new IllegalArgumentException("must be positive: " + count);
        }

We want to validate that the calling method invoked our method with the correct arguments. And if wrong, the caller should be warned that he made en error.

As the Java doc explains:

“Precondition exceptions are used to signal that the calling method has made an error. This tells the caller that it should not have invoked the method when it did, with the arguments it did, or perhaps ever. Postcondition or other invariant failures should not throw these types of exceptions.”

So, with the Preconditions class (and static imports), we can replace the code above with the following simple line of code:

checkArgument(count > 0, "must be positive: %s", count);

Likewise, you have similar methods to check state or null values.

checkNotNull(entry);

Quite neat, don’t you think?

“Note that the sense of the expression is inverted; with Preconditions you declare what you expect to be true, just as you do with an assert or a JUnit assertTrue call.”

From the excellent blog series on Google Collections over at Public Object:

“Preconditions provides methods for state validation. It makes input validation compact enough that you’ll always want to do it! And unlike Java’s built-in assert, Preconditions is always enabled.”

A great example of what I find all over the place in my code at Integrasco is the following:

    public PostExample(final String title, final Date date, final String author) {
       //some code to validate that title is not null
       //some code to validate that date is not null
       //some code to validate that author is not null

        this.title = title;
        this.date = date;
        this.author = author;
    }

Now look at how smooth your code becomes with Preconditions:

    public PostExample(final String title, final Date date, final String author) {
        this.title = checkNotNull(title);
        this.date = checkNotNull(date);
        this.author = checkNotNull(author);
    }

Is that neat or what?

We will publish a post on this in more detail soon with regards to exceptions and validations, so stay tuned!

One collection to rule them all! – The Multimap
I can’t even count how many times I’ve made a Map where each key can have multiple values and ended up with the Map<K, List<V>> structure.

And the hassle of adding things to such structures go along the lines of:

    Map<Person, List<BlogPost>> map = new HashMap<Person, List<BlogPost>>();

    public void addBlogPost(final Person author, final BlogPost blogPost) {
        List<BlogPost> blogPosts = map.get(author);
        if (blogPosts == null) {
            blogPosts = new ArrayList<BlogPost>();
            map.put(author, blogPosts);
        }
        blogPosts.add(blogPost);
    }

Don’t tell me you haven’t ever done this? With the Multimap collection from Google Collections, we can do this in the following (very sweet if I may say so) fashion:

    Multimap<Person, BlogPost> multimap = ArrayListMultimap.create();

    public void addBlogPost(final Person author, final BlogPost blogPost) {
        multimap.put(author, blogPost)
    }

Whoop, whoop!

Google Collections provides several implementations of Multimaps, for instance HashMultimap if you want to prevent duplicate pairs, TreeMultimap if you need the pairs in natural order, or LinkedHashMultimap if you need the ability to iterate the maps in insertion-order.

Multimaps provides several utility methods as well, go check out the API documentation on Multimap and Multimaps!

Excited yet? Keep reading!

Partitioning collections
I called this section Partitioning, and I guess you could say it is exactly what we covered under “Filtering Collections” in the previous blog post of this series, but when we apply these concepts in combination with functions and the Multimap, I think you will realize how powerful it can all be!

Let us pretend that we have a list of Maps. Each Map represent a document with certain attributes. A map may look something like this:

mapOf("type", "blog", "id", "292", "author", "john");

I.e., we have three keys, namely “type”, “id”, and “author”.
So our list of maps have the following structure:

List<Map<String, String>> listOfMaps

Now, we want to partition our list into several lists, by the type of entry. Let’s say that one type can be “blog”, another could be “news”, etc.

Now without Google Collections, that would be a real pain in the ass! We would have to loop the list, check the key of each map, then organize them into individual lists. And the hassle would be even bigger if we don’t know what types that we have! Following me?

With a little bit of Function magic, and the use of Multimaps, we can do this in a fairly elegant way:

        Multimap<String, Map<String, String>> partitionedMap = Multimaps.index(
                        listOfMaps,
                        new Function<Map<String, String>, String>() {
                            public String apply(final Map<String, String> from) {
                                return from.get("type");
                            }
                        });

Now we have a Multimap where each key represents the type!
If we want all the maps for a specific type, all we need to do is ask our multimap for it!

Okay, that’s it for now! Hope you enjoyed the ride and that maybe you got inspired to check out these really great projects from the developers over at Google! Feedback is highly appreciated!

In part one and two of this blog series I gave an introduction to the excellent Google Collections and Guava libraries.  In this blog post we will look at how you can use Google Collections to do filtering and ordering! Furthermore, I will show you how we can make Java just a tiny bit more “functional” with Google Collections!

Functions, Functions, Functions!!
Google Collections provides us with a couple of very neat things called Functions and Predicates! Similar to some of the magic you can do with for instance Scala, you can now do with good old non-functional Java! You’ll find these (and more) in the com.google.common.base package in Google Collections.

We will look at Predicates in the next section (on Filtering collections), but first let’s take a look at Functions!
Google Collections provides us with the interface Function<F, T>. In essence, a function is a transformation from one object to another.

The collection utility classes like Lists and Maps provide us with transformation methods:

   topMap = Maps.transformValues(fromMap, function);
   toList = Lists.transform(fromList, function);

To exemplify, let’s say you have a Map of items and a corresponding price in Euros. So, you figure out that you want an easy way to convert all prices to Dollars. Traditionally we would have to loop through the map and update each value with the converted price. Tedious…
With functions, this becomes easy!

Map usdPriceMap = Maps.transformValues(eurPriceMap, new Function() {
            double eurToUsd = 1.4888;
            public Double apply(final Double from) {
                return from * eurToUsd;
            }
        });

Well, you might say that the anonymous inner class makes this a bit messy, and this function would most likely be something that you want to reuse – still it demonstrates the functional aspect of things here. (C’mon please give us closures already!)
Similarly to the example above, we can also use Functions to transform from one object type to a completely different one – say for instance from an Integer to a String.

We will look further into Functions later in this blog series when I walk you through the Multimap collection and show how we can transform from one collection to a another with a little bit of function magic.

Filtering collections with predicates
One of the most common tasks I encounter when working with data at Integrasco is filtering and ordering large collections.
For the sake of simplicity, let’s say you have a list of names that you want to filter (in a rather stupid way):

        List<String> names = listOf("Aleksander", "Jaran", "Integrasco", "Guava", "Java");

With com.google.common.collect.Iterables and com.google.common.base.Predicates we can filter our list for example to just contain Aleksander or Jaran:

Now I know that sounds pretty stupid, but you can also implement your own Predicates, for example to return names that have a length shorter than say 5 characters (I stole this example from Stephan over at codemonkeyism.com):

        Iterable<String> filtered = filter(names, or(or(equalTo("Aleksander"),equalTo("Jaran")), lengthLessThan(5)));

Which will return us Aleksander, Jaran and Java (since Java is shorter than 5 chars.) The ‘or’ part here is a bit messy to read, but bear with me. The ‘equalTo’ and ‘or’ predicates are given to us for free by the Predicates class.

So to implement that lengthLessThan predicate, all you need to do is:

    private static class LengthLessThanPredicate implements Predicate<String> {
        private final int length;
        private LengthLessThanPredicate(final int length) {
            this.length = length;
        }
        public boolean apply(final String s) {
            return s.length() < length;
        }
    }

Wrap that in whatever utility class you want and access it like this:

    public static Predicate<String> lengthLessThan(final int length) {
        return new LengthLessThanPredicate(length);
    }

Check out Stephan‘s blog post on writing fluent interfaces for Google Collections – It’s really quite neat!

Sorting / Ordering Collections
Thanks to the java Collections utility class we can do stuff like

Collections.sort(List<T>, Comparator<? super T>)

But sometimes we want to do more complex stuff, combining several Comparators and moreover we may want a view of the sorted list, without changing the original order.

Google Collections provides us with Ordering, which allow us greater control over our sorting.
Let’s say we have two simple comparators for a class Person, that compares by lastName or by firstName:

        Comparator<Person> byLastName = new Comparator<Person>() {
            public int compare(final Person p1, final Person p2) {
                return p1.getLastName().compareTo(p2.getLastName());
            }
        };
        Comparator<Person> byFirstName = new Comparator<Person>() {
            public int compare(final Person p1, final Person p2) {
                return p1.getFirstName().compareTo(p2.getFirstName());
            }
        };

Now, if we want to sort by last name first, then by first name, and then return the sorted results in reverse order, all we need to do is:

        List<Person> sortedCopy = Ordering.from(byLastName).compound(byFirstName).reverse().sortedCopy(persons);

And even better, you don’t even need to create Comparators, you can just extend Ordering!

        List<Person> sortedCopy = orderByLastName.compound(orderByFirstName).reverse().sortedCopy(persons);

Filtering and Sorting cont’d
So in part 1 on this blog series, Steve commented that in Scala, you can do stuff like the following:
people.filter(_.firstName == "Steve").sort(_.lastName < _.lastName)
i.e. get people named Steve from the list people, and then sort by their last name.

Syntactically, that line of Scala code is pretty neat! So let’s see what we can do with Google Collections then. Google Collections provides us with the Iterables class that we covered earlier in this blog post (under filtering). We can do both filter and transform with the Iterables class (and you can do the same with Collections2, provided by Google Collections as well).
So I wanted to have a crack at how to solve the same thing as Steve did with his line of Scala code, and even though it is not as neat, this is one way of solving the above Scala code with the use of Predicates and Ordering:

   Ordering.from(byLastName).sortedCopy(filter(persons, withFirstName("Steve")));

Still not close to the syntactical sugar we get from Scala (and obviously we would need our “withFirstName” predicate and the “byLastName” Comparator), but at least this is much closer than where we were without Google Collections! (And it would become even easier to read if we take on Stephen’s approach to fluent interfaces).

As Kevin Bourrillion commented on another blog post on writing functional Java:

“The syntax sucks. At the same time, this stuff is now, has always been and will always be nothing but a stopgap measure until the right language change can come along, at which time we can finally really decide on the optimal syntax and have functional-style programming start actually making lives better in Java for once. So I’m undecided how much effort to put into the Function/Predicate stuff; it’s in the library more because it sort of had to be, not so much because we think it’s a crown jewel.”

In the next and final part of this blog series on Google Collections and Guava we will take a look at Set and Map operators in Google Collections, Validation with Preconditions and I will walk you through the wonderful Multimap collection and how we can use this for partitioning!

Stay tuned!

In part one of this blog series I gave an introduction to the excellent Google Collections and Guava libraries and briefly explained how you as a Java developer can benefit from using Guava with Collections to reduce the amount of boilerplate code in your projects. In this blog post we will dive deeper into the more advanced features that Guava offers to you as a Java developer!

We will take a deeper dive into Guava and look at the really neat CharMatcher class, the Joiner and Splitter classes and what else Guava brings us when it comes to working with primitives.

The Guava CharMatcher
The CharMatcher class in Guava is a quite neat addition to your Java toolbox! Some people call it “StringUtils on steroids”:p
Out of the box you have access to some predefined constant matchers like CharMatcher.WHITESPACE, CharMatcher.JAVA_DIGIT or CharMatcher.ASCII, and in addition you have some neat factory methods like CharMatcher.is(‘aaa’), CharMatcher.isNot(‘bbb’), CharMatcher.oneOf(‘abcd’).negate() and even more complex things like:

CharMatcher.inRange('a', 'z').or(inRange('A', 'Z'));

You can also subclass it and implement the matches(char c) method. You can even create one from one of your Google Collection Predicates (that we will cover next time)!

So, if you want to get all the digits from a piece of text, all you need to do is:

String string = CharMatcher.DIGIT.retainFrom("some text 89983 and more");

You want to go the other way around and remove all digits from a string, simply do the following:

String string = CharMatcher.DIGIT.removeFrom("some text 89983 and more");

For matching purposes you have several methods like:
matchesAllOf(CharSequence)
matchesAnyOf(CharSequence)
matchesNoneOf(CharSequence)

You also have indexIn, lastIndexIn and countIn methods in addition to several methods for trimming, replacing and collapsing.
Check out the Java doc for more info!

Joiner and Splitter
The Joiner class is currently part of Collections and the Splitter class is found in Guava (but will ultimately join hands in Guava, once Collections get it’s 1.0 release).
With the Joiner class, we can do stuff like this:

 String[] subdirs = { "usr", "local", "lib" };
 String directory = Joiner.on("/").join(subdirs);

or this:

 int[] numbers = { 1, 2, 3, 4, 5 };
 String numbersAsString = Joiner.on(";").join(Ints.asList(numbers));

Thanks to Guava we can also join directly on primitives, which is quite handy:

 String numbersAsStringDirectly = Ints.join(";", numbers);

For Strings we can obviously split directly, but the behavior is somewhat strange, and the Splitter class is more robust and gives us more options. Also, String split always returns and array as where the Splitter class returns us an Iterable.

Iterable split = Splitter.on(",").split(numbsAsString);

With the String split you can simply do:

String[] splitRegular = testString.split(",");

But try doing that with a String like this one:

String testString = "foo , what,,,more,";

Output would be:
‘foo ‘
‘ what’
”
”
‘more’
And that might be fine, but the Splitter class let’s us gain more control over the desired output of the splitting:

Iterable<String> split = Splitter.on(",").omitEmptyStrings().trimResults().split(testString);

Giving us the output ‘foo’,'what’,'more’

Both the Joiner and Splitter classes are configurable and you can even use the Joiner on maps!

Working with primitives cont’d
In part one of this blog series I briefly mentioned working with primitives and that Guava offers things like Ints.compare(a, b) and Ints.toArray(list).

Let me just introduce you to a couple of more handy things that Guava offers when it comes to working with primitives.

Let’s say we have an array of ints, and we want to know if that array contains a specific int. The old way of doing that would look something like this:

 int[] array = { 1, 2, 3, 4, 5 };
 int a = 4;
 boolean hasA = false;
 for (int i : array) {
 if (i == a) {
 hasA = true;
 }
 }

With Guava, we can do this:

boolean contains = Ints.contains(array, a);

And again, we can do this with all the other primitives as well! We can even do things like this directly in our array:

 int indexOf = Ints.indexOf(array, a);
 int max = Ints.max(array);
 int min = Ints.min(array);
 int[] concat = Ints.concat(array, array2);

In the next post in this series we will take a look at the more advanced features of the Google Collections library such as Functions, Filtering and Ordering! Stay tuned, and please share your comments with us!

http://www.flickr.com/photos/mache/ / CC BY 2.0

So I’ve been advocating Google Collections to all my colleagues since early this summer. Kevin Bourrillion said that one of his colleagues had told him that “not being able to use the Google Collections was like ‘coding with one hand tied behind his back.’“.

I couldn’t agree more with Kevin’s colleague!

Maybe the title of this blog entry is a bit strange. I mean “beautiful code”. I guess I could have said “less verbose” Java code, but hey, that doesn’t have the same magic sound to it!

Before I start this whole highly promotional rant about my new favorite java libraries, let me ask you a couple of questions:
How many times have you written something like this in your code:

Map<String, Map<Long, List<String>>> map = new HashMap<String, Map<Long,List<String>>>();

Or maybe something along these lines:

int a = 5;
int b = 10;
int compareTo = Integer.valueOf(a).compareTo(Integer.valueOf(b));

(Or with lots of ifs and elses;))

And how many times have you written something along these lines, just to read something from a file?:

File file = new File(getClass().getResource("/test.txt").getFile());
BufferedReader reader;
String text = "";
try {
reader = new BufferedReader(new FileReader(file));
String line = null;
while (true) {
line = reader.readLine();
if (line == null) {
break;
}
text += line.trim() + "\n";
}
reader.close();
reader = null;
} catch (FileNotFoundException e1) {
e1.printStackTrace();
} catch (IOException e) {
e.printStackTrace();
}

Yeah, I thought so… So what’s all the fuzz about? We’ve had Apache Commons Collections for several years. Why should we use yet another collections library?
I’ve read several comments like this one:

“Any Java programmer who’s been around awhile will already have accumulated most of these types of utility classes.”

Well, yes, that might be (and should hopefully) be true for most developers. But then again, there’s so much more to it than just getting rid of boiler plate code and reusing nifty utils! In this blog post I want to show you some of the things that really made me curious about – then later addicted to – Google Collections.

Like Jared Levy once said:

The library’s functionality simplifies your code so it’s easier to write, read, and maintain. While you can survive without such features, the Google Collections Library will improve your productivity as a developer, while reducing the amount of boilerplate low-level code you need to write.

http://www.flickr.com/photos/orcaman/ / CC BY 2.0

Furthermore I want to show you some of the cool stuff that the guys over at Google have been churning up under the name Guava, and how YOU as a Java developer can utilize these nifty libraries to make your code cleaner, faster to write, and once and for all get rid of all a lot of that boiler plate code we all hate so much!

Google Guava is the Google Core Libraries for Java 1.6. It is still a rather immature library that is subject to changes over the coming months, but will eventually be THE Java library;) Google Collections will become part of Guava once Collections reaches it’s 1.0 release. Guava (and Google Collections) have been pioneered by several Google developers and is widely used in their “myriad of Java projects”. Among others, the people behind it are Kevin Bourrillion, Jared Levy, Crazy Bob Lee, Josh Bloch(!) (Chief Java Architect at Google etc.) and limpbizkit (have no clue what this guy’s name is – anyone?:p). Google Collections has been around since 2007 (I think?) but Guava saw the light of day in September 2009.

In part one of this blog series I’ll give you an introduction to Google Collections and show you how you can benefit from using Guava with Collections to reduce the amount of boilerplate code in your projects (and gain access to the new and faster data structures that they provide!). In part 2 we will dive deeper into the more advanced features that Guava and Collections offers to you as a Java developer, so stay tuned!

Google Collections at a glance
Obviously one blog post will not give Google Collections the amount of in-depth coverage it deserves, so I’ve decided to just spend some time with the basic yet powerful features that I use on a daily basis when I write code.
First of all, don’t do this:

Map<String, Map<Long, List<String>>> map = new HashMap<String, Map<Long,List<String>>>();

Do this:

Map<String, Map<Long, List<String>>> map = Maps.newHashMap();

or rather this, (with static imports):

Map<String, Map<Long, List<String>>>map = newHashMap();

Nice, right? Thanks to generics and those handy factory methods that the Collections guys have provided us with, we no longer have to write things that Java really should understand, right? Yeah, I know this will be part of JDK 7, and that’s great. But Google Collections is here, now!

Similar to the static utility methods that com.google.common.collect.Maps provide, we also have Lists and Sets.

Lists.newArrayList();
Sets.newHashSet();

…and more! Go check it out for yourself!

Populating lists and maps
When writing unit tests you often want to populate lists (or maps, or sets) with dummy data, and as the sloppy “duct-tape” programmer that I am, I’ve found the same code over and over again in my tests, along these lines:

List<String> list = new ArrayList<String>();
list.add("a");
list.add("b");
list.add("c");
list.add("d");

Yeah, I know. Dirty. I want an immutable list, populated with my dummy data, and I want to do it with one line of code! How? Well, that’s easy!

ImmutableList<String> of = ImmutableList.of("a", "b", "c", "d");

Same goes for Maps!

ImmutableMap<String,String> map = ImmutableMap.of("key1", "value1", "key2", "value2");

I’ve grown really fond of these simple, yet powerful ways of writing code now. I wanted to write that line in an even shorter way, but couldn’t do it out of the box with static imports since both ImmutableList and ImmutableMap had the method “of”. But a quick workaround was simply to wrap these creational factory methods (and builder methods that they provide) in a collection util of our own. So for immutable maps and lists I simply write:

ImmutableMap<String,String> map2 = mapOf("key1", "value1", "key2", "value2")

or

ImmutableList<String> list2 = listOf("a", "b", "c", "d");

And if I want to populate an ArrayList (or a HashMap) I use:

ArrayList<String> list3 = arrayListOf("a", "b", "c", "d");

The choice is yours, obviously, but you have to admit, it’s quite neat compared to the “old” way, right?
Apart from the handy and clean ways of creating collections and populating them, we are also provided with lots of additional utility methods like filtering, set intersections and union, ordering and even some neat functional stuff! I’ll cover that in part 2!

Static imports and Eclipse templates
Before I wrap this up I want to tell you about how I use Collections even more efficiently when I code by using the Eclipse Code templates. (I assume you have similar features in IDEA and other IDE’s, so you can probably follow this recipe to some extent anyways):

Being a user of Eclipse I love shortcuts (check out Jaran’s post about MouseFeed and how you can easily learn Eclipse shortcuts).
Okay, Ctrl+Space is your friend! It’s also known as auto-complete:)
With Eclipse, you can create a template that binds to an auto-complete key-word and this is where the magic begins!
Instead of having to write Maps.newHashMap() or (even better – adding the method as a static import and writing newHashMap()) i simply type “newH”, hit ctrl+space and MAGIC!

Go to Window – Preferences in Eclipse. Go to Java -> Editor -> Templates and hit “New”.
The Name will be your shortcut, I usually name mine the method, i.e. “newHashMap” in this case.
Add your description if you like, for instance “Import static Maps.newHashMap”
And add the following Pattern:
${:importStatic(com.google.common.collect.Maps.newHashMap)}newHashMap();${cursor}
And that’s all there is to it! Now go crazy and add templates for all those method that you use alot!

Guava at a (very quick) glance
Last but not least, let me show you how you can use Guava to deal with the two remaining question I opened this blog post with:
Read lines from a file:

File file = new File(getClass().getResource("/test.txt").getFile());
List<String> lines = null;
try {
lines = Files.readLines(file, Charsets.UTF_8);
} catch (IOException e) {
e.printStackTrace();
}

Compare two primitives?

 int compare = Ints.compare(a, b);

Convert a list of Integers to an array of primitive ints?

List<Integer> list = listOf(1, 2, 3, 4);
int[] array2 = Ints.toArray(list);

Guava provides us with a comprehensive extension to the Core Java Libraries. Among other things we gain access to utilities for working with primitives through the Ints, Doubles, Floats, Shorts, Bytes and Bools classes in the com.google.common.primitives package. The com.google.common.io package provides utilities for working with streams, buffers, files etc, and the concurrent package provides classes like Futures, Callables and Executors to ease the pain of writing concurrent code. In addition to all of this, Guava also provides us with some additions to Collections and a really neat CharMatcher class, Joiner and Splitter classes that I will cover next time!

Check out the source code here:
svn checkout http://guava-libraries.googlecode.com/svn/trunk/guava-libraries-read-only

Next time we’ll take a deeper dive into Guava and also some of the more advanced stuff in Google Collections like how we can make Java just a tiny bit more “functional”, the über collection “Multimap” and how we can use mapping functions to transform collections. Stay tuned, and please share your comments on this with us! Have you tried Guava or Google Collections? What are your thoughts?