RFR: 8199318: add idempotent copy operation for Map.Entry
Remi Forax
forax at univ-mlv.fr
Thu Jun 3 19:46:51 UTC 2021
----- Mail original -----
> De: "Peter Levart" <peter.levart at gmail.com>
> À: "Rémi Forax" <forax at openjdk.java.net>, "core-libs-dev" <core-libs-dev at openjdk.java.net>
> Envoyé: Jeudi 3 Juin 2021 20:49:05
> Objet: Re: RFR: 8199318: add idempotent copy operation for Map.Entry
> On 02/06/2021 19:24, Rémi Forax wrote:
>> I foolishly hoped that nobody would subclass a class with `Immutable` in its
>> name,
>> oh boy i was wrong:)
>
>
> There's nothing wrong in subclassing an immutable class. As long as the
> subclass keeps being immutable. Was it subclassed and made mutable by that?
It has to be immutable all the way up, you have the same issue if the subclass is not final.
If you filter out guava an google cache, github get you 12 pages of result and only one stupid code
https://github.com/klayders/interlude/blob/95fd59a911d2baa8ac36ae6b877955aa4fbd095e/src/main/java/l2/gameserver/skills/SkillEntry.java#L12
A lot of code uses SimpleImmutableEntry as a pair, my hope is that the introduction of records will clean that practice.
That said, there is also several broken codes, mostly two issues,
either a.equals(n) is not equivalent to b.equals(a) or a.equals(b) is not equivalent to a.compareTo(b) == 0.
I kind of regret that the compiler does not provide automatically an implementation of compareTo if the record implements Comparable.
People sucks at writing compareTo and the resulting bugs are hard to find/reproduce.
>
>
> Peter
Rémi
More information about the core-libs-dev
mailing list