<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