FULL PRODUCT VERSION :
java version "1.4.1_02"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.1_02-b06)
Java HotSpot(TM) Client VM (build 1.4.1_02-b06, mixed mode)

java version "1.4.0_01"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.0_01-b03)
Java HotSpot(TM) Client VM (build 1.4.0_01-b03, mixed mode)

java version "1.3.1_07"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.3.1_07-b02)
Java HotSpot(TM) Client VM (build 1.3.1_07-b02, mixed mode)


FULL OS VERSION :
Linux indigo 2.4.20-8 #1 Thu Mar 13 17:54:28 EST 2003 i686 i686 i386 GNU/Linux


A DESCRIPTION OF THE PROBLEM :
Boxes seem to have some repaint problems when there's not a "heavy" (descended from JComponent) Swing component behind them. On Linux in the 1.4.x series, a Box as content pane fails to paint its background, resulting in random noise artifacts   in the final rendering. I have also observed a similar bug (which I'm in the process of pursueing) where a Box as the target of a ScrollPane gets painted solid white (instead of striped) when running on Mac OS X.

STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
Seems to have been broken in the transition from 1.3.x to 1.4.x, as it works with 1.3.1_07 but not with 1.4.0_01 and later.

Run the code below on a Linux box. Play with resizing the frame to see that the background on the right-hand side is never repainted.


REPRODUCIBILITY :
This bug can be reproduced always.

---------- BEGIN SOURCE ----------
import java.awt.*;
import javax.swing.*;
/**
* <code>BoxVsPanel</code> demonstrates a Box-rendering
* bug on Java 1.4.1.
*
* <p>Copyright (C) 2003 by Ian W. Davis. All rights reserved.
* <br>Begun on Tue Jun 10 08:51:17 EDT 2003
*/
public class BoxVsPanel //extends ... implements ...
{
    public void Main()
    {
        JPanel  panel   = new JPanel(new GridLayout(0,1));
        Box     box     = Box.createVerticalBox();
        
        fillContainer(panel);
        fillContainer(box);
        
        Box cp = Box.createHorizontalBox();
        cp.add(panel);
        cp.add(box);
        
        JFrame frame = new JFrame("BoxVsPanel2");
        frame.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);
        frame.setContentPane(cp);
        frame.pack();
        frame.setSize(frame.getWidth()+100, frame.getHeight()+100);
        frame.setVisible(true);
    }
    
    void fillContainer(Container c)
    {
        c.add(new JCheckBox("[Dum dum dum] A loooong time ago in a"));
        c.add(new JCheckBox("galaxy"));
        c.add(new JCheckBox("far, far away..."));
    }

    public static void main(String[] args)
    {
        BoxVsPanel mainprog = new BoxVsPanel();
        mainprog.Main();
    }
}//class

---------- END SOURCE ----------

CUSTOMER SUBMITTED WORKAROUND :
Boxes can be wrapped in JPanels to provide a solid background behind them.

Release Regression From : 1.3.1_07
The above release value was the last known release where this 
bug was known to work. Since then there has been a regression.

(Incident Review ID: 187522) 
======================================================================

If you must use a Box as a contentPane, you should invoke setOpaque(true) on it
and override paintComponent to fill in the background.
  xxxxx@xxxxx   2003-09-18

We require the content pane to be opaque. Box is bad for this as it is not opaque, and worse yet it does not honor the opaque property.
Box is a bad JComponent, it should have a UI and honor the opacity property.
  xxxxx@xxxxx   2003-09-18

While my previous evaluation is correct in that Box is a bad JComponent it isn't directly what was triggering this problem.
This test case previously worked because Swing wouldn't actually handle the painting of Boxs.  This is because Box was not a JComponent and Swing's painting only handles JComponents.  Refer to 4304100 for details on the motivation for making Box a JComponent.
Swing's painting infrastructure requires there to be an opaque JComponent in the containment hierarchy.  This is documented in JRootPane:

 * The painting architecture of Swing requires an opaque
 * <code>JComponent</code>
 * to exist in the containment hieararchy above all other components. This is
 * typically provided by way of the content pane. If you replace the content
 * pane, it is recommended that you make the content pane opaque
 * by way of <code>setOpaque(true)</code>. Additionally, if the content pane
 * overrides <code>paintComponent</code>, it
 * will need to completely fill in the background in an opaque color in 
 * <code>paintComponent</code>.

Once Box was made a JComponent this test case failed because Box is not opaque and therefore there are no opaque JComponents and you see painting artifacts.

Of course this changed in 1.5.  In 1.5 we made the rootpane opaque by default.  The test case then works in 1.5 because now there is an opaque JComponent in the containment hierarchy and all is well again.  I'm closing this bug out as a duplicate of the bug that changed the opacity of the JRootPane (4939857).

What of Box not being a good JComponent?  That's filed as 4907674, refer to it for more information.
  xxxxx@xxxxx   2005-07-14 13:41:56 GMT
Posted Date : 2005-07-14 13:41:56.0