Defining a derived attribute "name" and a method "setName" causes the containing class to become abstract when generating Java code.

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Paste the following code in Umple Online and generate Java code for it.

class Person {
  String firstName = "Tyler";
  String name = { "Your first name is "+getFirstName() };

  public void setName(String newName)
  {
    setFirstName(newName);
  }  
}

What is the expected output?

The expected output is a concrete Java class with the methods getFirstName(), 
setFirstName(String aFirstName), getName(), and setName(String newName) - along 
with the other auto generated methods. Each method's implementation should be 
as expected based on the Umple code below.

What is the actual output?

The actual output is an abstract Java class with the methods getFirstName(), 
setFirstName(String aFirstName), and getName() - along with the other auto 
generated methods. That is, the Java class has been made abstract even though 
it was never defined as such, and the setName(String newName) method is not 
created in the generated class.

Other notes:
 - This problem only occurs for Java code generation

Original issue reported on code.google.com by TylerJDMcConnell on 14 Mar 2014 at 3:27

• Blocking: #523

[GoogleCodeExporter]

Original comment by TylerJDMcConnell on 14 Mar 2014 at 3:27

• Now blocking: #523

[GoogleCodeExporter]

Original comment by TimothyCLethbridge on 21 Mar 2014 at 6:19

• Added labels: Priority-High
• Removed labels: Priority-Medium

[GoogleCodeExporter]

Original comment by TylerJDMcConnell on 4 Apr 2014 at 7:17

• Changed title: Defining a derived attribute "name" and a method "setName" causes the containing class to become abstract when generating Java code.

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

As per my conversation with Andrew and Miguel, we believe the expected 
behaviour for this bug is to:
 1) Remove any defined mutator/accessor methods which are named in conflict with a derived attribute during compilation. For example, if a derived attribute is named "class" and a method named "getClass" or "setClass" exists, then the compiler will remove the "getClass" or "setClass" method
 2) Display a compiler warning to the user stating that their conflicting method(s) was removed and explain exactly why it was removed, with the steps the developer should take to correct the warning. The message would be something like, "Ignoring method named '<conflicting method name>' because there exists a derived attribute named '<derived attribute name>'. Derived attributes should not have explicitly defined getters/setters. Please either remove the conflicting method or turn the derived attribute to a regular attribute."

Original comment by TylerJDMcConnell on 18 Apr 2014 at 5:26

[GoogleCodeExporter]

Once this issue is complete, another issue should be created to encapsulate the 
effort required to change all code producing the new warning from this issue.

Original comment by TylerJDMcConnell on 24 Apr 2014 at 3:39

[GoogleCodeExporter]

As far as I can tell, this issue is fixed. The compiler ignores the 
user-defined methods that have naming conflicts with umple-generated methods. 

The Java generator produces a concrete class for the example above, and leaves 
out the user-defined method setName.

Original comment by CraigBry...@gmail.com on 9 Feb 2015 at 3:06