Thats called type erasure. I've posted some more information about it in your other topic.
That's because Set and SortedSet are 2 different interfaces and Set<Double> and Set<Boolean> are because of type erasure the same.
I've noticed that you have multiple topics regarding generics. Try to read some information about it. I highly recommend the book from
Kathy Sierra and Bert Bates "Sun Certified Programmer for Java 6 Study Guide". It's great. If kathy of Bert is reading this, thank you!
"Any fool can write code that a computer can understand. Good programmers write code that humans can understand." --- Martin Fowler
Please correct my English.
I am sure you know that generics are only for compile time type safety, at runtime jvm has no information about this type safe declaration.
jvm sees the code as it used to see prior to generics....that is after the program is compiled all the type safe declaration are removed this is called type erasure.
let us say i have a class grandchild which passes a linkedlist object to the parent say method and child say method... The list will accept it. No matter what you save inside the object the object nature is list only..(I hope you understand)
You give generics name only to save different datatypes in an object(This is very imporatant what is an object but a userdefined datatype)
It compiles, compiler is just giving you the warning. Because here it thinks that you are overriding the super class' method and it tells you that to refer to a type safe collection you should make this one also type safe with the same type.
Raju Champaklal wrote:this code compiles.....but the code below this doesnt....why? and whats same erasure?
I noticed that we haven't replied to this one yet. So here's the answer to your question:
In Java 1.5, while fetching the objects from any collection it would be returned as an instance of "Object class" (which is the simply father of all classes). Now we have to typecast this returned object to whatever actual object it was. For example, if we got a string object we would say:
But the problem with this was that if the object stored in the collection was not a String object we would get a runtime error. So in Java 1.6 we have the capability of generics. Here we tell the compiler before hand that our collection (HashSet in my example above) would be storing some particular type, such as string. So once the compiler knows that HashSet object stores only Strings it can point out any mistakes in the code where we are not storing String.
Coming back to your question, the generics checking happens during compile-time. So during compilation it is checked that you are only putting String objects into HashSetObject. However, after compilation the generic is removed. So if you have two methods with same name but different generics both will still have the exact same signature after compilation. But then there would be an error. We would two methods with exact same signature but different bodies. This cannot be allowed hence the compiler gives you that error.