<Swing Dev> [9] Review Request for 8130892: Test javax/swing/plaf/basic/BasicTextUI/8001470/bug8001470.java fails in Solaris Sparcv9
Alexander Scherbatiy
alexandr.scherbatiy at oracle.com
Mon Aug 3 12:02:32 UTC 2015
The fix looks good to me.
Thanks,
Alexandr.
On 7/27/2015 4:32 PM, Semyon Sadetsky wrote:
> Alexander,
> you can run the next test on Windows which sets the right frame size
> and see that it fails because of the negative size.
>
> import javax.swing.*;
> import javax.swing.border.EmptyBorder;
> import java.awt.*;
>
> public class bug8001470 {
>
> private static JFrame frame;
> private static JTextField textField1;
> private static JTextField textField2;
>
> public static void main(String[] args) throws Exception {
> SwingUtilities.invokeAndWait(new Runnable() {
> @Override
> public void run() {
> frame = new JFrame("JTextField Test");
> frame.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);
>
> JPanel container = (JPanel) frame.getContentPane();
> container.setLayout(new GridLayout(2,1));
>
> textField1 = new JTextField("\u0e01");
> textField2 = new JTextField("\u0c01");
> JPanel panel = new JPanel();
> BorderLayout mgr = new BorderLayout();
> panel.setLayout(mgr);
> container.add(panel);
> panel.setBorder(new EmptyBorder(100, 100, 100, 100));
> panel.add(textField1);
> panel.add(textField2);
> frame.setVisible(true);
> frame.pack();
> }
> });
> if( textField1.getHeight() < 10 || textField2.getHeight() < 10 )
> throw new Exception("Wrong field height");
> System.out.println("ok");
> SwingUtilities.invokeLater(new Runnable() {
> @Override
> public void run() {
> frame.dispose();
> }
> });
> }
> }
>
> --Semyon
>
>
> On 7/27/2015 2:52 PM, Semyon Sadetsky wrote:
>> -Alexander Yarmoliskiy
>> +Alexander Zvegintsev
>>
>> On 7/27/2015 2:36 PM, Semyon Sadetsky wrote:
>>> It is probably an issue, but even if fix it we cannot guarantee that
>>> insets will be always less then the resulting frame size. Method
>>> guessInsets() which obtains insets in frame's peer is hinting.
>>> And again layout manager is able to apply negative size to container
>>> regardless the frame size.
>>>
>>> --Semyon
>>>
>>> On 7/27/2015 1:38 PM, Alexander Scherbatiy wrote:
>>>>
>>>> I see that sun.awt.X11.WindowDimensions class takes insets into
>>>> account and sets window size bigger than insets size. It looks like
>>>> difference between windows size and insets should be positive in
>>>> this case.
>>>>
>>>> Thanks,
>>>> Alexandr.
>>>>
>>>> On 7/27/2015 9:56 AM, Semyon Sadetsky wrote:
>>>>> Your expectation is not correct because if insets are set for a
>>>>> container then its child components can receive negative size even
>>>>> if the parent size is positive.
>>>>>
>>>>> --Semyon
>>>>>
>>>>> On 7/24/2015 7:09 PM, Sergey Bylokhov wrote:
>>>>>> On 23.07.15 16:06, Semyon Sadetsky wrote:
>>>>>>> Peer validation doesn't make any sense until layout manager may
>>>>>>> easily set negative size for any component using
>>>>>>> Component.setBounds(). That happens this issue particularly.
>>>>>> In your first request you mention that the problem occurs when
>>>>>> "On Linux and Solaris platforms the initial frame window width
>>>>>> and height can be negative".
>>>>>> My expectation is that: if the window size if >=0 then none of
>>>>>> the layout managers should set negative value for width/height, no?
>>>>>>
>>>>>>> So we need either to introduce the size constraint and fix the
>>>>>>> general issue either make UI to be prepared to get negative size
>>>>>>> occasionally i.e. fix the particular case (what is done in the
>>>>>>> solution).
>>>>>>> Which option are you suggesting?
>>>>>>>
>>>>>>> --Semyon
>>>>>>>
>>>>>>> On 7/23/2015 2:06 PM, Sergey Bylokhov wrote:
>>>>>>>> On 23.07.15 9:22, Semyon Sadetsky wrote:
>>>>>>>>> O.K. It sounds like a generic rule. Can I add this constant to
>>>>>>>>> the Component.reshape()?
>>>>>>>> Historically our components have a lack of any data validation
>>>>>>>> because the user was able to call peers methods directly. I
>>>>>>>> assume that such validation should exists already in the peers
>>>>>>>> classes(like XBaseWindow.xSetBounds()).
>>>>>>>>
>>>>>>>>> --Semyon
>>>>>>>>>
>>>>>>>>> On 7/22/2015 3:40 PM, Sergey Bylokhov wrote:
>>>>>>>>>> It seems that the bug is in fact that the size of the window
>>>>>>>>>> is negative. In a lot of place we assume that it should be >=0.
>>>>>>>>>>
>>>>>>>>>> On 22.07.15 14:28, Semyon Sadetsky wrote:
>>>>>>>>>>> In setVisible(true) if size is not specified and pack has
>>>>>>>>>>> not been called yet frame get some initial size depending on
>>>>>>>>>>> the platform.
>>>>>>>>>>> That is the purpose of the test : to call pack() after
>>>>>>>>>>> setVisible().
>>>>>>>>>>>
>>>>>>>>>>> --Semyon
>>>>>>>>>>>
>>>>>>>>>>> On 7/22/2015 2:03 PM, Alexander Scherbatiy wrote:
>>>>>>>>>>>> On 7/17/2015 5:32 PM, Semyon Sadetsky wrote:
>>>>>>>>>>>>> Hello,
>>>>>>>>>>>>>
>>>>>>>>>>>>> Please review fix for JDK9:
>>>>>>>>>>>>>
>>>>>>>>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8130892
>>>>>>>>>>>>> webrev:
>>>>>>>>>>>>> http://cr.openjdk.java.net/~ssadetsky/8130892/webrev.00/
>>>>>>>>>>>>>
>>>>>>>>>>>>> On Linux and Solaris platforms the initial frame window
>>>>>>>>>>>>> width and height can be negative. So the root view is
>>>>>>>>>>>>> initialization trigger was updated to take negative values
>>>>>>>>>>>>> into account. The fix was tested on Ubuntu 12, OEL7 and
>>>>>>>>>>>>> Solaris 11.
>>>>>>>>>>>> It looks strange that the test which does not set
>>>>>>>>>>>> explicit bounds and calls frame.pack() encounters into
>>>>>>>>>>>> negative sizes.
>>>>>>>>>>>> In which place does the frame window obtain negative
>>>>>>>>>>>> width and height?
>>>>>>>>>>>>
>>>>>>>>>>>> Thanks,
>>>>>>>>>>>> Alexandr.
>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> --Semyon
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>
More information about the swing-dev
mailing list