Evan Summers's Blog

Property Problems, Solutions and Wishes

Here are some problems and possible solutions (today) relating to bean properties.

Getters and Setters

Problem. We don't wanna write lots of getters and setters, or see them.

Solution. We use our IDE to generate them.

Wishlist. Maybe we wanna fold basic getters and setters right out of view en masse.

Another Wishlist. People wanna see the introduction of property keywords eg. property, readonly, etcetera. Personally, i'm happy with getters and setters with the help of my IDE.

Property References

Problem. Property names are strings, which are not geared for IDEs (besides being highlightable as strings as opposed to numbers and keywords). So we can't expect, and don't get any help from our IDE, or even compiler. All we can expect is runtime errors, D'oh!

Solution. We unit test our code so that we catch problems before they can hurt us at runtime.

Further Solution. We might implement BeanInfo meta-classes where we explicitly expose the bean property descriptors. For example, in Gooey Beans Info, we introduce a PropertyDescriptor wrapper with methods that our forms and table models will invoke eg. property.get(bean) and property.set(bean, value), which support validation, type conversion, and throw useful exceptions.

Wishlist. I wish for a language notation eg. Person@surname to access a PropertyDescriptor in a convenient, auto-completable, verifiable and refactorable way in my favourite IDE.

Bound Properties

Problem. Lazy people like me don't wanna implement all the JavaBean boilerplate to fire PropertyChangeEvent's.

Solution. We can use AOP to introduce PropertyChangeSupport and fire PropertyChangeEvent's, eg. using CGLIB. We use our explicit BeanInfo meta-class as a factory to create our enhanced beans. (I'll try this out in a follow up blog.)

Wish. I wish my favourite IDE could create new Java Beans (with PropertyChangeSupport) and generate setters which fire PropertyChangeEvent's, and code-fold them to look like POJO's with regular setters.

Further Wish. I wish for a standard tool in my favourite IDE's default build process, for annotation processing for compile-time AOP code generation, to enhance classes ala Spoon at compile-time. This could support a @JavaBean aspect annotation to request that a POJO be enhanced into a Java Bean ie. having observable properties.

Comments

• I've just noticed that Cay Horstmann uses the a term "property literals" (where i have "properties references" in the above blog) - i like his term a lot more :) eg. for Person@surname. I guess a property literal could be a final reference to a static immutable PropertyDescriptor wrapper for a given class and property, and used to reference a property eg. for beans binding, rather than a string literal of the property name. The advantage is that the IDE (and compiler) would understand what it's dealing with, and so could afford us auto-completion, verification, and automatically renaming property literals ie. together with the setter/getter (and the compiler could verify literal property references).

  Posted by: evanx on January 11, 2007 at 02:14 AM

• I agree that a smart IDE with code folding would be at least a partial solution. But I do wonder if there isn't more to it. Here is an example. I am not an expert on bound properties, and I just looked at the source code for javax.swing.AbstractButton to see some actual examples of bound property firing. Oh boy. It was all over the map. I had to ask myself whether there was a reason for all the variations in the code. Not being an expert, it would have been quite helpful to see keywords or annotations instead of a dozen different ad-hoc implementations.
  Another analogy would be the enhanced for loop. I just love seeing for (x : coll) and not having to worry about checking whether something funny goes on in the loop. The IDE could have done it. But I am glad the language did.
  

  Posted by: cayhorstmann on January 11, 2007 at 08:13 AM

• 
  if and when property keywords are introduced to obviate having to implement getters and setters (for starters) where these are virtual until implemented, i'm sure i'll be using them gleefully.
  But i think that the more important issues with properties are, property literal references (for beans binding) and boilerplate for "bound properties" ie. that fire PropertyChangeEvents. To my mind, these are hugely more important than not having to ask our IDE to generate getters and setters and cold-fold them for us!?

  Posted by: evanx on January 12, 2007 at 04:25 AM

• >We can use AOP to introduce PropertyChangeSupport

  Wouldn't that be perfect via an annotation:

  @PropertyChangeEvent
  public void setFoo() {

  }

  Posted by: tcowan on January 12, 2007 at 06:56 AM

• 
  tcowan, as you say, one could use annotations to indicate where to apply an aspect (and which aspect to apply, and possibly further parameters for the aspect), and this would be my preference.

  Another option that i find attractive is to have an aspect on the class eg. @JavaBean, which indicates that by default the setters should fire a PropertyChangeEvent eg. unless another annotation excludes them, eg. @NoPropertyChangeEvent() on that excluded setter method.
  

  Posted by: evanx on January 12, 2007 at 07:09 AM

• The difficulty with using annotations is that annotations aren't supposed to modify the code of the class that is being annotated. It is not clear to me how @PropertyChangeEvent or @JavaBean could be implemented to work as intended. In JavaEE, annotations can work because objects are managed in the EJB container. A client only calls into a proxy, and the container can process the annotations and set up the proxy to do such things as firing listeners or executing interceptors.

  Posted by: cayhorstmann on January 12, 2007 at 03:30 PM

• 
  Cay, i was thinking of annotations on the class as a request that the class be enhanced with aspects, eg. compile-time ala the apt annotation processing tool.

  But my understanding is apt has read-only access to the annotated classes, for the purpose of generating other artifacts, eg. new classes or XML resources and such-like. As i understand, the Spoon project performs source code generation eg. at compile-time using an ant task, but i haven't played with that yet.

  Otherwise we can enhance at runtime use CGLIB, in which case we need to use a factory to instantiate enhanced instances, maybe according to annotations on the class eg. @JavaBeanAspect. But typically i expressly apply a method interceptor to a class via its factory method, eg. JavaBeanAspectMethodInterceptor.class.

  At this stage, a method interceptor is the extent my implementation of an "aspect." It might check for further annotations on the method, eg. @NoPropertyChangeEvent, and filter on the method name, to do
  its magic or not.

  I'm starting to use/consider basic AOP for quite a few things, namely logging, EDT programming, error handling (you can see a "sneak preview" at the end of the "Gooey Beans Form" article) and now also bound properties (aka PropertyChangeSupport), which i've prototyped and am drafting an article on it :)

  Posted by: evanx on January 13, 2007 at 03:10 AM

This work is licensed under a Creative Commons License.