RFR: 8358624: ImmutableDescriptor violates equals/hashCode contract after deserialization [v2]

[Chris Plummer]

On Thu, 19 Jun 2025 11:17:01 GMT, Kevin Walls <kevinw at 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