使用JTextArea时，MigLayout在JOption窗格中导致异常。 FlowLayout很好

Question

The sample program below displays a frame with two buttons. Pressing the second button which uses MigLayout causes an exception. The first button which uses FlowLayout works just fine. Appears to be a bug in MigLayout ?

import java.awt.FlowLayout;
import java.awt.event.ActionEvent;
import java.awt.event.ActionListener;

import javax.swing.JButton;
import javax.swing.JDialog;
import javax.swing.JFrame;
import javax.swing.JOptionPane;
import javax.swing.JPanel;
import javax.swing.JTextArea;
import javax.swing.SwingUtilities;

import net.miginfocom.swing.MigLayout;

public class Main extends JPanel {

static private JFrame frame = new JFrame("Test MigLayout");

public Main() {
    JButton flowLayoutButton = new JButton("FlowLayout");
    JButton miglayoutButton = new JButton("MigLayout");
    add(flowLayoutButton);
    add(miglayoutButton);
    flowLayoutButton.addActionListener(new ActionListener() {
        public void actionPerformed(ActionEvent actionEventIn) {
            showDialog(false);
        }
    });
    miglayoutButton.addActionListener(new ActionListener() {
        public void actionPerformed(ActionEvent actionEventIn) {
            showDialog(true);
        }
    });
}

public static void main(String[] args) {
    Main main = new Main();
    frame.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);
    frame.setContentPane(main);
    SwingUtilities.invokeLater(new Runnable() {
        @Override
        public void run() {
            frame.pack();
            frame.setVisible(true);
            frame.setBounds(200, 200, 200, 200);
        }
    });
}
private void showDialog(boolean useMidgLayoutIn) {
    JPanel panel = new JPanel(useMidgLayoutIn ? new MigLayout() : new FlowLayout());
    JTextArea topTextArea = new JTextArea("Here is some junk text to fill up the Text Area.");
    panel.add(topTextArea);
    panel.add(new JButton("Button"));

    JOptionPane optionPane = new JOptionPane(panel, JOptionPane.ERROR_MESSAGE);
    JDialog dialog = optionPane.createDialog(frame, "Application  Error");
    dialog.setResizable(true);
    dialog.pack();
    dialog.setVisible(true);
}
}

Answer 1

The reason for the NPE is some mig-internal magic related to JTextArea/JEditorPane (details below). This may cause problems in nested containers some parent has a manager that keeps internal state, fi in BoxLayout.

Simplest way out: don't nest - MigLayout is designed to control one-big-panel. In the case of adding to pre-fabricated special-case containers like optionPane, that's not an option: here it helps to wrap the textArea/editorPane in a JScrollPane.

Not entirely sure if that's a bug, though manipulating the container hierarchy upwards in mere getter (preferredLayouutSize) looks suspicious.

Details of why the NPE happens: magic's effect is to force the parent container layout on querying the prefSize:

public Dimension preferredLayoutSize(Container parent) {
    synchronized (parent.getTreeLock()) {
        if (lastParentSize == null
                || !parent.getSize().equals(lastParentSize)) {
            for (ComponentWrapper wrapper : ccMap.keySet()) {
                Component c = (Component) wrapper.getComponent();
                if (c instanceof JTextArea
                        || c instanceof JEditorPane
                        || (c instanceof JComponent && Boolean.TRUE
                                .equals(((JComponent) c)
                                        .getClientProperty("migLayout.dynamicAspectRatio")))) {
                    layoutContainer(parent);
                    break;
                }
            }
        }

        lastParentSize = parent.getSize();
        return getSizeImpl(parent, LayoutUtil.PREF);
    }
}

Which in turn re-queries the top-level container's prefSize (down in adjustWindowSize):

private void adjustWindowSize(ContainerWrapper parent) {
    BoundSize wBounds = lc.getPackWidth();
    BoundSize hBounds = lc.getPackHeight();

    if (wBounds == null && hBounds == null)
        return;

    Window win = ((Window) SwingUtilities.getAncestorOfClass(Window.class,
            (Component) parent.getComponent()));
    if (win == null)
        return;

    Dimension prefSize = win.getPreferredSize();
    ....
}

When nested inside a BoxLayout, this leads to re-entering the checkTarget:

public Dimension preferredLayoutSize(Container target) {
    Dimension size;
    synchronized(this) {
        checkContainer(target);
        // checkRequests initializes all internal book-keeping
        checkRequests();
        // here's the NPE in the second round
        size = new Dimension(xTotal.preferred, yTotal.preferred);
    }
    ...
 }

void checkRequests() {
    // config only if not yet done earlier
    if (xChildren == null || yChildren == null) {
        // The requests have been invalidated... recalculate
        // the request information.
        int n = target.getComponentCount();
        //JW: first time around the arrays of sz are initialized
        xChildren = new SizeRequirements[n];
        yChildren = new SizeRequirements[n];
        for (int i = 0; i < n; i++) {
            Component c = target.getComponent(i);
            ....
            Dimension min = c.getMinimumSize();
            Dimension typ = c.getPreferredSize();
            ....
        }
        .... 
        // JW: never reached if c.getPref re-enters, that is xTotal remains null
        if (absoluteAxis == X_AXIS) {
            xTotal = SizeRequirements.getTiledSizeRequirements(xChildren);
            yTotal = SizeRequirements.getAlignedSizeRequirements(yChildren);
        } else {
            xTotal = SizeRequirements.getAlignedSizeRequirements(xChildren);
            yTotal = SizeRequirements.getTiledSizeRequirements(yChildren);
        }

     }
 }   

Answer 2

MigLayout 5.0 has compensation for this. It's in the trunk at Google Code if you want to test it.

Cheers, Mikael