Skip to main content

Say No to Properties Boilerplate!

Posted by cayhorstmann on June 8, 2006 at 4:15 PM PDT

Here is a simple code example from the href="">JBoss EJB3

public class LineItem implements
   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)
   { = 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;

   @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:

public class LineItem implements
   @Id @GeneratedValue(strategy=GenerationType.AUTO)
   @Property private int id;
   @Property private double subtotal;
   @Property private int quantity;
   @Property private String product;
   @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 href="">M.S. thesis. He

  • 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)
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

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 href="">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 href="">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 href="">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.


Related Topics >>


Link is broken

Interesting !
Is the thesis material available somewhere (the link is broken).
There is a high risk of collison however with frameworks that use annotations on the getter/setter (e.g. Hibernate)
On the other hand the doclet concept is very intersting to build API public documentation: I always thought it a pain to have to comment or read comments at getter/setter level (after all, formally speaking the setter just sets and the getter just gets the value) while only the documentation about the property itself is useful, but this one is usually private...
Thanks !