On Mon, 22 Sep 2025 15:59:19 GMT, Raffaello Giulietti <[email protected]> wrote:
>> In the meantime, `SecureRandom.nextLong()` has been implemented. >> Composing the two longs from the timestamp and the random will take fewer >> lines of code. >> 8357915: SecureRandom nextLong memory usage > > @kieran-farrell Is there a last-minute plan to make use of `nextLong()` as > suggested by @RogerRiggs? > Otherwise looks good Thanks @rgiulietti, the need for a nextLong() API existed whenwe were using higher percision bits in the first half of the UUID, there fore only required the second half (long) to be generated with random bits, however we are no longer using higher percision bits in the first ling, and instead using random bits in their place, so we would need to call nextLong twice and overwrite with the timestamp etc. which results in a large perfomance dec. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25303#discussion_r2371795396
