We often use worker threads to do some long-running process, so often run into two issues using SwingUtilities invokeLater/invokeAndWait, and have developed wrapper code to deal with it. One issue is executing code from both worker threads and the Event Dispatch Thread (EDT). invokeLater and invokeAndWait both throw exceptions if executed on EDT. Second, invokeAndWait isn’t guaranteed — interruption on the calling thread will resume execution before the job is finished. The remainder of this post shows the code we used to solve these issues.

Reducing repetitive code

We often write functions that are executed from the Event Dispatch Thread (EDT) and also from other threads. Since these methods will throw an exception if you’re already on the EDT, it makes sense for us to wrap them in a quick safety check so we avoid an extra three lines of code every place we want to use it. Thus, a first minor improvement:

public static runOnEDT(final Runnable r) throws InvocationTargetException {
	if ( SwingUtilities.isEventDispatchThread() )
		r.run();
	else
		SwingUtilities.invokeLater( r );
}

Note the use of invokeLater — that will be important to the next section. invokeAndWait wouldn’t work the same.

invokeAndWait doesn’t wait

The second gotcha with invokeAndWait is that it doesn’t always. Wait, that is. If a thread is waiting for a Runnable to execute on the EDT and that thread is interrupted, execution of the waiting thread will resume immediately, BEFORE FINISHING the Runnable. I had assumed this meant we failed to wait for the EDT, that the job was never executed and should I execute invokeAndWait again. This was the wrong interpretation. Turns out, all that happened was waiting on completion of the job was interrupted. The Runnable is still enqueued on the EDT and will still execute. Depending on how the timing works out, the EDT Runnable may even be executing at the same time. I just have no idea when it will finish. Very inconvenient.

invokeAndWait throws InterruptedException so you can learn of this situation and deal with it, but it’s not really something you can solve after the error has already occurred. So the following is our solution:

We create a FutureTask to wrap the provided Runnable. We can await completion of the FutureTask via FutureTask.get() which tells us when the provided Runnable has finished (successfully or thrown exceptions, or whatever). After the Runnable finishes, if there were any interruptions during execution, we re-interrupt Thread.currentThread() so the caller knows an interruption occurred and can choose to perform followup action.

public static void runAndBlockSilently(Runnable r) {
	final FutureTask ft = new FutureTask(r, null);
	boolean wasInterrupted = false;
	runSafely( ft );
	while (! ft.isDone() ) {
		try {
			ft.get();
		}
		catch ( InterruptedException e ) {
			wasInterrupted = true;
			// Continue ...
		}
		catch(ExecutionException exEx) {
			Throwable cause = exEx.getCause();
			logger.error( "Exception during BlockingRunnable: ", cause );
			if(cause instanceof RuntimeException)
				throw (RuntimeException) cause;
		}
	}

	if(wasInterrupted) {
		Thread.currentThread().interrupt();
	}
}

Happy Swinging.

-Carl

We recently had a visit from some distinguished guests. Chris Campbell, a member of the Java 2D Team at Sun, came to see demonstrations of the Palantir products. We were very pleased and flattered by his positive reactions to the work that we’ve done.On the basis of that visit, we were added to the Java Desktop community site as a Swing Sighting Preview and merited a mention on Romain Guy’s blog: Another Pretty Java Application.We’re excited to present this series of screenshots as the first public unveiling of the Palantir applications. On a technical note: everything you see in these screenshots is from live, running applications. The applications are entirely written in Java and the GUIs are composed of custom Swing components.After the jump: bigger thumbnails with a description of each screenshot. You can click above or below to see the full resolution screenshots. 

Instrument Explorer

The instrument explorer uses filtering mechanisms to drill down to subsets of the financial universe of interest. Note that the filters themselves act as views on the dataset.

UI Elements Montage

A montage of UI elements from Palantir Finance.

Regression Modelling

Advanced statistical packages capable of regression modelling operate on top of the intuitive object framework

The Dashboard

The Dashboard exists as a one-stop-shop for summary information on markets and the world.

Graph Explorer: Circular Context Menu

The circular context menu in the Graph Explorer reveals a multi-level hierarchy of actions to perform nodes selected on the graph.

Timeline Viewer

The Timeline Viewer enables the visualization of events on a timeline using intuitive filtering mechanisms. Note that the viewer interacts with the graph by fading out the nodes not included in the current temporal filters.

Graph Explorer: Resource Flow

In this single frame of an animated view we see the visualization of resources flowing between entities on the graph. In the live application, the directionality of movements are clearly rendered as movement on the graph. Note that flows can be thresholded to only show transactions above a certain size.

Graph Explorer

The Graph Explorer visualizes relationships between entities, events, and documents. At higher zoom levels, details appear on each edge to call out the nature of the one or more relationships the edge represents.

Graph Explorer: Histogram

The Histogram allows quick summarization and selection by common attributes for sets of nodes that appear in the Graph Explorer or other views.

Most people who’ve done a little preliminary looking online will learn that to create a component that functions like a hyperlink the easiest way is to use a JEditorPane. If you use the HTMLEditorKit you can introduce hyperlinks, they’ll render appropriately, and you can even add a HyperlinkListener. There’s just one drawback. It’s a little slow to instantiate. Alternatively, you can pass html to a JLabel, which will render the hyperlink, then add a mouse listener, but that’s not much faster. Besides that, the JEditorPane doesn’t seem to alter the mouse when you mouseover an active link. Sloppy. So I wrote HyperlinkLabel.

Try out the Web Start HyperlinkLabel Demo | Download executable jar + source

Take a look at these numbers for 1000 instantiations of a configured class:

JEditorPane: 1922 ms, 1906 ms, 1922 ms = Average 1916 ms
JLabel: 1250 ms, 1250 ms, 1234 ms = Average 1244 ms
HyperlinkLabel: 62 ms, 62 ms, 63 ms = Average 62.3 ms

Read on for more details.

Motivation

I suppose the amount of time you’re seeing above doesn’t seem too bad: 2 ms per editor pane instantiation isn’t so bad. But we have a lot of small hyperlink components, and my perf testing indicated it was burning up around 5% of our runtime in one workflow, so I figured why not make it as efficient as possible?

Also, the user experience wasn’t as good as it could have been – I wanted the hand cursor when mousing over the link to indicate to the user that the link is clickable. In particular, I only wanted the hand cursor when the mouse is over the link text, not just when the mouse is somewhere over the JLabel.

Painting the hyperlink

HyperlinkLabel permits one link embedded in a larger string, so the HyperlinkLabelUI obtains the prefix text, link text, and suffix text, then paints each of the three parts in appropriate color. The LineMetrics for the text supplies the offset from baseline at which to draw underlines. I found that the underline offset for font sizes I generally worked with was 0.7-ish and if I truncated to int in order to draw a line, it drew the line directly at the baseline. This turned out to be unattractive, so I applied Math.ceil() to round up.

In order to paint the text, the UI is told exactly where the text appears. This is computed via BasicLabelUI.layoutCL(lotsa args), a protected method. In order not to copy too much code around and duplicate layout computations, HyperlinkLabelUI tells HyperlinkLabel where the text is so mouseover/mouseclicks can be computed correctly. Since this updates on every paint, it’ll be accurate when a mouse event is delivered.

Using HyperlinkLabels

In most respects, it’s a JLabel – you can fiddle with the alignment, add an icon, etc. Just don’t try to set the text via HTML, or it won’t work quite right. A common pattern might be:

    HyperlinkLabel hll = new HyperlinkLabel();
    hll.setLinkText("Click for a tasty ", "snack", ".", Color.WHITE);
    hll.addActionListener(this);

Java 6.0 Compatibility

Well, Alert Reader Garry notified me that Java 6.0 not so happy with previous implementation — I called SwingUtilities2 methods directly, an apparent no-no, because Sun moved SwingUtilities2 to the com.sun package in that release. So I managed to work around that. Now I call super.paintEnabledText(), sequentially passing it the prefix, link text, and suffix with appropriate coordinates. The only trick I played was getting HyperlinkLabel to lie about its foreground color because the implementation of BasicLabelUI.paintEnabled is this:

        int mnemIndex = l.getDisplayedMnemonicIndex();
        g.setColor(l.getForeground());
        SwingUtilities2.drawStringUnderlineCharAt(l, g, s, mnemIndex, textX, textY);

So I had to make sure JLabel.getForeground() returned blue when I used paintEnabledText to paint the link text.

Wrapup

That’s all for today. At some point I might like the label to change the link color for “visited links” and it might be nice if it behaved a bit more like JButton — mouse press arms and mouse release fires. Firing only on mouse click means if you accidentally drag a bit after pressing the mouse button the link won’t fire. Nor does it visibly react to the mousePressed since it doesn’t have an armed state.

-Carl

Check out this reflection magic! Now iTunes isn’t the only one with fancy reflections on album art. The best part about it is that it’s a general use component that doesn’t require customization each time. It can wrap any transparent JComponent and it will automatically repaints whenever the contained component changes. You see the text appearing in the reflection as you type in the text field. Try the Web Start ReflectionDemo. Source code is provided in reflectiondemo.jar, and an explanation of how it’s done follows.

This component is a combination of several techniques:

• Image fading.
• Applying a transform so the contained component is painted upside down.
• Active update accomplished by, *gasp*, calling repaint during paintComponent!

Fading images

You can paint colors/lines/solid shapes/etc using a GradientPaint to create an object that fades from solid to transparent as we desired, but getting a complex graphic to do the same thing didn’t seem possible until we learned about AlphaComposite.DST_IN, (see our previous blog posting on the subject). It’s a class that, instead of blending two images together, allows you to use the color bytes from one image and the alpha from the second image. This technique allowed me to composite together a fully opaque picture of a component with a rectangle of black painted using a standard Gradient paint.

Imagine the icon upside down and you’ll see what I’m trying to accomplish here.

Inverting the component

The reflection is obtained by applying transforms to a Graphics object, then permitting the reflecting component to paint itself to a BufferedImage instead of the supplied Graphics instance. This results in a copy of the contained component painted upside down in a separate BufferedImage. After compositing using the above technique, you get something that looks like the component but upside down and faded with whatever GradientPaint you used.

You can paint upside down to the supplied Graphics, of course. However, if you want the fading effect to apply only to the contained component, you need to isolate it on a separate BufferedImage until it’s fully prepared.

In the below snippet of code, reflG2D is the Graphics2D of the offscreen buffer that holds the reflection so that it may be faded before painting to screen. The scaling step causes all y-coordinates to be multiplied by -1, so when you paint the children of ReflectionComponent to reflG2D, source paints itself upside down.

Look out, though, that means the paint which would normally be (0,0) -> (source.getWidth(), source.getHeight()) is now (0,0) -> (source.getWidth(), -source.getHeight()). You've just painted outside the boundaries of the image so you translate down to put it in the visible region. The rest of the translation ensures proper painting even if source isn't at (0,0) due to insets or the layout manager.

	Insets i = getInsets();
	reflG2D.scale(1,-1);
	reflG2D.translate(-source.getX(), - (source.getHeight()+i.top));

	super.paintChildren(reflG2D);

	reflG2D.translate(source.getX(), (source.getHeight()+i.top));
	reflG2D.scale(1,-1);

Don't forget to undo the changes you made so the fade operations can be done without being affected by the inversion/translation.

Active update of the reflection

This is a bit sketchy but too cool to pass up. I've seen several reflection component examples out there, but they don't seem to do active update, so here it is. There's no event that fires to report when repaints occur (I suppose Sun engineers figured it was just too likely to be abused). They're probably right. So I abused opacity instead. When a component is marked for repaint and it is transparent (i.e. isOpaque() == false), then the parent of said component will be repainted as well. So, if everything contained in a ReflectionComponent is transparent, then ReflectionComponent itself will repaint every time the contained object does so. The only hurdle to overcome is the crop -- the dirty region will never automatically include the reflection region because the reflection lies outside the bounds of the contained component. This makes it necessary to call repaint on the reflection region as well. Basically it doubles up on every repaint, not something you REALLY want to do all over the place but it does the job.

Here's how I did it:

public void paintComponent(Graphics g) {
	...
	Rectangle r = g.getClipBounds();
	if( (r.y+r.height) < (getHeight() - 1) ) {
		repaint(r.x, r.y, r.width, getHeight() - r.y);
	}
	...
}

Mouseover Editing simulates just that. The idea is to attach a MouseListener to the JTable and call editCellAt(row, col) whenever the cursor moves over a new cell. In other words, even though only one cell in a table can be fully interactive (the editing cell) at any given time, as long as we keep moving that cell to stay underneath the user’s cursor, the whole table will appear to be fully interactive. If done correctly, this will appear to the user as though he’s interacting with a bunch of real components (rather than rendered stamps) inside a giant Grid/GridBag/TableLayout.

Most importantly, the user will get mouseover feedback about which cells are editable, and how to edit them. Checkboxes, buttons, and comboboxes (if the L&F supports it) will highlight to indicate press-ability and the cursor will turn to a text caret when hovering over cells that contain textfields. When done correctly, the effect is nearly seamless and very satisfying.

Here’s a webstart demo. Read on for the solution in code.

There are three parts to the Mouseover Editing solution (over and above what’s needed for typical JTable editing).

Part 1: Identical Editors and Renderers

This is important. Typically, a table will use a JLabel to render a cell and a JTextField to edit the cell. When the editor is swapped in to replace the renderer, there’s a slight flicker—the textfield might have a different background color, the text mayb be in a slightly different location, etc. This is all well and good when the user has to click or double-click to engage the editor, because the click can be perceived as granting permission to the program to do something on its own. However, a simple mouseover is a different story. Here, the look, feel, and placement of the editor should exactly match up with the look, feel, and placement of the renderer; otherwise, there will be a flicker trail every time the cursor passes through the JTable.

In order to make editors and renderers look and behave identically, (a) we need them to start out identical and (b) we need to apply the same transformations to them.

The easiest way to make an identical editor and renderer is to produce two objects from a combined EditorRenderer class. Here’s how that might work for a checkbox:

public class CheckBoxEditorRenderer extends AbstractCellEditor implements TableCellRenderer
{
	private JCheckBox checkbox = new JCheckBox();
	public CheckBoxEditorRenderer() {
		super();
		checkbox.setFocusable(false);
	}
	public Component getTableCellRendererComponent(JTable table, Object value, boolean isSelected, boolean hasFocus, int row, int column) {
		if (value instanceof Boolean) {
			checkbox.setSelected((Boolean) value);
		}
		return checkbox;
	}
	public Component getTableCellEditorComponent(JTable table, Object value, boolean isSelected, int row, int column) {
		if (value instanceof Boolean) {
			checkbox.setSelected((Boolean) value);
		}
		return checkbox;
	}
	public Object getCellEditorValue() {
		return checkbox.isSelected();
	}
}

Notice how CheckBoxEditorRenderer implements both the TableCellRenderer and TableCellEditor interfaces (the latter via AbstractCellEditor).

Editors and renderers must also be subjected to the same transformations. In a subclass of JTable, say one called MouseoverJTable, use the following format for your prepareEditor() and prepareRenderer() methods:

public Component prepareRenderer(TableCellRenderer renderer, int row, int column) {
	Component c = super.prepareRenderer(renderer, row, column);
	return prepareEditorRenderer(c, row, column);
	}
	public Component prepareEditor(TableCellEditor editor, int row, int column) {
	Component c = super.prepareEditor(editor, row, column);
	return prepareEditorRenderer(c, row, column);
	}
	private Component prepareEditorRenderer(Component stamp, int row, int column) {
//	 ...  All sorts of shenanigans can go on here.
	}
}

This ensures that both the editor and the renderer will go through the same decoration path.

Part 2: Two-stage editing

What we’ve presented thus far works really well for buttons and checkboxes, which are minimally interactive. With comboboxes and textfields, there’s a problem. Suppose you mouse over a cell with a combobox. First the combobox will become highlighted (if the L&F supports it) to indicate that it’s clickable; this is expected and reasonable behavior. If you click on it, the combobox flyout will appear; this is also expected and reasonable behavior. Now move your mouse just a little bit…. oh no! You accidentally moused over another cell, and the table decided to swap out the editor you were using (the combobox) and swap in a new editor. Goodbye flyout.

To make sure this doesn’t happen, we need editors with two states: temporarily engaged and fully engaged. When the cursor first moves over a cell, we call editCellAt(r, c), and plop the editor into place, temporarily engaged. This means it’s an interactive JComponent that responds to mouse events, but that it’s okay to swap it out and replace it with a new editor if the cursor changes location. Then, if the user starts interacting with the Editor in a way that requires the editor to keep around a bit of state (like the visibility of a flyout for a combobox), we say that the editor is fully engaged, and that the table isn’t allowed to swap it out until the user disengages it.

What this looks like in code:

public interface TwoStageTableCellEditor extends TableCellEditor
{
    public boolean isFullyEngaged();
}

public class ComboBoxEditorRenderer extends AbstractCellEditor implements TwoStageTableCellEditor, TableCellRenderer
{
    private JComboBox combobox;
    ...
    public Object getCellEditorValue() {
        return combobox.getSelectedItem();
    }
    public boolean isFullyEngaged() {
        return combobox.isPopupVisible();
    }
}

Part 3: Mouseover swapping

Here’s where it all comes together. Mouseover swapping is what your (subclass of) JTable does in order to keep track of which cell is being edited, where the cursor is, and whether to swap the editor from one cell to another. This is kind of boring, and only really makes sense in code, so here you go:

// In the constructor...
// listeners for two-stage editing
this.addMouseListener(twoStageEditingListener);
this.addMouseMotionListener(twoStageEditingListener);

// In the body of your JTable subclass...
private final FullMouseAdapter twoStageEditingListener = new FullMouseAdapter() {
    public void mouseMoved(MouseEvent e) {
        possiblySwitchEditors(e);
    }
    public void mouseEntered(MouseEvent e) {
        possiblySwitchEditors(e);
    }
    public void mouseExited(MouseEvent e) {
        possiblySwitchEditors(e);
    }
    public void mouseClicked(MouseEvent e) {
        possiblySwitchEditors(e);
    }
};
private void possiblySwitchEditors(MouseEvent e) {
    Point p = e.getPoint();
    if (p != null) {
        int row = rowAtPoint(p);
        int col = columnAtPoint(p);
        if (row != getEditingRow() || col != getEditingColumn()) {
            if (isEditing()) {
                TableCellEditor editor = getCellEditor();
                if (editor instanceof TwoStageTableCellEditor && !((TwoStageTableCellEditor)editor).isInStageTwo()) {
                    if (!editor.stopCellEditing()) {
                        editor.cancelCellEditing();
                    }
                }
            }

            if (!isEditing()) {
                if (row != -1 && isCellEditable(row, col)) {
                    editCellAt(row, col);
                }
            }
        }
    }
}

Conclusion

This solution works pretty well. There are a couple flaws (e.g. start editing a textfield and then mouseover a button—no feedback, because the text field is fully engaged), but overall it is much better than an unadorned JTable, and not too much of a burden on the developer. Be warned, though: it may wreak havoc on the focus system.

Extra credit: Is it possible to achieve a similar effect by forwarding MouseEvents through to the renderers/stamps?