Bug 1257602 - Different naming conventions for 'aBcde' style fields
Different naming conventions for 'aBcde' style fields
Status: ASSIGNED
Product: JBoss BRMS Platform 6
Classification: JBoss
Component: Business Central (Show other bugs)
6.2.0
Unspecified Unspecified
medium Severity high
: ---
: ---
Assigned To: Mario Fusco
Lukáš Petrovický
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2015-08-27 08:29 EDT by Zuzana Krejčová
Modified: 2016-07-31 21:21 EDT (History)
5 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
For objects with names that have lowercase first letter and uppercase second letter, when using the guided editor, rule validation results in an error. This is caused by the guided editor expecting the setter method to have both the uppercase first and the second letters. Because only the first letter is capitalized in the setter method, validation fails. There are no workarounds for this issue at this stage.
Story Points: ---
Clone Of:
Environment:
Last Closed:
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Zuzana Krejčová 2015-08-27 08:29:39 EDT
Description of problem:
For data objects created in the Data Modeler, a field named 'aBcde' will get getter and setter named 'getaBcde' and 'setaBcde'.
Guided editors though will expect the setter to be named 'setABcde'.


Version-Release number of selected component (if applicable):
6.2 ER1


Steps to Reproduce:
1. Create a new Data Object via the Data Modeler.
2. Add a field of any type, give it a name like 'aBcde' (first letter lower case, second upper case). Save.
3. Switch to the Source tab.
4. Create a guided rule, bind the DO you just created to a variable.
5. Add action to change the 'aBcde' field to the RHS.
6. Switch to the Source tab.
7. Validate the rule.


Actual results:
Step 3. The setter method is called 'setaBcde'.
Step 6. The requested setter method is called 'setABcde'.
Step 7. Validation fails ("Unable to Analyse Expression...").


Expected results:
The setter method in both steps 3 and 6 is called the same. Validation passes.


Additional info:
Leaving it to component Business Central as I could not find any authoritative document on proper naming conventions for this case, therefore I cannot really say whether the fault is with the DM or the other guided editors.
Comment 2 Walter Medvedeo 2015-09-17 12:37:29 EDT
I agree with the comment above with reference to the existence of an authoritative document with a proper naming convention for this case. I couldn't find such a document at the moment of the initial implementation. 

But just to give more context I would say that both Eclipse and IntelliJIdea generates the same getter/setters as the data modeller.

i.e.

    String aBcde;

    public String getaBcde() {
        return aBcde;
    }

    public void setaBcde( String aBcde ) {
        this.aBcde = aBcde;
    }

So I guess that as soon users generates pojos with this IDEs and push them to bussines central, or uses them by importing a .jar in bussiness central we will fall in the same use case.

To change the getter/setter naming generation is not a problem and we can do it, but it will be great if someone of drools team can confirm this renaming.?
Comment 3 Edson Tirelli 2015-10-14 15:07:51 EDT
This is a bit tricky, but we must follow the javabean spec, more specifically section 8.8.:

"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 lower case 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 lower case. However to support the occasional use of all upper-case names, we check if the first two characters of the name are both upper case 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."

In order for the above to work when we go from the field name to the getter/setter name, we need to implement a capitalization rule that roundtrips the Introspector.decapitalize() method without breaking it. 

The following link has a good explanation:

http://dertompson.com/2013/04/29/java-bean-getterssetters/

So to be brief, when generating getters/setters for a given field name, check if the second letter is uppercase. If so, do not change anything. Otherwise, capitalize the first letter.

Walter, can you please check we adhere to this convention or fix it otherwise?
Comment 4 Walter Medvedeo 2015-10-15 06:42:09 EDT
yes, we adhere to the upper convention.

when it's said:

"check if the second letter is uppercase. If so, do not change anything. Otherwise, capitalize the first letter."

This is exactly what we do, If second letter is uppercase then we don't change it. And this is why in the example below we have that:

for - > String aBcde  (second letter upppercase)

we generate ->  
    public String getaBcde() and
    public void setaBcde( String aBcde ) 


For the private String iMessageId; example, provided in the link 
http://dertompson.com/2013/04/29/java-bean-getterssetters/ we generate the same as the link suggests.

ie. 

   public java.lang.String getiMessageId()
   {
      return this.iMessageId;
   }

   public void setiMessageId(java.lang.String iMessageId)
   {
      this.iMessageId = iMessageId;
   }

and I've used same field example with IntelliJ and eclipse, and both IDEs generates the same as the data modeller.

So I conclude that setters/getters generated by the data modeller are correct.
Comment 5 Zuzana Krejčová 2015-10-15 08:14:55 EDT
Walter are you sure the issue was fixed? As far as I understand, we only know, now, that the Data modeler does it right. It still has to be fixed in the guided editors though.
Could you reassign to whoever should be responsible for that?
Comment 6 Edson Tirelli 2015-10-15 08:58:36 EDT
If validation is failing, then it is probably an issue with MVEL compilation. Assigning it to Mario.

Zuzana, do you have the full error message you refer to here, please?

"Step 7. Validation fails ("Unable to Analyse Expression...")."
Comment 7 Walter Medvedeo 2015-10-15 09:34:57 EDT
Zuzana, good point! I forgot the original error :(.

Note You need to log in before you can comment on or make changes to this bug.