On Wed, 3 Jun 2026 07:35:36 GMT, Daisuke Yamazaki <[email protected]> wrote:
>> I fixed inconsistent `equals` / `hashCode` behaviour in `PoolEntry` and >> `BootstrapMethodEntry` objects created by different `ConstantPoolBuilder` >> instances. >> >> Previously, some hash codes depended on constant pool indices of referenced >> entries. >> Because of this, two entries with the same content could be equal but still >> have different hash codes if they came from different pools. >> >> This patch splits hashing into two types: >> 1. `public hashCode()`, now based only on content and consistent with >> `equals`(slower than the type 2) >> 2. internal pool lookup hash, still based on indices for fast >> `SplitConstantPool` and bootstrap method table deduplication >> >> This keeps fast local lookup performance while fixing the public `equals` / >> `hashCode` contract. >> >> Added `PoolEntryHashCodeTest`, migrated from the original issue reproducer, >> which compares equivalent entries created by distinct `ConstantPoolBuilders` >> with different index layouts. >> >> >> Running test 'jtreg:test/jdk/jdk/classfile/PoolEntryHashCodeTest.java' >> Passed: jdk/classfile/PoolEntryHashCodeTest.java >> Test results: passed: 1 >> >> >> --------- >> - [x] I confirm that I make this contribution in accordance with the >> [OpenJDK Interim AI Policy](https://openjdk.org/legal/ai). > > Daisuke Yamazaki has updated the pull request incrementally with one > additional commit since the last revision: > > Separate construction hashes from public hashCode values Sorry but FYI we will be mostly busy with JEP 401 recently. Anticipate some delays in the review cycles. Feel free to ping me for review after JEP 401 has been integrated. ------------- PR Comment: https://git.openjdk.org/jdk/pull/31255#issuecomment-4691609820
