Community
Participate
Working Groups
Many classes implement equals and/or hashCode in a verbose way, or redefine some utility methods that are already present in recent Java. We should have this code relying on Objects.equals() or Objects.hashCode() utility.
Gerrit change https://git.eclipse.org/r/141597 was merged to [master]. Commit: http://git.eclipse.org/c/platform/eclipse.platform.ui.git/commit/?id=dfb72e8983e1e1998acd00e1839a26312f970f72
We are trying out Eclipse SDK 4.12 as platform for our product, we have noticed *1* new failure. The test that now fails checks some menus, comparing 1:1 the menu text. The test finds that there is a missing hotkey text for some menu entry that has a backing command. After looking into it, our product also seems to be missing that hotkey in the text of the menu item. I.e. normally we have some tree item context menu with text: Debug Ctrl+Alt+D Now we have: Debug After looking some more into it, it looks like the map BindingTable.bindingsByCommand no longer finds a ParametrizedCommand while in the following code (this is only a partial stack trace): at org.eclipse.e4.ui.workbench.renderers.swt.HandledContributionItem.updateMenuItem(HandledContributionItem.java:260) at org.eclipse.e4.ui.workbench.renderers.swt.AbstractContributionItem.update(AbstractContributionItem.java:129) at org.eclipse.e4.ui.workbench.renderers.swt.AbstractContributionItem.fill(AbstractContributionItem.java:264) at org.eclipse.jface.action.MenuManager.doItemFill(MenuManager.java:728) at org.eclipse.jface.action.MenuManager.update(MenuManager.java:805) at org.eclipse.jface.action.MenuManager.update(MenuManager.java:672) at org.eclipse.e4.ui.workbench.renderers.swt.MenuManagerRenderer.scheduleManagerUpdate(MenuManagerRenderer.java:1223) at org.eclipse.e4.ui.workbench.renderers.swt.MenuManagerRenderer.processContents(MenuManagerRenderer.java:653) at org.eclipse.e4.ui.workbench.renderers.swt.MenuManagerRenderer.subscribeTopicChildAdded(MenuManagerRenderer.java:329) at sun.reflect.GeneratedMethodAccessor30.invoke(Unknown Source) The method in question is: org.eclipse.e4.ui.bindings.internal.BindingTable.getSequencesFor(ParameterizedCommand) I observe that the argument is object XYZ that represents command A. The map BindingTable.bindingsByCommand stores object JKL which also represents A. With our product based on Eclipse SDK 4.10 platform, BindingTable.getSequencesFor() finds the object in the map BindingTable.bindingsByCommand. With Eclipse 4.12 SDK platform, this is no longer the case. After adding the changes to ParameterizedCommand.hashCode() and ParameterizedCommand.equals() from this bug (bug 546994) to our 4.10 platform, our tests fails also on the 4.10 platform. I.e. the new implementations for hashCode() and equals() (I see that java.util is used) do not match the old implementations and break maps containing ParameterizedCommand objects. Its unclear what the impact is, other than the mentioned missing hotkey information in context menu entries. I'll open a major defect for this regression, as again, its unclear what the impact of the now broken hashCode/equals is. I'll try to come up with a minimal Eclipse-only example first though.
Hi Simeon, Can you please already open a new ticket reposting your comment? I think it can already be investigated and discussed in the current state.
New Gerrit change created: https://git.eclipse.org/r/142251
(In reply to Mickael Istria from comment #3) > Hi Simeon, Can you please already open a new ticket reposting your comment? > I think it can already be investigated and discussed in the current state. I will just reopen this bug, the number of bugs is too high and we can't spent time to generate reproducer for all of them.
Created attachment 278631 [details] Plugin to reproduce the problem with. Click hello world button on main toolbar to check hashCode/equals behaviour with and without the patch for bug 546994. Sorry, this is the best that I have. I've tried to define 2-3 commands as done in our product, however our product defines a view, a tree in the view, a context menu that changes based on the tree item types and we have 10+ commands. I've not been able to reduce this to a small Eclipse-only based example. The attached plug-in defines a command, which runs some code. The code will retrieve the same command with the same parameter twice, and test for hashCode and equals equality. Without the patch here (I'm using I20190505-1800), the two ParameterizedCommand objects have equal hash codes and are equal according to equal(). With the patch for bug 546994 (this bug), equals() returns false. At least the object with which the context menu queries for the menu item command is created in the same manner as in the example snippet I attached. As to the contents of the command to key bindings map, I'm not sure how those are created. I don't think this matters much though; as already seen by Mickael's change (https://git.eclipse.org/r/#/c/142251/), ParameterizedCommand.equals() as asymmetrical to ParameterizedCommand.hashCode(). The equals() method doesn't do a deep-equals for the parameters, while the hashCode() combines hash codes from each parameter. In addition, obviously the ParameterizedCommand.equals() behaviour changed. There are a ton of changed classes, I've not looked into any of those but ParameterizedCommand. It probably makes sense to go over them ASAP. A broken hashCode/equals contract is very difficult to debug and is far from the first place a developer would look into in case of regressions.
Gerrit change https://git.eclipse.org/r/142251 was merged to [master]. Commit: http://git.eclipse.org/c/platform/eclipse.platform.ui.git/commit/?id=4e383f8f0575316f03a23c7d2c43e615a33fa254
This change fixes our ART failure: https://git.eclipse.org/c/platform/eclipse.platform.ui.git/diff/bundles/org.eclipse.core.commands/src/org/eclipse/core/commands/ParameterizedCommand.java?id=4e383f8f0575316f03a23c7d2c43e615a33fa254
OK, looks like we don't see related problems in tests anymore.
