Java8: Why is it forbidden to define a default method for a method from java.lang.Object
Solution 1
This is yet another of those language design issues that seems "obviously a good idea" until you start digging and you realize that its actually a bad idea.
This mail has a lot on the subject (and on other subjects too.) There were several design forces that converged to bring us to the current design:
- The desire to keep the inheritance model simple;
- The fact that once you look past the obvious examples (e.g., turning
AbstractList
into an interface), you realize that inheriting equals/hashCode/toString is strongly tied to single inheritance and state, and interfaces are multiply inherited and stateless; - That it potentially opened the door to some surprising behaviors.
You've already touched on the "keep it simple" goal; the inheritance and conflict-resolution rules are designed to be very simple (classes win over interfaces, derived interfaces win over superinterfaces, and any other conflicts are resolved by the implementing class.) Of course these rules could be tweaked to make an exception, but I think you'll find when you start pulling on that string, that the incremental complexity is not as small as you might think.
Of course, there's some degree of benefit that would justify more complexity, but in this case it's not there. The methods we're talking about here are equals, hashCode, and toString. These methods are all intrinsically about object state, and it is the class that owns the state, not the interface, who is in the best position to determine what equality means for that class (especially as the contract for equality is quite strong; see Effective Java for some surprising consequences); interface writers are just too far removed.
It's easy to pull out the AbstractList
example; it would be lovely if we could get rid of AbstractList
and put the behavior into the List
interface. But once you move beyond this obvious example, there are not many other good examples to be found. At root, AbstractList
is designed for single inheritance. But interfaces must be designed for multiple inheritance.
Further, imagine you are writing this class:
class Foo implements com.libraryA.Bar, com.libraryB.Moo {
// Implementation of Foo, that does NOT override equals
}
The Foo
writer looks at the supertypes, sees no implementation of equals, and concludes that to get reference equality, all he need do is inherit equals from Object
. Then, next week, the library maintainer for Bar "helpfully" adds a default equals
implementation. Ooops! Now the semantics of Foo
have been broken by an interface in another maintenance domain "helpfully" adding a default for a common method.
Defaults are supposed to be defaults. Adding a default to an interface where there was none (anywhere in the hierarchy) should not affect the semantics of concrete implementing classes. But if defaults could "override" Object methods, that wouldn't be true.
So, while it seems like a harmless feature, it is in fact quite harmful: it adds a lot of complexity for little incremental expressivity, and it makes it far too easy for well-intentioned, harmless-looking changes to separately compiled interfaces to undermine the intended semantics of implementing classes.
Solution 2
It is forbidden to define default methods in interfaces for methods in java.lang.Object
, since the default methods would never be "reachable".
Default interface methods can be overwritten in classes implementing the interface and the class implementation of the method has a higher precedence than the interface implementation, even if the method is implemented in a superclass. Since all classes inherit from java.lang.Object
, the methods in java.lang.Object
would have precedence over the default method in the interface and be invoked instead.
Brian Goetz from Oracle provides a few more details on the design decision in this mailing list post.
Solution 3
To give a very pedantic answer, it is only forbidden to define a default
method for a public method from java.lang.Object
. There are 11 methods to consider, which can be categorized in three ways to answer this question.
- Six of the
Object
methods cannot havedefault
methods because they arefinal
and cannot be overridden at all:getClass()
,notify()
,notifyAll()
,wait()
,wait(long)
, andwait(long, int)
. - Three of the
Object
methods cannot havedefault
methods for the reasons given above by Brian Goetz:equals(Object)
,hashCode()
, andtoString()
. -
Two of the
Object
methods can havedefault
methods, though the value of such defaults is questionable at best:clone()
andfinalize()
.public class Main { public static void main(String... args) { new FOO().clone(); new FOO().finalize(); } interface ClonerFinalizer { default Object clone() {System.out.println("default clone"); return this;} default void finalize() {System.out.println("default finalize");} } static class FOO implements ClonerFinalizer { @Override public Object clone() { return ClonerFinalizer.super.clone(); } @Override public void finalize() { ClonerFinalizer.super.finalize(); } } }
Solution 4
I do not see into the head of Java language authors, so we may only guess. But I see many reasons and agree with them absolutely in this issue.
The main reason for introducing default methods is to be able to add new methods to interfaces without breaking the backward compatibility of older implementations. The default methods may also be used to provide "convenience" methods without the necessity to define them in each of the implementing classes.
None of these applies to toString and other methods of Object. Simply put, default methods were designed to provide the default behavior where there is no other definition. Not to provide implementations that will "compete" with other existing implementations.
The "base class always wins" rule has its solid reasons, too. It is supposed that classes define real implementations, while interfaces define default implementations, which are somewhat weaker.
Also, introducing ANY exceptions to general rules cause unnecessary complexity and raise other questions. Object is (more or less) a class as any other, so why should it have different behaviour?
All and all, the solution you propose would probably bring more cons than pros.
Solution 5
The reasoning is very simple, it is because Object is the base class for all the Java classes. So even if we have Object's method defined as default method in some interface, it will be useless because Object's method will always be used. That is why to avoid confusion, we cannot have default methods that are overriding Object class methods.
Related videos on Youtube
gexicide
I'm a long term developer of Tableau's Hyper database engine and currently the manager in charge of the Hyper API.
Updated on September 02, 2020Comments
-
gexicide over 3 years
Default methods are a nice new tool in our Java toolbox. However, I tried to write an interface that defines a
default
version of thetoString
method. Java tells me that this is forbidden, since methods declared injava.lang.Object
may not bedefault
ed. Why is this the case?I know that there is the "base class always wins" rule, so by default (pun ;), any
default
implementation of anObject
method would be overwritten by the method fromObject
anyway. However, I see no reason why there shouldn't be an exception for methods fromObject
in the spec. Especially fortoString
it might be very useful to have a default implementation.So, what is the reason why Java designers decided to not allow
default
methods overriding methods fromObject
?-
Eugene almost 6 yearsI feel so good about myself now, upvoting this for 100 times and thus a gold badge. good question!
-
-
Marwin almost 10 yearsI didn't notice the second paragraph of gexicide's answer when posting mine. It contains a link that explains the issue in more detail.
-
Brandon almost 10 yearsI am glad you took the time to explain this, and I appreciate all of the factors that were considered. I agree that this would be dangerous for
hashCode
andequals
, but I think it would be very useful fortoString
. For example, someDisplayable
interface might define aString display()
method, and it would save a ton of boilerplate to be able to definedefault String toString() { return display(); }
inDisplayable
, instead of requiring every singleDisplayable
to implementtoString()
or extend aDisplayableToString
base class. -
Brian Goetz almost 10 years@Brandon You're correct that allowing inheriting toString() would not be dangerous in the same way as it would be for equals() and hashCode(). On the other hand, now the feature would be even more irregular -- and you'd still incur all the same additional complexity about inheritance rules, for the sake of this one method...seems better to draw the line cleanly where we did.
-
Siu Ching Pong -Asuka Kenji- over 9 years@gexicide If
toString()
is based on only the interface methods, you could simply add something likedefault String toStringImpl()
to the interface, and overridetoString()
in each subclass to call the interface implementation - a bit ugly, but works, and better than nothing. :) Another way to do it is to make something likeObjects.hash()
,Arrays.deepEquals()
andArrays.deepToString()
. +1'd for @BrianGoetz's answer! -
Groostav over 8 yearsThe default behaviour of a lambda's toString() is really obnoxious. I know the lambda factory is designed to be very simple and fast, but spitting out a derrived classname really isn't helpful. Having a
default toString()
override in a functional interface would allow us to --at least-- do something like spit out the signature of the function and the parent class of the implementer. Even better, if we could bring some recursive toString strategies to bear we could walk through the closure to get a really good description of the lambda, and thus improve the lambda learning curve drastically. -
mjs over 6 yearsAny change to toString in any class, subclass, instance member could have that effect on implementing classes or users of a class. Furthermore, any change to any of the default methods would also likely affect all the implementing classes. So what's so special with toString, hashCode when it comes to someone altering the behaviour of an interface? If a class extends another class they could alter than too. Or if they are using the delegation pattern. Someone using Java 8 interfaces will have to do so by upgrading. A warning/error that can be suppressed on the subclass could've been provided.
-
pro_cheats over 6 years.Whats the point? You still didn't answer the WHY part - "So, what is the reason why Java designers decided to not allow default methods overriding methods from Object?"
-
Alexey Romanov about 4 yearsSurely the last point applies exactly as much is
Bar
is a class rather than an interface. -
David Lilljegren almost 4 yearsIf you use log4j2, one workaround for the
toString
problem is to let the interface extendlog4j.util.StringBuilderFormattable
and implementformatTo
as a default method -
Dávid Horváth over 3 yearsIMO,
Object
is not really a class, but a mix of the basic implementation stuff, and fallback methods. Maybe these fallback methods (liketoString()
) should be overridable by interfaces. My biggest "personal pain" is the impossibility of this type of templating:public default toString() { return toString(Locale.getDefault()); }
. -
zb226 over 2 years@pro_cheats His point is, as clearly stated, to be very pedantic. The answer adds some bits of info to the excellent accepted one, which already covered the WHY part.