The UUIDs.random() method currently provides a shortcut for UUID.randomUUID() in both 3.x and 4.x. It turns out that internally randomUUID() relies on SecureRandom to generate a random number. In the context of Cassandra primary key generation it was likely not considered as a requirement but was just overlooked.
A quick JMH benchmark iterating over a 1000 calls to nextLong() for various *Random classes give the following results:
So in short, SecureRandom is at least 250x slower than the usual Java alternatives and generates some garbage for each generated random number whereas the alternatives don't.
To work around this problem, I see 3 options:
1. Replace the UUIDs.random() implementation with a custom, non-secure UUID generation one.
2. Do 1. and move the current implementation to a new UUIDs.secureRandom() method, if you feel that there could be some value in keeping a secure implementation.
3. Add a UUIDs.nonSecureRandom() with the custom implementation discussed in 1. as a safest way to add a workaround without introducing any potential (if any?) security regression.
Note that we don’t make any guarantee on the security aspect of UUIDs.random() in its Javadoc, making the fact that we actually use SecureRandom arguably an implementation detail.
Let me know what you think and I can submit a patch accordingly.