Allow interface default toString implementation

[Remi Forax]

On 06/12/2014 02:09 AM, Brandon Mintern wrote:
> On Wed, Jun 11, 2014 at 8:57 AM, Brian Goetz <brian.goetz at oracle.com> wrote:
>
>> This recently came up on StackOverflow too:
>>
>> http://stackoverflow.com/questions/24016962/java8-why-
>> is-it-forbidden-to-define-a-default-method-for-a-method-
>> from-java-lan/24026292#24026292
>>
> To be fair, that was me. It seemed like a discussion more appropriate for
> the mailing list, so I moved it here.
>
> 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.

[Let pretend Java 8 was not shipped ... ]

Please don't forget that default methods are not only a Java the 
language feature, it's a VM feature that is used by Java the language.
So what you are talking about here is to have a special case in the way 
the VM treats default methods.

Adding a special case in the VM is something that have a higher cost 
that just having a special case in the compiler.
As an example, you can take a look to the long trail of bugs generated 
by the fact that there is a special case in the VM spec for 
Object::clone in case of arrays (instead of being protected, the method 
is public).
https://bugs.openjdk.java.net/issues/?jql=text%20~%20%22clone%20array%22

And to finish, Java is not the only language that run on the JVM, so 
adding a special case to the VM spec has the nasty side effect to add a 
special case to every languages than run on the JVM.

regards,
Rémi