Here is a simple code example from the JBoss EJB3 tutorial.

@Entity
public class LineItem implements java.io.Serializable
{
   private int id;
   private double subtotal;
   private int quantity;
   private String product;
   private Order order;

   @Id @GeneratedValue(strategy=GenerationType.AUTO)
   public int getId()
   {
      return id;
   }

   public void setId(int id)
   {
      this.id = id;
   }

   public double getSubtotal()
   {
      return subtotal;
   }

   public void setSubtotal(double subtotal)
   {
      this.subtotal = subtotal;
   }

   public int getQuantity()
   {
      return quantity;
   }

   public void setQuantity(int quantity)
   {
      this.quantity = quantity;
   }

   public String getProduct()
   {
      return product;
   }

   public void setProduct(String product)
   {
      this.product = product;
   }

   @ManyToOne
   @JoinColumn(name = "order_id")
   public Order getOrder()
   {
      return order;
   }

   public void setOrder(Order order)
   {
      this.order = order;
   }
}

64 lines.

Here is what you want to read:

@Entity
public class LineItem implements java.io.Serializable
{
   @Id @GeneratedValue(strategy=GenerationType.AUTO) 
   @Property private int id;
   @Property private double subtotal;
   @Property private int quantity;
   @Property private String product;
   @ManyToOne
   @JoinColumn(name = "order_id")
   @Property private Order order;@
}

12 lines.

That's only 20% of the original. The remaining 80% is boilerplate.

And that's not even counting the Javadoc!

There has to be a better way. My graduate student Alexandre Alves has provided just that in his M.S. thesis. He implemented

• an extension to the Mustang javac compiler
• a Javadoc doclet
• an optional annotation processor
• Ant tasks for all these

His tools support the @Property annotation of the preceding example. Simply call his propjavac, and it synthesizes the getters and setters and adds a Properties section to the Javadoc.

But wait, there's more. We give you syntax for accessing the properties, almost like in JavaScript or Visual Basic:

LineItem item = new LineItem();
item.@subtotal = 100; 
   // calls item.setSubtotal(100)
em.persist(item);
int id = item.@id; 
   // calls item.getId()

We chose the .@ operator rather than the simple dot in JS/VB so that there is no confusion with the field access item.id.

Alexandre worked out the pesky details with visibility, read-only properties, BeanInfo, inheritance, and so on.

But there is still work to be done.

1. If this is to be a feature of Dolphin, we can't use annotations to generate the getters and setters. Annotations aren't supposed to modify the file in which they are contained. It doesn't seem likely that we can introduce a property keyword either. I suppose we could reuse super . . . NOT. But what about

   private int @id;
   private Order @order;

   That's just a token, which doesn't break backwards compatibility because you couldn't have an annotation at that spot. Too subtle, or just right?
2. Alexandre's property annotation has attributes for finetuning the code generation, such as making read-only properties, package visible getters and setters, etc. That's harder to do with just syntax. Does one need these features, or should one go by the 80/20 rule? After all, one can always write plain Java for the non-standard cases.
3. The JavaBeans specification has lots of seldom-used advanced features, such as BeanInfo, indexed properties, property change listeners, and so on. Some of them can be supported easily, others are trickier. I'll gladly elaborate if anyone is interested. Does anyone use these regularly, and if so, do you need boilerplate relief? For example, the JSP/JSF EL doesn't even deal with indexed properties.

I really want native properties to happen in Dolphin. I am sick of the boilerplate. Two years ago, I thought it would be too late, but I have learned from EJB3 that Java can do the right thing...after we've tried everything else.