The following test fails to enlarge the button:

import java.awt.*;

public class Test {

    public static void main(String[] args) {
        Frame f = new Frame();
        Button b = new Button("ok");
        f.add(b);
        f.setExtendedState(Frame.MAXIMIZED_BOTH);
        f.pack();
        f.setVisible(true);
    }
}

This is a regression of the fix for CR 6637796.
Posted Date : 2008-03-31 12:50:24.0

N/A

It seems that fixing this issue by introducing an additional workaround doesn't make any sense. The root cause of this issue (as well as the 6637796) is the fact that the 'valid' property doesn't throw any notifications upon changes. However, the mixing code needs to handle changes to this property and recalculate the shapes of the effected components.

Which means that in order to fix this issue we need to rearchitect the validate()/invalidate()/isValid() machinery so that it allows to hook into the process of validating/invalidating a component.

The main task would be to identify all the locations of direct accessing of the 'valid' property and change them to use the setter/getter pair. After that, making the valid property private, we may be sure that we can safely hook into the setter and catch all the modifications to this property, and therefore we'll be able to correctly recalculate the shapes of components in appropriate moments of time.
Posted Date : 2008-04-01 11:21:18.0

I think no there is no hook necessary for this bug fix. It will make everything slow!
a Component with peer should during setBounds (only if bounds changed) simply inform the mixing code, to set new clippings.
So the old valid mechanism can be kept, because it has NOTHING to do with mixing code!!!
Simple Bugs should be solved simple and fast.