I am sort of dumb-founded that this is on the front-page of HackerNews. I know this isn't a constructive comment in any way, but this link is to a basic post that is going over the different between a list, a set, and a map?

Really?

Exactly. And if you look at the OP's nick, you'll notice that he is the author of this blog post. As a matter of fact, if you check out his submissions (http://news.ycombinator.com/submitted?id=mainguy) you'll notice that he has a habit of submitting his blog posts to HN whenever he writes them.

Here's a message to you, mainguy: It's nice that you're blogging and all, but please, understand that not everything you write is HN-worthy.

Flagged.

There are a number of people I know who have never touched Java and are being exposed to the eco-system through languages like Clojure and Scala and this kind of overview may be useful to them.

However, I agree that it's not worthy to be on the front-page of HN.

These are not Java-specific data structures. If you already know these concepts -- and I don't see how you could write code without inevitably bumping into them -- the Java implementations should be intuitive and trivial to learn. Not to mention clearly documented.

The only reason I feel this is out of place here is because the very first thing the author says is "if you google[...]" which I would hope most hackers do before they start asking questions of others.

Especially since it's talking about old Java 1.4 collections, with no mention of changes in the last seven years!

As of Java 1.5, generics were added. Before generics you had to cast every object you read from a collection. If someone accidentally inserted an object of the wrong type — possible in the OP's example code — casts could fail at runtime.

With generics, you tell the compiler what types of objects are permitted in each collection. The compiler inserts casts for you automatically and tells you at compile time if you try to insert an object of the wrong type. This results in programs that are both safer and clearer. So please use generics when using the collections framework.

I'm now going to briefly run through the examples provided in OP's post and update them accordingly.

  List<String> myList = new ArrayList<String>();
  myList.add("Second Thing");
  myList.add("Second Thing");
  myList.add("First Thing");

Note that I've used the interface form of List over a specialised type. This is so that any caller of a method which returns a collection can use the interface provided and they don't need to worry about the specific data structures you've used. This also means that you can update the underlying data structure without having to update any calling code. E.g. changing the above case from ArrayList to LinkedList.

  Set<String> mySet = new HashSet<String>();
  mySet.add("Second Thing");
  mySet.add("Second Thing");
  mySet.add("First Thing");

It is worth noting that Hashtable was not originally part of the Collections framework. It was retrofitted to conform to the Map interface in 1.2. You should instead use HashMap, which is the non-synchronized (sic) version of Hashtable. Although you can just as easily use Hashtable, the below example is just me being a little OCD.

  Map<String, String> myMap = new HashMap<String, String>();
  myMap.put("a", "Second Thing");
  myMap.put("b", "Second Thing");
  myMap.put("c", "First Thing");

EDIT: Updated some sections to read clearer.

> It is worth noting that Hashtable was not originally part of the Collections framework.

An other class in that case being Vector, and that's the reason why they have a lot of duplication in their methods: they have the original ones, and they have the new ones coming from the Collections framework interface (this is also the source of having both Iterator[0] and Enumerable[1] in the JDK: Iterator is the Collections framework iterator interface, Enumerable is the pre-Collections one)

An other big difference, which you hinted at, is that Hashtable and Vector are both synchronized collections (method calls will take the collection lock and behave "atomically"), whereas Collections framework classes are not, instead the Collections framework has compositional wrappers[2] which provide this behavior independently of the underlying collection implementation.

finally, a little trick for more fluent Collections initialization: you can abuse anonymous subclasses and instance initializers to get something much less imperative:

    List<String> myList = new ArrayList<String>() {{
        add("Second Thing");
        add("Second Thing");
        add("First Thing");
    }};

[0] http://docs.oracle.com/javase/6/docs/api/java/util/Iterator....

[1] http://docs.oracle.com/javase/6/docs/api/java/util/Enumerati...

[2] http://docs.oracle.com/javase/6/docs/api/java/util/Collectio...