Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ


Choose your language

InfoQ Homepage News The Great Property Debate

The Great Property Debate

Giving closures a break to start 2007, the Java community has taken up the topic of properties in recent days. A flurry of commentary revisiting the possibility of a property keyword and arrow operator has appeared. The discussion seems to have started largely as a result of a presentation at Prague JUG by Danny Corward, JavaSE Platform Lead. In the presentation he floates the idea of a few language additions related to properties in Java 7:

public property String foo;

a->Foo = b->Foo;

This resulted in a number of comments against arrows. Jacob Hookom wrote:

...I'm of the opinion that if you are willing to make a commitment to closures, then we do the same for properties-- something similar to C#. Spending time extending the long winded get/set convention is the wrong direction for the spec. Do everyone a favor and do properties right-- leaving the old Bean Property spec alone for APIs to accommodate and treating properties as a first class citizen in the metadata starting in SE 7...
Kirk commented:

...If this syntax can on encourage behavior that we don’t want than why on earth would the authors of the JSE 7.0 JSR propose such a change? My real answer is; since I’ve not spoken to the authors I don’t really know. However the evidence is the use case is ease of use for Java beans. Simply put, the spec lead for the next version of Java would like to change the language to handle an edge case while ignoring the potential of creating havoc in just about every other language use case...

Moving past the arrow for a moment Cay Horstmann provides a recap of the entire situation and mentions issues found along the way. In summary he writes:

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

Rate this Article