Community
Participate
Working Groups
3.5 RC2. We have cases where IBinding.getJavaElement() returns 'null' where it should not according to the spec. This leads to broken features and possible NPEs. Test Case: 1. start with new workspace 2. check out org.eclipse.jdt.ui from CVS (HEAD is OK) 3. open org.eclipse.jdt.internal.ui.actions.SelectionConverter 4. in the editor select "getElementAtOffset" of the method declaration getElementAtOffset(ITypeRoot, ITextSelection) 5. Edit > Copy Qualified Name ==> error dialog The reason is that IBinding.getJavaElement() returns 'null'. If you want to debug, the relevant code is: org.eclipse.jdt.internal.ui.actions.CopyQualifiedNameAction.getSelectedElement(JavaEditor)
This is a very recent regression introduced during RC1 which needs to be fixed for for 3.5.
Maybe caused by fix for bug 275853?
I get: org.eclipse.jdt.internal.ui.actions.SelectionConverter.getElementAtOffset(ITypeRoot, ITextSelection) I followed the given steps. I'll try to get the RC2 build from a zip file. I used a workspace that was updated to RC2.
Just tried again. Here are more detailed steps: 1. download RC2 from here: http://download.eclipse.org/eclipse/downloads/drops/S-3.5RC2-200905221710/index.php 2. unzip it to an empty directory 3. start eclipse with a new workspace using the following VM: java version "1.6.0_13" Java(TM) SE Runtime Environment (build 1.6.0_13-b03) Java HotSpot(TM) Client VM (build 11.3-b02, mixed mode) 4. check out 'org.eclipse.jdt.ui' (HEAD) 5. open org.eclipse.jdt.internal.ui.actions.SelectionConverter 6. make sure to set the selection into the method name of the DECLARATION of getElementAtOffset(ITypeRoot, ITextSelection) 7. Edit > Copy Qualified Name IMPORTANT: make sure the editor is the active part when doing this ==> error dialog
Reproduced. I have a fix. I'll test it intensively till tomorrow for an integration inside tomorrow's 8pm build. As soon as I am done with the testing and it is successful, I'll attach the patch for review.
For 3.5, I'll revert the fix for bug 275853. This is the safest approach as the current code doesn't allow to return the "right" java element for two methods in the whole SDK. The old code is only failing for one method. So none of the two solutions is perfect, but at least the behavior will be consistent with what we had with 3.4.2. I'll work on a complete fix for bug 275853 for 3.5.1.
Fixed and released in HEAD by reverting previous fix.
I think we should add a regression test for this bug now so that we still understand the test case that caused the NPE.
I wrote a plugin that checks for all method declarations that they have a java element and that the java element's positions correspond to the right method declaration. So when the time comes to fix this issue, I can check that there is no method without the right java element in the whole SDK code base.
Verified for 3.5RC3 using I20090526-2000.
Re comment 9: Cool! I guess this runs too long to be included in a normal test, right?
Verified in I20090527-2000.
(In reply to comment #11) > Re comment 9: Cool! I guess this runs too long to be included in a normal test, > right? Yes, it takes a while, but you can be sure that a complete solution for bug 275853 will be released when the check is green.
