Interfaces can talk

[Gaurav Raje]

I was thinking about it and I feel there is a strange loophole in the Java language. By definition, an interface is a strictly flat structure with absolutely no executable code(apart from constants). Hence, method calls should not be allowed, and should have no executable code.
But if you consider the bad design below

package test;

public class TestClass {

	/**
	 * @param args
	 */
	public TestClass() {
		System.out.print("Called");
	}

	public static void main(String[] args) {
		// TODO Auto-generated method stub
		aer t = new aer();
		t.t.equals("");
	}

}

interface tester {

	public static final TestClass t = new TestClass();
}

class aer implements tester {

}

You are actually calling the constructor from the interface. What is more weird is that you could add runtime variables at that time, and even change the structure of the object.
I know the code sample is a very poor design, but I thought java would address these issues to make it foolproof. Furthermore, if we do

package test;

public class TestClass {

	/**
	 * @param args
	 */
	public TestClass() {
		System.out.print("Called");
	}

	public static void main(String[] args) {
		// TODO Auto-generated method stub
		aer t = new aer();
		t.t.equals("");

	}

}

interface tester {

	public static final TestClass t = new TestClass();
}

class aer implements tester, testing {

}

interface testing {
	public static final TestClass t = new TestClass();
}

we face the dreaded diamond inheritance problem which was so dreaded in C++
Java doesnt let you compile the code, but I thought interface rules were brought to avoid such problems in the first place.

[Campbell Ritchie]

If it won't compile, what is the problem?

[Gaurav Raje]

Campbell Ritchie wrote:If it won't compile, what is the problem?

They could have supported multiple inheritance in the first place and not let the special cases containing diamond inheritance compile. While it is not a good practice, it has the same side effects as the above 1.

[Gaurav Raje]

Furthermore, the only place where the compiler complains is when I make the ambigous call to t.t.something(). Not if I dont refer the t.t . Not when I instantiate the aer object. Nor when I write the classes with ambigous objects. Which I believe is wrong. At least in multiple inheritance it complains right at the beginning.

[Campbell Ritchie]

Yes, I see what you mean. It compiles nicely until you actually use the collision of t.t
I know you are allowed two methods with the same signature (and return type) in two interfaces, whereas here it doesn't notice there are two identical constant identifiers until you try to use them.

I think you are going to have to go through the Java™ Language Specification; maybe this page will help.

[Gaurav Raje]

I read through that... and apparently, the code is perfectly valid as per the spec(which is reflected in the compile process). I guess (and strictly my opinion) since the code is a little stupid, Java never bothered to address such issues.

[Rauhl Roy]

Gaurav Raje wrote:I read through that... and apparently, the code is perfectly valid as per the spec(which is reflected in the compile process). I guess (and strictly my opinion) since the code is a little stupid, Java never bothered to address such issues.

since both are same one is shadowing the other, since it is legal you don't get any compiler or runtime errors

[Campbell Ritchie]

The behaviour you are showing is consistent with what it says in that JLS link. If you don't use the shadowing/colliding fields, all is well. You only get an ambiguity if you try to use them without disambiguating them.

[Gaurav Raje]

I agree completely. It is perfectly legal and hence the compilation. But my point is, being as strict about object orientation as it is, things like this are not supposed to be allowed. For eg, the inner complications of the superclass class should be taken care of by the same class and not exposed to the end user of the class. What if the superclass which had shadowed variables was used in another method which relied on the t.t object. As per abstraction, if t.t is a valid field in the class, it should anc can be used.

[Rauhl Roy]

Gaurav Raje wrote:I agree completely. It is perfectly legal and hence the compilation. But my point is, being as strict about object orientation as it is, things like this are not supposed to be allowed. For eg, the inner complications of the superclass class should be taken care of by the same class and not exposed to the end user of the class. What if the superclass which had shadowed variables was used in another method which relied on the t.t object. As per abstraction, if t.t is a valid field in the class, it should anc can be used.

Can you tell me what is the thing that you think is bypassing the OOPS here in the code. Can you please write your questions one by one

[Tom mmeke]

You are missing the point of interfaces ...

public static void main(String[] args) {  
        // TODO Auto-generated method stub  
        tester t = new aer();  
        t.t.equals("");  

        testing t = new aer();
        t.t.equals("");
  
    } 

The above shows you why the comiler compiles even when you implement the same method multiple times.
The real question is, why are you defining interfaces, if you call the method from the aer class directly anyway ?

[Rauhl Roy]

Tom mmeke wrote:You are missing the point of interfaces ...

public static void main(String[] args) {  
        // TODO Auto-generated method stub  
        tester t = new aer();  
        t.t.equals("");  

        testing t = new aer();
        t.t.equals("");
  
    } 

The above shows you why the comiler compiles even when you implement the same method multiple times.
The real question is, why are you defining interfaces, if you call the method from the aer class directly anyway ?

I thik he is trying to bypass the Java specifications? may i know is it correct?