Unique java objects - different behaviour in run and debug

Question

I'm working on a program that relies on objects being unique. I work with the same object in 2 places, and when an update is done in one place, this should be reflected in the other.

If I debug the program (in eclipse), everything works. My 2 object references both point at the same object (ojbect1==object2 returns true). If I run exactly the same program (in eclipse), there are different objects in both references (same comparison shows false).

This object is instantiated multiple times, but one of those instances is saved in a TreeMap and picked up later. However, when I pick it up, sometimes (as described above) it's a different object, which does not hold any changes made to the original object in the meantime.

Does anybody have an idea why this is?

I cannot replicate the problem in a smaller scope so unfortunately I can't post code here.

So, is the problem only happening when you run it outside of eclipse? or only when you run it in release mode? — Sam I am says Reinstate Monica, Feb 13 '14 at 18:40
Object.hashCode() isn't reliable for checking uniqueness (==, not .equals()) in a debugger. Use System.identityHashCode(). It's almost right. — David Ehrmann, Feb 13 '14 at 18:41
It isn't just hasCode(), the behaviour is also different. If I make a change to the object in place 1, I see the change in place 2 *when I debug*, but I don't see it running exactly the same code *when I run* — tb189, Feb 13 '14 at 18:43
If you want to check an object on hashCode you must override hashCode and equals.. — Shekhar Khairnar, Feb 13 '14 at 18:47
OK the hasCode() is clearly confusing. I've changed my question to make it a bit more clear. — tb189, Feb 13 '14 at 18:53

score 1 · Answer 1 · answered Feb 13 '14 at 18:48

1

You shouldn't be using Object.hashCode() as a key in a Map because it is not guaranteed to be unique.

Is there something in your object that uniquely identifies it? If so, then use that as the key. If not, then create a synthetic key (for example, by incrementing a counter and storing the value in the object).

answered Feb 13 '14 at 18:48

jdigital

11,926
4
34
51

I'm not using hashCode() as a key, sorry if my question raised this confusion. I just use hashCode() in a System.out to see if my 2 references are pointing to the same object or not. – tb189 Feb 13 '14 at 18:51
Are you certain that the key you're using is unique? – jdigital Feb 13 '14 at 18:56
I'm using 3 different values of an Enum as key. Still, even if they weren't, you'd expect the same behaviour in run mode than in debug mode ... – tb189 Feb 13 '14 at 18:57
Can you reliably reproduce the problem? – jdigital Feb 13 '14 at 18:58

score 0 · Answer 2 · edited May 23 '17 at 12:05

0

If you need your program to have a single instance of a given class, you should implement a Singleton pattern.

The recommended way to do this since java 5 is to define an enum type with only one element, something like:

public enum MyEnum { 
  MY_SINGLETON_INSTANCE;

  // business logic, etc.

 }

This is (at least according to Josh Bloch ;) ) the easiest and safest way to ensure your object instance is unique, doesn't matter what you do.

Here is a broader and more complete discussion on this topic:

Implementing the singleton pattern in Java

edited May 23 '17 at 12:05

Community

1
1

answered Feb 13 '14 at 18:42

Jorge_B

9,712
2
17
22

I'm using multiple instances of this object, but want to share one of those instances in multiple places. The enum will not allow this (having multiple instances). – tb189 Feb 13 '14 at 18:45
I am very sorry, I misunderstood you. Probably jdigital's idea is worth having a look at – Jorge_B Feb 13 '14 at 18:50

score 0 · Accepted Answer · answered Feb 15 '14 at 17:40

Eventually, I found out the issue was multithreading. Apparently, I was calling the method that 'saved' the object I needed to share multiple times in multiple threads (once where I needed it, and once in a validation routine that runs whenever the user inputs). If the validation thread was activated between my main thread saving the object and picking it up again later, the saved object reference was overwritten. In debug mode, I ran my program step by step, so the other threads had either finished already, or were stalled by the debugger (not sure how this works in eclipse). The fix was to ensure I only saved the object when I needed it, by only allowing this 'saved' object to be written from the place where I needed it.

Unique java objects - different behaviour in run and debug

3 Answers3

Linked