I was already aware of the explanation of https://github.com/hibernate/hibernate-orm/pull/4411#issuecomment-989304639 . It still did not make sense to me. What was the cost of adding at least a configuration? Why not keep the default value for 5.6.x ? Why not adding this to the release note as a breaking change with all the blinking lights?
I am sure, the use case reported here is only representative of a small minority of Hibernate users.

And if people ask nicely

If I appeared not nice, it is probably because I think the decision derived from the explanation is a mistake.
https://hibernate.atlassian.net/browse/HHH-15100 was created by someone else on march and received zero answer. Moreover, I am not among the kind of people who asks OSS maintainers then wait. I immediatly created a pull request yesterday for https://hibernate.atlassian.net/browse/HHH-15100 .

Generally speaking, I would suggest that if your map is growing so much, it would be interesting to try to avoid the root cause. Are you generating many queries dynamicaly via string manipulation? Why are all these tokens different? Or are you able to trigger this in another way?

The map contains 1318 entries on application startup before any query. The keys are either JPA entities simple name (like “product” for “Product”) or full qualified name (like “org.example.Product”). We don’t use any query string. But we have a massive usage of JPA CriteriaQuery generating tokens like “from” or “generatedAlias0.product”. Since the current fix, those false positives never make it to the map because of the 1000 entries limit. So each false positive generate one call to Class.forName().

Given the knowledge we had on December 2021 and potential performance implication on huge applications (the ones precisely needing performance optimization), I will keep saying that this ticket was very badly managed. This happens to everybody so please do not hold a grudge against me if you don’t agree.