Develop Reference

Mechanism of Java HashMap

Reading Algorithms book, need to grasp the concept of a hashtable. They write about hashing with separate chaining and hashing with linear probing. I guess Java's HashMap is a hashtable, therefore I'm wondering what mechanism does HashMap use (chaining or probing)?
I need to implement simplest HashMap with get, put, remove. Could you point me at the good material to read that?
When the unique keys used for the Map are custom objects, we need to implement hashCode() function inside the corresponding type. Did I get it right or when is hashCode() needed?
Unfortunately the book does not answer all questions, even though I understand that for many of you these questions are low level.

1: before java 1.8 HashMap uses separate chaining with linked lists to resolve collisions. There is a linked list for every bucket.
2: hmmmmmm maybe this one?
3: yes, you are right, hashCode() is used to calculate the hash of the Key. Then the hash code will be transformed to a number between 0 and number of buckets - 1.

This is a Most Confusing Question for many of us in Interviews.But its not that complex.
We know
HashMap stores key-value pair in Map.Entry (we all know)
HashMap works on hashing algorithm and uses hashCode() and equals() method in put() and get() methods. (even we know this)
When we call put method by passing key-value pair, HashMap uses Key **hashCode()** with hashing to **find out the index** to store the key-value pair. (this is important)
The Entry is **stored in the LinkedList**, so if there are already existing entry, it uses **equals() method to check if the passed key already exists** (even this is important)
if yes it overwrites the value else it creates a new entry and store this key-value Entry.
When we call get method by passing Key, again it uses the hashCode() to find the index in the array and then use equals() method to find the correct Entry and return it’s value. (now this is obvious)
THIS IMAGE WILL HELP YOU UNDERSTAND:

HashMap works on the principle of Hashing. Its working is two fold.
First, it maintains a Linked List to store objects of similar values, that means ones which are "equal".
Second it has a collection of these linked list whose headers are present in a array.
For more information refer blog Java Collection Internal Working

Are there any map implementations in Java that will give me a map where the entries are ordered in the same way I put them in?

What I would like to do is this:
for (Entry<Foo, Foo> myEntry : myMap.entryList())
{
if (someCondition(myEntry.getKey()))
{
doSomething(myEntry.getValue())
}
}
The order is important because myEntry.getValue() will point to a key that will be reached later on. Is there a Map implementation that guarantees the order of the entries and allows me to iterate over the entries in that order? I found SortedMap, but it looks like SortedMaps sort the keys. This isn't quite what I need. I simply want to get my entries out of my map in the same order that I put them in.
For those wondering what I'm trying to do, myMap represents a hierarchy of Foo objects. When the condition is met in 'someCondition', I mark the parent of the Foo (which happens to be the value of the entry). Later on when the parent becomes a key, I'll know that I've marked it before and will take action accordingly. Right now I've created a recursive 'markParent' call, but if I could iterate over the map in a known order, I wouldn't need to do that.

You mean like LinkedHashMap? ;-)
Hash table and linked list implementation of the Map interface, with predictable iteration order. This implementation differs from HashMap in that it maintains a doubly-linked list running through all of its entries. This linked list defines the iteration ordering, which is normally the order in which keys were inserted into the map (insertion-order). Note that insertion order is not affected if a key is re-inserted into the map. (A key k is reinserted into a map m if m.put(k, v) is invoked when m.containsKey(k) would return true immediately prior to the invocation.)
(My emphasis)
FWIW, how I got there, to help if you need to find similar information in the future: I had a vague recollection one of the JDK classes did that, so went to Map and read through the list of "Known Implementing Classes." In this case, I knew the name when I saw it, but I figure even if I hadn't known it, LinkedHashMap suggests order, so... :-)

LinkedHashMap will maintain the order of insertion which using LinkedList internally. And if you want to define any custom order, you can use SortedMap like TreeMap instead.

java constantly sorted list with quick retrieval

I'm looking for a constantly sorted list in java, which can also be used to retrieve an object very quickly. PriorityQueue works great for the "constantly sorted" requirement, and HashMap works great for the fast retrieval by key, but I need both in the same list. At one point I had wrote my own, but it does not implement the collections interfaces (so can't be used as a drop-in replacement for a java.util.List etc), and I'd rather stick to standard java classes if possible.
Is there such a list out there? Right now I'm using 2 lists, a priority queue and a hashmap, both contain the same objects. I use the priority queue to traverse the first part of the list in sorted order, the hashmap for fast retrieval by key (I need to do both operations interchangeably), but I'm hoping for a more elegant solution...
Edit: I should add that I need to have the list sorted by a different comparator then what is used for retrieval by key; the list is sorted by a long value, the key retrieval is a String.

Since you're already using HashMap, that implies that you have unique keys. Assuming that you want to order by those keys, TreeMap is your answer.

It sounds like what you're talking about is a collection with an automatically-maintained index.
Try looking at GlazedLists which use "list pipelines" to efficiently propagate changes -- their SortedList class should do the job.
edit: missed your retrieval-by-key requirement. That can be accomplished with GlazedLists.syncEventListToMap and GlazedLists.syncEventListToMultimap -- syncEventListToMap works if there are no duplicate keys, and syncEventListToMultimap works if there are duplicate keys. The nice part about this approach is that you can create multiple maps based on different indices.
If you want to use TreeMaps for indices -- which may give you better performance -- you need to keep your TreeMaps privately encapsulated within a custom class of your choosing, that exposes the interfaces/methods you want, and create accessors/mutators for that class to keep the indices in sync with the collection. Be sure to deal with concurrency issues (via synchronized methods or locks or whatever) if you access the collection from multiple threads.
edit: finally, if fast traversal of the items in sorted order is important, consider using ConcurrentSkipListMap instead of TreeMap -- not for its concurrency, but for its fast traversal. Skip lists are linked lists with multiple levels of linkage, one that traverses all items, the next that traverses every K items on average (for a given constant K), the next that traverses every K2 items on average, etc.

TreeMap
http://download.oracle.com/javase/6/docs/api/java/util/TreeMap.html

Go with a TreeSet.
A NavigableSet implementation based on a TreeMap. The elements are ordered using their natural ordering, or by a Comparator provided at set creation time, depending on which constructor is used.
This implementation provides guaranteed log(n) time cost for the basic operations (add, remove and contains).

I haven't tested this so I might be wrong, so consider this just an attempt.
Use TreeMap, wrap the key of this map as an object which has two attributes (the string which you use as the key in hashmap and the long which you use to maintain the sort order in PriorityQueue). Now for this object, override the equals and hashcode method using the string. Implement the comparable interface using the long.

Why don't you encapsulate your solution to a class that implements Collection or Map?
This way you could simply delegate the retrieval methods to the faster/better suiting collection. Just make sure that calls to write-methods (add/remove/put) will be forwarded to both collections. Remember indirect accesses, like iterator.remove(). Most of these methods are optional to implement, but you have to deactivate them (Collections.unmodifiableXXX will help here in most cases).

Which of Java's hash structures supports 'linear chaining'?

For homework, I have to implement a variety of hash functions in C++ or Java. I'm comfortable working with Java, but haven't used its hash functionality.
I want a hash structure that links colliding keys. Like this:
Is LinkedHashMap the correct choice here? Is it HashMap? Either? Why?

Well, just a regular HashMap links entries that end up in the same bucket (each bucket is really an element in an array of linked lists). A LinkedHashMap also maintains links between entries to preserve the insertion order, but that's not what's happening in your diagram.

HashMap does this.
What LinkedHashMap does is linking the keys in insertion order.

I think the standard HashMap already works this way: it has a number of bins, and elements with colliding hash codes end up in the same bin. You can lookup the source code of HashMap yourself: in your JDK installation directory there is a file src.zip that contains the source code.
LinkedHashMap is just a HashMap combined with a List to keep track of the insertion order of elements in the map. The word "linked" in its name doesn't have anything in particular to do with how elements in one bin are stored.

You may use HashMap
Map<String,ArrayList<Object>> map = new HashMap<String,ArrayList<Object>>();
Instead of object specify the type you need.
The HashMap grants fast random access.
Also there are :
TreeMap - data sorted by key.
LinkedHashMap - data stored in order it is entered to the container.

LinkedHashMap is for creating a iteratable map that with predictable order of the keys. Internally, a HashHap is free to use whatever means it deems fit to handle key collision which may or may not be a linked list. I don't think there is any standard guarantee that the underlaying mechanism for collision buckets to use a linked list in Java but in practice they may.

How does Java order items in a HashMap or a HashTable?

I was wondering how Java orders items in the Map (HashMap or Hashtable) when they are added. Are the keys ordered by the hashcode, memory reference or by allocation precedence...?
It's because I've noticed same pairs in the Map are not always in the same order

java.util.HashMap is unordered; you can't and shouldn't assume anything beyond that.
This class makes no guarantees as to the order of the map; in particular, it does not guarantee that the order will remain constant over time.
java.util.LinkedHashMap uses insertion-order.
This implementation differs from HashMap in that it maintains a doubly-linked list running through all of its entries. This linked list defines the iteration ordering, which is normally the order in which keys were inserted into the map (insertion-order).
java.util.TreeMap, a SortedMap, uses either natural or custom ordering of the keys.
The map is sorted according to the natural ordering of its keys, or by a Comparator provided at map creation time, depending on which constructor is used.

First of all: HashMap specifically doesn't provide a stable and/or defined ordering. So anything you observe is simply an implementation detail and you must not depend on it in any way.
Since it is sometimes useful to know the reason for the seemingly random ordering, here's the basic idea:
A HashMap has number of buckets (implemented as an array) in which to store entries.
When an item is added to the map, it is assigned to a buckets based on a value derived of its hashCode and the bucket size of the HashMap. (Note that it's possible that the bucket is already occupied, which is called a collision. That's handled gracefully and correctly, but I'll ignore that handling for the description because it doesn't change the concept).
The perceived ordering of the entires (such as returned by iterating over the Map) depends on the order of the entries in those buckets.
Whenever the size is rehashed (because the map exceeded its fullness threshold), then the number of buckets changes, which means that the position of each element might change, since the bucket position is derived from the number of buckets as well.

HashMap does not sort at all. For a map that sorts by key values you should use TreeMap instead.
From the JavaDocs for TreeMap:
Red-Black tree based implementation of
the SortedMap interface. This class
guarantees that the map will be in
ascending key order, sorted according
to the natural order for the key's
class (see Comparable), or by the
comparator provided at creation time,
depending on which constructor is
used.
From the documentation of HashMap:
This class makes no guarantees as to
the order of the map; in particular,
it does not guarantee that the order
will remain constant over time.

A Map is not an ordered data structure - you should not rely on entries in a HashMap being in a certain order. Some Map implementations such as LinkedHashMap and TreeMap do guarantee a certain order, but HashMap does not.
If you really want to know what happens internally, lookup the source code of HashMap - you can find it in src.zip which should be in your JDK installation directory.
A HashMap has a number of "buckets" in which it stores its entries. Which bucket an entry is stored in is determined by the hash code of the key of the entry. The order in which you see the entries in the HashMap depends on the hash codes of the keys. But don't write programs that rely on entries being in a certain order in a HashMap - the implementation might change in a future version of Java and your program then would not work anymore.

hashmap has a not defined order of the elements

There is no defined ordering in a hash table. Keys are placed into a slot, based on the hash code, but even that isn't a trivial order-by-hash-code.

HashMap stores the values using the unique hash-value generated using a part of the key. This hash-value maps to the address where it is going to be stored. This is how it ensures an access O(1).
LinkedHashmap on the other hand preserves the order in which you added to the map.