Community
Participate
Working Groups
Problem occurs on Eclipse 3.2 but does not occur on 3.0.2 (on Windows XP) 1. Create an object which name starts with non-Latin character (i.e ööbik) 2. Choose Source -> Generate Getters and Setters 3. Generate them as usually Generated methods' names do not meet the naming convention: for example the get method for variable ööbik is getööbik() but it should be getÖöbik() -- the variable's name should start with capital letter. In addition (with the same example), if there is a method getÖöbik() getters/setters generator doesn't recognize that it is there already and lets us choose to generate getters/setters for variable ööbik. I tried with variables starting with characters: õ, ä, ö, ü, š and ž. Again, it is notable, that the error didn't occur on Eclipse 3.0.2.
Getter and setter names are created using NamingConvention.suggestGetterName. Moving to jdt.core
I can reproduce this bug on v3.3rc4 (WinXP) as well as it's non-occurence before v3.2. Precisely suggestGetterName(), as well as many other methods in NamingConventions, calls suggestAccessorName() to convert the first character to upper case. Unfortunately all character case conversion and testing methods used in NamingConventions rely on jdt.internal.compiler.parser.ScannerHelper which is imho quite inept since it cosiders only the first 128 ASCII character instead of all unicode character classes. Sees like this is a cross platform issue. As you can see on http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.jdt.core/model/org/eclipse/jdt/core/NamingConventions.java?view=log ScannerHelper is used in NamingConventions since revision 1.33 instead of java.lang.Character -- for performance reasons the annotation says. Character SUPPORTS unicode character classes and case conversion. Similar changes have been made in quite a lot other JDT-classes. For instance jdt.core.compiler.CharOperation uses ScannerHelper for case-insensitive char array comparison which still sounds quite unbelievable to me. I will implement a neat little benchmark to compare case conversion in Character and ScannerHelper to see wether there is a serious lack of performance in Character. I might as well use the performance tests in the cvs but until now I don't understand them. ;) Though I don't believe that the difference in performance justifies the disregard of non-ASCII letters which is a violiation of the Java Language Specification (http://java.sun.com/docs/books/jls/third_edition/html/lexical.html#3.8) and the Unicode Standard Annex #31 (http://unicode.org/reports/tr31/)
The bug is that ScannerHelper#toUpperCase() call Character#toLowerCase() instead of Character#toUpperCase() David - Methods of ScannerHelper call methods of Character when the character is above 128. So there is no problem in this area or i misunderstand what you suggest. If you still think there is a problem in this area please open a separate.
David, you didn't misunderstand me. I simply overlooked this. ;) In this case my task will be a lot easier since I only have to fix this single line in ScannerHelper#toUpperCase(). The patch will be coming right away.
Created attachment 72686 [details] Patch for bug 153125: fix case conversion in ScannerHelper#toUpperCase() Here is the patch. ScannerHelper#toUpperCase() now calls Character#toUpperCase().
Created attachment 72691 [details] Fix + Regression test Patch proposed by David Foerster + Regression test
Released for 3.4M1. Test added NamingConventionTests#testSuggestGetterName008()
Verified for 3.4M1 using build I20070802-0800.
