It seems that if you are using Sun or IBM JDK1.3+ then you are not going to have this issue (with their JIT compilers). There is a mention you may have 'another issue' but that is not stated what this other issue is? (Thats not very helpful).
For me, I'd say that double-checked locking code is so common I'd expect JIT compilers to follow the Sun/IBM approach to avoid the issue.
Do we know specifically which JIT compilers still have this issue? Sychronization is generally an expense we want to avoid if we can (so I am not keen on the recommendations of the article).
posted 13 years ago
If we limit ourselves to jdk1.5+ are we safe?
As long as it is not in the spec then i would not buil on it. There are people around here who know the JLS and JVM Specs pretty good (obviously i am not one of those :-) ).
But right now, if you think that you need syncrhonization (probably pretty rare situations where you need it - different threads calling the equals() on the same instance ... but still required to make it work in 100% and not just 99.9%) then you'll need to sync the whole method/block.
Or you could avoid the lazy init ? Just create this Object upfront or in some init block ? Or use super.equals() (as long super class is java.lang.Object this should not make any difference ?). Early in the mornin' here... so i did not think this trough.
Stupid collections anyway. Why do they need equals/hashCode. Can't they just do the job without bothering programmers ? They should know if Objects are equal. Just like that. Can't be that hard :-)