On Nov 20 2013, at 16:31 , Remi Forax <[email protected]> wrote: > Hi mike, > > 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.
Ah, yes. It had worked for a while but then that decision was made. > >> 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. >> >> Mike > > Rémi > > >> >> On Nov 20 2013, at 14:54 , Remi Forax <[email protected]> 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. >>> >>> regards, >>> Rémi >>> >
