hi all
@Roberto:
I use it as well for the record number, so it's used twice, once centralized somewhere (DRY principle).
Regarding the static aspect, while I deeply agree,
Java doesn't offer us much choices here, furthermore this util class is a spin off from the UUID one, where the user is expected to do exactly the same.
About the javadoc, it starts with "Generate a long UUID". However this is partly misleading (it's a weak UUID), hence the big comment about it.
Regarding the way to generate this UUID, IMHO, I would prefer a proper long UUID mechanism than to rely on some artifact hopefully good enough, like nanoTime or currentTimeMillis, with no formal/mathematical backing since it's explicitly said to *not* use for this purpose.
Using the current
thread id feels even weaker. What if someone decides to use Data class in a monothreaded way but with multiple logical clients? Or if someone is doing thread pooling for performance reason on the calling side ? If two locks happen in the same thread, one could even reuse the first lock cookie to unlock the second lock, breaking severely the contract for the logical lock.
In the end, using the thread id looks like solving a logical record lock issue with a solution based on how it will be use outside of its scope, which feels bad to me, especially since it could backfire if not use the pre supposed way.
Maybe a solution might be there
http://stackoverflow.com/questions/325443/generate-uuid-in-java => using UUID.randomUUID().getLeastSignificantBits() it would take 2^32 UUIDs to get a collision. However I'm unsure whether there is a minimum time between each call to UUID.randomUUID(), but then the issue is the same for nanoTime or currentTimeMillis.