4

According to The Java Language Specification, Java SE 16 Edition (JLS) §9.2 Interface Members:

If an interface has no direct superinterface types, 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 (§4.3.2), unless an abstract method with the same signature, same return type, and a compatible throws clause is explicitly declared by the interface.

Why does any top-level Interface “implicitly” declare the public methods of the Object class? What is the purpose of this design?

Basil Bourque
  • 303,325
  • 100
  • 852
  • 1,154
theutonium.18
  • 483
  • 2
  • 7
  • Everything is an `Object`. – Mike 'Pomax' Kamermans Aug 21 '21 at 16:49
  • @Mike'Pomax'Kamermans Which is not true for Java, look at this answer: https://stackoverflow.com/a/11844096 – Benjamin M Aug 21 '21 at 17:00
  • I know it is like this, but I have not found a compelling reason for me why this choice was made in this manner. What I dislike the most is the lack of restriction like this: `Set extends InterfactWithHashCodeAndEquals>`. You can't do this at compile time, so you can pass _any_ Object into a set. Even if they did not override `equals/hashCode` _on purpose_. Or the fact that _any_ object can be used as a synchronizer – Eugene Aug 21 '21 at 17:28
  • @Eugene yep, for better or for worse. All programming languages have quirks, some more fundamental than others. However, rememeber: generics _didn't even exist_ in Java until 2004, when Java had already been around for over a decade. It was something added to the language more than ten years after the fundamentals had already been firmly and irrevocably established. – Mike 'Pomax' Kamermans Aug 21 '21 at 18:22

2 Answers2

3

What is the purpose of this design?

Because you want to be able to call all the Object methods ( toString, equals, hashCode, and such) on every object of any type.

interface Foo {
  
}

Foo foo = ...;

foo.equals(otherFoo);

Doesn't matter if I actually declared the equals method in the interface.

Basil Bourque
  • 303,325
  • 100
  • 852
  • 1,154
Benjamin M
  • 23,599
  • 32
  • 121
  • 201
  • But the JLS states that these methods are not inherited from the Object class - then how will it be useful? The class when implementing interface always inherits the method override definition from the Superclass rather than SuperInterface - so it is ultimately definition of Object class that will operate for any top level class only implementing an interface and not extending any other class explicitly As mentioned [here](https://docs.oracle.com/javase/specs/jls/se8/html/jls-9.html#:~:text=First%2C%20methods%20inherited,the%20class%20hierarchy.). – theutonium.18 Aug 21 '21 at 17:12
  • @theutonium.18 As you can see: I don't use any class. I access the `equals` method of the interface, which is implicitly given and the execution is propagated to the actual implementation. Interfaces provide a layer of abstraction and those implicit methods are there to make out lives easier. Imagine you had to add `toString` to every interface where you want to use it. If that would be the case, I would have switched to another language because it's too much boilerplate code to write. – Benjamin M Aug 21 '21 at 17:17
  • But then using this concept - how will you explain the invocation of `final` methods that are inherited from the `Object` class? – theutonium.18 Aug 21 '21 at 17:20
  • I don't understand the question. Interfaces do **not** inherit from `Object` class. They just implicitly provide the same methods, that propagate to the actual implementation. You should see it like this: Interfaces are just an abstraction that should make developers lives easier. You could create a copy of the Java language and remove interfaces completely, it will still work the same as with interfaces, but it will make development (and especially refactoring) harder. Interfaces are just a another layer to hide implementation details and group classes with common behavior. – Benjamin M Aug 21 '21 at 17:30
  • Thanks a lot Benjamin .. I got the sense of your answer - it is basically to make sure that methods of Object class are made accessible to all the subclasses - that implicitly interface adds the public methods of the `Object` class. – theutonium.18 Aug 21 '21 at 18:37
  • Right. And it's also "convenience": Similar to "every class extends Object". The Java devs could have made this explicit, so you had to write `extends Object` for every class. The same applies for interfaces: They could have made this explicit, too, so you had to add all `Object` methods to every interface. Both cases would have been a pretty boring writing exercise. And there are many more cases with similar behavior, like when you `extends XYZ`, you don't have to repeat all the method definitions, it's done implicitly for you. High level programming was made to write and repeat **less** code – Benjamin M Aug 21 '21 at 18:46
  • I think your comments address the question better than the answer, but still, it correctly addresses it nevertheless. I sometimes (with my limited lenses on jdk), wish that neither the interfaces nor objects would have these common methods. 1+. – Eugene Aug 21 '21 at 19:33
  • @Eugene I guess without those "default" methods lot's of Java frameworks wouldn't work properly, or get much slower due to heavy use of reflection. I'd say at least `getClass` is really mandatory. In the past 20 years the Java dev realized that some decisions from the past weren't the best. That's why `finalize` get's deprecated in Java 17. But on the other hand Java made a promise 25 years ago: Backwards compatibility. You still should be able to run code from 1996 on your current JVM. That's why they can't change the whole language and ecosystem with every release like other languages do. – Benjamin M Aug 21 '21 at 19:55
  • Also found this related question : https://stackoverflow.com/questions/2408730/how-methods-of-object-class-be-visible-through-interface – theutonium.18 Aug 22 '21 at 07:34
1

Every class is implicitly a subclass of Object

See: https://docs.oracle.com/javase/tutorial/java/IandI/subclasses.html for more

Definitions: A class that is derived from another class is called a subclass (also a derived class, extended class, or child class). The class from which the subclass is derived is called a superclass (also a base class or a parent class).

Excepting Object, which has no superclass, every class has one and only one direct superclass (single inheritance). In the absence of any other explicit superclass, every class is implicitly a subclass of Object.

Classes can be derived from classes that are derived from classes that are derived from classes, and so on, and ultimately derived from the topmost class, Object. Such a class is said to be descended from all the classes in the inheritance chain stretching back to Object.

Basil Bourque
  • 303,325
  • 100
  • 852
  • 1,154
balderman
  • 22,927
  • 7
  • 34
  • 52
  • But if you consider (JLS:9.4.1.2): Second, interfaces do not inherit from Object, but rather implicitly declare many of the same methods as Object (§9.2). So, there is no common ancestor for the toString declared in Object and the toString declared in an interface. At best, if both were candidates for inheritance by a class, they would conflict. Working around this problem would require awkward commingling of the class and interface inheritance trees. – theutonium.18 Aug 21 '21 at 16:57
  • @Basil - I think based on the artilcle extract I mentioned above - why is it being mentioned that both do not need to have common ancestors? – theutonium.18 Aug 21 '21 at 16:59
  • Here is the link to the excerpt : [link](https://docs.oracle.com/javase/specs/jls/se8/html/jls-9.html#:~:text=Second%2C%20interfaces%20do,interface%20inheritance%20trees.). Please use Chrome browser for it to highlight exact portion. – theutonium.18 Aug 21 '21 at 17:01
  • I don't understand this answer at all. The question is : "why **interfaces**..." and your answer is : "every **class**...", that you even highlight. This makes no sense. – Eugene Aug 21 '21 at 17:34
  • 1
    @Eugene Now I see the point made by you and theutonium.18. My first reading was too fast and shallow. I now agree this Answer does not actually address the Question with regard to *interfaces* rather than *classes*. – Basil Bourque Aug 21 '21 at 19:27
  • @BasilBourque right. the other, accepted answer, is correct, imo. – Eugene Aug 21 '21 at 19:31