Map.Entry.setValue as a default method

Remi Forax forax at univ-mlv.fr
Thu Nov 21 06:56:20 PST 2013


On 11/21/2013 02:08 AM, John Rose wrote:
> On Nov 20, 2013, at 4:31 PM, Remi Forax <forax at univ-mlv.fr 
> <mailto:forax at univ-mlv.fr>> wrote:
>
>> But while you can declare a default hashCode and equals, it will not 
>> work because the implementation of Object.hashCode and Object.equals 
>> will always be preferred to the default methods by the VM, this is 
>> how default methods are specified. Not something I'm very proud.
>
> Next question:  What's the best practice for declaring reusable code 
> for exactly those restricted methods (hashCode/equals, toString)? 
>  Because of the irregularity with Object, the opt-in isn't by default, 
> but there should still be a convention for supplying the code as a 
> "would-be default method".
>
> Maybe one of:
>   interface KoolReusablePair {
>     default boolean defaultEquals(Object x) { ... }
>     static int hashCode(KoolReusablePair self) { ... }
>     ...
>   }
>
>   class KoolImpl implements KoolReusablePair {
>     @Override //manual opt-in:
>     public boolean equals(Object x) { return 
> KoolReusablePair.super.defaultEquals(x); }
>     @Override //manual opt-in:
>     public int hashCode() { return KoolReusablePair.hashCode(this); }
>     ...
>   }
>
> — John

The plumber in me think that a static method unlike a default method 
will not pollute the itable.

regards,
Rémi



More information about the lambda-libs-spec-observers mailing list