Hacking on GraphHopper - a Java road routing engine. Peter has posted 62 posts at DZone. You can read more from them at their website. View Full User Profile

Java collections – Are There Alternatives?

09.04.2009
| 14313 views |
  • submit to reddit

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, which seem 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!).

 

From http://karussell.wordpress.com 

Published at DZone with permission of its author, Peter Karussell.

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)

Tags:

Comments

Thomas Mueller replied on Fri, 2009/09/04 - 2:45am

Databases: Do you know H2 and HSQLDB? I wouldn't call Apache Derby a 'lightweight' database - it's the biggest, most heavyweight and slowest open source Java database around. Sorry, as the author of H2 I had to say that :-) I can't speak about Neodatis, but it seems to be closed source.

Ricky Clarkson replied on Fri, 2009/09/04 - 4:46am

Also see Functional Java - http://code.google.com/p/functionaljava/

Mario Fusco replied on Fri, 2009/09/04 - 7:24am

 The way how you manipulate your collections is at least as important as the collection framework you use. If you could be intersted in use them in a DSL-style also check lambdaj

http://code.google.com/p/lambdaj/

Arek Stryjski replied on Fri, 2009/09/04 - 7:47am

I don't know about all of the projects you mentioned, but for sure Google Collections and Apache Commons Collections are not Java Collections alternatives but extensions.
They test some new solutions, which if proven useful to many users, maybe will go to standard Java Collections one day.

Could you explain why you consider database as an alternative to any Java API?
To me databases, distributed storage systems and Collections are different technologies, used in different situations.
They are not alternatives like Vector vs List (eg. Java 1 Collections vs Java 2 Collections or any Collections we will get in Java 7 or 27).

Jean-Philippe Toupin replied on Fri, 2009/09/04 - 8:20am

Neodatis is released under the LGPL.

Peter Karussell replied on Fri, 2009/09/04 - 10:18am in response to: Thomas Mueller

> Databases: Do you know H2 and HSQLDB? 

yes of course! I really like them, but all knows them already :-)

> I can't speak about Neodatis, but it seems to be closed source. 

its open source, sorry. I meantioned it because you can use it without JPA/Hibernate or jdbc - its an odb...

 

Peter Karussell replied on Fri, 2009/09/04 - 10:30am

> but for sure Google Collections and Apache Commons Collections are not Java Collections alternatives but extensions. 

You are right, but e.g. google's collections provide helper classes and high performance alternatives to e.g. Collections.unmodifiableCollection()

 

> They are not alternatives like Vector vs List 

Of course collections and databases are different. But with databases you can get/put objects like with collections (The important difference is the access time. I mean if O(1), O(log n) or O(n) or whatever). And if you use databases in-memory they could theoretically perform equally. So they should be considered as alternatives under certain circumstances. Only praxis could show you the right one.

Another usecase for database could be if you want to calculate sth. and you cannot hold all the necessary objects in memory at the same time ... so why not?

 

Peter Karussell replied on Fri, 2009/09/04 - 10:32am

Forgot the mention: see the original post for some further comments.

Laurent Lolo replied on Fri, 2009/09/04 - 5:06pm

NeoDatis is a LGPL ODB and can be used in a proprietary software. I used it from 3 months and i loved it. For small persistence usage, it is far more productive as JPA. For big databases, it is too young ... Db4o seems more mature but it is GPL licensed or proprietary licensed.
For collections, Google collections library have a very good immutable implementation collections and i love them. Immutable collections are default choice in Scala because of concurrency problems.

Andy Leung replied on Fri, 2009/09/04 - 5:18pm

> They are not alternatives like Vector vs List Of course collections and databases are different. But with databases you can get/put objects like with collections (The important difference is the access time. I mean if O(1), O(log n) or O(n) or whatever). And if you use databases in-memory they could theoretically perform equally. So they should be considered as alternatives under certain circumstances. Only praxis could show you the right one. Another usecase for database could be if you want to calculate sth. and you cannot hold all the necessary objects in memory at the same time ... so why not?
Peter, I have no idea why do developers want to use an in-memory database where you can simply use collections where these collections are also in-memory. The overhead of an in-memory database is lightweight but it is still an overhead. Plus I really don't see the reason of having in-memory database when you calculate things using collections. Shred some light on this one, the reason you mentioned may be reasonable but not convincing in the way you express it.

Lin QY replied on Sat, 2009/09/05 - 12:11am

thank you for nike air max 90

Toni Epple replied on Sat, 2009/09/05 - 2:01am

Good idea to post an overview:

Trove is one of my favorites. Their collections for primitives are great for tuning memory usage of an application. You can get amazing improvements by drop-in replacements

 --Toni

Peter Karussell replied on Sat, 2009/09/05 - 5:24am

> Plus I really don't see the reason of having in-memory database when you calculate things using collections  

Hmmh, I think you are right. But wait: one advantage of this could be that you could switch to a lower-memory pc and simply switch from in-memory to real database in a matter of milliseconds. That means you could deploy your application (which uses either in-memory or persistent-db) to any computer without any limitations for the RAM. The program itself could then detect which mode it will use ...

> Good idea to post an overview

Thanks Toni! Exactly this was my intention: list some libraries and learn others favourites :-)

Artur Biesiadowski replied on Sat, 2009/09/05 - 8:31am in response to: Andy Leung

<cite>I have no idea why do developers want to use an in-memory database where you can simply use collections where these collections are also in-memory.</cite>

Transparency for moving from external database or to external database is one reason, but for strictly technical one, I would think about indexes.

Sometimes, you may want to cache a lot of data in memory and query it in non-trivial way.  You can try having multiple maps with various keys, but it becomes a lot of pain to manage - and if you want to cover most cases, you will end up reimplementing database. Stuff like 'give me all objects with more than xyz higher than 100 having red color' is non-trivial in-memory if you want to avoid full scan.

If we are around in-memory databases, I would like to throw gigaspaces into the pool - have a lot of benefits over pure in-memory collections and local/remote database, as long as you don't want to move too much logic to your database layer.

Andy Leung replied on Sat, 2009/09/05 - 10:10am in response to: Artur Biesiadowski

Transparency for moving from external database or to external database is one reason, but for strictly technical one, I would think about indexes.
Nice one Artur. I do have another thought though. Talking about transparency, if this is for purely developing business logic, abstracting the DAO using collection as implementation works well. If this is for transition purpose of coding the entire app so eventually pull the trigger at Datasource to use external DB from using in-memory, I agree but then another question raised up in my head: Why don't I start with external DB in the first place for this purpose? Don't get me wrong, it's always nice to see some professionals who posts articles on dzone and then we can have interesting discussions around it. However, I just can't see the point of having that in-memory work as alternative of collections. However, I have another thought of practically using in-memory database. Let's say I have to code a portlet that contains DB code. On my development machine I will use in-memory, easy to refresh and easy to load. As long as I have enough memory for it, I save times on refreshing and connectivity configurations and all other matters. This is for the purpose of SDLC phases transitions. Just my 2 cents. :)

Alex(JAlexoid) ... replied on Sat, 2009/09/05 - 2:40pm

Amino Concurrent Building Blocksis a very nice library forsome concurrent utilities. Designed to have hinger performance than java.util.concurrent

http://amino-cbbs.sourceforge.net/

 

Tim Boudreau replied on Sat, 2009/09/05 - 3:22pm

I've certainly found it useful on a few occasions to hand-write collections-like classes for primitives (particularly if you're indexing a data structure that only grows at its tail, there are lots of very nice optimizations you can do since you can guarantee the data to be pre-sorted).

Never really thought of collections and a database as interchangeable - doesn't seem like there are a lot of problems where you don't know which one is the right tool for the job before you start coding. 

For large but fixed-record-size data structures, memory mapped files work quite well to keep data off the Java heap but generally quickly accessible.

Alex(JAlexoid) ... replied on Sat, 2009/09/05 - 4:22pm in response to: Andy Leung

In memory databases are ideal for testing purposes and temporary data.

Some temporary data is so sensitive, that you are not allowed to store it for more than a predefined amount of time. And traditional databases usualy have this thing called transaction log, where transaction data is stored and is not removed by DELETE - that is a big "No,no".

There is a need for them, otherwise they would just die out.

Peter Karussell replied on Sun, 2009/09/06 - 6:38am

Thanks for this. I'll add this to the list ... 

http://amino-cbbs.sourceforge.net/

 

Tracy Nelson replied on Fri, 2009/09/11 - 8:16am

Back In The Day (pre-Java 2), we used something called the JGL collection library.  It was (allegedly) modeled after the C++ STL, and provided some pretty nice collection classes.  I heard that it was offered to Sun to be made part of the Java standard, but they decided to write their own.  JGL is currently owned/maintained by a company known as ObjectSpace.  I believe the JGL classes are free-as-in-beer, but not (currently) open source, if that's important to you.

 There's a quick overview at http://www4.ncsu.edu/~kaltofen/courses/Languages/JavaExamples/jgl3.1.0/doc/user/Overview.html.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.