On Wed, 27 May 2026 15:40:41 GMT, Chen Liang <[email protected]> wrote:
>> src/java.base/share/classes/jdk/internal/classfile/impl/AbstractPoolEntry.java
>> line 530:
>>
>>> 528: abstract static sealed class AbstractRefEntry<T extends PoolEntry>
>>> extends AbstractPoolEntry {
>>> 529: protected final T ref1;
>>> 530: private @Stable int contentHash;
>>
>> I called the one in Utf8EntryImpl contentHash because it is a string hash
>> instead of a directly usable hash for an entry. So we need a better name.
>> I think we might use names like `constructionHash` and `fullHash` instead.
>> And the cache field for the full hash might be stored in the root
>> AbstractPoolEntry, which can declare like this:
>> int constructionHash() {
>> // Just return `hashCode()` by default?
>> // The "hash" field should get a rename otherwise.
>> assert hash != 0;
>> return hash;
>> }
>>
>> private @Stable int fullHash;
>>
>> public int hashCode() {
>> int hash = fullHash;
>> if (hash == 0) {
>> return fullHash = computeFullHash();
>> }
>> return hash;
>> }
>>
>> abstract int computeFullHash();
>
> That said, the construction hash of a `ClassEntry` is specially chosen to be
> `hash1(tag, descriptorStringHash)` instead of a hash of the UTF content -
> this is to allow fast hashing from an `L;` descriptor to an existing
> `ClassEntry`.
Good catch. I'll start by renaming them.
et me also look into whether the full-hash caching can be centralized in
`AbstractPoolEntry`.
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/31255#discussion_r3346312276
