wood burning stoves 2.0*
The moose likes Java in General and the fly likes hashCode for temporarly id ? Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Java » Java in General
Bookmark "hashCode for temporarly id ?" Watch "hashCode for temporarly id ?" New topic
Author

hashCode for temporarly id ?

nimo frey
Ranch Hand

Joined: Jun 28, 2008
Posts: 580
I use the Objects.hash and Objects.equals-Methods of Java7 to override hash/equals-Method. All works fine.

I have this question:

Can I use the hashCode of an instance for temporarly identification or should I use a string-version (by overriding toString) to identify this object.

For example:

The instance a of type O is represented by the hashCode '1448505687' and this string-version "hobbies: soccer|name: paul|age:22|state:null".

I have a list of O's and want to look, if the list contains the "instance a", which I get it from the client.
The client has either the hashCode or the string-version of the instance!
So I get only the hashCode or the string-version of "instance a".

Which version should I use:

// client gives me the instance a in form of the hashCode


// client gives me the instance a in form of an identifiable string-version of a:


So which version should I use? Both actually works, but I am not sure, if I can rely on the hashCode everytime. Which is better?
E Armitage
Rancher

Joined: Mar 17, 2012
Posts: 892
    
    9
1.) Those methods are not substitutes for writing hashCode methods. They are just helper for null safe invocations of hash code and equals.
2.) hashCode should not be used to identify if objects are equal or not. You should use the equals method for that. Equal objects must have the same hashCode but unequal objects don't have to have unequal hasCodes.
nimo frey
Ranch Hand

Joined: Jun 28, 2008
Posts: 580
1) I know. I wrote my hashCode/equals-Method with these methods.

2) I am generating the hashCode of an instance and cast it to a string X. This string, I gave it to the client (for example: web-view). When client sends the X to me, I can look, what object it is by using String.valueOf(_o.hashCode).equals(X).

As I stated before: The client has no java-object, so I cannot use _o.equals(X), because X is not a Java-Object, it is a string-identification of the java-object.

The only question I have is:

Should I use a toString-Method of the instance or can I rely on the computed hashCode (which is also unique) to identify my object-instance from the client to the server.

Actually it works without failure, but I am not sure, if I made it totally right.
E Armitage
Rancher

Joined: Mar 17, 2012
Posts: 892
    
    9
The point is that hashCodes are not required to be unique so don't use them as object identifiers to begin with.
nimo frey
Ranch Hand

Joined: Jun 28, 2008
Posts: 580
Oh, actually I have no collisions - all my instances are identifiable via the string version of the hashCode.

So what should I use instead? Should I override the toString-Version for identification?

So I do not use this '1448505687' but use the string-version "hobbies: soccer|name: paul|age:22|state:null". Is this better?
Campbell Ritchie
Sheriff

Joined: Oct 13, 2005
Posts: 39878
    
  28
nimo frey wrote:Oh, actually I have no collisions . . .
That is luck. You might have collisions in future. You could consider the identity Hash Code, but you should check carefully whether that will give unique results.
Jeff Verdegan
Bartender

Joined: Jan 03, 2004
Posts: 6109
    
    6

nimo frey wrote:Oh, actually I have no collisions - all my instances are identifiable via the string version of the hashCode.


I still wouldn't use hashCode as an identifier, for the simple reason that that's not its job.

So what should I use instead? Should I override the toString-Version for identification?


I wouldn't do that either, as that's not toString()'s job.

If you want an ID, create a getId() method. It might return a UUID that you generate for each object, or a sequence number that gets atomically incremented each time an object is created, or, maybe, I suppose it could return the same thing as toString(). I wouldn't do that last one though, personally.
nimo frey
Ranch Hand

Joined: Jun 28, 2008
Posts: 580
I guess, I dont want to use the identityHashCode.

It is better to use a real unique id. However, I do not persist the entity in a database, so I am not able to use a database-id-field.

I guess, I cannot use the

UUID a = UUID.randomUUID();

When I generate a UUID for the instance x and the client sends that UUID back to me, the instance x is no more binded to that UUID.
So I cannot compare it with the servers UUID as generating a new one for the instance x results in another UUID. I cannot use a singleton-class or the like.


Maybe, this is the right thing to do:
UUID b = UUID.fromString(this.toString());

I dont know.

However, I guess, the best is to use override the toString()-Method of my Object and use the String as a Identifier.

Both, Thanks for your help!
Campbell Ritchie
Sheriff

Joined: Oct 13, 2005
Posts: 39878
    
  28
I like JV’s suggestion of an automatically incremented field.
Jeff Verdegan
Bartender

Joined: Jan 03, 2004
Posts: 6109
    
    6

nimo frey wrote:
I guess, I cannot use the

UUID a = UUID.randomUUID();

When I generate a UUID for the instance x and the client sends that UUID back to me, the instance x is no more binded to that UUID.


It is if you make that a field of the object.

So I cannot compare it with the servers UUID as generating a new one for the instance x results in another UUID.


HUH???


Maybe, this is the right thing to do:
UUID b = UUID.fromString(this.toString());


That's pointless. That's no different than just using toString(), and I don't see why you think it's better than generating a final UUID at creation time. I'm also pretty sure it won't work, as UUIDs need to have a certain format.

Honestly, at this point, your requirements are pretty unclear.
nimo frey
Ranch Hand

Joined: Jun 28, 2008
Posts: 580
Hello both,

sorry sorry. I was so blind! Yes, you are absolutely right.

It is if you make that a field of the object.


I like JV’s suggestion of an automatically incremented field.


I was lost in fussiness;) (Serializable objects and so on..). But now it is clear!

Thank you for your patient!

Jeff Verdegan
Bartender

Joined: Jan 03, 2004
Posts: 6109
    
    6

Cool! Glad you figured it out!
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: hashCode for temporarly id ?