Allow interface default toString implementation

[Brian Goetz]

> What you're saying is "OK, I accept that its outright dangerous to inherit hashCode and equals from interfaces, but we should do something different for toString."
> 
> Well now you're putting words into my mouth. I didn't say anything like "outright dangerous." I just noticed that the strongest argument in the original discussion was against hashCode/equals, and I'm happy to avoid arguing a point that has been clearly decided. I was hoping that I might be able to give a good case for treating toString differently.

Putting words in my own mouth: I said “dangerous”, and you said something like “OK, I buy that for equals/hashCode, but what about toString?"

> 
> So this would be, basically, designing a special-purpose language feature for giving special inheritance behavior to one method.  Seems a poor return-on-complexity.
> 
> When you say special-purpose, are you referring to the idea of a toplevel interface, or something else?

Changing the inheritance semantics to govern the inheritance of a single (admittedly important) method.  

Recall the discussion started on the topic of “why can’t we inherit Object methods from interfaces”, and the argument against was basically “changing the inheritance semantics to support that would be complex, for not a lot of value, and in some cases for negative value.”  When hashCode and equals dropped out of the discussion, that leads to all the same complexity and more (because now it only applies to some methods), for even less value.  

You may well be thinking “but this doesn’t require a language change”, because of the trick you suggest with an Objects interface.  Its a clever trick, except that it doesn’t actually work — its not behaviorally compatible.  (Think about programs that use Object.class.getDeclaredMethod(); their behavior would change.)  So really, we are talking about a language change, to support a single method (and IMO not even supporting it very well.)  

> 
> Additionally, while this approach might magically make toString inheritance work well in *your* library, the reality is that toString shares the essential feature with equals and toString that it is primarily about state, and state resides with the class, not the interface.  You happen to have built a library where you've sufficiently virtualized the state, but your library is the exception, not the rule.  Making for an even worse return-on-complexity.
> 
> I'm sorry, but I don't understand the animosity here. I was trying to open up a discussion, and point out a specific use case that I thought illustrated the point of my suggestion reasonably well. I'm not trying to look for the solution to all of my problems. This is a much colder reception than I expected; I'm not trying to step on anyone's toes here.
>  
> So far, the simple rule is looking pretty good to me.
> 
> What simple rule would that be? 

Method declarations in classes take precedence over default declared in interfaces (i.e., “class wins”).  

In any case, bear in mind that the Java 8 ship has sailed, and switching the inheritance semantics now would change the behavior of existing code.