The same old Interface reference type issue

[Rekha Srinath]

Source: Inquisition

interface face { void meth(); }
class tester extends test implements face 
{ public void meth(){System.out.println("hello");}}
 
class test
{
   public static void main( String args[] )
   {
      test test_one = new tester();
      face f = test_one; // 1
      f.meth();
      
   }
}

I thought this would work fine... But the answer is "Compile time error at line 1 and it will compile if that line includes a cast for face"

This is what I thought: 'test' does not implement 'face'. But, there could be a scenario in the future wherein some class could extend 'test' AND implement 'face'. So, the compiler would allow Line 1 to be compiled, and at runtime also, 'test_one' actually points to a 'tester' object that indeed implements 'face' and hence, runtime exception also will not occur.

Where have I gone wrong?

[Harvinder Thakur]

Well it's an idiosyncrasy of the compiler implementation i guess.

Look at the following modified code:

interface face { void meth(); }
class tester extends test implements face 
{ public void meth(){System.out.println("hello");}}
 
class test
{
   public static void main( String args[] )
   {
      test test_one = new tester();
      face f = (face)test_one; // 1 : Explicit cast required in assignments
      boolean b = test_one instanceof face;//true
      boolean b1 = new test() instanceof face;//false
      System.out.println("b: "+b+" b1: "+b1);
      f.meth();
      
   }
}

I guess when assigning objects to references using assignment(=) operator the compiler checks for the actual type of the object being assigned.

Thus, when you say,

face f = test_one;

The compiler says, well test_one is of type *test* and since test does not implement *face* so i can't allow this assignment.

but when you say,

boolean b = test_one instanceof face;

Then the compiler says well, may be at run time it might turn out that *test_one* actually refers to an object which does implement *face*. Which actually is the case.

But weirdly, the compiler also gives the same benefit of doubt to the following:

boolean b1 = new test() instanceof face;

Conclusion: The compiler does not work the same when using instanceof operator as it does when using assignment(=) operator.

That's strange but i guess the key here is to look for whether you are making an explicit assignment because an assignment is more dangerous than the use instanceof operator. The reason being you would anyhow be doing something or the other based on the boolean result returned by the instanceof. So maybe compiler is less strict with the instanceof operator.

Well, i am just thinking aloud i guess. Anybody feels i am wrong then please do correct me.
[ December 01, 2008: Message edited by: Harvinder Thakur ]

[Rekha Srinath]

Ya I kind of understand Harvinder...But not 100% clear..
Lets see what others have to say as well..

[Chandra Bhatt]

Hi,

Your scenario is something like:

class Animal{
}

class Dog extends Animal{
}

class Cat extends Animal{
}

Dog d = new Dog();
Cat c = d; // Compiler Error

Its true that Dog and Cat both extend Animal. But there is no relation
between these two classes. Both are siblings extending same parent class.

[Duc Vo]

Another example: with the same reference, the below code will cause compiler error at line 3.

Car car = new Car();
Object carObj = car;
car = carObj;

And this will compile properly

Car car = new Car();
Object carObj = car;
car = (Car) carObj;

[Duc Vo]

Originally posted by Harvinder Thakur:

face f = test_one;

boolean b = test_one instanceof face;

boolean b1 = new test() instanceof face;

Not quite right though, in the above, b will be true and b1 will be false. It is perfectly legal since instanceof is just checking if an object is assignable to another class.
[ November 30, 2008: Message edited by: Duc Vo ]

[Abhi vijay]

interface I { void meth(); }
class B extends A implements I
{ public void meth(){System.out.println("hello");}}

class A
{
public static void main( String args[] )
{
A a = new B();
I i = (I)a; // 1
i.meth();

}
}

Line 1, explicit casting to I is required.

[Harvinder Thakur]

Originally posted by Duc Vo:

Not quite right though, in the above, b will be true and b1 will be false. It is perfectly legal since instanceof is just checking if an object is assignable to another class.

Let me make myself clear.

Firstly, b will be true and b1 will be false at runtime. I never refuted that and i completely agree with it.

The point i am trying to make is the behaviour of the compiler which means compile time behaviour and not run time behaviour.

So, when i say that,

[B]face f = test_one; // gives a compile time error [/B]

but,

[B]boolean b = test_one instanceof face; // does not give a compile time 
                                         //exception[/B]

and, if i say,

[B]boolean b = new test() instanceof face;// no compile time error[/B]

but,

class other {}
boolean b = new test() instanceof other; //Compiler readily throws 
                                         //and exception  and recognizes 
                                         //that test and other are 
                                         //incompatible types.

i am trying to highlight the difference between how the compiler behaves in the above mentioned scenarios. right.

So, IMHO the compiler does a stricter check incase of assignment(=) operator and is a bit lenient for instanceof operator because above in one case the compiler could have easily detected that *test* is not implementing *face*:

boolean b = new test() instanceof face;

I hope i make sense...

[Duc Vo]

Originally posted by Harvinder Thakur:

I hope i make sense...

Yes, you made sense. But what I meant is that your comparison is not quite right. You are comparing logical operator (instanceof) to a an assignment operator (=). The compiler treaments for logical operators (if it is true) and assignment operator (assign its reference/value from one to another) are very different.

[Harvinder Thakur]

Well i tried to put the instanceof operator in the fray because

Originally posted by Rekha:
But, there could be a scenario in the future wherein some class could extend 'test' AND implement 'face'.

as per the above quote i thought Rekha was confused with the use of *instanceof* operator and *assignment* operator, because her assumption holds true incase of instanceof operator and not assignment operator.

Well, maybe Rekha may correct me by showing an example that her assumption works in certain scenarios using assignment operator. Right now i am not able to think of that. :roll:

So, fellow ranchers please do correct me with your valuable inputs.

[Ankit Garg]

well harvinder came very close to ending this thread very early. Now let me try

Well if you write this code

interface Interface
{}
class Base
{}
.. main(..)
{
   Base b = /*some assignment*/;
   Interface i = b;
}

if the compiler would allow this, and the actual object to which the reference b points to is-not-a Interface, then you will have a ClassCastException at your hand. So the compiler cannot allow you to skip the cast as it cannot claim the blame of the runtime exception. It forces you to use the cast as if any exception comes, you know that you had used a cast.

In case of instanceof, the compiler is lenient as the real use of instanceof is indeed test the actual runtime type of the objects. If it would force you to use a cast when you test this

b instanceof Interface

like

((Interface)b) instanceof Interface

then the instance of comparison is of no use as the cast will only be successful if b is-a Interface. So basically if the cast was mandatory, then you will only have two possible answers 1) true 2) ClassCastException...

[Harvinder Thakur]

I fully agree with Ankit

[Rekha Srinath]

All,

Thanks for brainstorming ... I have now got a better idea than before ...