Skip to main content

Property Syntax for Java? A Constructive Alternative

Posted by hansmuller on January 10, 2007 at 5:57 AM PST

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; }
   

Would by equivalant to this (as before):
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.

Related Topics >>

Comments

Properties access with pointers p->x

I am wondering if an extension to java.util.Properties that I've published over on Google Code meets this need?

http://code.google.com/p/eproperties/ EProperties supports nested properties objects, and allows deep access using the 'pointer' syntax.