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.

Dialog Diatribe

I've been writing the occasional small application recently and
now and then I blunder into a problem with Java SE that's,
uh..., well, annoying. I realize that I'm not the only one
who's had this experience and I'm probably not the only one who
seeks relief by writing a lengthy diatribe and then sending it
to whomever might be guilty of creating the situation. Of
course, in my case that's often me, and since relief usually
doesn't come from berating oneself, I'm guilty of sending the
occasional long crabby missive to the people who are currently
responsible for maintaining things that I'm probably responsible
for bollocksing up in the first place. It's not a particularly
endearing habit.

I sent the following to Swing's technical lead,
Shannon
Hickey, and he confirmed that the details, though twisted
with bile, are essentially correct. So in the interest of
furthering my own therapy, and also to ensure that some record of
this will be stored away in Google's indices till the end
of time, I thought I'd share.

I would think that a fairly common idiom in a Swing application
would be to popup a dialog in response to selecting a menu item.
Given Matisse, we'll
assume that the JDialog has been created with the IDE, rather
than some JOptionPane convenience method, and given rudimentary
aesthetics, assume the dialog should be centered over the menu
item's frame. Accomplishing this seems to be much too
difficult:

public void showMyDialog(ActionEvent e) {
    // How to find the Dialog's Frame owner?
    Window dialogOwner = null;
    JDialog dialog = new MyDialog(dialogOwner, true); // true => modal Dialog
    dialog.pack();
    // How to center the Dialog?
    dailog.setVisible(true);
}

The first problem to deal with is mapping from the menu item's
ActionEvent to the frame that contains the menu item. The
frame will be the dialog's owner as well as the component we're
going to center the dialog relative to.

There seems to be an overabundance of SwingUtilities methods that
address this trivial problem:

• Window getWindowAncestor(Component c)
• Window windowForComponent(Component c)
• Component getRoot(Component c)

Sadly, none of them "work" for a JMenuItem. They all simply
traipse up the parent chain and in our case they find a
JPopupMenu and then null.

To find the Frame that owns a JMenuItem, we have to follow the JPopupMenu's

"invoker" property, which gets us back into the component
hierarchy. So to find the frame that corresponds to an ActionEvent
one must write (!):

Frame frameForActionEvent(ActionEvent e) {
    if (e.getSource() instanceof Component) {
        Component c = (Component)e.getSource();
        while(c != null) {
            if (c instanceof Frame) {
	        return (Frame)c;
            }
            c = (c instanceof JPopupMenu) ? ((JPopupMenu)c).getInvoker() : c.getParent();
        }
    }
    return null;
}

It would more useful to have written
<i>window</i>ForActionEvent but sadly support for
creating Dialogs whose owner is a Window (the parent class for
Frames and Dialogs) only appeared in Java SE 6, and I needed
code that worked for Java SE 5. It's also worth noting that
this works for Applets too, although you'd be forgiven for not
guessing that this is true. Applets do have a Frame parent
that's created by the Java plugin and whose bounds are the same
as the Applet (Panel) itself.

But we're still not done, because we must also center the dialog
over the frame. Naturally there are other useful positions for
the dialog. Centering a dialog over its frame happens to be what
started me on this quest.

I have it on good authority that
href="http://download.java.net/jdk6/docs/api/java/awt/Window.html#setLocationRelativeTo(java.awt.Component)">
Windows.setLocationRelativeTo() is the handy method for
this job. The javadoc for this method isn't promising:

    Sets the location of the window relative to the specified
    component.
  

OK so far. Except it sounds like I'm going to have to compute the
relative origin of my dialog and deal with edge (of the screen)
conditions. Yech.

    If the component is not currently showing, or c is null, the
    window is placed at the center of the screen. The center point
    can be determined with GraphicsEnvironment.getCenterPoint
    [sic]
  

Huh? What does "the component" refer to in this sentence? I
assume they're not referring to this Window and I have to
wonder what "showing" means in this context. Is is the same
thing as getVisible() being true? If not, do I
have to hope that my menu item is still "showing" when this
method is called? And what's this advice about
getCenterPoint (and where's the period)? In my
case the Window and its menu item are visible, so I'm hoping
none of this stuff applies. Because I don't really understand
it.

    If the bottom of the component is offscreen, the window is
    placed to the side of the Component that is closest to the
    center of the screen. So if the Component is on the right part
    of the screen, the Window is placed to its left, and visa
    versa.
  

This, no doubt, means that the method will endeavor to find a
location for my dialog that respects the relative location I've
specified, without making part of the dialog appear off-screen.
Good, I think.

So I still appear to be stuck with computing an origin for my
dialog that centers it relative to its owner. Before I code
that, I try leaving the origin of the new dialog at 0,0, which
is the default:

public void showMyDialog(ActionEvent e) {
    Window dialogOwner = frameForActionEvent(e);
    JDialog dialog = new MyDialog(dialogOwner, true);
    dialog.pack();
    aboutBox.setLocationRelativeTo(dialogOwner);
    dialog.setVisible(true);
}

Miraculously, this works. The dialog appears centered over the
dialogOwner unless that would cause the dialog to appear
off-screen. I have no idea why it works, since according to the
"spec" (and the name of the method) I should have had to compute
an appropriate relative origin for the dialog. But I guess I
don't.

Frankly, I think this whole mess is a mini-travesty. If I'm
going to show a dialog, I should be able to do so without
writing code that digs around the component hierarchy and
without experimentally determining what something as simple (and
not terribly useful) as Window.setLocationRelativeTo() does.

There, that feels a little better.

A href="http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4231737">
seven year old bug that covers the menu item to frame lookup
problem is still open. Given the fact that it's accumulated
exactly 0 votes in that time, perhaps no one has ever cared about
the problem quite as much as I do at this moment. I would think
that a cleaner way to handle this case would be some static
methods that handled the entire idiom, for example:

public void showMyDialog(AWTEvent event) {
    Window dialogOwner = Window.eventToWindow(event);
    JDialog dialog = new MyDialog(dialogOwner, true);
    Window.showModalDialog(dialog); // Center dialog relative to its owner
}

And Shannon suggested that the method name might be rationalized
as implying that the Window is be moved to a location that makes
its relationship to the component parameter obvious.
Typically that means centering the Window relative to the
component. In return for that tortured explanation, I had to
agree to file an RFE about the
Window.setLocationRelativeTo() javadoc. I haven't
done so yet. But I will.

Thanks for listening.

Fire Marshall Extinguishes Dukelele Performance

Tuesday morning this week, I was seated in the vast Moscone
keynote cavern, with 15,000 other Java developers, taking in the
start of another JavaOne conference. The keynotes and demos
were entertaining and I hope you didn't miss the HUGE Swing href="https://aerith.dev.java.net/">Aerith demo at the
conclusion of the morning. Sadly I did, although I've seen
quite a lot of it over last few weeks. I had to dart out early,
because my first-ever JavaOne musical gig started at about 10:30
and I had to get my bass and set up in time for the big Dukelele
show.

That's right, Dukelele. A Ukelele painted like so:

src="http://weblogs.java.net/blog/hansmuller/archive/dukelele.jpg" width="400" height="533" />

A group of us played music in front of the JavaOne store at one end of
the corridor that connects the Moscone's North and South subterranean
chambers. In addition to me, the band was Hideya Kawahara and Yuichi
Sakuraba playing Ukeleles (Dukeleles!) and singing, Mark Anenberg on a
guitar-shaped drum synthesizer, Chet Haase on a laptop powered
keyboard, and Kaoru Nakamura playing a keyboard/harmonica hybrid
called a Pianaca. And to top if off, Duke danced and hugged people.

We started playing as the keynote audience began flooding past and to
our delight, many of them stopped to listen. Tragically, the Moscone
Fire Marshall did not share our joy. After about 10 minutes he
swooped in and put a stop to the show. I guess we were a fire hazard,
or at least Hideya was. He was really putting his heart into singing
and playing and I suspect that the Fire Marshall was afraid that he
might suddenly burst into flames.

Another rock and roll show, shut down by the man. Not exactly
Altamont Speedway, but definitely a strange and abrupt ending to
our little performance. Fortunately one of our colleagues
videotaped the whole thing and so now you can check it out on
href="http://www.youtube.com/watch?v=wf5_TN602lc">YouTube.com.
No animals were harmed in the making of this video.

We played again, in the afternoon, outside on the sidewalk. It was a
bit breezy and most of the people who drifted by gave us an odd look
and then slipped indoors. One was exception was href="http://weblogs.java.net/blog/timboudreau/">Tim Boudreau, who
took in the entire set and then threw a quarter in our tip jar.
Except we didn't have a tip jar. Our friend the Fire Marshall seemed
to be pleased that we finished without spontaneously combusting.
Cautious man that he is, he kept a sharp eye on the proceedings from a
safe distance, clutching his fire extinguisher in one hand, and a
fistful of swag from the Motorola booth in the other. Next year
we'll bring our own fire protection.

A Reusable BuddyList Component

Every now and then someone drops by to ask about the slick chat/IM
demo components that were shown in the href="http://developers.sun.com/learning/javaoneonline/2005/desktop/TS-3605.pdf">
Extreme GUI Makeover JavaOne session last year. The Swing
components created for those demos where hacked together in order to
show what's possible and sadly, they're not available as production
quality components just yet. I certainly like the idea of
resuable, configurable/extensible, chat client GUI parts. If I
were building that kind of application I'd be happy to avoid starting
from scratch. This blog is a brief look at one such part. You can
try it out by pressing the launch button.

src="http://weblogs.java.net/blog/hansmuller/archive/jws-launch-button.png" width="88" height="23" style="border-style:none; margin-right:44px"/>

style="border: none; "/> BuddyList Demo Screenshot

BuddyCellRenderer is an attempt to build a somewhat reusable
JList CellRenderer for Chat/IM buddy lists. It's job is to
render an object that represents a Buddy roughly like this:

		  screen name
	[status]  short message   [icon]

Here "status" is one of online, offline, or away. Away status means
that the user is online but busy. The "screen name" is the Buddy's
name, "short message" is an optional short message from the Buddy, and
icon is a picture that represents the Buddy. All of this is quite
conventional. These elements appear in most chat/IM application
buddy-lists in one form or another. If a "short message"
isn't provided we change the layout just slightly:

	[status] screen name [icon]

The BuddyListCellRenderer must also provide a Buddy-specific tooltip
that's displayed if the user lingers over one BuddyList element.

JList renders list elements or "cells" by delegating to an
implementation of ListCellRenderer. ListCellRenderers have only one
method, getListCellRendererComponent(), which returns a Component that
the JList uses to paint a single list element. The JList really just
uses the cell renderer component's paint() method to draw or "rubber
stamp" a list element. The getListCellRendererComponent() method is
passed the JList model's "value" for each list element, and its
responsibility is to return a component that's been configured to
display that value.

The default ListCellRenderer is quite simple. It just uses the same
JLabel for every list element, roughly like this:

JLabel label = new JLabel();
Component getListCellRendererComponent(JList l, Object value, ...) {
    jLabel.setText(value.toString());
    return jLabel;
}

To display the properties of a Buddy in the way we've layed out above
will require more than just a JLabel. BuddyCellRenderer uses a JPanel
with subcomponents for the various properties and GridBagLayout to
define the layout.

A generic ListCellRenderer that configures our JPanel composite to
display a Buddy value is difficult because we don't want to
dictate the type of the Buddy object but we do need to
extract its status, screen name, icon, and message. What's needed
is an adapter that extracts the properties needed by the
BuddyCellRenderer from the app-specific Buddy object. The
BuddyListCellRenderer.Adapter class does this. The way it works
is easiest to explain with an example. Lets assume that our chat/IM
application has a Buddy class that looks like this:

class MyBuddy {
    boolean isOnline() { ... }
    boolean isAway() { ... }
    String getScreenName() { ... }
    ImageIcon getIcon() { ... }
}

A JList ListModel that encapsulated the list of MyBuddy objects would
have to be created; I will not delve into that here. The adapter for
MyBuddy objects could be defined and used like this:

class MyBuddyAdapter extends BuddyCellRenderer.Adapter {
    private MyBuddy getBuddy() { return (MyBuddy)getValue(); }
    public String getName() { return getBuddy().getScreenName(); }
    public String getMessage() { return getBuddy().getMessage(); }
    public ImageIcon getBuddyIcon() { return getBuddy().getIcon(); }
    public Status getStatus() { 
        if (getBuddy().isAway()) {
            return Status.AWAY;
        }
        else if (getBuddy().isOnline()) {
            return Status.ONLINE;
        }
        else {
            return Status.OFFLINE;
        }
    }
}

BuddyCellRenderer cellRenderer = new BuddyCellRenderer();
cellRenderer.setAdapter(new MyBuddyAdapter());
myBuddyJList.setCellRenderer(cellRenderer);

That's pretty much all there is to it. The BuddyCellRenderer
scales (and caches) the Icons provided by the Adapter if they're
bigger than BuddyCellRenderer.getBuddyIconSize().
It also caches the "grayed out" version of the icon that's used
when a Buddy's status is offline. Alternating rows are
rendered in an off-white color to help with readability and
the whole thing is layed out internally with the old Swing
layout veteran: GridBagLayout.

If you'd like to try making some changes to BuddyCellRenderer
and the demo, you can download a NetBeans
project with the source code and the jar files here:

Download BuddyList NetBeans Project .