This week's book giveaway is in the Kotlin forum.
We're giving away four copies of Kotlin in Action and have Dmitry Jemerov & Svetlana Isakova on-line!
See this thread for details.
Win a copy of Kotlin in Action this week in the Kotlin forum!
  • Post Reply Bookmark Topic Watch Topic
  • New Topic

instanceof and interfaces  RSS feed

 
David Fishman
Greenhorn
Posts: 18
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi there,
This is my first post, and first off just wanted to say I was very glad to find this forum - great job !
I am reading Mughal and Rasmussen's "A programmer's Guide to Java Cert", and according to their phrasing the compile-time check of the instanceof operator "... determines whether a reference of <source type> and a reference of <destination type> can denote objects of a reference type that is a common subtype of both <source type> and <destination type> in the type hierarchy".
They go on to give an example where the compiler will complain if you try to apply instanceof using one of their created classes and String (for example), which I understand.
What I don't understand is the following, which is my own little variation on one of their practice questions

From all the type hirarchy diagrams I've seen in the text, I would say that interfaces I and J are on two different branches of the type hierarchy (interfaces being described as supertypes which can be assigned references of subtypes etc), as is class E. So I expected the above not to pass the compiler, but instead it did and showed "FalseJ" and "FalseE" when run.
Am I missing something here, or is their explanation incomplete ? Apparently interfaces are treated differently than named classes but I couldn't find any qualifications regarding this.
Thanks !
 
Dirk Schreckmann
Sheriff
Posts: 7023
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Welcome to JavaRanch, David!
The Java compiler doesn't concern itself with evaluating the resulting value of an instanceof comparison. The compiler just makes sure that an object reference is on the left, and a data type is on the right of the operator.
It's at run time that the value of this comparison is determined, and both of your examples should evaluate to false, as you've noted.
I'm not exactly sure what you mean by the "compiler will complain if you try to apply instanceof using one of their created classes and String". If you mean that, if a reference of some custom data type is checked with instanceof to determine if it's a String, then I seriously doubt that the compiler will complain. This evaluation should occur at run time.
Is anything becoming clearer?
[ December 31, 2003: Message edited by: Dirk Schreckmann ]
 
Ernest Friedman-Hill
author and iconoclast
Sheriff
Posts: 24217
38
Chrome Eclipse IDE Mac OS X
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
The compiler actually will complain if the instanceof can't possibly succeed. For example,

will give a compiler error, since x can't possibly contain anything that can be cast to a String, since String is a final class.
Now, with interfaces, the compiler isn't so sure of itself. In your example below, "x instanceof J" is legal because while I's formal type is I, x could be pointing to an instance of some class that implements both I and J (as Dirk says, the compiler doesn't look at the actual value of x at compile time, only the static type of the variable.)
Likewise, "x instanceof E" is legal, because x could point to an instance of some subclass of E that implemented I.
 
Dirk Schreckmann
Sheriff
Posts: 7023
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I am surprised, obviously. I use instanceof less than I use the bit shifting operators. I wouldn't have suspected that Java did that much for compile-time type checking.
 
David Fishman
Greenhorn
Posts: 18
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Dirk and Ernest - Thanks for your replies.
I guess I was confused by the fact that I could not see any existing connections with the interfaces given the classes in the code, and am also surprised to learn the compiler allows a potential type hierarchy to satisfy the instanceof.
My surprise might be more of a philosophical than a practical issue though, and in any case the explanation makes sense.
Thanks again !
 
Ernest Friedman-Hill
author and iconoclast
Sheriff
Posts: 24217
38
Chrome Eclipse IDE Mac OS X
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

and am also surprised to learn the compiler allows a potential type hierarchy to satisfy the instanceof.

If you think about it, that's the whole point of instanceof. There's no point in using it to answer questions the compiler can answer at compile time; it's only the unknown runtime possibilities that matter.
 
Thomas Paul
mister krabs
Ranch Hand
Posts: 13974
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
interface I {}
interface J {}
class C implements I {}
class D implements J {}
class E {}
class F extends E implements I, J {}
Here is why the compiler can't say for sure that an object of type E does not implement I:
E e = new F();
if (e instanceof J) // evaluates to true
However, if class E is marked final then it can't have any children and your code will generate a compiler error!
 
David Fishman
Greenhorn
Posts: 18
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thanks all - much clearer now.
 
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!