We Keep Coding

java: difference between map and hash table

I don't understand this code Map<E, Integer> d = new HashTable<E, Integer>(list.size()); : we create a new object but is it a map or a hashtable? what is the difference between the both of them? I thought that a map is just a way to put 2 element together like a key and its value (for exemple {3; Detroit})

is it a map or a hashtable?
Yes.
The static, compile time type of the reference is Map. As others have already pointed out, it's an interface. You can call all the methods on the Map interface and know that they'll obey the contract and behave as describe.
The dynamic, run time type of the object reference refers to is Hashtable. It implements all the methods in the Map interface in its own way.
The key idea is that the compile time type of a reference is separate from the run time type of the object on the heap that it points to.
Hashtable is a JDK 1.0 class that sticks around for compatibility reasons. It's been retrofitted to implement the Map interface, which was introduced later. You'd be well advised to choose another implementation, such as HashMap, depending on your requirements.
The last part of Hashtable contains the reason why it should not be used:
As of the Java 2 platform v1.2, this class was retrofitted to implement the Map interface, making it a member of the Java Collections Framework. Unlike the new collection implementations, Hashtable is synchronized. If a thread-safe implementation is not needed, it is recommended to use HashMap in place of Hashtable. If a thread-safe highly-concurrent implementation is desired, then it is recommended to use ConcurrentHashMap in place of Hashtable.
This means that it is less efficient than HashMap for single-thread models and less efficient than ConcurrentHashMap for multi-threaded models.
Understanding how compile and run time types differ is crucial to understanding how object oriented polymorphism works. This is true for all OO languages: C++, Java, .NET, Python, etc.

Map is an interface. Hashtable is one of the classes that implements the Map interface.
See the Java Doc for the Map interface. Specifically the section that says all known implementing classes.
Any class that implements a Map provides a key->value data-structure. A Map being an interface defines the contract that all implementing classes must adhere to. By itself, a Map cannot be instantiated.
Note that while Hashtable should ideally have been named as HashTable following the java naming conventions, this is is a pre-historic class in Java which exists even before the standard java naming conventions came into existence. Therefore, it is still called Hashtable and not HashTable as wrongly mentioned in your question.

Map is an interface. HashTable is one implementation of that interface. There are several others, such as HashMap, SortedMap, etc. The interface defines the programming API; the implementation defines how that API is implemented. Different implementations may have different runtime performance characteristics.
With regard to interfaces vs. implementations, you may find my answer to Java - HashMap vs Map objects here helpful.

Where can I find a documentation Vector and Hashtable in Java?

I know this question can be a little stupid but I just want to clear the doubt.
When going through Java tutorial for Collection ( http://docs.oracle.com/javase/tutorial/collections/index.html ), I didn't find any relevant information about both Vector and Hashtable. Both belong to Collection framework as Vector is implementation of List and Hashtable is implementation of Map. If it is so then why it is not in Sun tutorial? Where can I find Sun tutorial for Collection which contain good doc about both Vector and Hashtable and in depth knowledge about elements storing in List, Set and Map?

Because Vector and Hashtable are old, legacy collection classes. Don't use them.
Instead of Vector use ArrayList; instead of Hashtable use HashMap.
When Java 1.2 was released (very long ago), new collection classes were added to Java (the Collections Framework). Sun did not remove the old classes such as Vector and Hashtable because they wanted the new Java version to be backwards compatible. And now we still have those old classes.
One difference to be aware of is that Vector and Hashtable are synchronized, while ArrayList and HashMap are not. Most of the time you don't need synchronization; if you do, then you must take care to synchronize your ArrayList, and if you need a map, use ConcurrentHashMap instead of plain HashMap.

In general, Vector and Hashtable could be considered deprecated.
If you look at the online javadoc for Vector and Hashtable you'll see that they were the original implementation of ArrayList and HashMap, until the Collections framework came along, at which point they were retrofitted to implement interfaces from the Collections framework; this way, old classes that depended on those classes being there would not break. The only difference between them and their more common brethren is that they are synchronized.
In the vast majority of cases, synchronization isn't called for, so programmers will avoid the synchronization overhead and opt for regular ArrayLists and HashMaps. If a synchronized collection is desired there's always Collections.synchronized____() (or ConcurrentHashMap) that would work just fine too.
You probably don't need a tutorial for Vector and Hashtable because their behavior is already so similar to classes you're likely to be familiar with, and because they aren't used much any more. As for more info on List, Set, and Map, the online javadoc is a good place to start.

here are useful links for you
http://javarevisited.blogspot.com/2010/10/difference-between-hashmap-and.html
http://javarevisited.blogspot.com/2011/09/difference-vector-vs-arraylist-in-java.html

As mentioned by the JavaDoc of Vector:
As of the Java 2 platform v1.2, this class was retrofitted to implement the List interface, making it a member of the Java Collections Framework. Unlike the new collection implementations, Vector is synchronized. If a thread-safe implementation is not needed, it is recommended to use ArrayList in place of Vector.
it is kind of a legacy implementation of the List interface. The whole collection framework has been implemented to be by default not thread-safe. If you need thread safety, you may wrap any non tread-safe implementation by using the proper Collections.synchronizedXXX() methods, where XXX is List or Map or Set for example. The same applies for HashTable, which is by default synchronized as well. You should use HashMap instead and Collections.synchonizedMap() instead.

What will store a Key-Value list in Java or an alternate of C# IDictionary in Java?

I am new to java development, I am from C# .net, developing android application.
I am looking for Key-Value list to use in Java same as IDictionary in C#.
Thanks

Use the Map<K, V> interface, and the HashMap<K, V> class for example. Or see the "All Known Subinterfaces" section in the Map<K, V> interface description for more implementations.
http://download.oracle.com/javase/6/docs/api/java/util/Map.html

Java has Hashtable and HashMap
See Differences between HashMap and Hashtable?

The interface you are looking for is Map<K, V>.
For an implementation similar to C#'s Dictionary try HashMap<K, V>

I've usually preferred java.util.TreeMap to a HashMap. It's not quite as fast, but you don't have to worry about hashing algorithms or setting the size. More important, it's memory-friendly because it uses small chunks of memory rather than allocating vast arrays. If you have close control over your Maps' creation and disposal, know in advance how much data they will hold, and know the number of entries will not vary dramatically as your program runs, use a Hashmap. Otherwise use a Treemap.
The other really cool Map, which I have yet to encounter the likes of in .NET, is java.util.concurrent.ConcurrentSkipListMap. This is excellent for multithreaded situations. It is completely thread safe and it is non-blocking.
(I found this question while looking at one closed for being a duplicate. I thought both questions could use an answer that mentioned something other than HashMaps, good as HashMaps are for most uses and similar as they are to the C# Dictionary.)

You are looking for an alternative to the generic IDictionary in C# which takes (key,value) pairs.
In Java, there is a Dictionary class that is the parent class of any class, which accepts (key,value) pairs.
A HashTable (which extends Dictionary) will suit your need. It performs operations like copy, remove, add, check if an item exists etcetera. However, while IDictionary supports foreach loop in C#, to loop over a HashTable in Java, you will need an Iterator.
An added advantage with HashTables is that it is synchronized, so you would not have to worry about concurrency.
IF however, you are looking for an asynchronous implementation, you should use the HashMap. A HashMap too requires an Iterator to traverse through it.
Undoubtedly, you also need to look at how an Iterator works in Java.
HashTables: http://download.oracle.com/javase/1.4.2/docs/api/java/util/Hashtable.html
HashMaps: http://download.oracle.com/javase/1.4.2/docs/api/java/util/HashMap.html
Iterator: http://download.oracle.com/javase/1.4.2/docs/api/java/util/Iterator.html

Why doesn't Java Map extend Collection?

I was surprised by the fact that Map<?,?> is not a Collection<?>.
I thought it'd make a LOT of sense if it was declared as such:
public interface Map<K,V> extends Collection<Map.Entry<K,V>>
After all, a Map<K,V> is a collection of Map.Entry<K,V>, isn't it?
So is there a good reason why it's not implemented as such?
Thanks to Cletus for a most authoritative answer, but I'm still wondering why, if you can already view a Map<K,V> as Set<Map.Entries<K,V>> (via entrySet()), it doesn't just extend that interface instead.
If a Map is a Collection, what are the elements? The only reasonable answer is "Key-value pairs"
Exactly, interface Map<K,V> extends Set<Map.Entry<K,V>> would be great!
but this provides a very limited (and not particularly useful) Map abstraction.
But if that's the case then why is entrySet specified by the interface? It must be useful somehow (and I think it's easy to argue for that position!).
You can't ask what value a given key maps to, nor can you delete the entry for a given key without knowing what value it maps to.
I'm not saying that that's all there is to it to Map! It can and should keep all the other methods (except entrySet, which is redundant now)!

From the Java Collections API Design FAQ:
Why doesn't Map extend Collection?
This was by design. We feel that
mappings are not collections and
collections are not mappings. Thus, it
makes little sense for Map to extend
the Collection interface (or vice
versa).
If a Map is a Collection, what are the
elements? The only reasonable answer
is "Key-value pairs", but this
provides a very limited (and not
particularly useful) Map abstraction.
You can't ask what value a given key
maps to, nor can you delete the entry
for a given key without knowing what
value it maps to.
Collection could be made to extend
Map, but this raises the question:
what are the keys? There's no really
satisfactory answer, and forcing one
leads to an unnatural interface.
Maps can be viewed as Collections (of
keys, values, or pairs), and this fact
is reflected in the three "Collection
view operations" on Maps (keySet,
entrySet, and values). While it is, in
principle, possible to view a List as
a Map mapping indices to elements,
this has the nasty property that
deleting an element from the List
changes the Key associated with every
element before the deleted element.
That's why we don't have a map view
operation on Lists.
Update: I think the quote answers most of the questions. It's worth stressing the part about a collection of entries not being a particularly useful abstraction. For example:
Set<Map.Entry<String,String>>
would allow:
set.add(entry("hello", "world"));
set.add(entry("hello", "world 2"));
(assuming an entry() method that creates a Map.Entry instance)
Maps require unique keys so this would violate this. Or if you impose unique keys on a Set of entries, it's not really a Set in the general sense. It's a Set with further restrictions.
Arguably you could say the equals()/hashCode() relationship for Map.Entry was purely on the key but even that has issues. More importantly, does it really add any value? You may find this abstraction breaks down once you start looking at the corner cases.
It's worth noting that the HashSet is actually implemented as a HashMap, not the other way around. This is purely an implementation detail but is interesting nonetheless.
The main reason for entrySet() to exist is to simplify traversal so you don't have to traverse the keys and then do a lookup of the key. Don't take it as prima facie evidence that a Map should be a Set of entries (imho).

While you've gotten a number of answers that cover your question fairly directly, I think it might be useful to step back a bit, and look at the question a bit more generally. That is, not to look specifically at how the Java library happens to be written, and look at why it's written that way.
The problem here is that inheritance only models one type of commonality. If you pick out two things that both seem "collection-like", you can probably pick out a 8 or 10 things they have in common. If you pick out a different pair of "collection-like" things, they'll also 8 or 10 things in common -- but they won't be the same 8 or 10 things as the first pair.
If you look at a dozen or so different "collection-like" things, virtually every one of them will probably have something like 8 or 10 characteristics in common with at least one other one -- but if you look at what's shared across every one of them, you're left with practically nothing.
This is a situation that inheritance (especially single inheritance) just doesn't model well. There's no clean dividing line between which of those are really collections and which aren't -- but if you want to define a meaningful Collection class, you're stuck with leaving some of them out. If you leave only a few of them out, your Collection class will only be able to provide quite a sparse interface. If you leave more out, you'll be able to give it a richer interface.
Some also take the option of basically saying: "this type of collection supports operation X, but you're not allowed to use it, by deriving from a base class that defines X, but attempting to use the derived class' X fails (e.g., by throwing an exception).
That still leaves one problem: almost regardless of which you leave out and which you put in, you're going to have to draw a hard line between what classes are in and what are out. No matter where you draw that line, you're going to be left with a clear, rather artificial, division between some things that are quite similar.

I guess the why is subjective.
In C#, I think Dictionary extends or at least implements a collection:
public class Dictionary<TKey, TValue> : IDictionary<TKey, TValue>,
ICollection<KeyValuePair<TKey, TValue>>, IEnumerable<KeyValuePair<TKey, TValue>>,
IDictionary, ICollection, IEnumerable, ISerializable, IDeserializationCallback
In Pharo Smalltak as well:
Collection subclass: #Set
Set subclass: #Dictionary
But there is an asymmetry with some methods. For instance, collect: will takes association (the equivalent of an entry), while do: take the values. They provide another method keysAndValuesDo: to iterate the dictionary by entry. Add: takes an association, but remove: has been "suppressed":
remove: anObject
self shouldNotImplement
So it's definitively doable, but leads to some other issues regarding the class hierarchy.
What is better is subjective.

The answer of cletus is good, but I want to add a semantic approach. To combine both makes no sense, think of the case you add a key-value-pair via the collection interface and the key already exists. The Map-interface allows only one value associated with the key. But if you automatically remove the existing entry with the same key, the collection has after the add the same size as before - very unexpected for a collection.

Java collections are broken. There is a missing interface, that of Relation. Hence, Map extends Relation extends Set. Relations (also called multi-maps) have unique name-value pairs. Maps (aka "Functions"), have unique names (or keys) which of course map to values. Sequences extend Maps (where each key is an integer > 0). Bags (or multi-sets) extend Maps (where each key is an element and each value is the number of times the element appears in the bag).
This structure would allow intersection, union etc. of a range of "collections". Hence, the hierarchy should be:
Set
|
Relation
|
Map
/ \
Bag Sequence
Sun/Oracle/Java ppl - please get it right next time. Thanks.

Map<K,V> should not extend Set<Map.Entry<K,V>> since:
You can't add different Map.Entrys with the same key to the same Map, but
You can add different Map.Entrys with the same key to the same Set<Map.Entry>.

If you look at the respective data structure you can easily guess why Map is not a part of Collection. Each Collection stores a single value where as a Map stores key-value pair. So methods in Collection interface are incompatible for Map interface. For example in Collection we have add(Object o). What would be such implementation in Map. It doesn't make sense to have such a method in Map. Instead we have a put(key,value) method in Map.
Same argument goes for addAll(), remove(), and removeAll() methods. So the main reason is the difference in the way data is stored in Map and Collection.
Also if you recall Collection interface implemented Iterable interface i.e. any interface with .iterator() method should return an iterator which must allow us to iterate over the values stored in the Collection. Now what would such method return for a Map? Key iterator or a Value iterator? This does not make sense either.
There are ways in which we can iterate over keys and values stores in a Map and that is how it is a part of Collection framework.

Exactly, interface Map<K,V> extends
Set<Map.Entry<K,V>> would be great!
Actually, if it were implements Map<K,V>, Set<Map.Entry<K,V>>, then I tend to agree.. It seems even natural. But that doesn't work very well, right? Let's say we have HashMap implements Map<K,V>, Set<Map.Entry<K,V>, LinkedHashMap implements Map<K,V>, Set<Map.Entry<K,V> etc... that is all good, but if you had entrySet(), nobody will forget to implement that method, and you can be sure that you can get entrySet for any Map, whereas you aren't if you are hoping that the implementor has implemented both interfaces...
The reason I don't want to have interface Map<K,V> extends Set<Map.Entry<K,V>> is simply, because there will be more methods. And after all, they are different things, right? Also very practically, if I hit map. in IDE, I don't want to see .remove(Object obj), and .remove(Map.Entry<K,V> entry) because I can't do hit ctrl+space, r, return and be done with it.

Straight and simple.
Collection is an interface which is expecting only one Object, whereas Map requires Two.
Collection(Object o);
Map<Object,Object>

Difference between a HashMap and a dictionary ADT

What is the difference between a Hash Map and dictionary ADT. And when to prefer one over another. For my programming assignment my instructor has asked to use one of them but I don't see any difference in between both. The program is supposed to work with a huge no. of strings. Any suggestions?

In terms of Java, both the class HashMap and the class Dictionary are implementations of the "Map" abstract data type. Abstract data types are not specific to any one programming language, and the Map ADT can also be known as a Hash, or a Dictionary, or an Associative Array (others at http://en.wikipedia.org/wiki/Associative_array). (Notice we're making a distinction between the Dictionary class and the Dictionary ADT.)
The Dictionary class has been marked as obsolete, so it's best not to use it.

This Stack Overflow post does a good job explaining the key differences:
Java hashmap vs hashtable
Note that Hashtable is simply an implementation of the Dictionary ADT. Also note that Java considers Dictionary "obsolete".
The fact that Hashtable is synchronized doesn't buy you much for most uses. Use HashMap.

In Java the HashMap implements the Map interface while the Dictionary does not. That makes the Dictionary obsolete (according to the API docs). That is, they both do a similar function so you are right that they seem very similar...a HashMap is a type of dictionary.
You are advised to use the HashMap though.

Map is an interface for an ADT in Java, the same general language-independent data structure for maintaining <key, value> pairs, and is introduced in Java 1.2.
Dictionary (not an implementation of Map) is an Abstract class for the same purpose introduced earlier in JDK 1.0. The only subclass it has is Hashtable which itself is implementing Map. Nevertheless, Dictionary class is obsolete now and you may forget it.
There are differences between the function members of Map and Dictionary, however you may find the difference between HashMap and Hashtable more useful. here you can find the differences.