From mikael.vidstedt at oracle.com  Mon May  4 05:12:05 2020
From: mikael.vidstedt at oracle.com (Mikael Vidstedt)
Date: Sun, 3 May 2020 22:12:05 -0700
Subject: <AWT Dev> RFR: 8244224: Implementation of JEP 381: Remove the
 Solaris and SPARC Ports - (client/desktop)
Message-ID: <F7749CA3-5EBC-493F-A500-E4AF2741D2CB@oracle.com>


Please review this change which implements part of JEP 381:

JBS: https://bugs.openjdk.java.net/browse/JDK-8244224
webrev: http://cr.openjdk.java.net/~mikael/webrevs/8244224/webrev.00/client/open/webrev/
JEP: https://bugs.openjdk.java.net/browse/JDK-8241787


Note: When reviewing this, please be aware that this exercise was *extremely* mind-numbing, so I appreciate your help reviewing all the individual changes carefully. You may want to get that coffee cup filled up (or whatever keeps you awake)!


Background:

Because of the size of the total patch and wide range of areas touched, this patch is one out of in total six partial patches which together make up the necessary changes to remove the Solaris and SPARC ports. The other patches are being sent out for review to mailing lists appropriate for the respective areas the touch. An email will be sent to jdk-dev summarizing all the patches/reviews. To be clear: this patch is *not* in itself complete and stand-alone - all of the (six) patches are needed to form a complete patch. Some changes in this patch may look wrong or incomplete unless also looking at the corresponding changes in other areas.

For convenience, I?m including a link below[1] to the full webrev, but in case you have comments on changes in other areas, outside of the files included in this thread, please provide those comments directly in the thread on the appropriate mailing list for that area if possible.

In case it helps, the changes were effectively produced by searching for and updating any code mentioning ?solaris", ?sparc?, ?solstudio?, ?sunos?, etc. More information about the areas impacted can be found in the JEP itself.


Testing:

A slightly earlier version of this change successfully passed tier1-8, as well as client tier1-2. Additional testing will be done after the first round of reviews has been completed.

Cheers,
Mikael

[1] http://cr.openjdk.java.net/~mikael/webrevs/8244224/webrev.00/all/open/webrev/


From Alan.Bateman at oracle.com  Mon May  4 15:23:02 2020
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Mon, 4 May 2020 16:23:02 +0100
Subject: <AWT Dev> 8244292: Headful clients failing with
	--illegal-access=deny
Message-ID: <ed6fd350-7350-b4d7-18e6-43124848c0df@oracle.com>

I ran the headful tests with --illegal-access=deny to shake out any 
issues in advance of changing the default in the future. There are 4 
tests that need their @modules tags updated because the tests access 
non-public members of classes in exported packages or members of classes 
in concealed packages:

java/awt/Toolkit/DisplayChangesException/DisplayChangesException.java
java/awt/event/SequencedEvent/MultipleContextsUnitTest.java
javax/accessibility/6714324/TabbedPaneMemLeak.java
com/sun/java/swing/plaf/windows/RevalidateOnPropertyChange.java

I've created JDK-8244292 [1] to track the issue and the patch to fix the 
issues is attached to the bug:
https://bugs.openjdk.java.net/secure/attachment/87984/client-tests.patch

The dates in the copyright headers isn't updated in the patch, I'll do 
that before pushing once the changes are reviewed.

-Alan

[1] https://bugs.openjdk.java.net/browse/JDK-8244292


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/awt-dev/attachments/20200504/5f606566/attachment.htm>

From philip.race at oracle.com  Mon May  4 15:36:39 2020
From: philip.race at oracle.com (Philip Race)
Date: Mon, 04 May 2020 08:36:39 -0700
Subject: <AWT Dev> 8244292: Headful clients failing with
	--illegal-access=deny
In-Reply-To: <ed6fd350-7350-b4d7-18e6-43124848c0df@oracle.com>
References: <ed6fd350-7350-b4d7-18e6-43124848c0df@oracle.com>
Message-ID: <5EB03687.7040604@oracle.com>

All looks fine to me.

-phil.

On 5/4/20, 8:23 AM, Alan Bateman wrote:
> I ran the headful tests with --illegal-access=deny to shake out any 
> issues in advance of changing the default in the future. There are 4 
> tests that need their @modules tags updated because the tests access 
> non-public members of classes in exported packages or members of 
> classes in concealed packages:
>
> java/awt/Toolkit/DisplayChangesException/DisplayChangesException.java
> java/awt/event/SequencedEvent/MultipleContextsUnitTest.java
> javax/accessibility/6714324/TabbedPaneMemLeak.java
> com/sun/java/swing/plaf/windows/RevalidateOnPropertyChange.java
>
> I've created JDK-8244292 [1] to track the issue and the patch to fix 
> the issues is attached to the bug:
> https://bugs.openjdk.java.net/secure/attachment/87984/client-tests.patch
>
> The dates in the copyright headers isn't updated in the patch, I'll do 
> that before pushing once the changes are reviewed.
>
> -Alan
>
> [1] https://bugs.openjdk.java.net/browse/JDK-8244292
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/awt-dev/attachments/20200504/b146e999/attachment.htm>

From Sergey.Bylokhov at oracle.com  Tue May  5 03:03:05 2020
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Mon, 4 May 2020 20:03:05 -0700
Subject: <AWT Dev> [OpenJDK 2D-Dev] RFR: 8244224: Implementation of JEP
 381: Remove the Solaris and SPARC Ports - (client/desktop)
In-Reply-To: <F7749CA3-5EBC-493F-A500-E4AF2741D2CB@oracle.com>
References: <F7749CA3-5EBC-493F-A500-E4AF2741D2CB@oracle.com>
Message-ID: <b2c6b911-d969-2ab8-3cae-bbb0e37798ad@oracle.com>

Probably the files relate to the Jemmy library should be excluded, these files a copy of the library.
But I do not know the future of this library on Solaris,
(cc) Shura.

On 5/3/20 10:12 pm, Mikael Vidstedt wrote:
> 
> Please review this change which implements part of JEP 381:
> 
> JBS: https://bugs.openjdk.java.net/browse/JDK-8244224
> webrev: http://cr.openjdk.java.net/~mikael/webrevs/8244224/webrev.00/client/open/webrev/
> JEP: https://bugs.openjdk.java.net/browse/JDK-8241787
> 
> 
> Note: When reviewing this, please be aware that this exercise was *extremely* mind-numbing, so I appreciate your help reviewing all the individual changes carefully. You may want to get that coffee cup filled up (or whatever keeps you awake)!
> 
> 
> Background:
> 
> Because of the size of the total patch and wide range of areas touched, this patch is one out of in total six partial patches which together make up the necessary changes to remove the Solaris and SPARC ports. The other patches are being sent out for review to mailing lists appropriate for the respective areas the touch. An email will be sent to jdk-dev summarizing all the patches/reviews. To be clear: this patch is *not* in itself complete and stand-alone - all of the (six) patches are needed to form a complete patch. Some changes in this patch may look wrong or incomplete unless also looking at the corresponding changes in other areas.
> 
> For convenience, I?m including a link below[1] to the full webrev, but in case you have comments on changes in other areas, outside of the files included in this thread, please provide those comments directly in the thread on the appropriate mailing list for that area if possible.
> 
> In case it helps, the changes were effectively produced by searching for and updating any code mentioning ?solaris", ?sparc?, ?solstudio?, ?sunos?, etc. More information about the areas impacted can be found in the JEP itself.
> 
> 
> Testing:
> 
> A slightly earlier version of this change successfully passed tier1-8, as well as client tier1-2. Additional testing will be done after the first round of reviews has been completed.
> 
> Cheers,
> Mikael
> 
> [1] http://cr.openjdk.java.net/~mikael/webrevs/8244224/webrev.00/all/open/webrev/
> 


-- 
Best regards, Sergey.

From alexandre.iline at oracle.com  Tue May  5 19:00:12 2020
From: alexandre.iline at oracle.com (Alexandre (Shura) Iline)
Date: Tue, 5 May 2020 12:00:12 -0700
Subject: <AWT Dev> [OpenJDK 2D-Dev] RFR: 8244224: Implementation of JEP
 381: Remove the Solaris and SPARC Ports - (client/desktop)
In-Reply-To: <b2c6b911-d969-2ab8-3cae-bbb0e37798ad@oracle.com>
References: <F7749CA3-5EBC-493F-A500-E4AF2741D2CB@oracle.com>
 <b2c6b911-d969-2ab8-3cae-bbb0e37798ad@oracle.com>
Message-ID: <4EC85EC4-C281-4E82-9CC6-076E7E268FD1@oracle.com>

Hi.

That is correct. Sources of Jemmy in JDK repository is a copy of sources from code-tools Jemmy project. 

Any changes should be done there first, and then propagated to the jdk testable. 

Thank you for the good catch, Sergey,

Shura

> On May 4, 2020, at 8:03 PM, Sergey Bylokhov <Sergey.Bylokhov at oracle.com> wrote:
> 
> Probably the files relate to the Jemmy library should be excluded, these files a copy of the library.
> But I do not know the future of this library on Solaris,
> (cc) Shura.
> 
> On 5/3/20 10:12 pm, Mikael Vidstedt wrote:
>> Please review this change which implements part of JEP 381:
>> JBS: https://bugs.openjdk.java.net/browse/JDK-8244224
>> webrev: http://cr.openjdk.java.net/~mikael/webrevs/8244224/webrev.00/client/open/webrev/
>> JEP: https://bugs.openjdk.java.net/browse/JDK-8241787
>> Note: When reviewing this, please be aware that this exercise was *extremely* mind-numbing, so I appreciate your help reviewing all the individual changes carefully. You may want to get that coffee cup filled up (or whatever keeps you awake)!
>> Background:
>> Because of the size of the total patch and wide range of areas touched, this patch is one out of in total six partial patches which together make up the necessary changes to remove the Solaris and SPARC ports. The other patches are being sent out for review to mailing lists appropriate for the respective areas the touch. An email will be sent to jdk-dev summarizing all the patches/reviews. To be clear: this patch is *not* in itself complete and stand-alone - all of the (six) patches are needed to form a complete patch. Some changes in this patch may look wrong or incomplete unless also looking at the corresponding changes in other areas.
>> For convenience, I?m including a link below[1] to the full webrev, but in case you have comments on changes in other areas, outside of the files included in this thread, please provide those comments directly in the thread on the appropriate mailing list for that area if possible.
>> In case it helps, the changes were effectively produced by searching for and updating any code mentioning ?solaris", ?sparc?, ?solstudio?, ?sunos?, etc. More information about the areas impacted can be found in the JEP itself.
>> Testing:
>> A slightly earlier version of this change successfully passed tier1-8, as well as client tier1-2. Additional testing will be done after the first round of reviews has been completed.
>> Cheers,
>> Mikael
>> [1] http://cr.openjdk.java.net/~mikael/webrevs/8244224/webrev.00/all/open/webrev/
> 
> 
> -- 
> Best regards, Sergey.


From mikael.vidstedt at oracle.com  Thu May  7 00:50:22 2020
From: mikael.vidstedt at oracle.com (Mikael Vidstedt)
Date: Wed, 6 May 2020 17:50:22 -0700
Subject: <AWT Dev> RFR: 8244224: Implementation of JEP 381: Remove the
 Solaris and SPARC Ports - (client/desktop)
In-Reply-To: <F7749CA3-5EBC-493F-A500-E4AF2741D2CB@oracle.com>
References: <F7749CA3-5EBC-493F-A500-E4AF2741D2CB@oracle.com>
Message-ID: <3D91D7AE-11DB-4E80-B9A2-DAF6A96E24E6@oracle.com>


Sergey/Shura, thank you for the reviews. I reverted the Jemmy changes, and found some additional Sun Studio cleanups.

New webrev here:

webrev: http://cr.openjdk.java.net/~mikael/webrevs/8244224/webrev.01/client/open/webrev/
incremental: http://cr.openjdk.java.net/~mikael/webrevs/8244224/webrev.01/client.incr/open/webrev/

Cheers,
Mikael

> On May 3, 2020, at 10:12 PM, Mikael Vidstedt <mikael.vidstedt at oracle.com> wrote:
> 
> 
> Please review this change which implements part of JEP 381:
> 
> JBS: https://bugs.openjdk.java.net/browse/JDK-8244224
> webrev: http://cr.openjdk.java.net/~mikael/webrevs/8244224/webrev.00/client/open/webrev/
> JEP: https://bugs.openjdk.java.net/browse/JDK-8241787
> 
> 
> Note: When reviewing this, please be aware that this exercise was *extremely* mind-numbing, so I appreciate your help reviewing all the individual changes carefully. You may want to get that coffee cup filled up (or whatever keeps you awake)!
> 
> 
> Background:
> 
> Because of the size of the total patch and wide range of areas touched, this patch is one out of in total six partial patches which together make up the necessary changes to remove the Solaris and SPARC ports. The other patches are being sent out for review to mailing lists appropriate for the respective areas the touch. An email will be sent to jdk-dev summarizing all the patches/reviews. To be clear: this patch is *not* in itself complete and stand-alone - all of the (six) patches are needed to form a complete patch. Some changes in this patch may look wrong or incomplete unless also looking at the corresponding changes in other areas.
> 
> For convenience, I?m including a link below[1] to the full webrev, but in case you have comments on changes in other areas, outside of the files included in this thread, please provide those comments directly in the thread on the appropriate mailing list for that area if possible.
> 
> In case it helps, the changes were effectively produced by searching for and updating any code mentioning ?solaris", ?sparc?, ?solstudio?, ?sunos?, etc. More information about the areas impacted can be found in the JEP itself.
> 
> 
> Testing:
> 
> A slightly earlier version of this change successfully passed tier1-8, as well as client tier1-2. Additional testing will be done after the first round of reviews has been completed.
> 
> Cheers,
> Mikael
> 
> [1] http://cr.openjdk.java.net/~mikael/webrevs/8244224/webrev.00/all/open/webrev/
> 


From prasanta.sadhukhan at oracle.com  Thu May  7 09:27:55 2020
From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan)
Date: Thu, 7 May 2020 14:57:55 +0530
Subject: <AWT Dev> RFR: 8243925 Toolkit#getScreenInsets() returns wrong
 value on HiDPI screens (Windows)
In-Reply-To: <4ba81a39-b7ca-7b59-4b54-f5009eb43bcf@oracle.com>
References: <4ba81a39-b7ca-7b59-4b54-f5009eb43bcf@oracle.com>
Message-ID: <eeddcd22-d0d3-f87e-2cf7-a6fb6451afc7@oracle.com>

Hi Sergey,

The regression test pass for me on windows and linux even without the fix

Regards
Prasanta
On 30-Apr-20 3:10 AM, Sergey Bylokhov wrote:
> Hello.
> Please review the fix for jdk/client.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8243925
> Fix: http://cr.openjdk.java.net/~serb/8243925/webrev.02
>
> One more place when we return the data in pixels, without
> proper conversation to the user's space.
>
> On macOS, this conversion is done by the OS, on Linux we already
> convert the data. The only missing platform is Windows. Note that
> we still have an inadequate specification for this and some other
> Toolkit API which states that results are in "in pixels".
>
> I will file the separate bug to update the spec because this bug
> I would like to backport to 11.
>
> The bug was found during work on
> https://bugs.openjdk.java.net/browse/JDK-8231564
>
>

From philip.race at oracle.com  Thu May  7 18:26:24 2020
From: philip.race at oracle.com (Philip Race)
Date: Thu, 07 May 2020 11:26:24 -0700
Subject: <AWT Dev> RFR: 8244224: Implementation of JEP 381: Remove the
 Solaris and SPARC Ports - (client/desktop)
In-Reply-To: <3D91D7AE-11DB-4E80-B9A2-DAF6A96E24E6@oracle.com>
References: <F7749CA3-5EBC-493F-A500-E4AF2741D2CB@oracle.com>
 <3D91D7AE-11DB-4E80-B9A2-DAF6A96E24E6@oracle.com>
Message-ID: <5EB452D0.3060309@oracle.com>

This is all +1 from me.

-phil.

On 5/6/20, 5:50 PM, Mikael Vidstedt wrote:
> Sergey/Shura, thank you for the reviews. I reverted the Jemmy changes, and found some additional Sun Studio cleanups.
>
> New webrev here:
>
> webrev: http://cr.openjdk.java.net/~mikael/webrevs/8244224/webrev.01/client/open/webrev/
> incremental: http://cr.openjdk.java.net/~mikael/webrevs/8244224/webrev.01/client.incr/open/webrev/
>
> Cheers,
> Mikael
>
>> On May 3, 2020, at 10:12 PM, Mikael Vidstedt<mikael.vidstedt at oracle.com>  wrote:
>>
>>
>> Please review this change which implements part of JEP 381:
>>
>> JBS: https://bugs.openjdk.java.net/browse/JDK-8244224
>> webrev: http://cr.openjdk.java.net/~mikael/webrevs/8244224/webrev.00/client/open/webrev/
>> JEP: https://bugs.openjdk.java.net/browse/JDK-8241787
>>
>>
>> Note: When reviewing this, please be aware that this exercise was *extremely* mind-numbing, so I appreciate your help reviewing all the individual changes carefully. You may want to get that coffee cup filled up (or whatever keeps you awake)!
>>
>>
>> Background:
>>
>> Because of the size of the total patch and wide range of areas touched, this patch is one out of in total six partial patches which together make up the necessary changes to remove the Solaris and SPARC ports. The other patches are being sent out for review to mailing lists appropriate for the respective areas the touch. An email will be sent to jdk-dev summarizing all the patches/reviews. To be clear: this patch is *not* in itself complete and stand-alone - all of the (six) patches are needed to form a complete patch. Some changes in this patch may look wrong or incomplete unless also looking at the corresponding changes in other areas.
>>
>> For convenience, I?m including a link below[1] to the full webrev, but in case you have comments on changes in other areas, outside of the files included in this thread, please provide those comments directly in the thread on the appropriate mailing list for that area if possible.
>>
>> In case it helps, the changes were effectively produced by searching for and updating any code mentioning ?solaris", ?sparc?, ?solstudio?, ?sunos?, etc. More information about the areas impacted can be found in the JEP itself.
>>
>>
>> Testing:
>>
>> A slightly earlier version of this change successfully passed tier1-8, as well as client tier1-2. Additional testing will be done after the first round of reviews has been completed.
>>
>> Cheers,
>> Mikael
>>
>> [1] http://cr.openjdk.java.net/~mikael/webrevs/8244224/webrev.00/all/open/webrev/
>>

From philip.race at oracle.com  Thu May  7 20:39:03 2020
From: philip.race at oracle.com (Philip Race)
Date: Thu, 07 May 2020 13:39:03 -0700
Subject: <AWT Dev> RFR: 8243925 Toolkit#getScreenInsets() returns wrong
 value on HiDPI screens (Windows)
In-Reply-To: <4ba81a39-b7ca-7b59-4b54-f5009eb43bcf@oracle.com>
References: <4ba81a39-b7ca-7b59-4b54-f5009eb43bcf@oracle.com>
Message-ID: <5EB471E7.2070801@oracle.com>

+1

-phil.

On 4/29/20, 2:40 PM, Sergey Bylokhov wrote:
> Hello.
> Please review the fix for jdk/client.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8243925
> Fix: http://cr.openjdk.java.net/~serb/8243925/webrev.02
>
> One more place when we return the data in pixels, without
> proper conversation to the user's space.
>
> On macOS, this conversion is done by the OS, on Linux we already
> convert the data. The only missing platform is Windows. Note that
> we still have an inadequate specification for this and some other
> Toolkit API which states that results are in "in pixels".
>
> I will file the separate bug to update the spec because this bug
> I would like to backport to 11.
>
> The bug was found during work on
> https://bugs.openjdk.java.net/browse/JDK-8231564
>
>

From mikael.vidstedt at oracle.com  Thu May  7 21:22:34 2020
From: mikael.vidstedt at oracle.com (Mikael Vidstedt)
Date: Thu, 7 May 2020 14:22:34 -0700
Subject: <AWT Dev> RFR: 8244224: Implementation of JEP 381: Remove the
 Solaris and SPARC Ports - (client/desktop)
In-Reply-To: <5EB452D0.3060309@oracle.com>
References: <F7749CA3-5EBC-493F-A500-E4AF2741D2CB@oracle.com>
 <3D91D7AE-11DB-4E80-B9A2-DAF6A96E24E6@oracle.com>
 <5EB452D0.3060309@oracle.com>
Message-ID: <BB6EB021-1A0D-4912-80A6-DD4D00A50273@oracle.com>


Thank you Phil!

Cheers,
Mikael

> On May 7, 2020, at 11:26 AM, Philip Race <philip.race at oracle.com> wrote:
> 
> This is all +1 from me.
> 
> -phil.
> 
> On 5/6/20, 5:50 PM, Mikael Vidstedt wrote:
>> Sergey/Shura, thank you for the reviews. I reverted the Jemmy changes, and found some additional Sun Studio cleanups.
>> 
>> New webrev here:
>> 
>> webrev: http://cr.openjdk.java.net/~mikael/webrevs/8244224/webrev.01/client/open/webrev/
>> incremental: http://cr.openjdk.java.net/~mikael/webrevs/8244224/webrev.01/client.incr/open/webrev/
>> 
>> Cheers,
>> Mikael
>> 
>>> On May 3, 2020, at 10:12 PM, Mikael Vidstedt<mikael.vidstedt at oracle.com>  wrote:
>>> 
>>> 
>>> Please review this change which implements part of JEP 381:
>>> 
>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8244224
>>> webrev: http://cr.openjdk.java.net/~mikael/webrevs/8244224/webrev.00/client/open/webrev/
>>> JEP: https://bugs.openjdk.java.net/browse/JDK-8241787
>>> 
>>> 
>>> Note: When reviewing this, please be aware that this exercise was *extremely* mind-numbing, so I appreciate your help reviewing all the individual changes carefully. You may want to get that coffee cup filled up (or whatever keeps you awake)!
>>> 
>>> 
>>> Background:
>>> 
>>> Because of the size of the total patch and wide range of areas touched, this patch is one out of in total six partial patches which together make up the necessary changes to remove the Solaris and SPARC ports. The other patches are being sent out for review to mailing lists appropriate for the respective areas the touch. An email will be sent to jdk-dev summarizing all the patches/reviews. To be clear: this patch is *not* in itself complete and stand-alone - all of the (six) patches are needed to form a complete patch. Some changes in this patch may look wrong or incomplete unless also looking at the corresponding changes in other areas.
>>> 
>>> For convenience, I?m including a link below[1] to the full webrev, but in case you have comments on changes in other areas, outside of the files included in this thread, please provide those comments directly in the thread on the appropriate mailing list for that area if possible.
>>> 
>>> In case it helps, the changes were effectively produced by searching for and updating any code mentioning ?solaris", ?sparc?, ?solstudio?, ?sunos?, etc. More information about the areas impacted can be found in the JEP itself.
>>> 
>>> 
>>> Testing:
>>> 
>>> A slightly earlier version of this change successfully passed tier1-8, as well as client tier1-2. Additional testing will be done after the first round of reviews has been completed.
>>> 
>>> Cheers,
>>> Mikael
>>> 
>>> [1] http://cr.openjdk.java.net/~mikael/webrevs/8244224/webrev.00/all/open/webrev/
>>> 


From Sergey.Bylokhov at oracle.com  Thu May  7 23:54:07 2020
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Thu, 7 May 2020 16:54:07 -0700
Subject: <AWT Dev> <Swing Dev> RFR: 8244224: Implementation of JEP 381:
 Remove the Solaris and SPARC Ports - (client/desktop)
In-Reply-To: <5EB452D0.3060309@oracle.com>
References: <F7749CA3-5EBC-493F-A500-E4AF2741D2CB@oracle.com>
 <3D91D7AE-11DB-4E80-B9A2-DAF6A96E24E6@oracle.com>
 <5EB452D0.3060309@oracle.com>
Message-ID: <8d229cb5-7616-b6b8-6b13-17fdb7633cef@oracle.com>

Looks fine.

On 5/7/20 11:26 am, Philip Race wrote:
> This is all +1 from me.
> 
> -phil.
> 
> On 5/6/20, 5:50 PM, Mikael Vidstedt wrote:
>> Sergey/Shura, thank you for the reviews. I reverted the Jemmy changes, and found some additional Sun Studio cleanups.
>>
>> New webrev here:
>>
>> webrev: http://cr.openjdk.java.net/~mikael/webrevs/8244224/webrev.01/client/open/webrev/
>> incremental: http://cr.openjdk.java.net/~mikael/webrevs/8244224/webrev.01/client.incr/open/webrev/
>>
>> Cheers,
>> Mikael
>>
>>> On May 3, 2020, at 10:12 PM, Mikael Vidstedt<mikael.vidstedt at oracle.com>? wrote:
>>>
>>>
>>> Please review this change which implements part of JEP 381:
>>>
>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8244224
>>> webrev: http://cr.openjdk.java.net/~mikael/webrevs/8244224/webrev.00/client/open/webrev/
>>> JEP: https://bugs.openjdk.java.net/browse/JDK-8241787
>>>
>>>
>>> Note: When reviewing this, please be aware that this exercise was *extremely* mind-numbing, so I appreciate your help reviewing all the individual changes carefully. You may want to get that coffee cup filled up (or whatever keeps you awake)!
>>>
>>>
>>> Background:
>>>
>>> Because of the size of the total patch and wide range of areas touched, this patch is one out of in total six partial patches which together make up the necessary changes to remove the Solaris and SPARC ports. The other patches are being sent out for review to mailing lists appropriate for the respective areas the touch. An email will be sent to jdk-dev summarizing all the patches/reviews. To be clear: this patch is *not* in itself complete and stand-alone - all of the (six) patches are needed to form a complete patch. Some changes in this patch may look wrong or incomplete unless also looking at the corresponding changes in other areas.
>>>
>>> For convenience, I?m including a link below[1] to the full webrev, but in case you have comments on changes in other areas, outside of the files included in this thread, please provide those comments directly in the thread on the appropriate mailing list for that area if possible.
>>>
>>> In case it helps, the changes were effectively produced by searching for and updating any code mentioning ?solaris", ?sparc?, ?solstudio?, ?sunos?, etc. More information about the areas impacted can be found in the JEP itself.
>>>
>>>
>>> Testing:
>>>
>>> A slightly earlier version of this change successfully passed tier1-8, as well as client tier1-2. Additional testing will be done after the first round of reviews has been completed.
>>>
>>> Cheers,
>>> Mikael
>>>
>>> [1] http://cr.openjdk.java.net/~mikael/webrevs/8244224/webrev.00/all/open/webrev/
>>>


-- 
Best regards, Sergey.

From Sergey.Bylokhov at oracle.com  Fri May  8 06:09:49 2020
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Thu, 7 May 2020 23:09:49 -0700
Subject: <AWT Dev> RFR: 8243925 Toolkit#getScreenInsets() returns wrong
 value on HiDPI screens (Windows)
In-Reply-To: <eeddcd22-d0d3-f87e-2cf7-a6fb6451afc7@oracle.com>
References: <4ba81a39-b7ca-7b59-4b54-f5009eb43bcf@oracle.com>
 <eeddcd22-d0d3-f87e-2cf7-a6fb6451afc7@oracle.com>
Message-ID: <fb5ba94e-cab0-edce-e80e-42ce3a34829f@oracle.com>

Hi, Prasanta.

On Linux, it should generally pass because we already scale the insets there,
but sometimes this test fails due to size mismatches, we have some rounding
issues during the calculation and conversion from the device to userspace.

It looks like when I commented out the fractional scales I also accidentally
delete the assertion in the test.

Here is an update test:
http://cr.openjdk.java.net/~serb/8243925/webrev.04
The fractional scales were returned, but the test is excluded on Linux. I
will fix that separately.


On 5/7/20 2:27 am, Prasanta Sadhukhan wrote:
> Hi Sergey,
> 
> The regression test pass for me on windows and linux even without the fix
> 
> Regards
> Prasanta
> On 30-Apr-20 3:10 AM, Sergey Bylokhov wrote:
>> Hello.
>> Please review the fix for jdk/client.
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8243925
>> Fix: http://cr.openjdk.java.net/~serb/8243925/webrev.02
>>
>> One more place when we return the data in pixels, without
>> proper conversation to the user's space.
>>
>> On macOS, this conversion is done by the OS, on Linux we already
>> convert the data. The only missing platform is Windows. Note that
>> we still have an inadequate specification for this and some other
>> Toolkit API which states that results are in "in pixels".
>>
>> I will file the separate bug to update the spec because this bug
>> I would like to backport to 11.
>>
>> The bug was found during work on
>> https://bugs.openjdk.java.net/browse/JDK-8231564
>>
>>


-- 
Best regards, Sergey.

From prasanta.sadhukhan at oracle.com  Thu May 14 06:51:18 2020
From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan)
Date: Thu, 14 May 2020 12:21:18 +0530
Subject: <AWT Dev> RFR: 8243925 Toolkit#getScreenInsets() returns wrong
 value on HiDPI screens (Windows)
In-Reply-To: <fb5ba94e-cab0-edce-e80e-42ce3a34829f@oracle.com>
References: <4ba81a39-b7ca-7b59-4b54-f5009eb43bcf@oracle.com>
 <eeddcd22-d0d3-f87e-2cf7-a6fb6451afc7@oracle.com>
 <fb5ba94e-cab0-edce-e80e-42ce3a34829f@oracle.com>
Message-ID: <123514fa-c1ff-1286-e28f-935b3c5c413c@oracle.com>

Hi Sergey,

Shouldn't we need to use ScaleDownY() for top and bottom?

Also, I think you like to rename runPocess() to runProcess() in the test ?

Regards
Prasanta
On 08-May-20 11:39 AM, Sergey Bylokhov wrote:
> Hi, Prasanta.
>
> On Linux, it should generally pass because we already scale the insets 
> there,
> but sometimes this test fails due to size mismatches, we have some 
> rounding
> issues during the calculation and conversion from the device to 
> userspace.
>
> It looks like when I commented out the fractional scales I also 
> accidentally
> delete the assertion in the test.
>
> Here is an update test:
> http://cr.openjdk.java.net/~serb/8243925/webrev.04
> The fractional scales were returned, but the test is excluded on Linux. I
> will fix that separately.
>
>
> On 5/7/20 2:27 am, Prasanta Sadhukhan wrote:
>> Hi Sergey,
>>
>> The regression test pass for me on windows and linux even without the 
>> fix
>>
>> Regards
>> Prasanta
>> On 30-Apr-20 3:10 AM, Sergey Bylokhov wrote:
>>> Hello.
>>> Please review the fix for jdk/client.
>>>
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8243925
>>> Fix: http://cr.openjdk.java.net/~serb/8243925/webrev.02
>>>
>>> One more place when we return the data in pixels, without
>>> proper conversation to the user's space.
>>>
>>> On macOS, this conversion is done by the OS, on Linux we already
>>> convert the data. The only missing platform is Windows. Note that
>>> we still have an inadequate specification for this and some other
>>> Toolkit API which states that results are in "in pixels".
>>>
>>> I will file the separate bug to update the spec because this bug
>>> I would like to backport to 11.
>>>
>>> The bug was found during work on
>>> https://bugs.openjdk.java.net/browse/JDK-8231564
>>>
>>>
>
>

From Sergey.Bylokhov at oracle.com  Thu May 14 14:14:26 2020
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Thu, 14 May 2020 07:14:26 -0700
Subject: <AWT Dev> RFR: 8243925 Toolkit#getScreenInsets() returns wrong
 value on HiDPI screens (Windows)
In-Reply-To: <123514fa-c1ff-1286-e28f-935b3c5c413c@oracle.com>
References: <4ba81a39-b7ca-7b59-4b54-f5009eb43bcf@oracle.com>
 <eeddcd22-d0d3-f87e-2cf7-a6fb6451afc7@oracle.com>
 <fb5ba94e-cab0-edce-e80e-42ce3a34829f@oracle.com>
 <123514fa-c1ff-1286-e28f-935b3c5c413c@oracle.com>
Message-ID: <67620a73-23c9-17ac-f54d-8a3ec3a3822b@oracle.com>

On 5/13/20 11:51 pm, Prasanta Sadhukhan wrote:
> Shouldn't we need to use ScaleDownY() for top and bottom?
> Also, I think you like to rename runPocess() to runProcess() in the test ?

Right! I have also updated the test from which I copied the typo:
http://cr.openjdk.java.net/~serb/8243925/webrev.05

> 
> Regards
> Prasanta
> On 08-May-20 11:39 AM, Sergey Bylokhov wrote:
>> Hi, Prasanta.
>>
>> On Linux, it should generally pass because we already scale the insets there,
>> but sometimes this test fails due to size mismatches, we have some rounding
>> issues during the calculation and conversion from the device to userspace.
>>
>> It looks like when I commented out the fractional scales I also accidentally
>> delete the assertion in the test.
>>
>> Here is an update test:
>> http://cr.openjdk.java.net/~serb/8243925/webrev.04
>> The fractional scales were returned, but the test is excluded on Linux. I
>> will fix that separately.
>>
>>
>> On 5/7/20 2:27 am, Prasanta Sadhukhan wrote:
>>> Hi Sergey,
>>>
>>> The regression test pass for me on windows and linux even without the fix
>>>
>>> Regards
>>> Prasanta
>>> On 30-Apr-20 3:10 AM, Sergey Bylokhov wrote:
>>>> Hello.
>>>> Please review the fix for jdk/client.
>>>>
>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8243925
>>>> Fix: http://cr.openjdk.java.net/~serb/8243925/webrev.02
>>>>
>>>> One more place when we return the data in pixels, without
>>>> proper conversation to the user's space.
>>>>
>>>> On macOS, this conversion is done by the OS, on Linux we already
>>>> convert the data. The only missing platform is Windows. Note that
>>>> we still have an inadequate specification for this and some other
>>>> Toolkit API which states that results are in "in pixels".
>>>>
>>>> I will file the separate bug to update the spec because this bug
>>>> I would like to backport to 11.
>>>>
>>>> The bug was found during work on
>>>> https://bugs.openjdk.java.net/browse/JDK-8231564
>>>>
>>>>
>>
>>


-- 
Best regards, Sergey.

From philip.race at oracle.com  Thu May 14 22:20:22 2020
From: philip.race at oracle.com (Philip Race)
Date: Thu, 14 May 2020 15:20:22 -0700
Subject: <AWT Dev> Project Lana EA build now available at
 https://jdk.java.net/lanai/ - feedback requested.
Message-ID: <5EBDC426.3020508@oracle.com>

The first EA build of Project Lanai is available at 
https://jdk.java.net/lanai/

This is a new Java2D graphics pipeline for macOS.

It can run the usual client demos, such as SwingSet2 and J2Ddemo,
and even a large app like an IDE, although not without glitches.
The EA download page has a link to the list of known, open bugs you can 
consult.

It is a first EA build and there is plenty of work still to be done
and we have doubtless not tested every situation nor do we have
every piece of mac hardware out there, so there will be unreported 
issues too.

Please try it, and provide feedback to the lanai-dev at openjdk.java.net 
mailing list.

Make sure you specify -Dsun.java2d.metal=true  !!

-phil.






From prasanta.sadhukhan at oracle.com  Fri May 15 05:52:06 2020
From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan)
Date: Fri, 15 May 2020 11:22:06 +0530
Subject: <AWT Dev> RFR: 8243925 Toolkit#getScreenInsets() returns wrong
 value on HiDPI screens (Windows)
In-Reply-To: <67620a73-23c9-17ac-f54d-8a3ec3a3822b@oracle.com>
References: <4ba81a39-b7ca-7b59-4b54-f5009eb43bcf@oracle.com>
 <eeddcd22-d0d3-f87e-2cf7-a6fb6451afc7@oracle.com>
 <fb5ba94e-cab0-edce-e80e-42ce3a34829f@oracle.com>
 <123514fa-c1ff-1286-e28f-935b3c5c413c@oracle.com>
 <67620a73-23c9-17ac-f54d-8a3ec3a3822b@oracle.com>
Message-ID: <3edeb6d3-fdef-df77-5af6-745f661b3631@oracle.com>

I believe the test should not be marked headful as no visible component 
is being shown. Rest looks ok.

Regards
Prasanta
On 14-May-20 7:44 PM, Sergey Bylokhov wrote:
> On 5/13/20 11:51 pm, Prasanta Sadhukhan wrote:
>> Shouldn't we need to use ScaleDownY() for top and bottom?
>> Also, I think you like to rename runPocess() to runProcess() in the 
>> test ?
>
> Right! I have also updated the test from which I copied the typo:
> http://cr.openjdk.java.net/~serb/8243925/webrev.05
>
>>
>> Regards
>> Prasanta
>> On 08-May-20 11:39 AM, Sergey Bylokhov wrote:
>>> Hi, Prasanta.
>>>
>>> On Linux, it should generally pass because we already scale the 
>>> insets there,
>>> but sometimes this test fails due to size mismatches, we have some 
>>> rounding
>>> issues during the calculation and conversion from the device to 
>>> userspace.
>>>
>>> It looks like when I commented out the fractional scales I also 
>>> accidentally
>>> delete the assertion in the test.
>>>
>>> Here is an update test:
>>> http://cr.openjdk.java.net/~serb/8243925/webrev.04
>>> The fractional scales were returned, but the test is excluded on 
>>> Linux. I
>>> will fix that separately.
>>>
>>>
>>> On 5/7/20 2:27 am, Prasanta Sadhukhan wrote:
>>>> Hi Sergey,
>>>>
>>>> The regression test pass for me on windows and linux even without 
>>>> the fix
>>>>
>>>> Regards
>>>> Prasanta
>>>> On 30-Apr-20 3:10 AM, Sergey Bylokhov wrote:
>>>>> Hello.
>>>>> Please review the fix for jdk/client.
>>>>>
>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8243925
>>>>> Fix: http://cr.openjdk.java.net/~serb/8243925/webrev.02
>>>>>
>>>>> One more place when we return the data in pixels, without
>>>>> proper conversation to the user's space.
>>>>>
>>>>> On macOS, this conversion is done by the OS, on Linux we already
>>>>> convert the data. The only missing platform is Windows. Note that
>>>>> we still have an inadequate specification for this and some other
>>>>> Toolkit API which states that results are in "in pixels".
>>>>>
>>>>> I will file the separate bug to update the spec because this bug
>>>>> I would like to backport to 11.
>>>>>
>>>>> The bug was found during work on
>>>>> https://bugs.openjdk.java.net/browse/JDK-8231564
>>>>>
>>>>>
>>>
>>>
>
>

From Sergey.Bylokhov at oracle.com  Fri May 15 10:29:07 2020
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Fri, 15 May 2020 03:29:07 -0700
Subject: <AWT Dev> RFR: 8243925 Toolkit#getScreenInsets() returns wrong
 value on HiDPI screens (Windows)
In-Reply-To: <3edeb6d3-fdef-df77-5af6-745f661b3631@oracle.com>
References: <4ba81a39-b7ca-7b59-4b54-f5009eb43bcf@oracle.com>
 <eeddcd22-d0d3-f87e-2cf7-a6fb6451afc7@oracle.com>
 <fb5ba94e-cab0-edce-e80e-42ce3a34829f@oracle.com>
 <123514fa-c1ff-1286-e28f-935b3c5c413c@oracle.com>
 <67620a73-23c9-17ac-f54d-8a3ec3a3822b@oracle.com>
 <3edeb6d3-fdef-df77-5af6-745f661b3631@oracle.com>
Message-ID: <37ef4f51-5197-a6ff-1ac0-def387fe3a6e@oracle.com>

On 5/14/20 10:52 pm, Prasanta Sadhukhan wrote:
> I believe the test should not be marked headful as no visible component is being shown. Rest looks ok.

If this keyword will be removed then the test will be skipped during our headful testing on headful systems.

> Regards
> Prasanta
> On 14-May-20 7:44 PM, Sergey Bylokhov wrote:
>> On 5/13/20 11:51 pm, Prasanta Sadhukhan wrote:
>>> Shouldn't we need to use ScaleDownY() for top and bottom?
>>> Also, I think you like to rename runPocess() to runProcess() in the test ?
>>
>> Right! I have also updated the test from which I copied the typo:
>> http://cr.openjdk.java.net/~serb/8243925/webrev.05
>>
>>>
>>> Regards
>>> Prasanta
>>> On 08-May-20 11:39 AM, Sergey Bylokhov wrote:
>>>> Hi, Prasanta.
>>>>
>>>> On Linux, it should generally pass because we already scale the insets there,
>>>> but sometimes this test fails due to size mismatches, we have some rounding
>>>> issues during the calculation and conversion from the device to userspace.
>>>>
>>>> It looks like when I commented out the fractional scales I also accidentally
>>>> delete the assertion in the test.
>>>>
>>>> Here is an update test:
>>>> http://cr.openjdk.java.net/~serb/8243925/webrev.04
>>>> The fractional scales were returned, but the test is excluded on Linux. I
>>>> will fix that separately.
>>>>
>>>>
>>>> On 5/7/20 2:27 am, Prasanta Sadhukhan wrote:
>>>>> Hi Sergey,
>>>>>
>>>>> The regression test pass for me on windows and linux even without the fix
>>>>>
>>>>> Regards
>>>>> Prasanta
>>>>> On 30-Apr-20 3:10 AM, Sergey Bylokhov wrote:
>>>>>> Hello.
>>>>>> Please review the fix for jdk/client.
>>>>>>
>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8243925
>>>>>> Fix: http://cr.openjdk.java.net/~serb/8243925/webrev.02
>>>>>>
>>>>>> One more place when we return the data in pixels, without
>>>>>> proper conversation to the user's space.
>>>>>>
>>>>>> On macOS, this conversion is done by the OS, on Linux we already
>>>>>> convert the data. The only missing platform is Windows. Note that
>>>>>> we still have an inadequate specification for this and some other
>>>>>> Toolkit API which states that results are in "in pixels".
>>>>>>
>>>>>> I will file the separate bug to update the spec because this bug
>>>>>> I would like to backport to 11.
>>>>>>
>>>>>> The bug was found during work on
>>>>>> https://bugs.openjdk.java.net/browse/JDK-8231564
>>>>>>
>>>>>>
>>>>
>>>>
>>
>>


-- 
Best regards, Sergey.

From prasanta.sadhukhan at oracle.com  Fri May 15 10:31:59 2020
From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan)
Date: Fri, 15 May 2020 16:01:59 +0530
Subject: <AWT Dev> RFR: 8243925 Toolkit#getScreenInsets() returns wrong
 value on HiDPI screens (Windows)
In-Reply-To: <37ef4f51-5197-a6ff-1ac0-def387fe3a6e@oracle.com>
References: <4ba81a39-b7ca-7b59-4b54-f5009eb43bcf@oracle.com>
 <eeddcd22-d0d3-f87e-2cf7-a6fb6451afc7@oracle.com>
 <fb5ba94e-cab0-edce-e80e-42ce3a34829f@oracle.com>
 <123514fa-c1ff-1286-e28f-935b3c5c413c@oracle.com>
 <67620a73-23c9-17ac-f54d-8a3ec3a3822b@oracle.com>
 <3edeb6d3-fdef-df77-5af6-745f661b3631@oracle.com>
 <37ef4f51-5197-a6ff-1ac0-def387fe3a6e@oracle.com>
Message-ID: <1b7efb15-7bd5-a1b7-dbe7-23f1e4fa21fd@oracle.com>


On 15-May-20 3:59 PM, Sergey Bylokhov wrote:
> On 5/14/20 10:52 pm, Prasanta Sadhukhan wrote:
>> I believe the test should not be marked headful as no visible 
>> component is being shown. Rest looks ok.
>
> If this keyword will be removed then the test will be skipped during 
> our headful testing on headful systems.
>
Yes, but what is the problem if it will be tested as headless? why there 
is a need to test on headful systems?
>> Regards
>> Prasanta
>> On 14-May-20 7:44 PM, Sergey Bylokhov wrote:
>>> On 5/13/20 11:51 pm, Prasanta Sadhukhan wrote:
>>>> Shouldn't we need to use ScaleDownY() for top and bottom?
>>>> Also, I think you like to rename runPocess() to runProcess() in the 
>>>> test ?
>>>
>>> Right! I have also updated the test from which I copied the typo:
>>> http://cr.openjdk.java.net/~serb/8243925/webrev.05
>>>
>>>>
>>>> Regards
>>>> Prasanta
>>>> On 08-May-20 11:39 AM, Sergey Bylokhov wrote:
>>>>> Hi, Prasanta.
>>>>>
>>>>> On Linux, it should generally pass because we already scale the 
>>>>> insets there,
>>>>> but sometimes this test fails due to size mismatches, we have some 
>>>>> rounding
>>>>> issues during the calculation and conversion from the device to 
>>>>> userspace.
>>>>>
>>>>> It looks like when I commented out the fractional scales I also 
>>>>> accidentally
>>>>> delete the assertion in the test.
>>>>>
>>>>> Here is an update test:
>>>>> http://cr.openjdk.java.net/~serb/8243925/webrev.04
>>>>> The fractional scales were returned, but the test is excluded on 
>>>>> Linux. I
>>>>> will fix that separately.
>>>>>
>>>>>
>>>>> On 5/7/20 2:27 am, Prasanta Sadhukhan wrote:
>>>>>> Hi Sergey,
>>>>>>
>>>>>> The regression test pass for me on windows and linux even without 
>>>>>> the fix
>>>>>>
>>>>>> Regards
>>>>>> Prasanta
>>>>>> On 30-Apr-20 3:10 AM, Sergey Bylokhov wrote:
>>>>>>> Hello.
>>>>>>> Please review the fix for jdk/client.
>>>>>>>
>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8243925
>>>>>>> Fix: http://cr.openjdk.java.net/~serb/8243925/webrev.02
>>>>>>>
>>>>>>> One more place when we return the data in pixels, without
>>>>>>> proper conversation to the user's space.
>>>>>>>
>>>>>>> On macOS, this conversion is done by the OS, on Linux we already
>>>>>>> convert the data. The only missing platform is Windows. Note that
>>>>>>> we still have an inadequate specification for this and some other
>>>>>>> Toolkit API which states that results are in "in pixels".
>>>>>>>
>>>>>>> I will file the separate bug to update the spec because this bug
>>>>>>> I would like to backport to 11.
>>>>>>>
>>>>>>> The bug was found during work on
>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8231564
>>>>>>>
>>>>>>>
>>>>>
>>>>>
>>>
>>>
>
>

From philip.race at oracle.com  Fri May 15 15:01:47 2020
From: philip.race at oracle.com (Philip Race)
Date: Fri, 15 May 2020 08:01:47 -0700
Subject: <AWT Dev> RFR: 8243925 Toolkit#getScreenInsets() returns wrong
 value on HiDPI screens (Windows)
In-Reply-To: <1b7efb15-7bd5-a1b7-dbe7-23f1e4fa21fd@oracle.com>
References: <4ba81a39-b7ca-7b59-4b54-f5009eb43bcf@oracle.com>
 <eeddcd22-d0d3-f87e-2cf7-a6fb6451afc7@oracle.com>
 <fb5ba94e-cab0-edce-e80e-42ce3a34829f@oracle.com>
 <123514fa-c1ff-1286-e28f-935b3c5c413c@oracle.com>
 <67620a73-23c9-17ac-f54d-8a3ec3a3822b@oracle.com>
 <3edeb6d3-fdef-df77-5af6-745f661b3631@oracle.com>
 <37ef4f51-5197-a6ff-1ac0-def387fe3a6e@oracle.com>
 <1b7efb15-7bd5-a1b7-dbe7-23f1e4fa21fd@oracle.com>
Message-ID: <5EBEAEDB.4070008@oracle.com>

The whole point is to test a headful config and in any case  :-

https://docs.oracle.com/en/java/javase/11/docs/api/java.desktop/java/awt/Toolkit.html#getScreenInsets(java.awt.GraphicsConfiguration)

publicInsets  <https://docs.oracle.com/en/java/javase/11/docs/api/java.desktop/java/awt/Insets.html>  getScreenInsets?(GraphicsConfiguration  <https://docs.oracle.com/en/java/javase/11/docs/api/java.desktop/java/awt/GraphicsConfiguration.html>  gc)
                        throwsHeadlessException  <https://docs.oracle.com/en/java/javase/11/docs/api/java.desktop/java/awt/HeadlessException.html>

Gets the insets of the screen.

Parameters:
    |gc| - a |GraphicsConfiguration|
Returns:
    the insets of this toolkit's screen, in pixels.
Throws:
    |HeadlessException
    <https://docs.oracle.com/en/java/javase/11/docs/api/java.desktop/java/awt/HeadlessException.html>|
    - if GraphicsEnvironment.isHeadless() returns true
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

-phil


On 5/15/20, 3:31 AM, Prasanta Sadhukhan wrote:
>
> On 15-May-20 3:59 PM, Sergey Bylokhov wrote:
>> On 5/14/20 10:52 pm, Prasanta Sadhukhan wrote:
>>> I believe the test should not be marked headful as no visible 
>>> component is being shown. Rest looks ok.
>>
>> If this keyword will be removed then the test will be skipped during 
>> our headful testing on headful systems.
>>
> Yes, but what is the problem if it will be tested as headless? why 
> there is a need to test on headful systems?
>>> Regards
>>> Prasanta
>>> On 14-May-20 7:44 PM, Sergey Bylokhov wrote:
>>>> On 5/13/20 11:51 pm, Prasanta Sadhukhan wrote:
>>>>> Shouldn't we need to use ScaleDownY() for top and bottom?
>>>>> Also, I think you like to rename runPocess() to runProcess() in 
>>>>> the test ?
>>>>
>>>> Right! I have also updated the test from which I copied the typo:
>>>> http://cr.openjdk.java.net/~serb/8243925/webrev.05
>>>>
>>>>>
>>>>> Regards
>>>>> Prasanta
>>>>> On 08-May-20 11:39 AM, Sergey Bylokhov wrote:
>>>>>> Hi, Prasanta.
>>>>>>
>>>>>> On Linux, it should generally pass because we already scale the 
>>>>>> insets there,
>>>>>> but sometimes this test fails due to size mismatches, we have 
>>>>>> some rounding
>>>>>> issues during the calculation and conversion from the device to 
>>>>>> userspace.
>>>>>>
>>>>>> It looks like when I commented out the fractional scales I also 
>>>>>> accidentally
>>>>>> delete the assertion in the test.
>>>>>>
>>>>>> Here is an update test:
>>>>>> http://cr.openjdk.java.net/~serb/8243925/webrev.04
>>>>>> The fractional scales were returned, but the test is excluded on 
>>>>>> Linux. I
>>>>>> will fix that separately.
>>>>>>
>>>>>>
>>>>>> On 5/7/20 2:27 am, Prasanta Sadhukhan wrote:
>>>>>>> Hi Sergey,
>>>>>>>
>>>>>>> The regression test pass for me on windows and linux even 
>>>>>>> without the fix
>>>>>>>
>>>>>>> Regards
>>>>>>> Prasanta
>>>>>>> On 30-Apr-20 3:10 AM, Sergey Bylokhov wrote:
>>>>>>>> Hello.
>>>>>>>> Please review the fix for jdk/client.
>>>>>>>>
>>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8243925
>>>>>>>> Fix: http://cr.openjdk.java.net/~serb/8243925/webrev.02
>>>>>>>>
>>>>>>>> One more place when we return the data in pixels, without
>>>>>>>> proper conversation to the user's space.
>>>>>>>>
>>>>>>>> On macOS, this conversion is done by the OS, on Linux we already
>>>>>>>> convert the data. The only missing platform is Windows. Note that
>>>>>>>> we still have an inadequate specification for this and some other
>>>>>>>> Toolkit API which states that results are in "in pixels".
>>>>>>>>
>>>>>>>> I will file the separate bug to update the spec because this bug
>>>>>>>> I would like to backport to 11.
>>>>>>>>
>>>>>>>> The bug was found during work on
>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8231564
>>>>>>>>
>>>>>>>>
>>>>>>
>>>>>>
>>>>
>>>>
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/awt-dev/attachments/20200515/6c57f887/attachment.htm>

From prasanta.sadhukhan at oracle.com  Sun May 17 11:04:06 2020
From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan)
Date: Sun, 17 May 2020 16:34:06 +0530
Subject: <AWT Dev> RFR: 8243925 Toolkit#getScreenInsets() returns wrong
 value on HiDPI screens (Windows)
In-Reply-To: <5EBEAEDB.4070008@oracle.com>
References: <4ba81a39-b7ca-7b59-4b54-f5009eb43bcf@oracle.com>
 <eeddcd22-d0d3-f87e-2cf7-a6fb6451afc7@oracle.com>
 <fb5ba94e-cab0-edce-e80e-42ce3a34829f@oracle.com>
 <123514fa-c1ff-1286-e28f-935b3c5c413c@oracle.com>
 <67620a73-23c9-17ac-f54d-8a3ec3a3822b@oracle.com>
 <3edeb6d3-fdef-df77-5af6-745f661b3631@oracle.com>
 <37ef4f51-5197-a6ff-1ac0-def387fe3a6e@oracle.com>
 <1b7efb15-7bd5-a1b7-dbe7-23f1e4fa21fd@oracle.com>
 <5EBEAEDB.4070008@oracle.com>
Message-ID: <5e947c35-05cd-ef10-88af-f8adb4a8d5ec@oracle.com>

OK. Looks good then.

Regards
Prasanta
On 15-May-20 8:31 PM, Philip Race wrote:
> The whole point is to test a headful config and in any case? :-
>
> https://docs.oracle.com/en/java/javase/11/docs/api/java.desktop/java/awt/Toolkit.html#getScreenInsets(java.awt.GraphicsConfiguration)
>
> publicInsets  <https://docs.oracle.com/en/java/javase/11/docs/api/java.desktop/java/awt/Insets.html> ?getScreenInsets?(GraphicsConfiguration  <https://docs.oracle.com/en/java/javase/11/docs/api/java.desktop/java/awt/GraphicsConfiguration.html> ?gc)
>                         throwsHeadlessException  <https://docs.oracle.com/en/java/javase/11/docs/api/java.desktop/java/awt/HeadlessException.html>
> Gets the insets of the screen.
>
> Parameters:
>     |gc| - a |GraphicsConfiguration|
> Returns:
>     the insets of this toolkit's screen, in pixels.
> Throws:
>     |HeadlessException
>     <https://docs.oracle.com/en/java/javase/11/docs/api/java.desktop/java/awt/HeadlessException.html>|
>     - if GraphicsEnvironment.isHeadless() returns true
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>
> -phil
>
>
> On 5/15/20, 3:31 AM, Prasanta Sadhukhan wrote:
>>
>> On 15-May-20 3:59 PM, Sergey Bylokhov wrote:
>>> On 5/14/20 10:52 pm, Prasanta Sadhukhan wrote:
>>>> I believe the test should not be marked headful as no visible 
>>>> component is being shown. Rest looks ok.
>>>
>>> If this keyword will be removed then the test will be skipped during 
>>> our headful testing on headful systems.
>>>
>> Yes, but what is the problem if it will be tested as headless? why 
>> there is a need to test on headful systems?
>>>> Regards
>>>> Prasanta
>>>> On 14-May-20 7:44 PM, Sergey Bylokhov wrote:
>>>>> On 5/13/20 11:51 pm, Prasanta Sadhukhan wrote:
>>>>>> Shouldn't we need to use ScaleDownY() for top and bottom?
>>>>>> Also, I think you like to rename runPocess() to runProcess() in 
>>>>>> the test ?
>>>>>
>>>>> Right! I have also updated the test from which I copied the typo:
>>>>> http://cr.openjdk.java.net/~serb/8243925/webrev.05
>>>>>
>>>>>>
>>>>>> Regards
>>>>>> Prasanta
>>>>>> On 08-May-20 11:39 AM, Sergey Bylokhov wrote:
>>>>>>> Hi, Prasanta.
>>>>>>>
>>>>>>> On Linux, it should generally pass because we already scale the 
>>>>>>> insets there,
>>>>>>> but sometimes this test fails due to size mismatches, we have 
>>>>>>> some rounding
>>>>>>> issues during the calculation and conversion from the device to 
>>>>>>> userspace.
>>>>>>>
>>>>>>> It looks like when I commented out the fractional scales I also 
>>>>>>> accidentally
>>>>>>> delete the assertion in the test.
>>>>>>>
>>>>>>> Here is an update test:
>>>>>>> http://cr.openjdk.java.net/~serb/8243925/webrev.04
>>>>>>> The fractional scales were returned, but the test is excluded on 
>>>>>>> Linux. I
>>>>>>> will fix that separately.
>>>>>>>
>>>>>>>
>>>>>>> On 5/7/20 2:27 am, Prasanta Sadhukhan wrote:
>>>>>>>> Hi Sergey,
>>>>>>>>
>>>>>>>> The regression test pass for me on windows and linux even 
>>>>>>>> without the fix
>>>>>>>>
>>>>>>>> Regards
>>>>>>>> Prasanta
>>>>>>>> On 30-Apr-20 3:10 AM, Sergey Bylokhov wrote:
>>>>>>>>> Hello.
>>>>>>>>> Please review the fix for jdk/client.
>>>>>>>>>
>>>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8243925
>>>>>>>>> Fix: http://cr.openjdk.java.net/~serb/8243925/webrev.02
>>>>>>>>>
>>>>>>>>> One more place when we return the data in pixels, without
>>>>>>>>> proper conversation to the user's space.
>>>>>>>>>
>>>>>>>>> On macOS, this conversion is done by the OS, on Linux we already
>>>>>>>>> convert the data. The only missing platform is Windows. Note that
>>>>>>>>> we still have an inadequate specification for this and some other
>>>>>>>>> Toolkit API which states that results are in "in pixels".
>>>>>>>>>
>>>>>>>>> I will file the separate bug to update the spec because this bug
>>>>>>>>> I would like to backport to 11.
>>>>>>>>>
>>>>>>>>> The bug was found during work on
>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8231564
>>>>>>>>>
>>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>
>>>>>
>>>
>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/awt-dev/attachments/20200517/808531aa/attachment.htm>

From JAYATHIRTH.D.V at ORACLE.COM  Mon May 18 11:18:23 2020
From: JAYATHIRTH.D.V at ORACLE.COM (Jayathirth D v)
Date: Mon, 18 May 2020 16:48:23 +0530
Subject: <AWT Dev> RFR 8028701:
 java/awt/Focus/ShowFrameCheckForegroundTest/ShowFrameCheckForegroundTest.java
 fails
Message-ID: <B2026853-2CF0-4152-943C-E2708ACF84AF@ORACLE.COM>

Hello All,

Please review the following fix in JDK 15:

Bug : https://bugs.openjdk.java.net/browse/JDK-8028701 <https://bugs.openjdk.java.net/browse/JDK-8028701> 
Webrev : http://cr.openjdk.java.net/~jdv/8028701/webrev.00/ <http://cr.openjdk.java.net/~jdv/8028701/webrev.00/> 

This test was problem listed because it was failing intermittently in our CI system and almost all ways of fixing it was failure. Most probably because of bad configuration in particular system.

Ran this test multiple times and it passes now so removing it from problem list.

Thanks,
Jay
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/awt-dev/attachments/20200518/e1432e19/attachment.htm>

From pankaj.b.bansal at oracle.com  Mon May 18 17:33:26 2020
From: pankaj.b.bansal at oracle.com (Pankaj Bansal)
Date: Mon, 18 May 2020 23:03:26 +0530
Subject: <AWT Dev> RFR 8028701:
 java/awt/Focus/ShowFrameCheckForegroundTest/ShowFrameCheckForegroundTest.java
 fails
In-Reply-To: <B2026853-2CF0-4152-943C-E2708ACF84AF@ORACLE.COM>
References: <B2026853-2CF0-4152-943C-E2708ACF84AF@ORACLE.COM>
Message-ID: <fe0bd463-e3b5-3a82-43d8-eb81290fb575@oracle.com>

Is the test now passing continuously in our nightly?

Regards,

Pankaj


On 18/05/20 4:48 PM, Jayathirth D v wrote:
> Hello All,
>
> Please review the following fix in JDK 15:
>
> Bug : https://bugs.openjdk.java.net/browse/JDK-8028701
> Webrev : http://cr.openjdk.java.net/~jdv/8028701/webrev.00/ 
> <http://cr.openjdk.java.net/%7Ejdv/8028701/webrev.00/>
>
> This test was problem listed because it was failing intermittently in 
> our CI system and almost all ways of fixing it was failure. Most 
> probably because of bad configuration in particular system.
>
> Ran this test multiple times and it passes now so removing it from 
> problem list.
>
> Thanks,
> Jay


From pankaj.b.bansal at oracle.com  Tue May 19 02:14:48 2020
From: pankaj.b.bansal at oracle.com (Pankaj Bansal)
Date: Tue, 19 May 2020 07:44:48 +0530
Subject: <AWT Dev> RFR 8028701:
 java/awt/Focus/ShowFrameCheckForegroundTest/ShowFrameCheckForegroundTest.java
 fails
In-Reply-To: <fe0bd463-e3b5-3a82-43d8-eb81290fb575@oracle.com>
References: <B2026853-2CF0-4152-943C-E2708ACF84AF@ORACLE.COM>
 <fe0bd463-e3b5-3a82-43d8-eb81290fb575@oracle.com>
Message-ID: <c98b63c0-7fb5-de75-e9fc-138bec89d2c4@oracle.com>

Actually I meant to ask if you have tried to run the test in group with 
other tests. The test may be passing when run as individual test, but 
may again start failing when run in nightly after removing from ProblemList.


-Pankaj


On 18/05/20 11:03 PM, Pankaj Bansal wrote:
> Is the test now passing continuously in our nightly?
>
> Regards,
>
> Pankaj
>
>
> On 18/05/20 4:48 PM, Jayathirth D v wrote:
>> Hello All,
>>
>> Please review the following fix in JDK 15:
>>
>> Bug : https://bugs.openjdk.java.net/browse/JDK-8028701
>> Webrev : http://cr.openjdk.java.net/~jdv/8028701/webrev.00/ 
>> <http://cr.openjdk.java.net/%7Ejdv/8028701/webrev.00/>
>>
>> This test was problem listed because it was failing intermittently in 
>> our CI system and almost all ways of fixing it was failure. Most 
>> probably because of bad configuration in particular system.
>>
>> Ran this test multiple times and it passes now so removing it from 
>> problem list.
>>
>> Thanks,
>> Jay
>


From JAYATHIRTH.D.V at ORACLE.COM  Tue May 19 08:42:47 2020
From: JAYATHIRTH.D.V at ORACLE.COM (Jayathirth D v)
Date: Tue, 19 May 2020 14:12:47 +0530
Subject: <AWT Dev> RFR 8028701:
 java/awt/Focus/ShowFrameCheckForegroundTest/ShowFrameCheckForegroundTest.java
 fails
In-Reply-To: <c98b63c0-7fb5-de75-e9fc-138bec89d2c4@oracle.com>
References: <B2026853-2CF0-4152-943C-E2708ACF84AF@ORACLE.COM>
 <fe0bd463-e3b5-3a82-43d8-eb81290fb575@oracle.com>
 <c98b63c0-7fb5-de75-e9fc-138bec89d2c4@oracle.com>
Message-ID: <74CC1372-91D7-4451-914A-731CC31DC7D1@ORACLE.COM>

Hi Pankaj,

AFAIK we don?t run problem listed tests in nightly.
I strongly suspect it to be machine configuration issue when this issue was suspected to fail in our internal CI systems(All test stabilisation fixes done were inconclusive).

And I also ran complete awt/focus in our internal CI and ShowFrameCheckForegroundTest is green on all platforms.

Thanks,
Jay

> On 19-May-2020, at 7:44 AM, Pankaj Bansal <pankaj.b.bansal at oracle.com> wrote:
> 
> Actually I meant to ask if you have tried to run the test in group with other tests. The test may be passing when run as individual test, but may again start failing when run in nightly after removing from ProblemList.
> 
> 
> -Pankaj
> 
> 
> On 18/05/20 11:03 PM, Pankaj Bansal wrote:
>> Is the test now passing continuously in our nightly?
>> 
>> Regards,
>> 
>> Pankaj
>> 
>> 
>> On 18/05/20 4:48 PM, Jayathirth D v wrote:
>>> Hello All,
>>> 
>>> Please review the following fix in JDK 15:
>>> 
>>> Bug : https://bugs.openjdk.java.net/browse/JDK-8028701
>>> Webrev : http://cr.openjdk.java.net/~jdv/8028701/webrev.00/ <http://cr.openjdk.java.net/%7Ejdv/8028701/webrev.00/>
>>> 
>>> This test was problem listed because it was failing intermittently in our CI system and almost all ways of fixing it was failure. Most probably because of bad configuration in particular system.
>>> 
>>> Ran this test multiple times and it passes now so removing it from problem list.
>>> 
>>> Thanks,
>>> Jay
>> 
> 


From pankaj.b.bansal at oracle.com  Tue May 19 10:03:09 2020
From: pankaj.b.bansal at oracle.com (Pankaj Bansal)
Date: Tue, 19 May 2020 15:33:09 +0530
Subject: <AWT Dev> RFR 8028701:
 java/awt/Focus/ShowFrameCheckForegroundTest/ShowFrameCheckForegroundTest.java
 fails
In-Reply-To: <74CC1372-91D7-4451-914A-731CC31DC7D1@ORACLE.COM>
References: <B2026853-2CF0-4152-943C-E2708ACF84AF@ORACLE.COM>
 <fe0bd463-e3b5-3a82-43d8-eb81290fb575@oracle.com>
 <c98b63c0-7fb5-de75-e9fc-138bec89d2c4@oracle.com>
 <74CC1372-91D7-4451-914A-731CC31DC7D1@ORACLE.COM>
Message-ID: <fb0c7f7d-af53-1221-1927-6a1736b6a861@oracle.com>

ok, looks good.

-Pankaj


On 19/05/20 2:12 PM, Jayathirth D v wrote:
> Hi Pankaj,
>
> AFAIK we don?t run problem listed tests in nightly.
> I strongly suspect it to be machine configuration issue when this issue was suspected to fail in our internal CI systems(All test stabilisation fixes done were inconclusive).
>
> And I also ran complete awt/focus in our internal CI and ShowFrameCheckForegroundTest is green on all platforms.
>
> Thanks,
> Jay
>
>> On 19-May-2020, at 7:44 AM, Pankaj Bansal <pankaj.b.bansal at oracle.com> wrote:
>>
>> Actually I meant to ask if you have tried to run the test in group with other tests. The test may be passing when run as individual test, but may again start failing when run in nightly after removing from ProblemList.
>>
>>
>> -Pankaj
>>
>>
>> On 18/05/20 11:03 PM, Pankaj Bansal wrote:
>>> Is the test now passing continuously in our nightly?
>>>
>>> Regards,
>>>
>>> Pankaj
>>>
>>>
>>> On 18/05/20 4:48 PM, Jayathirth D v wrote:
>>>> Hello All,
>>>>
>>>> Please review the following fix in JDK 15:
>>>>
>>>> Bug : https://bugs.openjdk.java.net/browse/JDK-8028701
>>>> Webrev : http://cr.openjdk.java.net/~jdv/8028701/webrev.00/ <http://cr.openjdk.java.net/%7Ejdv/8028701/webrev.00/>
>>>>
>>>> This test was problem listed because it was failing intermittently in our CI system and almost all ways of fixing it was failure. Most probably because of bad configuration in particular system.
>>>>
>>>> Ran this test multiple times and it passes now so removing it from problem list.
>>>>
>>>> Thanks,
>>>> Jay


From JAYATHIRTH.D.V at ORACLE.COM  Thu May 21 11:12:19 2020
From: JAYATHIRTH.D.V at ORACLE.COM (Jayathirth D v)
Date: Thu, 21 May 2020 16:42:19 +0530
Subject: <AWT Dev> RFR 8213129:
 java/awt/font/FontNames/LocaleFamilyNames.java times out in Win7
Message-ID: <55BAD64F-CE64-406F-A24C-74C968F273F1@ORACLE.COM>

Hello All,

Please review the following fix in JDK 15:

Bug : https://bugs.openjdk.java.net/browse/JDK-8213129 <https://bugs.openjdk.java.net/browse/JDK-8213129> 
Webrev : http://cr.openjdk.java.net/~jdv/8213129/webrev.00/ <http://cr.openjdk.java.net/~jdv/8213129/webrev.00/> 

This test was problem listed as part of stabilisation process and test was timing out only in my old Win 7 machine continuously.
I ran extensive test in our CI and it doesnt fail/timeout. We should remove it from problem list and run it in our CI.

Thanks,
Jay
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/awt-dev/attachments/20200521/7be3ec2e/attachment.htm>

From prasanta.sadhukhan at oracle.com  Thu May 21 14:41:23 2020
From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan)
Date: Thu, 21 May 2020 20:11:23 +0530
Subject: <AWT Dev> RFR 8213129:
 java/awt/font/FontNames/LocaleFamilyNames.java times out in Win7
In-Reply-To: <55BAD64F-CE64-406F-A24C-74C968F273F1@ORACLE.COM>
References: <55BAD64F-CE64-406F-A24C-74C968F273F1@ORACLE.COM>
Message-ID: <451281c0-46ed-8c02-212c-d0c1d6503fe4@oracle.com>

+1

Regards
Prasanta
On 21-May-20 4:42 PM, Jayathirth D v wrote:
> Hello All,
>
> Please review the following fix in JDK 15:
>
> Bug : https://bugs.openjdk.java.net/browse/JDK-8213129
> Webrev : http://cr.openjdk.java.net/~jdv/8213129/webrev.00/
>
> This test was problem listed as part of stabilisation process and test 
> was timing out only in my old Win 7 machine continuously.
> I ran extensive test in our CI and it doesnt fail/timeout. We should 
> remove it from problem list and run it in our CI.
>
> Thanks,
> Jay

From tejpal.rebari at oracle.com  Fri May 22 10:06:12 2020
From: tejpal.rebari at oracle.com (Tejpal Rebari)
Date: Fri, 22 May 2020 15:36:12 +0530
Subject: <AWT Dev> Fwd: <Swing Dev> RFR: 8239827: The test
 OpenByUNCPathNameTest.java should be changed to be manual
References: <B9E66C81-6971-4111-A6D1-EC5EC9BC1654@oracle.com>
Message-ID: <A224AF61-6176-4DE5-B0F8-FB6B1FFFEBD8@oracle.com>



> Begin forwarded message:
> 
> From: Tejpal Rebari <tejpal.rebari at oracle.com>
> Subject: <Swing Dev> RFR: 8239827: The test OpenByUNCPathNameTest.java should be changed to be manual
> Date: 22 May 2020 at 3:32:45 PM IST
> To: swing-dev at openjdk.java.net
> 
> Hi All,
> Please review the following test only fix for jdk15.
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8239827 <https://bugs.openjdk.java.net/browse/JDK-8239827>
> Webrev : http://cr.openjdk.java.net/~trebari/swing/8239827/webrev00/ <http://cr.openjdk.java.net/~trebari/swing/8239827/webrev00/>
> 
> This test regularly left open Notepad window in the nightly testing.
> So it was added to problem list.
> 
> The test opens file by local path name and UNC path name in windows and 
> then try to close the file using alt + f4, which is not working.
> So changed the test to manual test and removed from problem list.
> 
> Tested on Windows Platform.
> 
> 
> Thanks and Regards
> Tejpal

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/awt-dev/attachments/20200522/8fc2c85b/attachment.htm>

From prasanta.sadhukhan at oracle.com  Fri May 22 10:40:00 2020
From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan)
Date: Fri, 22 May 2020 16:10:00 +0530
Subject: <AWT Dev> Fwd: <Swing Dev> RFR: 8239827: The test
 OpenByUNCPathNameTest.java should be changed to be manual
In-Reply-To: <A224AF61-6176-4DE5-B0F8-FB6B1FFFEBD8@oracle.com>
References: <B9E66C81-6971-4111-A6D1-EC5EC9BC1654@oracle.com>
 <A224AF61-6176-4DE5-B0F8-FB6B1FFFEBD8@oracle.com>
Message-ID: <3edae161-8cc0-71eb-3cd3-3f6e9c4fc0c5@oracle.com>

If Alt+F4 is not working, then why dont we try with Alt+F+X which does 
close the notepad app.

Regards
Prasanta
On 22-May-20 3:36 PM, Tejpal Rebari wrote:
>
>
>> Begin forwarded message:
>>
>> *From: *Tejpal Rebari <tejpal.rebari at oracle.com 
>> <mailto:tejpal.rebari at oracle.com>>
>> *Subject: **<Swing Dev> RFR: 8239827: The test 
>> OpenByUNCPathNameTest.java should be changed to be manual*
>> *Date: *22 May 2020 at 3:32:45 PM IST
>> *To: *swing-dev at openjdk.java.net <mailto:swing-dev at openjdk.java.net>
>>
>> Hi All,
>> Please review the following test only fix for jdk15.
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8239827
>> Webrev : http://cr.openjdk.java.net/~trebari/swing/8239827/webrev00/
>>
>> This test regularly left open Notepad window in the nightly testing.
>> So it was added to problem list.
>>
>> The test opens file by local path name and UNC path name in windows and
>> then try to close the file using alt + f4, which is not working.
>> So changed the test to manual test and removed from problem list.
>>
>> Tested on Windows Platform.
>>
>>
>> Thanks and Regards
>> Tejpal
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/awt-dev/attachments/20200522/5ce798ef/attachment.htm>

From tejpal.rebari at oracle.com  Fri May 22 11:50:18 2020
From: tejpal.rebari at oracle.com (Tejpal Rebari)
Date: Fri, 22 May 2020 17:20:18 +0530
Subject: <AWT Dev> Fwd: <Swing Dev> RFR: 8239827: The test
 OpenByUNCPathNameTest.java should be changed to be manual
In-Reply-To: <3edae161-8cc0-71eb-3cd3-3f6e9c4fc0c5@oracle.com>
References: <B9E66C81-6971-4111-A6D1-EC5EC9BC1654@oracle.com>
 <A224AF61-6176-4DE5-B0F8-FB6B1FFFEBD8@oracle.com>
 <3edae161-8cc0-71eb-3cd3-3f6e9c4fc0c5@oracle.com>
Message-ID: <DEF33741-68C9-4A13-8B06-119C14AD69D8@oracle.com>


Hi prasanta, 

> On 22-May-2020, at 4:10 PM, Prasanta Sadhukhan <prasanta.sadhukhan at oracle.com> wrote:
> 
> If Alt+F4 is not working, then why dont we try with Alt+F+X which does close the notepad app.
> 
I meant that  alt + f4 is woking fine in my local windows machine ,
 but it lefts the Notepad window open in nightly testing as reported in JBS.

I also tried running the original test in nightly testing and it was passing 
as commented in the JBS. 

There is one more problem, the test fails if the default share on disk c$ is disabled or different disk is used,
Which I think can be changed only manually.



> Regards
> Prasanta
> On 22-May-20 3:36 PM, Tejpal Rebari wrote:
>> 
>> 
>>> Begin forwarded message:
>>> 
>>> From: Tejpal Rebari <tejpal.rebari at oracle.com <mailto:tejpal.rebari at oracle.com>>
>>> Subject: <Swing Dev> RFR: 8239827: The test OpenByUNCPathNameTest.java should be changed to be manual
>>> Date: 22 May 2020 at 3:32:45 PM IST
>>> To: swing-dev at openjdk.java.net <mailto:swing-dev at openjdk.java.net>
>>> 
>>> Hi All,
>>> Please review the following test only fix for jdk15.
>>> 
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8239827 <https://bugs.openjdk.java.net/browse/JDK-8239827>
>>> Webrev : http://cr.openjdk.java.net/~trebari/swing/8239827/webrev00/ <http://cr.openjdk.java.net/~trebari/swing/8239827/webrev00/>
>>> 
>>> This test regularly left open Notepad window in the nightly testing.
>>> So it was added to problem list.
>>> 
>>> The test opens file by local path name and UNC path name in windows and 
>>> then try to close the file using alt + f4, which is not working.
>>> So changed the test to manual test and removed from problem list.
>>> 
>>> Tested on Windows Platform.
>>> 
>>> 
>>> Thanks and Regards
>>> Tejpal
>> 

Regards
Tejpal

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/awt-dev/attachments/20200522/2efc4cdf/attachment-0001.htm>

From prasanta.sadhukhan at oracle.com  Sat May 23 04:54:40 2020
From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan)
Date: Sat, 23 May 2020 10:24:40 +0530
Subject: <AWT Dev> Fwd: <Swing Dev> RFR: 8239827: The test
 OpenByUNCPathNameTest.java should be changed to be manual
In-Reply-To: <DEF33741-68C9-4A13-8B06-119C14AD69D8@oracle.com>
References: <B9E66C81-6971-4111-A6D1-EC5EC9BC1654@oracle.com>
 <A224AF61-6176-4DE5-B0F8-FB6B1FFFEBD8@oracle.com>
 <3edae161-8cc0-71eb-3cd3-3f6e9c4fc0c5@oracle.com>
 <DEF33741-68C9-4A13-8B06-119C14AD69D8@oracle.com>
Message-ID: <76edfbf2-d11c-5529-e4f2-cf52cd0f8fff@oracle.com>


On 22-May-20 5:20 PM, Tejpal Rebari wrote:
>
> Hi prasanta,
>
>> On 22-May-2020, at 4:10 PM, Prasanta Sadhukhan 
>> <prasanta.sadhukhan at oracle.com 
>> <mailto:prasanta.sadhukhan at oracle.com>> wrote:
>>
>> If Alt+F4 is not working, then why dont we try with Alt+F+X which 
>> does close the notepad app.
>>
> I meant that ?alt + f4 is woking fine in my local windows machine ,
> ?but it lefts the Notepad window open in nightly testing as reported 
> in JBS.
>
How did you know Notepad window is kept open in nightly testing. Did you 
enable failure-handler or use Robot.createScreenCapture to capture the 
screenshot after test?

If alt+f4 is working then it should close the notepad window also, no? 
Maybe there is some timing issue which is not allowing alt+f4 to close 
the notepad app in mach5?

Regards
Prasanta
> I also tried running the original test in nightly testing and it was 
> passing
> as commented in the JBS.
>
> There is one more problem, the test fails if the default share on disk 
> c$ is disabled or different disk is used,
> Which I think can be changed only manually.
>
>
>
>> Regards
>> Prasanta
>> On 22-May-20 3:36 PM, Tejpal Rebari wrote:
>>>
>>>
>>>> Begin forwarded message:
>>>>
>>>> *From: *Tejpal Rebari <tejpal.rebari at oracle.com 
>>>> <mailto:tejpal.rebari at oracle.com>>
>>>> *Subject: **<Swing Dev> RFR: 8239827: The test 
>>>> OpenByUNCPathNameTest.java should be changed to be manual*
>>>> *Date: *22 May 2020 at 3:32:45 PM IST
>>>> *To: *swing-dev at openjdk.java.net <mailto:swing-dev at openjdk.java.net>
>>>>
>>>> Hi All,
>>>> Please review the following test only fix for jdk15.
>>>>
>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8239827
>>>> Webrev : http://cr.openjdk.java.net/~trebari/swing/8239827/webrev00/
>>>>
>>>> This test regularly left open Notepad window in the nightly testing.
>>>> So it was added to problem list.
>>>>
>>>> The test opens file by local path name and UNC path name in windows 
>>>> and
>>>> then try to close the file using alt + f4, which is not working.
>>>> So changed the test to manual test and removed from problem list.
>>>>
>>>> Tested on Windows Platform.
>>>>
>>>>
>>>> Thanks and Regards
>>>> Tejpal
>>>
>
> Regards
> Tejpal
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/awt-dev/attachments/20200523/eeff7bc6/attachment.htm>

From Sergey.Bylokhov at oracle.com  Tue May 26 14:34:40 2020
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Tue, 26 May 2020 07:34:40 -0700
Subject: <AWT Dev> Fwd: <Swing Dev> RFR: 8239827: The test
 OpenByUNCPathNameTest.java should be changed to be manual
In-Reply-To: <76edfbf2-d11c-5529-e4f2-cf52cd0f8fff@oracle.com>
References: <B9E66C81-6971-4111-A6D1-EC5EC9BC1654@oracle.com>
 <A224AF61-6176-4DE5-B0F8-FB6B1FFFEBD8@oracle.com>
 <3edae161-8cc0-71eb-3cd3-3f6e9c4fc0c5@oracle.com>
 <DEF33741-68C9-4A13-8B06-119C14AD69D8@oracle.com>
 <76edfbf2-d11c-5529-e4f2-cf52cd0f8fff@oracle.com>
Message-ID: <34f0cdff-945e-8edd-b3a8-24d8c8f8288f@oracle.com>

On 5/22/20 9:54 pm, Prasanta Sadhukhan wrote:
> 
> On 22-May-20 5:20 PM, Tejpal Rebari wrote:
>>
>> Hi prasanta,
>>
>>> On 22-May-2020, at 4:10 PM, Prasanta Sadhukhan <prasanta.sadhukhan at oracle.com <mailto:prasanta.sadhukhan at oracle.com>> wrote:
>>>
>>> If Alt+F4 is not working, then why dont we try with Alt+F+X which does close the notepad app.
>>>
>> I meant that ?alt + f4 is woking fine in my local windows machine ,
>> ?but it lefts the Notepad window open in nightly testing as reported in JBS.
>>
> How did you know Notepad window is kept open in nightly testing. Did you enable failure-handler or use Robot.createScreenCapture to capture the screenshot after test?
> 
> If alt+f4 is working then it should close the notepad window also, no? Maybe there is some timing issue which is not allowing alt+f4 to close the notepad app in mach5?

I have checked this by eyes, when sitting in the lab, the problem is that the notepad window is not focused in rare situations.


-- 
Best regards, Sergey.

From prasanta.sadhukhan at oracle.com  Wed May 27 04:42:11 2020
From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan)
Date: Wed, 27 May 2020 10:12:11 +0530
Subject: <AWT Dev> Fwd: <Swing Dev> RFR: 8239827: The test
 OpenByUNCPathNameTest.java should be changed to be manual
In-Reply-To: <34f0cdff-945e-8edd-b3a8-24d8c8f8288f@oracle.com>
References: <B9E66C81-6971-4111-A6D1-EC5EC9BC1654@oracle.com>
 <A224AF61-6176-4DE5-B0F8-FB6B1FFFEBD8@oracle.com>
 <3edae161-8cc0-71eb-3cd3-3f6e9c4fc0c5@oracle.com>
 <DEF33741-68C9-4A13-8B06-119C14AD69D8@oracle.com>
 <76edfbf2-d11c-5529-e4f2-cf52cd0f8fff@oracle.com>
 <34f0cdff-945e-8edd-b3a8-24d8c8f8288f@oracle.com>
Message-ID: <15c636d2-8453-208e-56c0-e4191de39a57@oracle.com>

Thanks for the clarification. looks ok then.

Regards
Prasanta
On 26-May-20 8:04 PM, Sergey Bylokhov wrote:
> On 5/22/20 9:54 pm, Prasanta Sadhukhan wrote:
>>
>> On 22-May-20 5:20 PM, Tejpal Rebari wrote:
>>>
>>> Hi prasanta,
>>>
>>>> On 22-May-2020, at 4:10 PM, Prasanta Sadhukhan 
>>>> <prasanta.sadhukhan at oracle.com 
>>>> <mailto:prasanta.sadhukhan at oracle.com>> wrote:
>>>>
>>>> If Alt+F4 is not working, then why dont we try with Alt+F+X which 
>>>> does close the notepad app.
>>>>
>>> I meant that ?alt + f4 is woking fine in my local windows machine ,
>>> ?but it lefts the Notepad window open in nightly testing as reported 
>>> in JBS.
>>>
>> How did you know Notepad window is kept open in nightly testing. Did 
>> you enable failure-handler or use Robot.createScreenCapture to 
>> capture the screenshot after test?
>>
>> If alt+f4 is working then it should close the notepad window also, 
>> no? Maybe there is some timing issue which is not allowing alt+f4 to 
>> close the notepad app in mach5?
>
> I have checked this by eyes, when sitting in the lab, the problem is 
> that the notepad window is not focused in rare situations.
>
>

From alexander.zuev at oracle.com  Wed May 27 15:53:05 2020
From: alexander.zuev at oracle.com (Alexander Zuev)
Date: Wed, 27 May 2020 18:53:05 +0300
Subject: <AWT Dev> RFR: 8212226 SurfaceManager throws "Invalid Image
 variant" for MultiResolutionImage (Windows)
Message-ID: <e223450a-125c-00e0-4c8d-53ced3d5c66f@oracle.com>

Hello,

 ? please review my fix for the issue 8212226: SurfaceManager throws 
"Invalid Image variant" for MultiResolutionImage (Windows)

 ? Bug: https://bugs.openjdk.java.net/browse/JDK-8212226
 ? Fix: http://cr.openjdk.java.net/~kizune/8212226/webrev

 ? There is no regression test since even for the manual regression test 
the setup would be quite difficult - you will have to have not just the 
multi-monitor configuration, but the configuration where on different 
displays you have different magnification factor. I tried to simulate 
different magnification factor by changing sun.java2d.uiScale parameter 
but that does not trigger the problem, image gets repainted correctly 
and no exception happens.

/Alex

From Sergey.Bylokhov at oracle.com  Wed May 27 18:36:15 2020
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Wed, 27 May 2020 11:36:15 -0700
Subject: <AWT Dev> RFR: 8212226 SurfaceManager throws "Invalid Image
 variant" for MultiResolutionImage (Windows)
In-Reply-To: <e223450a-125c-00e0-4c8d-53ced3d5c66f@oracle.com>
References: <e223450a-125c-00e0-4c8d-53ced3d5c66f@oracle.com>
Message-ID: <d7524998-f113-3961-202b-69518561c124@oracle.com>

Hi, Alexander.

On 5/27/20 8:53 am, Alexander Zuev wrote:
>  ? There is no regression test since even for the manual regression test the setup would be quite difficult - you will have to have not just the multi-monitor configuration, but the configuration where on different displays you have different magnification factor. I tried to simulate different magnification factor by changing sun.java2d.uiScale parameter but that does not trigger the problem, image gets repainted correctly and no exception happens.

I remember that at some point it was attempted to implement that initially we draw the default image resolution(if the correct resolution variant is not ready yet.) Not sure that it actually works this way. If the current approach(when we try to draw the MRI itself) does not work, should not we try to use default resolution variant directly if the proper variant is not ready yet?

-- 
Best regards, Sergey.

From alexander.scherbatiy at bell-sw.com  Thu May 28 09:46:52 2020
From: alexander.scherbatiy at bell-sw.com (Alexander Scherbatiy)
Date: Thu, 28 May 2020 12:46:52 +0300
Subject: <AWT Dev> RFR: 8245938 Remove unused print_stack(void) method from
	XToolkit.c
Message-ID: <ccaeea9c-5537-107b-1b08-52b27ba2c349@bell-sw.com>

Hello,

Could you review a simple cleanup 8245938 Remove unused 
print_stack(void) method from XToolkit.c

 ? Bug: https://bugs.openjdk.java.net/browse/JDK-8245938
 ? Fix: http://cr.openjdk.java.net/~alexsch/8245938/webrev.00

The unused print_stack function is removed from XToolkit.c.
The reason for the request is that execinfo is specific to glibc and is 
not supported by musl libc.

Thanks,
Alexander.


From alexander.zuev at oracle.com  Thu May 28 20:18:35 2020
From: alexander.zuev at oracle.com (Alexander Zuev)
Date: Thu, 28 May 2020 23:18:35 +0300
Subject: <AWT Dev> RFR: 8237243 [macOS]
 java/awt/event/KeyEvent/DisabledTargetF10/DisabledTargetF10.html fails
Message-ID: <d741de93-37af-9b35-b651-47d8151edb12@oracle.com>

Hello,

 ? please review my fix for issue.

 ? Bug: https://bugs.openjdk.java.net/browse/JDK-8237243
 ? Fix: http://cr.openjdk.java.net/~kizune/8237243/webrev/

 ? Test has been moved from closed part, cleaned up and marked linux only.
The initial fix that this regression test is for is viable only for XAWT 
toolkit so there is absolutely
no reason to test for it on any other platform.

/Alex

From prasanta.sadhukhan at oracle.com  Fri May 29 04:07:37 2020
From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan)
Date: Fri, 29 May 2020 09:37:37 +0530
Subject: <AWT Dev> RFR: 8237243 [macOS]
 java/awt/event/KeyEvent/DisabledTargetF10/DisabledTargetF10.html fails
In-Reply-To: <d741de93-37af-9b35-b651-47d8151edb12@oracle.com>
References: <d741de93-37af-9b35-b651-47d8151edb12@oracle.com>
Message-ID: <5451c5b5-7095-4652-11f7-7114829b505b@oracle.com>

looks ok to me. But since this is test sprint, it will be good if you 
can submit a mach5 job using client-tier3.js running this test for 
several iterations and see if mach5 is not complaining and put the job 
link in JBS.

Regards
Prasanta
On 29-May-20 1:48 AM, Alexander Zuev wrote:
> Hello,
>
> ? please review my fix for issue.
>
> ? Bug: https://bugs.openjdk.java.net/browse/JDK-8237243
> ? Fix: http://cr.openjdk.java.net/~kizune/8237243/webrev/
>
> ? Test has been moved from closed part, cleaned up and marked linux only.
> The initial fix that this regression test is for is viable only for 
> XAWT toolkit so there is absolutely
> no reason to test for it on any other platform.
>
> /Alex

From alexander.zuev at oracle.com  Fri May 29 12:03:09 2020
From: alexander.zuev at oracle.com (Alexander Zuev)
Date: Fri, 29 May 2020 15:03:09 +0300
Subject: <AWT Dev> RFR: 8237243 [macOS]
 java/awt/event/KeyEvent/DisabledTargetF10/DisabledTargetF10.html fails
In-Reply-To: <5451c5b5-7095-4652-11f7-7114829b505b@oracle.com>
References: <d741de93-37af-9b35-b651-47d8151edb12@oracle.com>
 <5451c5b5-7095-4652-11f7-7114829b505b@oracle.com>
Message-ID: <9ecda67c-f746-f8f6-383f-89837c4e69e2@oracle.com>

Hi Prasanta,

I did a full Mach5 test run, the test is passing, link to job added to JBS.

/Alex

On 29-May-20 7:07, Prasanta Sadhukhan wrote:
> looks ok to me. But since this is test sprint, it will be good if you 
> can submit a mach5 job using client-tier3.js running this test for 
> several iterations and see if mach5 is not complaining and put the job 
> link in JBS.
>
> Regards
> Prasanta
> On 29-May-20 1:48 AM, Alexander Zuev wrote:
>> Hello,
>>
>> ? please review my fix for issue.
>>
>> ? Bug: https://bugs.openjdk.java.net/browse/JDK-8237243
>> ? Fix: http://cr.openjdk.java.net/~kizune/8237243/webrev/
>>
>> ? Test has been moved from closed part, cleaned up and marked linux 
>> only.
>> The initial fix that this regression test is for is viable only for 
>> XAWT toolkit so there is absolutely
>> no reason to test for it on any other platform.
>>
>> /Alex


From alexey.ivanov at oracle.com  Fri May 29 21:35:10 2020
From: alexey.ivanov at oracle.com (Alexey Ivanov)
Date: Fri, 29 May 2020 22:35:10 +0100
Subject: <AWT Dev> RFR: 8182043 Access to Windows Large Icons
In-Reply-To: <a6bf0dea-0bc5-4100-882a-e22fcf05ac93@oracle.com>
References: <6eb1f0f8-f347-0048-c531-1ef07ae3f2a9@oracle.com>
 <34c75ffd-08b4-5ee3-3308-2953e272f20a@oracle.com>
 <a4bfcca9-4990-d5ec-dfbc-18223faf6cc4@oracle.com>
 <daa61d11-6235-dc5d-e086-afb575e0bbc5@oracle.com>
 <780f8a0c-0d65-643d-e7c6-862f0569d927@oracle.com>
 <d351a939-528e-a04c-9c51-6336d3eba6ae@oracle.com>
 <afaa0f29-1f3a-3d57-91cb-c0ed35a10793@oracle.com>
 <a6bf0dea-0bc5-4100-882a-e22fcf05ac93@oracle.com>
Message-ID: <bbfdc534-3a3e-ee9e-47f6-5c28b7b1a378@oracle.com>

Hi Alexander, Sergey,

Sorry for my belated reply.

On 08/04/2020 21:32, Sergey Bylokhov wrote:
> On 4/6/20 10:21 am, Alexander Zuev wrote:
>> Hi Alexey,
>>
>> ?? i moved method from the new class to the FileSystemView and it 
>> works, however when
>> i tried to use it in the JFileManager on Windows i found that 
>> JFileChooser only uses large
>> icons in Places tab and with my code icons there are significantly 
>> worse even on 200%
>> magnification. They are sharper but the way we scaling them down just 
>> makes them a
>> pixelated garbage. You can look at the compare yourself:
>
> The old method "FileSystemView.getSystemIcon(File)" as well as 
> ShellFolder.getIcon(boolean) also
> uses MRI, and works fine. As far as I understand we should be able to 
> replace the usage of
> ShellFolder.getIcon(true) by the new method 
> FileSystemView.getSystemIcon(File, 32x32). Also we
> should be able to re-implement FileSystemView.getSystemIcon(File) by 
> the FileSystemView.getSystemIcon(File, 16x16).
> And this should not cause any visual regressions, otherwise, we have 
> some issues in the new method.

I agree.

The new API provides access to larger set of icon sizes rather 16?16 and 
32?32 only. But I'd expect the same image from new API that was provided 
via the old API.

>> http://cr.openjdk.java.net/~kizune/8182043/compare/
>>
>> Naming is obvious - *old* are the original rendering, *new* is the 
>> modified with multiresolution image,
>> number at the end - magnification percent. Yes, the old icons look 
>> pretty blurry, but are new ones look any better?
>> Unless we change the way we downscale images in icons any images with 
>> high details will turn into this i'm afraid.
>
> It is not necessary to downscale the image which we fetch from the 
> native, I guess the reason
> is that we request the size 256x256 from the native and then downscale?

This is exactly the reason.

JFileChooser requests the 32?32 icon, we get the 256?256 icon and 
downscale it to 32?32. The result of downscaling cannot be as crisp as 
manually tuned icon for 32?32.

Can't we always get the requested size from the native?
This will get the best possible image from the icon resource when the 
requested size is available in the icon. If not available, the native 
will scale the icon to the requested size.

>> So i'm proposing making the new method available for user to request 
>> image of arbitrary size but i don't think using it in
>> JFileChooser is a good idea. 

Your own test shows the quality of the icon is poor; the new API cannot 
replace existing one. Why would a user want it then? I propose to pass 
the requested size to extractIcon() unconditionally.

>> Unless, of course, we create the true multi-resolution image with all 
>> the resolution variants
>> rendered by the system - but that is impossible at the moment (as 
>> Eiric pointed out before) due to the JDK-8212226
>> not fixed yet - we will have errors on resolution switch or on moving 
>> of the window between screens with different
>> magnification factors.
>
> Then how the old getSystemIcon(File) and ShellFolder.getIcon(boolean) 
> work?

I don't quite understand the mechanism but the icons returned change 
with DPI. This means in HiDPI environment, we get the correctly sized 
icon to the current DPI.


The ultimate goal of this API could be to provide an MRI which stores 
all the available icon sizes and loads dynamically the size that's most 
appropriate to the current display settings. Raymond Chen has a blog 
post about the format of the icon resources [1]. If we do that, we will 
handle all the scaling ourselves and will be able to define our own 
algorithm for choosing the closest match. As explained in 
LookupIconIdFromDirectoryEx [2], LoadIcon and LoadImage ?use this 
function to search the specified resource data for the icon? that best 
fits the current display device.?

>>
>> /Alex
>>
>> <SNIP>

[1] https://devblogs.microsoft.com/oldnewthing/20120720-00/?p=7083
[2] 
https://docs.microsoft.com/en-ie/windows/win32/api/winuser/nf-winuser-lookupiconidfromdirectoryex

-- 
Regards,
Alexey

From pankaj.b.bansal at oracle.com  Sun May 31 18:47:16 2020
From: pankaj.b.bansal at oracle.com (Pankaj Bansal)
Date: Mon, 1 Jun 2020 00:17:16 +0530
Subject: <AWT Dev> RFR: 8198626:
 java/awt/KeyboardFocusmanager/TypeAhead/TestDialogTypeAhead.html fails on
 mac
Message-ID: <0b40d414-6a8f-2018-bc49-d47bdb36ce72@oracle.com>

Hi All,

Please review the following test only fix for jdk15.

Bug : https://bugs.openjdk.java.net/browse/JDK-8198626
webrev: http://cr.openjdk.java.net/~pbansal/8198626/webrev00/ 
<http://cr.openjdk.java.net/%7Epbansal/8198626/webrev00/>

This test was added to the ProblemList as it was failing continuously??? .
I have made some changes to properly dispose the frame to stabilize the 
test. I have run multiple iterations of the test on mach5 and it is 
always passing. Links in JBS.

Regards
Pankaj

From philip.race at oracle.com  Sun May 31 22:44:11 2020
From: philip.race at oracle.com (Philip Race)
Date: Sun, 31 May 2020 15:44:11 -0700
Subject: <AWT Dev> RFR: 8198626:
 java/awt/KeyboardFocusmanager/TypeAhead/TestDialogTypeAhead.html fails on
 mac
In-Reply-To: <0b40d414-6a8f-2018-bc49-d47bdb36ce72@oracle.com>
References: <0b40d414-6a8f-2018-bc49-d47bdb36ce72@oracle.com>
Message-ID: <5ED4333B.20801@oracle.com>

Hi,

I don't see how sometimes not disposing the frame would have caused the 
failure cited in the bug report.

 > Execution failed: Applet thread threw exception: 
java.lang.RuntimeException: robotSema hasn't been triggered

Shouldn't we be doing something about that too ?

-phil

On 5/31/20, 11:47 AM, Pankaj Bansal wrote:
> Hi All,
>
> Please review the following test only fix for jdk15.
>
> Bug : https://bugs.openjdk.java.net/browse/JDK-8198626
> webrev: http://cr.openjdk.java.net/~pbansal/8198626/webrev00/ 
> <http://cr.openjdk.java.net/%7Epbansal/8198626/webrev00/>
>
> This test was added to the ProblemList as it was failing 
> continuously    .
> I have made some changes to properly dispose the frame to stabilize 
> the test. I have run multiple iterations of the test on mach5 and it 
> is always passing. Links in JBS.
>
> Regards
> Pankaj
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/awt-dev/attachments/20200531/c25c6aaf/attachment.htm>

From lance.andersen at oracle.com  Sun May 17 13:31:14 2020
From: lance.andersen at oracle.com (Lance Andersen)
Date: Sun, 17 May 2020 13:31:14 -0000
Subject: <AWT Dev> RFR: JDK-8243454 - Redundant code for executable jar
 file manifests except SplashScreen-Image
In-Reply-To: <01fb33ccad1252e45d103503062075f8f33a6387.camel@paratix.ch>
References: <866cb01ce33c1468f78b43ac51cbeb7b28d38125.camel@paratix.ch>
 <01fb33ccad1252e45d103503062075f8f33a6387.camel@paratix.ch>
Message-ID: <E9B1778A-2960-452A-BB40-BB58CC78FE28@oracle.com>

Hi Philipp,

I have not looked at this in detail yet, but the changes you are proposing would require a CSR and probably an update to the JAR specification

I am not  sure of the history as to why this was done, perhaps others might know.  I think this would be good to know as part of considering this change/

Best,
Lance

> On May 17, 2020, at 5:53 AM, Philipp Kunz <philipp.kunz at paratix.ch> wrote:
> 
> Hi,
> Essentially the same patch as last time [1] but this time with a bug
> number [2].The patch does not include the updated UnicodeTest.jar which
> I created with
> ../jtreg-5.0-b01/bin/jtreg -va -nr -jdk:build/linux-x86_64-server-
> release/images/jdk/ -Xshare:off
> test/jdk/tools/launcher/UnicodeTest.javacp
> JTwork/scratch/UnicodeTest.jar test/jdk/tools/launcher/
> Regards,Philipp
> [1] 
> https://mail.openjdk.java.net/pipermail/core-libs-dev/2020-January/064190.html[2
> ] https://bugs.openjdk.java.net/browse/JDK-8243454
> 
> On Sat, 2020-01-04 at 11:00 +0100, Philipp Kunz wrote:
>> Hi,
>> When I tried to improve Unicode support in JAR manifests in [1],
>> independent of what will happen with that, I found that there are not
>> only Manifest and Attributes classes parsing manifests but also some
>> c code which parses "SplashScreen-Image" attribute and also used to
>> parse some other attributes such as "Main-Class" and others.
>> There already are tests for splash screen images but those existing
>> ones work with the "-splash" command line option and not with the
>> "SplashScreen-Image" manifest attribute. I found "SplashScreen-Image" 
>> manifest attribute not yet covered with a test and extended the
>> existing UnicodeTest accordingly, see attached patch which confirmed
>> that the "SplashScreen-Image" manifest attribute already fully
>> supports Unicode.
>> Support for "JRE-Version" manifest attribute and "-jre-restrict-
>> search" and "-jre-no-restrict-search" command line attributes has
>> already been removed earlier already and the relevant lines of code
>> determining the main class from the manifest when launching have
>> already been moved to or near LauncherHelper::getMainClassFromJar in
>> earlier versions, apparently leaving them with no use any longer in
>> java.c, java.h, manifest_info.h, and parse_manifest.c, I figure.
>> Hence, I propose to remove those parts as in the attached patch.
>> This leaves manifest_info.h and parse_manifest.c with "SplashScreen-
>> Image" as the only attribute parsed there. Certainly it would be a
>> different change but anyway it might be worth a consideration to move
>> the code opening the splash screen image to LauncherHelper or a
>> similar appropriate place in Java which would allow to remove quite a
>> number of some lines of c code, provided it could be acceptable to
>> show the splash screen image slightly later.
>> There is no existing related bug and I didn't find a new one. It
>> would be nice to have "SplashScreen-Image" manifest attribute covered
>> with a test and there is some potential for cleaning up unused code
>> which certainly is not urgent at all and I would not know how
>> desirable this really is. Also I'm not sure whether it's better or
>> not to add SPLASHSCREEN_IMAGE to Attributes.Name.KNOWN_NAMES.
>> Any opinion about to how to proceed with this, if at all or would
>> someone sponsor this patch?
>> Regards,Philipp
>> 
>> [1] 
>> https://mail.openjdk.java.net/pipermail/core-libs-dev/2019-December/064149.html
>> 
> <20200517-splashscreenimageunicodetestwithoutunicodetestjar.patch>

 <http://oracle.com/us/design/oracle-email-sig-198324.gif>
 <http://oracle.com/us/design/oracle-email-sig-198324.gif> <http://oracle.com/us/design/oracle-email-sig-198324.gif>
 <http://oracle.com/us/design/oracle-email-sig-198324.gif>Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
Oracle Java Engineering 
1 Network Drive 
Burlington, MA 01803
Lance.Andersen at oracle.com <mailto:Lance.Andersen at oracle.com>



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/awt-dev/attachments/20200517/f395cab4/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: oracle_sig_logo.gif
Type: image/gif
Size: 658 bytes
Desc: not available
URL: <https://mail.openjdk.java.net/pipermail/awt-dev/attachments/20200517/f395cab4/oracle_sig_logo-0001.gif>