Inheritance question - Interfaces

[Dieter Quickfend]

So... because you can implicitly cast any interface reference to an Object reference, we can assume that an interface IS-A Object.

But Object is a class, can be instantiated, while an interface can only extend interfaces.

What gives? How is this possible? Is it a loophole so everything would be an Object, and interfaces don't really extend Objects, or is there a workaround to have an interface extend an Object?

for instance, is there a way you could say:

public interface MyInterface extends MyObject {}

I'm assuming not... But that would mean interfaces aren't really Objects, which would make it so that "Object o = myInterfaceReference;" should be a compiler error. But it's not.

So basically, what I mean to ask is; is there a way to have a self-made class mimic Object in a way so that it can parent an interface without being one itself?

[Matthew Brown]

Interfaces don't extend Objects. But you can never have a "pure" instance of an Interface. You only ever have an instance of a class that implements the interface - and this class will extend Object. So a cast to an Object can always be guaranteed to be safe.

[Ram Narayan.M]

Why Object o = myInterfaceReference is!!!

The class which implements "myInterfaceReference" definitely a sub-class of Object class... So no need of explicit type-casting to Object.

If interfaces were designed in case of extending the Object class, then we would not have got chance of implementing multiple interfaces...

[Dieter Quickfend]

I'm confused. In an exam I took, I think it was the ExamLab diagnostic, there was a question that said "An Interface IS-A Object", and my answer was false because obviously, an interface cannot inherit from a class. My answer was wrong, and the explanation said an Interface really IS-A Object, because any interface reference can be assigned to an Object.

Then from your explanation I must assume that that question was actually wrong and my initial answer was right. Or else I'm missing something.

[Rob Spoor]

java.lang.Object is the base type of all classes. Not of interfaces, as this little program shows:

public class Test
{
    public static void main(String[] args) throws Exception
    {
        Class<?> cls = java.util.List.class;
        while (cls != null)
        {
            System.out.println(cls);
            cls = cls.getSuperclass();
        }
    }
}

However, as mentioned, any instance that will ever be created is an instance of a concrete class, so it will be assignable to Object. Even if you reference it through an interface type, it is still instance of some class.

[Ram Narayan.M]

I also followed ExamLab... Explanation was clear... Explanation is like Interface "IS-A" Object... You can see double quoted "IS-A"... That is "Interface" type reference variable referring to class implementing it, can be directly assigned to "Object" type references variable since classes implementing interfaces is a sub-class Of Object... So no need of explicit typecasting...

Its not the meaning that "Interfaces implicitly extends Object"...

[Matthew Brown]

Dieter Quickfend wrote:I'm confused. In an exam I took, I think it was the ExamLab diagnostic, there was a question that said "An Interface IS-A Object", and my answer was false because obviously, an interface cannot inherit from a class. My answer was wrong, and the explanation said an Interface really IS-A Object, because any interface reference can be assigned to an Object.

I must admit, I don't like that wording, if that's exactly how it was. I'd be happier with something like: "If T is an interface, then a T IS-A Object", because that way it makes it clear that the IS-A relationship is referring to instances of T. But you're probably just going to have to accept their interpretation of what they meant!

[Avishkar Nikale]

My take is

At runtime the instance pointed by the interface reference is always and I repeat ALWAYS going
to be an instance of a class (that can be casted to java.lang.Object one way or the other).

Even if it is anonymous, it will still be extending java.lang.Object.

So the implicit cast does not fail since at runtime the reference will be pointing to an java.lang.Object or its subtype.

About the Examlab question, I agree with Matthew.

[Dieter Quickfend]

So

  
interface A{}
interface B extends A{}
public class C implements B{

public static void main(String... args){

A a = new C();
B b = a;
}
}
  

The only reason this doesn't work is because you can extend A directly, thus A can have Objects that aren't of type B?
So if there were a way to make sure that A can have only one direct child, B b = a; would be legal by the compiler, because it would know that an object of type B would always be an object of type A?


@Ram Narayan

I also followed ExamLab... Explanation was clear... Explanation is like Interface "IS-A" Object... You can see double quoted "IS-A"... That is "Interface" type reference variable referring to class implementing it, can be directly assigned to "Object" type references variable since classes implementing interfaces is a sub-class Of Object... So no need of explicit typecasting...

But that's exactly what I said, and that explanation is definitely not "clear" to me. The "IS-A" relationship in object oriented programming means that type1 is the same type or a subtype of type2. Now an interface is not an Object, nor is it a subtype of Object, which means that it doesn't have an "IS-A" relationship to Object.

So interfaces do NOT have an IS-A relationship to Object, but the compiler recognizes that every INSTANCE must be a subtype of Object, and therefore it allows you to assign it without an explicit cast (which you couldn't do anyway, because then it is also true that no interface has a direct relation to class Object - no supertype, no subtype).

Therefore, in my humble opinion, ExamLab is wrong if it claims "MyInterface IS-A Object", because the casting to Object has nothing to do with inheritance, and an interface has no inheritance relationship to Object, it's just an allowance Java makes.

Unless you all are wrong and interfaces DO extend Object, which would bring us back to the initial post.

[Avishkar Nikale]

Dieter,

I suggest you drop an Private Message to Devaka to see what the rationale might be.

Thanks for posting the question.

[Joanne Neal]

Dieter Quickfend wrote:Is it a loophole so everything would be an Object, and interfaces don't really extend Objects

Something like that. All interfaces that don't extend another interface implicitly include an abstract declaration of all public methods contained in the Object class.
That is why you can call toString (for example) on an interface reference. The inteface implicitly includes an abstract toString declaration that matches the toString declaration in Object.

[Avishkar Nikale]

Joanne,

I suspect that the compiler allows the same because it knows that at runtime the reference
will finally be pointing to an Object or its subtype.

Please note that interface as a concept has little to do with inheritance.
It just acts as a behavior guaranteed to be exposed publicly.

So it would be conceptually also wrong to say that an interface is subtype of class Object.

[Dieter Quickfend]

I think my confusion stems from this:

   
public interface MyInterface {}

//Explicit class definition
public class MyClass implements MyInterface{}

//Implicit class definition
public class MyClass extends Object implements MyInterface{}
 

So, MyClass IS-A MyInterface
And MyClass IS-A Object

But MyInterface... is no Object.

Therefore, MyInterface IS-A Object is only true if by "IS-A", you mean that the instanceof operator will return true if a reference variable of type MyInterface were compared to Object. Which, if Object were any other class than Object, it wouldn't. But that has nothing to do with the interface itself, but with the fact that all instances extend Object.

[Joanne Neal]

Avishkar Nikale wrote:I suspect that the compiler allows the same because it knows that at runtime the reference
will finally be pointing to an Object or its subtype.

No. What I described is actually what happens. I should have included a link in my post. See the Java Language Specification Section 9.2

[Avishkar Nikale]

Joanne,

The link is very helpful. Thanks for the same.

So can we conclude that the guidelines for an interface imply ensuring Object class behavior is not broken
but the "interface" as a construct itself IS-NOT-A Object ?

[David Newton]

Matthew Brown wrote:I'd be happier with something like: "If T is an interface, then a T IS-A Object", because that way it makes it clear that the IS-A relationship is referring to instances of T.

But your wording is just as unclear. If T is an *implementation* of an interface [...] removes the ambiguity.

[Matthew Brown]

David Newton wrote:

Matthew Brown wrote:I'd be happier with something like: "If T is an interface, then a T IS-A Object", because that way it makes it clear that the IS-A relationship is referring to instances of T.

But your wording is just as unclear. If T is an *implementation* of an interface [...] removes the ambiguity.

I think I'm happy with my original, thanks. It follows the convention of saying things like "a is a List". Given that, I think it's unambiguous enough. What other meaning could it have?

[David Newton]

It could mean that T is an interface.

public interface T {
    ...
}

T isn't an object, it's an interface. An instance of an implementation of T is an object.

[Devaka Cooray]

Conceptually, an interface is a compile-time prototype only. In the scope of SCJP, questions may target on has-a relationship between Object class and an interface-implementer, or compile time issues with Object and interfaces within the domain of reference types. Considering the fact that "Interface IS-A Object" , that could be misleading, to some extent.

My sense is that this question should be changed accordingly if it was not already changed with the beta-evolution.
If someone can specify the question number, that would be helpful as I do not have the question database right now.

Devaka

[Matthew Brown]

David Newton wrote:It could mean that T is an interface.

public interface T {
    ...
}

T isn't an object, it's an interface. An instance of an implementation of T is an object.

But if T is an interface, then *a* T is an object. In the same way that *an* Object is an object. I'd argue that the usual convension would be that "a <classname>" == "an instance of <classname>", and "a <interface>" == "an instance of an implementation of <interface>".

It's probably not worth worrying about, though.

[Sriram Naga]

An Interface IS-A Object can be misleading as many said above.

An Interface has no state and can't be instantiated.

Maybe the ExamLab question was referring to.. "An Interface reference IS-A Object", which surely is, since it refers to the instance of the class which implements the interface in question.

[David Newton]

@Matthew: Oh, I see what you're saying now--I missed the "a" in your original sentence.

[Avishkar Nikale]

Can the moderators end this topic as resolved with proper resolution provided in the last post ?

[Mike Simmons]

Sriram Gsn wrote:An Interface has no state

Not quite true. And by odd coincidence, this was the basis for a bug I fixed just yesterday. I leave this (for now) as a challenge for readers: when does an interface have state? No, I'm not talking about state in a class that implements the interface. I'm talking about state in the interface itself.

Note that this has very little to do with the original question. But since that question is done and we're still here ;), I raise the question anyway.

[David Newton]

Avishkar Nikale wrote:Can the moderators end this topic as resolved with proper resolution provided in the last post ?

Why?

[Dieter Quickfend]

Sriram Gsn wrote:Maybe the ExamLab question was referring to.. "An Interface reference IS-A Object", which surely is, since it refers to the instance of the class which implements the interface in question.

That will not work either, as an interface reference is a variable, not an Object.

What will work, is "the instance pointed to by an interface reference IS-A Object"

[Anand Hariharan]

Mike Simmons wrote:

Sriram Gsn wrote:An Interface has no state

Not quite true. (...) I leave this (for now) as a challenge for readers: when does an interface have state? No, I'm not talking about state in a class that implements the interface. I'm talking about state in the interface itself.

I'll bite. So when does an interface have a state? I expect your explanation will hold water to your statement "not talking about state in a class that implements the interface, [but] in the interface itself".

[Anand Hariharan]

Matthew Brown wrote:I'd argue that the usual convension would be that "a <classname>" == "an instance of <classname>", and "a <interface>" == "an instance of an implementation of <interface>".

Given the very nature of what this thread's about and the discussion it generated , I'd agree with "a <classname>" == "an instance of <classname>" and disagree with "a <interface>" == "an instance of an implementation of <interface>".

Matthew Brown wrote:It's probably not worth worrying about, though.

I'd agree with that!

[Mike Simmons]

Anand Hariharan wrote:

Mike Simmons wrote:

Sriram Gsn wrote:An Interface has no state

Not quite true. (...) I leave this (for now) as a challenge for readers: when does an interface have state? No, I'm not talking about state in a class that implements the interface. I'm talking about state in the interface itself.

I'll bite. So when does an interface have a state? I expect your explanation will hold water to your statement "not talking about state in a class that implements the interface, [but] in the interface itself".

I would hope so, since that's what I just said.

The issue is with fields in interfaces. Such fields are implicitly public, static, and final, and they must be initialized where they are declared. So they are much like constants, and we tend to think of them that way. But there is no requirement that the field needs to refer to an immutable object. For primitive fields, this isn't a problem. A final primitive is immutable and therefore stateless, no problem. But a final reference variable can easily refer to a mutable object that does have state.

This, for example, is perfectly legal (if obviously silly):

public interface MyInterface {
  StringBuilder myField = new StringBuilder();
}

There's mutable, stateful data, right there in the interface.

One could argue that the state isn't really in the interface, but in the mutable type that the interface field references. That's true. Depending on how you interpret "state in the interface itself", you might argue that my earlier statement is misleading. But my point is that the state is not in some other class that implements the interface. It's in something declared inside the interface itself. Something that would surprise most people.

The example I saw yesterday was more subtle than the StringBuilder example above. It was more like this:

public interface Foo {
  ...

  EnumSet<State> ALLOWED_STATES = EnumSet.of(STATE_A, STATE_B, STATE_C);
}

And elsewhere there was code that did something like this:

EnumSet allowed = Foo.ALLOWED_STATES;
if (conditionA)
  allowed.remove(STATE_A);
if (conditionB)
  allowed.remove(STATE_B);

The intent here was to modify the currently-allowed states, based on current conditions. The problem was that the code here was actually modifying the original (only) copy of ALLOWED_STATES. People were thinking of it as an immutable object (because it was inside an interface and had a NAME_IN_ALL_CAPS like a proper constant), where we were modifying a local copy or something. But that was not the case. I fixed it by moving the set of ALLOWED_STATES outside of the interface and into a private static final field, and inserting a call to clone():

EnumSet allowed = Foo.ALLOWED_STATES.close();

[Anand Hariharan]

Sorry to disappoint you, Mike -- With all that second guessing where I might counter or argue, I am in full agreement with you. Thank you for the patient explanation.

Mike Simmons wrote:The issue is with fields in interfaces. Such fields are implicitly public, static, and final, and they must be initialized where they are declared.

This would be where I chip in like Zellweger to say "Just shut up; you had me at hello". I didn't know Java allowed object references as fields in interfaces! This makes the distinction between abstract classes and interfaces slightly blurry (except perhaps the fields in abstract classes don't have to be final).

Mike Simmons wrote:So they are much like constants, and we tend to think of them that way. But there is no requirement that the field needs to refer to an immutable object. For primitive fields, this isn't a problem. A final primitive is immutable and therefore stateless, no problem. But a final reference variable can easily refer to a mutable object that does have state.

I consider this to be a defect (or at best a very annoying quirk) of Java. Gosling et al. reserved 'const' but decided not to use it. Instead they chose to overload 'final' with different meanings at different contexts. I miss the ability that C++ has to advertise that a method shall not modify a class' contents. This way, the compiler would catch a method not flagged as such, being called on a reference that is final.

EnumSet allowed = Foo.ALLOWED_STATES.close();

Do you use a Dvorak keyboard?

[Mike Simmons]

Umm, no. (I did once hit Bill Dvořák with a perfectly-aimed oarful of water while rafting on the Dolores River in Colorado, just before we all entered rapids that denied him any chance to respond. But I digress...) I just use close() much more often than clone(). Really, I think I use clone() less than once a year (outside of theoretical discussions at least) and this post was just after I actually had a use for it. And yet, I still didn't get it right. Oops.

Anand Hariharan wrote:I consider this to be a defect (or at best a very annoying quirk) of Java.

+++++++++!!!

So... errr... you don't happen to have a young and nubile sister, do you?

[Dieter Quickfend]

Correct me if I'm wrong, but, I am led to believe that, in Java, only instance members can be part of an object's state. As any field in an interface is implicitly static, it is acceptable to understand that in Java, an interface cannot have state. An interface can have a constant that, in its turn, has state, but it doesn't have state of itself.

[Mike Simmons]

Dieter Quickfend wrote:Correct me if I'm wrong, but, I am led to believe that, in Java, only instance members can be part of an object's state.

Well, instance members can be part of the state of each object, and class (static) members can be part of the state of the class.

Dieter Quickfend wrote:An interface can have a constant that, in its turn, has state, but it doesn't have state of itself.

I just showed that an interface can have a StringBuilder as a member. Have you tried it? Would you call that a constant? Or is it something else?

[Vinoth Kumar Kannan]

Dieter Quickfend wrote:... As any field in an interface is implicitly static, it is acceptable to understand that in Java, an interface cannot have state...

Static fields too must be a part of some state,right? (As in case of classes, they are part of the Class's state - as Mike said). So can we make an assumption that an interface has some state if it has variables(primitives/Objects..whatever)?

Dieter Quickfend wrote:... An interface can have a constant that, in its turn, has state, but it doesn't have state of itself.

Even though a constant has its own state(when it is an Object we are talking about),doesn't it still need to be present inside the interface's state, so that it is indicative that the constant belongs to that interface, rather than being orphan-like?

[Shanky Sohar]

Dieter Quickfend wrote:any interface reference can be assigned to an Object.

This is the whole point.Interface is not an object but we can point its refernce type to a the object of the class which implements it.

The instanceof operator (§15.20.2).
An expression whose type is a reference type may be tested using instanceof to find out whether the class of the object referenced by the run-time value of the expression is assignment compatible (§5.2) with some other reference type.

So you can say that reference type of the Interface can be assigned to a object of class which implements it..
but we cannot say that interface "ISA" Object

see the below code..

public interface Inter1 {
	void dostuff();
}

public class Inter11 implements Inter1 {
         public static void main(String[] args) {
		Inter1 i1=new Inter11();
		if(i1 instanceof Inter11){
			System.out.println("Passed");
		}

	}

}

The output will be "Passed"

[David Newton]

Shanky Sohar wrote:but we cannot say that interface "ISA" Object

Depends on how you're using it. Canonical usage of the term "is-a" *does* let you say "(instance of class that implements Foo) is-a Foo", since that's the point of interfaces.

[Shanky Sohar]

David Newton wrote:

Shanky Sohar wrote:but we cannot say that interface "ISA" Object

Depends on how you're using it. Canonical usage of the term "is-a" *does* let you say "(instance of class that implements Foo) is-a Foo", since that's the point of interfaces.

Yes that is correct