jira.codehaus.org

  • Log In Access more options
    • Online Help
    • Keyboard Shortcuts
    • About JIRA
    • JIRA Credits
    • What?s New
  • Dashboards Access more options (Alt+d)
  • Projects Access more options (Alt+p)
  • Issues Access more options (Alt+i)
  • groovy
  • GROOVY-3211

Groovy doesn't follow JavaBeans Specification on method name to property name decapitialization

  • Log In
  • Views
    • XML
    • Word
    • Printable

Details

  • Type: Bug Bug
  • Status: Closed Closed
  • Priority: Major Major
  • Resolution: Fixed
  • Affects Version/s: 1.5.6, 1.6-beta-1, 1.5.7, 1.6-beta-2
  • Fix Version/s: 1.6-rc-1, 1.6-rc-2
  • Component/s: None
  • Labels:
    None
  • Patch Submitted:
    Yes

Description

Like the title says.

For a Groovy property named 'PROPERTY' for example, rather than following JavaBeans Specification section 8.8 which says to preserve the initial capital, Groovy will always lowercase it.

Sun Microsystems 57 10/12/97

8.8 Capitalization of inferred names.

When we use design patterns to infer a property or event name, we need to decide what rules
to follow for capitalizing the inferred name. If we extract the name from the middle of a normal
mixedCase style Java name then the name will, by default, begin with a capital letter.

Java programmers are accustomed to having normal identifiers start with lowercase letters.
Vigorous reviewer input has convinced us that we should follow this same conventional rule
for property and event names.

Thus when we extract a property or event name from the middle of an existing Java name, we
normally convert the first character to lowercase. However to support the occasional use of all
upper-casenames, we check if the first two characters of the name are both uppercase and if
so leave it alone. So for example,

"FooBah" becomes "fooBah"
"Z" becomes "z"
"URL" becomes "URL"

We provide a method Introspector.decapitalize which implements this conversion rule.

This isn't an all one way deal though. Groovy has another rule about looking at the initial letter in some contexts to decide whether the name is a class (uppercase) or a property/method name (lowercase).

Also it would be difficult to preserve property names that begin with an initial lowercase and the rest if uppercase because the JavaBeans decapitalization rule will upcase that initial letter. Fixing that would require Groovy to generate a BeanInfo for the class in those cases (or all cases which would allow for dispensing with the expensive introspection/reflection stuff).

  • Options
    • Sort By Name
    • Sort By Date
    • Ascending
    • Descending
    • Download All

Attachments

  1. Text File
    the-real-propname-patch-again.txt
    17/Dec/08 1:23 PM
    11 kB
    Jim White

Issue Links

is depended upon by

Bug - A problem which impairs or prevents the functions of the product. GROOVY-3208 Static properties of Groovy classes not seen by subclasses

  • Critical - Crashes, loss of data, severe memory leak.
  • Closed - The issue is considered finished, the resolution is correct. Issues which are not closed can be reopened.

Activity

Ascending order - Click to sort in descending order
  • All
  • Comments
  • Work Log
  • History
  • Activity
Hide
Permalink
Jim White added a comment - 17/Dec/08 10:41 AM

For the 'initial lowercase then all caps' case ('pPROP'), would it be possible to not upcase the initial letter for the getter/setter?

Show
Jim White added a comment - 17/Dec/08 10:41 AM For the 'initial lowercase then all caps' case ('pPROP'), would it be possible to not upcase the initial letter for the getter/setter?
Hide
Permalink
Jim White added a comment - 17/Dec/08 12:48 PM

This patch gets all the places in Groovy that deals with this property name case conversion stuff to use the same two methods (Introspector.decapitalize and MetaClassHelper.capitalize).

MetaClassHelper.capitalize is also changed to match Introspector.decapitalize so that and initial lowercase followed by uppercase is left unchanged.

The consequence is that 'PROP' and 'aPROP' both work as expected.

The only breaking change is for getter/setter names for properties whose names are like 'aPROP'. The setter/getter is now named 'getaPROP'/'setaPROP'.

I think this is a pretty good solution, but of course discussion is welcome and I wait until some positive votes before committing.

Show
Jim White added a comment - 17/Dec/08 12:48 PM This patch gets all the places in Groovy that deals with this property name case conversion stuff to use the same two methods (Introspector.decapitalize and MetaClassHelper.capitalize). MetaClassHelper.capitalize is also changed to match Introspector.decapitalize so that and initial lowercase followed by uppercase is left unchanged. The consequence is that 'PROP' and 'aPROP' both work as expected. The only breaking change is for getter/setter names for properties whose names are like 'aPROP'. The setter/getter is now named 'getaPROP'/'setaPROP'. I think this is a pretty good solution, but of course discussion is welcome and I wait until some positive votes before committing.
Hide
Permalink
Jim White added a comment - 17/Dec/08 1:23 PM

A slight tweak to the patch. The previous one allowed too many method names to be seen as setter/getter names. For a getter/setter to have a valid (standard design pattern, that is) JavaBean property name, either the first and/or second letter will be uppercase.

Show
Jim White added a comment - 17/Dec/08 1:23 PM A slight tweak to the patch. The previous one allowed too many method names to be seen as setter/getter names. For a getter/setter to have a valid (standard design pattern, that is) JavaBean property name, either the first and/or second letter will be uppercase.
Hide
Permalink
Jim White added a comment - 17/Dec/08 2:22 PM

Committed to trunk (cs14463). Waiting for some feedback before merging to 1.6.

Show
Jim White added a comment - 17/Dec/08 2:22 PM Committed to trunk (cs14463). Waiting for some feedback before merging to 1.6.
Hide
Permalink
Jim White added a comment - 18/Dec/08 5:59 PM

Well, things have been strangely quiet considering all the discussion when these issues came up. Lacking any "No Jim, don't do it!", I have merged this change to 1.6 (cs14498).

Note that this is a breaking change from 1.5.

In particular, the getter/setter for 'aProperty' is now 'getaProperty' rather than 'getAProperty' (which now is for a property named 'AProperty').

Shouldn't we have a special list of issues that break backwards compatibility in some significant manner?

Show
Jim White added a comment - 18/Dec/08 5:59 PM Well, things have been strangely quiet considering all the discussion when these issues came up. Lacking any "No Jim, don't do it!", I have merged this change to 1.6 (cs14498). Note that this is a breaking change from 1.5. In particular, the getter/setter for 'aProperty' is now 'getaProperty' rather than 'getAProperty' (which now is for a property named 'AProperty'). Shouldn't we have a special list of issues that break backwards compatibility in some significant manner?

People

  • Assignee:
    Jim White
    Reporter:
    Jim White
Vote (0)
Watch (0)

Dates

  • Created:
    17/Dec/08 10:29 AM
    Updated:
    23/Dec/08 5:58 AM
    Resolved:
    18/Dec/08 5:59 PM
  • Atlassian JIRA (v5.0.4#731-sha1:3aa7374)
  • Report a problem
  • Powered by a free Atlassian JIRA open source license for Codehaus. Try JIRA - bug tracking software for your team.