HHH-19918 Avoid reflection when instantiating known FormatMapper

[beikov]

[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-19918

[yrodiere]

Backport of #11209

[beikov]

Hmm, this is the first time I see this monotonicity issue. Maybe this is something worth investigating? @cigaly

2025-11-13T12:37:32.8735075Z UUidV6V7GeneratorTest > testMonotonicityUuid7() FAILED
2025-11-13T12:37:32.8739865Z     java.lang.AssertionError: 
2025-11-13T12:37:32.8744008Z     Expecting actual:
2025-11-13T12:37:32.8747818Z       "019a7d38-9928-786c-bf3e-f8b27fc5a31c"
2025-11-13T12:37:32.8751670Z     to be greater than:
2025-11-13T12:37:32.8755609Z       "019a7d38-9928-786c-bf3e-f8b27fc5a31c"
2025-11-13T12:37:32.8757526Z         at org.hibernate.orm.test.id.uuid.rfc9562.UUidV6V7GeneratorTest.testMonotonicity(UUidV6V7GeneratorTest.java:43)
2025-11-13T12:37:32.8759432Z         at org.hibernate.orm.test.id.uuid.rfc9562.UUidV6V7GeneratorTest.testMonotonicityUuid7(UUidV6V7GeneratorTest.java:31)

[cigaly]

@beikov

Hmm, this is the first time I see this monotonicity issue. Maybe this is something worth investigating? @cigaly

Strange, two consecutive UUIDs are equals. That can mean only that internal state has not been change. I'll try to find out how that can be possible.

I guess that problem is in line

final long nextSequence = lastSequence + Holder.numberGenerator.nextLong( 0xFFFF_FFFFL );

There is very small (but non zero) chance that next long will be zero, so I would change that to

final long nextSequence = lastSequence + Holder.numberGenerator.nextLong( 0xFFFF_FFFEL ) + 1;

Should I create Jira issue and/or PR with that chane?

[beikov]

Yes, please create a Jira issue and a PR. Also, while you're at that, can you please add a javadoc comment explaining the * 0.004096 in the nanos method?

I'm also a bit surprised about the 0xFFFF_FFFFL constant now that I'm looking at it again. The javadoc of the class mentions a 62 bit pseudo-random counter, but here we just add a 16 bit random value to an existing sequence. What is the reason for this again? We could always create the full random 62 bits, but I guess there is an advantage to this process?