Does an interface extend Object?

[Alan Heebson]

I think I remember reading somewhere that an Interface does not have a constructor. Does this mean that interfaces do not extend from Object?

[fred rosenberger]

as far as i know, an interface is not an object, so it does not extend Object.

an interface is nothing more than a contract that states what methods must exist in an object. you don't create something that is an interface, you create an object of some kind that meets the requirements of the interface.

[Alan Heebson]

Thanks Fred

[marc weber]

You might then wonder how you can upcast a reference to an interface type, and still use that reference to call methods defined in Object.

The answer is in JLS 9.2 - Interface Members, which explains that an interface having no direct superinterfaces implicitly declares a public abstract method for each public instance method in Object.

[Niranjan Welankiwar]

If interface does not extends Object class then can please someone explain me the below code :

1.
interface a{

@Override
public int hashCode();

@Override
public String toString();

}


In above case, "a" interface is the new interface declared. Yet, no class is implementing it. Then how come the methods from Objects class methods are visible in interface ?

2.

If it doesn't extends Object class, then why I can't declare below method in interface ?

public Class getClass();

When I tried to declare this method in interface, it says cannot override from Object class as it is declared as final method in Object class.

Got confused . Please someone explain.

[Jeff Verdegan]

Niranjan Welankiwar wrote:If interface does not extends Object class then can please someone explain me the below code :
In above case, "a" interface is the new interface declared. Yet, no class is implementing it. Then how come the methods from Objects class methods are visible in interface ?
...
When I tried to declare this method in interface, it says cannot override from Object class as it is declared as final method in Object class.

Read Marc Weber's post from 2007, right above yours.

[Helen Ma]

Hi, according to KB, you can see interface as a 100% abstract class. An abstract class has at least one method declaration without any implementation. For interface, it must have all methods declaration without any implementation.
So, if an abstract class extends Object, an interface can also overrides the toString / equals/ hashCode methods from Objects.

[Joanne Neal]

Helen Ma wrote:An abstract class has at least one method declaration without any implementation.

No it doesn't. You can have an abstract class with no abstract methods.

Helen Ma wrote:So, if an abstract class extends Object, an interface can also overrides the toString / equals/ hashCode methods from Objects.

Despite what it says in KB, a 100% abstract class and an interface are not the same thing.
As Marc said above, interfaces that don't extend another interface implicitly include abstract definitions of all the public methods in the Object class.

[Yalvin Duha]

Niranjan Welankiwar wrote:If interface does not extends Object class then can please someone explain me the below code :

1.
interface a{

@Override
public int hashCode();

@Override
public String toString();

}

In above case, "a" interface is the new interface declared. Yet, no class is implementing it. Then how come the methods from Objects class methods are visible in interface ?

2. If it doesn't extends Object class, then why I can't declare below method in interface ?

public Class getClass();

When I tried to declare this method in interface, it says cannot override from Object class as it is declared as final method in Object class.

I'm glad I read some of these posts, because there are nitpicks that personally I've never thought about before. And generally, it forces you to dig a bit deeper, and that's great for the exam.

An interface does not extend anything; it's not a class and therefore it does not implicitly extend Object. Nonetheless, every other class does which perhaps prompted the language specification writers to take into account situations where the user explicitly creates an interface that includes Object's method, presumably to force the interface type (implementation) to implement them, which by in itself is unnecessary, because after all, every class is an Object, and therefore inherits all those methods automatically.

So, for such scenarios, as it was mentioned before, the spec people thought it's better to catch any misgiving at the compile-time. This is an excerpt from the Java Language Specification 7 on interface members (http://docs.oracle.com/javase/specs/jls/se7/html/jls-9.html#jls-9.2):

If an interface has no direct superinterfaces, then the interface implicitly declares a public abstract member method m with signature s, return type "r", and throws clause t corresponding to each public instance method m with signature s, return type "r", and throws clause t declared in Object, unless a method with the same signature, same return type, and a compatible throws clause is explicitly declared by the interface.

It is a compile-time error if the interface explicitly declares such a method m in the case where m is declared to be final in Object.

It follows that is a compile-time error if the interface declares a method with a signature that is override-equivalent (§8.4.2) to a public method of Object, but has a different return type or incompatible throws clause.

There are three types of visibility and accessibility designated to methods in Object class: non-final public, final, and protected.

For obviously reasons, final methods, i.e. wait()'s, notify()'s, and getClass(), cannot be implemented by a class that implements such interface. Consequently, the compiler must prevent the code from declaring such methods in the interface.

The non-final public methods can be declared in the interface with the proper preservation of overriding rules. They do not, however, need to be implemented by any subtype class, because, again, every class is implicitly an Object.

Finally, we have protected methods, i.e. clone() and finalize(). If you declare such methods in your interface, it becomes implicitly public abstract static. However, in the implementing class, since the overridden methods declared in the interface are "public", you've narrowed the accessibility from Object's protected to YourInterface's public, therefore you're obligated to keep visibility at public level in your implementing class as well. Consequently, you must define these two methods, i.e. clone() and finalize(), explicitly with a public modifier.

public interface ObjInf {

  /*
   * Non-final methods:
   */
  String toString();
  boolean equals(Object o);

  /*
   * Final methods:
   */
  // wait() throws InterruptedException;
  // notify();

  /*
   * Protected methods:
   */
  void finalize() throws Throwable;
  // Number is an Object (covariant return type) permitted in 1.5 and above
  Number clone() throws CloneNotSupportedException;

}

public class ObjImp implements ObjInf {

  public String toString() { } // not necessary because ObjImp inherits it from Object

  /*
   * Both finalize() and clone() must be implemented because an implicitly widen visibility
   * done by ObjInf (protected in Object to public in ObjInf) would be considered hidden
   * since ObjImp is a subtype of ObjInf.
   */
  public void finalize() throws Throwable {
    super.finalize();
  }

  // We narrowed down the return type again, but an Integer is a Number, 
  // and reflexively, since Number is an Object, then an Integer is also an Object, duh!
  public Integer clone() throws CloneNotSupportedException {
    return null;
  }

}

[saloni jhanwar]

Supplement

[gurpeet singh]

very nice explanation yalvin