Programming on the Edge

The Death of Beans

Published by Matt Hicks under , , , , , , on Wednesday, July 01, 2009
My previous post was more of a rant about the frustrations of Java Beans:

Have Beans been holding us back?

I stated at the end of my post/rant that my next post would be about what I suggest as the viable successor to Java Beans. To that end, I begin my discussion about properties.

Though I would like to claim the idea of properties as all my own invention, I cannot and the concept was even new to me when I first read about them here:

This is not really a new concept, but rather an attempt in Java to solve the problem other languages like C# and ActionScript solve with encapsulated properties that allow you to make calls like: = "Something";

Though this would appear to a Java developer as a public field being set to a value, in these languages there is a feature to provide special functions/methods for "set" and "get" of the private field and simplifies getter/setter functionality while maintaining a clean and consistent coding experience.

Unfortunately there is no such functionality built into Java and if you want to provide anything beyond assignment of fields to values you must use methods to accomplish this.

With Java 1.5 comes generics which really for the first time make properties practical without a lot of extending of classes. So take a simple example:

public class MyTest {
private String name;

public String getName() {
return name;

public void setName(String name) { = name;

Now, this is what it might look like using Properties:

public class MyTest {
public final Property<String> name = new Property<String>(null);

Properties have set(T t) and T get() methods that replace getters and setters, so a call to change the value would look like:"Testing");

Compared to:


They are about the same amount of actual code. What's great here though is that your Property object could contain much more additional functionality that you otherwise would have to inject yourself. For example if Property had the ability to addPropertyChangeListeners:

myTest.addPropertyChangeListener(myChangeListener);"Testing"); // Will now invoke myChangeListener when called

Further, you could have something like NotNullableProperty that extends Property and throws a NullPointerException if you try to call set with a null value:

public class MyTest {
public final NotNullableProperty<String> name = new NotNullableProperty<String>("");

Now a call to:;

Will throw a NPE and thus remove the need for you to ever have to check if "name" is null. This hopefully gives a slight grasp of the benefits this begins to provide.

Now, I mentioned above the article that really got me thinking this direction, but ultimately decided to write my own Property implementation because of some of the limitations and performance problems I saw with that implementation. Further, I had a lot of additional features I wanted to provide myself...and am often accused of wanting to write everything myself anyway. :)

This post isn't meant to push people to use a specific Property API but just to consider the methodology change even if they decide to write their own. After all, it only takes a few lines of code to create the base for your own Property class:

public class Property<T> {
private T t;

public T get() {
return t;

public void set(T t) {
this.t = t;

From there you can add any desired functionality: property bindings, value validation, property change listeners, observer/observable functionality, null checks, etc.

Though I don't want to push anyone to necessarily use a specific API, I will give reference to my own Property API for anyone interested in using it as it provides a great deal of functionality and I'm heavily using it in nearly all new programming projects these days and it supports filtering, change notification, property delegates, binding, read-only, adjusters, and much more. It is part of my xjava project:

To see the source code for my Property API in SVN:


Unknown said... @ July 1, 2009 at 3:15 PM

It's not a bad idea, though seems like you'd end up writing a lot of inner classes to handle custom setter logic.

Have you looked into what impact this method has (if any) on JIT versus doing it the "normal" way.

Matt Hicks said... @ July 1, 2009 at 3:21 PM

It really depends on how you handle the Property API. If you are doing something like PropertyChangeEvents then you would just add listeners to deal with this rather than extending or defining inner classes. In my own implementation I use delegates, so I can do:

name.setPropertyChangeDelegate(new MethodDelegate(someObject, "someMethod", String.class));

That will invoke someObject.someMethod(String) when the property changes.

As far as performance impact the base concept has no additional overhead apart from one additional "man-in-the-middle" Property object that's managing your "field" instead of in your Object directly. Everything else is just getters/setters. However, it is true that as you add additional functionality you are increasing the potential overhead per change as well as the memory consumed.

Martin Wildam said... @ July 2, 2009 at 4:48 AM

The good with your proposal is that it would offer more possibilities as the implementation of properties in other languages (and BTW: Properties were also there in Visual Basic 5 and maybe even earlier).

But I find the way, how it is done in Java not bad. Using such conventions gives you the option to define also different variants of setting a property. Using your approach would mean, that I would have to implement this in the Property class itself where it might not be desired. Or I create a subclass which would lead to "class polution" of the application.

Matt Hicks said... @ July 2, 2009 at 7:36 AM

Martin, that's a very good point. The way I see you have two options in the case that you need to provide some custom interactivity:

1.) Subclass the Property class. Though this would solve the problem I agree it would mean a lot of class pollution.
2.) Provide some methodology of overriding the functionality of Property without actually having to subclass. The way I solved this in my xjava implementation was to use my Delegates system to provide: setPropertyGetDelegate(Delegate) and setPropertySetDelegate(Delegate) which would actually allow you to "delegate" directly back to methods without losing the functionality or consistency of utilizing the Property methodology.

Martin Wildam said... @ July 2, 2009 at 9:23 AM

The second option seems to me a little complicated. But in general I would say that such a common property change listener implementation on the very property level will not make much sense in the most cases, isn't it? - It's again much work handling all single property changes.

I have many years of experience using properties in VB but I do not really miss them in Java.

What I notice is that in Java you can do much more implementing it yourself (like you did with your class) but the core tries to keep it simple. I find it good that way.

Matt Hicks said... @ July 2, 2009 at 12:20 PM

I agree, but honestly I rarely use that approach myself. In general I find myself working with the result of the property being changed, not the property itself and just managing PropertyChangeListeners is sufficient for that and allows me to see changes that occur on the Property in a synchronous way.

Unknown said... @ September 20, 2010 at 10:19 PM

It seems a good idea. I used it in order to improve a generic MVP that I was building:

Post a Comment