alexfromsun's Blog

Swing in a better world: Listeners

In the list of the things that needs improving in Swing, the implementation of listeners takes the first place. The problem is the fact that the order in which listeners are notified is not specified and it is not even guaranteed that your listeners will be notified after the Swing system listeners. Actually all listeners can be mixed together with any possible combination and it leads to two main problems:

• Listeners' order is messed up after updateUI() is called. See 4871932 and 6508168
• User's listeners are notified before the UI listeners See 4178930, 6294075, 4675786, 4688560, 5032759, 4816818 and 4730055

Examining the problem

 Let's write some code and check if a JButton is in the pressed state when MouseListener.mousePressed() is notified:

import javax.swing.*;
import java.awt.FlowLayout;
import java.awt.event.MouseAdapter;
import java.awt.event.MouseEvent;

public class ListenersOrder extends JFrame {

    public ListenersOrder() {
        setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);
        setLayout(new FlowLayout());

        final JButton button = new JButton("JButton");
        
        button.addMouseListener(new MouseAdapter() {
            public void mousePressed(MouseEvent e) {
                System.out.println("button.getModel().isPressed() = "
                        + button.getModel().isPressed());
            }
        });

        add(button);
        pack();
    }

    public static void main(String... args) throws Exception {
        SwingUtilities.invokeLater(new Runnable() {
            public void run() {
                new ListenersOrder().setVisible(true);
            }
        });
    }
}

When you press the button you can see that it is in the pressed state, as we may expect.
button.getModel().isPressed() = true
Let's add some more code and change the system Look and Feel after the button is created:

import javax.swing.*;
import java.awt.FlowLayout;
import java.awt.event.MouseAdapter;
import java.awt.event.MouseEvent;

public class ListenersOrder extends JFrame {

    public ListenersOrder() {
        setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);
        setLayout(new FlowLayout());

        final JButton button = new JButton("JButton");
        
        button.addMouseListener(new MouseAdapter() {
            public void mousePressed(MouseEvent e) {
                System.out.println("button.getModel().isPressed() = "
                        + button.getModel().isPressed());
            }
        });

        add(button);
        pack();
        
        changeLaF();
    }

    private void changeLaF() {
        try {
            UIManager.setLookAndFeel("com.sun.java.swing.plaf.nimbus.NimbusLookAndFeel");
        } catch (Exception e) {
            e.printStackTrace();
        }
        
        // we don't forget to update all the components
        SwingUtilities.updateComponentTreeUI(this);
    }
    
    public static void main(String... args) throws Exception {
        SwingUtilities.invokeLater(new Runnable() {
            public void run() {
                new ListenersOrder().setVisible(true);
            }
        });
    }
}

This simple update changes the mouse listener's order and now, surprisingly, when you press the button you'll see:
button.getModel().isPressed() = false

How to explain it?

Let's examine the mouse listeners' added to the button, corresponding to every relevant line:

So you can see that in the first test the ui listener sets the pressed flag before the user's listener, when in the second test the listener's order is reversed.
It means that the actual state of the button seeing from a user's mouseListener is unspecified and you shouldn't rely on any particular order.

Modal dialogs

Showing a modal dialog from a listener is the best way to observe your component in a transition state. If you run the following test and click an unselected list's item the modal dialog will come up and you'll be able to see the two selected items for a list with the SINGLE_SELECTION mode.

import javax.swing.*;
import javax.swing.event.ListSelectionEvent;
import javax.swing.event.ListSelectionListener;
import java.awt.FlowLayout;

public class ModalityTest extends JFrame {

    public ModalityTest() {
        setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);
        setLayout(new FlowLayout());

        String[] data = {"One", "Two", "Three", "Four"};
        JList list = new JList(data);
        list.setSelectionMode(
                ListSelectionModel.SINGLE_SELECTION);
        list.setSelectedIndex(0);

        list.addListSelectionListener(
                new ListSelectionListener() {
                    public void valueChanged(ListSelectionEvent e) {
                        
                        // Showing a modal dialog blocks the listener's notification
                        JOptionPane.showConfirmDialog(null,
                                "Do you see two selected lines ?");
                    }
                });

        add(list);
        setSize(200, 300);
    }

    public static void main(String... args) throws Exception {
        SwingUtilities.invokeLater(new Runnable() {
            public void run() {
                new ModalityTest().setVisible(true);
            }
        });
    }
}

This example shows why you shoudn't stop the listener's notification somewhere in the middle with a modal dialog and should always show it after all the listeners are notified. The recommended pattern is to always use SwingUtilities.invokeLater() when you need to show a modal dialog from your listener:

list.addListSelectionListener(
                new ListSelectionListener() {
                    public void valueChanged(ListSelectionEvent e) {

                        SwingUtilities.invokeLater(new Runnable() {
                            public void run() {
                                // Showing a modal dialog with invokeLater 
                                // doesn't leave the GUI in a transition state 
                                JOptionPane.showConfirmDialog(null,
                                        "Do you see two selected lines ?");
                            }
                        });
                    }
                });

How should it have been implemented?

     We seriously thought about improving the listeners notification several years ago but after heated disputes we didn't come up to one proposal. I offered to mark the Swing UI listeners with the existing UIResource interface and gurantee their notification before the user's listeners. The other propsal was to add a conception of listeners "weight" which will control the order in which a listener will be notified. So you would use the new add*Listener() methods with the second parameter - button.addMouseListener(listener, weight);

As a matter of fact the multiple listeners approach brings more problems than solutions. It would have been better to make the users override methods like processMouseEvent and automatically notify the same kind of method in the ComponentUI.

This was an entry from the Swing in a better world series
Thanks alexp

Swing in a better world: Checked exceptions

Checked exceptions are painful. I could write a long article about it,
but there are more than enough good blogs describing this problem.
My favorite article is written by Rod Waldhoff.




From my point of view the existence of the InvocationTargetException clearly shows the problem.

Imagine you call a method which throws an exception, you properly catches it


and then you decide to rewrite the code and call the same method via refection.


After that you have to catch the same exception in quite a different manner:

public class Test {

    public static void main(String[] args) {
        PrinterJob job = PrinterJob.getPrinterJob();
        
        // Call it in the usual way
        
        try {
            // this throws checked PrinterException
            job.print();
        } catch (PrinterException e) {
            // handle the printer exception
        }

        // Call the same method via reflection

        try {
            // this throws InvocationTargetException instead
            getPrintMethod().invoke(job);
        } catch (IllegalAccessException e) {
            e.printStackTrace();
        } 
        
        catch (InvocationTargetException e) {
            if(e.getCause() instanceof PrinterException) {
                // handle the printer exception;
                // a little bit more complicated than it used to be
            }
        }
    }

    static Method getPrintMethod() {
        try {
            return Class.forName("PrinterJob").getDeclaredMethod("print");
        } catch (Exception e) {
            e.printStackTrace();
        }
        return null;
    }
}

I would love it if Java doesn't require me to catch the InvocationTargetException
and let me work with the PrinterException the same way.

Let me give you some examples that illustrate what kind of mess it brings to the Swing code base.

Fortunately there are not many checked exceptions used in Swing code,
but when you implement printing you can't avoid PrinterException
and PrinterAbortException.


Since printing must be done in the background to not block the GUI,

we have to properly re-throw the exceptions back to the Event Dispatching Thread thread.




So in the implementation of the JTable.print() method you can find the following construction:

        // this runnable will be used to do the printing
        // (and save any throwables) on another thread
        Runnable runnable = new Runnable() {
            public void run() {
                try {
                    // do the printing
                    job.print(copyAttr);
                } catch (Throwable t) {
                    // save any Throwable to be rethrown
                    synchronized(lock) {
                        printError = t;
                    }
                } finally {
                    // we're finished - hide the dialog
                    printingStatus.dispose();
                }
            }
        };

and then we have to understand what kind of exception was thrown and how we can re-throw it back:

        // check the type of error and handle it
        if (pe != null) {
            // a subclass of PrinterException meaning the job was aborted,
            // in this case, by the user
            if (pe instanceof PrinterAbortException) {
                return false;
            } else if (pe instanceof PrinterException) {
                throw (PrinterException)pe;
            } else if (pe instanceof RuntimeException) {
                throw (RuntimeException)pe;
            } else if (pe instanceof Error) {
                throw (Error)pe;
            }

            // can not happen
            throw new AssertionError(pe);
        }

This boilerplate code can't be avoided, you can find the same pattern in the implementation of JTable.print().


If the methods that are called on the background thread threw another checked exceptions,
we would have to add another instanceof checks there.

More checked exceptions - more lines of code.




If there were no checked exceptions in java, that kind of code would be unnecessary,

we could freely re-throw any exception no matter what their type is.


I would definitely remove the checked exceptions from Java.

This was an entry from the Swing in a better world series

Thanks

alexp

Swing in a better world

I truly love the Swing GUI toolkit, I enjoy its flexibility, opennes and great abilities.

I know that some people say that Swing is too difficult to learn,
and I partly accept it because it took me several years working in the Swing team
to get the whole picture of the AWT, Java 2D and the Swing itself.

The Swing history counts more then 10 years and it is definitely not about end.
The new features have already been added to JDK 7
and the new blogs are coming to describe them.

Swing is the best graphical toolkit I have ever worked with,
anyway it could have been implemented even better.

Even the best piece of software in the world would have bugs
and design glitches. At this point I want to stop for a moment,
to look back and remember the cases when
I wanted Swing to be designed in a different way.

This information may be useful for all developers
who are working on any other graphical toolkit.

Swing is written in Java,
so its API is tightly bound with Java language peculiarities
and event high level decisions of the Swing architecture are affected by the language sometimes.

So I'll cover the java related issues first
and then touch some exclusively Swing features.

Java related issues

• Java interfaces
• Checked exceptions
• Generics and arrays

Swing design

• Listeners
• Compound components
• Static fields vs AppContext

Thanks
alexp

SAF and JDK7

Hello Swing community

After much discussion it's become clear that the Swing Application Framework API as it is today hasn't reached
consensus and we feel still needs further design work done.

Since the SAF API was committed to milestone 5 of JDK7 and that time is already here,
this date is now impossible, and we need to decommit SAF from any specific JDK 7 milestone.

Thanks

alexp