Skip to main content

Arrows in the Back

Posted by cayhorstmann on January 7, 2007 at 3:25 PM PST

I had href="http://weblogs.java.net/blog/cayhorstmann/archive/2006/06/say_no_to_prope.html">blogged
on property boilerplate and the work of my graduate student Alexandre
Alves in the summer, but I didn't get much reaction then. But recently,
there has been a flurry of blogs on native property syntax. Let's try this
again.

Why Native Properties?

??? style="float: left; margin-right: 1em;" /> Many programmers are sick and
tired of boring, repetitive boilerplate code for JavaBeans properties.

Here is a simple code example from the href="http://docs.jboss.org/ejb3/app-server/tutorial/">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. Boring, repetitive lines.

Alex's implementation of native properties crunched it down to 12
lines. (Don't get hung up on the @Property syntax--see below...)

@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;@
}

??? style="float: left; margin-right: 1em;" />I thought this would be a total
no-brainer. Wouldn't you rather read 12 lines of code than 64 lines?

Well, apparently not everyone. There are many emotional reactions
floating around in the blogosphere.

"What's the Big Deal, Dude? My IDE Writes
Getters/Setters for Me!"

Does your IDE also read them to you, dude?

Seriously, maybe an IDE could do intelligent code folding and show you
a one-line property when it sees six lines of getter/setter pairs in the
code. That sounds rather fragile, but it would be better than nothing.

"The Arrows are So Ugly! No, they are Silly!"

??? style="float: left; margin-right: 2em;" />Where do the arrows come in, you
ask. There are several proposals for a property access operator.

  • Danny Coward href="http://blogs.sun.com/dannycoward/resource/Java7Overview_Prague_JUG.pdf">floated
    the arrow operator, such as item->quantity = 10;
  • Alex used the .@ operator, such as item.@quantity =
    10;
  • Many people say "Let's just use the dot--it works for C#"
  • Some people say "Let's not have any property access operator. Just
    call the getters and setters."

The arrow got people excited. Everyone loves to hate the arrow
(see href="http://weblogs.java.net/blog/jhook/archive/2006/12/jse_7_no_arrows.html">here,
href="http://www.kodewerk.com/java_70_language_feature_considered_harmful.htm">here,
and href="http://www.weiqigao.com/blog/2006/12/07/you_wont_believe_this_but_the_arrow_operator_is_coming_to_java_7.html">here).
I don't know why--it is just an operator. Maybe .@ is prettier?
Surely, there is some token that can be parsed unambiguously and that
doesn't cause emotional waves.

Using just the dot is unfortunately a minefield. You'd have to look
closely what item.quantity means. Is there an accessible field
quantity? Is there a quantity property? Who wins if both
are present? Or is that illegal? I am sure that one can cook up a set of
rules, but is it worth it? Why are people so attached to the dot? For
example, Peter von der Ahé href="http://blogs.sun.com/ahe/entry/java_se_7_wish_list">writes: "It
has to be '.' (dot). Anything else would look silly."

Having no operator at all might work. Look at the EJB3 example--most of
the getters and setters invocations are done through reflection anyway.

"Getters and Setters are Evil!"

??? style="float: left; margin-right: 1em;" />There is href="http://www.google.com/search?q=getters+and+setters+are+evil">a lot
of sanctimonious handwringing on how getters and setters break
encapsulation. Yup. They do. People should never write code like that
LineItem class. But guess what...they do.

Why do good people write such evil code? Many tools require bean
properties. If you write EJB3 entities, JSF components, client-side
components, etc. etc, you end up writing lots and lots of getters and
setters.

"Let's Break Free from Beans!"

??? style="float: left; margin-right: 1em;" />One of programmers at Borland
once told me how, around 1996, their team showed the Delphi GUI builder to
the Java group. Their eyes popped out. They had never seen a visual GUI
builder. They had never understood why people preferred Visual Basic over
AWT or Motif--after all, everyone knows that Basic is icky. But once they
realized that a VB programmer can do in a day what takes weeks in Motif,
they too wanted a GUI builder. A GUI builder shows a property sheet. Java
needed properties. That's how the JavaBeans spec was born--it fakes
properties as getter/setter method pairs. [I don't know if this story is
actually true--I'd love to hear from the Java veterans.]

Of course, faking properties as getter/setter method pairs has been an
ugly mess.

It is tempting to start with a clean slate. My guess, though, is, that
we will get some integration of native properties with
java.beans.Introspector, for compatibility with legacy code.

"Don't Break My Code with a New Keyword!"

Alex used the @Property annotation in his prototype. Sure, a
property keyword would have been nicer, but that breaks the
gabazillion lines of code that use property as a name. Then
again, annotations are not supposed to change the semantics of the class
to which they are applied, but Alex' @Property synthesizes
getters and setters. What can be done?

  • Abuse a rarely used keyword, such as static,
    super, or goto.
  • Use a token. That's what happened in Java 5. for (element :
    collection)
    instead of for (element in collection).

I think the token approach will probably win out. I hate to give an
example, because people will say "that's so ugly". But just to show that
it can be done...you can put an @ after the type. For example,
here is a quantity property.

public int @ quantity;

I know it's ugly. Don't tell me "native properties are a bad idea
because this syntax is ugly". Someone will come up with something
acceptable. Or we'll all get used to something ugly, just like we got used
to the colon in the for loop.

"Native Properties are Boring. Let's Talk About Closures
Instead!"

???Or reified generic types. Or XML
syntax. I am glad that people worry about solving (or creating) tomorrow's
problems, but property boilerplate is a problem that we have today.

Let's Go Beyond the Emotions

Before vilifying a proposal because of unsightly syntax, let's
summarize what one wants in native properties.

  • The common case--a private field and public getter/setter
    pair--should require minimal boilerplate.
  • It should be easy to supply getters and/or setters that do some
    other work.
  • It should be easy to specify read-only or write-only properties.
  • Javadoc should document properties.
  • There should be reflective access to properties.
  • Properties need to integrate with annotations.

Here are some issues that have been raised.

  • Should getters and setters of native properties be regular methods?
  • Should native properties be compatible with JavaBeans properties?
  • Should there be href="http://www.javalobby.org/java/forums/t88090.html">support for
    bound and vetoable properties?
  • Should properties have other than public visibility?

The issue that has gotten the most press, namely what operator, if any,
to use for property access, seems the least important one.

Related Topics >>