Suggestion to add a static method to generate a random based UUID using ThreadLocalRandom (requires JDK 7)

[tehnic-take3]

I suggest to add a static method like the following to UUIDUtil (or any other appropriate class):

public static UUID generateThreadLocalRandomUUID() { ThreadLocalRandom rnd = ThreadLocalRandom.current(); return UUIDUtil.constructUUID(UUIDType.RANDOM_BASED, rnd.nextLong(), rnd.nextLong()); }

Using a generator created by Generators.randomBasedGenerator(ThreadLocalRandom.current()) is probably not a good idea when working in an environment with thread pools (like Java/Jakarta EE), so i came to this solution.

Best regards, Robert

[cowtowncoder]

Hi there! Thank you for the suggestion!

I'll have to think about this a bit wrt API; and also see what is the minimum JDK expectation (ThreadLocalRandom seems to have been added in Java 1.7/7).

[agentgt]

Sort of orthogonal but If the required JVM version is bumped to 9 or later I recommend you use System.Logger instead of SLF4J.

To be honest I'm surprised this library uses logging.

[cowtowncoder]

I doubt there's much point in bumping minimum JDK past 8 in near future.

As to logging, yes it is not used for regular operation (definitely not on per-uuid-generated basis) but for some specific failure condition... I'd have to check it but I think it was for file-backed locking, if used to store state across invocations (last "reserved" timestamp from time/location based variant).

You can also follow discussions wrt evolution of logging dependency, f.ex #32.

[cowtowncoder]

Ok, couple of notes:

• UUIDUtil is probably not an optimal place (although I guess I could). But maybe rather add straight into Generators
• Or, could perhaps figure out a way to encapsulate things to allow proper generator instance that hides access?
• ... alas, Jug 4.x is still Java 6 and ThreadLocalRandom seems to JDK 7 addition.

The last point would keep this out of 4.0.x. But if we were to increase JDK baseline to 8 that wouldn't be a problem. Besides although java source/target is defined as 1.6, I am not 100% sure there might not already be accidental JDK 7 dependencies.

Still, I need to think about this a bit now.