On Thu, 12 Mar 2026 01:34:30 GMT, Joe Darcy <[email protected]> wrote:
>> FYI, this discussion in Double about representation equivalence vs bit-wise >> equivalence may be useful here: >> https://docs.oracle.com/en/java/javase/25/docs/api/java.base/java/lang/Double.html#equivalenceRelation >> HTH > >> Thanks for the pointer, @jddarcy! >> >> I chose floatToRawIntBits / doubleToRawLongBits (bit-wise equivalence) >> because constant pool entries correspond to exact byte sequences in the >> class file — different NaN bit patterns produce different bytes and should >> be distinct entries. >> >> That said, floatToIntBits / doubleToLongBits (representation equivalence) >> would also be a reasonable choice here, since non-canonical NaN values are >> extremely rare in practice, and it would be consistent with the hashCode >> implementation which already uses Float.hashCode() → floatToIntBits. >> >> I'm happy to switch to floatToIntBits / doubleToLongBits if you think >> representation equivalence is more appropriate for this use case. > > Given my limited understanding of the use case, either may be acceptable but > bit-wise equivalence using raw-bits is certainly correct. In other words, it > would be acceptable, if not ideal for performance, for different NaN bit > patterns to not be treated as the same. HTH Thanks @jddarcy! I'll keep the current floatToRawIntBits / doubleToRawLongBits approach for bit-wise equivalence, since constant pool entries are byte-level representations and this preserves the distinction between different NaN bit patterns. I've also updated hashCode to use floatToRawIntBits / doubleToRawLongBits for consistency with equals, so that different NaN payloads won't unnecessarily collide in the same hash bucket. Thanks @jddarcy! I'll keep the floatToRawIntBits / doubleToRawLongBits approach for bit-wise equivalence. I've also updated hashCode to use raw bits accordingly, so equals and hashCode are now fully consistent — different NaN bit patterns will hash to different buckets. ------------- PR Comment: https://git.openjdk.org/jdk/pull/30196#issuecomment-4048574468 PR Comment: https://git.openjdk.org/jdk/pull/30196#issuecomment-4048603350
