Why the hashtable.hashCode() returns negative numbers

[ben josh]

Hello all
Im trying to construct hashtable that contains hashtables as values and hashCode of the hash tables as the keys
The thing is that the hashCode() values are always negative numbers and they are not unique even so the values of the hashtable
Different. how can it be ? Doesn�t it suppose to be unique number? And not negative?

[Peter Chase]

No, wrong on both counts.

A hash code can be any value that will fit in an "int". That includes negative numbers.

There is no guarantee that different objects will have different hash codes. The guarantee is that equal objects will have equal hash codes. It is in fact legal (but inadvisable) for a class to return the same hash code for all instances.

Basically, when implementing hashCode(), one first ensures that equal objects generate the same hash code, then tries to ensure that different objects produce a reasonable spread of hash codes. But one is constrained by a need for hashCode() to run quickly, so sometimes one compromises hashing quality for speed.

[ben josh]

So this leads me to the question how can I generate unique identifier to hashtable object
When its keys and values are fixed what I mean is when the hashtable have N keys and corresponding X values
The generated identifier will always be the same

[Ilja Preuss]

Originally posted by Meir Yan:
Im trying to construct hashtable that contains hashtables as values and hashCode of the hash tables as the keys

Why?

[ben josh]

i need unique key to the hashtable
can it be Produced from the hashtable itself based on its content?

[Rob Spoor]

Using hash codes for mutable objects, such as collections but also many user defined objects, is in most cases a BAAAAAD idea. If the object changes, its hash code may change, and as a result it will never be found again when retrieving it from a hash set. (The same goes for compareTo / comparators and tree sets - I've tried ).

Let's say you use the hash code as the key. Then you add something to the hash table. As a result, its hash code changes. You use that hash code, and you will not get the object you were looking for. The same holds for any other value you derive from the hash table's contents.

You need something that will never change within the lifetime of the hash table, and truth be told I couldn't think of any property it has. You might want to subclass the hash table, give it a read-only name field, then use that as the key, but I don't see any non-similar approach working.

[Paul Clapham]

And using a hashcode as a unique identifier is also a bad idea. It's true that two equal objects must have equal hashcodes, but it isn't true that two objects that are not equal must have different hashcodes. So there's no guarantee of uniqueness.

[Pat Farrell]

Originally posted by Meir Yan:
i need unique key to the hashtable

Do you need a unique for your object? or to use in a HashMap?

If you want a unique key, why not just use a Java GUID?
The HashMap/Table, etc. manages the values for you, I don't see why you would want to do it yourself.

[Ilja Preuss]

Originally posted by Meir Yan:
i need unique key to the hashtable

Why?

I'm wondering what you would use a Hashtable of Hashtables for, and whether there perhaps might be a better solution.

[Jesper de Jong]

Originally posted by Meir Yan:
i need unique key to the hashtable
can it be Produced from the hashtable itself based on its content?

So, you have a Hashtable and you want to compute a unique key based on the content of the Hashtable.

That is theoretically impossible if the unique key has less bits than the bits of the data in the Hashtable together. Here's the proof:

Suppose you want to make a key with 32 bits. Then there are 2^32 possible keys. Suppose that you have some data in your Hashtable, and that data takes up more than 32 bits - for example, you have three integers, which is 96 bits.

Now you can see that the data in the Hashtable can be in 2^96 different states, and you need a unique key for each state. But your key only has 32 bits, so you can't assign a unique key for each possible state. You would need a key of at least 96 bits (the size of the data itself), if you need a unique key for every possible state.

So if the object has N bits of data then you cannot compute a unique key that is less than N bits from the data itself.
[ September 05, 2007: Message edited by: Jesper Young ]

[Ilja Preuss]

Originally posted by Jesper Young:

So if the object has N bits of data then you cannot compute a unique key that is less than N bits from the data itself.

Unless you can find a way to represent the same data with less bits, of course.