Community
Participate
Working Groups
When an Image is disposed, the handle of that image is set to 0. This has the side effect that the value returned by the hashCode method changes. This can cause problems if the image is ever used directly or indirectly as a key in a table and the image is disposed before the value stored in the table. One specific case of this involves using a JFace DecorationOverlayIcon in combination with a LocalResourceManager (see bug 175526). Generally, the hashCode of an immutable object like an Image shouldn;t change over the lifespan of the object. To work around this at the JFace level, I have modified the DecorationOverlayIcon to use an identity hash on the image. This is really only a problem if there are a large number of cases where multiple images share the same handle. My guess is that is rare for images to share a handle. Is this a correct assumption?
Here's a comment John made on bug 175526: I think it would be best to fix the implementation of Image equals and hashCode. Note also that unequal instances of Image become equal to each other after the images are disposed (since both their handles become zero). This isn't technically a violation of the equals/hashCode contract, but it's nevertheless confusing and likely to lead to errors for clients. Otherwise we'll need to track down and remove any use of Image as hashtable keys.
This has caused some troubles for me as well.
For reference, bug 236324 shows another victim of unstable image hash code.
Most subclasses of Resource have the same problem (e.g. Color, Font). A solution would be to implement isDisposed() using "device == null" and not set the handle to -1 in the implementations of destroy(). That way, the hashCode() stays stable, and the only remaining glitch is that disposed resources from different devices could be considered equal. But that's already the case today, and should rarely be an issue.
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant.
