The Death of Beans

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:

https://bean-properties.dev.java.net/tutorial.html

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:

object.name = "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) {
        this.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:

myTest.name.set("Testing");

Compared to:

myTest.setName("Testing");

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);
myTest.name.set("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:

myTest.name.set(null);

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:

http://xjava.googlecode.com

To see the source code for my Property API in SVN:
http://xjava.googlecode.com/svn/trunk/src/org/xjava/bean/properties/