Map.Entry.setValue as a default method
forax at univ-mlv.fr
Thu Nov 21 00:31:22 UTC 2013
On 11/21/2013 12:07 AM, Mike Duigou wrote:
> It could still be added in a future rev.
yes, I've post that here as a remainder for the future generation :)
> setValue was less compelling and obviously correct than Iterator.remove(). I had a version of Map.Entry earlier on which provided provided setValue() along defaults for the required implementations of hashCode() and equals(). The spec for these later two methods is part of the API so defaults seemed appropriate.
Totally appropriate because a lot of people forget to implement them
when implementing Map.Entry,
3 or 4 years back, hibernate collections had that issue, by example.
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.
> We essentially didn't implement them to avoid scope creep--none of these were strictly necessary for our other goals. For Iterator.remove() we could get immediate benefit.
> On Nov 20 2013, at 14:54 , Remi Forax <forax at univ-mlv.fr> wrote:
>> A good question of one of my student,
>> why Iterator.remove() is a default method that throws UOE in 8 but Map.Entry.setValue() is not a default method with the same semantics.
More information about the core-libs-dev