On Thu, 19 Jun 2025 11:17:01 GMT, Kevin Walls <kev...@openjdk.org> wrote:
>> Hashcode needs to be reset to -1 to force its recalculation on next call, >> after deserialization. >> >> The change in the readResolve() method is the fix for this problem. While >> here I added similar lines in other methods that may update fields (although >> these are noted as not supported, as they change a class supposedly >> "immutable"). >> >> Added a test. There is a test for serialization for this class, but I found >> it clearer to add the test for this specific recently discovered issue in >> its own test file. > > Kevin Walls 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 six additional > commits since the last revision: > > - Merge remote-tracking branch 'upstream/master' into > 8358624_ImmutableDescriptor_hashcode > - spelling > - Exception name > - whitespace > - whitespace > - 8358624: ImmutableDescriptor violates equals/hashCode contract after > deserialization I'm not much of a serialization expert, so just asking for some clarification here. I assume when de-serialized, the initial hashcode is always 0. Why it is 0 and not by default -1. Seems this would be an issue with any de-serialized type and all would need to explicitly set to -1 as you have done in this case. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25758#issuecomment-2992607168
