• 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
  • Ron McLeod
  • Rob Spoor
  • Tim Cooke
  • Junilu Lacar
Sheriffs:
  • Henry Wong
  • Liutauras Vilda
  • Jeanne Boyarsky
Saloon Keepers:
  • Jesse Silverman
  • Tim Holloway
  • Stephan van Hulst
  • Tim Moores
  • Carey Brown
Bartenders:
  • Al Hobbs
  • Mikalai Zaikin
  • Piet Souris

Why an interface can declare Object methods...

 
Saloon Keeper
Posts: 1317
40
Eclipse IDE Postgres Database C++ Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I was reviewing tricky interface details yesterday and this morning.

Something that came up before and I didn't understand at the time, the fact that interfaces can declare Object methods, why would they ever do that?

Joke Answer: To make hard, tricky OCJP questions.

Real Answer: To force implementers of the interface to declare an override of the one inherited from Object because it is believed by the interface creator that the one from Object can't be relied on by implementers of the interface:

Relevant sections in the JLS (version 17):
8.4.3.1
9.4.1.2

Many better tutorials remind us that Interfaces can declare abstract versions of Object methods, and that it doesn't count towards the total of ONE that we want to see for a valid FunctionalInterface.

But none that I remember seeing went that extra little step and reminded you why this would be anything but a combination of "It is legal" and maybe being tired, drunk or confused.

The real use case is "Yeah, everyone gets one from Object, but that one isn't going to give implementers of this interface reliable behavior.  You at least must define one that does the same thing if that is actually what you want, or define a better one."

Pretty subtle, and I kept it in the back of my mind until I tripped over something in the JLS whilst looking for something else.
 
Saloon Keeper
Posts: 13280
292
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
The interesting thing about this is that it only works for methods inherited from Object.

If you have an interface that declares the same methods as an unrelated class, and you have another class that both extends the first class and implements the interface, it will use the inherited methods to implement the interface:

The TaxiDriver class uses Driver.drive(Car) to implement Chauffeur.drive(Car), although the Chauffeur and Driver types are unrelated.

In contrast, although all objects derive from Object, they can't use Object's methods to implement an interface that declares the same methods. At least, not without redeclaring the method and calling super.
 
Jesse Silverman
Saloon Keeper
Posts: 1317
40
Eclipse IDE Postgres Database C++ Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Right.  This is because they essentially use this to specifically invalidate the "default" implementations inherited from Object, not to disturb any others.

It is a minor weirdness that comes from having these useful default methods for every single class ever from Day One of Java.

I know people have discussed "Don't we wish they weren't there!" about many of them, because most such functionality *could have been* implemented in some other manner, but we are stuck with them for the rest of eternity in Java, I am pretty sure, and understanding the implications of this, sometimes subtle, is good if you want no nasty surprises in your Java programs...
 
Marshal
Posts: 74048
332
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
The three overridable public method from Object can be declared as non‑abstract methods in interfaces.
The two overridable protected method from Object can be declared as abstract methods in interfaces.
The other six methods can't be overridden and therefore can't be declared in interfaces at all.
 
Rancher
Posts: 162
5
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Maybe worth splitting into its own topic:

Although I understand what copy does and the differences between a shallow copy and a deep copy I wonder why it's part of Object if it still requires a class that wants to support it to implement Cloneable, which in itself is only a marker Interface that controlls the specific operation of Object.clone().
As the doc states "all arrays considered cloneable" is it just a work-around to make T[].clone() possible even when T itself doesn't implement cloneable itself?
Guess that's one of the compromises that had to be made when it was decided that an array is also seen as an object, even an array of primitives.
On the other side I'm not sure about how I would deal with this when Java would had been designed differently.
 
Campbell Ritchie
Marshal
Posts: 74048
332
  • Likes 1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Go through a book like Effective Java by Joshua Bloch about clone(). The clone() method is an example of one of the things done in the earliest days of Java® which nobody would do like that nowadays, and which nobody can change for fear of breaking old code (=backwards compatibility).

Matthew Bendford wrote:. . . "all arrays considered cloneable" is it just a work-around to make T[].clone() possible even when T itself doesn't implement cloneable itself? . . ..

No, the JLS (=Java┬« Language Specification) says that all arrays behave as if they were marked Cloneable, and all have an overridden clone() method. That returns a shallow clone of the array, so it isn't cloning a T, but only the T[].
 
Screaming fools! It's nothing more than a tiny ad:
Thread Boost feature
https://coderanch.com/t/674455/Thread-Boost-feature
reply
    Bookmark Topic Watch Topic
  • New Topic