Integer/Object HashTable contribution, anyone?

[clebert.suconic]

I need a simple hashTable implementation, lightweight assigning integers and objects.

I need that to improve the logic of Handles (internal hashCodes) and Objects.

I guess I would be able to find how to implement one in a data structure book, but of course if someone has such structure ready to be contributed it would be a nice contribution.

[clebert.suconic]

Before someone ask me why I can't simply use HashMap? here is the answer.

I'm already using HashMap, and I'm looking for a way to decrease the number of temporary objects created during an object parsing.

Having such structure would help me doing that.

[starksm64]

This is why Bill using the trove stuff. See the gnu.trove.TIntIntHashMap etc classes to see if they will work. The jar is thirdparty/trove/lib/trove.jar

[strkrobertm]

I second the trove recommendation. The code in the trove project is very good.

[clebert.suconic]

It looks perfect.

I got a question about it though.

Our repository info points a 2.1.1 release:

http://repository.jboss.com/trove/2.1.1/component-info.xml


While trove just released 1.1b5:

http://trove4j.sourceforge.net



Am I missing something?

[ruel.loehr]

Looks like it's the wrong version number. I'll figure out which version it really is, fix it, and update the builds.

[clebert.suconic]

Just commited the code.

JBossSerialization now needs trove.jar.

If dependency is an issue, we could consider copying TIntObjectHashMap sourcecode into jbser sourcetree. (As it's a LGPL, if I only changed the package name, I don't think this would be an issue).

I have testcases working, but I will make some soakTests to make sure I'm not breaking anything.

Please, don't use jboss-serialization/HEAD unless you want to give a developer's input.

For now you can use CR5.

[starksm64]

I don't think the trove dependency is a big issue. We may want to roll into the jboss common util module when its broken out.