| NPE in ComparisonUtil.isContainedInFeatureMap [message #1766826] |
Tue, 27 June 2017 12:42  |
Eclipse User |
|
|
|
Hi,
when switching from EMFCompare 3.0.1 to 3.2.1, I am getting NPEs in ComparisonUtil.isContainedInFeatureMap. I attached the NPE below.
The direct cause seems to be that in the first line of code in the body
public static boolean isContainedInFeatureMap(EObject object) {
final EAnnotation annotation = object.eContainingFeature()
.getEAnnotation(ExtendedMetaData.ANNOTATION_URI);
the compared object doesn't have a containing feature (it's the root object of the model). It seems this code has been introduced in 3.1.0.
Probably our way of starting the comparison is wrong (for 3.1.0 and later), here is a snippet:
IComparisonScope scope = EMFCompare.createDefaultScope(rset1, rset2);
Comparison comparison = EMFCompare.builder().build().compare(scope);
I could fix my specific issue by reverting to EMFCompare 3.0.1, but maybe it is a real bug and should be fixed (and we could keep using head).
Regards,
Klaus
java.lang.NullPointerException
at org.eclipse.emf.compare.internal.utils.ComparisonUtil.isContainedInFeatureMap(ComparisonUtil.java:570)
at org.eclipse.emf.compare.diff.DefaultDiffEngine.isFeatureMapMoveFromNonFeatureMapContainment(DefaultDiffEngine.java:880)
at org.eclipse.emf.compare.diff.DefaultDiffEngine.computeMultiValuedFeatureDifferencesTwoWay(DefaultDiffEngine.java:800)
at org.eclipse.emf.compare.diff.DefaultDiffEngine.computeDifferences(DefaultDiffEngine.java:556)
at org.eclipse.emf.compare.diff.DefaultDiffEngine.checkForDifferences(DefaultDiffEngine.java:161)
at org.eclipse.emf.compare.diff.DefaultDiffEngine.diff(DefaultDiffEngine.java:125)
at org.eclipse.emf.compare.EMFCompare.compare(EMFCompare.java:234)
at org.eclipse.emf.compare.EMFCompare.compare(EMFCompare.java:178)
[...]
|
|
|
| Re: NPE in ComparisonUtil.isContainedInFeatureMap [message #1767007 is a reply to message #1766826] |
Thu, 29 June 2017 09:14  |
| Eclipse User |
|
|
|
Hi,
This sounds and looks like a bug. We're checking if the object is contained within an annotation so I guess not having a containment feature also means that it's not contained within an annotation :). It would be easy to add a null check to avoid the exception, but that won't be enough if there are more bugs related to the same assumption later in the code. would you be able to provide us with a reproduction sample on bugzilla?
Laurent Goubet
Obeo
|
|
|
Powered by
FUDForum. Page generated in 0.03436 seconds
Home