On Tue, 19 Jul 2022 15:48:09 GMT, Andy Goryachev <[email protected]> wrote:
>> - added missing hashCode() methods > > Andy Goryachev has updated the pull request with a new target base due to a > merge or a rebase. The incremental webrev excludes the unrelated changes > brought in by the merge/rebase. The pull request contains five additional > commits since the last revision: > > - 8289389: review comments > - Merge remote-tracking branch 'origin/master' into 8289389.hash > - 8289389: minimize the impact of collision > - 8289389: toExternalForm() > - 8289389: implemented missing hashCode() John, thank you for your comments! I fully agree with the idea of not putting objects with mutable fields that participate in either equals() or hashCode() into Hashtable. This scenario might still be legitimate, for example by not modifying the fields in question after instantiation. I also agree that some of the changes might look unnecessary, or perhaps we should either return super.hashCode() or maybe getClass().hashCode() -- not a constant, as hashCode() guarantees some variability, while a constant does not. I do think, however, that suppressing this warning or turning it off is not a good idea. it forces the developer to think about exactly this issue. Do you have any specific objections? ------------- PR: https://git.openjdk.org/jfx/pull/821
