Meaningless Drivel is fun!
The moose likes Beginning Java and the fly likes creating a unique ID# for instances Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login

Win a copy of OCA Java SE 8 Programmer I Study Guide this week in the OCAJP 8 forum!
JavaRanch » Java Forums » Java » Beginning Java
Bookmark "creating a unique ID# for instances" Watch "creating a unique ID# for instances" New topic

creating a unique ID# for instances

kenji mapes
Ranch Hand

Joined: Jun 16, 2005
Posts: 38
So I am creating an abstract class with several multiderived class.

I need to create a unique ID # for an instance of each class which of course is an instance of the base class. I can only think of one place to store it. My guess is in an array but if I define it inside a constructor, hwo can I increment and keep in sequential and in order if the value will be local.

I am wondering if I can initialize a number outside of the constructor and have the datfield stored in an int array index, and have the next index ready to create a new ID. I suppose the index itself will be offset by 1 of the Vehicle ID. i.e. arrayName[0] will be 1, and so on.

Also, I am thinking that I will then need a search method, isFull, is Empty method, reset, and so on.

This is a problem ai have not tackled before. I am not a very experience Java developer. I'd say that I was on par with an advanced Java noob.

Any help and suggestions would be greatly appreciated. Thanks guys and gals.
Stuart Ash
Ranch Hand

Joined: Oct 07, 2005
Posts: 637
Do you think hashCode() will help you with what you want?

ASCII silly question, Get a silly ANSI.
kenji mapes
Ranch Hand

Joined: Jun 16, 2005
Posts: 38
I don;t know. I have never overridden the hjashcode method - usualy only equals, compareTo, toStrings, etc. I have only read suggestions by authors who sya to override the hashcode method when you override equals but have not understood why.

That does have intriguing possibilites though.
Jesper de Jong
Java Cowboy
Saloon Keeper

Joined: Aug 16, 2005
Posts: 15002

Try something like this.

If you want to store a list or map of all the instances, you could also do it in a static variable.

Java Beginners FAQ - JavaRanch SCJP FAQ - The Java Tutorial - Java SE 8 API documentation
Jeff Albertson
Ranch Hand

Joined: Sep 16, 2005
Posts: 1780
0. That should be

1. For thread safety, you should synchronize the instanceCount increment.

2. Also, as far as multithreading goes, this is dangerous:

That statement is letting *this* escape the constructor. Another thread could access
the map before object's constructor was done. What I suggest is some sort of factory.
The easiest would be adding static methods to all concrete classes:

You may also want to check out java.util.concurrent,ConcurrentHashMap.

Also, think about garbage collection and memory leaks! You should also have a removeFromMap,
if objects have end-of-lifetime that is easy to determine -- perhaps you create them at
the start of a method and release them in a finally block at the end. Otherwise, I would
consider using WeakReference.

There is no emoticon for what I am feeling!
kenji mapes
Ranch Hand

Joined: Jun 16, 2005
Posts: 38
Thanks. I will definitely try that out and see what it yields.
Stan James
(instanceof Sidekick)
Ranch Hand

Joined: Jan 29, 2003
Posts: 8791

I use that all the time and include the instance number in all the log messages. That can help a lot in multi-threaded or recursive routines. The ids are unique for one run of the program.

Is that sufficient for you? I wondered if you might need unique ids across a cluster or multiple runs of the program.

BTW: If an int won't hold the number of instances you make in one run, I'm impressed.

A good question is never answered. It is not a bolt to be tightened into place but a seed to be planted and to bear more seed toward the hope of greening the landscape of the idea. John Ciardi
Jim Yingst

Joined: Jan 30, 2000
Posts: 18671
Hmmm - I wouldn't trust that in a multithreaded environment without synchronization, Stan. The increment operator is not atomic. Though the chance of observing problems with this is probably pretty low most of the time, so if you don't need to guarantee that the ID is absolutely unique within a given JVM, making the call unsynchronized is probably OK. For debugging in log statements as you describe it's probably fine, as non-uniqueness is rare enough to be virtually unnoticeable. (As you've doubtless observed from years of use.) But in other applications, even rare instances of non-uniqueness could be very troublesome.

Kenji: note that the techniques shown so far only create IDs that are unique on a given JVM instance. If you need uniqueness across multiple machines (or even multiple JVMs on the same machine) you want a Universally Unique ID (UUID). I recommend looking at JUG or, it you're using Java 5, java.util.UUID.

"I'm not back." - Bill Harding, Twister
kenji mapes
Ranch Hand

Joined: Jun 16, 2005
Posts: 38
Thanks for the help and myriad information/ideas that you have generously shared with me. Time for me to roll up the proverbial sleeves, get to coding, and see what I can make of this.

Stan James
(instanceof Sidekick)
Ranch Hand

Joined: Jan 29, 2003
Posts: 8791
Where I've used it in threading apps is in the constructor of the runnable which were all made by a single driver thread. You're right ... we'd need to add some synchronization for objects created by different threads.

Kenji, have fun, show us what you come up with!
I agree. Here's the link:
subject: creating a unique ID# for instances
It's not a secret anymore!