wood burning stoves 2.0*
The moose likes Java in General and the fly likes Inheritance question - Interfaces Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Java » Java in General
Bookmark "Inheritance question - Interfaces" Watch "Inheritance question - Interfaces" New topic
Author

Inheritance question - Interfaces

Dieter Quickfend
Bartender

Joined: Aug 06, 2010
Posts: 505
    
    4

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?


Oracle Certified Professional: Java SE 6 Programmer && Oracle Certified Expert: (JEE 6 Web Component Developer && JEE 6 EJB Developer)
Matthew Brown
Bartender

Joined: Apr 06, 2010
Posts: 4343
    
    8

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
Ranch Hand

Joined: Jul 11, 2010
Posts: 247

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...


SCJP 6 [SCJP - Old is Gold]
Dieter Quickfend
Bartender

Joined: Aug 06, 2010
Posts: 505
    
    4

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
Sheriff

Joined: Oct 27, 2005
Posts: 19651
    
  18

java.lang.Object is the base type of all classes. Not of interfaces, as this little program shows:
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.


SCJP 1.4 - SCJP 6 - SCWCD 5 - OCEEJBD 6
How To Ask Questions How To Answer Questions
Ram Narayan.M
Ranch Hand

Joined: Jul 11, 2010
Posts: 247

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
Bartender

Joined: Apr 06, 2010
Posts: 4343
    
    8

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
Ranch Hand

Joined: Aug 06, 2010
Posts: 173
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.


Regards,
Avishkar Nikale
Dieter Quickfend
Bartender

Joined: Aug 06, 2010
Posts: 505
    
    4

So


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
Ranch Hand

Joined: Aug 06, 2010
Posts: 173
Dieter,

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

Thanks for posting the question.
Joanne Neal
Rancher

Joined: Aug 05, 2005
Posts: 3426
    
  12
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.


Joanne
Avishkar Nikale
Ranch Hand

Joined: Aug 06, 2010
Posts: 173
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
Bartender

Joined: Aug 06, 2010
Posts: 505
    
    4

I think my confusion stems from this:



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
Rancher

Joined: Aug 05, 2005
Posts: 3426
    
  12
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
Ranch Hand

Joined: Aug 06, 2010
Posts: 173
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
Author
Rancher

Joined: Sep 29, 2008
Posts: 12617

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
Bartender

Joined: Apr 06, 2010
Posts: 4343
    
    8

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
Author
Rancher

Joined: Sep 29, 2008
Posts: 12617

It could mean that T is an interface.
T isn't an object, it's an interface. An instance of an implementation of T is an object.
Devaka Cooray
ExamLab Creator
Saloon Keeper

Joined: Jul 29, 2008
Posts: 3019
    
  35

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


Author of ExamLab ExamLab - a free SCJP / OCPJP exam simulator
What would SCJP exam questions look like? -- Home -- Twitter -- How to Ask a Question
Matthew Brown
Bartender

Joined: Apr 06, 2010
Posts: 4343
    
    8

David Newton wrote:It could mean that T is an interface.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
Greenhorn

Joined: Aug 24, 2010
Posts: 8
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.


[My Page] | [JavaRanch FAQ] | SCJP6

"I am not afraid of the storm, as I am learning to sail my ship"
David Newton
Author
Rancher

Joined: Sep 29, 2008
Posts: 12617

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

Joined: Aug 06, 2010
Posts: 173
Can the moderators end this topic as resolved with proper resolution provided in the last post ?
Mike Simmons
Ranch Hand

Joined: Mar 05, 2008
Posts: 2992
    
    9
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
Author
Rancher

Joined: Sep 29, 2008
Posts: 12617

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

Why?
Dieter Quickfend
Bartender

Joined: Aug 06, 2010
Posts: 505
    
    4

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
Rancher

Joined: Aug 22, 2006
Posts: 257

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".


"Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away." -- Antoine de Saint-Exupery
Anand Hariharan
Rancher

Joined: Aug 22, 2006
Posts: 257

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
Ranch Hand

Joined: Mar 05, 2008
Posts: 2992
    
    9
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):

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:

And elsewhere there was code that did something like this:

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():
Anand Hariharan
Rancher

Joined: Aug 22, 2006
Posts: 257

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.


Do you use a Dvorak keyboard?
Mike Simmons
Ranch Hand

Joined: Mar 05, 2008
Posts: 2992
    
    9
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
Bartender

Joined: Aug 06, 2010
Posts: 505
    
    4

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
Ranch Hand

Joined: Mar 05, 2008
Posts: 2992
    
    9
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
Ranch Hand

Joined: Aug 19, 2009
Posts: 276

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?


OCPJP 6
Shanky Sohar
Ranch Hand

Joined: Mar 17, 2010
Posts: 1051

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..



The output will be "Passed"


SCJP6.0,My blog Ranchers from Delhi
David Newton
Author
Rancher

Joined: Sep 29, 2008
Posts: 12617

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
Ranch Hand

Joined: Mar 17, 2010
Posts: 1051

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
 
 
subject: Inheritance question - Interfaces
 
Similar Threads
Multiple inheritance
Implicit properties of interface members...
calling Object class methods using an interface reference variable
Inner classes must extend?
can Interface Implement and extend?