• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

Generics and instanceof Operator

 
Ranch Hand
Posts: 316
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Assertion :- ref instanceOf InterfaceType results to:-
true iff class of object ref directly or indirectly implements InterfaceType
false otherwise.

Assertion 2:- String class implements Comparable<String>


Asserion 3:- a) "sahil bhatia" instanceof Comparable<String>
b) "sahil mittal" instanceof Comparable<T>


Result :- Both the above statements upsets compiler....!!! Why ???

Thanks !!!
 
Rancher
Posts: 618
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Because instanceof is a runtime thing and generics is a compile time thing? It doesn't make sense to add <X> to the instanceof operator because the JVM doesn't know anything about <X>
 
Sahil Kapoor
Ranch Hand
Posts: 316
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Tom Reilly wrote:Because instanceof is a runtime thing and generics is a compile time thing?



If this is the case then , it should work, If it would have been vice-versa ie instanceof is a compile time thing and generics is a runtime-thing then the result could be reasoned. But what you are saying , is not supporting the result .

Please do elaborate if i am wrong !!!



Thanks !!!
 
Marshal
Posts: 28193
95
Eclipse IDE Firefox Browser MySQL Database
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Do you know about "erasure" in generics? Erasure explains it all. So find out about erasure if you haven't already heard about it.
 
author
Posts: 23951
142
jQuery Eclipse IDE Firefox Browser VI Editor C++ Chrome Java Linux Windows
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Sahil Kapoor wrote:

Tom Reilly wrote:Because instanceof is a runtime thing and generics is a compile time thing?



If this is the case then , it should work, If it would have been vice-versa ie instanceof is a compile time thing and generics is a runtime-thing then the result could be reasoned. But what you are saying , is not supporting the result .

Please do elaborate if i am wrong !!!



Okay... I'll ask. Can you elaborate on how you are right?

I don't understand how "it should work" and the "have been vice-versa" argument.

Henry
 
Sahil Kapoor
Ranch Hand
Posts: 316
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Like tom wrote

Because instanceof is a runtime thing and generics is a compile time thing?



If this is the case then "instance of" should work because compilation happens before runtime. So this means generics kind of thing would be resolved when it comes to runtime and hence could be applied.

But if it would have been vice-versa then...
(Just a Hypothetical view)

Then we could guessed the reason that since instanceof happens at compile time, and generics kind of this is to be resolved at runtime . It could not be applied.


 
Tom Reilly
Rancher
Posts: 618
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I wrote the following to demonstrate that the compiler does not produce an error when doing an instanceof on anything. It leaves everything to the JVM and the JVM knows nothing about generics (Refer to Paul's reference to erasure).

Therefore specifying would not add any value because the compiler would not complain that you specified <Integer> when you should have specified <String>. What surprised me though is that the compiler gives a warning when you don't specify <Integer> but gives an error when you do.
 
Sahil Kapoor
Ranch Hand
Posts: 316
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
@Paul Clapham

I understood a lil bit !!!
I woudl re read it again !!!
cheers!!!
 
Henry Wong
author
Posts: 23951
142
jQuery Eclipse IDE Firefox Browser VI Editor C++ Chrome Java Linux Windows
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Sahil Kapoor wrote:Like tom wrote

Because instanceof is a runtime thing and generics is a compile time thing?



If this is the case then "instance of" should work because compilation happens before runtime. So this means generics kind of thing would be resolved when it comes to runtime and hence could be applied.

But if it would have been vice-versa then...
(Just a Hypothetical view)

Then we could guessed the reason that since instanceof happens at compile time, and generics kind of this is to be resolved at runtime . It could not be applied.




Let me try to explain it this way.... The instanceof operation happens at runtime, and the generics type-checking stuff can only happen at compile time. So, what does this mean? It means when you do an instanceof, the compiler will not do the type checking at compile time, instead it will generate code, which will later run at runtime, to check the type.

But you are trying to take an instance of to something that is a generic. This means that the compiler needs to generate code, to be later run at runtime, to type check it. This code needs to check, at runtime, to something that doesn't exist at runtime -- the generic type. So... the compiler complains. It complains that it is not possible to generate such code.

In other words, it is complaining about not being able to generate the code for the instanceof -- and its not the actual instanceof that is generating the error.

Henry
 
Sahil Kapoor
Ranch Hand
Posts: 316
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
@Henry Wong

Appreciate your stupendous explanation.

Just one more question ?

Why does not this generic type stuff exists during run-time, i meant the specific version of generic type must exist during runtime to use it. What i understood from generics is as follows :-

Suppose we have a class
class Genes<T> { // We are using T inside also }

When i say Genes<String> (Suppose) then compiler generates the specific version of above generic type as follows

class Genes<String> { //replaced t with String }


Now at run-time the specific version exists or not ??
I think it must exist, so that we could use it ???

Please clarify ??

Thanks
Cheers!!!
 
Tom Reilly
Rancher
Posts: 618
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Let's try explaining it this way. You don't need generics at runtime because the compiler does such a good job at compile time. Before generics, we could write code like this:
This code compiled just fine. When running it, though, the JVM would throw a ClassCastException. After generics, we write the code like this:
This code does not compile. It tells you at compile time that you cannot cast a String to an Integer. (The same information that used to be given to you at runtime is now provided to you at compile time.) Code that does not compile cannot be run. Once you fix the compiler error, the compiler and the JVM are so confident that that there is no possible way you could be trying to cast a String to an Integer that the compiler does not give the information to the JVM and the JVM does not make the check.
 
Henry Wong
author
Posts: 23951
142
jQuery Eclipse IDE Firefox Browser VI Editor C++ Chrome Java Linux Windows
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Sahil Kapoor wrote:
Now at run-time the specific version exists or not ??
I think it must exist, so that we could use it ???



It doesn't. All type checking is done at compile time. And after the compiler confirms that everything is fine, it will generate code, as if you used Object references and explicit casting.

As mentioned by Paul, please take a look at "erasure" and "generics".

Henry
 
Sahil Kapoor
Ranch Hand
Posts: 316
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Thanks Tom Reily and Henry !!!

 
With a little knowledge, a cast iron skillet is non-stick and lasts a lifetime.
reply
    Bookmark Topic Watch Topic
  • New Topic