Branch: refs/heads/main Home: https://github.com/hibernate/hibernate-orm Commit: 434e45815dc366c09648c854eecf6cc6487e470d https://github.com/hibernate/hibernate-orm/commit/434e45815dc366c09648c85... Author: Develop-KIM <kimdonghwan913(a)gmail.com&gt; Date: 2026-07-14 (Tue, 14 Jul 2026) Changed paths: M hibernate-core/src/main/java/org/hibernate/type/descriptor/java/DateJavaType.java A hibernate-core/src/test/java/org/hibernate/orm/test/query/hql/UnionSameJavaTypeDifferentPathTest.java Log Message: ----------- HHH-20661 Return shared DateJavaType instances per temporal precision DateJavaType#resolveTypeForPrecision created a new DateJavaType on every call, so the same java.util.Date reached through different attribute paths (e.g. an entity field vs. one inherited from a @MappedSuperclass) resolved to distinct JavaType instances. A union of two such columns was then rejected by SqmQueryGroup's identity comparison with "Select items of the same index must have the same java type across all query parts", even though the equivalent Criteria query worked. Follow the pattern used by the other temporal JavaTypes: override forDatePrecision/forTimePrecision/forTimestampPrecision to return shared per-precision instances instead of allocating a new one. Resolving the same precision now yields the same instance, so the existing identity comparison keeps working and genuinely different types are still rejected. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply(a)anthropic.com&gt; To unsubscribe from these emails, change your notification settings at https://github.com/hibernate/hibernate-orm/settings/notifications