Distinct ID Number Per Object?

[tony]

use the time when the obj is created as its ID can ensure its uniqueness

 

[Mark Thornton]

Regarding identityHashCode() -- I have it on good authority than the
Sun JVM implementation, and the typical implementation, uses the RAM
address of the object's handle (which isn't moved by compacting gc).

I don't think the Sun JVM's have used object handles for many years. The
early garbage collectors did work that way.

Mark Thornton

 

[Twisted]

I don't think the Sun JVM's have used object handles for many years. The
early garbage collectors did work that way.

JVMs tend to either use handles, or they directly rewrite referring
objects' reference pointers. In the latter case, the object's own RAM
address is likely to be used to set its hash code when it's created,
but then the object may get moved and the hash code stay the same. If
that's the case, and a new object gets created in the same location,
the code might recur on concurrent lifetime objects. VMs like that are
probably better off using a hash of the clock time when the object was
created to set its identityHashCode. This is unlikely to show
collisions until you make tens of millions of objects, if done well.

In any event, the whole discussion is moot, since the OP did turn out
to have control of the classes whose objects need identifying, and can
just stick that snippet of increment-static-int-and-assign-to-public-
final-field code in his base class(es). And use a long if he expects
to have billions of objects or more during one JVM session with his
app. Zero collisions, mathematically guaranteed unless the app tries
to produce 2^64 + 1 or more objects, which would likely take until the
sun went out, if not longer.

 

[Karl Uppiano]

use the time when the obj is created as its ID can ensure its uniqueness

That only works if the objects are created slower than the resolution of the
timebase. Otherwise, you will get the same value for objects created in
rapid succession. For local uniqueness, a concatenation of time and serial
number (a simple counter) should be sufficient.

A UUID, depending on the generation algorithm, uses time, and/or the
computer's MAC address and/or random number generation to create unique
values. In this way, even objects created on different machines may be
combined into common database tables with near zero risk of collisions.
Plus, UUIDs are eminently printable, which was a requirement of the OP.

 

[Mark Thornton]

Plus, UUIDs are eminently printable, which was a requirement of the OP.

But not at all memorable. Using a printed UUID for any purpose is tedious.

Mark Thornton

 

[Lew]

JVMs tend to either use handles, or they directly rewrite referring
objects' reference pointers. In the latter case, the object's own RAM
address is likely to be used to set its hash code when it's created,
but then the object may get moved and the hash code stay the same.

Proving further that the hash code is not the same as the "address". The
"address" is permitted to change, but the hashCode() result is not. This was
part of my evidence when I pointed out

Nor is the "address" required to remain "constant" during the lifetime of the object, unlike the return value of hashCode().

Different things, different semantic spaces.

 

[Karl Uppiano]

But not at all memorable. Using a printed UUID for any purpose is tedious.

Probably no more tedious than any large number that will undoubtedly result
if you have to keep track of more than a few thousand instantiations.

 

[Tom Hawtin]

I don't think the Sun JVM's have used object handles for many years. The
early garbage collectors did work that way.

Absolutely.

Handles were briefly resurrected for the earliest HotSpot
implementations. On typical, modern, serious Java implementations,
objects do get moved in memory and have no fixed handles.

Even for 32-bit JVMs, identity hash codes do clash. If you look at the
values produced, they clearly aren't sensible addresses - odd numbers,
for instance. I believe that it is true that values are typically
*derived* from the address of the object at the time the hash is first
requested.

http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6321873

I can't believe this nonsense keeps turning up...

Tom Hawtin

 

[Lew]

Absolutely.

Handles were briefly resurrected for the earliest HotSpot
implementations. On typical, modern, serious Java implementations,
objects do get moved in memory and have no fixed handles.

Even for 32-bit JVMs, identity hash codes do clash. If you look at the
values produced, they clearly aren't sensible addresses - odd numbers,
for instance. I believe that it is true that values are typically
*derived* from the address of the object at the time the hash is first
requested.

http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6321873

I can't believe this nonsense keeps turning up...

Excellent link, and an interesting little program that proves the point that

It appears straightforward to find two live objects sharing the same identityHashCode, using only a bog standard JRE. Real implementations with unique identityHashCodes for live objects, I would expect to be confined to legacy J2ME JVMs (if they had System.identityHashCode).

It seems so clear /a priori/ that hashCode() return values and so-called
"internal addresses" are such completely different beasts in such completely
different worlds that no one should be able to confuse the two. It's also
curious that people focus on the phrase "the internal address of the object"
and not "converting ... into an integer" in the Javadoc description:

This is typically implemented by converting the internal address of the object into an integer,
but this implementation technique is not required by the JavaTM programming language.

Really, that part of the Javadoc description should just be deleted. In fact,
they should get rid of

As much as is reasonably practical, the hashCode method defined by class Object does return distinct integers for distinct objects.

It is imprecise and misleading. What they should say is something like, "A
good hash code approaches uniform distribution of values across the int range."

 

[Andreas Leitgeb]

That's how I thought of it. I might have seen it before and forgotten it,
since it came so easily to me. I did this:

protected static int componentID = 0;

protected int myID = componentID++;

Are you aware, that this is *not* thread-safe?
If you were running multiple threads (which I don't know,
so this warning may be moot), then you risk getting non-unique
IDs!

 

[Tom Hawtin]

Are you aware, that this is *not* thread-safe?
If you were running multiple threads (which I don't know,
so this warning may be moot), then you risk getting non-unique
IDs!

That has come up in different replies.

But anyway: It's extremely fragile to assume that you are running in
only a single thread, and therefore write *thread-hostile* code. (It
also doesn't help to use an access modifier other than private, or to
miss off final.) Using synchronized, or better AtomicInteger (or better
AtomicLong), adds very little cost while not requiring this small,
low-level piece of code depending upon large scale assumptions. The
thing about making unnecessary, hidden assumptions is that they often
turn out, or become, incorrect.

Tom Hawtin

 

[Bent C Dalager]

What kind of safeguards does Java have in place so this doesn't overload my
CPU or RAM?

Unless you override it, the Java VM will stop at 64 (or is it 128?) MB
of RAM usage and produce OutOfMemoryException if it still needs more.
This will tend to terminate the program. CPU usage is best controlled
via your OS (set the process to low priority, up its nice value, etc.,
depending on which OS you're using).

Cheers
Bent D

 

[Hal Vaughan]

Are you aware, that this is *not* thread-safe?
If you were running multiple threads (which I don't know,
so this warning may be moot), then you risk getting non-unique
IDs!

All the classes are created in a single thread *before* control is turned
over to Swing.

Hal

 

[Roedy Green]

Is there any way to get a unique string or number for each object that is
created by a particular JVM?

The hash is almost unique.

 

[Roedy Green]

Is there any way to get a unique string or number for each object that is
created by a particular JVM?

You can do it sequence numbering your objects in the constructor.