C# Hastable's equivalent in Java

[nithya4u]

Hi All,
Currently, am working on converting some part of C# code to JAVA. Am
having a problem with respect to the usage of Hashtable in C#. Is there

a java equivalent for it? I have searched lots and am not able to get a

solution.

In the C# code that am working on, there is an arraylist and they are
copying the values to a hashtable for easy retrieval purpose. After
making a copy, ironically, the order of values in both the arraylist
and the hastable are different.

I do not know based on which criterion this order is arrived at for
storage in hashtable. Does someone know what is criteria for this
sort...?? I have to follow the same for my Java conversion. The
Hashtable in java.util does not work the same as C#. I tried even with
TreeMap

 

[NullBock]

Hashtable in C#. Is there

a java equivalent for it? I have searched lots
and am not able to get a solution.

java.util.Hashtable??? Or better, java.util.HashMap

I do not know based on which criterion this order
is arrived at for storage in hashtable.

It's effectively random. It's based on the "hash" of the item to be
stored, which is a number derived by passing the stored item through an
algorithm, such that equivalent items produce the same number. Thus,

IF item_one EQUALS item_two
THEN item_one:hash EQUALS item_two:hash

This number is then used to quickly find a cell in a table where the
value associated with the item is stored. This is normally done by
computing the remainder of the hash number divided by the size of the
table.

And that last bit explains why the order of a hash table is normally
unpredictable. If you keep adding items to a hash table it'll grow,
which means that the index of a particular item stored in the table
changes. For example, say you want to store the string "I'm a bitty
kitty cat" in a hash table, and this string has a hash of 112358. When
you store the string in the table, the table has 53 cells, meaning that
the string would be stored at location 51 (112358 % 53 == 51). After
adding a few more values to the table, it grows to 97 cells. Now the
string is stored at location 32 (112358 % 97 == 32).

There *are* tables where you can predict the order. For instance,
LinkedHashMap maintains the order in which items are added, regardless
of how often the table grows. And TreeMap stores items in their sorted
(natural) order--1 is stored before 10, "cat" is stored before "dog,"
and so on.

Not knowing what types of values you're storing, I can't give you more
exact advice. Check out TreeMap and LinkedHashMap, though, and see if
they work for you.

Walter
----
Walter Gildersleeve
Freiburg, Germany

______________________________________________________
http://linkfrog.net
URL Shortening
Free and easy, small and green.

 

[Thomas Weidenfeller]

Hi All,
Currently, am working on converting some part of C# code to JAVA. Am
having a problem with respect to the usage of Hashtable in C#. Is there
a java equivalent for it?

Hashtable or better HashMap.

I have searched lots and am not able to get a
solution.

I don't know where you searched, but if you didn't find this, you should
work on your searching skills.

In the C# code that am working on, there is an arraylist and they are
copying the values to a hashtable for easy retrieval purpose. After
making a copy, ironically, the order of values in both the arraylist
and the hastable are different.

It is not ironically. A hashtable uses hashes. If you don't know how
this works, look it up. E.g. here:
http://en.wikipedia.org/wiki/Hashtable This is basic programming knowledge.

I do not know based on which criterion this order is arrived at for
storage in hashtable.

It is based on the hashes of the keys and the algorithm used to
implement the table.

Does someone know what is criteria for this
sort...??

It is not a sort at all. The keys are converted to hashes. A process
which in Java depends on the key object itself, plus (since something
like Java 1.5) also on the HashMap implementation. The goal is to
distribute the keys of an infinite domain as good as possible over a
finite range. Since there is no ideal hash function, people use all
sorts of different one.

I have to follow the same for my Java conversion. The
Hashtable in java.util does not work the same as C#.

They work very well. You just assume hashtables have a property which
they don't. If you want to get the exact same C# hashtable behavior, you
need to find out which hash functions are used there, and which
algorithm is used for the table, and reimplement a hashtable from
scratch. In theory, because if the original code really depends on the
internal order of a hashtable, it is badly broken and should be fixed
first. There is not much point in re-creating this design error in some
other language.

/Thomas

 

[bugbear]

It is not a sort at all. The keys are converted to hashes. A process
which in Java depends on the key object itself, plus (since something
like Java 1.5) also on the HashMap implementation. The goal is to
distribute the keys of an infinite domain as good as possible over a
finite range. Since there is no ideal hash function, people use all
sorts of different one.



They work very well. You just assume hashtables have a property which
they don't. If you want to get the exact same C# hashtable behavior, you
need to find out which hash functions are used there, and which
algorithm is used for the table, and reimplement a hashtable from
scratch. In theory, because if the original code really depends on the
internal order of a hashtable, it is badly broken and should be fixed
first. There is not much point in re-creating this design error in some
other language.

If the ordering *is* essential, org.apache.commons.collections.OrderedMap
uses extra resources to maintain items in insertion order.

To agree (strongly) with Thomas, this does not "fix a bug"
in HashMap, it adds *extra* functionality.

BugBear

 

[Daniel Dyer]

If the ordering *is* essential, org.apache.commons.collections.OrderedMap
uses extra resources to maintain items in insertion order.

Is there a reason to use this in preference to java.util.LinkedHashMap?

Dan.

 

[Chris Uppal]

a java equivalent for it? I have searched lots and am not able to get a
solution.

I think that you should spend some time reading the Java collections tutorial:

http://java.sun.com/docs/books/tutorial/collections/index.html

And then get used to reading the JavaDocs for the java.util package.

In the C# code that am working on, there is an arraylist and they are
copying the values to a hashtable for easy retrieval purpose. After
making a copy, ironically, the order of values in both the arraylist
and the hastable are different.

Yes, naturally. That's how hashtables work.

I do not know based on which criterion this order is arrived at for
storage in hashtable. Does someone know what is criteria for this
sort...?? I have to follow the same for my Java conversion. The
Hashtable in java.util does not work the same as C#. I tried even with
TreeMap

If the C# code expects a specific order of elements once they have been added
to the hashtable, then that code is /Very Seriously/ broken, and your only
option is to work out what the C# code /should/ have been doing and then
reproduce that in Java. You can't translate nonsense C# code into Java, any
more than you can translate "snc maszsa ifhusdkv cdd" into Japanese.

The whole point of a hashtable is that you don't /care/ what order the elements
are in, and because of that the implementation can play some "tricks" to allow
very fast access. If you do care about the order then a hashtable is the wrong
datastructure to use (though you might use a hybrid such as a
java.util.LinkedHashMap).

-- chris

 

[Roedy Green]

Currently, am working on converting some part of C# code to JAVA. Am
having a problem with respect to the usage of Hashtable in C#. Is there

see http://mindprod.com/jgloss/hashmap.html

 

[Oliver Wong]

Thomas Weidenfeller wrote: [...]

They work very well. You just assume hashtables have a property which
they don't. If you want to get the exact same C# hashtable behavior, you
need to find out which hash functions are used there, and which algorithm
is used for the table, and reimplement a hashtable from scratch. In
theory, because if the original code really depends on the internal order
of a hashtable, it is badly broken and should be fixed first. There is
not much point in re-creating this design error in some other language.

If the ordering *is* essential, org.apache.commons.collections.OrderedMap
uses extra resources to maintain items in insertion order.

To agree (strongly) with Thomas, this does not "fix a bug"
in HashMap, it adds *extra* functionality.

The OP wrote:

<quote>
In the C# code that am working on, there is an arraylist and they are
copying the values to a hashtable for easy retrieval purpose. After
making a copy, ironically, the order of values in both the arraylist
and the hastable are different.
</quote>

So if maintaining the exact same behaviour as in C# is required, simply
maintaining items in insertion order will not do it.

- Oliver