From alexandr.scherbatiy at oracle.com  Tue May  5 10:18:25 2015
From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy)
Date: Tue, 05 May 2015 13:18:25 +0300
Subject: <Swing Dev> <AWT Dev> [9] Review Request: JDK-8078855
 [TEST_BUG] javax/swing/JComboBox/8032878/bug8032878.java fails in
 WindowsClassicLookAndFeel
In-Reply-To: <554292E6.7080608@oracle.com>
References: <554292E6.7080608@oracle.com>
Message-ID: <554898F1.3060604@oracle.com>

On 4/30/2015 11:39 PM, pooja chopra wrote:
> Hello,
> Please review a fix for issue:
> 8078855 [TEST_BUG] javax/swing/JComboBox/8032878/bug8032878.java fails 
> in WindowsClassicLookAndFeel
> Test bug fix.
> https://bugs.openjdk.java.net/browse/JDK-8078855
> The webrev is : http://cr.openjdk.java.net/~pchopra/8078855/webrev.00/

    Does the fix work on Mac OS X with the Aqua L&F?

   Thanks,
   Alexandr.

>
> Thanks,
> Pooja



From doychin at dsoft-bg.com  Tue May  5 10:40:55 2015
From: doychin at dsoft-bg.com (Doychin Bondzhev)
Date: Tue, 05 May 2015 13:40:55 +0300
Subject: <Swing Dev> Proposal for change to  javax.swing.DefaultCellEditor
Message-ID: <55489E37.5030403@dsoft-bg.com>

Hi, guys.

i can't check in the archive was this ever discussed before but here is 
my proposal:

Right now  DefaultCellEditor has 3 constructors which accept text field, 
check box and combo box.

If you want to use another control that is more complex like panel with 
few buttons for example you will need to inherit from DefaultCellEditor 
  and call any of the three constructors and then in your code to reload 
editor component and delegate fields with new values.

What if there is default DefaultCellEditor constructor without parameters?

Or the other way is to have DefaultCellEditor constructor that accepts 
JComponent and EditorDelegate as parameters and just stores that values 
in editorComponent field. It will be the responsibility of the developer 
that inherits the DefaultCellEditor to create an instance of 
EditorDelegate that implements the necessary methods needed to 
communicate with his JComponent instance.

Any thoughts on this?

-- 
Doychin Bondzhev
dSoft-Bulgaria Ltd.
PowerPro - billing & provisioning solution for Service providers
PowerStor - Warehouse & POS
http://www.dsoft-bg.com/
Mobile: +359888243116
-------------- next part --------------
A non-text attachment was scrubbed...
Name: doychin.vcf
Type: text/x-vcard
Size: 268 bytes
Desc: not available
URL: <http://mail.openjdk.java.net/pipermail/swing-dev/attachments/20150505/36a7ac02/doychin.vcf>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5924 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mail.openjdk.java.net/pipermail/swing-dev/attachments/20150505/36a7ac02/smime.p7s>

From doychin at dsoft-bg.com  Fri May  1 15:08:03 2015
From: doychin at dsoft-bg.com (Doychin Bondzhev)
Date: Fri, 01 May 2015 18:08:03 +0300
Subject: <Swing Dev> Proposal for change to  javax.swing.DefaultCellEditor
Message-ID: <554396D3.8060000@dsoft-bg.com>

Hi, guys.

i can't check in the archive was this ever discussed before but here is 
my proposal:

Right now  DefaultCellEditor has 3 constructors which accept text field, 
check box and combo box.

If you want to use another control that is more complex like panel with 
few buttons for example you will need to inherit from DefaultCellEditor 
  and call any of the three constructors and then in your code to reload 
editor component and delegate fields with new values.

What if there is default DefaultCellEditor constructor without parameters?

Or the other way is to have DefaultCellEditor constructor that accepts 
JComponent and EditorDelegate as parameters and just stores that values 
in editorComponent field. It will be the responsibility of the developer 
that inherits the DefaultCellEditor to create an instance of 
EditorDelegate that implements the necessary methods needed to 
communicate with his JComponent instance.

Any thoughts on this?

-- 
Doychin Bondzhev
dSoft-Bulgaria Ltd.
PowerPro - billing & provisioning solution for Service providers
PowerStor - Warehouse & POS
http://www.dsoft-bg.com/
Mobile: +359888243116
-------------- next part --------------
A non-text attachment was scrubbed...
Name: doychin.vcf
Type: text/x-vcard
Size: 268 bytes
Desc: not available
URL: <http://mail.openjdk.java.net/pipermail/swing-dev/attachments/20150501/89f4e9d2/doychin.vcf>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5924 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mail.openjdk.java.net/pipermail/swing-dev/attachments/20150501/89f4e9d2/smime.p7s>

From alexey.ivanov at oracle.com  Tue May  5 13:16:22 2015
From: alexey.ivanov at oracle.com (Alexey Ivanov)
Date: Tue, 05 May 2015 16:16:22 +0300
Subject: <Swing Dev> <AWT Dev> [9] Review Request: JDK-8078855
 [TEST_BUG] javax/swing/JComboBox/8032878/bug8032878.java fails in
 WindowsClassicLookAndFeel
In-Reply-To: <554292E6.7080608@oracle.com>
References: <554292E6.7080608@oracle.com>
Message-ID: <5548C2A6.5070207@oracle.com>

Hello Pooja,

The modified test case does not reproduce the problem reported in 
https://bugs.openjdk.java.net/browse/JDK-8032878. So this fix cannot be 
applied to the regression test.

I confirm that the original test fails in WindowsClassicLookAndFeel 
because the editor selects the text, thus the typed text '123' is not 
added to existing text but replaces it. It could be a bug in 
WindowsClassicLookAndFeel or its feature. If it's not a bug, then the 
test should expect the value of "123" rather than "one123" where 
WindowsClassicLookAndFeel is used.

Regards,
Alexey

On 30.04.2015 23:39, pooja chopra wrote:
> Hello,
> Please review a fix for issue:
> 8078855 [TEST_BUG] javax/swing/JComboBox/8032878/bug8032878.java fails 
> in WindowsClassicLookAndFeel
> Test bug fix.
> https://bugs.openjdk.java.net/browse/JDK-8078855
> The webrev is : http://cr.openjdk.java.net/~pchopra/8078855/webrev.00/
>
> Thanks,
> Pooja



From Sergey.Bylokhov at oracle.com  Tue May  5 16:16:19 2015
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Tue, 05 May 2015 19:16:19 +0300
Subject: <Swing Dev> [9] Review Request: 6206437 Typo in JInternalFrame
 setDefaultCloseOperation() doc (WindowClosing --> internalFrameClosing)
Message-ID: <5548ECD3.5000009@oracle.com>

Hello.
Please review the fix for a small typo.

Bug: https://bugs.openjdk.java.net/browse/JDK-6206437
Webrev can be found at: http://cr.openjdk.java.net/~serb/6206437/webrev.00

-- 
Best regards, Sergey.



From pooja.chopra at oracle.com  Wed May  6 06:18:50 2015
From: pooja.chopra at oracle.com (pooja chopra)
Date: Wed, 06 May 2015 11:48:50 +0530
Subject: <Swing Dev> [9] Review Request: JDK-8079428 [TEST_BUG] Test
 javax/swing/plaf/windows/6921687/bug6921687.java fails
Message-ID: <5549B24A.40800@oracle.com>

Hello,
Please review a fix for issue:
8079428 [TEST_BUG] Test javax/swing/plaf/windows/6921687/bug6921687.java
Test bug fix.
https://bugs.openjdk.java.net/browse/JDK-8079428
The webrev is : http://cr.openjdk.java.net/~pchopra/8079428/webrev.00/

Thanks,
Pooja


From alexander.zvegintsev at oracle.com  Wed May  6 09:00:55 2015
From: alexander.zvegintsev at oracle.com (Alexander Zvegintsev)
Date: Wed, 06 May 2015 12:00:55 +0300
Subject: <Swing Dev> [9] Review Request: 6206437 Typo in JInternalFrame
 setDefaultCloseOperation() doc (WindowClosing --> internalFrameClosing)
In-Reply-To: <5548ECD3.5000009@oracle.com>
References: <5548ECD3.5000009@oracle.com>
Message-ID: <5549D847.9010809@oracle.com>

Hello Sergey,

the fix looks fine to me.

Thanks,

Alexander.

On 05/05/2015 07:16 PM, Sergey Bylokhov wrote:
> Hello.
> Please review the fix for a small typo.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-6206437
> Webrev can be found at: 
> http://cr.openjdk.java.net/~serb/6206437/webrev.00
>



From alexander.zvegintsev at oracle.com  Wed May  6 09:05:15 2015
From: alexander.zvegintsev at oracle.com (Alexander Zvegintsev)
Date: Wed, 06 May 2015 12:05:15 +0300
Subject: <Swing Dev> [9] Review Request: JDK-8079428 [TEST_BUG] Test
 javax/swing/plaf/windows/6921687/bug6921687.java fails
In-Reply-To: <5549B24A.40800@oracle.com>
References: <5549B24A.40800@oracle.com>
Message-ID: <5549D94B.5070406@oracle.com>

Hello Pooja,

the fix looks fine to me.

Thanks,

Alexander.

On 05/06/2015 09:18 AM, pooja chopra wrote:
> Hello,
> Please review a fix for issue:
> 8079428 [TEST_BUG] Test javax/swing/plaf/windows/6921687/bug6921687.java
> Test bug fix.
> https://bugs.openjdk.java.net/browse/JDK-8079428
> The webrev is : http://cr.openjdk.java.net/~pchopra/8079428/webrev.00/
>
> Thanks,
> Pooja



From Sergey.Bylokhov at oracle.com  Wed May  6 12:29:21 2015
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Wed, 06 May 2015 15:29:21 +0300
Subject: <Swing Dev> [9] Review Request: JDK-8079428 [TEST_BUG] Test
 javax/swing/plaf/windows/6921687/bug6921687.java fails
In-Reply-To: <5549B24A.40800@oracle.com>
References: <5549B24A.40800@oracle.com>
Message-ID: <554A0921.3010502@oracle.com>

Hello,
It seems that this is a bug in the jtreg because according its 
specification:

"If no |@run| tags are present in a defining file, a default is assumed 
depending upon the file's filename extension"

File type 	Default 	Notes
.java 	|@run main <name>| 	<name> is the name of the file without the 
".java" suffix
.sh 	|@run shell <file>| 	
.html 	|@run applet <file>| 	


Jonathan do you know something about this issue?

On 06.05.15 9:18, pooja chopra wrote:
> Hello,
> Please review a fix for issue:
> 8079428 [TEST_BUG] Test javax/swing/plaf/windows/6921687/bug6921687.java
> Test bug fix.
> https://bugs.openjdk.java.net/browse/JDK-8079428
> The webrev is : http://cr.openjdk.java.net/~pchopra/8079428/webrev.00/
>
> Thanks,
> Pooja


-- 
Best regards, Sergey.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/swing-dev/attachments/20150506/558c5ff1/attachment.html>

From alexey.ivanov at oracle.com  Wed May  6 13:30:25 2015
From: alexey.ivanov at oracle.com (Alexey Ivanov)
Date: Wed, 06 May 2015 16:30:25 +0300
Subject: <Swing Dev> [9] Review request for 8033069: mouse wheel scroll
 closes combobox popup
Message-ID: <554A1771.60103@oracle.com>

Hello Swing team,

Could you please review the fix:
     bug: https://bugs.openjdk.java.net/browse/JDK-8033069
     webrev: http://cr.openjdk.java.net/~aivanov/8033069/jdk9/webrev.00/

Description:
If you rotate mouse wheel when combo box popup is open, the popup gets 
closed.

The fix is to always consume MOUSE_WHEEL event.

There are two regression tests for the cases where popup has vertical 
scroll bar and does not have scroll bar.

Thanks,
Alexey


From alexey.ivanov at oracle.com  Wed May  6 13:45:57 2015
From: alexey.ivanov at oracle.com (Alexey Ivanov)
Date: Wed, 06 May 2015 16:45:57 +0300
Subject: <Swing Dev> [9] Review Request: JDK-8079428 [TEST_BUG] Test
 javax/swing/plaf/windows/6921687/bug6921687.java fails
In-Reply-To: <554A0921.3010502@oracle.com>
References: <5549B24A.40800@oracle.com> <554A0921.3010502@oracle.com>
Message-ID: <554A1B15.9060507@oracle.com>

Hello,

I faced this problem too, and only with JDK 9. If there's no @run tag in 
the java file, the main method of the test is not run. However in my 
case, the test reported success where I expected failure.

Regards,
Alexey

On 06.05.2015 15:29, Sergey Bylokhov wrote:
> Hello,
> It seems that this is a bug in the jtreg because according its 
> specification:
>
> "If no |@run| tags are present in a defining file, a default is 
> assumed depending upon the file's filename extension"
>
> File type 	Default 	Notes
> .java 	|@run main <name>| 	<name> is the name of the file without the 
> ".java" suffix
> .sh 	|@run shell <file>| 	
> .html 	|@run applet <file>| 	
>
>
> Jonathan do you know something about this issue?
>
> On 06.05.15 9:18, pooja chopra wrote:
>> Hello,
>> Please review a fix for issue:
>> 8079428 [TEST_BUG] Test javax/swing/plaf/windows/6921687/bug6921687.java
>> Test bug fix.
>> https://bugs.openjdk.java.net/browse/JDK-8079428
>> The webrev is : http://cr.openjdk.java.net/~pchopra/8079428/webrev.00/
>>
>> Thanks,
>> Pooja
>
>
> -- 
> Best regards, Sergey.



From yuri.nesterenko at oracle.com  Wed May  6 13:53:43 2015
From: yuri.nesterenko at oracle.com (Yuri Nesterenko)
Date: Wed, 06 May 2015 16:53:43 +0300
Subject: <Swing Dev> [9] Review Request: JDK-8079428 [TEST_BUG] Test
 javax/swing/plaf/windows/6921687/bug6921687.java fails
In-Reply-To: <554A1B15.9060507@oracle.com>
References: <5549B24A.40800@oracle.com> <554A0921.3010502@oracle.com>
	<554A1B15.9060507@oracle.com>
Message-ID: <554A1CE7.7010609@oracle.com>

I guess the @build instruction here adds some degree of uncertainty:
jtreg may not be able to determine which class to run.

-yan

On 05/06/2015 04:45 PM, Alexey Ivanov wrote:
> Hello,
>
> I faced this problem too, and only with JDK 9. If there's no @run tag in
> the java file, the main method of the test is not run. However in my
> case, the test reported success where I expected failure.
>
> Regards,
> Alexey
>
> On 06.05.2015 15:29, Sergey Bylokhov wrote:
>> Hello,
>> It seems that this is a bug in the jtreg because according its
>> specification:
>>
>> "If no |@run| tags are present in a defining file, a default is
>> assumed depending upon the file's filename extension"
>>
>> File type     Default     Notes
>> .java     |@run main <name>|     <name> is the name of the file
>> without the ".java" suffix
>> .sh     |@run shell <file>|
>> .html     |@run applet <file>|
>>
>>
>> Jonathan do you know something about this issue?
>>
>> On 06.05.15 9:18, pooja chopra wrote:
>>> Hello,
>>> Please review a fix for issue:
>>> 8079428 [TEST_BUG] Test javax/swing/plaf/windows/6921687/bug6921687.java
>>> Test bug fix.
>>> https://bugs.openjdk.java.net/browse/JDK-8079428
>>> The webrev is : http://cr.openjdk.java.net/~pchopra/8079428/webrev.00/
>>>
>>> Thanks,
>>> Pooja
>>
>>
>> --
>> Best regards, Sergey.
>



From alexandr.scherbatiy at oracle.com  Wed May  6 14:11:36 2015
From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy)
Date: Wed, 06 May 2015 17:11:36 +0300
Subject: <Swing Dev> [9] Review Request: JDK-8079428 [TEST_BUG] Test
 javax/swing/plaf/windows/6921687/bug6921687.java fails
In-Reply-To: <554A0921.3010502@oracle.com>
References: <5549B24A.40800@oracle.com> <554A0921.3010502@oracle.com>
Message-ID: <554A2118.403@oracle.com>


This is the known issue in jtreg: CODETOOLS-7901378 Test result error 
when @build used without @run main
    https://bugs.openjdk.java.net/browse/CODETOOLS-7901378

  It is closed as not an issue but I would argue against it. It 
definitely worked in jtreg 4.1 fcs b05.
  Why tests which pass with jtreg 4.1 b05 started to fail in b11?

  Thanks,
  Alexandr.


On 5/6/2015 3:29 PM, Sergey Bylokhov wrote:
> Hello,
> It seems that this is a bug in the jtreg because according its 
> specification:
>
> "If no |@run| tags are present in a defining file, a default is 
> assumed depending upon the file's filename extension"
>
> File type 	Default 	Notes
> .java 	|@run main <name>| 	<name> is the name of the file without the 
> ".java" suffix
> .sh 	|@run shell <file>| 	
> .html 	|@run applet <file>| 	
>
>
> Jonathan do you know something about this issue?
>
> On 06.05.15 9:18, pooja chopra wrote:
>> Hello,
>> Please review a fix for issue:
>> 8079428 [TEST_BUG] Test javax/swing/plaf/windows/6921687/bug6921687.java
>> Test bug fix.
>> https://bugs.openjdk.java.net/browse/JDK-8079428
>> The webrev is : http://cr.openjdk.java.net/~pchopra/8079428/webrev.00/
>>
>> Thanks,
>> Pooja
>
>
> -- 
> Best regards, Sergey.



From alexandr.scherbatiy at oracle.com  Wed May  6 14:15:29 2015
From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy)
Date: Wed, 06 May 2015 17:15:29 +0300
Subject: <Swing Dev> Proposal for change to javax.swing.DefaultCellEditor
In-Reply-To: <55489E37.5030403@dsoft-bg.com>
References: <55489E37.5030403@dsoft-bg.com>
Message-ID: <554A2201.1070203@oracle.com>


  Could you file an enhancement on your proposal in 
http://bugreport.java.com/bugreport

  Thanks,
  Alexandr.

On 5/5/2015 1:40 PM, Doychin Bondzhev wrote:
> Hi, guys.
>
> i can't check in the archive was this ever discussed before but here 
> is my proposal:
>
> Right now  DefaultCellEditor has 3 constructors which accept text 
> field, check box and combo box.
>
> If you want to use another control that is more complex like panel 
> with few buttons for example you will need to inherit from 
> DefaultCellEditor  and call any of the three constructors and then in 
> your code to reload editor component and delegate fields with new values.
>
> What if there is default DefaultCellEditor constructor without 
> parameters?
>
> Or the other way is to have DefaultCellEditor constructor that accepts 
> JComponent and EditorDelegate as parameters and just stores that 
> values in editorComponent field. It will be the responsibility of the 
> developer that inherits the DefaultCellEditor to create an instance of 
> EditorDelegate that implements the necessary methods needed to 
> communicate with his JComponent instance.
>
> Any thoughts on this?
>



From alexandr.scherbatiy at oracle.com  Wed May  6 15:09:27 2015
From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy)
Date: Wed, 06 May 2015 18:09:27 +0300
Subject: <Swing Dev> [9] Review Request: 6206437 Typo in JInternalFrame
 setDefaultCloseOperation() doc (WindowClosing --> internalFrameClosing)
In-Reply-To: <5549D847.9010809@oracle.com>
References: <5548ECD3.5000009@oracle.com> <5549D847.9010809@oracle.com>
Message-ID: <554A2EA7.8090801@oracle.com>


   The fix looks good to me.

   Thanks,
   Alexandr.

On 5/6/2015 12:00 PM, Alexander Zvegintsev wrote:
> Hello Sergey,
>
> the fix looks fine to me.
>
> Thanks,
>
> Alexander.
>
> On 05/05/2015 07:16 PM, Sergey Bylokhov wrote:
>> Hello.
>> Please review the fix for a small typo.
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-6206437
>> Webrev can be found at: 
>> http://cr.openjdk.java.net/~serb/6206437/webrev.00
>>
>



From Sergey.Bylokhov at oracle.com  Wed May  6 15:34:38 2015
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Wed, 06 May 2015 18:34:38 +0300
Subject: <Swing Dev> [9] Review Request: JDK-8079428 [TEST_BUG] Test
 javax/swing/plaf/windows/6921687/bug6921687.java fails
In-Reply-To: <554A2118.403@oracle.com>
References: <5549B24A.40800@oracle.com> <554A0921.3010502@oracle.com>
	<554A2118.403@oracle.com>
Message-ID: <554A348E.5070008@oracle.com>

After discussion we confirm that the problem in the tests.
This fix looks fine.

On 06.05.15 17:11, Alexander Scherbatiy wrote:
>
> This is the known issue in jtreg: CODETOOLS-7901378 Test result error 
> when @build used without @run main
>    https://bugs.openjdk.java.net/browse/CODETOOLS-7901378
>
>  It is closed as not an issue but I would argue against it. It 
> definitely worked in jtreg 4.1 fcs b05.
>  Why tests which pass with jtreg 4.1 b05 started to fail in b11?
>
>  Thanks,
>  Alexandr.
>
>
> On 5/6/2015 3:29 PM, Sergey Bylokhov wrote:
>> Hello,
>> It seems that this is a bug in the jtreg because according its 
>> specification:
>>
>> "If no |@run| tags are present in a defining file, a default is 
>> assumed depending upon the file's filename extension"
>>
>> File type     Default     Notes
>> .java     |@run main <name>|     <name> is the name of the file 
>> without the ".java" suffix
>> .sh     |@run shell <file>|
>> .html     |@run applet <file>|
>>
>>
>> Jonathan do you know something about this issue?
>>
>> On 06.05.15 9:18, pooja chopra wrote:
>>> Hello,
>>> Please review a fix for issue:
>>> 8079428 [TEST_BUG] Test 
>>> javax/swing/plaf/windows/6921687/bug6921687.java
>>> Test bug fix.
>>> https://bugs.openjdk.java.net/browse/JDK-8079428
>>> The webrev is : http://cr.openjdk.java.net/~pchopra/8079428/webrev.00/
>>>
>>> Thanks,
>>> Pooja
>>
>>
>> -- 
>> Best regards, Sergey.
>


-- 
Best regards, Sergey.



From Sergey.Bylokhov at oracle.com  Wed May  6 19:08:46 2015
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Wed, 06 May 2015 22:08:46 +0300
Subject: <Swing Dev> [9] Review Request: 8078149 [macosx] The text of the
 TextArea is not wrapped at word boundaries
Message-ID: <554A66BE.2020206@oracle.com>

Hello.
Please review the fix for a small fix.
This is the problem in lwawt, which was fixed in xawt already:

https://bugs.openjdk.java.net/browse/JDK-4992455

" 1. About line wrapping property.

   "JTextArea has a bound property for line wrapping that controls
   whether or not it will wrap lines. By default, the line
   wrapping property is set to false (not wrapped)."

   2. About wrapping style property.

   "If set to true the lines will be wrapped at word boundaries
   (whitespace) if they are too long to fit within the allocated
   width. If set to false, the lines will be wrapped at character
   boundaries. By default this property is false."

Since we use JTextArea in XAWT as the TextArea component we
should use the following code if we want to wrap lines at word
boundaries:

   jtext.setLineWrap(true);
   jtext.setWrapStyleWord(true);
"

Bug: https://bugs.openjdk.java.net/browse/JDK-8078149
Webrev can be found at: http://cr.openjdk.java.net/~serb/8078149/webrev.00

-- 
Best regards, Sergey.



From Sergey.Bylokhov at oracle.com  Wed May  6 19:28:09 2015
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Wed, 06 May 2015 22:28:09 +0300
Subject: <Swing Dev> [9] Review request for 8033069: mouse wheel scroll
 closes combobox popup
In-Reply-To: <554A1771.60103@oracle.com>
References: <554A1771.60103@oracle.com>
Message-ID: <554A6B49.7000705@oracle.com>

Hi, Alexey.
The changes in the BasicPopupMenuUI does not look clear, I am not sure 
but probably it will be better to implement it in the same way as for 
MOUSE_PRESSED(via UIManager property)? It will add an additional 
configuration possibility.
Can you also confirm that the case when the user install mouse wheel 
listener to the JComboBox still works.

On 06.05.15 16:30, Alexey Ivanov wrote:
> Hello Swing team,
>
> Could you please review the fix:
>     bug: https://bugs.openjdk.java.net/browse/JDK-8033069
>     webrev: http://cr.openjdk.java.net/~aivanov/8033069/jdk9/webrev.00/
>
> Description:
> If you rotate mouse wheel when combo box popup is open, the popup gets 
> closed.
>
> The fix is to always consume MOUSE_WHEEL event.
>
> There are two regression tests for the cases where popup has vertical 
> scroll bar and does not have scroll bar.
>
> Thanks,
> Alexey


-- 
Best regards, Sergey.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/swing-dev/attachments/20150506/0a59d079/attachment.html>

From Sergey.Bylokhov at oracle.com  Wed May  6 19:52:45 2015
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Wed, 06 May 2015 22:52:45 +0300
Subject: <Swing Dev> [9] Review Request: 8013820 JavaDoc for JSpinner
	contains errors
Message-ID: <554A710D.9070101@oracle.com>

Hello.
Please review the fix for a typo in jdk9.

Bug: https://bugs.openjdk.java.net/browse/JDK-8013820
Webrev can be found at: http://cr.openjdk.java.net/~serb/8013820/webrev.00

-- 
Best regards, Sergey.



From Sergey.Bylokhov at oracle.com  Thu May  7 11:46:36 2015
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Thu, 07 May 2015 14:46:36 +0300
Subject: <Swing Dev> [9] Review Request: 5036022: JSpinner does not reflect
 new font on subsequent calls to setFont
Message-ID: <554B509C.1000909@oracle.com>

Hello.
Please review the fix for jdk9.

All our UI components use a UIResource to store some l&f related data, 
such as fonts, colors and so on. This makes the logic of changing one 
l&f to another one simple. Because we can understand the difference, 
between the resources, which were set by the l&f, and  resources, which 
were set by the user. If resource was set by the l&f, it can be replaced 
by the new l&f or by another UI component, but resources which were set 
by the user should be preserved.

This rule is not fully followed in the Spinner**UI. It can contains two 
elements: spinner and textfield in the editor. If the user sets the font 
of the spinner UI component, it automatically update the font of the 
textfield if it was not set by the user directly. But it doesn't wrap 
this font into UIResource and later this causes assumption that this 
font was changed by the user directly, and this is wrong.

Bug: https://bugs.openjdk.java.net/browse/JDK-5036022
Webrev can be found at: http://cr.openjdk.java.net/~serb/5036022/webrev.00

-- 
Best regards, Sergey.



From alexander.zvegintsev at oracle.com  Thu May  7 12:06:53 2015
From: alexander.zvegintsev at oracle.com (Alexander Zvegintsev)
Date: Thu, 07 May 2015 15:06:53 +0300
Subject: <Swing Dev> [9] Review Request: 8013820 JavaDoc for JSpinner
	contains errors
In-Reply-To: <554A710D.9070101@oracle.com>
References: <554A710D.9070101@oracle.com>
Message-ID: <554B555D.5070101@oracle.com>

looks fine.

Thanks,

Alexander.

On 05/06/2015 10:52 PM, Sergey Bylokhov wrote:
> Hello.
> Please review the fix for a typo in jdk9.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8013820
> Webrev can be found at: 
> http://cr.openjdk.java.net/~serb/8013820/webrev.00
>



From alexey.ivanov at oracle.com  Thu May  7 12:31:16 2015
From: alexey.ivanov at oracle.com (Alexey Ivanov)
Date: Thu, 07 May 2015 15:31:16 +0300
Subject: <Swing Dev> [9] Review request for 8033069: mouse wheel scroll
 closes combobox popup
In-Reply-To: <554A6B49.7000705@oracle.com>
References: <554A1771.60103@oracle.com> <554A6B49.7000705@oracle.com>
Message-ID: <554B5B14.40505@oracle.com>

Hi Sergey,

The changes in BasicPopupMenuUI are similar to handling mouse events for 
JMenu. The popup stays open if user rotates wheel over combo box that 
opened the popup but the popup will be canceled if wheel is rotated over 
another combo box or any other component.

The client property "doNotCancelPopup" is set for each combo box because 
MOUSE_PRESS logic is in BasicComboPopup.Handler.mousePressed. If you 
click another combo box, it will open its own popup which automatically 
hides the popup that was visible.

In case of MOUSE_WHEEL, combo box over which mouse wheel is rotated 
should close the popup of another combo box that opened the popup; and 
it should do nothing if its own popup is open. Moving this logic into 
JComboBox MouseWheelListener seems too complicated.


As for user-installed MouseWheelListener on JComboBox, of course 
mouseWheelMoved is called but MouseWheelEvent is already marked 
consumed. It might have a negative effect on user code if they check 
isConsumed() flag. If the event is not consumed, the popup will be closed.

Regards,
Alexey

On 06.05.2015 22:28, Sergey Bylokhov wrote:
> Hi, Alexey.
> The changes in the BasicPopupMenuUI does not look clear, I am not sure 
> but probably it will be better to implement it in the same way as for 
> MOUSE_PRESSED(via UIManager property)? It will add an additional 
> configuration possibility.
> Can you also confirm that the case when the user install mouse wheel 
> listener to the JComboBox still works.
>
> On 06.05.15 16:30, Alexey Ivanov wrote:
>> Hello Swing team,
>>
>> Could you please review the fix:
>>     bug: https://bugs.openjdk.java.net/browse/JDK-8033069
>>     webrev: http://cr.openjdk.java.net/~aivanov/8033069/jdk9/webrev.00/
>>
>> Description:
>> If you rotate mouse wheel when combo box popup is open, the popup 
>> gets closed.
>>
>> The fix is to always consume MOUSE_WHEEL event.
>>
>> There are two regression tests for the cases where popup has vertical 
>> scroll bar and does not have scroll bar.
>>
>> Thanks,
>> Alexey
>
>
> -- 
> Best regards, Sergey.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/swing-dev/attachments/20150507/70aeb8df/attachment.html>

From alexander.zvegintsev at oracle.com  Thu May  7 12:48:15 2015
From: alexander.zvegintsev at oracle.com (Alexander Zvegintsev)
Date: Thu, 07 May 2015 15:48:15 +0300
Subject: <Swing Dev> [9] Review Request: 5036022: JSpinner does not
 reflect new font on subsequent calls to setFont
In-Reply-To: <554B509C.1000909@oracle.com>
References: <554B509C.1000909@oracle.com>
Message-ID: <554B5F0F.8030807@oracle.com>

looks fine to me.

Thanks,

Alexander.

On 05/07/2015 02:46 PM, Sergey Bylokhov wrote:
> Hello.
> Please review the fix for jdk9.
>
> All our UI components use a UIResource to store some l&f related data, 
> such as fonts, colors and so on. This makes the logic of changing one 
> l&f to another one simple. Because we can understand the difference, 
> between the resources, which were set by the l&f, and  resources, 
> which were set by the user. If resource was set by the l&f, it can be 
> replaced by the new l&f or by another UI component, but resources 
> which were set by the user should be preserved.
>
> This rule is not fully followed in the Spinner**UI. It can contains 
> two elements: spinner and textfield in the editor. If the user sets 
> the font of the spinner UI component, it automatically update the font 
> of the textfield if it was not set by the user directly. But it 
> doesn't wrap this font into UIResource and later this causes 
> assumption that this font was changed by the user directly, and this 
> is wrong.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-5036022
> Webrev can be found at: 
> http://cr.openjdk.java.net/~serb/5036022/webrev.00
>



From alexander.zvegintsev at oracle.com  Thu May  7 13:26:57 2015
From: alexander.zvegintsev at oracle.com (Alexander Zvegintsev)
Date: Thu, 07 May 2015 16:26:57 +0300
Subject: <Swing Dev> [9] Review Request: 8078149 [macosx] The text of
 the TextArea is not wrapped at word boundaries
In-Reply-To: <554A66BE.2020206@oracle.com>
References: <554A66BE.2020206@oracle.com>
Message-ID: <554B6821.2040906@oracle.com>

the fix looks fine to me.

Thanks,

Alexander.

On 05/06/2015 10:08 PM, Sergey Bylokhov wrote:
> Hello.
> Please review the fix for a small fix.
> This is the problem in lwawt, which was fixed in xawt already:
>
> https://bugs.openjdk.java.net/browse/JDK-4992455
>
> " 1. About line wrapping property.
>
>   "JTextArea has a bound property for line wrapping that controls
>   whether or not it will wrap lines. By default, the line
>   wrapping property is set to false (not wrapped)."
>
>   2. About wrapping style property.
>
>   "If set to true the lines will be wrapped at word boundaries
>   (whitespace) if they are too long to fit within the allocated
>   width. If set to false, the lines will be wrapped at character
>   boundaries. By default this property is false."
>
> Since we use JTextArea in XAWT as the TextArea component we
> should use the following code if we want to wrap lines at word
> boundaries:
>
>   jtext.setLineWrap(true);
>   jtext.setWrapStyleWord(true);
> "
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8078149
> Webrev can be found at: 
> http://cr.openjdk.java.net/~serb/8078149/webrev.00
>



From vivi.an at oracle.com  Thu May  7 16:57:16 2015
From: vivi.an at oracle.com (Vivi An)
Date: Thu, 07 May 2015 09:57:16 -0700
Subject: <Swing Dev> [9] Review Request for 8075609:
 java.lang.IllegalArgumentException: aContainer is not a focus cycle root of
 aComponent
In-Reply-To: <55415965.6090209@oracle.com>
References: <55415965.6090209@oracle.com>
Message-ID: <554B996C.4020708@oracle.com>

Hello, anyone can help to get this item reviewed?

Thanks again!

Vivi

On 4/29/2015 3:21 PM, Vivi An wrote:
> Hello,
>
> Could you please review below bug fix?
>
> Change made using focusCycleRoot to get root container of the 
> component's focus traversal cycle, instead of using getWindowAncestor 
> to find root window, since the focus root is not always a window. Test 
> case provided too.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8075609
> Webrev: http://cr.openjdk.java.net/~van/8075609/webrev.00/
>
> Thank you
>
> Regards,
>
> ~ Vivi
>
>
>
>
>
>
>



From jason_mehrens at hotmail.com  Thu May  7 20:08:30 2015
From: jason_mehrens at hotmail.com (Jason Mehrens)
Date: Thu, 7 May 2015 15:08:30 -0500
Subject: <Swing Dev> JDK-8023043 : Clipboard.getAvailableDataFlavors:
 Comparison method violates contract
In-Reply-To: <BLU181-W910C67A3429B0D8FE4871A83EE0@phx.gbl>
References: <BLU181-W644D97C980BBBF88F9D9E383EF0@phx.gbl>, ,
	<5537AAD2.2040107@oracle.com>,
	<BLU181-W910C67A3429B0D8FE4871A83EE0@phx.gbl>
Message-ID: <BLU181-W46E780485FEECAAFC3CDF983DF0@phx.gbl>

Anton,


I finally caught this error in production.  I patched our code to launch a JVM (with mergesort) using your test case, modifed to output the JVM version followed by the output when this error occurs.  The output is as follows:



==============================================================================

1.7.0_80-b15

java.awt.datatransfer.DataFlavor[mimetype=application/x-java-serialized-object;representationclass=java.lang.String]

java.awt.datatransfer.DataFlavor[mimetype=application/x-java-text-encoding;representationclass=[B]

java.awt.datatransfer.DataFlavor[mimetype=text/plain;representationclass=java.io.Reader]

java.awt.datatransfer.DataFlavor[mimetype=text/plain;representationclass=java.lang.String]

java.awt.datatransfer.DataFlavor[mimetype=text/plain;representationclass=java.nio.CharBuffer]

java.awt.datatransfer.DataFlavor[mimetype=text/plain;representationclass=[C]

java.awt.datatransfer.DataFlavor[mimetype=text/plain;representationclass=java.io.InputStream;charset=unicode]

java.awt.datatransfer.DataFlavor[mimetype=text/plain;representationclass=java.nio.ByteBuffer;charset=UTF-16]

java.awt.datatransfer.DataFlavor[mimetype=text/plain;representationclass=[B;charset=UTF-16]

java.awt.datatransfer.DataFlavor[mimetype=text/plain;representationclass=java.io.InputStream;charset=UTF-8]

java.awt.datatransfer.DataFlavor[mimetype=text/plain;representationclass=java.nio.ByteBuffer;charset=UTF-8]

java.awt.datatransfer.DataFlavor[mimetype=text/plain;representationclass=[B;charset=UTF-8]

java.awt.datatransfer.DataFlavor[mimetype=text/plain;representationclass=java.io.InputStream;charset=UTF-16BE]

java.awt.datatransfer.DataFlavor[mimetype=text/plain;representationclass=java.nio.ByteBuffer;charset=UTF-16BE]

java.awt.datatransfer.DataFlavor[mimetype=text/plain;representationclass=[B;charset=UTF-16BE]

java.awt.datatransfer.DataFlavor[mimetype=text/plain;representationclass=java.io.InputStream;charset=UTF-16LE]

java.awt.datatransfer.DataFlavor[mimetype=text/plain;representationclass=java.nio.ByteBuffer;charset=UTF-16LE]

java.awt.datatransfer.DataFlavor[mimetype=text/plain;representationclass=[B;charset=UTF-16LE]

java.awt.datatransfer.DataFlavor[mimetype=text/plain;representationclass=java.io.InputStream;charset=ISO-8859-1]

java.awt.datatransfer.DataFlavor[mimetype=text/plain;representationclass=java.nio.ByteBuffer;charset=ISO-8859-1]

java.awt.datatransfer.DataFlavor[mimetype=text/plain;representationclass=[B;charset=ISO-8859-1]

java.awt.datatransfer.DataFlavor[mimetype=text/plain;representationclass=java.io.InputStream;charset=windows-1252]

java.awt.datatransfer.DataFlavor[mimetype=text/plain;representationclass=java.nio.ByteBuffer;charset=windows-1252]

java.awt.datatransfer.DataFlavor[mimetype=text/plain;representationclass=[B;charset=windows-1252]

java.awt.datatransfer.DataFlavor[mimetype=text/plain;representationclass=java.io.InputStream;charset=US-ASCII]

java.awt.datatransfer.DataFlavor[mimetype=text/plain;representationclass=java.nio.ByteBuffer;charset=US-ASCII]

java.awt.datatransfer.DataFlavor[mimetype=text/plain;representationclass=[B;charset=US-ASCII]

 ==================================================================================



Jason



----------------------------------------
> From: jason_mehrens at hotmail.com
> To: anton.nashatyrev at oracle.com
> Date: Wed, 22 Apr 2015 14:59:26 -0500
> CC: swing-dev at openjdk.java.net
> Subject: Re: <Swing Dev> JDK-8023043 : Clipboard.getAvailableDataFlavors: Comparison method violates contract
>
> Anton,
>
>
> Thanks for looking at this. Sorry I don't have a test case to give you yet. For sure the machines are using JDK7u80 that are reproducing the error. The common case is that the user is copying text from an email client and then pasting it in to a JTextField. So I imagine that the content type of email is a factor in producing this issue.
>
>
> What I'll do is convert your ClipboardDump into the codebase so that I can just log that information as soon as it happens. We'll see how long it takes to catch this fish.
>
>
> Thanks,
>
>
> Jason
>
>
>
>
>
> ----------------------------------------
>> Date: Wed, 22 Apr 2015 17:06:10 +0300
>> From: anton.nashatyrev at oracle.com
>> To: jason_mehrens at hotmail.com
>> CC: swing-dev at openjdk.java.net
>> Subject: Re: <Swing Dev> JDK-8023043 : Clipboard.getAvailableDataFlavors: Comparison method violates contract
>>
>> Hi Jason,
>>
>> I've commented in the bug report:
>>
>> Couldn't reproduce locally.
>> Please next time the problem is reproduced on your side, run the small
>> program below and attach its output to this bug (or file a new one).
>> Make sure NOT using the system clipboard from the moment of exception
>> till running the test program.
>>
>> import java.awt.*;
>> import java.awt.datatransfer.DataFlavor;
>>
>> public class ClipboardDump {
>> public static void main(String[] args) {
>> System.setProperty("java.util.Arrays.useLegacyMergeSort", "true");
>>
>> DataFlavor[] dataFlavors =
>> Toolkit.getDefaultToolkit().getSystemClipboard().
>> getAvailableDataFlavors();
>>
>> for (DataFlavor df: dataFlavors) {
>> System.out.println(df);
>> }
>> }
>> }
>>
>> Please also make sure you are running 7u80 (not an earlier version)
>> since the Comparator fix was integrated to 7u80
>>
>> Thanks!
>> Anton.
>> On 21.04.2015 17:29, Jason Mehrens wrote:
>>> Hello Swing-Dev,
>>>
>>>
>>>
>>> Recently we have updated to JDK7u80 and have noticed a pattern of users generating the following error:
>>>
>>>
>>>
>>> ==================
>>>
>>> java.lang.IllegalArgumentException: Comparison method violates its general contract!
>>>
>>> at java.util.TimSort.mergeHi(Unknown Source)
>>>
>>> at java.util.TimSort.mergeAt(Unknown Source)
>>>
>>> at java.util.TimSort.mergeCollapse(Unknown Source)
>>>
>>> at java.util.TimSort.sort(Unknown Source)
>>>
>>> at java.util.TimSort.sort(Unknown Source)
>>>
>>> at java.util.Arrays.sort(Unknown Source)
>>>
>>> at sun.awt.datatransfer.DataTransferer.setToSortedDataFlavorArray(Unknown Source)
>>>
>>> at sun.awt.datatransfer.ClipboardTransferable.<init>(Unknown Source)
>>>
>>> at sun.awt.datatransfer.SunClipboard.getContents(Unknown Source)
>>>
>>> at javax.swing.TransferHandler$TransferAction.actionPerformedImpl(Unknown Source)
>>>
>>> at javax.swing.TransferHandler$TransferAction.access$700(Unknown Source)
>>>
>>> at javax.swing.TransferHandler$TransferAction$1.run(Unknown Source)
>>>
>>> at javax.swing.TransferHandler$TransferAction$1.run(Unknown Source)
>>>
>>> at java.security.AccessController.doPrivileged(Native Method)
>>>
>>> at java.security.ProtectionDomain$1.doIntersectionPrivilege(Unknown Source)
>>>
>>> at java.security.ProtectionDomain$1.doIntersectionPrivilege(Unknown Source)
>>>
>>> at javax.swing.TransferHandler$TransferAction$2.run(Unknown Source)
>>>
>>> at javax.swing.TransferHandler$TransferAction$2.run(Unknown Source)
>>>
>>> at java.security.AccessController.doPrivileged(Native Method)
>>>
>>> at java.security.ProtectionDomain$1.doIntersectionPrivilege(Unknown Source)
>>>
>>> at javax.swing.TransferHandler$TransferAction.actionPerformed(Unknown Source)
>>>
>>> at javax.swing.text.JTextComponent.invokeAction(Unknown Source)
>>>
>>> at javax.swing.text.JTextComponent.paste(Unknown Source)
>>>
>>> at javax.swing.text.DefaultEditorKit$PasteAction.actionPerformed(Unknown Source)
>>>
>>> at javax.swing.SwingUtilities.notifyAction(Unknown Source)
>>>
>>> at javax.swing.JComponent.processKeyBinding(Unknown Source)
>>>
>>> at javax.swing.JComponent.processKeyBindings(Unknown Source)
>>>
>>> at javax.swing.JComponent.processKeyEvent(Unknown Source)
>>>
>>> at java.awt.Component.processEvent(Unknown Source)
>>>
>>> at java.awt.Container.processEvent(Unknown Source)
>>>
>>> at java.awt.Component.dispatchEventImpl(Unknown Source)
>>>
>>> at java.awt.Container.dispatchEventImpl(Unknown Source)
>>>
>>> at java.awt.Component.dispatchEvent(Unknown Source)
>>>
>>> at java.awt.KeyboardFocusManager.redispatchEvent(Unknown Source)
>>>
>>> at java.awt.DefaultKeyboardFocusManager.dispatchKeyEvent(Unknown Source)
>>>
>>> at java.awt.DefaultKeyboardFocusManager.preDispatchKeyEvent(Unknown Source)
>>>
>>> at java.awt.DefaultKeyboardFocusManager.typeAheadAssertions(Unknown Source)
>>>
>>> at java.awt.DefaultKeyboardFocusManager.dispatchEvent(Unknown Source)
>>>
>>> at java.awt.Component.dispatchEventImpl(Unknown Source)
>>>
>>> at java.awt.Container.dispatchEventImpl(Unknown Source)
>>>
>>> at java.awt.Window.dispatchEventImpl(Unknown Source)
>>>
>>> at java.awt.Component.dispatchEvent(Unknown Source)
>>>
>>> at java.awt.EventQueue.dispatchEventImpl(Unknown Source)
>>>
>>> at java.awt.EventQueue.access$300(Unknown Source)
>>>
>>> at java.awt.EventQueue$3.run(Unknown Source)
>>>
>>> at java.awt.EventQueue$3.run(Unknown Source)
>>>
>>> at java.security.AccessController.doPrivileged(Native Method)
>>>
>>> at java.security.ProtectionDomain$1.doIntersectionPrivilege(Unknown Source)
>>>
>>> at java.security.ProtectionDomain$1.doIntersectionPrivilege(Unknown Source)
>>>
>>> at java.awt.EventQueue$4.run(Unknown Source)
>>>
>>> at java.awt.EventQueue$4.run(Unknown Source)
>>>
>>> at java.security.AccessController.doPrivileged(Native Method)
>>>
>>> at java.security.ProtectionDomain$1.doIntersectionPrivilege(Unknown Source)
>>>
>>> at java.awt.EventQueue.dispatchEvent(Unknown Source)
>>>
>>> at java.awt.EventDispatchThread.pumpOneEventForFilters(Unknown Source)
>>>
>>> at java.awt.EventDispatchThread.pumpEventsForFilter(Unknown Source)
>>>
>>> at java.awt.EventDispatchThread.pumpEventsForHierarchy(Unknown Source)
>>>
>>> at java.awt.EventDispatchThread.pumpEvents(Unknown Source)
>>>
>>> at java.awt.EventDispatchThread.pumpEvents(Unknown Source)
>>>
>>> at java.awt.EventDispatchThread.run(Unknown Source)
>>>
>>> =============
>>>
>>>
>>>
>>> When I check the issue tracker http://bugs.java.com/view_bug.do?bug_id=8023043 shows as fixed in 7u60. Did this get fixed in 7u60 through 7u80? The stacktrace is a little different from that bug so should I file this as a new issue?
>>>
>>>
>>>
>>> Thanks,
>>>
>>>
>>>
>>> Jason
>>>
>> 		 	   		  

From semyon.sadetsky at oracle.com  Fri May  8 08:47:54 2015
From: semyon.sadetsky at oracle.com (Semyon Sadetsky)
Date: Fri, 08 May 2015 11:47:54 +0300
Subject: <Swing Dev> [9] Review Request for 8079640: GroupLayout incorrect
 layout with large JTextArea
Message-ID: <554C783A.4080606@oracle.com>

Hello,

Please review fix for JDK9:

bug: https://bugs.openjdk.java.net/browse/JDK-8079640
webrev: http://cr.openjdk.java.net/~ssadetsky/8079640/webrev.00/

*THE ROOT CAUSE
Component minimum size is limited to Short.MAX_VALUE in GroupLayout.
JDK turtorial 
https://docs.oracle.com/javase/tutorial/uiswing/layout/group.html tells 
that Short.MAX_VALUE is treated as infinite.
But I did not find any reasons in JDK specs why a bigger number cannot 
be used.

*SOLUTION
Remove the limitation

*TESTING
Test is added to cover the large component scenario.
Existing GroupLayout tests are passed.

--Semyon



From semyon.sadetsky at oracle.com  Fri May  8 08:51:32 2015
From: semyon.sadetsky at oracle.com (Semyon Sadetsky)
Date: Fri, 08 May 2015 11:51:32 +0300
Subject: <Swing Dev> [9] Review Request for 6260348: GTK+ L&F
 JTextComponent not respecting desktop caret blink rate
In-Reply-To: <553E4836.3040408@oracle.com>
References: <5539004F.9060705@oracle.com> <553E4836.3040408@oracle.com>
Message-ID: <554C7914.7040802@oracle.com>

Hi Alexander,

gboolean and gint are equivalent.

--Semyon

On 4/27/2015 5:31 PM, Alexander Scherbatiy wrote:
> On 4/23/2015 5:23 PM, Semyon Sadetsky wrote:
>> Hello,
>>
>> Please review fix for JDK9:
>>
>> web rev: http://cr.openjdk.java.net/~ssadetsky/6260348/webrev.00/
>> bug: https://bugs.openjdk.java.net/browse/JDK-6260348
>
> gtk2_interface.c
> 2510     gint intval = NULL;
> 2511     (*fp_g_object_get)(settings, key, &intval, NULL);
> 2512     return create_Boolean(env, intval);
>
> Probably the type of the value should be gboolean.
>
>  Thanks,
>  Alexandr.
>
>>
>> ***ROOT CAUSE
>> GTK L&F never took care about native GTK cursor blink settings.
>>
>> ***SOLUTION
>> Implement this feature.
>>
>> ***TESTING
>> Two test scenarios added. 1st sets GTK cursor blink enabled and blink 
>> time 200 ms. 2nd disables cursor blinking. Then Java text caret is 
>> checked to respect these settings.
>>
>> --Semyon
>>
>>
>



From semyon.sadetsky at oracle.com  Fri May  8 09:13:40 2015
From: semyon.sadetsky at oracle.com (Semyon Sadetsky)
Date: Fri, 08 May 2015 12:13:40 +0300
Subject: <Swing Dev> [9] Review Request for 7172652: With JDK 1.7 text
 field does not obtain focus when using mnemonic Alt/Key combin
In-Reply-To: <553F8B9E.1090904@oracle.com>
References: <55351307.4020504@oracle.com> <553F8B9E.1090904@oracle.com>
Message-ID: <554C7E44.1050304@oracle.com>

updated: http://cr.openjdk.java.net/~ssadetsky/7172652/webrev.01/


On 4/28/2015 4:31 PM, Alexander Scherbatiy wrote:
>
>   Is it possible to make code shorter by adding methods like:
>   putOnRelease(InputMap inputMap, int keyCode, int modifiers)
>   removeOnRelease(InputMap inputMap, int keyCode, int modifiers)
>
>   Thanks,
>   Alexandr.
>
> On 4/20/2015 5:53 PM, Semyon Sadetsky wrote:
>> Hello,
>>
>> please review a fix for JDK9:
>>
>> webrev: http://cr.openjdk.java.net/~ssadetsky/7172652/webrev.00/
>> bug: https://bugs.openjdk.java.net/browse/JDK-7172652
>>
>> ***ROOT CAUSE
>> This is a bug in Label UI's key release event processing routine for 
>> key mnemonics: only one release event is captured instead of two (Alt 
>> release and the mnemonic key release). The Alt release event goes up 
>> on hierarchy and is captured by the parent internal frame's menu bar 
>> for which Alt key release means selection change event under the 
>> Windows system LnF.
>>
>> ***SOLUTION
>> Change key release event handling logic to capture events from both 
>> Alt modifier and the key. The logic takes into account that when the 
>> first release key event come it transfers focus back to the field so 
>> the second key release event should be captured from any window 
>> component.
>>
>> ***TESTING
>> A simple scenario is written to exclusively cover the situation.
>>
>> --Semyon
>>
>



From anton.tarasov at oracle.com  Fri May  8 09:52:25 2015
From: anton.tarasov at oracle.com (Anton V. Tarasov)
Date: Fri, 08 May 2015 12:52:25 +0300
Subject: <Swing Dev> [9] Review Request for 8075609:
 java.lang.IllegalArgumentException: aContainer is not a focus cycle root of
 aComponent
In-Reply-To: <55415965.6090209@oracle.com>
References: <55415965.6090209@oracle.com>
Message-ID: <554C8759.6040102@oracle.com>

Hi Vivi,

Looks fine to me.

Regards,
Anton.

On 30.04.2015 1:21, Vivi An wrote:
> Hello,
>
> Could you please review below bug fix?
>
> Change made using focusCycleRoot to get root container of the component's focus traversal cycle, 
> instead of using getWindowAncestor to find root window, since the focus root is not always a 
> window. Test case provided too.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8075609
> Webrev: http://cr.openjdk.java.net/~van/8075609/webrev.00/
>
> Thank you
>
> Regards,
>
> ~ Vivi
>
>
>
>
>
>
>



From alexandr.scherbatiy at oracle.com  Fri May  8 11:57:09 2015
From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy)
Date: Fri, 08 May 2015 14:57:09 +0300
Subject: <Swing Dev> [9] Review Request: 8078149 [macosx] The text of
 the TextArea is not wrapped at word boundaries
In-Reply-To: <554B6821.2040906@oracle.com>
References: <554A66BE.2020206@oracle.com> <554B6821.2040906@oracle.com>
Message-ID: <554CA495.5030007@oracle.com>


  The fix looks good to me.

  Thanks,
  Alexandr.

On 5/7/2015 4:26 PM, Alexander Zvegintsev wrote:
> the fix looks fine to me.
>
> Thanks,
>
> Alexander.
>
> On 05/06/2015 10:08 PM, Sergey Bylokhov wrote:
>> Hello.
>> Please review the fix for a small fix.
>> This is the problem in lwawt, which was fixed in xawt already:
>>
>> https://bugs.openjdk.java.net/browse/JDK-4992455
>>
>> " 1. About line wrapping property.
>>
>>   "JTextArea has a bound property for line wrapping that controls
>>   whether or not it will wrap lines. By default, the line
>>   wrapping property is set to false (not wrapped)."
>>
>>   2. About wrapping style property.
>>
>>   "If set to true the lines will be wrapped at word boundaries
>>   (whitespace) if they are too long to fit within the allocated
>>   width. If set to false, the lines will be wrapped at character
>>   boundaries. By default this property is false."
>>
>> Since we use JTextArea in XAWT as the TextArea component we
>> should use the following code if we want to wrap lines at word
>> boundaries:
>>
>>   jtext.setLineWrap(true);
>>   jtext.setWrapStyleWord(true);
>> "
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8078149
>> Webrev can be found at: 
>> http://cr.openjdk.java.net/~serb/8078149/webrev.00
>>
>



From alexandr.scherbatiy at oracle.com  Fri May  8 11:59:31 2015
From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy)
Date: Fri, 08 May 2015 14:59:31 +0300
Subject: <Swing Dev> [9] Review Request: 8013820 JavaDoc for JSpinner
	contains errors
In-Reply-To: <554B555D.5070101@oracle.com>
References: <554A710D.9070101@oracle.com> <554B555D.5070101@oracle.com>
Message-ID: <554CA523.9050405@oracle.com>


   The fix looks good to me.

   Thanks,
   Alexandr.

On 5/7/2015 3:06 PM, Alexander Zvegintsev wrote:
> looks fine.
>
> Thanks,
>
> Alexander.
>
> On 05/06/2015 10:52 PM, Sergey Bylokhov wrote:
>> Hello.
>> Please review the fix for a typo in jdk9.
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8013820
>> Webrev can be found at: 
>> http://cr.openjdk.java.net/~serb/8013820/webrev.00
>>
>



From alexandr.scherbatiy at oracle.com  Fri May  8 12:14:45 2015
From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy)
Date: Fri, 08 May 2015 15:14:45 +0300
Subject: <Swing Dev> [9] Review Request: 5036022: JSpinner does not
 reflect new font on subsequent calls to setFont
In-Reply-To: <554B5F0F.8030807@oracle.com>
References: <554B509C.1000909@oracle.com> <554B5F0F.8030807@oracle.com>
Message-ID: <554CA8B5.8060400@oracle.com>


  The fix looks good to me.

   Thanks,
   Alexandr.

On 5/7/2015 3:48 PM, Alexander Zvegintsev wrote:
> looks fine to me.
>
> Thanks,
>
> Alexander.
>
> On 05/07/2015 02:46 PM, Sergey Bylokhov wrote:
>> Hello.
>> Please review the fix for jdk9.
>>
>> All our UI components use a UIResource to store some l&f related 
>> data, such as fonts, colors and so on. This makes the logic of 
>> changing one l&f to another one simple. Because we can understand the 
>> difference, between the resources, which were set by the l&f, and  
>> resources, which were set by the user. If resource was set by the 
>> l&f, it can be replaced by the new l&f or by another UI component, 
>> but resources which were set by the user should be preserved.
>>
>> This rule is not fully followed in the Spinner**UI. It can contains 
>> two elements: spinner and textfield in the editor. If the user sets 
>> the font of the spinner UI component, it automatically update the 
>> font of the textfield if it was not set by the user directly. But it 
>> doesn't wrap this font into UIResource and later this causes 
>> assumption that this font was changed by the user directly, and this 
>> is wrong.
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-5036022
>> Webrev can be found at: 
>> http://cr.openjdk.java.net/~serb/5036022/webrev.00
>>
>



From alexandr.scherbatiy at oracle.com  Fri May  8 12:38:06 2015
From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy)
Date: Fri, 08 May 2015 15:38:06 +0300
Subject: <Swing Dev> JDK-8023043 : Clipboard.getAvailableDataFlavors:
 Comparison method violates contract
In-Reply-To: <BLU181-W46E780485FEECAAFC3CDF983DF0@phx.gbl>
References: <BLU181-W644D97C980BBBF88F9D9E383EF0@phx.gbl>, ,
	<5537AAD2.2040107@oracle.com>,
	<BLU181-W910C67A3429B0D8FE4871A83EE0@phx.gbl>
	<BLU181-W46E780485FEECAAFC3CDF983DF0@phx.gbl>
Message-ID: <554CAE2E.7080308@oracle.com>


   Hi Jason,

  Please, file it as a new issue in http://bugreport.java.com/bugreport

   Thanks,
   Alexandr.

On 5/7/2015 11:08 PM, Jason Mehrens wrote:
> Anton,
>
>
> I finally caught this error in production.  I patched our code to launch a JVM (with mergesort) using your test case, modifed to output the JVM version followed by the output when this error occurs.  The output is as follows:
>
>
>
> ==============================================================================
>
> 1.7.0_80-b15
>
> java.awt.datatransfer.DataFlavor[mimetype=application/x-java-serialized-object;representationclass=java.lang.String]
>
> java.awt.datatransfer.DataFlavor[mimetype=application/x-java-text-encoding;representationclass=[B]
>
> java.awt.datatransfer.DataFlavor[mimetype=text/plain;representationclass=java.io.Reader]
>
> java.awt.datatransfer.DataFlavor[mimetype=text/plain;representationclass=java.lang.String]
>
> java.awt.datatransfer.DataFlavor[mimetype=text/plain;representationclass=java.nio.CharBuffer]
>
> java.awt.datatransfer.DataFlavor[mimetype=text/plain;representationclass=[C]
>
> java.awt.datatransfer.DataFlavor[mimetype=text/plain;representationclass=java.io.InputStream;charset=unicode]
>
> java.awt.datatransfer.DataFlavor[mimetype=text/plain;representationclass=java.nio.ByteBuffer;charset=UTF-16]
>
> java.awt.datatransfer.DataFlavor[mimetype=text/plain;representationclass=[B;charset=UTF-16]
>
> java.awt.datatransfer.DataFlavor[mimetype=text/plain;representationclass=java.io.InputStream;charset=UTF-8]
>
> java.awt.datatransfer.DataFlavor[mimetype=text/plain;representationclass=java.nio.ByteBuffer;charset=UTF-8]
>
> java.awt.datatransfer.DataFlavor[mimetype=text/plain;representationclass=[B;charset=UTF-8]
>
> java.awt.datatransfer.DataFlavor[mimetype=text/plain;representationclass=java.io.InputStream;charset=UTF-16BE]
>
> java.awt.datatransfer.DataFlavor[mimetype=text/plain;representationclass=java.nio.ByteBuffer;charset=UTF-16BE]
>
> java.awt.datatransfer.DataFlavor[mimetype=text/plain;representationclass=[B;charset=UTF-16BE]
>
> java.awt.datatransfer.DataFlavor[mimetype=text/plain;representationclass=java.io.InputStream;charset=UTF-16LE]
>
> java.awt.datatransfer.DataFlavor[mimetype=text/plain;representationclass=java.nio.ByteBuffer;charset=UTF-16LE]
>
> java.awt.datatransfer.DataFlavor[mimetype=text/plain;representationclass=[B;charset=UTF-16LE]
>
> java.awt.datatransfer.DataFlavor[mimetype=text/plain;representationclass=java.io.InputStream;charset=ISO-8859-1]
>
> java.awt.datatransfer.DataFlavor[mimetype=text/plain;representationclass=java.nio.ByteBuffer;charset=ISO-8859-1]
>
> java.awt.datatransfer.DataFlavor[mimetype=text/plain;representationclass=[B;charset=ISO-8859-1]
>
> java.awt.datatransfer.DataFlavor[mimetype=text/plain;representationclass=java.io.InputStream;charset=windows-1252]
>
> java.awt.datatransfer.DataFlavor[mimetype=text/plain;representationclass=java.nio.ByteBuffer;charset=windows-1252]
>
> java.awt.datatransfer.DataFlavor[mimetype=text/plain;representationclass=[B;charset=windows-1252]
>
> java.awt.datatransfer.DataFlavor[mimetype=text/plain;representationclass=java.io.InputStream;charset=US-ASCII]
>
> java.awt.datatransfer.DataFlavor[mimetype=text/plain;representationclass=java.nio.ByteBuffer;charset=US-ASCII]
>
> java.awt.datatransfer.DataFlavor[mimetype=text/plain;representationclass=[B;charset=US-ASCII]
>
>   ==================================================================================
>
>
>
> Jason
>
>
>
> ----------------------------------------
>> From: jason_mehrens at hotmail.com
>> To: anton.nashatyrev at oracle.com
>> Date: Wed, 22 Apr 2015 14:59:26 -0500
>> CC: swing-dev at openjdk.java.net
>> Subject: Re: <Swing Dev> JDK-8023043 : Clipboard.getAvailableDataFlavors: Comparison method violates contract
>>
>> Anton,
>>
>>
>> Thanks for looking at this. Sorry I don't have a test case to give you yet. For sure the machines are using JDK7u80 that are reproducing the error. The common case is that the user is copying text from an email client and then pasting it in to a JTextField. So I imagine that the content type of email is a factor in producing this issue.
>>
>>
>> What I'll do is convert your ClipboardDump into the codebase so that I can just log that information as soon as it happens. We'll see how long it takes to catch this fish.
>>
>>
>> Thanks,
>>
>>
>> Jason
>>
>>
>>
>>
>>
>> ----------------------------------------
>>> Date: Wed, 22 Apr 2015 17:06:10 +0300
>>> From: anton.nashatyrev at oracle.com
>>> To: jason_mehrens at hotmail.com
>>> CC: swing-dev at openjdk.java.net
>>> Subject: Re: <Swing Dev> JDK-8023043 : Clipboard.getAvailableDataFlavors: Comparison method violates contract
>>>
>>> Hi Jason,
>>>
>>> I've commented in the bug report:
>>>
>>> Couldn't reproduce locally.
>>> Please next time the problem is reproduced on your side, run the small
>>> program below and attach its output to this bug (or file a new one).
>>> Make sure NOT using the system clipboard from the moment of exception
>>> till running the test program.
>>>
>>> import java.awt.*;
>>> import java.awt.datatransfer.DataFlavor;
>>>
>>> public class ClipboardDump {
>>> public static void main(String[] args) {
>>> System.setProperty("java.util.Arrays.useLegacyMergeSort", "true");
>>>
>>> DataFlavor[] dataFlavors =
>>> Toolkit.getDefaultToolkit().getSystemClipboard().
>>> getAvailableDataFlavors();
>>>
>>> for (DataFlavor df: dataFlavors) {
>>> System.out.println(df);
>>> }
>>> }
>>> }
>>>
>>> Please also make sure you are running 7u80 (not an earlier version)
>>> since the Comparator fix was integrated to 7u80
>>>
>>> Thanks!
>>> Anton.
>>> On 21.04.2015 17:29, Jason Mehrens wrote:
>>>> Hello Swing-Dev,
>>>>
>>>>
>>>>
>>>> Recently we have updated to JDK7u80 and have noticed a pattern of users generating the following error:
>>>>
>>>>
>>>>
>>>> ==================
>>>>
>>>> java.lang.IllegalArgumentException: Comparison method violates its general contract!
>>>>
>>>> at java.util.TimSort.mergeHi(Unknown Source)
>>>>
>>>> at java.util.TimSort.mergeAt(Unknown Source)
>>>>
>>>> at java.util.TimSort.mergeCollapse(Unknown Source)
>>>>
>>>> at java.util.TimSort.sort(Unknown Source)
>>>>
>>>> at java.util.TimSort.sort(Unknown Source)
>>>>
>>>> at java.util.Arrays.sort(Unknown Source)
>>>>
>>>> at sun.awt.datatransfer.DataTransferer.setToSortedDataFlavorArray(Unknown Source)
>>>>
>>>> at sun.awt.datatransfer.ClipboardTransferable.<init>(Unknown Source)
>>>>
>>>> at sun.awt.datatransfer.SunClipboard.getContents(Unknown Source)
>>>>
>>>> at javax.swing.TransferHandler$TransferAction.actionPerformedImpl(Unknown Source)
>>>>
>>>> at javax.swing.TransferHandler$TransferAction.access$700(Unknown Source)
>>>>
>>>> at javax.swing.TransferHandler$TransferAction$1.run(Unknown Source)
>>>>
>>>> at javax.swing.TransferHandler$TransferAction$1.run(Unknown Source)
>>>>
>>>> at java.security.AccessController.doPrivileged(Native Method)
>>>>
>>>> at java.security.ProtectionDomain$1.doIntersectionPrivilege(Unknown Source)
>>>>
>>>> at java.security.ProtectionDomain$1.doIntersectionPrivilege(Unknown Source)
>>>>
>>>> at javax.swing.TransferHandler$TransferAction$2.run(Unknown Source)
>>>>
>>>> at javax.swing.TransferHandler$TransferAction$2.run(Unknown Source)
>>>>
>>>> at java.security.AccessController.doPrivileged(Native Method)
>>>>
>>>> at java.security.ProtectionDomain$1.doIntersectionPrivilege(Unknown Source)
>>>>
>>>> at javax.swing.TransferHandler$TransferAction.actionPerformed(Unknown Source)
>>>>
>>>> at javax.swing.text.JTextComponent.invokeAction(Unknown Source)
>>>>
>>>> at javax.swing.text.JTextComponent.paste(Unknown Source)
>>>>
>>>> at javax.swing.text.DefaultEditorKit$PasteAction.actionPerformed(Unknown Source)
>>>>
>>>> at javax.swing.SwingUtilities.notifyAction(Unknown Source)
>>>>
>>>> at javax.swing.JComponent.processKeyBinding(Unknown Source)
>>>>
>>>> at javax.swing.JComponent.processKeyBindings(Unknown Source)
>>>>
>>>> at javax.swing.JComponent.processKeyEvent(Unknown Source)
>>>>
>>>> at java.awt.Component.processEvent(Unknown Source)
>>>>
>>>> at java.awt.Container.processEvent(Unknown Source)
>>>>
>>>> at java.awt.Component.dispatchEventImpl(Unknown Source)
>>>>
>>>> at java.awt.Container.dispatchEventImpl(Unknown Source)
>>>>
>>>> at java.awt.Component.dispatchEvent(Unknown Source)
>>>>
>>>> at java.awt.KeyboardFocusManager.redispatchEvent(Unknown Source)
>>>>
>>>> at java.awt.DefaultKeyboardFocusManager.dispatchKeyEvent(Unknown Source)
>>>>
>>>> at java.awt.DefaultKeyboardFocusManager.preDispatchKeyEvent(Unknown Source)
>>>>
>>>> at java.awt.DefaultKeyboardFocusManager.typeAheadAssertions(Unknown Source)
>>>>
>>>> at java.awt.DefaultKeyboardFocusManager.dispatchEvent(Unknown Source)
>>>>
>>>> at java.awt.Component.dispatchEventImpl(Unknown Source)
>>>>
>>>> at java.awt.Container.dispatchEventImpl(Unknown Source)
>>>>
>>>> at java.awt.Window.dispatchEventImpl(Unknown Source)
>>>>
>>>> at java.awt.Component.dispatchEvent(Unknown Source)
>>>>
>>>> at java.awt.EventQueue.dispatchEventImpl(Unknown Source)
>>>>
>>>> at java.awt.EventQueue.access$300(Unknown Source)
>>>>
>>>> at java.awt.EventQueue$3.run(Unknown Source)
>>>>
>>>> at java.awt.EventQueue$3.run(Unknown Source)
>>>>
>>>> at java.security.AccessController.doPrivileged(Native Method)
>>>>
>>>> at java.security.ProtectionDomain$1.doIntersectionPrivilege(Unknown Source)
>>>>
>>>> at java.security.ProtectionDomain$1.doIntersectionPrivilege(Unknown Source)
>>>>
>>>> at java.awt.EventQueue$4.run(Unknown Source)
>>>>
>>>> at java.awt.EventQueue$4.run(Unknown Source)
>>>>
>>>> at java.security.AccessController.doPrivileged(Native Method)
>>>>
>>>> at java.security.ProtectionDomain$1.doIntersectionPrivilege(Unknown Source)
>>>>
>>>> at java.awt.EventQueue.dispatchEvent(Unknown Source)
>>>>
>>>> at java.awt.EventDispatchThread.pumpOneEventForFilters(Unknown Source)
>>>>
>>>> at java.awt.EventDispatchThread.pumpEventsForFilter(Unknown Source)
>>>>
>>>> at java.awt.EventDispatchThread.pumpEventsForHierarchy(Unknown Source)
>>>>
>>>> at java.awt.EventDispatchThread.pumpEvents(Unknown Source)
>>>>
>>>> at java.awt.EventDispatchThread.pumpEvents(Unknown Source)
>>>>
>>>> at java.awt.EventDispatchThread.run(Unknown Source)
>>>>
>>>> =============
>>>>
>>>>
>>>>
>>>> When I check the issue tracker http://bugs.java.com/view_bug.do?bug_id=8023043 shows as fixed in 7u60. Did this get fixed in 7u60 through 7u80? The stacktrace is a little different from that bug so should I file this as a new issue?
>>>>
>>>>
>>>>
>>>> Thanks,
>>>>
>>>>
>>>>
>>>> Jason
>>>>
>>> 		 	   		



From anton.nashatyrev at oracle.com  Fri May  8 12:41:59 2015
From: anton.nashatyrev at oracle.com (Anton Nashatyrev)
Date: Fri, 08 May 2015 15:41:59 +0300
Subject: <Swing Dev> JDK-8023043 : Clipboard.getAvailableDataFlavors:
 Comparison method violates contract
In-Reply-To: <554CAE2E.7080308@oracle.com>
References: <BLU181-W644D97C980BBBF88F9D9E383EF0@phx.gbl>, ,
	<5537AAD2.2040107@oracle.com>,
	<BLU181-W910C67A3429B0D8FE4871A83EE0@phx.gbl>
	<BLU181-W46E780485FEECAAFC3CDF983DF0@phx.gbl>
	<554CAE2E.7080308@oracle.com>
Message-ID: <554CAF17.9020402@oracle.com>

Hi Alexander,

     I've updated the existing issue filed by Jason with the new 
information. So it seems no need to create a new one.

Thanks!
Anton.

On 08.05.2015 15:38, Alexander Scherbatiy wrote:
>
>   Hi Jason,
>
>  Please, file it as a new issue in http://bugreport.java.com/bugreport
>
>   Thanks,
>   Alexandr.
>
> On 5/7/2015 11:08 PM, Jason Mehrens wrote:
>> Anton,
>>
>>
>> I finally caught this error in production.  I patched our code to 
>> launch a JVM (with mergesort) using your test case, modifed to output 
>> the JVM version followed by the output when this error occurs.  The 
>> output is as follows:
>>
>>
>>
>> ============================================================================== 
>>
>>
>> 1.7.0_80-b15
>>
>> java.awt.datatransfer.DataFlavor[mimetype=application/x-java-serialized-object;representationclass=java.lang.String] 
>>
>>
>> java.awt.datatransfer.DataFlavor[mimetype=application/x-java-text-encoding;representationclass=[B] 
>>
>>
>> java.awt.datatransfer.DataFlavor[mimetype=text/plain;representationclass=java.io.Reader] 
>>
>>
>> java.awt.datatransfer.DataFlavor[mimetype=text/plain;representationclass=java.lang.String] 
>>
>>
>> java.awt.datatransfer.DataFlavor[mimetype=text/plain;representationclass=java.nio.CharBuffer] 
>>
>>
>> java.awt.datatransfer.DataFlavor[mimetype=text/plain;representationclass=[C] 
>>
>>
>> java.awt.datatransfer.DataFlavor[mimetype=text/plain;representationclass=java.io.InputStream;charset=unicode] 
>>
>>
>> java.awt.datatransfer.DataFlavor[mimetype=text/plain;representationclass=java.nio.ByteBuffer;charset=UTF-16] 
>>
>>
>> java.awt.datatransfer.DataFlavor[mimetype=text/plain;representationclass=[B;charset=UTF-16] 
>>
>>
>> java.awt.datatransfer.DataFlavor[mimetype=text/plain;representationclass=java.io.InputStream;charset=UTF-8] 
>>
>>
>> java.awt.datatransfer.DataFlavor[mimetype=text/plain;representationclass=java.nio.ByteBuffer;charset=UTF-8] 
>>
>>
>> java.awt.datatransfer.DataFlavor[mimetype=text/plain;representationclass=[B;charset=UTF-8] 
>>
>>
>> java.awt.datatransfer.DataFlavor[mimetype=text/plain;representationclass=java.io.InputStream;charset=UTF-16BE] 
>>
>>
>> java.awt.datatransfer.DataFlavor[mimetype=text/plain;representationclass=java.nio.ByteBuffer;charset=UTF-16BE] 
>>
>>
>> java.awt.datatransfer.DataFlavor[mimetype=text/plain;representationclass=[B;charset=UTF-16BE] 
>>
>>
>> java.awt.datatransfer.DataFlavor[mimetype=text/plain;representationclass=java.io.InputStream;charset=UTF-16LE] 
>>
>>
>> java.awt.datatransfer.DataFlavor[mimetype=text/plain;representationclass=java.nio.ByteBuffer;charset=UTF-16LE] 
>>
>>
>> java.awt.datatransfer.DataFlavor[mimetype=text/plain;representationclass=[B;charset=UTF-16LE] 
>>
>>
>> java.awt.datatransfer.DataFlavor[mimetype=text/plain;representationclass=java.io.InputStream;charset=ISO-8859-1] 
>>
>>
>> java.awt.datatransfer.DataFlavor[mimetype=text/plain;representationclass=java.nio.ByteBuffer;charset=ISO-8859-1] 
>>
>>
>> java.awt.datatransfer.DataFlavor[mimetype=text/plain;representationclass=[B;charset=ISO-8859-1] 
>>
>>
>> java.awt.datatransfer.DataFlavor[mimetype=text/plain;representationclass=java.io.InputStream;charset=windows-1252] 
>>
>>
>> java.awt.datatransfer.DataFlavor[mimetype=text/plain;representationclass=java.nio.ByteBuffer;charset=windows-1252] 
>>
>>
>> java.awt.datatransfer.DataFlavor[mimetype=text/plain;representationclass=[B;charset=windows-1252] 
>>
>>
>> java.awt.datatransfer.DataFlavor[mimetype=text/plain;representationclass=java.io.InputStream;charset=US-ASCII] 
>>
>>
>> java.awt.datatransfer.DataFlavor[mimetype=text/plain;representationclass=java.nio.ByteBuffer;charset=US-ASCII] 
>>
>>
>> java.awt.datatransfer.DataFlavor[mimetype=text/plain;representationclass=[B;charset=US-ASCII] 
>>
>>
>> ==================================================================================
>>
>>
>>
>> Jason
>>
>>
>>
>> ----------------------------------------
>>> From: jason_mehrens at hotmail.com
>>> To: anton.nashatyrev at oracle.com
>>> Date: Wed, 22 Apr 2015 14:59:26 -0500
>>> CC: swing-dev at openjdk.java.net
>>> Subject: Re: <Swing Dev> JDK-8023043 : 
>>> Clipboard.getAvailableDataFlavors: Comparison method violates contract
>>>
>>> Anton,
>>>
>>>
>>> Thanks for looking at this. Sorry I don't have a test case to give 
>>> you yet. For sure the machines are using JDK7u80 that are 
>>> reproducing the error. The common case is that the user is copying 
>>> text from an email client and then pasting it in to a JTextField. So 
>>> I imagine that the content type of email is a factor in producing 
>>> this issue.
>>>
>>>
>>> What I'll do is convert your ClipboardDump into the codebase so that 
>>> I can just log that information as soon as it happens. We'll see how 
>>> long it takes to catch this fish.
>>>
>>>
>>> Thanks,
>>>
>>>
>>> Jason
>>>
>>>
>>>
>>>
>>>
>>> ----------------------------------------
>>>> Date: Wed, 22 Apr 2015 17:06:10 +0300
>>>> From: anton.nashatyrev at oracle.com
>>>> To: jason_mehrens at hotmail.com
>>>> CC: swing-dev at openjdk.java.net
>>>> Subject: Re: <Swing Dev> JDK-8023043 : 
>>>> Clipboard.getAvailableDataFlavors: Comparison method violates contract
>>>>
>>>> Hi Jason,
>>>>
>>>> I've commented in the bug report:
>>>>
>>>> Couldn't reproduce locally.
>>>> Please next time the problem is reproduced on your side, run the small
>>>> program below and attach its output to this bug (or file a new one).
>>>> Make sure NOT using the system clipboard from the moment of exception
>>>> till running the test program.
>>>>
>>>> import java.awt.*;
>>>> import java.awt.datatransfer.DataFlavor;
>>>>
>>>> public class ClipboardDump {
>>>> public static void main(String[] args) {
>>>> System.setProperty("java.util.Arrays.useLegacyMergeSort", "true");
>>>>
>>>> DataFlavor[] dataFlavors =
>>>> Toolkit.getDefaultToolkit().getSystemClipboard().
>>>> getAvailableDataFlavors();
>>>>
>>>> for (DataFlavor df: dataFlavors) {
>>>> System.out.println(df);
>>>> }
>>>> }
>>>> }
>>>>
>>>> Please also make sure you are running 7u80 (not an earlier version)
>>>> since the Comparator fix was integrated to 7u80
>>>>
>>>> Thanks!
>>>> Anton.
>>>> On 21.04.2015 17:29, Jason Mehrens wrote:
>>>>> Hello Swing-Dev,
>>>>>
>>>>>
>>>>>
>>>>> Recently we have updated to JDK7u80 and have noticed a pattern of 
>>>>> users generating the following error:
>>>>>
>>>>>
>>>>>
>>>>> ==================
>>>>>
>>>>> java.lang.IllegalArgumentException: Comparison method violates its 
>>>>> general contract!
>>>>>
>>>>> at java.util.TimSort.mergeHi(Unknown Source)
>>>>>
>>>>> at java.util.TimSort.mergeAt(Unknown Source)
>>>>>
>>>>> at java.util.TimSort.mergeCollapse(Unknown Source)
>>>>>
>>>>> at java.util.TimSort.sort(Unknown Source)
>>>>>
>>>>> at java.util.TimSort.sort(Unknown Source)
>>>>>
>>>>> at java.util.Arrays.sort(Unknown Source)
>>>>>
>>>>> at 
>>>>> sun.awt.datatransfer.DataTransferer.setToSortedDataFlavorArray(Unknown 
>>>>> Source)
>>>>>
>>>>> at sun.awt.datatransfer.ClipboardTransferable.<init>(Unknown Source)
>>>>>
>>>>> at sun.awt.datatransfer.SunClipboard.getContents(Unknown Source)
>>>>>
>>>>> at 
>>>>> javax.swing.TransferHandler$TransferAction.actionPerformedImpl(Unknown 
>>>>> Source)
>>>>>
>>>>> at javax.swing.TransferHandler$TransferAction.access$700(Unknown 
>>>>> Source)
>>>>>
>>>>> at javax.swing.TransferHandler$TransferAction$1.run(Unknown Source)
>>>>>
>>>>> at javax.swing.TransferHandler$TransferAction$1.run(Unknown Source)
>>>>>
>>>>> at java.security.AccessController.doPrivileged(Native Method)
>>>>>
>>>>> at 
>>>>> java.security.ProtectionDomain$1.doIntersectionPrivilege(Unknown 
>>>>> Source)
>>>>>
>>>>> at 
>>>>> java.security.ProtectionDomain$1.doIntersectionPrivilege(Unknown 
>>>>> Source)
>>>>>
>>>>> at javax.swing.TransferHandler$TransferAction$2.run(Unknown Source)
>>>>>
>>>>> at javax.swing.TransferHandler$TransferAction$2.run(Unknown Source)
>>>>>
>>>>> at java.security.AccessController.doPrivileged(Native Method)
>>>>>
>>>>> at 
>>>>> java.security.ProtectionDomain$1.doIntersectionPrivilege(Unknown 
>>>>> Source)
>>>>>
>>>>> at 
>>>>> javax.swing.TransferHandler$TransferAction.actionPerformed(Unknown 
>>>>> Source)
>>>>>
>>>>> at javax.swing.text.JTextComponent.invokeAction(Unknown Source)
>>>>>
>>>>> at javax.swing.text.JTextComponent.paste(Unknown Source)
>>>>>
>>>>> at 
>>>>> javax.swing.text.DefaultEditorKit$PasteAction.actionPerformed(Unknown 
>>>>> Source)
>>>>>
>>>>> at javax.swing.SwingUtilities.notifyAction(Unknown Source)
>>>>>
>>>>> at javax.swing.JComponent.processKeyBinding(Unknown Source)
>>>>>
>>>>> at javax.swing.JComponent.processKeyBindings(Unknown Source)
>>>>>
>>>>> at javax.swing.JComponent.processKeyEvent(Unknown Source)
>>>>>
>>>>> at java.awt.Component.processEvent(Unknown Source)
>>>>>
>>>>> at java.awt.Container.processEvent(Unknown Source)
>>>>>
>>>>> at java.awt.Component.dispatchEventImpl(Unknown Source)
>>>>>
>>>>> at java.awt.Container.dispatchEventImpl(Unknown Source)
>>>>>
>>>>> at java.awt.Component.dispatchEvent(Unknown Source)
>>>>>
>>>>> at java.awt.KeyboardFocusManager.redispatchEvent(Unknown Source)
>>>>>
>>>>> at java.awt.DefaultKeyboardFocusManager.dispatchKeyEvent(Unknown 
>>>>> Source)
>>>>>
>>>>> at 
>>>>> java.awt.DefaultKeyboardFocusManager.preDispatchKeyEvent(Unknown 
>>>>> Source)
>>>>>
>>>>> at 
>>>>> java.awt.DefaultKeyboardFocusManager.typeAheadAssertions(Unknown 
>>>>> Source)
>>>>>
>>>>> at java.awt.DefaultKeyboardFocusManager.dispatchEvent(Unknown Source)
>>>>>
>>>>> at java.awt.Component.dispatchEventImpl(Unknown Source)
>>>>>
>>>>> at java.awt.Container.dispatchEventImpl(Unknown Source)
>>>>>
>>>>> at java.awt.Window.dispatchEventImpl(Unknown Source)
>>>>>
>>>>> at java.awt.Component.dispatchEvent(Unknown Source)
>>>>>
>>>>> at java.awt.EventQueue.dispatchEventImpl(Unknown Source)
>>>>>
>>>>> at java.awt.EventQueue.access$300(Unknown Source)
>>>>>
>>>>> at java.awt.EventQueue$3.run(Unknown Source)
>>>>>
>>>>> at java.awt.EventQueue$3.run(Unknown Source)
>>>>>
>>>>> at java.security.AccessController.doPrivileged(Native Method)
>>>>>
>>>>> at 
>>>>> java.security.ProtectionDomain$1.doIntersectionPrivilege(Unknown 
>>>>> Source)
>>>>>
>>>>> at 
>>>>> java.security.ProtectionDomain$1.doIntersectionPrivilege(Unknown 
>>>>> Source)
>>>>>
>>>>> at java.awt.EventQueue$4.run(Unknown Source)
>>>>>
>>>>> at java.awt.EventQueue$4.run(Unknown Source)
>>>>>
>>>>> at java.security.AccessController.doPrivileged(Native Method)
>>>>>
>>>>> at 
>>>>> java.security.ProtectionDomain$1.doIntersectionPrivilege(Unknown 
>>>>> Source)
>>>>>
>>>>> at java.awt.EventQueue.dispatchEvent(Unknown Source)
>>>>>
>>>>> at java.awt.EventDispatchThread.pumpOneEventForFilters(Unknown 
>>>>> Source)
>>>>>
>>>>> at java.awt.EventDispatchThread.pumpEventsForFilter(Unknown Source)
>>>>>
>>>>> at java.awt.EventDispatchThread.pumpEventsForHierarchy(Unknown 
>>>>> Source)
>>>>>
>>>>> at java.awt.EventDispatchThread.pumpEvents(Unknown Source)
>>>>>
>>>>> at java.awt.EventDispatchThread.pumpEvents(Unknown Source)
>>>>>
>>>>> at java.awt.EventDispatchThread.run(Unknown Source)
>>>>>
>>>>> =============
>>>>>
>>>>>
>>>>>
>>>>> When I check the issue tracker 
>>>>> http://bugs.java.com/view_bug.do?bug_id=8023043 shows as fixed in 
>>>>> 7u60. Did this get fixed in 7u60 through 7u80? The stacktrace is a 
>>>>> little different from that bug so should I file this as a new issue?
>>>>>
>>>>>
>>>>>
>>>>> Thanks,
>>>>>
>>>>>
>>>>>
>>>>> Jason
>>>>>
>>>>
>



From alexandr.scherbatiy at oracle.com  Fri May  8 12:46:00 2015
From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy)
Date: Fri, 08 May 2015 15:46:00 +0300
Subject: <Swing Dev> JDK-8023043 : Clipboard.getAvailableDataFlavors:
 Comparison method violates contract
In-Reply-To: <554CAF17.9020402@oracle.com>
References: <BLU181-W644D97C980BBBF88F9D9E383EF0@phx.gbl>, ,
	<5537AAD2.2040107@oracle.com>,
	<BLU181-W910C67A3429B0D8FE4871A83EE0@phx.gbl>
	<BLU181-W46E780485FEECAAFC3CDF983DF0@phx.gbl>
	<554CAE2E.7080308@oracle.com> <554CAF17.9020402@oracle.com>
Message-ID: <554CB008.7070907@oracle.com>

On 5/8/2015 3:41 PM, Anton Nashatyrev wrote:
> Hi Alexander,
>
>     I've updated the existing issue filed by Jason with the new 
> information. So it seems no need to create a new one.
       I see. I have founds this one: 
https://bugs.openjdk.java.net/browse/JDK-8078376

      Thanks,
      Alexandr.
>
> Thanks!
> Anton.
>
> On 08.05.2015 15:38, Alexander Scherbatiy wrote:
>>
>>   Hi Jason,
>>
>>  Please, file it as a new issue in http://bugreport.java.com/bugreport
>>
>>   Thanks,
>>   Alexandr.
>>
>> On 5/7/2015 11:08 PM, Jason Mehrens wrote:
>>> Anton,
>>>
>>>
>>> I finally caught this error in production.  I patched our code to 
>>> launch a JVM (with mergesort) using your test case, modifed to 
>>> output the JVM version followed by the output when this error 
>>> occurs.  The output is as follows:
>>>
>>>
>>>
>>> ============================================================================== 
>>>
>>>
>>> 1.7.0_80-b15
>>>
>>> java.awt.datatransfer.DataFlavor[mimetype=application/x-java-serialized-object;representationclass=java.lang.String] 
>>>
>>>
>>> java.awt.datatransfer.DataFlavor[mimetype=application/x-java-text-encoding;representationclass=[B] 
>>>
>>>
>>> java.awt.datatransfer.DataFlavor[mimetype=text/plain;representationclass=java.io.Reader] 
>>>
>>>
>>> java.awt.datatransfer.DataFlavor[mimetype=text/plain;representationclass=java.lang.String] 
>>>
>>>
>>> java.awt.datatransfer.DataFlavor[mimetype=text/plain;representationclass=java.nio.CharBuffer] 
>>>
>>>
>>> java.awt.datatransfer.DataFlavor[mimetype=text/plain;representationclass=[C] 
>>>
>>>
>>> java.awt.datatransfer.DataFlavor[mimetype=text/plain;representationclass=java.io.InputStream;charset=unicode] 
>>>
>>>
>>> java.awt.datatransfer.DataFlavor[mimetype=text/plain;representationclass=java.nio.ByteBuffer;charset=UTF-16] 
>>>
>>>
>>> java.awt.datatransfer.DataFlavor[mimetype=text/plain;representationclass=[B;charset=UTF-16] 
>>>
>>>
>>> java.awt.datatransfer.DataFlavor[mimetype=text/plain;representationclass=java.io.InputStream;charset=UTF-8] 
>>>
>>>
>>> java.awt.datatransfer.DataFlavor[mimetype=text/plain;representationclass=java.nio.ByteBuffer;charset=UTF-8] 
>>>
>>>
>>> java.awt.datatransfer.DataFlavor[mimetype=text/plain;representationclass=[B;charset=UTF-8] 
>>>
>>>
>>> java.awt.datatransfer.DataFlavor[mimetype=text/plain;representationclass=java.io.InputStream;charset=UTF-16BE] 
>>>
>>>
>>> java.awt.datatransfer.DataFlavor[mimetype=text/plain;representationclass=java.nio.ByteBuffer;charset=UTF-16BE] 
>>>
>>>
>>> java.awt.datatransfer.DataFlavor[mimetype=text/plain;representationclass=[B;charset=UTF-16BE] 
>>>
>>>
>>> java.awt.datatransfer.DataFlavor[mimetype=text/plain;representationclass=java.io.InputStream;charset=UTF-16LE] 
>>>
>>>
>>> java.awt.datatransfer.DataFlavor[mimetype=text/plain;representationclass=java.nio.ByteBuffer;charset=UTF-16LE] 
>>>
>>>
>>> java.awt.datatransfer.DataFlavor[mimetype=text/plain;representationclass=[B;charset=UTF-16LE] 
>>>
>>>
>>> java.awt.datatransfer.DataFlavor[mimetype=text/plain;representationclass=java.io.InputStream;charset=ISO-8859-1] 
>>>
>>>
>>> java.awt.datatransfer.DataFlavor[mimetype=text/plain;representationclass=java.nio.ByteBuffer;charset=ISO-8859-1] 
>>>
>>>
>>> java.awt.datatransfer.DataFlavor[mimetype=text/plain;representationclass=[B;charset=ISO-8859-1] 
>>>
>>>
>>> java.awt.datatransfer.DataFlavor[mimetype=text/plain;representationclass=java.io.InputStream;charset=windows-1252] 
>>>
>>>
>>> java.awt.datatransfer.DataFlavor[mimetype=text/plain;representationclass=java.nio.ByteBuffer;charset=windows-1252] 
>>>
>>>
>>> java.awt.datatransfer.DataFlavor[mimetype=text/plain;representationclass=[B;charset=windows-1252] 
>>>
>>>
>>> java.awt.datatransfer.DataFlavor[mimetype=text/plain;representationclass=java.io.InputStream;charset=US-ASCII] 
>>>
>>>
>>> java.awt.datatransfer.DataFlavor[mimetype=text/plain;representationclass=java.nio.ByteBuffer;charset=US-ASCII] 
>>>
>>>
>>> java.awt.datatransfer.DataFlavor[mimetype=text/plain;representationclass=[B;charset=US-ASCII] 
>>>
>>>
>>> ================================================================================== 
>>>
>>>
>>>
>>>
>>> Jason
>>>
>>>
>>>
>>> ----------------------------------------
>>>> From: jason_mehrens at hotmail.com
>>>> To: anton.nashatyrev at oracle.com
>>>> Date: Wed, 22 Apr 2015 14:59:26 -0500
>>>> CC: swing-dev at openjdk.java.net
>>>> Subject: Re: <Swing Dev> JDK-8023043 : 
>>>> Clipboard.getAvailableDataFlavors: Comparison method violates contract
>>>>
>>>> Anton,
>>>>
>>>>
>>>> Thanks for looking at this. Sorry I don't have a test case to give 
>>>> you yet. For sure the machines are using JDK7u80 that are 
>>>> reproducing the error. The common case is that the user is copying 
>>>> text from an email client and then pasting it in to a JTextField. 
>>>> So I imagine that the content type of email is a factor in 
>>>> producing this issue.
>>>>
>>>>
>>>> What I'll do is convert your ClipboardDump into the codebase so 
>>>> that I can just log that information as soon as it happens. We'll 
>>>> see how long it takes to catch this fish.
>>>>
>>>>
>>>> Thanks,
>>>>
>>>>
>>>> Jason
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> ----------------------------------------
>>>>> Date: Wed, 22 Apr 2015 17:06:10 +0300
>>>>> From: anton.nashatyrev at oracle.com
>>>>> To: jason_mehrens at hotmail.com
>>>>> CC: swing-dev at openjdk.java.net
>>>>> Subject: Re: <Swing Dev> JDK-8023043 : 
>>>>> Clipboard.getAvailableDataFlavors: Comparison method violates 
>>>>> contract
>>>>>
>>>>> Hi Jason,
>>>>>
>>>>> I've commented in the bug report:
>>>>>
>>>>> Couldn't reproduce locally.
>>>>> Please next time the problem is reproduced on your side, run the 
>>>>> small
>>>>> program below and attach its output to this bug (or file a new one).
>>>>> Make sure NOT using the system clipboard from the moment of exception
>>>>> till running the test program.
>>>>>
>>>>> import java.awt.*;
>>>>> import java.awt.datatransfer.DataFlavor;
>>>>>
>>>>> public class ClipboardDump {
>>>>> public static void main(String[] args) {
>>>>> System.setProperty("java.util.Arrays.useLegacyMergeSort", "true");
>>>>>
>>>>> DataFlavor[] dataFlavors =
>>>>> Toolkit.getDefaultToolkit().getSystemClipboard().
>>>>> getAvailableDataFlavors();
>>>>>
>>>>> for (DataFlavor df: dataFlavors) {
>>>>> System.out.println(df);
>>>>> }
>>>>> }
>>>>> }
>>>>>
>>>>> Please also make sure you are running 7u80 (not an earlier version)
>>>>> since the Comparator fix was integrated to 7u80
>>>>>
>>>>> Thanks!
>>>>> Anton.
>>>>> On 21.04.2015 17:29, Jason Mehrens wrote:
>>>>>> Hello Swing-Dev,
>>>>>>
>>>>>>
>>>>>>
>>>>>> Recently we have updated to JDK7u80 and have noticed a pattern of 
>>>>>> users generating the following error:
>>>>>>
>>>>>>
>>>>>>
>>>>>> ==================
>>>>>>
>>>>>> java.lang.IllegalArgumentException: Comparison method violates 
>>>>>> its general contract!
>>>>>>
>>>>>> at java.util.TimSort.mergeHi(Unknown Source)
>>>>>>
>>>>>> at java.util.TimSort.mergeAt(Unknown Source)
>>>>>>
>>>>>> at java.util.TimSort.mergeCollapse(Unknown Source)
>>>>>>
>>>>>> at java.util.TimSort.sort(Unknown Source)
>>>>>>
>>>>>> at java.util.TimSort.sort(Unknown Source)
>>>>>>
>>>>>> at java.util.Arrays.sort(Unknown Source)
>>>>>>
>>>>>> at 
>>>>>> sun.awt.datatransfer.DataTransferer.setToSortedDataFlavorArray(Unknown 
>>>>>> Source)
>>>>>>
>>>>>> at sun.awt.datatransfer.ClipboardTransferable.<init>(Unknown Source)
>>>>>>
>>>>>> at sun.awt.datatransfer.SunClipboard.getContents(Unknown Source)
>>>>>>
>>>>>> at 
>>>>>> javax.swing.TransferHandler$TransferAction.actionPerformedImpl(Unknown 
>>>>>> Source)
>>>>>>
>>>>>> at javax.swing.TransferHandler$TransferAction.access$700(Unknown 
>>>>>> Source)
>>>>>>
>>>>>> at javax.swing.TransferHandler$TransferAction$1.run(Unknown Source)
>>>>>>
>>>>>> at javax.swing.TransferHandler$TransferAction$1.run(Unknown Source)
>>>>>>
>>>>>> at java.security.AccessController.doPrivileged(Native Method)
>>>>>>
>>>>>> at 
>>>>>> java.security.ProtectionDomain$1.doIntersectionPrivilege(Unknown 
>>>>>> Source)
>>>>>>
>>>>>> at 
>>>>>> java.security.ProtectionDomain$1.doIntersectionPrivilege(Unknown 
>>>>>> Source)
>>>>>>
>>>>>> at javax.swing.TransferHandler$TransferAction$2.run(Unknown Source)
>>>>>>
>>>>>> at javax.swing.TransferHandler$TransferAction$2.run(Unknown Source)
>>>>>>
>>>>>> at java.security.AccessController.doPrivileged(Native Method)
>>>>>>
>>>>>> at 
>>>>>> java.security.ProtectionDomain$1.doIntersectionPrivilege(Unknown 
>>>>>> Source)
>>>>>>
>>>>>> at 
>>>>>> javax.swing.TransferHandler$TransferAction.actionPerformed(Unknown Source) 
>>>>>>
>>>>>>
>>>>>> at javax.swing.text.JTextComponent.invokeAction(Unknown Source)
>>>>>>
>>>>>> at javax.swing.text.JTextComponent.paste(Unknown Source)
>>>>>>
>>>>>> at 
>>>>>> javax.swing.text.DefaultEditorKit$PasteAction.actionPerformed(Unknown 
>>>>>> Source)
>>>>>>
>>>>>> at javax.swing.SwingUtilities.notifyAction(Unknown Source)
>>>>>>
>>>>>> at javax.swing.JComponent.processKeyBinding(Unknown Source)
>>>>>>
>>>>>> at javax.swing.JComponent.processKeyBindings(Unknown Source)
>>>>>>
>>>>>> at javax.swing.JComponent.processKeyEvent(Unknown Source)
>>>>>>
>>>>>> at java.awt.Component.processEvent(Unknown Source)
>>>>>>
>>>>>> at java.awt.Container.processEvent(Unknown Source)
>>>>>>
>>>>>> at java.awt.Component.dispatchEventImpl(Unknown Source)
>>>>>>
>>>>>> at java.awt.Container.dispatchEventImpl(Unknown Source)
>>>>>>
>>>>>> at java.awt.Component.dispatchEvent(Unknown Source)
>>>>>>
>>>>>> at java.awt.KeyboardFocusManager.redispatchEvent(Unknown Source)
>>>>>>
>>>>>> at java.awt.DefaultKeyboardFocusManager.dispatchKeyEvent(Unknown 
>>>>>> Source)
>>>>>>
>>>>>> at 
>>>>>> java.awt.DefaultKeyboardFocusManager.preDispatchKeyEvent(Unknown 
>>>>>> Source)
>>>>>>
>>>>>> at 
>>>>>> java.awt.DefaultKeyboardFocusManager.typeAheadAssertions(Unknown 
>>>>>> Source)
>>>>>>
>>>>>> at java.awt.DefaultKeyboardFocusManager.dispatchEvent(Unknown 
>>>>>> Source)
>>>>>>
>>>>>> at java.awt.Component.dispatchEventImpl(Unknown Source)
>>>>>>
>>>>>> at java.awt.Container.dispatchEventImpl(Unknown Source)
>>>>>>
>>>>>> at java.awt.Window.dispatchEventImpl(Unknown Source)
>>>>>>
>>>>>> at java.awt.Component.dispatchEvent(Unknown Source)
>>>>>>
>>>>>> at java.awt.EventQueue.dispatchEventImpl(Unknown Source)
>>>>>>
>>>>>> at java.awt.EventQueue.access$300(Unknown Source)
>>>>>>
>>>>>> at java.awt.EventQueue$3.run(Unknown Source)
>>>>>>
>>>>>> at java.awt.EventQueue$3.run(Unknown Source)
>>>>>>
>>>>>> at java.security.AccessController.doPrivileged(Native Method)
>>>>>>
>>>>>> at 
>>>>>> java.security.ProtectionDomain$1.doIntersectionPrivilege(Unknown 
>>>>>> Source)
>>>>>>
>>>>>> at 
>>>>>> java.security.ProtectionDomain$1.doIntersectionPrivilege(Unknown 
>>>>>> Source)
>>>>>>
>>>>>> at java.awt.EventQueue$4.run(Unknown Source)
>>>>>>
>>>>>> at java.awt.EventQueue$4.run(Unknown Source)
>>>>>>
>>>>>> at java.security.AccessController.doPrivileged(Native Method)
>>>>>>
>>>>>> at 
>>>>>> java.security.ProtectionDomain$1.doIntersectionPrivilege(Unknown 
>>>>>> Source)
>>>>>>
>>>>>> at java.awt.EventQueue.dispatchEvent(Unknown Source)
>>>>>>
>>>>>> at java.awt.EventDispatchThread.pumpOneEventForFilters(Unknown 
>>>>>> Source)
>>>>>>
>>>>>> at java.awt.EventDispatchThread.pumpEventsForFilter(Unknown Source)
>>>>>>
>>>>>> at java.awt.EventDispatchThread.pumpEventsForHierarchy(Unknown 
>>>>>> Source)
>>>>>>
>>>>>> at java.awt.EventDispatchThread.pumpEvents(Unknown Source)
>>>>>>
>>>>>> at java.awt.EventDispatchThread.pumpEvents(Unknown Source)
>>>>>>
>>>>>> at java.awt.EventDispatchThread.run(Unknown Source)
>>>>>>
>>>>>> =============
>>>>>>
>>>>>>
>>>>>>
>>>>>> When I check the issue tracker 
>>>>>> http://bugs.java.com/view_bug.do?bug_id=8023043 shows as fixed in 
>>>>>> 7u60. Did this get fixed in 7u60 through 7u80? The stacktrace is 
>>>>>> a little different from that bug so should I file this as a new 
>>>>>> issue?
>>>>>>
>>>>>>
>>>>>>
>>>>>> Thanks,
>>>>>>
>>>>>>
>>>>>>
>>>>>> Jason
>>>>>>
>>>>>
>>
>



From alexandr.scherbatiy at oracle.com  Fri May  8 12:52:45 2015
From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy)
Date: Fri, 08 May 2015 15:52:45 +0300
Subject: <Swing Dev> [9] Review Request for 6260348: GTK+ L&F
 JTextComponent not respecting desktop caret blink rate
In-Reply-To: <554C7914.7040802@oracle.com>
References: <5539004F.9060705@oracle.com> <553E4836.3040408@oracle.com>
	<554C7914.7040802@oracle.com>
Message-ID: <554CB19D.3040809@oracle.com>


   The fix looks good to me.

   Thanks,
   Alexandr.

On 5/8/2015 11:51 AM, Semyon Sadetsky wrote:
> Hi Alexander,
>
> gboolean and gint are equivalent.
>
> --Semyon
>
> On 4/27/2015 5:31 PM, Alexander Scherbatiy wrote:
>> On 4/23/2015 5:23 PM, Semyon Sadetsky wrote:
>>> Hello,
>>>
>>> Please review fix for JDK9:
>>>
>>> web rev: http://cr.openjdk.java.net/~ssadetsky/6260348/webrev.00/
>>> bug: https://bugs.openjdk.java.net/browse/JDK-6260348
>>
>> gtk2_interface.c
>> 2510     gint intval = NULL;
>> 2511     (*fp_g_object_get)(settings, key, &intval, NULL);
>> 2512     return create_Boolean(env, intval);
>>
>> Probably the type of the value should be gboolean.
>>
>>  Thanks,
>>  Alexandr.
>>
>>>
>>> ***ROOT CAUSE
>>> GTK L&F never took care about native GTK cursor blink settings.
>>>
>>> ***SOLUTION
>>> Implement this feature.
>>>
>>> ***TESTING
>>> Two test scenarios added. 1st sets GTK cursor blink enabled and 
>>> blink time 200 ms. 2nd disables cursor blinking. Then Java text 
>>> caret is checked to respect these settings.
>>>
>>> --Semyon
>>>
>>>
>>
>



From Sergey.Bylokhov at oracle.com  Fri May  8 13:07:47 2015
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Fri, 08 May 2015 16:07:47 +0300
Subject: <Swing Dev> [9] Review Request for 8079640: GroupLayout
 incorrect layout with large JTextArea
In-Reply-To: <554C783A.4080606@oracle.com>
References: <554C783A.4080606@oracle.com>
Message-ID: <554CB523.7080300@oracle.com>

Hi, Semyon.
It will be good to dig into the history of GroupLayout and understand 
why this was constrained, note that tutorial should be updated also.

On 08.05.15 11:47, Semyon Sadetsky wrote:
> Hello,
>
> Please review fix for JDK9:
>
> bug: https://bugs.openjdk.java.net/browse/JDK-8079640
> webrev: http://cr.openjdk.java.net/~ssadetsky/8079640/webrev.00/
>
> *THE ROOT CAUSE
> Component minimum size is limited to Short.MAX_VALUE in GroupLayout.
> JDK turtorial 
> https://docs.oracle.com/javase/tutorial/uiswing/layout/group.html 
> tells that Short.MAX_VALUE is treated as infinite.
> But I did not find any reasons in JDK specs why a bigger number cannot 
> be used.
>
> *SOLUTION
> Remove the limitation
>
> *TESTING
> Test is added to cover the large component scenario.
> Existing GroupLayout tests are passed.
>
> --Semyon
>


-- 
Best regards, Sergey.



From jonathan.gibbons at oracle.com  Thu May  7 21:28:17 2015
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Thu, 07 May 2015 14:28:17 -0700
Subject: <Swing Dev> [9] Review Request: JDK-8079428 [TEST_BUG] Test
 javax/swing/plaf/windows/6921687/bug6921687.java fails
In-Reply-To: <554A2118.403@oracle.com>
References: <5549B24A.40800@oracle.com> <554A0921.3010502@oracle.com>
	<554A2118.403@oracle.com>
Message-ID: <554BD8F1.9080202@oracle.com>

There is no issue here and the tests that used to "work" with jtreg b05 
didn't do what you thought they did. Just look at the .jtr file and see 
what jtreg actually did before.

First, you need to realize that "@build" is a shorthand for "@run 
build".    The section on "shorthands" is in the very next section of 
the spec after the section on "defaults" that you mention.

Shorthand 	Equivalent
@build <classname>+ 	@run build <classname>+
@clean <classname>+ 	@run clean <classname>+
@compile<option>* <arg>+ 	@run compile<option>* <arg>+
@ignore <word>* 	@run ignore <word>*



Now consider what a test containing just @build does.  @build is a 
shorthard for "@run build" and so after you expand the shorthand, it is 
/not/ a candidate for the default action with the part of the spec you 
reference. Therefore there is no attempt to actually run the class that 
was built.  That was the old behavior up through jtreg b05.   Clearly, 
that old behavior is silly -- it didn't actually run the test. That is 
the behavior you seem to be asking me to restore!  Once we realized the 
issue, the simplest fix was to detect and report this situation, which 
is the current behavior. If you just tell jtreg to build the test (and 
not run it) that will be now reported as an error.

I believe that the current state is a good one, even if it means users 
having to fix tests that were previously dysfunctional.

-- Jon

On 05/06/2015 07:11 AM, Alexander Scherbatiy wrote:
>
> This is the known issue in jtreg: CODETOOLS-7901378 Test result error 
> when @build used without @run main
>    https://bugs.openjdk.java.net/browse/CODETOOLS-7901378
>
>  It is closed as not an issue but I would argue against it. It 
> definitely worked in jtreg 4.1 fcs b05.
>  Why tests which pass with jtreg 4.1 b05 started to fail in b11?
>
>  Thanks,
>  Alexandr.
>
>
> On 5/6/2015 3:29 PM, Sergey Bylokhov wrote:
>> Hello,
>> It seems that this is a bug in the jtreg because according its 
>> specification:
>>
>> "If no |@run| tags are present in a defining file, a default is 
>> assumed depending upon the file's filename extension"
>>
>> File type     Default     Notes
>> .java     |@run main <name>|     <name> is the name of the file 
>> without the ".java" suffix
>> .sh     |@run shell <file>|
>> .html     |@run applet <file>|
>>
>>
>> Jonathan do you know something about this issue?
>>
>> On 06.05.15 9:18, pooja chopra wrote:
>>> Hello,
>>> Please review a fix for issue:
>>> 8079428 [TEST_BUG] Test 
>>> javax/swing/plaf/windows/6921687/bug6921687.java
>>> Test bug fix.
>>> https://bugs.openjdk.java.net/browse/JDK-8079428
>>> The webrev is : http://cr.openjdk.java.net/~pchopra/8079428/webrev.00/
>>>
>>> Thanks,
>>> Pooja
>>
>>
>> -- 
>> Best regards, Sergey.
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/swing-dev/attachments/20150507/eb4c070e/attachment.html>

From alexander.zvegintsev at oracle.com  Fri May  8 14:04:27 2015
From: alexander.zvegintsev at oracle.com (Alexander Zvegintsev)
Date: Fri, 08 May 2015 17:04:27 +0300
Subject: <Swing Dev> [9] Review Request for 6260348: GTK+ L&F
 JTextComponent not respecting desktop caret blink rate
In-Reply-To: <5539004F.9060705@oracle.com>
References: <5539004F.9060705@oracle.com>
Message-ID: <554CC26B.5020004@oracle.com>

Hi Semyon,

the fix itself looks good to me, but the test doesn't work.

1. FileWriter is replacing the .gtkrc-2.0 file (FileWriter(file, true 
/*append*/) should be used) ;
2. settings from .gtkrc-2.0  doesn't taken into account on my system.
there are at least two system tools which allows to modify such values:
gconftool-2 and gsettings. One of them may lack on different systems.
this will make test complicated.
So I suggest just remove the test and add noreg-hard label to the issue.

--
Thanks,
Alexander.

On 23.04.2015 17:23, Semyon Sadetsky wrote:
> Hello,
>
> Please review fix for JDK9:
>
> web rev: http://cr.openjdk.java.net/~ssadetsky/6260348/webrev.00/
> bug: https://bugs.openjdk.java.net/browse/JDK-6260348
>
> ***ROOT CAUSE
> GTK L&F never took care about native GTK cursor blink settings.
>
> ***SOLUTION
> Implement this feature.
>
> ***TESTING
> Two test scenarios added. 1st sets GTK cursor blink enabled and blink 
> time 200 ms. 2nd disables cursor blinking. Then Java text caret is 
> checked to respect these settings.
>
> --Semyon
>
>



From Sergey.Bylokhov at oracle.com  Fri May  8 18:25:20 2015
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Fri, 08 May 2015 21:25:20 +0300
Subject: <Swing Dev> [9] Review Request: 6368321 MetalRootPaneUI calls to
	deprecated code
Message-ID: <554CFF90.4090501@oracle.com>

Hello.
Please review the fix for jdk9. I do not plan to backport it to jdk8.

Usage of deprecated methods(xxxMenuBar()) were removed as suggested in 
the bug comments.
The fix is a part of https://bugs.openjdk.java.net/browse/JDK-8066622 
efforts.

Bug: https://bugs.openjdk.java.net/browse/JDK-6368321
Webrev can be found at: http://cr.openjdk.java.net/~serb/6368321/webrev.00

-- 
Best regards, Sergey.



From Sergey.Bylokhov at oracle.com  Fri May  8 23:50:53 2015
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Sat, 09 May 2015 02:50:53 +0300
Subject: <Swing Dev> [9] Review Request: 5109918 Wrong documentation for
 JSpinner.DateEditor constructor
Message-ID: <554D4BDD.3000403@oracle.com>

Hello.
Please review one more small fix for a typo in jdk9.

"Description for constructor "public JSpinner.DateEditor(JSpinner 
spinner)" containes:
      "This DateEditor becomes both a ChangeListener on the spinners model
       and a PropertyChangeListener on the new JFormattedTextField."
In fact DateEditor becomes a ChangeListener on the spinner but not on 
the spinners model"

All other constructors except this one were fixed already in 
https://bugs.openjdk.java.net/browse/JDK-4408581

Bug: https://bugs.openjdk.java.net/browse/JDK-5109918
Webrev can be found at: http://cr.openjdk.java.net/~serb/5109918/webrev.00

-- 
Best regards, Sergey.



From alexander.zvegintsev at oracle.com  Tue May 12 10:10:26 2015
From: alexander.zvegintsev at oracle.com (Alexander Zvegintsev)
Date: Tue, 12 May 2015 13:10:26 +0300
Subject: <Swing Dev> [9] Review Request: 6368321 MetalRootPaneUI calls
 to deprecated code
In-Reply-To: <554CFF90.4090501@oracle.com>
References: <554CFF90.4090501@oracle.com>
Message-ID: <5551D192.1060300@oracle.com>

Hello Sergey,

the fix looks fine.

Do we have any plans to remove setMenuBar and getMenuBar as they are 
deprecated for a long time?

Thanks,

Alexander.

On 05/08/2015 09:25 PM, Sergey Bylokhov wrote:
> Hello.
> Please review the fix for jdk9. I do not plan to backport it to jdk8.
>
> Usage of deprecated methods(xxxMenuBar()) were removed as suggested in 
> the bug comments.
> The fix is a part of https://bugs.openjdk.java.net/browse/JDK-8066622 
> efforts.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-6368321
> Webrev can be found at: 
> http://cr.openjdk.java.net/~serb/6368321/webrev.00
>



From alexander.zvegintsev at oracle.com  Tue May 12 10:23:16 2015
From: alexander.zvegintsev at oracle.com (Alexander Zvegintsev)
Date: Tue, 12 May 2015 13:23:16 +0300
Subject: <Swing Dev> [9] Review Request: 5109918 Wrong documentation for
 JSpinner.DateEditor constructor
In-Reply-To: <554D4BDD.3000403@oracle.com>
References: <554D4BDD.3000403@oracle.com>
Message-ID: <5551D494.1080803@oracle.com>

Hello Sergey,

the fix looks fine.

Thanks,

Alexander.

On 05/09/2015 02:50 AM, Sergey Bylokhov wrote:
> Hello.
> Please review one more small fix for a typo in jdk9.
>
> "Description for constructor "public JSpinner.DateEditor(JSpinner 
> spinner)" containes:
>      "This DateEditor becomes both a ChangeListener on the spinners model
>       and a PropertyChangeListener on the new JFormattedTextField."
> In fact DateEditor becomes a ChangeListener on the spinner but not on 
> the spinners model"
>
> All other constructors except this one were fixed already in 
> https://bugs.openjdk.java.net/browse/JDK-4408581
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-5109918
> Webrev can be found at: 
> http://cr.openjdk.java.net/~serb/5109918/webrev.00
>



From Sergey.Bylokhov at oracle.com  Tue May 12 18:38:37 2015
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Tue, 12 May 2015 21:38:37 +0300
Subject: <Swing Dev> [9] Review request for 8033069: mouse wheel scroll
 closes combobox popup
In-Reply-To: <554B5B14.40505@oracle.com>
References: <554A1771.60103@oracle.com> <554A6B49.7000705@oracle.com>
	<554B5B14.40505@oracle.com>
Message-ID: <555248AD.1090609@oracle.com>

Hi, Alexey.
Thanks for clarification, the fix looks good.

On 07.05.15 15:31, Alexey Ivanov wrote:
> Hi Sergey,
>
> The changes in BasicPopupMenuUI are similar to handling mouse events 
> for JMenu. The popup stays open if user rotates wheel over combo box 
> that opened the popup but the popup will be canceled if wheel is 
> rotated over another combo box or any other component.
>
> The client property "doNotCancelPopup" is set for each combo box 
> because MOUSE_PRESS logic is in BasicComboPopup.Handler.mousePressed. 
> If you click another combo box, it will open its own popup which 
> automatically hides the popup that was visible.
>
> In case of MOUSE_WHEEL, combo box over which mouse wheel is rotated 
> should close the popup of another combo box that opened the popup; and 
> it should do nothing if its own popup is open. Moving this logic into 
> JComboBox MouseWheelListener seems too complicated.
>
>
> As for user-installed MouseWheelListener on JComboBox, of course 
> mouseWheelMoved is called but MouseWheelEvent is already marked 
> consumed. It might have a negative effect on user code if they check 
> isConsumed() flag. If the event is not consumed, the popup will be closed.
>
> Regards,
> Alexey
>
> On 06.05.2015 22:28, Sergey Bylokhov wrote:
>> Hi, Alexey.
>> The changes in the BasicPopupMenuUI does not look clear, I am not 
>> sure but probably it will be better to implement it in the same way 
>> as for MOUSE_PRESSED(via UIManager property)? It will add an 
>> additional configuration possibility.
>> Can you also confirm that the case when the user install mouse wheel 
>> listener to the JComboBox still works.
>>
>> On 06.05.15 16:30, Alexey Ivanov wrote:
>>> Hello Swing team,
>>>
>>> Could you please review the fix:
>>>     bug: https://bugs.openjdk.java.net/browse/JDK-8033069
>>>     webrev: http://cr.openjdk.java.net/~aivanov/8033069/jdk9/webrev.00/
>>>
>>> Description:
>>> If you rotate mouse wheel when combo box popup is open, the popup 
>>> gets closed.
>>>
>>> The fix is to always consume MOUSE_WHEEL event.
>>>
>>> There are two regression tests for the cases where popup has 
>>> vertical scroll bar and does not have scroll bar.
>>>
>>> Thanks,
>>> Alexey
>>
>>
>> -- 
>> Best regards, Sergey.
>


-- 
Best regards, Sergey.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/swing-dev/attachments/20150512/2f2cdf01/attachment.html>

From alexandr.scherbatiy at oracle.com  Wed May 13 15:06:51 2015
From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy)
Date: Wed, 13 May 2015 18:06:51 +0300
Subject: <Swing Dev> [9] Review Request for 7172652: With JDK 1.7 text
 field does not obtain focus when using mnemonic Alt/Key combin
In-Reply-To: <554C7E44.1050304@oracle.com>
References: <55351307.4020504@oracle.com> <553F8B9E.1090904@oracle.com>
	<554C7E44.1050304@oracle.com>
Message-ID: <5553688B.4070303@oracle.com>

On 5/8/2015 12:13 PM, Semyon Sadetsky wrote:
> updated: http://cr.openjdk.java.net/~ssadetsky/7172652/webrev.01/

    - Should the labelFor request focus in the method 
BasicLabelUI.doRelease(...) as it was before the fix
    - There are some formatting problems (space after a method argument 
on line 507, bracket on line 534)
    -  It seems that inputMap.put() in doPress() method also can be 
changed to putOnRelease()
    - frame.dispose() also should be called on EDT in the test

    Thanks,
    Alexandr.

>
>
> On 4/28/2015 4:31 PM, Alexander Scherbatiy wrote:
>>
>>   Is it possible to make code shorter by adding methods like:
>>   putOnRelease(InputMap inputMap, int keyCode, int modifiers)
>>   removeOnRelease(InputMap inputMap, int keyCode, int modifiers)
>>
>>   Thanks,
>>   Alexandr.
>>
>> On 4/20/2015 5:53 PM, Semyon Sadetsky wrote:
>>> Hello,
>>>
>>> please review a fix for JDK9:
>>>
>>> webrev: http://cr.openjdk.java.net/~ssadetsky/7172652/webrev.00/
>>> bug: https://bugs.openjdk.java.net/browse/JDK-7172652
>>>
>>> ***ROOT CAUSE
>>> This is a bug in Label UI's key release event processing routine for 
>>> key mnemonics: only one release event is captured instead of two 
>>> (Alt release and the mnemonic key release). The Alt release event 
>>> goes up on hierarchy and is captured by the parent internal frame's 
>>> menu bar for which Alt key release means selection change event 
>>> under the Windows system LnF.
>>>
>>> ***SOLUTION
>>> Change key release event handling logic to capture events from both 
>>> Alt modifier and the key. The logic takes into account that when the 
>>> first release key event come it transfers focus back to the field so 
>>> the second key release event should be captured from any window 
>>> component.
>>>
>>> ***TESTING
>>> A simple scenario is written to exclusively cover the situation.
>>>
>>> --Semyon
>>>
>>
>



From alexandr.scherbatiy at oracle.com  Wed May 13 15:27:08 2015
From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy)
Date: Wed, 13 May 2015 18:27:08 +0300
Subject: <Swing Dev> [9] Review Request: 6368321 MetalRootPaneUI calls
 to deprecated code
In-Reply-To: <554CFF90.4090501@oracle.com>
References: <554CFF90.4090501@oracle.com>
Message-ID: <55536D4C.1020006@oracle.com>


   The fix looks good to me.

   Thanks,
   Alexandr.

On 5/8/2015 9:25 PM, Sergey Bylokhov wrote:
> Hello.
> Please review the fix for jdk9. I do not plan to backport it to jdk8.
>
> Usage of deprecated methods(xxxMenuBar()) were removed as suggested in 
> the bug comments.
> The fix is a part of https://bugs.openjdk.java.net/browse/JDK-8066622 
> efforts.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-6368321
> Webrev can be found at: 
> http://cr.openjdk.java.net/~serb/6368321/webrev.00
>



From alexandr.scherbatiy at oracle.com  Wed May 13 15:30:08 2015
From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy)
Date: Wed, 13 May 2015 18:30:08 +0300
Subject: <Swing Dev> [9] Review Request: 5109918 Wrong documentation for
 JSpinner.DateEditor constructor
In-Reply-To: <5551D494.1080803@oracle.com>
References: <554D4BDD.3000403@oracle.com> <5551D494.1080803@oracle.com>
Message-ID: <55536E00.2050102@oracle.com>


   The fix looks good to me.

   Thanks,
   Alexandr.

On 5/12/2015 1:23 PM, Alexander Zvegintsev wrote:
> Hello Sergey,
>
> the fix looks fine.
>
> Thanks,
>
> Alexander.
>
> On 05/09/2015 02:50 AM, Sergey Bylokhov wrote:
>> Hello.
>> Please review one more small fix for a typo in jdk9.
>>
>> "Description for constructor "public JSpinner.DateEditor(JSpinner 
>> spinner)" containes:
>>      "This DateEditor becomes both a ChangeListener on the spinners 
>> model
>>       and a PropertyChangeListener on the new JFormattedTextField."
>> In fact DateEditor becomes a ChangeListener on the spinner but not on 
>> the spinners model"
>>
>> All other constructors except this one were fixed already in 
>> https://bugs.openjdk.java.net/browse/JDK-4408581
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-5109918
>> Webrev can be found at: 
>> http://cr.openjdk.java.net/~serb/5109918/webrev.00
>>
>



From semyon.sadetsky at oracle.com  Thu May 14 07:25:49 2015
From: semyon.sadetsky at oracle.com (Semyon Sadetsky)
Date: Thu, 14 May 2015 10:25:49 +0300
Subject: <Swing Dev> [9] Review Request for 7172652: With JDK 1.7 text
 field does not obtain focus when using mnemonic Alt/Key combin
In-Reply-To: <5553688B.4070303@oracle.com>
References: <55351307.4020504@oracle.com> <553F8B9E.1090904@oracle.com>
	<554C7E44.1050304@oracle.com> <5553688B.4070303@oracle.com>
Message-ID: <55544DFD.5020407@oracle.com>

Alexander, thanks. all is relevant.
http://cr.openjdk.java.net/~ssadetsky/7172652/webrev.02/

--Semyon


On 5/13/2015 6:06 PM, Alexander Scherbatiy wrote:
> On 5/8/2015 12:13 PM, Semyon Sadetsky wrote:
>> updated: http://cr.openjdk.java.net/~ssadetsky/7172652/webrev.01/
>
>    - Should the labelFor request focus in the method 
> BasicLabelUI.doRelease(...) as it was before the fix
>    - There are some formatting problems (space after a method argument 
> on line 507, bracket on line 534)
>    -  It seems that inputMap.put() in doPress() method also can be 
> changed to putOnRelease()
>    - frame.dispose() also should be called on EDT in the test
>
>    Thanks,
>    Alexandr.
>
>>
>>
>> On 4/28/2015 4:31 PM, Alexander Scherbatiy wrote:
>>>
>>>   Is it possible to make code shorter by adding methods like:
>>>   putOnRelease(InputMap inputMap, int keyCode, int modifiers)
>>>   removeOnRelease(InputMap inputMap, int keyCode, int modifiers)
>>>
>>>   Thanks,
>>>   Alexandr.
>>>
>>> On 4/20/2015 5:53 PM, Semyon Sadetsky wrote:
>>>> Hello,
>>>>
>>>> please review a fix for JDK9:
>>>>
>>>> webrev: http://cr.openjdk.java.net/~ssadetsky/7172652/webrev.00/
>>>> bug: https://bugs.openjdk.java.net/browse/JDK-7172652
>>>>
>>>> ***ROOT CAUSE
>>>> This is a bug in Label UI's key release event processing routine 
>>>> for key mnemonics: only one release event is captured instead of 
>>>> two (Alt release and the mnemonic key release). The Alt release 
>>>> event goes up on hierarchy and is captured by the parent internal 
>>>> frame's menu bar for which Alt key release means selection change 
>>>> event under the Windows system LnF.
>>>>
>>>> ***SOLUTION
>>>> Change key release event handling logic to capture events from both 
>>>> Alt modifier and the key. The logic takes into account that when 
>>>> the first release key event come it transfers focus back to the 
>>>> field so the second key release event should be captured from any 
>>>> window component.
>>>>
>>>> ***TESTING
>>>> A simple scenario is written to exclusively cover the situation.
>>>>
>>>> --Semyon
>>>>
>>>
>>
>



From alexandr.scherbatiy at oracle.com  Thu May 14 11:26:01 2015
From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy)
Date: Thu, 14 May 2015 14:26:01 +0300
Subject: <Swing Dev> [9] Review request for 8033069: mouse wheel scroll
 closes combobox popup
In-Reply-To: <555248AD.1090609@oracle.com>
References: <554A1771.60103@oracle.com> <554A6B49.7000705@oracle.com>
	<554B5B14.40505@oracle.com> <555248AD.1090609@oracle.com>
Message-ID: <55548649.5030802@oracle.com>


   The fix looks good to me.

   Thanks,
   Alexandr.

On 5/12/2015 9:38 PM, Sergey Bylokhov wrote:
> Hi, Alexey.
> Thanks for clarification, the fix looks good.
>
> On 07.05.15 15:31, Alexey Ivanov wrote:
>> Hi Sergey,
>>
>> The changes in BasicPopupMenuUI are similar to handling mouse events 
>> for JMenu. The popup stays open if user rotates wheel over combo box 
>> that opened the popup but the popup will be canceled if wheel is 
>> rotated over another combo box or any other component.
>>
>> The client property "doNotCancelPopup" is set for each combo box 
>> because MOUSE_PRESS logic is in BasicComboPopup.Handler.mousePressed. 
>> If you click another combo box, it will open its own popup which 
>> automatically hides the popup that was visible.
>>
>> In case of MOUSE_WHEEL, combo box over which mouse wheel is rotated 
>> should close the popup of another combo box that opened the popup; 
>> and it should do nothing if its own popup is open. Moving this logic 
>> into JComboBox MouseWheelListener seems too complicated.
>>
>>
>> As for user-installed MouseWheelListener on JComboBox, of course 
>> mouseWheelMoved is called but MouseWheelEvent is already marked 
>> consumed. It might have a negative effect on user code if they check 
>> isConsumed() flag. If the event is not consumed, the popup will be 
>> closed.
>>
>> Regards,
>> Alexey
>>
>> On 06.05.2015 22:28, Sergey Bylokhov wrote:
>>> Hi, Alexey.
>>> The changes in the BasicPopupMenuUI does not look clear, I am not 
>>> sure but probably it will be better to implement it in the same way 
>>> as for MOUSE_PRESSED(via UIManager property)? It will add an 
>>> additional configuration possibility.
>>> Can you also confirm that the case when the user install mouse wheel 
>>> listener to the JComboBox still works.
>>>
>>> On 06.05.15 16:30, Alexey Ivanov wrote:
>>>> Hello Swing team,
>>>>
>>>> Could you please review the fix:
>>>>     bug: https://bugs.openjdk.java.net/browse/JDK-8033069
>>>>     webrev: 
>>>> http://cr.openjdk.java.net/~aivanov/8033069/jdk9/webrev.00/
>>>>
>>>> Description:
>>>> If you rotate mouse wheel when combo box popup is open, the popup 
>>>> gets closed.
>>>>
>>>> The fix is to always consume MOUSE_WHEEL event.
>>>>
>>>> There are two regression tests for the cases where popup has 
>>>> vertical scroll bar and does not have scroll bar.
>>>>
>>>> Thanks,
>>>> Alexey
>>>
>>>
>>> -- 
>>> Best regards, Sergey.
>>
>
>
> -- 
> Best regards, Sergey.



From semyon.sadetsky at oracle.com  Thu May 14 14:12:19 2015
From: semyon.sadetsky at oracle.com (Semyon Sadetsky)
Date: Thu, 14 May 2015 17:12:19 +0300
Subject: <Swing Dev> [9] Review Request for 8078269: JTabbedPane UI Property
 TabbedPane.tabAreaBackground no longer works
Message-ID: <5554AD43.6010702@oracle.com>

Hello,

Please review fix for JDK9:

bug: https://bugs.openjdk.java.net/browse/JDK-8078269
webrev: http://cr.openjdk.java.net/~ssadetsky/8078269/webrev.00/

This is regression of the 8007563 which was incorrect fix of the 4690946 
regression.
Actually the 4690946 was a test bug because tab area's background can be 
controlled separately using "TabbedPane.tabAreaBackground" property.
Presence of "TabbedPane.tabAreaBackground" depends on L&F. Test of the 
4690946 is fixed to take this into account.

Also inappropriate design chosen for the 8007563 reg test code affected 
test results stability. It also has been fixed.

--Semyon


From Sergey.Bylokhov at oracle.com  Thu May 14 14:39:32 2015
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Thu, 14 May 2015 17:39:32 +0300
Subject: <Swing Dev> [9] Review Request for 8078269: JTabbedPane UI
 Property TabbedPane.tabAreaBackground no longer works
In-Reply-To: <5554AD43.6010702@oracle.com>
References: <5554AD43.6010702@oracle.com>
Message-ID: <5554B3A4.70200@oracle.com>

Hi, Semyon.
Usage of background(if it was set) instead of property looks reasonable. 
Please clarify who sets default color of component explicitly to the 
value other than from UI property?

On 14.05.15 17:12, Semyon Sadetsky wrote:
> Hello,
>
> Please review fix for JDK9:
>
> bug: https://bugs.openjdk.java.net/browse/JDK-8078269
> webrev: http://cr.openjdk.java.net/~ssadetsky/8078269/webrev.00/
>
> This is regression of the 8007563 which was incorrect fix of the 
> 4690946 regression.
> Actually the 4690946 was a test bug because tab area's background can 
> be controlled separately using "TabbedPane.tabAreaBackground" property.
> Presence of "TabbedPane.tabAreaBackground" depends on L&F. Test of the 
> 4690946 is fixed to take this into account.
>
> Also inappropriate design chosen for the 8007563 reg test code 
> affected test results stability. It also has been fixed.
>
> --Semyon


-- 
Best regards, Sergey.



From semyon.sadetsky at oracle.com  Thu May 14 15:00:48 2015
From: semyon.sadetsky at oracle.com (Semyon Sadetsky)
Date: Thu, 14 May 2015 18:00:48 +0300
Subject: <Swing Dev> [9] Review Request for 8078269: JTabbedPane UI
 Property TabbedPane.tabAreaBackground no longer works
In-Reply-To: <5554B3A4.70200@oracle.com>
References: <5554AD43.6010702@oracle.com> <5554B3A4.70200@oracle.com>
Message-ID: <5554B8A0.2090900@oracle.com>

Sergey,

Why the component background priority looks reasonable for you?
A component has only one background color which is set by L&F to the 
default value. But it is not enough for the tabbed pane component which 
has more then one background surfaces and L&F can define more background 
colors to paint tabbed pane more precisely. In this case the common 
component background should have second priority.

--Semyon

On 5/14/2015 5:39 PM, Sergey Bylokhov wrote:
> Hi, Semyon.
> Usage of background(if it was set) instead of property looks 
> reasonable. Please clarify who sets default color of component 
> explicitly to the value other than from UI property?
>
> On 14.05.15 17:12, Semyon Sadetsky wrote:
>> Hello,
>>
>> Please review fix for JDK9:
>>
>> bug: https://bugs.openjdk.java.net/browse/JDK-8078269
>> webrev: http://cr.openjdk.java.net/~ssadetsky/8078269/webrev.00/
>>
>> This is regression of the 8007563 which was incorrect fix of the 
>> 4690946 regression.
>> Actually the 4690946 was a test bug because tab area's background can 
>> be controlled separately using "TabbedPane.tabAreaBackground" property.
>> Presence of "TabbedPane.tabAreaBackground" depends on L&F. Test of 
>> the 4690946 is fixed to take this into account.
>>
>> Also inappropriate design chosen for the 8007563 reg test code 
>> affected test results stability. It also has been fixed.
>>
>> --Semyon
>
>



From alexandr.scherbatiy at oracle.com  Thu May 14 15:19:06 2015
From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy)
Date: Thu, 14 May 2015 18:19:06 +0300
Subject: <Swing Dev> [9] Review Request for 7172652: With JDK 1.7 text
 field does not obtain focus when using mnemonic Alt/Key combin
In-Reply-To: <55544DFD.5020407@oracle.com>
References: <55351307.4020504@oracle.com> <553F8B9E.1090904@oracle.com>
	<554C7E44.1050304@oracle.com> <5553688B.4070303@oracle.com>
	<55544DFD.5020407@oracle.com>
Message-ID: <5554BCEA.7010309@oracle.com>


   The fix looks good to me.

   Thanks,
   Alexandr.

On 5/14/2015 10:25 AM, Semyon Sadetsky wrote:
> Alexander, thanks. all is relevant.
> http://cr.openjdk.java.net/~ssadetsky/7172652/webrev.02/
>
> --Semyon
>
>
> On 5/13/2015 6:06 PM, Alexander Scherbatiy wrote:
>> On 5/8/2015 12:13 PM, Semyon Sadetsky wrote:
>>> updated: http://cr.openjdk.java.net/~ssadetsky/7172652/webrev.01/
>>
>>    - Should the labelFor request focus in the method 
>> BasicLabelUI.doRelease(...) as it was before the fix
>>    - There are some formatting problems (space after a method 
>> argument on line 507, bracket on line 534)
>>    -  It seems that inputMap.put() in doPress() method also can be 
>> changed to putOnRelease()
>>    - frame.dispose() also should be called on EDT in the test
>>
>>    Thanks,
>>    Alexandr.
>>
>>>
>>>
>>> On 4/28/2015 4:31 PM, Alexander Scherbatiy wrote:
>>>>
>>>>   Is it possible to make code shorter by adding methods like:
>>>>   putOnRelease(InputMap inputMap, int keyCode, int modifiers)
>>>>   removeOnRelease(InputMap inputMap, int keyCode, int modifiers)
>>>>
>>>>   Thanks,
>>>>   Alexandr.
>>>>
>>>> On 4/20/2015 5:53 PM, Semyon Sadetsky wrote:
>>>>> Hello,
>>>>>
>>>>> please review a fix for JDK9:
>>>>>
>>>>> webrev: http://cr.openjdk.java.net/~ssadetsky/7172652/webrev.00/
>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-7172652
>>>>>
>>>>> ***ROOT CAUSE
>>>>> This is a bug in Label UI's key release event processing routine 
>>>>> for key mnemonics: only one release event is captured instead of 
>>>>> two (Alt release and the mnemonic key release). The Alt release 
>>>>> event goes up on hierarchy and is captured by the parent internal 
>>>>> frame's menu bar for which Alt key release means selection change 
>>>>> event under the Windows system LnF.
>>>>>
>>>>> ***SOLUTION
>>>>> Change key release event handling logic to capture events from 
>>>>> both Alt modifier and the key. The logic takes into account that 
>>>>> when the first release key event come it transfers focus back to 
>>>>> the field so the second key release event should be captured from 
>>>>> any window component.
>>>>>
>>>>> ***TESTING
>>>>> A simple scenario is written to exclusively cover the situation.
>>>>>
>>>>> --Semyon
>>>>>
>>>>
>>>
>>
>



From alexander.potochkin at oracle.com  Thu May 14 17:43:12 2015
From: alexander.potochkin at oracle.com (Alexander Potochkin)
Date: Thu, 14 May 2015 20:43:12 +0300
Subject: <Swing Dev> [9] Review Request: 6368321 MetalRootPaneUI calls
 to deprecated code
In-Reply-To: <554CFF90.4090501@oracle.com>
References: <554CFF90.4090501@oracle.com>
Message-ID: <5554DEB0.1030000@oracle.com>


Looks good.
(although a bit scary:-))

Thanks
alexp
> Hello.
> Please review the fix for jdk9. I do not plan to backport it to jdk8.
>
> Usage of deprecated methods(xxxMenuBar()) were removed as suggested in 
> the bug comments.
> The fix is a part of https://bugs.openjdk.java.net/browse/JDK-8066622 
> efforts.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-6368321
> Webrev can be found at: 
> http://cr.openjdk.java.net/~serb/6368321/webrev.00
>



From Sergey.Bylokhov at oracle.com  Fri May 15 11:06:50 2015
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Fri, 15 May 2015 14:06:50 +0300
Subject: <Swing Dev> [9] Review Request for 8078269: JTabbedPane UI
 Property TabbedPane.tabAreaBackground no longer works
In-Reply-To: <5554B8A0.2090900@oracle.com>
References: <5554AD43.6010702@oracle.com> <5554B3A4.70200@oracle.com>
	<5554B8A0.2090900@oracle.com>
Message-ID: <5555D34A.1070704@oracle.com>

On 14.05.15 18:00, Semyon Sadetsky wrote:
> Sergey,
>
> Why the component background priority looks reasonable for you?
Because otherwise there is no way to change the color of one particular 
component.
> A component has only one background color which is set by L&F to the 
> default value. But it is not enough for the tabbed pane component 
> which has more then one background surfaces and L&F can define more 
> background colors to paint tabbed pane more precisely. In this case 
> the common component background should have second priority.
What is the difference between "TabbedPane.background" and 
"TabbedPane.tabAreaBackground" in the metal l&f?
>
> --Semyon
>
> On 5/14/2015 5:39 PM, Sergey Bylokhov wrote:
>> Hi, Semyon.
>> Usage of background(if it was set) instead of property looks 
>> reasonable. Please clarify who sets default color of component 
>> explicitly to the value other than from UI property?
>>
>> On 14.05.15 17:12, Semyon Sadetsky wrote:
>>> Hello,
>>>
>>> Please review fix for JDK9:
>>>
>>> bug: https://bugs.openjdk.java.net/browse/JDK-8078269
>>> webrev: http://cr.openjdk.java.net/~ssadetsky/8078269/webrev.00/
>>>
>>> This is regression of the 8007563 which was incorrect fix of the 
>>> 4690946 regression.
>>> Actually the 4690946 was a test bug because tab area's background 
>>> can be controlled separately using "TabbedPane.tabAreaBackground" 
>>> property.
>>> Presence of "TabbedPane.tabAreaBackground" depends on L&F. Test of 
>>> the 4690946 is fixed to take this into account.
>>>
>>> Also inappropriate design chosen for the 8007563 reg test code 
>>> affected test results stability. It also has been fixed.
>>>
>>> --Semyon
>>
>>
>


-- 
Best regards, Sergey.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/swing-dev/attachments/20150515/41b2e121/attachment.html>

From semyon.sadetsky at oracle.com  Fri May 15 12:10:22 2015
From: semyon.sadetsky at oracle.com (Semyon Sadetsky)
Date: Fri, 15 May 2015 15:10:22 +0300
Subject: <Swing Dev> [9] Review Request for 8078269: JTabbedPane UI
 Property TabbedPane.tabAreaBackground no longer works
In-Reply-To: <5555D34A.1070704@oracle.com>
References: <5554AD43.6010702@oracle.com> <5554B3A4.70200@oracle.com>
	<5554B8A0.2090900@oracle.com> <5555D34A.1070704@oracle.com>
Message-ID: <5555E22E.6090803@oracle.com>


On 5/15/2015 2:06 PM, Sergey Bylokhov wrote:
> On 14.05.15 18:00, Semyon Sadetsky wrote:
>> Sergey,
>>
>> Why the component background priority looks reasonable for you?
> Because otherwise there is no way to change the color of one 
> particular component.
>> A component has only one background color which is set by L&F to the 
>> default value. But it is not enough for the tabbed pane component 
>> which has more then one background surfaces and L&F can define more 
>> background colors to paint tabbed pane more precisely. In this case 
>> the common component background should have second priority.
> What is the difference between "TabbedPane.background" and 
> "TabbedPane.tabAreaBackground" in the metal l&f? 
"TabbedPane.background" is the default background.

>>
>> --Semyon
>>
>> On 5/14/2015 5:39 PM, Sergey Bylokhov wrote:
>>> Hi, Semyon.
>>> Usage of background(if it was set) instead of property looks 
>>> reasonable. Please clarify who sets default color of component 
>>> explicitly to the value other than from UI property?
>>>
>>> On 14.05.15 17:12, Semyon Sadetsky wrote:
>>>> Hello,
>>>>
>>>> Please review fix for JDK9:
>>>>
>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8078269
>>>> webrev: http://cr.openjdk.java.net/~ssadetsky/8078269/webrev.00/
>>>>
>>>> This is regression of the 8007563 which was incorrect fix of the 
>>>> 4690946 regression.
>>>> Actually the 4690946 was a test bug because tab area's background 
>>>> can be controlled separately using "TabbedPane.tabAreaBackground" 
>>>> property.
>>>> Presence of "TabbedPane.tabAreaBackground" depends on L&F. Test of 
>>>> the 4690946 is fixed to take this into account.
>>>>
>>>> Also inappropriate design chosen for the 8007563 reg test code 
>>>> affected test results stability. It also has been fixed.
>>>>
>>>> --Semyon
>>>
>>>
>>
>
>
> -- 
> Best regards, Sergey.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/swing-dev/attachments/20150515/5c606127/attachment.html>

From alexander.zvegintsev at oracle.com  Fri May 15 13:52:07 2015
From: alexander.zvegintsev at oracle.com (Alexander Zvegintsev)
Date: Fri, 15 May 2015 16:52:07 +0300
Subject: <Swing Dev> [9] Review Request for 7172652: With JDK 1.7 text
 field does not obtain focus when using mnemonic Alt/Key combin
In-Reply-To: <55544DFD.5020407@oracle.com>
References: <55351307.4020504@oracle.com> <553F8B9E.1090904@oracle.com>
	<554C7E44.1050304@oracle.com> <5553688B.4070303@oracle.com>
	<55544DFD.5020407@oracle.com>
Message-ID: <5555FA07.6080609@oracle.com>

Hello Semyon,

the fix looks good to me, just a minor comment:
It seems to me that putOnRelease() is not a relevant name for this 
function,
since we call it on press too.

Thanks,

Alexander.

On 05/14/2015 10:25 AM, Semyon Sadetsky wrote:
> Alexander, thanks. all is relevant.
> http://cr.openjdk.java.net/~ssadetsky/7172652/webrev.02/
>
> --Semyon
>
>
> On 5/13/2015 6:06 PM, Alexander Scherbatiy wrote:
>> On 5/8/2015 12:13 PM, Semyon Sadetsky wrote:
>>> updated: http://cr.openjdk.java.net/~ssadetsky/7172652/webrev.01/
>>
>>    - Should the labelFor request focus in the method 
>> BasicLabelUI.doRelease(...) as it was before the fix
>>    - There are some formatting problems (space after a method 
>> argument on line 507, bracket on line 534)
>>    -  It seems that inputMap.put() in doPress() method also can be 
>> changed to putOnRelease()
>>    - frame.dispose() also should be called on EDT in the test
>>
>>    Thanks,
>>    Alexandr.
>>
>>>
>>>
>>> On 4/28/2015 4:31 PM, Alexander Scherbatiy wrote:
>>>>
>>>>   Is it possible to make code shorter by adding methods like:
>>>>   putOnRelease(InputMap inputMap, int keyCode, int modifiers)
>>>>   removeOnRelease(InputMap inputMap, int keyCode, int modifiers)
>>>>
>>>>   Thanks,
>>>>   Alexandr.
>>>>
>>>> On 4/20/2015 5:53 PM, Semyon Sadetsky wrote:
>>>>> Hello,
>>>>>
>>>>> please review a fix for JDK9:
>>>>>
>>>>> webrev: http://cr.openjdk.java.net/~ssadetsky/7172652/webrev.00/
>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-7172652
>>>>>
>>>>> ***ROOT CAUSE
>>>>> This is a bug in Label UI's key release event processing routine 
>>>>> for key mnemonics: only one release event is captured instead of 
>>>>> two (Alt release and the mnemonic key release). The Alt release 
>>>>> event goes up on hierarchy and is captured by the parent internal 
>>>>> frame's menu bar for which Alt key release means selection change 
>>>>> event under the Windows system LnF.
>>>>>
>>>>> ***SOLUTION
>>>>> Change key release event handling logic to capture events from 
>>>>> both Alt modifier and the key. The logic takes into account that 
>>>>> when the first release key event come it transfers focus back to 
>>>>> the field so the second key release event should be captured from 
>>>>> any window component.
>>>>>
>>>>> ***TESTING
>>>>> A simple scenario is written to exclusively cover the situation.
>>>>>
>>>>> --Semyon
>>>>>
>>>>
>>>
>>
>



From semyon.sadetsky at oracle.com  Fri May 15 14:49:42 2015
From: semyon.sadetsky at oracle.com (Semyon Sadetsky)
Date: Fri, 15 May 2015 17:49:42 +0300
Subject: <Swing Dev> [9] Review Request for 8078514: Nightly:
 api/javax_swing/DefaultRowSorter/index_ModelStructChanged failure
Message-ID: <55560786.9010306@oracle.com>

Hello,

Please review fix for JDK9:

bug: https://bugs.openjdk.java.net/browse/JDK-8078514
webrev: http://cr.openjdk.java.net/~ssadetsky/8078514/webrev.00/

The 6894632 fix violated a contract between the table and its row 
sorter: the sorter should receive TableChanged events even if table is 
not sorted actually.
Another way to fix 6894632 is to initialize sorter internal structures 
instantly. The last is applied in the fix.

--Semyon



From javalists at cbfiddle.com  Fri May 15 19:09:56 2015
From: javalists at cbfiddle.com (Alan Snyder)
Date: Fri, 15 May 2015 12:09:56 -0700
Subject: <Swing Dev> customizing L&Fs in JDK9
Message-ID: <72C9A743-CF07-4B84-9E8D-A6A5FF99A536@cbfiddle.com>

If my understanding is correct, the classes for several JDK specific L&Fs (Aqua, GTK, and Windows) will become inaccessible to applications in JDK9. Is this true?

I am concerned about the impact of this change for the Aqua look and feel, which historically has lagged behind the platform UI and continues to do so (although progress has been made) and for which both small and large customizations have been written. Blocking access to the Aqua look and feel classes will make such customizations much more difficult, possibly even impossible if native code is involved.

While I understand the desire to protect applications from depending upon JDK specific code, the benefit of this restriction seems small. After all, how many JDK implementations are there for desktop applications on OS X? The current OS X application architecture bundles a JRE in each application, so JDK changes will not break installed applications.



From philip.race at oracle.com  Fri May 15 19:49:06 2015
From: philip.race at oracle.com (Phil Race)
Date: Fri, 15 May 2015 12:49:06 -0700
Subject: <Swing Dev> customizing L&Fs in JDK9
In-Reply-To: <72C9A743-CF07-4B84-9E8D-A6A5FF99A536@cbfiddle.com>
References: <72C9A743-CF07-4B84-9E8D-A6A5FF99A536@cbfiddle.com>
Message-ID: <55564DB2.5070700@oracle.com>

My understanding is that the Aqua L&F classes are already inaccessible
if there's a SecurityManager so its not a completely new thing.
Whilst there may be ways around the JDK9 restrictions, what internal 
Aqua APIs do you need
to customise ? And how do you deliver those customisations ?

We are already looking at finding ways to expose some com.apple APIs in 
a supported way as Java APIs.
Perhaps something in Aqua can be fixed, or perhaps exposed - perhaps 
being a key word.

Note that bundling a JRE is not the same thing as building your own & 
bundling.
I expect most applications will want to work with a pre-built Oracle JDK 
which will hide internal APIs.

Perhaps



On 5/15/2015 12:09 PM, Alan Snyder wrote:
> If my understanding is correct, the classes for several JDK specific L&Fs (Aqua, GTK, and Windows) will become inaccessible to applications in JDK9. Is this true?
>
> I am concerned about the impact of this change for the Aqua look and feel, which historically has lagged behind the platform UI and continues to do so (although progress has been made) and for which both small and large customizations have been written. Blocking access to the Aqua look and feel classes will make such customizations much more difficult, possibly even impossible if native code is involved.
>
> While I understand the desire to protect applications from depending upon JDK specific code, the benefit of this restriction seems small. After all, how many JDK implementations are there for desktop applications on OS X? The current OS X application architecture bundles a JRE in each application, so JDK changes will not break installed applications.
>



From javalists at cbfiddle.com  Fri May 15 20:10:10 2015
From: javalists at cbfiddle.com (Alan Snyder)
Date: Fri, 15 May 2015 13:10:10 -0700
Subject: <Swing Dev> customizing L&Fs in JDK9
In-Reply-To: <55564DB2.5070700@oracle.com>
References: <72C9A743-CF07-4B84-9E8D-A6A5FF99A536@cbfiddle.com>
	<55564DB2.5070700@oracle.com>
Message-ID: <F85EBC47-5E18-4B3C-AC9F-456EA3159632@cbfiddle.com>

Bundled apps run without a Security Manager, at least they do for me. Users have higher expectations for bundled apps.

The customizations are delivered via a JAR file (and perhaps a JNI library). No need to build a custom JRE.

These are some of the APIs that I know have been used by L&F customizations:

      -> sun.font.CFontManager                              JDK internal API (rt.jar)
      -> sun.font.FontManager                               JDK internal API (rt.jar)
      -> sun.font.FontManagerFactory                        JDK internal API (rt.jar)
      -> com.apple.laf.AquaHighlighter                      JDK internal API (rt.jar)
      -> com.apple.laf.AquaHighlighter$AquaHighlightPainter JDK internal API (rt.jar)
      -> sun.awt.AppContext                                 JDK internal API (rt.jar)
      -> sun.swing.UIAction                                 JDK internal API (rt.jar)
      -> sun.awt.SunToolkit                                 JDK internal API (rt.jar)
      -> com.apple.laf.AquaTableHeaderUI                    JDK internal API (rt.jar)
      -> apple.laf.JRSUIConstants                           JDK internal API (rt.jar)
      -> apple.laf.JRSUIConstants$Orientation               JDK internal API (rt.jar)
      -> apple.laf.JRSUIConstants$State                     JDK internal API (rt.jar)
      -> apple.laf.JRSUIConstants$Size                      JDK internal API (rt.jar)
      -> com.apple.laf.AquaSliderUI                         JDK internal API (rt.jar)
      -> com.apple.laf.AquaTreeUI                           JDK internal API (rt.jar)
      -> com.apple.laf.AquaButtonUI                         JDK internal API (rt.jar)
      -> com.apple.laf.AquaComboBoxUI                       JDK internal API (rt.jar)
      -> com.apple.laf.AquaButtonBorder                     JDK internal API (rt.jar)
      -> com.apple.laf.AquaButtonBorder$Dynamic             JDK internal API (rt.jar)
      -> com.apple.laf.AquaUtilControlSize                  JDK internal API (rt.jar)
      -> com.apple.laf.AquaUtilControlSize$SizeDescriptor   JDK internal API (rt.jar)
      -> com.apple.laf.AquaUtilControlSize$SizeVariant      JDK internal API (rt.jar)
      -> com.apple.laf.AquaBorder                           JDK internal API (rt.jar)
      -> com.apple.laf.AquaListUI                           JDK internal API (rt.jar)
      -> com.apple.laf.AquaPanelUI                          JDK internal API (rt.jar)
      -> com.apple.laf.AquaSplitPaneDividerUI               JDK internal API (rt.jar)
      -> com.apple.laf.AquaSplitPaneUI                      JDK internal API (rt.jar)
      -> com.apple.laf.AquaTabbedPaneUI                     JDK internal API (rt.jar)
      -> com.apple.laf.AquaFocusHandler                     JDK internal API (rt.jar)
      -> com.apple.laf.AquaTableUI                          JDK internal API (rt.jar)
      -> com.apple.laf.AquaFocusHandler                     JDK internal API (rt.jar)
      -> com.apple.laf.AquaButtonToggleUI                   JDK internal API (rt.jar)
      -> com.apple.laf.AquaUtilControlSize                  JDK internal API (rt.jar)
      -> com.apple.laf.AquaUtilControlSize$PropertySizeListener JDK internal API (rt.jar)
      -> com.sun.java.swing.Painter                         JDK internal API (rt.jar)

Probably more would be except that they are package private.

A list of all the things that need fixing in the Aqua L&F would be very long, and not worth creating if there is no support for such a large effort.

As just one example, consider that Yosemite has been out for quite a while now and Java is still using Mavericks rendering on Yosemite.

  Alan


> On May 15, 2015, at 12:49 PM, Phil Race <philip.race at oracle.com> wrote:
> 
> My understanding is that the Aqua L&F classes are already inaccessible
> if there's a SecurityManager so its not a completely new thing.
> Whilst there may be ways around the JDK9 restrictions, what internal Aqua APIs do you need
> to customise ? And how do you deliver those customisations ?
> 
> We are already looking at finding ways to expose some com.apple APIs in a supported way as Java APIs.
> Perhaps something in Aqua can be fixed, or perhaps exposed - perhaps being a key word.
> 
> Note that bundling a JRE is not the same thing as building your own & bundling.
> I expect most applications will want to work with a pre-built Oracle JDK which will hide internal APIs.
> 
> Perhaps
> 
> 
> 
> On 5/15/2015 12:09 PM, Alan Snyder wrote:
>> If my understanding is correct, the classes for several JDK specific L&Fs (Aqua, GTK, and Windows) will become inaccessible to applications in JDK9. Is this true?
>> 
>> I am concerned about the impact of this change for the Aqua look and feel, which historically has lagged behind the platform UI and continues to do so (although progress has been made) and for which both small and large customizations have been written. Blocking access to the Aqua look and feel classes will make such customizations much more difficult, possibly even impossible if native code is involved.
>> 
>> While I understand the desire to protect applications from depending upon JDK specific code, the benefit of this restriction seems small. After all, how many JDK implementations are there for desktop applications on OS X? The current OS X application architecture bundles a JRE in each application, so JDK changes will not break installed applications.
>> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/swing-dev/attachments/20150515/48198b01/attachment.html>

From Sergey.Bylokhov at oracle.com  Fri May 15 20:44:54 2015
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Fri, 15 May 2015 23:44:54 +0300
Subject: <Swing Dev> customizing L&Fs in JDK9
In-Reply-To: <F85EBC47-5E18-4B3C-AC9F-456EA3159632@cbfiddle.com>
References: <72C9A743-CF07-4B84-9E8D-A6A5FF99A536@cbfiddle.com>	<55564DB2.5070700@oracle.com>
	<F85EBC47-5E18-4B3C-AC9F-456EA3159632@cbfiddle.com>
Message-ID: <55565AC6.6080909@oracle.com>

Hi, Alan.
Why this kind of customizations cannot be integrated to the jdk8/jdk9 
directly?
> As just one example, consider that Yosemite has been out for quite a 
> while now and Java is still using Mavericks rendering on Yosemite.
Any patches which improve appearance of jdk on Yosemite are welcome.
>
>   Alan
>
>
>> On May 15, 2015, at 12:49 PM, Phil Race <philip.race at oracle.com 
>> <mailto:philip.race at oracle.com>> wrote:
>>
>> My understanding is that the Aqua L&F classes are already inaccessible
>> if there's a SecurityManager so its not a completely new thing.
>> Whilst there may be ways around the JDK9 restrictions, what internal 
>> Aqua APIs do you need
>> to customise ? And how do you deliver those customisations ?
>>
>> We are already looking at finding ways to expose some com.apple APIs 
>> in a supported way as Java APIs.
>> Perhaps something in Aqua can be fixed, or perhaps exposed - perhaps 
>> being a key word.
>>
>> Note that bundling a JRE is not the same thing as building your own & 
>> bundling.
>> I expect most applications will want to work with a pre-built Oracle 
>> JDK which will hide internal APIs.
>>
>> Perhaps
>>
>>
>>
>> On 5/15/2015 12:09 PM, Alan Snyder wrote:
>>> If my understanding is correct, the classes for several JDK specific 
>>> L&Fs (Aqua, GTK, and Windows) will become inaccessible to 
>>> applications in JDK9. Is this true?
>>>
>>> I am concerned about the impact of this change for the Aqua look and 
>>> feel, which historically has lagged behind the platform UI and 
>>> continues to do so (although progress has been made) and for which 
>>> both small and large customizations have been written. Blocking 
>>> access to the Aqua look and feel classes will make such 
>>> customizations much more difficult, possibly even impossible if 
>>> native code is involved.
>>>
>>> While I understand the desire to protect applications from depending 
>>> upon JDK specific code, the benefit of this restriction seems small. 
>>> After all, how many JDK implementations are there for desktop 
>>> applications on OS X? The current OS X application architecture 
>>> bundles a JRE in each application, so JDK changes will not break 
>>> installed applications.
>>>
>>
>


-- 
Best regards, Sergey.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/swing-dev/attachments/20150515/7cc5301d/attachment.html>

From philip.race at oracle.com  Fri May 15 21:22:17 2015
From: philip.race at oracle.com (Phil Race)
Date: Fri, 15 May 2015 14:22:17 -0700
Subject: <Swing Dev> customizing L&Fs in JDK9
In-Reply-To: <F85EBC47-5E18-4B3C-AC9F-456EA3159632@cbfiddle.com>
References: <72C9A743-CF07-4B84-9E8D-A6A5FF99A536@cbfiddle.com>
	<55564DB2.5070700@oracle.com>
	<F85EBC47-5E18-4B3C-AC9F-456EA3159632@cbfiddle.com>
Message-ID: <55566389.5010608@oracle.com>

Hi,

The sun.* classes are definitely considered to be out of bounds on all 
platforms.
For the apple "laf" ones that is a very long list that is being customised.
It seems a lot of work to do that outside the JDK and I echo Sergey's 
comments
that if these are changes which would benefit other users they are best
delivered back into OpenJDK
And the technique for delivering the changes in a jar on the class path 
will not
work with the modular JDK even if we made all of these classes public and
exported .. jigsaw does not allow such split packages.

-phil.

On 5/15/2015 1:10 PM, Alan Snyder wrote:
> Bundled apps run without a Security Manager, at least they do for me. 
> Users have higher expectations for bundled apps.
>
> The customizations are delivered via a JAR file (and perhaps a JNI 
> library). No need to build a custom JRE.
>
> These are some of the APIs that I know have been used by L&F 
> customizations:
>
>       -> sun.font.CFontManager                              JDK 
> internal API (rt.jar)
>       -> sun.font.FontManager                               JDK 
> internal API (rt.jar)
>       -> sun.font.FontManagerFactory                        JDK 
> internal API (rt.jar)
>       -> com.apple.laf.AquaHighlighter                      JDK 
> internal API (rt.jar)
>       -> com.apple.laf.AquaHighlighter$AquaHighlightPainter JDK 
> internal API (rt.jar)
>       -> sun.awt.AppContext                                 JDK 
> internal API (rt.jar)
>       -> sun.swing.UIAction                                 JDK 
> internal API (rt.jar)
>       -> sun.awt.SunToolkit                                 JDK 
> internal API (rt.jar)
>       -> com.apple.laf.AquaTableHeaderUI                    JDK 
> internal API (rt.jar)
>       -> apple.laf.JRSUIConstants                           JDK 
> internal API (rt.jar)
>       -> apple.laf.JRSUIConstants$Orientation               JDK 
> internal API (rt.jar)
>       -> apple.laf.JRSUIConstants$State                     JDK 
> internal API (rt.jar)
>       -> apple.laf.JRSUIConstants$Size                      JDK 
> internal API (rt.jar)
>       -> com.apple.laf.AquaSliderUI                         JDK 
> internal API (rt.jar)
>       -> com.apple.laf.AquaTreeUI                           JDK 
> internal API (rt.jar)
>       -> com.apple.laf.AquaButtonUI                         JDK 
> internal API (rt.jar)
>       -> com.apple.laf.AquaComboBoxUI                       JDK 
> internal API (rt.jar)
>       -> com.apple.laf.AquaButtonBorder                     JDK 
> internal API (rt.jar)
>       -> com.apple.laf.AquaButtonBorder$Dynamic             JDK 
> internal API (rt.jar)
>       -> com.apple.laf.AquaUtilControlSize                  JDK 
> internal API (rt.jar)
>       -> com.apple.laf.AquaUtilControlSize$SizeDescriptor   JDK 
> internal API (rt.jar)
>       -> com.apple.laf.AquaUtilControlSize$SizeVariant      JDK 
> internal API (rt.jar)
>       -> com.apple.laf.AquaBorder                           JDK 
> internal API (rt.jar)
>       -> com.apple.laf.AquaListUI                           JDK 
> internal API (rt.jar)
>       -> com.apple.laf.AquaPanelUI                          JDK 
> internal API (rt.jar)
>       -> com.apple.laf.AquaSplitPaneDividerUI               JDK 
> internal API (rt.jar)
>       -> com.apple.laf.AquaSplitPaneUI                      JDK 
> internal API (rt.jar)
>       -> com.apple.laf.AquaTabbedPaneUI                     JDK 
> internal API (rt.jar)
>       -> com.apple.laf.AquaFocusHandler                     JDK 
> internal API (rt.jar)
>       -> com.apple.laf.AquaTableUI                          JDK 
> internal API (rt.jar)
>       -> com.apple.laf.AquaFocusHandler                     JDK 
> internal API (rt.jar)
>       -> com.apple.laf.AquaButtonToggleUI                   JDK 
> internal API (rt.jar)
>       -> com.apple.laf.AquaUtilControlSize                  JDK 
> internal API (rt.jar)
>       -> com.apple.laf.AquaUtilControlSize$PropertySizeListener JDK 
> internal API (rt.jar)
>       -> com.sun.java.swing.Painter                         JDK 
> internal API (rt.jar)
>
> Probably more would be except that they are package private.
>
> A list of all the things that need fixing in the Aqua L&F would be 
> very long, and not worth creating if there is no support for such a 
> large effort.
>
> As just one example, consider that Yosemite has been out for quite a 
> while now and Java is still using Mavericks rendering on Yosemite.
>
>   Alan
>
>
>> On May 15, 2015, at 12:49 PM, Phil Race <philip.race at oracle.com 
>> <mailto:philip.race at oracle.com>> wrote:
>>
>> My understanding is that the Aqua L&F classes are already inaccessible
>> if there's a SecurityManager so its not a completely new thing.
>> Whilst there may be ways around the JDK9 restrictions, what internal 
>> Aqua APIs do you need
>> to customise ? And how do you deliver those customisations ?
>>
>> We are already looking at finding ways to expose some com.apple APIs 
>> in a supported way as Java APIs.
>> Perhaps something in Aqua can be fixed, or perhaps exposed - perhaps 
>> being a key word.
>>
>> Note that bundling a JRE is not the same thing as building your own & 
>> bundling.
>> I expect most applications will want to work with a pre-built Oracle 
>> JDK which will hide internal APIs.
>>
>> Perhaps
>>
>>
>>
>> On 5/15/2015 12:09 PM, Alan Snyder wrote:
>>> If my understanding is correct, the classes for several JDK specific 
>>> L&Fs (Aqua, GTK, and Windows) will become inaccessible to 
>>> applications in JDK9. Is this true?
>>>
>>> I am concerned about the impact of this change for the Aqua look and 
>>> feel, which historically has lagged behind the platform UI and 
>>> continues to do so (although progress has been made) and for which 
>>> both small and large customizations have been written. Blocking 
>>> access to the Aqua look and feel classes will make such 
>>> customizations much more difficult, possibly even impossible if 
>>> native code is involved.
>>>
>>> While I understand the desire to protect applications from depending 
>>> upon JDK specific code, the benefit of this restriction seems small. 
>>> After all, how many JDK implementations are there for desktop 
>>> applications on OS X? The current OS X application architecture 
>>> bundles a JRE in each application, so JDK changes will not break 
>>> installed applications.
>>>
>>
>



From javalists at cbfiddle.com  Fri May 15 21:27:02 2015
From: javalists at cbfiddle.com (Alan Snyder)
Date: Fri, 15 May 2015 14:27:02 -0700
Subject: <Swing Dev> customizing L&Fs in JDK9
In-Reply-To: <55566389.5010608@oracle.com>
References: <72C9A743-CF07-4B84-9E8D-A6A5FF99A536@cbfiddle.com>
	<55564DB2.5070700@oracle.com>
	<F85EBC47-5E18-4B3C-AC9F-456EA3159632@cbfiddle.com>
	<55566389.5010608@oracle.com>
Message-ID: <C07AE102-45D1-43E8-9E17-16152591B22C@cbfiddle.com>

Sorry for any confusion, but there are no split packages. A new L&F is created with subclasses/uses class from the Aqua L&F.

  Alan

> On May 15, 2015, at 2:22 PM, Phil Race <philip.race at oracle.com> wrote:
> 
> Hi,
> 
> The sun.* classes are definitely considered to be out of bounds on all platforms.
> For the apple "laf" ones that is a very long list that is being customised.
> It seems a lot of work to do that outside the JDK and I echo Sergey's comments
> that if these are changes which would benefit other users they are best
> delivered back into OpenJDK
> And the technique for delivering the changes in a jar on the class path will not
> work with the modular JDK even if we made all of these classes public and
> exported .. jigsaw does not allow such split packages.
> 
> -phil.
> 
> On 5/15/2015 1:10 PM, Alan Snyder wrote:
>> Bundled apps run without a Security Manager, at least they do for me. Users have higher expectations for bundled apps.
>> 
>> The customizations are delivered via a JAR file (and perhaps a JNI library). No need to build a custom JRE.
>> 
>> These are some of the APIs that I know have been used by L&F customizations:
>> 
>>      -> sun.font.CFontManager                              JDK internal API (rt.jar)
>>      -> sun.font.FontManager                               JDK internal API (rt.jar)
>>      -> sun.font.FontManagerFactory                        JDK internal API (rt.jar)
>>      -> com.apple.laf.AquaHighlighter                      JDK internal API (rt.jar)
>>      -> com.apple.laf.AquaHighlighter$AquaHighlightPainter JDK internal API (rt.jar)
>>      -> sun.awt.AppContext                                 JDK internal API (rt.jar)
>>      -> sun.swing.UIAction                                 JDK internal API (rt.jar)
>>      -> sun.awt.SunToolkit                                 JDK internal API (rt.jar)
>>      -> com.apple.laf.AquaTableHeaderUI                    JDK internal API (rt.jar)
>>      -> apple.laf.JRSUIConstants                           JDK internal API (rt.jar)
>>      -> apple.laf.JRSUIConstants$Orientation               JDK internal API (rt.jar)
>>      -> apple.laf.JRSUIConstants$State                     JDK internal API (rt.jar)
>>      -> apple.laf.JRSUIConstants$Size                      JDK internal API (rt.jar)
>>      -> com.apple.laf.AquaSliderUI                         JDK internal API (rt.jar)
>>      -> com.apple.laf.AquaTreeUI                           JDK internal API (rt.jar)
>>      -> com.apple.laf.AquaButtonUI                         JDK internal API (rt.jar)
>>      -> com.apple.laf.AquaComboBoxUI                       JDK internal API (rt.jar)
>>      -> com.apple.laf.AquaButtonBorder                     JDK internal API (rt.jar)
>>      -> com.apple.laf.AquaButtonBorder$Dynamic             JDK internal API (rt.jar)
>>      -> com.apple.laf.AquaUtilControlSize                  JDK internal API (rt.jar)
>>      -> com.apple.laf.AquaUtilControlSize$SizeDescriptor   JDK internal API (rt.jar)
>>      -> com.apple.laf.AquaUtilControlSize$SizeVariant      JDK internal API (rt.jar)
>>      -> com.apple.laf.AquaBorder                           JDK internal API (rt.jar)
>>      -> com.apple.laf.AquaListUI                           JDK internal API (rt.jar)
>>      -> com.apple.laf.AquaPanelUI                          JDK internal API (rt.jar)
>>      -> com.apple.laf.AquaSplitPaneDividerUI               JDK internal API (rt.jar)
>>      -> com.apple.laf.AquaSplitPaneUI                      JDK internal API (rt.jar)
>>      -> com.apple.laf.AquaTabbedPaneUI                     JDK internal API (rt.jar)
>>      -> com.apple.laf.AquaFocusHandler                     JDK internal API (rt.jar)
>>      -> com.apple.laf.AquaTableUI                          JDK internal API (rt.jar)
>>      -> com.apple.laf.AquaFocusHandler                     JDK internal API (rt.jar)
>>      -> com.apple.laf.AquaButtonToggleUI                   JDK internal API (rt.jar)
>>      -> com.apple.laf.AquaUtilControlSize                  JDK internal API (rt.jar)
>>      -> com.apple.laf.AquaUtilControlSize$PropertySizeListener JDK internal API (rt.jar)
>>      -> com.sun.java.swing.Painter                         JDK internal API (rt.jar)
>> 
>> Probably more would be except that they are package private.
>> 
>> A list of all the things that need fixing in the Aqua L&F would be very long, and not worth creating if there is no support for such a large effort.
>> 
>> As just one example, consider that Yosemite has been out for quite a while now and Java is still using Mavericks rendering on Yosemite.
>> 
>>  Alan
>> 
>> 
>>> On May 15, 2015, at 12:49 PM, Phil Race <philip.race at oracle.com <mailto:philip.race at oracle.com> <mailto:philip.race at oracle.com <mailto:philip.race at oracle.com>>> wrote:
>>> 
>>> My understanding is that the Aqua L&F classes are already inaccessible
>>> if there's a SecurityManager so its not a completely new thing.
>>> Whilst there may be ways around the JDK9 restrictions, what internal Aqua APIs do you need
>>> to customise ? And how do you deliver those customisations ?
>>> 
>>> We are already looking at finding ways to expose some com.apple APIs in a supported way as Java APIs.
>>> Perhaps something in Aqua can be fixed, or perhaps exposed - perhaps being a key word.
>>> 
>>> Note that bundling a JRE is not the same thing as building your own & bundling.
>>> I expect most applications will want to work with a pre-built Oracle JDK which will hide internal APIs.
>>> 
>>> Perhaps
>>> 
>>> 
>>> 
>>> On 5/15/2015 12:09 PM, Alan Snyder wrote:
>>>> If my understanding is correct, the classes for several JDK specific L&Fs (Aqua, GTK, and Windows) will become inaccessible to applications in JDK9. Is this true?
>>>> 
>>>> I am concerned about the impact of this change for the Aqua look and feel, which historically has lagged behind the platform UI and continues to do so (although progress has been made) and for which both small and large customizations have been written. Blocking access to the Aqua look and feel classes will make such customizations much more difficult, possibly even impossible if native code is involved.
>>>> 
>>>> While I understand the desire to protect applications from depending upon JDK specific code, the benefit of this restriction seems small. After all, how many JDK implementations are there for desktop applications on OS X? The current OS X application architecture bundles a JRE in each application, so JDK changes will not break installed applications.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/swing-dev/attachments/20150515/81009ff9/attachment.html>

From javalists at cbfiddle.com  Fri May 15 21:35:18 2015
From: javalists at cbfiddle.com (Alan Snyder)
Date: Fri, 15 May 2015 14:35:18 -0700
Subject: <Swing Dev> customizing L&Fs in JDK9
In-Reply-To: <55565AC6.6080909@oracle.com>
References: <72C9A743-CF07-4B84-9E8D-A6A5FF99A536@cbfiddle.com>
	<55564DB2.5070700@oracle.com>
	<F85EBC47-5E18-4B3C-AC9F-456EA3159632@cbfiddle.com>
	<55565AC6.6080909@oracle.com>
Message-ID: <DA0EF126-A3EC-44FA-B057-7536DFB8EADC@cbfiddle.com>

I have been looking into the possibility of integrating changes into the JDK. I agree that would be the best outcome, although I also believe the list of potential changes is so large that it would be good to give developers the opportunity of making the customization that matters most to them.

Why not make the Aqua L&F a separate module?

The most pressing issue is that the Aqua L&F uses an Apple provided library that supports native rendering, and a change is needed in that library to use Yosemite native rendering on Yosemite. (You might think that would happen automatically, so I guess it is a bug that it does not.)

The other issue is that some of the customizations use various open source packages with multiple authors and licensing.

  Alan




> On May 15, 2015, at 1:44 PM, Sergey Bylokhov <Sergey.Bylokhov at oracle.com> wrote:
> 
> Hi, Alan.
> Why this kind of customizations cannot be integrated to the jdk8/jdk9 directly?
>> As just one example, consider that Yosemite has been out for quite a while now and Java is still using Mavericks rendering on Yosemite.
> Any patches which improve appearance of jdk on Yosemite are welcome.
>> 
>>   Alan
>> 
>> 
>>> On May 15, 2015, at 12:49 PM, Phil Race <philip.race at oracle.com <mailto:philip.race at oracle.com>> wrote:
>>> 
>>> My understanding is that the Aqua L&F classes are already inaccessible
>>> if there's a SecurityManager so its not a completely new thing.
>>> Whilst there may be ways around the JDK9 restrictions, what internal Aqua APIs do you need
>>> to customise ? And how do you deliver those customisations ?
>>> 
>>> We are already looking at finding ways to expose some com.apple APIs in a supported way as Java APIs.
>>> Perhaps something in Aqua can be fixed, or perhaps exposed - perhaps being a key word.
>>> 
>>> Note that bundling a JRE is not the same thing as building your own & bundling.
>>> I expect most applications will want to work with a pre-built Oracle JDK which will hide internal APIs.
>>> 
>>> Perhaps
>>> 
>>> 
>>> 
>>> On 5/15/2015 12:09 PM, Alan Snyder wrote:
>>>> If my understanding is correct, the classes for several JDK specific L&Fs (Aqua, GTK, and Windows) will become inaccessible to applications in JDK9. Is this true?
>>>> 
>>>> I am concerned about the impact of this change for the Aqua look and feel, which historically has lagged behind the platform UI and continues to do so (although progress has been made) and for which both small and large customizations have been written. Blocking access to the Aqua look and feel classes will make such customizations much more difficult, possibly even impossible if native code is involved.
>>>> 
>>>> While I understand the desire to protect applications from depending upon JDK specific code, the benefit of this restriction seems small. After all, how many JDK implementations are there for desktop applications on OS X? The current OS X application architecture bundles a JRE in each application, so JDK changes will not break installed applications.
>>>> 
>>> 
>> 
> 
> 
> -- 
> Best regards, Sergey. 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/swing-dev/attachments/20150515/9a209bc3/attachment.html>

From semyon.sadetsky at oracle.com  Mon May 18 12:19:36 2015
From: semyon.sadetsky at oracle.com (Semyon Sadetsky)
Date: Mon, 18 May 2015 15:19:36 +0300
Subject: <Swing Dev> [9] Review Request for 8079640: GroupLayout
 incorrect layout with large JTextArea
In-Reply-To: <554CB523.7080300@oracle.com>
References: <554C783A.4080606@oracle.com> <554CB523.7080300@oracle.com>
Message-ID: <5559D8D8.6020300@oracle.com>

Sergey,

I have dug into the SCCS history. This was set initially and was not 
related to any issues.

--Semyon


On 5/8/2015 4:07 PM, Sergey Bylokhov wrote:
> Hi, Semyon.
> It will be good to dig into the history of GroupLayout and understand 
> why this was constrained, note that tutorial should be updated also.
>
> On 08.05.15 11:47, Semyon Sadetsky wrote:
>> Hello,
>>
>> Please review fix for JDK9:
>>
>> bug: https://bugs.openjdk.java.net/browse/JDK-8079640
>> webrev: http://cr.openjdk.java.net/~ssadetsky/8079640/webrev.00/
>>
>> *THE ROOT CAUSE
>> Component minimum size is limited to Short.MAX_VALUE in GroupLayout.
>> JDK turtorial 
>> https://docs.oracle.com/javase/tutorial/uiswing/layout/group.html 
>> tells that Short.MAX_VALUE is treated as infinite.
>> But I did not find any reasons in JDK specs why a bigger number 
>> cannot be used.
>>
>> *SOLUTION
>> Remove the limitation
>>
>> *TESTING
>> Test is added to cover the large component scenario.
>> Existing GroupLayout tests are passed.
>>
>> --Semyon
>>
>
>



From Sergey.Bylokhov at oracle.com  Mon May 18 13:20:56 2015
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Mon, 18 May 2015 16:20:56 +0300
Subject: <Swing Dev> [9] Review Request for 8079640: GroupLayout
 incorrect layout with large JTextArea
In-Reply-To: <5559D8D8.6020300@oracle.com>
References: <554C783A.4080606@oracle.com> <554CB523.7080300@oracle.com>
	<5559D8D8.6020300@oracle.com>
Message-ID: <5559E738.8090904@oracle.com>

Looks fine then.
Please file a separate issue to update tutorial.

On 18.05.15 15:19, Semyon Sadetsky wrote:
> Sergey,
>
> I have dug into the SCCS history. This was set initially and was not 
> related to any issues.
>
> --Semyon
>
>
> On 5/8/2015 4:07 PM, Sergey Bylokhov wrote:
>> Hi, Semyon.
>> It will be good to dig into the history of GroupLayout and understand 
>> why this was constrained, note that tutorial should be updated also.
>>
>> On 08.05.15 11:47, Semyon Sadetsky wrote:
>>> Hello,
>>>
>>> Please review fix for JDK9:
>>>
>>> bug: https://bugs.openjdk.java.net/browse/JDK-8079640
>>> webrev: http://cr.openjdk.java.net/~ssadetsky/8079640/webrev.00/
>>>
>>> *THE ROOT CAUSE
>>> Component minimum size is limited to Short.MAX_VALUE in GroupLayout.
>>> JDK turtorial 
>>> https://docs.oracle.com/javase/tutorial/uiswing/layout/group.html 
>>> tells that Short.MAX_VALUE is treated as infinite.
>>> But I did not find any reasons in JDK specs why a bigger number 
>>> cannot be used.
>>>
>>> *SOLUTION
>>> Remove the limitation
>>>
>>> *TESTING
>>> Test is added to cover the large component scenario.
>>> Existing GroupLayout tests are passed.
>>>
>>> --Semyon
>>>
>>
>>
>


-- 
Best regards, Sergey.



From semyon.sadetsky at oracle.com  Mon May 18 14:56:15 2015
From: semyon.sadetsky at oracle.com (Semyon Sadetsky)
Date: Mon, 18 May 2015 17:56:15 +0300
Subject: <Swing Dev> [9] Review Request for 8079640: GroupLayout
 incorrect layout with large JTextArea
In-Reply-To: <5559E738.8090904@oracle.com>
References: <554C783A.4080606@oracle.com> <554CB523.7080300@oracle.com>
	<5559D8D8.6020300@oracle.com> <5559E738.8090904@oracle.com>
Message-ID: <5559FD8F.1030909@oracle.com>

JDK-8080604 created.

On 5/18/2015 4:20 PM, Sergey Bylokhov wrote:
> Looks fine then.
> Please file a separate issue to update tutorial.
>
> On 18.05.15 15:19, Semyon Sadetsky wrote:
>> Sergey,
>>
>> I have dug into the SCCS history. This was set initially and was not 
>> related to any issues.
>>
>> --Semyon
>>
>>
>> On 5/8/2015 4:07 PM, Sergey Bylokhov wrote:
>>> Hi, Semyon.
>>> It will be good to dig into the history of GroupLayout and 
>>> understand why this was constrained, note that tutorial should be 
>>> updated also.
>>>
>>> On 08.05.15 11:47, Semyon Sadetsky wrote:
>>>> Hello,
>>>>
>>>> Please review fix for JDK9:
>>>>
>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8079640
>>>> webrev: http://cr.openjdk.java.net/~ssadetsky/8079640/webrev.00/
>>>>
>>>> *THE ROOT CAUSE
>>>> Component minimum size is limited to Short.MAX_VALUE in GroupLayout.
>>>> JDK turtorial 
>>>> https://docs.oracle.com/javase/tutorial/uiswing/layout/group.html 
>>>> tells that Short.MAX_VALUE is treated as infinite.
>>>> But I did not find any reasons in JDK specs why a bigger number 
>>>> cannot be used.
>>>>
>>>> *SOLUTION
>>>> Remove the limitation
>>>>
>>>> *TESTING
>>>> Test is added to cover the large component scenario.
>>>> Existing GroupLayout tests are passed.
>>>>
>>>> --Semyon
>>>>
>>>
>>>
>>
>
>



From alexandr.scherbatiy at oracle.com  Tue May 19 11:03:33 2015
From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy)
Date: Tue, 19 May 2015 14:03:33 +0300
Subject: <Swing Dev> [9] Review Request for 8078514: Nightly:
 api/javax_swing/DefaultRowSorter/index_ModelStructChanged failure
In-Reply-To: <55560786.9010306@oracle.com>
References: <55560786.9010306@oracle.com>
Message-ID: <555B1885.2020605@oracle.com>

On 5/15/2015 5:49 PM, Semyon Sadetsky wrote:
> Hello,
>
> Please review fix for JDK9:
>
> bug: https://bugs.openjdk.java.net/browse/JDK-8078514
> webrev: http://cr.openjdk.java.net/~ssadetsky/8078514/webrev.00/

   DefaultRowSorter
221             allChanged();
222             modelRowCount = getModelWrapper().getRowCount();

- This can be moved to a private method that will be used both in the 
public modelStructureChanged() and setModelWrapper() methods.

532     public void sort()
- Could the rawFilter be null in case viewToModel != null an !isUnsorted() ?
- isUnsorted() method is called twice. Is it possible to store its value 
to a variable and use it?

Thanks,
Alexandr.

>
> The 6894632 fix violated a contract between the table and its row 
> sorter: the sorter should receive TableChanged events even if table is 
> not sorted actually.
> Another way to fix 6894632 is to initialize sorter internal structures 
> instantly. The last is applied in the fix.
>
> --Semyon
>



From alexandr.scherbatiy at oracle.com  Tue May 19 11:29:20 2015
From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy)
Date: Tue, 19 May 2015 14:29:20 +0300
Subject: <Swing Dev> [9] Review Request for 8079640: GroupLayout
 incorrect layout with large JTextArea
In-Reply-To: <5559D8D8.6020300@oracle.com>
References: <554C783A.4080606@oracle.com> <554CB523.7080300@oracle.com>
	<5559D8D8.6020300@oracle.com>
Message-ID: <555B1E90.7000006@oracle.com>


  The SequentialGroup.operator(int a, int b) method returns constrain(a) 
+ constrain(b).
  If there are no any restriction to the constrain() return value it can 
leads to the integer overflow.

  May be Integer.MAX_VALUE / 2 can be used instead of Short.MAX_VALUE?

Thanks,
Alexandr.

On 5/18/2015 3:19 PM, Semyon Sadetsky wrote:
> Sergey,
>
> I have dug into the SCCS history. This was set initially and was not 
> related to any issues.
>
> --Semyon
>
>
> On 5/8/2015 4:07 PM, Sergey Bylokhov wrote:
>> Hi, Semyon.
>> It will be good to dig into the history of GroupLayout and understand 
>> why this was constrained, note that tutorial should be updated also.
>>
>> On 08.05.15 11:47, Semyon Sadetsky wrote:
>>> Hello,
>>>
>>> Please review fix for JDK9:
>>>
>>> bug: https://bugs.openjdk.java.net/browse/JDK-8079640
>>> webrev: http://cr.openjdk.java.net/~ssadetsky/8079640/webrev.00/
>>>
>>> *THE ROOT CAUSE
>>> Component minimum size is limited to Short.MAX_VALUE in GroupLayout.
>>> JDK turtorial 
>>> https://docs.oracle.com/javase/tutorial/uiswing/layout/group.html 
>>> tells that Short.MAX_VALUE is treated as infinite.
>>> But I did not find any reasons in JDK specs why a bigger number 
>>> cannot be used.
>>>
>>> *SOLUTION
>>> Remove the limitation
>>>
>>> *TESTING
>>> Test is added to cover the large component scenario.
>>> Existing GroupLayout tests are passed.
>>>
>>> --Semyon
>>>
>>
>>
>



From semyon.sadetsky at oracle.com  Tue May 19 14:38:29 2015
From: semyon.sadetsky at oracle.com (Semyon Sadetsky)
Date: Tue, 19 May 2015 17:38:29 +0300
Subject: <Swing Dev> [9] Review Request for 8079640: GroupLayout
 incorrect layout with large JTextArea
In-Reply-To: <555B1E90.7000006@oracle.com>
References: <554C783A.4080606@oracle.com> <554CB523.7080300@oracle.com>
	<5559D8D8.6020300@oracle.com> <555B1E90.7000006@oracle.com>
Message-ID: <555B4AE5.20001@oracle.com>

Alexander, thanks that's true.
http://cr.openjdk.java.net/~ssadetsky/8079640/webrev.01/

On 5/19/2015 2:29 PM, Alexander Scherbatiy wrote:
>
>  The SequentialGroup.operator(int a, int b) method returns 
> constrain(a) + constrain(b).
>  If there are no any restriction to the constrain() return value it 
> can leads to the integer overflow.
>
>  May be Integer.MAX_VALUE / 2 can be used instead of Short.MAX_VALUE?
>
> Thanks,
> Alexandr.
>
> On 5/18/2015 3:19 PM, Semyon Sadetsky wrote:
>> Sergey,
>>
>> I have dug into the SCCS history. This was set initially and was not 
>> related to any issues.
>>
>> --Semyon
>>
>>
>> On 5/8/2015 4:07 PM, Sergey Bylokhov wrote:
>>> Hi, Semyon.
>>> It will be good to dig into the history of GroupLayout and 
>>> understand why this was constrained, note that tutorial should be 
>>> updated also.
>>>
>>> On 08.05.15 11:47, Semyon Sadetsky wrote:
>>>> Hello,
>>>>
>>>> Please review fix for JDK9:
>>>>
>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8079640
>>>> webrev: http://cr.openjdk.java.net/~ssadetsky/8079640/webrev.00/
>>>>
>>>> *THE ROOT CAUSE
>>>> Component minimum size is limited to Short.MAX_VALUE in GroupLayout.
>>>> JDK turtorial 
>>>> https://docs.oracle.com/javase/tutorial/uiswing/layout/group.html 
>>>> tells that Short.MAX_VALUE is treated as infinite.
>>>> But I did not find any reasons in JDK specs why a bigger number 
>>>> cannot be used.
>>>>
>>>> *SOLUTION
>>>> Remove the limitation
>>>>
>>>> *TESTING
>>>> Test is added to cover the large component scenario.
>>>> Existing GroupLayout tests are passed.
>>>>
>>>> --Semyon
>>>>
>>>
>>>
>>
>



From semyon.sadetsky at oracle.com  Tue May 19 14:50:52 2015
From: semyon.sadetsky at oracle.com (Semyon Sadetsky)
Date: Tue, 19 May 2015 17:50:52 +0300
Subject: <Swing Dev> [9] Review Request for 6260348: GTK+ L&F
 JTextComponent not respecting desktop caret blink rate
In-Reply-To: <554CC26B.5020004@oracle.com>
References: <5539004F.9060705@oracle.com> <554CC26B.5020004@oracle.com>
Message-ID: <555B4DCC.9010607@oracle.com>

Hi Alexander,

I agree.
http://cr.openjdk.java.net/~ssadetsky/6260348/webrev.01/

--Semyon

On 5/8/2015 5:04 PM, Alexander Zvegintsev wrote:
> Hi Semyon,
>
> the fix itself looks good to me, but the test doesn't work.
>
> 1. FileWriter is replacing the .gtkrc-2.0 file (FileWriter(file, true 
> /*append*/) should be used) ;
> 2. settings from .gtkrc-2.0  doesn't taken into account on my system.
> there are at least two system tools which allows to modify such values:
> gconftool-2 and gsettings. One of them may lack on different systems.
> this will make test complicated.
> So I suggest just remove the test and add noreg-hard label to the issue.
>
> -- 
> Thanks,
> Alexander.
>
> On 23.04.2015 17:23, Semyon Sadetsky wrote:
>> Hello,
>>
>> Please review fix for JDK9:
>>
>> web rev: http://cr.openjdk.java.net/~ssadetsky/6260348/webrev.00/
>> bug: https://bugs.openjdk.java.net/browse/JDK-6260348
>>
>> ***ROOT CAUSE
>> GTK L&F never took care about native GTK cursor blink settings.
>>
>> ***SOLUTION
>> Implement this feature.
>>
>> ***TESTING
>> Two test scenarios added. 1st sets GTK cursor blink enabled and blink 
>> time 200 ms. 2nd disables cursor blinking. Then Java text caret is 
>> checked to respect these settings.
>>
>> --Semyon
>>
>>
>



From alexander.zvegintsev at oracle.com  Tue May 19 14:56:45 2015
From: alexander.zvegintsev at oracle.com (Alexander Zvegintsev)
Date: Tue, 19 May 2015 17:56:45 +0300
Subject: <Swing Dev> [9] Review Request for 6260348: GTK+ L&F
 JTextComponent not respecting desktop caret blink rate
In-Reply-To: <555B4DCC.9010607@oracle.com>
References: <5539004F.9060705@oracle.com> <554CC26B.5020004@oracle.com>
	<555B4DCC.9010607@oracle.com>
Message-ID: <555B4F2D.8030806@oracle.com>

still looks good to me.

Thanks,

Alexander.

On 05/19/2015 05:50 PM, Semyon Sadetsky wrote:
> Hi Alexander,
>
> I agree.
> http://cr.openjdk.java.net/~ssadetsky/6260348/webrev.01/
>
> --Semyon
>
> On 5/8/2015 5:04 PM, Alexander Zvegintsev wrote:
>> Hi Semyon,
>>
>> the fix itself looks good to me, but the test doesn't work.
>>
>> 1. FileWriter is replacing the .gtkrc-2.0 file (FileWriter(file, true 
>> /*append*/) should be used) ;
>> 2. settings from .gtkrc-2.0  doesn't taken into account on my system.
>> there are at least two system tools which allows to modify such values:
>> gconftool-2 and gsettings. One of them may lack on different systems.
>> this will make test complicated.
>> So I suggest just remove the test and add noreg-hard label to the issue.
>>
>> -- 
>> Thanks,
>> Alexander.
>>
>> On 23.04.2015 17:23, Semyon Sadetsky wrote:
>>> Hello,
>>>
>>> Please review fix for JDK9:
>>>
>>> web rev: http://cr.openjdk.java.net/~ssadetsky/6260348/webrev.00/
>>> bug: https://bugs.openjdk.java.net/browse/JDK-6260348
>>>
>>> ***ROOT CAUSE
>>> GTK L&F never took care about native GTK cursor blink settings.
>>>
>>> ***SOLUTION
>>> Implement this feature.
>>>
>>> ***TESTING
>>> Two test scenarios added. 1st sets GTK cursor blink enabled and 
>>> blink time 200 ms. 2nd disables cursor blinking. Then Java text 
>>> caret is checked to respect these settings.
>>>
>>> --Semyon
>>>
>>>
>>
>



From alexandr.scherbatiy at oracle.com  Tue May 19 15:00:26 2015
From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy)
Date: Tue, 19 May 2015 18:00:26 +0300
Subject: <Swing Dev> [9] Review Request for 6260348: GTK+ L&F
 JTextComponent not respecting desktop caret blink rate
In-Reply-To: <555B4F2D.8030806@oracle.com>
References: <5539004F.9060705@oracle.com> <554CC26B.5020004@oracle.com>
	<555B4DCC.9010607@oracle.com> <555B4F2D.8030806@oracle.com>
Message-ID: <555B500A.3000303@oracle.com>


   The fix looks good to me.

   Thanks,
   Alexandr.

On 5/19/2015 5:56 PM, Alexander Zvegintsev wrote:
> still looks good to me.
>
> Thanks,
>
> Alexander.
>
> On 05/19/2015 05:50 PM, Semyon Sadetsky wrote:
>> Hi Alexander,
>>
>> I agree.
>> http://cr.openjdk.java.net/~ssadetsky/6260348/webrev.01/
>>
>> --Semyon
>>
>> On 5/8/2015 5:04 PM, Alexander Zvegintsev wrote:
>>> Hi Semyon,
>>>
>>> the fix itself looks good to me, but the test doesn't work.
>>>
>>> 1. FileWriter is replacing the .gtkrc-2.0 file (FileWriter(file, 
>>> true /*append*/) should be used) ;
>>> 2. settings from .gtkrc-2.0  doesn't taken into account on my system.
>>> there are at least two system tools which allows to modify such values:
>>> gconftool-2 and gsettings. One of them may lack on different systems.
>>> this will make test complicated.
>>> So I suggest just remove the test and add noreg-hard label to the 
>>> issue.
>>>
>>> -- 
>>> Thanks,
>>> Alexander.
>>>
>>> On 23.04.2015 17:23, Semyon Sadetsky wrote:
>>>> Hello,
>>>>
>>>> Please review fix for JDK9:
>>>>
>>>> web rev: http://cr.openjdk.java.net/~ssadetsky/6260348/webrev.00/
>>>> bug: https://bugs.openjdk.java.net/browse/JDK-6260348
>>>>
>>>> ***ROOT CAUSE
>>>> GTK L&F never took care about native GTK cursor blink settings.
>>>>
>>>> ***SOLUTION
>>>> Implement this feature.
>>>>
>>>> ***TESTING
>>>> Two test scenarios added. 1st sets GTK cursor blink enabled and 
>>>> blink time 200 ms. 2nd disables cursor blinking. Then Java text 
>>>> caret is checked to respect these settings.
>>>>
>>>> --Semyon
>>>>
>>>>
>>>
>>
>



From alexander.zvegintsev at oracle.com  Wed May 20 12:34:45 2015
From: alexander.zvegintsev at oracle.com (Alexander Zvegintsev)
Date: Wed, 20 May 2015 15:34:45 +0300
Subject: <Swing Dev> [9] Review Request for 8079640: GroupLayout
 incorrect layout with large JTextArea
In-Reply-To: <555B4AE5.20001@oracle.com>
References: <554C783A.4080606@oracle.com> <554CB523.7080300@oracle.com>
	<5559D8D8.6020300@oracle.com> <555B1E90.7000006@oracle.com>
	<555B4AE5.20001@oracle.com>
Message-ID: <555C7F65.6000002@oracle.com>

Hi Semyon,

I think that INFINITE is a bit inaccurate name.
Personally, I think that there is no need in extra variable here.
Why just not inline MAX_VALUE / 2 (with comment about integer overflow) 
into constrain()?

Thanks,

Alexander.

On 05/19/2015 05:38 PM, Semyon Sadetsky wrote:
> Alexander, thanks that's true.
> http://cr.openjdk.java.net/~ssadetsky/8079640/webrev.01/
>
> On 5/19/2015 2:29 PM, Alexander Scherbatiy wrote:
>>
>>  The SequentialGroup.operator(int a, int b) method returns 
>> constrain(a) + constrain(b).
>>  If there are no any restriction to the constrain() return value it 
>> can leads to the integer overflow.
>>
>>  May be Integer.MAX_VALUE / 2 can be used instead of Short.MAX_VALUE?
>>
>> Thanks,
>> Alexandr.
>>
>> On 5/18/2015 3:19 PM, Semyon Sadetsky wrote:
>>> Sergey,
>>>
>>> I have dug into the SCCS history. This was set initially and was not 
>>> related to any issues.
>>>
>>> --Semyon
>>>
>>>
>>> On 5/8/2015 4:07 PM, Sergey Bylokhov wrote:
>>>> Hi, Semyon.
>>>> It will be good to dig into the history of GroupLayout and 
>>>> understand why this was constrained, note that tutorial should be 
>>>> updated also.
>>>>
>>>> On 08.05.15 11:47, Semyon Sadetsky wrote:
>>>>> Hello,
>>>>>
>>>>> Please review fix for JDK9:
>>>>>
>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8079640
>>>>> webrev: http://cr.openjdk.java.net/~ssadetsky/8079640/webrev.00/
>>>>>
>>>>> *THE ROOT CAUSE
>>>>> Component minimum size is limited to Short.MAX_VALUE in GroupLayout.
>>>>> JDK turtorial 
>>>>> https://docs.oracle.com/javase/tutorial/uiswing/layout/group.html 
>>>>> tells that Short.MAX_VALUE is treated as infinite.
>>>>> But I did not find any reasons in JDK specs why a bigger number 
>>>>> cannot be used.
>>>>>
>>>>> *SOLUTION
>>>>> Remove the limitation
>>>>>
>>>>> *TESTING
>>>>> Test is added to cover the large component scenario.
>>>>> Existing GroupLayout tests are passed.
>>>>>
>>>>> --Semyon
>>>>>
>>>>
>>>>
>>>
>>
>



From semyon.sadetsky at oracle.com  Wed May 20 13:33:09 2015
From: semyon.sadetsky at oracle.com (Semyon Sadetsky)
Date: Wed, 20 May 2015 16:33:09 +0300
Subject: <Swing Dev> [9] Review Request for 8079640: GroupLayout
 incorrect layout with large JTextArea
In-Reply-To: <555C7F65.6000002@oracle.com>
References: <554C783A.4080606@oracle.com> <554CB523.7080300@oracle.com>
	<5559D8D8.6020300@oracle.com> <555B1E90.7000006@oracle.com>
	<555B4AE5.20001@oracle.com> <555C7F65.6000002@oracle.com>
Message-ID: <555C8D15.5060707@oracle.com>

Hi Alexander,

This definition is mentioned in the tutorial. I think it would be good 
to make this constant public eventually because it is often used in 
various the GroupLayout calls as a parameter.

--Semyon

On 5/20/2015 3:34 PM, Alexander Zvegintsev wrote:
> Hi Semyon,
>
> I think that INFINITE is a bit inaccurate name.
> Personally, I think that there is no need in extra variable here.
> Why just not inline MAX_VALUE / 2 (with comment about integer 
> overflow) into constrain()?
>
> Thanks,
>
> Alexander.
>
> On 05/19/2015 05:38 PM, Semyon Sadetsky wrote:
>> Alexander, thanks that's true.
>> http://cr.openjdk.java.net/~ssadetsky/8079640/webrev.01/
>>
>> On 5/19/2015 2:29 PM, Alexander Scherbatiy wrote:
>>>
>>>  The SequentialGroup.operator(int a, int b) method returns 
>>> constrain(a) + constrain(b).
>>>  If there are no any restriction to the constrain() return value it 
>>> can leads to the integer overflow.
>>>
>>>  May be Integer.MAX_VALUE / 2 can be used instead of Short.MAX_VALUE?
>>>
>>> Thanks,
>>> Alexandr.
>>>
>>> On 5/18/2015 3:19 PM, Semyon Sadetsky wrote:
>>>> Sergey,
>>>>
>>>> I have dug into the SCCS history. This was set initially and was 
>>>> not related to any issues.
>>>>
>>>> --Semyon
>>>>
>>>>
>>>> On 5/8/2015 4:07 PM, Sergey Bylokhov wrote:
>>>>> Hi, Semyon.
>>>>> It will be good to dig into the history of GroupLayout and 
>>>>> understand why this was constrained, note that tutorial should be 
>>>>> updated also.
>>>>>
>>>>> On 08.05.15 11:47, Semyon Sadetsky wrote:
>>>>>> Hello,
>>>>>>
>>>>>> Please review fix for JDK9:
>>>>>>
>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8079640
>>>>>> webrev: http://cr.openjdk.java.net/~ssadetsky/8079640/webrev.00/
>>>>>>
>>>>>> *THE ROOT CAUSE
>>>>>> Component minimum size is limited to Short.MAX_VALUE in GroupLayout.
>>>>>> JDK turtorial 
>>>>>> https://docs.oracle.com/javase/tutorial/uiswing/layout/group.html 
>>>>>> tells that Short.MAX_VALUE is treated as infinite.
>>>>>> But I did not find any reasons in JDK specs why a bigger number 
>>>>>> cannot be used.
>>>>>>
>>>>>> *SOLUTION
>>>>>> Remove the limitation
>>>>>>
>>>>>> *TESTING
>>>>>> Test is added to cover the large component scenario.
>>>>>> Existing GroupLayout tests are passed.
>>>>>>
>>>>>> --Semyon
>>>>>>
>>>>>
>>>>>
>>>>
>>>
>>
>



From alexander.zvegintsev at oracle.com  Wed May 20 13:50:02 2015
From: alexander.zvegintsev at oracle.com (Alexander Zvegintsev)
Date: Wed, 20 May 2015 16:50:02 +0300
Subject: <Swing Dev> [9] Review Request for 8079640: GroupLayout
 incorrect layout with large JTextArea
In-Reply-To: <555C8D15.5060707@oracle.com>
References: <554C783A.4080606@oracle.com> <554CB523.7080300@oracle.com>
	<5559D8D8.6020300@oracle.com> <555B1E90.7000006@oracle.com>
	<555B4AE5.20001@oracle.com> <555C7F65.6000002@oracle.com>
	<555C8D15.5060707@oracle.com>
Message-ID: <555C910A.9070605@oracle.com>

Oh, I see, thanks for clarifying this,

the fix looks good to me then.

Thanks,

Alexander.

On 05/20/2015 04:33 PM, Semyon Sadetsky wrote:
> Hi Alexander,
>
> This definition is mentioned in the tutorial. I think it would be good 
> to make this constant public eventually because it is often used in 
> various the GroupLayout calls as a parameter.
>
> --Semyon
>
> On 5/20/2015 3:34 PM, Alexander Zvegintsev wrote:
>> Hi Semyon,
>>
>> I think that INFINITE is a bit inaccurate name.
>> Personally, I think that there is no need in extra variable here.
>> Why just not inline MAX_VALUE / 2 (with comment about integer 
>> overflow) into constrain()?
>>
>> Thanks,
>>
>> Alexander.
>>
>> On 05/19/2015 05:38 PM, Semyon Sadetsky wrote:
>>> Alexander, thanks that's true.
>>> http://cr.openjdk.java.net/~ssadetsky/8079640/webrev.01/
>>>
>>> On 5/19/2015 2:29 PM, Alexander Scherbatiy wrote:
>>>>
>>>>  The SequentialGroup.operator(int a, int b) method returns 
>>>> constrain(a) + constrain(b).
>>>>  If there are no any restriction to the constrain() return value it 
>>>> can leads to the integer overflow.
>>>>
>>>>  May be Integer.MAX_VALUE / 2 can be used instead of Short.MAX_VALUE?
>>>>
>>>> Thanks,
>>>> Alexandr.
>>>>
>>>> On 5/18/2015 3:19 PM, Semyon Sadetsky wrote:
>>>>> Sergey,
>>>>>
>>>>> I have dug into the SCCS history. This was set initially and was 
>>>>> not related to any issues.
>>>>>
>>>>> --Semyon
>>>>>
>>>>>
>>>>> On 5/8/2015 4:07 PM, Sergey Bylokhov wrote:
>>>>>> Hi, Semyon.
>>>>>> It will be good to dig into the history of GroupLayout and 
>>>>>> understand why this was constrained, note that tutorial should be 
>>>>>> updated also.
>>>>>>
>>>>>> On 08.05.15 11:47, Semyon Sadetsky wrote:
>>>>>>> Hello,
>>>>>>>
>>>>>>> Please review fix for JDK9:
>>>>>>>
>>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8079640
>>>>>>> webrev: http://cr.openjdk.java.net/~ssadetsky/8079640/webrev.00/
>>>>>>>
>>>>>>> *THE ROOT CAUSE
>>>>>>> Component minimum size is limited to Short.MAX_VALUE in 
>>>>>>> GroupLayout.
>>>>>>> JDK turtorial 
>>>>>>> https://docs.oracle.com/javase/tutorial/uiswing/layout/group.html tells 
>>>>>>> that Short.MAX_VALUE is treated as infinite.
>>>>>>> But I did not find any reasons in JDK specs why a bigger number 
>>>>>>> cannot be used.
>>>>>>>
>>>>>>> *SOLUTION
>>>>>>> Remove the limitation
>>>>>>>
>>>>>>> *TESTING
>>>>>>> Test is added to cover the large component scenario.
>>>>>>> Existing GroupLayout tests are passed.
>>>>>>>
>>>>>>> --Semyon
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>



From alexandr.scherbatiy at oracle.com  Wed May 20 14:02:14 2015
From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy)
Date: Wed, 20 May 2015 17:02:14 +0300
Subject: <Swing Dev> [9] Review Request for 8079640: GroupLayout
 incorrect layout with large JTextArea
In-Reply-To: <555C910A.9070605@oracle.com>
References: <554C783A.4080606@oracle.com> <554CB523.7080300@oracle.com>
	<5559D8D8.6020300@oracle.com> <555B1E90.7000006@oracle.com>
	<555B4AE5.20001@oracle.com> <555C7F65.6000002@oracle.com>
	<555C8D15.5060707@oracle.com> <555C910A.9070605@oracle.com>
Message-ID: <555C93E6.50603@oracle.com>


   The fix looks good to me.

   Thanks,
   Alexandr.

On 5/20/2015 4:50 PM, Alexander Zvegintsev wrote:
> Oh, I see, thanks for clarifying this,
>
> the fix looks good to me then.
>
> Thanks,
>
> Alexander.
>
> On 05/20/2015 04:33 PM, Semyon Sadetsky wrote:
>> Hi Alexander,
>>
>> This definition is mentioned in the tutorial. I think it would be 
>> good to make this constant public eventually because it is often used 
>> in various the GroupLayout calls as a parameter.
>>
>> --Semyon
>>
>> On 5/20/2015 3:34 PM, Alexander Zvegintsev wrote:
>>> Hi Semyon,
>>>
>>> I think that INFINITE is a bit inaccurate name.
>>> Personally, I think that there is no need in extra variable here.
>>> Why just not inline MAX_VALUE / 2 (with comment about integer 
>>> overflow) into constrain()?
>>>
>>> Thanks,
>>>
>>> Alexander.
>>>
>>> On 05/19/2015 05:38 PM, Semyon Sadetsky wrote:
>>>> Alexander, thanks that's true.
>>>> http://cr.openjdk.java.net/~ssadetsky/8079640/webrev.01/
>>>>
>>>> On 5/19/2015 2:29 PM, Alexander Scherbatiy wrote:
>>>>>
>>>>>  The SequentialGroup.operator(int a, int b) method returns 
>>>>> constrain(a) + constrain(b).
>>>>>  If there are no any restriction to the constrain() return value 
>>>>> it can leads to the integer overflow.
>>>>>
>>>>>  May be Integer.MAX_VALUE / 2 can be used instead of Short.MAX_VALUE?
>>>>>
>>>>> Thanks,
>>>>> Alexandr.
>>>>>
>>>>> On 5/18/2015 3:19 PM, Semyon Sadetsky wrote:
>>>>>> Sergey,
>>>>>>
>>>>>> I have dug into the SCCS history. This was set initially and was 
>>>>>> not related to any issues.
>>>>>>
>>>>>> --Semyon
>>>>>>
>>>>>>
>>>>>> On 5/8/2015 4:07 PM, Sergey Bylokhov wrote:
>>>>>>> Hi, Semyon.
>>>>>>> It will be good to dig into the history of GroupLayout and 
>>>>>>> understand why this was constrained, note that tutorial should 
>>>>>>> be updated also.
>>>>>>>
>>>>>>> On 08.05.15 11:47, Semyon Sadetsky wrote:
>>>>>>>> Hello,
>>>>>>>>
>>>>>>>> Please review fix for JDK9:
>>>>>>>>
>>>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8079640
>>>>>>>> webrev: http://cr.openjdk.java.net/~ssadetsky/8079640/webrev.00/
>>>>>>>>
>>>>>>>> *THE ROOT CAUSE
>>>>>>>> Component minimum size is limited to Short.MAX_VALUE in 
>>>>>>>> GroupLayout.
>>>>>>>> JDK turtorial 
>>>>>>>> https://docs.oracle.com/javase/tutorial/uiswing/layout/group.html 
>>>>>>>> tells that Short.MAX_VALUE is treated as infinite.
>>>>>>>> But I did not find any reasons in JDK specs why a bigger number 
>>>>>>>> cannot be used.
>>>>>>>>
>>>>>>>> *SOLUTION
>>>>>>>> Remove the limitation
>>>>>>>>
>>>>>>>> *TESTING
>>>>>>>> Test is added to cover the large component scenario.
>>>>>>>> Existing GroupLayout tests are passed.
>>>>>>>>
>>>>>>>> --Semyon
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>



From pooja.chopra at oracle.com  Wed May 20 17:54:13 2015
From: pooja.chopra at oracle.com (pooja chopra)
Date: Wed, 20 May 2015 23:24:13 +0530
Subject: <Swing Dev> <AWT Dev> [9] Review Request: JDK-8078855
 [TEST_BUG] javax/swing/JComboBox/8032878/bug8032878.java fails in
 WindowsClassicLookAndFeel
In-Reply-To: <5548C2A6.5070207@oracle.com>
References: <554292E6.7080608@oracle.com> <5548C2A6.5070207@oracle.com>
Message-ID: <555CCA45.7090202@oracle.com>

Hi All,

Please review the updated webrev link as per discussion with Alexey as 
below for the fix :-

Please review a fix for issue:
8078855 [TEST_BUG] javax/swing/JComboBox/8032878/bug8032878.java fails 
in WindowsClassicLookAndFeel
Test bug fix.
https://bugs.openjdk.java.net/browse/JDK-8078855
The webrev is : http://cr.openjdk.java.net/~pchopra/8078855/webrev.01

Regards,
Pooja

On 5/5/2015 6:46 PM, Alexey Ivanov wrote:
> Hello Pooja,
>
> The modified test case does not reproduce the problem reported in 
> https://bugs.openjdk.java.net/browse/JDK-8032878. So this fix cannot 
> be applied to the regression test.
>
> I confirm that the original test fails in WindowsClassicLookAndFeel 
> because the editor selects the text, thus the typed text '123' is not 
> added to existing text but replaces it. It could be a bug in 
> WindowsClassicLookAndFeel or its feature. If it's not a bug, then the 
> test should expect the value of "123" rather than "one123" where 
> WindowsClassicLookAndFeel is used.
>
> Regards,
> Alexey
>
> On 30.04.2015 23:39, pooja chopra wrote:
>> Hello,
>> Please review a fix for issue:
>> 8078855 [TEST_BUG] javax/swing/JComboBox/8032878/bug8032878.java 
>> fails in WindowsClassicLookAndFeel
>> Test bug fix.
>> https://bugs.openjdk.java.net/browse/JDK-8078855
>> The webrev is : http://cr.openjdk.java.net/~pchopra/8078855/webrev.00/
>>
>> Thanks,
>> Pooja
>



From alexandr.scherbatiy at oracle.com  Thu May 21 09:17:13 2015
From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy)
Date: Thu, 21 May 2015 12:17:13 +0300
Subject: <Swing Dev> <AWT Dev> [9] Review Request: JDK-8078855
 [TEST_BUG] javax/swing/JComboBox/8032878/bug8032878.java fails in
 WindowsClassicLookAndFeel
In-Reply-To: <555CCA45.7090202@oracle.com>
References: <554292E6.7080608@oracle.com> <5548C2A6.5070207@oracle.com>
	<555CCA45.7090202@oracle.com>
Message-ID: <555DA299.7020503@oracle.com>


   The fix looks good to me.

   Thanks,
   Alexandr.

On 5/20/2015 8:54 PM, pooja chopra wrote:
> Hi All,
>
> Please review the updated webrev link as per discussion with Alexey as 
> below for the fix :-
>
> Please review a fix for issue:
> 8078855 [TEST_BUG] javax/swing/JComboBox/8032878/bug8032878.java fails 
> in WindowsClassicLookAndFeel
> Test bug fix.
> https://bugs.openjdk.java.net/browse/JDK-8078855
> The webrev is : http://cr.openjdk.java.net/~pchopra/8078855/webrev.01
>
> Regards,
> Pooja
>
> On 5/5/2015 6:46 PM, Alexey Ivanov wrote:
>> Hello Pooja,
>>
>> The modified test case does not reproduce the problem reported in 
>> https://bugs.openjdk.java.net/browse/JDK-8032878. So this fix cannot 
>> be applied to the regression test.
>>
>> I confirm that the original test fails in WindowsClassicLookAndFeel 
>> because the editor selects the text, thus the typed text '123' is not 
>> added to existing text but replaces it. It could be a bug in 
>> WindowsClassicLookAndFeel or its feature. If it's not a bug, then the 
>> test should expect the value of "123" rather than "one123" where 
>> WindowsClassicLookAndFeel is used.
>>
>> Regards,
>> Alexey
>>
>> On 30.04.2015 23:39, pooja chopra wrote:
>>> Hello,
>>> Please review a fix for issue:
>>> 8078855 [TEST_BUG] javax/swing/JComboBox/8032878/bug8032878.java 
>>> fails in WindowsClassicLookAndFeel
>>> Test bug fix.
>>> https://bugs.openjdk.java.net/browse/JDK-8078855
>>> The webrev is : http://cr.openjdk.java.net/~pchopra/8078855/webrev.00/
>>>
>>> Thanks,
>>> Pooja
>>
>



From alexey.ivanov at oracle.com  Thu May 21 12:10:49 2015
From: alexey.ivanov at oracle.com (Alexey Ivanov)
Date: Thu, 21 May 2015 15:10:49 +0300
Subject: <Swing Dev> [9] Review request for 8080628: No mnemonics on Open
 and Save buttons in JFileChooser
Message-ID: <555DCB49.706@oracle.com>

Hello Swing team,

Could you please review the fix:
     bug: https://bugs.openjdk.java.net/browse/JDK-8080628
     webrev: http://cr.openjdk.java.net/~aivanov/8080628/jdk9/webrev.00/

Description:
Since Open and Save buttons in JFileChooser are default ones, mnemonics 
are redundant on these buttons.

There's no mnemonic on Open and Save buttons in Metal Look-and-Feel but 
it's displayed on Open button when a directory is selected in the file 
list. This is inconsistent.

The fix:
Remove mnemonics in JFileChooser from basic.properties which is used as 
the base for translation updates.
Remove separate JFileChooser keys from metal.properties since they're 
the same as in basic.properties now.

The test:
Regression test checks Open, Save, and Cancel buttons in JFileChooser 
have no mnemonics in all the supported localizations in Metal and Nimbus 
look-and-feels.

Thanks,
Alexey


From alexandr.scherbatiy at oracle.com  Thu May 21 12:15:58 2015
From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy)
Date: Thu, 21 May 2015 15:15:58 +0300
Subject: <Swing Dev> [9] Review request for 8080628: No mnemonics on
 Open and Save buttons in JFileChooser
In-Reply-To: <555DCB49.706@oracle.com>
References: <555DCB49.706@oracle.com>
Message-ID: <555DCC7E.5040908@oracle.com>


   The fix looks good to me.

   Thanks,
   Alexandr.

On 5/21/2015 3:10 PM, Alexey Ivanov wrote:
> Hello Swing team,
>
> Could you please review the fix:
>     bug: https://bugs.openjdk.java.net/browse/JDK-8080628
>     webrev: http://cr.openjdk.java.net/~aivanov/8080628/jdk9/webrev.00/
>
> Description:
> Since Open and Save buttons in JFileChooser are default ones, 
> mnemonics are redundant on these buttons.
>
> There's no mnemonic on Open and Save buttons in Metal Look-and-Feel 
> but it's displayed on Open button when a directory is selected in the 
> file list. This is inconsistent.
>
> The fix:
> Remove mnemonics in JFileChooser from basic.properties which is used 
> as the base for translation updates.
> Remove separate JFileChooser keys from metal.properties since they're 
> the same as in basic.properties now.
>
> The test:
> Regression test checks Open, Save, and Cancel buttons in JFileChooser 
> have no mnemonics in all the supported localizations in Metal and 
> Nimbus look-and-feels.
>
> Thanks,
> Alexey



From Sergey.Bylokhov at oracle.com  Thu May 21 12:28:41 2015
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Thu, 21 May 2015 15:28:41 +0300
Subject: <Swing Dev> [9] Review request for 8080628: No mnemonics on
 Open and Save buttons in JFileChooser
In-Reply-To: <555DCB49.706@oracle.com>
References: <555DCB49.706@oracle.com>
Message-ID: <555DCF79.6070309@oracle.com>

Hi, Alexey.
Why only two look and fells are covered(metal/nimbus)?

On 21.05.15 15:10, Alexey Ivanov wrote:
> Hello Swing team,
>
> Could you please review the fix:
>     bug: https://bugs.openjdk.java.net/browse/JDK-8080628
>     webrev: http://cr.openjdk.java.net/~aivanov/8080628/jdk9/webrev.00/
>
> Description:
> Since Open and Save buttons in JFileChooser are default ones, 
> mnemonics are redundant on these buttons.
>
> There's no mnemonic on Open and Save buttons in Metal Look-and-Feel 
> but it's displayed on Open button when a directory is selected in the 
> file list. This is inconsistent.
>
> The fix:
> Remove mnemonics in JFileChooser from basic.properties which is used 
> as the base for translation updates.
> Remove separate JFileChooser keys from metal.properties since they're 
> the same as in basic.properties now.
>
> The test:
> Regression test checks Open, Save, and Cancel buttons in JFileChooser 
> have no mnemonics in all the supported localizations in Metal and 
> Nimbus look-and-feels.
>
> Thanks,
> Alexey


-- 
Best regards, Sergey.



From alexey.ivanov at oracle.com  Thu May 21 12:37:14 2015
From: alexey.ivanov at oracle.com (Alexey Ivanov)
Date: Thu, 21 May 2015 15:37:14 +0300
Subject: <Swing Dev> [9] Review request for 8080628: No mnemonics on
 Open and Save buttons in JFileChooser
In-Reply-To: <555DCF79.6070309@oracle.com>
References: <555DCB49.706@oracle.com> <555DCF79.6070309@oracle.com>
Message-ID: <555DD17A.2080500@oracle.com>

Hi Sergey,

Because other look-and-feels do not define their own resources.
Actually, one LaF would be enough, if Metal did not define its own Open 
and Save without mnemonics.

I can modify the test to iterate over all the installed LaFs. I just 
thought it was enough to use these two because either is available on 
all the platforms, and eventually all LaFs read the values from 
basic.properties after the fix.

Regards,
Alexey

On 21.05.2015 15:28, Sergey Bylokhov wrote:
> Hi, Alexey.
> Why only two look and fells are covered(metal/nimbus)?
>
> On 21.05.15 15:10, Alexey Ivanov wrote:
>> Hello Swing team,
>>
>> Could you please review the fix:
>>     bug: https://bugs.openjdk.java.net/browse/JDK-8080628
>>     webrev: http://cr.openjdk.java.net/~aivanov/8080628/jdk9/webrev.00/
>>
>> Description:
>> Since Open and Save buttons in JFileChooser are default ones, 
>> mnemonics are redundant on these buttons.
>>
>> There's no mnemonic on Open and Save buttons in Metal Look-and-Feel 
>> but it's displayed on Open button when a directory is selected in the 
>> file list. This is inconsistent.
>>
>> The fix:
>> Remove mnemonics in JFileChooser from basic.properties which is used 
>> as the base for translation updates.
>> Remove separate JFileChooser keys from metal.properties since they're 
>> the same as in basic.properties now.
>>
>> The test:
>> Regression test checks Open, Save, and Cancel buttons in JFileChooser 
>> have no mnemonics in all the supported localizations in Metal and 
>> Nimbus look-and-feels.
>>
>> Thanks,
>> Alexey
>
>



From Sergey.Bylokhov at oracle.com  Thu May 21 13:25:16 2015
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Thu, 21 May 2015 16:25:16 +0300
Subject: <Swing Dev> [9] Review request for 8080628: No mnemonics on
 Open and Save buttons in JFileChooser
In-Reply-To: <555DD17A.2080500@oracle.com>
References: <555DCB49.706@oracle.com> <555DCF79.6070309@oracle.com>
	<555DD17A.2080500@oracle.com>
Message-ID: <555DDCBC.10204@oracle.com>

Hi, Alexey.
If is obvious that all others l&f should work, then I do not see the 
reason why we cannot test them.

On 21.05.15 15:37, Alexey Ivanov wrote:
> Hi Sergey,
>
> Because other look-and-feels do not define their own resources.
> Actually, one LaF would be enough, if Metal did not define its own 
> Open and Save without mnemonics.
>
> I can modify the test to iterate over all the installed LaFs. I just 
> thought it was enough to use these two because either is available on 
> all the platforms, and eventually all LaFs read the values from 
> basic.properties after the fix.
>
> Regards,
> Alexey
>
> On 21.05.2015 15:28, Sergey Bylokhov wrote:
>> Hi, Alexey.
>> Why only two look and fells are covered(metal/nimbus)?
>>
>> On 21.05.15 15:10, Alexey Ivanov wrote:
>>> Hello Swing team,
>>>
>>> Could you please review the fix:
>>>     bug: https://bugs.openjdk.java.net/browse/JDK-8080628
>>>     webrev: http://cr.openjdk.java.net/~aivanov/8080628/jdk9/webrev.00/
>>>
>>> Description:
>>> Since Open and Save buttons in JFileChooser are default ones, 
>>> mnemonics are redundant on these buttons.
>>>
>>> There's no mnemonic on Open and Save buttons in Metal Look-and-Feel 
>>> but it's displayed on Open button when a directory is selected in 
>>> the file list. This is inconsistent.
>>>
>>> The fix:
>>> Remove mnemonics in JFileChooser from basic.properties which is used 
>>> as the base for translation updates.
>>> Remove separate JFileChooser keys from metal.properties since 
>>> they're the same as in basic.properties now.
>>>
>>> The test:
>>> Regression test checks Open, Save, and Cancel buttons in 
>>> JFileChooser have no mnemonics in all the supported localizations in 
>>> Metal and Nimbus look-and-feels.
>>>
>>> Thanks,
>>> Alexey
>>
>>
>


-- 
Best regards, Sergey.



From semyon.sadetsky at oracle.com  Thu May 21 14:34:03 2015
From: semyon.sadetsky at oracle.com (Semyon Sadetsky)
Date: Thu, 21 May 2015 17:34:03 +0300
Subject: <Swing Dev> [9] Review Request for 8078514: Nightly:
 api/javax_swing/DefaultRowSorter/index_ModelStructChanged failure
In-Reply-To: <555B1885.2020605@oracle.com>
References: <55560786.9010306@oracle.com> <555B1885.2020605@oracle.com>
Message-ID: <555DECDB.6020301@oracle.com>

Hello,

I have decided to remake the fix.
The reason for that is sun.swing.FilePane class. One of its inner 
classes extends DefaultRowSorter and relays on lazy initialization of 
the DefaultRowSorter in unsorted state. After removing the lazy init the 
FilePane crashes with AOB exception. This can be fixed, but I think it 
will be too big change for the issue and users can be already using the 
DefaultRowSorter in the similar way.
Here is the new approach: 
http://cr.openjdk.java.net/~ssadetsky/8078514/webrev.01/
It looks a little bit risky ,but all related tests have been passed.

--Semyon

On 5/19/2015 2:03 PM, Alexander Scherbatiy wrote:
> On 5/15/2015 5:49 PM, Semyon Sadetsky wrote:
>> Hello,
>>
>> Please review fix for JDK9:
>>
>> bug: https://bugs.openjdk.java.net/browse/JDK-8078514
>> webrev: http://cr.openjdk.java.net/~ssadetsky/8078514/webrev.00/
>
>   DefaultRowSorter
> 221             allChanged();
> 222             modelRowCount = getModelWrapper().getRowCount();
>
> - This can be moved to a private method that will be used both in the 
> public modelStructureChanged() and setModelWrapper() methods.
>
> 532     public void sort()
> - Could the rawFilter be null in case viewToModel != null an 
> !isUnsorted() ?
> - isUnsorted() method is called twice. Is it possible to store its 
> value to a variable and use it?
>
> Thanks,
> Alexandr.
>
>>
>> The 6894632 fix violated a contract between the table and its row 
>> sorter: the sorter should receive TableChanged events even if table 
>> is not sorted actually.
>> Another way to fix 6894632 is to initialize sorter internal 
>> structures instantly. The last is applied in the fix.
>>
>> --Semyon
>>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/swing-dev/attachments/20150521/fd4a8c72/attachment.html>

From alexey.ivanov at oracle.com  Fri May 22 13:08:19 2015
From: alexey.ivanov at oracle.com (Alexey Ivanov)
Date: Fri, 22 May 2015 16:08:19 +0300
Subject: <Swing Dev> <AWT Dev> [9] Review Request: JDK-8078855
 [TEST_BUG] javax/swing/JComboBox/8032878/bug8032878.java fails in
 WindowsClassicLookAndFeel
In-Reply-To: <555CCA45.7090202@oracle.com>
References: <554292E6.7080608@oracle.com> <5548C2A6.5070207@oracle.com>
	<555CCA45.7090202@oracle.com>
Message-ID: <555F2A43.4000707@oracle.com>

Hi Pooja,

The fix looks good to me.

Regards,
Alexey

On 20.05.2015 20:54, pooja chopra wrote:
> Hi All,
>
> Please review the updated webrev link as per discussion with Alexey as 
> below for the fix :-
>
> Please review a fix for issue:
> 8078855 [TEST_BUG] javax/swing/JComboBox/8032878/bug8032878.java fails 
> in WindowsClassicLookAndFeel
> Test bug fix.
> https://bugs.openjdk.java.net/browse/JDK-8078855
> The webrev is : http://cr.openjdk.java.net/~pchopra/8078855/webrev.01
>
> Regards,
> Pooja
>
> On 5/5/2015 6:46 PM, Alexey Ivanov wrote:
>> Hello Pooja,
>>
>> The modified test case does not reproduce the problem reported in 
>> https://bugs.openjdk.java.net/browse/JDK-8032878. So this fix cannot 
>> be applied to the regression test.
>>
>> I confirm that the original test fails in WindowsClassicLookAndFeel 
>> because the editor selects the text, thus the typed text '123' is not 
>> added to existing text but replaces it. It could be a bug in 
>> WindowsClassicLookAndFeel or its feature. If it's not a bug, then the 
>> test should expect the value of "123" rather than "one123" where 
>> WindowsClassicLookAndFeel is used.
>>
>> Regards,
>> Alexey
>>
>> On 30.04.2015 23:39, pooja chopra wrote:
>>> Hello,
>>> Please review a fix for issue:
>>> 8078855 [TEST_BUG] javax/swing/JComboBox/8032878/bug8032878.java 
>>> fails in WindowsClassicLookAndFeel
>>> Test bug fix.
>>> https://bugs.openjdk.java.net/browse/JDK-8078855
>>> The webrev is : http://cr.openjdk.java.net/~pchopra/8078855/webrev.00/
>>>
>>> Thanks,
>>> Pooja
>>
>



From alexey.ivanov at oracle.com  Fri May 22 15:26:50 2015
From: alexey.ivanov at oracle.com (Alexey Ivanov)
Date: Fri, 22 May 2015 18:26:50 +0300
Subject: <Swing Dev> [9] Review request for 8080628: No mnemonics on
 Open and Save buttons in JFileChooser
In-Reply-To: <555DDCBC.10204@oracle.com>
References: <555DCB49.706@oracle.com> <555DCF79.6070309@oracle.com>
	<555DD17A.2080500@oracle.com> <555DDCBC.10204@oracle.com>
Message-ID: <555F4ABA.4080807@oracle.com>

Hi Sergey,

Thanks for your comment. I overlooked GTK LaF which also needs updating.

I updated the test to iterate over all the installed Look-and-Feels:
http://cr.openjdk.java.net/~aivanov/8080628/jdk9/webrev.01/

Regards,
Alexey

On 21.05.2015 16:25, Sergey Bylokhov wrote:
> Hi, Alexey.
> If is obvious that all others l&f should work, then I do not see the 
> reason why we cannot test them.
>
> On 21.05.15 15:37, Alexey Ivanov wrote:
>> Hi Sergey,
>>
>> Because other look-and-feels do not define their own resources.
>> Actually, one LaF would be enough, if Metal did not define its own 
>> Open and Save without mnemonics.
>>
>> I can modify the test to iterate over all the installed LaFs. I just 
>> thought it was enough to use these two because either is available on 
>> all the platforms, and eventually all LaFs read the values from 
>> basic.properties after the fix.
>>
>> Regards,
>> Alexey
>>
>> On 21.05.2015 15:28, Sergey Bylokhov wrote:
>>> Hi, Alexey.
>>> Why only two look and fells are covered(metal/nimbus)?
>>>
>>> On 21.05.15 15:10, Alexey Ivanov wrote:
>>>> Hello Swing team,
>>>>
>>>> Could you please review the fix:
>>>>     bug: https://bugs.openjdk.java.net/browse/JDK-8080628
>>>>     webrev: 
>>>> http://cr.openjdk.java.net/~aivanov/8080628/jdk9/webrev.00/
>>>>
>>>> Description:
>>>> Since Open and Save buttons in JFileChooser are default ones, 
>>>> mnemonics are redundant on these buttons.
>>>>
>>>> There's no mnemonic on Open and Save buttons in Metal Look-and-Feel 
>>>> but it's displayed on Open button when a directory is selected in 
>>>> the file list. This is inconsistent.
>>>>
>>>> The fix:
>>>> Remove mnemonics in JFileChooser from basic.properties which is 
>>>> used as the base for translation updates.
>>>> Remove separate JFileChooser keys from metal.properties since 
>>>> they're the same as in basic.properties now.
>>>>
>>>> The test:
>>>> Regression test checks Open, Save, and Cancel buttons in 
>>>> JFileChooser have no mnemonics in all the supported localizations 
>>>> in Metal and Nimbus look-and-feels.
>>>>
>>>> Thanks,
>>>> Alexey
>>>
>>>
>>
>
>



From pooja.chopra at oracle.com  Fri May 22 16:59:23 2015
From: pooja.chopra at oracle.com (pooja chopra)
Date: Fri, 22 May 2015 22:29:23 +0530
Subject: <Swing Dev> <AWT Dev> [9] Review Request: JDK-8080953
 [TEST_BUG]Test java/awt/FontClass/DebugFonts.java fails due to wrongly
 typed bugid
Message-ID: <555F606B.3040606@oracle.com>

Hello,
Please review a fix for issue:
8080953 [TEST_BUG]Test java/awt/FontClass/DebugFonts.java fails due to 
wrongly typed bugid
Test bug fix.
https://bugs.openjdk.java.net/browse/JDK-8080953
The webrev is : http://cr.openjdk.java.net/~pchopra/8080953/webrev.00

Thanks,
Pooja



From alexey.ivanov at oracle.com  Mon May 25 13:28:56 2015
From: alexey.ivanov at oracle.com (Alexey Ivanov)
Date: Mon, 25 May 2015 16:28:56 +0300
Subject: <Swing Dev> [9] Review request for 8080628: No mnemonics on
 Open and Save buttons in JFileChooser
In-Reply-To: <555F4ABA.4080807@oracle.com>
References: <555DCB49.706@oracle.com>
	<555DCF79.6070309@oracle.com>	<555DD17A.2080500@oracle.com>
	<555DDCBC.10204@oracle.com> <555F4ABA.4080807@oracle.com>
Message-ID: <55632398.1010908@oracle.com>

Hi Sergey,

I updated the test once again: removed the unused imported and redundant 
comma in the locale array.

Updated webrev: http://cr.openjdk.java.net/~aivanov/8080628/jdk9/webrev.02/

It's identical to .01 except for the changes above.


Regards,
Alexey

On 22.05.2015 18:26, Alexey Ivanov wrote:
> Hi Sergey,
>
> Thanks for your comment. I overlooked GTK LaF which also needs updating.
>
> I updated the test to iterate over all the installed Look-and-Feels:
> http://cr.openjdk.java.net/~aivanov/8080628/jdk9/webrev.01/
>
> Regards,
> Alexey
>
> On 21.05.2015 16:25, Sergey Bylokhov wrote:
>> Hi, Alexey.
>> If is obvious that all others l&f should work, then I do not see the 
>> reason why we cannot test them.
>>
>> On 21.05.15 15:37, Alexey Ivanov wrote:
>>> Hi Sergey,
>>>
>>> Because other look-and-feels do not define their own resources.
>>> Actually, one LaF would be enough, if Metal did not define its own 
>>> Open and Save without mnemonics.
>>>
>>> I can modify the test to iterate over all the installed LaFs. I just 
>>> thought it was enough to use these two because either is available 
>>> on all the platforms, and eventually all LaFs read the values from 
>>> basic.properties after the fix.
>>>
>>> Regards,
>>> Alexey
>>>
>>> On 21.05.2015 15:28, Sergey Bylokhov wrote:
>>>> Hi, Alexey.
>>>> Why only two look and fells are covered(metal/nimbus)?
>>>>
>>>> On 21.05.15 15:10, Alexey Ivanov wrote:
>>>>> Hello Swing team,
>>>>>
>>>>> Could you please review the fix:
>>>>>     bug: https://bugs.openjdk.java.net/browse/JDK-8080628
>>>>>     webrev: 
>>>>> http://cr.openjdk.java.net/~aivanov/8080628/jdk9/webrev.00/
>>>>>
>>>>> Description:
>>>>> Since Open and Save buttons in JFileChooser are default ones, 
>>>>> mnemonics are redundant on these buttons.
>>>>>
>>>>> There's no mnemonic on Open and Save buttons in Metal 
>>>>> Look-and-Feel but it's displayed on Open button when a directory 
>>>>> is selected in the file list. This is inconsistent.
>>>>>
>>>>> The fix:
>>>>> Remove mnemonics in JFileChooser from basic.properties which is 
>>>>> used as the base for translation updates.
>>>>> Remove separate JFileChooser keys from metal.properties since 
>>>>> they're the same as in basic.properties now.
>>>>>
>>>>> The test:
>>>>> Regression test checks Open, Save, and Cancel buttons in 
>>>>> JFileChooser have no mnemonics in all the supported localizations 
>>>>> in Metal and Nimbus look-and-feels.
>>>>>
>>>>> Thanks,
>>>>> Alexey
>>>>
>>>>
>>>
>>
>>
>



From Sergey.Bylokhov at oracle.com  Mon May 25 15:15:29 2015
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Mon, 25 May 2015 18:15:29 +0300
Subject: <Swing Dev> [9] Review request for 8080628: No mnemonics on
 Open and Save buttons in JFileChooser
In-Reply-To: <55632398.1010908@oracle.com>
References: <555DCB49.706@oracle.com>
	<555DCF79.6070309@oracle.com>	<555DD17A.2080500@oracle.com>
	<555DDCBC.10204@oracle.com> <555F4ABA.4080807@oracle.com>
	<55632398.1010908@oracle.com>
Message-ID: <55633C91.6080206@oracle.com>

Hi, Alexey.
The fix looks good.

On 25.05.15 16:28, Alexey Ivanov wrote:
> Hi Sergey,
>
> I updated the test once again: removed the unused imported and 
> redundant comma in the locale array.
>
> Updated webrev: 
> http://cr.openjdk.java.net/~aivanov/8080628/jdk9/webrev.02/
>
> It's identical to .01 except for the changes above.
>
>
> Regards,
> Alexey
>
> On 22.05.2015 18:26, Alexey Ivanov wrote:
>> Hi Sergey,
>>
>> Thanks for your comment. I overlooked GTK LaF which also needs updating.
>>
>> I updated the test to iterate over all the installed Look-and-Feels:
>> http://cr.openjdk.java.net/~aivanov/8080628/jdk9/webrev.01/
>>
>> Regards,
>> Alexey
>>
>> On 21.05.2015 16:25, Sergey Bylokhov wrote:
>>> Hi, Alexey.
>>> If is obvious that all others l&f should work, then I do not see the 
>>> reason why we cannot test them.
>>>
>>> On 21.05.15 15:37, Alexey Ivanov wrote:
>>>> Hi Sergey,
>>>>
>>>> Because other look-and-feels do not define their own resources.
>>>> Actually, one LaF would be enough, if Metal did not define its own 
>>>> Open and Save without mnemonics.
>>>>
>>>> I can modify the test to iterate over all the installed LaFs. I 
>>>> just thought it was enough to use these two because either is 
>>>> available on all the platforms, and eventually all LaFs read the 
>>>> values from basic.properties after the fix.
>>>>
>>>> Regards,
>>>> Alexey
>>>>
>>>> On 21.05.2015 15:28, Sergey Bylokhov wrote:
>>>>> Hi, Alexey.
>>>>> Why only two look and fells are covered(metal/nimbus)?
>>>>>
>>>>> On 21.05.15 15:10, Alexey Ivanov wrote:
>>>>>> Hello Swing team,
>>>>>>
>>>>>> Could you please review the fix:
>>>>>>     bug: https://bugs.openjdk.java.net/browse/JDK-8080628
>>>>>>     webrev: 
>>>>>> http://cr.openjdk.java.net/~aivanov/8080628/jdk9/webrev.00/
>>>>>>
>>>>>> Description:
>>>>>> Since Open and Save buttons in JFileChooser are default ones, 
>>>>>> mnemonics are redundant on these buttons.
>>>>>>
>>>>>> There's no mnemonic on Open and Save buttons in Metal 
>>>>>> Look-and-Feel but it's displayed on Open button when a directory 
>>>>>> is selected in the file list. This is inconsistent.
>>>>>>
>>>>>> The fix:
>>>>>> Remove mnemonics in JFileChooser from basic.properties which is 
>>>>>> used as the base for translation updates.
>>>>>> Remove separate JFileChooser keys from metal.properties since 
>>>>>> they're the same as in basic.properties now.
>>>>>>
>>>>>> The test:
>>>>>> Regression test checks Open, Save, and Cancel buttons in 
>>>>>> JFileChooser have no mnemonics in all the supported localizations 
>>>>>> in Metal and Nimbus look-and-feels.
>>>>>>
>>>>>> Thanks,
>>>>>> Alexey
>>>>>
>>>>>
>>>>
>>>
>>>
>>
>


-- 
Best regards, Sergey.



From alexandr.scherbatiy at oracle.com  Mon May 25 15:55:57 2015
From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy)
Date: Mon, 25 May 2015 18:55:57 +0300
Subject: <Swing Dev> [9] Review request for 8080628: No mnemonics on
 Open and Save buttons in JFileChooser
In-Reply-To: <55633C91.6080206@oracle.com>
References: <555DCB49.706@oracle.com>
	<555DCF79.6070309@oracle.com>	<555DD17A.2080500@oracle.com>
	<555DDCBC.10204@oracle.com> <555F4ABA.4080807@oracle.com>
	<55632398.1010908@oracle.com> <55633C91.6080206@oracle.com>
Message-ID: <5563460D.7040809@oracle.com>


   The fix looks good to me.

   Thanks,
   Alexandr.

On 5/25/2015 6:15 PM, Sergey Bylokhov wrote:
> Hi, Alexey.
> The fix looks good.
>
> On 25.05.15 16:28, Alexey Ivanov wrote:
>> Hi Sergey,
>>
>> I updated the test once again: removed the unused imported and 
>> redundant comma in the locale array.
>>
>> Updated webrev: 
>> http://cr.openjdk.java.net/~aivanov/8080628/jdk9/webrev.02/
>>
>> It's identical to .01 except for the changes above.
>>
>>
>> Regards,
>> Alexey
>>
>> On 22.05.2015 18:26, Alexey Ivanov wrote:
>>> Hi Sergey,
>>>
>>> Thanks for your comment. I overlooked GTK LaF which also needs 
>>> updating.
>>>
>>> I updated the test to iterate over all the installed Look-and-Feels:
>>> http://cr.openjdk.java.net/~aivanov/8080628/jdk9/webrev.01/
>>>
>>> Regards,
>>> Alexey
>>>
>>> On 21.05.2015 16:25, Sergey Bylokhov wrote:
>>>> Hi, Alexey.
>>>> If is obvious that all others l&f should work, then I do not see 
>>>> the reason why we cannot test them.
>>>>
>>>> On 21.05.15 15:37, Alexey Ivanov wrote:
>>>>> Hi Sergey,
>>>>>
>>>>> Because other look-and-feels do not define their own resources.
>>>>> Actually, one LaF would be enough, if Metal did not define its own 
>>>>> Open and Save without mnemonics.
>>>>>
>>>>> I can modify the test to iterate over all the installed LaFs. I 
>>>>> just thought it was enough to use these two because either is 
>>>>> available on all the platforms, and eventually all LaFs read the 
>>>>> values from basic.properties after the fix.
>>>>>
>>>>> Regards,
>>>>> Alexey
>>>>>
>>>>> On 21.05.2015 15:28, Sergey Bylokhov wrote:
>>>>>> Hi, Alexey.
>>>>>> Why only two look and fells are covered(metal/nimbus)?
>>>>>>
>>>>>> On 21.05.15 15:10, Alexey Ivanov wrote:
>>>>>>> Hello Swing team,
>>>>>>>
>>>>>>> Could you please review the fix:
>>>>>>>     bug: https://bugs.openjdk.java.net/browse/JDK-8080628
>>>>>>>     webrev: 
>>>>>>> http://cr.openjdk.java.net/~aivanov/8080628/jdk9/webrev.00/
>>>>>>>
>>>>>>> Description:
>>>>>>> Since Open and Save buttons in JFileChooser are default ones, 
>>>>>>> mnemonics are redundant on these buttons.
>>>>>>>
>>>>>>> There's no mnemonic on Open and Save buttons in Metal 
>>>>>>> Look-and-Feel but it's displayed on Open button when a directory 
>>>>>>> is selected in the file list. This is inconsistent.
>>>>>>>
>>>>>>> The fix:
>>>>>>> Remove mnemonics in JFileChooser from basic.properties which is 
>>>>>>> used as the base for translation updates.
>>>>>>> Remove separate JFileChooser keys from metal.properties since 
>>>>>>> they're the same as in basic.properties now.
>>>>>>>
>>>>>>> The test:
>>>>>>> Regression test checks Open, Save, and Cancel buttons in 
>>>>>>> JFileChooser have no mnemonics in all the supported 
>>>>>>> localizations in Metal and Nimbus look-and-feels.
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Alexey
>>>>>>
>>>>>>
>>>>>
>>>>
>>>>
>>>
>>
>
>



From alexandr.scherbatiy at oracle.com  Tue May 26 10:38:49 2015
From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy)
Date: Tue, 26 May 2015 13:38:49 +0300
Subject: <Swing Dev> [9] Review Request for 8078514: Nightly:
 api/javax_swing/DefaultRowSorter/index_ModelStructChanged failure
In-Reply-To: <555DECDB.6020301@oracle.com>
References: <55560786.9010306@oracle.com> <555B1885.2020605@oracle.com>
	<555DECDB.6020301@oracle.com>
Message-ID: <55644D39.2080208@oracle.com>

On 5/21/2015 5:34 PM, Semyon Sadetsky wrote:
> Hello,
>
> I have decided to remake the fix.
> The reason for that is sun.swing.FilePane class. One of its inner 
> classes extends DefaultRowSorter and relays on lazy initialization of 
> the DefaultRowSorter in unsorted state. After removing the lazy init 
> the FilePane crashes with AOB exception.

    It looks like FilePane tries to call some operations like 
DefaultRowSorter.convertRowIndexToView(int) on non updated DefaultRowSorter.
    Is it possible to fix it in FilePane?

   Thanks,
   Alexandr.

> This can be fixed, but I think it will be too big change for the issue 
> and users can be already using the DefaultRowSorter in the similar way.
> Here is the new approach: 
> http://cr.openjdk.java.net/~ssadetsky/8078514/webrev.01/
> It looks a little bit risky ,but all related tests have been passed.
>
> --Semyon
>
> On 5/19/2015 2:03 PM, Alexander Scherbatiy wrote:
>> On 5/15/2015 5:49 PM, Semyon Sadetsky wrote:
>>> Hello,
>>>
>>> Please review fix for JDK9:
>>>
>>> bug: https://bugs.openjdk.java.net/browse/JDK-8078514
>>> webrev: http://cr.openjdk.java.net/~ssadetsky/8078514/webrev.00/
>>
>>   DefaultRowSorter
>> 221             allChanged();
>> 222             modelRowCount = getModelWrapper().getRowCount();
>>
>> - This can be moved to a private method that will be used both in the 
>> public modelStructureChanged() and setModelWrapper() methods.
>>
>> 532     public void sort()
>> - Could the rawFilter be null in case viewToModel != null an 
>> !isUnsorted() ?
>> - isUnsorted() method is called twice. Is it possible to store its 
>> value to a variable and use it?
>>
>> Thanks,
>> Alexandr.
>>
>>>
>>> The 6894632 fix violated a contract between the table and its row 
>>> sorter: the sorter should receive TableChanged events even if table 
>>> is not sorted actually.
>>> Another way to fix 6894632 is to initialize sorter internal 
>>> structures instantly. The last is applied in the fix.
>>>
>>> --Semyon
>>>
>>
>



From alexey.ivanov at oracle.com  Tue May 26 13:54:44 2015
From: alexey.ivanov at oracle.com (Alexey Ivanov)
Date: Tue, 26 May 2015 16:54:44 +0300
Subject: <Swing Dev> [8u-dev] Review request for 8080628: No mnemonics on
 Open and Save buttons in JFileChooser
Message-ID: <55647B24.5070805@oracle.com>

Hello Swing team,

Could you please review the fix for JDK 8:
     bug: https://bugs.openjdk.java.net/browse/JDK-8080628
     webrev: http://cr.openjdk.java.net/~aivanov/8080628/jdk8/webrev.00/

JDK9 code review: 
http://mail.openjdk.java.net/pipermail/swing-dev/2015-May/004547.html

The changes in JDK 8 are the same as in JDK 9, yet there are more files 
that need to be updated: basic_ja.properties, basic_ko.properties, 
basic_zh_CN.properties, basic_zh_TW.properties.


For completeness, here's the information from JDK 9 code review:

Description:
Since Open and Save buttons in JFileChooser are default ones, mnemonics 
are redundant on these buttons.

There's no mnemonic on Open and Save buttons in Metal Look-and-Feel but 
it's displayed on Open button when a directory is selected in the file 
list. This is inconsistent.

The fix:
Remove mnemonics in JFileChooser from basic.properties which is used as 
the base for translation updates.
Remove separate JFileChooser keys from metal.properties since they're 
the same as in basic.properties now.

The test:
Regression test checks Open, Save, and Cancel buttons in JFileChooser 
have no mnemonics in all the supported localizations in all the 
installed look-and-feels.

Thanks,
Alexey


From alexandr.scherbatiy at oracle.com  Tue May 26 13:59:29 2015
From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy)
Date: Tue, 26 May 2015 16:59:29 +0300
Subject: <Swing Dev> [8u-dev] Review request for 8080628: No mnemonics
 on Open and Save buttons in JFileChooser
In-Reply-To: <55647B24.5070805@oracle.com>
References: <55647B24.5070805@oracle.com>
Message-ID: <55647C41.40101@oracle.com>


   The fix looks good to me.

   Thanks,
   Alexandr.

On 5/26/2015 4:54 PM, Alexey Ivanov wrote:
> Hello Swing team,
>
> Could you please review the fix for JDK 8:
>     bug: https://bugs.openjdk.java.net/browse/JDK-8080628
>     webrev: http://cr.openjdk.java.net/~aivanov/8080628/jdk8/webrev.00/
>
> JDK9 code review: 
> http://mail.openjdk.java.net/pipermail/swing-dev/2015-May/004547.html
>
> The changes in JDK 8 are the same as in JDK 9, yet there are more 
> files that need to be updated: basic_ja.properties, 
> basic_ko.properties, basic_zh_CN.properties, basic_zh_TW.properties.
>
>
> For completeness, here's the information from JDK 9 code review:
>
> Description:
> Since Open and Save buttons in JFileChooser are default ones, 
> mnemonics are redundant on these buttons.
>
> There's no mnemonic on Open and Save buttons in Metal Look-and-Feel 
> but it's displayed on Open button when a directory is selected in the 
> file list. This is inconsistent.
>
> The fix:
> Remove mnemonics in JFileChooser from basic.properties which is used 
> as the base for translation updates.
> Remove separate JFileChooser keys from metal.properties since they're 
> the same as in basic.properties now.
>
> The test:
> Regression test checks Open, Save, and Cancel buttons in JFileChooser 
> have no mnemonics in all the supported localizations in all the 
> installed look-and-feels.
>
> Thanks,
> Alexey



From philip.race at oracle.com  Tue May 26 18:48:07 2015
From: philip.race at oracle.com (Phil Race)
Date: Tue, 26 May 2015 11:48:07 -0700
Subject: <Swing Dev> RFR:  8081231: JDK9 client build broken on Windows
Message-ID: <5564BFE7.7070207@oracle.com>

https://bugs.openjdk.java.net/browse/JDK-8081231


ShellFolder2 only gets a definition of DASSERT if DEBUG is defined.

Proposed fix :-

diff --git 
a/src/java.desktop/windows/native/libawt/windows/ShellFolder2.cpp 
b/src/java.desktop/windows/native/libawt/windows/ShellFolder2.cpp
--- a/src/java.desktop/windows/native/libawt/windows/ShellFolder2.cpp
+++ b/src/java.desktop/windows/native/libawt/windows/ShellFolder2.cpp
@@ -66,7 +66,9 @@

  #define DEFINE_FIELD_ID(var, cls, field, type) \
      jfieldID var = env->GetFieldID(cls, field, type); \
+#ifdef DEBUG
      DASSERT(var != NULL); \
+#endif
      CHECK_NULL_RETURN(var, NULL);

-phil.


From alexander.zvegintsev at oracle.com  Tue May 26 19:14:31 2015
From: alexander.zvegintsev at oracle.com (Alexander Zvegintsev)
Date: Tue, 26 May 2015 22:14:31 +0300
Subject: <Swing Dev> <AWT Dev> RFR: 8081231: JDK9 client build broken on
	Windows
In-Reply-To: <5564BFE7.7070207@oracle.com>
References: <5564BFE7.7070207@oracle.com>
Message-ID: <5564C617.3000203@oracle.com>

Looks fine

--
Thanks,
Alexander.

On 26.05.2015 21:48, Phil Race wrote:
> https://bugs.openjdk.java.net/browse/JDK-8081231
>
>
> ShellFolder2 only gets a definition of DASSERT if DEBUG is defined.
>
> Proposed fix :-
>
> diff --git 
> a/src/java.desktop/windows/native/libawt/windows/ShellFolder2.cpp 
> b/src/java.desktop/windows/native/libawt/windows/ShellFolder2.cpp
> --- a/src/java.desktop/windows/native/libawt/windows/ShellFolder2.cpp
> +++ b/src/java.desktop/windows/native/libawt/windows/ShellFolder2.cpp
> @@ -66,7 +66,9 @@
>
>  #define DEFINE_FIELD_ID(var, cls, field, type) \
>      jfieldID var = env->GetFieldID(cls, field, type); \
> +#ifdef DEBUG
>      DASSERT(var != NULL); \
> +#endif
>      CHECK_NULL_RETURN(var, NULL);
>
> -phil.



From philip.race at oracle.com  Tue May 26 20:41:43 2015
From: philip.race at oracle.com (Phil Race)
Date: Tue, 26 May 2015 13:41:43 -0700
Subject: <Swing Dev> <AWT Dev> RFR: 8081231: JDK9 client build broken on
	Windows
In-Reply-To: <5564C617.3000203@oracle.com>
References: <5564BFE7.7070207@oracle.com> <5564C617.3000203@oracle.com>
Message-ID: <5564DA87.1060007@oracle.com>

Actually no it wasn't :-)  I'd overlooked the line escapes.

So I'll try the following approach :- (but I am waiting for my build to 
complete) :-
diff --git 
a/src/java.desktop/windows/native/libawt/windows/ShellFolder2.cpp 
b/src/java.desktop/windows/native/libawt/windows/ShellFolder2.cpp
--- a/src/java.desktop/windows/native/libawt/windows/ShellFolder2.cpp
+++ b/src/java.desktop/windows/native/libawt/windows/ShellFolder2.cpp
@@ -64,6 +64,9 @@

  //#include <sun_awt_shell_Win32ShellFolder2.h>

+#ifndef DASSERT
+#define DASSERT(x)
+#endif
  #define DEFINE_FIELD_ID(var, cls, field, 
type)                            \
      jfieldID var = env->GetFieldID(cls, field, 
type);                     \
      DASSERT(var != 
NULL);                                                 \

-phil.

On 05/26/2015 12:14 PM, Alexander Zvegintsev wrote:
> Looks fine
>
> -- 
> Thanks,
> Alexander.
>
> On 26.05.2015 21:48, Phil Race wrote:
>> https://bugs.openjdk.java.net/browse/JDK-8081231
>>
>>
>> ShellFolder2 only gets a definition of DASSERT if DEBUG is defined.
>>
>> Proposed fix :-
>>
>> diff --git 
>> a/src/java.desktop/windows/native/libawt/windows/ShellFolder2.cpp 
>> b/src/java.desktop/windows/native/libawt/windows/ShellFolder2.cpp
>> --- a/src/java.desktop/windows/native/libawt/windows/ShellFolder2.cpp
>> +++ b/src/java.desktop/windows/native/libawt/windows/ShellFolder2.cpp
>> @@ -66,7 +66,9 @@
>>
>>  #define DEFINE_FIELD_ID(var, cls, field, type) \
>>      jfieldID var = env->GetFieldID(cls, field, type); \
>> +#ifdef DEBUG
>>      DASSERT(var != NULL); \
>> +#endif
>>      CHECK_NULL_RETURN(var, NULL);
>>
>> -phil.
>



From alexander.zvegintsev at oracle.com  Tue May 26 21:17:51 2015
From: alexander.zvegintsev at oracle.com (Alexander Zvegintsev)
Date: Wed, 27 May 2015 00:17:51 +0300
Subject: <Swing Dev> <AWT Dev> RFR: 8081231: JDK9 client build broken on
	Windows
In-Reply-To: <5564DA87.1060007@oracle.com>
References: <5564BFE7.7070207@oracle.com> <5564C617.3000203@oracle.com>
	<5564DA87.1060007@oracle.com>
Message-ID: <5564E2FF.9010804@oracle.com>

Oh, I see :)
+1

--
Thanks,
Alexander.

On 26.05.2015 23:41, Phil Race wrote:
> Actually no it wasn't :-)  I'd overlooked the line escapes.
>
> So I'll try the following approach :- (but I am waiting for my build 
> to complete) :-
> diff --git 
> a/src/java.desktop/windows/native/libawt/windows/ShellFolder2.cpp 
> b/src/java.desktop/windows/native/libawt/windows/ShellFolder2.cpp
> --- a/src/java.desktop/windows/native/libawt/windows/ShellFolder2.cpp
> +++ b/src/java.desktop/windows/native/libawt/windows/ShellFolder2.cpp
> @@ -64,6 +64,9 @@
>
>  //#include <sun_awt_shell_Win32ShellFolder2.h>
>
> +#ifndef DASSERT
> +#define DASSERT(x)
> +#endif
>  #define DEFINE_FIELD_ID(var, cls, field, 
> type)                            \
>      jfieldID var = env->GetFieldID(cls, field, 
> type);                     \
>      DASSERT(var != 
> NULL);                                                 \
>
> -phil.
>
> On 05/26/2015 12:14 PM, Alexander Zvegintsev wrote:
>> Looks fine
>>
>> -- 
>> Thanks,
>> Alexander.
>>
>> On 26.05.2015 21:48, Phil Race wrote:
>>> https://bugs.openjdk.java.net/browse/JDK-8081231
>>>
>>>
>>> ShellFolder2 only gets a definition of DASSERT if DEBUG is defined.
>>>
>>> Proposed fix :-
>>>
>>> diff --git 
>>> a/src/java.desktop/windows/native/libawt/windows/ShellFolder2.cpp 
>>> b/src/java.desktop/windows/native/libawt/windows/ShellFolder2.cpp
>>> --- a/src/java.desktop/windows/native/libawt/windows/ShellFolder2.cpp
>>> +++ b/src/java.desktop/windows/native/libawt/windows/ShellFolder2.cpp
>>> @@ -66,7 +66,9 @@
>>>
>>>  #define DEFINE_FIELD_ID(var, cls, field, type) \
>>>      jfieldID var = env->GetFieldID(cls, field, type); \
>>> +#ifdef DEBUG
>>>      DASSERT(var != NULL); \
>>> +#endif
>>>      CHECK_NULL_RETURN(var, NULL);
>>>
>>> -phil.
>>
>



From Sergey.Bylokhov at oracle.com  Thu May 28 12:59:23 2015
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Thu, 28 May 2015 15:59:23 +0300
Subject: <Swing Dev> [8u-dev] Review request for 8080628: No mnemonics
 on Open and Save buttons in JFileChooser
In-Reply-To: <55647C41.40101@oracle.com>
References: <55647B24.5070805@oracle.com> <55647C41.40101@oracle.com>
Message-ID: <5567112B.9000808@oracle.com>

Looks fine.

On 26.05.15 16:59, Alexander Scherbatiy wrote:
>
>   The fix looks good to me.
>
>   Thanks,
>   Alexandr.
>
> On 5/26/2015 4:54 PM, Alexey Ivanov wrote:
>> Hello Swing team,
>>
>> Could you please review the fix for JDK 8:
>>     bug: https://bugs.openjdk.java.net/browse/JDK-8080628
>>     webrev: http://cr.openjdk.java.net/~aivanov/8080628/jdk8/webrev.00/
>>
>> JDK9 code review: 
>> http://mail.openjdk.java.net/pipermail/swing-dev/2015-May/004547.html
>>
>> The changes in JDK 8 are the same as in JDK 9, yet there are more 
>> files that need to be updated: basic_ja.properties, 
>> basic_ko.properties, basic_zh_CN.properties, basic_zh_TW.properties.
>>
>>
>> For completeness, here's the information from JDK 9 code review:
>>
>> Description:
>> Since Open and Save buttons in JFileChooser are default ones, 
>> mnemonics are redundant on these buttons.
>>
>> There's no mnemonic on Open and Save buttons in Metal Look-and-Feel 
>> but it's displayed on Open button when a directory is selected in the 
>> file list. This is inconsistent.
>>
>> The fix:
>> Remove mnemonics in JFileChooser from basic.properties which is used 
>> as the base for translation updates.
>> Remove separate JFileChooser keys from metal.properties since they're 
>> the same as in basic.properties now.
>>
>> The test:
>> Regression test checks Open, Save, and Cancel buttons in JFileChooser 
>> have no mnemonics in all the supported localizations in all the 
>> installed look-and-feels.
>>
>> Thanks,
>> Alexey
>


-- 
Best regards, Sergey.



From semyon.sadetsky at oracle.com  Thu May 28 15:29:25 2015
From: semyon.sadetsky at oracle.com (Semyon Sadetsky)
Date: Thu, 28 May 2015 18:29:25 +0300
Subject: <Swing Dev> [9] Review Request for 8075785: The regression-swing
 case failed as colored text is not shown on disabled checkbox and radio
 button with the special options "-client
 -Dswing.defaultlaf=com.sun.java.swing.plaf.windows.WindowsClassicLookAndFeel".
Message-ID: <55673455.30202@oracle.com>

Hello,

Please review fix for JDK9:

bug: https://bugs.openjdk.java.net/browse/JDK-8075785
webrev: http://cr.openjdk.java.net/~ssadetsky/8075785/webrev.00/

*.disabledText properties are not suported in in Windows Classic L&F & 
Windows XP L&F.
In the fix the properties remain optional but are taken into account if 
set by user.

--Semyon


From javalists at cbfiddle.com  Fri May 29 02:13:12 2015
From: javalists at cbfiddle.com (Alan Snyder)
Date: Thu, 28 May 2015 19:13:12 -0700
Subject: <Swing Dev> internal API usage: sun.awt.AppContext
Message-ID: <9AC86A8B-CE08-473A-8019-B8B29F7DF6CA@cbfiddle.com>

I am using code ? a custom Swing look and feel ? that uses the getAppContext(), get(), put(), and remove() methods of sun.awt.AppContext to store configuration data.

Since the look and feel is registered by UIManager using the same mechanism, this seems like the right way to store configuration data for a look and feel.

I also note that AppContext advertises itself as a better solution (e.g. better than static fields) to protect applets from being disrupted by other applets, so it may have other uses.

Is there a way to duplicate this behavior using only public APIs? If not, I request that this functionality be exported in some form by JDK 9.

  Alan



From Sergey.Bylokhov at oracle.com  Fri May 29 10:24:29 2015
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Fri, 29 May 2015 13:24:29 +0300
Subject: <Swing Dev> [9] Review Request for 8075785: The
 regression-swing case failed as colored text is not shown on disabled
 checkbox and radio button with the special options "-client
 -Dswing.defaultlaf=com.sun.java.swing.plaf.windows.WindowsClassicLookAndFeel".
In-Reply-To: <55673455.30202@oracle.com>
References: <55673455.30202@oracle.com>
Message-ID: <55683E5D.1080901@oracle.com>

Hi, Semyon.
Why not set this properties in the look and feel to the same color as 
"Button.shadow" and use it WindowsGraphicsUtils?

On 28.05.15 18:29, Semyon Sadetsky wrote:
> Hello,
>
> Please review fix for JDK9:
>
> bug: https://bugs.openjdk.java.net/browse/JDK-8075785
> webrev: http://cr.openjdk.java.net/~ssadetsky/8075785/webrev.00/
>
> *.disabledText properties are not suported in in Windows Classic L&F & 
> Windows XP L&F.
> In the fix the properties remain optional but are taken into account 
> if set by user.
>
> --Semyon


-- 
Best regards, Sergey.



From alexander.v.stepanov at oracle.com  Fri May 29 11:58:57 2015
From: alexander.v.stepanov at oracle.com (alexander stepanov)
Date: Fri, 29 May 2015 14:58:57 +0300
Subject: <Swing Dev> RFR [9] 8081313: MultipleDocumentHandling.java: tidy
	warnings
Message-ID: <55685481.3040702@oracle.com>

Hello,

Could you please review fix
http://cr.openjdk.java.net/~avstepan/8081313/webrev.00/
for
https://bugs.openjdk.java.net/browse/JDK-8081313

Just a minor fix of docs; other code is not affected.

Thanks,
Alexander