• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

Inheritance question - Interfaces

 
Bartender
Posts: 543
4
Netbeans IDE Redhat Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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?
 
Bartender
Posts: 4568
9
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.
 
Ranch Hand
Posts: 247
Eclipse IDE Chrome Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Bartender
Posts: 543
4
Netbeans IDE Redhat Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.
 
Sheriff
Posts: 22783
131
Eclipse IDE Spring VI Editor Chrome Java Windows
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.
 
Ram Narayan.M
Ranch Hand
Posts: 247
Eclipse IDE Chrome Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Posts: 4568
9
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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!
 
Ranch Hand
Posts: 173
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Bartender
Posts: 543
4
Netbeans IDE Redhat Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Posts: 173
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Dieter,

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

Thanks for posting the question.
 
Rancher
Posts: 3742
16
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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
Ranch Hand
Posts: 173
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Posts: 543
4
Netbeans IDE Redhat Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Posts: 3742
16
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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
Posts: 173
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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 ?



 
Author
Posts: 12617
IntelliJ IDE Ruby
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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
Posts: 4568
9
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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
Posts: 12617
IntelliJ IDE Ruby
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.
 
Sheriff
Posts: 7135
1360
IntelliJ IDE jQuery Eclipse IDE Postgres Database Tomcat Server Chrome Google App Engine
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Bartender
Posts: 4568
9
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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.
 
Greenhorn
Posts: 8
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Author
Posts: 12617
IntelliJ IDE Ruby
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
@Matthew: Oh, I see what you're saying now--I missed the "a" in your original sentence.
 
Avishkar Nikale
Ranch Hand
Posts: 173
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Can the moderators end this topic as resolved with proper resolution provided in the last post ?
 
Master Rancher
Posts: 4806
72
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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
Posts: 12617
IntelliJ IDE Ruby
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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


Why?
 
Dieter Quickfend
Bartender
Posts: 543
4
Netbeans IDE Redhat Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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"
 
Rancher
Posts: 280
VI Editor C++ Debian
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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
Rancher
Posts: 280
VI Editor C++ Debian
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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
Master Rancher
Posts: 4806
72
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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
Posts: 280
VI Editor C++ Debian
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Master Rancher
Posts: 4806
72
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Posts: 543
4
Netbeans IDE Redhat Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Master Rancher
Posts: 4806
72
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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?
 
Ranch Hand
Posts: 276
Netbeans IDE Chrome Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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?
 
Ranch Hand
Posts: 1051
Eclipse IDE Firefox Browser
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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"
 
David Newton
Author
Posts: 12617
IntelliJ IDE Ruby
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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
Posts: 1051
Eclipse IDE Firefox Browser
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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
 
permaculture is giving a gift to your future self. After reading this tiny ad:
a bit of art, as a gift, that will fit in a stocking
https://gardener-gift.com
reply
    Bookmark Topic Watch Topic
  • New Topic