Thanks to visit codestin.com
Credit goes to github.com

Skip to content

Conversation

jrenaat
Copy link
Member

@jrenaat jrenaat commented Sep 4, 2025

[Please describe here what your change is about]


By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license
and can be relicensed under the terms of the LGPL v2.1 license in the future at the maintainers' discretion.
For more information on licensing, please check here.


https://hibernate.atlassian.net/browse/HHH-19276

@jrenaat jrenaat requested a review from beikov September 4, 2025 21:47
@jrenaat jrenaat marked this pull request as draft September 4, 2025 21:55
@jrenaat
Copy link
Member Author

jrenaat commented Sep 4, 2025

@beikov converted back to draft because the test isn't correctly establishing that no additonal instances of the enum java type or basic type are being generated.
Unfortunately the access to the registryValues Map in BasicTypeRegistry is private so I'm not sure how to actually verify that only one instance of EnumJavaType for HairColor is contained in it ...

@jrenaat jrenaat force-pushed the HHH-19276_memoryleak branch from 21e7dfc to c6bf358 Compare September 5, 2025 15:26
@jrenaat jrenaat marked this pull request as ready for review September 5, 2025 17:01
@jrenaat jrenaat force-pushed the HHH-19276_memoryleak branch from c6bf358 to c98a9a6 Compare September 5, 2025 17:09
@beikov
Copy link
Member

beikov commented Sep 8, 2025

A very simple test would be to simply verify that sessionFactory.getMappingMetamodel().resolveParameterBindType( MyEnum.VAL ) always returns the same object for multiple calls, assuming that is the entry point for creating these types (which it probably isn't).

The registryValues Map was dropped from BasicTypeRegistry since it's no longer needed, and it could lead to an
OutOfMemoryError (accumulation of EnumJavaType instances as keys in the Map).
@jrenaat jrenaat force-pushed the HHH-19276_memoryleak branch from c98a9a6 to 0a5ab82 Compare September 10, 2025 19:11
Comment on lines +43 to +44
&& !expectedElementType.getJavaType()
.isAssignableFrom( elementType.getExpressibleJavaType().getJavaTypeClass() ) ) {
Copy link
Member

@gavinking gavinking Sep 13, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
&& !expectedElementType.getJavaType()
.isAssignableFrom( elementType.getExpressibleJavaType().getJavaTypeClass() ) ) {
&& !TypecheckUtil.isTypeAssignable( expectedElementType, elementType.getSqmType(), bindingContext ) ) {
// && !expectedElementType.getRelationalJavaType().getJavaTypeClass()
// .isAssignableFrom( elementType.getRelationalJavaType().getJavaTypeClass() ) ) {

@gavinking
Copy link
Member

Superseded by #10935.

I answered @beikov's objecting by delegating to the heavy machinery in TypecheckUtil.

@gavinking gavinking closed this Sep 13, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants