On Tue, 1 Sep 2026 21:06:11 GMT, Nir Lisker <[email protected]> wrote:
>> please elaborate - the current implementation complies with the
>> hashCode/equals contract (and is effectively unchanged btw).
>
> Two `equals` objects must have the same hashcode. This is not the case here:
> `DataFormat#equals` calls `Set#equals`, whose contract says that the elements
> need to be equal (order-independent). The current hash function iterates the
> elements in an unspecified order, producing order-dependent hashes.
> `Set.of("a", "b")` and `Set.of("b", "a")` are `equals` but have different
> hashes. By delegating to `Set#hashCode`, we align it with `Set#equals` and
> have `Set` worry about matching its contract.
Regarding the difference from the current `master` code, creating a
`DataFormat` with identical IDs in a different order to an existing one used to
throw, but now it's ignored, so you get your new instance. If you now try to
`Map#get` with it, you will get `null` because the first-come-first-serve
`DataFormat` has a different hashcode than yours has. Imagine the surprise.
-------------
PR Review Comment: https://git.openjdk.org/jfx/pull/2197#discussion_r3908524738
