From Sergey.Bylokhov at oracle.com  Fri Apr  1 00:07:27 2016
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Fri, 1 Apr 2016 03:07:27 +0300
Subject: <Swing Dev> [9] Review request for 8136366 Add a public API to
 create a L&F without installation
In-Reply-To: <56FCC8B4.1040406@oracle.com>
References: <56FCC8B4.1040406@oracle.com>
Message-ID: <56FDBBBF.2090308@oracle.com>

On 31.03.16 9:50, Alexandr Scherbatiy wrote:
>    Some Swing L&Fs are not public. It is not possible to create them
> using reflection now in JDK 9 because of the modularization feature.
>    There are use cases when some information should be obtained from a
> L&F without its installation
>     - check if L&F is supported
>     - take some defaults to use it in custom L&F
>
>    The proposed solution adds UIManager.createLookAndFeel(className)
> method which allows to create a given L&F without installation.

It is interesting should we allow creation of any L&F or only those 
which were installed and/or supported? I recall that it was possible to 
initialize the windows l&f on linux, Will the new method add a 
possibility to create it? if yes should we support that?


-- 
Best regards, Sergey.


From philip.race at oracle.com  Fri Apr  1 00:32:17 2016
From: philip.race at oracle.com (Philip Race)
Date: Thu, 31 Mar 2016 17:32:17 -0700
Subject: <Swing Dev> [9] Review request for 8136366 Add a public API to
 create a L&F without installation
In-Reply-To: <56FDBBBF.2090308@oracle.com>
References: <56FCC8B4.1040406@oracle.com> <56FDBBBF.2090308@oracle.com>
Message-ID: <56FDC191.7030301@oracle.com>

 > I recall that it was possible to initialize the windows l&f on linux

Do you mean it was "impossible" ?

As far as I can tell this API lets you create (initialize) as you always 
could
although previously you could not get a handle to it, but with this
change even if you can obtain the L&F you still can't install it.
But there is a good question there .. will it fail in some way when you
call methods on even if it is not installed it if it is not on the 
appropriate platform ?
Perhaps due to missing native library support ?
If that or anything else is a concern then we should call
isSupportedLookAndFeel() to check before returning it (and document that).
Possibly this will cause an issue for people who were doing this 
directly on the
unsupported platform and did not have to deal with that check, but I doubt
that anyone ought to do that anyway.

So probably best to add the check.

-phil.

On 3/31/16, 5:07 PM, Sergey Bylokhov wrote:
> On 31.03.16 9:50, Alexandr Scherbatiy wrote:
>>    Some Swing L&Fs are not public. It is not possible to create them
>> using reflection now in JDK 9 because of the modularization feature.
>>    There are use cases when some information should be obtained from a
>> L&F without its installation
>>     - check if L&F is supported
>>     - take some defaults to use it in custom L&F
>>
>>    The proposed solution adds UIManager.createLookAndFeel(className)
>> method which allows to create a given L&F without installation.
>
> It is interesting should we allow creation of any L&F or only those 
> which were installed and/or supported? I recall that it was possible 
> to initialize the windows l&f on linux, Will the new method add a 
> possibility to create it? if yes should we support that?
>
>


From semyon.sadetsky at oracle.com  Fri Apr  1 06:38:43 2016
From: semyon.sadetsky at oracle.com (Semyon Sadetsky)
Date: Fri, 1 Apr 2016 09:38:43 +0300
Subject: <Swing Dev> [9] Review request for 8136366 Add a public API to
 create a L&F without installation
In-Reply-To: <56FCC8B4.1040406@oracle.com>
References: <56FCC8B4.1040406@oracle.com>
Message-ID: <56FE1773.3010303@oracle.com>

Looks good.

--Semyon

On 3/31/2016 9:50 AM, Alexandr Scherbatiy wrote:
>
> Hello,
>
> Could you review the fix:
>   bug: https://bugs.openjdk.java.net/browse/JDK-8136366
>   webrev: http://cr.openjdk.java.net/~alexsch/8136366/webrev.00
>
>   Some Swing L&Fs are not public. It is not possible to create them 
> using reflection now in JDK 9 because of the modularization feature.
>
>   There are use cases when some information should be obtained from a 
> L&F without its installation
>    - check if L&F is supported
>    - take some defaults to use it in custom L&F
>
>   The proposed solution adds UIManager.createLookAndFeel(className) 
> method which allows to create a given L&F without installation.
>
>  Thanks,
>  Alexandr.
>



From prem.balakrishnan at oracle.com  Fri Apr  1 08:18:57 2016
From: prem.balakrishnan at oracle.com (Prem Balakrishnan)
Date: Fri, 1 Apr 2016 01:18:57 -0700 (PDT)
Subject: <Swing Dev> Review Request JDK-6897701 : In Nimbus Disabled
 Menus and Menu Items don't look disabled
In-Reply-To: <56FD5B28.2030101@oracle.com>
References: <dd6748bf-e63c-441c-9a8a-9301920cf85e@default>
	<56FC0626.1060801@oracle.com>
	<0e92d730-eae3-492e-840b-d531171a262b@default>
	<56FD5B28.2030101@oracle.com>
Message-ID: <fcffb145-2e1d-480f-a7cd-7c48d94b34f5@default>

Hi Alexander,

Please review the updated patch as per review comments.

http://cr.openjdk.java.net/~arajkumar/prem/6897701/webrev.02/

Regards,
Prem

 

 

From: Alexander Scherbatiy 
Sent: Thursday, March 31, 2016 10:45 PM
To: Prem Balakrishnan; Semyon Sadetsky; Sergey Bylokhov; Rajeev Chamyal; swing-dev at openjdk.java.net
Subject: Re: Review Request JDK-6897701 : In Nimbus Disabled Menus and Menu Items don't look disabled

 

On 31/03/16 15:30, Prem Balakrishnan wrote:



Hi Semyon and Alexander

 

Thankyou for the review.

 

As per review comments,

 

Suggested fix will affect JRadioButton and JCheckBox states. 

Hence modified with the NEW Fix .

Also Test automated. 

Please review the updated patch.

http://cr.openjdk.java.net/~arapte/prem/6897701/webrev.01/

 

 - JMenu extends JMenuItem so the "c instanceof JMenu" is not necessary
 - The caught exception in the test should be re-thrown

 Thanks,
 Alexandr.



Regards,

Prem

 

 

From: Semyon Sadetsky 
Sent: Wednesday, March 30, 2016 10:30 PM
To: Prem Balakrishnan; Sergey Bylokhov; Alexander Scherbatiy; Rajeev Chamyal; HYPERLINK "mailto:swing-dev at openjdk.java.net"swing-dev at openjdk.java.net
Subject: Re: Review Request JDK-6897701 : In Nimbus Disabled Menus and Menu Items don't look disabled

 

Hi Prem,

In the block above the line you've changed:

 764         if ((context.getComponentState() & SynthConstants.DISABLED) != 0) {
 765             //This component is disabled, so return the disabled color.
 766             //In some cases this means ignoring the color specified by the
 767             //developer on the component. In other cases it means using a
 768             //specified disabledTextColor, such as on JTextComponents.
 769             //For example, JLabel doesn't specify a disabled color that the
 770             //developer can set, yet it should have a disabled color to the
 771             //text when the label is disabled. This code allows for that.

does not it solve the similar problem? Maybe it would be just better to add JMenu and JMenuItem case in it?

I'm just not sure that the condition (state == SynthConstants.ENABLED) will work if the menu item is a radio or a checkbox because the may have SynthConstants.SELECTED flag as well. Will this work for selected radio & checkbox?

--Semyon

On 3/30/2016 3:02 PM, Prem Balakrishnan wrote:

Hi,

Please review fix for JDK9,

Bug: https://bugs.openjdk.java.net/browse/JDK-6897701

Webrev: HYPERLINK "http://cr.openjdk.java.net/%7Earapte/prem/6897701/webrev.00/"http://cr.openjdk.java.net/~arapte/prem/6897701/webrev.00/

  

Issue:

In Nimbus Disabled Menus and Menu Items don't look disabled

 

Cause:

For JMenu and JMenuItem, Developer specified TEXT_FOREGROUND color was set even when they were Disabled.

(Instead of setting Color for the State)

 

Fix:

When JMenu and JMenuItem is disabled, Color for the State is used.

 

Test: Manual Test(since visual validation is required)

 

Regards,
Prem

 

 

 

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

From semyon.sadetsky at oracle.com  Fri Apr  1 10:18:20 2016
From: semyon.sadetsky at oracle.com (Semyon Sadetsky)
Date: Fri, 1 Apr 2016 13:18:20 +0300
Subject: <Swing Dev> Review Request JDK-6897701 : In Nimbus Disabled
 Menus and Menu Items don't look disabled
In-Reply-To: <fcffb145-2e1d-480f-a7cd-7c48d94b34f5@default>
References: <dd6748bf-e63c-441c-9a8a-9301920cf85e@default>
	<56FC0626.1060801@oracle.com>
	<0e92d730-eae3-492e-840b-d531171a262b@default>
	<56FD5B28.2030101@oracle.com>
	<fcffb145-2e1d-480f-a7cd-7c48d94b34f5@default>
Message-ID: <56FE4AEC.9080209@oracle.com>

Looks good.

--Semyon

On 4/1/2016 11:18 AM, Prem Balakrishnan wrote:
>
> Hi Alexander,
>
> Please review the updated patch as per review comments.
>
> http://cr.openjdk.java.net/~arajkumar/prem/6897701/webrev.02/ 
> <http://cr.openjdk.java.net/%7Earajkumar/prem/6897701/webrev.02/>
>
> Regards,
> Prem
>
> *From:*Alexander Scherbatiy
> *Sent:* Thursday, March 31, 2016 10:45 PM
> *To:* Prem Balakrishnan; Semyon Sadetsky; Sergey Bylokhov; Rajeev 
> Chamyal; swing-dev at openjdk.java.net
> *Subject:* Re: Review Request JDK-6897701 : In Nimbus Disabled Menus 
> and Menu Items don't look disabled
>
> On 31/03/16 15:30, Prem Balakrishnan wrote:
>
> Hi Semyon and Alexander
>
> Thankyou for the review.
>
> As per review comments,
>
> Suggested fix will affect JRadioButton and JCheckBox states.
>
> Hence modified with the NEW Fix .
>
> Also Test automated.
>
> Please review the updated patch.
>
> http://cr.openjdk.java.net/~arapte/prem/6897701/webrev.01/ 
> <http://cr.openjdk.java.net/%7Earapte/prem/6897701/webrev.01/>
>
>  - JMenu extends JMenuItem so the "c instanceof JMenu" is not necessary
>  - The caught exception in the test should be re-thrown
>
>  Thanks,
>  Alexandr.
>
> Regards,
>
> Prem
>
> *From:*Semyon Sadetsky
> *Sent:* Wednesday, March 30, 2016 10:30 PM
> *To:* Prem Balakrishnan; Sergey Bylokhov; Alexander Scherbatiy; Rajeev 
> Chamyal; swing-dev at openjdk.java.net <mailto:swing-dev at openjdk.java.net>
> *Subject:* Re: Review Request JDK-6897701 : In Nimbus Disabled Menus 
> and Menu Items don't look disabled
>
> Hi Prem,
>
> In the block above the line you've changed:
>
>  764         if ((context.getComponentState() & 
> SynthConstants.DISABLED) != 0) {
>  765             //This component is disabled, so return the disabled 
> color.
>  766             //In some cases this means ignoring the color 
> specified by the
>  767             //developer on the component. In other cases it means 
> using a
>  768             //specified disabledTextColor, such as on 
> JTextComponents.
>  769             //For example, JLabel doesn't specify a disabled 
> color that the
>  770             //developer can set, yet it should have a disabled 
> color to the
>  771             //text when the label is disabled. This code allows 
> for that.
>
> does not it solve the similar problem? Maybe it would be just better 
> to add JMenu and JMenuItem case in it?
>
> I'm just not sure that the condition (state == SynthConstants.ENABLED) 
> will work if the menu item is a radio or a checkbox because the may 
> have SynthConstants.SELECTED flag as well. Will this work for selected 
> radio & checkbox?
>
> --Semyon
>
> On 3/30/2016 3:02 PM, Prem Balakrishnan wrote:
>
>     Hi*,*
>
>     Please review fix for JDK9,
>
>     *Bug:*https://bugs.openjdk.java.net/browse/JDK-6897701
>
>     *Webrev:*http://cr.openjdk.java.net/~arapte/prem/6897701/webrev.00/ <http://cr.openjdk.java.net/%7Earapte/prem/6897701/webrev.00/>
>
>     *Issue:*
>
>     In Nimbus Disabled Menus and Menu Items don't look disabled
>
>     *Cause:*
>
>     For JMenu and JMenuItem, Developer specified TEXT_FOREGROUND color
>     was set even when they were Disabled.
>
>     (Instead of setting Color for the State)
>
>     *Fix:*
>
>     When JMenu and JMenuItem is disabled, Color for the State is used.
>
>     *Test: *Manual Test(since visual validation is required)
>
>     Regards,
>     Prem
>

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

From alexandr.scherbatiy at oracle.com  Fri Apr  1 11:33:26 2016
From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy)
Date: Fri, 1 Apr 2016 15:33:26 +0400
Subject: <Swing Dev> Review Request JDK-6897701 : In Nimbus Disabled
 Menus and Menu Items don't look disabled
In-Reply-To: <56FE4AEC.9080209@oracle.com>
References: <dd6748bf-e63c-441c-9a8a-9301920cf85e@default>
	<56FC0626.1060801@oracle.com>
	<0e92d730-eae3-492e-840b-d531171a262b@default>
	<56FD5B28.2030101@oracle.com>
	<fcffb145-2e1d-480f-a7cd-7c48d94b34f5@default>
	<56FE4AEC.9080209@oracle.com>
Message-ID: <56FE5C86.1040506@oracle.com>


The fix looks good to me.

Thanks,
Alexandr.

On 01/04/16 14:18, Semyon Sadetsky wrote:
> Looks good.
>
> --Semyon
>
> On 4/1/2016 11:18 AM, Prem Balakrishnan wrote:
>>
>> Hi Alexander,
>>
>> Please review the updated patch as per review comments.
>>
>> http://cr.openjdk.java.net/~arajkumar/prem/6897701/webrev.02/
>>
>> Regards,
>> Prem
>>
>> *From:*Alexander Scherbatiy
>> *Sent:* Thursday, March 31, 2016 10:45 PM
>> *To:* Prem Balakrishnan; Semyon Sadetsky; Sergey Bylokhov; Rajeev 
>> Chamyal; swing-dev at openjdk.java.net
>> *Subject:* Re: Review Request JDK-6897701 : In Nimbus Disabled Menus 
>> and Menu Items don't look disabled
>>
>> On 31/03/16 15:30, Prem Balakrishnan wrote:
>>
>> Hi Semyon and Alexander
>>
>> Thankyou for the review.
>>
>> As per review comments,
>>
>> Suggested fix will affect JRadioButton and JCheckBox states.
>>
>> Hence modified with the NEW Fix .
>>
>> Also Test automated.
>>
>> Please review the updated patch.
>>
>> http://cr.openjdk.java.net/~arapte/prem/6897701/webrev.01/
>>
>>  - JMenu extends JMenuItem so the "c instanceof JMenu" is not necessary
>>  - The caught exception in the test should be re-thrown
>>
>>  Thanks,
>>  Alexandr.
>>
>> Regards,
>>
>> Prem
>>
>> *From:*Semyon Sadetsky
>> *Sent:* Wednesday, March 30, 2016 10:30 PM
>> *To:* Prem Balakrishnan; Sergey Bylokhov; Alexander Scherbatiy; 
>> Rajeev Chamyal; swing-dev at openjdk.java.net 
>> <mailto:swing-dev at openjdk.java.net>
>> *Subject:* Re: Review Request JDK-6897701 : In Nimbus Disabled Menus 
>> and Menu Items don't look disabled
>>
>> Hi Prem,
>>
>> In the block above the line you've changed:
>>
>>  764         if ((context.getComponentState() & 
>> SynthConstants.DISABLED) != 0) {
>>  765             //This component is disabled, so return the disabled 
>> color.
>>  766             //In some cases this means ignoring the color 
>> specified by the
>>  767             //developer on the component. In other cases it 
>> means using a
>>  768             //specified disabledTextColor, such as on 
>> JTextComponents.
>>  769             //For example, JLabel doesn't specify a disabled 
>> color that the
>>  770             //developer can set, yet it should have a disabled 
>> color to the
>>  771             //text when the label is disabled. This code allows 
>> for that.
>>
>> does not it solve the similar problem? Maybe it would be just better 
>> to add JMenu and JMenuItem case in it?
>>
>> I'm just not sure that the condition (state == 
>> SynthConstants.ENABLED) will work if the menu item is a radio or a 
>> checkbox because the may have SynthConstants.SELECTED flag as well. 
>> Will this work for selected radio & checkbox?
>>
>> --Semyon
>>
>> On 3/30/2016 3:02 PM, Prem Balakrishnan wrote:
>>
>>     Hi*,*
>>
>>     Please review fix for JDK9,
>>
>>     *Bug:*https://bugs.openjdk.java.net/browse/JDK-6897701
>>
>>     *Webrev:*http://cr.openjdk.java.net/~arapte/prem/6897701/webrev.00/
>>     <http://cr.openjdk.java.net/%7Earapte/prem/6897701/webrev.00/>
>>
>>     *Issue:*
>>
>>     In Nimbus Disabled Menus and Menu Items don't look disabled
>>
>>     *Cause:*
>>
>>     For JMenu and JMenuItem, Developer specified TEXT_FOREGROUND
>>     color was set even when they were Disabled.
>>
>>     (Instead of setting Color for the State)
>>
>>     *Fix:*
>>
>>     When JMenu and JMenuItem is disabled, Color for the State is used.
>>
>>     *Test: *Manual Test(since visual validation is required)
>>
>>     Regards,
>>     Prem
>>
>

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

From alexandr.scherbatiy at oracle.com  Fri Apr  1 11:49:09 2016
From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy)
Date: Fri, 1 Apr 2016 15:49:09 +0400
Subject: <Swing Dev> [9] Review request for 8136366 Add a public API to
 create a L&F without installation
In-Reply-To: <56FDC191.7030301@oracle.com>
References: <56FCC8B4.1040406@oracle.com> <56FDBBBF.2090308@oracle.com>
	<56FDC191.7030301@oracle.com>
Message-ID: <56FE6035.7050806@oracle.com>

On 01/04/16 04:32, Philip Race wrote:
> > I recall that it was possible to initialize the windows l&f on linux
>
> Do you mean it was "impossible" ?
   There was a test that directly overrode isSupportedLookAndFeel() 
method to true for Windows L&F and set it on all platforms including Linux.
   We had a request to backport this fix from JDK 8 to JDK 7 but without 
explanation there it will be used:
http://mail.openjdk.java.net/pipermail/swing-dev/2013-October/003092.html

  The one reason for the current fix was to have a way to get some 
information from a L&F without installing it. May be someone wants to 
get fonts or colors from Windows L&F on Linux for its own custom L&F? It 
would be useful to allow it.

  Thanks,
  Alexandr.

>
> As far as I can tell this API lets you create (initialize) as you 
> always could
> although previously you could not get a handle to it, but with this
> change even if you can obtain the L&F you still can't install it.
> But there is a good question there .. will it fail in some way when you
> call methods on even if it is not installed it if it is not on the 
> appropriate platform ?
> Perhaps due to missing native library support ?
> If that or anything else is a concern then we should call
> isSupportedLookAndFeel() to check before returning it (and document 
> that).
> Possibly this will cause an issue for people who were doing this 
> directly on the
> unsupported platform and did not have to deal with that check, but I 
> doubt
> that anyone ought to do that anyway.
>
> So probably best to add the check.
>
> -phil.
>
> On 3/31/16, 5:07 PM, Sergey Bylokhov wrote:
>> On 31.03.16 9:50, Alexandr Scherbatiy wrote:
>>>    Some Swing L&Fs are not public. It is not possible to create them
>>> using reflection now in JDK 9 because of the modularization feature.
>>>    There are use cases when some information should be obtained from a
>>> L&F without its installation
>>>     - check if L&F is supported
>>>     - take some defaults to use it in custom L&F
>>>
>>>    The proposed solution adds UIManager.createLookAndFeel(className)
>>> method which allows to create a given L&F without installation.
>>
>> It is interesting should we allow creation of any L&F or only those 
>> which were installed and/or supported? I recall that it was possible 
>> to initialize the windows l&f on linux, Will the new method add a 
>> possibility to create it? if yes should we support that?
>>
>>



From neugens at redhat.com  Fri Apr  1 12:12:36 2016
From: neugens at redhat.com (Mario Torre)
Date: Fri, 1 Apr 2016 14:12:36 +0200
Subject: <Swing Dev> [9] Review request for 8136366 Add a public API to
 create a L&F without installation
In-Reply-To: <56FE6035.7050806@oracle.com>
References: <56FCC8B4.1040406@oracle.com> <56FDBBBF.2090308@oracle.com>
	<56FDC191.7030301@oracle.com> <56FE6035.7050806@oracle.com>
Message-ID: <CAJwKKmYYs7Od94jPqNcmNEkFz2arSSX0-UPN+fK4T0WiW703Qw@mail.gmail.com>

On Fri, Apr 1, 2016 at 1:49 PM, Alexander Scherbatiy
<alexandr.scherbatiy at oracle.com> wrote:
> May be someone wants to get
> fonts or colors from Windows L&F on Linux for its own custom L&F? It would
> be useful to allow it.

I don't think this would make any sense, the colours would still
depend on a specific version of the OS, so is not clear what
UIDefaults are returned by the Windows LAF on Linux or OSX, and those
may also be different in different versions of Windows itself.

I believe the Windows LAF is not "simulated" either, but the rendering
is redirected to native widgets pretty much like the GTK/OSX Look and
Feels work, so I doubt that running an application with the Windows
LAF under Linux would work at all (or perhaps it could is running with
wine, is that possible?), but I admit I didn't try this, so I'm open
to be very surprised :)

I think the sanest approach is to not support this scenario, though.

Cheers,
Mario


From alexandr.scherbatiy at oracle.com  Fri Apr  1 13:02:35 2016
From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy)
Date: Fri, 1 Apr 2016 17:02:35 +0400
Subject: <Swing Dev> [9] Review request for 8136366 Add a public API to
 create a L&F without installation
In-Reply-To: <CAJwKKmYYs7Od94jPqNcmNEkFz2arSSX0-UPN+fK4T0WiW703Qw@mail.gmail.com>
References: <56FCC8B4.1040406@oracle.com> <56FDBBBF.2090308@oracle.com>
	<56FDC191.7030301@oracle.com> <56FE6035.7050806@oracle.com>
	<CAJwKKmYYs7Od94jPqNcmNEkFz2arSSX0-UPN+fK4T0WiW703Qw@mail.gmail.com>
Message-ID: <56FE716B.6080906@oracle.com>

On 01/04/16 16:12, Mario Torre wrote:
> On Fri, Apr 1, 2016 at 1:49 PM, Alexander Scherbatiy
> <alexandr.scherbatiy at oracle.com> wrote:
>> May be someone wants to get
>> fonts or colors from Windows L&F on Linux for its own custom L&F? It would
>> be useful to allow it.
> I don't think this would make any sense, the colours would still
> depend on a specific version of the OS, so is not clear what
> UIDefaults are returned by the Windows LAF on Linux or OSX, and those
> may also be different in different versions of Windows itself.
>
> I believe the Windows LAF is not "simulated" either, but the rendering
> is redirected to native widgets pretty much like the GTK/OSX Look and
> Feels work, so I doubt that running an application with the Windows
> LAF under Linux would work at all (or perhaps it could is running with
> wine, is that possible?), but I admit I didn't try this, so I'm open
> to be very surprised :)
>
> I think the sanest approach is to not support this scenario, though.

    I see the point that creating non installed system L&F may not have 
many sense.

    One more use case that should be considered is using the 
createLookAndFeel(className) method with custom L&Fs.

    For example someone can have a list with L&F class names which 
includes both system and custom L&F.
    Using a class name he wants to check if the given L&F is supported. 
Does he need to install the custom L&F first?
    If no, he will need to handle L&Fs differently using 
UIManager.createLookAndFeel(className) for system L&Fs and reflection 
for custom.

   Thanks,
   Alexandr.

>
> Cheers,
> Mario



From Sergey.Bylokhov at oracle.com  Fri Apr  1 14:14:35 2016
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Fri, 1 Apr 2016 17:14:35 +0300
Subject: <Swing Dev> [9] Review request for 8136366 Add a public API to
 create a L&F without installation
In-Reply-To: <56FE716B.6080906@oracle.com>
References: <56FCC8B4.1040406@oracle.com> <56FDBBBF.2090308@oracle.com>
	<56FDC191.7030301@oracle.com> <56FE6035.7050806@oracle.com>
	<CAJwKKmYYs7Od94jPqNcmNEkFz2arSSX0-UPN+fK4T0WiW703Qw@mail.gmail.com>
	<56FE716B.6080906@oracle.com>
Message-ID: <56FE824B.1070105@oracle.com>

On 01.04.16 16:02, Alexander Scherbatiy wrote:
>     I see the point that creating non installed system L&F may not have
> many sense.

I guess we should thinking about supported/unsupported instead of 
installed/non-installed.

>
>     One more use case that should be considered is using the
> createLookAndFeel(className) method with custom L&Fs.
>
>     For example someone can have a list with L&F class names which
> includes both system and custom L&F.
>     Using a class name he wants to check if the given L&F is supported.
> Does he need to install the custom L&F first?
>     If no, he will need to handle L&Fs differently using
> UIManager.createLookAndFeel(className) for system L&Fs and reflection
> for custom.

Is the new method a "shortcut" for:
  - UIManager.setLookAndFeel("com.foo")
  - laf = UIManager.getLookAndFeel();
  - laf is used...
Then probably the new method should work symmetrically to 
setLookAndFeel() and throw UnsupportedLookAndFeelException()? And if the 
Laf will be created will means that its state is valid(like uidefaults etc)

Small notes:
- Should we specify the null behavior?
- It is unrelated to current fix, but I wonder why we call newInstance 
for all incoming classes(we initialize the class and create the 
instance), and then we cast this new object to LookAndFeel.

-- 
Best regards, Sergey.


From alexandr.scherbatiy at oracle.com  Fri Apr  1 15:19:09 2016
From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy)
Date: Fri, 1 Apr 2016 19:19:09 +0400
Subject: <Swing Dev> [9] Review request for 8136366 Add a public API to
 create a L&F without installation
In-Reply-To: <56FE824B.1070105@oracle.com>
References: <56FCC8B4.1040406@oracle.com> <56FDBBBF.2090308@oracle.com>
	<56FDC191.7030301@oracle.com> <56FE6035.7050806@oracle.com>
	<CAJwKKmYYs7Od94jPqNcmNEkFz2arSSX0-UPN+fK4T0WiW703Qw@mail.gmail.com>
	<56FE716B.6080906@oracle.com> <56FE824B.1070105@oracle.com>
Message-ID: <56FE916D.3010409@oracle.com>


   Hello,

  Could you review the updated fix:
    http://cr.openjdk.java.net/~alexsch/8136366/webrev.01

   The UnsupportedLookAndFeelException is thrown from the 
UIManager.createLookAndFeel(className) method for unsupported L&Fs.

   Thanks,
   Alexandr.

On 01/04/16 18:14, Sergey Bylokhov wrote:
> On 01.04.16 16:02, Alexander Scherbatiy wrote:
>>     I see the point that creating non installed system L&F may not have
>> many sense.
>
> I guess we should thinking about supported/unsupported instead of 
> installed/non-installed.
>
>>
>>     One more use case that should be considered is using the
>> createLookAndFeel(className) method with custom L&Fs.
>>
>>     For example someone can have a list with L&F class names which
>> includes both system and custom L&F.
>>     Using a class name he wants to check if the given L&F is supported.
>> Does he need to install the custom L&F first?
>>     If no, he will need to handle L&Fs differently using
>> UIManager.createLookAndFeel(className) for system L&Fs and reflection
>> for custom.
>
> Is the new method a "shortcut" for:
>  - UIManager.setLookAndFeel("com.foo")
>  - laf = UIManager.getLookAndFeel();
>  - laf is used...
> Then probably the new method should work symmetrically to 
> setLookAndFeel() and throw UnsupportedLookAndFeelException()? And if 
> the Laf will be created will means that its state is valid(like 
> uidefaults etc)
>
> Small notes:
> - Should we specify the null behavior?
> - It is unrelated to current fix, but I wonder why we call newInstance 
> for all incoming classes(we initialize the class and create the 
> instance), and then we cast this new object to LookAndFeel.
>



From peter.brunet at oracle.com  Fri Apr  1 18:54:48 2016
From: peter.brunet at oracle.com (Pete Brunet)
Date: Fri, 1 Apr 2016 13:54:48 -0500
Subject: <Swing Dev> RfR JDK-8153149,
	Uninitialised memory in WinAccessBridge.cpp:1128
Message-ID: <56FEC3F8.20601@oracle.com>

Please review this simple fix:
https://bugs.openjdk.java.net/browse/JDK-8153149
http://cr.openjdk.java.net/~ptbrunet/JDK-8153149/webrev.00/



From peter.brunet at oracle.com  Fri Apr  1 18:56:32 2016
From: peter.brunet at oracle.com (Pete Brunet)
Date: Fri, 1 Apr 2016 13:56:32 -0500
Subject: <Swing Dev> RfR: JDK-8153153,
 Format string argument mismatch in jaccesswalker.cpp:545
Message-ID: <56FEC460.50100@oracle.com>

Please review this simple fix:
https://bugs.openjdk.java.net/browse/JDK-8153153
http://cr.openjdk.java.net/~ptbrunet/JDK-8153153/webrev.00/


From philip.race at oracle.com  Fri Apr  1 22:19:00 2016
From: philip.race at oracle.com (Phil Race)
Date: Fri, 01 Apr 2016 15:19:00 -0700
Subject: <Swing Dev> RFR: 8147544: Remove sun.misc.ManagedLocalsThread from
	java.desktop
Message-ID: <56FEF3D4.9060704@oracle.com>

Bug: https://bugs.openjdk.java.net/browse/JDK-8147544
Fix: http://cr.openjdk.java.net/~prr/8147544/

ManagedLocalThreads is now superseded by a standard
constructor on java.lang.Thread :-
http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/f90cd2c011bc

The various places in JDK that use the internal API need to migrate to this.

This fix addresses all (I hope) such usages in java.desktop.

I had to invent names for threads in numerous places since
the required constructor insists on one.

Most uses install a Runnable but in about 4 cases we need to extend Thread.
In those cases I added a comment, and in some cases a private no-args
constructor() to try to guard against anyone coming along later and 
accidentally
adding & calling a wrong super-class constructor.

JPRT has been used to verify the build on all platforms and I am
in the process of running some sanity checks on the major
platforms to make sure nothing unexpected happens but
in general real testing of all of these changes is going to only happen
with a nearly full test run, so the earlier the better to get the 
changes in.

-phil.




From philip.race at oracle.com  Fri Apr  1 22:54:33 2016
From: philip.race at oracle.com (Phil Race)
Date: Fri, 01 Apr 2016 15:54:33 -0700
Subject: <Swing Dev> RfR JDK-8153149,
	Uninitialised memory in WinAccessBridge.cpp:1128
In-Reply-To: <56FEC3F8.20601@oracle.com>
References: <56FEC3F8.20601@oracle.com>
Message-ID: <56FEFC29.1040907@oracle.com>

You say its a simple fix but I need you to confirm if i have it right

What I see is that pkg is a pointer to part of "buffer" but the
contents of that buffer are not initialised so the field rVMID is garbage.
So you should not use it. So far so good.

But then a reader must ask himself
1) where does pkgVMID get initialised and used
2) where does pkg->rVMID get initalised and used


I suppose that the answer to (1) is

if (getAccessibleContextFromHWND(window, (long *)&(pkgVMID). ...)

and it then gets used in the call

findAccessBridgeWindow((long)pkgVMID); and for (2) that the call to sendMemoryPackage(..) fills in everything in buffer,

including implicity "pkg", and this gets used here

*vmID = pkg->rVMID;


Is this right ?

The odd thing is that pkgVMID and pkg->rVMID are not obviously the
same thing at all so the deleted assignment was really odd ..

-phil.

On 04/01/2016 11:54 AM, Pete Brunet wrote:
> Please review this simple fix:
> https://bugs.openjdk.java.net/browse/JDK-8153149
> http://cr.openjdk.java.net/~ptbrunet/JDK-8153149/webrev.00/
>



From philip.race at oracle.com  Sat Apr  2 15:58:23 2016
From: philip.race at oracle.com (Philip Race)
Date: Sat, 02 Apr 2016 08:58:23 -0700
Subject: <Swing Dev> RfR: JDK-8153153,
 Format string argument mismatch in jaccesswalker.cpp:545
In-Reply-To: <56FEC460.50100@oracle.com>
References: <56FEC460.50100@oracle.com>
Message-ID: <56FFEC1F.9050800@oracle.com>

I notice the bug has no evaluation. Unevaluated bugs aren't ready for 
review.
Also did you run this through jprt ? If this causes a warning on some other
platform than you tried you will break the build.

-phil.

On 4/1/16, 11:56 AM, Pete Brunet wrote:
> Please review this simple fix:
> https://bugs.openjdk.java.net/browse/JDK-8153153
> http://cr.openjdk.java.net/~ptbrunet/JDK-8153153/webrev.00/


From Sergey.Bylokhov at oracle.com  Sun Apr  3 16:49:00 2016
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Sun, 3 Apr 2016 19:49:00 +0300
Subject: <Swing Dev> [OpenJDK 2D-Dev] RFR: 8147544: Remove
 sun.misc.ManagedLocalsThread from java.desktop
In-Reply-To: <67BE8102-8D6D-4E12-A947-5F60DCF1BABB@oracle.com>
References: <56FEF3D4.9060704@oracle.com>
	<67BE8102-8D6D-4E12-A947-5F60DCF1BABB@oracle.com>
Message-ID: <5701497C.40301@oracle.com>

The fix looks fine, but we will need to use correct Thread constructor, 
it will not easy tracked unlike the usage of separate class.

On 03.04.16 18:24, Chris Hegarty wrote:
>
> On 1 Apr 2016, at 23:19, Phil Race <philip.race at oracle.com> wrote:
>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8147544
>> Fix: http://cr.openjdk.java.net/~prr/8147544/
>
> Your changes look ok to me.  Thanks for doing this Phil.
>
> -Chris.
>
>> ManagedLocalThreads is now superseded by a standard
>> constructor on java.lang.Thread :-
>> http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/f90cd2c011bc
>>
>> The various places in JDK that use the internal API need to migrate to this.
>>
>> This fix addresses all (I hope) such usages in java.desktop.
>>
>> I had to invent names for threads in numerous places since
>> the required constructor insists on one.
>>
>> Most uses install a Runnable but in about 4 cases we need to extend Thread.
>> In those cases I added a comment, and in some cases a private no-args
>> constructor() to try to guard against anyone coming along later and accidentally
>> adding & calling a wrong super-class constructor.
>>
>> JPRT has been used to verify the build on all platforms and I am
>> in the process of running some sanity checks on the major
>> platforms to make sure nothing unexpected happens but
>> in general real testing of all of these changes is going to only happen
>> with a nearly full test run, so the earlier the better to get the changes in.
>>
>> -phil.
>>
>>
>


-- 
Best regards, Sergey.


From philip.race at oracle.com  Sun Apr  3 17:50:07 2016
From: philip.race at oracle.com (Philip Race)
Date: Sun, 03 Apr 2016 10:50:07 -0700
Subject: <Swing Dev> [OpenJDK 2D-Dev] RFR: 8147544: Remove
 sun.misc.ManagedLocalsThread from java.desktop
In-Reply-To: <5701497C.40301@oracle.com>
References: <56FEF3D4.9060704@oracle.com>
	<67BE8102-8D6D-4E12-A947-5F60DCF1BABB@oracle.com>
	<5701497C.40301@oracle.com>
Message-ID: <570157CF.2060008@oracle.com>

Yes, it will be much harder to audit that the correct constructor
has been used, so it needs to be a reviewer checklist item.

-phil.


On 4/3/16, 9:49 AM, Sergey Bylokhov wrote:
> The fix looks fine, but we will need to use correct Thread 
> constructor, it will not easy tracked unlike the usage of separate class.
>
> On 03.04.16 18:24, Chris Hegarty wrote:
>>
>> On 1 Apr 2016, at 23:19, Phil Race <philip.race at oracle.com> wrote:
>>
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8147544
>>> Fix: http://cr.openjdk.java.net/~prr/8147544/
>>
>> Your changes look ok to me.  Thanks for doing this Phil.
>>
>> -Chris.
>>
>>> ManagedLocalThreads is now superseded by a standard
>>> constructor on java.lang.Thread :-
>>> http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/f90cd2c011bc
>>>
>>> The various places in JDK that use the internal API need to migrate 
>>> to this.
>>>
>>> This fix addresses all (I hope) such usages in java.desktop.
>>>
>>> I had to invent names for threads in numerous places since
>>> the required constructor insists on one.
>>>
>>> Most uses install a Runnable but in about 4 cases we need to extend 
>>> Thread.
>>> In those cases I added a comment, and in some cases a private no-args
>>> constructor() to try to guard against anyone coming along later and 
>>> accidentally
>>> adding & calling a wrong super-class constructor.
>>>
>>> JPRT has been used to verify the build on all platforms and I am
>>> in the process of running some sanity checks on the major
>>> platforms to make sure nothing unexpected happens but
>>> in general real testing of all of these changes is going to only happen
>>> with a nearly full test run, so the earlier the better to get the 
>>> changes in.
>>>
>>> -phil.
>>>
>>>
>>
>
>


From alexandr.scherbatiy at oracle.com  Mon Apr  4 12:38:14 2016
From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy)
Date: Mon, 04 Apr 2016 15:38:14 +0300
Subject: <Swing Dev> Review request for 6949414
 JMenu.buildMenuElementArray() endless loop
Message-ID: <57026036.1090205@oracle.com>


Hello,

Could you review the fix:
   bug: https://bugs.openjdk.java.net/browse/JDK-6949414
   webrev: http://cr.openjdk.java.net/~alexsch/6949414/webrev.00

   The endless loop in JMenu.buildMenuElementArray() method that 
JPopupMenu can be created without JMenuBar is fixed.
   NPE that JPopupMenu does not necessary have ancestor window is fixed.


Thanks,
Alexandr.



From peter.brunet at oracle.com  Mon Apr  4 13:33:54 2016
From: peter.brunet at oracle.com (Pete Brunet)
Date: Mon, 4 Apr 2016 08:33:54 -0500
Subject: <Swing Dev> RfR: JDK-8153153,
 Format string argument mismatch in jaccesswalker.cpp:545
In-Reply-To: <56FFEC1F.9050800@oracle.com>
References: <56FEC460.50100@oracle.com> <56FFEC1F.9050800@oracle.com>
Message-ID: <57026D42.5030504@oracle.com>

Hi Phil, As far as I know this doesn't need an evaluation.  It's just a
printf arg mismatch so a 64 bit pointer only gets printed as a 32 bit
value, i.e. %X was used where %p should have been used.  It's something
I fixed in a lot of other places but this is one I missed.  All 7 JPRT
targets build OK.

Pete

On 4/2/16 10:58 AM, Philip Race wrote:
> I notice the bug has no evaluation. Unevaluated bugs aren't ready for
> review.
> Also did you run this through jprt ? If this causes a warning on some
> other
> platform than you tried you will break the build.
>
> -phil.
>
> On 4/1/16, 11:56 AM, Pete Brunet wrote:
>> Please review this simple fix:
>> https://bugs.openjdk.java.net/browse/JDK-8153153
>> http://cr.openjdk.java.net/~ptbrunet/JDK-8153153/webrev.00/



From peter.brunet at oracle.com  Mon Apr  4 14:09:03 2016
From: peter.brunet at oracle.com (Pete Brunet)
Date: Mon, 4 Apr 2016 09:09:03 -0500
Subject: <Swing Dev> RfR JDK-8153149,
 Uninitialised memory in WinAccessBridge.cpp:1128
In-Reply-To: <56FEFC29.1040907@oracle.com>
References: <56FEC3F8.20601@oracle.com> <56FEFC29.1040907@oracle.com>
Message-ID: <5702757F.7080501@oracle.com>



On 4/1/16 5:54 PM, Phil Race wrote:
> You say its a simple fix but I need you to confirm if i have it right
>
> What I see is that pkg is a pointer to part of "buffer" but the
> contents of that buffer are not initialised so the field rVMID is
> garbage.
> So you should not use it. So far so good.
>
> But then a reader must ask himself
> 1) where does pkgVMID get initialised and used
> 2) where does pkg->rVMID get initalised and used
>
>
> I suppose that the answer to (1) is
>
> if (getAccessibleContextFromHWND(window, (long *)&(pkgVMID). ...)
>
> and it then gets used in the call
>
> findAccessBridgeWindow((long)pkgVMID); and for (2) that the call to
> sendMemoryPackage(..) fills in everything in buffer,
>
> including implicity "pkg", and this gets used here
>
> *vmID = pkg->rVMID;
>
>
> Is this right ?
Yes, That is all correct.
>
> The odd thing is that pkgVMID and pkg->rVMID are not obviously the
> same thing at all so the deleted assignment was really odd ..
True, I don't have a clue as to why that was there and the original
developers are long gone.  Maybe the code was much different at one
time.  The extra unneeded indentation might indicate that.  I looked
through the code to see if pkgVMID might have been an in/out instead of
just an out on the call to findAccessBrdige but it's just an out.

Pete
>
> -phil.
>
> On 04/01/2016 11:54 AM, Pete Brunet wrote:
>> Please review this simple fix:
>> https://bugs.openjdk.java.net/browse/JDK-8153149
>> http://cr.openjdk.java.net/~ptbrunet/JDK-8153149/webrev.00/
>>
>



From Sergey.Bylokhov at oracle.com  Mon Apr  4 14:15:43 2016
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Mon, 4 Apr 2016 17:15:43 +0300
Subject: <Swing Dev> Review request for 6949414
 JMenu.buildMenuElementArray() endless loop
In-Reply-To: <57026036.1090205@oracle.com>
References: <57026036.1090205@oracle.com>
Message-ID: <5702770F.5030800@oracle.com>

The fix looks fine.
(Probably the loop can be changed from the "while(true)" to iteration 
over MenuElement, but it is up2you)

On 04.04.16 15:38, Alexander Scherbatiy wrote:
>
> Hello,
>
> Could you review the fix:
>    bug: https://bugs.openjdk.java.net/browse/JDK-6949414
>    webrev: http://cr.openjdk.java.net/~alexsch/6949414/webrev.00
>
>    The endless loop in JMenu.buildMenuElementArray() method that
> JPopupMenu can be created without JMenuBar is fixed.
>    NPE that JPopupMenu does not necessary have ancestor window is fixed.
>
>
> Thanks,
> Alexandr.
>


-- 
Best regards, Sergey.


From semyon.sadetsky at oracle.com  Mon Apr  4 14:53:18 2016
From: semyon.sadetsky at oracle.com (Semyon Sadetsky)
Date: Mon, 4 Apr 2016 17:53:18 +0300
Subject: <Swing Dev> Review request for 6949414
 JMenu.buildMenuElementArray() endless loop
In-Reply-To: <57026036.1090205@oracle.com>
References: <57026036.1090205@oracle.com>
Message-ID: <57027FDE.3080903@oracle.com>

Looks good.

--Semyon

On 4/4/2016 3:38 PM, Alexander Scherbatiy wrote:
>
> Hello,
>
> Could you review the fix:
>   bug: https://bugs.openjdk.java.net/browse/JDK-6949414
>   webrev: http://cr.openjdk.java.net/~alexsch/6949414/webrev.00
>
>   The endless loop in JMenu.buildMenuElementArray() method that 
> JPopupMenu can be created without JMenuBar is fixed.
>   NPE that JPopupMenu does not necessary have ancestor window is fixed.
>
>
> Thanks,
> Alexandr.
>



From philip.race at oracle.com  Mon Apr  4 17:10:24 2016
From: philip.race at oracle.com (Phil Race)
Date: Mon, 04 Apr 2016 10:10:24 -0700
Subject: <Swing Dev> RfR: JDK-8153153,
 Format string argument mismatch in jaccesswalker.cpp:545
In-Reply-To: <57026D42.5030504@oracle.com>
References: <56FEC460.50100@oracle.com> <56FFEC1F.9050800@oracle.com>
	<57026D42.5030504@oracle.com>
Message-ID: <5702A000.8010005@oracle.com>

All bugs should have an evaluation. Period.

-phil.

On 04/04/2016 06:33 AM, Pete Brunet wrote:
> Hi Phil, As far as I know this doesn't need an evaluation.  It's just a
> printf arg mismatch so a 64 bit pointer only gets printed as a 32 bit
> value, i.e. %X was used where %p should have been used.  It's something
> I fixed in a lot of other places but this is one I missed.  All 7 JPRT
> targets build OK.
>
> Pete
>
> On 4/2/16 10:58 AM, Philip Race wrote:
>> I notice the bug has no evaluation. Unevaluated bugs aren't ready for
>> review.
>> Also did you run this through jprt ? If this causes a warning on some
>> other
>> platform than you tried you will break the build.
>>
>> -phil.
>>
>> On 4/1/16, 11:56 AM, Pete Brunet wrote:
>>> Please review this simple fix:
>>> https://bugs.openjdk.java.net/browse/JDK-8153153
>>> http://cr.openjdk.java.net/~ptbrunet/JDK-8153153/webrev.00/



From philip.race at oracle.com  Mon Apr  4 20:17:32 2016
From: philip.race at oracle.com (Phil Race)
Date: Mon, 04 Apr 2016 13:17:32 -0700
Subject: <Swing Dev> [9] Review request for 8136366 Add a public API to
 create a L&F without installation
In-Reply-To: <56FE916D.3010409@oracle.com>
References: <56FCC8B4.1040406@oracle.com> <56FDBBBF.2090308@oracle.com>
	<56FDC191.7030301@oracle.com> <56FE6035.7050806@oracle.com>
	<CAJwKKmYYs7Od94jPqNcmNEkFz2arSSX0-UPN+fK4T0WiW703Qw@mail.gmail.com>
	<56FE716B.6080906@oracle.com> <56FE824B.1070105@oracle.com>
	<56FE916D.3010409@oracle.com>
Message-ID: <5702CBDC.80508@oracle.com>

+1

-phil.

On 04/01/2016 08:19 AM, Alexander Scherbatiy wrote:
>
>   Hello,
>
>  Could you review the updated fix:
>    http://cr.openjdk.java.net/~alexsch/8136366/webrev.01
>
>   The UnsupportedLookAndFeelException is thrown from the 
> UIManager.createLookAndFeel(className) method for unsupported L&Fs.
>
>   Thanks,
>   Alexandr.
>
> On 01/04/16 18:14, Sergey Bylokhov wrote:
>> On 01.04.16 16:02, Alexander Scherbatiy wrote:
>>>     I see the point that creating non installed system L&F may not have
>>> many sense.
>>
>> I guess we should thinking about supported/unsupported instead of 
>> installed/non-installed.
>>
>>>
>>>     One more use case that should be considered is using the
>>> createLookAndFeel(className) method with custom L&Fs.
>>>
>>>     For example someone can have a list with L&F class names which
>>> includes both system and custom L&F.
>>>     Using a class name he wants to check if the given L&F is supported.
>>> Does he need to install the custom L&F first?
>>>     If no, he will need to handle L&Fs differently using
>>> UIManager.createLookAndFeel(className) for system L&Fs and reflection
>>> for custom.
>>
>> Is the new method a "shortcut" for:
>>  - UIManager.setLookAndFeel("com.foo")
>>  - laf = UIManager.getLookAndFeel();
>>  - laf is used...
>> Then probably the new method should work symmetrically to 
>> setLookAndFeel() and throw UnsupportedLookAndFeelException()? And if 
>> the Laf will be created will means that its state is valid(like 
>> uidefaults etc)
>>
>> Small notes:
>> - Should we specify the null behavior?
>> - It is unrelated to current fix, but I wonder why we call 
>> newInstance for all incoming classes(we initialize the class and 
>> create the instance), and then we cast this new object to LookAndFeel.
>>
>



From Sergey.Bylokhov at oracle.com  Mon Apr  4 20:24:08 2016
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Mon, 4 Apr 2016 23:24:08 +0300
Subject: <Swing Dev> [9] Review Request: 8141544 The interface
 sun.swing.UIClientPropertyKey can be made public
Message-ID: <5702CD68.1090005@oracle.com>

Hello,
Please review the fix for jdk9.

In the fix the UIClientPropertyKey interface is moved to javax.swing 
package. This is a tagging interface, which provides functionality 
similar to UIResource, but for the client properties(this can be useful 
for custom l&f). The spec of UIClientPropertyKey is self-descriptive.

ccc will be created after the technical review.

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


-- 
Best regards, Sergey.


From philip.race at oracle.com  Mon Apr  4 21:51:15 2016
From: philip.race at oracle.com (Phil Race)
Date: Mon, 04 Apr 2016 14:51:15 -0700
Subject: <Swing Dev> [9] Review request for 8132119 Provide public API
 for text related methods in SwingUtilities2
In-Reply-To: <56FD83E8.3060202@oracle.com>
References: <55E715A1.3090008@oracle.com> <55E72D3A.60807@oracle.com>
	<55ED586F.5070509@oracle.com> <55F6DC3C.60809@oracle.com>
	<5655D3AB.9050503@oracle.com> <5668051E.7090401@oracle.com>
	<5668E226.5000604@oracle.com> <5669646E.4070305@oracle.com>
	<566986FD.9020207@oracle.com> <5694F0C3.8020203@oracle.com>
	<5695572F.6070709@oracle.com> <56966730.7000701@oracle.com>
	<5698C71A.80703@oracle.com> <56991ED9.5030302@oracle.com>
	<569963B6.2050604@oracle.com> <56A5C40B.7010107@oracle.com>
	<CAM6ZMz8iEFQQtSb_bAVU5eUH=J=HapvKq3+Ana4pPxueJD1bNg@mail.gmail.com>
	<56AB8A94.2070404@oracle.com> <56EC2389.3020507@oracle.com>
	<56F38B0B.3060700@oracle.com> <56F3F13A.9000808@oracle.com>
	<56F3F83C.3010706@oracle.com> <56FD791E.1050707@oracle.com>
	<56FD83E8.3060202@oracle.com>
Message-ID: <5702E1D3.5070008@oracle.com>

Hi,

Is that a response to my suggestion we not over-specify, or something else ?
Can you point to an example of how this changed in the latest webrev ?

-phil.

On 03/31/2016 01:09 PM, Sergey Bylokhov wrote:
> Just a small clarification. In general implementations of these 
> methods can make some "magic", but the purpose of the change is to 
> provide to the user this "magic", I mean the user's components will be 
> able to apply this "magic" to the custom components(or change behavior 
> of standard l&f). So in the latest webrev some of implementations 
> details of these methods were hidden.
> I am not sure we express this goal successfully or not.
>
> On 31.03.16 22:23, Phil Race wrote:
>> Maybe the test to pass in that case is whether the default 
>> implementation
>> is going to be satisfactory for 90% of uses. If they are frequently
>> over-ridden
>> it would not be an appropriate use.
>>
>> Based on that criterion I think it is OK to use here.
>>
>> Another thought:
>> When you add default implementations you should also be on the hook
>> for explaining what that does. It is a deeper contract than you would
>> otherwise have as an interface and maybe needs to be an @implNote
>> or you need to call out the default implementation.
>> ie there is what someone must code to satisfy the contract of the
>> interface and what is a behaviour in the default method ?
>>
>>
>> Also here is a link to some comments by Brian Goetz on default methods :
>>
>> http://stackoverflow.com/questions/28681737/java-8-default-methods-as-traits-safe/28684917#28684917 
>>
>>
>>
>>    75      * No character is underlined if the index is negative or 
>> greater
>>    76      * than the string length {@code (index < 0 || index >=
>> string.length())}
>>    77      * or if the char value specified at the given index
>>    78      * is in the low-surrogate range.
>>
>>
>> I suppose if you point at the last char and it is a hi-surrogate nothing
>> is underlined in that case either.
>>
>> But I find the whole writing of this a bit inadequate as if you are
>> going to
>> this kind of detail you perhaps also need to say what happens in a 
>> complex
>> script where what happens is two unicode characters end up as a 
>> ligature,
>> and/or perhaps you aren't even pointing to a base character.
>> Maybe it is in fact over-specified. I see that the implementation draws
>> the underline itself rather than delegate to TextLayout. This might
>> make sense for performance reasons where it is simple text but some day
>> this maybe should be re-examined and so I would not over-specify it.
>>
>> How about :
>> "The underline will be positioned at the base glyph which
>> represents the valid char indicated by the index.
>> If the char index is not valid or is not the index of a
>> valid unicode code point then no underline is drawn"
>>
>> -phil.
>>
>>
>>
>> On 03/24/2016 07:22 AM, Sergey Bylokhov wrote:
>>> On 24.03.16 16:52, Alexander Scherbatiy wrote:
>>>> On 24/03/16 10:36, Semyon Sadetsky wrote:
>>>>> Hi Alexander,
>>>>>
>>>>> Could you answer one question:
>>>>> Why did you choose default interface methods to implement
>>>>> TextUIDrawing and not implement them in DefaultTextUIDrawing having
>>>>> declarations only in the interface?
>>>>> AFAIK the common point of view is default methods should be used
>>>>> rarely because they may lead to unreadable code.
>>>>>
>>>>    The only problem which I know about default methods is multiple
>>>> inheritance which has its own solution.
>>>
>>> What kind of problems? The benefit is obvious: it will not be
>>> necessary to implement all methods if only one of them should be 
>>> tweaked.
>>>
>>>>
>>>>    Could you give links to discussion or provide use cases where 
>>>> default
>>>> methods leads to the unreadable code and show how does it relate to 
>>>> the
>>>> TextUIDrawing  implementation?
>>>>
>>>>    Thanks,
>>>>    Alexandr.
>>>>> --Semyon
>>>>>
>>>>> On 3/18/2016 6:49 PM, Alexander Scherbatiy wrote:
>>>>>>
>>>>>> Could you review the updated fix:
>>>>>>   http://cr.openjdk.java.net/~alexsch/8132119/webrev.08/
>>>>>>
>>>>>>   - Public TextUIDrawing interface is added to the javax.swing.plaf
>>>>>> package
>>>>>>   - TextUIDrawing methods description does not mention component
>>>>>> properties to be more general
>>>>>>   - TextUIDrawing methods are made default
>>>>>>   - L&F sets an instance of the TextUIDrawing to look and feel
>>>>>> defaults using "uiDrawing.text" property
>>>>>>   - ComponentUI class is not changed
>>>>>>   - Each ComponentUI reads TextUIDrawing from UI defaults
>>>>>>   - There is an interesting issue described in
>>>>>> http://mail.openjdk.java.net/pipermail/swing-dev/2016-March/005509.html 
>>>>>>
>>>>>>
>>>>>>     which is related to the fact that MetalLabelUI returns a static
>>>>>> field from createUI() method.
>>>>>>     TitleBorder creates a JLabel but does not put it to any 
>>>>>> component
>>>>>> hierarchy. In this case SwingUtilities.updateComponentTreeUI() 
>>>>>> method
>>>>>> calls MetalLabelUI.uninstallDefaults() on the static metalLabelUI
>>>>>> field and sets a new LabelUI for ordinary labels. The TitleBorder
>>>>>> label UI is not changed in this case and it still uses the
>>>>>> metalLabelUI field which is not initialized.
>>>>>>     It seems that other applications can also use components just 
>>>>>> for
>>>>>> drawing and have the same issue.
>>>>>>     For this case the textUIDrawing field is not cleared in the
>>>>>> uninstallDefaults but just set to a static default value which 
>>>>>> should
>>>>>> not lead to memory leaks.
>>>>>>
>>>>>>   Thanks,
>>>>>>   Alexandr.
>>>>>>
>>>>>> On 29/01/16 19:51, Alexander Scherbatiy wrote:
>>>>>>> On 25/01/16 13:44, Andrej Golovnin wrote:
>>>>>>>> Hi Alexandr,
>>>>>>>>
>>>>>>>>> Could you review the updated fix:
>>>>>>>>> http://cr.openjdk.java.net/~alexsch/8132119/webrev.07/
>>>>>>>> ....
>>>>>>>>> - public TextUIDrawing interface is added to the javax.swing.plaf
>>>>>>>>> package
>>>>>>>>> - public "TextUIDrawing getTextUIDrawing()" method is added to 
>>>>>>>>> the
>>>>>>>>> ComponentUI class
>>>>>>>>> - L&F sets an instance of the TextUIDrawing to look and feel
>>>>>>>>> defaults using
>>>>>>>>> "uiDrawing.text" property
>>>>>>>>> - Look and Feel delegates use the instance of the TextUIDrawing
>>>>>>>>> for text
>>>>>>>>> drawing and measuring
>>>>>>>> Some thoughts on the current design/implementation:
>>>>>>>>
>>>>>>>> By adding a field to the ComponentUI class the current
>>>>>>>> implementation increases
>>>>>>>> memory consumption for all Swing applications. And you get the
>>>>>>>> feeling that
>>>>>>>> there are different implementations of TextUIDrawing per
>>>>>>>> ComponentUI instances.
>>>>>>>> Personally I can't imagine to have different implementations of
>>>>>>>> TextUIDrawing for
>>>>>>>> a given LookAndFeel. If I would design/implement it, then I would
>>>>>>>> implement it as
>>>>>>>> a property of the LookAndFeel class (similar to LayoutStyle) 
>>>>>>>> and not
>>>>>>>> the ComponentUI.
>>>>>>>> Developers can use then the following code to obtain the 
>>>>>>>> instance of
>>>>>>>> TextUIDrawing:
>>>>>>>>
>>>>>>>> UIManager.getLookAndFeel().getUIDrawing() // or
>>>>>>>> UIManager.getLookAndFeelUIDrawing() // use this static method as a
>>>>>>>> short cut for the line above.
>>>>>>>   LayoutStyle keeps its instance per App context. The same is for
>>>>>>> the LookAndFeel
>>>>>>>   when it is got through UIManager.getLookAndFeel() call.
>>>>>>>   It means that accessing an instance of a TextUIDrawing will leads
>>>>>>> to a time consumption.
>>>>>>>
>>>>>>>   There are 3 main ways of the SwingUtilities2.drawString(...) 
>>>>>>> usage:
>>>>>>>   1. ComponentUI classes
>>>>>>>   2. Components created in UI (like BasicInternalFrameTitlePane)
>>>>>>>   3. Public utilities methods (like 
>>>>>>> WindowsGraphicsUtils.paintText())
>>>>>>>
>>>>>>>   For the cases 1 and 2 it is possible to load and store the
>>>>>>> UIDrawing instance during installUI()/updateUI() calls to 
>>>>>>> decrease a
>>>>>>> time access to it.
>>>>>>>
>>>>>>>   For the case 3 it is necessary to get LookAndFeel instance each
>>>>>>> time (which is taken from an App context)
>>>>>>>   or use the passed JComponent object. It requires to have a public
>>>>>>> method and the associated variable for each instance of
>>>>>>> JComponent/ComponentUI/... class.
>>>>>>>> You can use this methods then in JDK too.
>>>>>>>>
>>>>>>>> And maybe rename the TextUIDrawing class to just UIDrawing and add
>>>>>>>> more useful methods,
>>>>>>>> e.g. a method to create a composite font, a method to convert DLUs
>>>>>>>> to pixels.
>>>>>>>   UIDrawing name may look like it should be used for any UI 
>>>>>>> drawing,
>>>>>>> not only for text ones. I am afraid that it can be misleading.
>>>>>>>
>>>>>>>   Thanks,
>>>>>>>   Alexandr.
>>>>>>>
>>>>>>>>
>>>>>>>> Best regards,
>>>>>>>> Andrej Golovnin
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>>
>>
>
>



From peter.brunet at oracle.com  Mon Apr  4 22:00:47 2016
From: peter.brunet at oracle.com (Pete Brunet)
Date: Mon, 4 Apr 2016 17:00:47 -0500
Subject: <Swing Dev> RfR: JDK-8153153,
 Format string argument mismatch in jaccesswalker.cpp:545
In-Reply-To: <5702A000.8010005@oracle.com>
References: <56FEC460.50100@oracle.com> <56FFEC1F.9050800@oracle.com>
	<57026D42.5030504@oracle.com> <5702A000.8010005@oracle.com>
Message-ID: <5702E40F.6010606@oracle.com>

Evaluation added.

Is the patch OK?

https://bugs.openjdk.java.net/browse/JDK-8153153
http://cr.openjdk.java.net/~ptbrunet/JDK-8153153/webrev.00/

Pete


On 4/4/16 12:10 PM, Phil Race wrote:
> All bugs should have an evaluation. Period.
>
> -phil.
>
> On 04/04/2016 06:33 AM, Pete Brunet wrote:
>> Hi Phil, As far as I know this doesn't need an evaluation.  It's just a
>> printf arg mismatch so a 64 bit pointer only gets printed as a 32 bit
>> value, i.e. %X was used where %p should have been used.  It's something
>> I fixed in a lot of other places but this is one I missed.  All 7 JPRT
>> targets build OK.
>>
>> Pete
>>
>> On 4/2/16 10:58 AM, Philip Race wrote:
>>> I notice the bug has no evaluation. Unevaluated bugs aren't ready for
>>> review.
>>> Also did you run this through jprt ? If this causes a warning on some
>>> other
>>> platform than you tried you will break the build.
>>>
>>> -phil.
>>>
>>> On 4/1/16, 11:56 AM, Pete Brunet wrote:
>>>> Please review this simple fix:
>>>> https://bugs.openjdk.java.net/browse/JDK-8153153
>>>> http://cr.openjdk.java.net/~ptbrunet/JDK-8153153/webrev.00/
>



From philip.race at oracle.com  Mon Apr  4 21:57:23 2016
From: philip.race at oracle.com (Phil Race)
Date: Mon, 04 Apr 2016 14:57:23 -0700
Subject: <Swing Dev> RfR: JDK-8153153,
 Format string argument mismatch in jaccesswalker.cpp:545
In-Reply-To: <5702E40F.6010606@oracle.com>
References: <56FEC460.50100@oracle.com> <56FFEC1F.9050800@oracle.com>
	<57026D42.5030504@oracle.com> <5702A000.8010005@oracle.com>
	<5702E40F.6010606@oracle.com>
Message-ID: <5702E343.9080803@oracle.com>

The bug is now evaluated and jPRT is happy so "+1"

-phil.

On 04/04/2016 03:00 PM, Pete Brunet wrote:
> Evaluation added.
>
> Is the patch OK?
>
> https://bugs.openjdk.java.net/browse/JDK-8153153
> http://cr.openjdk.java.net/~ptbrunet/JDK-8153153/webrev.00/
>
> Pete
>
>
> On 4/4/16 12:10 PM, Phil Race wrote:
>> All bugs should have an evaluation. Period.
>>
>> -phil.
>>
>> On 04/04/2016 06:33 AM, Pete Brunet wrote:
>>> Hi Phil, As far as I know this doesn't need an evaluation.  It's just a
>>> printf arg mismatch so a 64 bit pointer only gets printed as a 32 bit
>>> value, i.e. %X was used where %p should have been used.  It's something
>>> I fixed in a lot of other places but this is one I missed.  All 7 JPRT
>>> targets build OK.
>>>
>>> Pete
>>>
>>> On 4/2/16 10:58 AM, Philip Race wrote:
>>>> I notice the bug has no evaluation. Unevaluated bugs aren't ready for
>>>> review.
>>>> Also did you run this through jprt ? If this causes a warning on some
>>>> other
>>>> platform than you tried you will break the build.
>>>>
>>>> -phil.
>>>>
>>>> On 4/1/16, 11:56 AM, Pete Brunet wrote:
>>>>> Please review this simple fix:
>>>>> https://bugs.openjdk.java.net/browse/JDK-8153153
>>>>> http://cr.openjdk.java.net/~ptbrunet/JDK-8153153/webrev.00/



From peter.brunet at oracle.com  Mon Apr  4 22:02:56 2016
From: peter.brunet at oracle.com (Pete Brunet)
Date: Mon, 4 Apr 2016 17:02:56 -0500
Subject: <Swing Dev> RfR JDK-8153149,
 Uninitialised memory in WinAccessBridge.cpp:1128
In-Reply-To: <5702757F.7080501@oracle.com>
References: <56FEC3F8.20601@oracle.com> <56FEFC29.1040907@oracle.com>
	<5702757F.7080501@oracle.com>
Message-ID: <5702E490.60707@oracle.com>

To all, I added more information to the bug report.

Is the patch OK?

https://bugs.openjdk.java.net/browse/JDK-8153149
http://cr.openjdk.java.net/~ptbrunet/JDK-8153149/webrev.00/

Pete

On 4/4/16 9:09 AM, Pete Brunet wrote:
>
> On 4/1/16 5:54 PM, Phil Race wrote:
>> You say its a simple fix but I need you to confirm if i have it right
>>
>> What I see is that pkg is a pointer to part of "buffer" but the
>> contents of that buffer are not initialised so the field rVMID is
>> garbage.
>> So you should not use it. So far so good.
>>
>> But then a reader must ask himself
>> 1) where does pkgVMID get initialised and used
>> 2) where does pkg->rVMID get initalised and used
>>
>>
>> I suppose that the answer to (1) is
>>
>> if (getAccessibleContextFromHWND(window, (long *)&(pkgVMID). ...)
>>
>> and it then gets used in the call
>>
>> findAccessBridgeWindow((long)pkgVMID); and for (2) that the call to
>> sendMemoryPackage(..) fills in everything in buffer,
>>
>> including implicity "pkg", and this gets used here
>>
>> *vmID = pkg->rVMID;
>>
>>
>> Is this right ?
> Yes, That is all correct.
>> The odd thing is that pkgVMID and pkg->rVMID are not obviously the
>> same thing at all so the deleted assignment was really odd ..
> True, I don't have a clue as to why that was there and the original
> developers are long gone.  Maybe the code was much different at one
> time.  The extra unneeded indentation might indicate that.  I looked
> through the code to see if pkgVMID might have been an in/out instead of
> just an out on the call to findAccessBrdige but it's just an out.
>
> Pete
>> -phil.
>>
>> On 04/01/2016 11:54 AM, Pete Brunet wrote:
>>> Please review this simple fix:
>>> https://bugs.openjdk.java.net/browse/JDK-8153149
>>> http://cr.openjdk.java.net/~ptbrunet/JDK-8153149/webrev.00/
>>>



From philip.race at oracle.com  Mon Apr  4 21:58:53 2016
From: philip.race at oracle.com (Phil Race)
Date: Mon, 04 Apr 2016 14:58:53 -0700
Subject: <Swing Dev> RfR JDK-8153149,
	Uninitialised memory in WinAccessBridge.cpp:1128
In-Reply-To: <5702757F.7080501@oracle.com>
References: <56FEC3F8.20601@oracle.com> <56FEFC29.1040907@oracle.com>
	<5702757F.7080501@oracle.com>
Message-ID: <5702E39D.6080606@oracle.com>

OK, since we apparently have the same understanding of the code then "+1".

-phil.

On 04/04/2016 07:09 AM, Pete Brunet wrote:
>
> On 4/1/16 5:54 PM, Phil Race wrote:
>> You say its a simple fix but I need you to confirm if i have it right
>>
>> What I see is that pkg is a pointer to part of "buffer" but the
>> contents of that buffer are not initialised so the field rVMID is
>> garbage.
>> So you should not use it. So far so good.
>>
>> But then a reader must ask himself
>> 1) where does pkgVMID get initialised and used
>> 2) where does pkg->rVMID get initalised and used
>>
>>
>> I suppose that the answer to (1) is
>>
>> if (getAccessibleContextFromHWND(window, (long *)&(pkgVMID). ...)
>>
>> and it then gets used in the call
>>
>> findAccessBridgeWindow((long)pkgVMID); and for (2) that the call to
>> sendMemoryPackage(..) fills in everything in buffer,
>>
>> including implicity "pkg", and this gets used here
>>
>> *vmID = pkg->rVMID;
>>
>>
>> Is this right ?
> Yes, That is all correct.

>> The odd thing is that pkgVMID and pkg->rVMID are not obviously the
>> same thing at all so the deleted assignment was really odd ..
> True, I don't have a clue as to why that was there and the original
> developers are long gone.  Maybe the code was much different at one
> time.  The extra unneeded indentation might indicate that.  I looked
> through the code to see if pkgVMID might have been an in/out instead of
> just an out on the call to findAccessBrdige but it's just an out.
>
> Pete
>> -phil.
>>
>> On 04/01/2016 11:54 AM, Pete Brunet wrote:
>>> Please review this simple fix:
>>> https://bugs.openjdk.java.net/browse/JDK-8153149
>>> http://cr.openjdk.java.net/~ptbrunet/JDK-8153149/webrev.00/
>>>



From Sergey.Bylokhov at oracle.com  Tue Apr  5 13:59:19 2016
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Tue, 5 Apr 2016 16:59:19 +0300
Subject: <Swing Dev> [9] Review Request: 8141544 The interface
 sun.swing.UIClientPropertyKey can be made public
In-Reply-To: <5702CD68.1090005@oracle.com>
References: <5702CD68.1090005@oracle.com>
Message-ID: <5703C4B7.7060800@oracle.com>

This fix is updated according to offline comments:

http://cr.openjdk.java.net/~serb/8141544/webrev.01

  - the @since 9 was added to UIClientPropertyKey.
  - Note that StringUIClientPropertyKey was not made public for two reasons:
    * It is to trivial.
    * This was a internal decision to open this functionality and it 
seems that the scope of it is limited.

On 04.04.16 23:24, Sergey Bylokhov wrote:
> Hello,
> Please review the fix for jdk9.
>
> In the fix the UIClientPropertyKey interface is moved to javax.swing
> package. This is a tagging interface, which provides functionality
> similar to UIResource, but for the client properties(this can be useful
> for custom l&f). The spec of UIClientPropertyKey is self-descriptive.
>
> ccc will be created after the technical review.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8141544
> Webrev can be found at: http://cr.openjdk.java.net/~serb/8141544/webrev.00
>
>


-- 
Best regards, Sergey.


From Sergey.Bylokhov at oracle.com  Tue Apr  5 14:14:33 2016
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Tue, 5 Apr 2016 17:14:33 +0300
Subject: <Swing Dev> RfR: JDK-8153153,
 Format string argument mismatch in jaccesswalker.cpp:545
In-Reply-To: <5702E343.9080803@oracle.com>
References: <56FEC460.50100@oracle.com> <56FFEC1F.9050800@oracle.com>
	<57026D42.5030504@oracle.com> <5702A000.8010005@oracle.com>
	<5702E40F.6010606@oracle.com> <5702E343.9080803@oracle.com>
Message-ID: <5703C849.40702@oracle.com>

On 05.04.16 0:57, Phil Race wrote:
> The bug is now evaluated and jPRT is happy so "+1"

+1

>
> -phil.
>
> On 04/04/2016 03:00 PM, Pete Brunet wrote:
>> Evaluation added.
>>
>> Is the patch OK?
>>
>> https://bugs.openjdk.java.net/browse/JDK-8153153
>> http://cr.openjdk.java.net/~ptbrunet/JDK-8153153/webrev.00/
>>
>> Pete
>>
>>
>> On 4/4/16 12:10 PM, Phil Race wrote:
>>> All bugs should have an evaluation. Period.
>>>
>>> -phil.
>>>
>>> On 04/04/2016 06:33 AM, Pete Brunet wrote:
>>>> Hi Phil, As far as I know this doesn't need an evaluation.  It's just a
>>>> printf arg mismatch so a 64 bit pointer only gets printed as a 32 bit
>>>> value, i.e. %X was used where %p should have been used.  It's something
>>>> I fixed in a lot of other places but this is one I missed.  All 7 JPRT
>>>> targets build OK.
>>>>
>>>> Pete
>>>>
>>>> On 4/2/16 10:58 AM, Philip Race wrote:
>>>>> I notice the bug has no evaluation. Unevaluated bugs aren't ready for
>>>>> review.
>>>>> Also did you run this through jprt ? If this causes a warning on some
>>>>> other
>>>>> platform than you tried you will break the build.
>>>>>
>>>>> -phil.
>>>>>
>>>>> On 4/1/16, 11:56 AM, Pete Brunet wrote:
>>>>>> Please review this simple fix:
>>>>>> https://bugs.openjdk.java.net/browse/JDK-8153153
>>>>>> http://cr.openjdk.java.net/~ptbrunet/JDK-8153153/webrev.00/
>


-- 
Best regards, Sergey.


From Sergey.Bylokhov at oracle.com  Tue Apr  5 14:26:49 2016
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Tue, 5 Apr 2016 17:26:49 +0300
Subject: <Swing Dev> RfR JDK-8153149,
 Uninitialised memory in WinAccessBridge.cpp:1128
In-Reply-To: <5702E39D.6080606@oracle.com>
References: <56FEC3F8.20601@oracle.com> <56FEFC29.1040907@oracle.com>
	<5702757F.7080501@oracle.com> <5702E39D.6080606@oracle.com>
Message-ID: <5703CB29.7030807@oracle.com>

+1
I assume that jprt was passed, and the changed code was sanity checked.

On 05.04.16 0:58, Phil Race wrote:
> OK, since we apparently have the same understanding of the code then "+1".
>
> -phil.
>
> On 04/04/2016 07:09 AM, Pete Brunet wrote:
>>
>> On 4/1/16 5:54 PM, Phil Race wrote:
>>> You say its a simple fix but I need you to confirm if i have it right
>>>
>>> What I see is that pkg is a pointer to part of "buffer" but the
>>> contents of that buffer are not initialised so the field rVMID is
>>> garbage.
>>> So you should not use it. So far so good.
>>>
>>> But then a reader must ask himself
>>> 1) where does pkgVMID get initialised and used
>>> 2) where does pkg->rVMID get initalised and used
>>>
>>>
>>> I suppose that the answer to (1) is
>>>
>>> if (getAccessibleContextFromHWND(window, (long *)&(pkgVMID). ...)
>>>
>>> and it then gets used in the call
>>>
>>> findAccessBridgeWindow((long)pkgVMID); and for (2) that the call to
>>> sendMemoryPackage(..) fills in everything in buffer,
>>>
>>> including implicity "pkg", and this gets used here
>>>
>>> *vmID = pkg->rVMID;
>>>
>>>
>>> Is this right ?
>> Yes, That is all correct.
>
>>> The odd thing is that pkgVMID and pkg->rVMID are not obviously the
>>> same thing at all so the deleted assignment was really odd ..
>> True, I don't have a clue as to why that was there and the original
>> developers are long gone.  Maybe the code was much different at one
>> time.  The extra unneeded indentation might indicate that.  I looked
>> through the code to see if pkgVMID might have been an in/out instead of
>> just an out on the call to findAccessBrdige but it's just an out.
>>
>> Pete
>>> -phil.
>>>
>>> On 04/01/2016 11:54 AM, Pete Brunet wrote:
>>>> Please review this simple fix:
>>>> https://bugs.openjdk.java.net/browse/JDK-8153149
>>>> http://cr.openjdk.java.net/~ptbrunet/JDK-8153149/webrev.00/
>>>>
>


-- 
Best regards, Sergey.


From alexandr.scherbatiy at oracle.com  Tue Apr  5 14:35:30 2016
From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy)
Date: Tue, 5 Apr 2016 18:35:30 +0400
Subject: <Swing Dev> [9] Review Request: 8141544 The interface
 sun.swing.UIClientPropertyKey can be made public
In-Reply-To: <5703C4B7.7060800@oracle.com>
References: <5702CD68.1090005@oracle.com> <5703C4B7.7060800@oracle.com>
Message-ID: <5703CD32.2040000@oracle.com>


   The fix looks good to me.

   Thanks,
   Alexandr.

On 05/04/16 17:59, Sergey Bylokhov wrote:
> This fix is updated according to offline comments:
>
> http://cr.openjdk.java.net/~serb/8141544/webrev.01
>
>  - the @since 9 was added to UIClientPropertyKey.
>  - Note that StringUIClientPropertyKey was not made public for two 
> reasons:
>    * It is to trivial.
>    * This was a internal decision to open this functionality and it 
> seems that the scope of it is limited.
>
> On 04.04.16 23:24, Sergey Bylokhov wrote:
>> Hello,
>> Please review the fix for jdk9.
>>
>> In the fix the UIClientPropertyKey interface is moved to javax.swing
>> package. This is a tagging interface, which provides functionality
>> similar to UIResource, but for the client properties(this can be useful
>> for custom l&f). The spec of UIClientPropertyKey is self-descriptive.
>>
>> ccc will be created after the technical review.
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8141544
>> Webrev can be found at: 
>> http://cr.openjdk.java.net/~serb/8141544/webrev.00
>>
>>
>
>



From Sergey.Bylokhov at oracle.com  Tue Apr  5 16:39:16 2016
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Tue, 5 Apr 2016 19:39:16 +0300
Subject: <Swing Dev> [9] Review request for 8132119 Provide public API
 for text related methods in SwingUtilities2
In-Reply-To: <5702E1D3.5070008@oracle.com>
References: <55E715A1.3090008@oracle.com> <55E72D3A.60807@oracle.com>
	<55ED586F.5070509@oracle.com> <55F6DC3C.60809@oracle.com>
	<5655D3AB.9050503@oracle.com> <5668051E.7090401@oracle.com>
	<5668E226.5000604@oracle.com> <5669646E.4070305@oracle.com>
	<566986FD.9020207@oracle.com> <5694F0C3.8020203@oracle.com>
	<5695572F.6070709@oracle.com> <56966730.7000701@oracle.com>
	<5698C71A.80703@oracle.com> <56991ED9.5030302@oracle.com>
	<569963B6.2050604@oracle.com> <56A5C40B.7010107@oracle.com>
	<CAM6ZMz8iEFQQtSb_bAVU5eUH=J=HapvKq3+Ana4pPxueJD1bNg@mail.gmail.com>
	<56AB8A94.2070404@oracle.com> <56EC2389.3020507@oracle.com>
	<56F38B0B.3060700@oracle.com> <56F3F13A.9000808@oracle.com>
	<56F3F83C.3010706@oracle.com> <56FD791E.1050707@oracle.com>
	<56FD83E8.3060202@oracle.com> <5702E1D3.5070008@oracle.com>
Message-ID: <5703EA34.4030203@oracle.com>

On 05.04.16 0:51, Phil Race wrote:
> Hi,
>
> Is that a response to my suggestion we not over-specify, or something
> else ?

Yes, that's was a small clarification that previous version of the spec 
had more details.

> Can you point to an example of how this changed in the latest webrev ?

For example this notion was removed:
"The provided component is used to query text properties and 
anti-aliasing hints"
http://cr.openjdk.java.net/~alexsch/8132119/webrev.03/src/java.desktop/share/classes/javax/swing/text/Utilities.java.sdiff.html

>
> -phil.
>
> On 03/31/2016 01:09 PM, Sergey Bylokhov wrote:
>> Just a small clarification. In general implementations of these
>> methods can make some "magic", but the purpose of the change is to
>> provide to the user this "magic", I mean the user's components will be
>> able to apply this "magic" to the custom components(or change behavior
>> of standard l&f). So in the latest webrev some of implementations
>> details of these methods were hidden.
>> I am not sure we express this goal successfully or not.
>>
>> On 31.03.16 22:23, Phil Race wrote:
>>> Maybe the test to pass in that case is whether the default
>>> implementation
>>> is going to be satisfactory for 90% of uses. If they are frequently
>>> over-ridden
>>> it would not be an appropriate use.
>>>
>>> Based on that criterion I think it is OK to use here.
>>>
>>> Another thought:
>>> When you add default implementations you should also be on the hook
>>> for explaining what that does. It is a deeper contract than you would
>>> otherwise have as an interface and maybe needs to be an @implNote
>>> or you need to call out the default implementation.
>>> ie there is what someone must code to satisfy the contract of the
>>> interface and what is a behaviour in the default method ?
>>>
>>>
>>> Also here is a link to some comments by Brian Goetz on default methods :
>>>
>>> http://stackoverflow.com/questions/28681737/java-8-default-methods-as-traits-safe/28684917#28684917
>>>
>>>
>>>
>>>    75      * No character is underlined if the index is negative or
>>> greater
>>>    76      * than the string length {@code (index < 0 || index >=
>>> string.length())}
>>>    77      * or if the char value specified at the given index
>>>    78      * is in the low-surrogate range.
>>>
>>>
>>> I suppose if you point at the last char and it is a hi-surrogate nothing
>>> is underlined in that case either.
>>>
>>> But I find the whole writing of this a bit inadequate as if you are
>>> going to
>>> this kind of detail you perhaps also need to say what happens in a
>>> complex
>>> script where what happens is two unicode characters end up as a
>>> ligature,
>>> and/or perhaps you aren't even pointing to a base character.
>>> Maybe it is in fact over-specified. I see that the implementation draws
>>> the underline itself rather than delegate to TextLayout. This might
>>> make sense for performance reasons where it is simple text but some day
>>> this maybe should be re-examined and so I would not over-specify it.
>>>
>>> How about :
>>> "The underline will be positioned at the base glyph which
>>> represents the valid char indicated by the index.
>>> If the char index is not valid or is not the index of a
>>> valid unicode code point then no underline is drawn"
>>>
>>> -phil.
>>>
>>>
>>>
>>> On 03/24/2016 07:22 AM, Sergey Bylokhov wrote:
>>>> On 24.03.16 16:52, Alexander Scherbatiy wrote:
>>>>> On 24/03/16 10:36, Semyon Sadetsky wrote:
>>>>>> Hi Alexander,
>>>>>>
>>>>>> Could you answer one question:
>>>>>> Why did you choose default interface methods to implement
>>>>>> TextUIDrawing and not implement them in DefaultTextUIDrawing having
>>>>>> declarations only in the interface?
>>>>>> AFAIK the common point of view is default methods should be used
>>>>>> rarely because they may lead to unreadable code.
>>>>>>
>>>>>    The only problem which I know about default methods is multiple
>>>>> inheritance which has its own solution.
>>>>
>>>> What kind of problems? The benefit is obvious: it will not be
>>>> necessary to implement all methods if only one of them should be
>>>> tweaked.
>>>>
>>>>>
>>>>>    Could you give links to discussion or provide use cases where
>>>>> default
>>>>> methods leads to the unreadable code and show how does it relate to
>>>>> the
>>>>> TextUIDrawing  implementation?
>>>>>
>>>>>    Thanks,
>>>>>    Alexandr.
>>>>>> --Semyon
>>>>>>
>>>>>> On 3/18/2016 6:49 PM, Alexander Scherbatiy wrote:
>>>>>>>
>>>>>>> Could you review the updated fix:
>>>>>>>   http://cr.openjdk.java.net/~alexsch/8132119/webrev.08/
>>>>>>>
>>>>>>>   - Public TextUIDrawing interface is added to the javax.swing.plaf
>>>>>>> package
>>>>>>>   - TextUIDrawing methods description does not mention component
>>>>>>> properties to be more general
>>>>>>>   - TextUIDrawing methods are made default
>>>>>>>   - L&F sets an instance of the TextUIDrawing to look and feel
>>>>>>> defaults using "uiDrawing.text" property
>>>>>>>   - ComponentUI class is not changed
>>>>>>>   - Each ComponentUI reads TextUIDrawing from UI defaults
>>>>>>>   - There is an interesting issue described in
>>>>>>> http://mail.openjdk.java.net/pipermail/swing-dev/2016-March/005509.html
>>>>>>>
>>>>>>>
>>>>>>>     which is related to the fact that MetalLabelUI returns a static
>>>>>>> field from createUI() method.
>>>>>>>     TitleBorder creates a JLabel but does not put it to any
>>>>>>> component
>>>>>>> hierarchy. In this case SwingUtilities.updateComponentTreeUI()
>>>>>>> method
>>>>>>> calls MetalLabelUI.uninstallDefaults() on the static metalLabelUI
>>>>>>> field and sets a new LabelUI for ordinary labels. The TitleBorder
>>>>>>> label UI is not changed in this case and it still uses the
>>>>>>> metalLabelUI field which is not initialized.
>>>>>>>     It seems that other applications can also use components just
>>>>>>> for
>>>>>>> drawing and have the same issue.
>>>>>>>     For this case the textUIDrawing field is not cleared in the
>>>>>>> uninstallDefaults but just set to a static default value which
>>>>>>> should
>>>>>>> not lead to memory leaks.
>>>>>>>
>>>>>>>   Thanks,
>>>>>>>   Alexandr.
>>>>>>>
>>>>>>> On 29/01/16 19:51, Alexander Scherbatiy wrote:
>>>>>>>> On 25/01/16 13:44, Andrej Golovnin wrote:
>>>>>>>>> Hi Alexandr,
>>>>>>>>>
>>>>>>>>>> Could you review the updated fix:
>>>>>>>>>> http://cr.openjdk.java.net/~alexsch/8132119/webrev.07/
>>>>>>>>> ....
>>>>>>>>>> - public TextUIDrawing interface is added to the javax.swing.plaf
>>>>>>>>>> package
>>>>>>>>>> - public "TextUIDrawing getTextUIDrawing()" method is added to
>>>>>>>>>> the
>>>>>>>>>> ComponentUI class
>>>>>>>>>> - L&F sets an instance of the TextUIDrawing to look and feel
>>>>>>>>>> defaults using
>>>>>>>>>> "uiDrawing.text" property
>>>>>>>>>> - Look and Feel delegates use the instance of the TextUIDrawing
>>>>>>>>>> for text
>>>>>>>>>> drawing and measuring
>>>>>>>>> Some thoughts on the current design/implementation:
>>>>>>>>>
>>>>>>>>> By adding a field to the ComponentUI class the current
>>>>>>>>> implementation increases
>>>>>>>>> memory consumption for all Swing applications. And you get the
>>>>>>>>> feeling that
>>>>>>>>> there are different implementations of TextUIDrawing per
>>>>>>>>> ComponentUI instances.
>>>>>>>>> Personally I can't imagine to have different implementations of
>>>>>>>>> TextUIDrawing for
>>>>>>>>> a given LookAndFeel. If I would design/implement it, then I would
>>>>>>>>> implement it as
>>>>>>>>> a property of the LookAndFeel class (similar to LayoutStyle)
>>>>>>>>> and not
>>>>>>>>> the ComponentUI.
>>>>>>>>> Developers can use then the following code to obtain the
>>>>>>>>> instance of
>>>>>>>>> TextUIDrawing:
>>>>>>>>>
>>>>>>>>> UIManager.getLookAndFeel().getUIDrawing() // or
>>>>>>>>> UIManager.getLookAndFeelUIDrawing() // use this static method as a
>>>>>>>>> short cut for the line above.
>>>>>>>>   LayoutStyle keeps its instance per App context. The same is for
>>>>>>>> the LookAndFeel
>>>>>>>>   when it is got through UIManager.getLookAndFeel() call.
>>>>>>>>   It means that accessing an instance of a TextUIDrawing will leads
>>>>>>>> to a time consumption.
>>>>>>>>
>>>>>>>>   There are 3 main ways of the SwingUtilities2.drawString(...)
>>>>>>>> usage:
>>>>>>>>   1. ComponentUI classes
>>>>>>>>   2. Components created in UI (like BasicInternalFrameTitlePane)
>>>>>>>>   3. Public utilities methods (like
>>>>>>>> WindowsGraphicsUtils.paintText())
>>>>>>>>
>>>>>>>>   For the cases 1 and 2 it is possible to load and store the
>>>>>>>> UIDrawing instance during installUI()/updateUI() calls to
>>>>>>>> decrease a
>>>>>>>> time access to it.
>>>>>>>>
>>>>>>>>   For the case 3 it is necessary to get LookAndFeel instance each
>>>>>>>> time (which is taken from an App context)
>>>>>>>>   or use the passed JComponent object. It requires to have a public
>>>>>>>> method and the associated variable for each instance of
>>>>>>>> JComponent/ComponentUI/... class.
>>>>>>>>> You can use this methods then in JDK too.
>>>>>>>>>
>>>>>>>>> And maybe rename the TextUIDrawing class to just UIDrawing and add
>>>>>>>>> more useful methods,
>>>>>>>>> e.g. a method to create a composite font, a method to convert DLUs
>>>>>>>>> to pixels.
>>>>>>>>   UIDrawing name may look like it should be used for any UI
>>>>>>>> drawing,
>>>>>>>> not only for text ones. I am afraid that it can be misleading.
>>>>>>>>
>>>>>>>>   Thanks,
>>>>>>>>   Alexandr.
>>>>>>>>
>>>>>>>>>
>>>>>>>>> Best regards,
>>>>>>>>> Andrej Golovnin
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>>
>>>
>>
>>
>


-- 
Best regards, Sergey.


From semyon.sadetsky at oracle.com  Tue Apr  5 17:04:10 2016
From: semyon.sadetsky at oracle.com (Semyon Sadetsky)
Date: Tue, 5 Apr 2016 20:04:10 +0300
Subject: <Swing Dev> Review-request for 8145547: JEP 283: [AWT/Swing]
 Conditional support for GTK 3 on Linux
In-Reply-To: <56EBFC4A.3080908@oracle.com>
References: <56DB4C3B.1060902@oracle.com> <56E864DE.4000706@oracle.com>
	<56E99D68.90208@oracle.com> <56EAA99E.2040104@oracle.com>
	<56EAB064.9040403@oracle.com> <56EADE8A.9060508@oracle.com>
	<56EB0C31.20300@oracle.com> <56EBFC4A.3080908@oracle.com>
Message-ID: <5703F00A.4020000@oracle.com>

The fix is updated because JEP 272 was pushed. JEP 272 has dependency on 
GTK.

http://cr.openjdk.java.net/~ssadetsky/8145547/webrev.04/

--Semyon

On 3/18/2016 4:02 PM, Semyon Sadetsky wrote:
>
>
> On 3/17/2016 10:57 PM, Phil Race wrote:
>> I ran your changes (which included my fix) through jprt and all 
>> Solaris platforms failed as follows :-
>>
>> jdk/src/java.desktop/unix/native/libawt_xawt/awt/sun_awt_X11_GtkFileDialogPeer.c", 
>> line 37: error: typedef redeclared: GtkWindow (E_TYPEDEF_REDECLARED)
>> cc: acomp failed for 
>> jdk/src/java.desktop/unix/native/libawt_xawt/awt/sun_awt_X11_GtkFileDialogPeer.c
>>
> I have fixed the Solaris build: 
> http://cr.openjdk.java.net/~ssadetsky/8145547/webrev.03/.
>
> > gint intval = NULL;
> I think this happens with you specific compiler only. Old 
> gtk2_interface.c always contained the same line.
>
> I ran JPRT with webrev.03. The URL is:
> http://sthjprt.uk.oracle.com/archives/2016/03/2016-03-18-070745.ssadetsk.client/ 
>
> It seem macosx_x64_10.9-product-c2-jdk_math build failed because of 
> another change. (?) Could you help me to interpret the JPRT job status?
>
> --Semyon
>>
>> -phil.
>>
>> On 03/17/2016 09:42 AM, Phil Race wrote:
>>> This reminded me I had not yet tried the build myself.
>>> When I did I not get the error that Sergey did but I got this as 
>>> well :-
>>>
>>> jdk9-client/jdk/src/java.desktop/unix/native/libawt_xawt/awt/gtk3_interface.c: 
>>> In function ?get_integer_property?:
>>> jdk9-client/jdk/src/java.desktop/unix/native/libawt_xawt/awt/gtk3_interface.c:2542:19: 
>>> error: initialization makes integer from pointer without a cast 
>>> [-Werror]
>>> jdk9-client/jdk/src/java.desktop/unix/native/libawt_xawt/awt/gtk3_interface.c: 
>>> In function ?get_boolean_property?:
>>> jdk9-client/jdk/src/java.desktop/unix/native/libawt_xawt/awt/gtk3_interface.c:2549:19: 
>>> error: initialization makes integer from pointer without
>>>
>>> Both lines it complains about were :
>>>
>>>     gint intval = NULL;
>>>
>>> I changed them to
>>>        gint intval = 0;
>>>
>>> I am not using the 'official' compiler, but you really should make 
>>> sure jprt is
>>> happy before confirming the webrev as final - and also fix all of 
>>> these even if
>>> the official compiler does not complain.
>>>
>>> And I did not notice any problems running SwingSet2 with either of 
>>> GTK2 or GTK3
>>> specified. It at least ran fine and clearly picked up different 
>>> versions.
>>>
>>>
>>> -phil.
>>>
>>>
>>> On 03/17/2016 06:25 AM, Semyon Sadetsky wrote:
>>>> The awt_Desktop.c is missed in the webrev.
>>>> Please see the updated one: 
>>>> http://cr.openjdk.java.net/~ssadetsky/8145547/webrev.02/
>>>>
>>>> --Semyon
>>>>
>>>> On 3/17/2016 3:57 PM, Sergey Bylokhov wrote:
>>>>> On 16.03.16 20:52, Semyon Sadetsky wrote:
>>>>>> Hi Phil,
>>>>>>
>>>>>> Thank for review. You will find my reply below in the text.
>>>>>>
>>>>>> The updated webrev is
>>>>>> http://cr.openjdk.java.net/~ssadetsky/8145547/webrev.01/
>>>>>
>>>>> On my system this version fails to build(Ubuntu 15.10 + gcc 5.2.1):
>>>>>
>>>>> ERROR: Build failed for target 'images' in configuration 
>>>>> 'linux-x86_64-normal-server-release' (exit code 2)
>>>>> === Output from failing command(s) repeated here ===
>>>>> * For target support_native_java.desktop_libawt_xawt_awt_Desktop.o:
>>>>> /mnt/hgfs/moe/workspaces/jdk/9/client-gate/jdk/src/java.desktop/unix/native/libawt_xawt/xawt/awt_Desktop.c: 
>>>>> In function ?Java_sun_awt_X11_XDesktopPeer_init?:
>>>>> /mnt/hgfs/moe/workspaces/jdk/9/client-gate/jdk/src/java.desktop/unix/native/libawt_xawt/xawt/awt_Desktop.c:46:9: 
>>>>> error: implicit declaration of function ?gtk2_load? 
>>>>> [-Werror=implicit-function-declaration]
>>>>>      if (gtk2_load(env) && gtk2_show_uri_load(env)) {
>>>>>          ^
>>>>> /mnt/hgfs/moe/workspaces/jdk/9/client-gate/jdk/src/java.desktop/unix/native/libawt_xawt/xawt/awt_Desktop.c:46:27: 
>>>>> error: implicit declaration of function ?gtk2_show_uri_load? 
>>>>> [-Werror=implicit-function-declaration]
>>>>>      if (gtk2_load(env) && gtk2_show_uri_load(env)) {
>>>>>                            ^
>>>>> cc1: all warnings being treated as errors
>>>>> === End of repeated output ===
>>>>> === Make failure sequence repeated here ===
>>>>> Awt2dLibraries.gmk:369: recipe for target 
>>>>> '/mnt/hgfs/moe/workspaces/jdk/9/client-gate/build/linux-x86_64-normal-server-release/support/native/java.desktop/libawt_xawt/awt_Desktop.o' 
>>>>> failed
>>>>> make/Main.gmk:175: recipe for target 'java.desktop-libs' failed
>>>>> === End of repeated output ===
>>>>>
>>>>>
>>>>>> It also contains:
>>>>>> - new properties jdk.gtk.version and jdk.gtk.verbose
>>>>>> - appearance tuning for Ubuntu 15 (GTK 3.14). It may require more 
>>>>>> but we
>>>>>> can do this later as a separate bug.
>>>>>> The main implementation was done for Ubuntu 14.05 LTS (GTK 3.10) and
>>>>>> then tuned for OEL 7 (GTK 3.8). Each minor GTK version may have some
>>>>>> appearance changes.
>>>>>>
>>>>>> On 3/15/2016 10:39 PM, Phil Race wrote:
>>>>>>> There is a lot to read here. I think I need to patch and try it but
>>>>>>> first ...
>>>>>>>
>>>>>>> Two high level questions :
>>>>>>> 1) Have you verified that this behaves properly (or no worse than
>>>>>>> currently) with -Djava.awt.headless=true since Swing components
>>>>>>> are supposed to be able to draw off-screen in headless mode .. and
>>>>>>> yet a dependency on GTK and its dependency on xlibraries seems 
>>>>>>> to mean
>>>>>>> that you can't load GTK in this case.
>>>>>>> BTW I think it may be painful to get them to layout in such a case
>>>>>>> but that's another issue.
>>>>>> I tested it by painting to a BufferedImage. Seems it is enough.
>>>>>>>
>>>>>>> 2) Have you tried a hi-dpi system ?
>>>>>> Yes I have. It is identical to the existing GTK2 based appearance.
>>>>>>>
>>>>>>> 3) Have you submitted a JPRT job ? It is essential to know that 
>>>>>>> this
>>>>>>> builds cleanly on the "official" compilation environment.
>>>>>> I will do this before the push. I think it will be OK because I 
>>>>>> did not
>>>>>> use any new C constructs and the new libraries are linked 
>>>>>> dynamically.
>>>>>>> 4)I expect you ran Swingset2 + GTK L&F but have you run any of the
>>>>>>> regression test suite ?
>>>>>> Yes I ran javax/swing tests but many of them fails with GTK2 as 
>>>>>> well.
>>>>>> With GTK3 the result was the same except for some unstable tests. 
>>>>>> Unity
>>>>>> desktop has new window decorations like borderless windows which are
>>>>>> resized by dragging the outer window shadow, invisible overlay
>>>>>> scrollbars, etc. Many tests written for old window decorations 
>>>>>> fails.
>>>>>>>
>>>>>>> Minor comments :
>>>>>>>
>>>>>>> GTKEngine.java
>>>>>>>
>>>>>>>  494         Container parent = context.getComponent().getParent();
>>>>>>>  495         if(GTKLookAndFeel.is3()) {
>>>>>>>  496             if (parent != null && parent.getParent() 
>>>>>>> instanceof
>>>>>>> JComboBox) {
>>>>>>>  497                 if (parent.getParent().hasFocus()) {
>>>>>>>  498                     synthState |= SynthConstants.FOCUSED;
>>>>>>>  499                 }
>>>>>>>  500             }
>>>>>>>  501         }
>>>>>>>
>>>>>>> GTKPainter.java
>>>>>>>
>>>>>>> 746         if (GTKLookAndFeel.is3()) {
>>>>>>>  747             if (slider.getOrientation() == JSlider.VERTICAL) {
>>>>>>>  748                 y += 1;
>>>>>>>  749                 h -= 2;
>>>>>>>  750             } else {
>>>>>>>  751                 x += 1;
>>>>>>>  752                 w -= 2;
>>>>>>>  753             }
>>>>>>>  754         }
>>>>>>>
>>>>>>> I don't know where these numbers come from or what coordinate 
>>>>>>> system
>>>>>>> is being used here but it seems you are changing them for gtk 
>>>>>>> 2.2 as
>>>>>>> well as 3
>>>>>>> Can you speak to this ?
>>>>>> It is an appearance tuning for GTK3. I didn't change it for GTK2, 
>>>>>> why do
>>>>>> you think so?
>>>>>> This was used before my fix as well, for example
>>>>>>
>>>>>>                      if (containerParent instanceof JComboBox) {
>>>>>>                          x += (focusSize + 2);
>>>>>>                          y += (focusSize + 1);
>>>>>>                          w -= (2 * focusSize + 1);
>>>>>>                          h -= (2 * focusSize + 2);
>>>>>>                      } else {
>>>>>>                          x += focusSize;
>>>>>>                          y += focusSize;
>>>>>>                          w -= 2 * focusSize;
>>>>>>                          h -= 2 * focusSize;
>>>>>>                      }
>>>>>>
>>>>>> The only place where I changed the existing GTK2 appearance is:
>>>>>>
>>>>>> 1121         CLASS_SPECIFIC_MAP.put("Slider.thumbWidth", 
>>>>>> "slider-length");
>>>>>>
>>>>>>   in GTKStyle.java, because this property was omitted by mistake.
>>>>>>>
>>>>>>> GTKStyle.java
>>>>>>>
>>>>>>> 735         if(!GTKLookAndFeel.is3()) {
>>>>>>>
>>>>>>> 840      } else if(GTKLookAndFeel.is3() &&
>>>>>>> "ComboBox.forceOpaque".equals(key)) {
>>>>>>>
>>>>>>>
>>>>>>> we prefer a space between "if" and "("
>>>>>> Accepted.
>>>>>>>
>>>>>>> sun_awt_X11_GtkFileDialogPeer.c
>>>>>>>
>>>>>>>  392     if (gtk->gtk_check_version(2, 8, 0) == NULL) {
>>>>>>>
>>>>>>>
>>>>>>> Maybe I am not looking at the right fn but I thought I saw
>>>>>>> this fn return a boolean so a check against NULL looks wrong.
>>>>>> The declaration is in GtkApi struct of gtk_interface.h. It returns
>>>>>> char*. NULL means that the version is compatible.
>>>>>>>
>>>>>>>  393
>>>>>>> gtk->gtk_file_chooser_set_do_overwrite_confirmation(GTK_FILE_CHOOSER( 
>>>>>>>
>>>>>>>  394                 dialog), TRUE);
>>>>>>>
>>>>>>>
>>>>>>> You didn't add this but it is awfully specific about the GTK 
>>>>>>> version and
>>>>>>> I wonder if this test is doing what it should be doing on GTK 3?
>>>>>> Accepted.
>>>>>>>
>>>>>>> It is interesting that some equivalent looking Java level dialog
>>>>>>> checking in XToolkit.java
>>>>>>> checked for 3.0 too ..
>>>>>>>
>>>>>>> swing_GTKEngine.c :
>>>>>>>
>>>>>>>   30 /* Static buffer for conversion from java.lang.String to 
>>>>>>> UTF-8 */
>>>>>>>   31 static char convertionBuffer[CONV_BUFFER_SIZE];
>>>>>>>
>>>>>>> So the variable name should be spelt conversionBuffer.
>>>>>> Accepted.
>>>>>>>
>>>>>>> awt_UNIXToolkit.c
>>>>>>>
>>>>>>> < 287 free(ret);
>>>>>>>
>>>>>>> You deleted this free(). Is that correct ? It seems to imply
>>>>>>> you now expect a boolean return as discussed above and
>>>>>>> so in that case NULL looks odd here (line 260) too.
>>>>>> The JNI exported method returns boolean while the GTK method returns
>>>>>> char*. free() is deleted intentionally according to the GTK docs it
>>>>>> belongs to the library and should not be freed by user code.
>>>>>>>
>>>>>>> gtk3_interface.h :
>>>>>>>
>>>>>>>   36 #define G_PI 
>>>>>>> 3.1415926535897932384626433832795028841971693993751
>>>>>>>
>>>>>>> I don't think that is completely accurate :-) And I should have
>>>>>>> reviewed this yesterday [1].
>>>>>> :) This is glib's definition I just copied.
>>>>>>
>>>>>> --Semyon
>>>>>>>
>>>>>>> -phil.
>>>>>>>
>>>>>>> [1] http://www.piday.org/
>>>>>>>
>>>>>>>
>>>>>>> On 03/05/2016 01:14 PM, Semyon Sadetsky wrote:
>>>>>>>> Hello,
>>>>>>>>
>>>>>>>> Please review fix for JDK9:
>>>>>>>>
>>>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8145547
>>>>>>>> webrev: http://cr.openjdk.java.net/~ssadetsky/8145547/webrev.00/
>>>>>>>>
>>>>>>>> The fix contains GTK3 based implementation for Swing GTK LnF, AWT
>>>>>>>> FileChooser for Linux and AWT Robot for Linux.
>>>>>>>> Also the new system property is added to request specific GTK 
>>>>>>>> version
>>>>>>>> swing.gtk.version.
>>>>>>>>
>>>>>>>> --Semyon
>>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>
>>
>



From philip.race at oracle.com  Tue Apr  5 17:54:31 2016
From: philip.race at oracle.com (Phil Race)
Date: Tue, 05 Apr 2016 10:54:31 -0700
Subject: <Swing Dev> Review-request for 8145547: JEP 283: [AWT/Swing]
 Conditional support for GTK 3 on Linux
In-Reply-To: <5703F00A.4020000@oracle.com>
References: <56DB4C3B.1060902@oracle.com> <56E864DE.4000706@oracle.com>
	<56E99D68.90208@oracle.com> <56EAA99E.2040104@oracle.com>
	<56EAB064.9040403@oracle.com> <56EADE8A.9060508@oracle.com>
	<56EB0C31.20300@oracle.com> <56EBFC4A.3080908@oracle.com>
	<5703F00A.4020000@oracle.com>
Message-ID: <5703FBD7.4010200@oracle.com>

Could you point me to what was updated ?

-phil.

On 04/05/2016 10:04 AM, Semyon Sadetsky wrote:
> The fix is updated because JEP 272 was pushed. JEP 272 has dependency 
> on GTK.
>
> http://cr.openjdk.java.net/~ssadetsky/8145547/webrev.04/
>
> --Semyon
>
> On 3/18/2016 4:02 PM, Semyon Sadetsky wrote:
>>
>>
>> On 3/17/2016 10:57 PM, Phil Race wrote:
>>> I ran your changes (which included my fix) through jprt and all 
>>> Solaris platforms failed as follows :-
>>>
>>> jdk/src/java.desktop/unix/native/libawt_xawt/awt/sun_awt_X11_GtkFileDialogPeer.c", 
>>> line 37: error: typedef redeclared: GtkWindow (E_TYPEDEF_REDECLARED)
>>> cc: acomp failed for 
>>> jdk/src/java.desktop/unix/native/libawt_xawt/awt/sun_awt_X11_GtkFileDialogPeer.c
>>>
>> I have fixed the Solaris build: 
>> http://cr.openjdk.java.net/~ssadetsky/8145547/webrev.03/.
>>
>> > gint intval = NULL;
>> I think this happens with you specific compiler only. Old 
>> gtk2_interface.c always contained the same line.
>>
>> I ran JPRT with webrev.03. The URL is:
>> http://sthjprt.uk.oracle.com/archives/2016/03/2016-03-18-070745.ssadetsk.client/ 
>>
>> It seem macosx_x64_10.9-product-c2-jdk_math build failed because of 
>> another change. (?) Could you help me to interpret the JPRT job status?
>>
>> --Semyon
>>>
>>> -phil.
>>>
>>> On 03/17/2016 09:42 AM, Phil Race wrote:
>>>> This reminded me I had not yet tried the build myself.
>>>> When I did I not get the error that Sergey did but I got this as 
>>>> well :-
>>>>
>>>> jdk9-client/jdk/src/java.desktop/unix/native/libawt_xawt/awt/gtk3_interface.c: 
>>>> In function ?get_integer_property?:
>>>> jdk9-client/jdk/src/java.desktop/unix/native/libawt_xawt/awt/gtk3_interface.c:2542:19: 
>>>> error: initialization makes integer from pointer without a cast 
>>>> [-Werror]
>>>> jdk9-client/jdk/src/java.desktop/unix/native/libawt_xawt/awt/gtk3_interface.c: 
>>>> In function ?get_boolean_property?:
>>>> jdk9-client/jdk/src/java.desktop/unix/native/libawt_xawt/awt/gtk3_interface.c:2549:19: 
>>>> error: initialization makes integer from pointer without
>>>>
>>>> Both lines it complains about were :
>>>>
>>>>     gint intval = NULL;
>>>>
>>>> I changed them to
>>>>        gint intval = 0;
>>>>
>>>> I am not using the 'official' compiler, but you really should make 
>>>> sure jprt is
>>>> happy before confirming the webrev as final - and also fix all of 
>>>> these even if
>>>> the official compiler does not complain.
>>>>
>>>> And I did not notice any problems running SwingSet2 with either of 
>>>> GTK2 or GTK3
>>>> specified. It at least ran fine and clearly picked up different 
>>>> versions.
>>>>
>>>>
>>>> -phil.
>>>>
>>>>
>>>> On 03/17/2016 06:25 AM, Semyon Sadetsky wrote:
>>>>> The awt_Desktop.c is missed in the webrev.
>>>>> Please see the updated one: 
>>>>> http://cr.openjdk.java.net/~ssadetsky/8145547/webrev.02/
>>>>>
>>>>> --Semyon
>>>>>
>>>>> On 3/17/2016 3:57 PM, Sergey Bylokhov wrote:
>>>>>> On 16.03.16 20:52, Semyon Sadetsky wrote:
>>>>>>> Hi Phil,
>>>>>>>
>>>>>>> Thank for review. You will find my reply below in the text.
>>>>>>>
>>>>>>> The updated webrev is
>>>>>>> http://cr.openjdk.java.net/~ssadetsky/8145547/webrev.01/
>>>>>>
>>>>>> On my system this version fails to build(Ubuntu 15.10 + gcc 5.2.1):
>>>>>>
>>>>>> ERROR: Build failed for target 'images' in configuration 
>>>>>> 'linux-x86_64-normal-server-release' (exit code 2)
>>>>>> === Output from failing command(s) repeated here ===
>>>>>> * For target support_native_java.desktop_libawt_xawt_awt_Desktop.o:
>>>>>> /mnt/hgfs/moe/workspaces/jdk/9/client-gate/jdk/src/java.desktop/unix/native/libawt_xawt/xawt/awt_Desktop.c: 
>>>>>> In function ?Java_sun_awt_X11_XDesktopPeer_init?:
>>>>>> /mnt/hgfs/moe/workspaces/jdk/9/client-gate/jdk/src/java.desktop/unix/native/libawt_xawt/xawt/awt_Desktop.c:46:9: 
>>>>>> error: implicit declaration of function ?gtk2_load? 
>>>>>> [-Werror=implicit-function-declaration]
>>>>>>      if (gtk2_load(env) && gtk2_show_uri_load(env)) {
>>>>>>          ^
>>>>>> /mnt/hgfs/moe/workspaces/jdk/9/client-gate/jdk/src/java.desktop/unix/native/libawt_xawt/xawt/awt_Desktop.c:46:27: 
>>>>>> error: implicit declaration of function ?gtk2_show_uri_load? 
>>>>>> [-Werror=implicit-function-declaration]
>>>>>>      if (gtk2_load(env) && gtk2_show_uri_load(env)) {
>>>>>>                            ^
>>>>>> cc1: all warnings being treated as errors
>>>>>> === End of repeated output ===
>>>>>> === Make failure sequence repeated here ===
>>>>>> Awt2dLibraries.gmk:369: recipe for target 
>>>>>> '/mnt/hgfs/moe/workspaces/jdk/9/client-gate/build/linux-x86_64-normal-server-release/support/native/java.desktop/libawt_xawt/awt_Desktop.o' 
>>>>>> failed
>>>>>> make/Main.gmk:175: recipe for target 'java.desktop-libs' failed
>>>>>> === End of repeated output ===
>>>>>>
>>>>>>
>>>>>>> It also contains:
>>>>>>> - new properties jdk.gtk.version and jdk.gtk.verbose
>>>>>>> - appearance tuning for Ubuntu 15 (GTK 3.14). It may require 
>>>>>>> more but we
>>>>>>> can do this later as a separate bug.
>>>>>>> The main implementation was done for Ubuntu 14.05 LTS (GTK 3.10) 
>>>>>>> and
>>>>>>> then tuned for OEL 7 (GTK 3.8). Each minor GTK version may have 
>>>>>>> some
>>>>>>> appearance changes.
>>>>>>>
>>>>>>> On 3/15/2016 10:39 PM, Phil Race wrote:
>>>>>>>> There is a lot to read here. I think I need to patch and try it 
>>>>>>>> but
>>>>>>>> first ...
>>>>>>>>
>>>>>>>> Two high level questions :
>>>>>>>> 1) Have you verified that this behaves properly (or no worse than
>>>>>>>> currently) with -Djava.awt.headless=true since Swing components
>>>>>>>> are supposed to be able to draw off-screen in headless mode .. and
>>>>>>>> yet a dependency on GTK and its dependency on xlibraries seems 
>>>>>>>> to mean
>>>>>>>> that you can't load GTK in this case.
>>>>>>>> BTW I think it may be painful to get them to layout in such a case
>>>>>>>> but that's another issue.
>>>>>>> I tested it by painting to a BufferedImage. Seems it is enough.
>>>>>>>>
>>>>>>>> 2) Have you tried a hi-dpi system ?
>>>>>>> Yes I have. It is identical to the existing GTK2 based appearance.
>>>>>>>>
>>>>>>>> 3) Have you submitted a JPRT job ? It is essential to know that 
>>>>>>>> this
>>>>>>>> builds cleanly on the "official" compilation environment.
>>>>>>> I will do this before the push. I think it will be OK because I 
>>>>>>> did not
>>>>>>> use any new C constructs and the new libraries are linked 
>>>>>>> dynamically.
>>>>>>>> 4)I expect you ran Swingset2 + GTK L&F but have you run any of the
>>>>>>>> regression test suite ?
>>>>>>> Yes I ran javax/swing tests but many of them fails with GTK2 as 
>>>>>>> well.
>>>>>>> With GTK3 the result was the same except for some unstable 
>>>>>>> tests. Unity
>>>>>>> desktop has new window decorations like borderless windows which 
>>>>>>> are
>>>>>>> resized by dragging the outer window shadow, invisible overlay
>>>>>>> scrollbars, etc. Many tests written for old window decorations 
>>>>>>> fails.
>>>>>>>>
>>>>>>>> Minor comments :
>>>>>>>>
>>>>>>>> GTKEngine.java
>>>>>>>>
>>>>>>>>  494         Container parent = 
>>>>>>>> context.getComponent().getParent();
>>>>>>>>  495         if(GTKLookAndFeel.is3()) {
>>>>>>>>  496             if (parent != null && parent.getParent() 
>>>>>>>> instanceof
>>>>>>>> JComboBox) {
>>>>>>>>  497                 if (parent.getParent().hasFocus()) {
>>>>>>>>  498                     synthState |= SynthConstants.FOCUSED;
>>>>>>>>  499                 }
>>>>>>>>  500             }
>>>>>>>>  501         }
>>>>>>>>
>>>>>>>> GTKPainter.java
>>>>>>>>
>>>>>>>> 746         if (GTKLookAndFeel.is3()) {
>>>>>>>>  747             if (slider.getOrientation() == 
>>>>>>>> JSlider.VERTICAL) {
>>>>>>>>  748                 y += 1;
>>>>>>>>  749                 h -= 2;
>>>>>>>>  750             } else {
>>>>>>>>  751                 x += 1;
>>>>>>>>  752                 w -= 2;
>>>>>>>>  753             }
>>>>>>>>  754         }
>>>>>>>>
>>>>>>>> I don't know where these numbers come from or what coordinate 
>>>>>>>> system
>>>>>>>> is being used here but it seems you are changing them for gtk 
>>>>>>>> 2.2 as
>>>>>>>> well as 3
>>>>>>>> Can you speak to this ?
>>>>>>> It is an appearance tuning for GTK3. I didn't change it for 
>>>>>>> GTK2, why do
>>>>>>> you think so?
>>>>>>> This was used before my fix as well, for example
>>>>>>>
>>>>>>>                      if (containerParent instanceof JComboBox) {
>>>>>>>                          x += (focusSize + 2);
>>>>>>>                          y += (focusSize + 1);
>>>>>>>                          w -= (2 * focusSize + 1);
>>>>>>>                          h -= (2 * focusSize + 2);
>>>>>>>                      } else {
>>>>>>>                          x += focusSize;
>>>>>>>                          y += focusSize;
>>>>>>>                          w -= 2 * focusSize;
>>>>>>>                          h -= 2 * focusSize;
>>>>>>>                      }
>>>>>>>
>>>>>>> The only place where I changed the existing GTK2 appearance is:
>>>>>>>
>>>>>>> 1121 CLASS_SPECIFIC_MAP.put("Slider.thumbWidth", "slider-length");
>>>>>>>
>>>>>>>   in GTKStyle.java, because this property was omitted by mistake.
>>>>>>>>
>>>>>>>> GTKStyle.java
>>>>>>>>
>>>>>>>> 735         if(!GTKLookAndFeel.is3()) {
>>>>>>>>
>>>>>>>> 840      } else if(GTKLookAndFeel.is3() &&
>>>>>>>> "ComboBox.forceOpaque".equals(key)) {
>>>>>>>>
>>>>>>>>
>>>>>>>> we prefer a space between "if" and "("
>>>>>>> Accepted.
>>>>>>>>
>>>>>>>> sun_awt_X11_GtkFileDialogPeer.c
>>>>>>>>
>>>>>>>>  392     if (gtk->gtk_check_version(2, 8, 0) == NULL) {
>>>>>>>>
>>>>>>>>
>>>>>>>> Maybe I am not looking at the right fn but I thought I saw
>>>>>>>> this fn return a boolean so a check against NULL looks wrong.
>>>>>>> The declaration is in GtkApi struct of gtk_interface.h. It returns
>>>>>>> char*. NULL means that the version is compatible.
>>>>>>>>
>>>>>>>>  393
>>>>>>>> gtk->gtk_file_chooser_set_do_overwrite_confirmation(GTK_FILE_CHOOSER( 
>>>>>>>>
>>>>>>>>  394                 dialog), TRUE);
>>>>>>>>
>>>>>>>>
>>>>>>>> You didn't add this but it is awfully specific about the GTK 
>>>>>>>> version and
>>>>>>>> I wonder if this test is doing what it should be doing on GTK 3?
>>>>>>> Accepted.
>>>>>>>>
>>>>>>>> It is interesting that some equivalent looking Java level dialog
>>>>>>>> checking in XToolkit.java
>>>>>>>> checked for 3.0 too ..
>>>>>>>>
>>>>>>>> swing_GTKEngine.c :
>>>>>>>>
>>>>>>>>   30 /* Static buffer for conversion from java.lang.String to 
>>>>>>>> UTF-8 */
>>>>>>>>   31 static char convertionBuffer[CONV_BUFFER_SIZE];
>>>>>>>>
>>>>>>>> So the variable name should be spelt conversionBuffer.
>>>>>>> Accepted.
>>>>>>>>
>>>>>>>> awt_UNIXToolkit.c
>>>>>>>>
>>>>>>>> < 287 free(ret);
>>>>>>>>
>>>>>>>> You deleted this free(). Is that correct ? It seems to imply
>>>>>>>> you now expect a boolean return as discussed above and
>>>>>>>> so in that case NULL looks odd here (line 260) too.
>>>>>>> The JNI exported method returns boolean while the GTK method 
>>>>>>> returns
>>>>>>> char*. free() is deleted intentionally according to the GTK docs it
>>>>>>> belongs to the library and should not be freed by user code.
>>>>>>>>
>>>>>>>> gtk3_interface.h :
>>>>>>>>
>>>>>>>>   36 #define G_PI 
>>>>>>>> 3.1415926535897932384626433832795028841971693993751
>>>>>>>>
>>>>>>>> I don't think that is completely accurate :-) And I should have
>>>>>>>> reviewed this yesterday [1].
>>>>>>> :) This is glib's definition I just copied.
>>>>>>>
>>>>>>> --Semyon
>>>>>>>>
>>>>>>>> -phil.
>>>>>>>>
>>>>>>>> [1] http://www.piday.org/
>>>>>>>>
>>>>>>>>
>>>>>>>> On 03/05/2016 01:14 PM, Semyon Sadetsky wrote:
>>>>>>>>> Hello,
>>>>>>>>>
>>>>>>>>> Please review fix for JDK9:
>>>>>>>>>
>>>>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8145547
>>>>>>>>> webrev: http://cr.openjdk.java.net/~ssadetsky/8145547/webrev.00/
>>>>>>>>>
>>>>>>>>> The fix contains GTK3 based implementation for Swing GTK LnF, AWT
>>>>>>>>> FileChooser for Linux and AWT Robot for Linux.
>>>>>>>>> Also the new system property is added to request specific GTK 
>>>>>>>>> version
>>>>>>>>> swing.gtk.version.
>>>>>>>>>
>>>>>>>>> --Semyon
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>



From semyon.sadetsky at oracle.com  Tue Apr  5 18:02:35 2016
From: semyon.sadetsky at oracle.com (Semyon Sadetsky)
Date: Tue, 5 Apr 2016 21:02:35 +0300
Subject: <Swing Dev> [9] Review Request for 8078514: Nightly:
 api/javax_swing/DefaultRowSorter/index_ModelStructChanged failure
In-Reply-To: <566735DC.8050706@oracle.com>
References: <55560786.9010306@oracle.com> <555B1885.2020605@oracle.com>
	<555DECDB.6020301@oracle.com> <55644D39.2080208@oracle.com>
	<56376A78.3090900@oracle.com> <566735DC.8050706@oracle.com>
Message-ID: <5703FDBB.4000701@oracle.com>



On 12/8/2015 10:56 PM, Sergey Bylokhov wrote:
> On 02/11/15 16:51, Semyon Sadetsky wrote:
>> On 5/26/2015 1:38 PM, Alexander Scherbatiy wrote:
>>> 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?
>> I fixed the FilePane. Please review the updated webrev:
>> http://cr.openjdk.java.net/~ssadetsky/8078514/webrev.02/
>
> Can you please clarify the change from v01->v02 related to 
> modelRowCount. One fix version uses Math.max, latest version skip it. 
> but getViewRowCount() still use Math.max.
The v02 takes into account Alexander's concern about too many Math.max 
but changes the FilePane. Nevertheless in getViewRowCount() Math.max is 
required to fix the issue.

--Semyon
>
>>>
>>>   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 semyon.sadetsky at oracle.com  Tue Apr  5 18:16:47 2016
From: semyon.sadetsky at oracle.com (Semyon Sadetsky)
Date: Tue, 5 Apr 2016 21:16:47 +0300
Subject: <Swing Dev> Review-request for 8145547: JEP 283: [AWT/Swing]
 Conditional support for GTK 3 on Linux
In-Reply-To: <5703FBD7.4010200@oracle.com>
References: <56DB4C3B.1060902@oracle.com> <56E864DE.4000706@oracle.com>
	<56E99D68.90208@oracle.com> <56EAA99E.2040104@oracle.com>
	<56EAB064.9040403@oracle.com> <56EADE8A.9060508@oracle.com>
	<56EB0C31.20300@oracle.com> <56EBFC4A.3080908@oracle.com>
	<5703F00A.4020000@oracle.com> <5703FBD7.4010200@oracle.com>
Message-ID: <5704010F.2030001@oracle.com>

XTaskbarPeer.java, awt_Taskbar.c and awt_Taskbar.h were changed to use 
the new common gtk_interface.

Glib calls which are necessary for the taskbar module are  added to 
gtk_interface: g_object_unref(), g_list_append(), g_list_free(), 
g_list_free_full().

--Semyon


On 4/5/2016 8:54 PM, Phil Race wrote:
> Could you point me to what was updated ?
>
> -phil.
>
> On 04/05/2016 10:04 AM, Semyon Sadetsky wrote:
>> The fix is updated because JEP 272 was pushed. JEP 272 has dependency 
>> on GTK.
>>
>> http://cr.openjdk.java.net/~ssadetsky/8145547/webrev.04/
>>
>> --Semyon
>>
>> On 3/18/2016 4:02 PM, Semyon Sadetsky wrote:
>>>
>>>
>>> On 3/17/2016 10:57 PM, Phil Race wrote:
>>>> I ran your changes (which included my fix) through jprt and all 
>>>> Solaris platforms failed as follows :-
>>>>
>>>> jdk/src/java.desktop/unix/native/libawt_xawt/awt/sun_awt_X11_GtkFileDialogPeer.c", 
>>>> line 37: error: typedef redeclared: GtkWindow (E_TYPEDEF_REDECLARED)
>>>> cc: acomp failed for 
>>>> jdk/src/java.desktop/unix/native/libawt_xawt/awt/sun_awt_X11_GtkFileDialogPeer.c
>>>>
>>> I have fixed the Solaris build: 
>>> http://cr.openjdk.java.net/~ssadetsky/8145547/webrev.03/.
>>>
>>> > gint intval = NULL;
>>> I think this happens with you specific compiler only. Old 
>>> gtk2_interface.c always contained the same line.
>>>
>>> I ran JPRT with webrev.03. The URL is:
>>> http://sthjprt.uk.oracle.com/archives/2016/03/2016-03-18-070745.ssadetsk.client/ 
>>>
>>> It seem macosx_x64_10.9-product-c2-jdk_math build failed because of 
>>> another change. (?) Could you help me to interpret the JPRT job status?
>>>
>>> --Semyon
>>>>
>>>> -phil.
>>>>
>>>> On 03/17/2016 09:42 AM, Phil Race wrote:
>>>>> This reminded me I had not yet tried the build myself.
>>>>> When I did I not get the error that Sergey did but I got this as 
>>>>> well :-
>>>>>
>>>>> jdk9-client/jdk/src/java.desktop/unix/native/libawt_xawt/awt/gtk3_interface.c: 
>>>>> In function ?get_integer_property?:
>>>>> jdk9-client/jdk/src/java.desktop/unix/native/libawt_xawt/awt/gtk3_interface.c:2542:19: 
>>>>> error: initialization makes integer from pointer without a cast 
>>>>> [-Werror]
>>>>> jdk9-client/jdk/src/java.desktop/unix/native/libawt_xawt/awt/gtk3_interface.c: 
>>>>> In function ?get_boolean_property?:
>>>>> jdk9-client/jdk/src/java.desktop/unix/native/libawt_xawt/awt/gtk3_interface.c:2549:19: 
>>>>> error: initialization makes integer from pointer without
>>>>>
>>>>> Both lines it complains about were :
>>>>>
>>>>>     gint intval = NULL;
>>>>>
>>>>> I changed them to
>>>>>        gint intval = 0;
>>>>>
>>>>> I am not using the 'official' compiler, but you really should make 
>>>>> sure jprt is
>>>>> happy before confirming the webrev as final - and also fix all of 
>>>>> these even if
>>>>> the official compiler does not complain.
>>>>>
>>>>> And I did not notice any problems running SwingSet2 with either of 
>>>>> GTK2 or GTK3
>>>>> specified. It at least ran fine and clearly picked up different 
>>>>> versions.
>>>>>
>>>>>
>>>>> -phil.
>>>>>
>>>>>
>>>>> On 03/17/2016 06:25 AM, Semyon Sadetsky wrote:
>>>>>> The awt_Desktop.c is missed in the webrev.
>>>>>> Please see the updated one: 
>>>>>> http://cr.openjdk.java.net/~ssadetsky/8145547/webrev.02/
>>>>>>
>>>>>> --Semyon
>>>>>>
>>>>>> On 3/17/2016 3:57 PM, Sergey Bylokhov wrote:
>>>>>>> On 16.03.16 20:52, Semyon Sadetsky wrote:
>>>>>>>> Hi Phil,
>>>>>>>>
>>>>>>>> Thank for review. You will find my reply below in the text.
>>>>>>>>
>>>>>>>> The updated webrev is
>>>>>>>> http://cr.openjdk.java.net/~ssadetsky/8145547/webrev.01/
>>>>>>>
>>>>>>> On my system this version fails to build(Ubuntu 15.10 + gcc 5.2.1):
>>>>>>>
>>>>>>> ERROR: Build failed for target 'images' in configuration 
>>>>>>> 'linux-x86_64-normal-server-release' (exit code 2)
>>>>>>> === Output from failing command(s) repeated here ===
>>>>>>> * For target support_native_java.desktop_libawt_xawt_awt_Desktop.o:
>>>>>>> /mnt/hgfs/moe/workspaces/jdk/9/client-gate/jdk/src/java.desktop/unix/native/libawt_xawt/xawt/awt_Desktop.c: 
>>>>>>> In function ?Java_sun_awt_X11_XDesktopPeer_init?:
>>>>>>> /mnt/hgfs/moe/workspaces/jdk/9/client-gate/jdk/src/java.desktop/unix/native/libawt_xawt/xawt/awt_Desktop.c:46:9: 
>>>>>>> error: implicit declaration of function ?gtk2_load? 
>>>>>>> [-Werror=implicit-function-declaration]
>>>>>>>      if (gtk2_load(env) && gtk2_show_uri_load(env)) {
>>>>>>>          ^
>>>>>>> /mnt/hgfs/moe/workspaces/jdk/9/client-gate/jdk/src/java.desktop/unix/native/libawt_xawt/xawt/awt_Desktop.c:46:27: 
>>>>>>> error: implicit declaration of function ?gtk2_show_uri_load? 
>>>>>>> [-Werror=implicit-function-declaration]
>>>>>>>      if (gtk2_load(env) && gtk2_show_uri_load(env)) {
>>>>>>>                            ^
>>>>>>> cc1: all warnings being treated as errors
>>>>>>> === End of repeated output ===
>>>>>>> === Make failure sequence repeated here ===
>>>>>>> Awt2dLibraries.gmk:369: recipe for target 
>>>>>>> '/mnt/hgfs/moe/workspaces/jdk/9/client-gate/build/linux-x86_64-normal-server-release/support/native/java.desktop/libawt_xawt/awt_Desktop.o' 
>>>>>>> failed
>>>>>>> make/Main.gmk:175: recipe for target 'java.desktop-libs' failed
>>>>>>> === End of repeated output ===
>>>>>>>
>>>>>>>
>>>>>>>> It also contains:
>>>>>>>> - new properties jdk.gtk.version and jdk.gtk.verbose
>>>>>>>> - appearance tuning for Ubuntu 15 (GTK 3.14). It may require 
>>>>>>>> more but we
>>>>>>>> can do this later as a separate bug.
>>>>>>>> The main implementation was done for Ubuntu 14.05 LTS (GTK 
>>>>>>>> 3.10) and
>>>>>>>> then tuned for OEL 7 (GTK 3.8). Each minor GTK version may have 
>>>>>>>> some
>>>>>>>> appearance changes.
>>>>>>>>
>>>>>>>> On 3/15/2016 10:39 PM, Phil Race wrote:
>>>>>>>>> There is a lot to read here. I think I need to patch and try 
>>>>>>>>> it but
>>>>>>>>> first ...
>>>>>>>>>
>>>>>>>>> Two high level questions :
>>>>>>>>> 1) Have you verified that this behaves properly (or no worse than
>>>>>>>>> currently) with -Djava.awt.headless=true since Swing components
>>>>>>>>> are supposed to be able to draw off-screen in headless mode .. 
>>>>>>>>> and
>>>>>>>>> yet a dependency on GTK and its dependency on xlibraries seems 
>>>>>>>>> to mean
>>>>>>>>> that you can't load GTK in this case.
>>>>>>>>> BTW I think it may be painful to get them to layout in such a 
>>>>>>>>> case
>>>>>>>>> but that's another issue.
>>>>>>>> I tested it by painting to a BufferedImage. Seems it is enough.
>>>>>>>>>
>>>>>>>>> 2) Have you tried a hi-dpi system ?
>>>>>>>> Yes I have. It is identical to the existing GTK2 based appearance.
>>>>>>>>>
>>>>>>>>> 3) Have you submitted a JPRT job ? It is essential to know 
>>>>>>>>> that this
>>>>>>>>> builds cleanly on the "official" compilation environment.
>>>>>>>> I will do this before the push. I think it will be OK because I 
>>>>>>>> did not
>>>>>>>> use any new C constructs and the new libraries are linked 
>>>>>>>> dynamically.
>>>>>>>>> 4)I expect you ran Swingset2 + GTK L&F but have you run any of 
>>>>>>>>> the
>>>>>>>>> regression test suite ?
>>>>>>>> Yes I ran javax/swing tests but many of them fails with GTK2 as 
>>>>>>>> well.
>>>>>>>> With GTK3 the result was the same except for some unstable 
>>>>>>>> tests. Unity
>>>>>>>> desktop has new window decorations like borderless windows 
>>>>>>>> which are
>>>>>>>> resized by dragging the outer window shadow, invisible overlay
>>>>>>>> scrollbars, etc. Many tests written for old window decorations 
>>>>>>>> fails.
>>>>>>>>>
>>>>>>>>> Minor comments :
>>>>>>>>>
>>>>>>>>> GTKEngine.java
>>>>>>>>>
>>>>>>>>>  494         Container parent = 
>>>>>>>>> context.getComponent().getParent();
>>>>>>>>>  495         if(GTKLookAndFeel.is3()) {
>>>>>>>>>  496             if (parent != null && parent.getParent() 
>>>>>>>>> instanceof
>>>>>>>>> JComboBox) {
>>>>>>>>>  497                 if (parent.getParent().hasFocus()) {
>>>>>>>>>  498                     synthState |= SynthConstants.FOCUSED;
>>>>>>>>>  499                 }
>>>>>>>>>  500             }
>>>>>>>>>  501         }
>>>>>>>>>
>>>>>>>>> GTKPainter.java
>>>>>>>>>
>>>>>>>>> 746         if (GTKLookAndFeel.is3()) {
>>>>>>>>>  747             if (slider.getOrientation() == 
>>>>>>>>> JSlider.VERTICAL) {
>>>>>>>>>  748                 y += 1;
>>>>>>>>>  749                 h -= 2;
>>>>>>>>>  750             } else {
>>>>>>>>>  751                 x += 1;
>>>>>>>>>  752                 w -= 2;
>>>>>>>>>  753             }
>>>>>>>>>  754         }
>>>>>>>>>
>>>>>>>>> I don't know where these numbers come from or what coordinate 
>>>>>>>>> system
>>>>>>>>> is being used here but it seems you are changing them for gtk 
>>>>>>>>> 2.2 as
>>>>>>>>> well as 3
>>>>>>>>> Can you speak to this ?
>>>>>>>> It is an appearance tuning for GTK3. I didn't change it for 
>>>>>>>> GTK2, why do
>>>>>>>> you think so?
>>>>>>>> This was used before my fix as well, for example
>>>>>>>>
>>>>>>>>                      if (containerParent instanceof JComboBox) {
>>>>>>>>                          x += (focusSize + 2);
>>>>>>>>                          y += (focusSize + 1);
>>>>>>>>                          w -= (2 * focusSize + 1);
>>>>>>>>                          h -= (2 * focusSize + 2);
>>>>>>>>                      } else {
>>>>>>>>                          x += focusSize;
>>>>>>>>                          y += focusSize;
>>>>>>>>                          w -= 2 * focusSize;
>>>>>>>>                          h -= 2 * focusSize;
>>>>>>>>                      }
>>>>>>>>
>>>>>>>> The only place where I changed the existing GTK2 appearance is:
>>>>>>>>
>>>>>>>> 1121 CLASS_SPECIFIC_MAP.put("Slider.thumbWidth", "slider-length");
>>>>>>>>
>>>>>>>>   in GTKStyle.java, because this property was omitted by mistake.
>>>>>>>>>
>>>>>>>>> GTKStyle.java
>>>>>>>>>
>>>>>>>>> 735         if(!GTKLookAndFeel.is3()) {
>>>>>>>>>
>>>>>>>>> 840      } else if(GTKLookAndFeel.is3() &&
>>>>>>>>> "ComboBox.forceOpaque".equals(key)) {
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> we prefer a space between "if" and "("
>>>>>>>> Accepted.
>>>>>>>>>
>>>>>>>>> sun_awt_X11_GtkFileDialogPeer.c
>>>>>>>>>
>>>>>>>>>  392     if (gtk->gtk_check_version(2, 8, 0) == NULL) {
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Maybe I am not looking at the right fn but I thought I saw
>>>>>>>>> this fn return a boolean so a check against NULL looks wrong.
>>>>>>>> The declaration is in GtkApi struct of gtk_interface.h. It returns
>>>>>>>> char*. NULL means that the version is compatible.
>>>>>>>>>
>>>>>>>>>  393
>>>>>>>>> gtk->gtk_file_chooser_set_do_overwrite_confirmation(GTK_FILE_CHOOSER( 
>>>>>>>>>
>>>>>>>>>  394                 dialog), TRUE);
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> You didn't add this but it is awfully specific about the GTK 
>>>>>>>>> version and
>>>>>>>>> I wonder if this test is doing what it should be doing on GTK 3?
>>>>>>>> Accepted.
>>>>>>>>>
>>>>>>>>> It is interesting that some equivalent looking Java level dialog
>>>>>>>>> checking in XToolkit.java
>>>>>>>>> checked for 3.0 too ..
>>>>>>>>>
>>>>>>>>> swing_GTKEngine.c :
>>>>>>>>>
>>>>>>>>>   30 /* Static buffer for conversion from java.lang.String to 
>>>>>>>>> UTF-8 */
>>>>>>>>>   31 static char convertionBuffer[CONV_BUFFER_SIZE];
>>>>>>>>>
>>>>>>>>> So the variable name should be spelt conversionBuffer.
>>>>>>>> Accepted.
>>>>>>>>>
>>>>>>>>> awt_UNIXToolkit.c
>>>>>>>>>
>>>>>>>>> < 287 free(ret);
>>>>>>>>>
>>>>>>>>> You deleted this free(). Is that correct ? It seems to imply
>>>>>>>>> you now expect a boolean return as discussed above and
>>>>>>>>> so in that case NULL looks odd here (line 260) too.
>>>>>>>> The JNI exported method returns boolean while the GTK method 
>>>>>>>> returns
>>>>>>>> char*. free() is deleted intentionally according to the GTK 
>>>>>>>> docs it
>>>>>>>> belongs to the library and should not be freed by user code.
>>>>>>>>>
>>>>>>>>> gtk3_interface.h :
>>>>>>>>>
>>>>>>>>>   36 #define G_PI 
>>>>>>>>> 3.1415926535897932384626433832795028841971693993751
>>>>>>>>>
>>>>>>>>> I don't think that is completely accurate :-) And I should have
>>>>>>>>> reviewed this yesterday [1].
>>>>>>>> :) This is glib's definition I just copied.
>>>>>>>>
>>>>>>>> --Semyon
>>>>>>>>>
>>>>>>>>> -phil.
>>>>>>>>>
>>>>>>>>> [1] http://www.piday.org/
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On 03/05/2016 01:14 PM, Semyon Sadetsky wrote:
>>>>>>>>>> Hello,
>>>>>>>>>>
>>>>>>>>>> Please review fix for JDK9:
>>>>>>>>>>
>>>>>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8145547
>>>>>>>>>> webrev: http://cr.openjdk.java.net/~ssadetsky/8145547/webrev.00/
>>>>>>>>>>
>>>>>>>>>> The fix contains GTK3 based implementation for Swing GTK LnF, 
>>>>>>>>>> AWT
>>>>>>>>>> FileChooser for Linux and AWT Robot for Linux.
>>>>>>>>>> Also the new system property is added to request specific GTK 
>>>>>>>>>> version
>>>>>>>>>> swing.gtk.version.
>>>>>>>>>>
>>>>>>>>>> --Semyon
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>



From philip.race at oracle.com  Tue Apr  5 18:35:04 2016
From: philip.race at oracle.com (Phil Race)
Date: Tue, 05 Apr 2016 11:35:04 -0700
Subject: <Swing Dev> Review-request for 8145547: JEP 283: [AWT/Swing]
 Conditional support for GTK 3 on Linux
In-Reply-To: <5704010F.2030001@oracle.com>
References: <56DB4C3B.1060902@oracle.com> <56E864DE.4000706@oracle.com>
	<56E99D68.90208@oracle.com> <56EAA99E.2040104@oracle.com>
	<56EAB064.9040403@oracle.com> <56EADE8A.9060508@oracle.com>
	<56EB0C31.20300@oracle.com> <56EBFC4A.3080908@oracle.com>
	<5703F00A.4020000@oracle.com> <5703FBD7.4010200@oracle.com>
	<5704010F.2030001@oracle.com>
Message-ID: <57040558.3040704@oracle.com>

I see. I looked through the newly changed files and it seems fine although
I don't have time to re-apply the updated patch.

-phil.

On 04/05/2016 11:16 AM, Semyon Sadetsky wrote:
> XTaskbarPeer.java, awt_Taskbar.c and awt_Taskbar.h were changed to use 
> the new common gtk_interface.
>
> Glib calls which are necessary for the taskbar module are  added to 
> gtk_interface: g_object_unref(), g_list_append(), g_list_free(), 
> g_list_free_full().
>
> --Semyon
>
>
> On 4/5/2016 8:54 PM, Phil Race wrote:
>> Could you point me to what was updated ?
>>
>> -phil.
>>
>> On 04/05/2016 10:04 AM, Semyon Sadetsky wrote:
>>> The fix is updated because JEP 272 was pushed. JEP 272 has 
>>> dependency on GTK.
>>>
>>> http://cr.openjdk.java.net/~ssadetsky/8145547/webrev.04/
>>>
>>> --Semyon
>>>
>>> On 3/18/2016 4:02 PM, Semyon Sadetsky wrote:
>>>>
>>>>
>>>> On 3/17/2016 10:57 PM, Phil Race wrote:
>>>>> I ran your changes (which included my fix) through jprt and all 
>>>>> Solaris platforms failed as follows :-
>>>>>
>>>>> jdk/src/java.desktop/unix/native/libawt_xawt/awt/sun_awt_X11_GtkFileDialogPeer.c", 
>>>>> line 37: error: typedef redeclared: GtkWindow (E_TYPEDEF_REDECLARED)
>>>>> cc: acomp failed for 
>>>>> jdk/src/java.desktop/unix/native/libawt_xawt/awt/sun_awt_X11_GtkFileDialogPeer.c
>>>>>
>>>> I have fixed the Solaris build: 
>>>> http://cr.openjdk.java.net/~ssadetsky/8145547/webrev.03/.
>>>>
>>>> > gint intval = NULL;
>>>> I think this happens with you specific compiler only. Old 
>>>> gtk2_interface.c always contained the same line.
>>>>
>>>> I ran JPRT with webrev.03. The URL is:
>>>> http://sthjprt.uk.oracle.com/archives/2016/03/2016-03-18-070745.ssadetsk.client/ 
>>>>
>>>> It seem macosx_x64_10.9-product-c2-jdk_math build failed because of 
>>>> another change. (?) Could you help me to interpret the JPRT job 
>>>> status?
>>>>
>>>> --Semyon
>>>>>
>>>>> -phil.
>>>>>
>>>>> On 03/17/2016 09:42 AM, Phil Race wrote:
>>>>>> This reminded me I had not yet tried the build myself.
>>>>>> When I did I not get the error that Sergey did but I got this as 
>>>>>> well :-
>>>>>>
>>>>>> jdk9-client/jdk/src/java.desktop/unix/native/libawt_xawt/awt/gtk3_interface.c: 
>>>>>> In function ?get_integer_property?:
>>>>>> jdk9-client/jdk/src/java.desktop/unix/native/libawt_xawt/awt/gtk3_interface.c:2542:19: 
>>>>>> error: initialization makes integer from pointer without a cast 
>>>>>> [-Werror]
>>>>>> jdk9-client/jdk/src/java.desktop/unix/native/libawt_xawt/awt/gtk3_interface.c: 
>>>>>> In function ?get_boolean_property?:
>>>>>> jdk9-client/jdk/src/java.desktop/unix/native/libawt_xawt/awt/gtk3_interface.c:2549:19: 
>>>>>> error: initialization makes integer from pointer without
>>>>>>
>>>>>> Both lines it complains about were :
>>>>>>
>>>>>>     gint intval = NULL;
>>>>>>
>>>>>> I changed them to
>>>>>>        gint intval = 0;
>>>>>>
>>>>>> I am not using the 'official' compiler, but you really should 
>>>>>> make sure jprt is
>>>>>> happy before confirming the webrev as final - and also fix all of 
>>>>>> these even if
>>>>>> the official compiler does not complain.
>>>>>>
>>>>>> And I did not notice any problems running SwingSet2 with either 
>>>>>> of GTK2 or GTK3
>>>>>> specified. It at least ran fine and clearly picked up different 
>>>>>> versions.
>>>>>>
>>>>>>
>>>>>> -phil.
>>>>>>
>>>>>>
>>>>>> On 03/17/2016 06:25 AM, Semyon Sadetsky wrote:
>>>>>>> The awt_Desktop.c is missed in the webrev.
>>>>>>> Please see the updated one: 
>>>>>>> http://cr.openjdk.java.net/~ssadetsky/8145547/webrev.02/
>>>>>>>
>>>>>>> --Semyon
>>>>>>>
>>>>>>> On 3/17/2016 3:57 PM, Sergey Bylokhov wrote:
>>>>>>>> On 16.03.16 20:52, Semyon Sadetsky wrote:
>>>>>>>>> Hi Phil,
>>>>>>>>>
>>>>>>>>> Thank for review. You will find my reply below in the text.
>>>>>>>>>
>>>>>>>>> The updated webrev is
>>>>>>>>> http://cr.openjdk.java.net/~ssadetsky/8145547/webrev.01/
>>>>>>>>
>>>>>>>> On my system this version fails to build(Ubuntu 15.10 + gcc 
>>>>>>>> 5.2.1):
>>>>>>>>
>>>>>>>> ERROR: Build failed for target 'images' in configuration 
>>>>>>>> 'linux-x86_64-normal-server-release' (exit code 2)
>>>>>>>> === Output from failing command(s) repeated here ===
>>>>>>>> * For target 
>>>>>>>> support_native_java.desktop_libawt_xawt_awt_Desktop.o:
>>>>>>>> /mnt/hgfs/moe/workspaces/jdk/9/client-gate/jdk/src/java.desktop/unix/native/libawt_xawt/xawt/awt_Desktop.c: 
>>>>>>>> In function ?Java_sun_awt_X11_XDesktopPeer_init?:
>>>>>>>> /mnt/hgfs/moe/workspaces/jdk/9/client-gate/jdk/src/java.desktop/unix/native/libawt_xawt/xawt/awt_Desktop.c:46:9: 
>>>>>>>> error: implicit declaration of function ?gtk2_load? 
>>>>>>>> [-Werror=implicit-function-declaration]
>>>>>>>>      if (gtk2_load(env) && gtk2_show_uri_load(env)) {
>>>>>>>>          ^
>>>>>>>> /mnt/hgfs/moe/workspaces/jdk/9/client-gate/jdk/src/java.desktop/unix/native/libawt_xawt/xawt/awt_Desktop.c:46:27: 
>>>>>>>> error: implicit declaration of function ?gtk2_show_uri_load? 
>>>>>>>> [-Werror=implicit-function-declaration]
>>>>>>>>      if (gtk2_load(env) && gtk2_show_uri_load(env)) {
>>>>>>>>                            ^
>>>>>>>> cc1: all warnings being treated as errors
>>>>>>>> === End of repeated output ===
>>>>>>>> === Make failure sequence repeated here ===
>>>>>>>> Awt2dLibraries.gmk:369: recipe for target 
>>>>>>>> '/mnt/hgfs/moe/workspaces/jdk/9/client-gate/build/linux-x86_64-normal-server-release/support/native/java.desktop/libawt_xawt/awt_Desktop.o' 
>>>>>>>> failed
>>>>>>>> make/Main.gmk:175: recipe for target 'java.desktop-libs' failed
>>>>>>>> === End of repeated output ===
>>>>>>>>
>>>>>>>>
>>>>>>>>> It also contains:
>>>>>>>>> - new properties jdk.gtk.version and jdk.gtk.verbose
>>>>>>>>> - appearance tuning for Ubuntu 15 (GTK 3.14). It may require 
>>>>>>>>> more but we
>>>>>>>>> can do this later as a separate bug.
>>>>>>>>> The main implementation was done for Ubuntu 14.05 LTS (GTK 
>>>>>>>>> 3.10) and
>>>>>>>>> then tuned for OEL 7 (GTK 3.8). Each minor GTK version may 
>>>>>>>>> have some
>>>>>>>>> appearance changes.
>>>>>>>>>
>>>>>>>>> On 3/15/2016 10:39 PM, Phil Race wrote:
>>>>>>>>>> There is a lot to read here. I think I need to patch and try 
>>>>>>>>>> it but
>>>>>>>>>> first ...
>>>>>>>>>>
>>>>>>>>>> Two high level questions :
>>>>>>>>>> 1) Have you verified that this behaves properly (or no worse 
>>>>>>>>>> than
>>>>>>>>>> currently) with -Djava.awt.headless=true since Swing components
>>>>>>>>>> are supposed to be able to draw off-screen in headless mode 
>>>>>>>>>> .. and
>>>>>>>>>> yet a dependency on GTK and its dependency on xlibraries 
>>>>>>>>>> seems to mean
>>>>>>>>>> that you can't load GTK in this case.
>>>>>>>>>> BTW I think it may be painful to get them to layout in such a 
>>>>>>>>>> case
>>>>>>>>>> but that's another issue.
>>>>>>>>> I tested it by painting to a BufferedImage. Seems it is enough.
>>>>>>>>>>
>>>>>>>>>> 2) Have you tried a hi-dpi system ?
>>>>>>>>> Yes I have. It is identical to the existing GTK2 based 
>>>>>>>>> appearance.
>>>>>>>>>>
>>>>>>>>>> 3) Have you submitted a JPRT job ? It is essential to know 
>>>>>>>>>> that this
>>>>>>>>>> builds cleanly on the "official" compilation environment.
>>>>>>>>> I will do this before the push. I think it will be OK because 
>>>>>>>>> I did not
>>>>>>>>> use any new C constructs and the new libraries are linked 
>>>>>>>>> dynamically.
>>>>>>>>>> 4)I expect you ran Swingset2 + GTK L&F but have you run any 
>>>>>>>>>> of the
>>>>>>>>>> regression test suite ?
>>>>>>>>> Yes I ran javax/swing tests but many of them fails with GTK2 
>>>>>>>>> as well.
>>>>>>>>> With GTK3 the result was the same except for some unstable 
>>>>>>>>> tests. Unity
>>>>>>>>> desktop has new window decorations like borderless windows 
>>>>>>>>> which are
>>>>>>>>> resized by dragging the outer window shadow, invisible overlay
>>>>>>>>> scrollbars, etc. Many tests written for old window decorations 
>>>>>>>>> fails.
>>>>>>>>>>
>>>>>>>>>> Minor comments :
>>>>>>>>>>
>>>>>>>>>> GTKEngine.java
>>>>>>>>>>
>>>>>>>>>>  494         Container parent = 
>>>>>>>>>> context.getComponent().getParent();
>>>>>>>>>>  495         if(GTKLookAndFeel.is3()) {
>>>>>>>>>>  496             if (parent != null && parent.getParent() 
>>>>>>>>>> instanceof
>>>>>>>>>> JComboBox) {
>>>>>>>>>>  497                 if (parent.getParent().hasFocus()) {
>>>>>>>>>>  498                     synthState |= SynthConstants.FOCUSED;
>>>>>>>>>>  499                 }
>>>>>>>>>>  500             }
>>>>>>>>>>  501         }
>>>>>>>>>>
>>>>>>>>>> GTKPainter.java
>>>>>>>>>>
>>>>>>>>>> 746         if (GTKLookAndFeel.is3()) {
>>>>>>>>>>  747             if (slider.getOrientation() == 
>>>>>>>>>> JSlider.VERTICAL) {
>>>>>>>>>>  748                 y += 1;
>>>>>>>>>>  749                 h -= 2;
>>>>>>>>>>  750             } else {
>>>>>>>>>>  751                 x += 1;
>>>>>>>>>>  752                 w -= 2;
>>>>>>>>>>  753             }
>>>>>>>>>>  754         }
>>>>>>>>>>
>>>>>>>>>> I don't know where these numbers come from or what coordinate 
>>>>>>>>>> system
>>>>>>>>>> is being used here but it seems you are changing them for gtk 
>>>>>>>>>> 2.2 as
>>>>>>>>>> well as 3
>>>>>>>>>> Can you speak to this ?
>>>>>>>>> It is an appearance tuning for GTK3. I didn't change it for 
>>>>>>>>> GTK2, why do
>>>>>>>>> you think so?
>>>>>>>>> This was used before my fix as well, for example
>>>>>>>>>
>>>>>>>>>                      if (containerParent instanceof JComboBox) {
>>>>>>>>>                          x += (focusSize + 2);
>>>>>>>>>                          y += (focusSize + 1);
>>>>>>>>>                          w -= (2 * focusSize + 1);
>>>>>>>>>                          h -= (2 * focusSize + 2);
>>>>>>>>>                      } else {
>>>>>>>>>                          x += focusSize;
>>>>>>>>>                          y += focusSize;
>>>>>>>>>                          w -= 2 * focusSize;
>>>>>>>>>                          h -= 2 * focusSize;
>>>>>>>>>                      }
>>>>>>>>>
>>>>>>>>> The only place where I changed the existing GTK2 appearance is:
>>>>>>>>>
>>>>>>>>> 1121 CLASS_SPECIFIC_MAP.put("Slider.thumbWidth", 
>>>>>>>>> "slider-length");
>>>>>>>>>
>>>>>>>>>   in GTKStyle.java, because this property was omitted by mistake.
>>>>>>>>>>
>>>>>>>>>> GTKStyle.java
>>>>>>>>>>
>>>>>>>>>> 735         if(!GTKLookAndFeel.is3()) {
>>>>>>>>>>
>>>>>>>>>> 840      } else if(GTKLookAndFeel.is3() &&
>>>>>>>>>> "ComboBox.forceOpaque".equals(key)) {
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> we prefer a space between "if" and "("
>>>>>>>>> Accepted.
>>>>>>>>>>
>>>>>>>>>> sun_awt_X11_GtkFileDialogPeer.c
>>>>>>>>>>
>>>>>>>>>>  392     if (gtk->gtk_check_version(2, 8, 0) == NULL) {
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Maybe I am not looking at the right fn but I thought I saw
>>>>>>>>>> this fn return a boolean so a check against NULL looks wrong.
>>>>>>>>> The declaration is in GtkApi struct of gtk_interface.h. It 
>>>>>>>>> returns
>>>>>>>>> char*. NULL means that the version is compatible.
>>>>>>>>>>
>>>>>>>>>>  393
>>>>>>>>>> gtk->gtk_file_chooser_set_do_overwrite_confirmation(GTK_FILE_CHOOSER( 
>>>>>>>>>>
>>>>>>>>>>  394                 dialog), TRUE);
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> You didn't add this but it is awfully specific about the GTK 
>>>>>>>>>> version and
>>>>>>>>>> I wonder if this test is doing what it should be doing on GTK 3?
>>>>>>>>> Accepted.
>>>>>>>>>>
>>>>>>>>>> It is interesting that some equivalent looking Java level dialog
>>>>>>>>>> checking in XToolkit.java
>>>>>>>>>> checked for 3.0 too ..
>>>>>>>>>>
>>>>>>>>>> swing_GTKEngine.c :
>>>>>>>>>>
>>>>>>>>>>   30 /* Static buffer for conversion from java.lang.String to 
>>>>>>>>>> UTF-8 */
>>>>>>>>>>   31 static char convertionBuffer[CONV_BUFFER_SIZE];
>>>>>>>>>>
>>>>>>>>>> So the variable name should be spelt conversionBuffer.
>>>>>>>>> Accepted.
>>>>>>>>>>
>>>>>>>>>> awt_UNIXToolkit.c
>>>>>>>>>>
>>>>>>>>>> < 287 free(ret);
>>>>>>>>>>
>>>>>>>>>> You deleted this free(). Is that correct ? It seems to imply
>>>>>>>>>> you now expect a boolean return as discussed above and
>>>>>>>>>> so in that case NULL looks odd here (line 260) too.
>>>>>>>>> The JNI exported method returns boolean while the GTK method 
>>>>>>>>> returns
>>>>>>>>> char*. free() is deleted intentionally according to the GTK 
>>>>>>>>> docs it
>>>>>>>>> belongs to the library and should not be freed by user code.
>>>>>>>>>>
>>>>>>>>>> gtk3_interface.h :
>>>>>>>>>>
>>>>>>>>>>   36 #define G_PI 
>>>>>>>>>> 3.1415926535897932384626433832795028841971693993751
>>>>>>>>>>
>>>>>>>>>> I don't think that is completely accurate :-) And I should have
>>>>>>>>>> reviewed this yesterday [1].
>>>>>>>>> :) This is glib's definition I just copied.
>>>>>>>>>
>>>>>>>>> --Semyon
>>>>>>>>>>
>>>>>>>>>> -phil.
>>>>>>>>>>
>>>>>>>>>> [1] http://www.piday.org/
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On 03/05/2016 01:14 PM, Semyon Sadetsky wrote:
>>>>>>>>>>> Hello,
>>>>>>>>>>>
>>>>>>>>>>> Please review fix for JDK9:
>>>>>>>>>>>
>>>>>>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8145547
>>>>>>>>>>> webrev: 
>>>>>>>>>>> http://cr.openjdk.java.net/~ssadetsky/8145547/webrev.00/
>>>>>>>>>>>
>>>>>>>>>>> The fix contains GTK3 based implementation for Swing GTK 
>>>>>>>>>>> LnF, AWT
>>>>>>>>>>> FileChooser for Linux and AWT Robot for Linux.
>>>>>>>>>>> Also the new system property is added to request specific 
>>>>>>>>>>> GTK version
>>>>>>>>>>> swing.gtk.version.
>>>>>>>>>>>
>>>>>>>>>>> --Semyon
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>



From alexandr.scherbatiy at oracle.com  Wed Apr  6 07:32:31 2016
From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy)
Date: Wed, 06 Apr 2016 10:32:31 +0300
Subject: <Swing Dev> Review-request for 8145547: JEP 283: [AWT/Swing]
 Conditional support for GTK 3 on Linux
In-Reply-To: <5703F00A.4020000@oracle.com>
References: <56DB4C3B.1060902@oracle.com> <56E864DE.4000706@oracle.com>
	<56E99D68.90208@oracle.com> <56EAA99E.2040104@oracle.com>
	<56EAB064.9040403@oracle.com> <56EADE8A.9060508@oracle.com>
	<56EB0C31.20300@oracle.com> <56EBFC4A.3080908@oracle.com>
	<5703F00A.4020000@oracle.com>
Message-ID: <5704BB8F.2070709@oracle.com>


   The fix looks good to me.

   Thanks,
   Alexandr.

On 4/5/2016 8:04 PM, Semyon Sadetsky wrote:
> The fix is updated because JEP 272 was pushed. JEP 272 has dependency 
> on GTK.
>
> http://cr.openjdk.java.net/~ssadetsky/8145547/webrev.04/
>
> --Semyon
>
> On 3/18/2016 4:02 PM, Semyon Sadetsky wrote:
>>
>>
>> On 3/17/2016 10:57 PM, Phil Race wrote:
>>> I ran your changes (which included my fix) through jprt and all 
>>> Solaris platforms failed as follows :-
>>>
>>> jdk/src/java.desktop/unix/native/libawt_xawt/awt/sun_awt_X11_GtkFileDialogPeer.c", 
>>> line 37: error: typedef redeclared: GtkWindow (E_TYPEDEF_REDECLARED)
>>> cc: acomp failed for 
>>> jdk/src/java.desktop/unix/native/libawt_xawt/awt/sun_awt_X11_GtkFileDialogPeer.c
>>>
>> I have fixed the Solaris build: 
>> http://cr.openjdk.java.net/~ssadetsky/8145547/webrev.03/.
>>
>> > gint intval = NULL;
>> I think this happens with you specific compiler only. Old 
>> gtk2_interface.c always contained the same line.
>>
>> I ran JPRT with webrev.03. The URL is:
>> http://sthjprt.uk.oracle.com/archives/2016/03/2016-03-18-070745.ssadetsk.client/ 
>>
>> It seem macosx_x64_10.9-product-c2-jdk_math build failed because of 
>> another change. (?) Could you help me to interpret the JPRT job status?
>>
>> --Semyon
>>>
>>> -phil.
>>>
>>> On 03/17/2016 09:42 AM, Phil Race wrote:
>>>> This reminded me I had not yet tried the build myself.
>>>> When I did I not get the error that Sergey did but I got this as 
>>>> well :-
>>>>
>>>> jdk9-client/jdk/src/java.desktop/unix/native/libawt_xawt/awt/gtk3_interface.c: 
>>>> In function ?get_integer_property?:
>>>> jdk9-client/jdk/src/java.desktop/unix/native/libawt_xawt/awt/gtk3_interface.c:2542:19: 
>>>> error: initialization makes integer from pointer without a cast 
>>>> [-Werror]
>>>> jdk9-client/jdk/src/java.desktop/unix/native/libawt_xawt/awt/gtk3_interface.c: 
>>>> In function ?get_boolean_property?:
>>>> jdk9-client/jdk/src/java.desktop/unix/native/libawt_xawt/awt/gtk3_interface.c:2549:19: 
>>>> error: initialization makes integer from pointer without
>>>>
>>>> Both lines it complains about were :
>>>>
>>>>     gint intval = NULL;
>>>>
>>>> I changed them to
>>>>        gint intval = 0;
>>>>
>>>> I am not using the 'official' compiler, but you really should make 
>>>> sure jprt is
>>>> happy before confirming the webrev as final - and also fix all of 
>>>> these even if
>>>> the official compiler does not complain.
>>>>
>>>> And I did not notice any problems running SwingSet2 with either of 
>>>> GTK2 or GTK3
>>>> specified. It at least ran fine and clearly picked up different 
>>>> versions.
>>>>
>>>>
>>>> -phil.
>>>>
>>>>
>>>> On 03/17/2016 06:25 AM, Semyon Sadetsky wrote:
>>>>> The awt_Desktop.c is missed in the webrev.
>>>>> Please see the updated one: 
>>>>> http://cr.openjdk.java.net/~ssadetsky/8145547/webrev.02/
>>>>>
>>>>> --Semyon
>>>>>
>>>>> On 3/17/2016 3:57 PM, Sergey Bylokhov wrote:
>>>>>> On 16.03.16 20:52, Semyon Sadetsky wrote:
>>>>>>> Hi Phil,
>>>>>>>
>>>>>>> Thank for review. You will find my reply below in the text.
>>>>>>>
>>>>>>> The updated webrev is
>>>>>>> http://cr.openjdk.java.net/~ssadetsky/8145547/webrev.01/
>>>>>>
>>>>>> On my system this version fails to build(Ubuntu 15.10 + gcc 5.2.1):
>>>>>>
>>>>>> ERROR: Build failed for target 'images' in configuration 
>>>>>> 'linux-x86_64-normal-server-release' (exit code 2)
>>>>>> === Output from failing command(s) repeated here ===
>>>>>> * For target support_native_java.desktop_libawt_xawt_awt_Desktop.o:
>>>>>> /mnt/hgfs/moe/workspaces/jdk/9/client-gate/jdk/src/java.desktop/unix/native/libawt_xawt/xawt/awt_Desktop.c: 
>>>>>> In function ?Java_sun_awt_X11_XDesktopPeer_init?:
>>>>>> /mnt/hgfs/moe/workspaces/jdk/9/client-gate/jdk/src/java.desktop/unix/native/libawt_xawt/xawt/awt_Desktop.c:46:9: 
>>>>>> error: implicit declaration of function ?gtk2_load? 
>>>>>> [-Werror=implicit-function-declaration]
>>>>>>      if (gtk2_load(env) && gtk2_show_uri_load(env)) {
>>>>>>          ^
>>>>>> /mnt/hgfs/moe/workspaces/jdk/9/client-gate/jdk/src/java.desktop/unix/native/libawt_xawt/xawt/awt_Desktop.c:46:27: 
>>>>>> error: implicit declaration of function ?gtk2_show_uri_load? 
>>>>>> [-Werror=implicit-function-declaration]
>>>>>>      if (gtk2_load(env) && gtk2_show_uri_load(env)) {
>>>>>>                            ^
>>>>>> cc1: all warnings being treated as errors
>>>>>> === End of repeated output ===
>>>>>> === Make failure sequence repeated here ===
>>>>>> Awt2dLibraries.gmk:369: recipe for target 
>>>>>> '/mnt/hgfs/moe/workspaces/jdk/9/client-gate/build/linux-x86_64-normal-server-release/support/native/java.desktop/libawt_xawt/awt_Desktop.o' 
>>>>>> failed
>>>>>> make/Main.gmk:175: recipe for target 'java.desktop-libs' failed
>>>>>> === End of repeated output ===
>>>>>>
>>>>>>
>>>>>>> It also contains:
>>>>>>> - new properties jdk.gtk.version and jdk.gtk.verbose
>>>>>>> - appearance tuning for Ubuntu 15 (GTK 3.14). It may require 
>>>>>>> more but we
>>>>>>> can do this later as a separate bug.
>>>>>>> The main implementation was done for Ubuntu 14.05 LTS (GTK 3.10) 
>>>>>>> and
>>>>>>> then tuned for OEL 7 (GTK 3.8). Each minor GTK version may have 
>>>>>>> some
>>>>>>> appearance changes.
>>>>>>>
>>>>>>> On 3/15/2016 10:39 PM, Phil Race wrote:
>>>>>>>> There is a lot to read here. I think I need to patch and try it 
>>>>>>>> but
>>>>>>>> first ...
>>>>>>>>
>>>>>>>> Two high level questions :
>>>>>>>> 1) Have you verified that this behaves properly (or no worse than
>>>>>>>> currently) with -Djava.awt.headless=true since Swing components
>>>>>>>> are supposed to be able to draw off-screen in headless mode .. and
>>>>>>>> yet a dependency on GTK and its dependency on xlibraries seems 
>>>>>>>> to mean
>>>>>>>> that you can't load GTK in this case.
>>>>>>>> BTW I think it may be painful to get them to layout in such a case
>>>>>>>> but that's another issue.
>>>>>>> I tested it by painting to a BufferedImage. Seems it is enough.
>>>>>>>>
>>>>>>>> 2) Have you tried a hi-dpi system ?
>>>>>>> Yes I have. It is identical to the existing GTK2 based appearance.
>>>>>>>>
>>>>>>>> 3) Have you submitted a JPRT job ? It is essential to know that 
>>>>>>>> this
>>>>>>>> builds cleanly on the "official" compilation environment.
>>>>>>> I will do this before the push. I think it will be OK because I 
>>>>>>> did not
>>>>>>> use any new C constructs and the new libraries are linked 
>>>>>>> dynamically.
>>>>>>>> 4)I expect you ran Swingset2 + GTK L&F but have you run any of the
>>>>>>>> regression test suite ?
>>>>>>> Yes I ran javax/swing tests but many of them fails with GTK2 as 
>>>>>>> well.
>>>>>>> With GTK3 the result was the same except for some unstable 
>>>>>>> tests. Unity
>>>>>>> desktop has new window decorations like borderless windows which 
>>>>>>> are
>>>>>>> resized by dragging the outer window shadow, invisible overlay
>>>>>>> scrollbars, etc. Many tests written for old window decorations 
>>>>>>> fails.
>>>>>>>>
>>>>>>>> Minor comments :
>>>>>>>>
>>>>>>>> GTKEngine.java
>>>>>>>>
>>>>>>>>  494         Container parent = 
>>>>>>>> context.getComponent().getParent();
>>>>>>>>  495         if(GTKLookAndFeel.is3()) {
>>>>>>>>  496             if (parent != null && parent.getParent() 
>>>>>>>> instanceof
>>>>>>>> JComboBox) {
>>>>>>>>  497                 if (parent.getParent().hasFocus()) {
>>>>>>>>  498                     synthState |= SynthConstants.FOCUSED;
>>>>>>>>  499                 }
>>>>>>>>  500             }
>>>>>>>>  501         }
>>>>>>>>
>>>>>>>> GTKPainter.java
>>>>>>>>
>>>>>>>> 746         if (GTKLookAndFeel.is3()) {
>>>>>>>>  747             if (slider.getOrientation() == 
>>>>>>>> JSlider.VERTICAL) {
>>>>>>>>  748                 y += 1;
>>>>>>>>  749                 h -= 2;
>>>>>>>>  750             } else {
>>>>>>>>  751                 x += 1;
>>>>>>>>  752                 w -= 2;
>>>>>>>>  753             }
>>>>>>>>  754         }
>>>>>>>>
>>>>>>>> I don't know where these numbers come from or what coordinate 
>>>>>>>> system
>>>>>>>> is being used here but it seems you are changing them for gtk 
>>>>>>>> 2.2 as
>>>>>>>> well as 3
>>>>>>>> Can you speak to this ?
>>>>>>> It is an appearance tuning for GTK3. I didn't change it for 
>>>>>>> GTK2, why do
>>>>>>> you think so?
>>>>>>> This was used before my fix as well, for example
>>>>>>>
>>>>>>>                      if (containerParent instanceof JComboBox) {
>>>>>>>                          x += (focusSize + 2);
>>>>>>>                          y += (focusSize + 1);
>>>>>>>                          w -= (2 * focusSize + 1);
>>>>>>>                          h -= (2 * focusSize + 2);
>>>>>>>                      } else {
>>>>>>>                          x += focusSize;
>>>>>>>                          y += focusSize;
>>>>>>>                          w -= 2 * focusSize;
>>>>>>>                          h -= 2 * focusSize;
>>>>>>>                      }
>>>>>>>
>>>>>>> The only place where I changed the existing GTK2 appearance is:
>>>>>>>
>>>>>>> 1121 CLASS_SPECIFIC_MAP.put("Slider.thumbWidth", "slider-length");
>>>>>>>
>>>>>>>   in GTKStyle.java, because this property was omitted by mistake.
>>>>>>>>
>>>>>>>> GTKStyle.java
>>>>>>>>
>>>>>>>> 735         if(!GTKLookAndFeel.is3()) {
>>>>>>>>
>>>>>>>> 840      } else if(GTKLookAndFeel.is3() &&
>>>>>>>> "ComboBox.forceOpaque".equals(key)) {
>>>>>>>>
>>>>>>>>
>>>>>>>> we prefer a space between "if" and "("
>>>>>>> Accepted.
>>>>>>>>
>>>>>>>> sun_awt_X11_GtkFileDialogPeer.c
>>>>>>>>
>>>>>>>>  392     if (gtk->gtk_check_version(2, 8, 0) == NULL) {
>>>>>>>>
>>>>>>>>
>>>>>>>> Maybe I am not looking at the right fn but I thought I saw
>>>>>>>> this fn return a boolean so a check against NULL looks wrong.
>>>>>>> The declaration is in GtkApi struct of gtk_interface.h. It returns
>>>>>>> char*. NULL means that the version is compatible.
>>>>>>>>
>>>>>>>>  393
>>>>>>>> gtk->gtk_file_chooser_set_do_overwrite_confirmation(GTK_FILE_CHOOSER( 
>>>>>>>>
>>>>>>>>  394                 dialog), TRUE);
>>>>>>>>
>>>>>>>>
>>>>>>>> You didn't add this but it is awfully specific about the GTK 
>>>>>>>> version and
>>>>>>>> I wonder if this test is doing what it should be doing on GTK 3?
>>>>>>> Accepted.
>>>>>>>>
>>>>>>>> It is interesting that some equivalent looking Java level dialog
>>>>>>>> checking in XToolkit.java
>>>>>>>> checked for 3.0 too ..
>>>>>>>>
>>>>>>>> swing_GTKEngine.c :
>>>>>>>>
>>>>>>>>   30 /* Static buffer for conversion from java.lang.String to 
>>>>>>>> UTF-8 */
>>>>>>>>   31 static char convertionBuffer[CONV_BUFFER_SIZE];
>>>>>>>>
>>>>>>>> So the variable name should be spelt conversionBuffer.
>>>>>>> Accepted.
>>>>>>>>
>>>>>>>> awt_UNIXToolkit.c
>>>>>>>>
>>>>>>>> < 287 free(ret);
>>>>>>>>
>>>>>>>> You deleted this free(). Is that correct ? It seems to imply
>>>>>>>> you now expect a boolean return as discussed above and
>>>>>>>> so in that case NULL looks odd here (line 260) too.
>>>>>>> The JNI exported method returns boolean while the GTK method 
>>>>>>> returns
>>>>>>> char*. free() is deleted intentionally according to the GTK docs it
>>>>>>> belongs to the library and should not be freed by user code.
>>>>>>>>
>>>>>>>> gtk3_interface.h :
>>>>>>>>
>>>>>>>>   36 #define G_PI 
>>>>>>>> 3.1415926535897932384626433832795028841971693993751
>>>>>>>>
>>>>>>>> I don't think that is completely accurate :-) And I should have
>>>>>>>> reviewed this yesterday [1].
>>>>>>> :) This is glib's definition I just copied.
>>>>>>>
>>>>>>> --Semyon
>>>>>>>>
>>>>>>>> -phil.
>>>>>>>>
>>>>>>>> [1] http://www.piday.org/
>>>>>>>>
>>>>>>>>
>>>>>>>> On 03/05/2016 01:14 PM, Semyon Sadetsky wrote:
>>>>>>>>> Hello,
>>>>>>>>>
>>>>>>>>> Please review fix for JDK9:
>>>>>>>>>
>>>>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8145547
>>>>>>>>> webrev: http://cr.openjdk.java.net/~ssadetsky/8145547/webrev.00/
>>>>>>>>>
>>>>>>>>> The fix contains GTK3 based implementation for Swing GTK LnF, AWT
>>>>>>>>> FileChooser for Linux and AWT Robot for Linux.
>>>>>>>>> Also the new system property is added to request specific GTK 
>>>>>>>>> version
>>>>>>>>> swing.gtk.version.
>>>>>>>>>
>>>>>>>>> --Semyon
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>



From Sergey.Bylokhov at oracle.com  Wed Apr  6 10:40:45 2016
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Wed, 6 Apr 2016 13:40:45 +0300
Subject: <Swing Dev> [9] Review request for 8136366 Add a public API to
 create a L&F without installation
In-Reply-To: <56FE916D.3010409@oracle.com>
References: <56FCC8B4.1040406@oracle.com> <56FDBBBF.2090308@oracle.com>
	<56FDC191.7030301@oracle.com> <56FE6035.7050806@oracle.com>
	<CAJwKKmYYs7Od94jPqNcmNEkFz2arSSX0-UPN+fK4T0WiW703Qw@mail.gmail.com>
	<56FE716B.6080906@oracle.com> <56FE824B.1070105@oracle.com>
	<56FE916D.3010409@oracle.com>
Message-ID: <5704E7AD.8000902@oracle.com>

Looks fine.

On 01.04.16 18:19, Alexander Scherbatiy wrote:
>
>    Hello,
>
>   Could you review the updated fix:
>     http://cr.openjdk.java.net/~alexsch/8136366/webrev.01
>
>    The UnsupportedLookAndFeelException is thrown from the
> UIManager.createLookAndFeel(className) method for unsupported L&Fs.
>
>    Thanks,
>    Alexandr.
>
> On 01/04/16 18:14, Sergey Bylokhov wrote:
>> On 01.04.16 16:02, Alexander Scherbatiy wrote:
>>>     I see the point that creating non installed system L&F may not have
>>> many sense.
>>
>> I guess we should thinking about supported/unsupported instead of
>> installed/non-installed.
>>
>>>
>>>     One more use case that should be considered is using the
>>> createLookAndFeel(className) method with custom L&Fs.
>>>
>>>     For example someone can have a list with L&F class names which
>>> includes both system and custom L&F.
>>>     Using a class name he wants to check if the given L&F is supported.
>>> Does he need to install the custom L&F first?
>>>     If no, he will need to handle L&Fs differently using
>>> UIManager.createLookAndFeel(className) for system L&Fs and reflection
>>> for custom.
>>
>> Is the new method a "shortcut" for:
>>  - UIManager.setLookAndFeel("com.foo")
>>  - laf = UIManager.getLookAndFeel();
>>  - laf is used...
>> Then probably the new method should work symmetrically to
>> setLookAndFeel() and throw UnsupportedLookAndFeelException()? And if
>> the Laf will be created will means that its state is valid(like
>> uidefaults etc)
>>
>> Small notes:
>> - Should we specify the null behavior?
>> - It is unrelated to current fix, but I wonder why we call newInstance
>> for all incoming classes(we initialize the class and create the
>> instance), and then we cast this new object to LookAndFeel.
>>
>


-- 
Best regards, Sergey.


From avik.niyogi at oracle.com  Wed Apr  6 10:42:37 2016
From: avik.niyogi at oracle.com (Avik Niyogi)
Date: Wed, 6 Apr 2016 16:12:37 +0530
Subject: <Swing Dev> Review Request of 8152492: [macosx swing] double key
	event actions when using Mac menubar
Message-ID: <350CB937-DB61-46D9-A456-47D337E4788A@oracle.com>

Hi All,

Kindly review the bug fix for JDK 9.

Bug:
https://bugs.openjdk.java.net/browse/JDK-8152492 <https://bugs.openjdk.java.net/browse/JDK-8152492>

Webrev:
http://cr.openjdk.java.net/~aniyogi/8152492/webrev.00/ <http://cr.openjdk.java.net/~aniyogi/8152492/webrev.00/>

Issue:
For OSX, having there is provision of non-integrated menubar. for this case, triggering the menu action by key press triggered double action in some cases

Cause:
Due to the use of Shift modifier being a soft modifier in case of mac. For example ?Shift + m? is actually ?M? and ?Shift + ,? is ?<? . 
So such cases can not be used as shortcuts. This needs to be accounted for.
Also, cases where ?Cmd + Shift + c? is used as a shortcut, it should not morph that to a ?Cmd + C? command and should detect c itself.
Also, ?Shift + ?? has no equivalent soft modification and can be taken as a shortcut. This has to be accounted for.

Fix:
All required edge case scenarios for the soft modification of Shift and cases of valid modifiers were taken into account.

With Regards,
Avik Niyogi
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/swing-dev/attachments/20160406/dde8cec5/attachment.html>

From alexandr.scherbatiy at oracle.com  Wed Apr  6 20:23:56 2016
From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy)
Date: Thu, 7 Apr 2016 00:23:56 +0400
Subject: <Swing Dev> [9] Review request for 8132119 Provide public API
 for text related methods in SwingUtilities2
In-Reply-To: <56FD791E.1050707@oracle.com>
References: <55E715A1.3090008@oracle.com> <55E72D3A.60807@oracle.com>
	<55ED586F.5070509@oracle.com> <55F6DC3C.60809@oracle.com>
	<5655D3AB.9050503@oracle.com> <5668051E.7090401@oracle.com>
	<5668E226.5000604@oracle.com> <5669646E.4070305@oracle.com>
	<566986FD.9020207@oracle.com> <5694F0C3.8020203@oracle.com>
	<5695572F.6070709@oracle.com> <56966730.7000701@oracle.com>
	<5698C71A.80703@oracle.com> <56991ED9.5030302@oracle.com>
	<569963B6.2050604@oracle.com> <56A5C40B.7010107@oracle.com>
	<CAM6ZMz8iEFQQtSb_bAVU5eUH=J=HapvKq3+Ana4pPxueJD1bNg@mail.gmail.com>
	<56AB8A94.2070404@oracle.com> <56EC2389.3020507@oracle.com>
	<56F38B0B.3060700@oracle.com> <56F3F13A.9000808@oracle.com>
	<56F3F83C.3010706@oracle.com> <56FD791E.1050707@oracle.com>
Message-ID: <5705705C.2010007@oracle.com>


Hello,

Could you review the updated fix:
   http://cr.openjdk.java.net/~alexsch/8132119/webrev.09

  - TextUIDrawing interface and its default implementaion 
BasicTextUIDrawing class are added
  - font metrics argument description is updated

On 31/03/16 23:23, Phil Race wrote:
> Another webrev where you have to slip past 40_ files to get to the two 
> that really matter :-)
> I would have put SwingUtilities2.java and TextUIDrawing.java as the 
> first files.
    Updated.
>
>
> Some of what I have to say here is more along the lines of things to 
> think
> about rather than things that are wrong .. but there are also maybe 
> some things
> that need to be fixed.
>
> Is javax.swing.plaf really the right package for the new class ?
> I suppose it is for the use by the UI classes so maybe its right.
>
> Should the methods be taking "double" instead of "int" for location ?
> This means the measurement APIs too.
> None of the JDK 1.2 text APIs use ints. That is all 1.0 legacy.
> So if Swing internally wants to use ints that is OK but maybe the API
> should be floating point (double).
   The provided methods use Graphics as argument which only has 
drawString(String, int, int) method.
   If it is possible it is better to add the methods with float 
arguments and Graphics2D later.

> Would that  help hi-dpi at all ?
   The hi-dpi support mostly does not require changes in Swing. What it 
does just scales graphics using default transform from graphics 
configuration.

> I suppose it would add over-head since all the existing code uses int
> and we are no worse off and can add double methods later if we want to.
>
>
> Regarding FontMetrics we need to add a caution that is must be a 
> FontMetrics
> *obtained from the correct font and graphics*.
    Updated.
>
>
>  i.e what about attributes on the font such as "tracking" ?
> or on the graphics such as FRACTIONALMETRICS
> It looks like Swing might already fail if that were used.
>
> Look at this code :-
>
>    public static int stringWidth(JComponent c, FontMetrics fm, String 
> string){
>         if (string == null || string.equals("")) {
>             return 0;
>         }
>         boolean needsTextLayout = ((c != null) &&
> (c.getClientProperty(TextAttribute.NUMERIC_SHAPING) != null));
>         if (needsTextLayout) {
>             synchronized(charsBufferLock) {
>                 int length = syncCharsBuffer(string);
>                 needsTextLayout = isComplexLayout(charsBuffer, 0, 
> length);
>             }
>         }
>         if (needsTextLayout) {
>             TextLayout layout = createTextLayout(c, string,
>                                     fm.getFont(), 
> fm.getFontRenderContext());
>             return (int) layout.getAdvance();
>         } else {
>             return fm.stringWidth(string);
>         }
>     }
>
> The only thing Swing is looking at is one TextAttribute and whether we 
> have complex text.
> That is not enough. This is an existing implementation issue but one 
> we should fix here.
> You need to examine all the methods for similar issues.
   I created an enhancement for this:
     JDK-8153662 
SwingUtilities2.drawString()/getStringWidth()/clipString() should use 
more text attributes
       https://bugs.openjdk.java.net/browse/JDK-8153662
>
> The usage of default methods is worth thinking about.
> There is a significant subjective element to this and I've really 
> thought only myself about
> using them for the case where default methods are useful when you need 
> to extend an
> existing interface.
>
> But I can imagine they may also be handy when someone would typically 
> want to implement
> only one or two out of a larger number in an interface and the default 
> and you for some
> reason don't want to do that with an abstract class (notably you want 
> an other class to
> be able to implement the interface).
>
> So what do I think about the case where the interface is brand new and
> what you've done is more or less implement a concrete class, but it's 
> one that
> can be mixed in to another class ? Is that an appropriate use ?
>
> Maybe the test to pass in that case is whether the default implementation
> is going to be satisfactory for 90% of uses. If they are frequently 
> over-ridden
> it would not be an appropriate use.
   Using this argument it seems if someone wants to implement the 
TextUIDrawing it needs to override all its methods to keep them in sync. 
Because of this I moved the TextUIDrawing implementation to the separate 
javax.swing.plaf.basic.BasicTextUIDrawing class.
>
> Based on that criterion I think it is OK to use here.
>
> Another thought:
> When you add default implementations you should also be on the hook
> for explaining what that does. It is a deeper contract than you would
> otherwise have as an interface and maybe needs to be an @implNote
> or you need to call out the default implementation.
> ie there is what someone must code to satisfy the contract of the
> interface and what is a behaviour in the default method ?
   I added the addition "using text properties and anti-aliasing hints 
from the provided component" description to the BasicTextUIDrawing 
class. There is always a question how many details a method description 
should contain. It is not clear for  me should, for example, the used 
numeric shaper be listed in the description or not? Especially when 
there is an enhancement that the methods implementation should take more 
text attributes  into account.

> Also here is a link to some comments by Brian Goetz on default methods :
>
> http://stackoverflow.com/questions/28681737/java-8-default-methods-as-traits-safe/28684917#28684917 
>
>
>   75      * No character is underlined if the index is negative or 
> greater
>   76      * than the string length {@code (index < 0 || index >= 
> string.length())}
>   77      * or if the char value specified at the given index
>   78      * is in the low-surrogate range.
>
>
> I suppose if you point at the last char and it is a hi-surrogate 
> nothing is underlined in that case either.
>
> But I find the whole writing of this a bit inadequate as if you are 
> going to
> this kind of detail you perhaps also need to say what happens in a 
> complex
> script where what happens is two unicode characters end up as a ligature,
> and/or perhaps you aren't even pointing to a base character.
> Maybe it is in fact over-specified. I see that the implementation draws
> the underline itself rather than delegate to TextLayout. This might
> make sense for performance reasons where it is simple text but some day
> this maybe should be re-examined and so I would not over-specify it.
>
> How about :
> "The underline will be positioned at the base glyph which
> represents the valid char indicated by the index.
> If the char index is not valid or is not the index of a
> valid unicode code point then no underline is drawn"
   Updated.

   Thanks,
   Alexandr.
>
> -phil.
>
>
>
> On 03/24/2016 07:22 AM, Sergey Bylokhov wrote:
>> On 24.03.16 16:52, Alexander Scherbatiy wrote:
>>> On 24/03/16 10:36, Semyon Sadetsky wrote:
>>>> Hi Alexander,
>>>>
>>>> Could you answer one question:
>>>> Why did you choose default interface methods to implement
>>>> TextUIDrawing and not implement them in DefaultTextUIDrawing having
>>>> declarations only in the interface?
>>>> AFAIK the common point of view is default methods should be used
>>>> rarely because they may lead to unreadable code.
>>>>
>>>    The only problem which I know about default methods is multiple
>>> inheritance which has its own solution.
>>
>> What kind of problems? The benefit is obvious: it will not be 
>> necessary to implement all methods if only one of them should be 
>> tweaked.
>>
>>>
>>>    Could you give links to discussion or provide use cases where 
>>> default
>>> methods leads to the unreadable code and show how does it relate to the
>>> TextUIDrawing  implementation?
>>>
>>>    Thanks,
>>>    Alexandr.
>>>> --Semyon
>>>>
>>>> On 3/18/2016 6:49 PM, Alexander Scherbatiy wrote:
>>>>>
>>>>> Could you review the updated fix:
>>>>>   http://cr.openjdk.java.net/~alexsch/8132119/webrev.08/
>>>>>
>>>>>   - Public TextUIDrawing interface is added to the javax.swing.plaf
>>>>> package
>>>>>   - TextUIDrawing methods description does not mention component
>>>>> properties to be more general
>>>>>   - TextUIDrawing methods are made default
>>>>>   - L&F sets an instance of the TextUIDrawing to look and feel
>>>>> defaults using "uiDrawing.text" property
>>>>>   - ComponentUI class is not changed
>>>>>   - Each ComponentUI reads TextUIDrawing from UI defaults
>>>>>   - There is an interesting issue described in
>>>>> http://mail.openjdk.java.net/pipermail/swing-dev/2016-March/005509.html 
>>>>>
>>>>>     which is related to the fact that MetalLabelUI returns a static
>>>>> field from createUI() method.
>>>>>     TitleBorder creates a JLabel but does not put it to any component
>>>>> hierarchy. In this case SwingUtilities.updateComponentTreeUI() method
>>>>> calls MetalLabelUI.uninstallDefaults() on the static metalLabelUI
>>>>> field and sets a new LabelUI for ordinary labels. The TitleBorder
>>>>> label UI is not changed in this case and it still uses the
>>>>> metalLabelUI field which is not initialized.
>>>>>     It seems that other applications can also use components just for
>>>>> drawing and have the same issue.
>>>>>     For this case the textUIDrawing field is not cleared in the
>>>>> uninstallDefaults but just set to a static default value which should
>>>>> not lead to memory leaks.
>>>>>
>>>>>   Thanks,
>>>>>   Alexandr.
>>>>>
>>>>> On 29/01/16 19:51, Alexander Scherbatiy wrote:
>>>>>> On 25/01/16 13:44, Andrej Golovnin wrote:
>>>>>>> Hi Alexandr,
>>>>>>>
>>>>>>>> Could you review the updated fix:
>>>>>>>> http://cr.openjdk.java.net/~alexsch/8132119/webrev.07/
>>>>>>> ....
>>>>>>>> - public TextUIDrawing interface is added to the javax.swing.plaf
>>>>>>>> package
>>>>>>>> - public "TextUIDrawing getTextUIDrawing()" method is added to the
>>>>>>>> ComponentUI class
>>>>>>>> - L&F sets an instance of the TextUIDrawing to look and feel
>>>>>>>> defaults using
>>>>>>>> "uiDrawing.text" property
>>>>>>>> - Look and Feel delegates use the instance of the TextUIDrawing
>>>>>>>> for text
>>>>>>>> drawing and measuring
>>>>>>> Some thoughts on the current design/implementation:
>>>>>>>
>>>>>>> By adding a field to the ComponentUI class the current
>>>>>>> implementation increases
>>>>>>> memory consumption for all Swing applications. And you get the
>>>>>>> feeling that
>>>>>>> there are different implementations of TextUIDrawing per
>>>>>>> ComponentUI instances.
>>>>>>> Personally I can't imagine to have different implementations of
>>>>>>> TextUIDrawing for
>>>>>>> a given LookAndFeel. If I would design/implement it, then I would
>>>>>>> implement it as
>>>>>>> a property of the LookAndFeel class (similar to LayoutStyle) and 
>>>>>>> not
>>>>>>> the ComponentUI.
>>>>>>> Developers can use then the following code to obtain the 
>>>>>>> instance of
>>>>>>> TextUIDrawing:
>>>>>>>
>>>>>>> UIManager.getLookAndFeel().getUIDrawing() // or
>>>>>>> UIManager.getLookAndFeelUIDrawing() // use this static method as a
>>>>>>> short cut for the line above.
>>>>>>   LayoutStyle keeps its instance per App context. The same is for
>>>>>> the LookAndFeel
>>>>>>   when it is got through UIManager.getLookAndFeel() call.
>>>>>>   It means that accessing an instance of a TextUIDrawing will leads
>>>>>> to a time consumption.
>>>>>>
>>>>>>   There are 3 main ways of the SwingUtilities2.drawString(...) 
>>>>>> usage:
>>>>>>   1. ComponentUI classes
>>>>>>   2. Components created in UI (like BasicInternalFrameTitlePane)
>>>>>>   3. Public utilities methods (like 
>>>>>> WindowsGraphicsUtils.paintText())
>>>>>>
>>>>>>   For the cases 1 and 2 it is possible to load and store the
>>>>>> UIDrawing instance during installUI()/updateUI() calls to decrease a
>>>>>> time access to it.
>>>>>>
>>>>>>   For the case 3 it is necessary to get LookAndFeel instance each
>>>>>> time (which is taken from an App context)
>>>>>>   or use the passed JComponent object. It requires to have a public
>>>>>> method and the associated variable for each instance of
>>>>>> JComponent/ComponentUI/... class.
>>>>>>> You can use this methods then in JDK too.
>>>>>>>
>>>>>>> And maybe rename the TextUIDrawing class to just UIDrawing and add
>>>>>>> more useful methods,
>>>>>>> e.g. a method to create a composite font, a method to convert DLUs
>>>>>>> to pixels.
>>>>>>   UIDrawing name may look like it should be used for any UI drawing,
>>>>>> not only for text ones. I am afraid that it can be misleading.
>>>>>>
>>>>>>   Thanks,
>>>>>>   Alexandr.
>>>>>>
>>>>>>>
>>>>>>> Best regards,
>>>>>>> Andrej Golovnin
>>>>>>
>>>>>
>>>>
>>>
>>
>>
>



From semyon.sadetsky at oracle.com  Thu Apr  7 07:20:26 2016
From: semyon.sadetsky at oracle.com (Semyon Sadetsky)
Date: Thu, 7 Apr 2016 10:20:26 +0300
Subject: <Swing Dev> [9] Review request for 8132119 Provide public API
 for text related methods in SwingUtilities2
In-Reply-To: <5705705C.2010007@oracle.com>
References: <55E715A1.3090008@oracle.com> <55E72D3A.60807@oracle.com>
	<55ED586F.5070509@oracle.com> <55F6DC3C.60809@oracle.com>
	<5655D3AB.9050503@oracle.com> <5668051E.7090401@oracle.com>
	<5668E226.5000604@oracle.com> <5669646E.4070305@oracle.com>
	<566986FD.9020207@oracle.com> <5694F0C3.8020203@oracle.com>
	<5695572F.6070709@oracle.com> <56966730.7000701@oracle.com>
	<5698C71A.80703@oracle.com> <56991ED9.5030302@oracle.com>
	<569963B6.2050604@oracle.com> <56A5C40B.7010107@oracle.com>
	<CAM6ZMz8iEFQQtSb_bAVU5eUH=J=HapvKq3+Ana4pPxueJD1bNg@mail.gmail.com>
	<56AB8A94.2070404@oracle.com> <56EC2389.3020507@oracle.com>
	<56F38B0B.3060700@oracle.com> <56F3F13A.9000808@oracle.com>
	<56F3F83C.3010706@oracle.com> <56FD791E.1050707@oracle.com>
	<5705705C.2010007@oracle.com>
Message-ID: <57060A3A.5050601@oracle.com>

Looks good.

--Semyon

On 4/6/2016 11:23 PM, Alexander Scherbatiy wrote:
>
> Hello,
>
> Could you review the updated fix:
>   http://cr.openjdk.java.net/~alexsch/8132119/webrev.09
>
>  - TextUIDrawing interface and its default implementaion 
> BasicTextUIDrawing class are added
>  - font metrics argument description is updated
>
> On 31/03/16 23:23, Phil Race wrote:
>> Another webrev where you have to slip past 40_ files to get to the 
>> two that really matter :-)
>> I would have put SwingUtilities2.java and TextUIDrawing.java as the 
>> first files.
>    Updated.
>>
>>
>> Some of what I have to say here is more along the lines of things to 
>> think
>> about rather than things that are wrong .. but there are also maybe 
>> some things
>> that need to be fixed.
>>
>> Is javax.swing.plaf really the right package for the new class ?
>> I suppose it is for the use by the UI classes so maybe its right.
>>
>> Should the methods be taking "double" instead of "int" for location ?
>> This means the measurement APIs too.
>> None of the JDK 1.2 text APIs use ints. That is all 1.0 legacy.
>> So if Swing internally wants to use ints that is OK but maybe the API
>> should be floating point (double).
>   The provided methods use Graphics as argument which only has 
> drawString(String, int, int) method.
>   If it is possible it is better to add the methods with float 
> arguments and Graphics2D later.
>
>> Would that  help hi-dpi at all ?
>   The hi-dpi support mostly does not require changes in Swing. What it 
> does just scales graphics using default transform from graphics 
> configuration.
>
>> I suppose it would add over-head since all the existing code uses int
>> and we are no worse off and can add double methods later if we want to.
>>
>>
>> Regarding FontMetrics we need to add a caution that is must be a 
>> FontMetrics
>> *obtained from the correct font and graphics*.
>    Updated.
>>
>>
>>  i.e what about attributes on the font such as "tracking" ?
>> or on the graphics such as FRACTIONALMETRICS
>> It looks like Swing might already fail if that were used.
>>
>> Look at this code :-
>>
>>    public static int stringWidth(JComponent c, FontMetrics fm, String 
>> string){
>>         if (string == null || string.equals("")) {
>>             return 0;
>>         }
>>         boolean needsTextLayout = ((c != null) &&
>> (c.getClientProperty(TextAttribute.NUMERIC_SHAPING) != null));
>>         if (needsTextLayout) {
>>             synchronized(charsBufferLock) {
>>                 int length = syncCharsBuffer(string);
>>                 needsTextLayout = isComplexLayout(charsBuffer, 0, 
>> length);
>>             }
>>         }
>>         if (needsTextLayout) {
>>             TextLayout layout = createTextLayout(c, string,
>>                                     fm.getFont(), 
>> fm.getFontRenderContext());
>>             return (int) layout.getAdvance();
>>         } else {
>>             return fm.stringWidth(string);
>>         }
>>     }
>>
>> The only thing Swing is looking at is one TextAttribute and whether 
>> we have complex text.
>> That is not enough. This is an existing implementation issue but one 
>> we should fix here.
>> You need to examine all the methods for similar issues.
>   I created an enhancement for this:
>     JDK-8153662 
> SwingUtilities2.drawString()/getStringWidth()/clipString() should use 
> more text attributes
>       https://bugs.openjdk.java.net/browse/JDK-8153662
>>
>> The usage of default methods is worth thinking about.
>> There is a significant subjective element to this and I've really 
>> thought only myself about
>> using them for the case where default methods are useful when you 
>> need to extend an
>> existing interface.
>>
>> But I can imagine they may also be handy when someone would typically 
>> want to implement
>> only one or two out of a larger number in an interface and the 
>> default and you for some
>> reason don't want to do that with an abstract class (notably you want 
>> an other class to
>> be able to implement the interface).
>>
>> So what do I think about the case where the interface is brand new and
>> what you've done is more or less implement a concrete class, but it's 
>> one that
>> can be mixed in to another class ? Is that an appropriate use ?
>>
>> Maybe the test to pass in that case is whether the default 
>> implementation
>> is going to be satisfactory for 90% of uses. If they are frequently 
>> over-ridden
>> it would not be an appropriate use.
>   Using this argument it seems if someone wants to implement the 
> TextUIDrawing it needs to override all its methods to keep them in 
> sync. Because of this I moved the TextUIDrawing implementation to the 
> separate javax.swing.plaf.basic.BasicTextUIDrawing class.
>>
>> Based on that criterion I think it is OK to use here.
>>
>> Another thought:
>> When you add default implementations you should also be on the hook
>> for explaining what that does. It is a deeper contract than you would
>> otherwise have as an interface and maybe needs to be an @implNote
>> or you need to call out the default implementation.
>> ie there is what someone must code to satisfy the contract of the
>> interface and what is a behaviour in the default method ?
>   I added the addition "using text properties and anti-aliasing hints 
> from the provided component" description to the BasicTextUIDrawing 
> class. There is always a question how many details a method 
> description should contain. It is not clear for me should, for 
> example, the used numeric shaper be listed in the description or not? 
> Especially when there is an enhancement that the methods 
> implementation should take more text attributes  into account.
>
>> Also here is a link to some comments by Brian Goetz on default methods :
>>
>> http://stackoverflow.com/questions/28681737/java-8-default-methods-as-traits-safe/28684917#28684917 
>>
>>
>>   75      * No character is underlined if the index is negative or 
>> greater
>>   76      * than the string length {@code (index < 0 || index >= 
>> string.length())}
>>   77      * or if the char value specified at the given index
>>   78      * is in the low-surrogate range.
>>
>>
>> I suppose if you point at the last char and it is a hi-surrogate 
>> nothing is underlined in that case either.
>>
>> But I find the whole writing of this a bit inadequate as if you are 
>> going to
>> this kind of detail you perhaps also need to say what happens in a 
>> complex
>> script where what happens is two unicode characters end up as a 
>> ligature,
>> and/or perhaps you aren't even pointing to a base character.
>> Maybe it is in fact over-specified. I see that the implementation draws
>> the underline itself rather than delegate to TextLayout. This might
>> make sense for performance reasons where it is simple text but some day
>> this maybe should be re-examined and so I would not over-specify it.
>>
>> How about :
>> "The underline will be positioned at the base glyph which
>> represents the valid char indicated by the index.
>> If the char index is not valid or is not the index of a
>> valid unicode code point then no underline is drawn"
>   Updated.
>
>   Thanks,
>   Alexandr.
>>
>> -phil.
>>
>>
>>
>> On 03/24/2016 07:22 AM, Sergey Bylokhov wrote:
>>> On 24.03.16 16:52, Alexander Scherbatiy wrote:
>>>> On 24/03/16 10:36, Semyon Sadetsky wrote:
>>>>> Hi Alexander,
>>>>>
>>>>> Could you answer one question:
>>>>> Why did you choose default interface methods to implement
>>>>> TextUIDrawing and not implement them in DefaultTextUIDrawing having
>>>>> declarations only in the interface?
>>>>> AFAIK the common point of view is default methods should be used
>>>>> rarely because they may lead to unreadable code.
>>>>>
>>>>    The only problem which I know about default methods is multiple
>>>> inheritance which has its own solution.
>>>
>>> What kind of problems? The benefit is obvious: it will not be 
>>> necessary to implement all methods if only one of them should be 
>>> tweaked.
>>>
>>>>
>>>>    Could you give links to discussion or provide use cases where 
>>>> default
>>>> methods leads to the unreadable code and show how does it relate to 
>>>> the
>>>> TextUIDrawing  implementation?
>>>>
>>>>    Thanks,
>>>>    Alexandr.
>>>>> --Semyon
>>>>>
>>>>> On 3/18/2016 6:49 PM, Alexander Scherbatiy wrote:
>>>>>>
>>>>>> Could you review the updated fix:
>>>>>>   http://cr.openjdk.java.net/~alexsch/8132119/webrev.08/
>>>>>>
>>>>>>   - Public TextUIDrawing interface is added to the javax.swing.plaf
>>>>>> package
>>>>>>   - TextUIDrawing methods description does not mention component
>>>>>> properties to be more general
>>>>>>   - TextUIDrawing methods are made default
>>>>>>   - L&F sets an instance of the TextUIDrawing to look and feel
>>>>>> defaults using "uiDrawing.text" property
>>>>>>   - ComponentUI class is not changed
>>>>>>   - Each ComponentUI reads TextUIDrawing from UI defaults
>>>>>>   - There is an interesting issue described in
>>>>>> http://mail.openjdk.java.net/pipermail/swing-dev/2016-March/005509.html 
>>>>>>
>>>>>>     which is related to the fact that MetalLabelUI returns a static
>>>>>> field from createUI() method.
>>>>>>     TitleBorder creates a JLabel but does not put it to any 
>>>>>> component
>>>>>> hierarchy. In this case SwingUtilities.updateComponentTreeUI() 
>>>>>> method
>>>>>> calls MetalLabelUI.uninstallDefaults() on the static metalLabelUI
>>>>>> field and sets a new LabelUI for ordinary labels. The TitleBorder
>>>>>> label UI is not changed in this case and it still uses the
>>>>>> metalLabelUI field which is not initialized.
>>>>>>     It seems that other applications can also use components just 
>>>>>> for
>>>>>> drawing and have the same issue.
>>>>>>     For this case the textUIDrawing field is not cleared in the
>>>>>> uninstallDefaults but just set to a static default value which 
>>>>>> should
>>>>>> not lead to memory leaks.
>>>>>>
>>>>>>   Thanks,
>>>>>>   Alexandr.
>>>>>>
>>>>>> On 29/01/16 19:51, Alexander Scherbatiy wrote:
>>>>>>> On 25/01/16 13:44, Andrej Golovnin wrote:
>>>>>>>> Hi Alexandr,
>>>>>>>>
>>>>>>>>> Could you review the updated fix:
>>>>>>>>> http://cr.openjdk.java.net/~alexsch/8132119/webrev.07/
>>>>>>>> ....
>>>>>>>>> - public TextUIDrawing interface is added to the javax.swing.plaf
>>>>>>>>> package
>>>>>>>>> - public "TextUIDrawing getTextUIDrawing()" method is added to 
>>>>>>>>> the
>>>>>>>>> ComponentUI class
>>>>>>>>> - L&F sets an instance of the TextUIDrawing to look and feel
>>>>>>>>> defaults using
>>>>>>>>> "uiDrawing.text" property
>>>>>>>>> - Look and Feel delegates use the instance of the TextUIDrawing
>>>>>>>>> for text
>>>>>>>>> drawing and measuring
>>>>>>>> Some thoughts on the current design/implementation:
>>>>>>>>
>>>>>>>> By adding a field to the ComponentUI class the current
>>>>>>>> implementation increases
>>>>>>>> memory consumption for all Swing applications. And you get the
>>>>>>>> feeling that
>>>>>>>> there are different implementations of TextUIDrawing per
>>>>>>>> ComponentUI instances.
>>>>>>>> Personally I can't imagine to have different implementations of
>>>>>>>> TextUIDrawing for
>>>>>>>> a given LookAndFeel. If I would design/implement it, then I would
>>>>>>>> implement it as
>>>>>>>> a property of the LookAndFeel class (similar to LayoutStyle) 
>>>>>>>> and not
>>>>>>>> the ComponentUI.
>>>>>>>> Developers can use then the following code to obtain the 
>>>>>>>> instance of
>>>>>>>> TextUIDrawing:
>>>>>>>>
>>>>>>>> UIManager.getLookAndFeel().getUIDrawing() // or
>>>>>>>> UIManager.getLookAndFeelUIDrawing() // use this static method as a
>>>>>>>> short cut for the line above.
>>>>>>>   LayoutStyle keeps its instance per App context. The same is for
>>>>>>> the LookAndFeel
>>>>>>>   when it is got through UIManager.getLookAndFeel() call.
>>>>>>>   It means that accessing an instance of a TextUIDrawing will leads
>>>>>>> to a time consumption.
>>>>>>>
>>>>>>>   There are 3 main ways of the SwingUtilities2.drawString(...) 
>>>>>>> usage:
>>>>>>>   1. ComponentUI classes
>>>>>>>   2. Components created in UI (like BasicInternalFrameTitlePane)
>>>>>>>   3. Public utilities methods (like 
>>>>>>> WindowsGraphicsUtils.paintText())
>>>>>>>
>>>>>>>   For the cases 1 and 2 it is possible to load and store the
>>>>>>> UIDrawing instance during installUI()/updateUI() calls to 
>>>>>>> decrease a
>>>>>>> time access to it.
>>>>>>>
>>>>>>>   For the case 3 it is necessary to get LookAndFeel instance each
>>>>>>> time (which is taken from an App context)
>>>>>>>   or use the passed JComponent object. It requires to have a public
>>>>>>> method and the associated variable for each instance of
>>>>>>> JComponent/ComponentUI/... class.
>>>>>>>> You can use this methods then in JDK too.
>>>>>>>>
>>>>>>>> And maybe rename the TextUIDrawing class to just UIDrawing and add
>>>>>>>> more useful methods,
>>>>>>>> e.g. a method to create a composite font, a method to convert DLUs
>>>>>>>> to pixels.
>>>>>>>   UIDrawing name may look like it should be used for any UI 
>>>>>>> drawing,
>>>>>>> not only for text ones. I am afraid that it can be misleading.
>>>>>>>
>>>>>>>   Thanks,
>>>>>>>   Alexandr.
>>>>>>>
>>>>>>>>
>>>>>>>> Best regards,
>>>>>>>> Andrej Golovnin
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>>
>>
>



From Sergey.Bylokhov at oracle.com  Thu Apr  7 10:09:13 2016
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Thu, 7 Apr 2016 13:09:13 +0300
Subject: <Swing Dev> [9] Review request for 8132119 Provide public API
 for text related methods in SwingUtilities2
In-Reply-To: <5705705C.2010007@oracle.com>
References: <55E715A1.3090008@oracle.com> <55E72D3A.60807@oracle.com>
	<55ED586F.5070509@oracle.com> <55F6DC3C.60809@oracle.com>
	<5655D3AB.9050503@oracle.com> <5668051E.7090401@oracle.com>
	<5668E226.5000604@oracle.com> <5669646E.4070305@oracle.com>
	<566986FD.9020207@oracle.com> <5694F0C3.8020203@oracle.com>
	<5695572F.6070709@oracle.com> <56966730.7000701@oracle.com>
	<5698C71A.80703@oracle.com> <56991ED9.5030302@oracle.com>
	<569963B6.2050604@oracle.com> <56A5C40B.7010107@oracle.com>
	<CAM6ZMz8iEFQQtSb_bAVU5eUH=J=HapvKq3+Ana4pPxueJD1bNg@mail.gmail.com>
	<56AB8A94.2070404@oracle.com> <56EC2389.3020507@oracle.com>
	<56F38B0B.3060700@oracle.com> <56F3F13A.9000808@oracle.com>
	<56F3F83C.3010706@oracle.com> <56FD791E.1050707@oracle.com>
	<5705705C.2010007@oracle.com>
Message-ID: <570631C9.7090601@oracle.com>

On 06.04.16 23:23, Alexander Scherbatiy wrote:
> Could you review the updated fix:
>    http://cr.openjdk.java.net/~alexsch/8132119/webrev.09

There is tiny typos
TextUIDrawing.getClippedString():
     "@param c the component"
     I guess it should be:
     "@param c the component, may be null"
BasicTextUIDrawing:
     There is no dots at the end of the description of the class.

I am not sure but will javadoc automatically copy the @throws tag from 
the parent tag? For example @throws NullPointerException to 
BasicTextUIDrawing.drawString().

>> But I can imagine they may also be handy when someone would typically
>> want to implement
>> only one or two out of a larger number in an interface and the default
>> and you for some
>> reason don't want to do that with an abstract class (notably you want
>> an other class to
>> be able to implement the interface).
>>
>> So what do I think about the case where the interface is brand new and
>> what you've done is more or less implement a concrete class, but it's
>> one that
>> can be mixed in to another class ? Is that an appropriate use ?
>>
>> Maybe the test to pass in that case is whether the default implementation
>> is going to be satisfactory for 90% of uses. If they are frequently
>> over-ridden
>> it would not be an appropriate use.
>    Using this argument it seems if someone wants to implement the
> TextUIDrawing it needs to override all its methods to keep them in sync.
> Because of this I moved the TextUIDrawing implementation to the separate
> javax.swing.plaf.basic.BasicTextUIDrawing class.

I am fine, just one note. Now we have the interface, and the class 
without any state, and
  - If the users need to implement the only one method, then it will be 
necessary to subclass a BasicTextUIDrawing, which will limit the 
possible class hierarchy.
  - If the user most of the time will need to implement all methods to 
make them in sync he also can override BasicTextUIDrawing, then why we 
need the interface?

>>
>> Based on that criterion I think it is OK to use here.
>>
>> Another thought:
>> When you add default implementations you should also be on the hook
>> for explaining what that does. It is a deeper contract than you would
>> otherwise have as an interface and maybe needs to be an @implNote
>> or you need to call out the default implementation.
>> ie there is what someone must code to satisfy the contract of the
>> interface and what is a behaviour in the default method ?
>    I added the addition "using text properties and anti-aliasing hints
> from the provided component" description to the BasicTextUIDrawing
> class. There is always a question how many details a method description
> should contain. It is not clear for  me should, for example, the used
> numeric shaper be listed in the description or not? Especially when
> there is an enhancement that the methods implementation should take more
> text attributes  into account.
>
>> Also here is a link to some comments by Brian Goetz on default methods :
>>
>> http://stackoverflow.com/questions/28681737/java-8-default-methods-as-traits-safe/28684917#28684917
>>
>>
>>   75      * No character is underlined if the index is negative or
>> greater
>>   76      * than the string length {@code (index < 0 || index >=
>> string.length())}
>>   77      * or if the char value specified at the given index
>>   78      * is in the low-surrogate range.
>>
>>
>> I suppose if you point at the last char and it is a hi-surrogate
>> nothing is underlined in that case either.
>>
>> But I find the whole writing of this a bit inadequate as if you are
>> going to
>> this kind of detail you perhaps also need to say what happens in a
>> complex
>> script where what happens is two unicode characters end up as a ligature,
>> and/or perhaps you aren't even pointing to a base character.
>> Maybe it is in fact over-specified. I see that the implementation draws
>> the underline itself rather than delegate to TextLayout. This might
>> make sense for performance reasons where it is simple text but some day
>> this maybe should be re-examined and so I would not over-specify it.
>>
>> How about :
>> "The underline will be positioned at the base glyph which
>> represents the valid char indicated by the index.
>> If the char index is not valid or is not the index of a
>> valid unicode code point then no underline is drawn"
>    Updated.
>
>    Thanks,
>    Alexandr.
>>
>> -phil.
>>
>>
>>
>> On 03/24/2016 07:22 AM, Sergey Bylokhov wrote:
>>> On 24.03.16 16:52, Alexander Scherbatiy wrote:
>>>> On 24/03/16 10:36, Semyon Sadetsky wrote:
>>>>> Hi Alexander,
>>>>>
>>>>> Could you answer one question:
>>>>> Why did you choose default interface methods to implement
>>>>> TextUIDrawing and not implement them in DefaultTextUIDrawing having
>>>>> declarations only in the interface?
>>>>> AFAIK the common point of view is default methods should be used
>>>>> rarely because they may lead to unreadable code.
>>>>>
>>>>    The only problem which I know about default methods is multiple
>>>> inheritance which has its own solution.
>>>
>>> What kind of problems? The benefit is obvious: it will not be
>>> necessary to implement all methods if only one of them should be
>>> tweaked.
>>>
>>>>
>>>>    Could you give links to discussion or provide use cases where
>>>> default
>>>> methods leads to the unreadable code and show how does it relate to the
>>>> TextUIDrawing  implementation?
>>>>
>>>>    Thanks,
>>>>    Alexandr.
>>>>> --Semyon
>>>>>
>>>>> On 3/18/2016 6:49 PM, Alexander Scherbatiy wrote:
>>>>>>
>>>>>> Could you review the updated fix:
>>>>>>   http://cr.openjdk.java.net/~alexsch/8132119/webrev.08/
>>>>>>
>>>>>>   - Public TextUIDrawing interface is added to the javax.swing.plaf
>>>>>> package
>>>>>>   - TextUIDrawing methods description does not mention component
>>>>>> properties to be more general
>>>>>>   - TextUIDrawing methods are made default
>>>>>>   - L&F sets an instance of the TextUIDrawing to look and feel
>>>>>> defaults using "uiDrawing.text" property
>>>>>>   - ComponentUI class is not changed
>>>>>>   - Each ComponentUI reads TextUIDrawing from UI defaults
>>>>>>   - There is an interesting issue described in
>>>>>> http://mail.openjdk.java.net/pipermail/swing-dev/2016-March/005509.html
>>>>>>
>>>>>>     which is related to the fact that MetalLabelUI returns a static
>>>>>> field from createUI() method.
>>>>>>     TitleBorder creates a JLabel but does not put it to any component
>>>>>> hierarchy. In this case SwingUtilities.updateComponentTreeUI() method
>>>>>> calls MetalLabelUI.uninstallDefaults() on the static metalLabelUI
>>>>>> field and sets a new LabelUI for ordinary labels. The TitleBorder
>>>>>> label UI is not changed in this case and it still uses the
>>>>>> metalLabelUI field which is not initialized.
>>>>>>     It seems that other applications can also use components just for
>>>>>> drawing and have the same issue.
>>>>>>     For this case the textUIDrawing field is not cleared in the
>>>>>> uninstallDefaults but just set to a static default value which should
>>>>>> not lead to memory leaks.
>>>>>>
>>>>>>   Thanks,
>>>>>>   Alexandr.
>>>>>>
>>>>>> On 29/01/16 19:51, Alexander Scherbatiy wrote:
>>>>>>> On 25/01/16 13:44, Andrej Golovnin wrote:
>>>>>>>> Hi Alexandr,
>>>>>>>>
>>>>>>>>> Could you review the updated fix:
>>>>>>>>> http://cr.openjdk.java.net/~alexsch/8132119/webrev.07/
>>>>>>>> ....
>>>>>>>>> - public TextUIDrawing interface is added to the javax.swing.plaf
>>>>>>>>> package
>>>>>>>>> - public "TextUIDrawing getTextUIDrawing()" method is added to the
>>>>>>>>> ComponentUI class
>>>>>>>>> - L&F sets an instance of the TextUIDrawing to look and feel
>>>>>>>>> defaults using
>>>>>>>>> "uiDrawing.text" property
>>>>>>>>> - Look and Feel delegates use the instance of the TextUIDrawing
>>>>>>>>> for text
>>>>>>>>> drawing and measuring
>>>>>>>> Some thoughts on the current design/implementation:
>>>>>>>>
>>>>>>>> By adding a field to the ComponentUI class the current
>>>>>>>> implementation increases
>>>>>>>> memory consumption for all Swing applications. And you get the
>>>>>>>> feeling that
>>>>>>>> there are different implementations of TextUIDrawing per
>>>>>>>> ComponentUI instances.
>>>>>>>> Personally I can't imagine to have different implementations of
>>>>>>>> TextUIDrawing for
>>>>>>>> a given LookAndFeel. If I would design/implement it, then I would
>>>>>>>> implement it as
>>>>>>>> a property of the LookAndFeel class (similar to LayoutStyle) and
>>>>>>>> not
>>>>>>>> the ComponentUI.
>>>>>>>> Developers can use then the following code to obtain the
>>>>>>>> instance of
>>>>>>>> TextUIDrawing:
>>>>>>>>
>>>>>>>> UIManager.getLookAndFeel().getUIDrawing() // or
>>>>>>>> UIManager.getLookAndFeelUIDrawing() // use this static method as a
>>>>>>>> short cut for the line above.
>>>>>>>   LayoutStyle keeps its instance per App context. The same is for
>>>>>>> the LookAndFeel
>>>>>>>   when it is got through UIManager.getLookAndFeel() call.
>>>>>>>   It means that accessing an instance of a TextUIDrawing will leads
>>>>>>> to a time consumption.
>>>>>>>
>>>>>>>   There are 3 main ways of the SwingUtilities2.drawString(...)
>>>>>>> usage:
>>>>>>>   1. ComponentUI classes
>>>>>>>   2. Components created in UI (like BasicInternalFrameTitlePane)
>>>>>>>   3. Public utilities methods (like
>>>>>>> WindowsGraphicsUtils.paintText())
>>>>>>>
>>>>>>>   For the cases 1 and 2 it is possible to load and store the
>>>>>>> UIDrawing instance during installUI()/updateUI() calls to decrease a
>>>>>>> time access to it.
>>>>>>>
>>>>>>>   For the case 3 it is necessary to get LookAndFeel instance each
>>>>>>> time (which is taken from an App context)
>>>>>>>   or use the passed JComponent object. It requires to have a public
>>>>>>> method and the associated variable for each instance of
>>>>>>> JComponent/ComponentUI/... class.
>>>>>>>> You can use this methods then in JDK too.
>>>>>>>>
>>>>>>>> And maybe rename the TextUIDrawing class to just UIDrawing and add
>>>>>>>> more useful methods,
>>>>>>>> e.g. a method to create a composite font, a method to convert DLUs
>>>>>>>> to pixels.
>>>>>>>   UIDrawing name may look like it should be used for any UI drawing,
>>>>>>> not only for text ones. I am afraid that it can be misleading.
>>>>>>>
>>>>>>>   Thanks,
>>>>>>>   Alexandr.
>>>>>>>
>>>>>>>>
>>>>>>>> Best regards,
>>>>>>>> Andrej Golovnin
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>>
>>
>


-- 
Best regards, Sergey.


From semyon.sadetsky at oracle.com  Thu Apr  7 10:20:01 2016
From: semyon.sadetsky at oracle.com (Semyon Sadetsky)
Date: Thu, 7 Apr 2016 13:20:01 +0300
Subject: <Swing Dev> [9] Review request for 8151015: JTextArea.insert()
 does not behave as expected with invalid position
In-Reply-To: <56FAD66F.6010108@oracle.com>
References: <56E6EB5C.7000305@oracle.com> <56E9A0A5.8070102@oracle.com>
	<56F0099E.7050705@oracle.com> <56FAD66F.6010108@oracle.com>
Message-ID: <57063451.4090301@oracle.com>

Hi Phil,

I have found one failed test. My fix adds extra <p> element in the 
HTMLDocument after insert operation.
Looks like the HTMLDocument  ignores the implied character in the 
GapContent while the PlainDocument assume that it exists.
Both classes use the same GapContent code.
So, the fix need to be amended. The solution is to move the length check 
to the AbstractDocument which logic assumes that implied character is 
used in its content (see AbstractDocument#getLength() for example).

The updated webrev: http://cr.openjdk.java.net/~ssadetsky/8151015/webrev.01/
This webrev passes open and closed javax/swing/text/**/* tests.

Also bug4496801.java test is moved to open.

--Semyon

On 3/29/2016 10:24 PM, Phil Race wrote:
> There is actually a test for the previous bug - called 
> bug4496801.java, but it is in closed.
>
> I suggest it be opened as part of this fix.
>
> Also run any (all) related Swing regression tests that might cover 
> this area.
>
> I am a little nervous that since the original fix was 13 years ago 
> that some
> code out there may rely on the 'incorrect' fix by now ..
>
> -phil.
>
>
> On 03/21/2016 07:47 AM, Sergey Bylokhov wrote:
>> Should the test also cover the html based string(and cover the 
>> changes in HTMLDocument)?
>>
>> On 16.03.16 21:06, Alexander Scherbatiy wrote:
>>>
>>> The fix looks good to me.
>>>
>>> Just a small comment: if it is a new test it probably should not 
>>> contain
>>> 1998 year in the copyright.
>>>
>>> Thanks,
>>> Alexandr.
>>>
>>> On 14/03/16 20:48, Semyon Sadetsky wrote:
>>>> Hello,
>>>>
>>>> Please review fix for JDK9:
>>>>
>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8151015
>>>> webrev: http://cr.openjdk.java.net/~ssadetsky/8151015/webrev.00/
>>>>
>>>> It is regression of 4496801. The fix for 4496801 was wrong and the
>>>> correct fix should be taking into account the implied character at the
>>>> end of the document. Reverting 4496801 fixes 8151015. Also the correct
>>>> fix for 4496801 is provided.
>>>>
>>>> --Semyon
>>>
>>
>>
>

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

From alexandr.scherbatiy at oracle.com  Thu Apr  7 14:07:25 2016
From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy)
Date: Thu, 7 Apr 2016 18:07:25 +0400
Subject: <Swing Dev> [9] Review request for 8132119 Provide public API
 for text related methods in SwingUtilities2
In-Reply-To: <570631C9.7090601@oracle.com>
References: <55E715A1.3090008@oracle.com> <55E72D3A.60807@oracle.com>
	<55ED586F.5070509@oracle.com> <55F6DC3C.60809@oracle.com>
	<5655D3AB.9050503@oracle.com> <5668051E.7090401@oracle.com>
	<5668E226.5000604@oracle.com> <5669646E.4070305@oracle.com>
	<566986FD.9020207@oracle.com> <5694F0C3.8020203@oracle.com>
	<5695572F.6070709@oracle.com> <56966730.7000701@oracle.com>
	<5698C71A.80703@oracle.com> <56991ED9.5030302@oracle.com>
	<569963B6.2050604@oracle.com> <56A5C40B.7010107@oracle.com>
	<CAM6ZMz8iEFQQtSb_bAVU5eUH=J=HapvKq3+Ana4pPxueJD1bNg@mail.gmail.com>
	<56AB8A94.2070404@oracle.com> <56EC2389.3020507@oracle.com>
	<56F38B0B.3060700@oracle.com> <56F3F13A.9000808@oracle.com>
	<56F3F83C.3010706@oracle.com> <56FD791E.1050707@oracle.com>
	<5705705C.2010007@oracle.com> <570631C9.7090601@oracle.com>
Message-ID: <5706699D.5030904@oracle.com>


   Hello,

   Could you review the updated fix:
     http://cr.openjdk.java.net/~alexsch/8132119/webrev.10

On 07/04/16 14:09, Sergey Bylokhov wrote:
> On 06.04.16 23:23, Alexander Scherbatiy wrote:
>> Could you review the updated fix:
>>    http://cr.openjdk.java.net/~alexsch/8132119/webrev.09
>
> There is tiny typos
> TextUIDrawing.getClippedString():
>     "@param c the component"
>     I guess it should be:
>     "@param c the component, may be null"
   Updated.
> BasicTextUIDrawing:
>     There is no dots at the end of the description of the class.
>
> I am not sure but will javadoc automatically copy the @throws tag from 
> the parent tag? For example @throws NullPointerException to 
> BasicTextUIDrawing.drawString().

    I added throws NPE to the BasicTextUIDrawing class methods. It 
forces copying @throws tag from the parent javadoc.

   Thanks,
   Alexandr.
>
>>> But I can imagine they may also be handy when someone would typically
>>> want to implement
>>> only one or two out of a larger number in an interface and the default
>>> and you for some
>>> reason don't want to do that with an abstract class (notably you want
>>> an other class to
>>> be able to implement the interface).
>>>
>>> So what do I think about the case where the interface is brand new and
>>> what you've done is more or less implement a concrete class, but it's
>>> one that
>>> can be mixed in to another class ? Is that an appropriate use ?
>>>
>>> Maybe the test to pass in that case is whether the default 
>>> implementation
>>> is going to be satisfactory for 90% of uses. If they are frequently
>>> over-ridden
>>> it would not be an appropriate use.
>>    Using this argument it seems if someone wants to implement the
>> TextUIDrawing it needs to override all its methods to keep them in sync.
>> Because of this I moved the TextUIDrawing implementation to the separate
>> javax.swing.plaf.basic.BasicTextUIDrawing class.
>
> I am fine, just one note. Now we have the interface, and the class 
> without any state, and
>  - If the users need to implement the only one method, then it will be 
> necessary to subclass a BasicTextUIDrawing, which will limit the 
> possible class hierarchy.
>  - If the user most of the time will need to implement all methods to 
> make them in sync he also can override BasicTextUIDrawing, then why we 
> need the interface?
>
>>>
>>> Based on that criterion I think it is OK to use here.
>>>
>>> Another thought:
>>> When you add default implementations you should also be on the hook
>>> for explaining what that does. It is a deeper contract than you would
>>> otherwise have as an interface and maybe needs to be an @implNote
>>> or you need to call out the default implementation.
>>> ie there is what someone must code to satisfy the contract of the
>>> interface and what is a behaviour in the default method ?
>>    I added the addition "using text properties and anti-aliasing hints
>> from the provided component" description to the BasicTextUIDrawing
>> class. There is always a question how many details a method description
>> should contain. It is not clear for  me should, for example, the used
>> numeric shaper be listed in the description or not? Especially when
>> there is an enhancement that the methods implementation should take more
>> text attributes  into account.
>>
>>> Also here is a link to some comments by Brian Goetz on default 
>>> methods :
>>>
>>> http://stackoverflow.com/questions/28681737/java-8-default-methods-as-traits-safe/28684917#28684917 
>>>
>>>
>>>
>>>   75      * No character is underlined if the index is negative or
>>> greater
>>>   76      * than the string length {@code (index < 0 || index >=
>>> string.length())}
>>>   77      * or if the char value specified at the given index
>>>   78      * is in the low-surrogate range.
>>>
>>>
>>> I suppose if you point at the last char and it is a hi-surrogate
>>> nothing is underlined in that case either.
>>>
>>> But I find the whole writing of this a bit inadequate as if you are
>>> going to
>>> this kind of detail you perhaps also need to say what happens in a
>>> complex
>>> script where what happens is two unicode characters end up as a 
>>> ligature,
>>> and/or perhaps you aren't even pointing to a base character.
>>> Maybe it is in fact over-specified. I see that the implementation draws
>>> the underline itself rather than delegate to TextLayout. This might
>>> make sense for performance reasons where it is simple text but some day
>>> this maybe should be re-examined and so I would not over-specify it.
>>>
>>> How about :
>>> "The underline will be positioned at the base glyph which
>>> represents the valid char indicated by the index.
>>> If the char index is not valid or is not the index of a
>>> valid unicode code point then no underline is drawn"
>>    Updated.
>>
>>    Thanks,
>>    Alexandr.
>>>
>>> -phil.
>>>
>>>
>>>
>>> On 03/24/2016 07:22 AM, Sergey Bylokhov wrote:
>>>> On 24.03.16 16:52, Alexander Scherbatiy wrote:
>>>>> On 24/03/16 10:36, Semyon Sadetsky wrote:
>>>>>> Hi Alexander,
>>>>>>
>>>>>> Could you answer one question:
>>>>>> Why did you choose default interface methods to implement
>>>>>> TextUIDrawing and not implement them in DefaultTextUIDrawing having
>>>>>> declarations only in the interface?
>>>>>> AFAIK the common point of view is default methods should be used
>>>>>> rarely because they may lead to unreadable code.
>>>>>>
>>>>>    The only problem which I know about default methods is multiple
>>>>> inheritance which has its own solution.
>>>>
>>>> What kind of problems? The benefit is obvious: it will not be
>>>> necessary to implement all methods if only one of them should be
>>>> tweaked.
>>>>
>>>>>
>>>>>    Could you give links to discussion or provide use cases where
>>>>> default
>>>>> methods leads to the unreadable code and show how does it relate 
>>>>> to the
>>>>> TextUIDrawing  implementation?
>>>>>
>>>>>    Thanks,
>>>>>    Alexandr.
>>>>>> --Semyon
>>>>>>
>>>>>> On 3/18/2016 6:49 PM, Alexander Scherbatiy wrote:
>>>>>>>
>>>>>>> Could you review the updated fix:
>>>>>>> http://cr.openjdk.java.net/~alexsch/8132119/webrev.08/
>>>>>>>
>>>>>>>   - Public TextUIDrawing interface is added to the javax.swing.plaf
>>>>>>> package
>>>>>>>   - TextUIDrawing methods description does not mention component
>>>>>>> properties to be more general
>>>>>>>   - TextUIDrawing methods are made default
>>>>>>>   - L&F sets an instance of the TextUIDrawing to look and feel
>>>>>>> defaults using "uiDrawing.text" property
>>>>>>>   - ComponentUI class is not changed
>>>>>>>   - Each ComponentUI reads TextUIDrawing from UI defaults
>>>>>>>   - There is an interesting issue described in
>>>>>>> http://mail.openjdk.java.net/pipermail/swing-dev/2016-March/005509.html 
>>>>>>>
>>>>>>>
>>>>>>>     which is related to the fact that MetalLabelUI returns a static
>>>>>>> field from createUI() method.
>>>>>>>     TitleBorder creates a JLabel but does not put it to any 
>>>>>>> component
>>>>>>> hierarchy. In this case SwingUtilities.updateComponentTreeUI() 
>>>>>>> method
>>>>>>> calls MetalLabelUI.uninstallDefaults() on the static metalLabelUI
>>>>>>> field and sets a new LabelUI for ordinary labels. The TitleBorder
>>>>>>> label UI is not changed in this case and it still uses the
>>>>>>> metalLabelUI field which is not initialized.
>>>>>>>     It seems that other applications can also use components 
>>>>>>> just for
>>>>>>> drawing and have the same issue.
>>>>>>>     For this case the textUIDrawing field is not cleared in the
>>>>>>> uninstallDefaults but just set to a static default value which 
>>>>>>> should
>>>>>>> not lead to memory leaks.
>>>>>>>
>>>>>>>   Thanks,
>>>>>>>   Alexandr.
>>>>>>>
>>>>>>> On 29/01/16 19:51, Alexander Scherbatiy wrote:
>>>>>>>> On 25/01/16 13:44, Andrej Golovnin wrote:
>>>>>>>>> Hi Alexandr,
>>>>>>>>>
>>>>>>>>>> Could you review the updated fix:
>>>>>>>>>> http://cr.openjdk.java.net/~alexsch/8132119/webrev.07/
>>>>>>>>> ....
>>>>>>>>>> - public TextUIDrawing interface is added to the 
>>>>>>>>>> javax.swing.plaf
>>>>>>>>>> package
>>>>>>>>>> - public "TextUIDrawing getTextUIDrawing()" method is added 
>>>>>>>>>> to the
>>>>>>>>>> ComponentUI class
>>>>>>>>>> - L&F sets an instance of the TextUIDrawing to look and feel
>>>>>>>>>> defaults using
>>>>>>>>>> "uiDrawing.text" property
>>>>>>>>>> - Look and Feel delegates use the instance of the TextUIDrawing
>>>>>>>>>> for text
>>>>>>>>>> drawing and measuring
>>>>>>>>> Some thoughts on the current design/implementation:
>>>>>>>>>
>>>>>>>>> By adding a field to the ComponentUI class the current
>>>>>>>>> implementation increases
>>>>>>>>> memory consumption for all Swing applications. And you get the
>>>>>>>>> feeling that
>>>>>>>>> there are different implementations of TextUIDrawing per
>>>>>>>>> ComponentUI instances.
>>>>>>>>> Personally I can't imagine to have different implementations of
>>>>>>>>> TextUIDrawing for
>>>>>>>>> a given LookAndFeel. If I would design/implement it, then I would
>>>>>>>>> implement it as
>>>>>>>>> a property of the LookAndFeel class (similar to LayoutStyle) and
>>>>>>>>> not
>>>>>>>>> the ComponentUI.
>>>>>>>>> Developers can use then the following code to obtain the
>>>>>>>>> instance of
>>>>>>>>> TextUIDrawing:
>>>>>>>>>
>>>>>>>>> UIManager.getLookAndFeel().getUIDrawing() // or
>>>>>>>>> UIManager.getLookAndFeelUIDrawing() // use this static method 
>>>>>>>>> as a
>>>>>>>>> short cut for the line above.
>>>>>>>>   LayoutStyle keeps its instance per App context. The same is for
>>>>>>>> the LookAndFeel
>>>>>>>>   when it is got through UIManager.getLookAndFeel() call.
>>>>>>>>   It means that accessing an instance of a TextUIDrawing will 
>>>>>>>> leads
>>>>>>>> to a time consumption.
>>>>>>>>
>>>>>>>>   There are 3 main ways of the SwingUtilities2.drawString(...)
>>>>>>>> usage:
>>>>>>>>   1. ComponentUI classes
>>>>>>>>   2. Components created in UI (like BasicInternalFrameTitlePane)
>>>>>>>>   3. Public utilities methods (like
>>>>>>>> WindowsGraphicsUtils.paintText())
>>>>>>>>
>>>>>>>>   For the cases 1 and 2 it is possible to load and store the
>>>>>>>> UIDrawing instance during installUI()/updateUI() calls to 
>>>>>>>> decrease a
>>>>>>>> time access to it.
>>>>>>>>
>>>>>>>>   For the case 3 it is necessary to get LookAndFeel instance each
>>>>>>>> time (which is taken from an App context)
>>>>>>>>   or use the passed JComponent object. It requires to have a 
>>>>>>>> public
>>>>>>>> method and the associated variable for each instance of
>>>>>>>> JComponent/ComponentUI/... class.
>>>>>>>>> You can use this methods then in JDK too.
>>>>>>>>>
>>>>>>>>> And maybe rename the TextUIDrawing class to just UIDrawing and 
>>>>>>>>> add
>>>>>>>>> more useful methods,
>>>>>>>>> e.g. a method to create a composite font, a method to convert 
>>>>>>>>> DLUs
>>>>>>>>> to pixels.
>>>>>>>>   UIDrawing name may look like it should be used for any UI 
>>>>>>>> drawing,
>>>>>>>> not only for text ones. I am afraid that it can be misleading.
>>>>>>>>
>>>>>>>>   Thanks,
>>>>>>>>   Alexandr.
>>>>>>>>
>>>>>>>>>
>>>>>>>>> Best regards,
>>>>>>>>> Andrej Golovnin
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>>
>>>
>>
>
>



From Sergey.Bylokhov at oracle.com  Fri Apr  8 10:49:02 2016
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Fri, 8 Apr 2016 13:49:02 +0300
Subject: <Swing Dev> Review-request for 8145547: JEP 283: [AWT/Swing]
 Conditional support for GTK 3 on Linux
In-Reply-To: <56F05BB5.2080209@oracle.com>
References: <56DB4C3B.1060902@oracle.com> <56E864DE.4000706@oracle.com>
	<56E99D68.90208@oracle.com> <56EA9929.9020605@oracle.com>
	<56EBF688.1090006@oracle.com> <56ED7507.1090204@oracle.com>
	<56EFF685.1090702@oracle.com> <56EFFC8A.1010306@oracle.com>
	<56F044BF.2000609@oracle.com> <56F0498A.4090802@oracle.com>
	<56F04BBD.1030102@oracle.com> <56F051FD.3000203@oracle.com>
	<56F05BB5.2080209@oracle.com>
Message-ID: <57078C9E.2080409@oracle.com>

On 21.03.16 23:38, Semyon Sadetsky wrote:
>> This does not solve the problem when check/init/load will try to use
>> the different versions. I guess I provided enough arguments to
>> initialize these data only once.
> I've already explained that GTK library cannot be loaded twice, only one
> version may be loaded regardless of the property value.

We already found that there is a problem in synchronization, there is 
some other cases, which can be introduced in the future. To eliminate 
even the possibility of such missconfigurationion, it would be better 
try to load only the one version which was set by "jdk.gtk.version" for 
the first time. It will solve bunch of possible issues.

>> It will be better to make it obvious and not to depends on some order.
>> I am curious where you find it widely used. At least in the client I
>> found only one usage.
> I can help you. Look at GTKEngine.java: WidgetType, StateType, Settings,
> ShadowType, Orientation, PositionType, etc...

Thanks, this all in one file of gtk look and feel. This is a bad 
pattern, and we should not copy it to the UnixToolkit class. For 
additional information read the spec of ordinal method and "Effective 
Java" by Josh Bloch Item 31.

Also I am not sure that I understand where we survive the hang which can 
occur if we try to load the gtk library if it was loaded before by the 
other applications(like fx or swt).

-- 
Best regards, Sergey.


From Sergey.Bylokhov at oracle.com  Fri Apr  8 12:01:51 2016
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Fri, 8 Apr 2016 15:01:51 +0300
Subject: <Swing Dev> [9] Review Request: 6832045
 DefaultSynthStyle.{getStateInfo, getMatchCount) should use Integer.bitCount
Message-ID: <57079DAF.6030401@oracle.com>

Hello,
Please review the small cleanup for jdk9.

The code which was copied from BigInteger.bitCnt() replaced by 
Integer.bitCount().
Note that this code is removed from BigInteger class itself and also 
replaced by Integer.bitCount [1].

The getMatchCount() method is removed, because initially(long ago) it 
was used in place which was changed in the fix. But now it is unused.

[1] http://hg.openjdk.java.net/jdk9/client/jdk/rev/8d2efec31d78

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

-- 
Best regards, Sergey.


From alexandr.scherbatiy at oracle.com  Fri Apr  8 12:59:16 2016
From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy)
Date: Fri, 8 Apr 2016 16:59:16 +0400
Subject: <Swing Dev> [9] Review Request: 6832045
 DefaultSynthStyle.{getStateInfo, getMatchCount) should use Integer.bitCount
In-Reply-To: <57079DAF.6030401@oracle.com>
References: <57079DAF.6030401@oracle.com>
Message-ID: <5707AB24.1000308@oracle.com>


The fix looks good to me.

Thanks,
Alexandr.

On 08/04/16 16:01, Sergey Bylokhov wrote:
> Hello,
> Please review the small cleanup for jdk9.
>
> The code which was copied from BigInteger.bitCnt() replaced by 
> Integer.bitCount().
> Note that this code is removed from BigInteger class itself and also 
> replaced by Integer.bitCount [1].
>
> The getMatchCount() method is removed, because initially(long ago) it 
> was used in place which was changed in the fix. But now it is unused.
>
> [1] http://hg.openjdk.java.net/jdk9/client/jdk/rev/8d2efec31d78
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-6832045
> Webrev can be found at: 
> http://cr.openjdk.java.net/~serb/6832045/webrev.00
>



From Sergey.Bylokhov at oracle.com  Fri Apr  8 14:45:29 2016
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Fri, 8 Apr 2016 17:45:29 +0300
Subject: <Swing Dev> Review Request of 8152492: [macosx swing] double
 key event actions when using Mac menubar
In-Reply-To: <350CB937-DB61-46D9-A456-47D337E4788A@oracle.com>
References: <350CB937-DB61-46D9-A456-47D337E4788A@oracle.com>
Message-ID: <5707C409.4030702@oracle.com>

Hi, Avik.
It seems there is one more bug in this "if".
Change the input source to "Hindi Dev.."/"Russian.." then this test 
fails anyway(it will produce the double action).
Moreover if I change the source input to Hindi Transliteration, the test 
sometimes crashed.
Please double check.

On 06.04.16 13:42, Avik Niyogi wrote:
> Hi All,
>
> Kindly review the bug fix for JDK 9.
>
> *Bug:*
> https://bugs.openjdk.java.net/browse/JDK-8152492
>
> *Webrev:*
> http://cr.openjdk.java.net/~aniyogi/8152492/webrev.00/
>
> *Issue:*
> For OSX, having there is provision of non-integrated menubar. for this
> case, triggering the menu action by key press triggered double action in
> some cases
>
> *Cause:*
> Due to the use of Shift modifier being a soft modifier in case of mac.
> For example ?Shift + m? is actually ?M? and ?Shift + ,? is ?<? .
> So such cases can not be used as shortcuts. This needs to be accounted for.
> Also, cases where ?Cmd + Shift + c? is used as a shortcut, it should not
> morph that to a ?Cmd + C? command and should detect c itself.
> Also, ?Shift + ?? has no equivalent soft modification and can be taken
> as a shortcut. This has to be accounted for.
>
> *Fix:*
> All required edge case scenarios for the soft modification of Shift and
> cases of valid modifiers were taken into account.
>
> With Regards,
> Avik Niyogi


-- 
Best regards, Sergey.


From semyon.sadetsky at oracle.com  Fri Apr  8 17:03:22 2016
From: semyon.sadetsky at oracle.com (Semyon Sadetsky)
Date: Fri, 8 Apr 2016 20:03:22 +0300
Subject: <Swing Dev> Review-request for 8145547: JEP 283: [AWT/Swing]
 Conditional support for GTK 3 on Linux
In-Reply-To: <5704BB8F.2070709@oracle.com>
References: <56DB4C3B.1060902@oracle.com> <56E864DE.4000706@oracle.com>
	<56E99D68.90208@oracle.com> <56EAA99E.2040104@oracle.com>
	<56EAB064.9040403@oracle.com> <56EADE8A.9060508@oracle.com>
	<56EB0C31.20300@oracle.com> <56EBFC4A.3080908@oracle.com>
	<5703F00A.4020000@oracle.com> <5704BB8F.2070709@oracle.com>
Message-ID: <5707E45A.6070008@oracle.com>

The fix was updated to take into account defects discovered by parfait:

(*env)->ExceptionCheck(env); is removed from the 
gtk3_get_drawable_data() in gtk2_interface.c and gtk3_interface.c 
because GetPrimitiveArrayCritical()/ ReleasePrimitiveArrayCritical() do 
not throw exceptions.

xx and yy variables in the gtk3_paint_arrow() of gtk3_interface.c might 
not be initialized.

The updated webrev: http://cr.openjdk.java.net/~ssadetsky/8145547/webrev.05/

--Semyon


On 4/6/2016 10:32 AM, Alexander Scherbatiy wrote:
>
>   The fix looks good to me.
>
>   Thanks,
>   Alexandr.
>
> On 4/5/2016 8:04 PM, Semyon Sadetsky wrote:
>> The fix is updated because JEP 272 was pushed. JEP 272 has dependency 
>> on GTK.
>>
>> http://cr.openjdk.java.net/~ssadetsky/8145547/webrev.04/
>>
>> --Semyon
>>
>> On 3/18/2016 4:02 PM, Semyon Sadetsky wrote:
>>>
>>>
>>> On 3/17/2016 10:57 PM, Phil Race wrote:
>>>> I ran your changes (which included my fix) through jprt and all 
>>>> Solaris platforms failed as follows :-
>>>>
>>>> jdk/src/java.desktop/unix/native/libawt_xawt/awt/sun_awt_X11_GtkFileDialogPeer.c", 
>>>> line 37: error: typedef redeclared: GtkWindow (E_TYPEDEF_REDECLARED)
>>>> cc: acomp failed for 
>>>> jdk/src/java.desktop/unix/native/libawt_xawt/awt/sun_awt_X11_GtkFileDialogPeer.c
>>>>
>>> I have fixed the Solaris build: 
>>> http://cr.openjdk.java.net/~ssadetsky/8145547/webrev.03/.
>>>
>>> > gint intval = NULL;
>>> I think this happens with you specific compiler only. Old 
>>> gtk2_interface.c always contained the same line.
>>>
>>> I ran JPRT with webrev.03. The URL is:
>>> http://sthjprt.uk.oracle.com/archives/2016/03/2016-03-18-070745.ssadetsk.client/ 
>>>
>>> It seem macosx_x64_10.9-product-c2-jdk_math build failed because of 
>>> another change. (?) Could you help me to interpret the JPRT job status?
>>>
>>> --Semyon
>>>>
>>>> -phil.
>>>>
>>>> On 03/17/2016 09:42 AM, Phil Race wrote:
>>>>> This reminded me I had not yet tried the build myself.
>>>>> When I did I not get the error that Sergey did but I got this as 
>>>>> well :-
>>>>>
>>>>> jdk9-client/jdk/src/java.desktop/unix/native/libawt_xawt/awt/gtk3_interface.c: 
>>>>> In function ?get_integer_property?:
>>>>> jdk9-client/jdk/src/java.desktop/unix/native/libawt_xawt/awt/gtk3_interface.c:2542:19: 
>>>>> error: initialization makes integer from pointer without a cast 
>>>>> [-Werror]
>>>>> jdk9-client/jdk/src/java.desktop/unix/native/libawt_xawt/awt/gtk3_interface.c: 
>>>>> In function ?get_boolean_property?:
>>>>> jdk9-client/jdk/src/java.desktop/unix/native/libawt_xawt/awt/gtk3_interface.c:2549:19: 
>>>>> error: initialization makes integer from pointer without
>>>>>
>>>>> Both lines it complains about were :
>>>>>
>>>>>     gint intval = NULL;
>>>>>
>>>>> I changed them to
>>>>>        gint intval = 0;
>>>>>
>>>>> I am not using the 'official' compiler, but you really should make 
>>>>> sure jprt is
>>>>> happy before confirming the webrev as final - and also fix all of 
>>>>> these even if
>>>>> the official compiler does not complain.
>>>>>
>>>>> And I did not notice any problems running SwingSet2 with either of 
>>>>> GTK2 or GTK3
>>>>> specified. It at least ran fine and clearly picked up different 
>>>>> versions.
>>>>>
>>>>>
>>>>> -phil.
>>>>>
>>>>>
>>>>> On 03/17/2016 06:25 AM, Semyon Sadetsky wrote:
>>>>>> The awt_Desktop.c is missed in the webrev.
>>>>>> Please see the updated one: 
>>>>>> http://cr.openjdk.java.net/~ssadetsky/8145547/webrev.02/
>>>>>>
>>>>>> --Semyon
>>>>>>
>>>>>> On 3/17/2016 3:57 PM, Sergey Bylokhov wrote:
>>>>>>> On 16.03.16 20:52, Semyon Sadetsky wrote:
>>>>>>>> Hi Phil,
>>>>>>>>
>>>>>>>> Thank for review. You will find my reply below in the text.
>>>>>>>>
>>>>>>>> The updated webrev is
>>>>>>>> http://cr.openjdk.java.net/~ssadetsky/8145547/webrev.01/
>>>>>>>
>>>>>>> On my system this version fails to build(Ubuntu 15.10 + gcc 5.2.1):
>>>>>>>
>>>>>>> ERROR: Build failed for target 'images' in configuration 
>>>>>>> 'linux-x86_64-normal-server-release' (exit code 2)
>>>>>>> === Output from failing command(s) repeated here ===
>>>>>>> * For target support_native_java.desktop_libawt_xawt_awt_Desktop.o:
>>>>>>> /mnt/hgfs/moe/workspaces/jdk/9/client-gate/jdk/src/java.desktop/unix/native/libawt_xawt/xawt/awt_Desktop.c: 
>>>>>>> In function ?Java_sun_awt_X11_XDesktopPeer_init?:
>>>>>>> /mnt/hgfs/moe/workspaces/jdk/9/client-gate/jdk/src/java.desktop/unix/native/libawt_xawt/xawt/awt_Desktop.c:46:9: 
>>>>>>> error: implicit declaration of function ?gtk2_load? 
>>>>>>> [-Werror=implicit-function-declaration]
>>>>>>>      if (gtk2_load(env) && gtk2_show_uri_load(env)) {
>>>>>>>          ^
>>>>>>> /mnt/hgfs/moe/workspaces/jdk/9/client-gate/jdk/src/java.desktop/unix/native/libawt_xawt/xawt/awt_Desktop.c:46:27: 
>>>>>>> error: implicit declaration of function ?gtk2_show_uri_load? 
>>>>>>> [-Werror=implicit-function-declaration]
>>>>>>>      if (gtk2_load(env) && gtk2_show_uri_load(env)) {
>>>>>>>                            ^
>>>>>>> cc1: all warnings being treated as errors
>>>>>>> === End of repeated output ===
>>>>>>> === Make failure sequence repeated here ===
>>>>>>> Awt2dLibraries.gmk:369: recipe for target 
>>>>>>> '/mnt/hgfs/moe/workspaces/jdk/9/client-gate/build/linux-x86_64-normal-server-release/support/native/java.desktop/libawt_xawt/awt_Desktop.o' 
>>>>>>> failed
>>>>>>> make/Main.gmk:175: recipe for target 'java.desktop-libs' failed
>>>>>>> === End of repeated output ===
>>>>>>>
>>>>>>>
>>>>>>>> It also contains:
>>>>>>>> - new properties jdk.gtk.version and jdk.gtk.verbose
>>>>>>>> - appearance tuning for Ubuntu 15 (GTK 3.14). It may require 
>>>>>>>> more but we
>>>>>>>> can do this later as a separate bug.
>>>>>>>> The main implementation was done for Ubuntu 14.05 LTS (GTK 
>>>>>>>> 3.10) and
>>>>>>>> then tuned for OEL 7 (GTK 3.8). Each minor GTK version may have 
>>>>>>>> some
>>>>>>>> appearance changes.
>>>>>>>>
>>>>>>>> On 3/15/2016 10:39 PM, Phil Race wrote:
>>>>>>>>> There is a lot to read here. I think I need to patch and try 
>>>>>>>>> it but
>>>>>>>>> first ...
>>>>>>>>>
>>>>>>>>> Two high level questions :
>>>>>>>>> 1) Have you verified that this behaves properly (or no worse than
>>>>>>>>> currently) with -Djava.awt.headless=true since Swing components
>>>>>>>>> are supposed to be able to draw off-screen in headless mode .. 
>>>>>>>>> and
>>>>>>>>> yet a dependency on GTK and its dependency on xlibraries seems 
>>>>>>>>> to mean
>>>>>>>>> that you can't load GTK in this case.
>>>>>>>>> BTW I think it may be painful to get them to layout in such a 
>>>>>>>>> case
>>>>>>>>> but that's another issue.
>>>>>>>> I tested it by painting to a BufferedImage. Seems it is enough.
>>>>>>>>>
>>>>>>>>> 2) Have you tried a hi-dpi system ?
>>>>>>>> Yes I have. It is identical to the existing GTK2 based appearance.
>>>>>>>>>
>>>>>>>>> 3) Have you submitted a JPRT job ? It is essential to know 
>>>>>>>>> that this
>>>>>>>>> builds cleanly on the "official" compilation environment.
>>>>>>>> I will do this before the push. I think it will be OK because I 
>>>>>>>> did not
>>>>>>>> use any new C constructs and the new libraries are linked 
>>>>>>>> dynamically.
>>>>>>>>> 4)I expect you ran Swingset2 + GTK L&F but have you run any of 
>>>>>>>>> the
>>>>>>>>> regression test suite ?
>>>>>>>> Yes I ran javax/swing tests but many of them fails with GTK2 as 
>>>>>>>> well.
>>>>>>>> With GTK3 the result was the same except for some unstable 
>>>>>>>> tests. Unity
>>>>>>>> desktop has new window decorations like borderless windows 
>>>>>>>> which are
>>>>>>>> resized by dragging the outer window shadow, invisible overlay
>>>>>>>> scrollbars, etc. Many tests written for old window decorations 
>>>>>>>> fails.
>>>>>>>>>
>>>>>>>>> Minor comments :
>>>>>>>>>
>>>>>>>>> GTKEngine.java
>>>>>>>>>
>>>>>>>>>  494         Container parent = 
>>>>>>>>> context.getComponent().getParent();
>>>>>>>>>  495         if(GTKLookAndFeel.is3()) {
>>>>>>>>>  496             if (parent != null && parent.getParent() 
>>>>>>>>> instanceof
>>>>>>>>> JComboBox) {
>>>>>>>>>  497                 if (parent.getParent().hasFocus()) {
>>>>>>>>>  498                     synthState |= SynthConstants.FOCUSED;
>>>>>>>>>  499                 }
>>>>>>>>>  500             }
>>>>>>>>>  501         }
>>>>>>>>>
>>>>>>>>> GTKPainter.java
>>>>>>>>>
>>>>>>>>> 746         if (GTKLookAndFeel.is3()) {
>>>>>>>>>  747             if (slider.getOrientation() == 
>>>>>>>>> JSlider.VERTICAL) {
>>>>>>>>>  748                 y += 1;
>>>>>>>>>  749                 h -= 2;
>>>>>>>>>  750             } else {
>>>>>>>>>  751                 x += 1;
>>>>>>>>>  752                 w -= 2;
>>>>>>>>>  753             }
>>>>>>>>>  754         }
>>>>>>>>>
>>>>>>>>> I don't know where these numbers come from or what coordinate 
>>>>>>>>> system
>>>>>>>>> is being used here but it seems you are changing them for gtk 
>>>>>>>>> 2.2 as
>>>>>>>>> well as 3
>>>>>>>>> Can you speak to this ?
>>>>>>>> It is an appearance tuning for GTK3. I didn't change it for 
>>>>>>>> GTK2, why do
>>>>>>>> you think so?
>>>>>>>> This was used before my fix as well, for example
>>>>>>>>
>>>>>>>>                      if (containerParent instanceof JComboBox) {
>>>>>>>>                          x += (focusSize + 2);
>>>>>>>>                          y += (focusSize + 1);
>>>>>>>>                          w -= (2 * focusSize + 1);
>>>>>>>>                          h -= (2 * focusSize + 2);
>>>>>>>>                      } else {
>>>>>>>>                          x += focusSize;
>>>>>>>>                          y += focusSize;
>>>>>>>>                          w -= 2 * focusSize;
>>>>>>>>                          h -= 2 * focusSize;
>>>>>>>>                      }
>>>>>>>>
>>>>>>>> The only place where I changed the existing GTK2 appearance is:
>>>>>>>>
>>>>>>>> 1121 CLASS_SPECIFIC_MAP.put("Slider.thumbWidth", "slider-length");
>>>>>>>>
>>>>>>>>   in GTKStyle.java, because this property was omitted by mistake.
>>>>>>>>>
>>>>>>>>> GTKStyle.java
>>>>>>>>>
>>>>>>>>> 735         if(!GTKLookAndFeel.is3()) {
>>>>>>>>>
>>>>>>>>> 840      } else if(GTKLookAndFeel.is3() &&
>>>>>>>>> "ComboBox.forceOpaque".equals(key)) {
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> we prefer a space between "if" and "("
>>>>>>>> Accepted.
>>>>>>>>>
>>>>>>>>> sun_awt_X11_GtkFileDialogPeer.c
>>>>>>>>>
>>>>>>>>>  392     if (gtk->gtk_check_version(2, 8, 0) == NULL) {
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Maybe I am not looking at the right fn but I thought I saw
>>>>>>>>> this fn return a boolean so a check against NULL looks wrong.
>>>>>>>> The declaration is in GtkApi struct of gtk_interface.h. It returns
>>>>>>>> char*. NULL means that the version is compatible.
>>>>>>>>>
>>>>>>>>>  393
>>>>>>>>> gtk->gtk_file_chooser_set_do_overwrite_confirmation(GTK_FILE_CHOOSER( 
>>>>>>>>>
>>>>>>>>>  394                 dialog), TRUE);
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> You didn't add this but it is awfully specific about the GTK 
>>>>>>>>> version and
>>>>>>>>> I wonder if this test is doing what it should be doing on GTK 3?
>>>>>>>> Accepted.
>>>>>>>>>
>>>>>>>>> It is interesting that some equivalent looking Java level dialog
>>>>>>>>> checking in XToolkit.java
>>>>>>>>> checked for 3.0 too ..
>>>>>>>>>
>>>>>>>>> swing_GTKEngine.c :
>>>>>>>>>
>>>>>>>>>   30 /* Static buffer for conversion from java.lang.String to 
>>>>>>>>> UTF-8 */
>>>>>>>>>   31 static char convertionBuffer[CONV_BUFFER_SIZE];
>>>>>>>>>
>>>>>>>>> So the variable name should be spelt conversionBuffer.
>>>>>>>> Accepted.
>>>>>>>>>
>>>>>>>>> awt_UNIXToolkit.c
>>>>>>>>>
>>>>>>>>> < 287 free(ret);
>>>>>>>>>
>>>>>>>>> You deleted this free(). Is that correct ? It seems to imply
>>>>>>>>> you now expect a boolean return as discussed above and
>>>>>>>>> so in that case NULL looks odd here (line 260) too.
>>>>>>>> The JNI exported method returns boolean while the GTK method 
>>>>>>>> returns
>>>>>>>> char*. free() is deleted intentionally according to the GTK 
>>>>>>>> docs it
>>>>>>>> belongs to the library and should not be freed by user code.
>>>>>>>>>
>>>>>>>>> gtk3_interface.h :
>>>>>>>>>
>>>>>>>>>   36 #define G_PI 
>>>>>>>>> 3.1415926535897932384626433832795028841971693993751
>>>>>>>>>
>>>>>>>>> I don't think that is completely accurate :-) And I should have
>>>>>>>>> reviewed this yesterday [1].
>>>>>>>> :) This is glib's definition I just copied.
>>>>>>>>
>>>>>>>> --Semyon
>>>>>>>>>
>>>>>>>>> -phil.
>>>>>>>>>
>>>>>>>>> [1] http://www.piday.org/
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On 03/05/2016 01:14 PM, Semyon Sadetsky wrote:
>>>>>>>>>> Hello,
>>>>>>>>>>
>>>>>>>>>> Please review fix for JDK9:
>>>>>>>>>>
>>>>>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8145547
>>>>>>>>>> webrev: http://cr.openjdk.java.net/~ssadetsky/8145547/webrev.00/
>>>>>>>>>>
>>>>>>>>>> The fix contains GTK3 based implementation for Swing GTK LnF, 
>>>>>>>>>> AWT
>>>>>>>>>> FileChooser for Linux and AWT Robot for Linux.
>>>>>>>>>> Also the new system property is added to request specific GTK 
>>>>>>>>>> version
>>>>>>>>>> swing.gtk.version.
>>>>>>>>>>
>>>>>>>>>> --Semyon
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>

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

From Sergey.Bylokhov at oracle.com  Fri Apr  8 17:45:08 2016
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Fri, 8 Apr 2016 20:45:08 +0300
Subject: <Swing Dev> [9] Review request for 8132119 Provide public API
 for text related methods in SwingUtilities2
In-Reply-To: <5706699D.5030904@oracle.com>
References: <55E715A1.3090008@oracle.com> <55E72D3A.60807@oracle.com>
	<55ED586F.5070509@oracle.com> <55F6DC3C.60809@oracle.com>
	<5655D3AB.9050503@oracle.com> <5668051E.7090401@oracle.com>
	<5668E226.5000604@oracle.com> <5669646E.4070305@oracle.com>
	<566986FD.9020207@oracle.com> <5694F0C3.8020203@oracle.com>
	<5695572F.6070709@oracle.com> <56966730.7000701@oracle.com>
	<5698C71A.80703@oracle.com> <56991ED9.5030302@oracle.com>
	<569963B6.2050604@oracle.com> <56A5C40B.7010107@oracle.com>
	<CAM6ZMz8iEFQQtSb_bAVU5eUH=J=HapvKq3+Ana4pPxueJD1bNg@mail.gmail.com>
	<56AB8A94.2070404@oracle.com> <56EC2389.3020507@oracle.com>
	<56F38B0B.3060700@oracle.com> <56F3F13A.9000808@oracle.com>
	<56F3F83C.3010706@oracle.com> <56FD791E.1050707@oracle.com>
	<5705705C.2010007@oracle.com> <570631C9.7090601@oracle.com>
	<5706699D.5030904@oracle.com>
Message-ID: <5707EE24.80309@oracle.com>

On 07.04.16 17:07, Alexander Scherbatiy wrote:
>    Could you review the updated fix:
>      http://cr.openjdk.java.net/~alexsch/8132119/webrev.10

Looks fine to me, but I am curious how often we use "throws NPE" in 
public API (especially w/o "@throws NPE" in javadoc).

>
> On 07/04/16 14:09, Sergey Bylokhov wrote:
>> On 06.04.16 23:23, Alexander Scherbatiy wrote:
>>> Could you review the updated fix:
>>>    http://cr.openjdk.java.net/~alexsch/8132119/webrev.09
>>
>> There is tiny typos
>> TextUIDrawing.getClippedString():
>>     "@param c the component"
>>     I guess it should be:
>>     "@param c the component, may be null"
>    Updated.
>> BasicTextUIDrawing:
>>     There is no dots at the end of the description of the class.
>>
>> I am not sure but will javadoc automatically copy the @throws tag from
>> the parent tag? For example @throws NullPointerException to
>> BasicTextUIDrawing.drawString().
>
>     I added throws NPE to the BasicTextUIDrawing class methods. It
> forces copying @throws tag from the parent javadoc.
>
>    Thanks,
>    Alexandr.
>>
>>>> But I can imagine they may also be handy when someone would typically
>>>> want to implement
>>>> only one or two out of a larger number in an interface and the default
>>>> and you for some
>>>> reason don't want to do that with an abstract class (notably you want
>>>> an other class to
>>>> be able to implement the interface).
>>>>
>>>> So what do I think about the case where the interface is brand new and
>>>> what you've done is more or less implement a concrete class, but it's
>>>> one that
>>>> can be mixed in to another class ? Is that an appropriate use ?
>>>>
>>>> Maybe the test to pass in that case is whether the default
>>>> implementation
>>>> is going to be satisfactory for 90% of uses. If they are frequently
>>>> over-ridden
>>>> it would not be an appropriate use.
>>>    Using this argument it seems if someone wants to implement the
>>> TextUIDrawing it needs to override all its methods to keep them in sync.
>>> Because of this I moved the TextUIDrawing implementation to the separate
>>> javax.swing.plaf.basic.BasicTextUIDrawing class.
>>
>> I am fine, just one note. Now we have the interface, and the class
>> without any state, and
>>  - If the users need to implement the only one method, then it will be
>> necessary to subclass a BasicTextUIDrawing, which will limit the
>> possible class hierarchy.
>>  - If the user most of the time will need to implement all methods to
>> make them in sync he also can override BasicTextUIDrawing, then why we
>> need the interface?
>>
>>>>
>>>> Based on that criterion I think it is OK to use here.
>>>>
>>>> Another thought:
>>>> When you add default implementations you should also be on the hook
>>>> for explaining what that does. It is a deeper contract than you would
>>>> otherwise have as an interface and maybe needs to be an @implNote
>>>> or you need to call out the default implementation.
>>>> ie there is what someone must code to satisfy the contract of the
>>>> interface and what is a behaviour in the default method ?
>>>    I added the addition "using text properties and anti-aliasing hints
>>> from the provided component" description to the BasicTextUIDrawing
>>> class. There is always a question how many details a method description
>>> should contain. It is not clear for  me should, for example, the used
>>> numeric shaper be listed in the description or not? Especially when
>>> there is an enhancement that the methods implementation should take more
>>> text attributes  into account.
>>>
>>>> Also here is a link to some comments by Brian Goetz on default
>>>> methods :
>>>>
>>>> http://stackoverflow.com/questions/28681737/java-8-default-methods-as-traits-safe/28684917#28684917
>>>>
>>>>
>>>>
>>>>   75      * No character is underlined if the index is negative or
>>>> greater
>>>>   76      * than the string length {@code (index < 0 || index >=
>>>> string.length())}
>>>>   77      * or if the char value specified at the given index
>>>>   78      * is in the low-surrogate range.
>>>>
>>>>
>>>> I suppose if you point at the last char and it is a hi-surrogate
>>>> nothing is underlined in that case either.
>>>>
>>>> But I find the whole writing of this a bit inadequate as if you are
>>>> going to
>>>> this kind of detail you perhaps also need to say what happens in a
>>>> complex
>>>> script where what happens is two unicode characters end up as a
>>>> ligature,
>>>> and/or perhaps you aren't even pointing to a base character.
>>>> Maybe it is in fact over-specified. I see that the implementation draws
>>>> the underline itself rather than delegate to TextLayout. This might
>>>> make sense for performance reasons where it is simple text but some day
>>>> this maybe should be re-examined and so I would not over-specify it.
>>>>
>>>> How about :
>>>> "The underline will be positioned at the base glyph which
>>>> represents the valid char indicated by the index.
>>>> If the char index is not valid or is not the index of a
>>>> valid unicode code point then no underline is drawn"
>>>    Updated.
>>>
>>>    Thanks,
>>>    Alexandr.
>>>>
>>>> -phil.
>>>>
>>>>
>>>>
>>>> On 03/24/2016 07:22 AM, Sergey Bylokhov wrote:
>>>>> On 24.03.16 16:52, Alexander Scherbatiy wrote:
>>>>>> On 24/03/16 10:36, Semyon Sadetsky wrote:
>>>>>>> Hi Alexander,
>>>>>>>
>>>>>>> Could you answer one question:
>>>>>>> Why did you choose default interface methods to implement
>>>>>>> TextUIDrawing and not implement them in DefaultTextUIDrawing having
>>>>>>> declarations only in the interface?
>>>>>>> AFAIK the common point of view is default methods should be used
>>>>>>> rarely because they may lead to unreadable code.
>>>>>>>
>>>>>>    The only problem which I know about default methods is multiple
>>>>>> inheritance which has its own solution.
>>>>>
>>>>> What kind of problems? The benefit is obvious: it will not be
>>>>> necessary to implement all methods if only one of them should be
>>>>> tweaked.
>>>>>
>>>>>>
>>>>>>    Could you give links to discussion or provide use cases where
>>>>>> default
>>>>>> methods leads to the unreadable code and show how does it relate
>>>>>> to the
>>>>>> TextUIDrawing  implementation?
>>>>>>
>>>>>>    Thanks,
>>>>>>    Alexandr.
>>>>>>> --Semyon
>>>>>>>
>>>>>>> On 3/18/2016 6:49 PM, Alexander Scherbatiy wrote:
>>>>>>>>
>>>>>>>> Could you review the updated fix:
>>>>>>>> http://cr.openjdk.java.net/~alexsch/8132119/webrev.08/
>>>>>>>>
>>>>>>>>   - Public TextUIDrawing interface is added to the javax.swing.plaf
>>>>>>>> package
>>>>>>>>   - TextUIDrawing methods description does not mention component
>>>>>>>> properties to be more general
>>>>>>>>   - TextUIDrawing methods are made default
>>>>>>>>   - L&F sets an instance of the TextUIDrawing to look and feel
>>>>>>>> defaults using "uiDrawing.text" property
>>>>>>>>   - ComponentUI class is not changed
>>>>>>>>   - Each ComponentUI reads TextUIDrawing from UI defaults
>>>>>>>>   - There is an interesting issue described in
>>>>>>>> http://mail.openjdk.java.net/pipermail/swing-dev/2016-March/005509.html
>>>>>>>>
>>>>>>>>
>>>>>>>>     which is related to the fact that MetalLabelUI returns a static
>>>>>>>> field from createUI() method.
>>>>>>>>     TitleBorder creates a JLabel but does not put it to any
>>>>>>>> component
>>>>>>>> hierarchy. In this case SwingUtilities.updateComponentTreeUI()
>>>>>>>> method
>>>>>>>> calls MetalLabelUI.uninstallDefaults() on the static metalLabelUI
>>>>>>>> field and sets a new LabelUI for ordinary labels. The TitleBorder
>>>>>>>> label UI is not changed in this case and it still uses the
>>>>>>>> metalLabelUI field which is not initialized.
>>>>>>>>     It seems that other applications can also use components
>>>>>>>> just for
>>>>>>>> drawing and have the same issue.
>>>>>>>>     For this case the textUIDrawing field is not cleared in the
>>>>>>>> uninstallDefaults but just set to a static default value which
>>>>>>>> should
>>>>>>>> not lead to memory leaks.
>>>>>>>>
>>>>>>>>   Thanks,
>>>>>>>>   Alexandr.
>>>>>>>>
>>>>>>>> On 29/01/16 19:51, Alexander Scherbatiy wrote:
>>>>>>>>> On 25/01/16 13:44, Andrej Golovnin wrote:
>>>>>>>>>> Hi Alexandr,
>>>>>>>>>>
>>>>>>>>>>> Could you review the updated fix:
>>>>>>>>>>> http://cr.openjdk.java.net/~alexsch/8132119/webrev.07/
>>>>>>>>>> ....
>>>>>>>>>>> - public TextUIDrawing interface is added to the
>>>>>>>>>>> javax.swing.plaf
>>>>>>>>>>> package
>>>>>>>>>>> - public "TextUIDrawing getTextUIDrawing()" method is added
>>>>>>>>>>> to the
>>>>>>>>>>> ComponentUI class
>>>>>>>>>>> - L&F sets an instance of the TextUIDrawing to look and feel
>>>>>>>>>>> defaults using
>>>>>>>>>>> "uiDrawing.text" property
>>>>>>>>>>> - Look and Feel delegates use the instance of the TextUIDrawing
>>>>>>>>>>> for text
>>>>>>>>>>> drawing and measuring
>>>>>>>>>> Some thoughts on the current design/implementation:
>>>>>>>>>>
>>>>>>>>>> By adding a field to the ComponentUI class the current
>>>>>>>>>> implementation increases
>>>>>>>>>> memory consumption for all Swing applications. And you get the
>>>>>>>>>> feeling that
>>>>>>>>>> there are different implementations of TextUIDrawing per
>>>>>>>>>> ComponentUI instances.
>>>>>>>>>> Personally I can't imagine to have different implementations of
>>>>>>>>>> TextUIDrawing for
>>>>>>>>>> a given LookAndFeel. If I would design/implement it, then I would
>>>>>>>>>> implement it as
>>>>>>>>>> a property of the LookAndFeel class (similar to LayoutStyle) and
>>>>>>>>>> not
>>>>>>>>>> the ComponentUI.
>>>>>>>>>> Developers can use then the following code to obtain the
>>>>>>>>>> instance of
>>>>>>>>>> TextUIDrawing:
>>>>>>>>>>
>>>>>>>>>> UIManager.getLookAndFeel().getUIDrawing() // or
>>>>>>>>>> UIManager.getLookAndFeelUIDrawing() // use this static method
>>>>>>>>>> as a
>>>>>>>>>> short cut for the line above.
>>>>>>>>>   LayoutStyle keeps its instance per App context. The same is for
>>>>>>>>> the LookAndFeel
>>>>>>>>>   when it is got through UIManager.getLookAndFeel() call.
>>>>>>>>>   It means that accessing an instance of a TextUIDrawing will
>>>>>>>>> leads
>>>>>>>>> to a time consumption.
>>>>>>>>>
>>>>>>>>>   There are 3 main ways of the SwingUtilities2.drawString(...)
>>>>>>>>> usage:
>>>>>>>>>   1. ComponentUI classes
>>>>>>>>>   2. Components created in UI (like BasicInternalFrameTitlePane)
>>>>>>>>>   3. Public utilities methods (like
>>>>>>>>> WindowsGraphicsUtils.paintText())
>>>>>>>>>
>>>>>>>>>   For the cases 1 and 2 it is possible to load and store the
>>>>>>>>> UIDrawing instance during installUI()/updateUI() calls to
>>>>>>>>> decrease a
>>>>>>>>> time access to it.
>>>>>>>>>
>>>>>>>>>   For the case 3 it is necessary to get LookAndFeel instance each
>>>>>>>>> time (which is taken from an App context)
>>>>>>>>>   or use the passed JComponent object. It requires to have a
>>>>>>>>> public
>>>>>>>>> method and the associated variable for each instance of
>>>>>>>>> JComponent/ComponentUI/... class.
>>>>>>>>>> You can use this methods then in JDK too.
>>>>>>>>>>
>>>>>>>>>> And maybe rename the TextUIDrawing class to just UIDrawing and
>>>>>>>>>> add
>>>>>>>>>> more useful methods,
>>>>>>>>>> e.g. a method to create a composite font, a method to convert
>>>>>>>>>> DLUs
>>>>>>>>>> to pixels.
>>>>>>>>>   UIDrawing name may look like it should be used for any UI
>>>>>>>>> drawing,
>>>>>>>>> not only for text ones. I am afraid that it can be misleading.
>>>>>>>>>
>>>>>>>>>   Thanks,
>>>>>>>>>   Alexandr.
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Best regards,
>>>>>>>>>> Andrej Golovnin
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>
>>
>>
>


-- 
Best regards, Sergey.


From kevin.rushforth at oracle.com  Fri Apr  8 18:34:44 2016
From: kevin.rushforth at oracle.com (Kevin Rushforth)
Date: Fri, 08 Apr 2016 11:34:44 -0700
Subject: <Swing Dev> [9] Review request for 8132119 Provide public API
 for text related methods in SwingUtilities2
In-Reply-To: <5707EE24.80309@oracle.com>
References: <55E715A1.3090008@oracle.com>
	<55E72D3A.60807@oracle.com>	<55ED586F.5070509@oracle.com>
	<55F6DC3C.60809@oracle.com>	<5655D3AB.9050503@oracle.com>
	<5668051E.7090401@oracle.com>	<5668E226.5000604@oracle.com>
	<5669646E.4070305@oracle.com>	<566986FD.9020207@oracle.com>
	<5694F0C3.8020203@oracle.com>	<5695572F.6070709@oracle.com>
	<56966730.7000701@oracle.com>	<5698C71A.80703@oracle.com>
	<56991ED9.5030302@oracle.com>	<569963B6.2050604@oracle.com>
	<56A5C40B.7010107@oracle.com>	<CAM6ZMz8iEFQQtSb_bAVU5eUH=J=HapvKq3+Ana4pPxueJD1bNg@mail.gmail.com>	<56AB8A94.2070404@oracle.com>
	<56EC2389.3020507@oracle.com>	<56F38B0B.3060700@oracle.com>
	<56F3F13A.9000808@oracle.com>	<56F3F83C.3010706@oracle.com>
	<56FD791E.1050707@oracle.com>	<5705705C.2010007@oracle.com>
	<570631C9.7090601@oracle.com>	<5706699D.5030904@oracle.com>
	<5707EE24.80309@oracle.com>
Message-ID: <5707F9C4.7040803@oracle.com>

Just my $0.02 (feel free to ignore).

Specifying "throws" on a method for an unchecked exception like NPE 
seems odd. Typically, only checked exceptions are declared. Both checked 
and unchecked exceptions can and should be documented with @throws.

-- Kevin


Sergey Bylokhov wrote:
> On 07.04.16 17:07, Alexander Scherbatiy wrote:
>>    Could you review the updated fix:
>>      http://cr.openjdk.java.net/~alexsch/8132119/webrev.10
>
> Looks fine to me, but I am curious how often we use "throws NPE" in 
> public API (especially w/o "@throws NPE" in javadoc).
>
>>
>> On 07/04/16 14:09, Sergey Bylokhov wrote:
>>> On 06.04.16 23:23, Alexander Scherbatiy wrote:
>>>> Could you review the updated fix:
>>>>    http://cr.openjdk.java.net/~alexsch/8132119/webrev.09
>>>
>>> There is tiny typos
>>> TextUIDrawing.getClippedString():
>>>     "@param c the component"
>>>     I guess it should be:
>>>     "@param c the component, may be null"
>>    Updated.
>>> BasicTextUIDrawing:
>>>     There is no dots at the end of the description of the class.
>>>
>>> I am not sure but will javadoc automatically copy the @throws tag from
>>> the parent tag? For example @throws NullPointerException to
>>> BasicTextUIDrawing.drawString().
>>
>>     I added throws NPE to the BasicTextUIDrawing class methods. It
>> forces copying @throws tag from the parent javadoc.
>>
>>    Thanks,
>>    Alexandr.
>>>
>>>>> But I can imagine they may also be handy when someone would typically
>>>>> want to implement
>>>>> only one or two out of a larger number in an interface and the 
>>>>> default
>>>>> and you for some
>>>>> reason don't want to do that with an abstract class (notably you want
>>>>> an other class to
>>>>> be able to implement the interface).
>>>>>
>>>>> So what do I think about the case where the interface is brand new 
>>>>> and
>>>>> what you've done is more or less implement a concrete class, but it's
>>>>> one that
>>>>> can be mixed in to another class ? Is that an appropriate use ?
>>>>>
>>>>> Maybe the test to pass in that case is whether the default
>>>>> implementation
>>>>> is going to be satisfactory for 90% of uses. If they are frequently
>>>>> over-ridden
>>>>> it would not be an appropriate use.
>>>>    Using this argument it seems if someone wants to implement the
>>>> TextUIDrawing it needs to override all its methods to keep them in 
>>>> sync.
>>>> Because of this I moved the TextUIDrawing implementation to the 
>>>> separate
>>>> javax.swing.plaf.basic.BasicTextUIDrawing class.
>>>
>>> I am fine, just one note. Now we have the interface, and the class
>>> without any state, and
>>>  - If the users need to implement the only one method, then it will be
>>> necessary to subclass a BasicTextUIDrawing, which will limit the
>>> possible class hierarchy.
>>>  - If the user most of the time will need to implement all methods to
>>> make them in sync he also can override BasicTextUIDrawing, then why we
>>> need the interface?
>>>
>>>>>
>>>>> Based on that criterion I think it is OK to use here.
>>>>>
>>>>> Another thought:
>>>>> When you add default implementations you should also be on the hook
>>>>> for explaining what that does. It is a deeper contract than you would
>>>>> otherwise have as an interface and maybe needs to be an @implNote
>>>>> or you need to call out the default implementation.
>>>>> ie there is what someone must code to satisfy the contract of the
>>>>> interface and what is a behaviour in the default method ?
>>>>    I added the addition "using text properties and anti-aliasing hints
>>>> from the provided component" description to the BasicTextUIDrawing
>>>> class. There is always a question how many details a method 
>>>> description
>>>> should contain. It is not clear for  me should, for example, the used
>>>> numeric shaper be listed in the description or not? Especially when
>>>> there is an enhancement that the methods implementation should take 
>>>> more
>>>> text attributes  into account.
>>>>
>>>>> Also here is a link to some comments by Brian Goetz on default
>>>>> methods :
>>>>>
>>>>> http://stackoverflow.com/questions/28681737/java-8-default-methods-as-traits-safe/28684917#28684917 
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>   75      * No character is underlined if the index is negative or
>>>>> greater
>>>>>   76      * than the string length {@code (index < 0 || index >=
>>>>> string.length())}
>>>>>   77      * or if the char value specified at the given index
>>>>>   78      * is in the low-surrogate range.
>>>>>
>>>>>
>>>>> I suppose if you point at the last char and it is a hi-surrogate
>>>>> nothing is underlined in that case either.
>>>>>
>>>>> But I find the whole writing of this a bit inadequate as if you are
>>>>> going to
>>>>> this kind of detail you perhaps also need to say what happens in a
>>>>> complex
>>>>> script where what happens is two unicode characters end up as a
>>>>> ligature,
>>>>> and/or perhaps you aren't even pointing to a base character.
>>>>> Maybe it is in fact over-specified. I see that the implementation 
>>>>> draws
>>>>> the underline itself rather than delegate to TextLayout. This might
>>>>> make sense for performance reasons where it is simple text but 
>>>>> some day
>>>>> this maybe should be re-examined and so I would not over-specify it.
>>>>>
>>>>> How about :
>>>>> "The underline will be positioned at the base glyph which
>>>>> represents the valid char indicated by the index.
>>>>> If the char index is not valid or is not the index of a
>>>>> valid unicode code point then no underline is drawn"
>>>>    Updated.
>>>>
>>>>    Thanks,
>>>>    Alexandr.
>>>>>
>>>>> -phil.
>>>>>
>>>>>
>>>>>
>>>>> On 03/24/2016 07:22 AM, Sergey Bylokhov wrote:
>>>>>> On 24.03.16 16:52, Alexander Scherbatiy wrote:
>>>>>>> On 24/03/16 10:36, Semyon Sadetsky wrote:
>>>>>>>> Hi Alexander,
>>>>>>>>
>>>>>>>> Could you answer one question:
>>>>>>>> Why did you choose default interface methods to implement
>>>>>>>> TextUIDrawing and not implement them in DefaultTextUIDrawing 
>>>>>>>> having
>>>>>>>> declarations only in the interface?
>>>>>>>> AFAIK the common point of view is default methods should be used
>>>>>>>> rarely because they may lead to unreadable code.
>>>>>>>>
>>>>>>>    The only problem which I know about default methods is multiple
>>>>>>> inheritance which has its own solution.
>>>>>>
>>>>>> What kind of problems? The benefit is obvious: it will not be
>>>>>> necessary to implement all methods if only one of them should be
>>>>>> tweaked.
>>>>>>
>>>>>>>
>>>>>>>    Could you give links to discussion or provide use cases where
>>>>>>> default
>>>>>>> methods leads to the unreadable code and show how does it relate
>>>>>>> to the
>>>>>>> TextUIDrawing  implementation?
>>>>>>>
>>>>>>>    Thanks,
>>>>>>>    Alexandr.
>>>>>>>> --Semyon
>>>>>>>>
>>>>>>>> On 3/18/2016 6:49 PM, Alexander Scherbatiy wrote:
>>>>>>>>>
>>>>>>>>> Could you review the updated fix:
>>>>>>>>> http://cr.openjdk.java.net/~alexsch/8132119/webrev.08/
>>>>>>>>>
>>>>>>>>>   - Public TextUIDrawing interface is added to the 
>>>>>>>>> javax.swing.plaf
>>>>>>>>> package
>>>>>>>>>   - TextUIDrawing methods description does not mention component
>>>>>>>>> properties to be more general
>>>>>>>>>   - TextUIDrawing methods are made default
>>>>>>>>>   - L&F sets an instance of the TextUIDrawing to look and feel
>>>>>>>>> defaults using "uiDrawing.text" property
>>>>>>>>>   - ComponentUI class is not changed
>>>>>>>>>   - Each ComponentUI reads TextUIDrawing from UI defaults
>>>>>>>>>   - There is an interesting issue described in
>>>>>>>>> http://mail.openjdk.java.net/pipermail/swing-dev/2016-March/005509.html 
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>     which is related to the fact that MetalLabelUI returns a 
>>>>>>>>> static
>>>>>>>>> field from createUI() method.
>>>>>>>>>     TitleBorder creates a JLabel but does not put it to any
>>>>>>>>> component
>>>>>>>>> hierarchy. In this case SwingUtilities.updateComponentTreeUI()
>>>>>>>>> method
>>>>>>>>> calls MetalLabelUI.uninstallDefaults() on the static metalLabelUI
>>>>>>>>> field and sets a new LabelUI for ordinary labels. The TitleBorder
>>>>>>>>> label UI is not changed in this case and it still uses the
>>>>>>>>> metalLabelUI field which is not initialized.
>>>>>>>>>     It seems that other applications can also use components
>>>>>>>>> just for
>>>>>>>>> drawing and have the same issue.
>>>>>>>>>     For this case the textUIDrawing field is not cleared in the
>>>>>>>>> uninstallDefaults but just set to a static default value which
>>>>>>>>> should
>>>>>>>>> not lead to memory leaks.
>>>>>>>>>
>>>>>>>>>   Thanks,
>>>>>>>>>   Alexandr.
>>>>>>>>>
>>>>>>>>> On 29/01/16 19:51, Alexander Scherbatiy wrote:
>>>>>>>>>> On 25/01/16 13:44, Andrej Golovnin wrote:
>>>>>>>>>>> Hi Alexandr,
>>>>>>>>>>>
>>>>>>>>>>>> Could you review the updated fix:
>>>>>>>>>>>> http://cr.openjdk.java.net/~alexsch/8132119/webrev.07/
>>>>>>>>>>> ....
>>>>>>>>>>>> - public TextUIDrawing interface is added to the
>>>>>>>>>>>> javax.swing.plaf
>>>>>>>>>>>> package
>>>>>>>>>>>> - public "TextUIDrawing getTextUIDrawing()" method is added
>>>>>>>>>>>> to the
>>>>>>>>>>>> ComponentUI class
>>>>>>>>>>>> - L&F sets an instance of the TextUIDrawing to look and feel
>>>>>>>>>>>> defaults using
>>>>>>>>>>>> "uiDrawing.text" property
>>>>>>>>>>>> - Look and Feel delegates use the instance of the 
>>>>>>>>>>>> TextUIDrawing
>>>>>>>>>>>> for text
>>>>>>>>>>>> drawing and measuring
>>>>>>>>>>> Some thoughts on the current design/implementation:
>>>>>>>>>>>
>>>>>>>>>>> By adding a field to the ComponentUI class the current
>>>>>>>>>>> implementation increases
>>>>>>>>>>> memory consumption for all Swing applications. And you get the
>>>>>>>>>>> feeling that
>>>>>>>>>>> there are different implementations of TextUIDrawing per
>>>>>>>>>>> ComponentUI instances.
>>>>>>>>>>> Personally I can't imagine to have different implementations of
>>>>>>>>>>> TextUIDrawing for
>>>>>>>>>>> a given LookAndFeel. If I would design/implement it, then I 
>>>>>>>>>>> would
>>>>>>>>>>> implement it as
>>>>>>>>>>> a property of the LookAndFeel class (similar to LayoutStyle) 
>>>>>>>>>>> and
>>>>>>>>>>> not
>>>>>>>>>>> the ComponentUI.
>>>>>>>>>>> Developers can use then the following code to obtain the
>>>>>>>>>>> instance of
>>>>>>>>>>> TextUIDrawing:
>>>>>>>>>>>
>>>>>>>>>>> UIManager.getLookAndFeel().getUIDrawing() // or
>>>>>>>>>>> UIManager.getLookAndFeelUIDrawing() // use this static method
>>>>>>>>>>> as a
>>>>>>>>>>> short cut for the line above.
>>>>>>>>>>   LayoutStyle keeps its instance per App context. The same is 
>>>>>>>>>> for
>>>>>>>>>> the LookAndFeel
>>>>>>>>>>   when it is got through UIManager.getLookAndFeel() call.
>>>>>>>>>>   It means that accessing an instance of a TextUIDrawing will
>>>>>>>>>> leads
>>>>>>>>>> to a time consumption.
>>>>>>>>>>
>>>>>>>>>>   There are 3 main ways of the SwingUtilities2.drawString(...)
>>>>>>>>>> usage:
>>>>>>>>>>   1. ComponentUI classes
>>>>>>>>>>   2. Components created in UI (like BasicInternalFrameTitlePane)
>>>>>>>>>>   3. Public utilities methods (like
>>>>>>>>>> WindowsGraphicsUtils.paintText())
>>>>>>>>>>
>>>>>>>>>>   For the cases 1 and 2 it is possible to load and store the
>>>>>>>>>> UIDrawing instance during installUI()/updateUI() calls to
>>>>>>>>>> decrease a
>>>>>>>>>> time access to it.
>>>>>>>>>>
>>>>>>>>>>   For the case 3 it is necessary to get LookAndFeel instance 
>>>>>>>>>> each
>>>>>>>>>> time (which is taken from an App context)
>>>>>>>>>>   or use the passed JComponent object. It requires to have a
>>>>>>>>>> public
>>>>>>>>>> method and the associated variable for each instance of
>>>>>>>>>> JComponent/ComponentUI/... class.
>>>>>>>>>>> You can use this methods then in JDK too.
>>>>>>>>>>>
>>>>>>>>>>> And maybe rename the TextUIDrawing class to just UIDrawing and
>>>>>>>>>>> add
>>>>>>>>>>> more useful methods,
>>>>>>>>>>> e.g. a method to create a composite font, a method to convert
>>>>>>>>>>> DLUs
>>>>>>>>>>> to pixels.
>>>>>>>>>>   UIDrawing name may look like it should be used for any UI
>>>>>>>>>> drawing,
>>>>>>>>>> not only for text ones. I am afraid that it can be misleading.
>>>>>>>>>>
>>>>>>>>>>   Thanks,
>>>>>>>>>>   Alexandr.
>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Best regards,
>>>>>>>>>>> Andrej Golovnin
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>>
>>
>
>


From alexandr.scherbatiy at oracle.com  Fri Apr  8 19:00:58 2016
From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy)
Date: Fri, 8 Apr 2016 23:00:58 +0400
Subject: <Swing Dev> [9] Review request for 8132119 Provide public API
 for text related methods in SwingUtilities2
In-Reply-To: <5707F9C4.7040803@oracle.com>
References: <55E715A1.3090008@oracle.com> <55E72D3A.60807@oracle.com>
	<55ED586F.5070509@oracle.com> <55F6DC3C.60809@oracle.com>
	<5655D3AB.9050503@oracle.com> <5668051E.7090401@oracle.com>
	<5668E226.5000604@oracle.com> <5669646E.4070305@oracle.com>
	<566986FD.9020207@oracle.com> <5694F0C3.8020203@oracle.com>
	<5695572F.6070709@oracle.com> <56966730.7000701@oracle.com>
	<5698C71A.80703@oracle.com> <56991ED9.5030302@oracle.com>
	<569963B6.2050604@oracle.com> <56A5C40B.7010107@oracle.com>
	<CAM6ZMz8iEFQQtSb_bAVU5eUH=J=HapvKq3+Ana4pPxueJD1bNg@mail.gmail.com>
	<56AB8A94.2070404@oracle.com> <56EC2389.3020507@oracle.com>
	<56F38B0B.3060700@oracle.com> <56F3F13A.9000808@oracle.com>
	<56F3F83C.3010706@oracle.com> <56FD791E.1050707@oracle.com>
	<5705705C.2010007@oracle.com> <570631C9.7090601@oracle.com>
	<5706699D.5030904@oracle.com> <5707EE24.80309@oracle.com>
	<5707F9C4.7040803@oracle.com>
Message-ID: <5707FFEA.7010201@oracle.com>


  Hello,

  Could you review the updated fix:
   http://cr.openjdk.java.net/~alexsch/8132119/webrev.11/

  - @throws tag is added in javadoc for methods in BasicTextUIDrawing class
  -  unchecked exceptions are removed from methods throws declaration

   Thanks,
   Alexandr.

On 08/04/16 22:34, Kevin Rushforth wrote:
> Just my $0.02 (feel free to ignore).
>
> Specifying "throws" on a method for an unchecked exception like NPE 
> seems odd. Typically, only checked exceptions are declared. Both 
> checked and unchecked exceptions can and should be documented with 
> @throws.
>
> -- Kevin
>
>
> Sergey Bylokhov wrote:
>> On 07.04.16 17:07, Alexander Scherbatiy wrote:
>>>    Could you review the updated fix:
>>>      http://cr.openjdk.java.net/~alexsch/8132119/webrev.10
>>
>> Looks fine to me, but I am curious how often we use "throws NPE" in 
>> public API (especially w/o "@throws NPE" in javadoc).
>>
>>>
>>> On 07/04/16 14:09, Sergey Bylokhov wrote:
>>>> On 06.04.16 23:23, Alexander Scherbatiy wrote:
>>>>> Could you review the updated fix:
>>>>>    http://cr.openjdk.java.net/~alexsch/8132119/webrev.09
>>>>
>>>> There is tiny typos
>>>> TextUIDrawing.getClippedString():
>>>>     "@param c the component"
>>>>     I guess it should be:
>>>>     "@param c the component, may be null"
>>>    Updated.
>>>> BasicTextUIDrawing:
>>>>     There is no dots at the end of the description of the class.
>>>>
>>>> I am not sure but will javadoc automatically copy the @throws tag from
>>>> the parent tag? For example @throws NullPointerException to
>>>> BasicTextUIDrawing.drawString().
>>>
>>>     I added throws NPE to the BasicTextUIDrawing class methods. It
>>> forces copying @throws tag from the parent javadoc.
>>>
>>>    Thanks,
>>>    Alexandr.
>>>>
>>>>>> But I can imagine they may also be handy when someone would 
>>>>>> typically
>>>>>> want to implement
>>>>>> only one or two out of a larger number in an interface and the 
>>>>>> default
>>>>>> and you for some
>>>>>> reason don't want to do that with an abstract class (notably you 
>>>>>> want
>>>>>> an other class to
>>>>>> be able to implement the interface).
>>>>>>
>>>>>> So what do I think about the case where the interface is brand 
>>>>>> new and
>>>>>> what you've done is more or less implement a concrete class, but 
>>>>>> it's
>>>>>> one that
>>>>>> can be mixed in to another class ? Is that an appropriate use ?
>>>>>>
>>>>>> Maybe the test to pass in that case is whether the default
>>>>>> implementation
>>>>>> is going to be satisfactory for 90% of uses. If they are frequently
>>>>>> over-ridden
>>>>>> it would not be an appropriate use.
>>>>>    Using this argument it seems if someone wants to implement the
>>>>> TextUIDrawing it needs to override all its methods to keep them in 
>>>>> sync.
>>>>> Because of this I moved the TextUIDrawing implementation to the 
>>>>> separate
>>>>> javax.swing.plaf.basic.BasicTextUIDrawing class.
>>>>
>>>> I am fine, just one note. Now we have the interface, and the class
>>>> without any state, and
>>>>  - If the users need to implement the only one method, then it will be
>>>> necessary to subclass a BasicTextUIDrawing, which will limit the
>>>> possible class hierarchy.
>>>>  - If the user most of the time will need to implement all methods to
>>>> make them in sync he also can override BasicTextUIDrawing, then why we
>>>> need the interface?
>>>>
>>>>>>
>>>>>> Based on that criterion I think it is OK to use here.
>>>>>>
>>>>>> Another thought:
>>>>>> When you add default implementations you should also be on the hook
>>>>>> for explaining what that does. It is a deeper contract than you 
>>>>>> would
>>>>>> otherwise have as an interface and maybe needs to be an @implNote
>>>>>> or you need to call out the default implementation.
>>>>>> ie there is what someone must code to satisfy the contract of the
>>>>>> interface and what is a behaviour in the default method ?
>>>>>    I added the addition "using text properties and anti-aliasing 
>>>>> hints
>>>>> from the provided component" description to the BasicTextUIDrawing
>>>>> class. There is always a question how many details a method 
>>>>> description
>>>>> should contain. It is not clear for  me should, for example, the used
>>>>> numeric shaper be listed in the description or not? Especially when
>>>>> there is an enhancement that the methods implementation should 
>>>>> take more
>>>>> text attributes  into account.
>>>>>
>>>>>> Also here is a link to some comments by Brian Goetz on default
>>>>>> methods :
>>>>>>
>>>>>> http://stackoverflow.com/questions/28681737/java-8-default-methods-as-traits-safe/28684917#28684917 
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>   75      * No character is underlined if the index is negative or
>>>>>> greater
>>>>>>   76      * than the string length {@code (index < 0 || index >=
>>>>>> string.length())}
>>>>>>   77      * or if the char value specified at the given index
>>>>>>   78      * is in the low-surrogate range.
>>>>>>
>>>>>>
>>>>>> I suppose if you point at the last char and it is a hi-surrogate
>>>>>> nothing is underlined in that case either.
>>>>>>
>>>>>> But I find the whole writing of this a bit inadequate as if you are
>>>>>> going to
>>>>>> this kind of detail you perhaps also need to say what happens in a
>>>>>> complex
>>>>>> script where what happens is two unicode characters end up as a
>>>>>> ligature,
>>>>>> and/or perhaps you aren't even pointing to a base character.
>>>>>> Maybe it is in fact over-specified. I see that the implementation 
>>>>>> draws
>>>>>> the underline itself rather than delegate to TextLayout. This might
>>>>>> make sense for performance reasons where it is simple text but 
>>>>>> some day
>>>>>> this maybe should be re-examined and so I would not over-specify it.
>>>>>>
>>>>>> How about :
>>>>>> "The underline will be positioned at the base glyph which
>>>>>> represents the valid char indicated by the index.
>>>>>> If the char index is not valid or is not the index of a
>>>>>> valid unicode code point then no underline is drawn"
>>>>>    Updated.
>>>>>
>>>>>    Thanks,
>>>>>    Alexandr.
>>>>>>
>>>>>> -phil.
>>>>>>
>>>>>>
>>>>>>
>>>>>> On 03/24/2016 07:22 AM, Sergey Bylokhov wrote:
>>>>>>> On 24.03.16 16:52, Alexander Scherbatiy wrote:
>>>>>>>> On 24/03/16 10:36, Semyon Sadetsky wrote:
>>>>>>>>> Hi Alexander,
>>>>>>>>>
>>>>>>>>> Could you answer one question:
>>>>>>>>> Why did you choose default interface methods to implement
>>>>>>>>> TextUIDrawing and not implement them in DefaultTextUIDrawing 
>>>>>>>>> having
>>>>>>>>> declarations only in the interface?
>>>>>>>>> AFAIK the common point of view is default methods should be used
>>>>>>>>> rarely because they may lead to unreadable code.
>>>>>>>>>
>>>>>>>>    The only problem which I know about default methods is multiple
>>>>>>>> inheritance which has its own solution.
>>>>>>>
>>>>>>> What kind of problems? The benefit is obvious: it will not be
>>>>>>> necessary to implement all methods if only one of them should be
>>>>>>> tweaked.
>>>>>>>
>>>>>>>>
>>>>>>>>    Could you give links to discussion or provide use cases where
>>>>>>>> default
>>>>>>>> methods leads to the unreadable code and show how does it relate
>>>>>>>> to the
>>>>>>>> TextUIDrawing  implementation?
>>>>>>>>
>>>>>>>>    Thanks,
>>>>>>>>    Alexandr.
>>>>>>>>> --Semyon
>>>>>>>>>
>>>>>>>>> On 3/18/2016 6:49 PM, Alexander Scherbatiy wrote:
>>>>>>>>>>
>>>>>>>>>> Could you review the updated fix:
>>>>>>>>>> http://cr.openjdk.java.net/~alexsch/8132119/webrev.08/
>>>>>>>>>>
>>>>>>>>>>   - Public TextUIDrawing interface is added to the 
>>>>>>>>>> javax.swing.plaf
>>>>>>>>>> package
>>>>>>>>>>   - TextUIDrawing methods description does not mention component
>>>>>>>>>> properties to be more general
>>>>>>>>>>   - TextUIDrawing methods are made default
>>>>>>>>>>   - L&F sets an instance of the TextUIDrawing to look and feel
>>>>>>>>>> defaults using "uiDrawing.text" property
>>>>>>>>>>   - ComponentUI class is not changed
>>>>>>>>>>   - Each ComponentUI reads TextUIDrawing from UI defaults
>>>>>>>>>>   - There is an interesting issue described in
>>>>>>>>>> http://mail.openjdk.java.net/pipermail/swing-dev/2016-March/005509.html 
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>     which is related to the fact that MetalLabelUI returns a 
>>>>>>>>>> static
>>>>>>>>>> field from createUI() method.
>>>>>>>>>>     TitleBorder creates a JLabel but does not put it to any
>>>>>>>>>> component
>>>>>>>>>> hierarchy. In this case SwingUtilities.updateComponentTreeUI()
>>>>>>>>>> method
>>>>>>>>>> calls MetalLabelUI.uninstallDefaults() on the static 
>>>>>>>>>> metalLabelUI
>>>>>>>>>> field and sets a new LabelUI for ordinary labels. The 
>>>>>>>>>> TitleBorder
>>>>>>>>>> label UI is not changed in this case and it still uses the
>>>>>>>>>> metalLabelUI field which is not initialized.
>>>>>>>>>>     It seems that other applications can also use components
>>>>>>>>>> just for
>>>>>>>>>> drawing and have the same issue.
>>>>>>>>>>     For this case the textUIDrawing field is not cleared in the
>>>>>>>>>> uninstallDefaults but just set to a static default value which
>>>>>>>>>> should
>>>>>>>>>> not lead to memory leaks.
>>>>>>>>>>
>>>>>>>>>>   Thanks,
>>>>>>>>>>   Alexandr.
>>>>>>>>>>
>>>>>>>>>> On 29/01/16 19:51, Alexander Scherbatiy wrote:
>>>>>>>>>>> On 25/01/16 13:44, Andrej Golovnin wrote:
>>>>>>>>>>>> Hi Alexandr,
>>>>>>>>>>>>
>>>>>>>>>>>>> Could you review the updated fix:
>>>>>>>>>>>>> http://cr.openjdk.java.net/~alexsch/8132119/webrev.07/
>>>>>>>>>>>> ....
>>>>>>>>>>>>> - public TextUIDrawing interface is added to the
>>>>>>>>>>>>> javax.swing.plaf
>>>>>>>>>>>>> package
>>>>>>>>>>>>> - public "TextUIDrawing getTextUIDrawing()" method is added
>>>>>>>>>>>>> to the
>>>>>>>>>>>>> ComponentUI class
>>>>>>>>>>>>> - L&F sets an instance of the TextUIDrawing to look and feel
>>>>>>>>>>>>> defaults using
>>>>>>>>>>>>> "uiDrawing.text" property
>>>>>>>>>>>>> - Look and Feel delegates use the instance of the 
>>>>>>>>>>>>> TextUIDrawing
>>>>>>>>>>>>> for text
>>>>>>>>>>>>> drawing and measuring
>>>>>>>>>>>> Some thoughts on the current design/implementation:
>>>>>>>>>>>>
>>>>>>>>>>>> By adding a field to the ComponentUI class the current
>>>>>>>>>>>> implementation increases
>>>>>>>>>>>> memory consumption for all Swing applications. And you get the
>>>>>>>>>>>> feeling that
>>>>>>>>>>>> there are different implementations of TextUIDrawing per
>>>>>>>>>>>> ComponentUI instances.
>>>>>>>>>>>> Personally I can't imagine to have different 
>>>>>>>>>>>> implementations of
>>>>>>>>>>>> TextUIDrawing for
>>>>>>>>>>>> a given LookAndFeel. If I would design/implement it, then I 
>>>>>>>>>>>> would
>>>>>>>>>>>> implement it as
>>>>>>>>>>>> a property of the LookAndFeel class (similar to 
>>>>>>>>>>>> LayoutStyle) and
>>>>>>>>>>>> not
>>>>>>>>>>>> the ComponentUI.
>>>>>>>>>>>> Developers can use then the following code to obtain the
>>>>>>>>>>>> instance of
>>>>>>>>>>>> TextUIDrawing:
>>>>>>>>>>>>
>>>>>>>>>>>> UIManager.getLookAndFeel().getUIDrawing() // or
>>>>>>>>>>>> UIManager.getLookAndFeelUIDrawing() // use this static method
>>>>>>>>>>>> as a
>>>>>>>>>>>> short cut for the line above.
>>>>>>>>>>>   LayoutStyle keeps its instance per App context. The same 
>>>>>>>>>>> is for
>>>>>>>>>>> the LookAndFeel
>>>>>>>>>>>   when it is got through UIManager.getLookAndFeel() call.
>>>>>>>>>>>   It means that accessing an instance of a TextUIDrawing will
>>>>>>>>>>> leads
>>>>>>>>>>> to a time consumption.
>>>>>>>>>>>
>>>>>>>>>>>   There are 3 main ways of the SwingUtilities2.drawString(...)
>>>>>>>>>>> usage:
>>>>>>>>>>>   1. ComponentUI classes
>>>>>>>>>>>   2. Components created in UI (like 
>>>>>>>>>>> BasicInternalFrameTitlePane)
>>>>>>>>>>>   3. Public utilities methods (like
>>>>>>>>>>> WindowsGraphicsUtils.paintText())
>>>>>>>>>>>
>>>>>>>>>>>   For the cases 1 and 2 it is possible to load and store the
>>>>>>>>>>> UIDrawing instance during installUI()/updateUI() calls to
>>>>>>>>>>> decrease a
>>>>>>>>>>> time access to it.
>>>>>>>>>>>
>>>>>>>>>>>   For the case 3 it is necessary to get LookAndFeel instance 
>>>>>>>>>>> each
>>>>>>>>>>> time (which is taken from an App context)
>>>>>>>>>>>   or use the passed JComponent object. It requires to have a
>>>>>>>>>>> public
>>>>>>>>>>> method and the associated variable for each instance of
>>>>>>>>>>> JComponent/ComponentUI/... class.
>>>>>>>>>>>> You can use this methods then in JDK too.
>>>>>>>>>>>>
>>>>>>>>>>>> And maybe rename the TextUIDrawing class to just UIDrawing and
>>>>>>>>>>>> add
>>>>>>>>>>>> more useful methods,
>>>>>>>>>>>> e.g. a method to create a composite font, a method to convert
>>>>>>>>>>>> DLUs
>>>>>>>>>>>> to pixels.
>>>>>>>>>>>   UIDrawing name may look like it should be used for any UI
>>>>>>>>>>> drawing,
>>>>>>>>>>> not only for text ones. I am afraid that it can be misleading.
>>>>>>>>>>>
>>>>>>>>>>>   Thanks,
>>>>>>>>>>>   Alexandr.
>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Best regards,
>>>>>>>>>>>> Andrej Golovnin
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>>
>>>
>>
>>



From Sergey.Bylokhov at oracle.com  Fri Apr  8 19:55:09 2016
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Fri, 8 Apr 2016 22:55:09 +0300
Subject: <Swing Dev> [9] Review request for 8132119 Provide public API
 for text related methods in SwingUtilities2
In-Reply-To: <5707FFEA.7010201@oracle.com>
References: <55E715A1.3090008@oracle.com> <55E72D3A.60807@oracle.com>
	<55ED586F.5070509@oracle.com> <55F6DC3C.60809@oracle.com>
	<5655D3AB.9050503@oracle.com> <5668051E.7090401@oracle.com>
	<5668E226.5000604@oracle.com> <5669646E.4070305@oracle.com>
	<566986FD.9020207@oracle.com> <5694F0C3.8020203@oracle.com>
	<5695572F.6070709@oracle.com> <56966730.7000701@oracle.com>
	<5698C71A.80703@oracle.com> <56991ED9.5030302@oracle.com>
	<569963B6.2050604@oracle.com> <56A5C40B.7010107@oracle.com>
	<CAM6ZMz8iEFQQtSb_bAVU5eUH=J=HapvKq3+Ana4pPxueJD1bNg@mail.gmail.com>
	<56AB8A94.2070404@oracle.com> <56EC2389.3020507@oracle.com>
	<56F38B0B.3060700@oracle.com> <56F3F13A.9000808@oracle.com>
	<56F3F83C.3010706@oracle.com> <56FD791E.1050707@oracle.com>
	<5705705C.2010007@oracle.com> <570631C9.7090601@oracle.com>
	<5706699D.5030904@oracle.com> <5707EE24.80309@oracle.com>
	<5707F9C4.7040803@oracle.com> <5707FFEA.7010201@oracle.com>
Message-ID: <57080C9D.8070809@oracle.com>

Looks fine, Thanks.

On 08.04.16 22:00, Alexander Scherbatiy wrote:
>
>   Hello,
>
>   Could you review the updated fix:
>    http://cr.openjdk.java.net/~alexsch/8132119/webrev.11/
>
>   - @throws tag is added in javadoc for methods in BasicTextUIDrawing class
>   -  unchecked exceptions are removed from methods throws declaration
>
>    Thanks,
>    Alexandr.
>
> On 08/04/16 22:34, Kevin Rushforth wrote:
>> Just my $0.02 (feel free to ignore).
>>
>> Specifying "throws" on a method for an unchecked exception like NPE
>> seems odd. Typically, only checked exceptions are declared. Both
>> checked and unchecked exceptions can and should be documented with
>> @throws.
>>
>> -- Kevin
>>
>>
>> Sergey Bylokhov wrote:
>>> On 07.04.16 17:07, Alexander Scherbatiy wrote:
>>>>    Could you review the updated fix:
>>>>      http://cr.openjdk.java.net/~alexsch/8132119/webrev.10
>>>
>>> Looks fine to me, but I am curious how often we use "throws NPE" in
>>> public API (especially w/o "@throws NPE" in javadoc).
>>>
>>>>
>>>> On 07/04/16 14:09, Sergey Bylokhov wrote:
>>>>> On 06.04.16 23:23, Alexander Scherbatiy wrote:
>>>>>> Could you review the updated fix:
>>>>>>    http://cr.openjdk.java.net/~alexsch/8132119/webrev.09
>>>>>
>>>>> There is tiny typos
>>>>> TextUIDrawing.getClippedString():
>>>>>     "@param c the component"
>>>>>     I guess it should be:
>>>>>     "@param c the component, may be null"
>>>>    Updated.
>>>>> BasicTextUIDrawing:
>>>>>     There is no dots at the end of the description of the class.
>>>>>
>>>>> I am not sure but will javadoc automatically copy the @throws tag from
>>>>> the parent tag? For example @throws NullPointerException to
>>>>> BasicTextUIDrawing.drawString().
>>>>
>>>>     I added throws NPE to the BasicTextUIDrawing class methods. It
>>>> forces copying @throws tag from the parent javadoc.
>>>>
>>>>    Thanks,
>>>>    Alexandr.
>>>>>
>>>>>>> But I can imagine they may also be handy when someone would
>>>>>>> typically
>>>>>>> want to implement
>>>>>>> only one or two out of a larger number in an interface and the
>>>>>>> default
>>>>>>> and you for some
>>>>>>> reason don't want to do that with an abstract class (notably you
>>>>>>> want
>>>>>>> an other class to
>>>>>>> be able to implement the interface).
>>>>>>>
>>>>>>> So what do I think about the case where the interface is brand
>>>>>>> new and
>>>>>>> what you've done is more or less implement a concrete class, but
>>>>>>> it's
>>>>>>> one that
>>>>>>> can be mixed in to another class ? Is that an appropriate use ?
>>>>>>>
>>>>>>> Maybe the test to pass in that case is whether the default
>>>>>>> implementation
>>>>>>> is going to be satisfactory for 90% of uses. If they are frequently
>>>>>>> over-ridden
>>>>>>> it would not be an appropriate use.
>>>>>>    Using this argument it seems if someone wants to implement the
>>>>>> TextUIDrawing it needs to override all its methods to keep them in
>>>>>> sync.
>>>>>> Because of this I moved the TextUIDrawing implementation to the
>>>>>> separate
>>>>>> javax.swing.plaf.basic.BasicTextUIDrawing class.
>>>>>
>>>>> I am fine, just one note. Now we have the interface, and the class
>>>>> without any state, and
>>>>>  - If the users need to implement the only one method, then it will be
>>>>> necessary to subclass a BasicTextUIDrawing, which will limit the
>>>>> possible class hierarchy.
>>>>>  - If the user most of the time will need to implement all methods to
>>>>> make them in sync he also can override BasicTextUIDrawing, then why we
>>>>> need the interface?
>>>>>
>>>>>>>
>>>>>>> Based on that criterion I think it is OK to use here.
>>>>>>>
>>>>>>> Another thought:
>>>>>>> When you add default implementations you should also be on the hook
>>>>>>> for explaining what that does. It is a deeper contract than you
>>>>>>> would
>>>>>>> otherwise have as an interface and maybe needs to be an @implNote
>>>>>>> or you need to call out the default implementation.
>>>>>>> ie there is what someone must code to satisfy the contract of the
>>>>>>> interface and what is a behaviour in the default method ?
>>>>>>    I added the addition "using text properties and anti-aliasing
>>>>>> hints
>>>>>> from the provided component" description to the BasicTextUIDrawing
>>>>>> class. There is always a question how many details a method
>>>>>> description
>>>>>> should contain. It is not clear for  me should, for example, the used
>>>>>> numeric shaper be listed in the description or not? Especially when
>>>>>> there is an enhancement that the methods implementation should
>>>>>> take more
>>>>>> text attributes  into account.
>>>>>>
>>>>>>> Also here is a link to some comments by Brian Goetz on default
>>>>>>> methods :
>>>>>>>
>>>>>>> http://stackoverflow.com/questions/28681737/java-8-default-methods-as-traits-safe/28684917#28684917
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>   75      * No character is underlined if the index is negative or
>>>>>>> greater
>>>>>>>   76      * than the string length {@code (index < 0 || index >=
>>>>>>> string.length())}
>>>>>>>   77      * or if the char value specified at the given index
>>>>>>>   78      * is in the low-surrogate range.
>>>>>>>
>>>>>>>
>>>>>>> I suppose if you point at the last char and it is a hi-surrogate
>>>>>>> nothing is underlined in that case either.
>>>>>>>
>>>>>>> But I find the whole writing of this a bit inadequate as if you are
>>>>>>> going to
>>>>>>> this kind of detail you perhaps also need to say what happens in a
>>>>>>> complex
>>>>>>> script where what happens is two unicode characters end up as a
>>>>>>> ligature,
>>>>>>> and/or perhaps you aren't even pointing to a base character.
>>>>>>> Maybe it is in fact over-specified. I see that the implementation
>>>>>>> draws
>>>>>>> the underline itself rather than delegate to TextLayout. This might
>>>>>>> make sense for performance reasons where it is simple text but
>>>>>>> some day
>>>>>>> this maybe should be re-examined and so I would not over-specify it.
>>>>>>>
>>>>>>> How about :
>>>>>>> "The underline will be positioned at the base glyph which
>>>>>>> represents the valid char indicated by the index.
>>>>>>> If the char index is not valid or is not the index of a
>>>>>>> valid unicode code point then no underline is drawn"
>>>>>>    Updated.
>>>>>>
>>>>>>    Thanks,
>>>>>>    Alexandr.
>>>>>>>
>>>>>>> -phil.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On 03/24/2016 07:22 AM, Sergey Bylokhov wrote:
>>>>>>>> On 24.03.16 16:52, Alexander Scherbatiy wrote:
>>>>>>>>> On 24/03/16 10:36, Semyon Sadetsky wrote:
>>>>>>>>>> Hi Alexander,
>>>>>>>>>>
>>>>>>>>>> Could you answer one question:
>>>>>>>>>> Why did you choose default interface methods to implement
>>>>>>>>>> TextUIDrawing and not implement them in DefaultTextUIDrawing
>>>>>>>>>> having
>>>>>>>>>> declarations only in the interface?
>>>>>>>>>> AFAIK the common point of view is default methods should be used
>>>>>>>>>> rarely because they may lead to unreadable code.
>>>>>>>>>>
>>>>>>>>>    The only problem which I know about default methods is multiple
>>>>>>>>> inheritance which has its own solution.
>>>>>>>>
>>>>>>>> What kind of problems? The benefit is obvious: it will not be
>>>>>>>> necessary to implement all methods if only one of them should be
>>>>>>>> tweaked.
>>>>>>>>
>>>>>>>>>
>>>>>>>>>    Could you give links to discussion or provide use cases where
>>>>>>>>> default
>>>>>>>>> methods leads to the unreadable code and show how does it relate
>>>>>>>>> to the
>>>>>>>>> TextUIDrawing  implementation?
>>>>>>>>>
>>>>>>>>>    Thanks,
>>>>>>>>>    Alexandr.
>>>>>>>>>> --Semyon
>>>>>>>>>>
>>>>>>>>>> On 3/18/2016 6:49 PM, Alexander Scherbatiy wrote:
>>>>>>>>>>>
>>>>>>>>>>> Could you review the updated fix:
>>>>>>>>>>> http://cr.openjdk.java.net/~alexsch/8132119/webrev.08/
>>>>>>>>>>>
>>>>>>>>>>>   - Public TextUIDrawing interface is added to the
>>>>>>>>>>> javax.swing.plaf
>>>>>>>>>>> package
>>>>>>>>>>>   - TextUIDrawing methods description does not mention component
>>>>>>>>>>> properties to be more general
>>>>>>>>>>>   - TextUIDrawing methods are made default
>>>>>>>>>>>   - L&F sets an instance of the TextUIDrawing to look and feel
>>>>>>>>>>> defaults using "uiDrawing.text" property
>>>>>>>>>>>   - ComponentUI class is not changed
>>>>>>>>>>>   - Each ComponentUI reads TextUIDrawing from UI defaults
>>>>>>>>>>>   - There is an interesting issue described in
>>>>>>>>>>> http://mail.openjdk.java.net/pipermail/swing-dev/2016-March/005509.html
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>     which is related to the fact that MetalLabelUI returns a
>>>>>>>>>>> static
>>>>>>>>>>> field from createUI() method.
>>>>>>>>>>>     TitleBorder creates a JLabel but does not put it to any
>>>>>>>>>>> component
>>>>>>>>>>> hierarchy. In this case SwingUtilities.updateComponentTreeUI()
>>>>>>>>>>> method
>>>>>>>>>>> calls MetalLabelUI.uninstallDefaults() on the static
>>>>>>>>>>> metalLabelUI
>>>>>>>>>>> field and sets a new LabelUI for ordinary labels. The
>>>>>>>>>>> TitleBorder
>>>>>>>>>>> label UI is not changed in this case and it still uses the
>>>>>>>>>>> metalLabelUI field which is not initialized.
>>>>>>>>>>>     It seems that other applications can also use components
>>>>>>>>>>> just for
>>>>>>>>>>> drawing and have the same issue.
>>>>>>>>>>>     For this case the textUIDrawing field is not cleared in the
>>>>>>>>>>> uninstallDefaults but just set to a static default value which
>>>>>>>>>>> should
>>>>>>>>>>> not lead to memory leaks.
>>>>>>>>>>>
>>>>>>>>>>>   Thanks,
>>>>>>>>>>>   Alexandr.
>>>>>>>>>>>
>>>>>>>>>>> On 29/01/16 19:51, Alexander Scherbatiy wrote:
>>>>>>>>>>>> On 25/01/16 13:44, Andrej Golovnin wrote:
>>>>>>>>>>>>> Hi Alexandr,
>>>>>>>>>>>>>
>>>>>>>>>>>>>> Could you review the updated fix:
>>>>>>>>>>>>>> http://cr.openjdk.java.net/~alexsch/8132119/webrev.07/
>>>>>>>>>>>>> ....
>>>>>>>>>>>>>> - public TextUIDrawing interface is added to the
>>>>>>>>>>>>>> javax.swing.plaf
>>>>>>>>>>>>>> package
>>>>>>>>>>>>>> - public "TextUIDrawing getTextUIDrawing()" method is added
>>>>>>>>>>>>>> to the
>>>>>>>>>>>>>> ComponentUI class
>>>>>>>>>>>>>> - L&F sets an instance of the TextUIDrawing to look and feel
>>>>>>>>>>>>>> defaults using
>>>>>>>>>>>>>> "uiDrawing.text" property
>>>>>>>>>>>>>> - Look and Feel delegates use the instance of the
>>>>>>>>>>>>>> TextUIDrawing
>>>>>>>>>>>>>> for text
>>>>>>>>>>>>>> drawing and measuring
>>>>>>>>>>>>> Some thoughts on the current design/implementation:
>>>>>>>>>>>>>
>>>>>>>>>>>>> By adding a field to the ComponentUI class the current
>>>>>>>>>>>>> implementation increases
>>>>>>>>>>>>> memory consumption for all Swing applications. And you get the
>>>>>>>>>>>>> feeling that
>>>>>>>>>>>>> there are different implementations of TextUIDrawing per
>>>>>>>>>>>>> ComponentUI instances.
>>>>>>>>>>>>> Personally I can't imagine to have different
>>>>>>>>>>>>> implementations of
>>>>>>>>>>>>> TextUIDrawing for
>>>>>>>>>>>>> a given LookAndFeel. If I would design/implement it, then I
>>>>>>>>>>>>> would
>>>>>>>>>>>>> implement it as
>>>>>>>>>>>>> a property of the LookAndFeel class (similar to
>>>>>>>>>>>>> LayoutStyle) and
>>>>>>>>>>>>> not
>>>>>>>>>>>>> the ComponentUI.
>>>>>>>>>>>>> Developers can use then the following code to obtain the
>>>>>>>>>>>>> instance of
>>>>>>>>>>>>> TextUIDrawing:
>>>>>>>>>>>>>
>>>>>>>>>>>>> UIManager.getLookAndFeel().getUIDrawing() // or
>>>>>>>>>>>>> UIManager.getLookAndFeelUIDrawing() // use this static method
>>>>>>>>>>>>> as a
>>>>>>>>>>>>> short cut for the line above.
>>>>>>>>>>>>   LayoutStyle keeps its instance per App context. The same
>>>>>>>>>>>> is for
>>>>>>>>>>>> the LookAndFeel
>>>>>>>>>>>>   when it is got through UIManager.getLookAndFeel() call.
>>>>>>>>>>>>   It means that accessing an instance of a TextUIDrawing will
>>>>>>>>>>>> leads
>>>>>>>>>>>> to a time consumption.
>>>>>>>>>>>>
>>>>>>>>>>>>   There are 3 main ways of the SwingUtilities2.drawString(...)
>>>>>>>>>>>> usage:
>>>>>>>>>>>>   1. ComponentUI classes
>>>>>>>>>>>>   2. Components created in UI (like
>>>>>>>>>>>> BasicInternalFrameTitlePane)
>>>>>>>>>>>>   3. Public utilities methods (like
>>>>>>>>>>>> WindowsGraphicsUtils.paintText())
>>>>>>>>>>>>
>>>>>>>>>>>>   For the cases 1 and 2 it is possible to load and store the
>>>>>>>>>>>> UIDrawing instance during installUI()/updateUI() calls to
>>>>>>>>>>>> decrease a
>>>>>>>>>>>> time access to it.
>>>>>>>>>>>>
>>>>>>>>>>>>   For the case 3 it is necessary to get LookAndFeel instance
>>>>>>>>>>>> each
>>>>>>>>>>>> time (which is taken from an App context)
>>>>>>>>>>>>   or use the passed JComponent object. It requires to have a
>>>>>>>>>>>> public
>>>>>>>>>>>> method and the associated variable for each instance of
>>>>>>>>>>>> JComponent/ComponentUI/... class.
>>>>>>>>>>>>> You can use this methods then in JDK too.
>>>>>>>>>>>>>
>>>>>>>>>>>>> And maybe rename the TextUIDrawing class to just UIDrawing and
>>>>>>>>>>>>> add
>>>>>>>>>>>>> more useful methods,
>>>>>>>>>>>>> e.g. a method to create a composite font, a method to convert
>>>>>>>>>>>>> DLUs
>>>>>>>>>>>>> to pixels.
>>>>>>>>>>>>   UIDrawing name may look like it should be used for any UI
>>>>>>>>>>>> drawing,
>>>>>>>>>>>> not only for text ones. I am afraid that it can be misleading.
>>>>>>>>>>>>
>>>>>>>>>>>>   Thanks,
>>>>>>>>>>>>   Alexandr.
>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> Best regards,
>>>>>>>>>>>>> Andrej Golovnin
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>
>>>
>


-- 
Best regards, Sergey.


From semyon.sadetsky at oracle.com  Mon Apr 11 06:33:12 2016
From: semyon.sadetsky at oracle.com (Semyon Sadetsky)
Date: Mon, 11 Apr 2016 09:33:12 +0300
Subject: <Swing Dev> [9] Review request for 8132119 Provide public API
 for text related methods in SwingUtilities2
In-Reply-To: <5707FFEA.7010201@oracle.com>
References: <55E715A1.3090008@oracle.com> <55E72D3A.60807@oracle.com>
	<55ED586F.5070509@oracle.com> <55F6DC3C.60809@oracle.com>
	<5655D3AB.9050503@oracle.com> <5668051E.7090401@oracle.com>
	<5668E226.5000604@oracle.com> <5669646E.4070305@oracle.com>
	<566986FD.9020207@oracle.com> <5694F0C3.8020203@oracle.com>
	<5695572F.6070709@oracle.com> <56966730.7000701@oracle.com>
	<5698C71A.80703@oracle.com> <56991ED9.5030302@oracle.com>
	<569963B6.2050604@oracle.com> <56A5C40B.7010107@oracle.com>
	<CAM6ZMz8iEFQQtSb_bAVU5eUH=J=HapvKq3+Ana4pPxueJD1bNg@mail.gmail.com>
	<56AB8A94.2070404@oracle.com> <56EC2389.3020507@oracle.com>
	<56F38B0B.3060700@oracle.com> <56F3F13A.9000808@oracle.com>
	<56F3F83C.3010706@oracle.com> <56FD791E.1050707@oracle.com>
	<5705705C.2010007@oracle.com> <570631C9.7090601@oracle.com>
	<5706699D.5030904@oracle.com> <5707EE24.80309@oracle.com>
	<5707F9C4.7040803@oracle.com> <5707FFEA.7010201@oracle.com>
Message-ID: <570B4528.8020305@oracle.com>

Looks good.

--Semyon

On 4/8/2016 10:00 PM, Alexander Scherbatiy wrote:
>
>  Hello,
>
>  Could you review the updated fix:
>   http://cr.openjdk.java.net/~alexsch/8132119/webrev.11/
>
>  - @throws tag is added in javadoc for methods in BasicTextUIDrawing 
> class
>  -  unchecked exceptions are removed from methods throws declaration
>
>   Thanks,
>   Alexandr.
>
> On 08/04/16 22:34, Kevin Rushforth wrote:
>> Just my $0.02 (feel free to ignore).
>>
>> Specifying "throws" on a method for an unchecked exception like NPE 
>> seems odd. Typically, only checked exceptions are declared. Both 
>> checked and unchecked exceptions can and should be documented with 
>> @throws.
>>
>> -- Kevin
>>
>>
>> Sergey Bylokhov wrote:
>>> On 07.04.16 17:07, Alexander Scherbatiy wrote:
>>>>    Could you review the updated fix:
>>>>      http://cr.openjdk.java.net/~alexsch/8132119/webrev.10
>>>
>>> Looks fine to me, but I am curious how often we use "throws NPE" in 
>>> public API (especially w/o "@throws NPE" in javadoc).
>>>
>>>>
>>>> On 07/04/16 14:09, Sergey Bylokhov wrote:
>>>>> On 06.04.16 23:23, Alexander Scherbatiy wrote:
>>>>>> Could you review the updated fix:
>>>>>>    http://cr.openjdk.java.net/~alexsch/8132119/webrev.09
>>>>>
>>>>> There is tiny typos
>>>>> TextUIDrawing.getClippedString():
>>>>>     "@param c the component"
>>>>>     I guess it should be:
>>>>>     "@param c the component, may be null"
>>>>    Updated.
>>>>> BasicTextUIDrawing:
>>>>>     There is no dots at the end of the description of the class.
>>>>>
>>>>> I am not sure but will javadoc automatically copy the @throws tag 
>>>>> from
>>>>> the parent tag? For example @throws NullPointerException to
>>>>> BasicTextUIDrawing.drawString().
>>>>
>>>>     I added throws NPE to the BasicTextUIDrawing class methods. It
>>>> forces copying @throws tag from the parent javadoc.
>>>>
>>>>    Thanks,
>>>>    Alexandr.
>>>>>
>>>>>>> But I can imagine they may also be handy when someone would 
>>>>>>> typically
>>>>>>> want to implement
>>>>>>> only one or two out of a larger number in an interface and the 
>>>>>>> default
>>>>>>> and you for some
>>>>>>> reason don't want to do that with an abstract class (notably you 
>>>>>>> want
>>>>>>> an other class to
>>>>>>> be able to implement the interface).
>>>>>>>
>>>>>>> So what do I think about the case where the interface is brand 
>>>>>>> new and
>>>>>>> what you've done is more or less implement a concrete class, but 
>>>>>>> it's
>>>>>>> one that
>>>>>>> can be mixed in to another class ? Is that an appropriate use ?
>>>>>>>
>>>>>>> Maybe the test to pass in that case is whether the default
>>>>>>> implementation
>>>>>>> is going to be satisfactory for 90% of uses. If they are frequently
>>>>>>> over-ridden
>>>>>>> it would not be an appropriate use.
>>>>>>    Using this argument it seems if someone wants to implement the
>>>>>> TextUIDrawing it needs to override all its methods to keep them 
>>>>>> in sync.
>>>>>> Because of this I moved the TextUIDrawing implementation to the 
>>>>>> separate
>>>>>> javax.swing.plaf.basic.BasicTextUIDrawing class.
>>>>>
>>>>> I am fine, just one note. Now we have the interface, and the class
>>>>> without any state, and
>>>>>  - If the users need to implement the only one method, then it 
>>>>> will be
>>>>> necessary to subclass a BasicTextUIDrawing, which will limit the
>>>>> possible class hierarchy.
>>>>>  - If the user most of the time will need to implement all methods to
>>>>> make them in sync he also can override BasicTextUIDrawing, then 
>>>>> why we
>>>>> need the interface?
>>>>>
>>>>>>>
>>>>>>> Based on that criterion I think it is OK to use here.
>>>>>>>
>>>>>>> Another thought:
>>>>>>> When you add default implementations you should also be on the hook
>>>>>>> for explaining what that does. It is a deeper contract than you 
>>>>>>> would
>>>>>>> otherwise have as an interface and maybe needs to be an @implNote
>>>>>>> or you need to call out the default implementation.
>>>>>>> ie there is what someone must code to satisfy the contract of the
>>>>>>> interface and what is a behaviour in the default method ?
>>>>>>    I added the addition "using text properties and anti-aliasing 
>>>>>> hints
>>>>>> from the provided component" description to the BasicTextUIDrawing
>>>>>> class. There is always a question how many details a method 
>>>>>> description
>>>>>> should contain. It is not clear for  me should, for example, the 
>>>>>> used
>>>>>> numeric shaper be listed in the description or not? Especially when
>>>>>> there is an enhancement that the methods implementation should 
>>>>>> take more
>>>>>> text attributes  into account.
>>>>>>
>>>>>>> Also here is a link to some comments by Brian Goetz on default
>>>>>>> methods :
>>>>>>>
>>>>>>> http://stackoverflow.com/questions/28681737/java-8-default-methods-as-traits-safe/28684917#28684917 
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>   75      * No character is underlined if the index is negative or
>>>>>>> greater
>>>>>>>   76      * than the string length {@code (index < 0 || index >=
>>>>>>> string.length())}
>>>>>>>   77      * or if the char value specified at the given index
>>>>>>>   78      * is in the low-surrogate range.
>>>>>>>
>>>>>>>
>>>>>>> I suppose if you point at the last char and it is a hi-surrogate
>>>>>>> nothing is underlined in that case either.
>>>>>>>
>>>>>>> But I find the whole writing of this a bit inadequate as if you are
>>>>>>> going to
>>>>>>> this kind of detail you perhaps also need to say what happens in a
>>>>>>> complex
>>>>>>> script where what happens is two unicode characters end up as a
>>>>>>> ligature,
>>>>>>> and/or perhaps you aren't even pointing to a base character.
>>>>>>> Maybe it is in fact over-specified. I see that the 
>>>>>>> implementation draws
>>>>>>> the underline itself rather than delegate to TextLayout. This might
>>>>>>> make sense for performance reasons where it is simple text but 
>>>>>>> some day
>>>>>>> this maybe should be re-examined and so I would not over-specify 
>>>>>>> it.
>>>>>>>
>>>>>>> How about :
>>>>>>> "The underline will be positioned at the base glyph which
>>>>>>> represents the valid char indicated by the index.
>>>>>>> If the char index is not valid or is not the index of a
>>>>>>> valid unicode code point then no underline is drawn"
>>>>>>    Updated.
>>>>>>
>>>>>>    Thanks,
>>>>>>    Alexandr.
>>>>>>>
>>>>>>> -phil.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On 03/24/2016 07:22 AM, Sergey Bylokhov wrote:
>>>>>>>> On 24.03.16 16:52, Alexander Scherbatiy wrote:
>>>>>>>>> On 24/03/16 10:36, Semyon Sadetsky wrote:
>>>>>>>>>> Hi Alexander,
>>>>>>>>>>
>>>>>>>>>> Could you answer one question:
>>>>>>>>>> Why did you choose default interface methods to implement
>>>>>>>>>> TextUIDrawing and not implement them in DefaultTextUIDrawing 
>>>>>>>>>> having
>>>>>>>>>> declarations only in the interface?
>>>>>>>>>> AFAIK the common point of view is default methods should be used
>>>>>>>>>> rarely because they may lead to unreadable code.
>>>>>>>>>>
>>>>>>>>>    The only problem which I know about default methods is 
>>>>>>>>> multiple
>>>>>>>>> inheritance which has its own solution.
>>>>>>>>
>>>>>>>> What kind of problems? The benefit is obvious: it will not be
>>>>>>>> necessary to implement all methods if only one of them should be
>>>>>>>> tweaked.
>>>>>>>>
>>>>>>>>>
>>>>>>>>>    Could you give links to discussion or provide use cases where
>>>>>>>>> default
>>>>>>>>> methods leads to the unreadable code and show how does it relate
>>>>>>>>> to the
>>>>>>>>> TextUIDrawing  implementation?
>>>>>>>>>
>>>>>>>>>    Thanks,
>>>>>>>>>    Alexandr.
>>>>>>>>>> --Semyon
>>>>>>>>>>
>>>>>>>>>> On 3/18/2016 6:49 PM, Alexander Scherbatiy wrote:
>>>>>>>>>>>
>>>>>>>>>>> Could you review the updated fix:
>>>>>>>>>>> http://cr.openjdk.java.net/~alexsch/8132119/webrev.08/
>>>>>>>>>>>
>>>>>>>>>>>   - Public TextUIDrawing interface is added to the 
>>>>>>>>>>> javax.swing.plaf
>>>>>>>>>>> package
>>>>>>>>>>>   - TextUIDrawing methods description does not mention 
>>>>>>>>>>> component
>>>>>>>>>>> properties to be more general
>>>>>>>>>>>   - TextUIDrawing methods are made default
>>>>>>>>>>>   - L&F sets an instance of the TextUIDrawing to look and feel
>>>>>>>>>>> defaults using "uiDrawing.text" property
>>>>>>>>>>>   - ComponentUI class is not changed
>>>>>>>>>>>   - Each ComponentUI reads TextUIDrawing from UI defaults
>>>>>>>>>>>   - There is an interesting issue described in
>>>>>>>>>>> http://mail.openjdk.java.net/pipermail/swing-dev/2016-March/005509.html 
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>     which is related to the fact that MetalLabelUI returns a 
>>>>>>>>>>> static
>>>>>>>>>>> field from createUI() method.
>>>>>>>>>>>     TitleBorder creates a JLabel but does not put it to any
>>>>>>>>>>> component
>>>>>>>>>>> hierarchy. In this case SwingUtilities.updateComponentTreeUI()
>>>>>>>>>>> method
>>>>>>>>>>> calls MetalLabelUI.uninstallDefaults() on the static 
>>>>>>>>>>> metalLabelUI
>>>>>>>>>>> field and sets a new LabelUI for ordinary labels. The 
>>>>>>>>>>> TitleBorder
>>>>>>>>>>> label UI is not changed in this case and it still uses the
>>>>>>>>>>> metalLabelUI field which is not initialized.
>>>>>>>>>>>     It seems that other applications can also use components
>>>>>>>>>>> just for
>>>>>>>>>>> drawing and have the same issue.
>>>>>>>>>>>     For this case the textUIDrawing field is not cleared in the
>>>>>>>>>>> uninstallDefaults but just set to a static default value which
>>>>>>>>>>> should
>>>>>>>>>>> not lead to memory leaks.
>>>>>>>>>>>
>>>>>>>>>>>   Thanks,
>>>>>>>>>>>   Alexandr.
>>>>>>>>>>>
>>>>>>>>>>> On 29/01/16 19:51, Alexander Scherbatiy wrote:
>>>>>>>>>>>> On 25/01/16 13:44, Andrej Golovnin wrote:
>>>>>>>>>>>>> Hi Alexandr,
>>>>>>>>>>>>>
>>>>>>>>>>>>>> Could you review the updated fix:
>>>>>>>>>>>>>> http://cr.openjdk.java.net/~alexsch/8132119/webrev.07/
>>>>>>>>>>>>> ....
>>>>>>>>>>>>>> - public TextUIDrawing interface is added to the
>>>>>>>>>>>>>> javax.swing.plaf
>>>>>>>>>>>>>> package
>>>>>>>>>>>>>> - public "TextUIDrawing getTextUIDrawing()" method is added
>>>>>>>>>>>>>> to the
>>>>>>>>>>>>>> ComponentUI class
>>>>>>>>>>>>>> - L&F sets an instance of the TextUIDrawing to look and feel
>>>>>>>>>>>>>> defaults using
>>>>>>>>>>>>>> "uiDrawing.text" property
>>>>>>>>>>>>>> - Look and Feel delegates use the instance of the 
>>>>>>>>>>>>>> TextUIDrawing
>>>>>>>>>>>>>> for text
>>>>>>>>>>>>>> drawing and measuring
>>>>>>>>>>>>> Some thoughts on the current design/implementation:
>>>>>>>>>>>>>
>>>>>>>>>>>>> By adding a field to the ComponentUI class the current
>>>>>>>>>>>>> implementation increases
>>>>>>>>>>>>> memory consumption for all Swing applications. And you get 
>>>>>>>>>>>>> the
>>>>>>>>>>>>> feeling that
>>>>>>>>>>>>> there are different implementations of TextUIDrawing per
>>>>>>>>>>>>> ComponentUI instances.
>>>>>>>>>>>>> Personally I can't imagine to have different 
>>>>>>>>>>>>> implementations of
>>>>>>>>>>>>> TextUIDrawing for
>>>>>>>>>>>>> a given LookAndFeel. If I would design/implement it, then 
>>>>>>>>>>>>> I would
>>>>>>>>>>>>> implement it as
>>>>>>>>>>>>> a property of the LookAndFeel class (similar to 
>>>>>>>>>>>>> LayoutStyle) and
>>>>>>>>>>>>> not
>>>>>>>>>>>>> the ComponentUI.
>>>>>>>>>>>>> Developers can use then the following code to obtain the
>>>>>>>>>>>>> instance of
>>>>>>>>>>>>> TextUIDrawing:
>>>>>>>>>>>>>
>>>>>>>>>>>>> UIManager.getLookAndFeel().getUIDrawing() // or
>>>>>>>>>>>>> UIManager.getLookAndFeelUIDrawing() // use this static method
>>>>>>>>>>>>> as a
>>>>>>>>>>>>> short cut for the line above.
>>>>>>>>>>>>   LayoutStyle keeps its instance per App context. The same 
>>>>>>>>>>>> is for
>>>>>>>>>>>> the LookAndFeel
>>>>>>>>>>>>   when it is got through UIManager.getLookAndFeel() call.
>>>>>>>>>>>>   It means that accessing an instance of a TextUIDrawing will
>>>>>>>>>>>> leads
>>>>>>>>>>>> to a time consumption.
>>>>>>>>>>>>
>>>>>>>>>>>>   There are 3 main ways of the SwingUtilities2.drawString(...)
>>>>>>>>>>>> usage:
>>>>>>>>>>>>   1. ComponentUI classes
>>>>>>>>>>>>   2. Components created in UI (like 
>>>>>>>>>>>> BasicInternalFrameTitlePane)
>>>>>>>>>>>>   3. Public utilities methods (like
>>>>>>>>>>>> WindowsGraphicsUtils.paintText())
>>>>>>>>>>>>
>>>>>>>>>>>>   For the cases 1 and 2 it is possible to load and store the
>>>>>>>>>>>> UIDrawing instance during installUI()/updateUI() calls to
>>>>>>>>>>>> decrease a
>>>>>>>>>>>> time access to it.
>>>>>>>>>>>>
>>>>>>>>>>>>   For the case 3 it is necessary to get LookAndFeel 
>>>>>>>>>>>> instance each
>>>>>>>>>>>> time (which is taken from an App context)
>>>>>>>>>>>>   or use the passed JComponent object. It requires to have a
>>>>>>>>>>>> public
>>>>>>>>>>>> method and the associated variable for each instance of
>>>>>>>>>>>> JComponent/ComponentUI/... class.
>>>>>>>>>>>>> You can use this methods then in JDK too.
>>>>>>>>>>>>>
>>>>>>>>>>>>> And maybe rename the TextUIDrawing class to just UIDrawing 
>>>>>>>>>>>>> and
>>>>>>>>>>>>> add
>>>>>>>>>>>>> more useful methods,
>>>>>>>>>>>>> e.g. a method to create a composite font, a method to convert
>>>>>>>>>>>>> DLUs
>>>>>>>>>>>>> to pixels.
>>>>>>>>>>>>   UIDrawing name may look like it should be used for any UI
>>>>>>>>>>>> drawing,
>>>>>>>>>>>> not only for text ones. I am afraid that it can be misleading.
>>>>>>>>>>>>
>>>>>>>>>>>>   Thanks,
>>>>>>>>>>>>   Alexandr.
>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> Best regards,
>>>>>>>>>>>>> Andrej Golovnin
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>
>>>
>



From semyon.sadetsky at oracle.com  Mon Apr 11 07:24:13 2016
From: semyon.sadetsky at oracle.com (Semyon Sadetsky)
Date: Mon, 11 Apr 2016 10:24:13 +0300
Subject: <Swing Dev> Review-request for 8145547: JEP 283: [AWT/Swing]
 Conditional support for GTK 3 on Linux
In-Reply-To: <5707E45A.6070008@oracle.com>
References: <56DB4C3B.1060902@oracle.com> <56E864DE.4000706@oracle.com>
	<56E99D68.90208@oracle.com> <56EAA99E.2040104@oracle.com>
	<56EAB064.9040403@oracle.com> <56EADE8A.9060508@oracle.com>
	<56EB0C31.20300@oracle.com> <56EBFC4A.3080908@oracle.com>
	<5703F00A.4020000@oracle.com> <5704BB8F.2070709@oracle.com>
	<5707E45A.6070008@oracle.com>
Message-ID: <570B511D.10300@oracle.com>

Please review the new update: 
http://cr.openjdk.java.net/~ssadetsky/8145547/webrev.06/

The changes applied:
gtk_interface.c: Algorithm to detect already loaded GTK library is 
changed to search the library name in /proc/self/map file data.
Thus the library detection is improved for the case when an other loaded 
library has dependency on GTK library.

--Semyon

On 4/8/2016 8:03 PM, Semyon Sadetsky wrote:
> The fix was updated to take into account defects discovered by parfait:
>
> (*env)->ExceptionCheck(env); is removed from the 
> gtk3_get_drawable_data() in gtk2_interface.c and gtk3_interface.c 
> because GetPrimitiveArrayCritical()/ ReleasePrimitiveArrayCritical() 
> do not throw exceptions.
>
> xx and yy variables in the gtk3_paint_arrow() of gtk3_interface.c 
> might not be initialized.
>
> The updated webrev: 
> http://cr.openjdk.java.net/~ssadetsky/8145547/webrev.05/
>
> --Semyon
>
>
> On 4/6/2016 10:32 AM, Alexander Scherbatiy wrote:
>>
>>   The fix looks good to me.
>>
>>   Thanks,
>>   Alexandr.
>>
>> On 4/5/2016 8:04 PM, Semyon Sadetsky wrote:
>>> The fix is updated because JEP 272 was pushed. JEP 272 has 
>>> dependency on GTK.
>>>
>>> http://cr.openjdk.java.net/~ssadetsky/8145547/webrev.04/
>>>
>>> --Semyon
>>>
>>> On 3/18/2016 4:02 PM, Semyon Sadetsky wrote:
>>>>
>>>>
>>>> On 3/17/2016 10:57 PM, Phil Race wrote:
>>>>> I ran your changes (which included my fix) through jprt and all 
>>>>> Solaris platforms failed as follows :-
>>>>>
>>>>> jdk/src/java.desktop/unix/native/libawt_xawt/awt/sun_awt_X11_GtkFileDialogPeer.c", 
>>>>> line 37: error: typedef redeclared: GtkWindow (E_TYPEDEF_REDECLARED)
>>>>> cc: acomp failed for 
>>>>> jdk/src/java.desktop/unix/native/libawt_xawt/awt/sun_awt_X11_GtkFileDialogPeer.c
>>>>>
>>>> I have fixed the Solaris build: 
>>>> http://cr.openjdk.java.net/~ssadetsky/8145547/webrev.03/.
>>>>
>>>> > gint intval = NULL;
>>>> I think this happens with you specific compiler only. Old 
>>>> gtk2_interface.c always contained the same line.
>>>>
>>>> I ran JPRT with webrev.03. The URL is:
>>>> http://sthjprt.uk.oracle.com/archives/2016/03/2016-03-18-070745.ssadetsk.client/ 
>>>>
>>>> It seem macosx_x64_10.9-product-c2-jdk_math build failed because of 
>>>> another change. (?) Could you help me to interpret the JPRT job 
>>>> status?
>>>>
>>>> --Semyon
>>>>>
>>>>> -phil.
>>>>>
>>>>> On 03/17/2016 09:42 AM, Phil Race wrote:
>>>>>> This reminded me I had not yet tried the build myself.
>>>>>> When I did I not get the error that Sergey did but I got this as 
>>>>>> well :-
>>>>>>
>>>>>> jdk9-client/jdk/src/java.desktop/unix/native/libawt_xawt/awt/gtk3_interface.c: 
>>>>>> In function ?get_integer_property?:
>>>>>> jdk9-client/jdk/src/java.desktop/unix/native/libawt_xawt/awt/gtk3_interface.c:2542:19: 
>>>>>> error: initialization makes integer from pointer without a cast 
>>>>>> [-Werror]
>>>>>> jdk9-client/jdk/src/java.desktop/unix/native/libawt_xawt/awt/gtk3_interface.c: 
>>>>>> In function ?get_boolean_property?:
>>>>>> jdk9-client/jdk/src/java.desktop/unix/native/libawt_xawt/awt/gtk3_interface.c:2549:19: 
>>>>>> error: initialization makes integer from pointer without
>>>>>>
>>>>>> Both lines it complains about were :
>>>>>>
>>>>>>     gint intval = NULL;
>>>>>>
>>>>>> I changed them to
>>>>>>        gint intval = 0;
>>>>>>
>>>>>> I am not using the 'official' compiler, but you really should 
>>>>>> make sure jprt is
>>>>>> happy before confirming the webrev as final - and also fix all of 
>>>>>> these even if
>>>>>> the official compiler does not complain.
>>>>>>
>>>>>> And I did not notice any problems running SwingSet2 with either 
>>>>>> of GTK2 or GTK3
>>>>>> specified. It at least ran fine and clearly picked up different 
>>>>>> versions.
>>>>>>
>>>>>>
>>>>>> -phil.
>>>>>>
>>>>>>
>>>>>> On 03/17/2016 06:25 AM, Semyon Sadetsky wrote:
>>>>>>> The awt_Desktop.c is missed in the webrev.
>>>>>>> Please see the updated one: 
>>>>>>> http://cr.openjdk.java.net/~ssadetsky/8145547/webrev.02/
>>>>>>>
>>>>>>> --Semyon
>>>>>>>
>>>>>>> On 3/17/2016 3:57 PM, Sergey Bylokhov wrote:
>>>>>>>> On 16.03.16 20:52, Semyon Sadetsky wrote:
>>>>>>>>> Hi Phil,
>>>>>>>>>
>>>>>>>>> Thank for review. You will find my reply below in the text.
>>>>>>>>>
>>>>>>>>> The updated webrev is
>>>>>>>>> http://cr.openjdk.java.net/~ssadetsky/8145547/webrev.01/
>>>>>>>>
>>>>>>>> On my system this version fails to build(Ubuntu 15.10 + gcc 
>>>>>>>> 5.2.1):
>>>>>>>>
>>>>>>>> ERROR: Build failed for target 'images' in configuration 
>>>>>>>> 'linux-x86_64-normal-server-release' (exit code 2)
>>>>>>>> === Output from failing command(s) repeated here ===
>>>>>>>> * For target 
>>>>>>>> support_native_java.desktop_libawt_xawt_awt_Desktop.o:
>>>>>>>> /mnt/hgfs/moe/workspaces/jdk/9/client-gate/jdk/src/java.desktop/unix/native/libawt_xawt/xawt/awt_Desktop.c: 
>>>>>>>> In function ?Java_sun_awt_X11_XDesktopPeer_init?:
>>>>>>>> /mnt/hgfs/moe/workspaces/jdk/9/client-gate/jdk/src/java.desktop/unix/native/libawt_xawt/xawt/awt_Desktop.c:46:9: 
>>>>>>>> error: implicit declaration of function ?gtk2_load? 
>>>>>>>> [-Werror=implicit-function-declaration]
>>>>>>>>      if (gtk2_load(env) && gtk2_show_uri_load(env)) {
>>>>>>>>          ^
>>>>>>>> /mnt/hgfs/moe/workspaces/jdk/9/client-gate/jdk/src/java.desktop/unix/native/libawt_xawt/xawt/awt_Desktop.c:46:27: 
>>>>>>>> error: implicit declaration of function ?gtk2_show_uri_load? 
>>>>>>>> [-Werror=implicit-function-declaration]
>>>>>>>>      if (gtk2_load(env) && gtk2_show_uri_load(env)) {
>>>>>>>>                            ^
>>>>>>>> cc1: all warnings being treated as errors
>>>>>>>> === End of repeated output ===
>>>>>>>> === Make failure sequence repeated here ===
>>>>>>>> Awt2dLibraries.gmk:369: recipe for target 
>>>>>>>> '/mnt/hgfs/moe/workspaces/jdk/9/client-gate/build/linux-x86_64-normal-server-release/support/native/java.desktop/libawt_xawt/awt_Desktop.o' 
>>>>>>>> failed
>>>>>>>> make/Main.gmk:175: recipe for target 'java.desktop-libs' failed
>>>>>>>> === End of repeated output ===
>>>>>>>>
>>>>>>>>
>>>>>>>>> It also contains:
>>>>>>>>> - new properties jdk.gtk.version and jdk.gtk.verbose
>>>>>>>>> - appearance tuning for Ubuntu 15 (GTK 3.14). It may require 
>>>>>>>>> more but we
>>>>>>>>> can do this later as a separate bug.
>>>>>>>>> The main implementation was done for Ubuntu 14.05 LTS (GTK 
>>>>>>>>> 3.10) and
>>>>>>>>> then tuned for OEL 7 (GTK 3.8). Each minor GTK version may 
>>>>>>>>> have some
>>>>>>>>> appearance changes.
>>>>>>>>>
>>>>>>>>> On 3/15/2016 10:39 PM, Phil Race wrote:
>>>>>>>>>> There is a lot to read here. I think I need to patch and try 
>>>>>>>>>> it but
>>>>>>>>>> first ...
>>>>>>>>>>
>>>>>>>>>> Two high level questions :
>>>>>>>>>> 1) Have you verified that this behaves properly (or no worse 
>>>>>>>>>> than
>>>>>>>>>> currently) with -Djava.awt.headless=true since Swing components
>>>>>>>>>> are supposed to be able to draw off-screen in headless mode 
>>>>>>>>>> .. and
>>>>>>>>>> yet a dependency on GTK and its dependency on xlibraries 
>>>>>>>>>> seems to mean
>>>>>>>>>> that you can't load GTK in this case.
>>>>>>>>>> BTW I think it may be painful to get them to layout in such a 
>>>>>>>>>> case
>>>>>>>>>> but that's another issue.
>>>>>>>>> I tested it by painting to a BufferedImage. Seems it is enough.
>>>>>>>>>>
>>>>>>>>>> 2) Have you tried a hi-dpi system ?
>>>>>>>>> Yes I have. It is identical to the existing GTK2 based 
>>>>>>>>> appearance.
>>>>>>>>>>
>>>>>>>>>> 3) Have you submitted a JPRT job ? It is essential to know 
>>>>>>>>>> that this
>>>>>>>>>> builds cleanly on the "official" compilation environment.
>>>>>>>>> I will do this before the push. I think it will be OK because 
>>>>>>>>> I did not
>>>>>>>>> use any new C constructs and the new libraries are linked 
>>>>>>>>> dynamically.
>>>>>>>>>> 4)I expect you ran Swingset2 + GTK L&F but have you run any 
>>>>>>>>>> of the
>>>>>>>>>> regression test suite ?
>>>>>>>>> Yes I ran javax/swing tests but many of them fails with GTK2 
>>>>>>>>> as well.
>>>>>>>>> With GTK3 the result was the same except for some unstable 
>>>>>>>>> tests. Unity
>>>>>>>>> desktop has new window decorations like borderless windows 
>>>>>>>>> which are
>>>>>>>>> resized by dragging the outer window shadow, invisible overlay
>>>>>>>>> scrollbars, etc. Many tests written for old window decorations 
>>>>>>>>> fails.
>>>>>>>>>>
>>>>>>>>>> Minor comments :
>>>>>>>>>>
>>>>>>>>>> GTKEngine.java
>>>>>>>>>>
>>>>>>>>>>  494         Container parent = 
>>>>>>>>>> context.getComponent().getParent();
>>>>>>>>>>  495         if(GTKLookAndFeel.is3()) {
>>>>>>>>>>  496             if (parent != null && parent.getParent() 
>>>>>>>>>> instanceof
>>>>>>>>>> JComboBox) {
>>>>>>>>>>  497                 if (parent.getParent().hasFocus()) {
>>>>>>>>>>  498                     synthState |= SynthConstants.FOCUSED;
>>>>>>>>>>  499                 }
>>>>>>>>>>  500             }
>>>>>>>>>>  501         }
>>>>>>>>>>
>>>>>>>>>> GTKPainter.java
>>>>>>>>>>
>>>>>>>>>> 746         if (GTKLookAndFeel.is3()) {
>>>>>>>>>>  747             if (slider.getOrientation() == 
>>>>>>>>>> JSlider.VERTICAL) {
>>>>>>>>>>  748                 y += 1;
>>>>>>>>>>  749                 h -= 2;
>>>>>>>>>>  750             } else {
>>>>>>>>>>  751                 x += 1;
>>>>>>>>>>  752                 w -= 2;
>>>>>>>>>>  753             }
>>>>>>>>>>  754         }
>>>>>>>>>>
>>>>>>>>>> I don't know where these numbers come from or what coordinate 
>>>>>>>>>> system
>>>>>>>>>> is being used here but it seems you are changing them for gtk 
>>>>>>>>>> 2.2 as
>>>>>>>>>> well as 3
>>>>>>>>>> Can you speak to this ?
>>>>>>>>> It is an appearance tuning for GTK3. I didn't change it for 
>>>>>>>>> GTK2, why do
>>>>>>>>> you think so?
>>>>>>>>> This was used before my fix as well, for example
>>>>>>>>>
>>>>>>>>>                      if (containerParent instanceof JComboBox) {
>>>>>>>>>                          x += (focusSize + 2);
>>>>>>>>>                          y += (focusSize + 1);
>>>>>>>>>                          w -= (2 * focusSize + 1);
>>>>>>>>>                          h -= (2 * focusSize + 2);
>>>>>>>>>                      } else {
>>>>>>>>>                          x += focusSize;
>>>>>>>>>                          y += focusSize;
>>>>>>>>>                          w -= 2 * focusSize;
>>>>>>>>>                          h -= 2 * focusSize;
>>>>>>>>>                      }
>>>>>>>>>
>>>>>>>>> The only place where I changed the existing GTK2 appearance is:
>>>>>>>>>
>>>>>>>>> 1121 CLASS_SPECIFIC_MAP.put("Slider.thumbWidth", 
>>>>>>>>> "slider-length");
>>>>>>>>>
>>>>>>>>>   in GTKStyle.java, because this property was omitted by mistake.
>>>>>>>>>>
>>>>>>>>>> GTKStyle.java
>>>>>>>>>>
>>>>>>>>>> 735         if(!GTKLookAndFeel.is3()) {
>>>>>>>>>>
>>>>>>>>>> 840      } else if(GTKLookAndFeel.is3() &&
>>>>>>>>>> "ComboBox.forceOpaque".equals(key)) {
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> we prefer a space between "if" and "("
>>>>>>>>> Accepted.
>>>>>>>>>>
>>>>>>>>>> sun_awt_X11_GtkFileDialogPeer.c
>>>>>>>>>>
>>>>>>>>>>  392     if (gtk->gtk_check_version(2, 8, 0) == NULL) {
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Maybe I am not looking at the right fn but I thought I saw
>>>>>>>>>> this fn return a boolean so a check against NULL looks wrong.
>>>>>>>>> The declaration is in GtkApi struct of gtk_interface.h. It 
>>>>>>>>> returns
>>>>>>>>> char*. NULL means that the version is compatible.
>>>>>>>>>>
>>>>>>>>>>  393
>>>>>>>>>> gtk->gtk_file_chooser_set_do_overwrite_confirmation(GTK_FILE_CHOOSER( 
>>>>>>>>>>
>>>>>>>>>>  394                 dialog), TRUE);
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> You didn't add this but it is awfully specific about the GTK 
>>>>>>>>>> version and
>>>>>>>>>> I wonder if this test is doing what it should be doing on GTK 3?
>>>>>>>>> Accepted.
>>>>>>>>>>
>>>>>>>>>> It is interesting that some equivalent looking Java level dialog
>>>>>>>>>> checking in XToolkit.java
>>>>>>>>>> checked for 3.0 too ..
>>>>>>>>>>
>>>>>>>>>> swing_GTKEngine.c :
>>>>>>>>>>
>>>>>>>>>>   30 /* Static buffer for conversion from java.lang.String to 
>>>>>>>>>> UTF-8 */
>>>>>>>>>>   31 static char convertionBuffer[CONV_BUFFER_SIZE];
>>>>>>>>>>
>>>>>>>>>> So the variable name should be spelt conversionBuffer.
>>>>>>>>> Accepted.
>>>>>>>>>>
>>>>>>>>>> awt_UNIXToolkit.c
>>>>>>>>>>
>>>>>>>>>> < 287 free(ret);
>>>>>>>>>>
>>>>>>>>>> You deleted this free(). Is that correct ? It seems to imply
>>>>>>>>>> you now expect a boolean return as discussed above and
>>>>>>>>>> so in that case NULL looks odd here (line 260) too.
>>>>>>>>> The JNI exported method returns boolean while the GTK method 
>>>>>>>>> returns
>>>>>>>>> char*. free() is deleted intentionally according to the GTK 
>>>>>>>>> docs it
>>>>>>>>> belongs to the library and should not be freed by user code.
>>>>>>>>>>
>>>>>>>>>> gtk3_interface.h :
>>>>>>>>>>
>>>>>>>>>>   36 #define G_PI 
>>>>>>>>>> 3.1415926535897932384626433832795028841971693993751
>>>>>>>>>>
>>>>>>>>>> I don't think that is completely accurate :-) And I should have
>>>>>>>>>> reviewed this yesterday [1].
>>>>>>>>> :) This is glib's definition I just copied.
>>>>>>>>>
>>>>>>>>> --Semyon
>>>>>>>>>>
>>>>>>>>>> -phil.
>>>>>>>>>>
>>>>>>>>>> [1] http://www.piday.org/
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On 03/05/2016 01:14 PM, Semyon Sadetsky wrote:
>>>>>>>>>>> Hello,
>>>>>>>>>>>
>>>>>>>>>>> Please review fix for JDK9:
>>>>>>>>>>>
>>>>>>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8145547
>>>>>>>>>>> webrev: 
>>>>>>>>>>> http://cr.openjdk.java.net/~ssadetsky/8145547/webrev.00/
>>>>>>>>>>>
>>>>>>>>>>> The fix contains GTK3 based implementation for Swing GTK 
>>>>>>>>>>> LnF, AWT
>>>>>>>>>>> FileChooser for Linux and AWT Robot for Linux.
>>>>>>>>>>> Also the new system property is added to request specific 
>>>>>>>>>>> GTK version
>>>>>>>>>>> swing.gtk.version.
>>>>>>>>>>>
>>>>>>>>>>> --Semyon
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>

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

From semyon.sadetsky at oracle.com  Mon Apr 11 07:49:18 2016
From: semyon.sadetsky at oracle.com (Semyon Sadetsky)
Date: Mon, 11 Apr 2016 10:49:18 +0300
Subject: <Swing Dev> Review-request for 8145547: JEP 283: [AWT/Swing]
 Conditional support for GTK 3 on Linux
In-Reply-To: <57078C9E.2080409@oracle.com>
References: <56DB4C3B.1060902@oracle.com> <56E864DE.4000706@oracle.com>
	<56E99D68.90208@oracle.com> <56EA9929.9020605@oracle.com>
	<56EBF688.1090006@oracle.com> <56ED7507.1090204@oracle.com>
	<56EFF685.1090702@oracle.com> <56EFFC8A.1010306@oracle.com>
	<56F044BF.2000609@oracle.com> <56F0498A.4090802@oracle.com>
	<56F04BBD.1030102@oracle.com> <56F051FD.3000203@oracle.com>
	<56F05BB5.2080209@oracle.com> <57078C9E.2080409@oracle.com>
Message-ID: <570B56FE.20109@oracle.com>

Sergey,

I yet do not understand your arguments unless the synchronization issue 
(it took place before the current fix and it is better to investigate it 
separately).
But I think this topic is important and shouldn't be lost. I would 
suggest you to file a JIRA ticket with description of bad scenarios from 
the flexible "jdk.gtk.version" property your see. It would be also great 
if you provide test cases. Then we will systematize all pros and cons 
and elaborate the final solution. Are you good with that?

--Semyon

On 4/8/2016 1:49 PM, Sergey Bylokhov wrote:
> On 21.03.16 23:38, Semyon Sadetsky wrote:
>>> This does not solve the problem when check/init/load will try to use
>>> the different versions. I guess I provided enough arguments to
>>> initialize these data only once.
>> I've already explained that GTK library cannot be loaded twice, only one
>> version may be loaded regardless of the property value.
>
> We already found that there is a problem in synchronization, there is 
> some other cases, which can be introduced in the future. To eliminate 
> even the possibility of such missconfigurationion, it would be better 
> try to load only the one version which was set by "jdk.gtk.version" 
> for the first time. It will solve bunch of possible issues.
>
>>> It will be better to make it obvious and not to depends on some order.
>>> I am curious where you find it widely used. At least in the client I
>>> found only one usage.
>> I can help you. Look at GTKEngine.java: WidgetType, StateType, Settings,
>> ShadowType, Orientation, PositionType, etc...
>
> Thanks, this all in one file of gtk look and feel. This is a bad 
> pattern, and we should not copy it to the UnixToolkit class. For 
> additional information read the spec of ordinal method and "Effective 
> Java" by Josh Bloch Item 31.
>
> Also I am not sure that I understand where we survive the hang which 
> can occur if we try to load the gtk library if it was loaded before by 
> the other applications(like fx or swt).
>



From chris.hegarty at oracle.com  Sun Apr  3 15:24:21 2016
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Sun, 3 Apr 2016 16:24:21 +0100
Subject: <Swing Dev> RFR: 8147544: Remove sun.misc.ManagedLocalsThread
	from java.desktop
In-Reply-To: <56FEF3D4.9060704@oracle.com>
References: <56FEF3D4.9060704@oracle.com>
Message-ID: <67BE8102-8D6D-4E12-A947-5F60DCF1BABB@oracle.com>


On 1 Apr 2016, at 23:19, Phil Race <philip.race at oracle.com> wrote:

> Bug: https://bugs.openjdk.java.net/browse/JDK-8147544
> Fix: http://cr.openjdk.java.net/~prr/8147544/

Your changes look ok to me.  Thanks for doing this Phil.

-Chris.

> ManagedLocalThreads is now superseded by a standard
> constructor on java.lang.Thread :-
> http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/f90cd2c011bc
> 
> The various places in JDK that use the internal API need to migrate to this.
> 
> This fix addresses all (I hope) such usages in java.desktop.
> 
> I had to invent names for threads in numerous places since
> the required constructor insists on one.
> 
> Most uses install a Runnable but in about 4 cases we need to extend Thread.
> In those cases I added a comment, and in some cases a private no-args
> constructor() to try to guard against anyone coming along later and accidentally
> adding & calling a wrong super-class constructor.
> 
> JPRT has been used to verify the build on all platforms and I am
> in the process of running some sanity checks on the major
> platforms to make sure nothing unexpected happens but
> in general real testing of all of these changes is going to only happen
> with a nearly full test run, so the earlier the better to get the changes in.
> 
> -phil.
> 
> 



From Reto.Merz at abacus.ch  Mon Apr  4 13:54:13 2016
From: Reto.Merz at abacus.ch (Reto Merz)
Date: Mon, 04 Apr 2016 15:54:13 +0200
Subject: <Swing Dev> Public RequestFocusController/AWTAccessor API
Message-ID: <57028E250200005B000C8808@mail.abacus.ch>

Hello,

Jigsaw will disallow access to internal packages.
We have written a complex validation and focus management
implementation
for our closed-source RIA and maintain it since JRE 1.4.

For this we use some internal API. We have a custom implementation of
these interfaces:

sun.awt.RequestFocusController
sun.awt.AWTAccessor.ComponentAccessor

And use this getter and setter:

sun.awt.AWTAccessor#setComponentAccessor(AWTAccessor.ComponentAccessor)
sun.awt.AWTAccessor#getComponentAccessor()
sun.awt.AWTAccessor.ComponentAccessor#setRequestFocusController(RequestFocusController)

Please make this API public.

Furthermore we need to call
java.awt.Component#revalidateSynchronously().
We do this with reflection. It would be nice to have a public API for
this.
Maybe a new static method on AWTAccessor:
AWTAccessor.revalidateSynchronously(Component)

Best Regards
Reto Merz



From guy.abossolo.foh at scientificware.com  Thu Apr  7 17:32:56 2016
From: guy.abossolo.foh at scientificware.com (Abossolo Foh Guy)
Date: Thu, 07 Apr 2016 19:32:56 +0200
Subject: <Swing Dev> JDK-7169915 : Swing Table Layout bad repaint of the row
Message-ID: <10a2e304a839b0a906142fb108e41ee7@scientificware.com>

Hello,

Could you apply the modification I suggested 4 years ago about the Bug : 
JDK-7169915 : Swing Table Layout bad repaint of the row.

The test case I had sent in 2012 is the same I used in : JDK-8133864 
Wrong display, when the document I18n properties is true.

A version of this test (called I18nLayoutTest.java) is now candidate as 
part of tests for JDK 9 (/test/javax/swing/text/TableView/)

Yours faithfully.


-- 
Abossolo Foh Guy
71 rue Guy de Maupassant
69500 Bron


From christian.thalinger at oracle.com  Fri Apr  8 19:05:48 2016
From: christian.thalinger at oracle.com (Christian Thalinger)
Date: Fri, 8 Apr 2016 09:05:48 -1000
Subject: <Swing Dev> [9] Review Request: 6832045
	DefaultSynthStyle.{getStateInfo,
	getMatchCount) should use Integer.bitCount
In-Reply-To: <57079DAF.6030401@oracle.com>
References: <57079DAF.6030401@oracle.com>
Message-ID: <1CD249CC-FBF0-4580-AA20-51F87DA4FE2A@oracle.com>

Excellent.  Thanks for finally getting around to fix it.

> On Apr 8, 2016, at 2:01 AM, Sergey Bylokhov <Sergey.Bylokhov at oracle.com> wrote:
> 
> Hello,
> Please review the small cleanup for jdk9.
> 
> The code which was copied from BigInteger.bitCnt() replaced by Integer.bitCount().
> Note that this code is removed from BigInteger class itself and also replaced by Integer.bitCount [1].
> 
> The getMatchCount() method is removed, because initially(long ago) it was used in place which was changed in the fix. But now it is unused.
> 
> [1] http://hg.openjdk.java.net/jdk9/client/jdk/rev/8d2efec31d78
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-6832045
> Webrev can be found at: http://cr.openjdk.java.net/~serb/6832045/webrev.00
> 
> -- 
> Best regards, Sergey.



From alexandr.scherbatiy at oracle.com  Mon Apr 11 08:26:24 2016
From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy)
Date: Mon, 11 Apr 2016 11:26:24 +0300
Subject: <Swing Dev> Public RequestFocusController/AWTAccessor API
In-Reply-To: <57028E250200005B000C8808@mail.abacus.ch>
References: <57028E250200005B000C8808@mail.abacus.ch>
Message-ID: <570B5FB0.20807@oracle.com>


  Resending the request to awt-dev alias.

  Thanks,
  Alexandr.

On 4/4/2016 4:54 PM, Reto Merz wrote:
> Hello,
>
> Jigsaw will disallow access to internal packages.
> We have written a complex validation and focus management
> implementation
> for our closed-source RIA and maintain it since JRE 1.4.
>
> For this we use some internal API. We have a custom implementation of
> these interfaces:
>
> sun.awt.RequestFocusController
> sun.awt.AWTAccessor.ComponentAccessor
>
> And use this getter and setter:
>
> sun.awt.AWTAccessor#setComponentAccessor(AWTAccessor.ComponentAccessor)
> sun.awt.AWTAccessor#getComponentAccessor()
> sun.awt.AWTAccessor.ComponentAccessor#setRequestFocusController(RequestFocusController)
>
> Please make this API public.
>
> Furthermore we need to call
> java.awt.Component#revalidateSynchronously().
> We do this with reflection. It would be nice to have a public API for
> this.
> Maybe a new static method on AWTAccessor:
> AWTAccessor.revalidateSynchronously(Component)
>
> Best Regards
> Reto Merz
>



From alexandr.scherbatiy at oracle.com  Mon Apr 11 11:18:19 2016
From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy)
Date: Mon, 11 Apr 2016 14:18:19 +0300
Subject: <Swing Dev> Result: New Swing Group Member: Semyon Sadetsky
Message-ID: <570B87FB.8000708@oracle.com>


The vote for Semyon Sadetsky [1] is now closed.

Yes: 4
Veto: 0
Abstain: 0

According to the Bylaws definition of Lazy Consensus, this is sufficient 
to approve the nomination.

Thanks,
Alexandr.

[1] http://mail.openjdk.java.net/pipermail/swing-dev/2016-March/005527.html
[2] http://openjdk.java.net/bylaws#lazy-consensus


From alexandr.scherbatiy at oracle.com  Mon Apr 11 15:02:28 2016
From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy)
Date: Mon, 11 Apr 2016 18:02:28 +0300
Subject: <Swing Dev> [9] Review Request for 8145787: [TEST_BUG][PIT]
 javax/swing/undo/UndoManager/AbstractDocumentUndoConcurrentTest.java fails
 with CannotUndoException
In-Reply-To: <5679548D.90104@oracle.com>
References: <5679548D.90104@oracle.com>
Message-ID: <570BBC84.3090206@oracle.com>

On 12/22/2015 4:47 PM, Semyon Sadetsky wrote:
> Hello,
>
> Please review fix for JDK9:
>
> bug: https://bugs.openjdk.java.net/browse/JDK-8145787
> webrev: http://cr.openjdk.java.net/~ssadetsky/8145787/webrev.00/
>
> This is a multithreading stress test in which the undo queue depth may 
> reach zero sometimes occasionally. The corresponding checks were added.
     What is the sequence of the threads leads that the exception is thrown?

    Thanks,
    Alexandr.

>
> --Semyon
>



From philip.race at oracle.com  Mon Apr 11 23:29:52 2016
From: philip.race at oracle.com (Philip Race)
Date: Mon, 11 Apr 2016 16:29:52 -0700
Subject: <Swing Dev> [9] Review request for 8132119 Provide public API
 for text related methods in SwingUtilities2
In-Reply-To: <5705705C.2010007@oracle.com>
References: <55E715A1.3090008@oracle.com> <55E72D3A.60807@oracle.com>
	<55ED586F.5070509@oracle.com> <55F6DC3C.60809@oracle.com>
	<5655D3AB.9050503@oracle.com> <5668051E.7090401@oracle.com>
	<5668E226.5000604@oracle.com> <5669646E.4070305@oracle.com>
	<566986FD.9020207@oracle.com> <5694F0C3.8020203@oracle.com>
	<5695572F.6070709@oracle.com> <56966730.7000701@oracle.com>
	<5698C71A.80703@oracle.com> <56991ED9.5030302@oracle.com>
	<569963B6.2050604@oracle.com> <56A5C40B.7010107@oracle.com>
	<CAM6ZMz8iEFQQtSb_bAVU5eUH=J=HapvKq3+Ana4pPxueJD1bNg@mail.gmail.com>
	<56AB8A94.2070404@oracle.com> <56EC2389.3020507@oracle.com>
	<56F38B0B.3060700@oracle.com> <56F3F13A.9000808@oracle.com>
	<56F3F83C.3010706@oracle.com> <56FD791E.1050707@oracle.com>
	<5705705C.2010007@oracle.com>
Message-ID: <570C3370.1090702@oracle.com>



On 4/6/16, 1:23 PM, Alexander Scherbatiy wrote:
>
> Hello,
>
> Could you review the updated fix:
>   http://cr.openjdk.java.net/~alexsch/8132119/webrev.09
>
>  - TextUIDrawing interface and its default implementaion 
> BasicTextUIDrawing class are added
>  - font metrics argument description is updated
>
> On 31/03/16 23:23, Phil Race wrote:
>> Another webrev where you have to slip past 40_ files to get to the 
>> two that really matter :-)
>> I would have put SwingUtilities2.java and TextUIDrawing.java as the 
>> first files.
>    Updated.
>>
>>
>> Some of what I have to say here is more along the lines of things to 
>> think
>> about rather than things that are wrong .. but there are also maybe 
>> some things
>> that need to be fixed.
>>
>> Is javax.swing.plaf really the right package for the new class ?
>> I suppose it is for the use by the UI classes so maybe its right.
>>
>> Should the methods be taking "double" instead of "int" for location ?
>> This means the measurement APIs too.
>> None of the JDK 1.2 text APIs use ints. That is all 1.0 legacy.
>> So if Swing internally wants to use ints that is OK but maybe the API
>> should be floating point (double).
>   The provided methods use Graphics as argument which only has 
> drawString(String, int, int) method.
>   If it is possible it is better to add the methods with float 
> arguments and Graphics2D later.
>
>> Would that  help hi-dpi at all ?
>   The hi-dpi support mostly does not require changes in Swing. What it 
> does just scales graphics using default transform from graphics 
> configuration.

Yes, but in another bug you are dealing with a problem positioning
the caret because of (somewhat) similar issues where coordinates have been
rounded to an integral. A floating point value allows you to say  that
this is 25.5 in user-space, even it if is 51.0 in device space.

>
>> I suppose it would add over-head since all the existing code uses int
>> and we are no worse off and can add double methods later if we want to.
>>
>>
>> Regarding FontMetrics we need to add a caution that is must be a 
>> FontMetrics
>> *obtained from the correct font and graphics*.
>    Updated.
>>
>>
>>  i.e what about attributes on the font such as "tracking" ?
>> or on the graphics such as FRACTIONALMETRICS
>> It looks like Swing might already fail if that were used.
>>
>> Look at this code :-
>>
>>    public static int stringWidth(JComponent c, FontMetrics fm, String 
>> string){
>>         if (string == null || string.equals("")) {
>>             return 0;
>>         }
>>         boolean needsTextLayout = ((c != null) &&
>> (c.getClientProperty(TextAttribute.NUMERIC_SHAPING) != null));
>>         if (needsTextLayout) {
>>             synchronized(charsBufferLock) {
>>                 int length = syncCharsBuffer(string);
>>                 needsTextLayout = isComplexLayout(charsBuffer, 0, 
>> length);
>>             }
>>         }
>>         if (needsTextLayout) {
>>             TextLayout layout = createTextLayout(c, string,
>>                                     fm.getFont(), 
>> fm.getFontRenderContext());
>>             return (int) layout.getAdvance();
>>         } else {
>>             return fm.stringWidth(string);
>>         }
>>     }
>>
>> The only thing Swing is looking at is one TextAttribute and whether 
>> we have complex text.
>> That is not enough. This is an existing implementation issue but one 
>> we should fix here.
>> You need to examine all the methods for similar issues.
>   I created an enhancement for this:
>     JDK-8153662 
> SwingUtilities2.drawString()/getStringWidth()/clipString() should use 
> more text attributes
>       https://bugs.openjdk.java.net/browse/JDK-8153662

you mean bug ? I upgraded it to P3 because it matters a lot more now
with this public API
>>
>> The usage of default methods is worth thinking about.
>> There is a significant subjective element to this and I've really 
>> thought only myself about
>> using them for the case where default methods are useful when you 
>> need to extend an
>> existing interface.
>>
>> But I can imagine they may also be handy when someone would typically 
>> want to implement
>> only one or two out of a larger number in an interface and the 
>> default and you for some
>> reason don't want to do that with an abstract class (notably you want 
>> an other class to
>> be able to implement the interface).
>>
>> So what do I think about the case where the interface is brand new and
>> what you've done is more or less implement a concrete class, but it's 
>> one that
>> can be mixed in to another class ? Is that an appropriate use ?
>>
>> Maybe the test to pass in that case is whether the default 
>> implementation
>> is going to be satisfactory for 90% of uses. If they are frequently 
>> over-ridden
>> it would not be an appropriate use.
>   Using this argument it seems if someone wants to implement the 
> TextUIDrawing it needs to override all its methods to keep them in 
> sync. Because of this I moved the TextUIDrawing implementation to the 
> separate javax.swing.plaf.basic.BasicTextUIDrawing class.

Fair enough although I wonder if by the same argument there is any point
in exposing BasicTextUIDrawing as a public class ? I don't have a strong
objection to exposing it, except that the name "Basic..." seems to 
invite subclassing ..

-phil
>>
>> Based on that criterion I think it is OK to use here.
>>
>> Another thought:
>> When you add default implementations you should also be on the hook
>> for explaining what that does. It is a deeper contract than you would
>> otherwise have as an interface and maybe needs to be an @implNote
>> or you need to call out the default implementation.
>> ie there is what someone must code to satisfy the contract of the
>> interface and what is a behaviour in the default method ?
>   I added the addition "using text properties and anti-aliasing hints 
> from the provided component" description to the BasicTextUIDrawing 
> class. There is always a question how many details a method 
> description should contain. It is not clear for  me should, for 
> example, the used numeric shaper be listed in the description or not? 
> Especially when there is an enhancement that the methods 
> implementation should take more text attributes  into account.
>
>> Also here is a link to some comments by Brian Goetz on default methods :
>>
>> http://stackoverflow.com/questions/28681737/java-8-default-methods-as-traits-safe/28684917#28684917 
>>
>>
>>   75      * No character is underlined if the index is negative or 
>> greater
>>   76      * than the string length {@code (index < 0 || index >= 
>> string.length())}
>>   77      * or if the char value specified at the given index
>>   78      * is in the low-surrogate range.
>>
>>
>> I suppose if you point at the last char and it is a hi-surrogate 
>> nothing is underlined in that case either.
>>
>> But I find the whole writing of this a bit inadequate as if you are 
>> going to
>> this kind of detail you perhaps also need to say what happens in a 
>> complex
>> script where what happens is two unicode characters end up as a 
>> ligature,
>> and/or perhaps you aren't even pointing to a base character.
>> Maybe it is in fact over-specified. I see that the implementation draws
>> the underline itself rather than delegate to TextLayout. This might
>> make sense for performance reasons where it is simple text but some day
>> this maybe should be re-examined and so I would not over-specify it.
>>
>> How about :
>> "The underline will be positioned at the base glyph which
>> represents the valid char indicated by the index.
>> If the char index is not valid or is not the index of a
>> valid unicode code point then no underline is drawn"
>   Updated.
>
>   Thanks,
>   Alexandr.
>>
>> -phil.
>>
>>
>>
>> On 03/24/2016 07:22 AM, Sergey Bylokhov wrote:
>>> On 24.03.16 16:52, Alexander Scherbatiy wrote:
>>>> On 24/03/16 10:36, Semyon Sadetsky wrote:
>>>>> Hi Alexander,
>>>>>
>>>>> Could you answer one question:
>>>>> Why did you choose default interface methods to implement
>>>>> TextUIDrawing and not implement them in DefaultTextUIDrawing having
>>>>> declarations only in the interface?
>>>>> AFAIK the common point of view is default methods should be used
>>>>> rarely because they may lead to unreadable code.
>>>>>
>>>>    The only problem which I know about default methods is multiple
>>>> inheritance which has its own solution.
>>>
>>> What kind of problems? The benefit is obvious: it will not be 
>>> necessary to implement all methods if only one of them should be 
>>> tweaked.
>>>
>>>>
>>>>    Could you give links to discussion or provide use cases where 
>>>> default
>>>> methods leads to the unreadable code and show how does it relate to 
>>>> the
>>>> TextUIDrawing  implementation?
>>>>
>>>>    Thanks,
>>>>    Alexandr.
>>>>> --Semyon
>>>>>
>>>>> On 3/18/2016 6:49 PM, Alexander Scherbatiy wrote:
>>>>>>
>>>>>> Could you review the updated fix:
>>>>>>   http://cr.openjdk.java.net/~alexsch/8132119/webrev.08/
>>>>>>
>>>>>>   - Public TextUIDrawing interface is added to the javax.swing.plaf
>>>>>> package
>>>>>>   - TextUIDrawing methods description does not mention component
>>>>>> properties to be more general
>>>>>>   - TextUIDrawing methods are made default
>>>>>>   - L&F sets an instance of the TextUIDrawing to look and feel
>>>>>> defaults using "uiDrawing.text" property
>>>>>>   - ComponentUI class is not changed
>>>>>>   - Each ComponentUI reads TextUIDrawing from UI defaults
>>>>>>   - There is an interesting issue described in
>>>>>> http://mail.openjdk.java.net/pipermail/swing-dev/2016-March/005509.html 
>>>>>>
>>>>>>     which is related to the fact that MetalLabelUI returns a static
>>>>>> field from createUI() method.
>>>>>>     TitleBorder creates a JLabel but does not put it to any 
>>>>>> component
>>>>>> hierarchy. In this case SwingUtilities.updateComponentTreeUI() 
>>>>>> method
>>>>>> calls MetalLabelUI.uninstallDefaults() on the static metalLabelUI
>>>>>> field and sets a new LabelUI for ordinary labels. The TitleBorder
>>>>>> label UI is not changed in this case and it still uses the
>>>>>> metalLabelUI field which is not initialized.
>>>>>>     It seems that other applications can also use components just 
>>>>>> for
>>>>>> drawing and have the same issue.
>>>>>>     For this case the textUIDrawing field is not cleared in the
>>>>>> uninstallDefaults but just set to a static default value which 
>>>>>> should
>>>>>> not lead to memory leaks.
>>>>>>
>>>>>>   Thanks,
>>>>>>   Alexandr.
>>>>>>
>>>>>> On 29/01/16 19:51, Alexander Scherbatiy wrote:
>>>>>>> On 25/01/16 13:44, Andrej Golovnin wrote:
>>>>>>>> Hi Alexandr,
>>>>>>>>
>>>>>>>>> Could you review the updated fix:
>>>>>>>>> http://cr.openjdk.java.net/~alexsch/8132119/webrev.07/
>>>>>>>> ....
>>>>>>>>> - public TextUIDrawing interface is added to the javax.swing.plaf
>>>>>>>>> package
>>>>>>>>> - public "TextUIDrawing getTextUIDrawing()" method is added to 
>>>>>>>>> the
>>>>>>>>> ComponentUI class
>>>>>>>>> - L&F sets an instance of the TextUIDrawing to look and feel
>>>>>>>>> defaults using
>>>>>>>>> "uiDrawing.text" property
>>>>>>>>> - Look and Feel delegates use the instance of the TextUIDrawing
>>>>>>>>> for text
>>>>>>>>> drawing and measuring
>>>>>>>> Some thoughts on the current design/implementation:
>>>>>>>>
>>>>>>>> By adding a field to the ComponentUI class the current
>>>>>>>> implementation increases
>>>>>>>> memory consumption for all Swing applications. And you get the
>>>>>>>> feeling that
>>>>>>>> there are different implementations of TextUIDrawing per
>>>>>>>> ComponentUI instances.
>>>>>>>> Personally I can't imagine to have different implementations of
>>>>>>>> TextUIDrawing for
>>>>>>>> a given LookAndFeel. If I would design/implement it, then I would
>>>>>>>> implement it as
>>>>>>>> a property of the LookAndFeel class (similar to LayoutStyle) 
>>>>>>>> and not
>>>>>>>> the ComponentUI.
>>>>>>>> Developers can use then the following code to obtain the 
>>>>>>>> instance of
>>>>>>>> TextUIDrawing:
>>>>>>>>
>>>>>>>> UIManager.getLookAndFeel().getUIDrawing() // or
>>>>>>>> UIManager.getLookAndFeelUIDrawing() // use this static method as a
>>>>>>>> short cut for the line above.
>>>>>>>   LayoutStyle keeps its instance per App context. The same is for
>>>>>>> the LookAndFeel
>>>>>>>   when it is got through UIManager.getLookAndFeel() call.
>>>>>>>   It means that accessing an instance of a TextUIDrawing will leads
>>>>>>> to a time consumption.
>>>>>>>
>>>>>>>   There are 3 main ways of the SwingUtilities2.drawString(...) 
>>>>>>> usage:
>>>>>>>   1. ComponentUI classes
>>>>>>>   2. Components created in UI (like BasicInternalFrameTitlePane)
>>>>>>>   3. Public utilities methods (like 
>>>>>>> WindowsGraphicsUtils.paintText())
>>>>>>>
>>>>>>>   For the cases 1 and 2 it is possible to load and store the
>>>>>>> UIDrawing instance during installUI()/updateUI() calls to 
>>>>>>> decrease a
>>>>>>> time access to it.
>>>>>>>
>>>>>>>   For the case 3 it is necessary to get LookAndFeel instance each
>>>>>>> time (which is taken from an App context)
>>>>>>>   or use the passed JComponent object. It requires to have a public
>>>>>>> method and the associated variable for each instance of
>>>>>>> JComponent/ComponentUI/... class.
>>>>>>>> You can use this methods then in JDK too.
>>>>>>>>
>>>>>>>> And maybe rename the TextUIDrawing class to just UIDrawing and add
>>>>>>>> more useful methods,
>>>>>>>> e.g. a method to create a composite font, a method to convert DLUs
>>>>>>>> to pixels.
>>>>>>>   UIDrawing name may look like it should be used for any UI 
>>>>>>> drawing,
>>>>>>> not only for text ones. I am afraid that it can be misleading.
>>>>>>>
>>>>>>>   Thanks,
>>>>>>>   Alexandr.
>>>>>>>
>>>>>>>>
>>>>>>>> Best regards,
>>>>>>>> Andrej Golovnin
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>>
>>
>


From semyon.sadetsky at oracle.com  Tue Apr 12 13:59:07 2016
From: semyon.sadetsky at oracle.com (Semyon Sadetsky)
Date: Tue, 12 Apr 2016 16:59:07 +0300
Subject: <Swing Dev> [9] Review request for 8153351: GTK Menu's have no
	border
Message-ID: <570CFF2B.60704@oracle.com>

Hello,

Please review fix for JDK9:
bug: https://bugs.openjdk.java.net/browse/JDK-8153351
webrev: http://cr.openjdk.java.net/~ssadetsky/8153351/webrev.00/

There are 2 issues here:
- so called "wide-separators" were not supported in GTK LnF. Metrics for 
those separators should be taken from another properties and they should 
be painted as boxes not lines. The fix adds supports for this GTK feature.
- The real insets of the popup menu should be taken into account when 
its background is painted, otherwise depending on the system theme there 
may be no space left for the popup menu border.
Since reproducible test scenario would require to setup the system theme 
the bug is labeled noreg-hard.

--Semyon


From semyon.sadetsky at oracle.com  Tue Apr 12 16:16:54 2016
From: semyon.sadetsky at oracle.com (Semyon Sadetsky)
Date: Tue, 12 Apr 2016 19:16:54 +0300
Subject: <Swing Dev> [9] Review Request for 8145787: [TEST_BUG][PIT]
 javax/swing/undo/UndoManager/AbstractDocumentUndoConcurrentTest.java fails
 with CannotUndoException
In-Reply-To: <570BBC84.3090206@oracle.com>
References: <5679548D.90104@oracle.com> <570BBC84.3090206@oracle.com>
Message-ID: <570D1F76.8050607@oracle.com>

On 4/11/2016 6:02 PM, Alexander Scherbatiy wrote:
> On 12/22/2015 4:47 PM, Semyon Sadetsky wrote:
>> Hello,
>>
>> Please review fix for JDK9:
>>
>> bug: https://bugs.openjdk.java.net/browse/JDK-8145787
>> webrev: http://cr.openjdk.java.net/~ssadetsky/8145787/webrev.00/
>>
>> This is a multithreading stress test in which the undo queue depth 
>> may reach zero sometimes occasionally. The corresponding checks were 
>> added.
>     What is the sequence of the threads leads that the exception is 
> thrown?
When undo() operation from t3 called more times than insertString() and 
remove() in t1 and t2. Note that undoOrRedo() in t3 is also may work as 
undo().

--Semyon
>
>    Thanks,
>    Alexandr.
>
>>
>> --Semyon
>>
>



From Sergey.Bylokhov at oracle.com  Tue Apr 12 17:01:23 2016
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Tue, 12 Apr 2016 20:01:23 +0300
Subject: <Swing Dev> [9] Review request for 8153351: GTK Menu's have no
 border
In-Reply-To: <570CFF2B.60704@oracle.com>
References: <570CFF2B.60704@oracle.com>
Message-ID: <570D29E3.4010403@oracle.com>

Looks fine.
I think it will be useful to back-port it(8-bp label).

On 12.04.16 16:59, Semyon Sadetsky wrote:
> Hello,
>
> Please review fix for JDK9:
> bug: https://bugs.openjdk.java.net/browse/JDK-8153351
> webrev: http://cr.openjdk.java.net/~ssadetsky/8153351/webrev.00/
>
> There are 2 issues here:
> - so called "wide-separators" were not supported in GTK LnF. Metrics for
> those separators should be taken from another properties and they should
> be painted as boxes not lines. The fix adds supports for this GTK feature.
> - The real insets of the popup menu should be taken into account when
> its background is painted, otherwise depending on the system theme there
> may be no space left for the popup menu border.
> Since reproducible test scenario would require to setup the system theme
> the bug is labeled noreg-hard.
>
> --Semyon


-- 
Best regards, Sergey.


From alexandr.scherbatiy at oracle.com  Tue Apr 12 19:02:57 2016
From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy)
Date: Tue, 12 Apr 2016 23:02:57 +0400
Subject: <Swing Dev> [9] Review request for 8132791 No access to
	SynthContext.getContext()
Message-ID: <570D4661.70507@oracle.com>


Hello,

Could you review the fix:
   bug: https://bugs.openjdk.java.net/browse/JDK-8132791
   webrev: http://cr.openjdk.java.net/~alexsch/8132791/webrev.00


SynthContext is an object with 4 fields which is used a lot by Synth L&F 
for components painting. It has an internal API which allows to put 
unused objects to queue and reuse them later. Application developers 
will not be able to have access to this API in JDK 9 with modularization 
feature so they only be able to create new SyntContext objects. There 
are ways that a SyntContext object created by a developer can be 
disposed by Synth L&F and put to the unused object queue.  This can lead 
to a memory leak.

There are 2 options to fix the issue: provide a public API for the 
SyntContext object custom disposing or just get rid of the unused object 
queue.

Effective Java Guide has a suggestion: ?avoiding object creation by 
maintaining your own object pool is a bad idea unless the objects in the 
pool are extremely heavyweight?

To check if there are memory or performance degradation for the second 
solution I used SwingMark application which extensively creates and 
paints a lot of Swing components like labels, menus and others.

The tests were run 5 times with using the object queue and without it.
There results can be found at: 
http://cr.openjdk.java.net/~alexsch/8132791/profiling/results_3-5

The minimum and maximum values from 5 runs are:

Tests which used an object queue:
used memory (in bytes)
   min: 3.75 million max: 3.78 million
heap size  (in bytes)
   min: 11.53 million max: 12.58 million
elapsed time (in milliseconds)
   min: 57.27 thousand max: 57.97 thousand
requests for SynthContext objects: 380 thousands
created objects: 21

Tests which did not use an object queue:
used memory (in bytes)
   min:  3.71 million max: 3.79 million
heap size   (in bytes)
   min: 11.53 million max: 12.58 million
elapsed time (in milliseconds)
   min: 57.90 thousand max: 57.97 thousand
requests for SynthContext objects: 380 thousands
created objects: 380 thousands

There were about 380 thousand request for SynthContext objects in both 
tests but only 21 object were crated for the first ones.

However, the used memory size and running time are nearly the same for 
both runs for these particular tests.

According to the test results it looks reasonable to remove the custom 
object pool support from the SynthContext object.

Thanks,
Alexandr.



From alexandr.scherbatiy at oracle.com  Tue Apr 12 19:03:41 2016
From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy)
Date: Tue, 12 Apr 2016 23:03:41 +0400
Subject: <Swing Dev> [9] Review Request for 8145787: [TEST_BUG][PIT]
 javax/swing/undo/UndoManager/AbstractDocumentUndoConcurrentTest.java fails
 with CannotUndoException
In-Reply-To: <570D1F76.8050607@oracle.com>
References: <5679548D.90104@oracle.com> <570BBC84.3090206@oracle.com>
	<570D1F76.8050607@oracle.com>
Message-ID: <570D468D.3050108@oracle.com>


The fix looks good to me.

Thanks,
Alexandr.

On 12/04/16 20:16, Semyon Sadetsky wrote:
> On 4/11/2016 6:02 PM, Alexander Scherbatiy wrote:
>> On 12/22/2015 4:47 PM, Semyon Sadetsky wrote:
>>> Hello,
>>>
>>> Please review fix for JDK9:
>>>
>>> bug: https://bugs.openjdk.java.net/browse/JDK-8145787
>>> webrev: http://cr.openjdk.java.net/~ssadetsky/8145787/webrev.00/
>>>
>>> This is a multithreading stress test in which the undo queue depth 
>>> may reach zero sometimes occasionally. The corresponding checks were 
>>> added.
>>     What is the sequence of the threads leads that the exception is 
>> thrown?
> When undo() operation from t3 called more times than insertString() 
> and remove() in t1 and t2. Note that undoOrRedo() in t3 is also may 
> work as undo().
>
> --Semyon
>>
>>    Thanks,
>>    Alexandr.
>>
>>>
>>> --Semyon
>>>
>>
>



From alexandr.scherbatiy at oracle.com  Tue Apr 12 19:22:42 2016
From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy)
Date: Tue, 12 Apr 2016 23:22:42 +0400
Subject: <Swing Dev> [9] Review request for 8153351: GTK Menu's have no
 border
In-Reply-To: <570CFF2B.60704@oracle.com>
References: <570CFF2B.60704@oracle.com>
Message-ID: <570D4B02.7080909@oracle.com>

The fix looks good to me.

Thanks,
Alexandr.

On 12/04/16 17:59, Semyon Sadetsky wrote:
> Hello,
>
> Please review fix for JDK9:
> bug: https://bugs.openjdk.java.net/browse/JDK-8153351
> webrev: http://cr.openjdk.java.net/~ssadetsky/8153351/webrev.00/
>
> There are 2 issues here:
> - so called "wide-separators" were not supported in GTK LnF. Metrics 
> for those separators should be taken from another properties and they 
> should be painted as boxes not lines. The fix adds supports for this 
> GTK feature.
> - The real insets of the popup menu should be taken into account when 
> its background is painted, otherwise depending on the system theme 
> there may be no space left for the popup menu border.
> Since reproducible test scenario would require to setup the system 
> theme the bug is labeled noreg-hard.
>
> --Semyon



From semyon.sadetsky at oracle.com  Tue Apr 12 19:34:32 2016
From: semyon.sadetsky at oracle.com (Semyon Sadetsky)
Date: Tue, 12 Apr 2016 22:34:32 +0300
Subject: <Swing Dev> [9] Review request for 8132791 No access to
 SynthContext.getContext()
In-Reply-To: <570D4661.70507@oracle.com>
References: <570D4661.70507@oracle.com>
Message-ID: <570D4DC8.9050206@oracle.com>

Hi Alexander,

Your comparison makes sense.
In addition to your change I'd suggest to remove the reset() method in 
SynthContext and set the fields in the constructor.
Does the factory method really necessary? It seems the public 
constructor has the same arguments and produces the same object.

--Semyon

On 4/12/2016 10:02 PM, Alexander Scherbatiy wrote:
>
> Hello,
>
> Could you review the fix:
>   bug: https://bugs.openjdk.java.net/browse/JDK-8132791
>   webrev: http://cr.openjdk.java.net/~alexsch/8132791/webrev.00
>
>
> SynthContext is an object with 4 fields which is used a lot by Synth 
> L&F for components painting. It has an internal API which allows to 
> put unused objects to queue and reuse them later. Application 
> developers will not be able to have access to this API in JDK 9 with 
> modularization feature so they only be able to create new SyntContext 
> objects. There are ways that a SyntContext object created by a 
> developer can be disposed by Synth L&F and put to the unused object 
> queue.  This can lead to a memory leak.
>
> There are 2 options to fix the issue: provide a public API for the 
> SyntContext object custom disposing or just get rid of the unused 
> object queue.
>
> Effective Java Guide has a suggestion: ?avoiding object creation by 
> maintaining your own object pool is a bad idea unless the objects in 
> the pool are extremely heavyweight?
>
> To check if there are memory or performance degradation for the second 
> solution I used SwingMark application which extensively creates and 
> paints a lot of Swing components like labels, menus and others.
>
> The tests were run 5 times with using the object queue and without it.
> There results can be found at: 
> http://cr.openjdk.java.net/~alexsch/8132791/profiling/results_3-5
>
> The minimum and maximum values from 5 runs are:
>
> Tests which used an object queue:
> used memory (in bytes)
>   min: 3.75 million max: 3.78 million
> heap size  (in bytes)
>   min: 11.53 million max: 12.58 million
> elapsed time (in milliseconds)
>   min: 57.27 thousand max: 57.97 thousand
> requests for SynthContext objects: 380 thousands
> created objects: 21
>
> Tests which did not use an object queue:
> used memory (in bytes)
>   min:  3.71 million max: 3.79 million
> heap size   (in bytes)
>   min: 11.53 million max: 12.58 million
> elapsed time (in milliseconds)
>   min: 57.90 thousand max: 57.97 thousand
> requests for SynthContext objects: 380 thousands
> created objects: 380 thousands
>
> There were about 380 thousand request for SynthContext objects in both 
> tests but only 21 object were crated for the first ones.
>
> However, the used memory size and running time are nearly the same for 
> both runs for these particular tests.
>
> According to the test results it looks reasonable to remove the custom 
> object pool support from the SynthContext object.
>
> Thanks,
> Alexandr.
>



From alexandr.scherbatiy at oracle.com  Tue Apr 12 19:55:05 2016
From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy)
Date: Tue, 12 Apr 2016 23:55:05 +0400
Subject: <Swing Dev> [9] Review request for 8132791 No access to
 SynthContext.getContext()
In-Reply-To: <570D4DC8.9050206@oracle.com>
References: <570D4661.70507@oracle.com> <570D4DC8.9050206@oracle.com>
Message-ID: <570D5299.3090307@oracle.com>

On 12/04/16 23:34, Semyon Sadetsky wrote:
> Hi Alexander,
>
> Your comparison makes sense.
> In addition to your change I'd suggest to remove the reset() method in 
> SynthContext and set the fields in the constructor.
> Does the factory method really necessary? It seems the public 
> constructor has the same arguments and produces the same object.

  This is the good point.

The public constructor has a restriction that a component, region, and 
style arguments must not be null.

Some SynthUI classes (for example SynthLabelUI) violates this 
restriction calling the SynthContext.getContext(...) method. This can 
really be a bug but I would prefer to not mix it with the current fix.

I have created an issue on it: JDK-8154109 Some SynthUI classes can 
request to create a SynthContext with null fields
   https://bugs.openjdk.java.net/browse/JDK-8154109

  Thanks,
  Alexandr.

>
>
> --Semyon
>
> On 4/12/2016 10:02 PM, Alexander Scherbatiy wrote:
>>
>> Hello,
>>
>> Could you review the fix:
>>   bug: https://bugs.openjdk.java.net/browse/JDK-8132791
>>   webrev: http://cr.openjdk.java.net/~alexsch/8132791/webrev.00
>>
>>
>> SynthContext is an object with 4 fields which is used a lot by Synth 
>> L&F for components painting. It has an internal API which allows to 
>> put unused objects to queue and reuse them later. Application 
>> developers will not be able to have access to this API in JDK 9 with 
>> modularization feature so they only be able to create new SyntContext 
>> objects. There are ways that a SyntContext object created by a 
>> developer can be disposed by Synth L&F and put to the unused object 
>> queue.  This can lead to a memory leak.
>>
>> There are 2 options to fix the issue: provide a public API for the 
>> SyntContext object custom disposing or just get rid of the unused 
>> object queue.
>>
>> Effective Java Guide has a suggestion: ?avoiding object creation by 
>> maintaining your own object pool is a bad idea unless the objects in 
>> the pool are extremely heavyweight?
>>
>> To check if there are memory or performance degradation for the 
>> second solution I used SwingMark application which extensively 
>> creates and paints a lot of Swing components like labels, menus and 
>> others.
>>
>> The tests were run 5 times with using the object queue and without it.
>> There results can be found at: 
>> http://cr.openjdk.java.net/~alexsch/8132791/profiling/results_3-5
>>
>> The minimum and maximum values from 5 runs are:
>>
>> Tests which used an object queue:
>> used memory (in bytes)
>>   min: 3.75 million max: 3.78 million
>> heap size  (in bytes)
>>   min: 11.53 million max: 12.58 million
>> elapsed time (in milliseconds)
>>   min: 57.27 thousand max: 57.97 thousand
>> requests for SynthContext objects: 380 thousands
>> created objects: 21
>>
>> Tests which did not use an object queue:
>> used memory (in bytes)
>>   min:  3.71 million max: 3.79 million
>> heap size   (in bytes)
>>   min: 11.53 million max: 12.58 million
>> elapsed time (in milliseconds)
>>   min: 57.90 thousand max: 57.97 thousand
>> requests for SynthContext objects: 380 thousands
>> created objects: 380 thousands
>>
>> There were about 380 thousand request for SynthContext objects in 
>> both tests but only 21 object were crated for the first ones.
>>
>> However, the used memory size and running time are nearly the same 
>> for both runs for these particular tests.
>>
>> According to the test results it looks reasonable to remove the 
>> custom object pool support from the SynthContext object.
>>
>> Thanks,
>> Alexandr.
>>
>



From Sergey.Bylokhov at oracle.com  Tue Apr 12 22:40:20 2016
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Wed, 13 Apr 2016 01:40:20 +0300
Subject: <Swing Dev> [9] Review request for 8132791 No access to
 SynthContext.getContext()
In-Reply-To: <570D4661.70507@oracle.com>
References: <570D4661.70507@oracle.com>
Message-ID: <570D7954.1090603@oracle.com>

Hi, Alexander.

Can you please run the same test using the minimum possible Xmx(like 5 
or 10 mb). It will be interesting who the performance will drop will be 
in this corner case, when the memory is under pressure.

On 12.04.16 22:02, Alexander Scherbatiy wrote:
>
> Hello,
>
> Could you review the fix:
>    bug: https://bugs.openjdk.java.net/browse/JDK-8132791
>    webrev: http://cr.openjdk.java.net/~alexsch/8132791/webrev.00
>
>
> SynthContext is an object with 4 fields which is used a lot by Synth L&F
> for components painting. It has an internal API which allows to put
> unused objects to queue and reuse them later. Application developers
> will not be able to have access to this API in JDK 9 with modularization
> feature so they only be able to create new SyntContext objects. There
> are ways that a SyntContext object created by a developer can be
> disposed by Synth L&F and put to the unused object queue.  This can lead
> to a memory leak.
>
> There are 2 options to fix the issue: provide a public API for the
> SyntContext object custom disposing or just get rid of the unused object
> queue.
>
> Effective Java Guide has a suggestion: ?avoiding object creation by
> maintaining your own object pool is a bad idea unless the objects in the
> pool are extremely heavyweight?
>
> To check if there are memory or performance degradation for the second
> solution I used SwingMark application which extensively creates and
> paints a lot of Swing components like labels, menus and others.
>
> The tests were run 5 times with using the object queue and without it.
> There results can be found at:
> http://cr.openjdk.java.net/~alexsch/8132791/profiling/results_3-5
>
> The minimum and maximum values from 5 runs are:
>
> Tests which used an object queue:
> used memory (in bytes)
>    min: 3.75 million max: 3.78 million
> heap size  (in bytes)
>    min: 11.53 million max: 12.58 million
> elapsed time (in milliseconds)
>    min: 57.27 thousand max: 57.97 thousand
> requests for SynthContext objects: 380 thousands
> created objects: 21
>
> Tests which did not use an object queue:
> used memory (in bytes)
>    min:  3.71 million max: 3.79 million
> heap size   (in bytes)
>    min: 11.53 million max: 12.58 million
> elapsed time (in milliseconds)
>    min: 57.90 thousand max: 57.97 thousand
> requests for SynthContext objects: 380 thousands
> created objects: 380 thousands
>
> There were about 380 thousand request for SynthContext objects in both
> tests but only 21 object were crated for the first ones.
>
> However, the used memory size and running time are nearly the same for
> both runs for these particular tests.
>
> According to the test results it looks reasonable to remove the custom
> object pool support from the SynthContext object.
>
> Thanks,
> Alexandr.
>


-- 
Best regards, Sergey.


From abdul.kolarkunnu at oracle.com  Wed Apr 13 12:40:27 2016
From: abdul.kolarkunnu at oracle.com (Muneer Kolarkunnu)
Date: Wed, 13 Apr 2016 05:40:27 -0700 (PDT)
Subject: <Swing Dev> Review request for 8025430: [TEST_BUG]
 javax/swing/JEditorPane/5076514/bug5076514.java failed since jdk8b108
Message-ID: <d0d58726-fb7f-4db2-88da-cbccdf604383@default>

Hi All,

                Please review the fix for test bug 8025430,

                Webrev: http://cr.openjdk.java.net/~ntv/muneer/8025430/webrev.00/

                Bug: https://bugs.openjdk.java.net/browse/JDK-8025430

 

Issue:

It is a test bug, API checkSystemClipboardAccess() is deprecated. 
Deprecated message from java doc for your reference : "The dependency on AWTPermission creates an impediment to future modularization of the Java platform. Users of this method should instead invoke checkPermission(java.security.Permission) directly. This method will be changed in a future release to check the permission java.security.AllPermission." 

Fix:

              API  checkPermission(java.security.Permission) is used instead of checkSystemClipboardAccess()

 

Regards,

Muneer

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

From ajit.ghaisas at oracle.com  Wed Apr 13 13:08:37 2016
From: ajit.ghaisas at oracle.com (Ajit Ghaisas)
Date: Wed, 13 Apr 2016 06:08:37 -0700 (PDT)
Subject: <Swing Dev> [9] JDK-8049069 : JButton incorrect behaviour on
 button release
In-Reply-To: <56FA825E.8030608@oracle.com>
References: <b8077c49-2413-40ed-b765-43847cc52eb6@default>
	<56F46408.7060403@oracle.com>
	<529629fc-b68d-4a5b-8882-1bb2b7bc409e@default>
	<56FA825E.8030608@oracle.com>
Message-ID: <785d1c7f-636f-4da1-9514-23b6ff941ce0@default>

Hi,

    Thanks for the review.
    Your questioning lead me to think about correcting the SwingUtilities isXXXMouseButton() methods.
   
    It is possible to identify under which mouse state these methods are invoked using the MouseEvent parameter.
    Please review the updated webrev.
    http://cr.openjdk.java.net/~aghaisas/8049069/webrev.01/

    With this fix, I have verified tests mentioned under : JDK-7146377, JDK-7088744 and JDK-8049069. All of them passed.

Regards,
Ajit

-----Original Message-----
From: Alexander Scherbatiy 
Sent: Tuesday, March 29, 2016 6:56 PM
To: Ajit Ghaisas; Sergey Bylokhov; swing-dev at openjdk.java.net; Rajeev Chamyal
Subject: Re: <Swing Dev> [9] JDK-8049069 : JButton incorrect behaviour on button release

On 28/03/16 15:43, Ajit Ghaisas wrote:
> Hi,
>         
>      In JDK-6u115, this bug is not reproducible.
>      Fix for JDK-7088744 did  not break the JButton behavior.
>      This bug is regression due to changes done to SwingUtilities as a fix of JDK-7146377.
>
>      After reading comments on JBS for JDK-7146377, I realized that the modification was done to support left mouse drag.
>      Ideally, it should have been done using a new public method such as isLeftMouseButtonDown() and using it in test/client code.
>      In this case, we will need to add isMiddleMouseButtonDown() and isRightMouseButtonDown() methods as well.
>      Modifying existing APIs as well as introducing new public APIs 
> raises a risk of forced test/client code modifications. (This is the 
> reason why I have chosen option 2 as mentioned below)

   The SwingUtilities.isLeftMouseButton() method used not only in JButton listener but in other places too.
   Could you check some component like JSpinner with proper L&F that it does not have the same issue described in 8049069.

   It is possible just to add one internal method
isLeftMouseButtonDown() to the sun.swing.SwingUtilities2 class first.
   Will it be enough to  fix these two issues 8049069 and 7146377?

   Thanks,
   Alexandr.
>
>      I have fixed the JDK-8049069 in BasicButtonListener.java as there is no need to use swingUtilities methods in mousePressed() and mouseReleased() methods.
>
> Regards,
> Ajit
>
> -----Original Message-----
> From: Sergey Bylokhov
> Sent: Friday, March 25, 2016 3:33 AM
> To: Ajit Ghaisas; swing-dev at openjdk.java.net; Alexander Scherbatiy; 
> Rajeev Chamyal
> Subject: Re: <Swing Dev> [9] JDK-8049069 : JButton incorrect behaviour 
> on button release
>
> Hi, Ajit.
> Is this bug a regression of JDK-7088744 or JDK-8049069, or it works this way in jdk6 as well?
> I guess the code in jdk6 was something like this:
>       public static boolean isLeftMouseButton(MouseEvent anEvent) {
>            return ((anEvent.getModifiers() & InputEvent.BUTTON1_MASK) != 0);
>       }
>
> On 24.03.16 12:55, Ajit Ghaisas wrote:
>> Hi,
>>
>> Bug : https://bugs.openjdk.java.net/browse/JDK-8049069
>>
>> Issue :  A JButton which is pressed using left mouse button gets released if right mouse button is pressed and released.
>>
>> Root cause :
>> ---------------
>> In file BasicButtonListener.java, mousePressed() and mouseReleased() methods check whether the event is from left mouse button.
>> This check is done using ----  if 
>> (SwingUtilities.isLeftMouseButton(e)
>> ) This method returns true if left mouse button is down OR event is from left mouse button.
>> SwingUtilities.isLeftMouseButton() returns true if it is called for right mouse event while holding left button down. This causes mouseReleased() method to release pressed JButton.
>>
>>
>> Alternatives considered :
>> -----------------------------
>> 1. Modifying SwingUtilities.isLeftMouseButton() method to only test 
>> for whether the event is from left mouse button only 2. Modifying mousePressed() and mouseReleased() methods to check for whether the event is from left mouse button using argument passed to them.
>>
>> Option 1 will break the code wherever SwingUtilities.isLeftMouseButton() is used to test for left mouse button down.
>> File history revealed that the mouse button down condition is added to fix another bug.
>>
>> Hence, option 2 is chosen as it is safe and intuitive.
>> I have also added a test. It passes on Windows, Linux and Mac.
>> Test mentioned in comment on the bug also passed.
>>
>> Please review the webrev :
>>
>> http://cr.openjdk.java.net/~aghaisas/8049069/webrev.00/
>>
>> Regards,
>> Ajit
>>
>
> --
> Best regards, Sergey.



From semyon.sadetsky at oracle.com  Wed Apr 13 14:07:48 2016
From: semyon.sadetsky at oracle.com (Semyon Sadetsky)
Date: Wed, 13 Apr 2016 17:07:48 +0300
Subject: <Swing Dev> [9] Review request for 8153276: [TEST_BUG]
 javax/swing/JFileChooser/ShellFolderQueries/ShellFolderQueriesTest.java
Message-ID: <570E52B4.7090907@oracle.com>

Hello,

Please review fix for JDK9:

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

Internal API usage sun.awt.OSInfo was replaced by jdk.testlibrary.OSInfo.

--Semyon



From yuri.nesterenko at oracle.com  Wed Apr 13 14:17:18 2016
From: yuri.nesterenko at oracle.com (Yuri Nesterenko)
Date: Wed, 13 Apr 2016 17:17:18 +0300
Subject: <Swing Dev> [9] Review request for 8153276: [TEST_BUG]
 javax/swing/JFileChooser/ShellFolderQueries/ShellFolderQueriesTest.java
In-Reply-To: <570E52B4.7090907@oracle.com>
References: <570E52B4.7090907@oracle.com>
Message-ID: <570E54EE.7030700@oracle.com>

Looks good to me.

-yan

On 04/13/2016 05:07 PM, Semyon Sadetsky wrote:
> Hello,
>
> Please review fix for JDK9:
>
> bug: https://bugs.openjdk.java.net/browse/JDK-8153276
> webrev: http://cr.openjdk.java.net/~ssadetsky/8153276/webrev.00/
>
> Internal API usage sun.awt.OSInfo was replaced by jdk.testlibrary.OSInfo.
>
> --Semyon
>



From prasanta.sadhukhan at oracle.com  Wed Apr 13 14:19:18 2016
From: prasanta.sadhukhan at oracle.com (prasanta sadhukhan)
Date: Wed, 13 Apr 2016 19:49:18 +0530
Subject: <Swing Dev> Review request for 8025430: [TEST_BUG]
 javax/swing/JEditorPane/5076514/bug5076514.java failed since jdk8b108
In-Reply-To: <d0d58726-fb7f-4db2-88da-cbccdf604383@default>
References: <d0d58726-fb7f-4db2-88da-cbccdf604383@default>
Message-ID: <570E5566.2010209@oracle.com>

You need to add
@run main <test> for latest jtreg to run. Have you run against latest jtreg?

Regards
Prasanta
On 4/13/2016 6:10 PM, Muneer Kolarkunnu wrote:
>
> Hi All,
>
>                 Please review the fix for test bug 8025430,
>
>                 Webrev: 
> http://cr.openjdk.java.net/~ntv/muneer/8025430/webrev.00/ 
> <http://cr.openjdk.java.net/%7Entv/muneer/8025430/webrev.00/>
>
>                 Bug: https://bugs.openjdk.java.net/browse/JDK-8025430
>
> Issue:
>
> It is a test bug, API checkSystemClipboardAccess() is deprecated.
> Deprecated message from java doc for your reference : "The dependency 
> on AWTPermission creates an impediment to future modularization of the 
> Java platform. Users of this method should instead invoke 
> checkPermission(java.security.Permission) directly. This method will 
> be changed in a future release to check the permission 
> java.security.AllPermission."
>
> Fix:
>
>               API  checkPermission(java.security.Permission) is used 
> instead of checkSystemClipboardAccess()
>
> Regards,
>
> Muneer
>

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

From Sergey.Bylokhov at oracle.com  Wed Apr 13 18:44:16 2016
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Wed, 13 Apr 2016 21:44:16 +0300
Subject: <Swing Dev> [9] Review request for 8153276: [TEST_BUG]
 javax/swing/JFileChooser/ShellFolderQueries/ShellFolderQueriesTest.java
In-Reply-To: <570E54EE.7030700@oracle.com>
References: <570E52B4.7090907@oracle.com> <570E54EE.7030700@oracle.com>
Message-ID: <570E9380.7080904@oracle.com>

+1

On 13.04.16 17:17, Yuri Nesterenko wrote:
> Looks good to me.
>
> -yan
>
> On 04/13/2016 05:07 PM, Semyon Sadetsky wrote:
>> Hello,
>>
>> Please review fix for JDK9:
>>
>> bug: https://bugs.openjdk.java.net/browse/JDK-8153276
>> webrev: http://cr.openjdk.java.net/~ssadetsky/8153276/webrev.00/
>>
>> Internal API usage sun.awt.OSInfo was replaced by jdk.testlibrary.OSInfo.
>>
>> --Semyon
>>
>


-- 
Best regards, Sergey.


From philip.race at oracle.com  Wed Apr 13 18:57:19 2016
From: philip.race at oracle.com (Philip Race)
Date: Wed, 13 Apr 2016 11:57:19 -0700
Subject: <Swing Dev> [9] Review request for 8153276: [TEST_BUG]
	javax/swing/JFileChooser/ShellFolderQueries/ShellFolderQueriesTest.java
In-Reply-To: <570E9380.7080904@oracle.com>
References: <570E52B4.7090907@oracle.com> <570E54EE.7030700@oracle.com>
	<570E9380.7080904@oracle.com>
Message-ID: <570E968F.7080003@oracle.com>

Perhaps better but given the minimal use here can't we just
replace it with 
System.getProperty("os.name").toLowerCase().contains("windows") ?

Then you neither need jtreg to run it, nor internal API.

-phil.

On 4/13/16, 11:44 AM, Sergey Bylokhov wrote:
> +1
>
> On 13.04.16 17:17, Yuri Nesterenko wrote:
>> Looks good to me.
>>
>> -yan
>>
>> On 04/13/2016 05:07 PM, Semyon Sadetsky wrote:
>>> Hello,
>>>
>>> Please review fix for JDK9:
>>>
>>> bug: https://bugs.openjdk.java.net/browse/JDK-8153276
>>> webrev: http://cr.openjdk.java.net/~ssadetsky/8153276/webrev.00/
>>>
>>> Internal API usage sun.awt.OSInfo was replaced by 
>>> jdk.testlibrary.OSInfo.
>>>
>>> --Semyon
>>>
>>
>
>


From alexandr.scherbatiy at oracle.com  Wed Apr 13 19:14:25 2016
From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy)
Date: Wed, 13 Apr 2016 23:14:25 +0400
Subject: <Swing Dev> [9] Review request for 8132791 No access to
 SynthContext.getContext()
In-Reply-To: <570D7954.1090603@oracle.com>
References: <570D4661.70507@oracle.com> <570D7954.1090603@oracle.com>
Message-ID: <570E9A91.5090905@oracle.com>


   Hello,

   Could you review  the updated fix:
     http://cr.openjdk.java.net/~alexsch/8132791/webrev.01/

   - reset() method is removed form the SynthContext class
   - unused checks to null are removed from

On 13/04/16 02:40, Sergey Bylokhov wrote:
> Hi, Alexander.
>
> Can you please run the same test using the minimum possible Xmx(like 5 
> or 10 mb). It will be interesting who the performance will drop will 
> be in this corner case, when the memory is under pressure.
   The tests immediately fail with OOME using -Xmx2m option, fail on the 
same steps with 3 and 4 mb and pass with 5 mb.

Thanks,
Alexandr.

>
> On 12.04.16 22:02, Alexander Scherbatiy wrote:
>>
>> Hello,
>>
>> Could you review the fix:
>>    bug: https://bugs.openjdk.java.net/browse/JDK-8132791
>>    webrev: http://cr.openjdk.java.net/~alexsch/8132791/webrev.00
>>
>>
>> SynthContext is an object with 4 fields which is used a lot by Synth L&F
>> for components painting. It has an internal API which allows to put
>> unused objects to queue and reuse them later. Application developers
>> will not be able to have access to this API in JDK 9 with modularization
>> feature so they only be able to create new SyntContext objects. There
>> are ways that a SyntContext object created by a developer can be
>> disposed by Synth L&F and put to the unused object queue. This can lead
>> to a memory leak.
>>
>> There are 2 options to fix the issue: provide a public API for the
>> SyntContext object custom disposing or just get rid of the unused object
>> queue.
>>
>> Effective Java Guide has a suggestion: ?avoiding object creation by
>> maintaining your own object pool is a bad idea unless the objects in the
>> pool are extremely heavyweight?
>>
>> To check if there are memory or performance degradation for the second
>> solution I used SwingMark application which extensively creates and
>> paints a lot of Swing components like labels, menus and others.
>>
>> The tests were run 5 times with using the object queue and without it.
>> There results can be found at:
>> http://cr.openjdk.java.net/~alexsch/8132791/profiling/results_3-5
>>
>> The minimum and maximum values from 5 runs are:
>>
>> Tests which used an object queue:
>> used memory (in bytes)
>>    min: 3.75 million max: 3.78 million
>> heap size  (in bytes)
>>    min: 11.53 million max: 12.58 million
>> elapsed time (in milliseconds)
>>    min: 57.27 thousand max: 57.97 thousand
>> requests for SynthContext objects: 380 thousands
>> created objects: 21
>>
>> Tests which did not use an object queue:
>> used memory (in bytes)
>>    min:  3.71 million max: 3.79 million
>> heap size   (in bytes)
>>    min: 11.53 million max: 12.58 million
>> elapsed time (in milliseconds)
>>    min: 57.90 thousand max: 57.97 thousand
>> requests for SynthContext objects: 380 thousands
>> created objects: 380 thousands
>>
>> There were about 380 thousand request for SynthContext objects in both
>> tests but only 21 object were crated for the first ones.
>>
>> However, the used memory size and running time are nearly the same for
>> both runs for these particular tests.
>>
>> According to the test results it looks reasonable to remove the custom
>> object pool support from the SynthContext object.
>>
>> Thanks,
>> Alexandr.
>>
>
>



From alexandr.scherbatiy at oracle.com  Wed Apr 13 19:29:48 2016
From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy)
Date: Wed, 13 Apr 2016 23:29:48 +0400
Subject: <Swing Dev> [9] JDK-8049069 : JButton incorrect behaviour on
 button release
In-Reply-To: <785d1c7f-636f-4da1-9514-23b6ff941ce0@default>
References: <b8077c49-2413-40ed-b765-43847cc52eb6@default>
	<56F46408.7060403@oracle.com>
	<529629fc-b68d-4a5b-8882-1bb2b7bc409e@default>
	<56FA825E.8030608@oracle.com>
	<785d1c7f-636f-4da1-9514-23b6ff941ce0@default>
Message-ID: <570E9E2C.1070805@oracle.com>


There is the same code which is repeated in three methods. Is it 
possible to add a private method which takes button, button mask, and 
event as parameters and returns true if the mouse event specifies the 
given button? It would be possible to reuse it in public methods.

Thanks,
Alexandr.

On 13/04/16 17:08, Ajit Ghaisas wrote:
> Hi,
>
>      Thanks for the review.
>      Your questioning lead me to think about correcting the SwingUtilities isXXXMouseButton() methods.
>     
>      It is possible to identify under which mouse state these methods are invoked using the MouseEvent parameter.
>      Please review the updated webrev.
>      http://cr.openjdk.java.net/~aghaisas/8049069/webrev.01/
>
>      With this fix, I have verified tests mentioned under : JDK-7146377, JDK-7088744 and JDK-8049069. All of them passed.
>
> Regards,
> Ajit
>
> -----Original Message-----
> From: Alexander Scherbatiy
> Sent: Tuesday, March 29, 2016 6:56 PM
> To: Ajit Ghaisas; Sergey Bylokhov; swing-dev at openjdk.java.net; Rajeev Chamyal
> Subject: Re: <Swing Dev> [9] JDK-8049069 : JButton incorrect behaviour on button release
>
> On 28/03/16 15:43, Ajit Ghaisas wrote:
>> Hi,
>>          
>>       In JDK-6u115, this bug is not reproducible.
>>       Fix for JDK-7088744 did  not break the JButton behavior.
>>       This bug is regression due to changes done to SwingUtilities as a fix of JDK-7146377.
>>
>>       After reading comments on JBS for JDK-7146377, I realized that the modification was done to support left mouse drag.
>>       Ideally, it should have been done using a new public method such as isLeftMouseButtonDown() and using it in test/client code.
>>       In this case, we will need to add isMiddleMouseButtonDown() and isRightMouseButtonDown() methods as well.
>>       Modifying existing APIs as well as introducing new public APIs
>> raises a risk of forced test/client code modifications. (This is the
>> reason why I have chosen option 2 as mentioned below)
>     The SwingUtilities.isLeftMouseButton() method used not only in JButton listener but in other places too.
>     Could you check some component like JSpinner with proper L&F that it does not have the same issue described in 8049069.
>
>     It is possible just to add one internal method
> isLeftMouseButtonDown() to the sun.swing.SwingUtilities2 class first.
>     Will it be enough to  fix these two issues 8049069 and 7146377?
>
>     Thanks,
>     Alexandr.
>>       I have fixed the JDK-8049069 in BasicButtonListener.java as there is no need to use swingUtilities methods in mousePressed() and mouseReleased() methods.
>>
>> Regards,
>> Ajit
>>
>> -----Original Message-----
>> From: Sergey Bylokhov
>> Sent: Friday, March 25, 2016 3:33 AM
>> To: Ajit Ghaisas; swing-dev at openjdk.java.net; Alexander Scherbatiy;
>> Rajeev Chamyal
>> Subject: Re: <Swing Dev> [9] JDK-8049069 : JButton incorrect behaviour
>> on button release
>>
>> Hi, Ajit.
>> Is this bug a regression of JDK-7088744 or JDK-8049069, or it works this way in jdk6 as well?
>> I guess the code in jdk6 was something like this:
>>        public static boolean isLeftMouseButton(MouseEvent anEvent) {
>>             return ((anEvent.getModifiers() & InputEvent.BUTTON1_MASK) != 0);
>>        }
>>
>> On 24.03.16 12:55, Ajit Ghaisas wrote:
>>> Hi,
>>>
>>> Bug : https://bugs.openjdk.java.net/browse/JDK-8049069
>>>
>>> Issue :  A JButton which is pressed using left mouse button gets released if right mouse button is pressed and released.
>>>
>>> Root cause :
>>> ---------------
>>> In file BasicButtonListener.java, mousePressed() and mouseReleased() methods check whether the event is from left mouse button.
>>> This check is done using ----  if
>>> (SwingUtilities.isLeftMouseButton(e)
>>> ) This method returns true if left mouse button is down OR event is from left mouse button.
>>> SwingUtilities.isLeftMouseButton() returns true if it is called for right mouse event while holding left button down. This causes mouseReleased() method to release pressed JButton.
>>>
>>>
>>> Alternatives considered :
>>> -----------------------------
>>> 1. Modifying SwingUtilities.isLeftMouseButton() method to only test
>>> for whether the event is from left mouse button only 2. Modifying mousePressed() and mouseReleased() methods to check for whether the event is from left mouse button using argument passed to them.
>>>
>>> Option 1 will break the code wherever SwingUtilities.isLeftMouseButton() is used to test for left mouse button down.
>>> File history revealed that the mouse button down condition is added to fix another bug.
>>>
>>> Hence, option 2 is chosen as it is safe and intuitive.
>>> I have also added a test. It passes on Windows, Linux and Mac.
>>> Test mentioned in comment on the bug also passed.
>>>
>>> Please review the webrev :
>>>
>>> http://cr.openjdk.java.net/~aghaisas/8049069/webrev.00/
>>>
>>> Regards,
>>> Ajit
>>>
>> --
>> Best regards, Sergey.



From Sergey.Bylokhov at oracle.com  Wed Apr 13 19:44:31 2016
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Wed, 13 Apr 2016 22:44:31 +0300
Subject: <Swing Dev> [9] Review request for 8132791 No access to
 SynthContext.getContext()
In-Reply-To: <570E9A91.5090905@oracle.com>
References: <570D4661.70507@oracle.com> <570D7954.1090603@oracle.com>
	<570E9A91.5090905@oracle.com>
Message-ID: <570EA19F.5090807@oracle.com>

On 13.04.16 22:14, Alexander Scherbatiy wrote:
>    The tests immediately fail with OOME using -Xmx2m option, fail on the
> same steps with 3 and 4 mb and pass with 5 mb.

And there is no difference in SwingMark results before and after the fix?

>
> Thanks,
> Alexandr.
>
>>
>> On 12.04.16 22:02, Alexander Scherbatiy wrote:
>>>
>>> Hello,
>>>
>>> Could you review the fix:
>>>    bug: https://bugs.openjdk.java.net/browse/JDK-8132791
>>>    webrev: http://cr.openjdk.java.net/~alexsch/8132791/webrev.00
>>>
>>>
>>> SynthContext is an object with 4 fields which is used a lot by Synth L&F
>>> for components painting. It has an internal API which allows to put
>>> unused objects to queue and reuse them later. Application developers
>>> will not be able to have access to this API in JDK 9 with modularization
>>> feature so they only be able to create new SyntContext objects. There
>>> are ways that a SyntContext object created by a developer can be
>>> disposed by Synth L&F and put to the unused object queue. This can lead
>>> to a memory leak.
>>>
>>> There are 2 options to fix the issue: provide a public API for the
>>> SyntContext object custom disposing or just get rid of the unused object
>>> queue.
>>>
>>> Effective Java Guide has a suggestion: ?avoiding object creation by
>>> maintaining your own object pool is a bad idea unless the objects in the
>>> pool are extremely heavyweight?
>>>
>>> To check if there are memory or performance degradation for the second
>>> solution I used SwingMark application which extensively creates and
>>> paints a lot of Swing components like labels, menus and others.
>>>
>>> The tests were run 5 times with using the object queue and without it.
>>> There results can be found at:
>>> http://cr.openjdk.java.net/~alexsch/8132791/profiling/results_3-5
>>>
>>> The minimum and maximum values from 5 runs are:
>>>
>>> Tests which used an object queue:
>>> used memory (in bytes)
>>>    min: 3.75 million max: 3.78 million
>>> heap size  (in bytes)
>>>    min: 11.53 million max: 12.58 million
>>> elapsed time (in milliseconds)
>>>    min: 57.27 thousand max: 57.97 thousand
>>> requests for SynthContext objects: 380 thousands
>>> created objects: 21
>>>
>>> Tests which did not use an object queue:
>>> used memory (in bytes)
>>>    min:  3.71 million max: 3.79 million
>>> heap size   (in bytes)
>>>    min: 11.53 million max: 12.58 million
>>> elapsed time (in milliseconds)
>>>    min: 57.90 thousand max: 57.97 thousand
>>> requests for SynthContext objects: 380 thousands
>>> created objects: 380 thousands
>>>
>>> There were about 380 thousand request for SynthContext objects in both
>>> tests but only 21 object were crated for the first ones.
>>>
>>> However, the used memory size and running time are nearly the same for
>>> both runs for these particular tests.
>>>
>>> According to the test results it looks reasonable to remove the custom
>>> object pool support from the SynthContext object.
>>>
>>> Thanks,
>>> Alexandr.
>>>
>>
>>
>


-- 
Best regards, Sergey.


From ajit.ghaisas at oracle.com  Thu Apr 14 06:44:50 2016
From: ajit.ghaisas at oracle.com (Ajit Ghaisas)
Date: Wed, 13 Apr 2016 23:44:50 -0700 (PDT)
Subject: <Swing Dev> [9] JDK-8049069 : JButton incorrect behaviour on
 button release
In-Reply-To: <570E9E2C.1070805@oracle.com>
References: <b8077c49-2413-40ed-b765-43847cc52eb6@default>
	<56F46408.7060403@oracle.com>
	<529629fc-b68d-4a5b-8882-1bb2b7bc409e@default>
	<56FA825E.8030608@oracle.com>
	<785d1c7f-636f-4da1-9514-23b6ff941ce0@default>
	<570E9E2C.1070805@oracle.com>
Message-ID: <f44cc821-34b5-443f-8ddb-9deef910f016@default>

Thanks Alex for the good suggestion to have a private method to avoid code repetition.

I have modified the code accordingly.  Please review the updated webrev.
http://cr.openjdk.java.net/~aghaisas/8049069/webrev.02/

Regards,
Ajit

-----Original Message-----
From: Alexander Scherbatiy 
Sent: Thursday, April 14, 2016 1:00 AM
To: Ajit Ghaisas; Sergey Bylokhov; swing-dev at openjdk.java.net
Subject: Re: <Swing Dev> [9] JDK-8049069 : JButton incorrect behaviour on button release


There is the same code which is repeated in three methods. Is it possible to add a private method which takes button, button mask, and event as parameters and returns true if the mouse event specifies the given button? It would be possible to reuse it in public methods.

Thanks,
Alexandr.

On 13/04/16 17:08, Ajit Ghaisas wrote:
> Hi,
>
>      Thanks for the review.
>      Your questioning lead me to think about correcting the SwingUtilities isXXXMouseButton() methods.
>     
>      It is possible to identify under which mouse state these methods are invoked using the MouseEvent parameter.
>      Please review the updated webrev.
>      http://cr.openjdk.java.net/~aghaisas/8049069/webrev.01/
>
>      With this fix, I have verified tests mentioned under : JDK-7146377, JDK-7088744 and JDK-8049069. All of them passed.
>
> Regards,
> Ajit
>
> -----Original Message-----
> From: Alexander Scherbatiy
> Sent: Tuesday, March 29, 2016 6:56 PM
> To: Ajit Ghaisas; Sergey Bylokhov; swing-dev at openjdk.java.net; Rajeev 
> Chamyal
> Subject: Re: <Swing Dev> [9] JDK-8049069 : JButton incorrect behaviour 
> on button release
>
> On 28/03/16 15:43, Ajit Ghaisas wrote:
>> Hi,
>>          
>>       In JDK-6u115, this bug is not reproducible.
>>       Fix for JDK-7088744 did  not break the JButton behavior.
>>       This bug is regression due to changes done to SwingUtilities as a fix of JDK-7146377.
>>
>>       After reading comments on JBS for JDK-7146377, I realized that the modification was done to support left mouse drag.
>>       Ideally, it should have been done using a new public method such as isLeftMouseButtonDown() and using it in test/client code.
>>       In this case, we will need to add isMiddleMouseButtonDown() and isRightMouseButtonDown() methods as well.
>>       Modifying existing APIs as well as introducing new public APIs 
>> raises a risk of forced test/client code modifications. (This is the 
>> reason why I have chosen option 2 as mentioned below)
>     The SwingUtilities.isLeftMouseButton() method used not only in JButton listener but in other places too.
>     Could you check some component like JSpinner with proper L&F that it does not have the same issue described in 8049069.
>
>     It is possible just to add one internal method
> isLeftMouseButtonDown() to the sun.swing.SwingUtilities2 class first.
>     Will it be enough to  fix these two issues 8049069 and 7146377?
>
>     Thanks,
>     Alexandr.
>>       I have fixed the JDK-8049069 in BasicButtonListener.java as there is no need to use swingUtilities methods in mousePressed() and mouseReleased() methods.
>>
>> Regards,
>> Ajit
>>
>> -----Original Message-----
>> From: Sergey Bylokhov
>> Sent: Friday, March 25, 2016 3:33 AM
>> To: Ajit Ghaisas; swing-dev at openjdk.java.net; Alexander Scherbatiy; 
>> Rajeev Chamyal
>> Subject: Re: <Swing Dev> [9] JDK-8049069 : JButton incorrect 
>> behaviour on button release
>>
>> Hi, Ajit.
>> Is this bug a regression of JDK-7088744 or JDK-8049069, or it works this way in jdk6 as well?
>> I guess the code in jdk6 was something like this:
>>        public static boolean isLeftMouseButton(MouseEvent anEvent) {
>>             return ((anEvent.getModifiers() & InputEvent.BUTTON1_MASK) != 0);
>>        }
>>
>> On 24.03.16 12:55, Ajit Ghaisas wrote:
>>> Hi,
>>>
>>> Bug : https://bugs.openjdk.java.net/browse/JDK-8049069
>>>
>>> Issue :  A JButton which is pressed using left mouse button gets released if right mouse button is pressed and released.
>>>
>>> Root cause :
>>> ---------------
>>> In file BasicButtonListener.java, mousePressed() and mouseReleased() methods check whether the event is from left mouse button.
>>> This check is done using ----  if
>>> (SwingUtilities.isLeftMouseButton(e)
>>> ) This method returns true if left mouse button is down OR event is from left mouse button.
>>> SwingUtilities.isLeftMouseButton() returns true if it is called for right mouse event while holding left button down. This causes mouseReleased() method to release pressed JButton.
>>>
>>>
>>> Alternatives considered :
>>> -----------------------------
>>> 1. Modifying SwingUtilities.isLeftMouseButton() method to only test 
>>> for whether the event is from left mouse button only 2. Modifying mousePressed() and mouseReleased() methods to check for whether the event is from left mouse button using argument passed to them.
>>>
>>> Option 1 will break the code wherever SwingUtilities.isLeftMouseButton() is used to test for left mouse button down.
>>> File history revealed that the mouse button down condition is added to fix another bug.
>>>
>>> Hence, option 2 is chosen as it is safe and intuitive.
>>> I have also added a test. It passes on Windows, Linux and Mac.
>>> Test mentioned in comment on the bug also passed.
>>>
>>> Please review the webrev :
>>>
>>> http://cr.openjdk.java.net/~aghaisas/8049069/webrev.00/
>>>
>>> Regards,
>>> Ajit
>>>
>> --
>> Best regards, Sergey.



From semyon.sadetsky at oracle.com  Thu Apr 14 07:05:17 2016
From: semyon.sadetsky at oracle.com (Semyon Sadetsky)
Date: Thu, 14 Apr 2016 10:05:17 +0300
Subject: <Swing Dev> [9] Review request for 8153276: [TEST_BUG]
 javax/swing/JFileChooser/ShellFolderQueries/ShellFolderQueriesTest.java
In-Reply-To: <570E968F.7080003@oracle.com>
References: <570E52B4.7090907@oracle.com> <570E54EE.7030700@oracle.com>
	<570E9380.7080904@oracle.com> <570E968F.7080003@oracle.com>
Message-ID: <570F412D.3040307@oracle.com>

On 4/13/2016 9:57 PM, Philip Race wrote:
> Perhaps better but given the minimal use here can't we just
> replace it with 
> System.getProperty("os.name").toLowerCase().contains("windows") ?
>
> Then you neither need jtreg to run it, nor internal API.
I agree. See the updated webrev: 
http://cr.openjdk.java.net/~ssadetsky/8153276/webrev.01/

--Semyon
>
> -phil.
>
> On 4/13/16, 11:44 AM, Sergey Bylokhov wrote:
>> +1
>>
>> On 13.04.16 17:17, Yuri Nesterenko wrote:
>>> Looks good to me.
>>>
>>> -yan
>>>
>>> On 04/13/2016 05:07 PM, Semyon Sadetsky wrote:
>>>> Hello,
>>>>
>>>> Please review fix for JDK9:
>>>>
>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8153276
>>>> webrev: http://cr.openjdk.java.net/~ssadetsky/8153276/webrev.00/
>>>>
>>>> Internal API usage sun.awt.OSInfo was replaced by 
>>>> jdk.testlibrary.OSInfo.
>>>>
>>>> --Semyon
>>>>
>>>
>>
>>



From yuri.nesterenko at oracle.com  Thu Apr 14 07:41:36 2016
From: yuri.nesterenko at oracle.com (Yuri Nesterenko)
Date: Thu, 14 Apr 2016 10:41:36 +0300
Subject: <Swing Dev> [9] Review request for 8153276: [TEST_BUG]
 javax/swing/JFileChooser/ShellFolderQueries/ShellFolderQueriesTest.java
In-Reply-To: <570F412D.3040307@oracle.com>
References: <570E52B4.7090907@oracle.com> <570E54EE.7030700@oracle.com>
	<570E9380.7080904@oracle.com> <570E968F.7080003@oracle.com>
	<570F412D.3040307@oracle.com>
Message-ID: <570F49B0.3080904@oracle.com>

Ok, +1, simplest working device is better, definitely in the tests.

-yan

On 04/14/2016 10:05 AM, Semyon Sadetsky wrote:
> On 4/13/2016 9:57 PM, Philip Race wrote:
>> Perhaps better but given the minimal use here can't we just
>> replace it with
>> System.getProperty("os.name").toLowerCase().contains("windows") ?
>>
>> Then you neither need jtreg to run it, nor internal API.
> I agree. See the updated webrev:
> http://cr.openjdk.java.net/~ssadetsky/8153276/webrev.01/
>
> --Semyon
>>
>> -phil.
>>
>> On 4/13/16, 11:44 AM, Sergey Bylokhov wrote:
>>> +1
>>>
>>> On 13.04.16 17:17, Yuri Nesterenko wrote:
>>>> Looks good to me.
>>>>
>>>> -yan
>>>>
>>>> On 04/13/2016 05:07 PM, Semyon Sadetsky wrote:
>>>>> Hello,
>>>>>
>>>>> Please review fix for JDK9:
>>>>>
>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8153276
>>>>> webrev: http://cr.openjdk.java.net/~ssadetsky/8153276/webrev.00/
>>>>>
>>>>> Internal API usage sun.awt.OSInfo was replaced by
>>>>> jdk.testlibrary.OSInfo.
>>>>>
>>>>> --Semyon
>>>>>
>>>>
>>>
>>>
>



From abdul.kolarkunnu at oracle.com  Thu Apr 14 08:29:47 2016
From: abdul.kolarkunnu at oracle.com (Muneer Kolarkunnu)
Date: Thu, 14 Apr 2016 01:29:47 -0700 (PDT)
Subject: <Swing Dev> Review request for 8025430: [TEST_BUG]
 javax/swing/JEditorPane/5076514/bug5076514.java failed since jdk8b108
In-Reply-To: <570E5566.2010209@oracle.com>
References: <d0d58726-fb7f-4db2-88da-cbccdf604383@default>
	<570E5566.2010209@oracle.com>
Message-ID: <9faef317-8985-4a54-ac5f-3ac8052ab490@default>

I added the @run tag and updated the review: http://cr.openjdk.java.net/~ntv/muneer/8025430/webrev.01/

 

I tested with latest jtreg with and without @run tag, both are working.

 

But there is a difference in the logs in the following line:

Without @run flag:

command: main bug5076514

reason: Assumed action based on file name: run main bug5076514 

 

With @run flag:

command: main bug5076514
reason: User specified action: run main bug5076514

 

Regards,

Muneer

 

From: prasanta sadhukhan 
Sent: Wednesday, April 13, 2016 7:49 PM
To: Muneer Kolarkunnu; swing-dev at openjdk.java.net
Subject: Re: Review request for 8025430: [TEST_BUG] javax/swing/JEditorPane/5076514/bug5076514.java failed since jdk8b108

 

You need to add 
@run main <test> for latest jtreg to run. Have you run against latest jtreg?

Regards
Prasanta

On 4/13/2016 6:10 PM, Muneer Kolarkunnu wrote:

Hi All,

                Please review the fix for test bug 8025430,

                Webrev: http://cr.openjdk.java.net/~ntv/muneer/8025430/webrev.00/

                Bug: https://bugs.openjdk.java.net/browse/JDK-8025430

 

Issue:

It is a test bug, API checkSystemClipboardAccess() is deprecated. 
Deprecated message from java doc for your reference : "The dependency on AWTPermission creates an impediment to future modularization of the Java platform. Users of this method should instead invoke checkPermission(java.security.Permission) directly. This method will be changed in a future release to check the permission java.security.AllPermission." 

Fix:

              API  checkPermission(java.security.Permission) is used instead of checkSystemClipboardAccess()

 

Regards,

Muneer

 

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

From alexandr.scherbatiy at oracle.com  Thu Apr 14 08:53:34 2016
From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy)
Date: Thu, 14 Apr 2016 12:53:34 +0400
Subject: <Swing Dev> [9] JDK-8049069 : JButton incorrect behaviour on
 button release
In-Reply-To: <f44cc821-34b5-443f-8ddb-9deef910f016@default>
References: <b8077c49-2413-40ed-b765-43847cc52eb6@default>
	<56F46408.7060403@oracle.com>
	<529629fc-b68d-4a5b-8882-1bb2b7bc409e@default>
	<56FA825E.8030608@oracle.com>
	<785d1c7f-636f-4da1-9514-23b6ff941ce0@default>
	<570E9E2C.1070805@oracle.com>
	<f44cc821-34b5-443f-8ddb-9deef910f016@default>
Message-ID: <570F5A8E.4010109@oracle.com>


The fix looks good to me.

Thanks,
Alexandr.

On 14/04/16 10:44, Ajit Ghaisas wrote:
> Thanks Alex for the good suggestion to have a private method to avoid code repetition.
>
> I have modified the code accordingly.  Please review the updated webrev.
> http://cr.openjdk.java.net/~aghaisas/8049069/webrev.02/
>
> Regards,
> Ajit
>
> -----Original Message-----
> From: Alexander Scherbatiy
> Sent: Thursday, April 14, 2016 1:00 AM
> To: Ajit Ghaisas; Sergey Bylokhov; swing-dev at openjdk.java.net
> Subject: Re: <Swing Dev> [9] JDK-8049069 : JButton incorrect behaviour on button release
>
>
> There is the same code which is repeated in three methods. Is it possible to add a private method which takes button, button mask, and event as parameters and returns true if the mouse event specifies the given button? It would be possible to reuse it in public methods.
>
> Thanks,
> Alexandr.
>
> On 13/04/16 17:08, Ajit Ghaisas wrote:
>> Hi,
>>
>>       Thanks for the review.
>>       Your questioning lead me to think about correcting the SwingUtilities isXXXMouseButton() methods.
>>      
>>       It is possible to identify under which mouse state these methods are invoked using the MouseEvent parameter.
>>       Please review the updated webrev.
>>       http://cr.openjdk.java.net/~aghaisas/8049069/webrev.01/
>>
>>       With this fix, I have verified tests mentioned under : JDK-7146377, JDK-7088744 and JDK-8049069. All of them passed.
>>
>> Regards,
>> Ajit
>>
>> -----Original Message-----
>> From: Alexander Scherbatiy
>> Sent: Tuesday, March 29, 2016 6:56 PM
>> To: Ajit Ghaisas; Sergey Bylokhov; swing-dev at openjdk.java.net; Rajeev
>> Chamyal
>> Subject: Re: <Swing Dev> [9] JDK-8049069 : JButton incorrect behaviour
>> on button release
>>
>> On 28/03/16 15:43, Ajit Ghaisas wrote:
>>> Hi,
>>>           
>>>        In JDK-6u115, this bug is not reproducible.
>>>        Fix for JDK-7088744 did  not break the JButton behavior.
>>>        This bug is regression due to changes done to SwingUtilities as a fix of JDK-7146377.
>>>
>>>        After reading comments on JBS for JDK-7146377, I realized that the modification was done to support left mouse drag.
>>>        Ideally, it should have been done using a new public method such as isLeftMouseButtonDown() and using it in test/client code.
>>>        In this case, we will need to add isMiddleMouseButtonDown() and isRightMouseButtonDown() methods as well.
>>>        Modifying existing APIs as well as introducing new public APIs
>>> raises a risk of forced test/client code modifications. (This is the
>>> reason why I have chosen option 2 as mentioned below)
>>      The SwingUtilities.isLeftMouseButton() method used not only in JButton listener but in other places too.
>>      Could you check some component like JSpinner with proper L&F that it does not have the same issue described in 8049069.
>>
>>      It is possible just to add one internal method
>> isLeftMouseButtonDown() to the sun.swing.SwingUtilities2 class first.
>>      Will it be enough to  fix these two issues 8049069 and 7146377?
>>
>>      Thanks,
>>      Alexandr.
>>>        I have fixed the JDK-8049069 in BasicButtonListener.java as there is no need to use swingUtilities methods in mousePressed() and mouseReleased() methods.
>>>
>>> Regards,
>>> Ajit
>>>
>>> -----Original Message-----
>>> From: Sergey Bylokhov
>>> Sent: Friday, March 25, 2016 3:33 AM
>>> To: Ajit Ghaisas; swing-dev at openjdk.java.net; Alexander Scherbatiy;
>>> Rajeev Chamyal
>>> Subject: Re: <Swing Dev> [9] JDK-8049069 : JButton incorrect
>>> behaviour on button release
>>>
>>> Hi, Ajit.
>>> Is this bug a regression of JDK-7088744 or JDK-8049069, or it works this way in jdk6 as well?
>>> I guess the code in jdk6 was something like this:
>>>         public static boolean isLeftMouseButton(MouseEvent anEvent) {
>>>              return ((anEvent.getModifiers() & InputEvent.BUTTON1_MASK) != 0);
>>>         }
>>>
>>> On 24.03.16 12:55, Ajit Ghaisas wrote:
>>>> Hi,
>>>>
>>>> Bug : https://bugs.openjdk.java.net/browse/JDK-8049069
>>>>
>>>> Issue :  A JButton which is pressed using left mouse button gets released if right mouse button is pressed and released.
>>>>
>>>> Root cause :
>>>> ---------------
>>>> In file BasicButtonListener.java, mousePressed() and mouseReleased() methods check whether the event is from left mouse button.
>>>> This check is done using ----  if
>>>> (SwingUtilities.isLeftMouseButton(e)
>>>> ) This method returns true if left mouse button is down OR event is from left mouse button.
>>>> SwingUtilities.isLeftMouseButton() returns true if it is called for right mouse event while holding left button down. This causes mouseReleased() method to release pressed JButton.
>>>>
>>>>
>>>> Alternatives considered :
>>>> -----------------------------
>>>> 1. Modifying SwingUtilities.isLeftMouseButton() method to only test
>>>> for whether the event is from left mouse button only 2. Modifying mousePressed() and mouseReleased() methods to check for whether the event is from left mouse button using argument passed to them.
>>>>
>>>> Option 1 will break the code wherever SwingUtilities.isLeftMouseButton() is used to test for left mouse button down.
>>>> File history revealed that the mouse button down condition is added to fix another bug.
>>>>
>>>> Hence, option 2 is chosen as it is safe and intuitive.
>>>> I have also added a test. It passes on Windows, Linux and Mac.
>>>> Test mentioned in comment on the bug also passed.
>>>>
>>>> Please review the webrev :
>>>>
>>>> http://cr.openjdk.java.net/~aghaisas/8049069/webrev.00/
>>>>
>>>> Regards,
>>>> Ajit
>>>>
>>> --
>>> Best regards, Sergey.



From alexandr.scherbatiy at oracle.com  Thu Apr 14 11:17:03 2016
From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy)
Date: Thu, 14 Apr 2016 15:17:03 +0400
Subject: <Swing Dev> [9] Review request for 8132791 No access to
 SynthContext.getContext()
In-Reply-To: <570EA19F.5090807@oracle.com>
References: <570D4661.70507@oracle.com> <570D7954.1090603@oracle.com>
	<570E9A91.5090905@oracle.com> <570EA19F.5090807@oracle.com>
Message-ID: <570F7C2F.6020200@oracle.com>

On 13/04/16 23:44, Sergey Bylokhov wrote:
> On 13.04.16 22:14, Alexander Scherbatiy wrote:
>>    The tests immediately fail with OOME using -Xmx2m option, fail on the
>> same steps with 3 and 4 mb and pass with 5 mb.
>
> And there is no difference in SwingMark results before and after the fix?

   The tests with -Xmx5m options have the similar results too:
http://cr.openjdk.java.net/~alexsch/8132791/profiling/results-xmx5m_3-5/

   Thanks,
   Alexandr.

>
>>
>> Thanks,
>> Alexandr.
>>
>>>
>>> On 12.04.16 22:02, Alexander Scherbatiy wrote:
>>>>
>>>> Hello,
>>>>
>>>> Could you review the fix:
>>>>    bug: https://bugs.openjdk.java.net/browse/JDK-8132791
>>>>    webrev: http://cr.openjdk.java.net/~alexsch/8132791/webrev.00
>>>>
>>>>
>>>> SynthContext is an object with 4 fields which is used a lot by 
>>>> Synth L&F
>>>> for components painting. It has an internal API which allows to put
>>>> unused objects to queue and reuse them later. Application developers
>>>> will not be able to have access to this API in JDK 9 with 
>>>> modularization
>>>> feature so they only be able to create new SyntContext objects. There
>>>> are ways that a SyntContext object created by a developer can be
>>>> disposed by Synth L&F and put to the unused object queue. This can 
>>>> lead
>>>> to a memory leak.
>>>>
>>>> There are 2 options to fix the issue: provide a public API for the
>>>> SyntContext object custom disposing or just get rid of the unused 
>>>> object
>>>> queue.
>>>>
>>>> Effective Java Guide has a suggestion: ?avoiding object creation by
>>>> maintaining your own object pool is a bad idea unless the objects 
>>>> in the
>>>> pool are extremely heavyweight?
>>>>
>>>> To check if there are memory or performance degradation for the second
>>>> solution I used SwingMark application which extensively creates and
>>>> paints a lot of Swing components like labels, menus and others.
>>>>
>>>> The tests were run 5 times with using the object queue and without it.
>>>> There results can be found at:
>>>> http://cr.openjdk.java.net/~alexsch/8132791/profiling/results_3-5
>>>>
>>>> The minimum and maximum values from 5 runs are:
>>>>
>>>> Tests which used an object queue:
>>>> used memory (in bytes)
>>>>    min: 3.75 million max: 3.78 million
>>>> heap size  (in bytes)
>>>>    min: 11.53 million max: 12.58 million
>>>> elapsed time (in milliseconds)
>>>>    min: 57.27 thousand max: 57.97 thousand
>>>> requests for SynthContext objects: 380 thousands
>>>> created objects: 21
>>>>
>>>> Tests which did not use an object queue:
>>>> used memory (in bytes)
>>>>    min:  3.71 million max: 3.79 million
>>>> heap size   (in bytes)
>>>>    min: 11.53 million max: 12.58 million
>>>> elapsed time (in milliseconds)
>>>>    min: 57.90 thousand max: 57.97 thousand
>>>> requests for SynthContext objects: 380 thousands
>>>> created objects: 380 thousands
>>>>
>>>> There were about 380 thousand request for SynthContext objects in both
>>>> tests but only 21 object were crated for the first ones.
>>>>
>>>> However, the used memory size and running time are nearly the same for
>>>> both runs for these particular tests.
>>>>
>>>> According to the test results it looks reasonable to remove the custom
>>>> object pool support from the SynthContext object.
>>>>
>>>> Thanks,
>>>> Alexandr.
>>>>
>>>
>>>
>>
>
>



From semyon.sadetsky at oracle.com  Thu Apr 14 11:26:44 2016
From: semyon.sadetsky at oracle.com (Semyon Sadetsky)
Date: Thu, 14 Apr 2016 14:26:44 +0300
Subject: <Swing Dev> [9] Review request for 8132791 No access to
 SynthContext.getContext()
In-Reply-To: <570E9A91.5090905@oracle.com>
References: <570D4661.70507@oracle.com> <570D7954.1090603@oracle.com>
	<570E9A91.5090905@oracle.com>
Message-ID: <570F7E74.9010106@oracle.com>

Looks good.

--Semyon

On 4/13/2016 10:14 PM, Alexander Scherbatiy wrote:
>
>   Hello,
>
>   Could you review  the updated fix:
>     http://cr.openjdk.java.net/~alexsch/8132791/webrev.01/
>
>   - reset() method is removed form the SynthContext class
>   - unused checks to null are removed from
>
> On 13/04/16 02:40, Sergey Bylokhov wrote:
>> Hi, Alexander.
>>
>> Can you please run the same test using the minimum possible Xmx(like 
>> 5 or 10 mb). It will be interesting who the performance will drop 
>> will be in this corner case, when the memory is under pressure.
>   The tests immediately fail with OOME using -Xmx2m option, fail on 
> the same steps with 3 and 4 mb and pass with 5 mb.
>
> Thanks,
> Alexandr.
>
>>
>> On 12.04.16 22:02, Alexander Scherbatiy wrote:
>>>
>>> Hello,
>>>
>>> Could you review the fix:
>>>    bug: https://bugs.openjdk.java.net/browse/JDK-8132791
>>>    webrev: http://cr.openjdk.java.net/~alexsch/8132791/webrev.00
>>>
>>>
>>> SynthContext is an object with 4 fields which is used a lot by Synth 
>>> L&F
>>> for components painting. It has an internal API which allows to put
>>> unused objects to queue and reuse them later. Application developers
>>> will not be able to have access to this API in JDK 9 with 
>>> modularization
>>> feature so they only be able to create new SyntContext objects. There
>>> are ways that a SyntContext object created by a developer can be
>>> disposed by Synth L&F and put to the unused object queue. This can lead
>>> to a memory leak.
>>>
>>> There are 2 options to fix the issue: provide a public API for the
>>> SyntContext object custom disposing or just get rid of the unused 
>>> object
>>> queue.
>>>
>>> Effective Java Guide has a suggestion: ?avoiding object creation by
>>> maintaining your own object pool is a bad idea unless the objects in 
>>> the
>>> pool are extremely heavyweight?
>>>
>>> To check if there are memory or performance degradation for the second
>>> solution I used SwingMark application which extensively creates and
>>> paints a lot of Swing components like labels, menus and others.
>>>
>>> The tests were run 5 times with using the object queue and without it.
>>> There results can be found at:
>>> http://cr.openjdk.java.net/~alexsch/8132791/profiling/results_3-5
>>>
>>> The minimum and maximum values from 5 runs are:
>>>
>>> Tests which used an object queue:
>>> used memory (in bytes)
>>>    min: 3.75 million max: 3.78 million
>>> heap size  (in bytes)
>>>    min: 11.53 million max: 12.58 million
>>> elapsed time (in milliseconds)
>>>    min: 57.27 thousand max: 57.97 thousand
>>> requests for SynthContext objects: 380 thousands
>>> created objects: 21
>>>
>>> Tests which did not use an object queue:
>>> used memory (in bytes)
>>>    min:  3.71 million max: 3.79 million
>>> heap size   (in bytes)
>>>    min: 11.53 million max: 12.58 million
>>> elapsed time (in milliseconds)
>>>    min: 57.90 thousand max: 57.97 thousand
>>> requests for SynthContext objects: 380 thousands
>>> created objects: 380 thousands
>>>
>>> There were about 380 thousand request for SynthContext objects in both
>>> tests but only 21 object were crated for the first ones.
>>>
>>> However, the used memory size and running time are nearly the same for
>>> both runs for these particular tests.
>>>
>>> According to the test results it looks reasonable to remove the custom
>>> object pool support from the SynthContext object.
>>>
>>> Thanks,
>>> Alexandr.
>>>
>>
>>
>



From alexandr.scherbatiy at oracle.com  Thu Apr 14 11:32:54 2016
From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy)
Date: Thu, 14 Apr 2016 15:32:54 +0400
Subject: <Swing Dev> [9] Review request for 8153276: [TEST_BUG]
 javax/swing/JFileChooser/ShellFolderQueries/ShellFolderQueriesTest.java
In-Reply-To: <570F49B0.3080904@oracle.com>
References: <570E52B4.7090907@oracle.com> <570E54EE.7030700@oracle.com>
	<570E9380.7080904@oracle.com> <570E968F.7080003@oracle.com>
	<570F412D.3040307@oracle.com> <570F49B0.3080904@oracle.com>
Message-ID: <570F7FE6.9070608@oracle.com>

The fix looks good to me.

Thanks,
Alexandr.

On 14/04/16 11:41, Yuri Nesterenko wrote:
> Ok, +1, simplest working device is better, definitely in the tests.
>
> -yan
>
> On 04/14/2016 10:05 AM, Semyon Sadetsky wrote:
>> On 4/13/2016 9:57 PM, Philip Race wrote:
>>> Perhaps better but given the minimal use here can't we just
>>> replace it with
>>> System.getProperty("os.name").toLowerCase().contains("windows") ?
>>>
>>> Then you neither need jtreg to run it, nor internal API.
>> I agree. See the updated webrev:
>> http://cr.openjdk.java.net/~ssadetsky/8153276/webrev.01/
>>
>> --Semyon
>>>
>>> -phil.
>>>
>>> On 4/13/16, 11:44 AM, Sergey Bylokhov wrote:
>>>> +1
>>>>
>>>> On 13.04.16 17:17, Yuri Nesterenko wrote:
>>>>> Looks good to me.
>>>>>
>>>>> -yan
>>>>>
>>>>> On 04/13/2016 05:07 PM, Semyon Sadetsky wrote:
>>>>>> Hello,
>>>>>>
>>>>>> Please review fix for JDK9:
>>>>>>
>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8153276
>>>>>> webrev: http://cr.openjdk.java.net/~ssadetsky/8153276/webrev.00/
>>>>>>
>>>>>> Internal API usage sun.awt.OSInfo was replaced by
>>>>>> jdk.testlibrary.OSInfo.
>>>>>>
>>>>>> --Semyon
>>>>>>
>>>>>
>>>>
>>>>
>>
>



From Sergey.Bylokhov at oracle.com  Thu Apr 14 13:07:55 2016
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Thu, 14 Apr 2016 16:07:55 +0300
Subject: <Swing Dev> [9] Review request for 8132791 No access to
 SynthContext.getContext()
In-Reply-To: <570F7C2F.6020200@oracle.com>
References: <570D4661.70507@oracle.com> <570D7954.1090603@oracle.com>
	<570E9A91.5090905@oracle.com> <570EA19F.5090807@oracle.com>
	<570F7C2F.6020200@oracle.com>
Message-ID: <570F962B.4040309@oracle.com>

On 14.04.16 14:17, Alexander Scherbatiy wrote:
>    The tests with -Xmx5m options have the similar results too:
> http://cr.openjdk.java.net/~alexsch/8132791/profiling/results-xmx5m_3-5/

Thanks, looks fine.


>>>> On 12.04.16 22:02, Alexander Scherbatiy wrote:
>>>>>
>>>>> Hello,
>>>>>
>>>>> Could you review the fix:
>>>>>    bug: https://bugs.openjdk.java.net/browse/JDK-8132791
>>>>>    webrev: http://cr.openjdk.java.net/~alexsch/8132791/webrev.00
>>>>>
>>>>>
>>>>> SynthContext is an object with 4 fields which is used a lot by
>>>>> Synth L&F
>>>>> for components painting. It has an internal API which allows to put
>>>>> unused objects to queue and reuse them later. Application developers
>>>>> will not be able to have access to this API in JDK 9 with
>>>>> modularization
>>>>> feature so they only be able to create new SyntContext objects. There
>>>>> are ways that a SyntContext object created by a developer can be
>>>>> disposed by Synth L&F and put to the unused object queue. This can
>>>>> lead
>>>>> to a memory leak.
>>>>>
>>>>> There are 2 options to fix the issue: provide a public API for the
>>>>> SyntContext object custom disposing or just get rid of the unused
>>>>> object
>>>>> queue.
>>>>>
>>>>> Effective Java Guide has a suggestion: ?avoiding object creation by
>>>>> maintaining your own object pool is a bad idea unless the objects
>>>>> in the
>>>>> pool are extremely heavyweight?
>>>>>
>>>>> To check if there are memory or performance degradation for the second
>>>>> solution I used SwingMark application which extensively creates and
>>>>> paints a lot of Swing components like labels, menus and others.
>>>>>
>>>>> The tests were run 5 times with using the object queue and without it.
>>>>> There results can be found at:
>>>>> http://cr.openjdk.java.net/~alexsch/8132791/profiling/results_3-5
>>>>>
>>>>> The minimum and maximum values from 5 runs are:
>>>>>
>>>>> Tests which used an object queue:
>>>>> used memory (in bytes)
>>>>>    min: 3.75 million max: 3.78 million
>>>>> heap size  (in bytes)
>>>>>    min: 11.53 million max: 12.58 million
>>>>> elapsed time (in milliseconds)
>>>>>    min: 57.27 thousand max: 57.97 thousand
>>>>> requests for SynthContext objects: 380 thousands
>>>>> created objects: 21
>>>>>
>>>>> Tests which did not use an object queue:
>>>>> used memory (in bytes)
>>>>>    min:  3.71 million max: 3.79 million
>>>>> heap size   (in bytes)
>>>>>    min: 11.53 million max: 12.58 million
>>>>> elapsed time (in milliseconds)
>>>>>    min: 57.90 thousand max: 57.97 thousand
>>>>> requests for SynthContext objects: 380 thousands
>>>>> created objects: 380 thousands
>>>>>
>>>>> There were about 380 thousand request for SynthContext objects in both
>>>>> tests but only 21 object were crated for the first ones.
>>>>>
>>>>> However, the used memory size and running time are nearly the same for
>>>>> both runs for these particular tests.
>>>>>
>>>>> According to the test results it looks reasonable to remove the custom
>>>>> object pool support from the SynthContext object.
>>>>>
>>>>> Thanks,
>>>>> Alexandr.
>>>>>
>>>>
>>>>
>>>
>>
>>
>


-- 
Best regards, Sergey.


From prasanta.sadhukhan at oracle.com  Thu Apr 14 14:02:19 2016
From: prasanta.sadhukhan at oracle.com (prasanta sadhukhan)
Date: Thu, 14 Apr 2016 19:32:19 +0530
Subject: <Swing Dev> Review request for 8025430: [TEST_BUG]
 javax/swing/JEditorPane/5076514/bug5076514.java failed since jdk8b108
In-Reply-To: <9faef317-8985-4a54-ac5f-3ac8052ab490@default>
References: <d0d58726-fb7f-4db2-88da-cbccdf604383@default>
	<570E5566.2010209@oracle.com>
	<9faef317-8985-4a54-ac5f-3ac8052ab490@default>
Message-ID: <570FA2EB.5080200@oracle.com>

ok. looks good to me.

Regards
Prasanta
On 4/14/2016 1:59 PM, Muneer Kolarkunnu wrote:
>
> I added the @run tag and updated the review: 
> http://cr.openjdk.java.net/~ntv/muneer/8025430/webrev.01/ 
> <http://cr.openjdk.java.net/%7Entv/muneer/8025430/webrev.01/>
>
> I tested with latest jtreg with and without @run tag, both are working.
>
> But there is a difference in the logs in the following line:
>
> *Without @run flag:*
>
> command: main bug5076514
>
> reason: Assumed action based on file name: run main bug5076514
>
> *With @run flag:*
>
> command: main bug5076514
> reason: User specified action: run main bug5076514
>
> Regards,
>
> Muneer
>
> *From:*prasanta sadhukhan
> *Sent:* Wednesday, April 13, 2016 7:49 PM
> *To:* Muneer Kolarkunnu; swing-dev at openjdk.java.net
> *Subject:* Re: Review request for 8025430: [TEST_BUG] 
> javax/swing/JEditorPane/5076514/bug5076514.java failed since jdk8b108
>
> You need to add
> @run main <test> for latest jtreg to run. Have you run against latest 
> jtreg?
>
> Regards
> Prasanta
>
> On 4/13/2016 6:10 PM, Muneer Kolarkunnu wrote:
>
>     Hi All,
>
>                     Please review the fix for test bug 8025430,
>
>                     Webrev:
>     http://cr.openjdk.java.net/~ntv/muneer/8025430/webrev.00/
>     <http://cr.openjdk.java.net/%7Entv/muneer/8025430/webrev.00/>
>
>                     Bug: https://bugs.openjdk.java.net/browse/JDK-8025430
>
>     Issue:
>
>     It is a test bug, API checkSystemClipboardAccess() is deprecated.
>     Deprecated message from java doc for your reference : "The
>     dependency on AWTPermission creates an impediment to future
>     modularization of the Java platform. Users of this method should
>     instead invoke checkPermission(java.security.Permission) directly.
>     This method will be changed in a future release to check the
>     permission java.security.AllPermission."
>
>     Fix:
>
>                   API  checkPermission(java.security.Permission) is
>     used instead of checkSystemClipboardAccess()
>
>     Regards,
>
>     Muneer
>

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

From Sergey.Bylokhov at oracle.com  Thu Apr 14 15:13:14 2016
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Thu, 14 Apr 2016 18:13:14 +0300
Subject: <Swing Dev> [9] Review Request: 8143346 Broken link in
	java.beans.XMLEncoder
Message-ID: <570FB38A.4020902@oracle.com>

Hello,
Please review the fix for jdk9.

The bunch of links in client code were updated to point to the new 
location on oracle.com site.

During the fix I realized that not all of data stored on java.sun.com 
were moved to the oracle.com. For example:
The article "Using Timers in Swing Applications"
http://java.sun.com/products/jfc/tsc/articles/timer/

I leave such links for now, and will try to find someone who can 
probably restore them on oracle.com.

Another problem I found is that some of the articles have a broken 
formatting (take a look to <java>,. etc):
http://www.oracle.com/technetwork/java/persistence3-139471.html
I'll try to find someone who will be able to fix it.

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


-- 
Best regards, Sergey.


From Sergey.Bylokhov at oracle.com  Thu Apr 14 15:15:39 2016
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Thu, 14 Apr 2016 18:15:39 +0300
Subject: <Swing Dev> Review request for 8025430: [TEST_BUG]
 javax/swing/JEditorPane/5076514/bug5076514.java failed since jdk8b108
In-Reply-To: <570FA2EB.5080200@oracle.com>
References: <d0d58726-fb7f-4db2-88da-cbccdf604383@default>
	<570E5566.2010209@oracle.com>
	<9faef317-8985-4a54-ac5f-3ac8052ab490@default>
	<570FA2EB.5080200@oracle.com>
Message-ID: <570FB41B.2050305@oracle.com>

looks fine.

On 14.04.16 17:02, prasanta sadhukhan wrote:
> ok. looks good to me.
>
> Regards
> Prasanta
> On 4/14/2016 1:59 PM, Muneer Kolarkunnu wrote:
>>
>> I added the @run tag and updated the review:
>> http://cr.openjdk.java.net/~ntv/muneer/8025430/webrev.01/
>> <http://cr.openjdk.java.net/%7Entv/muneer/8025430/webrev.01/>
>>
>> I tested with latest jtreg with and without @run tag, both are working.
>>
>> But there is a difference in the logs in the following line:
>>
>> *Without @run flag:*
>>
>> command: main bug5076514
>>
>> reason: Assumed action based on file name: run main bug5076514
>>
>> *With @run flag:*
>>
>> command: main bug5076514
>> reason: User specified action: run main bug5076514
>>
>> Regards,
>>
>> Muneer
>>
>> *From:*prasanta sadhukhan
>> *Sent:* Wednesday, April 13, 2016 7:49 PM
>> *To:* Muneer Kolarkunnu; swing-dev at openjdk.java.net
>> *Subject:* Re: Review request for 8025430: [TEST_BUG]
>> javax/swing/JEditorPane/5076514/bug5076514.java failed since jdk8b108
>>
>> You need to add
>> @run main <test> for latest jtreg to run. Have you run against latest
>> jtreg?
>>
>> Regards
>> Prasanta
>>
>> On 4/13/2016 6:10 PM, Muneer Kolarkunnu wrote:
>>
>>     Hi All,
>>
>>                     Please review the fix for test bug 8025430,
>>
>>                     Webrev:
>>     <http://cr.openjdk.java.net/%7Entv/muneer/8025430/webrev.00/>http://cr.openjdk.java.net/~ntv/muneer/8025430/webrev.00/
>>
>>                     Bug: https://bugs.openjdk.java.net/browse/JDK-8025430
>>
>>     Issue:
>>
>>     It is a test bug, API checkSystemClipboardAccess() is deprecated.
>>     Deprecated message from java doc for your reference : "The
>>     dependency on AWTPermission creates an impediment to future
>>     modularization of the Java platform. Users of this method should
>>     instead invoke checkPermission(java.security.Permission) directly.
>>     This method will be changed in a future release to check the
>>     permission java.security.AllPermission."
>>
>>     Fix:
>>
>>                   API  checkPermission(java.security.Permission) is
>>     used instead of checkSystemClipboardAccess()
>>
>>     Regards,
>>
>>     Muneer
>>
>


-- 
Best regards, Sergey.


From philip.race at oracle.com  Thu Apr 14 16:04:06 2016
From: philip.race at oracle.com (Phil Race)
Date: Thu, 14 Apr 2016 09:04:06 -0700
Subject: <Swing Dev> [9] Review Request: 8143346 Broken link in
	java.beans.XMLEncoder
In-Reply-To: <570FB38A.4020902@oracle.com>
References: <570FB38A.4020902@oracle.com>
Message-ID: <570FBF76.8090708@oracle.com>

I don't know that there is any actual problem with any of the new URLs here
but I don't have much information about what is and is not supposed to work.

In particular
1) Is the  java.sun.com -> oracle.com redirect considered to be something
we can rely on for ever ? Given the number of references to the former
it may need to be.

2) But on the other hand, is there a policy of updating the links as 
time permits ?

3) I don't know how permanent names like "persistence4-140124.html" are
considered to be ? I would guess this is a generated name and perhaps next
time the web page "tree" is re-generated it'll be a different name ?

4) Although I only see it in a comment, it is odd in JDK 9 docs to 
reference JDK 8:-

+// <https://docs.oracle.com/javase/8/docs/technotes/guides/access/index.html>

But I don't think we can do anything about that.

5) || src/demo/share/jvmti/index.html is presumably owned by someone else ..
but I don't suppose they will mind you fixing it.


For 1 -> 3 can we ask the docs team ?

-phil.

On 04/14/2016 08:13 AM, Sergey Bylokhov wrote:
> Hello,
> Please review the fix for jdk9.
>
> The bunch of links in client code were updated to point to the new 
> location on oracle.com site.
>
> During the fix I realized that not all of data stored on java.sun.com 
> were moved to the oracle.com. For example:
> The article "Using Timers in Swing Applications"
> http://java.sun.com/products/jfc/tsc/articles/timer/
>
> I leave such links for now, and will try to find someone who can 
> probably restore them on oracle.com.
>
> Another problem I found is that some of the articles have a broken 
> formatting (take a look to <java>,. etc):
> http://www.oracle.com/technetwork/java/persistence3-139471.html
> I'll try to find someone who will be able to fix it.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8143346
> Webrev can be found at: 
> http://cr.openjdk.java.net/~serb/8143346/webrev.04
>
>

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

From Sergey.Bylokhov at oracle.com  Thu Apr 14 16:22:16 2016
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Thu, 14 Apr 2016 19:22:16 +0300
Subject: <Swing Dev> [9] Review Request: 8143346 Broken link in
	java.beans.XMLEncoder
In-Reply-To: <570FBF76.8090708@oracle.com>
References: <570FB38A.4020902@oracle.com> <570FBF76.8090708@oracle.com>
Message-ID: <570FC3B8.8080800@oracle.com>

On 14.04.16 19:04, Phil Race wrote:
> In particular
> 1) Is the  java.sun.com -> oracle.com redirect considered to be something
> we can rely on for ever ? Given the number of references to the former
> it may need to be.
>
> 2) But on the other hand, is there a policy of updating the links as
> time permits ?
>
> 3) I don't know how permanent names like "persistence4-140124.html" are
> considered to be ? I would guess this is a generated name and perhaps next
> time the web page "tree" is re-generated it'll be a different name ?
> For 1 -> 3 can we ask the docs team ?

I think these links should be stable, for example the fix [1][2] adds 
the similar links, and they still work.
[1] https://bugs.openjdk.java.net/browse/JDK-7072328
[2] https://bugs.openjdk.java.net/browse/JDK-8020688

But it will be good to double check the policy about the links, and find 
the responsible team for the site content (I am sure the formatting 
should be updated).


-- 
Best regards, Sergey.


From Sergey.Bylokhov at oracle.com  Thu Apr 14 16:41:34 2016
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Thu, 14 Apr 2016 19:41:34 +0300
Subject: <Swing Dev> [9] JDK-8049069 : JButton incorrect behaviour on
 button release
In-Reply-To: <570F5A8E.4010109@oracle.com>
References: <b8077c49-2413-40ed-b765-43847cc52eb6@default>
	<56F46408.7060403@oracle.com>
	<529629fc-b68d-4a5b-8882-1bb2b7bc409e@default>
	<56FA825E.8030608@oracle.com>
	<785d1c7f-636f-4da1-9514-23b6ff941ce0@default>
	<570E9E2C.1070805@oracle.com>
	<f44cc821-34b5-443f-8ddb-9deef910f016@default>
	<570F5A8E.4010109@oracle.com>
Message-ID: <570FC83E.3060103@oracle.com>

+1

On 14.04.16 11:53, Alexander Scherbatiy wrote:
>
> The fix looks good to me.
>
> Thanks,
> Alexandr.
>
> On 14/04/16 10:44, Ajit Ghaisas wrote:
>> Thanks Alex for the good suggestion to have a private method to avoid
>> code repetition.
>>
>> I have modified the code accordingly.  Please review the updated webrev.
>> http://cr.openjdk.java.net/~aghaisas/8049069/webrev.02/
>>
>> Regards,
>> Ajit
>>
>> -----Original Message-----
>> From: Alexander Scherbatiy
>> Sent: Thursday, April 14, 2016 1:00 AM
>> To: Ajit Ghaisas; Sergey Bylokhov; swing-dev at openjdk.java.net
>> Subject: Re: <Swing Dev> [9] JDK-8049069 : JButton incorrect behaviour
>> on button release
>>
>>
>> There is the same code which is repeated in three methods. Is it
>> possible to add a private method which takes button, button mask, and
>> event as parameters and returns true if the mouse event specifies the
>> given button? It would be possible to reuse it in public methods.
>>
>> Thanks,
>> Alexandr.
>>
>> On 13/04/16 17:08, Ajit Ghaisas wrote:
>>> Hi,
>>>
>>>       Thanks for the review.
>>>       Your questioning lead me to think about correcting the
>>> SwingUtilities isXXXMouseButton() methods.
>>>       It is possible to identify under which mouse state these
>>> methods are invoked using the MouseEvent parameter.
>>>       Please review the updated webrev.
>>>       http://cr.openjdk.java.net/~aghaisas/8049069/webrev.01/
>>>
>>>       With this fix, I have verified tests mentioned under :
>>> JDK-7146377, JDK-7088744 and JDK-8049069. All of them passed.
>>>
>>> Regards,
>>> Ajit
>>>
>>> -----Original Message-----
>>> From: Alexander Scherbatiy
>>> Sent: Tuesday, March 29, 2016 6:56 PM
>>> To: Ajit Ghaisas; Sergey Bylokhov; swing-dev at openjdk.java.net; Rajeev
>>> Chamyal
>>> Subject: Re: <Swing Dev> [9] JDK-8049069 : JButton incorrect behaviour
>>> on button release
>>>
>>> On 28/03/16 15:43, Ajit Ghaisas wrote:
>>>> Hi,
>>>>        In JDK-6u115, this bug is not reproducible.
>>>>        Fix for JDK-7088744 did  not break the JButton behavior.
>>>>        This bug is regression due to changes done to SwingUtilities
>>>> as a fix of JDK-7146377.
>>>>
>>>>        After reading comments on JBS for JDK-7146377, I realized
>>>> that the modification was done to support left mouse drag.
>>>>        Ideally, it should have been done using a new public method
>>>> such as isLeftMouseButtonDown() and using it in test/client code.
>>>>        In this case, we will need to add isMiddleMouseButtonDown()
>>>> and isRightMouseButtonDown() methods as well.
>>>>        Modifying existing APIs as well as introducing new public APIs
>>>> raises a risk of forced test/client code modifications. (This is the
>>>> reason why I have chosen option 2 as mentioned below)
>>>      The SwingUtilities.isLeftMouseButton() method used not only in
>>> JButton listener but in other places too.
>>>      Could you check some component like JSpinner with proper L&F
>>> that it does not have the same issue described in 8049069.
>>>
>>>      It is possible just to add one internal method
>>> isLeftMouseButtonDown() to the sun.swing.SwingUtilities2 class first.
>>>      Will it be enough to  fix these two issues 8049069 and 7146377?
>>>
>>>      Thanks,
>>>      Alexandr.
>>>>        I have fixed the JDK-8049069 in BasicButtonListener.java as
>>>> there is no need to use swingUtilities methods in mousePressed() and
>>>> mouseReleased() methods.
>>>>
>>>> Regards,
>>>> Ajit
>>>>
>>>> -----Original Message-----
>>>> From: Sergey Bylokhov
>>>> Sent: Friday, March 25, 2016 3:33 AM
>>>> To: Ajit Ghaisas; swing-dev at openjdk.java.net; Alexander Scherbatiy;
>>>> Rajeev Chamyal
>>>> Subject: Re: <Swing Dev> [9] JDK-8049069 : JButton incorrect
>>>> behaviour on button release
>>>>
>>>> Hi, Ajit.
>>>> Is this bug a regression of JDK-7088744 or JDK-8049069, or it works
>>>> this way in jdk6 as well?
>>>> I guess the code in jdk6 was something like this:
>>>>         public static boolean isLeftMouseButton(MouseEvent anEvent) {
>>>>              return ((anEvent.getModifiers() &
>>>> InputEvent.BUTTON1_MASK) != 0);
>>>>         }
>>>>
>>>> On 24.03.16 12:55, Ajit Ghaisas wrote:
>>>>> Hi,
>>>>>
>>>>> Bug : https://bugs.openjdk.java.net/browse/JDK-8049069
>>>>>
>>>>> Issue :  A JButton which is pressed using left mouse button gets
>>>>> released if right mouse button is pressed and released.
>>>>>
>>>>> Root cause :
>>>>> ---------------
>>>>> In file BasicButtonListener.java, mousePressed() and
>>>>> mouseReleased() methods check whether the event is from left mouse
>>>>> button.
>>>>> This check is done using ----  if
>>>>> (SwingUtilities.isLeftMouseButton(e)
>>>>> ) This method returns true if left mouse button is down OR event is
>>>>> from left mouse button.
>>>>> SwingUtilities.isLeftMouseButton() returns true if it is called for
>>>>> right mouse event while holding left button down. This causes
>>>>> mouseReleased() method to release pressed JButton.
>>>>>
>>>>>
>>>>> Alternatives considered :
>>>>> -----------------------------
>>>>> 1. Modifying SwingUtilities.isLeftMouseButton() method to only test
>>>>> for whether the event is from left mouse button only 2. Modifying
>>>>> mousePressed() and mouseReleased() methods to check for whether the
>>>>> event is from left mouse button using argument passed to them.
>>>>>
>>>>> Option 1 will break the code wherever
>>>>> SwingUtilities.isLeftMouseButton() is used to test for left mouse
>>>>> button down.
>>>>> File history revealed that the mouse button down condition is added
>>>>> to fix another bug.
>>>>>
>>>>> Hence, option 2 is chosen as it is safe and intuitive.
>>>>> I have also added a test. It passes on Windows, Linux and Mac.
>>>>> Test mentioned in comment on the bug also passed.
>>>>>
>>>>> Please review the webrev :
>>>>>
>>>>> http://cr.openjdk.java.net/~aghaisas/8049069/webrev.00/
>>>>>
>>>>> Regards,
>>>>> Ajit
>>>>>
>>>> --
>>>> Best regards, Sergey.
>


-- 
Best regards, Sergey.


From prem.balakrishnan at oracle.com  Fri Apr 15 08:22:19 2016
From: prem.balakrishnan at oracle.com (Prem Balakrishnan)
Date: Fri, 15 Apr 2016 01:22:19 -0700 (PDT)
Subject: <Swing Dev> Review Request JDK-8153056 : 8152647(duplicate of
 6439354) Manual Test always passes
In-Reply-To: <56FD661F.7030803@oracle.com>
References: <604bc0a3-ff40-459c-a6c8-63a84bbbeae8@default>
	<56FC085C.2010206@oracle.com>
	<092365d9-5be2-487a-be4d-8c169a1820ed@default>
	<56FD661F.7030803@oracle.com>
Message-ID: <9936f551-445f-4108-8f0f-c790e1fbf0f8@default>

Hi Alexander,

 

Thank you for the review.

 

Updated test with CountDownLatch.

http://cr.openjdk.java.net/~arapte/prem/8153056/webrev.01/

 

Regards,
Prem

 

 

From: Alexander Scherbatiy 
Sent: Thursday, March 31, 2016 11:32 PM
To: Prem Balakrishnan; Sergey Bylokhov; Semyon Sadetsky; Rajeev Chamyal; swing-dev at openjdk.java.net
Subject: Re: Review Request JDK-8153056 : 8152647(duplicate of 6439354) Manual Test always passes

 

On 31/03/16 14:59, Prem Balakrishnan wrote:



Hi Alexander,

 

Thankyou for the review.

I agree with what you said ,jtreg  does not wait for new created JFrame.

Executed test on : 

Jtreg version: 4.2.0 and 4.1 , facing same issue, even without user/tester validating the output test status shows passed.


  It looks like jtreg does not wait for UI closing for manual main tests.
  May be it is better to use CountDownLatch in this case? It least there will not be necessary to distinguish InterruptedException generated by program of by other reasons.  

 Thanks,
 Alexandr.



 

Hence test enhanced to overcome the above scenario.

 

 

Regards,

Prem

 

From: Alexander Scherbatiy 
Sent: Wednesday, March 30, 2016 10:40 PM
To: Prem Balakrishnan; Sergey Bylokhov; Semyon Sadetsky; Rajeev Chamyal; HYPERLINK "mailto:swing-dev at openjdk.java.net"swing-dev at openjdk.java.net
Subject: Re: Review Request JDK-8153056 : 8152647(duplicate of 6439354) Manual Test always passes

 

On 30/03/16 16:08, Prem Balakrishnan wrote:




Hi,

Please review fix for JDK9,

Bug: https://bugs.openjdk.java.net/browse/JDK-8153056 

Webrev: HYPERLINK "http://cr.openjdk.java.net/%7Earapte/prem/8153056/webrev.00/"http://cr.openjdk.java.net/~arapte/prem/8153056/webrev.00/

 

  

Issue:

8152647(duplicate of 6439354) Manual Test always passes

 

Fix:

Enhanced Test(with Pass, Fail and Timeout)


   It does not look as issue in the test but rather as jtreg does not wait for new created JFrame.
   Could you run the test without the fix with previous version of jtreg? Is the JFrame is shown in this case?

  Thanks,
  Alexandr.




 

Regards,
Prem

 

 

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

From alexandr.scherbatiy at oracle.com  Fri Apr 15 13:46:43 2016
From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy)
Date: Fri, 15 Apr 2016 17:46:43 +0400
Subject: <Swing Dev> [9] Review request for 8152677 [macosx] All files
 filter can't be selected in JFileChooser
Message-ID: <5710F0C3.5030201@oracle.com>


Hello,

Could you review the fix:
   bug: https://bugs.openjdk.java.net/browse/JDK-8152677
   webrev: http://cr.openjdk.java.net/~alexsch/8152677/webrev.00

   FilterComboBoxModel from AquaFileChooserUI overrides 
getSelectedItem() method to always return the selected filter from the 
file chooser.

   JFileChooser.setFileFilter(FileFilter) first assign the passed filter 
to fileFilter field and then fire "fileFilterChanged" property change 
event. This leads that FilterComboBoxModel compares new file filter with 
the selected one (which has the same value because it is obtained from 
JFileChooser.fileFilter field) and do not updated JComboBox internal 
structure so JComboBox.selectedItemReminder field still points to the 
old one.

   When a user selects ?All Files? filter which is the first item from a 
JFileChooser the JComboBox does not fire the action event because 
selectedItemReminder points to the same first item.

   The proposed solution is to remember the previous selected item in 
the AquaFileChooserUI.FilterComboBoxModel.

   Thanks,
   Alexandr.


From alexandr.scherbatiy at oracle.com  Fri Apr 15 13:48:54 2016
From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy)
Date: Fri, 15 Apr 2016 17:48:54 +0400
Subject: <Swing Dev> Review Request JDK-8153056 : 8152647(duplicate of
 6439354) Manual Test always passes
In-Reply-To: <9936f551-445f-4108-8f0f-c790e1fbf0f8@default>
References: <604bc0a3-ff40-459c-a6c8-63a84bbbeae8@default>
	<56FC085C.2010206@oracle.com>
	<092365d9-5be2-487a-be4d-8c169a1820ed@default>
	<56FD661F.7030803@oracle.com>
	<9936f551-445f-4108-8f0f-c790e1fbf0f8@default>
Message-ID: <5710F146.3010800@oracle.com>


   The fix looks good to me.

   Thanks,
   Alexandr.

On 15/04/16 12:22, Prem Balakrishnan wrote:
>
> Hi Alexander,
>
> Thank you for the review.
>
> Updated test with CountDownLatch.
>
> http://cr.openjdk.java.net/~arapte/prem/8153056/webrev.01/ 
> <http://cr.openjdk.java.net/%7Earapte/prem/8153056/webrev.01/>
>
> Regards,
> Prem
>
> *From:*Alexander Scherbatiy
> *Sent:* Thursday, March 31, 2016 11:32 PM
> *To:* Prem Balakrishnan; Sergey Bylokhov; Semyon Sadetsky; Rajeev 
> Chamyal; swing-dev at openjdk.java.net
> *Subject:* Re: Review Request JDK-8153056 : 8152647(duplicate of 
> 6439354) Manual Test always passes
>
> On 31/03/16 14:59, Prem Balakrishnan wrote:
>
> Hi Alexander,
>
> Thankyou for the review.
>
> I agree with what you said ,jtreg  does not wait for new created JFrame.
>
> Executed test on :
>
> Jtreg version: 4.2.0 and 4.1 , facing same issue, even without 
> user/tester validating the output test status shows passed.
>
>
>   It looks like jtreg does not wait for UI closing for manual main tests.
>   May be it is better to use CountDownLatch in this case? It least 
> there will not be necessary to distinguish InterruptedException 
> generated by program of by other reasons.
>
>  Thanks,
>  Alexandr.
>
> Hence test enhanced to overcome the above scenario.
>
> Regards,
>
> Prem
>
> *From:*Alexander Scherbatiy
> *Sent:* Wednesday, March 30, 2016 10:40 PM
> *To:* Prem Balakrishnan; Sergey Bylokhov; Semyon Sadetsky; Rajeev 
> Chamyal; swing-dev at openjdk.java.net <mailto:swing-dev at openjdk.java.net>
> *Subject:* Re: Review Request JDK-8153056 : 8152647(duplicate of 
> 6439354) Manual Test always passes
>
> On 30/03/16 16:08, Prem Balakrishnan wrote:
>
>
> Hi*,*
>
> Please review fix for JDK9,
>
> *Bug:*https://bugs.openjdk.java.net/browse/JDK-8153056
>
> *Webrev:*http://cr.openjdk.java.net/~arapte/prem/8153056/webrev.00/ 
> <http://cr.openjdk.java.net/%7Earapte/prem/8153056/webrev.00/>
>
> *Issue:*
>
> 8152647(duplicate of 6439354) Manual Test always passes
>
> *Fix:*
>
> Enhanced Test(with Pass, Fail and Timeout)
>
>
>    It does not look as issue in the test but rather as jtreg does not 
> wait for new created JFrame.
>    Could you run the test without the fix with previous version of 
> jtreg? Is the JFrame is shown in this case?
>
>   Thanks,
>   Alexandr.
>
>
> Regards,
> Prem
>

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

From Sergey.Bylokhov at oracle.com  Fri Apr 15 14:27:22 2016
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Fri, 15 Apr 2016 17:27:22 +0300
Subject: <Swing Dev> [9] Review request for 8152677 [macosx] All files
 filter can't be selected in JFileChooser
In-Reply-To: <5710F0C3.5030201@oracle.com>
References: <5710F0C3.5030201@oracle.com>
Message-ID: <5710FA4A.4080502@oracle.com>

Is it possible that default selection of FileChooser will be different 
from "acceptAllFileFilter"?

On 15.04.16 16:46, Alexander Scherbatiy wrote:
>
> Hello,
>
> Could you review the fix:
>    bug: https://bugs.openjdk.java.net/browse/JDK-8152677
>    webrev: http://cr.openjdk.java.net/~alexsch/8152677/webrev.00
>
>    FilterComboBoxModel from AquaFileChooserUI overrides
> getSelectedItem() method to always return the selected filter from the
> file chooser.
>
>    JFileChooser.setFileFilter(FileFilter) first assign the passed filter
> to fileFilter field and then fire "fileFilterChanged" property change
> event. This leads that FilterComboBoxModel compares new file filter with
> the selected one (which has the same value because it is obtained from
> JFileChooser.fileFilter field) and do not updated JComboBox internal
> structure so JComboBox.selectedItemReminder field still points to the
> old one.
>
>    When a user selects ?All Files? filter which is the first item from a
> JFileChooser the JComboBox does not fire the action event because
> selectedItemReminder points to the same first item.
>
>    The proposed solution is to remember the previous selected item in
> the AquaFileChooserUI.FilterComboBoxModel.
>
>    Thanks,
>    Alexandr.


-- 
Best regards, Sergey.


From prasanta.sadhukhan at oracle.com  Fri Apr 15 15:06:55 2016
From: prasanta.sadhukhan at oracle.com (prasanta sadhukhan)
Date: Fri, 15 Apr 2016 20:36:55 +0530
Subject: <Swing Dev> Review Request JDK-8153056 : 8152647(duplicate of
 6439354) Manual Test always passes
In-Reply-To: <9936f551-445f-4108-8f0f-c790e1fbf0f8@default>
References: <604bc0a3-ff40-459c-a6c8-63a84bbbeae8@default>
	<56FC085C.2010206@oracle.com>
	<092365d9-5be2-487a-be4d-8c169a1820ed@default>
	<56FD661F.7030803@oracle.com>
	<9936f551-445f-4108-8f0f-c790e1fbf0f8@default>
Message-ID: <5711038F.9030808@oracle.com>

Hi Prem,

Why did you remove 1999 from the copyright? I guess that's the initial 
year when this test was written. I guess we need to keep it and make 
like 1999,2016.
I guess also this try/catch block is redundant

try {
56 latch.await();
57 } catch (InterruptedException ie) {
58 throw ie;
59 }


Regards
Prasanta
On 4/15/2016 1:52 PM, Prem Balakrishnan wrote:
>
> Hi Alexander,
>
> Thank you for the review.
>
> Updated test with CountDownLatch.
>
> http://cr.openjdk.java.net/~arapte/prem/8153056/webrev.01/ 
> <http://cr.openjdk.java.net/%7Earapte/prem/8153056/webrev.01/>
>
> Regards,
> Prem
>
> *From:*Alexander Scherbatiy
> *Sent:* Thursday, March 31, 2016 11:32 PM
> *To:* Prem Balakrishnan; Sergey Bylokhov; Semyon Sadetsky; Rajeev 
> Chamyal; swing-dev at openjdk.java.net
> *Subject:* Re: Review Request JDK-8153056 : 8152647(duplicate of 
> 6439354) Manual Test always passes
>
> On 31/03/16 14:59, Prem Balakrishnan wrote:
>
> Hi Alexander,
>
> Thankyou for the review.
>
> I agree with what you said ,jtreg  does not wait for new created JFrame.
>
> Executed test on :
>
> Jtreg version: 4.2.0 and 4.1 , facing same issue, even without 
> user/tester validating the output test status shows passed.
>
>
>   It looks like jtreg does not wait for UI closing for manual main tests.
>   May be it is better to use CountDownLatch in this case? It least 
> there will not be necessary to distinguish InterruptedException 
> generated by program of by other reasons.
>
>  Thanks,
>  Alexandr.
>
> Hence test enhanced to overcome the above scenario.
>
> Regards,
>
> Prem
>
> *From:*Alexander Scherbatiy
> *Sent:* Wednesday, March 30, 2016 10:40 PM
> *To:* Prem Balakrishnan; Sergey Bylokhov; Semyon Sadetsky; Rajeev 
> Chamyal; swing-dev at openjdk.java.net <mailto:swing-dev at openjdk.java.net>
> *Subject:* Re: Review Request JDK-8153056 : 8152647(duplicate of 
> 6439354) Manual Test always passes
>
> On 30/03/16 16:08, Prem Balakrishnan wrote:
>
>
> Hi*,*
>
> Please review fix for JDK9,
>
> *Bug:*https://bugs.openjdk.java.net/browse/JDK-8153056
>
> *Webrev:*http://cr.openjdk.java.net/~arapte/prem/8153056/webrev.00/ 
> <http://cr.openjdk.java.net/%7Earapte/prem/8153056/webrev.00/>
>
> *Issue:*
>
> 8152647(duplicate of 6439354) Manual Test always passes
>
> *Fix:*
>
> Enhanced Test(with Pass, Fail and Timeout)
>
>
>    It does not look as issue in the test but rather as jtreg does not 
> wait for new created JFrame.
>    Could you run the test without the fix with previous version of 
> jtreg? Is the JFrame is shown in this case?
>
>   Thanks,
>   Alexandr.
>
>
> Regards,
> Prem
>

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

From alexandr.scherbatiy at oracle.com  Fri Apr 15 16:22:35 2016
From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy)
Date: Fri, 15 Apr 2016 20:22:35 +0400
Subject: <Swing Dev> [9] Review request for 8152677 [macosx] All files
 filter can't be selected in JFileChooser
In-Reply-To: <5710FA4A.4080502@oracle.com>
References: <5710F0C3.5030201@oracle.com> <5710FA4A.4080502@oracle.com>
Message-ID: <5711154B.10200@oracle.com>

On 15/04/16 18:27, Sergey Bylokhov wrote:
> Is it possible that default selection of FileChooser will be different 
> from "acceptAllFileFilter"?

  When a JFileChooser is created it always adds Accept All file filter 
in the constructor because useAcceptAllFileFilter filed is true by default.
  Because of this the AquaFileChooserUI.FilterComboBoxModel initially 
has the Accept All file filter as the first item.

  After that it is possible to unset the Accept All file filter by 
calling JFileChooser.setAcceptAllFileFilterUsed(false).

  Thanks,
  Alexandr.

>
> On 15.04.16 16:46, Alexander Scherbatiy wrote:
>>
>> Hello,
>>
>> Could you review the fix:
>>    bug: https://bugs.openjdk.java.net/browse/JDK-8152677
>>    webrev: http://cr.openjdk.java.net/~alexsch/8152677/webrev.00
>>
>>    FilterComboBoxModel from AquaFileChooserUI overrides
>> getSelectedItem() method to always return the selected filter from the
>> file chooser.
>>
>>    JFileChooser.setFileFilter(FileFilter) first assign the passed filter
>> to fileFilter field and then fire "fileFilterChanged" property change
>> event. This leads that FilterComboBoxModel compares new file filter with
>> the selected one (which has the same value because it is obtained from
>> JFileChooser.fileFilter field) and do not updated JComboBox internal
>> structure so JComboBox.selectedItemReminder field still points to the
>> old one.
>>
>>    When a user selects ?All Files? filter which is the first item from a
>> JFileChooser the JComboBox does not fire the action event because
>> selectedItemReminder points to the same first item.
>>
>>    The proposed solution is to remember the previous selected item in
>> the AquaFileChooserUI.FilterComboBoxModel.
>>
>>    Thanks,
>>    Alexandr.
>
>



From Sergey.Bylokhov at oracle.com  Fri Apr 15 16:26:57 2016
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Fri, 15 Apr 2016 19:26:57 +0300
Subject: <Swing Dev> [9] Review request for 8152677 [macosx] All files
 filter can't be selected in JFileChooser
In-Reply-To: <5711154B.10200@oracle.com>
References: <5710F0C3.5030201@oracle.com> <5710FA4A.4080502@oracle.com>
	<5711154B.10200@oracle.com>
Message-ID: <57111651.7050108@oracle.com>

On 15.04.16 19:22, Alexander Scherbatiy wrote:
> On 15/04/16 18:27, Sergey Bylokhov wrote:
>   When a JFileChooser is created it always adds Accept All file filter
> in the constructor because useAcceptAllFileFilter filed is true by default.
>   Because of this the AquaFileChooserUI.FilterComboBoxModel initially
> has the Accept All file filter as the first item.
>
>   After that it is possible to unset the Accept All file filter by
> calling JFileChooser.setAcceptAllFileFilterUsed(false).

But what will happen if the user will update the filter before the Aqua 
will be set as default l&f(for example if Metal is set as default via 
commandline)?

>> On 15.04.16 16:46, Alexander Scherbatiy wrote:
>>>
>>> Hello,
>>>
>>> Could you review the fix:
>>>    bug: https://bugs.openjdk.java.net/browse/JDK-8152677
>>>    webrev: http://cr.openjdk.java.net/~alexsch/8152677/webrev.00
>>>
>>>    FilterComboBoxModel from AquaFileChooserUI overrides
>>> getSelectedItem() method to always return the selected filter from the
>>> file chooser.
>>>
>>>    JFileChooser.setFileFilter(FileFilter) first assign the passed filter
>>> to fileFilter field and then fire "fileFilterChanged" property change
>>> event. This leads that FilterComboBoxModel compares new file filter with
>>> the selected one (which has the same value because it is obtained from
>>> JFileChooser.fileFilter field) and do not updated JComboBox internal
>>> structure so JComboBox.selectedItemReminder field still points to the
>>> old one.
>>>
>>>    When a user selects ?All Files? filter which is the first item from a
>>> JFileChooser the JComboBox does not fire the action event because
>>> selectedItemReminder points to the same first item.
>>>
>>>    The proposed solution is to remember the previous selected item in
>>> the AquaFileChooserUI.FilterComboBoxModel.
>>>
>>>    Thanks,
>>>    Alexandr.
>>
>>
>


-- 
Best regards, Sergey.


From prem.balakrishnan at oracle.com  Mon Apr 18 05:33:15 2016
From: prem.balakrishnan at oracle.com (Prem Balakrishnan)
Date: Sun, 17 Apr 2016 22:33:15 -0700 (PDT)
Subject: <Swing Dev> Review Request JDK-8153056 : 8152647(duplicate of
 6439354) Manual Test always passes
In-Reply-To: <5711038F.9030808@oracle.com>
References: <604bc0a3-ff40-459c-a6c8-63a84bbbeae8@default>
	<56FC085C.2010206@oracle.com>
	<092365d9-5be2-487a-be4d-8c169a1820ed@default>
	<56FD661F.7030803@oracle.com>
	<9936f551-445f-4108-8f0f-c790e1fbf0f8@default>
	<5711038F.9030808@oracle.com>
Message-ID: <07f0ddce-ec62-455a-b2b0-96ff402d3d0e@default>

Hi Prasanta,

 

1.       This test was initially written in the year  2016 (by me), later  found the issue with the test file and correcting it.

By mistake added the 1999 to the copyright, hence removed it.

 

2.       try/catch block is Not redundant , await() method throws InterruptedException, which must be caught or declared to be thrown.

   public void await() throws HYPERLINK "https://docs.oracle.com/javase/7/docs/api/java/lang/InterruptedException.html"InterruptedException

 

Regards,

Prem

 

From: prasanta sadhukhan 
Sent: Friday, April 15, 2016 8:37 PM
To: Prem Balakrishnan; Alexander Scherbatiy; Sergey Bylokhov; Semyon Sadetsky; Rajeev Chamyal; swing-dev at openjdk.java.net
Subject: Re: <Swing Dev> Review Request JDK-8153056 : 8152647(duplicate of 6439354) Manual Test always passes

 

Hi Prem,

Why did you remove 1999 from the copyright? I guess that's the initial year when this test was written. I guess we need to keep it and make like 1999,2016.
I guess also this try/catch block is redundant 

try {
  56             latch.await();
  57         } catch (InterruptedException ie) {
  58             throw ie;
  59         }


Regards
Prasanta

On 4/15/2016 1:52 PM, Prem Balakrishnan wrote:

Hi Alexander, 

 

Thank you for the review.

 

Updated test with CountDownLatch.

http://cr.openjdk.java.net/~arapte/prem/8153056/webrev.01/

 

Regards,
Prem

 

 

From: Alexander Scherbatiy 
Sent: Thursday, March 31, 2016 11:32 PM
To: Prem Balakrishnan; Sergey Bylokhov; Semyon Sadetsky; Rajeev Chamyal; HYPERLINK "mailto:swing-dev at openjdk.java.net"swing-dev at openjdk.java.net
Subject: Re: Review Request JDK-8153056 : 8152647(duplicate of 6439354) Manual Test always passes

 

On 31/03/16 14:59, Prem Balakrishnan wrote:




Hi Alexander,

 

Thankyou for the review.

I agree with what you said ,jtreg  does not wait for new created JFrame.

Executed test on : 

Jtreg version: 4.2.0 and 4.1 , facing same issue, even without user/tester validating the output test status shows passed.


  It looks like jtreg does not wait for UI closing for manual main tests.
  May be it is better to use CountDownLatch in this case? It least there will not be necessary to distinguish InterruptedException generated by program of by other reasons.  

 Thanks,
 Alexandr.




 

Hence test enhanced to overcome the above scenario.

 

 

Regards,

Prem

 

From: Alexander Scherbatiy 
Sent: Wednesday, March 30, 2016 10:40 PM
To: Prem Balakrishnan; Sergey Bylokhov; Semyon Sadetsky; Rajeev Chamyal; HYPERLINK "mailto:swing-dev at openjdk.java.net"swing-dev at openjdk.java.net
Subject: Re: Review Request JDK-8153056 : 8152647(duplicate of 6439354) Manual Test always passes

 

On 30/03/16 16:08, Prem Balakrishnan wrote:





Hi,

Please review fix for JDK9,

Bug: https://bugs.openjdk.java.net/browse/JDK-8153056 

Webrev: HYPERLINK "http://cr.openjdk.java.net/%7Earapte/prem/8153056/webrev.00/"http://cr.openjdk.java.net/~arapte/prem/8153056/webrev.00/

 

  

Issue:

8152647(duplicate of 6439354) Manual Test always passes

 

Fix:

Enhanced Test(with Pass, Fail and Timeout)


   It does not look as issue in the test but rather as jtreg does not wait for new created JFrame.
   Could you run the test without the fix with previous version of jtreg? Is the JFrame is shown in this case?

  Thanks,
  Alexandr.





 

Regards,
Prem

 

 

 

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

From prem.balakrishnan at oracle.com  Mon Apr 18 06:52:27 2016
From: prem.balakrishnan at oracle.com (Prem Balakrishnan)
Date: Sun, 17 Apr 2016 23:52:27 -0700 (PDT)
Subject: <Swing Dev> Review Request JDK-8153056 : 8152647(duplicate of
 6439354) Manual Test always passes
In-Reply-To: <07f0ddce-ec62-455a-b2b0-96ff402d3d0e@default>
References: <604bc0a3-ff40-459c-a6c8-63a84bbbeae8@default>
	<56FC085C.2010206@oracle.com>
	<092365d9-5be2-487a-be4d-8c169a1820ed@default>
	<56FD661F.7030803@oracle.com>
	<9936f551-445f-4108-8f0f-c790e1fbf0f8@default>
	<5711038F.9030808@oracle.com>
	<07f0ddce-ec62-455a-b2b0-96ff402d3d0e@default>
Message-ID: <0397edee-0a3f-40d5-b344-d3628dbca8a7@default>

Hi Prasanta,

 

Sorry , It was my mistake, initially I didn't notice that, 

I was  catching exception as well as declared it to be thrown.

Updated Webrev as per review comments.

 

http://cr.openjdk.java.net/~arapte/prem/8153056/webrev.02/ 

 

Regards,
Prem

 

From: Prem Balakrishnan 
Sent: Monday, April 18, 2016 11:03 AM
To: Prasanta Sadhukhan; Alexander Scherbatiy; Sergey Bylokhov; Semyon Sadetsky; Rajeev Chamyal; swing-dev at openjdk.java.net
Subject: Re: <Swing Dev> Review Request JDK-8153056 : 8152647(duplicate of 6439354) Manual Test always passes

 

Hi Prasanta,

 

1.       This test was initially written in the year  2016 (by me), later  found the issue with the test file and correcting it.

By mistake added the 1999 to the copyright, hence removed it.

 

2.       try/catch block is Not redundant , await() method throws InterruptedException, which must be caught or declared to be thrown.

   public void await() throws HYPERLINK "https://docs.oracle.com/javase/7/docs/api/java/lang/InterruptedException.html"InterruptedException

 

Regards,

Prem

 

From: prasanta sadhukhan 
Sent: Friday, April 15, 2016 8:37 PM
To: Prem Balakrishnan; Alexander Scherbatiy; Sergey Bylokhov; Semyon Sadetsky; Rajeev Chamyal; HYPERLINK "mailto:swing-dev at openjdk.java.net"swing-dev at openjdk.java.net
Subject: Re: <Swing Dev> Review Request JDK-8153056 : 8152647(duplicate of 6439354) Manual Test always passes

 

Hi Prem,

Why did you remove 1999 from the copyright? I guess that's the initial year when this test was written. I guess we need to keep it and make like 1999,2016.
I guess also this try/catch block is redundant 

try {
  56             latch.await();
  57         } catch (InterruptedException ie) {
  58             throw ie;
  59         }


Regards
Prasanta

On 4/15/2016 1:52 PM, Prem Balakrishnan wrote:

Hi Alexander, 

 

Thank you for the review.

 

Updated test with CountDownLatch.

http://cr.openjdk.java.net/~arapte/prem/8153056/webrev.01/

 

Regards,
Prem

 

 

From: Alexander Scherbatiy 
Sent: Thursday, March 31, 2016 11:32 PM
To: Prem Balakrishnan; Sergey Bylokhov; Semyon Sadetsky; Rajeev Chamyal; HYPERLINK "mailto:swing-dev at openjdk.java.net"swing-dev at openjdk.java.net
Subject: Re: Review Request JDK-8153056 : 8152647(duplicate of 6439354) Manual Test always passes

 

On 31/03/16 14:59, Prem Balakrishnan wrote:



Hi Alexander,

 

Thankyou for the review.

I agree with what you said ,jtreg  does not wait for new created JFrame.

Executed test on : 

Jtreg version: 4.2.0 and 4.1 , facing same issue, even without user/tester validating the output test status shows passed.


  It looks like jtreg does not wait for UI closing for manual main tests.
  May be it is better to use CountDownLatch in this case? It least there will not be necessary to distinguish InterruptedException generated by program of by other reasons.  

 Thanks,
 Alexandr.



 

Hence test enhanced to overcome the above scenario.

 

 

Regards,

Prem

 

From: Alexander Scherbatiy 
Sent: Wednesday, March 30, 2016 10:40 PM
To: Prem Balakrishnan; Sergey Bylokhov; Semyon Sadetsky; Rajeev Chamyal; HYPERLINK "mailto:swing-dev at openjdk.java.net"swing-dev at openjdk.java.net
Subject: Re: Review Request JDK-8153056 : 8152647(duplicate of 6439354) Manual Test always passes

 

On 30/03/16 16:08, Prem Balakrishnan wrote:




Hi,

Please review fix for JDK9,

Bug: https://bugs.openjdk.java.net/browse/JDK-8153056 

Webrev: HYPERLINK "http://cr.openjdk.java.net/%7Earapte/prem/8153056/webrev.00/"http://cr.openjdk.java.net/~arapte/prem/8153056/webrev.00/

 

  

Issue:

8152647(duplicate of 6439354) Manual Test always passes

 

Fix:

Enhanced Test(with Pass, Fail and Timeout)


   It does not look as issue in the test but rather as jtreg does not wait for new created JFrame.
   Could you run the test without the fix with previous version of jtreg? Is the JFrame is shown in this case?

  Thanks,
  Alexandr.




 

Regards,
Prem

 

 

 

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

From prasanta.sadhukhan at oracle.com  Mon Apr 18 06:54:55 2016
From: prasanta.sadhukhan at oracle.com (prasanta sadhukhan)
Date: Mon, 18 Apr 2016 12:24:55 +0530
Subject: <Swing Dev> Review Request JDK-8153056 : 8152647(duplicate of
 6439354) Manual Test always passes
In-Reply-To: <0397edee-0a3f-40d5-b344-d3628dbca8a7@default>
References: <604bc0a3-ff40-459c-a6c8-63a84bbbeae8@default>
	<56FC085C.2010206@oracle.com>
	<092365d9-5be2-487a-be4d-8c169a1820ed@default>
	<56FD661F.7030803@oracle.com>
	<9936f551-445f-4108-8f0f-c790e1fbf0f8@default>
	<5711038F.9030808@oracle.com>
	<07f0ddce-ec62-455a-b2b0-96ff402d3d0e@default>
	<0397edee-0a3f-40d5-b344-d3628dbca8a7@default>
Message-ID: <571484BF.9040800@oracle.com>

Looks good to me.

Regards
Prasanta
On 4/18/2016 12:22 PM, Prem Balakrishnan wrote:
>
> Hi Prasanta,
>
> Sorry , It was my mistake, initially I didn?t notice that,
>
> I was  catching exception as well as declared it to be thrown.
>
> Updated Webrev as per review comments.
>
> http://cr.openjdk.java.net/~arapte/prem/8153056/webrev.02/ 
> <http://cr.openjdk.java.net/%7Earapte/prem/8153056/webrev.02/>
>
> Regards,
> Prem
>
> *From:*Prem Balakrishnan
> *Sent:* Monday, April 18, 2016 11:03 AM
> *To:* Prasanta Sadhukhan; Alexander Scherbatiy; Sergey Bylokhov; 
> Semyon Sadetsky; Rajeev Chamyal; swing-dev at openjdk.java.net
> *Subject:* Re: <Swing Dev> Review Request JDK-8153056 : 
> 8152647(duplicate of 6439354) Manual Test always passes
>
> Hi Prasanta,
>
> 1.This test was initially written in the year  2016 (by me), later 
>  found the issue with the test file and correcting it.
>
> By mistake added the 1999 to the copyright, hence removed it.
>
> 2.try/catch block is Not redundant , await() method throws 
> InterruptedException, which must be caught or declared to be thrown.
>
>    public void await() throws InterruptedException 
> <https://docs.oracle.com/javase/7/docs/api/java/lang/InterruptedException.html>
>
> Regards,
>
> Prem
>
> *From:*prasanta sadhukhan
> *Sent:* Friday, April 15, 2016 8:37 PM
> *To:* Prem Balakrishnan; Alexander Scherbatiy; Sergey Bylokhov; Semyon 
> Sadetsky; Rajeev Chamyal; swing-dev at openjdk.java.net 
> <mailto:swing-dev at openjdk.java.net>
> *Subject:* Re: <Swing Dev> Review Request JDK-8153056 : 
> 8152647(duplicate of 6439354) Manual Test always passes
>
> Hi Prem,
>
> Why did you remove 1999 from the copyright? I guess that's the initial 
> year when this test was written. I guess we need to keep it and make 
> like 1999,2016.
> I guess also this try/catch block is redundant
>
> try {
>   56             latch.await();
>   57         } catch (InterruptedException ie) {
>   58             throw ie;
>   59         }
>
>
> Regards
> Prasanta
>
> On 4/15/2016 1:52 PM, Prem Balakrishnan wrote:
>
>     Hi Alexander,
>
>     Thank you for the review.
>
>     Updated test with CountDownLatch.
>
>     http://cr.openjdk.java.net/~arapte/prem/8153056/webrev.01/
>     <http://cr.openjdk.java.net/%7Earapte/prem/8153056/webrev.01/>
>
>     Regards,
>     Prem
>
>     *From:*Alexander Scherbatiy
>     *Sent:* Thursday, March 31, 2016 11:32 PM
>     *To:* Prem Balakrishnan; Sergey Bylokhov; Semyon Sadetsky; Rajeev
>     Chamyal; swing-dev at openjdk.java.net
>     <mailto:swing-dev at openjdk.java.net>
>     *Subject:* Re: Review Request JDK-8153056 : 8152647(duplicate of
>     6439354) Manual Test always passes
>
>     On 31/03/16 14:59, Prem Balakrishnan wrote:
>
>     Hi Alexander,
>
>     Thankyou for the review.
>
>     I agree with what you said ,jtreg  does not wait for new created
>     JFrame.
>
>     Executed test on :
>
>     Jtreg version: 4.2.0 and 4.1 , facing same issue, even without
>     user/tester validating the output test status shows passed.
>
>
>       It looks like jtreg does not wait for UI closing for manual main
>     tests.
>       May be it is better to use CountDownLatch in this case? It least
>     there will not be necessary to distinguish InterruptedException
>     generated by program of by other reasons.
>
>      Thanks,
>      Alexandr.
>
>     Hence test enhanced to overcome the above scenario.
>
>     Regards,
>
>     Prem
>
>     *From:*Alexander Scherbatiy
>     *Sent:* Wednesday, March 30, 2016 10:40 PM
>     *To:* Prem Balakrishnan; Sergey Bylokhov; Semyon Sadetsky; Rajeev
>     Chamyal; swing-dev at openjdk.java.net
>     <mailto:swing-dev at openjdk.java.net>
>     *Subject:* Re: Review Request JDK-8153056 : 8152647(duplicate of
>     6439354) Manual Test always passes
>
>     On 30/03/16 16:08, Prem Balakrishnan wrote:
>
>
>     Hi*,*
>
>     Please review fix for JDK9,
>
>     *Bug:*https://bugs.openjdk.java.net/browse/JDK-8153056
>
>     *Webrev:*http://cr.openjdk.java.net/~arapte/prem/8153056/webrev.00/ <http://cr.openjdk.java.net/%7Earapte/prem/8153056/webrev.00/>
>
>     *Issue:*
>
>     8152647(duplicate of 6439354) Manual Test always passes
>
>     *Fix:*
>
>     Enhanced Test(with Pass, Fail and Timeout)
>
>
>        It does not look as issue in the test but rather as jtreg does
>     not wait for new created JFrame.
>        Could you run the test without the fix with previous version of
>     jtreg? Is the JFrame is shown in this case?
>
>       Thanks,
>       Alexandr.
>
>
>     Regards,
>     Prem
>

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

From peter.brunet at oracle.com  Tue Apr 19 01:50:59 2016
From: peter.brunet at oracle.com (Pete Brunet)
Date: Mon, 18 Apr 2016 20:50:59 -0500
Subject: <Swing Dev> RfR JDK-8076554,
 [macosx] Custom Swing text components need to allow standard
 accessibility
Message-ID: <57158F03.1060708@oracle.com>

Please review the following patch.

Bug: https://bugs.openjdk.java.net/browse/JDK-8076554
Patch: http://cr.openjdk.java.net/~ptbrunet/JDK-8076554/webrev.02/

The problem is that the code is currently hardcoded to only support text
accessibility for JTextComponent using the DocumentListener,
CaretListener interfaces.  This eliminates the ability to provide
accessibility for a custom text components.  The resolution is to remove
the JTextComponent gate and use the PropertyChangeListener listener
interface with its ACCESSIBLE_CARET_PROPERTY and
ACCESSIBLE_TEXT_PROPERTY properties.

I tested this with the two test cases which can be found at
http://cr.openjdk.java.net/~ptbrunet/JDK-8076554/test/
running them side by side with VoiceOver.

Note that I will fix the similar JProgressBar and JSlider restrictions
in JDK-8154507 and JDK-8154508 respectively.

Pete




From avik.niyogi at oracle.com  Tue Apr 19 06:17:19 2016
From: avik.niyogi at oracle.com (Avik Niyogi)
Date: Tue, 19 Apr 2016 11:47:19 +0530
Subject: <Swing Dev> Review Request of 8152492: [macosx swing] double
	key event actions when using Mac menubar
In-Reply-To: <5707C409.4030702@oracle.com>
References: <350CB937-DB61-46D9-A456-47D337E4788A@oracle.com>
	<5707C409.4030702@oracle.com>
Message-ID: <123F5EB3-DD71-4706-A9F2-217F8B29BEF7@oracle.com>

Hi Sergey,
I have tried all these Input sources:

I am unable to reproduce the test failure as mentioned by you with these inputs. Please provide some screenshots and/or details of the procedure used for this test failure.
Thank you in advance.

With Regards,
Avik Niyogi

> On 08-Apr-2016, at 8:15 pm, Sergey Bylokhov <Sergey.Bylokhov at oracle.com> wrote:
> 
> Hi, Avik.
> It seems there is one more bug in this "if".
> Change the input source to "Hindi Dev.."/"Russian.." then this test fails anyway(it will produce the double action).
> Moreover if I change the source input to Hindi Transliteration, the test sometimes crashed.
> Please double check.
> 
> On 06.04.16 13:42, Avik Niyogi wrote:
>> Hi All,
>> 
>> Kindly review the bug fix for JDK 9.
>> 
>> *Bug:*
>> https://bugs.openjdk.java.net/browse/JDK-8152492
>> 
>> *Webrev:*
>> http://cr.openjdk.java.net/~aniyogi/8152492/webrev.00/
>> 
>> *Issue:*
>> For OSX, having there is provision of non-integrated menubar. for this
>> case, triggering the menu action by key press triggered double action in
>> some cases
>> 
>> *Cause:*
>> Due to the use of Shift modifier being a soft modifier in case of mac.
>> For example ?Shift + m? is actually ?M? and ?Shift + ,? is ?<? .
>> So such cases can not be used as shortcuts. This needs to be accounted for.
>> Also, cases where ?Cmd + Shift + c? is used as a shortcut, it should not
>> morph that to a ?Cmd + C? command and should detect c itself.
>> Also, ?Shift + ?? has no equivalent soft modification and can be taken
>> as a shortcut. This has to be accounted for.
>> 
>> *Fix:*
>> All required edge case scenarios for the soft modification of Shift and
>> cases of valid modifiers were taken into account.
>> 
>> With Regards,
>> Avik Niyogi
> 
> 
> -- 
> Best regards, Sergey.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/swing-dev/attachments/20160419/31b254f6/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Screen Shot 2016-04-19 at 11.40.33 am.png
Type: image/png
Size: 103436 bytes
Desc: not available
URL: <http://mail.openjdk.java.net/pipermail/swing-dev/attachments/20160419/31b254f6/ScreenShot2016-04-19at11.40.33am.png>

From alexandr.scherbatiy at oracle.com  Tue Apr 19 08:08:07 2016
From: alexandr.scherbatiy at oracle.com (Alexandr Scherbatiy)
Date: Tue, 19 Apr 2016 01:08:07 -0700
Subject: <Swing Dev> [9] Review request for 8132119 Provide public API
 for text related methods in SwingUtilities2
In-Reply-To: <570C3370.1090702@oracle.com>
References: <55E715A1.3090008@oracle.com> <55E72D3A.60807@oracle.com>
	<55ED586F.5070509@oracle.com> <55F6DC3C.60809@oracle.com>
	<5655D3AB.9050503@oracle.com> <5668051E.7090401@oracle.com>
	<5668E226.5000604@oracle.com> <5669646E.4070305@oracle.com>
	<566986FD.9020207@oracle.com> <5694F0C3.8020203@oracle.com>
	<5695572F.6070709@oracle.com> <56966730.7000701@oracle.com>
	<5698C71A.80703@oracle.com> <56991ED9.5030302@oracle.com>
	<569963B6.2050604@oracle.com> <56A5C40B.7010107@oracle.com>
	<CAM6ZMz8iEFQQtSb_bAVU5eUH=J=HapvKq3+Ana4pPxueJD1bNg@mail.gmail.com>
	<56AB8A94.2070404@oracle.com> <56EC2389.3020507@oracle.com>
	<56F38B0B.3060700@oracle.com> <56F3F13A.9000808@oracle.com>
	<56F3F83C.3010706@oracle.com> <56FD791E.1050707@oracle.com>
	<5705705C.2010007@oracle.com> <570C3370.1090702@oracle.com>
Message-ID: <5715E767.5000409@oracle.com>

On 4/11/2016 4:29 PM, Philip Race wrote:
>
>
> On 4/6/16, 1:23 PM, Alexander Scherbatiy wrote:
>>
>> Hello,
>>
>> Could you review the updated fix:
>>   http://cr.openjdk.java.net/~alexsch/8132119/webrev.09
>>
>>  - TextUIDrawing interface and its default implementaion 
>> BasicTextUIDrawing class are added
>>  - font metrics argument description is updated
>>
>> On 31/03/16 23:23, Phil Race wrote:
>>> Another webrev where you have to slip past 40_ files to get to the 
>>> two that really matter :-)
>>> I would have put SwingUtilities2.java and TextUIDrawing.java as the 
>>> first files.
>>    Updated.
>>>
>>>
>>> Some of what I have to say here is more along the lines of things to 
>>> think
>>> about rather than things that are wrong .. but there are also maybe 
>>> some things
>>> that need to be fixed.
>>>
>>> Is javax.swing.plaf really the right package for the new class ?
>>> I suppose it is for the use by the UI classes so maybe its right.
>>>
>>> Should the methods be taking "double" instead of "int" for location ?
>>> This means the measurement APIs too.
>>> None of the JDK 1.2 text APIs use ints. That is all 1.0 legacy.
>>> So if Swing internally wants to use ints that is OK but maybe the API
>>> should be floating point (double).
>>   The provided methods use Graphics as argument which only has 
>> drawString(String, int, int) method.
>>   If it is possible it is better to add the methods with float 
>> arguments and Graphics2D later.
>>
>>> Would that  help hi-dpi at all ?
>>   The hi-dpi support mostly does not require changes in Swing. What 
>> it does just scales graphics using default transform from graphics 
>> configuration.
>
> Yes, but in another bug you are dealing with a problem positioning
> the caret because of (somewhat) similar issues where coordinates have 
> been
> rounded to an integral. A floating point value allows you to say that
> this is 25.5 in user-space, even it if is 51.0 in device space.

    It needs some more investigation.

    What I have now is Swing uses font metrics to calculate a string 
width (FontMetrics.charsWidth(...)) which sums up float char values.
    The difference between font metrics used by Swing and font metrics 
from graphics passed to paint method is that the fist has null frc.tx 
matrix and the second one has a matrix with scales 2 on HiDPI display.
    The returned char width by the font metrics with null transform has 
value 7 for char 'a' (linear advance is 6.67 and xAdvance is 7).
    The char width for the font metrics with scaled transform is 6.5 for 
the same font and char.  FileFontStrike requests glyph metrics and gets 
linear advance  13.35 (dev transform is taken into account) xAdvance  13 
-  and apply the reverse transform. The result is 13 / 2  = 6.5.

   And this bothers me because a result for applying the tx transform 
and inverting it is different than just use the identity transform. 
There are definitely problems with advance rounding but it seems they 
are placed out of the Swing area.

>
>>
>>> I suppose it would add over-head since all the existing code uses int
>>> and we are no worse off and can add double methods later if we want to.
>>>
>>>
>>> Regarding FontMetrics we need to add a caution that is must be a 
>>> FontMetrics
>>> *obtained from the correct font and graphics*.
>>    Updated.
>>>
>>>
>>>  i.e what about attributes on the font such as "tracking" ?
>>> or on the graphics such as FRACTIONALMETRICS
>>> It looks like Swing might already fail if that were used.
>>>
>>> Look at this code :-
>>>
>>>    public static int stringWidth(JComponent c, FontMetrics fm, 
>>> String string){
>>>         if (string == null || string.equals("")) {
>>>             return 0;
>>>         }
>>>         boolean needsTextLayout = ((c != null) &&
>>> (c.getClientProperty(TextAttribute.NUMERIC_SHAPING) != null));
>>>         if (needsTextLayout) {
>>>             synchronized(charsBufferLock) {
>>>                 int length = syncCharsBuffer(string);
>>>                 needsTextLayout = isComplexLayout(charsBuffer, 0, 
>>> length);
>>>             }
>>>         }
>>>         if (needsTextLayout) {
>>>             TextLayout layout = createTextLayout(c, string,
>>>                                     fm.getFont(), 
>>> fm.getFontRenderContext());
>>>             return (int) layout.getAdvance();
>>>         } else {
>>>             return fm.stringWidth(string);
>>>         }
>>>     }
>>>
>>> The only thing Swing is looking at is one TextAttribute and whether 
>>> we have complex text.
>>> That is not enough. This is an existing implementation issue but one 
>>> we should fix here.
>>> You need to examine all the methods for similar issues.
>>   I created an enhancement for this:
>>     JDK-8153662 
>> SwingUtilities2.drawString()/getStringWidth()/clipString() should use 
>> more text attributes
>>       https://bugs.openjdk.java.net/browse/JDK-8153662
>
> you mean bug ? I upgraded it to P3 because it matters a lot more now
> with this public API

   I do not think that it is a bug because the main request was to have 
methods which draw strings in the same way as it is done by Swing L&Fs.
   This will allow to have custom UI component which mimic to the 
standard L&Fs.

   It is also can be considered from the following point of view: is the 
proposed request to use more text attributes more important for standard 
Swing L&F or for custom L&F.
   It seems is not the first case because Swing lives with the current 
implementation for the long time.
   For the second case we provide the public TextUIDrawing interface 
which a developer can override and use any text attributes that are 
necessary.

>>>
>>> The usage of default methods is worth thinking about.
>>> There is a significant subjective element to this and I've really 
>>> thought only myself about
>>> using them for the case where default methods are useful when you 
>>> need to extend an
>>> existing interface.
>>>
>>> But I can imagine they may also be handy when someone would 
>>> typically want to implement
>>> only one or two out of a larger number in an interface and the 
>>> default and you for some
>>> reason don't want to do that with an abstract class (notably you 
>>> want an other class to
>>> be able to implement the interface).
>>>
>>> So what do I think about the case where the interface is brand new and
>>> what you've done is more or less implement a concrete class, but 
>>> it's one that
>>> can be mixed in to another class ? Is that an appropriate use ?
>>>
>>> Maybe the test to pass in that case is whether the default 
>>> implementation
>>> is going to be satisfactory for 90% of uses. If they are frequently 
>>> over-ridden
>>> it would not be an appropriate use.
>>   Using this argument it seems if someone wants to implement the 
>> TextUIDrawing it needs to override all its methods to keep them in 
>> sync. Because of this I moved the TextUIDrawing implementation to the 
>> separate javax.swing.plaf.basic.BasicTextUIDrawing class.
>
> Fair enough although I wonder if by the same argument there is any point
> in exposing BasicTextUIDrawing as a public class ? I don't have a strong
> objection to exposing it, except that the name "Basic..." seems to 
> invite subclassing ..
    'Basic' in this case refers to the BasicLookAndFeel. All UI 
components for the Basic L&F has the Basic prefix.
     Basic L&F usually provides some basic implementation which can be 
used by others L&F.

    Thanks,
    Alexandr.

>
> -phil
>>>
>>> Based on that criterion I think it is OK to use here.
>>>
>>> Another thought:
>>> When you add default implementations you should also be on the hook
>>> for explaining what that does. It is a deeper contract than you would
>>> otherwise have as an interface and maybe needs to be an @implNote
>>> or you need to call out the default implementation.
>>> ie there is what someone must code to satisfy the contract of the
>>> interface and what is a behaviour in the default method ?
>>   I added the addition "using text properties and anti-aliasing hints 
>> from the provided component" description to the BasicTextUIDrawing 
>> class. There is always a question how many details a method 
>> description should contain. It is not clear for  me should, for 
>> example, the used numeric shaper be listed in the description or not? 
>> Especially when there is an enhancement that the methods 
>> implementation should take more text attributes  into account.
>>
>>> Also here is a link to some comments by Brian Goetz on default 
>>> methods :
>>>
>>> http://stackoverflow.com/questions/28681737/java-8-default-methods-as-traits-safe/28684917#28684917 
>>>
>>>
>>>   75      * No character is underlined if the index is negative or 
>>> greater
>>>   76      * than the string length {@code (index < 0 || index >= 
>>> string.length())}
>>>   77      * or if the char value specified at the given index
>>>   78      * is in the low-surrogate range.
>>>
>>>
>>> I suppose if you point at the last char and it is a hi-surrogate 
>>> nothing is underlined in that case either.
>>>
>>> But I find the whole writing of this a bit inadequate as if you are 
>>> going to
>>> this kind of detail you perhaps also need to say what happens in a 
>>> complex
>>> script where what happens is two unicode characters end up as a 
>>> ligature,
>>> and/or perhaps you aren't even pointing to a base character.
>>> Maybe it is in fact over-specified. I see that the implementation draws
>>> the underline itself rather than delegate to TextLayout. This might
>>> make sense for performance reasons where it is simple text but some day
>>> this maybe should be re-examined and so I would not over-specify it.
>>>
>>> How about :
>>> "The underline will be positioned at the base glyph which
>>> represents the valid char indicated by the index.
>>> If the char index is not valid or is not the index of a
>>> valid unicode code point then no underline is drawn"
>>   Updated.
>>
>>   Thanks,
>>   Alexandr.
>>>
>>> -phil.
>>>
>>>
>>>
>>> On 03/24/2016 07:22 AM, Sergey Bylokhov wrote:
>>>> On 24.03.16 16:52, Alexander Scherbatiy wrote:
>>>>> On 24/03/16 10:36, Semyon Sadetsky wrote:
>>>>>> Hi Alexander,
>>>>>>
>>>>>> Could you answer one question:
>>>>>> Why did you choose default interface methods to implement
>>>>>> TextUIDrawing and not implement them in DefaultTextUIDrawing having
>>>>>> declarations only in the interface?
>>>>>> AFAIK the common point of view is default methods should be used
>>>>>> rarely because they may lead to unreadable code.
>>>>>>
>>>>>    The only problem which I know about default methods is multiple
>>>>> inheritance which has its own solution.
>>>>
>>>> What kind of problems? The benefit is obvious: it will not be 
>>>> necessary to implement all methods if only one of them should be 
>>>> tweaked.
>>>>
>>>>>
>>>>>    Could you give links to discussion or provide use cases where 
>>>>> default
>>>>> methods leads to the unreadable code and show how does it relate 
>>>>> to the
>>>>> TextUIDrawing  implementation?
>>>>>
>>>>>    Thanks,
>>>>>    Alexandr.
>>>>>> --Semyon
>>>>>>
>>>>>> On 3/18/2016 6:49 PM, Alexander Scherbatiy wrote:
>>>>>>>
>>>>>>> Could you review the updated fix:
>>>>>>> http://cr.openjdk.java.net/~alexsch/8132119/webrev.08/
>>>>>>>
>>>>>>>   - Public TextUIDrawing interface is added to the javax.swing.plaf
>>>>>>> package
>>>>>>>   - TextUIDrawing methods description does not mention component
>>>>>>> properties to be more general
>>>>>>>   - TextUIDrawing methods are made default
>>>>>>>   - L&F sets an instance of the TextUIDrawing to look and feel
>>>>>>> defaults using "uiDrawing.text" property
>>>>>>>   - ComponentUI class is not changed
>>>>>>>   - Each ComponentUI reads TextUIDrawing from UI defaults
>>>>>>>   - There is an interesting issue described in
>>>>>>> http://mail.openjdk.java.net/pipermail/swing-dev/2016-March/005509.html 
>>>>>>>
>>>>>>>     which is related to the fact that MetalLabelUI returns a static
>>>>>>> field from createUI() method.
>>>>>>>     TitleBorder creates a JLabel but does not put it to any 
>>>>>>> component
>>>>>>> hierarchy. In this case SwingUtilities.updateComponentTreeUI() 
>>>>>>> method
>>>>>>> calls MetalLabelUI.uninstallDefaults() on the static metalLabelUI
>>>>>>> field and sets a new LabelUI for ordinary labels. The TitleBorder
>>>>>>> label UI is not changed in this case and it still uses the
>>>>>>> metalLabelUI field which is not initialized.
>>>>>>>     It seems that other applications can also use components 
>>>>>>> just for
>>>>>>> drawing and have the same issue.
>>>>>>>     For this case the textUIDrawing field is not cleared in the
>>>>>>> uninstallDefaults but just set to a static default value which 
>>>>>>> should
>>>>>>> not lead to memory leaks.
>>>>>>>
>>>>>>>   Thanks,
>>>>>>>   Alexandr.
>>>>>>>
>>>>>>> On 29/01/16 19:51, Alexander Scherbatiy wrote:
>>>>>>>> On 25/01/16 13:44, Andrej Golovnin wrote:
>>>>>>>>> Hi Alexandr,
>>>>>>>>>
>>>>>>>>>> Could you review the updated fix:
>>>>>>>>>> http://cr.openjdk.java.net/~alexsch/8132119/webrev.07/
>>>>>>>>> ....
>>>>>>>>>> - public TextUIDrawing interface is added to the 
>>>>>>>>>> javax.swing.plaf
>>>>>>>>>> package
>>>>>>>>>> - public "TextUIDrawing getTextUIDrawing()" method is added 
>>>>>>>>>> to the
>>>>>>>>>> ComponentUI class
>>>>>>>>>> - L&F sets an instance of the TextUIDrawing to look and feel
>>>>>>>>>> defaults using
>>>>>>>>>> "uiDrawing.text" property
>>>>>>>>>> - Look and Feel delegates use the instance of the TextUIDrawing
>>>>>>>>>> for text
>>>>>>>>>> drawing and measuring
>>>>>>>>> Some thoughts on the current design/implementation:
>>>>>>>>>
>>>>>>>>> By adding a field to the ComponentUI class the current
>>>>>>>>> implementation increases
>>>>>>>>> memory consumption for all Swing applications. And you get the
>>>>>>>>> feeling that
>>>>>>>>> there are different implementations of TextUIDrawing per
>>>>>>>>> ComponentUI instances.
>>>>>>>>> Personally I can't imagine to have different implementations of
>>>>>>>>> TextUIDrawing for
>>>>>>>>> a given LookAndFeel. If I would design/implement it, then I would
>>>>>>>>> implement it as
>>>>>>>>> a property of the LookAndFeel class (similar to LayoutStyle) 
>>>>>>>>> and not
>>>>>>>>> the ComponentUI.
>>>>>>>>> Developers can use then the following code to obtain the 
>>>>>>>>> instance of
>>>>>>>>> TextUIDrawing:
>>>>>>>>>
>>>>>>>>> UIManager.getLookAndFeel().getUIDrawing() // or
>>>>>>>>> UIManager.getLookAndFeelUIDrawing() // use this static method 
>>>>>>>>> as a
>>>>>>>>> short cut for the line above.
>>>>>>>>   LayoutStyle keeps its instance per App context. The same is for
>>>>>>>> the LookAndFeel
>>>>>>>>   when it is got through UIManager.getLookAndFeel() call.
>>>>>>>>   It means that accessing an instance of a TextUIDrawing will 
>>>>>>>> leads
>>>>>>>> to a time consumption.
>>>>>>>>
>>>>>>>>   There are 3 main ways of the SwingUtilities2.drawString(...) 
>>>>>>>> usage:
>>>>>>>>   1. ComponentUI classes
>>>>>>>>   2. Components created in UI (like BasicInternalFrameTitlePane)
>>>>>>>>   3. Public utilities methods (like 
>>>>>>>> WindowsGraphicsUtils.paintText())
>>>>>>>>
>>>>>>>>   For the cases 1 and 2 it is possible to load and store the
>>>>>>>> UIDrawing instance during installUI()/updateUI() calls to 
>>>>>>>> decrease a
>>>>>>>> time access to it.
>>>>>>>>
>>>>>>>>   For the case 3 it is necessary to get LookAndFeel instance each
>>>>>>>> time (which is taken from an App context)
>>>>>>>>   or use the passed JComponent object. It requires to have a 
>>>>>>>> public
>>>>>>>> method and the associated variable for each instance of
>>>>>>>> JComponent/ComponentUI/... class.
>>>>>>>>> You can use this methods then in JDK too.
>>>>>>>>>
>>>>>>>>> And maybe rename the TextUIDrawing class to just UIDrawing and 
>>>>>>>>> add
>>>>>>>>> more useful methods,
>>>>>>>>> e.g. a method to create a composite font, a method to convert 
>>>>>>>>> DLUs
>>>>>>>>> to pixels.
>>>>>>>>   UIDrawing name may look like it should be used for any UI 
>>>>>>>> drawing,
>>>>>>>> not only for text ones. I am afraid that it can be misleading.
>>>>>>>>
>>>>>>>>   Thanks,
>>>>>>>>   Alexandr.
>>>>>>>>
>>>>>>>>>
>>>>>>>>> Best regards,
>>>>>>>>> Andrej Golovnin
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>>
>>>
>>



From avik.niyogi at oracle.com  Tue Apr 19 08:46:11 2016
From: avik.niyogi at oracle.com (Avik Niyogi)
Date: Tue, 19 Apr 2016 14:16:11 +0530
Subject: <Swing Dev> Review Request of 8152492: [macosx swing] double
	key event actions when using Mac menubar
In-Reply-To: <123F5EB3-DD71-4706-A9F2-217F8B29BEF7@oracle.com>
References: <350CB937-DB61-46D9-A456-47D337E4788A@oracle.com>
	<5707C409.4030702@oracle.com>
	<123F5EB3-DD71-4706-A9F2-217F8B29BEF7@oracle.com>
Message-ID: <9D087362-41B8-46F3-8A6C-E47D9186723C@oracle.com>

Hi All,
Please review my code changes with inputs received:
http://cr.openjdk.java.net/~aniyogi/8152492/webrev.01/ <http://cr.openjdk.java.net/~aniyogi/8152492/webrev.01/>

With Regards,
Avik Niyogi
> On 19-Apr-2016, at 11:47 am, Avik Niyogi <avik.niyogi at oracle.com> wrote:
> 
> Hi Sergey,
> I have tried all these Input sources:
> <Screen Shot 2016-04-19 at 11.40.33 am.png>
> I am unable to reproduce the test failure as mentioned by you with these inputs. Please provide some screenshots and/or details of the procedure used for this test failure.
> Thank you in advance.
> 
> With Regards,
> Avik Niyogi
> 
>> On 08-Apr-2016, at 8:15 pm, Sergey Bylokhov <Sergey.Bylokhov at oracle.com <mailto:Sergey.Bylokhov at oracle.com>> wrote:
>> 
>> Hi, Avik.
>> It seems there is one more bug in this "if".
>> Change the input source to "Hindi Dev.."/"Russian.." then this test fails anyway(it will produce the double action).
>> Moreover if I change the source input to Hindi Transliteration, the test sometimes crashed.
>> Please double check.
>> 
>> On 06.04.16 13:42, Avik Niyogi wrote:
>>> Hi All,
>>> 
>>> Kindly review the bug fix for JDK 9.
>>> 
>>> *Bug:*
>>> https://bugs.openjdk.java.net/browse/JDK-8152492 <https://bugs.openjdk.java.net/browse/JDK-8152492>
>>> 
>>> *Webrev:*
>>> http://cr.openjdk.java.net/~aniyogi/8152492/webrev.00/
>>> 
>>> *Issue:*
>>> For OSX, having there is provision of non-integrated menubar. for this
>>> case, triggering the menu action by key press triggered double action in
>>> some cases
>>> 
>>> *Cause:*
>>> Due to the use of Shift modifier being a soft modifier in case of mac.
>>> For example ?Shift + m? is actually ?M? and ?Shift + ,? is ?<? .
>>> So such cases can not be used as shortcuts. This needs to be accounted for.
>>> Also, cases where ?Cmd + Shift + c? is used as a shortcut, it should not
>>> morph that to a ?Cmd + C? command and should detect c itself.
>>> Also, ?Shift + ?? has no equivalent soft modification and can be taken
>>> as a shortcut. This has to be accounted for.
>>> 
>>> *Fix:*
>>> All required edge case scenarios for the soft modification of Shift and
>>> cases of valid modifiers were taken into account.
>>> 
>>> With Regards,
>>> Avik Niyogi
>> 
>> 
>> -- 
>> Best regards, Sergey.
> 

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

From guy.abossolo.foh at scientificware.com  Tue Apr 19 11:08:43 2016
From: guy.abossolo.foh at scientificware.com (Abossolo Foh Guy)
Date: Tue, 19 Apr 2016 13:08:43 +0200
Subject: <Swing Dev> [PATCH] JDK-7169915 : Swing Table Layout bad repaint of
 the row [REGRESSION] JDK-8133864 : Wrong display,
 when the document I18n properties is true.
Message-ID: <6cee126c009ab4b79ba20fffa3c7e3fa@scientificware.com>

Hello,

I built the recent OpenJDK8u and OpenJDK9 sources (openjdk_versions.txt) 
with the patch shown in the output_diff.txt attachment.

I applied your patch for JDK-8133864 : Wrong display, when the document 
I18n properties is true.
And I applied my patch for JDK-7169915 : Swing Table Layout bad repaint 
of the row.

All works fine in OpenJDK8u and the document is well displayed. The 
table appears as I expected with all its lines and columns (JDK-8133864 
solved), size and borders included even if we write some text inside 
(JDK-7169915 solved). I can modify it as I want.

But with OpenJDK9, the display of the document is wrong. The table 
appears as I expected with all its lines and columns (JDK-8133864 
solved), size and borders included (JDK-7169915 solved) but the entire 
document display is modified, the table is displayed on a new line. And 
the document became unuseable, I can't modify it as I want.

This morning, I ran the same test programme (CodeBug.java in attachment) 
with the Oracle JDK9 b114 (i.e. OpenJDK9 only with your patch  for 
JDK-8133864) : The table appears as I expected with all its lines and 
columns (JDK-8133864 solved) but the size and borders are bad repainted 
when we write some text inside (JDK-7169915 solved). And the document 
became unuseable too, I can't modify it as I want.

My conclusion :
1- JDK-8133864 is solved with your PATCH.
2- JDK-7169915 could be solved with my PATCH.
3- There is regression between JDK8 and JDK9 may be in the Views 
arrangement.

Best regards.

----------------------------------------------------------------------------------------------------------------------

Hello,

Could you apply the modification I suggested 4 years ago about the Bug : 
JDK-7169915 : Swing Table Layout bad repaint of the row.

The test case I had sent in 2012 is the same I used in : JDK-8133864 
Wrong display, when the document I18n properties is true.

A version of this test (called I18nLayoutTest.java) is now candidate as 
part of tests for JDK 9 (/test/javax/swing/text/TableView/)

Yours faithfully.


-- 
Abossolo Foh Guy
71 rue Guy de Maupassant
69500 Bron
-------------- next part --------------
A non-text attachment was scrubbed...
Name: output_diff.txt
Type: text/x-java
Size: 6254 bytes
Desc: not available
URL: <http://mail.openjdk.java.net/pipermail/swing-dev/attachments/20160419/f47fda06/output_diff.txt>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: openjdk_versions.txt
URL: <http://mail.openjdk.java.net/pipermail/swing-dev/attachments/20160419/f47fda06/openjdk_versions.txt>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: CodeBug.java
Type: text/x-java
Size: 8804 bytes
Desc: not available
URL: <http://mail.openjdk.java.net/pipermail/swing-dev/attachments/20160419/f47fda06/CodeBug.java>

From semyon.sadetsky at oracle.com  Tue Apr 19 11:40:18 2016
From: semyon.sadetsky at oracle.com (Semyon Sadetsky)
Date: Tue, 19 Apr 2016 14:40:18 +0300
Subject: <Swing Dev> [9] Review request for 8154431: Allow source and target
 based validation for the focus transfer between two JComponents.
Message-ID: <57161922.8080808@oracle.com>

Hello,

Please review fix for JDK9:
bug: https://bugs.openjdk.java.net/browse/JDK-8154431
webrev: http://cr.openjdk.java.net/~ssadetsky/8154431/webrev.00/

The thing is the Swing validation doesn't allow to validate state of the 
target component of input focus transfer operation.
To support that the fix adds two new methods verifyTarget(JComponent 
target) and shouldYieldFocus(JComponent source, JComponent target) to 
the javax.swing.InputVerifier class, and its old 
shouldYieldFocus(JComponent input) is marked as deprecated.
The solution guaranties full compatibility with previous JDK versions.

--Semyon

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

From alexandr.scherbatiy at oracle.com  Tue Apr 19 12:21:48 2016
From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy)
Date: Tue, 19 Apr 2016 16:21:48 +0400
Subject: <Swing Dev> [9] Review request for 8152677 [macosx] All files
 filter can't be selected in JFileChooser
In-Reply-To: <57111651.7050108@oracle.com>
References: <5710F0C3.5030201@oracle.com> <5710FA4A.4080502@oracle.com>
	<5711154B.10200@oracle.com> <57111651.7050108@oracle.com>
Message-ID: <571622DC.8070209@oracle.com>


   Hello,

   Could you review the updated fix:
     http://cr.openjdk.java.net/~alexsch/8152677/webrev.01

   - file chooser file filter is used as an initial value for the old 
file filter in the AquaFileChooserUI.FilterComboBoxModel
   - AcceptAllFileFilter class and filed are made static


  The current regression appears after fixing issue JDK-8031696 [macosx] 
TwentyThousandTest test failed with OOM.
  This was because for the each file filter setting (this includes file 
chooser creating and UI updating) new Aqua L&F file loading thread was 
started.
  The current fix makes the acceptAllFileFilter field static which 
allows to eliminate the tread starting when the file chooser UI is 
updated. However, it is still not enough and the TwentyThousandTest 
still fails. It requires additional investigation what else leads to the 
OOME.  I have created a separate issue on it: JDK-8154548 [macosx] 
Reconsider TwentyThousandTest test failed fix:
    https://bugs.openjdk.java.net/browse/JDK-8154548

   Thanks,
   Alexandr.


On 15/04/16 20:26, Sergey Bylokhov wrote:
> On 15.04.16 19:22, Alexander Scherbatiy wrote:
>> On 15/04/16 18:27, Sergey Bylokhov wrote:
>>   When a JFileChooser is created it always adds Accept All file filter
>> in the constructor because useAcceptAllFileFilter filed is true by 
>> default.
>>   Because of this the AquaFileChooserUI.FilterComboBoxModel initially
>> has the Accept All file filter as the first item.
>>
>>   After that it is possible to unset the Accept All file filter by
>> calling JFileChooser.setAcceptAllFileFilterUsed(false).
>
> But what will happen if the user will update the filter before the 
> Aqua will be set as default l&f(for example if Metal is set as default 
> via commandline)?
>
>>> On 15.04.16 16:46, Alexander Scherbatiy wrote:
>>>>
>>>> Hello,
>>>>
>>>> Could you review the fix:
>>>>    bug: https://bugs.openjdk.java.net/browse/JDK-8152677
>>>>    webrev: http://cr.openjdk.java.net/~alexsch/8152677/webrev.00
>>>>
>>>>    FilterComboBoxModel from AquaFileChooserUI overrides
>>>> getSelectedItem() method to always return the selected filter from the
>>>> file chooser.
>>>>
>>>>    JFileChooser.setFileFilter(FileFilter) first assign the passed 
>>>> filter
>>>> to fileFilter field and then fire "fileFilterChanged" property change
>>>> event. This leads that FilterComboBoxModel compares new file filter 
>>>> with
>>>> the selected one (which has the same value because it is obtained from
>>>> JFileChooser.fileFilter field) and do not updated JComboBox internal
>>>> structure so JComboBox.selectedItemReminder field still points to the
>>>> old one.
>>>>
>>>>    When a user selects ?All Files? filter which is the first item 
>>>> from a
>>>> JFileChooser the JComboBox does not fire the action event because
>>>> selectedItemReminder points to the same first item.
>>>>
>>>>    The proposed solution is to remember the previous selected item in
>>>> the AquaFileChooserUI.FilterComboBoxModel.
>>>>
>>>>    Thanks,
>>>>    Alexandr.
>>>
>>>
>>
>
>



From Sergey.Bylokhov at oracle.com  Tue Apr 19 12:38:34 2016
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Tue, 19 Apr 2016 15:38:34 +0300
Subject: <Swing Dev> Review Request of 8152492: [macosx swing] double
 key event actions when using Mac menubar
In-Reply-To: <9D087362-41B8-46F3-8A6C-E47D9186723C@oracle.com>
References: <350CB937-DB61-46D9-A456-47D337E4788A@oracle.com>
	<5707C409.4030702@oracle.com>
	<123F5EB3-DD71-4706-A9F2-217F8B29BEF7@oracle.com>
	<9D087362-41B8-46F3-8A6C-E47D9186723C@oracle.com>
Message-ID: <571626CA.4050504@oracle.com>

On 19.04.16 11:46, Avik Niyogi wrote:
> Hi All,
> Please review my code changes with inputs received:

Can you please add some description of your changes, it seems you 
removed all code which was added by you previously.

> http://cr.openjdk.java.net/~aniyogi/8152492/webrev.01/
>
> With Regards,
> Avik Niyogi
>> On 19-Apr-2016, at 11:47 am, Avik Niyogi <avik.niyogi at oracle.com
>> <mailto:avik.niyogi at oracle.com>> wrote:
>>
>> Hi Sergey,
>> I have tried all these Input sources:
>> <Screen Shot 2016-04-19 at 11.40.33 am.png>
>> I am unable to reproduce the test failure as mentioned by you with
>> these inputs. Please provide some screenshots and/or details of the
>> procedure used for this test failure.
>> Thank you in advance.
>>
>> With Regards,
>> Avik Niyogi
>>
>>> On 08-Apr-2016, at 8:15 pm, Sergey Bylokhov
>>> <Sergey.Bylokhov at oracle.com <mailto:Sergey.Bylokhov at oracle.com>> wrote:
>>>
>>> Hi, Avik.
>>> It seems there is one more bug in this "if".
>>> Change the input source to "Hindi Dev.."/"Russian.." then this test
>>> fails anyway(it will produce the double action).
>>> Moreover if I change the source input to Hindi Transliteration, the
>>> test sometimes crashed.
>>> Please double check.
>>>
>>> On 06.04.16 13:42, Avik Niyogi wrote:
>>>> Hi All,
>>>>
>>>> Kindly review the bug fix for JDK 9.
>>>>
>>>> *Bug:*
>>>> https://bugs.openjdk.java.net/browse/JDK-8152492
>>>>
>>>> *Webrev:*
>>>> http://cr.openjdk.java.net/~aniyogi/8152492/webrev.00/
>>>>
>>>> *Issue:*
>>>> For OSX, having there is provision of non-integrated menubar. for this
>>>> case, triggering the menu action by key press triggered double action in
>>>> some cases
>>>>
>>>> *Cause:*
>>>> Due to the use of Shift modifier being a soft modifier in case of mac.
>>>> For example ?Shift + m? is actually ?M? and ?Shift + ,? is ?<? .
>>>> So such cases can not be used as shortcuts. This needs to be
>>>> accounted for.
>>>> Also, cases where ?Cmd + Shift + c? is used as a shortcut, it should not
>>>> morph that to a ?Cmd + C? command and should detect c itself.
>>>> Also, ?Shift + ?? has no equivalent soft modification and can be taken
>>>> as a shortcut. This has to be accounted for.
>>>>
>>>> *Fix:*
>>>> All required edge case scenarios for the soft modification of Shift and
>>>> cases of valid modifiers were taken into account.
>>>>
>>>> With Regards,
>>>> Avik Niyogi
>>>
>>>
>>> --
>>> Best regards, Sergey.
>>
>


-- 
Best regards, Sergey.


From alexandr.scherbatiy at oracle.com  Tue Apr 19 12:39:34 2016
From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy)
Date: Tue, 19 Apr 2016 16:39:34 +0400
Subject: <Swing Dev> RfR JDK-8076554,
 [macosx] Custom Swing text components need to allow standard
 accessibility
In-Reply-To: <57158F03.1060708@oracle.com>
References: <57158F03.1060708@oracle.com>
Message-ID: <57162706.5050102@oracle.com>

On 19/04/16 05:50, Pete Brunet wrote:
> Please review the following patch.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8076554
> Patch: http://cr.openjdk.java.net/~ptbrunet/JDK-8076554/webrev.02/
>
> The problem is that the code is currently hardcoded to only support text
> accessibility for JTextComponent using the DocumentListener,
> CaretListener interfaces.  This eliminates the ability to provide
> accessibility for a custom text components.  The resolution is to remove
> the JTextComponent gate and use the PropertyChangeListener listener
> interface with its ACCESSIBLE_CARET_PROPERTY and
> ACCESSIBLE_TEXT_PROPERTY properties.
   The AccessibleState class already has the MANAGES_DESCENDANTS 
constant. What is purpose to add a constant with the same name to the 
_AccessibleState?

   Thanks,
   Alexandr.
>
> I tested this with the two test cases which can be found at
> http://cr.openjdk.java.net/~ptbrunet/JDK-8076554/test/
> running them side by side with VoiceOver.
>
> Note that I will fix the similar JProgressBar and JSlider restrictions
> in JDK-8154507 and JDK-8154508 respectively.
>
> Pete
>
>

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

From alexandr.scherbatiy at oracle.com  Tue Apr 19 13:00:12 2016
From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy)
Date: Tue, 19 Apr 2016 17:00:12 +0400
Subject: <Swing Dev> [9] Review request for 8154431: Allow source and
 target based validation for the focus transfer between two JComponents.
In-Reply-To: <57161922.8080808@oracle.com>
References: <57161922.8080808@oracle.com>
Message-ID: <57162BDC.3010106@oracle.com>

On 19/04/16 15:40, Semyon Sadetsky wrote:
> Hello,
>
> Please review fix for JDK9:
> bug: https://bugs.openjdk.java.net/browse/JDK-8154431
> webrev: http://cr.openjdk.java.net/~ssadetsky/8154431/webrev.00/

   - there is a small typo in the test copyright year: 20016
   - could you add a check to the verifyTarget(JComponent) method 
implementation in the test that the passed component is really the 
target component.

   Thanks,
   Alexandr.
>
> The thing is the Swing validation doesn't allow to validate state of 
> the target component of input focus transfer operation.
> To support that the fix adds two new methods verifyTarget(JComponent 
> target) and shouldYieldFocus(JComponent source, JComponent target) to 
> the javax.swing.InputVerifier class, and its old 
> shouldYieldFocus(JComponent input) is marked as deprecated.
> The solution guaranties full compatibility with previous JDK versions.
>
> --Semyon
>

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

From Sergey.Bylokhov at oracle.com  Tue Apr 19 13:04:25 2016
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Tue, 19 Apr 2016 16:04:25 +0300
Subject: <Swing Dev> [9] Review request for 8152677 [macosx] All files
 filter can't be selected in JFileChooser
In-Reply-To: <571622DC.8070209@oracle.com>
References: <5710F0C3.5030201@oracle.com> <5710FA4A.4080502@oracle.com>
	<5711154B.10200@oracle.com> <57111651.7050108@oracle.com>
	<571622DC.8070209@oracle.com>
Message-ID: <57162CD9.7090607@oracle.com>

Looks fine.

On 19.04.16 15:21, Alexander Scherbatiy wrote:
>
>    Hello,
>
>    Could you review the updated fix:
>      http://cr.openjdk.java.net/~alexsch/8152677/webrev.01
>
>    - file chooser file filter is used as an initial value for the old
> file filter in the AquaFileChooserUI.FilterComboBoxModel
>    - AcceptAllFileFilter class and filed are made static
>
>
>   The current regression appears after fixing issue JDK-8031696 [macosx]
> TwentyThousandTest test failed with OOM.
>   This was because for the each file filter setting (this includes file
> chooser creating and UI updating) new Aqua L&F file loading thread was
> started.
>   The current fix makes the acceptAllFileFilter field static which
> allows to eliminate the tread starting when the file chooser UI is
> updated. However, it is still not enough and the TwentyThousandTest
> still fails. It requires additional investigation what else leads to the
> OOME.  I have created a separate issue on it: JDK-8154548 [macosx]
> Reconsider TwentyThousandTest test failed fix:
>     https://bugs.openjdk.java.net/browse/JDK-8154548
>
>    Thanks,
>    Alexandr.
>
>
> On 15/04/16 20:26, Sergey Bylokhov wrote:
>> On 15.04.16 19:22, Alexander Scherbatiy wrote:
>>> On 15/04/16 18:27, Sergey Bylokhov wrote:
>>>   When a JFileChooser is created it always adds Accept All file filter
>>> in the constructor because useAcceptAllFileFilter filed is true by
>>> default.
>>>   Because of this the AquaFileChooserUI.FilterComboBoxModel initially
>>> has the Accept All file filter as the first item.
>>>
>>>   After that it is possible to unset the Accept All file filter by
>>> calling JFileChooser.setAcceptAllFileFilterUsed(false).
>>
>> But what will happen if the user will update the filter before the
>> Aqua will be set as default l&f(for example if Metal is set as default
>> via commandline)?
>>
>>>> On 15.04.16 16:46, Alexander Scherbatiy wrote:
>>>>>
>>>>> Hello,
>>>>>
>>>>> Could you review the fix:
>>>>>    bug: https://bugs.openjdk.java.net/browse/JDK-8152677
>>>>>    webrev: http://cr.openjdk.java.net/~alexsch/8152677/webrev.00
>>>>>
>>>>>    FilterComboBoxModel from AquaFileChooserUI overrides
>>>>> getSelectedItem() method to always return the selected filter from the
>>>>> file chooser.
>>>>>
>>>>>    JFileChooser.setFileFilter(FileFilter) first assign the passed
>>>>> filter
>>>>> to fileFilter field and then fire "fileFilterChanged" property change
>>>>> event. This leads that FilterComboBoxModel compares new file filter
>>>>> with
>>>>> the selected one (which has the same value because it is obtained from
>>>>> JFileChooser.fileFilter field) and do not updated JComboBox internal
>>>>> structure so JComboBox.selectedItemReminder field still points to the
>>>>> old one.
>>>>>
>>>>>    When a user selects ?All Files? filter which is the first item
>>>>> from a
>>>>> JFileChooser the JComboBox does not fire the action event because
>>>>> selectedItemReminder points to the same first item.
>>>>>
>>>>>    The proposed solution is to remember the previous selected item in
>>>>> the AquaFileChooserUI.FilterComboBoxModel.
>>>>>
>>>>>    Thanks,
>>>>>    Alexandr.
>>>>
>>>>
>>>
>>
>>
>


-- 
Best regards, Sergey.


From peter.brunet at oracle.com  Tue Apr 19 15:54:45 2016
From: peter.brunet at oracle.com (Pete Brunet)
Date: Tue, 19 Apr 2016 10:54:45 -0500
Subject: <Swing Dev> RfR JDK-8076554,
 [macosx] Custom Swing text components need to allow standard
 accessibility
In-Reply-To: <57162706.5050102@oracle.com>
References: <57158F03.1060708@oracle.com> <57162706.5050102@oracle.com>
Message-ID: <571654C5.1020008@oracle.com>

Thanks for noticing that Alexandr.  I see this state was added in 1.5
and apparently the code from which I borrowed this from was never
updated.  I will remove that and open a bug to remove that from the
original.  -Pete

On 4/19/16 7:39 AM, Alexander Scherbatiy wrote:
> On 19/04/16 05:50, Pete Brunet wrote:
>> Please review the following patch.
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8076554
>> Patch: http://cr.openjdk.java.net/~ptbrunet/JDK-8076554/webrev.02/
>>
>> The problem is that the code is currently hardcoded to only support text
>> accessibility for JTextComponent using the DocumentListener,
>> CaretListener interfaces.  This eliminates the ability to provide
>> accessibility for a custom text components.  The resolution is to remove
>> the JTextComponent gate and use the PropertyChangeListener listener
>> interface with its ACCESSIBLE_CARET_PROPERTY and
>> ACCESSIBLE_TEXT_PROPERTY properties.
>   The AccessibleState class already has the MANAGES_DESCENDANTS
> constant. What is purpose to add a constant with the same name to the
> _AccessibleState?
>
>   Thanks,
>   Alexandr.
>> I tested this with the two test cases which can be found at
>> http://cr.openjdk.java.net/~ptbrunet/JDK-8076554/test/
>> running them side by side with VoiceOver.
>>
>> Note that I will fix the similar JProgressBar and JSlider restrictions
>> in JDK-8154507 and JDK-8154508 respectively.
>>
>> Pete
>>
>>
>

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

From philip.race at oracle.com  Tue Apr 19 17:21:40 2016
From: philip.race at oracle.com (Phil Race)
Date: Tue, 19 Apr 2016 10:21:40 -0700 (PDT)
Subject: <Swing Dev> RfR JDK-8076554,
 [macosx] Custom Swing text components need to allow standard
 accessibility
In-Reply-To: <571654C5.1020008@oracle.com>
References: <57158F03.1060708@oracle.com> <57162706.5050102@oracle.com>
	<571654C5.1020008@oracle.com>
Message-ID: <57166924.4040301@oracle.com>

Which seems to imply the _AccessibleState subclass has been obsolete 
since 1.5
Although when these tools were unbundled it perhaps could not assume 1.5.

The rest of the changes look fine and it is a lot simpler than the v0 ..

-phil.

On 04/19/2016 08:54 AM, Pete Brunet wrote:
> Thanks for noticing that Alexandr.  I see this state was added in 1.5 
> and apparently the code from which I borrowed this from was never 
> updated.  I will remove that and open a bug to remove that from the 
> original.  -Pete
>
> On 4/19/16 7:39 AM, Alexander Scherbatiy wrote:
>> On 19/04/16 05:50, Pete Brunet wrote:
>>> Please review the following patch.
>>>
>>> Bug:https://bugs.openjdk.java.net/browse/JDK-8076554
>>> Patch:http://cr.openjdk.java.net/~ptbrunet/JDK-8076554/webrev.02/
>>>
>>> The problem is that the code is currently hardcoded to only support text
>>> accessibility for JTextComponent using the DocumentListener,
>>> CaretListener interfaces.  This eliminates the ability to provide
>>> accessibility for a custom text components.  The resolution is to remove
>>> the JTextComponent gate and use the PropertyChangeListener listener
>>> interface with its ACCESSIBLE_CARET_PROPERTY and
>>> ACCESSIBLE_TEXT_PROPERTY properties.
>>   The AccessibleState class already has the MANAGES_DESCENDANTS 
>> constant. What is purpose to add a constant with the same name to the 
>> _AccessibleState?
>>
>>   Thanks,
>>   Alexandr.
>>> I tested this with the two test cases which can be found at
>>> http://cr.openjdk.java.net/~ptbrunet/JDK-8076554/test/
>>> running them side by side with VoiceOver.
>>>
>>> Note that I will fix the similar JProgressBar and JSlider restrictions
>>> in JDK-8154507 and JDK-8154508 respectively.
>>>
>>> Pete
>>>
>>>
>>
>

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

From philip.race at oracle.com  Tue Apr 19 17:26:52 2016
From: philip.race at oracle.com (Phil Race)
Date: Tue, 19 Apr 2016 10:26:52 -0700 (PDT)
Subject: <Swing Dev> RfR JDK-8076554,
 [macosx] Custom Swing text components need to allow standard
 accessibility
In-Reply-To: <57166924.4040301@oracle.com>
References: <57158F03.1060708@oracle.com> <57162706.5050102@oracle.com>
	<571654C5.1020008@oracle.com> <57166924.4040301@oracle.com>
Message-ID: <57166A5C.2010902@oracle.com>

oh one nit picky thing - can we get rid of the wild card imports ?

-phil.

On 04/19/2016 10:21 AM, Phil Race wrote:
> Which seems to imply the _AccessibleState subclass has been obsolete 
> since 1.5
> Although when these tools were unbundled it perhaps could not assume 1.5.
>
> The rest of the changes look fine and it is a lot simpler than the v0 ..
>
> -phil.
>
> On 04/19/2016 08:54 AM, Pete Brunet wrote:
>> Thanks for noticing that Alexandr.  I see this state was added in 1.5 
>> and apparently the code from which I borrowed this from was never 
>> updated.  I will remove that and open a bug to remove that from the 
>> original.  -Pete
>>
>> On 4/19/16 7:39 AM, Alexander Scherbatiy wrote:
>>> On 19/04/16 05:50, Pete Brunet wrote:
>>>> Please review the following patch.
>>>>
>>>> Bug:https://bugs.openjdk.java.net/browse/JDK-8076554
>>>> Patch:http://cr.openjdk.java.net/~ptbrunet/JDK-8076554/webrev.02/
>>>>
>>>> The problem is that the code is currently hardcoded to only support text
>>>> accessibility for JTextComponent using the DocumentListener,
>>>> CaretListener interfaces.  This eliminates the ability to provide
>>>> accessibility for a custom text components.  The resolution is to remove
>>>> the JTextComponent gate and use the PropertyChangeListener listener
>>>> interface with its ACCESSIBLE_CARET_PROPERTY and
>>>> ACCESSIBLE_TEXT_PROPERTY properties.
>>>   The AccessibleState class already has the MANAGES_DESCENDANTS 
>>> constant. What is purpose to add a constant with the same name to 
>>> the _AccessibleState?
>>>
>>>   Thanks,
>>>   Alexandr.
>>>> I tested this with the two test cases which can be found at
>>>> http://cr.openjdk.java.net/~ptbrunet/JDK-8076554/test/
>>>> running them side by side with VoiceOver.
>>>>
>>>> Note that I will fix the similar JProgressBar and JSlider restrictions
>>>> in JDK-8154507 and JDK-8154508 respectively.
>>>>
>>>> Pete
>>>>
>>>>
>>>
>>
>

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

From philip.race at oracle.com  Tue Apr 19 16:47:50 2016
From: philip.race at oracle.com (Phil Race)
Date: Tue, 19 Apr 2016 09:47:50 -0700 (PDT)
Subject: <Swing Dev> [9] Review request for 8154431: Allow source and
 target based validation for the focus transfer between two JComponents.
In-Reply-To: <57161922.8080808@oracle.com>
References: <57161922.8080808@oracle.com>
Message-ID: <57166136.90205@oracle.com>

Hi,

You are deprecating shouldYieldFocus(JComponent) and yet this class 
directly uses it.
Is this deprecation really the right thing to do ?

The new over-loaded shouldYieldFocus() is perhaps not much more than a 
utility.
And the doc says "calls verify(input)" which seems odd since you do not
directly call it. And you are just describing what the default 
implementation
does aren't you ?

-phil.

On 04/19/2016 04:40 AM, Semyon Sadetsky wrote:
> Hello,
>
> Please review fix for JDK9:
> bug: https://bugs.openjdk.java.net/browse/JDK-8154431
> webrev: http://cr.openjdk.java.net/~ssadetsky/8154431/webrev.00/
>
> The thing is the Swing validation doesn't allow to validate state of 
> the target component of input focus transfer operation.
> To support that the fix adds two new methods verifyTarget(JComponent 
> target) and shouldYieldFocus(JComponent source, JComponent target) to 
> the javax.swing.InputVerifier class, and its old 
> shouldYieldFocus(JComponent input) is marked as deprecated.
> The solution guaranties full compatibility with previous JDK versions.
>
> --Semyon
>

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

From semyon.sadetsky at oracle.com  Tue Apr 19 18:05:11 2016
From: semyon.sadetsky at oracle.com (Semyon Sadetsky)
Date: Tue, 19 Apr 2016 11:05:11 -0700 (PDT)
Subject: <Swing Dev> [9] Review request for 8154431: Allow source and
 target based validation for the focus transfer between two JComponents.
In-Reply-To: <57166136.90205@oracle.com>
References: <57161922.8080808@oracle.com> <57166136.90205@oracle.com>
Message-ID: <57167357.2050705@oracle.com>

On 4/19/2016 7:47 PM, Phil Race wrote:
> Hi,
>
> You are deprecating shouldYieldFocus(JComponent) and yet this class 
> directly uses it.
> Is this deprecation really the right thing to do ?
Why is this not correct? There are plenty examples in JDK: 
Component#setVisible() & Component#show(), Component#transferFocus() & 
Component#nextFocus(), etc...
This is necessary for backward compatibility.
>
> The new over-loaded shouldYieldFocus() is perhaps not much more than a 
> utility.
> And the doc says "calls verify(input)" which seems odd since you do not
> directly call it. And you are just describing what the default 
> implementation
> does aren't you ?
This is also necessary for compatibility. There may be implementations 
of the InputVerify where the shouldYieldFocus() is overloaded since it 
is public (that was initial design mistake, I suppose). At the same time 
the shouldYieldFocus() is the entry point that plugs InputVerify into 
the JComponent.
But you are correct "calls verify(input)" is not precisely describes 
what happens in this method. Maybe just make it more indirect, like 
"validate the source and the target components..."?

--Semyon
>
> -phil.
>
> On 04/19/2016 04:40 AM, Semyon Sadetsky wrote:
>> Hello,
>>
>> Please review fix for JDK9:
>> bug: https://bugs.openjdk.java.net/browse/JDK-8154431
>> webrev: http://cr.openjdk.java.net/~ssadetsky/8154431/webrev.00/
>>
>> The thing is the Swing validation doesn't allow to validate state of 
>> the target component of input focus transfer operation.
>> To support that the fix adds two new methods verifyTarget(JComponent 
>> target) and shouldYieldFocus(JComponent source, JComponent target) to 
>> the javax.swing.InputVerifier class, and its old 
>> shouldYieldFocus(JComponent input) is marked as deprecated.
>> The solution guaranties full compatibility with previous JDK versions.
>>
>> --Semyon
>>
>

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

From peter.brunet at oracle.com  Tue Apr 19 19:05:21 2016
From: peter.brunet at oracle.com (Pete Brunet)
Date: Tue, 19 Apr 2016 14:05:21 -0500
Subject: <Swing Dev> RfR JDK-8076554,
 [macosx] Custom Swing text components need to allow standard
 accessibility
In-Reply-To: <57166A5C.2010902@oracle.com>
References: <57158F03.1060708@oracle.com> <57162706.5050102@oracle.com>
	<571654C5.1020008@oracle.com> <57166924.4040301@oracle.com>
	<57166A5C.2010902@oracle.com>
Message-ID: <57168171.8070207@oracle.com>

New patch: http://cr.openjdk.java.net/~ptbrunet/JDK-8076554/webrev.03/

Changes:
- removed _AccessibleState
- removed wildcard imports.

Is this ready to push?

Pete

On 4/19/16 12:26 PM, Phil Race wrote:
> oh one nit picky thing - can we get rid of the wild card imports ?
>
> -phil.
>
> On 04/19/2016 10:21 AM, Phil Race wrote:
>> Which seems to imply the _AccessibleState subclass has been obsolete
>> since 1.5
>> Although when these tools were unbundled it perhaps could not assume 1.5.
>>
>> The rest of the changes look fine and it is a lot simpler than the v0 ..
>>
>> -phil.
>>
>> On 04/19/2016 08:54 AM, Pete Brunet wrote:
>>> Thanks for noticing that Alexandr.  I see this state was added in
>>> 1.5 and apparently the code from which I borrowed this from was
>>> never updated.  I will remove that and open a bug to remove that
>>> from the original.  -Pete
>>>
>>> On 4/19/16 7:39 AM, Alexander Scherbatiy wrote:
>>>> On 19/04/16 05:50, Pete Brunet wrote:
>>>>> Please review the following patch.
>>>>>
>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8076554
>>>>> Patch: http://cr.openjdk.java.net/~ptbrunet/JDK-8076554/webrev.02/
>>>>>
>>>>> The problem is that the code is currently hardcoded to only support text
>>>>> accessibility for JTextComponent using the DocumentListener,
>>>>> CaretListener interfaces.  This eliminates the ability to provide
>>>>> accessibility for a custom text components.  The resolution is to remove
>>>>> the JTextComponent gate and use the PropertyChangeListener listener
>>>>> interface with its ACCESSIBLE_CARET_PROPERTY and
>>>>> ACCESSIBLE_TEXT_PROPERTY properties.
>>>>   The AccessibleState class already has the MANAGES_DESCENDANTS
>>>> constant. What is purpose to add a constant with the same name to
>>>> the _AccessibleState?
>>>>
>>>>   Thanks,
>>>>   Alexandr.
>>>>> I tested this with the two test cases which can be found at
>>>>> http://cr.openjdk.java.net/~ptbrunet/JDK-8076554/test/
>>>>> running them side by side with VoiceOver.
>>>>>
>>>>> Note that I will fix the similar JProgressBar and JSlider restrictions
>>>>> in JDK-8154507 and JDK-8154508 respectively.
>>>>>
>>>>> Pete
>>>>>
>>>>>
>>>>
>>>
>>
>

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

From philip.race at oracle.com  Tue Apr 19 19:16:55 2016
From: philip.race at oracle.com (Phil Race)
Date: Tue, 19 Apr 2016 12:16:55 -0700
Subject: <Swing Dev> RfR JDK-8076554,
 [macosx] Custom Swing text components need to allow standard
 accessibility
In-Reply-To: <57168171.8070207@oracle.com>
References: <57158F03.1060708@oracle.com> <57162706.5050102@oracle.com>
	<571654C5.1020008@oracle.com> <57166924.4040301@oracle.com>
	<57166A5C.2010902@oracle.com> <57168171.8070207@oracle.com>
Message-ID: <57168427.3080905@oracle.com>

+1

-phil.

On 04/19/2016 12:05 PM, Pete Brunet wrote:
> New patch: http://cr.openjdk.java.net/~ptbrunet/JDK-8076554/webrev.03/
>
> Changes:
> - removed _AccessibleState
> - removed wildcard imports.
>
> Is this ready to push?
>
> Pete
>
> On 4/19/16 12:26 PM, Phil Race wrote:
>> oh one nit picky thing - can we get rid of the wild card imports ?
>>
>> -phil.
>>
>> On 04/19/2016 10:21 AM, Phil Race wrote:
>>> Which seems to imply the _AccessibleState subclass has been obsolete 
>>> since 1.5
>>> Although when these tools were unbundled it perhaps could not assume 
>>> 1.5.
>>>
>>> The rest of the changes look fine and it is a lot simpler than the v0 ..
>>>
>>> -phil.
>>>
>>> On 04/19/2016 08:54 AM, Pete Brunet wrote:
>>>> Thanks for noticing that Alexandr.  I see this state was added in 
>>>> 1.5 and apparently the code from which I borrowed this from was 
>>>> never updated.  I will remove that and open a bug to remove that 
>>>> from the original.  -Pete
>>>>
>>>> On 4/19/16 7:39 AM, Alexander Scherbatiy wrote:
>>>>> On 19/04/16 05:50, Pete Brunet wrote:
>>>>>> Please review the following patch.
>>>>>>
>>>>>> Bug:https://bugs.openjdk.java.net/browse/JDK-8076554
>>>>>> Patch:http://cr.openjdk.java.net/~ptbrunet/JDK-8076554/webrev.02/
>>>>>>
>>>>>> The problem is that the code is currently hardcoded to only support text
>>>>>> accessibility for JTextComponent using the DocumentListener,
>>>>>> CaretListener interfaces.  This eliminates the ability to provide
>>>>>> accessibility for a custom text components.  The resolution is to remove
>>>>>> the JTextComponent gate and use the PropertyChangeListener listener
>>>>>> interface with its ACCESSIBLE_CARET_PROPERTY and
>>>>>> ACCESSIBLE_TEXT_PROPERTY properties.
>>>>>   The AccessibleState class already has the MANAGES_DESCENDANTS 
>>>>> constant. What is purpose to add a constant with the same name to 
>>>>> the _AccessibleState?
>>>>>
>>>>>   Thanks,
>>>>>   Alexandr.
>>>>>> I tested this with the two test cases which can be found at
>>>>>> http://cr.openjdk.java.net/~ptbrunet/JDK-8076554/test/
>>>>>> running them side by side with VoiceOver.
>>>>>>
>>>>>> Note that I will fix the similar JProgressBar and JSlider restrictions
>>>>>> in JDK-8154507 and JDK-8154508 respectively.
>>>>>>
>>>>>> Pete
>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>

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

From philip.race at oracle.com  Tue Apr 19 21:11:04 2016
From: philip.race at oracle.com (Phil Race)
Date: Tue, 19 Apr 2016 14:11:04 -0700 (PDT)
Subject: <Swing Dev> [9] Review request for 8154431: Allow source and
 target based validation for the focus transfer between two JComponents.
In-Reply-To: <571689F5.6000401@oracle.com>
References: <57161922.8080808@oracle.com> <57166136.90205@oracle.com>
	<57167357.2050705@oracle.com> <571689F5.6000401@oracle.com>
Message-ID: <57169EE8.1040108@oracle.com>

PS I see the class doc talks about shouldYieldFocus() being called,
so I don't understand the inter-relationship of that and verify(), but
it makes me no more sure that deprecating that method is right.

I think perhaps verify() is all that the app is supposed to have over-ridden
and the comments are written on the assumption it would not over-ride
anything else.
So perhaps the design mistake could be that shouldYieldFocus() was not 
final.
Maybe your new one should be - if it is public at all ...

BTW you removed text that says

  Before focus is transfered to another Swing component

The key word here is SWING - I looked at the JComponent code
and it returns true if either source or target is not a JComponent,
without ever getting near the call to shouldYieldFocus().

-phil.


On 04/19/2016 12:41 PM, Phil Race wrote:
> On 04/19/2016 11:05 AM, Semyon Sadetsky wrote:
>> On 4/19/2016 7:47 PM, Phil Race wrote:
>>> Hi,
>>>
>>> You are deprecating shouldYieldFocus(JComponent) and yet this class 
>>> directly uses it.
>>> Is this deprecation really the right thing to do ?
>> Why is this not correct? There are plenty examples in JDK: 
>> Component#setVisible() & Component#show(), Component#transferFocus() 
>> & Component#nextFocus(), etc...
>> This is necessary for backward compatibility.
>
> My question is why deprecate it ?
>
> So far as I can see unless some one wants to over-ride verifyTarget() 
> they are
> fine to continue over-riding this method and ignore the new one.
>
> Leaving aside the merits of those previous changes, and at least one 
> of those I think was dubious,
> all you have done is at an @Deprecated annotation. There is no 
> @deprecated javadoc tag, and you
> have left doc which says when this method is called. In fact that doc 
> is now very misleading.
> It is not called. You call the new one.
>
>
> BTW I see you mis-spell over-ridden as overriden in verifyTarget(..)
>
>>>
>>> The new over-loaded shouldYieldFocus() is perhaps not much more than 
>>> a utility.
>>> And the doc says "calls verify(input)" which seems odd since you do not
>>> directly call it. And you are just describing what the default 
>>> implementation
>>> does aren't you ?
>> This is also necessary for compatibility. There may be 
>> implementations of the InputVerify where the shouldYieldFocus() is 
>> overloaded since it is public (that was initial design mistake, I 
>> suppose). At the same time the shouldYieldFocus() is the entry point 
>> that plugs InputVerify into the JComponent.
>> But you are correct "calls verify(input)" is not precisely describes 
>> what happens in this method. Maybe just make it more indirect, like 
>> "validate the source and the target components..."?
>
> Now I am rather confused. You make it sound like verify() not 
> shouldYieldFocus() is all the public
> API should have contained, but you are adding a public over-load of it.
> So why does this new method need to be public ? All you need is 
> verifyTarget(), dont you ?
>
> -phil.
>
>
>>
>> --Semyon
>>>
>>> -phil.
>>>
>>> On 04/19/2016 04:40 AM, Semyon Sadetsky wrote:
>>>> Hello,
>>>>
>>>> Please review fix for JDK9:
>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8154431
>>>> webrev: http://cr.openjdk.java.net/~ssadetsky/8154431/webrev.00/
>>>>
>>>> The thing is the Swing validation doesn't allow to validate state 
>>>> of the target component of input focus transfer operation.
>>>> To support that the fix adds two new methods 
>>>> verifyTarget(JComponent target) and shouldYieldFocus(JComponent 
>>>> source, JComponent target) to the javax.swing.InputVerifier class, 
>>>> and its old shouldYieldFocus(JComponent input) is marked as 
>>>> deprecated.
>>>> The solution guaranties full compatibility with previous JDK versions.
>>>>
>>>> --Semyon
>>>>
>>>
>>
>

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

From peter.brunet at oracle.com  Tue Apr 19 21:52:34 2016
From: peter.brunet at oracle.com (Pete Brunet)
Date: Tue, 19 Apr 2016 14:52:34 -0700 (PDT)
Subject: <Swing Dev> RfR JDK-8076554,
 [macosx] Custom Swing text components need to allow standard
 accessibility
In-Reply-To: <57168427.3080905@oracle.com>
References: <57158F03.1060708@oracle.com> <57162706.5050102@oracle.com>
	<571654C5.1020008@oracle.com> <57166924.4040301@oracle.com>
	<57166A5C.2010902@oracle.com> <57168171.8070207@oracle.com>
	<57168427.3080905@oracle.com>
Message-ID: <5716A8A2.2060706@oracle.com>

p.s. JPRT ran OK. 

Still need one more +1.

On 4/19/16 2:16 PM, Phil Race wrote:
> +1
>
> -phil.
>
> On 04/19/2016 12:05 PM, Pete Brunet wrote:
>> New patch: http://cr.openjdk.java.net/~ptbrunet/JDK-8076554/webrev.03/
>>
>> Changes:
>> - removed _AccessibleState
>> - removed wildcard imports.
>>
>> Is this ready to push?
>>
>> Pete
>>
>> On 4/19/16 12:26 PM, Phil Race wrote:
>>> oh one nit picky thing - can we get rid of the wild card imports ?
>>>
>>> -phil.
>>>
>>> On 04/19/2016 10:21 AM, Phil Race wrote:
>>>> Which seems to imply the _AccessibleState subclass has been
>>>> obsolete since 1.5
>>>> Although when these tools were unbundled it perhaps could not
>>>> assume 1.5.
>>>>
>>>> The rest of the changes look fine and it is a lot simpler than the
>>>> v0 ..
>>>>
>>>> -phil.
>>>>
>>>> On 04/19/2016 08:54 AM, Pete Brunet wrote:
>>>>> Thanks for noticing that Alexandr.  I see this state was added in
>>>>> 1.5 and apparently the code from which I borrowed this from was
>>>>> never updated.  I will remove that and open a bug to remove that
>>>>> from the original.  -Pete
>>>>>
>>>>> On 4/19/16 7:39 AM, Alexander Scherbatiy wrote:
>>>>>> On 19/04/16 05:50, Pete Brunet wrote:
>>>>>>> Please review the following patch.
>>>>>>>
>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8076554
>>>>>>> Patch: http://cr.openjdk.java.net/~ptbrunet/JDK-8076554/webrev.02/
>>>>>>>
>>>>>>> The problem is that the code is currently hardcoded to only support text
>>>>>>> accessibility for JTextComponent using the DocumentListener,
>>>>>>> CaretListener interfaces.  This eliminates the ability to provide
>>>>>>> accessibility for a custom text components.  The resolution is to remove
>>>>>>> the JTextComponent gate and use the PropertyChangeListener listener
>>>>>>> interface with its ACCESSIBLE_CARET_PROPERTY and
>>>>>>> ACCESSIBLE_TEXT_PROPERTY properties.
>>>>>>   The AccessibleState class already has the MANAGES_DESCENDANTS
>>>>>> constant. What is purpose to add a constant with the same name to
>>>>>> the _AccessibleState?
>>>>>>
>>>>>>   Thanks,
>>>>>>   Alexandr.
>>>>>>> I tested this with the two test cases which can be found at
>>>>>>> http://cr.openjdk.java.net/~ptbrunet/JDK-8076554/test/
>>>>>>> running them side by side with VoiceOver.
>>>>>>>
>>>>>>> Note that I will fix the similar JProgressBar and JSlider restrictions
>>>>>>> in JDK-8154507 and JDK-8154508 respectively.
>>>>>>>
>>>>>>> Pete
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>

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

From semyon.sadetsky at oracle.com  Tue Apr 19 22:17:36 2016
From: semyon.sadetsky at oracle.com (Semyon Sadetsky)
Date: Tue, 19 Apr 2016 15:17:36 -0700 (PDT)
Subject: <Swing Dev> [9] Review request for 8154431: Allow source and
 target based validation for the focus transfer between two JComponents.
In-Reply-To: <57169EE8.1040108@oracle.com>
References: <57161922.8080808@oracle.com> <57166136.90205@oracle.com>
	<57167357.2050705@oracle.com> <571689F5.6000401@oracle.com>
	<57169EE8.1040108@oracle.com>
Message-ID: <5716AE80.7060106@oracle.com>

On 4/20/2016 12:11 AM, Phil Race wrote:
> PS I see the class doc talks about shouldYieldFocus() being called,
> so I don't understand the inter-relationship of that and verify(), but
> it makes me no more sure that deprecating that method is right.
I deprecated shouldYieldFocus(JCopmponent) and added 
shouldYieldFocus(JCopmponent, JComponent). I cannot simply remove the 
first because it's public and can be called from user code. But it's not 
used in JDK code outside this class anymore only internally for 
compatibility.
I can remove the @Depricated annotation but still cannot get why do we 
need to keep two overloaded shouldYieldFocus methods if only one is 
supposed to be used? That may confuse user which one of them to use, so 
@Depricated is a hint.
>
> I think perhaps verify() is all that the app is supposed to have 
> over-ridden
> and the comments are written on the assumption it would not over-ride
> anything else.
Right. But in fact shouldYieldFocus is public and not final.
> So perhaps the design mistake could be that shouldYieldFocus() was not 
> final.
> Maybe your new one should be - if it is public at all ...
Probably you are correct. Before this method had the same signature as 
verify() and there was no reason for user to change its default 
implementation because it would not provide anything extra . I think it 
should be package private then.
But now it has 2 arguments and can be taken in consideration as some 
intermediate step in which the results obtained from the verify() and 
the new verifyTarget() are combined, and user may want to change the 
behavior how they are combined. Does it make sense?
>
> BTW you removed text that says
>
> Before focus is transfered to another Swing component
> The key word here is SWING - I looked at the JComponent code
> and it returns true if either source or target is not a JComponent,
> without ever getting near the call to shouldYieldFocus().
I know. That is why I changed the description of the class and its first 
statement now:

" This class provides the validation mechanism for Swing components."

I think we can emphasize this additionally. What do you think about the 
next:

   39  * Before focus is transferred from the source Swing component to 
the target
   40  * Swing component

?

--Semyon

>
> -phil.
>
>
> On 04/19/2016 12:41 PM, Phil Race wrote:
>> On 04/19/2016 11:05 AM, Semyon Sadetsky wrote:
>>> On 4/19/2016 7:47 PM, Phil Race wrote:
>>>> Hi,
>>>>
>>>> You are deprecating shouldYieldFocus(JComponent) and yet this class 
>>>> directly uses it.
>>>> Is this deprecation really the right thing to do ?
>>> Why is this not correct? There are plenty examples in JDK: 
>>> Component#setVisible() & Component#show(), Component#transferFocus() 
>>> & Component#nextFocus(), etc...
>>> This is necessary for backward compatibility.
>>
>> My question is why deprecate it ?
>>
>> So far as I can see unless some one wants to over-ride verifyTarget() 
>> they are
>> fine to continue over-riding this method and ignore the new one.
>>
>> Leaving aside the merits of those previous changes, and at least one 
>> of those I think was dubious,
>> all you have done is at an @Deprecated annotation. There is no 
>> @deprecated javadoc tag, and you
>> have left doc which says when this method is called. In fact that doc 
>> is now very misleading.
>> It is not called. You call the new one.
>>
>>
>> BTW I see you mis-spell over-ridden as overriden in verifyTarget(..)
>>
>>>>
>>>> The new over-loaded shouldYieldFocus() is perhaps not much more 
>>>> than a utility.
>>>> And the doc says "calls verify(input)" which seems odd since you do not
>>>> directly call it. And you are just describing what the default 
>>>> implementation
>>>> does aren't you ?
>>> This is also necessary for compatibility. There may be 
>>> implementations of the InputVerify where the shouldYieldFocus() is 
>>> overloaded since it is public (that was initial design mistake, I 
>>> suppose). At the same time the shouldYieldFocus() is the entry point 
>>> that plugs InputVerify into the JComponent.
>>> But you are correct "calls verify(input)" is not precisely describes 
>>> what happens in this method. Maybe just make it more indirect, like 
>>> "validate the source and the target components..."?
>>
>> Now I am rather confused. You make it sound like verify() not 
>> shouldYieldFocus() is all the public
>> API should have contained, but you are adding a public over-load of it.
>> So why does this new method need to be public ? All you need is 
>> verifyTarget(), dont you ?
>>
>> -phil.
>>
>>
>>>
>>> --Semyon
>>>>
>>>> -phil.
>>>>
>>>> On 04/19/2016 04:40 AM, Semyon Sadetsky wrote:
>>>>> Hello,
>>>>>
>>>>> Please review fix for JDK9:
>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8154431
>>>>> webrev: http://cr.openjdk.java.net/~ssadetsky/8154431/webrev.00/
>>>>>
>>>>> The thing is the Swing validation doesn't allow to validate state 
>>>>> of the target component of input focus transfer operation.
>>>>> To support that the fix adds two new methods 
>>>>> verifyTarget(JComponent target) and shouldYieldFocus(JComponent 
>>>>> source, JComponent target) to the javax.swing.InputVerifier class, 
>>>>> and its old shouldYieldFocus(JComponent input) is marked as 
>>>>> deprecated.
>>>>> The solution guaranties full compatibility with previous JDK versions.
>>>>>
>>>>> --Semyon
>>>>>
>>>>
>>>
>>
>

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

From avik.niyogi at oracle.com  Wed Apr 20 06:07:57 2016
From: avik.niyogi at oracle.com (Avik Niyogi)
Date: Wed, 20 Apr 2016 11:37:57 +0530
Subject: <Swing Dev> Review Request of 8152492: [macosx swing] double
	key event actions when using Mac menubar
In-Reply-To: <571626CA.4050504@oracle.com>
References: <350CB937-DB61-46D9-A456-47D337E4788A@oracle.com>
	<5707C409.4030702@oracle.com>
	<123F5EB3-DD71-4706-A9F2-217F8B29BEF7@oracle.com>
	<9D087362-41B8-46F3-8A6C-E47D9186723C@oracle.com>
	<571626CA.4050504@oracle.com>
Message-ID: <4CC47F90-5269-40C8-82CA-5DC3B41713AB@oracle.com>

Hi All,
I have added some comments and made some minor tweaks as per the inputs received.
Please review my code changes as available at this link below:

http://cr.openjdk.java.net/~aniyogi/8152492/webrev.02/ <http://cr.openjdk.java.net/~aniyogi/8152492/webrev.02/>

With Regards,
Avik Niyogi

> On 19-Apr-2016, at 6:08 pm, Sergey Bylokhov <Sergey.Bylokhov at oracle.com> wrote:
> 
> On 19.04.16 11:46, Avik Niyogi wrote:
>> Hi All,
>> Please review my code changes with inputs received:
> 
> Can you please add some description of your changes, it seems you removed all code which was added by you previously.
> 
>> http://cr.openjdk.java.net/~aniyogi/8152492/webrev.01/ <http://cr.openjdk.java.net/~aniyogi/8152492/webrev.01/>
>> 
>> With Regards,
>> Avik Niyogi
>>> On 19-Apr-2016, at 11:47 am, Avik Niyogi <avik.niyogi at oracle.com <mailto:avik.niyogi at oracle.com>
>>> <mailto:avik.niyogi at oracle.com <mailto:avik.niyogi at oracle.com>>> wrote:
>>> 
>>> Hi Sergey,
>>> I have tried all these Input sources:
>>> <Screen Shot 2016-04-19 at 11.40.33 am.png>
>>> I am unable to reproduce the test failure as mentioned by you with
>>> these inputs. Please provide some screenshots and/or details of the
>>> procedure used for this test failure.
>>> Thank you in advance.
>>> 
>>> With Regards,
>>> Avik Niyogi
>>> 
>>>> On 08-Apr-2016, at 8:15 pm, Sergey Bylokhov
>>>> <Sergey.Bylokhov at oracle.com <mailto:Sergey.Bylokhov at oracle.com> <mailto:Sergey.Bylokhov at oracle.com <mailto:Sergey.Bylokhov at oracle.com>>> wrote:
>>>> 
>>>> Hi, Avik.
>>>> It seems there is one more bug in this "if".
>>>> Change the input source to "Hindi Dev.."/"Russian.." then this test
>>>> fails anyway(it will produce the double action).
>>>> Moreover if I change the source input to Hindi Transliteration, the
>>>> test sometimes crashed.
>>>> Please double check.
>>>> 
>>>> On 06.04.16 13:42, Avik Niyogi wrote:
>>>>> Hi All,
>>>>> 
>>>>> Kindly review the bug fix for JDK 9.
>>>>> 
>>>>> *Bug:*
>>>>> https://bugs.openjdk.java.net/browse/JDK-8152492
>>>>> 
>>>>> *Webrev:*
>>>>> http://cr.openjdk.java.net/~aniyogi/8152492/webrev.00/
>>>>> 
>>>>> *Issue:*
>>>>> For OSX, having there is provision of non-integrated menubar. for this
>>>>> case, triggering the menu action by key press triggered double action in
>>>>> some cases
>>>>> 
>>>>> *Cause:*
>>>>> Due to the use of Shift modifier being a soft modifier in case of mac.
>>>>> For example ?Shift + m? is actually ?M? and ?Shift + ,? is ?<? .
>>>>> So such cases can not be used as shortcuts. This needs to be
>>>>> accounted for.
>>>>> Also, cases where ?Cmd + Shift + c? is used as a shortcut, it should not
>>>>> morph that to a ?Cmd + C? command and should detect c itself.
>>>>> Also, ?Shift + ?? has no equivalent soft modification and can be taken
>>>>> as a shortcut. This has to be accounted for.
>>>>> 
>>>>> *Fix:*
>>>>> All required edge case scenarios for the soft modification of Shift and
>>>>> cases of valid modifiers were taken into account.
>>>>> 
>>>>> With Regards,
>>>>> Avik Niyogi
>>>> 
>>>> 
>>>> --
>>>> Best regards, Sergey.
>>> 
>> 
> 
> 
> -- 
> Best regards, Sergey.

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

From philip.race at oracle.com  Tue Apr 19 19:41:41 2016
From: philip.race at oracle.com (Phil Race)
Date: Tue, 19 Apr 2016 12:41:41 -0700 (PDT)
Subject: <Swing Dev> [9] Review request for 8154431: Allow source and
 target based validation for the focus transfer between two JComponents.
In-Reply-To: <57167357.2050705@oracle.com>
References: <57161922.8080808@oracle.com> <57166136.90205@oracle.com>
	<57167357.2050705@oracle.com>
Message-ID: <571689F5.6000401@oracle.com>

On 04/19/2016 11:05 AM, Semyon Sadetsky wrote:
> On 4/19/2016 7:47 PM, Phil Race wrote:
>> Hi,
>>
>> You are deprecating shouldYieldFocus(JComponent) and yet this class 
>> directly uses it.
>> Is this deprecation really the right thing to do ?
> Why is this not correct? There are plenty examples in JDK: 
> Component#setVisible() & Component#show(), Component#transferFocus() & 
> Component#nextFocus(), etc...
> This is necessary for backward compatibility.

My question is why deprecate it ?

So far as I can see unless some one wants to over-ride verifyTarget() 
they are
fine to continue over-riding this method and ignore the new one.

Leaving aside the merits of those previous changes, and at least one of 
those I think was dubious,
all you have done is at an @Deprecated annotation. There is no 
@deprecated javadoc tag, and you
have left doc which says when this method is called. In fact that doc is 
now very misleading.
It is not called. You call the new one.


BTW I see you mis-spell over-ridden as overriden in verifyTarget(..)

>>
>> The new over-loaded shouldYieldFocus() is perhaps not much more than 
>> a utility.
>> And the doc says "calls verify(input)" which seems odd since you do not
>> directly call it. And you are just describing what the default 
>> implementation
>> does aren't you ?
> This is also necessary for compatibility. There may be implementations 
> of the InputVerify where the shouldYieldFocus() is overloaded since it 
> is public (that was initial design mistake, I suppose). At the same 
> time the shouldYieldFocus() is the entry point that plugs InputVerify 
> into the JComponent.
> But you are correct "calls verify(input)" is not precisely describes 
> what happens in this method. Maybe just make it more indirect, like 
> "validate the source and the target components..."?

Now I am rather confused. You make it sound like verify() not 
shouldYieldFocus() is all the public
API should have contained, but you are adding a public over-load of it.
So why does this new method need to be public ? All you need is 
verifyTarget(), dont you ?

-phil.


>
> --Semyon
>>
>> -phil.
>>
>> On 04/19/2016 04:40 AM, Semyon Sadetsky wrote:
>>> Hello,
>>>
>>> Please review fix for JDK9:
>>> bug: https://bugs.openjdk.java.net/browse/JDK-8154431
>>> webrev: http://cr.openjdk.java.net/~ssadetsky/8154431/webrev.00/
>>>
>>> The thing is the Swing validation doesn't allow to validate state of 
>>> the target component of input focus transfer operation.
>>> To support that the fix adds two new methods verifyTarget(JComponent 
>>> target) and shouldYieldFocus(JComponent source, JComponent target) 
>>> to the javax.swing.InputVerifier class, and its old 
>>> shouldYieldFocus(JComponent input) is marked as deprecated.
>>> The solution guaranties full compatibility with previous JDK versions.
>>>
>>> --Semyon
>>>
>>
>

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

From semyon.sadetsky at oracle.com  Wed Apr 20 08:40:59 2016
From: semyon.sadetsky at oracle.com (Semyon Sadetsky)
Date: Wed, 20 Apr 2016 11:40:59 +0300
Subject: <Swing Dev> [9] Review request for 8154431: Allow source and
 target based validation for the focus transfer between two JComponents.
In-Reply-To: <571689F5.6000401@oracle.com>
References: <57161922.8080808@oracle.com> <57166136.90205@oracle.com>
	<57167357.2050705@oracle.com> <571689F5.6000401@oracle.com>
Message-ID: <5717409B.2070401@oracle.com>

On 4/19/2016 10:41 PM, Phil Race wrote:
> On 04/19/2016 11:05 AM, Semyon Sadetsky wrote:
>> On 4/19/2016 7:47 PM, Phil Race wrote:
>>> Hi,
>>>
>>> You are deprecating shouldYieldFocus(JComponent) and yet this class 
>>> directly uses it.
>>> Is this deprecation really the right thing to do ?
>> Why is this not correct? There are plenty examples in JDK: 
>> Component#setVisible() & Component#show(), Component#transferFocus() 
>> & Component#nextFocus(), etc...
>> This is necessary for backward compatibility.
>
> My question is why deprecate it ?
I can repeat my reply to your anther e-mail in this thread if you did 
not noticed it.

 > I deprecated shouldYieldFocus(JCopmponent) and added 
shouldYieldFocus(JCopmponent, JComponent). I cannot simply remove the 
first because
 > it's public and can be called from user code. But it's not used in 
JDK code outside this class anymore only internally for compatibility.
 > I can remove the @Depricated annotation but still cannot get why do 
we need to keep two overloaded shouldYieldFocus methods if only one is
 >  supposed to be used? That may confuse user which one of them to use, 
so @Depricated is a hint.
>
> So far as I can see unless some one wants to over-ride verifyTarget() 
> they are
> fine to continue over-riding this method and ignore the new one.
Yes, users may continue to use their old code after the fix. No changes 
required on user side. It seems that is what is the backward 
compatibility means.
>
> Leaving aside the merits of those previous changes, and at least one 
> of those I think was dubious,
> all you have done is at an @Deprecated annotation. There is no 
> @deprecated javadoc tag, and you
> have left doc which says when this method is called. In fact that doc 
> is now very misleading.
> It is not called. You call the new one.
Agreed. I will add @depricated to the method javadoc and ask user do not 
use it for the newly written code.
>
>
> BTW I see you mis-spell over-ridden as overriden in verifyTarget(..)
Just stats from JDK: 5 usages in comments of "over-riden" and more then 
300 "overriden"... Google Translate was spoiled :)

--Semyon
>
>>>
>>> The new over-loaded shouldYieldFocus() is perhaps not much more than 
>>> a utility.
>>> And the doc says "calls verify(input)" which seems odd since you do not
>>> directly call it. And you are just describing what the default 
>>> implementation
>>> does aren't you ?
>> This is also necessary for compatibility. There may be 
>> implementations of the InputVerify where the shouldYieldFocus() is 
>> overloaded since it is public (that was initial design mistake, I 
>> suppose). At the same time the shouldYieldFocus() is the entry point 
>> that plugs InputVerify into the JComponent.
>> But you are correct "calls verify(input)" is not precisely describes 
>> what happens in this method. Maybe just make it more indirect, like 
>> "validate the source and the target components..."?
>
> Now I am rather confused. You make it sound like verify() not 
> shouldYieldFocus() is all the public
> API should have contained, but you are adding a public over-load of it.
> So why does this new method need to be public ? All you need is 
> verifyTarget(), dont you ?
>
> -phil.
>
>
>>
>> --Semyon
>>>
>>> -phil.
>>>
>>> On 04/19/2016 04:40 AM, Semyon Sadetsky wrote:
>>>> Hello,
>>>>
>>>> Please review fix for JDK9:
>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8154431
>>>> webrev: http://cr.openjdk.java.net/~ssadetsky/8154431/webrev.00/
>>>>
>>>> The thing is the Swing validation doesn't allow to validate state 
>>>> of the target component of input focus transfer operation.
>>>> To support that the fix adds two new methods 
>>>> verifyTarget(JComponent target) and shouldYieldFocus(JComponent 
>>>> source, JComponent target) to the javax.swing.InputVerifier class, 
>>>> and its old shouldYieldFocus(JComponent input) is marked as 
>>>> deprecated.
>>>> The solution guaranties full compatibility with previous JDK versions.
>>>>
>>>> --Semyon
>>>>
>>>
>>
>

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

From alexandr.scherbatiy at oracle.com  Wed Apr 20 11:19:01 2016
From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy)
Date: Wed, 20 Apr 2016 15:19:01 +0400
Subject: <Swing Dev> RfR JDK-8076554,
 [macosx] Custom Swing text components need to allow standard
 accessibility
In-Reply-To: <5716A8A2.2060706@oracle.com>
References: <57158F03.1060708@oracle.com> <57162706.5050102@oracle.com>
	<571654C5.1020008@oracle.com> <57166924.4040301@oracle.com>
	<57166A5C.2010902@oracle.com> <57168171.8070207@oracle.com>
	<57168427.3080905@oracle.com> <5716A8A2.2060706@oracle.com>
Message-ID: <571765A5.4020302@oracle.com>


The fix looks good to me.

Thanks,
Alexandr.

On 20/04/16 01:52, Pete Brunet wrote:
> p.s. JPRT ran OK.
>
> Still need one more +1.
>
> On 4/19/16 2:16 PM, Phil Race wrote:
>> +1
>>
>> -phil.
>>
>> On 04/19/2016 12:05 PM, Pete Brunet wrote:
>>> New patch: http://cr.openjdk.java.net/~ptbrunet/JDK-8076554/webrev.03/
>>>
>>> Changes:
>>> - removed _AccessibleState
>>> - removed wildcard imports.
>>>
>>> Is this ready to push?
>>>
>>> Pete
>>>
>>> On 4/19/16 12:26 PM, Phil Race wrote:
>>>> oh one nit picky thing - can we get rid of the wild card imports ?
>>>>
>>>> -phil.
>>>>
>>>> On 04/19/2016 10:21 AM, Phil Race wrote:
>>>>> Which seems to imply the _AccessibleState subclass has been 
>>>>> obsolete since 1.5
>>>>> Although when these tools were unbundled it perhaps could not 
>>>>> assume 1.5.
>>>>>
>>>>> The rest of the changes look fine and it is a lot simpler than the 
>>>>> v0 ..
>>>>>
>>>>> -phil.
>>>>>
>>>>> On 04/19/2016 08:54 AM, Pete Brunet wrote:
>>>>>> Thanks for noticing that Alexandr.  I see this state was added in 
>>>>>> 1.5 and apparently the code from which I borrowed this from was 
>>>>>> never updated.  I will remove that and open a bug to remove that 
>>>>>> from the original. -Pete
>>>>>>
>>>>>> On 4/19/16 7:39 AM, Alexander Scherbatiy wrote:
>>>>>>> On 19/04/16 05:50, Pete Brunet wrote:
>>>>>>>> Please review the following patch.
>>>>>>>>
>>>>>>>> Bug:https://bugs.openjdk.java.net/browse/JDK-8076554
>>>>>>>> Patch:http://cr.openjdk.java.net/~ptbrunet/JDK-8076554/webrev.02/
>>>>>>>>
>>>>>>>> The problem is that the code is currently hardcoded to only support text
>>>>>>>> accessibility for JTextComponent using the DocumentListener,
>>>>>>>> CaretListener interfaces.  This eliminates the ability to provide
>>>>>>>> accessibility for a custom text components.  The resolution is to remove
>>>>>>>> the JTextComponent gate and use the PropertyChangeListener listener
>>>>>>>> interface with its ACCESSIBLE_CARET_PROPERTY and
>>>>>>>> ACCESSIBLE_TEXT_PROPERTY properties.
>>>>>>>   The AccessibleState class already has the MANAGES_DESCENDANTS 
>>>>>>> constant. What is purpose to add a constant with the same name 
>>>>>>> to the _AccessibleState?
>>>>>>>
>>>>>>>   Thanks,
>>>>>>>   Alexandr.
>>>>>>>> I tested this with the two test cases which can be found at
>>>>>>>> http://cr.openjdk.java.net/~ptbrunet/JDK-8076554/test/
>>>>>>>> running them side by side with VoiceOver.
>>>>>>>>
>>>>>>>> Note that I will fix the similar JProgressBar and JSlider restrictions
>>>>>>>> in JDK-8154507 and JDK-8154508 respectively.
>>>>>>>>
>>>>>>>> Pete
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>

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

From Sergey.Bylokhov at oracle.com  Wed Apr 20 15:20:10 2016
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Wed, 20 Apr 2016 18:20:10 +0300
Subject: <Swing Dev> RfR JDK-8076554,
 [macosx] Custom Swing text components need to allow standard
 accessibility
In-Reply-To: <57168427.3080905@oracle.com>
References: <57158F03.1060708@oracle.com> <57162706.5050102@oracle.com>
	<571654C5.1020008@oracle.com> <57166924.4040301@oracle.com>
	<57166A5C.2010902@oracle.com> <57168171.8070207@oracle.com>
	<57168427.3080905@oracle.com>
Message-ID: <57179E2A.8070605@oracle.com>

Hi, Pete.
Just a small notes:
  - It seems that AXTextChangeNotifier() should be created only if "c is 
Accessible".
  - I am not sure, but when we clear these listeners(which were added to 
AccessibilityEventMonitor), or it is not necessary?
  - Is it possible that "AccessibleContext.ACCESSIBLE_TEXT_PROPERTY" 
will be fired by JProgressBar or JSlider, if yes then we will get double 
notification(one from AXTextChangeNotifier and one from 
AXProgressChangeNotifier).

On 19.04.16 22:16, Phil Race wrote:
> +1
>
> -phil.
>
> On 04/19/2016 12:05 PM, Pete Brunet wrote:
>> New patch: http://cr.openjdk.java.net/~ptbrunet/JDK-8076554/webrev.03/
>>
>> Changes:
>> - removed _AccessibleState
>> - removed wildcard imports.
>>
>> Is this ready to push?
>>
>> Pete
>>
>> On 4/19/16 12:26 PM, Phil Race wrote:
>>> oh one nit picky thing - can we get rid of the wild card imports ?
>>>
>>> -phil.
>>>
>>> On 04/19/2016 10:21 AM, Phil Race wrote:
>>>> Which seems to imply the _AccessibleState subclass has been obsolete
>>>> since 1.5
>>>> Although when these tools were unbundled it perhaps could not assume
>>>> 1.5.
>>>>
>>>> The rest of the changes look fine and it is a lot simpler than the v0 ..
>>>>
>>>> -phil.
>>>>
>>>> On 04/19/2016 08:54 AM, Pete Brunet wrote:
>>>>> Thanks for noticing that Alexandr.  I see this state was added in
>>>>> 1.5 and apparently the code from which I borrowed this from was
>>>>> never updated.  I will remove that and open a bug to remove that
>>>>> from the original.  -Pete
>>>>>
>>>>> On 4/19/16 7:39 AM, Alexander Scherbatiy wrote:
>>>>>> On 19/04/16 05:50, Pete Brunet wrote:
>>>>>>> Please review the following patch.
>>>>>>>
>>>>>>> Bug:https://bugs.openjdk.java.net/browse/JDK-8076554
>>>>>>> Patch:http://cr.openjdk.java.net/~ptbrunet/JDK-8076554/webrev.02/
>>>>>>>
>>>>>>> The problem is that the code is currently hardcoded to only support text
>>>>>>> accessibility for JTextComponent using the DocumentListener,
>>>>>>> CaretListener interfaces.  This eliminates the ability to provide
>>>>>>> accessibility for a custom text components.  The resolution is to remove
>>>>>>> the JTextComponent gate and use the PropertyChangeListener listener
>>>>>>> interface with its ACCESSIBLE_CARET_PROPERTY and
>>>>>>> ACCESSIBLE_TEXT_PROPERTY properties.
>>>>>>   The AccessibleState class already has the MANAGES_DESCENDANTS
>>>>>> constant. What is purpose to add a constant with the same name to
>>>>>> the _AccessibleState?
>>>>>>
>>>>>>   Thanks,
>>>>>>   Alexandr.
>>>>>>> I tested this with the two test cases which can be found at
>>>>>>> http://cr.openjdk.java.net/~ptbrunet/JDK-8076554/test/
>>>>>>> running them side by side with VoiceOver.
>>>>>>>
>>>>>>> Note that I will fix the similar JProgressBar and JSlider restrictions
>>>>>>> in JDK-8154507 and JDK-8154508 respectively.
>>>>>>>
>>>>>>> Pete
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>


-- 
Best regards, Sergey.


From peter.brunet at oracle.com  Wed Apr 20 23:10:12 2016
From: peter.brunet at oracle.com (Pete Brunet)
Date: Wed, 20 Apr 2016 18:10:12 -0500
Subject: <Swing Dev> RfR JDK-8076554,
 [macosx] Custom Swing text components need to allow standard
 accessibility
In-Reply-To: <57179E2A.8070605@oracle.com>
References: <57158F03.1060708@oracle.com> <57162706.5050102@oracle.com>
	<571654C5.1020008@oracle.com> <57166924.4040301@oracle.com>
	<57166A5C.2010902@oracle.com> <57168171.8070207@oracle.com>
	<57168427.3080905@oracle.com> <57179E2A.8070605@oracle.com>
Message-ID: <57180C54.3030507@oracle.com>

Hi Sergey, I already pushed the fix but ...

On 4/20/16 10:20 AM, Sergey Bylokhov wrote:
> Hi, Pete.
> Just a small notes:
>  - It seems that AXTextChangeNotifier() should be created only if "c
> is Accessible".
That's true.  I added a comment to 8154507/8 and will fix that with one
of those patches.
>  - I am not sure, but when we clear these listeners(which were added
> to AccessibilityEventMonitor), or it is not necessary?
I didn't see a removal mechanism in the current code so I didn't do
that.  If VO is not active I assume the allocations won't happen.  If
someone start/stops VO I agree there would be a unused code in memory,
but I suspect there is no means to unallocate/disable all the a11y
support.  I will check at Apple to see if anyone knows.  Other than for
testers this would be an unusual scenario.
>  - Is it possible that "AccessibleContext.ACCESSIBLE_TEXT_PROPERTY"
> will be fired by JProgressBar or JSlider, if yes then we will get
> double notification(one from AXTextChangeNotifier and one from
> AXProgressChangeNotifier).
I'll need to look into this more when I work on 8154507/8.  I added your
comments to those bugs.

Pete
>
> On 19.04.16 22:16, Phil Race wrote:
>> +1
>>
>> -phil.
>>
>> On 04/19/2016 12:05 PM, Pete Brunet wrote:
>>> New patch: http://cr.openjdk.java.net/~ptbrunet/JDK-8076554/webrev.03/
>>>
>>> Changes:
>>> - removed _AccessibleState
>>> - removed wildcard imports.
>>>
>>> Is this ready to push?
>>>
>>> Pete
>>>
>>> On 4/19/16 12:26 PM, Phil Race wrote:
>>>> oh one nit picky thing - can we get rid of the wild card imports ?
>>>>
>>>> -phil.
>>>>
>>>> On 04/19/2016 10:21 AM, Phil Race wrote:
>>>>> Which seems to imply the _AccessibleState subclass has been obsolete
>>>>> since 1.5
>>>>> Although when these tools were unbundled it perhaps could not assume
>>>>> 1.5.
>>>>>
>>>>> The rest of the changes look fine and it is a lot simpler than the
>>>>> v0 ..
>>>>>
>>>>> -phil.
>>>>>
>>>>> On 04/19/2016 08:54 AM, Pete Brunet wrote:
>>>>>> Thanks for noticing that Alexandr.  I see this state was added in
>>>>>> 1.5 and apparently the code from which I borrowed this from was
>>>>>> never updated.  I will remove that and open a bug to remove that
>>>>>> from the original.  -Pete
>>>>>>
>>>>>> On 4/19/16 7:39 AM, Alexander Scherbatiy wrote:
>>>>>>> On 19/04/16 05:50, Pete Brunet wrote:
>>>>>>>> Please review the following patch.
>>>>>>>>
>>>>>>>> Bug:https://bugs.openjdk.java.net/browse/JDK-8076554
>>>>>>>> Patch:http://cr.openjdk.java.net/~ptbrunet/JDK-8076554/webrev.02/
>>>>>>>>
>>>>>>>> The problem is that the code is currently hardcoded to only
>>>>>>>> support text
>>>>>>>> accessibility for JTextComponent using the DocumentListener,
>>>>>>>> CaretListener interfaces.  This eliminates the ability to provide
>>>>>>>> accessibility for a custom text components.  The resolution is
>>>>>>>> to remove
>>>>>>>> the JTextComponent gate and use the PropertyChangeListener
>>>>>>>> listener
>>>>>>>> interface with its ACCESSIBLE_CARET_PROPERTY and
>>>>>>>> ACCESSIBLE_TEXT_PROPERTY properties.
>>>>>>>   The AccessibleState class already has the MANAGES_DESCENDANTS
>>>>>>> constant. What is purpose to add a constant with the same name to
>>>>>>> the _AccessibleState?
>>>>>>>
>>>>>>>   Thanks,
>>>>>>>   Alexandr.
>>>>>>>> I tested this with the two test cases which can be found at
>>>>>>>> http://cr.openjdk.java.net/~ptbrunet/JDK-8076554/test/
>>>>>>>> running them side by side with VoiceOver.
>>>>>>>>
>>>>>>>> Note that I will fix the similar JProgressBar and JSlider
>>>>>>>> restrictions
>>>>>>>> in JDK-8154507 and JDK-8154508 respectively.
>>>>>>>>
>>>>>>>> Pete
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>
>



From manajit.halder at oracle.com  Thu Apr 21 09:52:45 2016
From: manajit.halder at oracle.com (Manajit Halder)
Date: Thu, 21 Apr 2016 15:22:45 +0530
Subject: <Swing Dev> Review Request of 8152492: [macosx swing] double
	key event actions when using Mac menubar
In-Reply-To: <4CC47F90-5269-40C8-82CA-5DC3B41713AB@oracle.com>
References: <350CB937-DB61-46D9-A456-47D337E4788A@oracle.com>
	<5707C409.4030702@oracle.com>
	<123F5EB3-DD71-4706-A9F2-217F8B29BEF7@oracle.com>
	<9D087362-41B8-46F3-8A6C-E47D9186723C@oracle.com>
	<571626CA.4050504@oracle.com>
	<4CC47F90-5269-40C8-82CA-5DC3B41713AB@oracle.com>
Message-ID: <AC0E0B3F-6DEC-427D-8EFD-1249D4FC5B61@oracle.com>

Hi Avik,

Changes looks good to me.

Regards,
Manajit

> On 20-Apr-2016, at 11:37 am, Avik Niyogi <avik.niyogi at oracle.com> wrote:
> 
> Hi All,
> I have added some comments and made some minor tweaks as per the inputs received.
> Please review my code changes as available at this link below:
> 
> http://cr.openjdk.java.net/~aniyogi/8152492/webrev.02/ <http://cr.openjdk.java.net/~aniyogi/8152492/webrev.02/>
> 
> With Regards,
> Avik Niyogi
> 
>> On 19-Apr-2016, at 6:08 pm, Sergey Bylokhov <Sergey.Bylokhov at oracle.com <mailto:Sergey.Bylokhov at oracle.com>> wrote:
>> 
>> On 19.04.16 11:46, Avik Niyogi wrote:
>>> Hi All,
>>> Please review my code changes with inputs received:
>> 
>> Can you please add some description of your changes, it seems you removed all code which was added by you previously.
>> 
>>> http://cr.openjdk.java.net/~aniyogi/8152492/webrev.01/ <http://cr.openjdk.java.net/~aniyogi/8152492/webrev.01/>
>>> 
>>> With Regards,
>>> Avik Niyogi
>>>> On 19-Apr-2016, at 11:47 am, Avik Niyogi <avik.niyogi at oracle.com <mailto:avik.niyogi at oracle.com>
>>>> <mailto:avik.niyogi at oracle.com <mailto:avik.niyogi at oracle.com>>> wrote:
>>>> 
>>>> Hi Sergey,
>>>> I have tried all these Input sources:
>>>> <Screen Shot 2016-04-19 at 11.40.33 am.png>
>>>> I am unable to reproduce the test failure as mentioned by you with
>>>> these inputs. Please provide some screenshots and/or details of the
>>>> procedure used for this test failure.
>>>> Thank you in advance.
>>>> 
>>>> With Regards,
>>>> Avik Niyogi
>>>> 
>>>>> On 08-Apr-2016, at 8:15 pm, Sergey Bylokhov
>>>>> <Sergey.Bylokhov at oracle.com <mailto:Sergey.Bylokhov at oracle.com> <mailto:Sergey.Bylokhov at oracle.com <mailto:Sergey.Bylokhov at oracle.com>>> wrote:
>>>>> 
>>>>> Hi, Avik.
>>>>> It seems there is one more bug in this "if".
>>>>> Change the input source to "Hindi Dev.."/"Russian.." then this test
>>>>> fails anyway(it will produce the double action).
>>>>> Moreover if I change the source input to Hindi Transliteration, the
>>>>> test sometimes crashed.
>>>>> Please double check.
>>>>> 
>>>>> On 06.04.16 13:42, Avik Niyogi wrote:
>>>>>> Hi All,
>>>>>> 
>>>>>> Kindly review the bug fix for JDK 9.
>>>>>> 
>>>>>> *Bug:*
>>>>>> https://bugs.openjdk.java.net/browse/JDK-8152492 <https://bugs.openjdk.java.net/browse/JDK-8152492>
>>>>>> 
>>>>>> *Webrev:*
>>>>>> http://cr.openjdk.java.net/~aniyogi/8152492/webrev.00/
>>>>>> 
>>>>>> *Issue:*
>>>>>> For OSX, having there is provision of non-integrated menubar. for this
>>>>>> case, triggering the menu action by key press triggered double action in
>>>>>> some cases
>>>>>> 
>>>>>> *Cause:*
>>>>>> Due to the use of Shift modifier being a soft modifier in case of mac.
>>>>>> For example ?Shift + m? is actually ?M? and ?Shift + ,? is ?<? .
>>>>>> So such cases can not be used as shortcuts. This needs to be
>>>>>> accounted for.
>>>>>> Also, cases where ?Cmd + Shift + c? is used as a shortcut, it should not
>>>>>> morph that to a ?Cmd + C? command and should detect c itself.
>>>>>> Also, ?Shift + ?? has no equivalent soft modification and can be taken
>>>>>> as a shortcut. This has to be accounted for.
>>>>>> 
>>>>>> *Fix:*
>>>>>> All required edge case scenarios for the soft modification of Shift and
>>>>>> cases of valid modifiers were taken into account.
>>>>>> 
>>>>>> With Regards,
>>>>>> Avik Niyogi
>>>>> 
>>>>> 
>>>>> --
>>>>> Best regards, Sergey.
>>>> 
>>> 
>> 
>> 
>> -- 
>> Best regards, Sergey.
> 

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

From semyon.sadetsky at oracle.com  Thu Apr 21 13:22:37 2016
From: semyon.sadetsky at oracle.com (Semyon Sadetsky)
Date: Thu, 21 Apr 2016 16:22:37 +0300
Subject: <Swing Dev> [9] Review request for 8046031: UI of Java Web Start
 app isn't updated when changing Windows theme
Message-ID: <5718D41D.7090104@oracle.com>

Hello,

Please review fix for JDK9:

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

Under the Windoew LnF when the native Windows theme is changed some java 
frames remains unchanged if there are several application contexts. The 
thing is the DesktopProperty#updatePending flag that prevents to run 
more then one UI update operation is shared between different 
applications contexts while they may be updated with the property change 
concurrently from different EDT threads so they may loose the update.
To avoid this mutual interference the updatePending is moved from the 
global to the application context scope.
The test would require to write native code so the issue is labeled 
noreg-hard.

--Semyon


From alexandr.scherbatiy at oracle.com  Thu Apr 21 13:56:01 2016
From: alexandr.scherbatiy at oracle.com (Alexandr Scherbatiy)
Date: Thu, 21 Apr 2016 06:56:01 -0700
Subject: <Swing Dev> [9] Review request for 8046031: UI of Java Web
 Start app isn't updated when changing Windows theme
In-Reply-To: <5718D41D.7090104@oracle.com>
References: <5718D41D.7090104@oracle.com>
Message-ID: <5718DBF1.7090407@oracle.com>


  The fix looks good to me.

  Thanks,
  Alexandr.

On 4/21/2016 6:22 AM, Semyon Sadetsky wrote:
> Hello,
>
> Please review fix for JDK9:
>
> bug: https://bugs.openjdk.java.net/browse/JDK-8046031
> webrev: http://cr.openjdk.java.net/~ssadetsky/8046031/webrev.00/
>
> Under the Windoew LnF when the native Windows theme is changed some 
> java frames remains unchanged if there are several application 
> contexts. The thing is the DesktopProperty#updatePending flag that 
> prevents to run more then one UI update operation is shared between 
> different applications contexts while they may be updated with the 
> property change concurrently from different EDT threads so they may 
> loose the update.
> To avoid this mutual interference the updatePending is moved from the 
> global to the application context scope.
> The test would require to write native code so the issue is labeled 
> noreg-hard.
>
> --Semyon



From Sergey.Bylokhov at oracle.com  Thu Apr 21 19:46:33 2016
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Thu, 21 Apr 2016 22:46:33 +0300
Subject: <Swing Dev> [9] Review request for 8046031: UI of Java Web
 Start app isn't updated when changing Windows theme
In-Reply-To: <5718DBF1.7090407@oracle.com>
References: <5718D41D.7090104@oracle.com> <5718DBF1.7090407@oracle.com>
Message-ID: <57192E19.40107@oracle.com>

Hi, Semyon.
As far as I understand from the bug description, the method 
DesktopProperty.updateUI() is called on the different EDT? Does it mean 
that we share the same DesktopProperty object across different 
Appcontext? (if not then probably we can skip the usage of Appcontext 
and change the field to non-static)?
If the Appcontext is necessary, then we should not use interned string 
as a key, I suggest to use the simple new Object(), so it will not be 
accessible outside of this class.

On 21.04.16 16:56, Alexandr Scherbatiy wrote:
>
>   The fix looks good to me.
>
>   Thanks,
>   Alexandr.
>
> On 4/21/2016 6:22 AM, Semyon Sadetsky wrote:
>> Hello,
>>
>> Please review fix for JDK9:
>>
>> bug: https://bugs.openjdk.java.net/browse/JDK-8046031
>> webrev: http://cr.openjdk.java.net/~ssadetsky/8046031/webrev.00/
>>
>> Under the Windoew LnF when the native Windows theme is changed some
>> java frames remains unchanged if there are several application
>> contexts. The thing is the DesktopProperty#updatePending flag that
>> prevents to run more then one UI update operation is shared between
>> different applications contexts while they may be updated with the
>> property change concurrently from different EDT threads so they may
>> loose the update.
>> To avoid this mutual interference the updatePending is moved from the
>> global to the application context scope.
>> The test would require to write native code so the issue is labeled
>> noreg-hard.
>>
>> --Semyon
>


-- 
Best regards, Sergey.


From semyon.sadetsky at oracle.com  Fri Apr 22 08:08:59 2016
From: semyon.sadetsky at oracle.com (Semyon Sadetsky)
Date: Fri, 22 Apr 2016 11:08:59 +0300
Subject: <Swing Dev> [9] Review request for 8154431: Allow source and
 target based validation for the focus transfer between two JComponents.
In-Reply-To: <5717409B.2070401@oracle.com>
References: <57161922.8080808@oracle.com> <57166136.90205@oracle.com>
	<57167357.2050705@oracle.com> <571689F5.6000401@oracle.com>
	<5717409B.2070401@oracle.com>
Message-ID: <5719DC1B.8000907@oracle.com>

Please review the updated webrev:
The fix is updated according to the reviewers comments:

- the test was updated to check the target object and year typo was updated
- new shouldYieldFocus() javadoc improved
- @depricated documentation is added to the old shouldYieldFocus()
- Swing component emphasized in the class javadoc

--Semyon

On 4/20/2016 11:40 AM, Semyon Sadetsky wrote:
> On 4/19/2016 10:41 PM, Phil Race wrote:
>> On 04/19/2016 11:05 AM, Semyon Sadetsky wrote:
>>> On 4/19/2016 7:47 PM, Phil Race wrote:
>>>> Hi,
>>>>
>>>> You are deprecating shouldYieldFocus(JComponent) and yet this class 
>>>> directly uses it.
>>>> Is this deprecation really the right thing to do ?
>>> Why is this not correct? There are plenty examples in JDK: 
>>> Component#setVisible() & Component#show(), Component#transferFocus() 
>>> & Component#nextFocus(), etc...
>>> This is necessary for backward compatibility.
>>
>> My question is why deprecate it ?
> I can repeat my reply to your anther e-mail in this thread if you did 
> not noticed it.
>
> > I deprecated shouldYieldFocus(JCopmponent) and added 
> shouldYieldFocus(JCopmponent, JComponent). I cannot simply remove the 
> first because
> > it's public and can be called from user code. But it's not used in 
> JDK code outside this class anymore only internally for compatibility.
> > I can remove the @Depricated annotation but still cannot get why do 
> we need to keep two overloaded shouldYieldFocus methods if only one is
> >  supposed to be used? That may confuse user which one of them to 
> use, so @Depricated is a hint.
>>
>> So far as I can see unless some one wants to over-ride verifyTarget() 
>> they are
>> fine to continue over-riding this method and ignore the new one.
> Yes, users may continue to use their old code after the fix. No 
> changes required on user side. It seems that is what is the backward 
> compatibility means.
>>
>> Leaving aside the merits of those previous changes, and at least one 
>> of those I think was dubious,
>> all you have done is at an @Deprecated annotation. There is no 
>> @deprecated javadoc tag, and you
>> have left doc which says when this method is called. In fact that doc 
>> is now very misleading.
>> It is not called. You call the new one.
> Agreed. I will add @depricated to the method javadoc and ask user do 
> not use it for the newly written code.
>>
>>
>> BTW I see you mis-spell over-ridden as overriden in verifyTarget(..)
> Just stats from JDK: 5 usages in comments of "over-riden" and more 
> then 300 "overriden"... Google Translate was spoiled :)
>
> --Semyon
>>
>>>>
>>>> The new over-loaded shouldYieldFocus() is perhaps not much more 
>>>> than a utility.
>>>> And the doc says "calls verify(input)" which seems odd since you do not
>>>> directly call it. And you are just describing what the default 
>>>> implementation
>>>> does aren't you ?
>>> This is also necessary for compatibility. There may be 
>>> implementations of the InputVerify where the shouldYieldFocus() is 
>>> overloaded since it is public (that was initial design mistake, I 
>>> suppose). At the same time the shouldYieldFocus() is the entry point 
>>> that plugs InputVerify into the JComponent.
>>> But you are correct "calls verify(input)" is not precisely describes 
>>> what happens in this method. Maybe just make it more indirect, like 
>>> "validate the source and the target components..."?
>>
>> Now I am rather confused. You make it sound like verify() not 
>> shouldYieldFocus() is all the public
>> API should have contained, but you are adding a public over-load of it.
>> So why does this new method need to be public ? All you need is 
>> verifyTarget(), dont you ?
>>
>> -phil.
>>
>>
>>>
>>> --Semyon
>>>>
>>>> -phil.
>>>>
>>>> On 04/19/2016 04:40 AM, Semyon Sadetsky wrote:
>>>>> Hello,
>>>>>
>>>>> Please review fix for JDK9:
>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8154431
>>>>> webrev: http://cr.openjdk.java.net/~ssadetsky/8154431/webrev.00/
>>>>>
>>>>> The thing is the Swing validation doesn't allow to validate state 
>>>>> of the target component of input focus transfer operation.
>>>>> To support that the fix adds two new methods 
>>>>> verifyTarget(JComponent target) and shouldYieldFocus(JComponent 
>>>>> source, JComponent target) to the javax.swing.InputVerifier class, 
>>>>> and its old shouldYieldFocus(JComponent input) is marked as 
>>>>> deprecated.
>>>>> The solution guaranties full compatibility with previous JDK versions.
>>>>>
>>>>> --Semyon
>>>>>
>>>>
>>>
>>
>

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

From semyon.sadetsky at oracle.com  Fri Apr 22 08:11:27 2016
From: semyon.sadetsky at oracle.com (Semyon Sadetsky)
Date: Fri, 22 Apr 2016 11:11:27 +0300
Subject: <Swing Dev> [9] Review request for 8154431: Allow source and
 target based validation for the focus transfer between two JComponents.
In-Reply-To: <5719DC1B.8000907@oracle.com>
References: <57161922.8080808@oracle.com> <57166136.90205@oracle.com>
	<57167357.2050705@oracle.com> <571689F5.6000401@oracle.com>
	<5717409B.2070401@oracle.com> <5719DC1B.8000907@oracle.com>
Message-ID: <5719DCAF.4080803@oracle.com>

Forget to attach the link: 
http://cr.openjdk.java.net/~ssadetsky/8154431/webrev.01/

--Semyon

On 4/22/2016 11:08 AM, Semyon Sadetsky wrote:
> Please review the updated webrev:
> The fix is updated according to the reviewers comments:
>
> - the test was updated to check the target object and year typo was 
> updated
> - new shouldYieldFocus() javadoc improved
> - @depricated documentation is added to the old shouldYieldFocus()
> - Swing component emphasized in the class javadoc
>
> --Semyon
>
> On 4/20/2016 11:40 AM, Semyon Sadetsky wrote:
>> On 4/19/2016 10:41 PM, Phil Race wrote:
>>> On 04/19/2016 11:05 AM, Semyon Sadetsky wrote:
>>>> On 4/19/2016 7:47 PM, Phil Race wrote:
>>>>> Hi,
>>>>>
>>>>> You are deprecating shouldYieldFocus(JComponent) and yet this 
>>>>> class directly uses it.
>>>>> Is this deprecation really the right thing to do ?
>>>> Why is this not correct? There are plenty examples in JDK: 
>>>> Component#setVisible() & Component#show(), 
>>>> Component#transferFocus() & Component#nextFocus(), etc...
>>>> This is necessary for backward compatibility.
>>>
>>> My question is why deprecate it ?
>> I can repeat my reply to your anther e-mail in this thread if you did 
>> not noticed it.
>>
>> > I deprecated shouldYieldFocus(JCopmponent) and added 
>> shouldYieldFocus(JCopmponent, JComponent). I cannot simply remove the 
>> first because
>> > it's public and can be called from user code. But it's not used in 
>> JDK code outside this class anymore only internally for compatibility.
>> > I can remove the @Depricated annotation but still cannot get why do 
>> we need to keep two overloaded shouldYieldFocus methods if only one is
>> >  supposed to be used? That may confuse user which one of them to 
>> use, so @Depricated is a hint.
>>>
>>> So far as I can see unless some one wants to over-ride 
>>> verifyTarget() they are
>>> fine to continue over-riding this method and ignore the new one.
>> Yes, users may continue to use their old code after the fix. No 
>> changes required on user side. It seems that is what is the backward 
>> compatibility means.
>>>
>>> Leaving aside the merits of those previous changes, and at least one 
>>> of those I think was dubious,
>>> all you have done is at an @Deprecated annotation. There is no 
>>> @deprecated javadoc tag, and you
>>> have left doc which says when this method is called. In fact that 
>>> doc is now very misleading.
>>> It is not called. You call the new one.
>> Agreed. I will add @depricated to the method javadoc and ask user do 
>> not use it for the newly written code.
>>>
>>>
>>> BTW I see you mis-spell over-ridden as overriden in verifyTarget(..)
>> Just stats from JDK: 5 usages in comments of "over-riden" and more 
>> then 300 "overriden"... Google Translate was spoiled :)
>>
>> --Semyon
>>>
>>>>>
>>>>> The new over-loaded shouldYieldFocus() is perhaps not much more 
>>>>> than a utility.
>>>>> And the doc says "calls verify(input)" which seems odd since you 
>>>>> do not
>>>>> directly call it. And you are just describing what the default 
>>>>> implementation
>>>>> does aren't you ?
>>>> This is also necessary for compatibility. There may be 
>>>> implementations of the InputVerify where the shouldYieldFocus() is 
>>>> overloaded since it is public (that was initial design mistake, I 
>>>> suppose). At the same time the shouldYieldFocus() is the entry 
>>>> point that plugs InputVerify into the JComponent.
>>>> But you are correct "calls verify(input)" is not precisely 
>>>> describes what happens in this method. Maybe just make it more 
>>>> indirect, like "validate the source and the target components..."?
>>>
>>> Now I am rather confused. You make it sound like verify() not 
>>> shouldYieldFocus() is all the public
>>> API should have contained, but you are adding a public over-load of it.
>>> So why does this new method need to be public ? All you need is 
>>> verifyTarget(), dont you ?
>>>
>>> -phil.
>>>
>>>
>>>>
>>>> --Semyon
>>>>>
>>>>> -phil.
>>>>>
>>>>> On 04/19/2016 04:40 AM, Semyon Sadetsky wrote:
>>>>>> Hello,
>>>>>>
>>>>>> Please review fix for JDK9:
>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8154431
>>>>>> webrev: http://cr.openjdk.java.net/~ssadetsky/8154431/webrev.00/
>>>>>>
>>>>>> The thing is the Swing validation doesn't allow to validate state 
>>>>>> of the target component of input focus transfer operation.
>>>>>> To support that the fix adds two new methods 
>>>>>> verifyTarget(JComponent target) and shouldYieldFocus(JComponent 
>>>>>> source, JComponent target) to the javax.swing.InputVerifier 
>>>>>> class, and its old shouldYieldFocus(JComponent input) is marked 
>>>>>> as deprecated.
>>>>>> The solution guaranties full compatibility with previous JDK 
>>>>>> versions.
>>>>>>
>>>>>> --Semyon
>>>>>>
>>>>>
>>>>
>>>
>>
>

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

From semyon.sadetsky at oracle.com  Fri Apr 22 16:29:06 2016
From: semyon.sadetsky at oracle.com (Semyon Sadetsky)
Date: Fri, 22 Apr 2016 19:29:06 +0300
Subject: <Swing Dev> [9] Review request for 8046031: UI of Java Web
 Start app isn't updated when changing Windows theme
In-Reply-To: <57192E19.40107@oracle.com>
References: <5718D41D.7090104@oracle.com> <5718DBF1.7090407@oracle.com>
	<57192E19.40107@oracle.com>
Message-ID: <571A5152.2050907@oracle.com>



On 4/21/2016 10:46 PM, Sergey Bylokhov wrote:
> Hi, Semyon.
> As far as I understand from the bug description, the method 
> DesktopProperty.updateUI() is called on the different EDT? Does it 
> mean that we share the same DesktopProperty object across different 
> Appcontext? (if not then probably we can skip the usage of Appcontext 
> and change the field to non-static)?
No, we do not share the same DesktopProperty object, but it would be odd 
to expect that there is only one DesktopProperty per app context. 
Putting the flag into the app scope protects from scheduling events 
recursively
> If the Appcontext is necessary, then we should not use interned string 
> as a key, I suggest to use the simple new Object(), so it will not be 
> accessible outside of this class.
This is a public field. Accessing it outside the class shouldn't be an 
issue.

--Semyon
>
> On 21.04.16 16:56, Alexandr Scherbatiy wrote:
>>
>>   The fix looks good to me.
>>
>>   Thanks,
>>   Alexandr.
>>
>> On 4/21/2016 6:22 AM, Semyon Sadetsky wrote:
>>> Hello,
>>>
>>> Please review fix for JDK9:
>>>
>>> bug: https://bugs.openjdk.java.net/browse/JDK-8046031
>>> webrev: http://cr.openjdk.java.net/~ssadetsky/8046031/webrev.00/
>>>
>>> Under the Windoew LnF when the native Windows theme is changed some
>>> java frames remains unchanged if there are several application
>>> contexts. The thing is the DesktopProperty#updatePending flag that
>>> prevents to run more then one UI update operation is shared between
>>> different applications contexts while they may be updated with the
>>> property change concurrently from different EDT threads so they may
>>> loose the update.
>>> To avoid this mutual interference the updatePending is moved from the
>>> global to the application context scope.
>>> The test would require to write native code so the issue is labeled
>>> noreg-hard.
>>>
>>> --Semyon
>>
>
>



From philip.race at oracle.com  Fri Apr 22 18:06:40 2016
From: philip.race at oracle.com (Phil Race)
Date: Fri, 22 Apr 2016 11:06:40 -0700
Subject: <Swing Dev> RFR 8154213: clean up uses of boxed primitive
 constructors in the java.desktop module
Message-ID: <571A6830.5090108@oracle.com>

Bug: https://bugs.openjdk.java.net/browse/JDK-8154213
Webrev: http://cr.openjdk.java.net/~prr/8154213/

https://bugs.openjdk.java.net/browse/JDK-8145468 has caused
the following constructors usages to be deprecated :
new Long(long) and new Integer(String)
new Integer(int) and new Integer(String)
new Float(int) and new Float(String)
new Double(int) and new Double(String)
new Character(char)

The deprecations warnings were suppressed for the java.desktop module.

This fix changes all uses in the java.desktop module to use Foo.valueOf(..)
or in a few cases where we directly assign to a variable use auto-boxing.

Additionally doc comments that use constructors were updated.

Finally the deprecation suppression was removed.

JPRT has been used to verify the build and I have run through the
various affected Swing L&Fs using SwingSet as a sanity check.

I do not have any information on the performance difference (benefits or 
otherwise)
of this change but I did not see any usage in java.desktop that appears 
to be
remotely performance critical.

-phil.



From philip.race at oracle.com  Fri Apr 22 19:41:24 2016
From: philip.race at oracle.com (Phil Race)
Date: Fri, 22 Apr 2016 12:41:24 -0700
Subject: <Swing Dev> Review-request for 8145547: JEP 283: [AWT/Swing]
 Conditional support for GTK 3 on Linux
In-Reply-To: <570B56FE.20109@oracle.com>
References: <56DB4C3B.1060902@oracle.com> <56E864DE.4000706@oracle.com>
	<56E99D68.90208@oracle.com> <56EA9929.9020605@oracle.com>
	<56EBF688.1090006@oracle.com> <56ED7507.1090204@oracle.com>
	<56EFF685.1090702@oracle.com> <56EFFC8A.1010306@oracle.com>
	<56F044BF.2000609@oracle.com> <56F0498A.4090802@oracle.com>
	<56F04BBD.1030102@oracle.com> <56F051FD.3000203@oracle.com>
	<56F05BB5.2080209@oracle.com> <57078C9E.2080409@oracle.com>
	<570B56FE.20109@oracle.com>
Message-ID: <571A7E64.2060609@oracle.com>

Hi Semyon,

I think we can/should quickly fix the new ordinal() usage and file a 
separate bug for the GTKEngine usage.

We can table (defer) changes for the potential hang as long as we file a 
JIRA to investigate.

Then we can get the JEP in sooner rather than later (Monday!)

-phil.


On 04/11/2016 12:49 AM, Semyon Sadetsky wrote:
> Sergey,
>
> I yet do not understand your arguments unless the synchronization 
> issue (it took place before the current fix and it is better to 
> investigate it separately).
> But I think this topic is important and shouldn't be lost. I would 
> suggest you to file a JIRA ticket with description of bad scenarios 
> from the flexible "jdk.gtk.version" property your see. It would be 
> also great if you provide test cases. Then we will systematize all 
> pros and cons and elaborate the final solution. Are you good with that?
>
> --Semyon
>
> On 4/8/2016 1:49 PM, Sergey Bylokhov wrote:
>> On 21.03.16 23:38, Semyon Sadetsky wrote:
>>>> This does not solve the problem when check/init/load will try to use
>>>> the different versions. I guess I provided enough arguments to
>>>> initialize these data only once.
>>> I've already explained that GTK library cannot be loaded twice, only 
>>> one
>>> version may be loaded regardless of the property value.
>>
>> We already found that there is a problem in synchronization, there is 
>> some other cases, which can be introduced in the future. To eliminate 
>> even the possibility of such missconfigurationion, it would be better 
>> try to load only the one version which was set by "jdk.gtk.version" 
>> for the first time. It will solve bunch of possible issues.
>>
>>>> It will be better to make it obvious and not to depends on some order.
>>>> I am curious where you find it widely used. At least in the client I
>>>> found only one usage.
>>> I can help you. Look at GTKEngine.java: WidgetType, StateType, 
>>> Settings,
>>> ShadowType, Orientation, PositionType, etc...
>>
>> Thanks, this all in one file of gtk look and feel. This is a bad 
>> pattern, and we should not copy it to the UnixToolkit class. For 
>> additional information read the spec of ordinal method and "Effective 
>> Java" by Josh Bloch Item 31.
>>
>> Also I am not sure that I understand where we survive the hang which 
>> can occur if we try to load the gtk library if it was loaded before 
>> by the other applications(like fx or swt).
>>
>



From semyon.sadetsky at oracle.com  Mon Apr 25 08:16:08 2016
From: semyon.sadetsky at oracle.com (Semyon Sadetsky)
Date: Mon, 25 Apr 2016 11:16:08 +0300
Subject: <Swing Dev> Review-request for 8145547: JEP 283: [AWT/Swing]
 Conditional support for GTK 3 on Linux
In-Reply-To: <571A7E64.2060609@oracle.com>
References: <56DB4C3B.1060902@oracle.com> <56E864DE.4000706@oracle.com>
	<56E99D68.90208@oracle.com> <56EA9929.9020605@oracle.com>
	<56EBF688.1090006@oracle.com> <56ED7507.1090204@oracle.com>
	<56EFF685.1090702@oracle.com> <56EFFC8A.1010306@oracle.com>
	<56F044BF.2000609@oracle.com> <56F0498A.4090802@oracle.com>
	<56F04BBD.1030102@oracle.com> <56F051FD.3000203@oracle.com>
	<56F05BB5.2080209@oracle.com> <57078C9E.2080409@oracle.com>
	<570B56FE.20109@oracle.com> <571A7E64.2060609@oracle.com>
Message-ID: <571DD248.7000904@oracle.com>

Hello,

The issues

https://bugs.openjdk.java.net/browse/JDK-8154992
https://bugs.openjdk.java.net/browse/JDK-8154993
https://bugs.openjdk.java.net/browse/JDK-8154994

were filed. So ready to push then...

--Semyon


On 4/22/2016 10:41 PM, Phil Race wrote:
> Hi Semyon,
>
> I think we can/should quickly fix the new ordinal() usage and file a 
> separate bug for the GTKEngine usage.
>
> We can table (defer) changes for the potential hang as long as we file 
> a JIRA to investigate.
>
> Then we can get the JEP in sooner rather than later (Monday!)
>
> -phil.
>
>
> On 04/11/2016 12:49 AM, Semyon Sadetsky wrote:
>> Sergey,
>>
>> I yet do not understand your arguments unless the synchronization 
>> issue (it took place before the current fix and it is better to 
>> investigate it separately).
>> But I think this topic is important and shouldn't be lost. I would 
>> suggest you to file a JIRA ticket with description of bad scenarios 
>> from the flexible "jdk.gtk.version" property your see. It would be 
>> also great if you provide test cases. Then we will systematize all 
>> pros and cons and elaborate the final solution. Are you good with that?
>>
>> --Semyon
>>
>> On 4/8/2016 1:49 PM, Sergey Bylokhov wrote:
>>> On 21.03.16 23:38, Semyon Sadetsky wrote:
>>>>> This does not solve the problem when check/init/load will try to use
>>>>> the different versions. I guess I provided enough arguments to
>>>>> initialize these data only once.
>>>> I've already explained that GTK library cannot be loaded twice, 
>>>> only one
>>>> version may be loaded regardless of the property value.
>>>
>>> We already found that there is a problem in synchronization, there 
>>> is some other cases, which can be introduced in the future. To 
>>> eliminate even the possibility of such missconfigurationion, it 
>>> would be better try to load only the one version which was set by 
>>> "jdk.gtk.version" for the first time. It will solve bunch of 
>>> possible issues.
>>>
>>>>> It will be better to make it obvious and not to depends on some 
>>>>> order.
>>>>> I am curious where you find it widely used. At least in the client I
>>>>> found only one usage.
>>>> I can help you. Look at GTKEngine.java: WidgetType, StateType, 
>>>> Settings,
>>>> ShadowType, Orientation, PositionType, etc...
>>>
>>> Thanks, this all in one file of gtk look and feel. This is a bad 
>>> pattern, and we should not copy it to the UnixToolkit class. For 
>>> additional information read the spec of ordinal method and 
>>> "Effective Java" by Josh Bloch Item 31.
>>>
>>> Also I am not sure that I understand where we survive the hang which 
>>> can occur if we try to load the gtk library if it was loaded before 
>>> by the other applications(like fx or swt).
>>>
>>
>



From Sergey.Bylokhov at oracle.com  Mon Apr 25 14:58:14 2016
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Mon, 25 Apr 2016 17:58:14 +0300
Subject: <Swing Dev> [9] Review request for 8046031: UI of Java Web
 Start app isn't updated when changing Windows theme
In-Reply-To: <571A5152.2050907@oracle.com>
References: <5718D41D.7090104@oracle.com> <5718DBF1.7090407@oracle.com>
	<57192E19.40107@oracle.com> <571A5152.2050907@oracle.com>
Message-ID: <571E3086.5040200@oracle.com>

On 22.04.16 19:29, Semyon Sadetsky wrote:
>
>
> On 4/21/2016 10:46 PM, Sergey Bylokhov wrote:
>> Hi, Semyon.
>> As far as I understand from the bug description, the method
>> DesktopProperty.updateUI() is called on the different EDT? Does it
>> mean that we share the same DesktopProperty object across different
>> Appcontext? (if not then probably we can skip the usage of Appcontext
>> and change the field to non-static)?
> No, we do not share the same DesktopProperty object, but it would be odd
> to expect that there is only one DesktopProperty per app context.

Why it is odd? This code is called in the "propertyChange()" which 
executes on some EDT, each EDT is bound already to some specific 
Appcontext. Otherwise we should store all data inside this class per 
appcontext(since we don't do this I assume that we store this object per 
Appcontext). Plus I see it is used only in the WinLookAndFeel and the 
l&f itself is stored per appcontext also.

> Putting the flag into the app scope protects from scheduling events
> recursively
>> If the Appcontext is necessary, then we should not use interned string
>> as a key, I suggest to use the simple new Object(), so it will not be
>> accessible outside of this class.
> This is a public field. Accessing it outside the class shouldn't be an
> issue.

I overlooked that it is public in my first email. Why? If it is not used 
outside of this class it should be private. Also the interned string 
will provide a way to access this data even if "com/sun/java/swing" 
package will be inaccessible. So it is better to use private key.

>
> --Semyon
>>
>> On 21.04.16 16:56, Alexandr Scherbatiy wrote:
>>>
>>>   The fix looks good to me.
>>>
>>>   Thanks,
>>>   Alexandr.
>>>
>>> On 4/21/2016 6:22 AM, Semyon Sadetsky wrote:
>>>> Hello,
>>>>
>>>> Please review fix for JDK9:
>>>>
>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8046031
>>>> webrev: http://cr.openjdk.java.net/~ssadetsky/8046031/webrev.00/
>>>>
>>>> Under the Windoew LnF when the native Windows theme is changed some
>>>> java frames remains unchanged if there are several application
>>>> contexts. The thing is the DesktopProperty#updatePending flag that
>>>> prevents to run more then one UI update operation is shared between
>>>> different applications contexts while they may be updated with the
>>>> property change concurrently from different EDT threads so they may
>>>> loose the update.
>>>> To avoid this mutual interference the updatePending is moved from the
>>>> global to the application context scope.
>>>> The test would require to write native code so the issue is labeled
>>>> noreg-hard.
>>>>
>>>> --Semyon
>>>
>>
>>
>


-- 
Best regards, Sergey.


From semyon.sadetsky at oracle.com  Mon Apr 25 17:56:45 2016
From: semyon.sadetsky at oracle.com (Semyon Sadetsky)
Date: Mon, 25 Apr 2016 20:56:45 +0300
Subject: <Swing Dev> [9] Review request for 8046031: UI of Java Web
 Start app isn't updated when changing Windows theme
In-Reply-To: <571E3086.5040200@oracle.com>
References: <5718D41D.7090104@oracle.com> <5718DBF1.7090407@oracle.com>
	<57192E19.40107@oracle.com> <571A5152.2050907@oracle.com>
	<571E3086.5040200@oracle.com>
Message-ID: <571E5A5D.4030401@oracle.com>



On 4/25/2016 5:58 PM, Sergey Bylokhov wrote:
> On 22.04.16 19:29, Semyon Sadetsky wrote:
>>
>>
>> On 4/21/2016 10:46 PM, Sergey Bylokhov wrote:
>>> Hi, Semyon.
>>> As far as I understand from the bug description, the method
>>> DesktopProperty.updateUI() is called on the different EDT? Does it
>>> mean that we share the same DesktopProperty object across different
>>> Appcontext? (if not then probably we can skip the usage of Appcontext
>>> and change the field to non-static)?
>> No, we do not share the same DesktopProperty object, but it would be odd
>> to expect that there is only one DesktopProperty per app context.
>
> Why it is odd? This code is called in the "propertyChange()" which 
> executes on some EDT, each EDT is bound already to some specific 
> Appcontext. Otherwise we should store all data inside this class per 
> appcontext(since we don't do this I assume that we store this object 
> per Appcontext). Plus I see it is used only in the WinLookAndFeel and 
> the l&f itself is stored per appcontext also.
I see 4 at least:

             this.themeActive = new 
TriggerDesktopProperty("win.xpstyle.themeActive");
             this.dllName     = new 
TriggerDesktopProperty("win.xpstyle.dllName");
             this.colorName   = new 
TriggerDesktopProperty("win.xpstyle.colorName");
             this.sizeName    = new 
TriggerDesktopProperty("win.xpstyle.sizeName");

--Semyon
>
>> Putting the flag into the app scope protects from scheduling events
>> recursively
>>> If the Appcontext is necessary, then we should not use interned string
>>> as a key, I suggest to use the simple new Object(), so it will not be
>>> accessible outside of this class.
>> This is a public field. Accessing it outside the class shouldn't be an
>> issue.
>
> I overlooked that it is public in my first email. Why? If it is not 
> used outside of this class it should be private. Also the interned 
> string will provide a way to access this data even if 
> "com/sun/java/swing" package will be inaccessible. So it is better to 
> use private key.
>
>>
>> --Semyon
>>>
>>> On 21.04.16 16:56, Alexandr Scherbatiy wrote:
>>>>
>>>>   The fix looks good to me.
>>>>
>>>>   Thanks,
>>>>   Alexandr.
>>>>
>>>> On 4/21/2016 6:22 AM, Semyon Sadetsky wrote:
>>>>> Hello,
>>>>>
>>>>> Please review fix for JDK9:
>>>>>
>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8046031
>>>>> webrev: http://cr.openjdk.java.net/~ssadetsky/8046031/webrev.00/
>>>>>
>>>>> Under the Windoew LnF when the native Windows theme is changed some
>>>>> java frames remains unchanged if there are several application
>>>>> contexts. The thing is the DesktopProperty#updatePending flag that
>>>>> prevents to run more then one UI update operation is shared between
>>>>> different applications contexts while they may be updated with the
>>>>> property change concurrently from different EDT threads so they may
>>>>> loose the update.
>>>>> To avoid this mutual interference the updatePending is moved from the
>>>>> global to the application context scope.
>>>>> The test would require to write native code so the issue is labeled
>>>>> noreg-hard.
>>>>>
>>>>> --Semyon
>>>>
>>>
>>>
>>
>
>



From alexandr.scherbatiy at oracle.com  Tue Apr 26 09:52:50 2016
From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy)
Date: Tue, 26 Apr 2016 13:52:50 +0400
Subject: <Swing Dev> Review Request of 8152492: [macosx swing] double
 key event actions when using Mac menubar
In-Reply-To: <AC0E0B3F-6DEC-427D-8EFD-1249D4FC5B61@oracle.com>
References: <350CB937-DB61-46D9-A456-47D337E4788A@oracle.com>
	<5707C409.4030702@oracle.com>
	<123F5EB3-DD71-4706-A9F2-217F8B29BEF7@oracle.com>
	<9D087362-41B8-46F3-8A6C-E47D9186723C@oracle.com>
	<571626CA.4050504@oracle.com>
	<4CC47F90-5269-40C8-82CA-5DC3B41713AB@oracle.com>
	<AC0E0B3F-6DEC-427D-8EFD-1249D4FC5B61@oracle.com>
Message-ID: <571F3A72.7070902@oracle.com>


The fix looks good to me.

Thanks,
Alexandr.

On 21/04/16 13:52, Manajit Halder wrote:
> Hi Avik,
>
> Changes looks good to me.
>
> Regards,
> Manajit
>
>> On 20-Apr-2016, at 11:37 am, Avik Niyogi <avik.niyogi at oracle.com 
>> <mailto:avik.niyogi at oracle.com>> wrote:
>>
>> Hi All,
>> I have added some comments and made some minor tweaks as per the 
>> inputs received.
>> Please review my code changes as available at this link below:
>>
>> http://cr.openjdk.java.net/~aniyogi/8152492/webrev.02/ 
>> <http://cr.openjdk.java.net/%7Eaniyogi/8152492/webrev.02/>
>>
>> With Regards,
>> Avik Niyogi
>>
>>> On 19-Apr-2016, at 6:08 pm, Sergey Bylokhov 
>>> <Sergey.Bylokhov at oracle.com <mailto:Sergey.Bylokhov at oracle.com>> wrote:
>>>
>>> On 19.04.16 11:46, Avik Niyogi wrote:
>>>> Hi All,
>>>> Please review my code changes with inputs received:
>>>
>>> Can you please add some description of your changes, it seems you 
>>> removed all code which was added by you previously.
>>>
>>>> http://cr.openjdk.java.net/~aniyogi/8152492/webrev.01/ 
>>>> <http://cr.openjdk.java.net/%7Eaniyogi/8152492/webrev.01/>
>>>>
>>>> With Regards,
>>>> Avik Niyogi
>>>>> On 19-Apr-2016, at 11:47 am, Avik Niyogi <avik.niyogi at oracle.com 
>>>>> <mailto:avik.niyogi at oracle.com>
>>>>> <mailto:avik.niyogi at oracle.com>> wrote:
>>>>>
>>>>> Hi Sergey,
>>>>> I have tried all these Input sources:
>>>>> <Screen Shot 2016-04-19 at 11.40.33 am.png>
>>>>> I am unable to reproduce the test failure as mentioned by you with
>>>>> these inputs. Please provide some screenshots and/or details of the
>>>>> procedure used for this test failure.
>>>>> Thank you in advance.
>>>>>
>>>>> With Regards,
>>>>> Avik Niyogi
>>>>>
>>>>>> On 08-Apr-2016, at 8:15 pm, Sergey Bylokhov
>>>>>> <Sergey.Bylokhov at oracle.com 
>>>>>> <mailto:Sergey.Bylokhov at oracle.com><mailto:Sergey.Bylokhov at oracle.com>> 
>>>>>> wrote:
>>>>>>
>>>>>> Hi, Avik.
>>>>>> It seems there is one more bug in this "if".
>>>>>> Change the input source to "Hindi Dev.."/"Russian.." then this test
>>>>>> fails anyway(it will produce the double action).
>>>>>> Moreover if I change the source input to Hindi Transliteration, the
>>>>>> test sometimes crashed.
>>>>>> Please double check.
>>>>>>
>>>>>> On 06.04.16 13:42, Avik Niyogi wrote:
>>>>>>> Hi All,
>>>>>>>
>>>>>>> Kindly review the bug fix for JDK 9.
>>>>>>>
>>>>>>> *Bug:*
>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8152492
>>>>>>>
>>>>>>> *Webrev:*
>>>>>>> http://cr.openjdk.java.net/~aniyogi/8152492/webrev.00/ 
>>>>>>> <http://cr.openjdk.java.net/%7Eaniyogi/8152492/webrev.00/>
>>>>>>>
>>>>>>> *Issue:*
>>>>>>> For OSX, having there is provision of non-integrated menubar. 
>>>>>>> for this
>>>>>>> case, triggering the menu action by key press triggered double 
>>>>>>> action in
>>>>>>> some cases
>>>>>>>
>>>>>>> *Cause:*
>>>>>>> Due to the use of Shift modifier being a soft modifier in case 
>>>>>>> of mac.
>>>>>>> For example ?Shift + m? is actually ?M? and ?Shift + ,? is ?<? .
>>>>>>> So such cases can not be used as shortcuts. This needs to be
>>>>>>> accounted for.
>>>>>>> Also, cases where ?Cmd + Shift + c? is used as a shortcut, it 
>>>>>>> should not
>>>>>>> morph that to a ?Cmd + C? command and should detect c itself.
>>>>>>> Also, ?Shift + ?? has no equivalent soft modification and can be 
>>>>>>> taken
>>>>>>> as a shortcut. This has to be accounted for.
>>>>>>>
>>>>>>> *Fix:*
>>>>>>> All required edge case scenarios for the soft modification of 
>>>>>>> Shift and
>>>>>>> cases of valid modifiers were taken into account.
>>>>>>>
>>>>>>> With Regards,
>>>>>>> Avik Niyogi
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Best regards, Sergey.
>>>>>
>>>>
>>>
>>>
>>> --
>>> Best regards, Sergey.
>>
>

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

From Sergey.Bylokhov at oracle.com  Tue Apr 26 12:41:43 2016
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Tue, 26 Apr 2016 15:41:43 +0300
Subject: <Swing Dev> [9] Review request for 8046031: UI of Java Web
 Start app isn't updated when changing Windows theme
In-Reply-To: <571E5A5D.4030401@oracle.com>
References: <5718D41D.7090104@oracle.com> <5718DBF1.7090407@oracle.com>
	<57192E19.40107@oracle.com> <571A5152.2050907@oracle.com>
	<571E3086.5040200@oracle.com> <571E5A5D.4030401@oracle.com>
Message-ID: <571F6207.3040101@oracle.com>

On 25.04.16 20:56, Semyon Sadetsky wrote:
>
>
> On 4/25/2016 5:58 PM, Sergey Bylokhov wrote:
>> Why it is odd? This code is called in the "propertyChange()" which
>> executes on some EDT, each EDT is bound already to some specific
>> Appcontext. Otherwise we should store all data inside this class per
>> appcontext(since we don't do this I assume that we store this object
>> per Appcontext). Plus I see it is used only in the WinLookAndFeel and
>> the l&f itself is stored per appcontext also.
> I see 4 at least:

All of these are a private object fields in Windows l&F and the l&f is 
stored per appcontext. what is the problem in these fields?

>
>              this.themeActive = new
> TriggerDesktopProperty("win.xpstyle.themeActive");
>              this.dllName     = new
> TriggerDesktopProperty("win.xpstyle.dllName");
>              this.colorName   = new
> TriggerDesktopProperty("win.xpstyle.colorName");
>              this.sizeName    = new
> TriggerDesktopProperty("win.xpstyle.sizeName");
>
> --Semyon
>>
>>> Putting the flag into the app scope protects from scheduling events
>>> recursively
>>>> If the Appcontext is necessary, then we should not use interned string
>>>> as a key, I suggest to use the simple new Object(), so it will not be
>>>> accessible outside of this class.
>>> This is a public field. Accessing it outside the class shouldn't be an
>>> issue.
>>
>> I overlooked that it is public in my first email. Why? If it is not
>> used outside of this class it should be private. Also the interned
>> string will provide a way to access this data even if
>> "com/sun/java/swing" package will be inaccessible. So it is better to
>> use private key.
>>
>>>
>>> --Semyon
>>>>
>>>> On 21.04.16 16:56, Alexandr Scherbatiy wrote:
>>>>>
>>>>>   The fix looks good to me.
>>>>>
>>>>>   Thanks,
>>>>>   Alexandr.
>>>>>
>>>>> On 4/21/2016 6:22 AM, Semyon Sadetsky wrote:
>>>>>> Hello,
>>>>>>
>>>>>> Please review fix for JDK9:
>>>>>>
>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8046031
>>>>>> webrev: http://cr.openjdk.java.net/~ssadetsky/8046031/webrev.00/
>>>>>>
>>>>>> Under the Windoew LnF when the native Windows theme is changed some
>>>>>> java frames remains unchanged if there are several application
>>>>>> contexts. The thing is the DesktopProperty#updatePending flag that
>>>>>> prevents to run more then one UI update operation is shared between
>>>>>> different applications contexts while they may be updated with the
>>>>>> property change concurrently from different EDT threads so they may
>>>>>> loose the update.
>>>>>> To avoid this mutual interference the updatePending is moved from the
>>>>>> global to the application context scope.
>>>>>> The test would require to write native code so the issue is labeled
>>>>>> noreg-hard.
>>>>>>
>>>>>> --Semyon
>>>>>
>>>>
>>>>
>>>
>>
>>
>


-- 
Best regards, Sergey.


From joe.darcy at oracle.com  Tue Apr 26 16:45:38 2016
From: joe.darcy at oracle.com (joe darcy)
Date: Tue, 26 Apr 2016 09:45:38 -0700
Subject: <Swing Dev> Fwd: Re: JDK 9 pre-review of JDK-6850612: Deprecate
 Class.newInstance since it violates the checked exception language contract
In-Reply-To: <5718FEF7.1020807@oracle.com>
References: <5718FEF7.1020807@oracle.com>
Message-ID: <57f52e95-9485-1114-5314-cbdf1680709b@oracle.com>

Phil and other client reviewers,

Please review this change from core libs which impacts client libs 
implementations. In brief, deprecating a method in core reflection 
requires uses of that method to have a @SuppressWarnings("deprecation") 
annotation. The typical way to minimize the scope of the deprecation is 
to declare a temporary variable which can host the @SuppressWarnings 
annotation. The alternative would have been to suppress the warning on 
the entire method, which would allow addition use of deprecated methods 
to sneak in.

      http://cr.openjdk.java.net/~darcy/6850612.0/

Thanks,

-Joe


-------- Forwarded Message --------
Subject: 	Re: JDK 9 pre-review of JDK-6850612: Deprecate 
Class.newInstance since it violates the checked exception language contract
Date: 	Thu, 21 Apr 2016 09:25:27 -0700
From: 	joe darcy <joe.darcy at oracle.com>
Organization: 	Oracle Corporation
To: 	core-libs-dev <core-libs-dev at openjdk.java.net>



Hello,

After a generally positive reception, please review the webrev to
implement the deprecation of Class.newInstance and the suppression of
the resulting warnings:

      http://cr.openjdk.java.net/~darcy/6850612.0/

There are also some changes in the langtools repo; I'll send a separate
review request for those changes to compiler-dev.

I'll also forward this review request to other areas with affected code.

Thanks,

-Joe

On 4/17/2016 10:31 AM, joe darcy wrote:
> Hello,
>
> With talk of deprecation in the air [1], I thought it would be a fine
> time to examine one of the bugs on my list
>
>     JDK-6850612: Deprecate Class.newInstance since it violates the
> checked exception language contract
>
> As the title of the bug implies, The Class.newInstance method
> knowingly violates the checking exception contract. This has long been
> documented in its specification:
>
>> Note that this method propagates any exception thrown by the nullary
>> constructor, including a checked exception. Use of this method
>> effectively bypasses the compile-time exception checking that would
>> otherwise be performed by the compiler. The Constructor.newInstance
>> method avoids this problem by wrapping any exception thrown by the
>> constructor in a (checked) InvocationTargetException.
>
> Roughly, the fix would be to turn the text of this note into the
> @deprecated text and to add a @Deprecated(since="9") annotation to the
> method. There are a few dozen uses of the method in the JDK that would
> have to be @SuppressWarning-ed or otherwise updated.
>
> Thoughts on the appropriateness of deprecating this method at this time?
>
> Comments on the bug have suggested that besides deprecating the
> method, a new method on Class could be introduced,
> newInstanceWithProperExceptionBehavior, that had the same signature
> but wrapped exceptions thrown by the constructor call in the same way
> Constructor.newInstance does.
>
> Thanks,
>
> -Joe
>
> [1]
> http://mail.openjdk.java.net/pipermail/core-libs-dev/2016-April/040192.html

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

From philip.race at oracle.com  Tue Apr 26 17:38:49 2016
From: philip.race at oracle.com (Phil Race)
Date: Tue, 26 Apr 2016 10:38:49 -0700
Subject: <Swing Dev> [9] Review request for 8132119 Provide public API
 for text related methods in SwingUtilities2
In-Reply-To: <5715E767.5000409@oracle.com>
References: <55E715A1.3090008@oracle.com> <55E72D3A.60807@oracle.com>
	<55ED586F.5070509@oracle.com> <55F6DC3C.60809@oracle.com>
	<5655D3AB.9050503@oracle.com> <5668051E.7090401@oracle.com>
	<5668E226.5000604@oracle.com> <5669646E.4070305@oracle.com>
	<566986FD.9020207@oracle.com> <5694F0C3.8020203@oracle.com>
	<5695572F.6070709@oracle.com> <56966730.7000701@oracle.com>
	<5698C71A.80703@oracle.com> <56991ED9.5030302@oracle.com>
	<569963B6.2050604@oracle.com> <56A5C40B.7010107@oracle.com>
	<CAM6ZMz8iEFQQtSb_bAVU5eUH=J=HapvKq3+Ana4pPxueJD1bNg@mail.gmail.com>
	<56AB8A94.2070404@oracle.com> <56EC2389.3020507@oracle.com>
	<56F38B0B.3060700@oracle.com> <56F3F13A.9000808@oracle.com>
	<56F3F83C.3010706@oracle.com> <56FD791E.1050707@oracle.com>
	<5705705C.2010007@oracle.com> <570C3370.1090702@oracle.com>
	<5715E767.5000409@oracle.com>
Message-ID: <571FA7A9.6060105@oracle.com>

On 04/19/2016 01:08 AM, Alexandr Scherbatiy wrote:
> On 4/11/2016 4:29 PM, Philip Race wrote:
>>
>>
>> On 4/6/16, 1:23 PM, Alexander Scherbatiy wrote:
>>>
>>> Hello,
>>>
>>> Could you review the updated fix:
>>>   http://cr.openjdk.java.net/~alexsch/8132119/webrev.09
>>>
>>>  - TextUIDrawing interface and its default implementaion 
>>> BasicTextUIDrawing class are added
>>>  - font metrics argument description is updated
>>>
>>> On 31/03/16 23:23, Phil Race wrote:
>>>> Another webrev where you have to slip past 40_ files to get to the 
>>>> two that really matter :-)
>>>> I would have put SwingUtilities2.java and TextUIDrawing.java as the 
>>>> first files.
>>>    Updated.
>>>>
>>>>
>>>> Some of what I have to say here is more along the lines of things 
>>>> to think
>>>> about rather than things that are wrong .. but there are also maybe 
>>>> some things
>>>> that need to be fixed.
>>>>
>>>> Is javax.swing.plaf really the right package for the new class ?
>>>> I suppose it is for the use by the UI classes so maybe its right.
>>>>
>>>> Should the methods be taking "double" instead of "int" for location ?
>>>> This means the measurement APIs too.
>>>> None of the JDK 1.2 text APIs use ints. That is all 1.0 legacy.
>>>> So if Swing internally wants to use ints that is OK but maybe the API
>>>> should be floating point (double).
>>>   The provided methods use Graphics as argument which only has 
>>> drawString(String, int, int) method.
>>>   If it is possible it is better to add the methods with float 
>>> arguments and Graphics2D later.
>>>
>>>> Would that  help hi-dpi at all ?
>>>   The hi-dpi support mostly does not require changes in Swing. What 
>>> it does just scales graphics using default transform from graphics 
>>> configuration.
>>
>> Yes, but in another bug you are dealing with a problem positioning
>> the caret because of (somewhat) similar issues where coordinates have 
>> been
>> rounded to an integral. A floating point value allows you to say that
>> this is 25.5 in user-space, even it if is 51.0 in device space.
>
>    It needs some more investigation.
>
>    What I have now is Swing uses font metrics to calculate a string 
> width (FontMetrics.charsWidth(...)) which sums up float char values.
>    The difference between font metrics used by Swing and font metrics 
> from graphics passed to paint method is that the fist has null frc.tx 
> matrix and the second one has a matrix with scales 2 on HiDPI display.
>    The returned char width by the font metrics with null transform has 
> value 7 for char 'a' (linear advance is 6.67 and xAdvance is 7).
>    The char width for the font metrics with scaled transform is 6.5 
> for the same font and char.  FileFontStrike requests glyph metrics and 
> gets linear advance  13.35 (dev transform is taken into account) 
> xAdvance  13 -  and apply the reverse transform. The result is 13 / 2  
> = 6.5.
>
>   And this bothers me because a result for applying the tx transform 
> and inverting it is different than just use the identity transform. 
> There are definitely problems with advance rounding but it seems they 
> are placed out of the Swing area.
>

  I am not sure if you are implying a bug in the font code, but there is 
none that I see
from the above.

There are several distinct issues here
1) You must specify the device transform, unless you are requesting and 
using linear advances.
2) Linear advance is not generally used by Swing since it implies 
unhinted text
3) Rounding of advances back to user space is OK in the case of hinted 
advances and
     identity transform - ie the traditional Swing case - but in the 
case like that you describe
     where the device pixel advance is 13 for a (2.0,2.0) device scale 
then the translation
     back to user space can't express that accurately if it only has int 
to work with,

If Swing is not using the same device transform in calculating the 
advance as it is when
drawing then that is a bug . That was the point of the comment we added 
below about
obtaining the correct FontMetrics .. our L&Fs should be doing that as 
well as admonishing
others to do so.


>>
>>>
>>>> I suppose it would add over-head since all the existing code uses int
>>>> and we are no worse off and can add double methods later if we want 
>>>> to.
>>>>
>>>>
>>>> Regarding FontMetrics we need to add a caution that is must be a 
>>>> FontMetrics
>>>> *obtained from the correct font and graphics*.
>>>    Updated.
>>>>
>>>>
>>>>  i.e what about attributes on the font such as "tracking" ?
>>>> or on the graphics such as FRACTIONALMETRICS
>>>> It looks like Swing might already fail if that were used.
>>>>
>>>> Look at this code :-
>>>>
>>>>    public static int stringWidth(JComponent c, FontMetrics fm, 
>>>> String string){
>>>>         if (string == null || string.equals("")) {
>>>>             return 0;
>>>>         }
>>>>         boolean needsTextLayout = ((c != null) &&
>>>> (c.getClientProperty(TextAttribute.NUMERIC_SHAPING) != null));
>>>>         if (needsTextLayout) {
>>>>             synchronized(charsBufferLock) {
>>>>                 int length = syncCharsBuffer(string);
>>>>                 needsTextLayout = isComplexLayout(charsBuffer, 0, 
>>>> length);
>>>>             }
>>>>         }
>>>>         if (needsTextLayout) {
>>>>             TextLayout layout = createTextLayout(c, string,
>>>>                                     fm.getFont(), 
>>>> fm.getFontRenderContext());
>>>>             return (int) layout.getAdvance();
>>>>         } else {
>>>>             return fm.stringWidth(string);
>>>>         }
>>>>     }
>>>>
>>>> The only thing Swing is looking at is one TextAttribute and whether 
>>>> we have complex text.
>>>> That is not enough. This is an existing implementation issue but 
>>>> one we should fix here.
>>>> You need to examine all the methods for similar issues.
>>>   I created an enhancement for this:
>>>     JDK-8153662 
>>> SwingUtilities2.drawString()/getStringWidth()/clipString() should 
>>> use more text attributes
>>>       https://bugs.openjdk.java.net/browse/JDK-8153662
>>
>> you mean bug ? I upgraded it to P3 because it matters a lot more now
>> with this public API
>
>   I do not think that it is a bug because the main request was to have 
> methods which draw strings in the same way as it is done by Swing L&Fs.

It seems like a bug to me

> This will allow to have custom UI component which mimic to the 
> standard L&Fs.
>
>   It is also can be considered from the following point of view: is 
> the proposed request to use more text attributes more important for 
> standard Swing L&F or for custom L&F.
>   It seems is not the first case because Swing lives with the current 
> implementation for the long time.
>   For the second case we provide the public TextUIDrawing interface 
> which a developer can override and use any text attributes that are 
> necessary.
>
We aren't talking about a separate API to provide text attributes, we 
are talking about the
ones that are part of the font and the implementation is not respecting.

-phil.



From alexandr.scherbatiy at oracle.com  Tue Apr 26 18:26:11 2016
From: alexandr.scherbatiy at oracle.com (Alexandr Scherbatiy)
Date: Tue, 26 Apr 2016 21:26:11 +0300
Subject: <Swing Dev> [9] Review request for 8132119 Provide public API
 for text related methods in SwingUtilities2
In-Reply-To: <571FA7A9.6060105@oracle.com>
References: <55E715A1.3090008@oracle.com> <55E72D3A.60807@oracle.com>
	<55ED586F.5070509@oracle.com> <55F6DC3C.60809@oracle.com>
	<5655D3AB.9050503@oracle.com> <5668051E.7090401@oracle.com>
	<5668E226.5000604@oracle.com> <5669646E.4070305@oracle.com>
	<566986FD.9020207@oracle.com> <5694F0C3.8020203@oracle.com>
	<5695572F.6070709@oracle.com> <56966730.7000701@oracle.com>
	<5698C71A.80703@oracle.com> <56991ED9.5030302@oracle.com>
	<569963B6.2050604@oracle.com> <56A5C40B.7010107@oracle.com>
	<CAM6ZMz8iEFQQtSb_bAVU5eUH=J=HapvKq3+Ana4pPxueJD1bNg@mail.gmail.com>
	<56AB8A94.2070404@oracle.com> <56EC2389.3020507@oracle.com>
	<56F38B0B.3060700@oracle.com> <56F3F13A.9000808@oracle.com>
	<56F3F83C.3010706@oracle.com> <56FD791E.1050707@oracle.com>
	<5705705C.2010007@oracle.com> <570C3370.1090702@oracle.com>
	<5715E767.5000409@oracle.com> <571FA7A9.6060105@oracle.com>
Message-ID: <571FB2C3.10808@oracle.com>

On 4/26/2016 8:38 PM, Phil Race wrote:
> On 04/19/2016 01:08 AM, Alexandr Scherbatiy wrote:
>> On 4/11/2016 4:29 PM, Philip Race wrote:
>>>
>>>
>>> On 4/6/16, 1:23 PM, Alexander Scherbatiy wrote:
>>>>
>>>> Hello,
>>>>
>>>> Could you review the updated fix:
>>>>   http://cr.openjdk.java.net/~alexsch/8132119/webrev.09
>>>>
>>>>  - TextUIDrawing interface and its default implementaion 
>>>> BasicTextUIDrawing class are added
>>>>  - font metrics argument description is updated
>>>>
>>>> On 31/03/16 23:23, Phil Race wrote:
>>>>> Another webrev where you have to slip past 40_ files to get to the 
>>>>> two that really matter :-)
>>>>> I would have put SwingUtilities2.java and TextUIDrawing.java as 
>>>>> the first files.
>>>>    Updated.
>>>>>
>>>>>
>>>>> Some of what I have to say here is more along the lines of things 
>>>>> to think
>>>>> about rather than things that are wrong .. but there are also 
>>>>> maybe some things
>>>>> that need to be fixed.
>>>>>
>>>>> Is javax.swing.plaf really the right package for the new class ?
>>>>> I suppose it is for the use by the UI classes so maybe its right.
>>>>>
>>>>> Should the methods be taking "double" instead of "int" for location ?
>>>>> This means the measurement APIs too.
>>>>> None of the JDK 1.2 text APIs use ints. That is all 1.0 legacy.
>>>>> So if Swing internally wants to use ints that is OK but maybe the API
>>>>> should be floating point (double).
>>>>   The provided methods use Graphics as argument which only has 
>>>> drawString(String, int, int) method.
>>>>   If it is possible it is better to add the methods with float 
>>>> arguments and Graphics2D later.
>>>>
>>>>> Would that  help hi-dpi at all ?
>>>>   The hi-dpi support mostly does not require changes in Swing. What 
>>>> it does just scales graphics using default transform from graphics 
>>>> configuration.
>>>
>>> Yes, but in another bug you are dealing with a problem positioning
>>> the caret because of (somewhat) similar issues where coordinates 
>>> have been
>>> rounded to an integral. A floating point value allows you to say that
>>> this is 25.5 in user-space, even it if is 51.0 in device space.
>>
>>    It needs some more investigation.
>>
>>    What I have now is Swing uses font metrics to calculate a string 
>> width (FontMetrics.charsWidth(...)) which sums up float char values.
>>    The difference between font metrics used by Swing and font metrics 
>> from graphics passed to paint method is that the fist has null frc.tx 
>> matrix and the second one has a matrix with scales 2 on HiDPI display.
>>    The returned char width by the font metrics with null transform 
>> has value 7 for char 'a' (linear advance is 6.67 and xAdvance is 7).
>>    The char width for the font metrics with scaled transform is 6.5 
>> for the same font and char.  FileFontStrike requests glyph metrics 
>> and gets linear advance  13.35 (dev transform is taken into account) 
>> xAdvance  13 -  and apply the reverse transform. The result is 13 / 
>> 2  = 6.5.
>>
>>   And this bothers me because a result for applying the tx transform 
>> and inverting it is different than just use the identity transform. 
>> There are definitely problems with advance rounding but it seems they 
>> are placed out of the Swing area.
>>
>
>  I am not sure if you are implying a bug in the font code, but there 
> is none that I see
> from the above.
>
> There are several distinct issues here
> 1) You must specify the device transform, unless you are requesting 
> and using linear advances.
> 2) Linear advance is not generally used by Swing since it implies 
> unhinted text
> 3) Rounding of advances back to user space is OK in the case of hinted 
> advances and
>     identity transform - ie the traditional Swing case - but in the 
> case like that you describe
>     where the device pixel advance is 13 for a (2.0,2.0) device scale 
> then the translation
>     back to user space can't express that accurately if it only has 
> int to work with,
>
> If Swing is not using the same device transform in calculating the 
> advance as it is when
> drawing then that is a bug . That was the point of the comment we 
> added below about
> obtaining the correct FontMetrics .. our L&Fs should be doing that as 
> well as admonishing
> others to do so.

      It is true that Swing uses FontRenderingContext which does not 
take the graphics configuration transform into account.

     However, there are use case which should be considered:

     Using graphics configuration transform in Swing 
FontRenderingContext leads that text component size will depend on the 
graphics device.

     Let's take an a frame which has some text components placed in one 
row. Moving a frame from a non-HiDPI display to HiDPI display can lead 
that the size of text components can be changed and they will be 
rearranged in two rows.
     The same can be applicable for printing. Printing a text component 
from HiDPI display can lead that text will be shorter or longer than 
component bounds on a page.

    There is one more case. A text component before it is added to a 
frame does not know about device where it will be shown.
    So the following is possible:
     -----------------
         JTextField textField = new JTextField("ABC");
         int width1 = textField.getWidth(); // no graphics configuration 
is provided, frc Tx is identity
         frame.add(textField);
         int width2 = textField.getWidth(); // frc Tx is 2 on HiDPI display
     -----------------
Now it is possible that width1 is not equal to width2.

    Thanks,
    Alexandr.

>
>
>>>
>>>>
>>>>> I suppose it would add over-head since all the existing code uses int
>>>>> and we are no worse off and can add double methods later if we 
>>>>> want to.
>>>>>
>>>>>
>>>>> Regarding FontMetrics we need to add a caution that is must be a 
>>>>> FontMetrics
>>>>> *obtained from the correct font and graphics*.
>>>>    Updated.
>>>>>
>>>>>
>>>>>  i.e what about attributes on the font such as "tracking" ?
>>>>> or on the graphics such as FRACTIONALMETRICS
>>>>> It looks like Swing might already fail if that were used.
>>>>>
>>>>> Look at this code :-
>>>>>
>>>>>    public static int stringWidth(JComponent c, FontMetrics fm, 
>>>>> String string){
>>>>>         if (string == null || string.equals("")) {
>>>>>             return 0;
>>>>>         }
>>>>>         boolean needsTextLayout = ((c != null) &&
>>>>> (c.getClientProperty(TextAttribute.NUMERIC_SHAPING) != null));
>>>>>         if (needsTextLayout) {
>>>>>             synchronized(charsBufferLock) {
>>>>>                 int length = syncCharsBuffer(string);
>>>>>                 needsTextLayout = isComplexLayout(charsBuffer, 0, 
>>>>> length);
>>>>>             }
>>>>>         }
>>>>>         if (needsTextLayout) {
>>>>>             TextLayout layout = createTextLayout(c, string,
>>>>>                                     fm.getFont(), 
>>>>> fm.getFontRenderContext());
>>>>>             return (int) layout.getAdvance();
>>>>>         } else {
>>>>>             return fm.stringWidth(string);
>>>>>         }
>>>>>     }
>>>>>
>>>>> The only thing Swing is looking at is one TextAttribute and 
>>>>> whether we have complex text.
>>>>> That is not enough. This is an existing implementation issue but 
>>>>> one we should fix here.
>>>>> You need to examine all the methods for similar issues.
>>>>   I created an enhancement for this:
>>>>     JDK-8153662 
>>>> SwingUtilities2.drawString()/getStringWidth()/clipString() should 
>>>> use more text attributes
>>>>       https://bugs.openjdk.java.net/browse/JDK-8153662
>>>
>>> you mean bug ? I upgraded it to P3 because it matters a lot more now
>>> with this public API
>>
>>   I do not think that it is a bug because the main request was to 
>> have methods which draw strings in the same way as it is done by 
>> Swing L&Fs.
>
> It seems like a bug to me
>
>> This will allow to have custom UI component which mimic to the 
>> standard L&Fs.
>>
>>   It is also can be considered from the following point of view: is 
>> the proposed request to use more text attributes more important for 
>> standard Swing L&F or for custom L&F.
>>   It seems is not the first case because Swing lives with the current 
>> implementation for the long time.
>>   For the second case we provide the public TextUIDrawing interface 
>> which a developer can override and use any text attributes that are 
>> necessary.
>>
> We aren't talking about a separate API to provide text attributes, we 
> are talking about the
> ones that are part of the font and the implementation is not respecting.
>
> -phil.
>



From philip.race at oracle.com  Tue Apr 26 18:31:55 2016
From: philip.race at oracle.com (Phil Race)
Date: Tue, 26 Apr 2016 11:31:55 -0700
Subject: <Swing Dev> [9] Review request for 8132119 Provide public API
 for text related methods in SwingUtilities2
In-Reply-To: <571FB2C3.10808@oracle.com>
References: <55E715A1.3090008@oracle.com> <55E72D3A.60807@oracle.com>
	<55ED586F.5070509@oracle.com> <55F6DC3C.60809@oracle.com>
	<5655D3AB.9050503@oracle.com> <5668051E.7090401@oracle.com>
	<5668E226.5000604@oracle.com> <5669646E.4070305@oracle.com>
	<566986FD.9020207@oracle.com> <5694F0C3.8020203@oracle.com>
	<5695572F.6070709@oracle.com> <56966730.7000701@oracle.com>
	<5698C71A.80703@oracle.com> <56991ED9.5030302@oracle.com>
	<569963B6.2050604@oracle.com> <56A5C40B.7010107@oracle.com>
	<CAM6ZMz8iEFQQtSb_bAVU5eUH=J=HapvKq3+Ana4pPxueJD1bNg@mail.gmail.com>
	<56AB8A94.2070404@oracle.com> <56EC2389.3020507@oracle.com>
	<56F38B0B.3060700@oracle.com> <56F3F13A.9000808@oracle.com>
	<56F3F83C.3010706@oracle.com> <56FD791E.1050707@oracle.com>
	<5705705C.2010007@oracle.com> <570C3370.1090702@oracle.com>
	<5715E767.5000409@oracle.com> <571FA7A9.6060105@oracle.com>
	<571FB2C3.10808@oracle.com>
Message-ID: <571FB41B.6010200@oracle.com>

On 04/26/2016 11:26 AM, Alexandr Scherbatiy wrote:
> On 4/26/2016 8:38 PM, Phil Race wrote:
>> On 04/19/2016 01:08 AM, Alexandr Scherbatiy wrote:
>>> On 4/11/2016 4:29 PM, Philip Race wrote:
>>>>
>>>>
>>>> On 4/6/16, 1:23 PM, Alexander Scherbatiy wrote:
>>>>>
>>>>> Hello,
>>>>>
>>>>> Could you review the updated fix:
>>>>>   http://cr.openjdk.java.net/~alexsch/8132119/webrev.09
>>>>>
>>>>>  - TextUIDrawing interface and its default implementaion 
>>>>> BasicTextUIDrawing class are added
>>>>>  - font metrics argument description is updated
>>>>>
>>>>> On 31/03/16 23:23, Phil Race wrote:
>>>>>> Another webrev where you have to slip past 40_ files to get to 
>>>>>> the two that really matter :-)
>>>>>> I would have put SwingUtilities2.java and TextUIDrawing.java as 
>>>>>> the first files.
>>>>>    Updated.
>>>>>>
>>>>>>
>>>>>> Some of what I have to say here is more along the lines of things 
>>>>>> to think
>>>>>> about rather than things that are wrong .. but there are also 
>>>>>> maybe some things
>>>>>> that need to be fixed.
>>>>>>
>>>>>> Is javax.swing.plaf really the right package for the new class ?
>>>>>> I suppose it is for the use by the UI classes so maybe its right.
>>>>>>
>>>>>> Should the methods be taking "double" instead of "int" for 
>>>>>> location ?
>>>>>> This means the measurement APIs too.
>>>>>> None of the JDK 1.2 text APIs use ints. That is all 1.0 legacy.
>>>>>> So if Swing internally wants to use ints that is OK but maybe the 
>>>>>> API
>>>>>> should be floating point (double).
>>>>>   The provided methods use Graphics as argument which only has 
>>>>> drawString(String, int, int) method.
>>>>>   If it is possible it is better to add the methods with float 
>>>>> arguments and Graphics2D later.
>>>>>
>>>>>> Would that  help hi-dpi at all ?
>>>>>   The hi-dpi support mostly does not require changes in Swing. 
>>>>> What it does just scales graphics using default transform from 
>>>>> graphics configuration.
>>>>
>>>> Yes, but in another bug you are dealing with a problem positioning
>>>> the caret because of (somewhat) similar issues where coordinates 
>>>> have been
>>>> rounded to an integral. A floating point value allows you to say that
>>>> this is 25.5 in user-space, even it if is 51.0 in device space.
>>>
>>>    It needs some more investigation.
>>>
>>>    What I have now is Swing uses font metrics to calculate a string 
>>> width (FontMetrics.charsWidth(...)) which sums up float char values.
>>>    The difference between font metrics used by Swing and font 
>>> metrics from graphics passed to paint method is that the fist has 
>>> null frc.tx matrix and the second one has a matrix with scales 2 on 
>>> HiDPI display.
>>>    The returned char width by the font metrics with null transform 
>>> has value 7 for char 'a' (linear advance is 6.67 and xAdvance is 7).
>>>    The char width for the font metrics with scaled transform is 6.5 
>>> for the same font and char.  FileFontStrike requests glyph metrics 
>>> and gets linear advance  13.35 (dev transform is taken into account) 
>>> xAdvance  13 -  and apply the reverse transform. The result is 13 / 
>>> 2  = 6.5.
>>>
>>>   And this bothers me because a result for applying the tx transform 
>>> and inverting it is different than just use the identity transform. 
>>> There are definitely problems with advance rounding but it seems 
>>> they are placed out of the Swing area.
>>>
>>
>>  I am not sure if you are implying a bug in the font code, but there 
>> is none that I see
>> from the above.
>>
>> There are several distinct issues here
>> 1) You must specify the device transform, unless you are requesting 
>> and using linear advances.
>> 2) Linear advance is not generally used by Swing since it implies 
>> unhinted text
>> 3) Rounding of advances back to user space is OK in the case of 
>> hinted advances and
>>     identity transform - ie the traditional Swing case - but in the 
>> case like that you describe
>>     where the device pixel advance is 13 for a (2.0,2.0) device scale 
>> then the translation
>>     back to user space can't express that accurately if it only has 
>> int to work with,
>>
>> If Swing is not using the same device transform in calculating the 
>> advance as it is when
>> drawing then that is a bug . That was the point of the comment we 
>> added below about
>> obtaining the correct FontMetrics .. our L&Fs should be doing that as 
>> well as admonishing
>> others to do so.
>
>      It is true that Swing uses FontRenderingContext which does not 
> take the graphics configuration transform into account.
>
>     However, there are use case which should be considered:
>
>     Using graphics configuration transform in Swing 
> FontRenderingContext leads that text component size will depend on the 
> graphics device.
>
>     Let's take an a frame which has some text components placed in one 
> row. Moving a frame from a non-HiDPI display to HiDPI display can lead 
> that the size of text components can be changed and they will be 
> rearranged in two rows.
>     The same can be applicable for printing. Printing a text component 
> from HiDPI display can lead that text will be shorter or longer than 
> component bounds on a page.

Indeed .. and there have been bugs on this where Swing text is clipped 
when printed.
Sadly I don't believe the bug tail from that has been completely squashed.

>
>    There is one more case. A text component before it is added to a 
> frame does not know about device where it will be shown.
>    So the following is possible:
>     -----------------
>         JTextField textField = new JTextField("ABC");
>         int width1 = textField.getWidth(); // no graphics 
> configuration is provided, frc Tx is identity
>         frame.add(textField);
>         int width2 = textField.getWidth(); // frc Tx is 2 on HiDPI 
> display
>     -----------------
> Now it is possible that width1 is not equal to width2.

Absolutely true. And it is something Swing needs to handle.

-phil.

>
>    Thanks,
>    Alexandr.
>
>>
>>
>>>>
>>>>>
>>>>>> I suppose it would add over-head since all the existing code uses 
>>>>>> int
>>>>>> and we are no worse off and can add double methods later if we 
>>>>>> want to.
>>>>>>
>>>>>>
>>>>>> Regarding FontMetrics we need to add a caution that is must be a 
>>>>>> FontMetrics
>>>>>> *obtained from the correct font and graphics*.
>>>>>    Updated.
>>>>>>
>>>>>>
>>>>>>  i.e what about attributes on the font such as "tracking" ?
>>>>>> or on the graphics such as FRACTIONALMETRICS
>>>>>> It looks like Swing might already fail if that were used.
>>>>>>
>>>>>> Look at this code :-
>>>>>>
>>>>>>    public static int stringWidth(JComponent c, FontMetrics fm, 
>>>>>> String string){
>>>>>>         if (string == null || string.equals("")) {
>>>>>>             return 0;
>>>>>>         }
>>>>>>         boolean needsTextLayout = ((c != null) &&
>>>>>> (c.getClientProperty(TextAttribute.NUMERIC_SHAPING) != null));
>>>>>>         if (needsTextLayout) {
>>>>>>             synchronized(charsBufferLock) {
>>>>>>                 int length = syncCharsBuffer(string);
>>>>>>                 needsTextLayout = isComplexLayout(charsBuffer, 0, 
>>>>>> length);
>>>>>>             }
>>>>>>         }
>>>>>>         if (needsTextLayout) {
>>>>>>             TextLayout layout = createTextLayout(c, string,
>>>>>>                                     fm.getFont(), 
>>>>>> fm.getFontRenderContext());
>>>>>>             return (int) layout.getAdvance();
>>>>>>         } else {
>>>>>>             return fm.stringWidth(string);
>>>>>>         }
>>>>>>     }
>>>>>>
>>>>>> The only thing Swing is looking at is one TextAttribute and 
>>>>>> whether we have complex text.
>>>>>> That is not enough. This is an existing implementation issue but 
>>>>>> one we should fix here.
>>>>>> You need to examine all the methods for similar issues.
>>>>>   I created an enhancement for this:
>>>>>     JDK-8153662 
>>>>> SwingUtilities2.drawString()/getStringWidth()/clipString() should 
>>>>> use more text attributes
>>>>>       https://bugs.openjdk.java.net/browse/JDK-8153662
>>>>
>>>> you mean bug ? I upgraded it to P3 because it matters a lot more now
>>>> with this public API
>>>
>>>   I do not think that it is a bug because the main request was to 
>>> have methods which draw strings in the same way as it is done by 
>>> Swing L&Fs.
>>
>> It seems like a bug to me
>>
>>> This will allow to have custom UI component which mimic to the 
>>> standard L&Fs.
>>>
>>>   It is also can be considered from the following point of view: is 
>>> the proposed request to use more text attributes more important for 
>>> standard Swing L&F or for custom L&F.
>>>   It seems is not the first case because Swing lives with the 
>>> current implementation for the long time.
>>>   For the second case we provide the public TextUIDrawing interface 
>>> which a developer can override and use any text attributes that are 
>>> necessary.
>>>
>> We aren't talking about a separate API to provide text attributes, we 
>> are talking about the
>> ones that are part of the font and the implementation is not respecting.
>>
>> -phil.
>>
>



From alexandr.scherbatiy at oracle.com  Tue Apr 26 20:31:34 2016
From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy)
Date: Wed, 27 Apr 2016 00:31:34 +0400
Subject: <Swing Dev> [9] Review request for 8132119 Provide public API
 for text related methods in SwingUtilities2
In-Reply-To: <571FB41B.6010200@oracle.com>
References: <55E715A1.3090008@oracle.com> <55E72D3A.60807@oracle.com>
	<55ED586F.5070509@oracle.com> <55F6DC3C.60809@oracle.com>
	<5655D3AB.9050503@oracle.com> <5668051E.7090401@oracle.com>
	<5668E226.5000604@oracle.com> <5669646E.4070305@oracle.com>
	<566986FD.9020207@oracle.com> <5694F0C3.8020203@oracle.com>
	<5695572F.6070709@oracle.com> <56966730.7000701@oracle.com>
	<5698C71A.80703@oracle.com> <56991ED9.5030302@oracle.com>
	<569963B6.2050604@oracle.com> <56A5C40B.7010107@oracle.com>
	<CAM6ZMz8iEFQQtSb_bAVU5eUH=J=HapvKq3+Ana4pPxueJD1bNg@mail.gmail.com>
	<56AB8A94.2070404@oracle.com> <56EC2389.3020507@oracle.com>
	<56F38B0B.3060700@oracle.com> <56F3F13A.9000808@oracle.com>
	<56F3F83C.3010706@oracle.com> <56FD791E.1050707@oracle.com>
	<5705705C.2010007@oracle.com> <570C3370.1090702@oracle.com>
	<5715E767.5000409@oracle.com> <571FA7A9.6060105@oracle.com>
	<571FB2C3.10808@oracle.com> <571FB41B.6010200@oracle.com>
Message-ID: <571FD026.2070006@oracle.com>

On 26/04/16 22:31, Phil Race wrote:
> On 04/26/2016 11:26 AM, Alexandr Scherbatiy wrote:
>> On 4/26/2016 8:38 PM, Phil Race wrote:
>>> On 04/19/2016 01:08 AM, Alexandr Scherbatiy wrote:
>>>> On 4/11/2016 4:29 PM, Philip Race wrote:
>>>>>
>>>>>
>>>>> On 4/6/16, 1:23 PM, Alexander Scherbatiy wrote:
>>>>>>
>>>>>> Hello,
>>>>>>
>>>>>> Could you review the updated fix:
>>>>>>   http://cr.openjdk.java.net/~alexsch/8132119/webrev.09
>>>>>>
>>>>>>  - TextUIDrawing interface and its default implementaion 
>>>>>> BasicTextUIDrawing class are added
>>>>>>  - font metrics argument description is updated
>>>>>>
>>>>>> On 31/03/16 23:23, Phil Race wrote:
>>>>>>> Another webrev where you have to slip past 40_ files to get to 
>>>>>>> the two that really matter :-)
>>>>>>> I would have put SwingUtilities2.java and TextUIDrawing.java as 
>>>>>>> the first files.
>>>>>>    Updated.
>>>>>>>
>>>>>>>
>>>>>>> Some of what I have to say here is more along the lines of 
>>>>>>> things to think
>>>>>>> about rather than things that are wrong .. but there are also 
>>>>>>> maybe some things
>>>>>>> that need to be fixed.
>>>>>>>
>>>>>>> Is javax.swing.plaf really the right package for the new class ?
>>>>>>> I suppose it is for the use by the UI classes so maybe its right.
>>>>>>>
>>>>>>> Should the methods be taking "double" instead of "int" for 
>>>>>>> location ?
>>>>>>> This means the measurement APIs too.
>>>>>>> None of the JDK 1.2 text APIs use ints. That is all 1.0 legacy.
>>>>>>> So if Swing internally wants to use ints that is OK but maybe 
>>>>>>> the API
>>>>>>> should be floating point (double).
>>>>>>   The provided methods use Graphics as argument which only has 
>>>>>> drawString(String, int, int) method.
>>>>>>   If it is possible it is better to add the methods with float 
>>>>>> arguments and Graphics2D later.
>>>>>>
>>>>>>> Would that  help hi-dpi at all ?
>>>>>>   The hi-dpi support mostly does not require changes in Swing. 
>>>>>> What it does just scales graphics using default transform from 
>>>>>> graphics configuration.
>>>>>
>>>>> Yes, but in another bug you are dealing with a problem positioning
>>>>> the caret because of (somewhat) similar issues where coordinates 
>>>>> have been
>>>>> rounded to an integral. A floating point value allows you to say that
>>>>> this is 25.5 in user-space, even it if is 51.0 in device space.
>>>>
>>>>    It needs some more investigation.
>>>>
>>>>    What I have now is Swing uses font metrics to calculate a string 
>>>> width (FontMetrics.charsWidth(...)) which sums up float char values.
>>>>    The difference between font metrics used by Swing and font 
>>>> metrics from graphics passed to paint method is that the fist has 
>>>> null frc.tx matrix and the second one has a matrix with scales 2 on 
>>>> HiDPI display.
>>>>    The returned char width by the font metrics with null transform 
>>>> has value 7 for char 'a' (linear advance is 6.67 and xAdvance is 7).
>>>>    The char width for the font metrics with scaled transform is 6.5 
>>>> for the same font and char.  FileFontStrike requests glyph metrics 
>>>> and gets linear advance  13.35 (dev transform is taken into 
>>>> account) xAdvance  13 -  and apply the reverse transform. The 
>>>> result is 13 / 2  = 6.5.
>>>>
>>>>   And this bothers me because a result for applying the tx 
>>>> transform and inverting it is different than just use the identity 
>>>> transform. There are definitely problems with advance rounding but 
>>>> it seems they are placed out of the Swing area.
>>>>
>>>
>>>  I am not sure if you are implying a bug in the font code, but there 
>>> is none that I see
>>> from the above.
>>>
>>> There are several distinct issues here
>>> 1) You must specify the device transform, unless you are requesting 
>>> and using linear advances.
>>> 2) Linear advance is not generally used by Swing since it implies 
>>> unhinted text
>>> 3) Rounding of advances back to user space is OK in the case of 
>>> hinted advances and
>>>     identity transform - ie the traditional Swing case - but in the 
>>> case like that you describe
>>>     where the device pixel advance is 13 for a (2.0,2.0) device 
>>> scale then the translation
>>>     back to user space can't express that accurately if it only has 
>>> int to work with,
>>>
>>> If Swing is not using the same device transform in calculating the 
>>> advance as it is when
>>> drawing then that is a bug . That was the point of the comment we 
>>> added below about
>>> obtaining the correct FontMetrics .. our L&Fs should be doing that 
>>> as well as admonishing
>>> others to do so.
>>
>>      It is true that Swing uses FontRenderingContext which does not 
>> take the graphics configuration transform into account.
>>
>>     However, there are use case which should be considered:
>>
>>     Using graphics configuration transform in Swing 
>> FontRenderingContext leads that text component size will depend on 
>> the graphics device.
>>
>>     Let's take an a frame which has some text components placed in 
>> one row. Moving a frame from a non-HiDPI display to HiDPI display can 
>> lead that the size of text components can be changed and they will be 
>> rearranged in two rows.
>>     The same can be applicable for printing. Printing a text 
>> component from HiDPI display can lead that text will be shorter or 
>> longer than component bounds on a page.
>
> Indeed .. and there have been bugs on this where Swing text is clipped 
> when printed.
> Sadly I don't believe the bug tail from that has been completely 
> squashed.
>
>>
>>    There is one more case. A text component before it is added to a 
>> frame does not know about device where it will be shown.
>>    So the following is possible:
>>     -----------------
>>         JTextField textField = new JTextField("ABC");
>>         int width1 = textField.getWidth(); // no graphics 
>> configuration is provided, frc Tx is identity
>>         frame.add(textField);
>>         int width2 = textField.getWidth(); // frc Tx is 2 on HiDPI 
>> display
>>     -----------------
>> Now it is possible that width1 is not equal to width2.
>
> Absolutely true. And it is something Swing needs to handle.

   Even more, it is not will be possible to rely on the fact that width 
of number of chars is just sum of each char width.

   For example, on graphics configuration with transform 2 the glyph 
xAdvance can be 13 and the char width in user space will be calculated 
as 13 / 2 = 6.5.
   FontMetrics. charWidth('a') will return 7 and charsWidth(array of 10 
'a' ) will be 65 wich is not 7 * 10.


   Thanks,
   Alexandr.

>
> -phil.
>
>>
>>    Thanks,
>>    Alexandr.
>>
>>>
>>>
>>>>>
>>>>>>
>>>>>>> I suppose it would add over-head since all the existing code 
>>>>>>> uses int
>>>>>>> and we are no worse off and can add double methods later if we 
>>>>>>> want to.
>>>>>>>
>>>>>>>
>>>>>>> Regarding FontMetrics we need to add a caution that is must be a 
>>>>>>> FontMetrics
>>>>>>> *obtained from the correct font and graphics*.
>>>>>>    Updated.
>>>>>>>
>>>>>>>
>>>>>>>  i.e what about attributes on the font such as "tracking" ?
>>>>>>> or on the graphics such as FRACTIONALMETRICS
>>>>>>> It looks like Swing might already fail if that were used.
>>>>>>>
>>>>>>> Look at this code :-
>>>>>>>
>>>>>>>    public static int stringWidth(JComponent c, FontMetrics fm, 
>>>>>>> String string){
>>>>>>>         if (string == null || string.equals("")) {
>>>>>>>             return 0;
>>>>>>>         }
>>>>>>>         boolean needsTextLayout = ((c != null) &&
>>>>>>> (c.getClientProperty(TextAttribute.NUMERIC_SHAPING) != null));
>>>>>>>         if (needsTextLayout) {
>>>>>>>             synchronized(charsBufferLock) {
>>>>>>>                 int length = syncCharsBuffer(string);
>>>>>>>                 needsTextLayout = isComplexLayout(charsBuffer, 
>>>>>>> 0, length);
>>>>>>>             }
>>>>>>>         }
>>>>>>>         if (needsTextLayout) {
>>>>>>>             TextLayout layout = createTextLayout(c, string,
>>>>>>>                                     fm.getFont(), 
>>>>>>> fm.getFontRenderContext());
>>>>>>>             return (int) layout.getAdvance();
>>>>>>>         } else {
>>>>>>>             return fm.stringWidth(string);
>>>>>>>         }
>>>>>>>     }
>>>>>>>
>>>>>>> The only thing Swing is looking at is one TextAttribute and 
>>>>>>> whether we have complex text.
>>>>>>> That is not enough. This is an existing implementation issue but 
>>>>>>> one we should fix here.
>>>>>>> You need to examine all the methods for similar issues.
>>>>>>   I created an enhancement for this:
>>>>>>     JDK-8153662 
>>>>>> SwingUtilities2.drawString()/getStringWidth()/clipString() should 
>>>>>> use more text attributes
>>>>>>       https://bugs.openjdk.java.net/browse/JDK-8153662
>>>>>
>>>>> you mean bug ? I upgraded it to P3 because it matters a lot more now
>>>>> with this public API
>>>>
>>>>   I do not think that it is a bug because the main request was to 
>>>> have methods which draw strings in the same way as it is done by 
>>>> Swing L&Fs.
>>>
>>> It seems like a bug to me
>>>
>>>> This will allow to have custom UI component which mimic to the 
>>>> standard L&Fs.
>>>>
>>>>   It is also can be considered from the following point of view: is 
>>>> the proposed request to use more text attributes more important for 
>>>> standard Swing L&F or for custom L&F.
>>>>   It seems is not the first case because Swing lives with the 
>>>> current implementation for the long time.
>>>>   For the second case we provide the public TextUIDrawing interface 
>>>> which a developer can override and use any text attributes that are 
>>>> necessary.
>>>>
>>> We aren't talking about a separate API to provide text attributes, 
>>> we are talking about the
>>> ones that are part of the font and the implementation is not 
>>> respecting.
>>>
>>> -phil.
>>>
>>
>

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

From Sergey.Bylokhov at oracle.com  Tue Apr 26 20:39:01 2016
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Tue, 26 Apr 2016 23:39:01 +0300
Subject: <Swing Dev> [9] Review request for 8132119 Provide public API
 for text related methods in SwingUtilities2
In-Reply-To: <571FD026.2070006@oracle.com>
References: <55E715A1.3090008@oracle.com> <55E72D3A.60807@oracle.com>
	<55ED586F.5070509@oracle.com> <55F6DC3C.60809@oracle.com>
	<5655D3AB.9050503@oracle.com> <5668051E.7090401@oracle.com>
	<5668E226.5000604@oracle.com> <5669646E.4070305@oracle.com>
	<566986FD.9020207@oracle.com> <5694F0C3.8020203@oracle.com>
	<5695572F.6070709@oracle.com> <56966730.7000701@oracle.com>
	<5698C71A.80703@oracle.com> <56991ED9.5030302@oracle.com>
	<569963B6.2050604@oracle.com> <56A5C40B.7010107@oracle.com>
	<CAM6ZMz8iEFQQtSb_bAVU5eUH=J=HapvKq3+Ana4pPxueJD1bNg@mail.gmail.com>
	<56AB8A94.2070404@oracle.com> <56EC2389.3020507@oracle.com>
	<56F38B0B.3060700@oracle.com> <56F3F13A.9000808@oracle.com>
	<56F3F83C.3010706@oracle.com> <56FD791E.1050707@oracle.com>
	<5705705C.2010007@oracle.com> <570C3370.1090702@oracle.com>
	<5715E767.5000409@oracle.com> <571FA7A9.6060105@oracle.com>
	<571FB2C3.10808@oracle.com> <571FB41B.6010200@oracle.com>
	<571FD026.2070006@oracle.com>
Message-ID: <571FD1E5.9030601@oracle.com>

On 26.04.16 23:31, Alexander Scherbatiy wrote:
>>> Now it is possible that width1 is not equal to width2.
>>
>> Absolutely true. And it is something Swing needs to handle.
>
>    Even more, it is not will be possible to rely on the fact that width
> of number of chars is just sum of each char width.
>
>    For example, on graphics configuration with transform 2 the glyph
> xAdvance can be 13 and the char width in user space will be calculated
> as 13 / 2 = 6.5.
>    FontMetrics. charWidth('a') will return 7 and charsWidth(array of 10
> 'a' ) will be 65 wich is not 7 * 10.

13 / 2 = 6.5 is a fractional data in the user's space and actually such 
data is a "bug" when the fractional metrics are off. This was discussed 
a few times when this bug was fixed on OSX. and CStrike code on osx was 
changed to handle fraction on/off in terms of user's space(not the 
actual device space=pixels). I guess there is no other solution other 
than that.


-- 
Best regards, Sergey.


From philip.race at oracle.com  Tue Apr 26 21:34:16 2016
From: philip.race at oracle.com (Phil Race)
Date: Tue, 26 Apr 2016 14:34:16 -0700
Subject: <Swing Dev> [9] Review request for 8132119 Provide public API
 for text related methods in SwingUtilities2
In-Reply-To: <571FD1E5.9030601@oracle.com>
References: <55E715A1.3090008@oracle.com> <55E72D3A.60807@oracle.com>
	<55ED586F.5070509@oracle.com> <55F6DC3C.60809@oracle.com>
	<5655D3AB.9050503@oracle.com> <5668051E.7090401@oracle.com>
	<5668E226.5000604@oracle.com> <5669646E.4070305@oracle.com>
	<566986FD.9020207@oracle.com> <5694F0C3.8020203@oracle.com>
	<5695572F.6070709@oracle.com> <56966730.7000701@oracle.com>
	<5698C71A.80703@oracle.com> <56991ED9.5030302@oracle.com>
	<569963B6.2050604@oracle.com> <56A5C40B.7010107@oracle.com>
	<CAM6ZMz8iEFQQtSb_bAVU5eUH=J=HapvKq3+Ana4pPxueJD1bNg@mail.gmail.com>
	<56AB8A94.2070404@oracle.com> <56EC2389.3020507@oracle.com>
	<56F38B0B.3060700@oracle.com> <56F3F13A.9000808@oracle.com>
	<56F3F83C.3010706@oracle.com> <56FD791E.1050707@oracle.com>
	<5705705C.2010007@oracle.com> <570C3370.1090702@oracle.com>
	<5715E767.5000409@oracle.com> <571FA7A9.6060105@oracle.com>
	<571FB2C3.10808@oracle.com> <571FB41B.6010200@oracle.com>
	<571FD026.2070006@oracle.com> <571FD1E5.9030601@oracle.com>
Message-ID: <571FDED8.5070800@oracle.com>

On 04/26/2016 01:39 PM, Sergey Bylokhov wrote:
> On 26.04.16 23:31, Alexander Scherbatiy wrote:
>>>> Now it is possible that width1 is not equal to width2.
>>>
>>> Absolutely true. And it is something Swing needs to handle.
>>
>>    Even more, it is not will be possible to rely on the fact that width
>> of number of chars is just sum of each char width.
>>
>>    For example, on graphics configuration with transform 2 the glyph
>> xAdvance can be 13 and the char width in user space will be calculated
>> as 13 / 2 = 6.5.
>>    FontMetrics. charWidth('a') will return 7 and charsWidth(array of 10
>> 'a' ) will be 65 wich is not 7 * 10.
>
> 13 / 2 = 6.5 is a fractional data in the user's space and actually 
> such data is a "bug" when the fractional metrics are off. This was 
> discussed a few times when this bug was fixed on OSX. and CStrike code 
> on osx was changed to handle fraction on/off in terms of user's 
> space(not the actual device space=pixels). I guess there is no other 
> solution other than that.
>
>

Fractional metrics being "off" does not mean that *user space* advances 
need to be integers,
it refers to *device* space advances. Of course if your API does not 
support floats you have a
problem - particularly if - you are character advance adding in which 
case it is better to ask the
font system for the overall advance of the text.
https://docs.oracle.com/javase/8/docs/api/java/awt/RenderingHints.html#KEY_FRACTIONALMETRICS

-phil.




From Sergey.Bylokhov at oracle.com  Tue Apr 26 22:28:33 2016
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Wed, 27 Apr 2016 01:28:33 +0300
Subject: <Swing Dev> [9] Review request for 8132119 Provide public API
 for text related methods in SwingUtilities2
In-Reply-To: <571FDED8.5070800@oracle.com>
References: <55E715A1.3090008@oracle.com> <55ED586F.5070509@oracle.com>
	<55F6DC3C.60809@oracle.com> <5655D3AB.9050503@oracle.com>
	<5668051E.7090401@oracle.com> <5668E226.5000604@oracle.com>
	<5669646E.4070305@oracle.com> <566986FD.9020207@oracle.com>
	<5694F0C3.8020203@oracle.com> <5695572F.6070709@oracle.com>
	<56966730.7000701@oracle.com> <5698C71A.80703@oracle.com>
	<56991ED9.5030302@oracle.com> <569963B6.2050604@oracle.com>
	<56A5C40B.7010107@oracle.com>
	<CAM6ZMz8iEFQQtSb_bAVU5eUH=J=HapvKq3+Ana4pPxueJD1bNg@mail.gmail.com>
	<56AB8A94.2070404@oracle.com> <56EC2389.3020507@oracle.com>
	<56F38B0B.3060700@oracle.com> <56F3F13A.9000808@oracle.com>
	<56F3F83C.3010706@oracle.com> <56FD791E.1050707@oracle.com>
	<5705705C.2010007@oracle.com> <570C3370.1090702@oracle.com>
	<5715E767.5000409@oracle.com> <571FA7A9.6060105@oracle.com>
	<571FB2C3.10808@oracle.com> <571FB41B.6010200@oracle.com>
	<571FD026.2070006@oracle.com> <571FD1E5.9030601@oracle.com>
	<571FDED8.5070800@oracle.com>
Message-ID: <571FEB91.7080401@oracle.com>

On 27.04.16 0:34, Phil Race wrote:
> Fractional metrics being "off" does not mean that *user space* advances
> need to be integers,
> it refers to *device* space advances. Of course if your API does not
> support floats you have a
> problem - particularly if - you are character advance adding in which
> case it is better to ask the
> font system for the overall advance of the text.
> https://docs.oracle.com/javase/8/docs/api/java/awt/RenderingHints.html#KEY_FRACTIONALMETRICS

The documentation says that in case of "fm-off" the "simplified system 
based on integer device positions is typically used" + "rounding advance 
widths for rasterized glyphs to integer distances", it does not say that 
the "integer distance" should be rounded to the nearest device/pixel. It 
says that "rounding operations as the high quality and very precise 
definition of the shape and metrics of the character glyphs must be 
matched to discrete device pixels" I guess we should confirm the 
specification because results of the fix will be "discrete number of 
device pixels", isn't it?

-- 
Best regards, Sergey.


From Sergey.Bylokhov at oracle.com  Tue Apr 26 22:38:48 2016
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Wed, 27 Apr 2016 01:38:48 +0300
Subject: <Swing Dev> [9] Review request for 8132119 Provide public API
 for text related methods in SwingUtilities2
In-Reply-To: <571FEB91.7080401@oracle.com>
References: <55E715A1.3090008@oracle.com> <55F6DC3C.60809@oracle.com>
	<5655D3AB.9050503@oracle.com> <5668051E.7090401@oracle.com>
	<5668E226.5000604@oracle.com> <5669646E.4070305@oracle.com>
	<566986FD.9020207@oracle.com> <5694F0C3.8020203@oracle.com>
	<5695572F.6070709@oracle.com> <56966730.7000701@oracle.com>
	<5698C71A.80703@oracle.com> <56991ED9.5030302@oracle.com>
	<569963B6.2050604@oracle.com> <56A5C40B.7010107@oracle.com>
	<CAM6ZMz8iEFQQtSb_bAVU5eUH=J=HapvKq3+Ana4pPxueJD1bNg@mail.gmail.com>
	<56AB8A94.2070404@oracle.com> <56EC2389.3020507@oracle.com>
	<56F38B0B.3060700@oracle.com> <56F3F13A.9000808@oracle.com>
	<56F3F83C.3010706@oracle.com> <56FD791E.1050707@oracle.com>
	<5705705C.2010007@oracle.com> <570C3370.1090702@oracle.com>
	<5715E767.5000409@oracle.com> <571FA7A9.6060105@oracle.com>
	<571FB2C3.10808@oracle.com> <571FB41B.6010200@oracle.com>
	<571FD026.2070006@oracle.com> <571FD1E5.9030601@oracle.com>
	<571FDED8.5070800@oracle.com> <571FEB91.7080401@oracle.com>
Message-ID: <571FEDF8.7010106@oracle.com>

On 27.04.16 1:28, Sergey Bylokhov wrote:
> On 27.04.16 0:34, Phil Race wrote:
>> Fractional metrics being "off" does not mean that *user space* advances
>> need to be integers,
>> it refers to *device* space advances.

FYI, Review of the previous fix:
http://mail.openjdk.java.net/pipermail/2d-dev/2013-July/003527.html

-- 
Best regards, Sergey.


From philip.race at oracle.com  Tue Apr 26 22:50:42 2016
From: philip.race at oracle.com (Phil Race)
Date: Tue, 26 Apr 2016 15:50:42 -0700
Subject: <Swing Dev> [9] Review request for 8132119 Provide public API
 for text related methods in SwingUtilities2
In-Reply-To: <571FEB91.7080401@oracle.com>
References: <55E715A1.3090008@oracle.com> <55F6DC3C.60809@oracle.com>
	<5655D3AB.9050503@oracle.com> <5668051E.7090401@oracle.com>
	<5668E226.5000604@oracle.com> <5669646E.4070305@oracle.com>
	<566986FD.9020207@oracle.com> <5694F0C3.8020203@oracle.com>
	<5695572F.6070709@oracle.com> <56966730.7000701@oracle.com>
	<5698C71A.80703@oracle.com> <56991ED9.5030302@oracle.com>
	<569963B6.2050604@oracle.com> <56A5C40B.7010107@oracle.com>
	<CAM6ZMz8iEFQQtSb_bAVU5eUH=J=HapvKq3+Ana4pPxueJD1bNg@mail.gmail.com>
	<56AB8A94.2070404@oracle.com> <56EC2389.3020507@oracle.com>
	<56F38B0B.3060700@oracle.com> <56F3F13A.9000808@oracle.com>
	<56F3F83C.3010706@oracle.com> <56FD791E.1050707@oracle.com>
	<5705705C.2010007@oracle.com> <570C3370.1090702@oracle.com>
	<5715E767.5000409@oracle.com> <571FA7A9.6060105@oracle.com>
	<571FB2C3.10808@oracle.com> <571FB41B.6010200@oracle.com>
	<571FD026.2070006@oracle.com> <571FD1E5.9030601@oracle.com>
	<571FDED8.5070800@oracle.com> <571FEB91.7080401@oracle.com>
Message-ID: <571FF0C2.5080901@oracle.com>

Glyphs are always rasterised in device space so it does mean device space.
The identity transform therefore happens to always return a user space
advance is that is an integer, but it is not bound to be so under any 
other transform.

-phil.

On 04/26/2016 03:28 PM, Sergey Bylokhov wrote:
> On 27.04.16 0:34, Phil Race wrote:
>> Fractional metrics being "off" does not mean that *user space* advances
>> need to be integers,
>> it refers to *device* space advances. Of course if your API does not
>> support floats you have a
>> problem - particularly if - you are character advance adding in which
>> case it is better to ask the
>> font system for the overall advance of the text.
>> https://docs.oracle.com/javase/8/docs/api/java/awt/RenderingHints.html#KEY_FRACTIONALMETRICS 
>>
>
> The documentation says that in case of "fm-off" the "simplified system 
> based on integer device positions is typically used" + "rounding 
> advance widths for rasterized glyphs to integer distances", it does 
> not say that the "integer distance" should be rounded to the nearest 
> device/pixel. It says that "rounding operations as the high quality 
> and very precise definition of the shape and metrics of the character 
> glyphs must be matched to discrete device pixels" I guess we should 
> confirm the specification because results of the fix will be "discrete 
> number of device pixels", isn't it?
>



From Sergey.Bylokhov at oracle.com  Tue Apr 26 23:49:00 2016
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Wed, 27 Apr 2016 02:49:00 +0300
Subject: <Swing Dev> [9] Review request for 8132119 Provide public API
 for text related methods in SwingUtilities2
In-Reply-To: <571FF0C2.5080901@oracle.com>
References: <55E715A1.3090008@oracle.com> <5655D3AB.9050503@oracle.com>
	<5668051E.7090401@oracle.com> <5668E226.5000604@oracle.com>
	<5669646E.4070305@oracle.com> <566986FD.9020207@oracle.com>
	<5694F0C3.8020203@oracle.com> <5695572F.6070709@oracle.com>
	<56966730.7000701@oracle.com> <5698C71A.80703@oracle.com>
	<56991ED9.5030302@oracle.com> <569963B6.2050604@oracle.com>
	<56A5C40B.7010107@oracle.com>
	<CAM6ZMz8iEFQQtSb_bAVU5eUH=J=HapvKq3+Ana4pPxueJD1bNg@mail.gmail.com>
	<56AB8A94.2070404@oracle.com> <56EC2389.3020507@oracle.com>
	<56F38B0B.3060700@oracle.com> <56F3F13A.9000808@oracle.com>
	<56F3F83C.3010706@oracle.com> <56FD791E.1050707@oracle.com>
	<5705705C.2010007@oracle.com> <570C3370.1090702@oracle.com>
	<5715E767.5000409@oracle.com> <571FA7A9.6060105@oracle.com>
	<571FB2C3.10808@oracle.com> <571FB41B.6010200@oracle.com>
	<571FD026.2070006@oracle.com> <571FD1E5.9030601@oracle.com>
	<571FDED8.5070800@oracle.com> <571FEB91.7080401@oracle.com>
	<571FF0C2.5080901@oracle.com>
Message-ID: <571FFE6C.2030908@oracle.com>

On 27.04.16 1:50, Phil Race wrote:
> Glyphs are always rasterised in device space so it does mean device space.

I don't argue with it, the question is how to round.

> The identity transform therefore happens to always return a user space
> advance is that is an integer, but it is not bound to be so under any
> other transform.

I am not sure that this is correct. The simple example:

BufferedImage bi = new BufferedImage(width, height,TYPE_INT_ARGB);
int length = g2d.getFontMetrics().stringWidth(TEXT);
Graphics2D g2d = bi.createGraphics();
g2d.scale(2, 2);
length = g2d.getFontMetrics().stringWidth(TEXT);

In what space will be the length? I assume that this is the user space. 
Note that if in the second time we get 13 pixels we will round it to 7 
(but rendering will be done to 6.5 * 2 = 13). My suggestion in the fix 
is to make this round on the lower level and use the same values as 
stringWidth() and during rendering.

>
> -phil.
>
> On 04/26/2016 03:28 PM, Sergey Bylokhov wrote:
>> On 27.04.16 0:34, Phil Race wrote:
>>> Fractional metrics being "off" does not mean that *user space* advances
>>> need to be integers,
>>> it refers to *device* space advances. Of course if your API does not
>>> support floats you have a
>>> problem - particularly if - you are character advance adding in which
>>> case it is better to ask the
>>> font system for the overall advance of the text.
>>> https://docs.oracle.com/javase/8/docs/api/java/awt/RenderingHints.html#KEY_FRACTIONALMETRICS
>>>
>>
>> The documentation says that in case of "fm-off" the "simplified system
>> based on integer device positions is typically used" + "rounding
>> advance widths for rasterized glyphs to integer distances", it does
>> not say that the "integer distance" should be rounded to the nearest
>> device/pixel. It says that "rounding operations as the high quality
>> and very precise definition of the shape and metrics of the character
>> glyphs must be matched to discrete device pixels" I guess we should
>> confirm the specification because results of the fix will be "discrete
>> number of device pixels", isn't it?
>>
>


-- 
Best regards, Sergey.


From philip.race at oracle.com  Wed Apr 27 03:17:13 2016
From: philip.race at oracle.com (Philip Race)
Date: Tue, 26 Apr 2016 20:17:13 -0700
Subject: <Swing Dev> [9] Review request for 8132119 Provide public API
 for text related methods in SwingUtilities2
In-Reply-To: <571FFE6C.2030908@oracle.com>
References: <55E715A1.3090008@oracle.com> <5668051E.7090401@oracle.com>
	<5668E226.5000604@oracle.com> <5669646E.4070305@oracle.com>
	<566986FD.9020207@oracle.com> <5694F0C3.8020203@oracle.com>
	<5695572F.6070709@oracle.com> <56966730.7000701@oracle.com>
	<5698C71A.80703@oracle.com> <56991ED9.5030302@oracle.com>
	<569963B6.2050604@oracle.com> <56A5C40B.7010107@oracle.com>
	<CAM6ZMz8iEFQQtSb_bAVU5eUH=J=HapvKq3+Ana4pPxueJD1bNg@mail.gmail.com>
	<56AB8A94.2070404@oracle.com> <56EC2389.3020507@oracle.com>
	<56F38B0B.3060700@oracle.com> <56F3F13A.9000808@oracle.com>
	<56F3F83C.3010706@oracle.com> <56FD791E.1050707@oracle.com>
	<5705705C.2010007@oracle.com> <570C3370.1090702@oracle.com>
	<5715E767.5000409@oracle.com> <571FA7A9.6060105@oracle.com>
	<571FB2C3.10808@oracle.com> <571FB41B.6010200@oracle.com>
	<571FD026.2070006@oracle.com> <571FD1E5.9030601@oracle.com>
	<571FDED8.5070800@oracle.com> <571FEB91.7080401@oracle.com>
	<571FF0C2.5080901@oracle.com> <571FFE6C.2030908@oracle.com>
Message-ID: <57202F39.7000403@oracle.com>

Applications cannot change the device transform and expect the same user 
space
metrics unless they specify fractional metrics to be ON.

In your example below you may already have a scaled graphics context
if you were printing (for example).

If you want no change to the user space positions or [as also implied] 
shapes of the glyphs
as the transform changes then you are asking for text that will not look
right at other resolutions. Printed text will look poorly spaced.

Changing what happens in the font system is not an option since it
will break many applications - even if it were the right thing to do - 
which it is not.

-phil.





On 4/26/16, 4:49 PM, Sergey Bylokhov wrote:
> On 27.04.16 1:50, Phil Race wrote:
>> Glyphs are always rasterised in device space so it does mean device 
>> space.
>
> I don't argue with it, the question is how to round.
>
>> The identity transform therefore happens to always return a user space
>> advance is that is an integer, but it is not bound to be so under any
>> other transform.
>
> I am not sure that this is correct. The simple example:
>
> BufferedImage bi = new BufferedImage(width, height,TYPE_INT_ARGB);
> int length = g2d.getFontMetrics().stringWidth(TEXT);
> Graphics2D g2d = bi.createGraphics();
> g2d.scale(2, 2);
> length = g2d.getFontMetrics().stringWidth(TEXT);
>
> In what space will be the length? I assume that this is the user 
> space. Note that if in the second time we get 13 pixels we will round 
> it to 7 (but rendering will be done to 6.5 * 2 = 13). My suggestion in 
> the fix is to make this round on the lower level and use the same 
> values as stringWidth() and during rendering.
>
>>
>> -phil.
>>
>> On 04/26/2016 03:28 PM, Sergey Bylokhov wrote:
>>> On 27.04.16 0:34, Phil Race wrote:
>>>> Fractional metrics being "off" does not mean that *user space* 
>>>> advances
>>>> need to be integers,
>>>> it refers to *device* space advances. Of course if your API does not
>>>> support floats you have a
>>>> problem - particularly if - you are character advance adding in which
>>>> case it is better to ask the
>>>> font system for the overall advance of the text.
>>>> https://docs.oracle.com/javase/8/docs/api/java/awt/RenderingHints.html#KEY_FRACTIONALMETRICS 
>>>>
>>>>
>>>
>>> The documentation says that in case of "fm-off" the "simplified system
>>> based on integer device positions is typically used" + "rounding
>>> advance widths for rasterized glyphs to integer distances", it does
>>> not say that the "integer distance" should be rounded to the nearest
>>> device/pixel. It says that "rounding operations as the high quality
>>> and very precise definition of the shape and metrics of the character
>>> glyphs must be matched to discrete device pixels" I guess we should
>>> confirm the specification because results of the fix will be "discrete
>>> number of device pixels", isn't it?
>>>
>>
>
>


From semyon.sadetsky at oracle.com  Wed Apr 27 07:11:18 2016
From: semyon.sadetsky at oracle.com (Semyon Sadetsky)
Date: Wed, 27 Apr 2016 10:11:18 +0300
Subject: <Swing Dev> [9] Review request for 8046031: UI of Java Web
 Start app isn't updated when changing Windows theme
In-Reply-To: <571F6207.3040101@oracle.com>
References: <5718D41D.7090104@oracle.com> <5718DBF1.7090407@oracle.com>
	<57192E19.40107@oracle.com> <571A5152.2050907@oracle.com>
	<571E3086.5040200@oracle.com> <571E5A5D.4030401@oracle.com>
	<571F6207.3040101@oracle.com>
Message-ID: <57206616.8020006@oracle.com>



On 4/26/2016 3:41 PM, Sergey Bylokhov wrote:
> On 25.04.16 20:56, Semyon Sadetsky wrote:
>>
>>
>> On 4/25/2016 5:58 PM, Sergey Bylokhov wrote:
>>> Why it is odd? This code is called in the "propertyChange()" which
>>> executes on some EDT, each EDT is bound already to some specific
>>> Appcontext. Otherwise we should store all data inside this class per
>>> appcontext(since we don't do this I assume that we store this object
>>> per Appcontext). Plus I see it is used only in the WinLookAndFeel and
>>> the l&f itself is stored per appcontext also.
>> I see 4 at least:
>
> All of these are a private object fields in Windows l&F and the l&f is 
> stored per appcontext. what is the problem in these fields?
The problem is performance. They may trigger the property change and 
then update all context's UI's. The last is rather heavy operation, so 
if next property update request come and isUpdatePending() is true then 
the new overall UI update event is not posted.

--Semyon
>
>>
>>              this.themeActive = new
>> TriggerDesktopProperty("win.xpstyle.themeActive");
>>              this.dllName     = new
>> TriggerDesktopProperty("win.xpstyle.dllName");
>>              this.colorName   = new
>> TriggerDesktopProperty("win.xpstyle.colorName");
>>              this.sizeName    = new
>> TriggerDesktopProperty("win.xpstyle.sizeName");
>>
>> --Semyon
>>>
>>>> Putting the flag into the app scope protects from scheduling events
>>>> recursively
>>>>> If the Appcontext is necessary, then we should not use interned 
>>>>> string
>>>>> as a key, I suggest to use the simple new Object(), so it will not be
>>>>> accessible outside of this class.
>>>> This is a public field. Accessing it outside the class shouldn't be an
>>>> issue.
>>>
>>> I overlooked that it is public in my first email. Why? If it is not
>>> used outside of this class it should be private. Also the interned
>>> string will provide a way to access this data even if
>>> "com/sun/java/swing" package will be inaccessible. So it is better to
>>> use private key.
>>>
>>>>
>>>> --Semyon
>>>>>
>>>>> On 21.04.16 16:56, Alexandr Scherbatiy wrote:
>>>>>>
>>>>>>   The fix looks good to me.
>>>>>>
>>>>>>   Thanks,
>>>>>>   Alexandr.
>>>>>>
>>>>>> On 4/21/2016 6:22 AM, Semyon Sadetsky wrote:
>>>>>>> Hello,
>>>>>>>
>>>>>>> Please review fix for JDK9:
>>>>>>>
>>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8046031
>>>>>>> webrev: http://cr.openjdk.java.net/~ssadetsky/8046031/webrev.00/
>>>>>>>
>>>>>>> Under the Windoew LnF when the native Windows theme is changed some
>>>>>>> java frames remains unchanged if there are several application
>>>>>>> contexts. The thing is the DesktopProperty#updatePending flag that
>>>>>>> prevents to run more then one UI update operation is shared between
>>>>>>> different applications contexts while they may be updated with the
>>>>>>> property change concurrently from different EDT threads so they may
>>>>>>> loose the update.
>>>>>>> To avoid this mutual interference the updatePending is moved 
>>>>>>> from the
>>>>>>> global to the application context scope.
>>>>>>> The test would require to write native code so the issue is labeled
>>>>>>> noreg-hard.
>>>>>>>
>>>>>>> --Semyon
>>>>>>
>>>>>
>>>>>
>>>>
>>>
>>>
>>
>
>



From Sergey.Bylokhov at oracle.com  Wed Apr 27 11:58:08 2016
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Wed, 27 Apr 2016 14:58:08 +0300
Subject: <Swing Dev> [9] Review request for 8132119 Provide public API
 for text related methods in SwingUtilities2
In-Reply-To: <57202F39.7000403@oracle.com>
References: <55E715A1.3090008@oracle.com> <5668E226.5000604@oracle.com>
	<5669646E.4070305@oracle.com> <566986FD.9020207@oracle.com>
	<5694F0C3.8020203@oracle.com> <5695572F.6070709@oracle.com>
	<56966730.7000701@oracle.com> <5698C71A.80703@oracle.com>
	<56991ED9.5030302@oracle.com> <569963B6.2050604@oracle.com>
	<56A5C40B.7010107@oracle.com>
	<CAM6ZMz8iEFQQtSb_bAVU5eUH=J=HapvKq3+Ana4pPxueJD1bNg@mail.gmail.com>
	<56AB8A94.2070404@oracle.com> <56EC2389.3020507@oracle.com>
	<56F38B0B.3060700@oracle.com> <56F3F13A.9000808@oracle.com>
	<56F3F83C.3010706@oracle.com> <56FD791E.1050707@oracle.com>
	<5705705C.2010007@oracle.com> <570C3370.1090702@oracle.com>
	<5715E767.5000409@oracle.com> <571FA7A9.6060105@oracle.com>
	<571FB2C3.10808@oracle.com> <571FB41B.6010200@oracle.com>
	<571FD026.2070006@oracle.com> <571FD1E5.9030601@oracle.com>
	<571FDED8.5070800@oracle.com> <571FEB91.7080401@oracle.com>
	<571FF0C2.5080901@oracle.com> <571FFE6C.2030908@oracle.com>
	<57202F39.7000403@oracle.com>
Message-ID: <5720A950.8070808@oracle.com>

On 27.04.16 6:17, Philip Race wrote:
> Applications cannot change the device transform and expect the same user
> space
> metrics unless they specify fractional metrics to be ON.
>
> In your example below you may already have a scaled graphics context
> if you were printing (for example).

Do we have the difference between device scale, and full scale(device 
scale+user scale)? I guess we have only two transforms on the low level:
  - Font transform
  - Full transform(device + user).
So from the application point of view there is no difference the scale 
was changed by device or by the application.

> Changing what happens in the font system is not an option since it
> will break many applications - even if it were the right thing to do -
> which it is not.

I do not think that the spaces will be poor, especially if the new 
rounding will be closer to the correct values in floats.

>
> -phil.
>
>
>
>
>
> On 4/26/16, 4:49 PM, Sergey Bylokhov wrote:
>> On 27.04.16 1:50, Phil Race wrote:
>>> Glyphs are always rasterised in device space so it does mean device
>>> space.
>>
>> I don't argue with it, the question is how to round.
>>
>>> The identity transform therefore happens to always return a user space
>>> advance is that is an integer, but it is not bound to be so under any
>>> other transform.
>>
>> I am not sure that this is correct. The simple example:
>>
>> BufferedImage bi = new BufferedImage(width, height,TYPE_INT_ARGB);
>> int length = g2d.getFontMetrics().stringWidth(TEXT);
>> Graphics2D g2d = bi.createGraphics();
>> g2d.scale(2, 2);
>> length = g2d.getFontMetrics().stringWidth(TEXT);
>>
>> In what space will be the length? I assume that this is the user
>> space. Note that if in the second time we get 13 pixels we will round
>> it to 7 (but rendering will be done to 6.5 * 2 = 13). My suggestion in
>> the fix is to make this round on the lower level and use the same
>> values as stringWidth() and during rendering.
>>
>>>
>>> -phil.
>>>
>>> On 04/26/2016 03:28 PM, Sergey Bylokhov wrote:
>>>> On 27.04.16 0:34, Phil Race wrote:
>>>>> Fractional metrics being "off" does not mean that *user space*
>>>>> advances
>>>>> need to be integers,
>>>>> it refers to *device* space advances. Of course if your API does not
>>>>> support floats you have a
>>>>> problem - particularly if - you are character advance adding in which
>>>>> case it is better to ask the
>>>>> font system for the overall advance of the text.
>>>>> https://docs.oracle.com/javase/8/docs/api/java/awt/RenderingHints.html#KEY_FRACTIONALMETRICS
>>>>>
>>>>>
>>>>
>>>> The documentation says that in case of "fm-off" the "simplified system
>>>> based on integer device positions is typically used" + "rounding
>>>> advance widths for rasterized glyphs to integer distances", it does
>>>> not say that the "integer distance" should be rounded to the nearest
>>>> device/pixel. It says that "rounding operations as the high quality
>>>> and very precise definition of the shape and metrics of the character
>>>> glyphs must be matched to discrete device pixels" I guess we should
>>>> confirm the specification because results of the fix will be "discrete
>>>> number of device pixels", isn't it?
>>>>
>>>
>>
>>


-- 
Best regards, Sergey.


From philip.race at oracle.com  Wed Apr 27 16:55:29 2016
From: philip.race at oracle.com (Philip Race)
Date: Wed, 27 Apr 2016 09:55:29 -0700
Subject: <Swing Dev> Fwd: Re: JDK 9 pre-review of JDK-6850612: Deprecate
 Class.newInstance since it violates the checked exception language contract
In-Reply-To: <57f52e95-9485-1114-5314-cbdf1680709b@oracle.com>
References: <5718FEF7.1020807@oracle.com>
	<57f52e95-9485-1114-5314-cbdf1680709b@oracle.com>
Message-ID: <5720EF01.3070902@oracle.com>

Rather than adding all these annotations I would prefer that you do
what Stuart did with the boxed primitive constructor deprecation
where he disabled the deprecation checking on the desktop module
until we can clean it up. That one was done within about a week and
should be in dev in a few days ..

-phil

On 4/26/16, 9:45 AM, joe darcy wrote:
>
> Phil and other client reviewers,
>
> Please review this change from core libs which impacts client libs 
> implementations. In brief, deprecating a method in core reflection 
> requires uses of that method to have a 
> @SuppressWarnings("deprecation") annotation. The typical way to 
> minimize the scope of the deprecation is to declare a temporary 
> variable which can host the @SuppressWarnings annotation. The 
> alternative would have been to suppress the warning on the entire 
> method, which would allow addition use of deprecated methods to sneak in.
>
> http://cr.openjdk.java.net/~darcy/6850612.0/
>
> Thanks,
>
> -Joe
>
>
> -------- Forwarded Message --------
> Subject: 	Re: JDK 9 pre-review of JDK-6850612: Deprecate 
> Class.newInstance since it violates the checked exception language 
> contract
> Date: 	Thu, 21 Apr 2016 09:25:27 -0700
> From: 	joe darcy <joe.darcy at oracle.com>
> Organization: 	Oracle Corporation
> To: 	core-libs-dev <core-libs-dev at openjdk.java.net>
>
>
>
> Hello,
>
> After a generally positive reception, please review the webrev to
> implement the deprecation of Class.newInstance and the suppression of
> the resulting warnings:
>
>       http://cr.openjdk.java.net/~darcy/6850612.0/
>
> There are also some changes in the langtools repo; I'll send a separate
> review request for those changes to compiler-dev.
>
> I'll also forward this review request to other areas with affected code.
>
> Thanks,
>
> -Joe
>
> On 4/17/2016 10:31 AM, joe darcy wrote:
> >  Hello,
> >
> >  With talk of deprecation in the air [1], I thought it would be a fine
> >  time to examine one of the bugs on my list
> >
> >      JDK-6850612: Deprecate Class.newInstance since it violates the
> >  checked exception language contract
> >
> >  As the title of the bug implies, The Class.newInstance method
> >  knowingly violates the checking exception contract. This has long been
> >  documented in its specification:
> >
> >>  Note that this method propagates any exception thrown by the nullary
> >>  constructor, including a checked exception. Use of this method
> >>  effectively bypasses the compile-time exception checking that would
> >>  otherwise be performed by the compiler. The Constructor.newInstance
> >>  method avoids this problem by wrapping any exception thrown by the
> >>  constructor in a (checked) InvocationTargetException.
> >
> >  Roughly, the fix would be to turn the text of this note into the
> >  @deprecated text and to add a @Deprecated(since="9") annotation to the
> >  method. There are a few dozen uses of the method in the JDK that would
> >  have to be @SuppressWarning-ed or otherwise updated.
> >
> >  Thoughts on the appropriateness of deprecating this method at this time?
> >
> >  Comments on the bug have suggested that besides deprecating the
> >  method, a new method on Class could be introduced,
> >  newInstanceWithProperExceptionBehavior, that had the same signature
> >  but wrapped exceptions thrown by the constructor call in the same way
> >  Constructor.newInstance does.
> >
> >  Thanks,
> >
> >  -Joe
> >
> >  [1]
> >  http://mail.openjdk.java.net/pipermail/core-libs-dev/2016-April/040192.html
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/swing-dev/attachments/20160427/369f5b71/attachment.html>

From alexandr.scherbatiy at oracle.com  Wed Apr 27 20:41:19 2016
From: alexandr.scherbatiy at oracle.com (Alexandr Scherbatiy)
Date: Wed, 27 Apr 2016 23:41:19 +0300
Subject: <Swing Dev> [9] Review request for 8132119 Provide public API
 for text related methods in SwingUtilities2
In-Reply-To: <57202F39.7000403@oracle.com>
References: <55E715A1.3090008@oracle.com> <5668E226.5000604@oracle.com>
	<5669646E.4070305@oracle.com> <566986FD.9020207@oracle.com>
	<5694F0C3.8020203@oracle.com> <5695572F.6070709@oracle.com>
	<56966730.7000701@oracle.com> <5698C71A.80703@oracle.com>
	<56991ED9.5030302@oracle.com> <569963B6.2050604@oracle.com>
	<56A5C40B.7010107@oracle.com>
	<CAM6ZMz8iEFQQtSb_bAVU5eUH=J=HapvKq3+Ana4pPxueJD1bNg@mail.gmail.com>
	<56AB8A94.2070404@oracle.com> <56EC2389.3020507@oracle.com>
	<56F38B0B.3060700@oracle.com> <56F3F13A.9000808@oracle.com>
	<56F3F83C.3010706@oracle.com> <56FD791E.1050707@oracle.com>
	<5705705C.2010007@oracle.com> <570C3370.1090702@oracle.com>
	<5715E767.5000409@oracle.com> <571FA7A9.6060105@oracle.com>
	<571FB2C3.10808@oracle.com> <571FB41B.6010200@oracle.com>
	<571FD026.2070006@oracle.com> <571FD1E5.9030601@oracle.com>
	<571FDED8.5070800@oracle.com> <571FEB91.7080401@oracle.com>
	<571FF0C2.5080901@oracle.com> <571FFE6C.2030908@oracle.com>
	<57202F39.7000403@oracle.com>
Message-ID: <572123EF.3040002@oracle.com>



   I just want to highlight one more problem which happen even  font 
metrics with right transform are used.
   It refers to the text selection.

   Suppose there is a graphics with scale 2. The char 'a' advance can be 
13 in device space and 13 / 2 = 6.5 in user space.
   The task is to highlight a selected text in the middle of a string

   Let's the selected index will be 11. The x coordinate to draw the 
selected text is FontMetrics.charsWidth(chars, 0, index) = 72.
    The selected text drawn from this position will be shifted to the 
right because real x coordinate in user space is 6.5 * 11 = 71.5.
   This leads that text is jumping when it is selected and deselected.

   To properly draw a selected text in this case there should be API 
which allows both return float chars width and draw a text from float 
position.
   But we have only API which gets a chars width and draws a text from 
int position in the user space.

   Below is a code which illustrate the text selection issue.
   The image shows two strings which are selected from index 10 and 11. 
The second selection is shifted to the right:
http://cr.openjdk.java.net/~alexsch/8142966/images/text-selection.png

   ----------------------------
         int imgWidth = 400;
         int imgHeight = 150;

         BufferedImage buffImage = new BufferedImage(imgWidth, imgHeight,
                 BufferedImage.TYPE_INT_RGB);

         Graphics2D g = buffImage.createGraphics();
         g.setColor(Color.WHITE);
         g.fillRect(0, 0, imgWidth, imgHeight);

         int x = 10;
         int y1 = 20;
         int y2 = 40;

         g.scale(2, 2);
         String text = "aaaaaaaaaaaaaaaaaaaaaaaa";
         g.setColor(Color.BLUE);
         char[] chars = text.toCharArray();
         g.drawChars(chars, 0, chars.length, x, y1);
         g.drawChars(chars, 0, chars.length, x, y2);

         int selIndex = 10;
         int selNum = 6;

         FontMetrics fm = g.getFontMetrics(g.getFont());
         g.setColor(Color.RED);
         g.drawChars(chars, selIndex, selNum, x + fm.charsWidth(chars, 
0, selIndex), y1);
         selIndex++;
         g.drawChars(chars, selIndex, selNum, x + fm.charsWidth(chars, 
0, selIndex), y2);

         g.dispose();
   ----------------------------


On 4/27/2016 6:17 AM, Philip Race wrote:
> Applications cannot change the device transform and expect the same 
> user space
> metrics unless they specify fractional metrics to be ON.
>
> In your example below you may already have a scaled graphics context
> if you were printing (for example).
>
> If you want no change to the user space positions or [as also implied] 
> shapes of the glyphs
> as the transform changes then you are asking for text that will not look
> right at other resolutions. Printed text will look poorly spaced.
>
> Changing what happens in the font system is not an option since it
> will break many applications - even if it were the right thing to do - 
> which it is not.
>
> -phil.
>
>
> On 4/26/16, 4:49 PM, Sergey Bylokhov wrote:
>> On 27.04.16 1:50, Phil Race wrote:
>>> Glyphs are always rasterised in device space so it does mean device 
>>> space.
>>
>> I don't argue with it, the question is how to round.
>>
>>> The identity transform therefore happens to always return a user space
>>> advance is that is an integer, but it is not bound to be so under any
>>> other transform.
>>
>> I am not sure that this is correct. The simple example:
>>
>> BufferedImage bi = new BufferedImage(width, height,TYPE_INT_ARGB);
>> int length = g2d.getFontMetrics().stringWidth(TEXT);
>> Graphics2D g2d = bi.createGraphics();
>> g2d.scale(2, 2);
>> length = g2d.getFontMetrics().stringWidth(TEXT);
>>
>> In what space will be the length? I assume that this is the user 
>> space. Note that if in the second time we get 13 pixels we will round 
>> it to 7 (but rendering will be done to 6.5 * 2 = 13). My suggestion 
>> in the fix is to make this round on the lower level and use the same 
>> values as stringWidth() and during rendering.
>>
>>>
>>> -phil.
>>>
>>> On 04/26/2016 03:28 PM, Sergey Bylokhov wrote:
>>>> On 27.04.16 0:34, Phil Race wrote:
>>>>> Fractional metrics being "off" does not mean that *user space* 
>>>>> advances
>>>>> need to be integers,
>>>>> it refers to *device* space advances. Of course if your API does not
>>>>> support floats you have a
>>>>> problem - particularly if - you are character advance adding in which
>>>>> case it is better to ask the
>>>>> font system for the overall advance of the text.
>>>>> https://docs.oracle.com/javase/8/docs/api/java/awt/RenderingHints.html#KEY_FRACTIONALMETRICS 
>>>>>
>>>>>
>>>>
>>>> The documentation says that in case of "fm-off" the "simplified system
>>>> based on integer device positions is typically used" + "rounding
>>>> advance widths for rasterized glyphs to integer distances", it does
>>>> not say that the "integer distance" should be rounded to the nearest
>>>> device/pixel. It says that "rounding operations as the high quality
>>>> and very precise definition of the shape and metrics of the character
>>>> glyphs must be matched to discrete device pixels" I guess we should
>>>> confirm the specification because results of the fix will be "discrete
>>>> number of device pixels", isn't it?
>>>>
>>>
>>
>>



From philip.race at oracle.com  Wed Apr 27 23:03:01 2016
From: philip.race at oracle.com (Phil Race)
Date: Wed, 27 Apr 2016 16:03:01 -0700
Subject: <Swing Dev> [9] Review request for 8132119 Provide public API
 for text related methods in SwingUtilities2
In-Reply-To: <572123EF.3040002@oracle.com>
References: <55E715A1.3090008@oracle.com> <5669646E.4070305@oracle.com>
	<566986FD.9020207@oracle.com> <5694F0C3.8020203@oracle.com>
	<5695572F.6070709@oracle.com> <56966730.7000701@oracle.com>
	<5698C71A.80703@oracle.com> <56991ED9.5030302@oracle.com>
	<569963B6.2050604@oracle.com> <56A5C40B.7010107@oracle.com>
	<CAM6ZMz8iEFQQtSb_bAVU5eUH=J=HapvKq3+Ana4pPxueJD1bNg@mail.gmail.com>
	<56AB8A94.2070404@oracle.com> <56EC2389.3020507@oracle.com>
	<56F38B0B.3060700@oracle.com> <56F3F13A.9000808@oracle.com>
	<56F3F83C.3010706@oracle.com> <56FD791E.1050707@oracle.com>
	<5705705C.2010007@oracle.com> <570C3370.1090702@oracle.com>
	<5715E767.5000409@oracle.com> <571FA7A9.6060105@oracle.com>
	<571FB2C3.10808@oracle.com> <571FB41B.6010200@oracle.com>
	<571FD026.2070006@oracle.com> <571FD1E5.9030601@oracle.com>
	<571FDED8.5070800@oracle.com> <571FEB91.7080401@oracle.com>
	<571FF0C2.5080901@oracle.com> <571FFE6C.2030908@oracle.com>
	<57202F39.7000403@oracle.com> <572123EF.3040002@oracle.com>
Message-ID: <57214525.3020708@oracle.com>

I referred  to this issue on this thread many emails ago as one reason 
why float might be better.

 >   But we have only API which gets a chars width and draws a text from 
int position in the user space.

There have been such APIs on the 2D classes since JDK 1.2, eg :

https://docs.oracle.com/javase/8/docs/api/java/awt/Graphics2D.html#drawString-java.lang.String-float-float-
https://docs.oracle.com/javase/8/docs/api/java/awt/Font.html#getStringBounds-java.lang.String-java.awt.font.FontRenderContext-

Swing should be able to use these - or one of the other related ones - 
where it needs floating point.

When Swing detects complex text it turns over editing and highlighting 
to TextLayout, does it not ?
Perhaps doing the same for hi-dpi would work as well.

-phil.

On 04/27/2016 01:41 PM, Alexandr Scherbatiy wrote:
>
>
>   I just want to highlight one more problem which happen even font 
> metrics with right transform are used.
>   It refers to the text selection.
>
>   Suppose there is a graphics with scale 2. The char 'a' advance can 
> be 13 in device space and 13 / 2 = 6.5 in user space.
>   The task is to highlight a selected text in the middle of a string
>
>   Let's the selected index will be 11. The x coordinate to draw the 
> selected text is FontMetrics.charsWidth(chars, 0, index) = 72.
>    The selected text drawn from this position will be shifted to the 
> right because real x coordinate in user space is 6.5 * 11 = 71.5.
>   This leads that text is jumping when it is selected and deselected.
>
>   To properly draw a selected text in this case there should be API 
> which allows both return float chars width and draw a text from float 
> position.
>   But we have only API which gets a chars width and draws a text from 
> int position in the user space.
>
>   Below is a code which illustrate the text selection issue.
>   The image shows two strings which are selected from index 10 and 11. 
> The second selection is shifted to the right:
> http://cr.openjdk.java.net/~alexsch/8142966/images/text-selection.png
>
>   ----------------------------
>         int imgWidth = 400;
>         int imgHeight = 150;
>
>         BufferedImage buffImage = new BufferedImage(imgWidth, imgHeight,
>                 BufferedImage.TYPE_INT_RGB);
>
>         Graphics2D g = buffImage.createGraphics();
>         g.setColor(Color.WHITE);
>         g.fillRect(0, 0, imgWidth, imgHeight);
>
>         int x = 10;
>         int y1 = 20;
>         int y2 = 40;
>
>         g.scale(2, 2);
>         String text = "aaaaaaaaaaaaaaaaaaaaaaaa";
>         g.setColor(Color.BLUE);
>         char[] chars = text.toCharArray();
>         g.drawChars(chars, 0, chars.length, x, y1);
>         g.drawChars(chars, 0, chars.length, x, y2);
>
>         int selIndex = 10;
>         int selNum = 6;
>
>         FontMetrics fm = g.getFontMetrics(g.getFont());
>         g.setColor(Color.RED);
>         g.drawChars(chars, selIndex, selNum, x + fm.charsWidth(chars, 
> 0, selIndex), y1);
>         selIndex++;
>         g.drawChars(chars, selIndex, selNum, x + fm.charsWidth(chars, 
> 0, selIndex), y2);
>
>         g.dispose();
>   ----------------------------
>
>
> On 4/27/2016 6:17 AM, Philip Race wrote:
>> Applications cannot change the device transform and expect the same 
>> user space
>> metrics unless they specify fractional metrics to be ON.
>>
>> In your example below you may already have a scaled graphics context
>> if you were printing (for example).
>>
>> If you want no change to the user space positions or [as also 
>> implied] shapes of the glyphs
>> as the transform changes then you are asking for text that will not look
>> right at other resolutions. Printed text will look poorly spaced.
>>
>> Changing what happens in the font system is not an option since it
>> will break many applications - even if it were the right thing to do 
>> - which it is not.
>>
>> -phil.
>>
>>
>> On 4/26/16, 4:49 PM, Sergey Bylokhov wrote:
>>> On 27.04.16 1:50, Phil Race wrote:
>>>> Glyphs are always rasterised in device space so it does mean device 
>>>> space.
>>>
>>> I don't argue with it, the question is how to round.
>>>
>>>> The identity transform therefore happens to always return a user space
>>>> advance is that is an integer, but it is not bound to be so under any
>>>> other transform.
>>>
>>> I am not sure that this is correct. The simple example:
>>>
>>> BufferedImage bi = new BufferedImage(width, height,TYPE_INT_ARGB);
>>> int length = g2d.getFontMetrics().stringWidth(TEXT);
>>> Graphics2D g2d = bi.createGraphics();
>>> g2d.scale(2, 2);
>>> length = g2d.getFontMetrics().stringWidth(TEXT);
>>>
>>> In what space will be the length? I assume that this is the user 
>>> space. Note that if in the second time we get 13 pixels we will 
>>> round it to 7 (but rendering will be done to 6.5 * 2 = 13). My 
>>> suggestion in the fix is to make this round on the lower level and 
>>> use the same values as stringWidth() and during rendering.
>>>
>>>>
>>>> -phil.
>>>>
>>>> On 04/26/2016 03:28 PM, Sergey Bylokhov wrote:
>>>>> On 27.04.16 0:34, Phil Race wrote:
>>>>>> Fractional metrics being "off" does not mean that *user space* 
>>>>>> advances
>>>>>> need to be integers,
>>>>>> it refers to *device* space advances. Of course if your API does not
>>>>>> support floats you have a
>>>>>> problem - particularly if - you are character advance adding in 
>>>>>> which
>>>>>> case it is better to ask the
>>>>>> font system for the overall advance of the text.
>>>>>> https://docs.oracle.com/javase/8/docs/api/java/awt/RenderingHints.html#KEY_FRACTIONALMETRICS 
>>>>>>
>>>>>>
>>>>>
>>>>> The documentation says that in case of "fm-off" the "simplified 
>>>>> system
>>>>> based on integer device positions is typically used" + "rounding
>>>>> advance widths for rasterized glyphs to integer distances", it does
>>>>> not say that the "integer distance" should be rounded to the nearest
>>>>> device/pixel. It says that "rounding operations as the high quality
>>>>> and very precise definition of the shape and metrics of the character
>>>>> glyphs must be matched to discrete device pixels" I guess we should
>>>>> confirm the specification because results of the fix will be 
>>>>> "discrete
>>>>> number of device pixels", isn't it?
>>>>>
>>>>
>>>
>>>
>



From Sergey.Bylokhov at oracle.com  Thu Apr 28 09:20:52 2016
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Thu, 28 Apr 2016 12:20:52 +0300
Subject: <Swing Dev> [9] Review request for 8132119 Provide public API
 for text related methods in SwingUtilities2
In-Reply-To: <57214525.3020708@oracle.com>
References: <55E715A1.3090008@oracle.com> <566986FD.9020207@oracle.com>
	<5694F0C3.8020203@oracle.com> <5695572F.6070709@oracle.com>
	<56966730.7000701@oracle.com> <5698C71A.80703@oracle.com>
	<56991ED9.5030302@oracle.com> <569963B6.2050604@oracle.com>
	<56A5C40B.7010107@oracle.com>
	<CAM6ZMz8iEFQQtSb_bAVU5eUH=J=HapvKq3+Ana4pPxueJD1bNg@mail.gmail.com>
	<56AB8A94.2070404@oracle.com> <56EC2389.3020507@oracle.com>
	<56F38B0B.3060700@oracle.com> <56F3F13A.9000808@oracle.com>
	<56F3F83C.3010706@oracle.com> <56FD791E.1050707@oracle.com>
	<5705705C.2010007@oracle.com> <570C3370.1090702@oracle.com>
	<5715E767.5000409@oracle.com> <571FA7A9.6060105@oracle.com>
	<571FB2C3.10808@oracle.com> <571FB41B.6010200@oracle.com>
	<571FD026.2070006@oracle.com> <571FD1E5.9030601@oracle.com>
	<571FDED8.5070800@oracle.com> <571FEB91.7080401@oracle.com>
	<571FF0C2.5080901@oracle.com> <571FFE6C.2030908@oracle.com>
	<57202F39.7000403@oracle.com> <572123EF.3040002@oracle.com>
	<57214525.3020708@oracle.com>
Message-ID: <5721D5F4.9030206@oracle.com>

On 28.04.16 2:03, Phil Race wrote:
> I referred  to this issue on this thread many emails ago as one reason
> why float might be better.
>
> Swing should be able to use these - or one of the other related ones -
> where it needs floating point.

The problem below and a suggestion of using float has the similar 
symptoms to the situation when fm-on, when actual rendering and metrics 
in "int" are different. The suggestion of using float is correct, but 
why it should be used when fm-off? according to the spec all metrics in 
this case should be calculated as "int". I still think that all these 
problems are occurs because we incorrectly calculate "int" metrics when 
fm-off(actually from the users point of view fm-off mode is useless, 
because even if fm-off the application get fractional data instead of 
expected ints).

>
> When Swing detects complex text it turns over editing and highlighting
> to TextLayout, does it not ?
> Perhaps doing the same for hi-dpi would work as well.
>
> -phil.
>
> On 04/27/2016 01:41 PM, Alexandr Scherbatiy wrote:
>>
>>
>>   I just want to highlight one more problem which happen even font
>> metrics with right transform are used.
>>   It refers to the text selection.
>>
>>   Suppose there is a graphics with scale 2. The char 'a' advance can
>> be 13 in device space and 13 / 2 = 6.5 in user space.
>>   The task is to highlight a selected text in the middle of a string
>>
>>   Let's the selected index will be 11. The x coordinate to draw the
>> selected text is FontMetrics.charsWidth(chars, 0, index) = 72.
>>    The selected text drawn from this position will be shifted to the
>> right because real x coordinate in user space is 6.5 * 11 = 71.5.
>>   This leads that text is jumping when it is selected and deselected.
>>
>>   To properly draw a selected text in this case there should be API
>> which allows both return float chars width and draw a text from float
>> position.
>>   But we have only API which gets a chars width and draws a text from
>> int position in the user space.
>>
>>   Below is a code which illustrate the text selection issue.
>>   The image shows two strings which are selected from index 10 and 11.
>> The second selection is shifted to the right:
>> http://cr.openjdk.java.net/~alexsch/8142966/images/text-selection.png
>>
>>   ----------------------------
>>         int imgWidth = 400;
>>         int imgHeight = 150;
>>
>>         BufferedImage buffImage = new BufferedImage(imgWidth, imgHeight,
>>                 BufferedImage.TYPE_INT_RGB);
>>
>>         Graphics2D g = buffImage.createGraphics();
>>         g.setColor(Color.WHITE);
>>         g.fillRect(0, 0, imgWidth, imgHeight);
>>
>>         int x = 10;
>>         int y1 = 20;
>>         int y2 = 40;
>>
>>         g.scale(2, 2);
>>         String text = "aaaaaaaaaaaaaaaaaaaaaaaa";
>>         g.setColor(Color.BLUE);
>>         char[] chars = text.toCharArray();
>>         g.drawChars(chars, 0, chars.length, x, y1);
>>         g.drawChars(chars, 0, chars.length, x, y2);
>>
>>         int selIndex = 10;
>>         int selNum = 6;
>>
>>         FontMetrics fm = g.getFontMetrics(g.getFont());
>>         g.setColor(Color.RED);
>>         g.drawChars(chars, selIndex, selNum, x + fm.charsWidth(chars,
>> 0, selIndex), y1);
>>         selIndex++;
>>         g.drawChars(chars, selIndex, selNum, x + fm.charsWidth(chars,
>> 0, selIndex), y2);
>>
>>         g.dispose();
>>   ----------------------------
>>
>>
>> On 4/27/2016 6:17 AM, Philip Race wrote:
>>> Applications cannot change the device transform and expect the same
>>> user space
>>> metrics unless they specify fractional metrics to be ON.
>>>
>>> In your example below you may already have a scaled graphics context
>>> if you were printing (for example).
>>>
>>> If you want no change to the user space positions or [as also
>>> implied] shapes of the glyphs
>>> as the transform changes then you are asking for text that will not look
>>> right at other resolutions. Printed text will look poorly spaced.
>>>
>>> Changing what happens in the font system is not an option since it
>>> will break many applications - even if it were the right thing to do
>>> - which it is not.
>>>
>>> -phil.
>>>
>>>
>>> On 4/26/16, 4:49 PM, Sergey Bylokhov wrote:
>>>> On 27.04.16 1:50, Phil Race wrote:
>>>>> Glyphs are always rasterised in device space so it does mean device
>>>>> space.
>>>>
>>>> I don't argue with it, the question is how to round.
>>>>
>>>>> The identity transform therefore happens to always return a user space
>>>>> advance is that is an integer, but it is not bound to be so under any
>>>>> other transform.
>>>>
>>>> I am not sure that this is correct. The simple example:
>>>>
>>>> BufferedImage bi = new BufferedImage(width, height,TYPE_INT_ARGB);
>>>> int length = g2d.getFontMetrics().stringWidth(TEXT);
>>>> Graphics2D g2d = bi.createGraphics();
>>>> g2d.scale(2, 2);
>>>> length = g2d.getFontMetrics().stringWidth(TEXT);
>>>>
>>>> In what space will be the length? I assume that this is the user
>>>> space. Note that if in the second time we get 13 pixels we will
>>>> round it to 7 (but rendering will be done to 6.5 * 2 = 13). My
>>>> suggestion in the fix is to make this round on the lower level and
>>>> use the same values as stringWidth() and during rendering.
>>>>
>>>>>
>>>>> -phil.
>>>>>
>>>>> On 04/26/2016 03:28 PM, Sergey Bylokhov wrote:
>>>>>> On 27.04.16 0:34, Phil Race wrote:
>>>>>>> Fractional metrics being "off" does not mean that *user space*
>>>>>>> advances
>>>>>>> need to be integers,
>>>>>>> it refers to *device* space advances. Of course if your API does not
>>>>>>> support floats you have a
>>>>>>> problem - particularly if - you are character advance adding in
>>>>>>> which
>>>>>>> case it is better to ask the
>>>>>>> font system for the overall advance of the text.
>>>>>>> https://docs.oracle.com/javase/8/docs/api/java/awt/RenderingHints.html#KEY_FRACTIONALMETRICS
>>>>>>>
>>>>>>>
>>>>>>
>>>>>> The documentation says that in case of "fm-off" the "simplified
>>>>>> system
>>>>>> based on integer device positions is typically used" + "rounding
>>>>>> advance widths for rasterized glyphs to integer distances", it does
>>>>>> not say that the "integer distance" should be rounded to the nearest
>>>>>> device/pixel. It says that "rounding operations as the high quality
>>>>>> and very precise definition of the shape and metrics of the character
>>>>>> glyphs must be matched to discrete device pixels" I guess we should
>>>>>> confirm the specification because results of the fix will be
>>>>>> "discrete
>>>>>> number of device pixels", isn't it?
>>>>>>
>>>>>
>>>>
>>>>
>>
>


-- 
Best regards, Sergey.


From Sergey.Bylokhov at oracle.com  Thu Apr 28 11:31:40 2016
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Thu, 28 Apr 2016 14:31:40 +0300
Subject: <Swing Dev> [9] Review request for 8132119 Provide public API
 for text related methods in SwingUtilities2
In-Reply-To: <5721D5F4.9030206@oracle.com>
References: <55E715A1.3090008@oracle.com> <5694F0C3.8020203@oracle.com>
	<5695572F.6070709@oracle.com> <56966730.7000701@oracle.com>
	<5698C71A.80703@oracle.com> <56991ED9.5030302@oracle.com>
	<569963B6.2050604@oracle.com> <56A5C40B.7010107@oracle.com>
	<CAM6ZMz8iEFQQtSb_bAVU5eUH=J=HapvKq3+Ana4pPxueJD1bNg@mail.gmail.com>
	<56AB8A94.2070404@oracle.com> <56EC2389.3020507@oracle.com>
	<56F38B0B.3060700@oracle.com> <56F3F13A.9000808@oracle.com>
	<56F3F83C.3010706@oracle.com> <56FD791E.1050707@oracle.com>
	<5705705C.2010007@oracle.com> <570C3370.1090702@oracle.com>
	<5715E767.5000409@oracle.com> <571FA7A9.6060105@oracle.com>
	<571FB2C3.10808@oracle.com> <571FB41B.6010200@oracle.com>
	<571FD026.2070006@oracle.com> <571FD1E5.9030601@oracle.com>
	<571FDED8.5070800@oracle.com> <571FEB91.7080401@oracle.com>
	<571FF0C2.5080901@oracle.com> <571FFE6C.2030908@oracle.com>
	<57202F39.7000403@oracle.com> <572123EF.3040002@oracle.com>
	<57214525.3020708@oracle.com> <5721D5F4.9030206@oracle.com>
Message-ID: <5721F49C.2010201@oracle.com>

On 28.04.16 12:20, Sergey Bylokhov wrote:
> The problem below and a suggestion of using float has the similar
> symptoms to the situation when fm-on, when actual rendering and metrics
> in "int" are different. The suggestion of using float is correct, but
> why it should be used when fm-off? according to the spec all metrics in
> this case should be calculated as "int". I still think that all these
> problems are occurs because we incorrectly calculate "int" metrics when
> fm-off(actually from the users point of view fm-off mode is useless,
> because even if fm-off the application get fractional data instead of
> expected ints).

I suggest to implement it like on OSX, then tweak the algorithm of 
rounding, and if after that someone will complains then add a new render 
hint to round the text according the user space.

>
>>
>> When Swing detects complex text it turns over editing and highlighting
>> to TextLayout, does it not ?
>> Perhaps doing the same for hi-dpi would work as well.
>>
>> -phil.
>>
>> On 04/27/2016 01:41 PM, Alexandr Scherbatiy wrote:
>>>
>>>
>>>   I just want to highlight one more problem which happen even font
>>> metrics with right transform are used.
>>>   It refers to the text selection.
>>>
>>>   Suppose there is a graphics with scale 2. The char 'a' advance can
>>> be 13 in device space and 13 / 2 = 6.5 in user space.
>>>   The task is to highlight a selected text in the middle of a string
>>>
>>>   Let's the selected index will be 11. The x coordinate to draw the
>>> selected text is FontMetrics.charsWidth(chars, 0, index) = 72.
>>>    The selected text drawn from this position will be shifted to the
>>> right because real x coordinate in user space is 6.5 * 11 = 71.5.
>>>   This leads that text is jumping when it is selected and deselected.
>>>
>>>   To properly draw a selected text in this case there should be API
>>> which allows both return float chars width and draw a text from float
>>> position.
>>>   But we have only API which gets a chars width and draws a text from
>>> int position in the user space.
>>>
>>>   Below is a code which illustrate the text selection issue.
>>>   The image shows two strings which are selected from index 10 and 11.
>>> The second selection is shifted to the right:
>>> http://cr.openjdk.java.net/~alexsch/8142966/images/text-selection.png
>>>
>>>   ----------------------------
>>>         int imgWidth = 400;
>>>         int imgHeight = 150;
>>>
>>>         BufferedImage buffImage = new BufferedImage(imgWidth, imgHeight,
>>>                 BufferedImage.TYPE_INT_RGB);
>>>
>>>         Graphics2D g = buffImage.createGraphics();
>>>         g.setColor(Color.WHITE);
>>>         g.fillRect(0, 0, imgWidth, imgHeight);
>>>
>>>         int x = 10;
>>>         int y1 = 20;
>>>         int y2 = 40;
>>>
>>>         g.scale(2, 2);
>>>         String text = "aaaaaaaaaaaaaaaaaaaaaaaa";
>>>         g.setColor(Color.BLUE);
>>>         char[] chars = text.toCharArray();
>>>         g.drawChars(chars, 0, chars.length, x, y1);
>>>         g.drawChars(chars, 0, chars.length, x, y2);
>>>
>>>         int selIndex = 10;
>>>         int selNum = 6;
>>>
>>>         FontMetrics fm = g.getFontMetrics(g.getFont());
>>>         g.setColor(Color.RED);
>>>         g.drawChars(chars, selIndex, selNum, x + fm.charsWidth(chars,
>>> 0, selIndex), y1);
>>>         selIndex++;
>>>         g.drawChars(chars, selIndex, selNum, x + fm.charsWidth(chars,
>>> 0, selIndex), y2);
>>>
>>>         g.dispose();
>>>   ----------------------------
>>>
>>>
>>> On 4/27/2016 6:17 AM, Philip Race wrote:
>>>> Applications cannot change the device transform and expect the same
>>>> user space
>>>> metrics unless they specify fractional metrics to be ON.
>>>>
>>>> In your example below you may already have a scaled graphics context
>>>> if you were printing (for example).
>>>>
>>>> If you want no change to the user space positions or [as also
>>>> implied] shapes of the glyphs
>>>> as the transform changes then you are asking for text that will not
>>>> look
>>>> right at other resolutions. Printed text will look poorly spaced.
>>>>
>>>> Changing what happens in the font system is not an option since it
>>>> will break many applications - even if it were the right thing to do
>>>> - which it is not.
>>>>
>>>> -phil.
>>>>
>>>>
>>>> On 4/26/16, 4:49 PM, Sergey Bylokhov wrote:
>>>>> On 27.04.16 1:50, Phil Race wrote:
>>>>>> Glyphs are always rasterised in device space so it does mean device
>>>>>> space.
>>>>>
>>>>> I don't argue with it, the question is how to round.
>>>>>
>>>>>> The identity transform therefore happens to always return a user
>>>>>> space
>>>>>> advance is that is an integer, but it is not bound to be so under any
>>>>>> other transform.
>>>>>
>>>>> I am not sure that this is correct. The simple example:
>>>>>
>>>>> BufferedImage bi = new BufferedImage(width, height,TYPE_INT_ARGB);
>>>>> int length = g2d.getFontMetrics().stringWidth(TEXT);
>>>>> Graphics2D g2d = bi.createGraphics();
>>>>> g2d.scale(2, 2);
>>>>> length = g2d.getFontMetrics().stringWidth(TEXT);
>>>>>
>>>>> In what space will be the length? I assume that this is the user
>>>>> space. Note that if in the second time we get 13 pixels we will
>>>>> round it to 7 (but rendering will be done to 6.5 * 2 = 13). My
>>>>> suggestion in the fix is to make this round on the lower level and
>>>>> use the same values as stringWidth() and during rendering.
>>>>>
>>>>>>
>>>>>> -phil.
>>>>>>
>>>>>> On 04/26/2016 03:28 PM, Sergey Bylokhov wrote:
>>>>>>> On 27.04.16 0:34, Phil Race wrote:
>>>>>>>> Fractional metrics being "off" does not mean that *user space*
>>>>>>>> advances
>>>>>>>> need to be integers,
>>>>>>>> it refers to *device* space advances. Of course if your API does
>>>>>>>> not
>>>>>>>> support floats you have a
>>>>>>>> problem - particularly if - you are character advance adding in
>>>>>>>> which
>>>>>>>> case it is better to ask the
>>>>>>>> font system for the overall advance of the text.
>>>>>>>> https://docs.oracle.com/javase/8/docs/api/java/awt/RenderingHints.html#KEY_FRACTIONALMETRICS
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>> The documentation says that in case of "fm-off" the "simplified
>>>>>>> system
>>>>>>> based on integer device positions is typically used" + "rounding
>>>>>>> advance widths for rasterized glyphs to integer distances", it does
>>>>>>> not say that the "integer distance" should be rounded to the nearest
>>>>>>> device/pixel. It says that "rounding operations as the high quality
>>>>>>> and very precise definition of the shape and metrics of the
>>>>>>> character
>>>>>>> glyphs must be matched to discrete device pixels" I guess we should
>>>>>>> confirm the specification because results of the fix will be
>>>>>>> "discrete
>>>>>>> number of device pixels", isn't it?
>>>>>>>
>>>>>>
>>>>>
>>>>>
>>>
>>
>
>


-- 
Best regards, Sergey.


From Sergey.Bylokhov at oracle.com  Thu Apr 28 12:57:00 2016
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Thu, 28 Apr 2016 15:57:00 +0300
Subject: <Swing Dev> [9] Review request for 8046031: UI of Java Web
 Start app isn't updated when changing Windows theme
In-Reply-To: <57206616.8020006@oracle.com>
References: <5718D41D.7090104@oracle.com> <5718DBF1.7090407@oracle.com>
	<57192E19.40107@oracle.com> <571A5152.2050907@oracle.com>
	<571E3086.5040200@oracle.com> <571E5A5D.4030401@oracle.com>
	<571F6207.3040101@oracle.com> <57206616.8020006@oracle.com>
Message-ID: <5722089C.2010506@oracle.com>

On 27.04.16 10:11, Semyon Sadetsky wrote:
>> All of these are a private object fields in Windows l&F and the l&f is
>> stored per appcontext. what is the problem in these fields?
> The problem is performance. They may trigger the property change and
> then update all context's UI's. The last is rather heavy operation, so
> if next property update request come and isUpdatePending() is true then
> the new overall UI update event is not posted.

ok, then just make the new field private and do not use the interned 
string as a key.

>
> --Semyon
>>
>>>
>>>              this.themeActive = new
>>> TriggerDesktopProperty("win.xpstyle.themeActive");
>>>              this.dllName     = new
>>> TriggerDesktopProperty("win.xpstyle.dllName");
>>>              this.colorName   = new
>>> TriggerDesktopProperty("win.xpstyle.colorName");
>>>              this.sizeName    = new
>>> TriggerDesktopProperty("win.xpstyle.sizeName");
>>>
>>> --Semyon
>>>>
>>>>> Putting the flag into the app scope protects from scheduling events
>>>>> recursively
>>>>>> If the Appcontext is necessary, then we should not use interned
>>>>>> string
>>>>>> as a key, I suggest to use the simple new Object(), so it will not be
>>>>>> accessible outside of this class.
>>>>> This is a public field. Accessing it outside the class shouldn't be an
>>>>> issue.
>>>>
>>>> I overlooked that it is public in my first email. Why? If it is not
>>>> used outside of this class it should be private. Also the interned
>>>> string will provide a way to access this data even if
>>>> "com/sun/java/swing" package will be inaccessible. So it is better to
>>>> use private key.
>>>>
>>>>>
>>>>> --Semyon
>>>>>>
>>>>>> On 21.04.16 16:56, Alexandr Scherbatiy wrote:
>>>>>>>
>>>>>>>   The fix looks good to me.
>>>>>>>
>>>>>>>   Thanks,
>>>>>>>   Alexandr.
>>>>>>>
>>>>>>> On 4/21/2016 6:22 AM, Semyon Sadetsky wrote:
>>>>>>>> Hello,
>>>>>>>>
>>>>>>>> Please review fix for JDK9:
>>>>>>>>
>>>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8046031
>>>>>>>> webrev: http://cr.openjdk.java.net/~ssadetsky/8046031/webrev.00/
>>>>>>>>
>>>>>>>> Under the Windoew LnF when the native Windows theme is changed some
>>>>>>>> java frames remains unchanged if there are several application
>>>>>>>> contexts. The thing is the DesktopProperty#updatePending flag that
>>>>>>>> prevents to run more then one UI update operation is shared between
>>>>>>>> different applications contexts while they may be updated with the
>>>>>>>> property change concurrently from different EDT threads so they may
>>>>>>>> loose the update.
>>>>>>>> To avoid this mutual interference the updatePending is moved
>>>>>>>> from the
>>>>>>>> global to the application context scope.
>>>>>>>> The test would require to write native code so the issue is labeled
>>>>>>>> noreg-hard.
>>>>>>>>
>>>>>>>> --Semyon
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>
>>>>
>>>
>>
>>
>


-- 
Best regards, Sergey.


From artem.ananiev at oracle.com  Thu Apr 28 15:04:14 2016
From: artem.ananiev at oracle.com (Artem Ananiev)
Date: Thu, 28 Apr 2016 18:04:14 +0300
Subject: <Swing Dev> [9] Review request for 8046031: UI of Java Web
 Start app isn't updated when changing Windows theme
In-Reply-To: <5718D41D.7090104@oracle.com>
References: <5718D41D.7090104@oracle.com>
Message-ID: <5722266E.3080503@oracle.com>

Hi, Semyon,

On 4/21/16 4:22 PM, Semyon Sadetsky wrote:
> Hello,
>
> Please review fix for JDK9:
>
> bug: https://bugs.openjdk.java.net/browse/JDK-8046031
> webrev: http://cr.openjdk.java.net/~ssadetsky/8046031/webrev.00/
>
> Under the Windoew LnF when the native Windows theme is changed some java
> frames remains unchanged if there are several application contexts. The
> thing is the DesktopProperty#updatePending flag that prevents to run
> more then one UI update operation is shared between different
> applications contexts while they may be updated with the property change
> concurrently from different EDT threads so they may loose the update.
> To avoid this mutual interference the updatePending is moved from the
> global to the application context scope.

could you add this evaluation to bug comments, please? At a glance, the 
fix looked flawed to me, but then in email discussion you proved it's 
fine, so the details are worth adding to the bug. For example, it's far 
from trivial to understand, why updatePending is shared between 
different DefaultProperties (globally in VM before the fix, and within 
the current AppContext after the fix).

> The test would require to write native code so the issue is labeled
> noreg-hard.

Does it really require native code? A test can create two app contexts, 
one desktop property, call its updateUI() in both EDTs, and check that 
it's executed twice.

Thanks,

Artem

> --Semyon


From semyon.sadetsky at oracle.com  Thu Apr 28 16:30:34 2016
From: semyon.sadetsky at oracle.com (Semyon Sadetsky)
Date: Thu, 28 Apr 2016 19:30:34 +0300
Subject: <Swing Dev> [9] Review request for 8046031: UI of Java Web
 Start app isn't updated when changing Windows theme
In-Reply-To: <5722089C.2010506@oracle.com>
References: <5718D41D.7090104@oracle.com> <5718DBF1.7090407@oracle.com>
	<57192E19.40107@oracle.com> <571A5152.2050907@oracle.com>
	<571E3086.5040200@oracle.com> <571E5A5D.4030401@oracle.com>
	<571F6207.3040101@oracle.com> <57206616.8020006@oracle.com>
	<5722089C.2010506@oracle.com>
Message-ID: <57223AAA.9070305@oracle.com>



On 4/28/2016 3:57 PM, Sergey Bylokhov wrote:
> On 27.04.16 10:11, Semyon Sadetsky wrote:
>>> All of these are a private object fields in Windows l&F and the l&f is
>>> stored per appcontext. what is the problem in these fields?
>> The problem is performance. They may trigger the property change and
>> then update all context's UI's. The last is rather heavy operation, so
>> if next property update request come and isUpdatePending() is true then
>> the new overall UI update event is not posted.
>
> ok, then just make the new field private and do not use the interned 
> string as a key.
Why do you think it should be private? This flag may be used as a sign 
of the upcoming  global UI update.

--Semyon
>
>>
>> --Semyon
>>>
>>>>
>>>>              this.themeActive = new
>>>> TriggerDesktopProperty("win.xpstyle.themeActive");
>>>>              this.dllName     = new
>>>> TriggerDesktopProperty("win.xpstyle.dllName");
>>>>              this.colorName   = new
>>>> TriggerDesktopProperty("win.xpstyle.colorName");
>>>>              this.sizeName    = new
>>>> TriggerDesktopProperty("win.xpstyle.sizeName");
>>>>
>>>> --Semyon
>>>>>
>>>>>> Putting the flag into the app scope protects from scheduling events
>>>>>> recursively
>>>>>>> If the Appcontext is necessary, then we should not use interned
>>>>>>> string
>>>>>>> as a key, I suggest to use the simple new Object(), so it will 
>>>>>>> not be
>>>>>>> accessible outside of this class.
>>>>>> This is a public field. Accessing it outside the class shouldn't 
>>>>>> be an
>>>>>> issue.
>>>>>
>>>>> I overlooked that it is public in my first email. Why? If it is not
>>>>> used outside of this class it should be private. Also the interned
>>>>> string will provide a way to access this data even if
>>>>> "com/sun/java/swing" package will be inaccessible. So it is better to
>>>>> use private key.
>>>>>
>>>>>>
>>>>>> --Semyon
>>>>>>>
>>>>>>> On 21.04.16 16:56, Alexandr Scherbatiy wrote:
>>>>>>>>
>>>>>>>>   The fix looks good to me.
>>>>>>>>
>>>>>>>>   Thanks,
>>>>>>>>   Alexandr.
>>>>>>>>
>>>>>>>> On 4/21/2016 6:22 AM, Semyon Sadetsky wrote:
>>>>>>>>> Hello,
>>>>>>>>>
>>>>>>>>> Please review fix for JDK9:
>>>>>>>>>
>>>>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8046031
>>>>>>>>> webrev: http://cr.openjdk.java.net/~ssadetsky/8046031/webrev.00/
>>>>>>>>>
>>>>>>>>> Under the Windoew LnF when the native Windows theme is changed 
>>>>>>>>> some
>>>>>>>>> java frames remains unchanged if there are several application
>>>>>>>>> contexts. The thing is the DesktopProperty#updatePending flag 
>>>>>>>>> that
>>>>>>>>> prevents to run more then one UI update operation is shared 
>>>>>>>>> between
>>>>>>>>> different applications contexts while they may be updated with 
>>>>>>>>> the
>>>>>>>>> property change concurrently from different EDT threads so 
>>>>>>>>> they may
>>>>>>>>> loose the update.
>>>>>>>>> To avoid this mutual interference the updatePending is moved
>>>>>>>>> from the
>>>>>>>>> global to the application context scope.
>>>>>>>>> The test would require to write native code so the issue is 
>>>>>>>>> labeled
>>>>>>>>> noreg-hard.
>>>>>>>>>
>>>>>>>>> --Semyon
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>
>>>
>>
>
>



From Sergey.Bylokhov at oracle.com  Thu Apr 28 16:46:32 2016
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Thu, 28 Apr 2016 19:46:32 +0300
Subject: <Swing Dev> [9] Review request for 8046031: UI of Java Web
 Start app isn't updated when changing Windows theme
In-Reply-To: <57223AAA.9070305@oracle.com>
References: <5718D41D.7090104@oracle.com> <5718DBF1.7090407@oracle.com>
	<57192E19.40107@oracle.com> <571A5152.2050907@oracle.com>
	<571E3086.5040200@oracle.com> <571E5A5D.4030401@oracle.com>
	<571F6207.3040101@oracle.com> <57206616.8020006@oracle.com>
	<5722089C.2010506@oracle.com> <57223AAA.9070305@oracle.com>
Message-ID: <57223E68.20809@oracle.com>

On 28.04.16 19:30, Semyon Sadetsky wrote:
>> ok, then just make the new field private and do not use the interned
>> string as a key.
> Why do you think it should be private? This flag may be used as a sign
> of the upcoming  global UI update.

Because right now it is not used outside of the class, and was a private 
before the fix.


-- 
Best regards, Sergey.


From semyon.sadetsky at oracle.com  Fri Apr 29 12:59:06 2016
From: semyon.sadetsky at oracle.com (Semyon Sadetsky)
Date: Fri, 29 Apr 2016 15:59:06 +0300
Subject: <Swing Dev> [9] Review request for 8046031: UI of Java Web
 Start app isn't updated when changing Windows theme
In-Reply-To: <5722266E.3080503@oracle.com>
References: <5718D41D.7090104@oracle.com> <5722266E.3080503@oracle.com>
Message-ID: <57235A9A.8030609@oracle.com>

Hi Artem,

Thank you for review.

I have added the comment to JIRA.

As for the test. Even if Toolkit.setDesktopProperty() were called using 
reflection, it seems to me, such test wouldn't be indicative, because 
even before the fix both contexts had a chance to be updated correctly. 
The bug has stochastic nature and requires that the event scheduling on 
both EDTs happens roughly at the same time. It's hard to make this 
deterministic.

--Semyon

On 4/28/2016 6:04 PM, Artem Ananiev wrote:
> Hi, Semyon,
>
> On 4/21/16 4:22 PM, Semyon Sadetsky wrote:
>> Hello,
>>
>> Please review fix for JDK9:
>>
>> bug: https://bugs.openjdk.java.net/browse/JDK-8046031
>> webrev: http://cr.openjdk.java.net/~ssadetsky/8046031/webrev.00/
>>
>> Under the Windoew LnF when the native Windows theme is changed some java
>> frames remains unchanged if there are several application contexts. The
>> thing is the DesktopProperty#updatePending flag that prevents to run
>> more then one UI update operation is shared between different
>> applications contexts while they may be updated with the property change
>> concurrently from different EDT threads so they may loose the update.
>> To avoid this mutual interference the updatePending is moved from the
>> global to the application context scope.
>
> could you add this evaluation to bug comments, please? At a glance, 
> the fix looked flawed to me, but then in email discussion you proved 
> it's fine, so the details are worth adding to the bug. For example, 
> it's far from trivial to understand, why updatePending is shared 
> between different DefaultProperties (globally in VM before the fix, 
> and within the current AppContext after the fix).
>
>> The test would require to write native code so the issue is labeled
>> noreg-hard.
>
> Does it really require native code? A test can create two app 
> contexts, one desktop property, call its updateUI() in both EDTs, and 
> check that it's executed twice.
>
> Thanks,
>
> Artem
>
>> --Semyon



From Sergey.Bylokhov at oracle.com  Fri Apr 29 15:55:08 2016
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Fri, 29 Apr 2016 18:55:08 +0300
Subject: <Swing Dev> internal API usage: PopupFactory.setPopupType()
In-Reply-To: <6C055940-0220-4965-AEAE-B704B1245021@cbfiddle.com>
References: <C4079AA5-CDF2-423D-92AC-9E0C69D14CFD@cbfiddle.com>
	<569D489B.5010608@oracle.com>
	<6C055940-0220-4965-AEAE-B704B1245021@cbfiddle.com>
Message-ID: <b40bd288-9b2d-4183-46a3-ac1fb03abb08@oracle.com>

Hi, Alan.
If you write your own l&f then you can change this behavior via
         PopupFactory.setSharedInstance(spf);
In this case you can override PopupFactory.getPopup() and always return 
popup you want.

At least the Aqua look and feel force HW popups via this way.

On 18.01.16 23:57, Alan Snyder wrote:
> I want a solution that forces popups to be heavyweight and does not allow the application any choice in the matter.
>
> My UI could set this flag on each popup, but the application could reset the flag.
>
>   Alan
>
>
>> On Jan 18, 2016, at 12:18 PM, Sergey Bylokhov <Sergey.Bylokhov at oracle.com> wrote:
>>
>> Hi, Alan.
>> Did you try to use JPopupMenu.setLightWeightPopupEnabled() for this usecase?
>>
>> On 17/01/16 07:19, Alan Snyder wrote:
>>> I have submitted an RFE to make the functionality
>>> of PopupFactory.setPopupType() publicly available.
>>>
>>> JI-9028692
>>>
>>> Regards,
>>>
>>>   Alan
>>>
>>
>>
>> --
>> Best regards, Sergey.
>


-- 
Best regards, Sergey.