Community
Participate
Working Groups
Build Identifier: 20090920-1017 I think a short Example shows good what went wrong: Before: class Example { String aString; } After generate Getter/Setter: class Example { String aString; public String getaString() { return aString; } public void setaString(String aString) { this.aString = aString; } } This is not correct: Correct Names would be "getAString" und "setAString". At least this is what most reflection frameworks would try for property "aString". Reproducible: Always Steps to Reproduce: 1. See example above
Moving to JDT/UI.
(In reply to comment #1) > Moving to JDT/UI. We have a finger in the pie too: org.eclipse.jdt.core.NamingConventions.suggestGetterName(IJavaProject, char[], int, boolean, char[][])
(In reply to comment #2) > org.eclipse.jdt.core.NamingConventions.suggestGetterName(IJavaProject, char[], > int, boolean, char[][]) Yes. That's where it went wrong. Simply wrong suggestion. Same for Setter.
Back to JDT/Core.
This is contradicting with bug #154823. There appear to be conventions that require the getter/setter name to be either ways. For instance, frameworks such as Struts (and perhaps Spring too) require the first lower case character, if followed by an upper case char, to be kept as is. On the other hand, reflection seem to work the other way.
(In reply to comment #5) > ...There appear to be conventions that > require the getter/setter name to be either ways. For instance, frameworks such > as Struts (and perhaps Spring too) require the first lower case character... I don't think any framework expectation should drive the naming conventions. Apart from that a lower case after get/set is simply horrible to read. A bit C#isch. Also a lower case after get/set would mean there is no general rule. It would be a special case. No thanks. That are good reasons against the lower case. If you decide to do the lower case solution the code generation (getter/setter) and everything connected to it has to be adapted accordingly. Anyway... now it took month and there is still no solution in sight. What... I mean what the heck is going on there ? Its no rocket science!
As discussed in https://jira.springframework.org/browse/IDE-337 , the contradiction is already in the java.beans classes: java.beans.Introspector#decapitalize(String) and java.beans.NameGenerator#capitalize(String) (which is used in PropertyDescriptor) are not bijective. See also http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4727079 and http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6590463 . I think we should keep adhering to the JavaBeans spec (8.8 Capitalization of inferred names), which mentions Introspector#decapitalize(String).
I don't think eclipse can do anything here. Closing the bug.
For me this is against the java naming conventions: http://www.oracle.com/technetwork/java/codeconventions-135099.html#367 "Methods should be verbs, in mixed case with the first letter lowercase, with the first letter of each internal word capitalized." Any character after the get is the first of a internal word. I don't think that any specification out there should break this basic naming convention. I like to read things as they are: boolean iAtHome; void setiAtHome(boolean) { ... } // really - wow - When did I become a member ? // instead of void setIAtHome(boolean) { ... } // ah.. its about me... :) Looks sick to me.
(In reply to comment #9) > For me this is against the java naming conventions: I understand your concern. However, naming conventions are not rules by themselves. When we are talking of a specification, we have to give more importance to that, for many users will be left with broken code.
Verified for 3.7M5
*** Bug 343645 has been marked as a duplicate of this bug. ***
For the record: https://github.com/devonfw/cobigen/issues/1095
