instanceof

[vijay umar]

consider the code line:
interface Face { }
class Bar implements Face{ }
class Foo extends Bar { }

based on this the following table is constructed( k& s book pg-286,operators)




First Operand instanceof operand(comparing reference) Result after instanceof is performed
(Reference Being Tested)
null Any class or interface type false
Foo instance Foo, Bar, Face, Object true
Bar instance Bar, Face, Object true
Bar instance Foo false
Foo [ ] Foo, Bar, Face false
Foo [ ] Object true
Foo [ 1 ] Foo, Bar, Face, Object true

here i have the doubt regarding the relation between Foo[] and FOo,bar,Face which gives an false on instanceof operation between them and Foo[1] and foo,bar,face,Object instanceof relation gives true result how is this possible !! what is the difference between foo[] and foo[1];

[Bob Wheeler]

vijay umar wrote:
here i have the doubt regarding the relation between Foo[] and FOo,bar,Face which gives an false on instanceof operation between them and Foo[1] and foo,bar,face,Object instanceof relation gives true result how is this possible !! what is the difference between foo[] and foo[1];

foo[] is an array object, not a foo object. foo[1] is a foo object.

[vijay umar]

but where do we declare an object like foo[1]....

i thought it is an array element... isnt it!

[Alexander Danilou]

IMHO trying to compile Foo[] instanceof Foo (or Bar, of Face) should give compile time error, something like inconvertible types, am I wrong???

[Bob Wheeler]

Alexander Danilou wrote:IMHO trying to compile Foo[] instanceof Foo (or Bar, of Face) should give compile time error, something like inconvertible types, am I wrong???

No, you are right. They are not in the same inheritance tree, so the compiler can see the error.

but where do we declare an object like foo[1]....
i thought it is an array element... isnt it!

Yes, it is an array element, which is foo. Every element in the array foo[] is of type foo (or a subtype).

Some code example:

  
interface Face { }
class Bar implements Face{ }
class Foo extends Bar { } 
class Boo extends Bar { }

public class instanceoffTest {
	public static void main(String[] args){
		Foo f = new Foo();
		Foo[] fa = {f, new Foo()};
		Boo b =  new Boo();
		Foo fe = fa[1]; // Foo object
		Bar ba = new Bar();
		boolean b1 = fe instanceof Foo; // true
		boolean b2 = fa instanceof Foo; // inconvertible - compiler error
		boolean b3 = ba instanceof Foo; // false, but same inheritance tree
	}
}
  

[vijay umar]

That means array object of a class is different from the actual object of a class!! isnt it

[Bob Wheeler]

vijay umar wrote:That means array object of a class is different from the actual object of a class!! isnt it

Yes. They even don't share the same inheritance tree. So if you compare them with then instanceof operator, you get a compiler error.

cheers
Bob

[vijay umar]

ok! thanks a lot bob!

[Nigel Shrin]

Bob Wheeler wrote:

vijay umar wrote:That means array object of a class is different from the actual object of a class!! isnt it

Yes. They even don't share the same inheritance tree. So if you compare them with then instanceof operator, you get a compiler error.

cheers
Bob

If instanceOf detects that you have tested dog to be cat, and they are not related inheritance wise, why give a compiler error, why not just say false!?

Thanks

[Ankit Garg]

From the JLS

If a cast of the RelationalExpression (the left operand of instanceof) to the ReferenceType (the right operand of instanceof) would be rejected as a compile-time error, then the instanceof relational expression likewise produces a compile-time error.

So since Cat and Dog (which is by the way nowhere in this thread) are not compatible, then instanceof comparison will fail at compile time...

[Nigel Shrin]

thanks Ankit
a guess we're saying - that's the spec', that's how it is -- as opposed to why

[Ankit Garg]

Nigel Shrin wrote:a guess we're saying - that's the spec', that's how it is -- as opposed to why

No, that's not the case. Lets take an example

class Cat {
}
class Tiger {
}

Now if you try an instanceof comparison between these, it will fail. The reason being, it can never be true. Then what's the use of allowing such thing. You can't do a cast, neither anything else. So allowing this is useless and wastage of developers efforts and might result in a bug later on (obviously if you are doing such a test, then you've done something wrong as this test will always be false so its wrong)...

[Nigel Shrin]

with instanceOf you have three possible results:
1) True - is current object type or a parent/ancestor class
2) False - if in the tree but beneath
3) Compile error if outside inheritance tree

So my question of why not return False if outside the tree, would encompass both the last two scenarios - a false could be a valid branch to other code.

So you would have to use a try/catch if there is a risk of a compile error? / or you should not be asking the question!!!

[Salil Vverma]

Hey Nigel,

I think, giving the compilation error when objects are in different inheritance tree make more sense, reason being a developer should use instance of operator only when he can not determine the type of object at the time of coding. I guess an intelligent developer would never try to check something in runtime which he already know at design time itself.

Regards
Salil Verma