Bug 1257602

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.?

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?

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.

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?

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...")."

Zuzana, good point! I forgot the original error :(.