Question

As far as i know, the generics are only useful at compilation time.

Thus it is possible to declare:

private Set set = new HashSet<String>();

And then, in this string hashset, to add dogs or anything to that set, without any problem since there is not any check at runtime like for arrays (ArrayStoreException…) (but you may have problems like a classcast when you use that set…

So what i want to say is, we usually instantiate generic collections that way:

Set<String> set = new HashSet<String>();

My question is, why do we put the type of the HashSet, since only the type of the reference of the variable is really important (i think).

I mean, we could simply write:

Set<String> set = new HashSet();

And it would work exactly the same right?
So why do we usually write the type during the instantiation? (it’s not mandatory)

---

Edit

I know about the “diamond operator” for type inference but why do we even need it!!! since type inference is already working!

The following code :

            Set<String> set = new HashSet();
            set.add("Test add a string 1");
            set.add("Test add a string 2");
            for ( String s : set ) {
                    System.out.println(s);
            }

Produces the output:

Test add a string 1
Test add a string 2

Test it yourself
http://ideone.com/vuiCE

So now you talk about type inference as a Java7 feature, but it is already working for me…

With java7 i will have to replace my

            Set<String> set = new HashSet();

By

            Set<String> set = new HashSet<>();

It’s still 2 extra characters for doing exactly the same thing no? (Unless generics are not only compile time with Java7? I don’t know)

Answer 1

Although Java currently erases generic type info, they have been extremely careful to design the language and libraries so that it is possible in future to add back full generic type info (so called reification). Any correctly written generic code (i.e. without any javac warning) will survive such language change. In your example, the diamond version is future proof; the raw version is not – it still must compile of course, but it will throw type cast exception at runtime.

Yet, this future-compatibility is a completely delusional. Erasure will stay with us forever. If full reification is introduced, it is safe to say almost all non trivial generic code will break, because everybody is writing incorrect generic code.

It is not our fault. Java forces us to. It gives us the bullshit erasure, and we have no choice but to hack around it to implement stuff. Our code is full of dependencies on detail knowledge of erasure.

JDK is the most guilty one. JDK APIs are carefully designed to survive reification; however the implementations depend on erasure. If Java adds reification, these JDK codes must be rewritten. Java team will be extremely hypocritical if they blame us for writing incorrect code while they must do the same thing themselves.

Given the amount of code that cannot survive reification without rewrite, we can safely say Java is never going to add reification, as long as it keeps the commitment on backward compatibility.

In that case, yeah, whatever. Nothing really terrible about Set<String> set = new HashSet(). Personally I always add <> to avoid the warning. (Actually whenever possible I’ll try to make my code reification-proof, which is, as I said, a delusional act)

In your example, inference is trivial. There can be more complex case where <> inference is not so trivial, its type checking can be helpful, which the raw version lacks.

class Foo<T>
{
    Foo(Class<T> clazz){}
}

Foo<String> foo1 = new Foo(Integer.class);    // compiles (wrongly) 

Foo<String> foo2 = new Foo<>(Integer.class);  // does not compile