Community
Participate
Working Groups
The DefaultResourceDescriptionDelta will return true for haveEObjectDescriptionsChanged() if any of the compared EObject descriptions don't have the same order of the user data keys (see #equals(IEObjectDescription, IEObjectDescription)). I think it is OK to expect this (but should be documented), but we must make sure all implementations also satisfy this requirement. This is not the case with descriptions returned by StatefulResourceDescription#copyExportedObjects() or CopiedResourceDescription(IResourceDescription). The alternative is of course to change the comparison logic in DefaultResourceDescriptionDelta#equals(). Any thoughts on this?
Knut, could you please provide a patch for this issue?
Hi Sebastian, The question for me is how to fix the problem. From a performance perspective I would say that the IEObjectDescription#getUserDataKeys() array should be ordered and that DefaultResourceDescriptionDelta#haveEObjectDescriptionsChanged() should return "true" if this order is different. As a consequence all implementation classes should be updated. E.g. use ImmutableMap#copyOf() or similar when copying an IEObjectDescription. Do you agree with the proposed solution?
Since the constructor of org.eclipse.xtext.resource.EObjectDescription takes a map as a parameter. Do you really expect a significant performance penalty if you check them for equality in an order-independent manner? How many entries do you usually have in your user data?
Created attachment 203293 [details] patch for DefaultResourceDescriptionDelta We typically only have between 1 and 5 entries. But note that DefaultResourceDescriptionDelta also assumes that the getExportedObjects() maintains the insertion order for two IResourceDescriptions to be the same. The problem can be addressed locally in DefaultResourceDescriptionDelta.java as in the attached patch. I could of course also write some test cases.
please apply. A test verifying the equals method works as expected would be good, too.
Pushed fix to master.
Closing all bugs that were set to RESOLVED before Neon.0
