HHH-18974 - initialize SecureRandom at runtime

[jrenaat]

inside the UuidVersion7Strategy constructor

---

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-18974

[beikov]

The idea is to rather remove Holder and adding a private final SecureRandom numberGenerator = new SecureRandom(); to UuidVersion7Strategy, which will require that State#getNextState accepts a SecureRandom parameter.

[jrenaat]

The idea is to rather remove Holder and adding a private final SecureRandom numberGenerator = new SecureRandom(); to UuidVersion7Strategy, which will require that State#getNextState accepts a SecureRandom parameter.

I've already talked with Yoann about a potential solution; the PR is currently only partial.

[yrodiere]

LGTM assuming you managed to get tests to pass on Quarkus (as we discussed), thanks!

---

The idea is to rather remove Holder and adding a private final SecureRandom numberGenerator = new SecureRandom(); to UuidVersion7Strategy

Unfortunately if we do that, the UuidVersion7Strategy#INSTANCE, along with its SecureRandom, will end up in the heap just before native compilation, which will lead to the exact same problem.

Your suggestion could potentially work if the numberGenerator in UuidVersion7Strategy was lazily-initialized -- but even then I'm not entirely sure.

The removal of the numberGenerator access is indeed not enough, it's just the first part of a two-fold solution:

1. First commit: making sure that no access is made to numbergenerator before we actually generate UUIDs (i.e., at runtime for native applications).
2. Second commit: making sure that any native application using Hibernate ORM will initialize the Holder classes at runtime, ensuring the SecureRandom (and its seed) will be initialized at runtime.

This is enough to fix the issue in theory, and Jan checked this by running integration tests in my ORM 7 upgrade PR, so we should be fine.