Hans Muller's Blog

January 2007 Archives

Application Framework Prototype Bows

I've made a prototype of the fledgling JSR-296 API available, it's https://appframework.dev.java.net/. There's a quick overview doc and downloads of the source code, the javadoc, and the AppFramework.jar file. If you're interested in this API, please take a look at the overview, and download the code and then take a look at some of the examples and the javadoc. You can post feedback here or, if you want to participate in the long-term discussion, subscribe to the appframework.dev.java.net "users" mailing list: https://appframework.dev.java.net/servlets/ProjectMailingListList . The users alias is the last one listed.

That's all I really wanted to say. I don't want to make too much of a commotion about this version of the design because there's still quite a bit that remains to be done. I was hoping that this would be a sort-of stealth release: not terribly noticeable, unless you know where to look. On the other hand, I know there are Swing developers who aren't members of the JSR-296 expert group, who'd like to take stock of where this project is going. And I know there are experienced Swing developers out there, some of whom have built their own application frameworks, that would like see how this one measures up. I'd welcome feedback from anyone who's interested and I'll promise to respond promptly, unless you bring up a really difficult issue or a really large number of them. That might take longer.

Note also: the JCP defines a milestone called "Early Draft Review" that means the expert group thinks the spec is complete enough to begin fine tuning. We have not reached that milestone yet.

Property Syntax for Java? A Constructive Alternative

Having written, by conservative estimates, about a jillion Java Beans classes over the years, I have to say that I'm amazed that we'd seriously consider changing the Java language to trivialize this kind of Java Bean property. It certainly is a property per the spec, a read/write property at that, but - as a Swing developer - it's the kind of property I almost never write. And if repetitive boilerplate is what we're hunting with this language change, then we're shooting at rabbits while a herd of buffalo thunders by. The mighty buffalo of the Java Beans boilerplate animal kingdom are bound properties. They're the kind of properties we write so that our beans can be automatically and dynamically synchronized with a GUI or with each other. As a desktop developer, I almost always write bound properties.

To write a bound property properly you've got to ensure that your class defines or inherits support for a PropertyChangeListener. That's about 20 lines of code just to get started:

class FooBean {
    private final java.beans.PropertyChangeSupport pcs;
    public FooBean () {
	pcs = new PropertyChangeSupport(this);
    }
    public void addPropertyChangeListener(PropertyChangeListener listener) {
        pcs.addPropertyChangeListener(listener);
    }
    public void removePropertyChangeListener(PropertyChangeListener listener) {
        pcs.removePropertyChangeListener(listener);
    }
    public PropertyChangeListener[] getPropertyChangeListeners() {
        return pcs.getPropertyChangeListeners();
    }
    protected void firePropertyChange(String propertyName, Object oldValue, Object newValue) {
        pcs.firePropertyChange(propertyName, oldValue, newValue);
    }
}
    

And then there's the definition of each read/write property which should: check the validity of new values in its set method as well as calling firePropertyChange to notify PropertyChangeListeners, and defensively copy the return value (if necessary) in its get method. I suppose one could concoct syntax that would simplify all of this, at least a little, as well as allowing for read-only/write-only variants. But that's not the proposal I wanted to make here.

If you consider the property keyword proposal in light of Java's origins in the C language, then it's pretty clear what the proposal's proponents are really after: structs. It's not about defining properties, it's about simplifying defining a Java class that's comparable to a struct in the C language. So perhaps the proposal should really focus on allowing one to write classes, not properties. Where this:

struct FooBean { Foo foo; }
    

class FooBean {
    private Foo foo; 
    public Foo getFoo() { return foo; }
    public void setFoo(Foo foo) { this.foo = foo; }
}
    

If you admit that the focus of the property proposal is really adding support for defining structs in Java, then using "->" to refer to struct properties feels like coming home again.

struct Point { int x, y; }
Point p = new Point(); 
p->x = p->y = 0; // oh joy
    

I'm not a language design expert however I would think that I would be among the target developers for Java language feature designed to support properties. In my humble (ha) opinion, the current proposal serves the needs of Java Beans developers poorly by targeting a special case that doesn't warrant language support. Although I would welcome a proposal that also simplified defining bound properties, I would guess that it would be hard to invent syntax that would handle the general case without being obscure. If there is a consituency for the current proposal, I say: give them structs instead.

This work is licensed under a Creative Commons License.