Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

Is there an equivalent of boost::multi_index for Java someplace?

I stumbled upon multi_index on a lark last night while pounding my head against a collection that I need to access by 3 different key values, and also to have rebalancing array semantics. Well, I got one of my two wishes (3 different key values) in boost::multi_index.

Does anything similar exist in the Java world?

like image 430
Chris K Avatar asked Jun 18 '10 14:06

Chris K


3 Answers

I have just finished MultiIndexContainer in Java: http://code.google.com/p/multiindexcontainer/wiki/MainPage. I know that it is not complete equivalent of boost multi_index_container but maybe it could be sufficient for your requirement.

like image 108
Fekete Kamosh Avatar answered Nov 17 '22 07:11

Fekete Kamosh


Resurrecting an old question, but take a look at CQEngine as a solution.

For background also see related question How do you query object collections in Java (Criteria/SQL-like)?

like image 30
npgall Avatar answered Nov 17 '22 08:11

npgall


I think the short answer is no, there's no obvious equivalent.

The boost multi-index class is very heavily templated, which isn't easily translatable in Java. There are generics, but they're not at all the same. ( How are Java generics different from C++ templates? Why can't I use int as a parameter? ).

So without templating, what would the multi-index class look like?

I imagine you would have your data class, e.g. Person, containing index members like a Map implementation. At this point, you have a choices:

  1. Add some "indexes" directly to the Person class (like some Hashtables) and write lookup functions. Manage index synchronization within the Person class.
  2. Write an "IndexProvider" class that decouples the index functionality entirely from Person - it would have to be able to dynamically create different index types and I would imagine you would handle synchronization via callbacks.
  3. Some mix of 1) and 2) - like an abstract base class for index functionality, which doesn't properly decouple the behaviour but does provide some code reuse.

I think, in the majority of cases 1) is the easiest to write, easiest to maintain and is probably the most performant. 2) seems like over-engineering.

The other option, if you have a lot of data structures that need indexing, is to store them in a database.

like image 1
Tim Gee Avatar answered Nov 17 '22 09:11

Tim Gee