Skip to main content

Property Problems, Solutions and Wishes

Posted by evanx on January 11, 2007 at 1:50 AM PST

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 e.g. 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 i.e. having observable properties.

Related Topics >>