Java collections – Are there alternatives?

Posted on by

The built-in collections for Java have good performance and are nice to use – especially with the new for-loop pattern.

But are there alternatives? And if so, why should I use them? (Please use the comment functionality ;-))

The following collection implementations I found on the web:

There are also some older projects, where the development seems to be abandoned:

If you need real big data in memory you should consider a lightweight database (or a real one??) like neodatis, derby or something really interesting: HBase from the hadoop project (Apache/Yahoo!).

Advertisement

10 thoughts on “Java collections – Are there alternatives?”

  1. As long as you’re happy, there’s no need to use anything else. The JDK’s collections framework has been optimized and it keeps improving from release to release. The idea behind GNU Trove was to provide optimized drop-in replacements for the standard collections classes. In my experience, starting from JDK-1.5, Trove is slower and it also lacks Generics support. But you should measure performance for yourself, maybe there are use cases where Trove is still faster.

    Then there’s a number of data structures that the JDK doesn’t offer, for example MultiMap/Bag data structures. Google Collections and Commons Collections offer quite a few additional data structures.

    Commons collections don’t support Generics and sometimes they violate the JDK’s interface contracts. That’s a no-go for me.

    Google Collections are high-quality and intended to complement the JDK’s collection classes. They always follow the JDK interface contract. You can safely use them if the JDK doesn’t offer what you need.

    I don’t know about the other ones. In general, I don’t trust them because it’s unlikely that they went through the same QA process that the JDK classes did.

    • Thanks for sharing!

      2 minutes ago I replaced all HashMap’s and LinkedHashMap’s in my TimeFinder application with FastMap (javolution) and it is faster šŸ™‚

      I had 16 samples for the complex algorithm: sometimes the improvement is only a bit but the most times it is a lot … nice … without any effort

  2. Did you try ConcurrentHashMap from the JDK yet? I know it’s counter-intuitive, but I heard that it performs better in some cases than HashMap.

    In case you test it, please let me know how it turns out šŸ™‚

  3. Thanks for the hint. And indeed the ConcurrentHashMap is often faster than the HashMap, but in my case it was not faster than FastMap. But please always test for yourself šŸ™‚
    The algorithm uses more often Map.get() than e.g. put() in the critical places …

    Unless I won’t detect performance problems I will choose FastMap, because to test performance the predictability of iteration is very important. HashMap iterates “non-deterministic” – I.e. if you put some keys A,B,C the iteration over the elements will depend on execution (randomly!) and not on insertation order like it is the case for FastMap.

  4. I wouldn’t say that fastutil is abandoned. It’s just that it’s ‘finished’. I’ve been using it for seven? years already and I have to say that it’s the most bug free library that I’ve used.

    I’m using fastutil classes as a basis for custom object cache. They are both faster and less memory hogs than the built in collections in jdk.

    P.S.
    I’m pretty sure that the fastutil library gets updated as soon as generics move to the next level (if they ever do).

Comments are closed.