Win a copy of Testing JavaScript Applications this week in the HTML Pages with CSS and JavaScript forum!
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other all forums
this forum made possible by our volunteer staff, including ...
  • Campbell Ritchie
  • Bear Bibeault
  • Ron McLeod
  • Jeanne Boyarsky
  • Paul Clapham
  • Tim Cooke
  • Liutauras Vilda
  • Junilu Lacar
Saloon Keepers:
  • Tim Moores
  • Stephan van Hulst
  • Tim Holloway
  • fred rosenberger
  • salvin francis
  • Piet Souris
  • Frits Walraven
  • Carey Brown

recNo choice

Ranch Hand
Posts: 74
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
hi all

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 => 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.

Ranch Hand
Posts: 81
Eclipse IDE Spring Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I just wanted to thank everyone for their posts. This was just what I needed to see to finish my assignment. All the posts here addressed all my questions. I must say this website is absolutely awesome and has helped me immensely.


Greg Funston SCJP
With a little knowledge, a cast iron skillet is non-stick and lasts a lifetime.
    Bookmark Topic Watch Topic
  • New Topic