Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 171463

Summary:	[Working Sets] hashCode of workingSet may change
Product:	[Eclipse Project] Platform	Reporter:	Michael Valenta <Michael.Valenta>
Component:	UI	Assignee:	Platform UI Triaged <platform-ui-triaged>
Status:	CLOSED WONTFIX	QA Contact:
Severity:	normal
Priority:	P3	CC:	danielfriederich, eclipse, Michael_Rennie
Version:	3.3
Target Milestone:	---
Hardware:	PC
OS:	Windows XP
Whiteboard:	stalebug

Description Michael Valenta

2007-01-23 16:39:32 EST

The current implementation of hashCode in WorkingSet can change if the name or elements of the working set change. Is it possible to have two working sets in the workbench that are equal but not identical? I ask because the working set manager seems to control the instances. Perhaps the hashCode need only use the inherited hash and equals. Otherwise, a non-mutable property should be used for the hashCode.

Comment 1 Kim Horne

2007-01-24 08:29:40 EST

I wonder if this is the cause of our dynamic test failures.  A mutable hash code could certainly mess up any cleanup operations we have... mmm.

Strictly speaking yes, it is possible - the working sets only have one namespace after they've been added to the manager.  Up until then they're anonymous.  We also have the constraint that you cant add the "same" working set to the manager (based on name).  Perhaps we can generate the hash code from the original name the set was made with and not have it based on the current name/elements.

Comment 2 Kim Horne

2007-05-08 11:17:47 EDT

No time ATM.

Comment 3 Kim Horne

2007-09-12 08:53:33 EDT

*** Bug 202960 has been marked as a duplicate of this bug. ***

Comment 4 Kim Horne

2007-09-12 08:55:39 EDT

Patch from bug 202960 applie to HEAD - concerns or not it seems better than what we have now.

Comment 5 Kim Horne

2007-09-18 15:27:45 EDT

We still have a mutable hash code although it's FAR less likely - if you dork with the edit page ID it will still change.  Reopening.

Comment 6 Darin Wright

2007-09-24 12:02:02 EDT

*** Bug 184915 has been marked as a duplicate of this bug. ***

Comment 7 Boris Bokowski

2009-05-06 16:48:50 EDT

Removing 3.5 target milestone. We are in the end-game now. Please have a look and decide if this should be targeted at 3.6.

Comment 8 Daniel Friederich

2009-09-16 15:52:26 EDT

I came across this issue when looking into bug 238956,
the WorkingSet.hashCode function as it is used as hash value for BreakpointContainer (as in bug 184915).
The applied fix however does not really suffice for me as the hash code still encodes the working set name, which is user editable.
So when a breakpoint working set name is changed, then various maps (in BreakpointContainer and in StructureViewer) do no longer find the entries and some UI updates fail. Locally worked around them, but this is the underlying issue.

Comment 9 Lars Vogel

2019-11-08 04:37:48 EST

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.

If the bug is still relevant please remove the stalebug whiteboard tag.