On Mon, 22 Sep 2025 13:26:30 GMT, Jaikiran Pai <j...@openjdk.org> wrote:
> Can I please get a review of this change to a test library class which > proposes to remove the calls to `MessageDigest` from the static initializer > of `jdk.test.lib.Utils`? > > The `Utils` test library class constructs a random generator which can be > used in tests. Back in JDK 16, we updated this class to use a consistent seed > (if none is explicitly set) when running against promotable JDK builds. This > was done in https://bugs.openjdk.org/browse/JDK-8253750. The motivation > behind using a consistent seed as explained in that issue is reasonable. > > In the implementation of seed generation, we generate the seed based off the > JDK build version and we currently use the `java.security.MessageDigest` > class to generate the bytes for the seed. The use of `MessageDigest` here > drags in a lot of security-libs infrastructure. If this `Utils` class then > gets used in tests that configure the security-libs in a specific manner > (like intentionally setting certain configurations which trigger an > exception), then the `Utils` class fails during its static initialization. > This prevents its usage in such tests as well as sometimes causes unexpected > failures like: > > https://bugs.openjdk.org/browse/JDK-8367583 > https://bugs.openjdk.org/browse/JDK-8345578 > > The change in this PR replaces the usage of security-libs infrastructure with > a much more simpler implementation for the seed generation. The proposed > usage of `CRC32`, to generate the seed based off the version, doesn't drag in > these additional classes and should thus prevent issues like the ones noted > above. > > I've run this change locally as well as our CI (tier1, tier2, tier3) and > haven't seen any failures. Hello Weijun, > But you did try that and has confirmed it's no longer an issue, right? Right, locally, I reverted the change done in https://github.com/openjdk/jdk/pull/27269 and built a JDK as follows: bash configure --with-version-build=42 make clean images I then ran the `sun/security/util/AlgorithmConstraints/InvalidCryptoDisabledAlgos.java` test with and without the changes proposed in this current PR. The test continues to fail (with the same reason) without the changes in this PR and passes after these changes. > I assume there is no need to back out the changes made in JDK-8367583 and > JDK-8345578 (at least not here) so that this fix can be backported cleanly if > necessary. Yes, I think it's not necessary to undo those fixes in those 2 tests. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27427#issuecomment-3319738572
