This week's book giveaways are in the Refactoring and Agile forums.
We're giving away four copies each of Re-engineering Legacy Software and Docker in Action and have the authors on-line!
See this thread and this one for details.
Win a copy of Re-engineering Legacy Software this week in the Refactoring forum
or Docker in Action in the Cloud/Virtualization forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

compile error in generics

 
Raju Champaklal
Ranch Hand
Posts: 521
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
this code compiles.....but the code below this doesnt....why? and whats same erasure?


 
Wouter Oet
Saloon Keeper
Posts: 2700
IntelliJ IDE Opera
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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!
 
Neha Daga
Ranch Hand
Posts: 504
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.

I hope I am correct.
 
Raju Champaklal
Ranch Hand
Posts: 521
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
got you... thanks
 
Raju Champaklal
Ranch Hand
Posts: 521
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator


then why doesnt this compile ? i know you said that there will be erasure but the compiler says that they cant be overloaded....can you clear this one? and even this one
 
Neha Daga
Ranch Hand
Posts: 504
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
the compiler error I am getting is:
Name clash: The method say(List<Integer>) of type Child has the same erasure as say(List<String>) of type Parent but does not override it
 
Raju Champaklal
Ranch Hand
Posts: 521
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Raju Champaklal wrote:

then why doesnt this compile ? i know you said that there will be erasure but the compiler says that they cant be overridden or overloaded....can you clear this one? and even this one
 
PrasannaKumar Sathiyanantham
Ranch Hand
Posts: 110
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Regarding the above example,

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)
 
Raju Champaklal
Ranch Hand
Posts: 521
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
i know but what does it mean? why cant they be overridden?
 
Neha Daga
Ranch Hand
Posts: 504
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
The reason I think is:
for compiler they are two different type safe lists so it is definitely not a legal override.

Its just a guess, actually I am really confused
 
Raju Champaklal
Ranch Hand
Posts: 521
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
then why not overloading? hmm maybe because of the erasure you said....
 
Neha Daga
Ranch Hand
Posts: 504
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
yes, probably we are right.
 
Raju Champaklal
Ranch Hand
Posts: 521
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
if parent has (List list) and child has (List<String> list) it doesnt compile but if its the opposite it compiles? this is so confusing
 
Neha Daga
Ranch Hand
Posts: 504
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Ranch Hand
Posts: 521
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
http://www.angelikalanger.com/GenericsFAQ/FAQSections/ProgrammingIdioms.html#FAQ050

this link may help me
 
Raju Champaklal
Ranch Hand
Posts: 521
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
still not getting it....6 days left for exam
 
Anchit Herredia
Greenhorn
Posts: 26
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.

Hope that answers. Here's some more info: Generics_in_Java

 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic