Community
Participate
Working Groups
It's not possible to remove the existing super interfaces of a class using IDOMType.setSuperInterfaces with an empty array. This results in EMF's JMerger not being able to produce a result that matches the generated results after a model change. I'll attach a JUnit test to reproduce the problem and here's a patch to fix it: ### Eclipse Workspace Patch 1.0 #P org.eclipse.jdt.core Index: model/org/eclipse/jdt/internal/core/jdom/DOMType.java =================================================================== RCS file: /home/eclipse/org.eclipse.jdt.core/model/org/eclipse/jdt/internal/core/jdom/DOMType.java,v retrieving revision 1.39 diff -u -r1.39 DOMType.java --- model/org/eclipse/jdt/internal/core/jdom/DOMType.java 29 Mar 2006 03:13:59 -0000 1.39 +++ model/org/eclipse/jdt/internal/core/jdom/DOMType.java 6 May 2006 16:36:48 -0000 @@ -316,7 +316,7 @@ buffer.append(fDocument, fInterfacesRange[0], fInterfacesRange[1] + 1 - fInterfacesRange[0]); } } - if (hasInterfaces) { + if (hasInterfaces || fSuperInterfaces == EMPTY_SUPERINTERFACES) { if (fImplementsRange[0] < 0) { buffer.append(' '); } else {
Created attachment 40552 [details] JUnit test to reproduce the problem.
Created attachment 40553 [details] The patch as an attachment. The idea is simply to notice that the fSuperInterfaces is the special empty value and hence that the content should be generated as if the appropriate implements clause has already been appended, and since nothing was appended and we don't want anything appended, that's the right handling at this point in the content processing.
Isn't EMF supposed to move to DOM API instead of JDOM ? JDOM is deprecated.
We're still working to get migrated to AST, and will leave the JDOM-based version as the default for the next release.
Empty arrays are already supposed to be handled. I am investigating.
I tried your JUnit tests with RC3 and they passed. What version are you using?
Forget my last comment. I forgot the change the test name to include the right prefix. The tests were not run.
Created attachment 40639 [details] Proposed fix The given patch is considering the two parts after the extends and before the implements and the part after the implements and before the body start. The previous patch also works because the position of the implements range starts at the wrong location when a comment is located between the extends clause and the implements clause. This might be fixed in the future. This is why I prefer this one.
How important is it to get this into 3.2?
Olivier, It's not super important that it get in, just a nice to have. The bug has been there a long time and no one complained directly. It's much more likely that folks add stuff to a model rather than remove stuff, so it's not commonly encountered. It's really your call as to the risk associated with the fix. There's always the risk that the fixed behavior will upset someone else relying on the incorrect behavior...
If the bug was noticed a while ago, it should have been reported earlier. Now we are close to RC4. So it is late in the game. Philippe, this is your call.
As Ed said: not critical. Thus it doesn't qualify for RC4. This isn't a regression, and sitting in deprecated code which has been wrong since ever I suspect. This being said, we should be able to schedule this for a 3.2.1.
Fixed in 3.2.1 branch. Regression test added in the JDOMTests.
Released for 3.2.1 Released for 3.3 M1 while merging TARGET_321 in HEAD
Verified for 3.3 M1 using build I20060807-0010.
Verified for 3.2.1 using build M20060908-1655
