Community
Participate
Working Groups
Build Identifier: I20100330-0800 OS:Windows 7 JRE:IBM JRE 1.6 Locale:Japanese When renaming variants that contain Ext-B characters with Alt+Shift+R, Java Editor does not open a hover help that shows more details. Reproducible: Always Steps to Reproduce: 1.Import bugXXXX.zip attached to this bug report, which is a Java project. 2.See screenshot1.png and screenshot2.png 3.Move the cursot on str\u53f1 and press Alt+Shift+R, it is correct. 4.Move the cursot on str\ud842\udf9f and press Alt+Shift+R, it is wrong.
Created attachment 163858 [details] bug308147.zip, a Java Project with screen shots.
To reproduce, the project encoding must be set to UTF-8. The problem is that codeSelect(..) doesn't work for the second local variable. The AST is fine in this case. The missing popup is because we fall back to the 'Rename in File' quick assist in that case (which is sometimes useful when the code is not compiling but should be used here).
(In reply to comment #2) > The problem is that codeSelect(..) doesn't work for the second local variable. > The AST is fine in this case. I think the problem comes from the region computation. On the second local variable the region length is 3 and not 4 even if the variable name has 4 characters. In org.eclipse.jface.text.TextViewerHoverManager#computeInformation() final IRegion region= hover.getHoverRegion(fTextViewer, offset); The region is computed using: Character.isJavaIdentifierPart(c) to find out if the next character should be included in the region. This is not that simple when Unicode 4 is involved. This is exactly the case here. \ud842\udf9f is a high surrogate followed by a low surrogate. If the first character is within 0xd800 and 0xdbff, then the second part must be within 0xdc00 and 0xdfff. You can see the way we read the next character in: org.eclipse.jdt.internal.compiler.parser.Scanner.getNextCharAsJavaIdentifierPart() We might have a bug in codeSelect(..), but the region's length must be fixed first. Moving back to JDT/UI for comment.
The fix for bug 308356 solves the steps in comment 0. But the Javadoc hover is still broken for such variables, since the JavaWordFinder does not consider supplementary characters. Since support for code points has only been added in Java 1.5, the fix needs to implement this manually (like the Scanner in JDT Core).
Original problem is fixed in HEAD, see bug 308612 for the hover.
I verified that this bug is fixed on I20100426-0852.
