This week's book giveaway is in the OO, Patterns, UML and Refactoring forum. We're giving away four copies of Refactoring for Software Design Smells: Managing Technical Debt and have Girish Suryanarayana, Ganesh Samarthyam & Tushar Sharma on-line! See this thread for details.
Generic was not available until JDK 1.5.
For backward compatibility, it compiles when you use a generic class in a non-generic way.
For example,we are supposed to use HashMap in this way : HashMap<String, String> or any other type. But it compiles if you put HashMap h = new HashMap();
You will get a warning, but it compiles in JDK 6.
it compiles because compiler sees it as class Y extends X<Object>
No, it works to maintain backward compatibility.
You just created the classes S and V, but most of the time you'll have to deal with legacy code.
For example, last year you downloaded ms-util.jar from Microsoft.com. They had this awesome class S that did a lot of thing:
You decided on your project to extend that class to add some functionality:
Everything is fine, right? No generics so it is simple ;)
However, some Monday morning, a user reports a bug with your application. You investigate a bit and you find that the bug is in the class S... but you are in luck, it has been fixed in the latest version of ms-util.jar. So you head to Microsoft.com and download the newest version of ms-util.jar.
When you open (and decompile) the new ms-util.jar, here's what you find:
Microsoft has changed their classes to use generics. Awesome.... but will it break your code? Remember, your class V that extends S does not use generics and even pass a non-typed list to their methods!!
Sun made it that your old code (class V) would continue to compile. If they hadn't, you would have needed to recode all your classes!