I was already aware of the explanation of . 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.
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 .

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.

The explanation is here: . As mentioned, we could introduce a configurable threshold, if there’s evidence of this being necessary. And if people ask nicely.

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?

For information our imports map contains 1318 entries without any negative entry. So this fix pretty much disabled the negative cache.

The added limit caused a critical and hard to trace performance issue on our major application.
I can’t fathom how this kind of breaking change could have been added without a configurable limit and without waiting for a major version …

Thank you! I’ve now also submitted the requested changes in the PR.