From Sergey.Bylokhov at oracle.com  Fri Aug  1 10:25:17 2014
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Fri, 01 Aug 2014 14:25:17 +0400
Subject: <AWT Dev> [9] Review Request: 8026497 Font2DTest demo: unused
	resource files
Message-ID: <53DB6B0D.9010004@oracle.com>

Hello.
Please review a small fix for jdk9. Unused property files were removed.

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

-- 
Best regards, Sergey.


From alexander.zvegintsev at oracle.com  Fri Aug  1 11:19:17 2014
From: alexander.zvegintsev at oracle.com (Alexander Zvegintsev)
Date: Fri, 01 Aug 2014 15:19:17 +0400
Subject: <AWT Dev> [9] Review Request: 8026497 Font2DTest demo: unused
 resource files
In-Reply-To: <53DB6B0D.9010004@oracle.com>
References: <53DB6B0D.9010004@oracle.com>
Message-ID: <53DB77B5.4000409@oracle.com>

Hi Sergey,

the fix looks good to me.

--
Thanks,
Alexander.

On 08/01/2014 02:25 PM, Sergey Bylokhov wrote:
> Hello.
> Please review a small fix for jdk9. Unused property files were removed.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8026497
> Webrev can be found at: 
> http://cr.openjdk.java.net/~serb/8026497/webrev.00
>


From andrew.brygin at oracle.com  Fri Aug  1 11:31:26 2014
From: andrew.brygin at oracle.com (Andrew Brygin)
Date: Fri, 01 Aug 2014 15:31:26 +0400
Subject: <AWT Dev> [OpenJDK 2D-Dev] [9] Review Request: 8026497
 Font2DTest demo: unused resource files
In-Reply-To: <53DB6B0D.9010004@oracle.com>
References: <53DB6B0D.9010004@oracle.com>
Message-ID: <53DB7A8E.9080504@oracle.com>

Hello Sergey,

  the change looks fine to me.

Thanks,
Andrew

On 8/1/2014 2:25 PM, Sergey Bylokhov wrote:
> Hello.
> Please review a small fix for jdk9. Unused property files were removed.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8026497
> Webrev can be found at: 
> http://cr.openjdk.java.net/~serb/8026497/webrev.00
>


From yuri.nesterenko at oracle.com  Tue Aug  5 08:41:07 2014
From: yuri.nesterenko at oracle.com (Yuri Nesterenko)
Date: Tue, 05 Aug 2014 12:41:07 +0400
Subject: <AWT Dev> [9] Review request for 8053657: [TEST_BUG] move some
 5 tests related to undecorated Frame/JFrame to JDK
In-Reply-To: <53D89696.5070602@oracle.com>
References: <53D89696.5070602@oracle.com>
Message-ID: <53E098A3.1020108@oracle.com>

A friendly reminder!

Thanks,
-yan

On 07/30/2014 10:54 AM, Yuri Nesterenko wrote:
> Hi team,
>
> please review yet another test update in jdk9:
>
> http://cr.openjdk.java.net/~yan/8053657/webrev.00
>
> ( https://bugs.openjdk.java.net/browse/JDK-8053657 )
>
> These are 5 tests made out of some 8 old functional ones
> dealing with undecorated Frames (and JFrames).
>
> NB: piggybacking here a removal of
> java/awt/Mixing/AWT_Mixing/Util.java.
> It was approved long ago but I forgot to delete it in
> time.
>
> Tests proven on 4 platforms in continuous runs.
>
> Thanks,
> -yan


From alexander.v.stepanov at oracle.com  Tue Aug  5 09:27:39 2014
From: alexander.v.stepanov at oracle.com (alexander stepanov)
Date: Tue, 05 Aug 2014 13:27:39 +0400
Subject: <AWT Dev> [9] Review request for 8052012: move awt automated tests
 from AWT_Modality to OpenJDK repository - part 5
Message-ID: <53E0A38B.90601@oracle.com>

Hello,

Could you please review the fix for
https://bugs.openjdk.java.net/browse/JDK-8052012

webrev:
http://cr.openjdk.java.net/~avstepan/8052012

This is the next portion of functional AWT tests prepared for migration 
to OpenJDK repository.

The tests were checked on Ubuntu 14.04 Linux, Solaris 11, Mac OS X 
10.8.5 and Windows 7.

Thanks,
Alexander

From Sergey.Bylokhov at oracle.com  Tue Aug  5 10:37:03 2014
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Tue, 05 Aug 2014 14:37:03 +0400
Subject: <AWT Dev> [9] Review request for 8052012: move awt automated
 tests from AWT_Modality to OpenJDK repository - part 5
In-Reply-To: <53E0A38B.90601@oracle.com>
References: <53E0A38B.90601@oracle.com>
Message-ID: <53E0B3CF.2000705@oracle.com>

The fix looks good to me.

On 05.08.2014 13:27, alexander stepanov wrote:
> Hello,
>
> Could you please review the fix for
> https://bugs.openjdk.java.net/browse/JDK-8052012
>
> webrev:
> http://cr.openjdk.java.net/~avstepan/8052012
>
> This is the next portion of functional AWT tests prepared for 
> migration to OpenJDK repository.
>
> The tests were checked on Ubuntu 14.04 Linux, Solaris 11, Mac OS X 
> 10.8.5 and Windows 7.
>
> Thanks,
> Alexander


-- 
Best regards, Sergey.


From Sergey.Bylokhov at oracle.com  Tue Aug  5 10:48:20 2014
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Tue, 05 Aug 2014 14:48:20 +0400
Subject: <AWT Dev> [9] Review Request: 8029253 [macosx] Performance
 problems with Retina display on Mac OS X
In-Reply-To: <53985D1B.8070807@oracle.com>
References: <5398531E.2050207@oracle.com> <53985B12.8010403@oracle.com>
	<53985D1B.8070807@oracle.com>
Message-ID: <53E0B674.6030701@oracle.com>

Hello,
Can somebody review the fix?

On 11.06.2014 17:43, Sergey Bylokhov wrote:
> On 11.06.2014 17:35, Andrew Brygin wrote:
>> Hi Sergey,
>>
>>  could you please clarify why you have eliminated OGLC_VENDOR_SUN?
> We have only two bits to store the vendor information, since SUN is 
> not used I replace it by INTEL.
>>
>> Thanks,
>> Andrew
>>
>> On 6/11/2014 5:01 PM, Sergey Bylokhov wrote:
>>> Hello.
>>> Please review the fix for jdk 9, which is also targeted for jdk 8u20.
>>> Description:
>>> We have two codepaths to draw a raster to the opengl:
>>>  - via glDrawPixels
>>>  - via intermediate texture.
>>> We empirically checked, what way is better, based on benchmarks. 
>>> Became obvious that on intel devices the glDrawPixels is slower than 
>>> intermediate texture, and this is a bottleneck when the scrolling is 
>>> used.
>>>
>>> j2bench is not properly cover retina case, but according to some of 
>>> my tests results is 2-3 times better.
>>>
>>> There is no regressions on windows:
>>> Summary:
>>>   ogl-base:
>>>     Number of tests:  60
>>>     Overall average:  1452524.357368045
>>>     Best spread:      0.17% variance
>>>     Worst spread:     248.44% variance
>>>     (Basis for results comparison)
>>>
>>>   ogl-fix:
>>>     Number of tests:  60
>>>     Overall average:  1469528.5484618822
>>>     Best spread:      0.12% variance
>>>     Worst spread:     246.59% variance
>>>     Comparison to basis:
>>>       Best result:      161.48% of basis
>>>       Worst result:     93.54% of basis
>>>       Number of wins:   38
>>>       Number of ties:   17
>>>       Number of losses: 5
>>>
>>> http://cr.openjdk.java.net/~serb/8029253/perf/windows.txt
>>>
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8029253
>>> Webrev can be found at: 
>>> http://cr.openjdk.java.net/~serb/8029253/webrev.00
>>>
>>
>
>


-- 
Best regards, Sergey.


From alexander.v.stepanov at oracle.com  Tue Aug  5 11:34:52 2014
From: alexander.v.stepanov at oracle.com (alexander stepanov)
Date: Tue, 05 Aug 2014 15:34:52 +0400
Subject: <AWT Dev> [9] Review request for 8052012: move awt automated
 tests from AWT_Modality to OpenJDK repository - part 5
In-Reply-To: <53E0B3CF.2000705@oracle.com>
References: <53E0A38B.90601@oracle.com> <53E0B3CF.2000705@oracle.com>
Message-ID: <53E0C15C.3090500@oracle.com>

Thanks!

On 05.08.2014 14:37, Sergey Bylokhov wrote:
> The fix looks good to me.
>
> On 05.08.2014 13:27, alexander stepanov wrote:
>> Hello,
>>
>> Could you please review the fix for
>> https://bugs.openjdk.java.net/browse/JDK-8052012
>>
>> webrev:
>> http://cr.openjdk.java.net/~avstepan/8052012
>>
>> This is the next portion of functional AWT tests prepared for 
>> migration to OpenJDK repository.
>>
>> The tests were checked on Ubuntu 14.04 Linux, Solaris 11, Mac OS X 
>> 10.8.5 and Windows 7.
>>
>> Thanks,
>> Alexander
>
>


From anthony.petrov at oracle.com  Tue Aug  5 13:08:52 2014
From: anthony.petrov at oracle.com (Anthony Petrov)
Date: Tue, 05 Aug 2014 17:08:52 +0400
Subject: <AWT Dev> [9/8u40] Review request for RT-37149 and JDK-8049065
 : Implement DnD for SwingNode
In-Reply-To: <53C932B9.1010409@oracle.com>
References: <53C932B9.1010409@oracle.com>
Message-ID: <53E0D764.9090507@oracle.com>

Anton, Artem, Steve,

Could you please review this fix?

--
best regards,
Anthony

On 7/18/2014 6:44 PM, Anthony Petrov wrote:
> Hi Petr, Anton, Artem, Steve,
>
> Please review the fix at https://javafx-jira.kenai.com/browse/RT-37149
>
> Webrevs:
>
> JDK: http://cr.openjdk.java.net/~anthony/9-5.2/
>
> FX: http://cr.openjdk.java.net/~anthony/g-522-swingNodeDnD-RT-37149.3/
>
>
> JavaFX implements the DragSourceContextPeer and DragGestureRecognizer so
> that SwingNode content could pose as a drag source. In order to support
> a drop target, the DropTargetContextPeer is implemented in SwingNode and
> the add/removeDropTarget() methods register/unregister the drop target
> listeners.
>
> The changes in JDK are mostly technical. We simply delegate the
> Toolkit.createDragSourceContextPeer() and
> Toolkit.createDragGestureRecognizer() factory methods to SwingNode.
> Similarly, we delegate the DropTargetPeer.add/removeDropTarget()
> operations to SwingNode as well.
>
> In FX I've factored out the CachingTransferable class from the
> SwingDragSource class so as to share the implementation with the
> SwingNode DnD support. Also I've added a few utility methods to
> DataFlavorUtils and SwingFXUtils. The main fix is the new code in
> FXDnD.java which actually implements the AWT interfaces, installs
> appropriate event handlers on the SwingNode node in FX, and handles all
> the DnD events.
>
> Note that the JDK <-> FX interface is loose because I use default
> methods in the LightweightContent interface, so that you can run new FX
> with the old JDK, or old FX with the new JDK, and nothing should break.
> Obviously, the DnD in SwingNode will only work if both JDK and FX are
> patched.
>
> I've tested these changes on Windows and Mac with the sample code from
> this JIRA as well as a JFXPanel DnD test application from RT-34283. The
> DnD works fine for me in both intra- and inter-process modes.
>
> Please post your review comments in JIRA.
>
> --
> best regards,
> Anthony

From dmitriy.ermashov at oracle.com  Wed Aug  6 12:06:22 2014
From: dmitriy.ermashov at oracle.com (Dmitriy Ermashov)
Date: Wed, 06 Aug 2014 16:06:22 +0400
Subject: <AWT Dev> Review Request for 8051716: Move AWT_BAT functional
 tests to OpenJDK (1 of 3)
In-Reply-To: <53DA48F4.1070405@oracle.com>
References: <53D64038.5040307@oracle.com> <53DA48F4.1070405@oracle.com>
Message-ID: <53E21A3E.7070403@oracle.com>

Hi,

Just a kindly reminder.

Thanks,
Dima

On 31.07.2014 17:47, Dmitriy Ermashov wrote:
> Hi,
>
> Please review the updated version of tests:
> http://cr.openjdk.java.net/~dermashov/8051716/webrev.01/
>
> Last changes:
> 1. All GUI creation/modification moved to EDT
>
> Thanks,
> Dima
>
> On 28.07.2014 16:21, Dmitriy Ermashov wrote:
>> Hi AWT team,
>>
>> Please review one more batch of functional tests:
>> http://cr.openjdk.java.net/~dermashov/8051716/webrev.00/
>>
>> Corresponding bug:
>> https://bugs.openjdk.java.net/browse/JDK-8051716
>>
>> The tests were taken from reliability test framework. So, as one can 
>> see, several tests
>> do not actual verify anything, but just produce some actions (e.g. 
>> TestFrame.java) and
>> make sure no dead lock occurs.
>> On the other hand, there are three tests TaskX* that should be run on 
>> well configured
>> node, where gcc compiler and other developers libraries should be 
>> installed.
>>
>> Test were verified on following platforms:
>> Windows 7 x64
>> Ubuntu 14.04 x64
>> Ubuntu 10.04 arm
>> Solaris 11 x64 (intel)
>> OS X 10.10 beta
>>
>


From Sergey.Bylokhov at oracle.com  Wed Aug  6 12:48:25 2014
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Wed, 06 Aug 2014 16:48:25 +0400
Subject: <AWT Dev> [9] Review request for 8053657: [TEST_BUG] move some
 5 tests related to undecorated Frame/JFrame to JDK
In-Reply-To: <53E098A3.1020108@oracle.com>
References: <53D89696.5070602@oracle.com> <53E098A3.1020108@oracle.com>
Message-ID: <53E22419.6090309@oracle.com>

Hi, Yuri.
In some of these tests focusGained variable is not used or its 
validation is missed. In UndecoratedInitiallyIconified you can simplify 
the code and uses a throws in main instead of try/catch.

On 05.08.2014 12:41, Yuri Nesterenko wrote:
> A friendly reminder!
>
> Thanks,
> -yan
>
> On 07/30/2014 10:54 AM, Yuri Nesterenko wrote:
>> Hi team,
>>
>> please review yet another test update in jdk9:
>>
>> http://cr.openjdk.java.net/~yan/8053657/webrev.00
>>
>> ( https://bugs.openjdk.java.net/browse/JDK-8053657 )
>>
>> These are 5 tests made out of some 8 old functional ones
>> dealing with undecorated Frames (and JFrames).
>>
>> NB: piggybacking here a removal of
>> java/awt/Mixing/AWT_Mixing/Util.java.
>> It was approved long ago but I forgot to delete it in
>> time.
>>
>> Tests proven on 4 platforms in continuous runs.
>>
>> Thanks,
>> -yan
>


-- 
Best regards, Sergey.


From yuri.nesterenko at oracle.com  Wed Aug  6 13:09:55 2014
From: yuri.nesterenko at oracle.com (Yuri Nesterenko)
Date: Wed, 06 Aug 2014 17:09:55 +0400
Subject: <AWT Dev> [9] Review request for 8053657: [TEST_BUG] move some
 5 tests related to undecorated Frame/JFrame to JDK
In-Reply-To: <53E22419.6090309@oracle.com>
References: <53D89696.5070602@oracle.com> <53E098A3.1020108@oracle.com>
	<53E22419.6090309@oracle.com>
Message-ID: <53E22923.80603@oracle.com>

Oh! You are right, thank you.
Second version is

http://cr.openjdk.java.net/~yan/8053657/webrev.01/

-yan

On 08/06/2014 04:48 PM, Sergey Bylokhov wrote:
> Hi, Yuri.
> In some of these tests focusGained variable is not used or its
> validation is missed. In UndecoratedInitiallyIconified you can simplify
> the code and uses a throws in main instead of try/catch.
>
> On 05.08.2014 12:41, Yuri Nesterenko wrote:
>> A friendly reminder!
>>
>> Thanks,
>> -yan
>>
>> On 07/30/2014 10:54 AM, Yuri Nesterenko wrote:
>>> Hi team,
>>>
>>> please review yet another test update in jdk9:
>>>
>>> http://cr.openjdk.java.net/~yan/8053657/webrev.00
>>>
>>> ( https://bugs.openjdk.java.net/browse/JDK-8053657 )
>>>
>>> These are 5 tests made out of some 8 old functional ones
>>> dealing with undecorated Frames (and JFrames).
>>>
>>> NB: piggybacking here a removal of
>>> java/awt/Mixing/AWT_Mixing/Util.java.
>>> It was approved long ago but I forgot to delete it in
>>> time.
>>>
>>> Tests proven on 4 platforms in continuous runs.
>>>
>>> Thanks,
>>> -yan
>>
>
>


From anthony.petrov at oracle.com  Wed Aug  6 17:12:47 2014
From: anthony.petrov at oracle.com (Anthony Petrov)
Date: Wed, 06 Aug 2014 21:12:47 +0400
Subject: <AWT Dev> [9/8u40] Review request for RT-37149 and JDK-8049065
 : Implement DnD for SwingNode
In-Reply-To: <53E0D764.9090507@oracle.com>
References: <53C932B9.1010409@oracle.com> <53E0D764.9090507@oracle.com>
Message-ID: <53E2620F.1070209@oracle.com>

Anton: thank you for reviewing the fix.

All: I need at least one more reviewer for the JDK part of the fix 
because we're going to back-port the change to 8u40. Could anyone please 
review it? Artem, Sergey, anyone?

For your convenience: https://javafx-jira.kenai.com/browse/RT-37149

http://cr.openjdk.java.net/~anthony/9-5.2/
https://bugs.openjdk.java.net/browse/JDK-8049065

--
best regards,
Anthony

On 8/5/2014 5:08 PM, Anthony Petrov wrote:
> Anton, Artem, Steve,
>
> Could you please review this fix?
>
> --
> best regards,
> Anthony
>
> On 7/18/2014 6:44 PM, Anthony Petrov wrote:
>> Hi Petr, Anton, Artem, Steve,
>>
>> Please review the fix at https://javafx-jira.kenai.com/browse/RT-37149
>>
>> Webrevs:
>>
>> JDK: http://cr.openjdk.java.net/~anthony/9-5.2/
>>
>> FX: http://cr.openjdk.java.net/~anthony/g-522-swingNodeDnD-RT-37149.3/
>>
>>
>> JavaFX implements the DragSourceContextPeer and DragGestureRecognizer so
>> that SwingNode content could pose as a drag source. In order to support
>> a drop target, the DropTargetContextPeer is implemented in SwingNode and
>> the add/removeDropTarget() methods register/unregister the drop target
>> listeners.
>>
>> The changes in JDK are mostly technical. We simply delegate the
>> Toolkit.createDragSourceContextPeer() and
>> Toolkit.createDragGestureRecognizer() factory methods to SwingNode.
>> Similarly, we delegate the DropTargetPeer.add/removeDropTarget()
>> operations to SwingNode as well.
>>
>> In FX I've factored out the CachingTransferable class from the
>> SwingDragSource class so as to share the implementation with the
>> SwingNode DnD support. Also I've added a few utility methods to
>> DataFlavorUtils and SwingFXUtils. The main fix is the new code in
>> FXDnD.java which actually implements the AWT interfaces, installs
>> appropriate event handlers on the SwingNode node in FX, and handles all
>> the DnD events.
>>
>> Note that the JDK <-> FX interface is loose because I use default
>> methods in the LightweightContent interface, so that you can run new FX
>> with the old JDK, or old FX with the new JDK, and nothing should break.
>> Obviously, the DnD in SwingNode will only work if both JDK and FX are
>> patched.
>>
>> I've tested these changes on Windows and Mac with the sample code from
>> this JIRA as well as a JFXPanel DnD test application from RT-34283. The
>> DnD works fine for me in both intra- and inter-process modes.
>>
>> Please post your review comments in JIRA.
>>
>> --
>> best regards,
>> Anthony

From Sergey.Bylokhov at oracle.com  Thu Aug  7 10:51:10 2014
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Thu, 07 Aug 2014 14:51:10 +0400
Subject: <AWT Dev> [9] Review request for 8051359 JPopupMenu creation in
 headless mode with JDK9b23 causes NPE
In-Reply-To: <04ABA9FE-E79B-439A-9E64-A10AA2E879D8@oracle.com>
References: <53CCDE6B.6020307@oracle.com>
	<A012739E-9161-403C-A628-0F9B30E90FC5@oracle.com>
	<53CE4444.9090102@oracle.com>
	<04ABA9FE-E79B-439A-9E64-A10AA2E879D8@oracle.com>
Message-ID: <53E35A1E.3010804@oracle.com>

Hi, Alexander.
The fix looks good.

On 22.07.2014 15:06, Petr Pchelko wrote:
> Hello, Alexander.
>
> The fix looks good to me.
>
> With best regards. Petr.
>
> On 22 ???? 2014 ?., at 15:00, Alexander Scherbatiy <alexandr.scherbatiy at oracle.com> wrote:
>
>>   Hello,
>>
>>   Could you review the updated fix:
>>     http://cr.openjdk.java.net/~alexsch/8051359/webrev.01/
>>
>> - isHeadless() check is removed from the targetToAppContext and insertTargetMapping methods.
>>
>>   Regression java/awt/Headless and javax/swing/Headless tests pass with this fix.
>>   Only some tests from JCK api/java_awt and api/javax_swing fail in headless mode and they have different cause than app context NPE.
>>
>>   Thanks,
>>   Alexandr.
>>
>>
>> On 7/21/2014 2:01 PM, Petr Pchelko wrote:
>>> Hello, Alexander.
>>>
>>> Isn't it better to use a different approach and just remove the headless check in targetToAppContext method?
>>> I think this check is incorrect, because it's perfectly valid to have multiple AppContexts in headless mode.
>>>
>>> With best regards. Petr
>>>
>>> On 21 ???? 2014 ?., at 13:33, Alexander Scherbatiy <alexandr.scherbatiy at oracle.com> wrote:
>>>
>>>> Hello,
>>>>
>>>> Could you review the fix:
>>>>   bug: https://bugs.openjdk.java.net/browse/JDK-8051359
>>>>   webrev: http://cr.openjdk.java.net/~alexsch/8051359/webrev.00
>>>>
>>>>   The fix avoids NPE throwing in headless mode.
>>>>
>>>>   There are already regression tests that covers the issue in jdk/test/javax/swing/Headless folder.
>>>>
>>>>
>>>> Thanks,
>>>> Alexandr.
>>>>


-- 
Best regards, Sergey.


From petr.pchelko at oracle.com  Mon Aug 11 14:27:56 2014
From: petr.pchelko at oracle.com (Petr Pchelko)
Date: Mon, 11 Aug 2014 18:27:56 +0400
Subject: <AWT Dev> [9/8u40] Review request for RT-37149 and JDK-8049065
	: Implement DnD for SwingNode
In-Reply-To: <53E2620F.1070209@oracle.com>
References: <53C932B9.1010409@oracle.com> <53E0D764.9090507@oracle.com>
	<53E2620F.1070209@oracle.com>
Message-ID: <0AF263C0-EBC2-4005-A7F2-95130DD6C116@oracle.com>

Hello, Anthony.

The AWT part looks good to me. 

With best regards. Petr.

> On Aug 6, 2014, at 9:12 PM, Anthony Petrov <anthony.petrov at oracle.com> wrote:
> 
> Anton: thank you for reviewing the fix.
> 
> All: I need at least one more reviewer for the JDK part of the fix because we're going to back-port the change to 8u40. Could anyone please review it? Artem, Sergey, anyone?
> 
> For your convenience: https://javafx-jira.kenai.com/browse/RT-37149
> 
> http://cr.openjdk.java.net/~anthony/9-5.2/
> https://bugs.openjdk.java.net/browse/JDK-8049065
> 
> --
> best regards,
> Anthony
> 
> On 8/5/2014 5:08 PM, Anthony Petrov wrote:
>> Anton, Artem, Steve,
>> 
>> Could you please review this fix?
>> 
>> --
>> best regards,
>> Anthony
>> 
>> On 7/18/2014 6:44 PM, Anthony Petrov wrote:
>>> Hi Petr, Anton, Artem, Steve,
>>> 
>>> Please review the fix at https://javafx-jira.kenai.com/browse/RT-37149
>>> 
>>> Webrevs:
>>> 
>>> JDK: http://cr.openjdk.java.net/~anthony/9-5.2/
>>> 
>>> FX: http://cr.openjdk.java.net/~anthony/g-522-swingNodeDnD-RT-37149.3/
>>> 
>>> 
>>> JavaFX implements the DragSourceContextPeer and DragGestureRecognizer so
>>> that SwingNode content could pose as a drag source. In order to support
>>> a drop target, the DropTargetContextPeer is implemented in SwingNode and
>>> the add/removeDropTarget() methods register/unregister the drop target
>>> listeners.
>>> 
>>> The changes in JDK are mostly technical. We simply delegate the
>>> Toolkit.createDragSourceContextPeer() and
>>> Toolkit.createDragGestureRecognizer() factory methods to SwingNode.
>>> Similarly, we delegate the DropTargetPeer.add/removeDropTarget()
>>> operations to SwingNode as well.
>>> 
>>> In FX I've factored out the CachingTransferable class from the
>>> SwingDragSource class so as to share the implementation with the
>>> SwingNode DnD support. Also I've added a few utility methods to
>>> DataFlavorUtils and SwingFXUtils. The main fix is the new code in
>>> FXDnD.java which actually implements the AWT interfaces, installs
>>> appropriate event handlers on the SwingNode node in FX, and handles all
>>> the DnD events.
>>> 
>>> Note that the JDK <-> FX interface is loose because I use default
>>> methods in the LightweightContent interface, so that you can run new FX
>>> with the old JDK, or old FX with the new JDK, and nothing should break.
>>> Obviously, the DnD in SwingNode will only work if both JDK and FX are
>>> patched.
>>> 
>>> I've tested these changes on Windows and Mac with the sample code from
>>> this JIRA as well as a JFXPanel DnD test application from RT-34283. The
>>> DnD works fine for me in both intra- and inter-process modes.
>>> 
>>> Please post your review comments in JIRA.
>>> 
>>> --
>>> best regards,
>>> Anthony


From anthony.petrov at oracle.com  Mon Aug 11 17:57:43 2014
From: anthony.petrov at oracle.com (Anthony Petrov)
Date: Mon, 11 Aug 2014 21:57:43 +0400
Subject: <AWT Dev> [9/8u40] Review request for RT-37149 and JDK-8049065
 : Implement DnD for SwingNode
In-Reply-To: <0AF263C0-EBC2-4005-A7F2-95130DD6C116@oracle.com>
References: <53C932B9.1010409@oracle.com> <53E0D764.9090507@oracle.com>
	<53E2620F.1070209@oracle.com>
	<0AF263C0-EBC2-4005-A7F2-95130DD6C116@oracle.com>
Message-ID: <53E90417.6010608@oracle.com>

Thank you very much, Petr!

Tomorrow I'll be pushing both JDK 9 and FX 8u-dev parts to the 
repositories unless anyone raises any objections.

After that, I'll be requesting an approval to back-port the JDK fix to 
JDK 8u-dev, so that the whole feature could be delivered to JDK/FX 8u40.

--
best regards,
Anthony

On 8/11/2014 6:27 PM, Petr Pchelko wrote:
> Hello, Anthony.
>
> The AWT part looks good to me.
>
> With best regards. Petr.
>
>> On Aug 6, 2014, at 9:12 PM, Anthony Petrov <anthony.petrov at oracle.com> wrote:
>>
>> Anton: thank you for reviewing the fix.
>>
>> All: I need at least one more reviewer for the JDK part of the fix because we're going to back-port the change to 8u40. Could anyone please review it? Artem, Sergey, anyone?
>>
>> For your convenience: https://javafx-jira.kenai.com/browse/RT-37149
>>
>> http://cr.openjdk.java.net/~anthony/9-5.2/
>> https://bugs.openjdk.java.net/browse/JDK-8049065
>>
>> --
>> best regards,
>> Anthony
>>
>> On 8/5/2014 5:08 PM, Anthony Petrov wrote:
>>> Anton, Artem, Steve,
>>>
>>> Could you please review this fix?
>>>
>>> --
>>> best regards,
>>> Anthony
>>>
>>> On 7/18/2014 6:44 PM, Anthony Petrov wrote:
>>>> Hi Petr, Anton, Artem, Steve,
>>>>
>>>> Please review the fix at https://javafx-jira.kenai.com/browse/RT-37149
>>>>
>>>> Webrevs:
>>>>
>>>> JDK: http://cr.openjdk.java.net/~anthony/9-5.2/
>>>>
>>>> FX: http://cr.openjdk.java.net/~anthony/g-522-swingNodeDnD-RT-37149.3/
>>>>
>>>>
>>>> JavaFX implements the DragSourceContextPeer and DragGestureRecognizer so
>>>> that SwingNode content could pose as a drag source. In order to support
>>>> a drop target, the DropTargetContextPeer is implemented in SwingNode and
>>>> the add/removeDropTarget() methods register/unregister the drop target
>>>> listeners.
>>>>
>>>> The changes in JDK are mostly technical. We simply delegate the
>>>> Toolkit.createDragSourceContextPeer() and
>>>> Toolkit.createDragGestureRecognizer() factory methods to SwingNode.
>>>> Similarly, we delegate the DropTargetPeer.add/removeDropTarget()
>>>> operations to SwingNode as well.
>>>>
>>>> In FX I've factored out the CachingTransferable class from the
>>>> SwingDragSource class so as to share the implementation with the
>>>> SwingNode DnD support. Also I've added a few utility methods to
>>>> DataFlavorUtils and SwingFXUtils. The main fix is the new code in
>>>> FXDnD.java which actually implements the AWT interfaces, installs
>>>> appropriate event handlers on the SwingNode node in FX, and handles all
>>>> the DnD events.
>>>>
>>>> Note that the JDK <-> FX interface is loose because I use default
>>>> methods in the LightweightContent interface, so that you can run new FX
>>>> with the old JDK, or old FX with the new JDK, and nothing should break.
>>>> Obviously, the DnD in SwingNode will only work if both JDK and FX are
>>>> patched.
>>>>
>>>> I've tested these changes on Windows and Mac with the sample code from
>>>> this JIRA as well as a JFXPanel DnD test application from RT-34283. The
>>>> DnD works fine for me in both intra- and inter-process modes.
>>>>
>>>> Please post your review comments in JIRA.
>>>>
>>>> --
>>>> best regards,
>>>> Anthony
>

From Sergey.Bylokhov at oracle.com  Tue Aug 12 13:32:59 2014
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Tue, 12 Aug 2014 17:32:59 +0400
Subject: <AWT Dev> [9] Review request for 8053657: [TEST_BUG] move some
 5 tests related to undecorated Frame/JFrame to JDK
In-Reply-To: <53E22923.80603@oracle.com>
References: <53D89696.5070602@oracle.com> <53E098A3.1020108@oracle.com>
	<53E22419.6090309@oracle.com> <53E22923.80603@oracle.com>
Message-ID: <53EA178B.9060105@oracle.com>

Hi, Yuri.
It is unclear why you move creation of the JFrame from the EDT in 
UndecoratedInitiallyIconified. It should be moved back.
On 06.08.2014 17:09, Yuri Nesterenko wrote:
> Oh! You are right, thank you.
> Second version is
>
> http://cr.openjdk.java.net/~yan/8053657/webrev.01/
>
> -yan
>
> On 08/06/2014 04:48 PM, Sergey Bylokhov wrote:
>> Hi, Yuri.
>> In some of these tests focusGained variable is not used or its
>> validation is missed. In UndecoratedInitiallyIconified you can simplify
>> the code and uses a throws in main instead of try/catch.
>>
>> On 05.08.2014 12:41, Yuri Nesterenko wrote:
>>> A friendly reminder!
>>>
>>> Thanks,
>>> -yan
>>>
>>> On 07/30/2014 10:54 AM, Yuri Nesterenko wrote:
>>>> Hi team,
>>>>
>>>> please review yet another test update in jdk9:
>>>>
>>>> http://cr.openjdk.java.net/~yan/8053657/webrev.00
>>>>
>>>> ( https://bugs.openjdk.java.net/browse/JDK-8053657 )
>>>>
>>>> These are 5 tests made out of some 8 old functional ones
>>>> dealing with undecorated Frames (and JFrames).
>>>>
>>>> NB: piggybacking here a removal of
>>>> java/awt/Mixing/AWT_Mixing/Util.java.
>>>> It was approved long ago but I forgot to delete it in
>>>> time.
>>>>
>>>> Tests proven on 4 platforms in continuous runs.
>>>>
>>>> Thanks,
>>>> -yan
>>>
>>
>>
>


-- 
Best regards, Sergey.


From dmitriy.ermashov at oracle.com  Tue Aug 12 13:35:40 2014
From: dmitriy.ermashov at oracle.com (Dmitriy Ermashov)
Date: Tue, 12 Aug 2014 17:35:40 +0400
Subject: <AWT Dev> Review Request for 8051716: Move AWT_BAT functional
 tests to OpenJDK (1 of 3)
In-Reply-To: <53E21A3E.7070403@oracle.com>
References: <53D64038.5040307@oracle.com> <53DA48F4.1070405@oracle.com>
	<53E21A3E.7070403@oracle.com>
Message-ID: <53EA182C.7020308@oracle.com>

Hi AWT team,

Could anyone please review  the tests?
http://cr.openjdk.java.net/~dermashov/8051716/webrev.01/

Corresponding bug:
https://bugs.openjdk.java.net/browse/JDK-8051716

The tests were taken from reliability test framework. So, as one can 
see, several tests
do not actual verify anything, but just produce some actions (e.g. 
TestFrame.java) and
make sure no dead lock occurs.
On the other hand, there are three tests TaskX* that should be run on 
well configured
node, where gcc compiler and other developers libraries should be 
installed.

Test were verified on following platforms:
Windows 7 x64
Ubuntu 14.04 x64
Ubuntu 10.04 arm
Solaris 11 x64 (intel)
OS X 10.10 beta

Thanks,
Dima

On 06.08.2014 16:06, Dmitriy Ermashov wrote:
> Hi,
>
> Just a kindly reminder.
>
> Thanks,
> Dima
>
> On 31.07.2014 17:47, Dmitriy Ermashov wrote:
>> Hi,
>>
>> Please review the updated version of tests:
>> http://cr.openjdk.java.net/~dermashov/8051716/webrev.01/
>>
>> Last changes:
>> 1. All GUI creation/modification moved to EDT
>>
>> Thanks,
>> Dima
>>
>> On 28.07.2014 16:21, Dmitriy Ermashov wrote:
>>> Hi AWT team,
>>>
>>> Please review one more batch of functional tests:
>>> http://cr.openjdk.java.net/~dermashov/8051716/webrev.00/
>>>
>>> Corresponding bug:
>>> https://bugs.openjdk.java.net/browse/JDK-8051716
>>>
>>> The tests were taken from reliability test framework. So, as one can 
>>> see, several tests
>>> do not actual verify anything, but just produce some actions (e.g. 
>>> TestFrame.java) and
>>> make sure no dead lock occurs.
>>> On the other hand, there are three tests TaskX* that should be run 
>>> on well configured
>>> node, where gcc compiler and other developers libraries should be 
>>> installed.
>>>
>>> Test were verified on following platforms:
>>> Windows 7 x64
>>> Ubuntu 14.04 x64
>>> Ubuntu 10.04 arm
>>> Solaris 11 x64 (intel)
>>> OS X 10.10 beta
>>>
>>
>


From yuri.nesterenko at oracle.com  Tue Aug 12 13:49:08 2014
From: yuri.nesterenko at oracle.com (Yuri Nesterenko)
Date: Tue, 12 Aug 2014 17:49:08 +0400
Subject: <AWT Dev> [9] Review request for 8053657: [TEST_BUG] move some
 5 tests related to undecorated Frame/JFrame to JDK
In-Reply-To: <53EA178B.9060105@oracle.com>
References: <53D89696.5070602@oracle.com> <53E098A3.1020108@oracle.com>
	<53E22419.6090309@oracle.com> <53E22923.80603@oracle.com>
	<53EA178B.9060105@oracle.com>
Message-ID: <53EA1B54.6020309@oracle.com>

OK, third version then!
http://cr.openjdk.java.net/~yan/8053657/webrev.02/

-yan

On 08/12/2014 05:32 PM, Sergey Bylokhov wrote:
> Hi, Yuri.
> It is unclear why you move creation of the JFrame from the EDT in
> UndecoratedInitiallyIconified. It should be moved back.
> On 06.08.2014 17:09, Yuri Nesterenko wrote:
>> Oh! You are right, thank you.
>> Second version is
>>
>> http://cr.openjdk.java.net/~yan/8053657/webrev.01/
>>
>> -yan
>>
>> On 08/06/2014 04:48 PM, Sergey Bylokhov wrote:
>>> Hi, Yuri.
>>> In some of these tests focusGained variable is not used or its
>>> validation is missed. In UndecoratedInitiallyIconified you can simplify
>>> the code and uses a throws in main instead of try/catch.
>>>
>>> On 05.08.2014 12:41, Yuri Nesterenko wrote:
>>>> A friendly reminder!
>>>>
>>>> Thanks,
>>>> -yan
>>>>
>>>> On 07/30/2014 10:54 AM, Yuri Nesterenko wrote:
>>>>> Hi team,
>>>>>
>>>>> please review yet another test update in jdk9:
>>>>>
>>>>> http://cr.openjdk.java.net/~yan/8053657/webrev.00
>>>>>
>>>>> ( https://bugs.openjdk.java.net/browse/JDK-8053657 )
>>>>>
>>>>> These are 5 tests made out of some 8 old functional ones
>>>>> dealing with undecorated Frames (and JFrames).
>>>>>
>>>>> NB: piggybacking here a removal of
>>>>> java/awt/Mixing/AWT_Mixing/Util.java.
>>>>> It was approved long ago but I forgot to delete it in
>>>>> time.
>>>>>
>>>>> Tests proven on 4 platforms in continuous runs.
>>>>>
>>>>> Thanks,
>>>>> -yan
>>>>
>>>
>>>
>>
>
>


From Sergey.Bylokhov at oracle.com  Tue Aug 12 14:05:19 2014
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Tue, 12 Aug 2014 18:05:19 +0400
Subject: <AWT Dev> [9] Review request for 8053657: [TEST_BUG] move some
 5 tests related to undecorated Frame/JFrame to JDK
In-Reply-To: <53EA1B54.6020309@oracle.com>
References: <53D89696.5070602@oracle.com> <53E098A3.1020108@oracle.com>
	<53E22419.6090309@oracle.com> <53E22923.80603@oracle.com>
	<53EA178B.9060105@oracle.com> <53EA1B54.6020309@oracle.com>
Message-ID: <53EA1F1F.4040501@oracle.com>

Hi, Yuri.
Thanks. The fix looks good.

On 12.08.2014 17:49, Yuri Nesterenko wrote:
> OK, third version then!
> http://cr.openjdk.java.net/~yan/8053657/webrev.02/
>
> -yan
>
> On 08/12/2014 05:32 PM, Sergey Bylokhov wrote:
>> Hi, Yuri.
>> It is unclear why you move creation of the JFrame from the EDT in
>> UndecoratedInitiallyIconified. It should be moved back.
>> On 06.08.2014 17:09, Yuri Nesterenko wrote:
>>> Oh! You are right, thank you.
>>> Second version is
>>>
>>> http://cr.openjdk.java.net/~yan/8053657/webrev.01/
>>>
>>> -yan
>>>
>>> On 08/06/2014 04:48 PM, Sergey Bylokhov wrote:
>>>> Hi, Yuri.
>>>> In some of these tests focusGained variable is not used or its
>>>> validation is missed. In UndecoratedInitiallyIconified you can 
>>>> simplify
>>>> the code and uses a throws in main instead of try/catch.
>>>>
>>>> On 05.08.2014 12:41, Yuri Nesterenko wrote:
>>>>> A friendly reminder!
>>>>>
>>>>> Thanks,
>>>>> -yan
>>>>>
>>>>> On 07/30/2014 10:54 AM, Yuri Nesterenko wrote:
>>>>>> Hi team,
>>>>>>
>>>>>> please review yet another test update in jdk9:
>>>>>>
>>>>>> http://cr.openjdk.java.net/~yan/8053657/webrev.00
>>>>>>
>>>>>> ( https://bugs.openjdk.java.net/browse/JDK-8053657 )
>>>>>>
>>>>>> These are 5 tests made out of some 8 old functional ones
>>>>>> dealing with undecorated Frames (and JFrames).
>>>>>>
>>>>>> NB: piggybacking here a removal of
>>>>>> java/awt/Mixing/AWT_Mixing/Util.java.
>>>>>> It was approved long ago but I forgot to delete it in
>>>>>> time.
>>>>>>
>>>>>> Tests proven on 4 platforms in continuous runs.
>>>>>>
>>>>>> Thanks,
>>>>>> -yan
>>>>>
>>>>
>>>>
>>>
>>
>>
>


-- 
Best regards, Sergey.


From alexander.zvegintsev at oracle.com  Tue Aug 12 19:36:34 2014
From: alexander.zvegintsev at oracle.com (Alexander Zvegintsev)
Date: Tue, 12 Aug 2014 23:36:34 +0400
Subject: <AWT Dev> Review request for 8051617: Fullscreen mode is not
 working properly on Xorg
Message-ID: <53EA6CC2.1080607@oracle.com>

Hello,

please review the fix
http://cr.openjdk.java.net/~azvegint/jdk/9/8051617/00/
for the issue
https://bugs.openjdk.java.net/browse/JDK-8051617

Our logic for detecting top level window may fail on some window managers.
This fix passes this window directly.

-- 
--
Thanks,
Alexander.


From sergey.bylokhov at oracle.com  Tue Aug 12 23:30:39 2014
From: sergey.bylokhov at oracle.com (Sergey Bylokhov)
Date: Tue, 12 Aug 2014 16:30:39 -0700 (PDT)
Subject: <AWT Dev> Review request for 8051617: Fullscreen mode is not
 working properly on Xorg
Message-ID: <f753c00d-1e42-489f-88c2-d8a0291fab4e@default>

Hi, Alexander.
Can you confirm that it works in multi-screen configuration?
Also please check that xrender,x11 and opengl pipelines work as expected in fullscreen.

>>Hello,

>>please review the fix
>>http://cr.openjdk.java.net/~azvegint/jdk/9/8051617/00/
>>for the issue
>>https://bugs.openjdk.java.net/browse/JDK-8051617

>>Our logic for detecting top level window may fail on some window managers.
>>This fix passes this window directly.

-- 
--
Thanks,
Alexander.


From anthony.petrov at oracle.com  Wed Aug 13 12:01:50 2014
From: anthony.petrov at oracle.com (Anthony Petrov)
Date: Wed, 13 Aug 2014 16:01:50 +0400
Subject: <AWT Dev> Review request for 8051617: Fullscreen mode is not
 working properly on Xorg
In-Reply-To: <53EA6CC2.1080607@oracle.com>
References: <53EA6CC2.1080607@oracle.com>
Message-ID: <53EB53AE.6090101@oracle.com>

Hi Alexander,

I don't see any immediate problems with the changes and generally the 
fix looks good to me. However, I suppose that on some rare window 
managers this might not work as expected. We should understand the risk 
and be ready to fix problems if any regressions are reported.

Also note that there are non-, single-, and double- (and possibly even 
multi-) re-parenting window managers. See XWM.java for details. Have you 
tested this code with at least one WM of each of these categories to 
ensure we don't break things?

--
best regards,
Anthony

On 8/12/2014 11:36 PM, Alexander Zvegintsev wrote:
> Hello,
>
> please review the fix
> http://cr.openjdk.java.net/~azvegint/jdk/9/8051617/00/
> for the issue
> https://bugs.openjdk.java.net/browse/JDK-8051617
>
> Our logic for detecting top level window may fail on some window managers.
> This fix passes this window directly.
>

From alexander.v.stepanov at oracle.com  Fri Aug 15 08:19:54 2014
From: alexander.v.stepanov at oracle.com (alexander stepanov)
Date: Fri, 15 Aug 2014 12:19:54 +0400
Subject: <AWT Dev> [9] Review Request for 8054358: move awt automated tests
 from AWT_Modality to OpenJDK repository - part 7
Message-ID: <53EDC2AA.9080802@oracle.com>

Hello,

Could you please review the fix for
https://bugs.openjdk.java.net/browse/JDK-8054358

webrev:
http://cr.openjdk.java.net/~avstepan/8054358/

This is the next portion of functional AWT tests prepared for migration 
to OpenJDK repository.

The tests were checked on Ubuntu 14.04 Linux, Solaris 11, Mac OS X 
10.8.5 and Windows 7.

Thanks,
Alexander

From anthony.petrov at oracle.com  Mon Aug 18 14:15:08 2014
From: anthony.petrov at oracle.com (Anthony Petrov)
Date: Mon, 18 Aug 2014 18:15:08 +0400
Subject: <AWT Dev> RFR [9] Modular Source Code
In-Reply-To: <53F203EF.9070907@oracle.com>
References: <3132CBA0-5920-4DDA-8E69-308D5492F0DD@oracle.com>	<53EDCA54.2090107@oracle.com>
	<53EDDD47.2010204@oracle.com> <53F203EF.9070907@oracle.com>
Message-ID: <53F20A6C.7090805@oracle.com>

On 8/18/2014 5:47 PM, Magnus Ihse Bursie wrote:
> libawt et al:
>    The relation between libawt, libawt_headless, libjawt, libawt_xawt
> and libawt_lwawt are hairy enough to make my brain curl up. I believe
> there are simplifications to be made but I gave up trying to figure them
> out.

libawt contains code that is shared between all AWT lib implementations. 
Depending on what mode/toolkit is requested, it loads a specific variant 
of the awt native library, such as:

  - libawt_headless - headless AWT implementation.
  - libawt_xawt - XToolkit implementation (uses X11 for GUI)
  - libawt_lwawt - CToolkit implementation (uses Cocoa for GUI)

Historically, we were able to choose between lwawt and xawt on Mac in 
the past, but we no longer support or even build xawt on Mac. Also, in 
the past there was MToolkit (which used Motif for GUI). Again, we no 
longer support this toolkit. So, currently we always use xawt on 
Linux/Solaris and lwawt on Mac. But since we still need to choose 
between a real toolkit and a headless toolkit, we need the common libawt 
library.

libjawt is a helper library that implements JAWT API and is loaded by 
applications that use the JAWT interface which allows them to get direct 
access to the native AWT drawing surface and use native APIs (e.g. 
OpenGL) to draw on the surface. This library isn't needed for regular 
AWT/Swing applications.

So I'm not sure if the current set of AWT libraries could be simplified 
any further.

Hope this helps.

--
best regards,
Anthony

From philip.race at oracle.com  Tue Aug 19 23:09:09 2014
From: philip.race at oracle.com (Phil Race)
Date: Tue, 19 Aug 2014 16:09:09 -0700
Subject: <AWT Dev> RFR [9] Modular Source Code
In-Reply-To: <53F20A6C.7090805@oracle.com>
References: <3132CBA0-5920-4DDA-8E69-308D5492F0DD@oracle.com>	<53EDCA54.2090107@oracle.com>
	<53EDDD47.2010204@oracle.com> <53F203EF.9070907@oracle.com>
	<53F20A6C.7090805@oracle.com>
Message-ID: <53F3D915.5030208@oracle.com>

On a related note I am scratching my head about why some files
destined to be compiled into libawt or libawt_xawt go into a directory
called 'common'.
Eg OpenGL sources are in common but aren't common to all libs
or even to all awt libs, since they would go into libawt on windows
and libawt_xawt on unix and not at all into libawt_headless.

'common 'might (guessing here)  have started out as place to put interface
header files shared between libs but maybe got adopted for other uses ?

-phil.



On 08/18/2014 07:15 AM, Anthony Petrov wrote:
> On 8/18/2014 5:47 PM, Magnus Ihse Bursie wrote:
>> libawt et al:
>>    The relation between libawt, libawt_headless, libjawt, libawt_xawt
>> and libawt_lwawt are hairy enough to make my brain curl up. I believe
>> there are simplifications to be made but I gave up trying to figure them
>> out.
>
> libawt contains code that is shared between all AWT lib 
> implementations. Depending on what mode/toolkit is requested, it loads 
> a specific variant of the awt native library, such as:
>
>  - libawt_headless - headless AWT implementation.
>  - libawt_xawt - XToolkit implementation (uses X11 for GUI)
>  - libawt_lwawt - CToolkit implementation (uses Cocoa for GUI)
>
> Historically, we were able to choose between lwawt and xawt on Mac in 
> the past, but we no longer support or even build xawt on Mac. Also, in 
> the past there was MToolkit (which used Motif for GUI). Again, we no 
> longer support this toolkit. So, currently we always use xawt on 
> Linux/Solaris and lwawt on Mac. But since we still need to choose 
> between a real toolkit and a headless toolkit, we need the common 
> libawt library.
>
> libjawt is a helper library that implements JAWT API and is loaded by 
> applications that use the JAWT interface which allows them to get 
> direct access to the native AWT drawing surface and use native APIs 
> (e.g. OpenGL) to draw on the surface. This library isn't needed for 
> regular AWT/Swing applications.
>
> So I'm not sure if the current set of AWT libraries could be 
> simplified any further.
>
> Hope this helps.
>
> -- 
> best regards,
> Anthony


From erik.joelsson at oracle.com  Wed Aug 20 08:37:09 2014
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Wed, 20 Aug 2014 10:37:09 +0200
Subject: <AWT Dev> RFR [9] Modular Source Code
In-Reply-To: <53F3D915.5030208@oracle.com>
References: <3132CBA0-5920-4DDA-8E69-308D5492F0DD@oracle.com>	<53EDCA54.2090107@oracle.com>	<53EDDD47.2010204@oracle.com>
	<53F203EF.9070907@oracle.com>	<53F20A6C.7090805@oracle.com>
	<53F3D915.5030208@oracle.com>
Message-ID: <53F45E35.7030809@oracle.com>

Hello,

The basic rule for the new source layout is that for each library, there 
is a directory where all sources for that library go. This was hard to 
apply to libawt and friends since as you say, some files go in libawt on 
windows and libawt_xawt on linux and solaris. For now, I put those in 
common for lack of a better place.

/Erik


On 2014-08-20 01:09, Phil Race wrote:
> On a related note I am scratching my head about why some files
> destined to be compiled into libawt or libawt_xawt go into a directory
> called 'common'.
> Eg OpenGL sources are in common but aren't common to all libs
> or even to all awt libs, since they would go into libawt on windows
> and libawt_xawt on unix and not at all into libawt_headless.
>
> 'common 'might (guessing here)  have started out as place to put 
> interface
> header files shared between libs but maybe got adopted for other uses ?
>
> -phil.
>
>
>
> On 08/18/2014 07:15 AM, Anthony Petrov wrote:
>> On 8/18/2014 5:47 PM, Magnus Ihse Bursie wrote:
>>> libawt et al:
>>>    The relation between libawt, libawt_headless, libjawt, libawt_xawt
>>> and libawt_lwawt are hairy enough to make my brain curl up. I believe
>>> there are simplifications to be made but I gave up trying to figure 
>>> them
>>> out.
>>
>> libawt contains code that is shared between all AWT lib 
>> implementations. Depending on what mode/toolkit is requested, it 
>> loads a specific variant of the awt native library, such as:
>>
>>  - libawt_headless - headless AWT implementation.
>>  - libawt_xawt - XToolkit implementation (uses X11 for GUI)
>>  - libawt_lwawt - CToolkit implementation (uses Cocoa for GUI)
>>
>> Historically, we were able to choose between lwawt and xawt on Mac in 
>> the past, but we no longer support or even build xawt on Mac. Also, 
>> in the past there was MToolkit (which used Motif for GUI). Again, we 
>> no longer support this toolkit. So, currently we always use xawt on 
>> Linux/Solaris and lwawt on Mac. But since we still need to choose 
>> between a real toolkit and a headless toolkit, we need the common 
>> libawt library.
>>
>> libjawt is a helper library that implements JAWT API and is loaded by 
>> applications that use the JAWT interface which allows them to get 
>> direct access to the native AWT drawing surface and use native APIs 
>> (e.g. OpenGL) to draw on the surface. This library isn't needed for 
>> regular AWT/Swing applications.
>>
>> So I'm not sure if the current set of AWT libraries could be 
>> simplified any further.
>>
>> Hope this helps.
>>
>> -- 
>> best regards,
>> Anthony
>


From magnus.ihse.bursie at oracle.com  Wed Aug 20 09:14:10 2014
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Wed, 20 Aug 2014 11:14:10 +0200
Subject: <AWT Dev> RFR [9] Modular Source Code
In-Reply-To: <53F20A6C.7090805@oracle.com>
References: <3132CBA0-5920-4DDA-8E69-308D5492F0DD@oracle.com>	<53EDCA54.2090107@oracle.com>
	<53EDDD47.2010204@oracle.com> <53F203EF.9070907@oracle.com>
	<53F20A6C.7090805@oracle.com>
Message-ID: <53F466E2.7070501@oracle.com>

On 2014-08-18 16:15, Anthony Petrov wrote:
> On 8/18/2014 5:47 PM, Magnus Ihse Bursie wrote:
>> libawt et al:
>>    The relation between libawt, libawt_headless, libjawt, libawt_xawt
>> and libawt_lwawt are hairy enough to make my brain curl up. I believe
>> there are simplifications to be made but I gave up trying to figure them
>> out.
>
> libawt contains code that is shared between all AWT lib 
> implementations. Depending on what mode/toolkit is requested, it loads 
> a specific variant of the awt native library, such as:
>
>  - libawt_headless - headless AWT implementation.
>  - libawt_xawt - XToolkit implementation (uses X11 for GUI)
>  - libawt_lwawt - CToolkit implementation (uses Cocoa for GUI)
>
> Historically, we were able to choose between lwawt and xawt on Mac in 
> the past, but we no longer support or even build xawt on Mac. Also, in 
> the past there was MToolkit (which used Motif for GUI). Again, we no 
> longer support this toolkit. So, currently we always use xawt on 
> Linux/Solaris and lwawt on Mac. But since we still need to choose 
> between a real toolkit and a headless toolkit, we need the common 
> libawt library.
>
> libjawt is a helper library that implements JAWT API and is loaded by 
> applications that use the JAWT interface which allows them to get 
> direct access to the native AWT drawing surface and use native APIs 
> (e.g. OpenGL) to draw on the surface. This library isn't needed for 
> regular AWT/Swing applications.
>
> So I'm not sure if the current set of AWT libraries could be 
> simplified any further.
>
> Hope this helps.

Thank you for the clarification, it was very helpful!

While the set of AWT libraries probably cannot be simplified as you say, 
my gut feeling is still that the current layout of files on disk does 
not optimally match the actual libraries we build. Armed with the help 
of your description, I'll look into them once again and see if I can 
make that statement more concrete.

/Magnus

From yuri.nesterenko at oracle.com  Wed Aug 20 12:09:21 2014
From: yuri.nesterenko at oracle.com (Yuri Nesterenko)
Date: Wed, 20 Aug 2014 16:09:21 +0400
Subject: <AWT Dev> [9] Review request for 8055664: move 14 tests about
 setLocationRelativeTo to jdk
Message-ID: <53F48FF1.3070304@oracle.com>

Hi team,

please review this test update in jdk9:

http://cr.openjdk.java.net/~yan/8055664/webrev.00

( https://bugs.openjdk.java.net/browse/JDK-8055664 )

There's a single test made out of 14 old internal functional tests.
Existing tests do verify that a Frame (Dialog, JFrame etc.
toplevel) if setLocationRelativeTo(Component) do it right.

As the number of components * toplevels is rather big,
the test picks randomly just few of them from the lists.
If by chance there will be failure, simple option would
allow to run all combinations.
Also, if we'll have a "switch" controlling this selection
behavior, we'll use it here.

Thanks,
-yan

From alexey.ivanov at oracle.com  Wed Aug 20 13:35:25 2014
From: alexey.ivanov at oracle.com (Alexey Ivanov)
Date: Wed, 20 Aug 2014 17:35:25 +0400
Subject: <AWT Dev> [7u-dev] Request for approval for JDK-8043610: Sorting
 columns in JFileChooser fails with AppContext NPE
Message-ID: <53F4A41D.4020804@oracle.com>

Hello,

Please approve the backport of the fix to jdk7u-dev.

I replaced lambda expressions and method reference with anonymous classes:

     webrev: http://cr.openjdk.java.net/~aivanov/8043610/jdk7/webrev.00/


AWT and Swing teams,

Could you please review the backport?

JBS bug: https://bugs.openjdk.java.net/browse/JDK-8043610
JDK9 review: 
http://mail.openjdk.java.net/pipermail/awt-dev/2014-May/007846.html
JDK9 webrev: http://cr.openjdk.java.net/~pchelko/9/8043610/webrev/

JDK9 changeset: http://hg.openjdk.java.net/jdk9/client/jdk/rev/604abecf62c2
JDK8 changeset: 
http://hg.openjdk.java.net/jdk8u/jdk8u-dev/jdk/rev/b20c4785bb81


Thank you in advance,
Alexey.

From anthony.petrov at oracle.com  Wed Aug 20 13:44:01 2014
From: anthony.petrov at oracle.com (Anthony Petrov)
Date: Wed, 20 Aug 2014 17:44:01 +0400
Subject: <AWT Dev> [7u-dev] Request for approval for JDK-8043610:
 Sorting columns in JFileChooser fails with AppContext NPE
In-Reply-To: <53F4A41D.4020804@oracle.com>
References: <53F4A41D.4020804@oracle.com>
Message-ID: <53F4A621.1070905@oracle.com>

Looks fine. +1

--
best regards,
Anthony

On 8/20/2014 5:35 PM, Alexey Ivanov wrote:
> Hello,
>
> Please approve the backport of the fix to jdk7u-dev.
>
> I replaced lambda expressions and method reference with anonymous classes:
>
>      webrev: http://cr.openjdk.java.net/~aivanov/8043610/jdk7/webrev.00/
>
>
> AWT and Swing teams,
>
> Could you please review the backport?
>
> JBS bug: https://bugs.openjdk.java.net/browse/JDK-8043610
> JDK9 review:
> http://mail.openjdk.java.net/pipermail/awt-dev/2014-May/007846.html
> JDK9 webrev: http://cr.openjdk.java.net/~pchelko/9/8043610/webrev/
>
> JDK9 changeset: http://hg.openjdk.java.net/jdk9/client/jdk/rev/604abecf62c2
> JDK8 changeset:
> http://hg.openjdk.java.net/jdk8u/jdk8u-dev/jdk/rev/b20c4785bb81
>
>
> Thank you in advance,
> Alexey.

From sean.coffey at oracle.com  Wed Aug 20 14:10:19 2014
From: sean.coffey at oracle.com (=?UTF-8?B?U2XDoW4gQ29mZmV5?=)
Date: Wed, 20 Aug 2014 15:10:19 +0100
Subject: <AWT Dev> [7u-dev] Request for approval for JDK-8043610:
 Sorting columns in JFileChooser fails with AppContext NPE
In-Reply-To: <53F4A621.1070905@oracle.com>
References: <53F4A41D.4020804@oracle.com> <53F4A621.1070905@oracle.com>
Message-ID: <53F4AC4B.2080506@oracle.com>

Approved.

regards,
Sean.

On 20/08/14 14:44, Anthony Petrov wrote:
> Looks fine. +1
>
> -- 
> best regards,
> Anthony
>
> On 8/20/2014 5:35 PM, Alexey Ivanov wrote:
>> Hello,
>>
>> Please approve the backport of the fix to jdk7u-dev.
>>
>> I replaced lambda expressions and method reference with anonymous 
>> classes:
>>
>>      webrev: http://cr.openjdk.java.net/~aivanov/8043610/jdk7/webrev.00/
>>
>>
>> AWT and Swing teams,
>>
>> Could you please review the backport?
>>
>> JBS bug: https://bugs.openjdk.java.net/browse/JDK-8043610
>> JDK9 review:
>> http://mail.openjdk.java.net/pipermail/awt-dev/2014-May/007846.html
>> JDK9 webrev: http://cr.openjdk.java.net/~pchelko/9/8043610/webrev/
>>
>> JDK9 changeset: 
>> http://hg.openjdk.java.net/jdk9/client/jdk/rev/604abecf62c2
>> JDK8 changeset:
>> http://hg.openjdk.java.net/jdk8u/jdk8u-dev/jdk/rev/b20c4785bb81
>>
>>
>> Thank you in advance,
>> Alexey.


From alexandr.scherbatiy at oracle.com  Wed Aug 20 17:10:24 2014
From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy)
Date: Wed, 20 Aug 2014 21:10:24 +0400
Subject: <AWT Dev> [OpenJDK 2D-Dev] [9] Review request for 8029339
 Custom MultiResolution image support on HiDPI displays
In-Reply-To: <53D7B35B.1010703@oracle.com>
References: <52D51764.8020103@oracle.com> <52DF2F98.3030503@oracle.com>
	<52F4BCEB.9040702@oracle.com> <52F5782A.9060300@oracle.com>
	<52FB7E3E.6050000@oracle.com> <52FC14EC.9080503@oracle.com>
	<53037D3D.80709@oracle.com> <5307E71E.50607@oracle.com>
	<530F3592.40600@oracle.com> <532B00AD.1000704@oracle.com>
	<532B7EC5.9000206@oracle.com> <532C4DD7.1080804@oracle.com>
	<532CD202.5070508@oracle.com> <53302A8E.6090107@oracle.com>
	<53343914.6090004@oracle.com> <533C8DDB.5000406@oracle.com>
	<533E9D42.10409@oracle.com> <53598D86.5020607@oracle.com>
	<535A7509.6050802@oracle.com> <5370DC41.5080608@oracle.com>
	<537639D5.9000206@oracle.com> <53764700.2060309@oracle.com>
	<5379E117.6010202@oracle.com> <538F2D56.80609@oracle.com>
	<5396220E.9030708@oracle.com> <5397180C.5040105@oracle.com>
	<53987361.5040903@oracle.com> <53BC0803.6090704@oracle.com>
	<53D7B35B.1010703@oracle.com>
Message-ID: <53F4D680.60902@oracle.com>


   Hi Phil,

   I have prepared the fix where resolution variants are added directly 
to the Image:
    http://cr.openjdk.java.net/~alexsch/8029339/list/webrev.00

   You could compare this with the previous version where 
MultiResolutionImage interface is used:
     http://cr.openjdk.java.net/~alexsch/8029339/webrev.05

   It could help to decide in which way it is better to provide the 
multi-resolution image support.

   Below are some comments:

   1. High level goal:
      Introduce an API that allows to create and handle an image with 
resolution variants.

   2. What is not subject of the provided API
     - Scale naming convention for high-resolution images
     - Providing pixel scale factor for the screen/window

   3. Use cases

    3.1 Loading and drawing high-resolution icons in IntelliJ IDEA
      A high-resolution image is loaded from resources and stored in 
JBHiDPIScaledImage class  which is a subclass of the buffered image.
      The high-resolution image is used to create a disabled icon in the 
IconLoader.getDisabledIcon(icon) method.
https://github.com/JetBrains/intellij-community/blob/master/platform/util/src/com/intellij/openapi/util/IconLoader.java

    3.2 Loading and drawing high-resolution icons in NetBeans
      NetBeans does not have support for the high-resolution icons loading.
      It loads an icon from the file system using 
Toolkit.getDefaultToolkit().getImage(url) method or from resources
      by  ImageReader  and store it in ToolTipImage class which is 
subclass of the buffered image.
      ImageUtilities.createDisabledIcon(icon) method creates a disabled 
icon by applying  RGBImageFilter to the icon.
http://hg.netbeans.org/main/file/97dcf49eb4a7/openide.util/src/org/openide/util/ImageUtilities.java

    3.3 Loading system icons in JDK 1.8
      JDK requests icons from the native system for system L&Fs and 
applies filters for them.
      See for example AquaUtils.generateLightenedImage() method:
http://hg.openjdk.java.net/jdk9/client/jdk/file/e6f48c4fad38/src/java.desktop/macosx/classes/com/apple/laf/AquaUtils.java

   4. HiDPI support for Images on different OSes

     4.1 Mac OS X
       Cocoa API contains NSImage that allows to work with image 
representations: add/remove/get all representations.
       It picks up an image with necessary resolution based on the 
screen backing store pixel scale factor and applied transforms.
https://developer.apple.com/library/mac/documentation/Cocoa/Reference/ApplicationKit/Classes/NSImage_Class/Reference/Reference.html 


     4.2 Linux
       GTK+ 3 API has gtkcssimagescaled lib (it seems that it is not 
public/stable)
       that parses the -gtk-scaled css property and draws a GtkCssImage 
according to the given scale factor.

       I have not found information about the HiDPI support in Xlib.

     4.3 Windows
       I have only found the tutorial that suggests to select and draw a 
bitmap using the queried DPI
       and scale the coordinates for drawing a rectangular frame
http://msdn.microsoft.com/en-us/library/dd464659%28v=vs.85%29.aspx

       Windows also provides the horizontal and vertical DPI of the desktop
http://msdn.microsoft.com/en-us/library/windows/apps/dd371316

   5. Pseudo API
      Below are some ways which illustrates how multi-resolution images 
can be created and used.

     5.1 Resolution variants are stored directly in Image class.
     To query a resolution variant it needs to compare the resolution 
variant width/height
     with the requested high-resolution size.
     ------------
     public abstract class Image {

         public void addResolutionVariant(Image image) {...}
         public List<Image> getResolutionVariants() {...}
     }
     ------------
     // create a disabled image with resolution variants

     Image disabledImage = getDisabledImage(image);

     for (Image rv : image.getResolutionVariants()) {
         disabledImage.addResolutionVariant(getDisabledImage(rv));
     }
     ------------
     This approach requires that all resolution variants have been 
created even not of them are really used.

     5.2  Resolution variants are stored in a separate object that 
allows to create them by demand.
     To query a resolution variant it needs to compare the resolution 
variant scale factor
     with the requested scale (that can include both screen DPI scale 
and applied transforms).
     ------------
     public abstract class Image {

         public static interface ResolutionVariant {
             Image getImage();
             float getScaleFactor();
         }

         public void addResolutionVariant(ResolutionVariant 
resolutionVariant) {...}
         public List<ResolutionVariant> getResolutionVariants() {...}
     }
     ------------
     // create a disabled image with resolution variants
     Image disabledImage = getDisabledImage(image);

     for (Image.ResolutionVariant rv : image.getResolutionVariants()) {
         disabledImage.addResolutionVariant(new Image.ResolutionVariant() {

             public Image getImage() {
                 return getDisabledImage(rv.getImage());
             }

             public float getScaleFactor() {
                 return rv.getScaleFactor();
             }
         });
     }
     ------------

     It does not have problem if a predefined set of images is provided 
(like image.png and image at 2x.png on the file system).
     This does not cover cases where a resolution variant can be created 
using the exact requested size (like loading icons from the native system).
     A resolution variant can be queried based on a scale factor and 
applied transforms.

     5.3 The provided example allows to create a resolution variant 
using the requested high-resolution image size.
     ------------
     public interface MultiResolutionImage {
         Image getResolutionVariant(float width, float height);
     }
     ------------
     // create a multi-resolution image
     Image mrImage = new AbstractMultiResolutionImage() {

             public Image getResolutionVariant(float width, float height) {
                 // create and return a resolution variant with exact 
requested width/height size
             }

             protected Image getBaseImage() {
                 return baseImage;
             }
         };
     ------------
     // create a disabled image with resolution variants
     Image disabledImage = null;
     if (image instanceof MultiResolutionImage) {
         final MultiResolutionImage mrImage = (MultiResolutionImage) image;
         disabledImage = new AbstractMultiResolutionImage(){

             public Image getResolutionVariant(float width, float height) {
                 return 
getDisabledImage(mrImage.getResolutionVariant(width, height));
             }

             protected Image getBaseImage() {
                 return getDisabledImage(mrImage);
             }
         };
     } else {
         disabledImage = getDisabledImage(image);
     }
     ------------

   Thanks,
   Alexandr.


On 7/29/2014 6:44 PM, Alexander Scherbatiy wrote:
>> On 6/11/2014 7:18 PM, Alexander Scherbatiy wrote:
>>>
>>>  Hi Phil ,
>>>
>>>  I just prepared a simple FAQ about the Custom MultiResolution image 
>>> API. Hope it will be helpful.
>>>
>>> 1. Scale naming convention for high-resolution images.
>>>
>>>  Different OSes use different "scale" naming convention for 
>>> high-resolution images:
>>>  Mac OS X: image.ext, image at 2x.ext
>>>  Windows: image.scale-100.ext, image.scale-140.ext, image.scale-180.ext
>>>
>>>  Q: Does "scale" naming convention supported in JDK?
>>>  A: Mac OS X "scale" naming convention are supported in JDK 8u20 
>>> (see JDK-8011059)
>>>       It is planned to support the Windows "scale" naming convention 
>>> as well.
>>>
>>>  Q. How does it work in JDK?
>>>  A. Bundle image.ext and image at 2x.ext images with your app on Mac OS 
>>> X and call Toolkit.getImage(...) method:
>>>         Image image = 
>>> Toolkit.getDefaultToolkit().getImage("image.ext");
>>>         Graphics2D g2d = // get graphics
>>>         g2d.drawImage(image, 0, 0, null)
>>>   SunGraphics2D automatically queries and draws the provided 
>>> high-resolution image.
>>>
>>>   Q: There are different "scale" naming conventions on Mac OS X and 
>>> Windows.
>>>        May be it is better to have unified "scale" naming 
>>> conventions for all OSes in Java like image[java-scale-Nx].ext?
>>>   A: It seems reasonable and can be filled as a new JDK enhancement.
>>>
>>>   Q: Does using "scale" naming conventions solves all problems.
>>>   A: There are tasks like image processing/programmatically 
>>> generated images/loading images from non-standard sources
>>>        that can't be solved with predefined set of images.
>>>   Q: Are there any tools that support these tasks?
>>>   A: Cocoa API contains NSImage that allows to work with image 
>>> representations: addRepresentation/removeRepresentation/representations
>>>       JDK uses these methods to get/set multi-resolution images for 
>>> the Native system (see sun.lwawt.macosx.CImage class).
>>>
>>> 2. Graphics2D
>>> Q: How SunGraphics2D deals with multi-resolution images?
>>> A: SunGraphics2D queries a resolution variant using DPI scale 
>>> factors and transformed base image sizes
>>>        //   logicalDPIX, logicalDPIY - DPI scale factors
>>>        //   destImageWidth, destImageHeight - transformed base image 
>>> sizes including DPI scale factors
>>>         multiResolutionImage.getResolutionVariant(logicalDPIX, 
>>> logicalDPIY, destImageWidth, destImageHeight);
>>>
>>> Q: Which algorithm multi-resolution image is used in 
>>> getResolutionVariant(...) method?
>>> A:  ToolkitImage returned by toolkit.loadImage() method should 
>>> behave like the native system.
>>>      It means that it should use transformed image sizes on Mac OS X 
>>> and only DPI scale factors on Windows.
>>>      it looks like:
>>>         -----------------
>>>        //   logicalDPIX, logicalDPIY - DPI scale factors
>>>        //   destImageWidth, destImageHeight - transformed base image 
>>> sizes including DPI scale factors
>>>         public Image getResolutionVariant(float logicalDPIX, float 
>>> logicalDPIY,
>>>                 float destImageWidth, float destImageHeight) {
>>>                   if (Mac OS X) {
>>>                        return resolution variant best fitted to the 
>>> destImageWidth and destImageHeight
>>>                   } else if (Windows){
>>>                        return resolution variant best fitted to the 
>>> logicalDPIX and logicalDPIY scale factors
>>>                   }
>>>         }
>>>         -----------------
>>>
>>>  3. Custom multi-resolution image.
>>>  Q: The custom multi-resolution image should be able to return an 
>>> image according to the requested
>>>       transformed image size and DPI scale factors. Is it enough?
>>>   A: There are task like setting custom cursor that require to get 
>>> all resolution variants.
>>>       So the custom multi-resolution image should also contain the 
>>> getResolutionVariants():
>>>
>>>  Q: Should the custom multi-resolution image be class or interface?
>>>  A: There is ToolkitImage that should also have resolution variants.
>>>    It is not possible to extend it from MultiResolutionImage class.
>>>    The current proposal introduces the MultiResolutionImage as an 
>>> interface.
>>>
>>>  Q: MultiResolutionImage interface sounds strange for me.
>>>  A: The better name can be suggested.
>>>
>>>   Q: What does the Custom MultiResolution image API suggest?
>>>   A:  The current proposal provides MultiResolutionImage interface 
>>> with the following methods:
>>>     ---------------------------
>>>     Image getResolutionVariant(float logicalDPIX, float logicalDPIY,
>>>             float destImageWidth, float destImageHeight);
>>>
>>>     List<Image> getResolutionVariants();
>>>     ---------------------------
>>>   and AbstractMultiResolutionImage class. See samples below.
>>>
>>>
>>>  4. Memory cost
>>>  Q: Can the the implementation be "lazy"?
>>>  A: SunGraphics2D does not require full list of resolution variants. 
>>> It queries only the image with necessary resolution.
>>>      It means that resolution variants can be loaded by demand.
>>>    Setting a custom cursor requires all resolution variants.
>>>
>>>  5. Rendering hints.
>>>  Q: Why rendering hints are added.
>>>  A: Provided rendering hints affects only multi-resolution images 
>>> and allows to disable
>>>      resolution variants usage in app. It can be useful for 
>>> performance reasons.
>>>
>>>  6. Samples.
>>>  Q: It is interesting to look at samples.
>>>  A: Below are 3 samples:
>>>      1. Draw an image with "Hello World!" text
>>>      2. Set a lightened custom cursor
>>>      3. Draw a multi-resolution image created from the program
>>>
>>>    Sample 1. Draw a image with "Hello World!" text. The text is 
>>> drawn both on the base image and on high-resolution image.
>>>        disk: duke.png, duke at 2x.png
>>>    -------------------------------
>>>     public static void main(String[] args) {
>>>
>>>         Image image = 
>>> Toolkit.getDefaultToolkit().getImage("duke.png"); // duke.png and 
>>> duke at 2x.png images are loaded by MR-ToolkitImage
>>>
>>>         Image imagewithText = image instanceof MultiResolutionImage
>>>                 ? new TextMultiresolutionImage(image) : 
>>> drawText(image);
>>>
>>>         Graphics2D g2d = // get graphics 2D
>>>         g2d.drawImage(imagewithText, x, y, null);
>>>     }
>>>
>>>     static Image drawText(Image image) {
>>>         // return an image with "Hello World!" text
>>>     }
>>>
>>>     static class TextMultiresolutionImage extends 
>>> AbstractMultiResolutionImage {
>>>
>>>         private final Image baseImage;
>>>
>>>         public TextMultiresolutionImage(Image baseImage) {
>>>             this.baseImage = baseImage;
>>>         }
>>>
>>>         @Override
>>>         public Image getResolutionVariant(float logicalDPIX, float 
>>> logicalDPIY,
>>>                 float destImageWidth, float destImageHeight) {
>>>             Image rvImage = ((MultiResolutionImage) baseImage).
>>>                     getResolutionVariant(logicalDPIX, logicalDPIY,
>>>                             destImageWidth, destImageHeight);
>>>             return drawText(rvImage);
>>>         }
>>>
>>>         @Override
>>>         public List<Image> getResolutionVariants() {
>>>                // this method is not used by SunGraphics2D to draw 
>>> the image.
>>>               // we just skip it in this example
>>>         }
>>>
>>>         @Override
>>>         protected Image getBaseImage() {
>>>             return drawText(baseImage);
>>>         }
>>>     }
>>>    -------------------------------
>>>
>>>   Sample 2. Using filters to create a lightened  custom cursor.
>>>   The filter is applied to both the base and high-resolution image.
>>>    -------------------------------
>>>     public static void main(String[] args) {
>>>
>>>         Image image = 
>>> Toolkit.getDefaultToolkit().getImage("cursor.png"); // cursor.png 
>>> and cursor at 2x.png files are provided
>>>         Image lightenedImage = image instanceof MultiResolutionImage
>>>                 ? new LigtenedMultiresolutionImage(image) : 
>>> applyFilter(image);
>>>
>>>         Cursor lightenedCursor = Toolkit.getDefaultToolkit().
>>>                 createCustomCursor(lightenedImage, new Point(0, 0), 
>>> "Lightened Cursor");
>>>         JFrame frame = new JFrame("Frame with lightened cursor");
>>>         frame.setCursor(lightenedCursor);
>>>     }
>>>
>>>     static Image applyFilter(Image image) {
>>>         GrayFilter filter = new GrayFilter(true, 50);
>>>         final ImageProducer prod = new 
>>> FilteredImageSource(image.getSource(), filter);
>>>         return Toolkit.getDefaultToolkit().createImage(prod);
>>>     }
>>>
>>>     static class LigtenedMultiresolutionImage extends 
>>> AbstractMultiResolutionImage {
>>>
>>>         private final Image baseImage;
>>>
>>>         public LigtenedMultiresolutionImage(Image baseImage) {
>>>             this.baseImage = baseImage;
>>>         }
>>>
>>>         @Override
>>>         public Image getResolutionVariant(float logicalDPIX, float 
>>> logicalDPIY,
>>>                 float destImageWidth, float destImageHeight) {
>>>               // this method is not necessary for the custom cursor 
>>> creation
>>>              // we just skip it
>>>         }
>>>
>>>         // all resolution variants are created to pass them to 
>>> NSImage for the custom cursor on Mac OS X.
>>>         @Override
>>>         public List<Image> getResolutionVariants() {
>>>             List<Image> resolutionVariants = new LinkedList<>();
>>>             for (Image rvImage : ((MultiResolutionImage) baseImage).
>>>                     getResolutionVariants()) {
>>>                 resolutionVariants.add(applyFilter(rvImage));
>>>             }
>>>             return resolutionVariants;
>>>         }
>>>
>>>         @Override
>>>         protected Image getBaseImage() {
>>>             return applyFilter(baseImage);
>>>         }
>>>     }
>>>    -------------------------------
>>>
>>>    Sample 3. Draw a multi-resolution image created from the program:
>>>    -------------------------------
>>>     public static void main(String[] args) {
>>>
>>>         Image image = generateImage(1);
>>>         Image image2x = generateImage(2);
>>>         Image mrImage = new CustomMultiresolutionImage(image, image2x);
>>>
>>>         Graphics2D g2d = // get graphics2D
>>>         g2d.drawImage(mrImage, 0, 0, null);
>>>     }
>>>
>>>     static Image generateImage(float scaleFactor) {
>>>         // generate image according to the scale factor
>>>     }
>>>
>>>     static class CustomMultiresolutionImage extends 
>>> AbstractMultiResolutionImage {
>>>
>>>         private final Image image;
>>>         private final Image highResolutionImage;
>>>
>>>         public CustomMultiresolutionImage(Image baseImage, Image 
>>> highResolutionImage) {
>>>             this.image = baseImage;
>>>             this.highResolutionImage = highResolutionImage;
>>>         }
>>>
>>>         @Override
>>>         public Image getResolutionVariant(float logicalDPIX, float 
>>> logicalDPIY,
>>>                 float destImageWidth, float destImageHeight) {
>>>             // destImageWidth and destImageHeight includes both 
>>> transforms
>>>             // DPI scale factors from Graphics
>>>             if (destImageWidth <= image.getWidth(null)
>>>                     && destImageHeight <= image.getHeight(null)) {
>>>                 return image;
>>>             }
>>>             return highResolutionImage;
>>>         }
>>>
>>>         @Override
>>>         public List<Image> getResolutionVariants() {
>>>             return Arrays.<Image>asList(image, highResolutionImage);
>>>         }
>>>
>>>         @Override
>>>         protected Image getBaseImage() {
>>>             return image;
>>>         }
>>>     }
>>> -------------------------------
>>> Thanks,
>>> Alexandr.
>>>
>>>
>>> On 6/10/2014 6:37 PM, Alexander Scherbatiy wrote:
>>>> On 6/10/2014 1:07 AM, Phil Race wrote:
>>>>> Why the split ?
>>>>> If you look only at the first part. If you can do that then why is 
>>>>> the 2nd part needed ?
>>>>    The second part introduces algorithms that can be used to 
>>>> retrieve a resolution variant
>>>>    from a set of images. It can be DPI based, transform based, OS 
>>>> based and so on.
>>>>    The first part can be implemented without the second part.
>>>>
>>>>> The name "MultiResolutionImage" implies to me that this is a 
>>>>> sub-class of Image.
>>>>> But its not, its a way to get images. 
>>>>> AbstractMultiResolutionImage, however is
>>>>> a subclass and it implements the former.
>>>>
>>>>    Could you suggest the better name? It really needs to have an 
>>>> interface if existed image implementation
>>>>    is supposed to have resolution variants. The example which is 
>>>> used in JDK is ToolkitImage.
>>>>    Toolkit.getImage(filename) method returns ToolkitImage which is 
>>>> loaded by demand.
>>>>    LWCToolkit should return an image with resolution variants on 
>>>> Mac OS X if both image and  image at 2x
>>>>    are provided. What we need here is the  ToolkitImage that 
>>>> contains resolution  variants.
>>>>    It can be done if the MultiResolutionImage is an interface and 
>>>> it is not possible to do if MultiResolutionImage is a class.
>>>>    Here is the MultiResolutionToolkitImage implementation:
>>>> http://hg.openjdk.java.net/jdk9/client/jdk/file/b7ef5e2d252c/src/share/classes/sun/awt/image/MultiResolutionToolkitImage.java 
>>>>
>>>>
>>>>> I am supposing (since you don't explain) that you want an Image 
>>>>> sub-class here
>>>>> so that the app can specify it where ever an Image is currently 
>>>>> accepted by API
>>>>> and the API that is "aware" can accept it.
>>>>     If an image implements the MultiResolutionImage interface, 
>>>> SunGraphics2D can use it
>>>>     to draw an image with necessary resolution on HiDPI display.
>>>>
>>>>> I worry about the memory cost of all of this. Can the the 
>>>>> implementation be "lazy"?
>>>>     Yes. See the MultiResolutionCachedImage implementation:
>>>> http://hg.openjdk.java.net/jdk9/client/jdk/file/b7ef5e2d252c/src/share/classes/sun/awt/image/MultiResolutionCachedImage.java 
>>>>
>>>>> ie even if I call getResolutionVariants() do those images all have 
>>>>> to be fully initialised before
>>>>> they are used? It looks like the app probably has to do so ..
>>>>     If it needs to pass resolution variants to the native system 
>>>> like setting a custom cursor on Mac OS X
>>>>     it really needs to initialize all resolution variants.
>>>>
>>>>      If it needs to create one multi-resolution image based on 
>>>> another multi-resolution image like
>>>>      generating a lightening image using a filter, it possible to 
>>>> do this lazy.
>>>>      See the map(Function<Image, Image> mapper) method in the 
>>>> MultiResolutionCachedImage.
>>>>
>>>>    SunGraphics2D class uses only getResolutionVariant( ...) method 
>>>> to retrieve necessary resolution variant.
>>>>    It does not call getResolutionVariants() methods so all 
>>>> resolution variants are not created during image drawing.
>>>>
>>>>>
>>>>> Also it precludes being able to return "on demand" an image that 
>>>>> is rendered to
>>>>> be exactly the size requested. That could be created, drawn using 
>>>>> graphics primitives
>>>>> and created precisely and only if needed.
>>>>>
>>>>> Instead we have an API that requires you to apparentlty eagerly 
>>>>> create even the
>>>>> highest res image when you are on a device that has no need for it.
>>>>>
>>>>> Who will actually call getResolutionVariants() ? 
>>>>     Both.
>>>>> Is it us (the implementation) because we
>>>>     We use it to create an NSImage from a custom cursor. See 
>>>> Toolkit.createCustomCursor()
>>>>    and CImage.createFromImage(final Image image) methods.
>>>>
>>>>    Developers can use it to show all resolution variants in some 
>>>> image tool.
>>>>
>>>>> don't trust the app to make the right selection based on the 
>>>>> parameterised call
>>>>> getResolutionVariant() ?
>>>>    As it shown, the getResolutionVariant(...) and 
>>>> getResolutionVariants() methods are used
>>>>    for different purposes.
>>>>    getResolutionVariant(...) method is used by SunGraphics2D class 
>>>> to pickup an image
>>>>    with necessary resolution variant.
>>>>    getResolutionVariants() method is used when an application needs 
>>>> to use all resolution variants.
>>>>
>>>>>
>>>>> Which approach do we use to pick the image ? If its the former, 
>>>>> the app controls it,
>>>>     It is the former.
>>>>     We also use it MR-ToolkitImage to get a resolution variant 
>>>> according to the current system (for example, transforms
>>>>      are included to get resolution variant size on Mac OS X).
>>>>
>>>>> if its the latter its us. But which ?
>>>>>
>>>>> I am still stuck on the parameters to getResolutionVariant
>>>>>
>>>>>  * @param baseImageWidth the width of the base image.
>>>>>
>>>>>
>>>>> Isn't the base image always the smallest ? 
>>>>     No for general case. May be it would be possible to print a 
>>>> multi-resolution image
>>>>     on a printer that can have low DPI.
>>>>
>>>>> Why are we, the caller, supposed
>>>>> to say what that size to the class that has that image.
>>>>
>>>>    This question has already had long discussion. The answer is 
>>>> that we do it because it is free for us.
>>>>    SunGraphics2D already gets the base image size because it uses 
>>>> it for resolution image size calculation.
>>>>    If you have objections against this, let's remove the base image 
>>>> size parameters.
>>>>    Developer always can obtain this information calling 
>>>> getWidth()/Height() methods.
>>>>
>>>>> So I'd really like to see the example of that method in 
>>>>> CustomMultiResolutionImage
>>>>> filled out so we can see what is imagined here ..
>>>>
>>>>    Below are two samples.
>>>>    The first one loads a multi-resolution image from disk, and 
>>>> writes text "Hello World!" on it. Only getResolutionVariant(...) 
>>>> method is used
>>>>    by system in SunGraphics2D. The getResolutionVariants() method 
>>>> is not used.
>>>>
>>>>    The second one creates a lightened custom cursor. The 
>>>> getResolutionVariants() method is called by system to create 
>>>> NSImage with necessary image representations.
>>>>
>>>>    Note that Toolkit.getImage(filename) method is already able to 
>>>> load both image and image at 2x  images on Mac OS X.
>>>>
>>>>    Sample 1. Draw an image with "Hello World!" text:
>>>>        disk: duke.png, duke at 2x.png
>>>>    -------------------------------
>>>>     public static void main(String[] args) {
>>>>
>>>>         Image image = 
>>>> Toolkit.getDefaultToolkit().getImage("duke.png"); // duke.png and 
>>>> duke at 2x.png images are loaded by MR-ToolkitImage
>>>>
>>>>         Image imagewithText = image instanceof MultiResolutionImage
>>>>                 ? new TextMultiresolutionImage(image) : 
>>>> drawText(image);
>>>>
>>>>         Graphics2D g2d = // get graphics 2D
>>>>         g2d.drawImage(imagewithText, x, y, null);
>>>>     }
>>>>
>>>>     static Image drawText(Image image) {
>>>>         // return an image with "Hello World!" text
>>>>     }
>>>>
>>>>     static class TextMultiresolutionImage extends 
>>>> AbstractMultiResolutionImage {
>>>>
>>>>         private final Image baseImage;
>>>>
>>>>         public TextMultiresolutionImage(Image baseImage) {
>>>>             this.baseImage = baseImage;
>>>>         }
>>>>
>>>>         @Override
>>>>         public Image getResolutionVariant(float destImageWidth, 
>>>> float destImageHeight) {
>>>>             Image rvImage = ((MultiResolutionImage) baseImage).
>>>>                     getResolutionVariant(destImageWidth, 
>>>> destImageHeight);
>>>>             return drawText(rvImage);
>>>>         }
>>>>
>>>>         // this method is not used by SunGraphics2D to draw the image
>>>>         @Override
>>>>         public List<Image> getResolutionVariants() {
>>>>             List<Image> resolutionvariants = new LinkedList<>();
>>>>             for (Image image : ((MultiResolutionImage) baseImage).
>>>>                     getResolutionVariants()) {
>>>>                 resolutionvariants.add(drawText(image));
>>>>             }
>>>>             return resolutionvariants;
>>>>         }
>>>>
>>>>         @Override
>>>>         protected Image getBaseImage() {
>>>>             return drawText(baseImage);
>>>>         }
>>>>     }
>>>>    -------------------------------
>>>>
>>>>   Sample 2. Using filters to create a lightened  custom cursor.
>>>>    -------------------------------
>>>>     public static void main(String[] args) {
>>>>
>>>>         Image image = 
>>>> Toolkit.getDefaultToolkit().getImage("cursor.png"); // cursor.png 
>>>> and cursor at 2x.png files are provided
>>>>         Image lightenedImage = image instanceof MultiResolutionImage
>>>>                 ? new LigtenedMultiresolutionImage(image) : 
>>>> applyFilter(image);
>>>>
>>>>         Cursor lightenedCursor = Toolkit.getDefaultToolkit().
>>>>                 createCustomCursor(lightenedImage, new Point(0, 0), 
>>>> "Lightened Cursor");
>>>>         JFrame frame = new JFrame("Frame with lightened cursor");
>>>>         frame.setCursor(lightenedCursor);
>>>>     }
>>>>
>>>>     static Image applyFilter(Image image) {
>>>>         // apply a filter to create ligtened image
>>>>     }
>>>>
>>>>     static class LigtenedMultiresolutionImage extends 
>>>> AbstractMultiResolutionImage {
>>>>
>>>>         private final Image baseImage;
>>>>
>>>>         public LigtenedMultiresolutionImage(Image baseImage) {
>>>>             this.baseImage = baseImage;
>>>>         }
>>>>
>>>>         @Override
>>>>         public Image getResolutionVariant(float destImageWidth, 
>>>> float destImageHeight) {
>>>>             Image rvImage = ((MultiResolutionImage) baseImage).
>>>>                     getResolutionVariant(destImageWidth, 
>>>> destImageHeight);
>>>>             return applyFilter(rvImage);
>>>>         }
>>>>
>>>>         // all resolution variants are created to pass them to NSImage
>>>>         @Override
>>>>         public List<Image> getResolutionVariants() {
>>>>             List<Image> resolutionvariants = new LinkedList<>();
>>>>             for (Image image : ((MultiResolutionImage) baseImage).
>>>>                     getResolutionVariants()) {
>>>>                 resolutionvariants.add(applyFilter(image));
>>>>             }
>>>>             return resolutionvariants;
>>>>         }
>>>>
>>>>         @Override
>>>>         protected Image getBaseImage() {
>>>>             return applyFilter(baseImage);
>>>>         }
>>>>     }
>>>>    -------------------------------
>>>>>
>>>>> Based solely on the usage I see here, its not clear why 
>>>>> MultiResolutionImage needs
>>>>> to separately exist. what would implement MultiResolutionImage 
>>>>> except for
>>>>> a class that extends AbstractMultiResolutionImage  ? Where would 
>>>>> you use
>>>>> a straight implementation of MultiResolutionImage ?
>>>>     See sun.awt.image.MultiResolutionToolkitImage in JDK 9. Both 
>>>> ToolkitImage and MultiResolutionImage should be used in this case.
>>>>
>>>>>
>>>>> Actually I am not sure you answered Jim's question as to who is 
>>>>> requesting these APIs.
>>>>> "The AWT team" doesn't need them as they won't be writing the apps.
>>>>
>>>>   There was a long thread about the image with sub-pixel resolution 
>>>> drawing  on Mac OS X:
>>>> http://mail.openjdk.java.net/pipermail/macosx-port-dev/2013-April/005559.html 
>>>>
>>>>
>>>>  It was pointed out that Icon images that can be programmatically 
>>>> generated also need to have HiDPI support:
>>>> http://mail.openjdk.java.net/pipermail/macosx-port-dev/2013-April/005566.html 
>>>>
>>>> http://mail.openjdk.java.net/pipermail/macosx-port-dev/2013-April/005569.html 
>>>>
>>>>
>>>>  All requests about Mac OS X HiDPI support were included to the 
>>>> umbrella issue:
>>>>    7124410 [macosx] Lion HiDPI support
>>>> https://bugs.openjdk.java.net/browse/JDK-7124410
>>>>
>>>>>
>>>>> If the 99% use case will be to provide a way for apps to provide 
>>>>> images at custom sizes
>>>>> then we seem to be making them write new code. SFAIK FX found a 
>>>>> way to do something
>>>>> similar to what OS X and Windows do which is to load based on file
>>>>> name convention. 
>>>>       JDK 8 have already loaded images with @2x name convention on 
>>>> Mac OS X.
>>>>       See the fix for the issue JDK-8011059 [macosx] Support 
>>>> automatic @2x images loading on Mac OS X
>>>>        https://bugs.openjdk.java.net/browse/JDK-8011059
>>>>> If we can do that, we load just the one we need. Is the point
>>>>> of use so far removed from the loading logic that we can't do this ?
>>>>
>>>>     Mac OS X has both ways to create images: using @2x name 
>>>> convention for files
>>>>     and NSImage with methods 
>>>> addRepresentation/removeRepresentation/representations.
>>>>
>>>>     The current API is proposed to dial with images that can have 
>>>> source that is different  from files.
>>>>     It is also used to process already loaded images.
>>>>     See the provided two samples with lightened custom cursor and 
>>>> text on image.
>>>>     Is it possible to write the same samples on JavaFX?
>>>>
>>>>> And none of this seems to help anyone who calls new 
>>>>> BufferedImage(w, h, type) ..
>>>>
>>>>    Yes. It needs to create a BufferedImage for each screen 
>>>> resolution and put them to a multi-resolution image.
>>>>
>>>>>
>>>>> BTW I am not sold on the need for the RenderingHint. Where did the 
>>>>> idea come from ?
>>>>> It would affect all rendering using that graphics instance, not 
>>>>> just a specific image and
>>>>> if someone doesn't want a MultiRes image used, then maybe they 
>>>>> just don't provide one ..
>>>>
>>>>     KEY_RESOLUTION_VARIANT is used to switch on/off resolution 
>>>> variants usage.
>>>>     VALUE_RESOLUTION_VARIANT_ON - SunGraphics2D queries resolution 
>>>> variants from multi-resolution image on HiDPI displays.
>>>>     VALUE_RESOLUTION_VARIANT_OFF - SunGraphics2D does not use 
>>>> resolution variants. Only base image is used.
>>>>
>>>>> In any case, without a solid demonstrated need I would not add the 
>>>>> API.
>>>>>
>>>>     See provided 2 samples.
>>>>
>>>>   Thanks,
>>>>   Alexandr.
>>>>>
>>>>> -phil.
>>>>>
>>>>> On 6/4/2014 7:29 AM, Alexander Scherbatiy wrote:
>>>>>>
>>>>>>   Hi Phil,
>>>>>>
>>>>>>   Could you review the fix where only new MultiResolutionImage 
>>>>>> interface and AbstractMultiResolutionImage class are added:
>>>>>> http://cr.openjdk.java.net/~alexsch/8029339/webrev.05/
>>>>>>
>>>>>>   Thanks,
>>>>>>   Alexandr.
>>>>>>
>>>>>>
>>>>>> On 5/19/2014 2:46 PM, Alexander Scherbatiy wrote:
>>>>>>>
>>>>>>>   Hi Phil,
>>>>>>>
>>>>>>> On 5/16/2014 9:12 PM, Phil Race wrote:
>>>>>>>> I think Jim was looking at this. I am not sure if you yet 
>>>>>>>> answered all his questions/concerns.
>>>>>>>>
>>>>>>>> There's a lot of API here and it will take more time than I 
>>>>>>>> have right now just to get
>>>>>>>> my head around it so do not expect a quick answer.
>>>>>>>>
>>>>>>>> 1. Why is there no javadoc on the new API on Toolkit ?
>>>>>>>   It was decided to split the original issue on two parts:
>>>>>>>        - this fix adds only MultiResolutionImage interface and 
>>>>>>> AbstractMultiResolutionImage class.
>>>>>>>            Here is the webrev for it: 
>>>>>>> http://cr.openjdk.java.net/~alexsch/8029339/webrev.05/
>>>>>>>       - the Toolkit related API is moved to the separate issue
>>>>>>>
>>>>>>>   Could you review the current fix:
>>>>>>> http://cr.openjdk.java.net/~alexsch/8029339/webrev.05/
>>>>>>>
>>>>>>>> 2. What kinds of classes are expected to implement 
>>>>>>>> MultiResolutionImage
>>>>>>>> Application ones or platform ones ?
>>>>>>>     Both.
>>>>>>>     - Application: A developer can provide a set of images with 
>>>>>>> different resolutions to create a multi-resolution image. An 
>>>>>>> image with best-fitting resolution
>>>>>>>         will be drawn on HiDPI display.
>>>>>>>     - Platform: we used it to support Aqua L&F on HiDPI displays.
>>>>>>>
>>>>>>>> 3. can you better explain all these parameters :
>>>>>>>>
>>>>>>>>   49      * @param logicalDPIX the logical horizontal DPI of 
>>>>>>>> the desktop.
>>>>>>>>   50      * @param logicalDPIY the logical vertical DPI of the 
>>>>>>>> desktop.
>>>>>>>>   51      * @param baseImageWidth the width of the base image.
>>>>>>>>   52      * @param baseImageHeight the height of the base image.
>>>>>>>>   53      * @param destImageWidth the width of the destination 
>>>>>>>> image.
>>>>>>>>   54      * @param destImageHeight the height of the 
>>>>>>>> destination image.
>>>>>>>>   55      * @return image resolution variant.
>>>>>>>
>>>>>>>     Could we postpone it to the CCC request?
>>>>>>>
>>>>>>>>
>>>>>>>> 4.    public List<Image> getResolutionVariants();
>>>>>>>>
>>>>>>>> So this implies a fixed, known ahead of time set of images ?
>>>>>>>> Why is it required to have this API ? How will anyone be able to
>>>>>>>> tell which is which and use the list ?
>>>>>>>
>>>>>>>    Here are some usages from the JDK code:
>>>>>>>     - AquaImagefactory.getAppIconCompositedOn(final Image 
>>>>>>> background)
>>>>>>>        The original multi-resolution image is used to create 
>>>>>>> another multi-resolution image with the background
>>>>>>>     - AquaUtils.generateLightenedImage(Image image, ImageFilter 
>>>>>>> filter)
>>>>>>>       The original multi-resolution image is used to create 
>>>>>>> lightening multi-resolution image
>>>>>>>     - CImage.createFromImage(final Image image)
>>>>>>>         Resolution variants from a multi-resolution image are 
>>>>>>> used to create an NSImage
>>>>>>>     - CCustomCursor:  it is possible set a custom cursor which 
>>>>>>> contains resolution variants to the native system
>>>>>>>
>>>>>>>     Usually the getResolutionVariants() method is used to create 
>>>>>>> one multi-resolution image based on the another multi-resolution 
>>>>>>> image.
>>>>>>>
>>>>>>>> 5. Why is the rendering hint needed ?
>>>>>>>       Someone can manually switch off the multi-resolution image 
>>>>>>> drawing from graphics so only the base image will be drawn.
>>>>>>>       It is useful for the performance reason. There is a choice 
>>>>>>> to draw the high-resolution image slowly or the low-resolution 
>>>>>>> image faster.
>>>>>>>
>>>>>>>    Thanks,
>>>>>>>    Alexandr.
>>>>>>>> -phil.
>>>>>>>>
>>>>>>>>
>>>>>>>> On 5/16/2014 9:16 AM, Alexander Scherbatiy wrote:
>>>>>>>>>
>>>>>>>>>   Hi Phil,
>>>>>>>>>
>>>>>>>>>   I need a reviewer from the 2d group for the fix. Could you 
>>>>>>>>> take a look at the fix and review it?
>>>>>>>>>
>>>>>>>>>   Thanks,
>>>>>>>>>   Alexandr.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On 5/12/2014 6:35 PM, Alexander Scherbatiy wrote:
>>>>>>>>>>
>>>>>>>>>>   There was a long thread about the image with sub-pixel 
>>>>>>>>>> resolution drawing  on Mac OS X:
>>>>>>>>>> http://mail.openjdk.java.net/pipermail/macosx-port-dev/2013-April/005559.html 
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>  It was pointed out that Icon images that can be 
>>>>>>>>>> programmatically generated also need to have HiDPI support:
>>>>>>>>>> http://mail.openjdk.java.net/pipermail/macosx-port-dev/2013-April/005566.html 
>>>>>>>>>>
>>>>>>>>>> http://mail.openjdk.java.net/pipermail/macosx-port-dev/2013-April/005569.html 
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>  All requests about Mac OS X HiDPI support were included to 
>>>>>>>>>> the umbrella issue:
>>>>>>>>>>    7124410 [macosx] Lion HiDPI support
>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-7124410
>>>>>>>>>>
>>>>>>>>>>  Thanks,
>>>>>>>>>>  Alexandr.
>>>>>>>>>>
>>>>>>>>>> On 4/25/2014 6:45 PM, Alexander Scherbatiy wrote:
>>>>>>>>>>> On 4/25/2014 2:17 AM, Jim Graham wrote:
>>>>>>>>>>>> Hi Alexandr,
>>>>>>>>>>>>
>>>>>>>>>>>> I asked for who was requesting these facilities and you 
>>>>>>>>>>>> responded with the solution you are planning to provide.
>>>>>>>>>>>>
>>>>>>>>>>>> I don't care what the solution looks like if we have nobody 
>>>>>>>>>>>> asking for the feature - I am asking who is asking for 
>>>>>>>>>>>> these capabilities?
>>>>>>>>>>>
>>>>>>>>>>>    This is the request from the AWT team for the HiDPI support.
>>>>>>>>>>>
>>>>>>>>>>>    Thanks,
>>>>>>>>>>>    Alexandr.
>>>>>>>>>>>>
>>>>>>>>>>>>             ...jim
>>>>>>>>>>>>
>>>>>>>>>>>> On 4/4/14 4:53 AM, Alexander Scherbatiy wrote:
>>>>>>>>>>>>> On 4/3/2014 2:23 AM, Jim Graham wrote:
>>>>>>>>>>>>>> Hi Alexandr,
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> The back and forth is getting confusing here, so I 
>>>>>>>>>>>>>> thought I'd try to
>>>>>>>>>>>>>> summarize and start fresh(ish):
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> 1. We need to support @2x internally for MacOS 
>>>>>>>>>>>>>> compatibility (done).
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> 2. We will need to support _DPI images for Win-DPI 
>>>>>>>>>>>>>> compatibility (TBD).
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> 3. Customers may have their own collection of images to 
>>>>>>>>>>>>>> bundle
>>>>>>>>>>>>>> together into an MR image (working on that here). What is 
>>>>>>>>>>>>>> the push
>>>>>>>>>>>>>> for this?  Is this simply parity with Mac interfaces?
>>>>>>>>>>>>>
>>>>>>>>>>>>>          ----------
>>>>>>>>>>>>>          Image[] resolutionVariants = // get sorted by 
>>>>>>>>>>>>> sizes array of
>>>>>>>>>>>>> resolution variants;
>>>>>>>>>>>>>          Image mrImage =
>>>>>>>>>>>>> Toolkit.getDefaultToolkit().createMRImage(baseImageIndex,
>>>>>>>>>>>>> resolutionVariants);
>>>>>>>>>>>>>          ----------
>>>>>>>>>>>>>
>>>>>>>>>>>>>       Here is the proposed patch:
>>>>>>>>>>>>> http://cr.openjdk.java.net/~alexsch/8029339/webrev.04/
>>>>>>>>>>>>>
>>>>>>>>>>>>>> 4. Customers may want to synthetically generate images at 
>>>>>>>>>>>>>> arbitrary
>>>>>>>>>>>>>> resolutions (a variation that is impacting this 
>>>>>>>>>>>>>> solution). What is
>>>>>>>>>>>>>> the push for this?
>>>>>>>>>>>>>          ----------
>>>>>>>>>>>>>          Image mrImage =
>>>>>>>>>>>>> Toolkit.getDefaultToolkit().createMRImage(baseImageWidth, 
>>>>>>>>>>>>> baseImageHeight,
>>>>>>>>>>>>>                  new float[][]{{100, 100}, {150, 150}, 
>>>>>>>>>>>>> {200, 200}}, //
>>>>>>>>>>>>> resolution variants sizes
>>>>>>>>>>>>>                  (rvWidth, rvHeight) -> { /* generate a 
>>>>>>>>>>>>> resolution
>>>>>>>>>>>>> variant */  });
>>>>>>>>>>>>>         ----------
>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> 5. I'm guessing that customers might want to override the 
>>>>>>>>>>>>>> logic to
>>>>>>>>>>>>>> choose from among multiple resolutions. That came from me 
>>>>>>>>>>>>>> based on
>>>>>>>>>>>>>> seeing Mac and Win using different selection logic and 
>>>>>>>>>>>>>> our history of
>>>>>>>>>>>>>> developers split between those wanting cross-platform 
>>>>>>>>>>>>>> consistency and
>>>>>>>>>>>>>> those wanting consistency with native apps on each 
>>>>>>>>>>>>>> platform. Also,
>>>>>>>>>>>>>> the needs of an animator may differ from the needs of a
>>>>>>>>>>>>>> resolution-settable-document editor as to how dynamically 
>>>>>>>>>>>>>> the images
>>>>>>>>>>>>>> shift between resolution variants.
>>>>>>>>>>>>>         ----------
>>>>>>>>>>>>>          Image[] resolutionVariants = // get sorted by 
>>>>>>>>>>>>> sizes array of
>>>>>>>>>>>>> resolution variants;
>>>>>>>>>>>>>          Image mrImage = ImageResolutionHelper.createMRImage(
>>>>>>>>>>>>>                  (rvWidth, rvHeight, resolutionVariants) 
>>>>>>>>>>>>> -> { /*use a
>>>>>>>>>>>>> custom logic to choose a resolution variant from an array 
>>>>>>>>>>>>> of images*/},
>>>>>>>>>>>>>                  (logicalDPI, baseImageSize, 
>>>>>>>>>>>>> destImageSize) ->
>>>>>>>>>>>>> destImageSize, // calculate the custom aware resolution 
>>>>>>>>>>>>> variant size
>>>>>>>>>>>>>                  baseImageIndex, resolutionVariants);
>>>>>>>>>>>>>         ----------
>>>>>>>>>>>>>
>>>>>>>>>>>>>     or just extend the CustomMultiResolutionImage which 
>>>>>>>>>>>>> has Image as the
>>>>>>>>>>>>> parent class:
>>>>>>>>>>>>>
>>>>>>>>>>>>> --------------------
>>>>>>>>>>>>>   public class CustomMultiResolutionImage extends
>>>>>>>>>>>>> AbstractMultiResolutionImage {
>>>>>>>>>>>>>
>>>>>>>>>>>>>      @Override
>>>>>>>>>>>>>      public Image getResolutionVariant(float logicalDPIX, 
>>>>>>>>>>>>> float
>>>>>>>>>>>>> logicalDPIY,
>>>>>>>>>>>>>              float baseImageWidth, float baseImageHeight,
>>>>>>>>>>>>>              float destImageWidth, float destImageHeight) {
>>>>>>>>>>>>>          // return a resolution variant based on the given 
>>>>>>>>>>>>> logical DPI,
>>>>>>>>>>>>>          // base image size, or destination image size
>>>>>>>>>>>>>      }
>>>>>>>>>>>>>
>>>>>>>>>>>>>      @Override
>>>>>>>>>>>>>      public List<Image> getResolutionVariants() {
>>>>>>>>>>>>>          // return a list of resolution variants
>>>>>>>>>>>>>      }
>>>>>>>>>>>>>
>>>>>>>>>>>>>      @Override
>>>>>>>>>>>>>      protected Image getBaseImage() {
>>>>>>>>>>>>>          // return the base image
>>>>>>>>>>>>>      }
>>>>>>>>>>>>> }
>>>>>>>>>>>>> --------------------
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Is that a fair summary of all of the considerations so 
>>>>>>>>>>>>>> far, or did I
>>>>>>>>>>>>>> miss something?
>>>>>>>>>>>>>     I think it should cover the main needs.
>>>>>>>>>>>>>
>>>>>>>>>>>>>      Thanks,
>>>>>>>>>>>>>      Alexandr.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>             ...jim
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On 3/27/14 7:43 AM, Alexander Scherbatiy wrote:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>   Below are some thoughts about TK.createMRImage(...) 
>>>>>>>>>>>>>>> method
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> On 3/24/2014 4:52 PM, Alexander Scherbatiy wrote:
>>>>>>>>>>>>>>>> Hello,
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>   Could you review the updated fix:
>>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~alexsch/8029339/webrev.03/
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>   - baseImageWidth/Height arguments are added to the
>>>>>>>>>>>>>>>> getResolutionVariant(...) method
>>>>>>>>>>>>>>>>   - dest image sizes are reverted to included DPI scale
>>>>>>>>>>>>>>>>   - AbstractMultiResolutionImage is added. It needs 
>>>>>>>>>>>>>>>> only to implement
>>>>>>>>>>>>>>>> only 3 methods from the AbstractMultiResolutionImage class
>>>>>>>>>>>>>>>>     to create a custom multi-resolution image. For 
>>>>>>>>>>>>>>>> example:
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> On 3/22/2014 3:57 AM, Jim Graham wrote:
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Your code example below can be expressed as an 
>>>>>>>>>>>>>>>>> implementation of the
>>>>>>>>>>>>>>>>> single-method, lambda-compatible interface that 
>>>>>>>>>>>>>>>>> expresses just the
>>>>>>>>>>>>>>>>> getRV() method. They could easily do:
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> final Image baseImage = ...;
>>>>>>>>>>>>>>>>> TK.createMRImage(new RVInterface() {
>>>>>>>>>>>>>>>>>     public Image getRV(...) {
>>>>>>>>>>>>>>>>>         // calculate rvWidth and rvHeight
>>>>>>>>>>>>>>>>>         // look up rvWidth/rvHeight in a database of 
>>>>>>>>>>>>>>>>> images
>>>>>>>>>>>>>>>>>         // possibly contruct a new image
>>>>>>>>>>>>>>>>>         return rvImage;
>>>>>>>>>>>>>>>>>     }
>>>>>>>>>>>>>>>>> }, baseImage);
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>       The RVInterface mixes the logic that construct an 
>>>>>>>>>>>>>>> image and
>>>>>>>>>>>>>>> chooses the necessary resolution variant.
>>>>>>>>>>>>>>>       It is ok if a developer always implements this 
>>>>>>>>>>>>>>> interface. If it
>>>>>>>>>>>>>>> needs to have DPI/Transform/Platform aware RVInterface 
>>>>>>>>>>>>>>> the image
>>>>>>>>>>>>>>> construction logic should be separated.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>      Does  TK.createMRImage() method implies that 
>>>>>>>>>>>>>>> Platform aware logic
>>>>>>>>>>>>>>> should be used for a resolution-variant choosing?
>>>>>>>>>>>>>>>      If so, may be general createMRImage() can be placed 
>>>>>>>>>>>>>>> in the
>>>>>>>>>>>>>>> ImageResolutionHelper.
>>>>>>>>>>>>>>>>> The main issue I see is if you might want the newly 
>>>>>>>>>>>>>>>>> constructed
>>>>>>>>>>>>>>>>> variants to appear in the List returned from the 
>>>>>>>>>>>>>>>>> getVariants()
>>>>>>>>>>>>>>>>> method.  I'm not sure what value that would have 
>>>>>>>>>>>>>>>>> beyond simply
>>>>>>>>>>>>>>>>> returning the base media that the object uses from 
>>>>>>>>>>>>>>>>> which to construct
>>>>>>>>>>>>>>>>> its variants...?
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>    It can be solved by using something like array of 
>>>>>>>>>>>>>>> image sizes or
>>>>>>>>>>>>>>> other seeds and a mapper that can create an image from 
>>>>>>>>>>>>>>> the given seed.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>   It can look like:
>>>>>>>>>>>>>>> -------------------------
>>>>>>>>>>>>>>> public class ImageResolutionHelper {
>>>>>>>>>>>>>>>      public interface RVChooser {
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>          public Image getRV(
>>>>>>>>>>>>>>>                  float logicalDPIX, float logicalDPIY,
>>>>>>>>>>>>>>>                  float baseImageWidth, float 
>>>>>>>>>>>>>>> baseImageHeight,
>>>>>>>>>>>>>>>                  float destImageWidth, float 
>>>>>>>>>>>>>>> destImageHeight,
>>>>>>>>>>>>>>>                  final Image... resolutionVariants);
>>>>>>>>>>>>>>>      }
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>      public static final RVChooser DPI_AWARE = ...;
>>>>>>>>>>>>>>>      public static final RVChooser TRANSFORM_AWARE = ...;
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>      // resolutionVariants is an array of sorted by 
>>>>>>>>>>>>>>> width/height images
>>>>>>>>>>>>>>>      static Image createMRImage(final RVChooser rvChooser,
>>>>>>>>>>>>>>>              final int baseImageIndex, final Image...
>>>>>>>>>>>>>>> resolutionVariants) { ... }
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>      // sorted by width/height images should be 
>>>>>>>>>>>>>>> generated from seeds
>>>>>>>>>>>>>>>      static <Type> Image createMRImage(final RVChooser 
>>>>>>>>>>>>>>> rvChooser,
>>>>>>>>>>>>>>>              final Type baseImageSeed, final 
>>>>>>>>>>>>>>> Function<Type, Image>
>>>>>>>>>>>>>>> mapper, final Type... rvSeeds) {...}
>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> public abstract class Toolkit {
>>>>>>>>>>>>>>>      public abstract Image createMRImage(int 
>>>>>>>>>>>>>>> baseImageIndex, Image...
>>>>>>>>>>>>>>> resolutionVariants); // Platform aware rv chooser is used
>>>>>>>>>>>>>>>      public abstract RVChooser getPlatformRVChooser() ;
>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>> --------------------------
>>>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>>>> Alexandr.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>      I think it is better to provide both the 
>>>>>>>>>>>>>>>>>> MultiResolutionImage
>>>>>>>>>>>>>>>>>> and
>>>>>>>>>>>>>>>>>> its implementation based on the given resolution 
>>>>>>>>>>>>>>>>>> variants array.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> It occurs to me that even if we don't go with a 
>>>>>>>>>>>>>>>>> lambda-factory-based
>>>>>>>>>>>>>>>>> approach like what I'm describing, it might make sense 
>>>>>>>>>>>>>>>>> to provide a
>>>>>>>>>>>>>>>>> baseMR implementation that they can subclass to keep 
>>>>>>>>>>>>>>>>> them from trying
>>>>>>>>>>>>>>>>> to subclass off of BufferedImage instead. I really 
>>>>>>>>>>>>>>>>> would like to
>>>>>>>>>>>>>>>>> avoid "custom MR images are subclasses of BufImg" if 
>>>>>>>>>>>>>>>>> we can as I
>>>>>>>>>>>>>>>>> think the mix of concepts is a little jarring...
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>             ...jim
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>     The implementation could look like:
>>>>>>>>>>>>>>>>>> ---------------------------------
>>>>>>>>>>>>>>>>>> public class CustomMultiResolutionImage extends Image 
>>>>>>>>>>>>>>>>>> implements
>>>>>>>>>>>>>>>>>> MultiResolutionImage {
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>      int baseImageIndex;
>>>>>>>>>>>>>>>>>>      Image[] resolutionVariants;
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>      public CustomMultiResolutionImage(int 
>>>>>>>>>>>>>>>>>> baseImageIndex,
>>>>>>>>>>>>>>>>>>              Image... resolutionVariants) {
>>>>>>>>>>>>>>>>>>          this.baseImageIndex = baseImageIndex;
>>>>>>>>>>>>>>>>>>          this.resolutionVariants = resolutionVariants;
>>>>>>>>>>>>>>>>>>      }
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>      @Override
>>>>>>>>>>>>>>>>>>      public int getWidth(ImageObserver observer) {
>>>>>>>>>>>>>>>>>>          return getBaseImage().getWidth(null);
>>>>>>>>>>>>>>>>>>      }
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>      @Override
>>>>>>>>>>>>>>>>>>      public int getHeight(ImageObserver observer) {
>>>>>>>>>>>>>>>>>>          return getBaseImage().getHeight(null);
>>>>>>>>>>>>>>>>>>      }
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>      @Override
>>>>>>>>>>>>>>>>>>      public ImageProducer getSource() {
>>>>>>>>>>>>>>>>>>          return getBaseImage().getSource();
>>>>>>>>>>>>>>>>>>      }
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>      @Override
>>>>>>>>>>>>>>>>>>      public Graphics getGraphics() {
>>>>>>>>>>>>>>>>>>          return getBaseImage().getGraphics();
>>>>>>>>>>>>>>>>>>      }
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>      @Override
>>>>>>>>>>>>>>>>>>      public Object getProperty(String name, 
>>>>>>>>>>>>>>>>>> ImageObserver observer) {
>>>>>>>>>>>>>>>>>>          return getBaseImage().getProperty(name, 
>>>>>>>>>>>>>>>>>> observer);
>>>>>>>>>>>>>>>>>>      }
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>      @Override
>>>>>>>>>>>>>>>>>>      public Image getResolutionVariant(float 
>>>>>>>>>>>>>>>>>> logicalDPIX, float
>>>>>>>>>>>>>>>>>> logicalDPIY,
>>>>>>>>>>>>>>>>>>              float destinationImageWidth, float
>>>>>>>>>>>>>>>>>> destinationImageHeight) {
>>>>>>>>>>>>>>>>>>              // calculate resolution variant 
>>>>>>>>>>>>>>>>>> width/height
>>>>>>>>>>>>>>>>>>          return getResolutionVariant(rvWidth, rvHeight);
>>>>>>>>>>>>>>>>>>      }
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>      @Override
>>>>>>>>>>>>>>>>>>      public List<Image> getResolutionVariants() {
>>>>>>>>>>>>>>>>>>          return Arrays.asList(resolutionVariants);
>>>>>>>>>>>>>>>>>>      }
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>      private Image getResolutionVariant(float 
>>>>>>>>>>>>>>>>>> rvWidth, float
>>>>>>>>>>>>>>>>>> rvHeight) {
>>>>>>>>>>>>>>>>>>          // return a resolution variant based on the 
>>>>>>>>>>>>>>>>>> given width and
>>>>>>>>>>>>>>>>>> height
>>>>>>>>>>>>>>>>>>      }
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>      private Image getBaseImage() {
>>>>>>>>>>>>>>>>>>          return resolutionVariants[baseImageIndex];
>>>>>>>>>>>>>>>>>>      }
>>>>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>>>> ---------------------------------
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>    Thanks,
>>>>>>>>>>>>>>>>>>    Alexandr.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Then we provide one of these from 
>>>>>>>>>>>>>>>>>>> TK.get/createImage() when the
>>>>>>>>>>>>>>>>>>> platform detects @2x, or Win8-style variants.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> For custom images we provide TK.createMRImage(lambda 
>>>>>>>>>>>>>>>>>>> getRV, Image
>>>>>>>>>>>>>>>>>>> variants...) and TK.createMRImage(Image variants...);
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Since the get<List> method is just bookkeeping, I 
>>>>>>>>>>>>>>>>>>> don't see them
>>>>>>>>>>>>>>>>>>> needing to override it, so the getRV() method is 
>>>>>>>>>>>>>>>>>>> really the only
>>>>>>>>>>>>>>>>>>> thing
>>>>>>>>>>>>>>>>>>> they might want to override, and we can tie into the 
>>>>>>>>>>>>>>>>>>> new Lambda
>>>>>>>>>>>>>>>>>>> capabilities by making a single-method interface for 
>>>>>>>>>>>>>>>>>>> it that they
>>>>>>>>>>>>>>>>>>> supply in a factory method.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> I realize that the interface you created is more 
>>>>>>>>>>>>>>>>>>> fundamentally
>>>>>>>>>>>>>>>>>>> OO, but
>>>>>>>>>>>>>>>>>>> the Image class has always been special in this 
>>>>>>>>>>>>>>>>>>> regard in the AWT
>>>>>>>>>>>>>>>>>>> ecosystem (in so far as we do not support someone 
>>>>>>>>>>>>>>>>>>> implementing their
>>>>>>>>>>>>>>>>>>> own Image subclass even though it is technically 
>>>>>>>>>>>>>>>>>>> possible).
>>>>>>>>>>>>>>>>>>> Because of
>>>>>>>>>>>>>>>>>>> this special nature of Image, we end up with the 
>>>>>>>>>>>>>>>>>>> situation that if
>>>>>>>>>>>>>>>>>>> someone were given a need to create a subclass of 
>>>>>>>>>>>>>>>>>>> Image, then they
>>>>>>>>>>>>>>>>>>> would turn to BufImg as their superclass even though 
>>>>>>>>>>>>>>>>>>> BufImg is
>>>>>>>>>>>>>>>>>>> essentially an implementation-specific leaf node on 
>>>>>>>>>>>>>>>>>>> the Image class
>>>>>>>>>>>>>>>>>>> hierarchy.  This approach with a factory method to 
>>>>>>>>>>>>>>>>>>> create an
>>>>>>>>>>>>>>>>>>> internal
>>>>>>>>>>>>>>>>>>> subclass of the new MRI class mirrors the existing 
>>>>>>>>>>>>>>>>>>> cases of Image
>>>>>>>>>>>>>>>>>>> objects that come from factories as well.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Thoughts?
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>             ...jim
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> On 3/20/14 7:52 AM, Alexander Scherbatiy wrote:
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>    Hello,
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>    Could you review the updated version of the fix:
>>>>>>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~alexsch/8029339/webrev.01/
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>   - The "getResolutionVariant(int width, int 
>>>>>>>>>>>>>>>>>>>> height)" method from
>>>>>>>>>>>>>>>>>>>> MultiResolutionImage class is changed to
>>>>>>>>>>>>>>>>>>>>     Image getResolutionVariant(float logicalDPIX, 
>>>>>>>>>>>>>>>>>>>> float
>>>>>>>>>>>>>>>>>>>> logicalDPIY,
>>>>>>>>>>>>>>>>>>>> float width, float height, AffineTransform transform);
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>   - sun.awt.image.ImageResolutionHelper class is 
>>>>>>>>>>>>>>>>>>>> added. The
>>>>>>>>>>>>>>>>>>>> sun.awt.image.MultiResolutionToolkitImage and
>>>>>>>>>>>>>>>>>>>> sun.awt.image.MultiResolutionBufferedImage classes 
>>>>>>>>>>>>>>>>>>>> are used
>>>>>>>>>>>>>>>>>>>> PLATFORM ImageResolutionHelper.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>   The  MultiResolutionImage interface 
>>>>>>>>>>>>>>>>>>>> implementation could look
>>>>>>>>>>>>>>>>>>>> like:
>>>>>>>>>>>>>>>>>>>> ------------------------------
>>>>>>>>>>>>>>>>>>>> public class CustomMultiResolutionImage extends 
>>>>>>>>>>>>>>>>>>>> BufferedImage
>>>>>>>>>>>>>>>>>>>> implements
>>>>>>>>>>>>>>>>>>>> MultiResolutionImage {
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>      private final Image[] resolutionVariants;
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>      public CustomMultiResolutionImage(int 
>>>>>>>>>>>>>>>>>>>> baseIndex, Image...
>>>>>>>>>>>>>>>>>>>> images) {
>>>>>>>>>>>>>>>>>>>> super(images[baseIndex].getWidth(null),
>>>>>>>>>>>>>>>>>>>> images[baseIndex].getHeight(null),
>>>>>>>>>>>>>>>>>>>> BufferedImage.TYPE_INT_RGB);
>>>>>>>>>>>>>>>>>>>> this.resolutionVariants = images;
>>>>>>>>>>>>>>>>>>>>          Graphics g = getGraphics();
>>>>>>>>>>>>>>>>>>>> g.drawImage(images[baseIndex], 0, 0, null);
>>>>>>>>>>>>>>>>>>>>          g.dispose();
>>>>>>>>>>>>>>>>>>>>      }
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>      @Override
>>>>>>>>>>>>>>>>>>>>      public Image getResolutionVariant(float 
>>>>>>>>>>>>>>>>>>>> logicalDPIX, float
>>>>>>>>>>>>>>>>>>>> logicalDPIY,
>>>>>>>>>>>>>>>>>>>>              float width, float height, 
>>>>>>>>>>>>>>>>>>>> AffineTransform
>>>>>>>>>>>>>>>>>>>> transform) {
>>>>>>>>>>>>>>>>>>>>          return getResolutionVariant(logicalDPIX * 
>>>>>>>>>>>>>>>>>>>> width,
>>>>>>>>>>>>>>>>>>>> logicalDPIY *
>>>>>>>>>>>>>>>>>>>> height);
>>>>>>>>>>>>>>>>>>>>      }
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>      @Override
>>>>>>>>>>>>>>>>>>>>      public List<Image> getResolutionVariants() {
>>>>>>>>>>>>>>>>>>>>          return Arrays.asList(resolutionVariants);
>>>>>>>>>>>>>>>>>>>>      }
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>      public Image getResolutionVariant(double 
>>>>>>>>>>>>>>>>>>>> width, double
>>>>>>>>>>>>>>>>>>>> height) {
>>>>>>>>>>>>>>>>>>>>          for (Image image : resolutionVariants) {
>>>>>>>>>>>>>>>>>>>>              if (width <= image.getWidth(null) && 
>>>>>>>>>>>>>>>>>>>> height <=
>>>>>>>>>>>>>>>>>>>> image.getHeight(null)) {
>>>>>>>>>>>>>>>>>>>>                  return image;
>>>>>>>>>>>>>>>>>>>>              }
>>>>>>>>>>>>>>>>>>>>          }
>>>>>>>>>>>>>>>>>>>>          return this;
>>>>>>>>>>>>>>>>>>>>      }
>>>>>>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>>>>>> ------------------------------
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>    Thanks,
>>>>>>>>>>>>>>>>>>>>    Alexandr.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> On 2/27/2014 4:54 PM, Alexander Scherbatiy wrote:
>>>>>>>>>>>>>>>>>>>>> On 2/22/2014 3:54 AM, Jim Graham wrote:
>>>>>>>>>>>>>>>>>>>>>> Hi Alexandr,
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> On 2/18/14 7:33 AM, Alexander Scherbatiy wrote:
>>>>>>>>>>>>>>>>>>>>>>> Hi Jim,
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>   Let's divide the discussion into two part.
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>   1. Where it is better to hold resolution 
>>>>>>>>>>>>>>>>>>>>>>> variants?
>>>>>>>>>>>>>>>>>>>>>>>      Putting resolution variants in Image class 
>>>>>>>>>>>>>>>>>>>>>>> brings some
>>>>>>>>>>>>>>>>>>>>>>> questions like:
>>>>>>>>>>>>>>>>>>>>>>>    - Some type of images do not need to have 
>>>>>>>>>>>>>>>>>>>>>>> resolution variants
>>>>>>>>>>>>>>>>>>>>>>>    - Should resolution variants have the same 
>>>>>>>>>>>>>>>>>>>>>>> type as the base
>>>>>>>>>>>>>>>>>>>>>>> image?
>>>>>>>>>>>>>>>>>>>>>>>    - getResolutionVariants() method can return 
>>>>>>>>>>>>>>>>>>>>>>> copy of the
>>>>>>>>>>>>>>>>>>>>>>> original
>>>>>>>>>>>>>>>>>>>>>>> list
>>>>>>>>>>>>>>>>>>>>>>> so add/removeRV methods should be also added.
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>    There are pros and cons for placing 
>>>>>>>>>>>>>>>>>>>>>>> resolution variants to
>>>>>>>>>>>>>>>>>>>>>>> Image
>>>>>>>>>>>>>>>>>>>>>>> class or to a separate intreface.
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> I agree that this could be a separate interface. 
>>>>>>>>>>>>>>>>>>>>>> In my examples
>>>>>>>>>>>>>>>>>>>>>> below I was just sticking them inside an 
>>>>>>>>>>>>>>>>>>>>>> "Image{}" to show where
>>>>>>>>>>>>>>>>>>>>>> they
>>>>>>>>>>>>>>>>>>>>>> lived in the set of involved objects, not a specific
>>>>>>>>>>>>>>>>>>>>>> recommendation
>>>>>>>>>>>>>>>>>>>>>> that they actually be new methods on the base 
>>>>>>>>>>>>>>>>>>>>>> class itself. I
>>>>>>>>>>>>>>>>>>>>>> probably should have put a comment there about that.
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> With respect to add/remove - that is assuming a 
>>>>>>>>>>>>>>>>>>>>>> need for manual
>>>>>>>>>>>>>>>>>>>>>> construction of an image set, right? Forgive me 
>>>>>>>>>>>>>>>>>>>>>> if I'm
>>>>>>>>>>>>>>>>>>>>>> forgetting
>>>>>>>>>>>>>>>>>>>>>> something, but I seem to recall that manual 
>>>>>>>>>>>>>>>>>>>>>> Multi-Res images was
>>>>>>>>>>>>>>>>>>>>>> proposed as a way for developers to introduce @2x 
>>>>>>>>>>>>>>>>>>>>>> support
>>>>>>>>>>>>>>>>>>>>>> themselves,
>>>>>>>>>>>>>>>>>>>>>> but if we are internally managing @2x and -DPI 
>>>>>>>>>>>>>>>>>>>>>> variants for them,
>>>>>>>>>>>>>>>>>>>>>> then I'm not sure if there is actual developer 
>>>>>>>>>>>>>>>>>>>>>> need to manually
>>>>>>>>>>>>>>>>>>>>>> construct their own.  Am I forgetting something?
>>>>>>>>>>>>>>>>>>>>>    The NSImage has 
>>>>>>>>>>>>>>>>>>>>> addRepresentation/removeRepresentation
>>>>>>>>>>>>>>>>>>>>> methods to
>>>>>>>>>>>>>>>>>>>>> work with image representations on Mac OS X.
>>>>>>>>>>>>>>>>>>>>>    The java.awt.Image class should provide similar
>>>>>>>>>>>>>>>>>>>>> functionality to
>>>>>>>>>>>>>>>>>>>>> have the possibilities as Cocoa on HiDPI displays.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> 2. Using scale factor/image sizes/scaled image 
>>>>>>>>>>>>>>>>>>>>>>> sizes to
>>>>>>>>>>>>>>>>>>>>>>> retreive a
>>>>>>>>>>>>>>>>>>>>>>> resolution variant.
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>    May be it is better to have a structure that 
>>>>>>>>>>>>>>>>>>>>>>> provide all
>>>>>>>>>>>>>>>>>>>>>>> necessary
>>>>>>>>>>>>>>>>>>>>>>> information  to query the resolution variant: 
>>>>>>>>>>>>>>>>>>>>>>> scale factor,
>>>>>>>>>>>>>>>>>>>>>>> draw area
>>>>>>>>>>>>>>>>>>>>>>> width/height, transformed area width/height?
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>    For example:
>>>>>>>>>>>>>>>>>>>>>>> ---------------------
>>>>>>>>>>>>>>>>>>>>>>>      public interface MultiResolutionImage {
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>          interface DrawAreaInfo {
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>              float getScaleFactor();
>>>>>>>>>>>>>>>>>>>>>>>              float getAreaWidth();
>>>>>>>>>>>>>>>>>>>>>>>              float getAreaHeight();
>>>>>>>>>>>>>>>>>>>>>>>              float getTransformedAreaWidth();
>>>>>>>>>>>>>>>>>>>>>>>              float getTransformedAreaHeight();
>>>>>>>>>>>>>>>>>>>>>>>          }
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>          public Image 
>>>>>>>>>>>>>>>>>>>>>>> getResolutionVariant(DrawAreaInfo
>>>>>>>>>>>>>>>>>>>>>>> drawAreaInfo) ;
>>>>>>>>>>>>>>>>>>>>>>>          public List<Image> 
>>>>>>>>>>>>>>>>>>>>>>> getResolutionVariants();
>>>>>>>>>>>>>>>>>>>>>>>      }
>>>>>>>>>>>>>>>>>>>>>>> ---------------------
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> The problem with a constructor is that this is 
>>>>>>>>>>>>>>>>>>>>>> something that is
>>>>>>>>>>>>>>>>>>>>>> (potentially) done on every drawImage() call, 
>>>>>>>>>>>>>>>>>>>>>> which means we are
>>>>>>>>>>>>>>>>>>>>>> inviting GC into the equation. If we can come up 
>>>>>>>>>>>>>>>>>>>>>> with a simple
>>>>>>>>>>>>>>>>>>>>>> "just
>>>>>>>>>>>>>>>>>>>>>> a couple/3/4 numbers" way to embed that data into 
>>>>>>>>>>>>>>>>>>>>>> a method call
>>>>>>>>>>>>>>>>>>>>>> argument list then we can make this lighter weight.
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> What about simply having floating point (double) 
>>>>>>>>>>>>>>>>>>>>>> dimensions on
>>>>>>>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>>>>>> rendered size
>>>>>>>>>>>>>>>>>>>>>       There should be a way to choose a resolution 
>>>>>>>>>>>>>>>>>>>>> variant
>>>>>>>>>>>>>>>>>>>>> based on
>>>>>>>>>>>>>>>>>>>>> requested drawing size or transformed drawing size.
>>>>>>>>>>>>>>>>>>>>>       At least a current transformation should be 
>>>>>>>>>>>>>>>>>>>>> included too.
>>>>>>>>>>>>>>>>>>>>>> plus a single floating point "logical DPI" for 
>>>>>>>>>>>>>>>>>>>>>> the screen?
>>>>>>>>>>>>>>>>>>>>>      There is the ID2D1Factory::GetDesktopDpi 
>>>>>>>>>>>>>>>>>>>>> method which returns
>>>>>>>>>>>>>>>>>>>>> dpiX and dpiY.
>>>>>>>>>>>>>>>>>>>>> http://msdn.microsoft.com/en-us/library/windows/apps/dd371316 
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>     That means that logicalDPIX/Y can have 
>>>>>>>>>>>>>>>>>>>>> different values.
>>>>>>>>>>>>>>>>>>>>>      At least it is described in the
>>>>>>>>>>>>>>>>>>>>> http://msdn.microsoft.com/en-us/library/windows/apps/ff684173 
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>      "To get the DPI setting, call the 
>>>>>>>>>>>>>>>>>>>>> ID2D1Factory::GetDesktopDpi
>>>>>>>>>>>>>>>>>>>>> method. The DPI is returned as two floating-point 
>>>>>>>>>>>>>>>>>>>>> values, one for
>>>>>>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>>>>> x-axis and one for the y-axis. In theory, these 
>>>>>>>>>>>>>>>>>>>>> values can differ.
>>>>>>>>>>>>>>>>>>>>> Calculate a separate scaling factor for each axis."
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>   The getResolutionVariant method could look like:
>>>>>>>>>>>>>>>>>>>>> --------------------------------------
>>>>>>>>>>>>>>>>>>>>>     public Image getResolutionVariant(float 
>>>>>>>>>>>>>>>>>>>>> logicalDPIX, float
>>>>>>>>>>>>>>>>>>>>> logicalDPIY,
>>>>>>>>>>>>>>>>>>>>>             float widthX, float widthY, 
>>>>>>>>>>>>>>>>>>>>> AffineTransform
>>>>>>>>>>>>>>>>>>>>> transform);
>>>>>>>>>>>>>>>>>>>>> --------------------------------------
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>  If the image is known (either passed as an 
>>>>>>>>>>>>>>>>>>>>>> argument or the
>>>>>>>>>>>>>>>>>>>>>> method is
>>>>>>>>>>>>>>>>>>>>>> called on the image), then it can provide the 
>>>>>>>>>>>>>>>>>>>>>> original WH.
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> The MultiResolutionImage default implementation 
>>>>>>>>>>>>>>>>>>>>>>> could allow
>>>>>>>>>>>>>>>>>>>>>>> to use
>>>>>>>>>>>>>>>>>>>>>>> different strategies like scale 
>>>>>>>>>>>>>>>>>>>>>>> factor/transfom/OS based
>>>>>>>>>>>>>>>>>>>>>>>    to query a resolution variant. The OS based 
>>>>>>>>>>>>>>>>>>>>>>> strategy can be
>>>>>>>>>>>>>>>>>>>>>>> used by
>>>>>>>>>>>>>>>>>>>>>>> default.
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> For Mac policy, all we need is the transformed 
>>>>>>>>>>>>>>>>>>>>>> dimensions, which
>>>>>>>>>>>>>>>>>>>>>> can
>>>>>>>>>>>>>>>>>>>>>> be passed in as FP for generality. For Windows 
>>>>>>>>>>>>>>>>>>>>>> policy, all we
>>>>>>>>>>>>>>>>>>>>>> need
>>>>>>>>>>>>>>>>>>>>>> is logical DPI for the screen. What other 
>>>>>>>>>>>>>>>>>>>>>> information would we
>>>>>>>>>>>>>>>>>>>>>> need, or would an algorithm like to use, that 
>>>>>>>>>>>>>>>>>>>>>> can't be computed
>>>>>>>>>>>>>>>>>>>>>> from
>>>>>>>>>>>>>>>>>>>>>> those 2 pieces?
>>>>>>>>>>>>>>>>>>>>>      The aim is to provide a base class that can 
>>>>>>>>>>>>>>>>>>>>> be used to
>>>>>>>>>>>>>>>>>>>>> create a
>>>>>>>>>>>>>>>>>>>>> MultiResolutionImage like:
>>>>>>>>>>>>>>>>>>>>> http://hg.openjdk.java.net/jdk9/client/jdk/diff/ae53ebce5fa3/src/share/classes/sun/awt/image/MultiResolutionBufferedImage.java 
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>      A developer should be able to implement a 
>>>>>>>>>>>>>>>>>>>>> custom algorithm to
>>>>>>>>>>>>>>>>>>>>> query a resolution variant.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>     It can be done by overriding the 
>>>>>>>>>>>>>>>>>>>>> getResolutionVariant image:
>>>>>>>>>>>>>>>>>>>>>    -----------------------
>>>>>>>>>>>>>>>>>>>>>         Image mrImage = new 
>>>>>>>>>>>>>>>>>>>>> MultiResolutionBufferedImage(){
>>>>>>>>>>>>>>>>>>>>>             @Override
>>>>>>>>>>>>>>>>>>>>>             public Image getResolutionVariant(...) {
>>>>>>>>>>>>>>>>>>>>>                 // Custom logic here
>>>>>>>>>>>>>>>>>>>>>             }
>>>>>>>>>>>>>>>>>>>>>         };
>>>>>>>>>>>>>>>>>>>>>    -----------------------
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>    Or it can be done by using resolution variant 
>>>>>>>>>>>>>>>>>>>>> choosers so a
>>>>>>>>>>>>>>>>>>>>> developer can implement custom resolution variant 
>>>>>>>>>>>>>>>>>>>>> query:
>>>>>>>>>>>>>>>>>>>>>    -----------------------
>>>>>>>>>>>>>>>>>>>>> public class MultiResolutionBufferedImage implements
>>>>>>>>>>>>>>>>>>>>> MultiResolutionImage{
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>     interface ResolutionVariantChooser{
>>>>>>>>>>>>>>>>>>>>>         Image getResolutionVariant(dpi, size,..., 
>>>>>>>>>>>>>>>>>>>>> List<Image>
>>>>>>>>>>>>>>>>>>>>> resolutionVariants);
>>>>>>>>>>>>>>>>>>>>>     }
>>>>>>>>>>>>>>>>>>>>> ResolutionVariantChooser TRANSFORM_BASED = null;
>>>>>>>>>>>>>>>>>>>>> ResolutionVariantChooser DPI_BASED = null;
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> ResolutionVariantChooser rvChooser;
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>     @Override
>>>>>>>>>>>>>>>>>>>>>     public Image getResolutionVariant(dpi, 
>>>>>>>>>>>>>>>>>>>>> size,...,) {
>>>>>>>>>>>>>>>>>>>>>         return rvChooser.getResolutionVariant(dpi, 
>>>>>>>>>>>>>>>>>>>>> size,...,
>>>>>>>>>>>>>>>>>>>>> getResolutionVariants());
>>>>>>>>>>>>>>>>>>>>>     }
>>>>>>>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>>>>>>>    -----------------------
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>   Thanks,
>>>>>>>>>>>>>>>>>>>>>   Alexandr.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>             ...jim
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>>>>>>>>>>>> Alexandr.
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> On 2/13/2014 4:42 AM, Jim Graham wrote:
>>>>>>>>>>>>>>>>>>>>>>>> On 2/12/14 5:59 AM, Alexander Scherbatiy wrote:
>>>>>>>>>>>>>>>>>>>>>>>>> On 2/8/2014 4:19 AM, Jim Graham wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>> The primary thing that I was concerned about 
>>>>>>>>>>>>>>>>>>>>>>>>>> was the
>>>>>>>>>>>>>>>>>>>>>>>>>> presence of
>>>>>>>>>>>>>>>>>>>>>>>>>> integers in the API when Windows uses 
>>>>>>>>>>>>>>>>>>>>>>>>>> non-integer multiples
>>>>>>>>>>>>>>>>>>>>>>>>>       It would make sense to pass real numbers 
>>>>>>>>>>>>>>>>>>>>>>>>> to the
>>>>>>>>>>>>>>>>>>>>>>>>> getResolutionVariant() method if the 
>>>>>>>>>>>>>>>>>>>>>>>>> difference between
>>>>>>>>>>>>>>>>>>>>>>>>> resolution
>>>>>>>>>>>>>>>>>>>>>>>>> variants sizes is 1.
>>>>>>>>>>>>>>>>>>>>>>>>>       It seems that it is not a common case.
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> I was thinking of other API that is related to 
>>>>>>>>>>>>>>>>>>>>>>>> this, such as
>>>>>>>>>>>>>>>>>>>>>>>> the API
>>>>>>>>>>>>>>>>>>>>>>>> that queries the scaling factor from a 
>>>>>>>>>>>>>>>>>>>>>>>> SurfaceManager. I
>>>>>>>>>>>>>>>>>>>>>>>> seem to
>>>>>>>>>>>>>>>>>>>>>>>> remember some integer return values in that, 
>>>>>>>>>>>>>>>>>>>>>>>> but Windows might
>>>>>>>>>>>>>>>>>>>>>>>> have
>>>>>>>>>>>>>>>>>>>>>>>> the answer 1.4 or 1.8, depending on the screen 
>>>>>>>>>>>>>>>>>>>>>>>> scaling factor
>>>>>>>>>>>>>>>>>>>>>>>> that was
>>>>>>>>>>>>>>>>>>>>>>>> determined from the UI.
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> In terms of the getResolutionVariant() method 
>>>>>>>>>>>>>>>>>>>>>>>> here, those
>>>>>>>>>>>>>>>>>>>>>>>> non-integer
>>>>>>>>>>>>>>>>>>>>>>>> screen scaling factors don't directly impact 
>>>>>>>>>>>>>>>>>>>>>>>> this API. But, we
>>>>>>>>>>>>>>>>>>>>>>>> have
>>>>>>>>>>>>>>>>>>>>>>>> some issues with the use of integers there from 
>>>>>>>>>>>>>>>>>>>>>>>> other sources:
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> - That API assumes that the caller will 
>>>>>>>>>>>>>>>>>>>>>>>> determine the pixel
>>>>>>>>>>>>>>>>>>>>>>>> size
>>>>>>>>>>>>>>>>>>>>>>>> needed, but the actual media choice is 
>>>>>>>>>>>>>>>>>>>>>>>> determined with
>>>>>>>>>>>>>>>>>>>>>>>> different
>>>>>>>>>>>>>>>>>>>>>>>> techniques on Mac and Windows so this means 
>>>>>>>>>>>>>>>>>>>>>>>> that the caller
>>>>>>>>>>>>>>>>>>>>>>>> will
>>>>>>>>>>>>>>>>>>>>>>>> have
>>>>>>>>>>>>>>>>>>>>>>>> to worry about platform conventions. Is that 
>>>>>>>>>>>>>>>>>>>>>>>> the right
>>>>>>>>>>>>>>>>>>>>>>>> tradeoff?
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> - The technique recommended for Mac involves 
>>>>>>>>>>>>>>>>>>>>>>>> computing the
>>>>>>>>>>>>>>>>>>>>>>>> precise
>>>>>>>>>>>>>>>>>>>>>>>> size desired using the current transform, which 
>>>>>>>>>>>>>>>>>>>>>>>> may be a
>>>>>>>>>>>>>>>>>>>>>>>> floating
>>>>>>>>>>>>>>>>>>>>>>>> point value, so the integer values used in this 
>>>>>>>>>>>>>>>>>>>>>>>> API are already
>>>>>>>>>>>>>>>>>>>>>>>> approximations and there is no documentation on 
>>>>>>>>>>>>>>>>>>>>>>>> how to
>>>>>>>>>>>>>>>>>>>>>>>> generate the
>>>>>>>>>>>>>>>>>>>>>>>> proper integer.  In particular, the current 
>>>>>>>>>>>>>>>>>>>>>>>> code in SG2D
>>>>>>>>>>>>>>>>>>>>>>>> naively
>>>>>>>>>>>>>>>>>>>>>>>> uses
>>>>>>>>>>>>>>>>>>>>>>>> a cast to integer to determine the values to 
>>>>>>>>>>>>>>>>>>>>>>>> supply which
>>>>>>>>>>>>>>>>>>>>>>>> means a
>>>>>>>>>>>>>>>>>>>>>>>> transformed size of W+0.5 will be truncated to 
>>>>>>>>>>>>>>>>>>>>>>>> W and the lower
>>>>>>>>>>>>>>>>>>>>>>>> resolution image will be used. Does that 
>>>>>>>>>>>>>>>>>>>>>>>> conform to Mac
>>>>>>>>>>>>>>>>>>>>>>>> guidelines? Do
>>>>>>>>>>>>>>>>>>>>>>>> they require the truncated size to reach W+1 
>>>>>>>>>>>>>>>>>>>>>>>> before the next
>>>>>>>>>>>>>>>>>>>>>>>> size is
>>>>>>>>>>>>>>>>>>>>>>>> used?  Passing in float or double values would 
>>>>>>>>>>>>>>>>>>>>>>>> sidestep all of
>>>>>>>>>>>>>>>>>>>>>>>> that
>>>>>>>>>>>>>>>>>>>>>>>> since then the comparisons would be done with 
>>>>>>>>>>>>>>>>>>>>>>>> full precision,
>>>>>>>>>>>>>>>>>>>>>>>> but as
>>>>>>>>>>>>>>>>>>>>>>>> long as we can determine a "best practices 
>>>>>>>>>>>>>>>>>>>>>>>> compatible with all
>>>>>>>>>>>>>>>>>>>>>>>> platforms" rule on how to round to integers, 
>>>>>>>>>>>>>>>>>>>>>>>> then integers
>>>>>>>>>>>>>>>>>>>>>>>> are OK
>>>>>>>>>>>>>>>>>>>>>>>> there.
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> - The Windows document you cite below suggests 
>>>>>>>>>>>>>>>>>>>>>>>> that the
>>>>>>>>>>>>>>>>>>>>>>>> determination
>>>>>>>>>>>>>>>>>>>>>>>> should be made by looking at the Screen DPI and 
>>>>>>>>>>>>>>>>>>>>>>>> choosing the
>>>>>>>>>>>>>>>>>>>>>>>> next
>>>>>>>>>>>>>>>>>>>>>>>> higher media variant based on that screen DPI. 
>>>>>>>>>>>>>>>>>>>>>>>> They do not
>>>>>>>>>>>>>>>>>>>>>>>> specify
>>>>>>>>>>>>>>>>>>>>>>>> choosing media based on the current transform 
>>>>>>>>>>>>>>>>>>>>>>>> as is done for
>>>>>>>>>>>>>>>>>>>>>>>> Mac.  If
>>>>>>>>>>>>>>>>>>>>>>>> we stick with supplying values that are used to 
>>>>>>>>>>>>>>>>>>>>>>>> determine which
>>>>>>>>>>>>>>>>>>>>>>>> media
>>>>>>>>>>>>>>>>>>>>>>>> to use, then on Windows we should not take the 
>>>>>>>>>>>>>>>>>>>>>>>> transform into
>>>>>>>>>>>>>>>>>>>>>>>> account,
>>>>>>>>>>>>>>>>>>>>>>>> but instead query the SurfaceManager for the 
>>>>>>>>>>>>>>>>>>>>>>>> scale factor and
>>>>>>>>>>>>>>>>>>>>>>>> only
>>>>>>>>>>>>>>>>>>>>>>>> transform by those values (even if the current 
>>>>>>>>>>>>>>>>>>>>>>>> transform was
>>>>>>>>>>>>>>>>>>>>>>>> manually
>>>>>>>>>>>>>>>>>>>>>>>> overridden to identity).
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> There are pros and cons to both approaches.
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> Mac ensures that you are always using the best 
>>>>>>>>>>>>>>>>>>>>>>>> media for any
>>>>>>>>>>>>>>>>>>>>>>>> given
>>>>>>>>>>>>>>>>>>>>>>>> render operation.
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> But, Windows ensure more consistency in the 
>>>>>>>>>>>>>>>>>>>>>>>> face of other
>>>>>>>>>>>>>>>>>>>>>>>> scaling.
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> The thing to consider is that if you have a 
>>>>>>>>>>>>>>>>>>>>>>>> 500x500 image
>>>>>>>>>>>>>>>>>>>>>>>> with a
>>>>>>>>>>>>>>>>>>>>>>>> 1000x1000 variant and you rendering it at 
>>>>>>>>>>>>>>>>>>>>>>>> 500x500 and then
>>>>>>>>>>>>>>>>>>>>>>>> 501x501,
>>>>>>>>>>>>>>>>>>>>>>>> that first jump will be fairly jarring as the 
>>>>>>>>>>>>>>>>>>>>>>>> scaled version
>>>>>>>>>>>>>>>>>>>>>>>> of the
>>>>>>>>>>>>>>>>>>>>>>>> 1000x1000 will not look precisely like the 
>>>>>>>>>>>>>>>>>>>>>>>> original 500x500
>>>>>>>>>>>>>>>>>>>>>>>> did.
>>>>>>>>>>>>>>>>>>>>>>>> With
>>>>>>>>>>>>>>>>>>>>>>>> @2x images only, this effect is minimized so 
>>>>>>>>>>>>>>>>>>>>>>>> the advantage of
>>>>>>>>>>>>>>>>>>>>>>>> always
>>>>>>>>>>>>>>>>>>>>>>>> using "the best media for a given render 
>>>>>>>>>>>>>>>>>>>>>>>> operation" may
>>>>>>>>>>>>>>>>>>>>>>>> outweigh the
>>>>>>>>>>>>>>>>>>>>>>>> inconsistency issue. But, on Windows where the 
>>>>>>>>>>>>>>>>>>>>>>>> media are
>>>>>>>>>>>>>>>>>>>>>>>> 1.4x or
>>>>>>>>>>>>>>>>>>>>>>>> 1.8x
>>>>>>>>>>>>>>>>>>>>>>>> in size, a downscaled image will start to show 
>>>>>>>>>>>>>>>>>>>>>>>> more
>>>>>>>>>>>>>>>>>>>>>>>> interpolation
>>>>>>>>>>>>>>>>>>>>>>>> noise and so the balance of the two choices may 
>>>>>>>>>>>>>>>>>>>>>>>> shift more
>>>>>>>>>>>>>>>>>>>>>>>> towards not
>>>>>>>>>>>>>>>>>>>>>>>> wanting a jarring shift.
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> We might want one or more of the following:
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> - Developer chooses policy (TX_AWARE, DPI_AWARE,
>>>>>>>>>>>>>>>>>>>>>>>> ALWAYS_LARGEST,
>>>>>>>>>>>>>>>>>>>>>>>> NONE,
>>>>>>>>>>>>>>>>>>>>>>>> PLATFORM) where the last policy would use 
>>>>>>>>>>>>>>>>>>>>>>>> TX_AWARE on Mac and
>>>>>>>>>>>>>>>>>>>>>>>> DPI_AWARE on Windows
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> - We create our own policy and always use it 
>>>>>>>>>>>>>>>>>>>>>>>> (TX_AWARE? or
>>>>>>>>>>>>>>>>>>>>>>>> DPI_AWARE?)
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> - We create our own policy that dynamically 
>>>>>>>>>>>>>>>>>>>>>>>> chooses one of the
>>>>>>>>>>>>>>>>>>>>>>>> above
>>>>>>>>>>>>>>>>>>>>>>>> strategies depending on platform or available 
>>>>>>>>>>>>>>>>>>>>>>>> media or ???
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> - We could create an optional interface for 
>>>>>>>>>>>>>>>>>>>>>>>> them to install
>>>>>>>>>>>>>>>>>>>>>>>> their
>>>>>>>>>>>>>>>>>>>>>>>> own
>>>>>>>>>>>>>>>>>>>>>>>> algorithm as well. I think it would work best 
>>>>>>>>>>>>>>>>>>>>>>>> as a delegate
>>>>>>>>>>>>>>>>>>>>>>>> interface
>>>>>>>>>>>>>>>>>>>>>>>> that one installs into Image so that it can be 
>>>>>>>>>>>>>>>>>>>>>>>> used with any
>>>>>>>>>>>>>>>>>>>>>>>> image
>>>>>>>>>>>>>>>>>>>>>>>> without having to subclass (it wouldn't really 
>>>>>>>>>>>>>>>>>>>>>>>> have much to do
>>>>>>>>>>>>>>>>>>>>>>>> for
>>>>>>>>>>>>>>>>>>>>>>>> BufferedImages or VolatileImages, though):
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> class Image {
>>>>>>>>>>>>>>>>>>>>>>>>     void 
>>>>>>>>>>>>>>>>>>>>>>>> setResolutionHelper(ImageResolutionHelper foo);
>>>>>>>>>>>>>>>>>>>>>>>> List<Image> getResolutionVariants();
>>>>>>>>>>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> or:
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> class Graphics {
>>>>>>>>>>>>>>>>>>>>>>>>      void 
>>>>>>>>>>>>>>>>>>>>>>>> setResolutionHelper(ImageResolutionHelper foo);
>>>>>>>>>>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> or - anywhere else it could be installed more 
>>>>>>>>>>>>>>>>>>>>>>>> centrally (per
>>>>>>>>>>>>>>>>>>>>>>>> App
>>>>>>>>>>>>>>>>>>>>>>>> context)?
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> and the interface would be something like one 
>>>>>>>>>>>>>>>>>>>>>>>> of these
>>>>>>>>>>>>>>>>>>>>>>>> variants:
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> interface ImageResolutionHelper {
>>>>>>>>>>>>>>>>>>>>>>>>     // This version would prevent substituting 
>>>>>>>>>>>>>>>>>>>>>>>> a random image:
>>>>>>>>>>>>>>>>>>>>>>>>     // They have to return an index into the 
>>>>>>>>>>>>>>>>>>>>>>>> List<Image> for
>>>>>>>>>>>>>>>>>>>>>>>> that
>>>>>>>>>>>>>>>>>>>>>>>> image...
>>>>>>>>>>>>>>>>>>>>>>>>     public int chooseVariant(Image img, double 
>>>>>>>>>>>>>>>>>>>>>>>> dpi, number w,
>>>>>>>>>>>>>>>>>>>>>>>> number h);
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> or:
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>     // This version would allow substituting an 
>>>>>>>>>>>>>>>>>>>>>>>> arbitrary
>>>>>>>>>>>>>>>>>>>>>>>> image:
>>>>>>>>>>>>>>>>>>>>>>>>     public Image getVariant(Image img, double 
>>>>>>>>>>>>>>>>>>>>>>>> dpi, number w,
>>>>>>>>>>>>>>>>>>>>>>>> number
>>>>>>>>>>>>>>>>>>>>>>>> h);
>>>>>>>>>>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> Since they would be in full control of the 
>>>>>>>>>>>>>>>>>>>>>>>> policy, though, we
>>>>>>>>>>>>>>>>>>>>>>>> would
>>>>>>>>>>>>>>>>>>>>>>>> unfortunately always have to call this, there 
>>>>>>>>>>>>>>>>>>>>>>>> would be no more
>>>>>>>>>>>>>>>>>>>>>>>> testing
>>>>>>>>>>>>>>>>>>>>>>>> in SG2D to see "if" we need to deal with DPI, 
>>>>>>>>>>>>>>>>>>>>>>>> though perhaps we
>>>>>>>>>>>>>>>>>>>>>>>> could
>>>>>>>>>>>>>>>>>>>>>>>> document some internal conditions in which we 
>>>>>>>>>>>>>>>>>>>>>>>> do not call it
>>>>>>>>>>>>>>>>>>>>>>>> for
>>>>>>>>>>>>>>>>>>>>>>>> common cases (but that would have to be well 
>>>>>>>>>>>>>>>>>>>>>>>> agreed not to
>>>>>>>>>>>>>>>>>>>>>>>> get in
>>>>>>>>>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>>>>>>>> way of reasonable uses of the API and well 
>>>>>>>>>>>>>>>>>>>>>>>> documented)?
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> Note that we would have to do a security audit 
>>>>>>>>>>>>>>>>>>>>>>>> to make sure
>>>>>>>>>>>>>>>>>>>>>>>> that
>>>>>>>>>>>>>>>>>>>>>>>> random image substitution couldn't allow any 
>>>>>>>>>>>>>>>>>>>>>>>> sort of "screen
>>>>>>>>>>>>>>>>>>>>>>>> phishing"
>>>>>>>>>>>>>>>>>>>>>>>> exploit.
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>             ...jim
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> and also what policy they use for choosing 
>>>>>>>>>>>>>>>>>>>>>>>>>> scaled images.
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> I don't see a mention of taking the current 
>>>>>>>>>>>>>>>>>>>>>>>>>> transform into
>>>>>>>>>>>>>>>>>>>>>>>>>> account,
>>>>>>>>>>>>>>>>>>>>>>>>>> just physical issues like screen DPI and form 
>>>>>>>>>>>>>>>>>>>>>>>>>> factor. They
>>>>>>>>>>>>>>>>>>>>>>>>>> talk
>>>>>>>>>>>>>>>>>>>>>>>>>> about
>>>>>>>>>>>>>>>>>>>>>>>>>> resolution plateaus and in their 
>>>>>>>>>>>>>>>>>>>>>>>>>> recommendations section they
>>>>>>>>>>>>>>>>>>>>>>>>>> tell the
>>>>>>>>>>>>>>>>>>>>>>>>>> developer to use a particular property that 
>>>>>>>>>>>>>>>>>>>>>>>>>> tells them the
>>>>>>>>>>>>>>>>>>>>>>>>>> screen
>>>>>>>>>>>>>>>>>>>>>>>>>> resolution to figure out which image to load 
>>>>>>>>>>>>>>>>>>>>>>>>>> if they are
>>>>>>>>>>>>>>>>>>>>>>>>>> loading
>>>>>>>>>>>>>>>>>>>>>>>>>> manually.  There is no discussion about 
>>>>>>>>>>>>>>>>>>>>>>>>>> dynamically loading
>>>>>>>>>>>>>>>>>>>>>>>>>> multiple
>>>>>>>>>>>>>>>>>>>>>>>>>> versions of the image based on a dynamic 
>>>>>>>>>>>>>>>>>>>>>>>>>> program-applied
>>>>>>>>>>>>>>>>>>>>>>>>>> transform
>>>>>>>>>>>>>>>>>>>>>>>>>> factor as is done on MacOS.
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> Also, they tell developers to draw images to 
>>>>>>>>>>>>>>>>>>>>>>>>>> a specific size
>>>>>>>>>>>>>>>>>>>>>>>>>> rather
>>>>>>>>>>>>>>>>>>>>>>>>>> than using auto-sizing. That begs the 
>>>>>>>>>>>>>>>>>>>>>>>>>> question as to how
>>>>>>>>>>>>>>>>>>>>>>>>>> they
>>>>>>>>>>>>>>>>>>>>>>>>>> interpret a call to draw an image just using 
>>>>>>>>>>>>>>>>>>>>>>>>>> a location in
>>>>>>>>>>>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>>>>>>>>>> presence of various DPI factors.
>>>>>>>>>>>>>>>>>>>>>>>>>       There is an interesting doc that 
>>>>>>>>>>>>>>>>>>>>>>>>> describes how to write
>>>>>>>>>>>>>>>>>>>>>>>>> DPI-aware
>>>>>>>>>>>>>>>>>>>>>>>>> Win32 applications:
>>>>>>>>>>>>>>>>>>>>>>>>> http://msdn.microsoft.com/en-us/library/dd464646%28v=vs.85%29.aspx 
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>       It is suggested to handle WM_DPICHANGED 
>>>>>>>>>>>>>>>>>>>>>>>>> message, load
>>>>>>>>>>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>>>>>>>>> graphic
>>>>>>>>>>>>>>>>>>>>>>>>> that has slightly greater resolution to the 
>>>>>>>>>>>>>>>>>>>>>>>>> current DPI and
>>>>>>>>>>>>>>>>>>>>>>>>> use
>>>>>>>>>>>>>>>>>>>>>>>>> StretchBlt
>>>>>>>>>>>>>>>>>>>>>>>>>       to scale down the image.
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>      Thanks,
>>>>>>>>>>>>>>>>>>>>>>>>>      Alexandr.
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> ...jim
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> On 2/7/14 3:00 AM, Alexander Scherbatiy wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>> On 1/22/2014 6:40 AM, Jim Graham wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>> Hi Alexander,
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>> Before we get too far down the road on this 
>>>>>>>>>>>>>>>>>>>>>>>>>>>> API, I think we
>>>>>>>>>>>>>>>>>>>>>>>>>>>> understand
>>>>>>>>>>>>>>>>>>>>>>>>>>>> the way in which MacOS processes 
>>>>>>>>>>>>>>>>>>>>>>>>>>>> multi-resolution images
>>>>>>>>>>>>>>>>>>>>>>>>>>>> for
>>>>>>>>>>>>>>>>>>>>>>>>>>>> HiDPI
>>>>>>>>>>>>>>>>>>>>>>>>>>>> screens, but have we investigated the 
>>>>>>>>>>>>>>>>>>>>>>>>>>>> processes that
>>>>>>>>>>>>>>>>>>>>>>>>>>>> Windows
>>>>>>>>>>>>>>>>>>>>>>>>>>>> uses
>>>>>>>>>>>>>>>>>>>>>>>>>>>> under Windows 8? My impression is that 
>>>>>>>>>>>>>>>>>>>>>>>>>>>> Windows 8 has
>>>>>>>>>>>>>>>>>>>>>>>>>>>> included a
>>>>>>>>>>>>>>>>>>>>>>>>>>>> number of new techniques for dealing with 
>>>>>>>>>>>>>>>>>>>>>>>>>>>> the high
>>>>>>>>>>>>>>>>>>>>>>>>>>>> resolution
>>>>>>>>>>>>>>>>>>>>>>>>>>>> displays
>>>>>>>>>>>>>>>>>>>>>>>>>>>> that it will run on in the Windows tablet 
>>>>>>>>>>>>>>>>>>>>>>>>>>>> and mobile
>>>>>>>>>>>>>>>>>>>>>>>>>>>> industries
>>>>>>>>>>>>>>>>>>>>>>>>>>>> and
>>>>>>>>>>>>>>>>>>>>>>>>>>>> that these will also come into play as 4K 
>>>>>>>>>>>>>>>>>>>>>>>>>>>> displays (already
>>>>>>>>>>>>>>>>>>>>>>>>>>>> available)
>>>>>>>>>>>>>>>>>>>>>>>>>>>> become more common on the desktop. We 
>>>>>>>>>>>>>>>>>>>>>>>>>>>> should make sure
>>>>>>>>>>>>>>>>>>>>>>>>>>>> that
>>>>>>>>>>>>>>>>>>>>>>>>>>>> what we
>>>>>>>>>>>>>>>>>>>>>>>>>>>> come up with here can provide native 
>>>>>>>>>>>>>>>>>>>>>>>>>>>> compatibility with
>>>>>>>>>>>>>>>>>>>>>>>>>>>> either
>>>>>>>>>>>>>>>>>>>>>>>>>>>> platform's policies and standard practices.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>> If you've investigated the MS policies I'd 
>>>>>>>>>>>>>>>>>>>>>>>>>>>> like to see a
>>>>>>>>>>>>>>>>>>>>>>>>>>>> summary so
>>>>>>>>>>>>>>>>>>>>>>>>>>>> that we can consider them as we review this 
>>>>>>>>>>>>>>>>>>>>>>>>>>>> API...
>>>>>>>>>>>>>>>>>>>>>>>>>>>     There is the Windows Guidelines for 
>>>>>>>>>>>>>>>>>>>>>>>>>>> scaling to pixel
>>>>>>>>>>>>>>>>>>>>>>>>>>> density:
>>>>>>>>>>>>>>>>>>>>>>>>>>> http://msdn.microsoft.com/en-us/library/windows/apps/hh465362.aspx 
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>     which says that Windows has automatic 
>>>>>>>>>>>>>>>>>>>>>>>>>>> resource loading
>>>>>>>>>>>>>>>>>>>>>>>>>>> that
>>>>>>>>>>>>>>>>>>>>>>>>>>> supports
>>>>>>>>>>>>>>>>>>>>>>>>>>> three version of images scaling (100%, 140%, 
>>>>>>>>>>>>>>>>>>>>>>>>>>> and 180%)
>>>>>>>>>>>>>>>>>>>>>>>>>>> --------------------------------
>>>>>>>>>>>>>>>>>>>>>>>>>>> Without scaling, as the pixel density of a 
>>>>>>>>>>>>>>>>>>>>>>>>>>> display device
>>>>>>>>>>>>>>>>>>>>>>>>>>> increases, the
>>>>>>>>>>>>>>>>>>>>>>>>>>> physical sizes of objects on screen get 
>>>>>>>>>>>>>>>>>>>>>>>>>>> smaller.
>>>>>>>>>>>>>>>>>>>>>>>>>>> When UI would otherwise be too small to 
>>>>>>>>>>>>>>>>>>>>>>>>>>> touch and when text
>>>>>>>>>>>>>>>>>>>>>>>>>>> gets
>>>>>>>>>>>>>>>>>>>>>>>>>>> too
>>>>>>>>>>>>>>>>>>>>>>>>>>> small to read,
>>>>>>>>>>>>>>>>>>>>>>>>>>> Windows scales the system and app UI to one 
>>>>>>>>>>>>>>>>>>>>>>>>>>> of the following
>>>>>>>>>>>>>>>>>>>>>>>>>>> scaling
>>>>>>>>>>>>>>>>>>>>>>>>>>> plateaus:
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>      1.0 (100%, no scaling is applied)
>>>>>>>>>>>>>>>>>>>>>>>>>>>      1.4 (140% scaling)
>>>>>>>>>>>>>>>>>>>>>>>>>>>      1.8 (180% scaling)
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>> Windows determines which scaling plateau to 
>>>>>>>>>>>>>>>>>>>>>>>>>>> use based on the
>>>>>>>>>>>>>>>>>>>>>>>>>>> physical
>>>>>>>>>>>>>>>>>>>>>>>>>>> screen size, the screen resolution, the DPI 
>>>>>>>>>>>>>>>>>>>>>>>>>>> of the
>>>>>>>>>>>>>>>>>>>>>>>>>>> screen, and
>>>>>>>>>>>>>>>>>>>>>>>>>>> form
>>>>>>>>>>>>>>>>>>>>>>>>>>> factor.
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>> Use resource loading for bitmap images in 
>>>>>>>>>>>>>>>>>>>>>>>>>>> the app package
>>>>>>>>>>>>>>>>>>>>>>>>>>> For
>>>>>>>>>>>>>>>>>>>>>>>>>>> bitmap
>>>>>>>>>>>>>>>>>>>>>>>>>>> images stored
>>>>>>>>>>>>>>>>>>>>>>>>>>> in the app package, provide a separate image 
>>>>>>>>>>>>>>>>>>>>>>>>>>> for each
>>>>>>>>>>>>>>>>>>>>>>>>>>> scaling
>>>>>>>>>>>>>>>>>>>>>>>>>>> factor(100%, 140%, and 180%),
>>>>>>>>>>>>>>>>>>>>>>>>>>> and name your image files using the "scale" 
>>>>>>>>>>>>>>>>>>>>>>>>>>> naming
>>>>>>>>>>>>>>>>>>>>>>>>>>> convention
>>>>>>>>>>>>>>>>>>>>>>>>>>> described
>>>>>>>>>>>>>>>>>>>>>>>>>>> below.
>>>>>>>>>>>>>>>>>>>>>>>>>>> Windows loads the right image for the 
>>>>>>>>>>>>>>>>>>>>>>>>>>> current scale
>>>>>>>>>>>>>>>>>>>>>>>>>>> automatically.
>>>>>>>>>>>>>>>>>>>>>>>>>>> --------------------------------
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>   The image name convention for the various 
>>>>>>>>>>>>>>>>>>>>>>>>>>> scales is:
>>>>>>>>>>>>>>>>>>>>>>>>>>> images/logo.scale-100.png
>>>>>>>>>>>>>>>>>>>>>>>>>>> images/logo.scale-140.png
>>>>>>>>>>>>>>>>>>>>>>>>>>> images/logo.scale-180.png
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>    The 'ms-appx:///images/logo.png' uri is 
>>>>>>>>>>>>>>>>>>>>>>>>>>> used to load the
>>>>>>>>>>>>>>>>>>>>>>>>>>> image
>>>>>>>>>>>>>>>>>>>>>>>>>>> in an
>>>>>>>>>>>>>>>>>>>>>>>>>>> application.
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>    If we want to support this in the same 
>>>>>>>>>>>>>>>>>>>>>>>>>>> way as it is done
>>>>>>>>>>>>>>>>>>>>>>>>>>> for Mac
>>>>>>>>>>>>>>>>>>>>>>>>>>> OS X
>>>>>>>>>>>>>>>>>>>>>>>>>>>    the WToolkit should return 
>>>>>>>>>>>>>>>>>>>>>>>>>>> MultiResolution image in
>>>>>>>>>>>>>>>>>>>>>>>>>>> case if
>>>>>>>>>>>>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>>>>>>>>>>> loaded image has .scale-* qualifiers.
>>>>>>>>>>>>>>>>>>>>>>>>>>>    The Graphics class can request an image 
>>>>>>>>>>>>>>>>>>>>>>>>>>> with necessary
>>>>>>>>>>>>>>>>>>>>>>>>>>> resolution
>>>>>>>>>>>>>>>>>>>>>>>>>>> from the MultiResolution image.
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>    It seems that nothing should be changed 
>>>>>>>>>>>>>>>>>>>>>>>>>>> in the
>>>>>>>>>>>>>>>>>>>>>>>>>>> MultiResolution
>>>>>>>>>>>>>>>>>>>>>>>>>>> interface in this case.
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>     Thanks,
>>>>>>>>>>>>>>>>>>>>>>>>>>>     Alexandr.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>> ...jim
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 1/14/14 2:54 AM, Alexander Scherbatiy 
>>>>>>>>>>>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Hello,
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Could you review the fix:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>    bug: 
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8029339 
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>    webrev:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~alexsch/8029339/webrev.00 
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>    This is a proposal to introduce an API 
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> that allows to
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> create a
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> custom
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> multi resolution image.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> I. It seems reasonable that the API should 
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> provide two
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> basic
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> operations:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>   1. Get the resolution variant based on 
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> the requested
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> image
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> width and
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> height:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>      - Image getResolutionVariant(int 
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> width, int height)
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>     Usually the system provides the scale 
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> factor which
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> represents
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> number of pixels corresponding to each 
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> linear unit on the
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> display.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>     However, it has sense to combine the 
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> scale factor and
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> current
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> transformations to get the actual image 
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> size to be
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> displayed.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>   2. Get all provided resolution variants:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>     - List<Image> getResolutionVariants()
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>    There are several uses cases:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>     - Create a new multi-resolution image 
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> based on the
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> given
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> multi-resolution image.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>     - Pass to the native system the 
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> multi-resolution
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> image. For
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> example,
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> a use can set to the system the custom 
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> multi-resolution
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> cursor.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> II. There are some possible ways where the 
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> new API can be
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> added
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>   1. java.awt.Image.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>    The 2 new methods can be added to the 
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Image class. A
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> user
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> can
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> override
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>    the getResolutionVariant() and 
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> getResolutionVariants()
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> methods to
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> provide the resolution variants
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>    or there can be default implementations 
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> of these
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> methods
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> if a
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> user
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> puts resolution variants
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>    to the list in the sorted order.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>    To check that the image has resolution 
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> variants the
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> following
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> statement can be used:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> image.getResolutionVariants().size()
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> != 1
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>    The disadvantage is that there is an 
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> overhead that the
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Image
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> class
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> should contain the List object and not all
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>    images can have resolution variants.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>   2. Introduce new MultiResolutionImage 
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> interface.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>    A user should extend Image class and 
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> implement the
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> MultiResolutionImage interface.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>    For example:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> ---------------------
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>      public class 
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> CustomMultiResolutionImage extends
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> BufferedImage
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> implements MultiResolutionImage {
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>          Image highResolutionImage;
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> public 
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> CustomMultiResolutionImage(BufferedImage
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> baseImage,
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> BufferedImage highResolutionImage) {
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> super(baseImage.getWidth(),
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> baseImage.getHeight(),
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> baseImage.getType());
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> this.highResolutionImage = 
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> highResolutionImage;
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Graphics g = getGraphics();
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> g.drawImage(baseImage, 0, 0, null);
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> g.dispose();
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>          }
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> @Override
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> public Image getResolutionVariant(int 
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> width, int
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> height) {
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> return ((width <= getWidth() && height <=
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> getHeight()))
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> ? this : highResolutionImage;
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>          }
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> @Override
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> public List<Image> getResolutionVariants() {
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> return Arrays.asList(this,
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> highResolutionImage);
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>          }
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>      }
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> ---------------------
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>   The current fix adds the 
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> MultiResolutionImage interface
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> and
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> public
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> resolution variant rendering hints.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Alexandr.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>


From Sergey.Bylokhov at oracle.com  Thu Aug 21 17:38:24 2014
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Thu, 21 Aug 2014 21:38:24 +0400
Subject: <AWT Dev> [9] Review Request: 8055326 Fix typos in client-related
	packages
Message-ID: <53F62E90.90401@oracle.com>

Hello,
Please review the fix for jdk 9.
The fix was contributed by  pavel.rappo at oracle.com

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

-- 
Best regards, Sergey.


From philip.race at oracle.com  Thu Aug 21 18:04:43 2014
From: philip.race at oracle.com (Phil Race)
Date: Thu, 21 Aug 2014 11:04:43 -0700
Subject: <AWT Dev> [9] Review Request: 8055326 Fix typos in
	client-related packages
In-Reply-To: <53F62E90.90401@oracle.com>
References: <53F62E90.90401@oracle.com>
Message-ID: <53F634BB.7000905@oracle.com>

Was the additional spce on the 2nd line intended here ?

--- old/src/java.desktop/share/classes/java/awt/ContainerOrderFocusTraversalPolicy.java	2014-08-21 20:50:04.859532400 +0400
+++ new/src/java.desktop/share/classes/java/awt/ContainerOrderFocusTraversalPolicy.java	2014-08-21 20:50:04.663521200 +0400
@@ -166,8 +166,8 @@
                      retComp = cont.getFocusTraversalPolicy().getDefaultComponent(cont);
  
                      if (retComp != null && log.isLoggable(PlatformLogger.Level.FINE)) {
-                        log.fine("### Transfered focus down-cycle to " + retComp +
-                                 " in the focus cycle root " + cont);
+                        log.fine("### Transferred focus down-cycle to " + retComp +
+                                " in the focus cycle root " + cont);


And I don't see what was so wrong with this, perhaps because I wrote it :-)

-         * so that when the Font2D is GC'd it can also remove the file.
+         * so that when the Font2D is GC'ed it can also remove the file.


Other than that, looks good.
Some fun new words in there. I particularly liked utilitized and unclude.

-phil.

On 8/21/2014 10:38 AM, Sergey Bylokhov wrote:
> Hello,
> Please review the fix for jdk 9.
> The fix was contributed by  pavel.rappo at oracle.com
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8055326
> Webrev can be found at: 
> http://cr.openjdk.java.net/~serb/8055326/webrev.00
>


From alexandr.scherbatiy at oracle.com  Fri Aug 22 08:29:37 2014
From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy)
Date: Fri, 22 Aug 2014 12:29:37 +0400
Subject: <AWT Dev> [7u-dev] Request for approval for JDK-8043610:
 Sorting columns in JFileChooser fails with AppContext NPE
In-Reply-To: <53F4A41D.4020804@oracle.com>
References: <53F4A41D.4020804@oracle.com>
Message-ID: <53F6FF71.8080307@oracle.com>


   The fix looks good to me.

   Thanks,
   Alexandr.

On 8/20/2014 5:35 PM, Alexey Ivanov wrote:
> Hello,
>
> Please approve the backport of the fix to jdk7u-dev.
>
> I replaced lambda expressions and method reference with anonymous 
> classes:
>
>     webrev: http://cr.openjdk.java.net/~aivanov/8043610/jdk7/webrev.00/
>
>
> AWT and Swing teams,
>
> Could you please review the backport?
>
> JBS bug: https://bugs.openjdk.java.net/browse/JDK-8043610
> JDK9 review: 
> http://mail.openjdk.java.net/pipermail/awt-dev/2014-May/007846.html
> JDK9 webrev: http://cr.openjdk.java.net/~pchelko/9/8043610/webrev/
>
> JDK9 changeset: 
> http://hg.openjdk.java.net/jdk9/client/jdk/rev/604abecf62c2
> JDK8 changeset: 
> http://hg.openjdk.java.net/jdk8u/jdk8u-dev/jdk/rev/b20c4785bb81
>
>
> Thank you in advance,
> Alexey.


From dalibor.topic at oracle.com  Fri Aug 22 09:28:43 2014
From: dalibor.topic at oracle.com (dalibor topic)
Date: Fri, 22 Aug 2014 11:28:43 +0200
Subject: <AWT Dev> [7u-dev] Request for approval for JDK-8043610:
 Sorting columns in JFileChooser fails with AppContext NPE
In-Reply-To: <53F4A41D.4020804@oracle.com>
References: <53F4A41D.4020804@oracle.com>
Message-ID: <53F70D4B.3030705@oracle.com>

Approved for jdk7u-dev.

cheers,
dalibor topic

On 20.08.2014 15:35, Alexey Ivanov wrote:
> Hello,
>
> Please approve the backport of the fix to jdk7u-dev.
>
> I replaced lambda expressions and method reference with anonymous classes:
>
>      webrev: http://cr.openjdk.java.net/~aivanov/8043610/jdk7/webrev.00/
>
>
> AWT and Swing teams,
>
> Could you please review the backport?
>
> JBS bug: https://bugs.openjdk.java.net/browse/JDK-8043610
> JDK9 review:
> http://mail.openjdk.java.net/pipermail/awt-dev/2014-May/007846.html
> JDK9 webrev: http://cr.openjdk.java.net/~pchelko/9/8043610/webrev/
>
> JDK9 changeset: http://hg.openjdk.java.net/jdk9/client/jdk/rev/604abecf62c2
> JDK8 changeset:
> http://hg.openjdk.java.net/jdk8u/jdk8u-dev/jdk/rev/b20c4785bb81
>
>
> Thank you in advance,
> Alexey.

-- 
<http://www.oracle.com> Dalibor Topic | Principal Product Manager
Phone: +494089091214 <tel:+494089091214> | Mobile: +491737185961
<tel:+491737185961>

ORACLE Deutschland B.V. & Co. KG | K?hneh?fe 5 | 22761 Hamburg

ORACLE Deutschland B.V. & Co. KG
Hauptverwaltung: Riesstr. 25, D-80992 M?nchen
Registergericht: Amtsgericht M?nchen, HRA 95603
Gesch?ftsf?hrer: J?rgen Kunz

Komplement?rin: ORACLE Deutschland Verwaltung B.V.
Hertogswetering 163/167, 3543 AS Utrecht, Niederlande
Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697
Gesch?ftsf?hrer: Alexander van der Ven, Astrid Kepper, Val Maher

<http://www.oracle.com/commitment> Oracle is committed to developing
practices and products that help protect the environment

From alexey.ivanov at oracle.com  Fri Aug 22 11:14:21 2014
From: alexey.ivanov at oracle.com (Alexey Ivanov)
Date: Fri, 22 Aug 2014 15:14:21 +0400
Subject: <AWT Dev> [7u-dev] Request for approval for JDK-8043610:
 Sorting columns in JFileChooser fails with AppContext NPE
In-Reply-To: <53F4AC4B.2080506@oracle.com>
References: <53F4A41D.4020804@oracle.com> <53F4A621.1070905@oracle.com>
	<53F4AC4B.2080506@oracle.com>
Message-ID: <53F7260D.4090403@oracle.com>

Se?n and Dalibor, thank you for approval.
Anthony and Alexander, thank you for review.

Regards,
Alexey.

On 20.08.2014 18:10, Se?n Coffey wrote:
> Approved.
>
> regards,
> Sean.
>
> On 20/08/14 14:44, Anthony Petrov wrote:
>> Looks fine. +1
>>
>> -- 
>> best regards,
>> Anthony
>>
>> On 8/20/2014 5:35 PM, Alexey Ivanov wrote:
>>> Hello,
>>>
>>> Please approve the backport of the fix to jdk7u-dev.
>>>
>>> I replaced lambda expressions and method reference with anonymous 
>>> classes:
>>>
>>>      webrev: 
>>> http://cr.openjdk.java.net/~aivanov/8043610/jdk7/webrev.00/
>>>
>>>
>>> AWT and Swing teams,
>>>
>>> Could you please review the backport?
>>>
>>> JBS bug: https://bugs.openjdk.java.net/browse/JDK-8043610
>>> JDK9 review:
>>> http://mail.openjdk.java.net/pipermail/awt-dev/2014-May/007846.html
>>> JDK9 webrev: http://cr.openjdk.java.net/~pchelko/9/8043610/webrev/
>>>
>>> JDK9 changeset: 
>>> http://hg.openjdk.java.net/jdk9/client/jdk/rev/604abecf62c2
>>> JDK8 changeset:
>>> http://hg.openjdk.java.net/jdk8u/jdk8u-dev/jdk/rev/b20c4785bb81
>>>
>>>
>>> Thank you in advance,
>>> Alexey.
>


From alexander.v.stepanov at oracle.com  Fri Aug 22 16:17:18 2014
From: alexander.v.stepanov at oracle.com (alexander stepanov)
Date: Fri, 22 Aug 2014 20:17:18 +0400
Subject: <AWT Dev> [9] Review Request for 8054359: move awt automated tests
 from AWT_Modality to OpenJDK repository - part 8
Message-ID: <53F76D0E.1000809@oracle.com>

Hello,

Could you please review the fix for
https://bugs.openjdk.java.net/browse/JDK-8054359

webrev:
http://cr.openjdk.java.net/~avstepan/8054359/

This is the next portion of functional AWT tests prepared for migration 
to OpenJDK repository.

The tests were checked on Ubuntu 14.04 Linux, Solaris 11 and Windows 7.

On Mac OS X 10.8.5 they are failing due to unfixed
https://bugs.openjdk.java.net/browse/JDK-7186009

Some of them are also failing because of
https://bugs.openjdk.java.net/browse/JDK-8055752

Thanks,
Alexander

From andreas.lundblad at gmail.com  Sat Aug 23 23:42:28 2014
From: andreas.lundblad at gmail.com (Andreas Lundblad)
Date: Sun, 24 Aug 2014 01:42:28 +0200
Subject: <AWT Dev> RFE: Listeners with Adapter-classes should have empty
	default methods
Message-ID: <CAFsBG0B3GX9qYSMzgU4yiemWaRaDisv+tUrHTFCuT798mXkBgg@mail.gmail.com>

For listener interfaces where it's common to just implement one or two
methods, there are corresponding Adapter classes with empty method
implementations. (For example: MouseListener/MouseAdapter,
KeyListener/KeyAdapter, ComponentListener/ComponentAdapter, ...)

The Adapter classes are really convenient for obvious reasons. However, due
to the constraint of single inheritance, they can't be used together with
each other. That is, if I want to listen to key presses
(KeyListener.keyPressed) and mouse clicks (MouseListener.mouseClicked) I'm
doomed to either

 1) choose to extend one of the adapters and clutter my code with empty
method implementations for the other, or

 2) Extend the two adapters in two separate classes and instantiate two
separate listener objects (which gets slightly messy if they need to share
some state).

Therefor I propose to add empty default implementations for these types of
listener interfaces. This would allow me to for instance implement
KeyListener and MouseListener and just override keyPressed and mouseClicked.

Some basic grepping yields the following list:

ComponentListener
ContainerListener
DragSourceListener
DropTargetListener
FocusListener
HierarchyBoundsListener
InternalFrameListener
KeyListener
MouseListener
MouseMotionListener
PrintJobListener
WindowListener

best regards,
Andreas Lundblad
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20140824/6ccc9d43/attachment.html>

From magnus.ihse.bursie at oracle.com  Mon Aug 25 09:14:04 2014
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Mon, 25 Aug 2014 11:14:04 +0200
Subject: <AWT Dev> RFR [9] Modular Source Code
In-Reply-To: <53F466E2.7070501@oracle.com>
References: <3132CBA0-5920-4DDA-8E69-308D5492F0DD@oracle.com>	<53EDCA54.2090107@oracle.com>
	<53EDDD47.2010204@oracle.com> <53F203EF.9070907@oracle.com>
	<53F20A6C.7090805@oracle.com> <53F466E2.7070501@oracle.com>
Message-ID: <53FAFE5C.2060600@oracle.com>

On 2014-08-20 11:14, Magnus Ihse Bursie wrote:
> On 2014-08-18 16:15, Anthony Petrov wrote:
>> So I'm not sure if the current set of AWT libraries could be 
>> simplified any further.
>>
>> Hope this helps.
>
> Thank you for the clarification, it was very helpful!
>
> While the set of AWT libraries probably cannot be simplified as you 
> say, my gut feeling is still that the current layout of files on disk 
> does not optimally match the actual libraries we build. Armed with the 
> help of your description, I'll look into them once again and see if I 
> can make that statement more concrete.

This is my suggestions based on what I found when trying to remove the 
last unnecessary entanglement. Note that all paths are relative to the 
java.desktop module, and  that I have at this stage only looked at 
compiled sources (*.c), not header files.

* The following files are in the windows directory tree, but are 
explicitly excluded on Windows. Thus they will never be built, and 
should be removed instead:
   ./windows/native/libawt/sun/java2d/d3d/D3DPipeline.cpp
   ./windows/native/libawt/sun/java2d/d3d/D3DShaderGen.c
   ./windows/native/libawt/sun/windows/WBufferStrategy.cpp

* The following file is in the share directory tree, but is only used on 
Windows. It should be moved to the corresponding windows directory instead:
   ./share/native/libawt/sun/java2d/ShaderList.c

* The following directory is in the unix directory tree, but is only 
used on Solaris. It should be moved to the corresponding solaris 
directory instead:
   ./unix/native/libawt/sun/java2d/loops

* The directory ./unix/native/common/sun/awt contains five more or less 
unrelated .c files. Three of them are only used in libawt_xawt, and 
should be moved there:
   ./unix/native/common/sun/awt/awt_Font.c
   ./unix/native/common/sun/awt/fontpath.c
   ./unix/native/common/sun/awt/X11Color.c
Of the remaining two CUPSfuncs.c seems correctly placed, since it is 
shared between libawt_xawt and libawt_lwawt. However, I'm wondering 
about initIDs.c. It is compiled in libawt as well as libawt_xawt, but 
when I checked some random functions, they are exported (via the 
mapfile) for libawt only. So I believe it is a mistake to include it in 
libawt_xawt, and that it should be moved to the libawt directory. This 
will need verification from someone on the AWT team.

* The directory ./unix/native/libjawt is included in libawt_xawt (and in 
libjawt, of course). This seems suspicious to me. There is just a single 
file with a single function, JAWT_GetAWT(), which is exported in libjawt 
(via a mapfile), but not in libawt_xawt. I believe it is a mistake to 
include it in libawt_xawt. This will need verification from someone on 
the AWT team.

* All of the awt-related directories (libawt_* and common) include an 
unnecessary extra layer, the "sun" directory. It is not needed anymore, 
and just makes all paths extra long. I suggest that we remove that layer 
and move everything up one step.

* The makefiles include too specific directories. Instead of including 
e.g. ./*/native/common/sun/java2d/opengl and 
./*/native/common/sun/java2d/x11, we should just include 
./*/native/common/sun/java2d. This level corresponds to a logical 
grouping of the source code, and not the directory structure in that 
grouping.

* The file ./windows/native/common/awt_makecube.cpp is a bit strange. It 
is not a shared file; instead it's a stand-alone binary with a main() 
function. It is not compiled by any makefile targets. If this file is 
actually used, I suggest moving it to a better location 
(windows/native/launchers?), and starting to compile it with the build. 
(Stuff that's not built regularly is doomed to bit rot.) It if is not 
used, I suggest we remove it.

* And as I stated before, the medlialib directories are typically not 
used by libawt and friends. It is used by libmlib_image and 
libmlib_image_v, and should move away from the awt directory.

/Magnus

From anthony.petrov at oracle.com  Mon Aug 25 10:25:39 2014
From: anthony.petrov at oracle.com (Anthony Petrov)
Date: Mon, 25 Aug 2014 14:25:39 +0400
Subject: <AWT Dev> RFE: Listeners with Adapter-classes should have empty
 default methods
In-Reply-To: <CAFsBG0B3GX9qYSMzgU4yiemWaRaDisv+tUrHTFCuT798mXkBgg@mail.gmail.com>
References: <CAFsBG0B3GX9qYSMzgU4yiemWaRaDisv+tUrHTFCuT798mXkBgg@mail.gmail.com>
Message-ID: <53FB0F23.5050408@oracle.com>

Hi Andreas,

Yes, in fact Petr has proposed this same enhancement back in January:

http://mail.openjdk.java.net/pipermail/awt-dev/2014-January/006799.html

Do you want to contribute a patch for this RFE? If so, please read this 
document:

http://openjdk.java.net/contribute/

The most important part is to get your OCA signed, after which we can 
accept patches from you.

--
best regards,
Anthony

On 8/24/2014 3:42 AM, Andreas Lundblad wrote:
> For listener interfaces where it's common to just implement one or two
> methods, there are corresponding Adapter classes with empty method
> implementations. (For example: MouseListener/MouseAdapter,
> KeyListener/KeyAdapter, ComponentListener/ComponentAdapter, ...)
>
> The Adapter classes are really convenient for obvious reasons. However,
> due to the constraint of single inheritance, they can't be used together
> with each other. That is, if I want to listen to key presses
> (KeyListener.keyPressed) and mouse clicks (MouseListener.mouseClicked)
> I'm doomed to either
>
>   1) choose to extend one of the adapters and clutter my code with empty
> method implementations for the other, or
>
>   2) Extend the two adapters in two separate classes and instantiate two
> separate listener objects (which gets slightly messy if they need to
> share some state).
>
> Therefor I propose to add empty default implementations for these types
> of listener interfaces. This would allow me to for instance implement
> KeyListener and MouseListener and just override keyPressed and mouseClicked.
>
> Some basic grepping yields the following list:
>
> ComponentListener
> ContainerListener
> DragSourceListener
> DropTargetListener
> FocusListener
> HierarchyBoundsListener
> InternalFrameListener
> KeyListener
> MouseListener
> MouseMotionListener
> PrintJobListener
> WindowListener
>
> best regards,
> Andreas Lundblad

From andreas.lundblad at gmail.com  Mon Aug 25 10:32:05 2014
From: andreas.lundblad at gmail.com (Andreas Lundblad)
Date: Mon, 25 Aug 2014 12:32:05 +0200
Subject: <AWT Dev> RFE: Listeners with Adapter-classes should have empty
 default methods
In-Reply-To: <53FB0F23.5050408@oracle.com>
References: <CAFsBG0B3GX9qYSMzgU4yiemWaRaDisv+tUrHTFCuT798mXkBgg@mail.gmail.com>
	<53FB0F23.5050408@oracle.com>
Message-ID: <CAFsBG0C31hytpn_Uk5MP-tFO88t4_E57Z9DEb4L+Yy4Rycx4bw@mail.gmail.com>

On Mon, Aug 25, 2014 at 12:25 PM, Anthony Petrov <anthony.petrov at oracle.com>
wrote:

> Hi Andreas,
>
> Yes, in fact Petr has proposed this same enhancement back in January:
>
> http://mail.openjdk.java.net/pipermail/awt-dev/2014-January/006799.html
>


Ah, sorry for the duplicate!


>
> Do you want to contribute a patch for this RFE? If so, please read this
> document:
>
> http://openjdk.java.net/contribute/
>
> The most important part is to get your OCA signed, after which we can
> accept patches from you.
>
>
I happen to be a member of the langtools team so the OCA shouldn't be a
problem. I'll let you know if I find the time to contribute with a patch!
:-)

-- Andreas
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20140825/e688530e/attachment.html>

From anthony.petrov at oracle.com  Mon Aug 25 10:38:14 2014
From: anthony.petrov at oracle.com (Anthony Petrov)
Date: Mon, 25 Aug 2014 14:38:14 +0400
Subject: <AWT Dev> RFE: Listeners with Adapter-classes should have empty
 default methods
In-Reply-To: <CAFsBG0C31hytpn_Uk5MP-tFO88t4_E57Z9DEb4L+Yy4Rycx4bw@mail.gmail.com>
References: <CAFsBG0B3GX9qYSMzgU4yiemWaRaDisv+tUrHTFCuT798mXkBgg@mail.gmail.com>	<53FB0F23.5050408@oracle.com>
	<CAFsBG0C31hytpn_Uk5MP-tFO88t4_E57Z9DEb4L+Yy4Rycx4bw@mail.gmail.com>
Message-ID: <53FB1216.3090007@oracle.com>

Sounds good. Thanks!

--
best regards,
Anthony

On 8/25/2014 2:32 PM, Andreas Lundblad wrote:
>
>
>
> On Mon, Aug 25, 2014 at 12:25 PM, Anthony Petrov
> <anthony.petrov at oracle.com <mailto:anthony.petrov at oracle.com>> wrote:
>
>     Hi Andreas,
>
>     Yes, in fact Petr has proposed this same enhancement back in January:
>
>     http://mail.openjdk.java.net/__pipermail/awt-dev/2014-__January/006799.html
>     <http://mail.openjdk.java.net/pipermail/awt-dev/2014-January/006799.html>
>
>
>
> Ah, sorry for the duplicate!
>
>
>     Do you want to contribute a patch for this RFE? If so, please read
>     this document:
>
>     http://openjdk.java.net/__contribute/
>     <http://openjdk.java.net/contribute/>
>
>     The most important part is to get your OCA signed, after which we
>     can accept patches from you.
>
>
> I happen to be a member of the langtools team so the OCA shouldn't be a
> problem. I'll let you know if I find the time to contribute with a
> patch! :-)
>
> -- Andreas

From alexhenrie24 at gmail.com  Mon Aug 25 19:11:25 2014
From: alexhenrie24 at gmail.com (Alex Henrie)
Date: Mon, 25 Aug 2014 13:11:25 -0600
Subject: <AWT Dev> [PATCH] Fix right-click detection in Linux and Solaris
Message-ID: <20140825131125.5481031af7406404aab72f3f@gmail.com>

With this patch applied, only clicks on the mouse's right button and not
clicks to the mouse's forward or back buttons trigger a context menu
(MouseEvent.isPopupTrigger() == true).

Class XWindow tried to map physical mouse buttons to logical mouse
buttons, but this unnecessary because that mapping is already handled
automatically in Xlib:
http://www.x.org/archive/X11R7.5/doc/man/man3/XKeyEvent.3.html

Also, XGetPointerMapping returns the total number of physical mouse
buttons (16 on my computer), not the value of a map entry:
http://www.x.org/archive/X11R7.5/doc/man/man3/XGetPointerMapping.3.html

This JDK bug has to be fixed before
https://netbeans.org/bugzilla/show_bug.cgi?id=198885 can be fixed.

This patch will probably also fix
https://bugs.openjdk.java.net/browse/JDK-6624085

A test program is attached.

This is my first time contributing code to OpenJDK, so if I've done
something wrong, please be nice ;-)

-Alex

diff --git a/src/java.desktop/unix/classes/sun/awt/X11/XWindow.java b/src/java.desktop/unix/classes/sun/awt/X11/XWindow.java
--- a/src/java.desktop/unix/classes/sun/awt/X11/XWindow.java
+++ b/src/java.desktop/unix/classes/sun/awt/X11/XWindow.java
@@ -50,17 +50,16 @@ class XWindow extends XBaseWindow implem
     private static final PlatformLogger focusLog = PlatformLogger.getLogger("sun.awt.X11.focus.XWindow");
     private static PlatformLogger keyEventLog = PlatformLogger.getLogger("sun.awt.X11.kye.XWindow");
   /* If a motion comes in while a multi-click is pending,
    * allow a smudge factor so that moving the mouse by a small
    * amount does not wipe out the multi-click state variables.
    */
     private final static int AWT_MULTICLICK_SMUDGE = 4;
     // ButtonXXX events stuff
-    static int rbutton = 0;
     static int lastX = 0, lastY = 0;
     static long lastTime = 0;
     static long lastButton = 0;
     static WeakReference<XWindow> lastWindowRef = null;
     static int clickCount = 0;
 
     // used to check if we need to re-create surfaceData.
     int oldWidth = -1;
@@ -627,33 +626,16 @@ class XWindow extends XBaseWindow implem
             res |= XToolkit.metaMask;
         }
         if ((mods & (InputEvent.ALT_GRAPH_DOWN_MASK | InputEvent.ALT_GRAPH_MASK)) != 0) {
             res |= XToolkit.modeSwitchMask;
         }
         return res;
     }
 
-    /**
-     * Returns true if this event is disabled and shouldn't be passed to Java.
-     * Default implementation returns false for all events.
-     */
-    static int getRightButtonNumber() {
-        if (rbutton == 0) { // not initialized yet
-            XToolkit.awtLock();
-            try {
-                rbutton = XlibWrapper.XGetPointerMapping(XToolkit.getDisplay(), XlibWrapper.ibuffer, 3);
-            }
-            finally {
-                XToolkit.awtUnlock();
-            }
-        }
-        return rbutton;
-    }
-
     static int getMouseMovementSmudge() {
         //TODO: It's possible to read corresponding settings
         return AWT_MULTICLICK_SMUDGE;
     }
 
     public void handleButtonPressRelease(XEvent xev) {
         super.handleButtonPressRelease(xev);
         XButtonEvent xbe = xev.get_xbutton();
@@ -711,21 +693,17 @@ class XWindow extends XBaseWindow implem
                 lastY = y;
             }
             lastTime = when;
 
 
             /*
                Check for popup trigger !!
             */
-            if (lbutton == getRightButtonNumber() || lbutton > 2) {
-                popupTrigger = true;
-            } else {
-                popupTrigger = false;
-            }
+            popupTrigger = (lbutton == 3);
         }
 
         button = XConstants.buttons[lbutton - 1];
         // 4 and 5 buttons are usually considered assigned to a first wheel
         if (lbutton == XConstants.buttons[3] ||
             lbutton == XConstants.buttons[4]) {
             wheel_mouse = true;
         }
-------------- next part --------------
A non-text attachment was scrubbed...
Name: MouseDebug.tar.xz
Type: application/octet-stream
Size: 13260 bytes
Desc: not available
URL: <http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20140825/714f34ec/MouseDebug.tar-0001.xz>

From yuri.nesterenko at oracle.com  Tue Aug 26 06:42:59 2014
From: yuri.nesterenko at oracle.com (Yuri Nesterenko)
Date: Tue, 26 Aug 2014 10:42:59 +0400
Subject: <AWT Dev> [9] Review request for 8055664: move 14 tests about
 setLocationRelativeTo to jdk
In-Reply-To: <53F48FF1.3070304@oracle.com>
References: <53F48FF1.3070304@oracle.com>
Message-ID: <53FC2C73.4060702@oracle.com>

A polite reminder!


On 08/20/2014 04:09 PM, Yuri Nesterenko wrote:
> Hi team,
>
> please review this test update in jdk9:
>
> http://cr.openjdk.java.net/~yan/8055664/webrev.00
>
> ( https://bugs.openjdk.java.net/browse/JDK-8055664 )
>
> There's a single test made out of 14 old internal functional tests.
> Existing tests do verify that a Frame (Dialog, JFrame etc.
> toplevel) does setLocationRelativeTo(Component) right.
>
> As the number of components * toplevels is rather big,
> the test picks randomly just few of them from the lists.
> If by chance there will be a failure, a simple option would
> allow to run all combinations.
> Also, if we'll have a "switch" controlling this selection
> behavior, we'll use it here.
>
> Thanks,
> -yan


From dmitriy.ermashov at oracle.com  Tue Aug 26 13:40:53 2014
From: dmitriy.ermashov at oracle.com (Dmitriy Ermashov)
Date: Tue, 26 Aug 2014 17:40:53 +0400
Subject: <AWT Dev> Review Request for 8039749: Migrate needed functionality
 from all subclasses of java.awt.Robot in jdk/test directory to the ancestor
Message-ID: <53FC8E65.8060208@oracle.com>

Hi awt team!

A few months ago we have consolidated methods required by functional and 
regression tests in ExtendedRobot class. After a period of extensive 
testing, it's time to migrate them to java.awt.Robot.

Please review the changeset:
http://cr.openjdk.java.net/~dermashov/8039749/webrev.00/

Corresponding bug:
https://bugs.openjdk.java.net/browse/JDK-8039749

Note that this change is an important prerequisite to a massive 
regression and functional test suites change for Jigsaw.
As one can see the webrev contains changes in class signature. The CCC 
request will take place after the code review.

Thanks,
Dima
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20140826/96e22e50/attachment.html>

From anthony.petrov at oracle.com  Wed Aug 27 10:57:29 2014
From: anthony.petrov at oracle.com (Anthony Petrov)
Date: Wed, 27 Aug 2014 14:57:29 +0400
Subject: <AWT Dev> RFR [9] Modular Source Code
In-Reply-To: <53FAFE5C.2060600@oracle.com>
References: <3132CBA0-5920-4DDA-8E69-308D5492F0DD@oracle.com>	<53EDCA54.2090107@oracle.com>
	<53EDDD47.2010204@oracle.com> <53F203EF.9070907@oracle.com>
	<53F20A6C.7090805@oracle.com> <53F466E2.7070501@oracle.com>
	<53FAFE5C.2060600@oracle.com>
Message-ID: <53FDB999.3030001@oracle.com>

Hi Magnus,

Those look like reasonable suggestions. Could you please file separate 
bugs for each of these issues? Also, please note that most of them 
belong to 2D, not AWT (e.g. the font-, color-, d3d-, and opengl-related 
files) even though they're compiled into the awt native libraries.

--
best regards,
Anthony

On 8/25/2014 1:14 PM, Magnus Ihse Bursie wrote:
> On 2014-08-20 11:14, Magnus Ihse Bursie wrote:
>> On 2014-08-18 16:15, Anthony Petrov wrote:
>>> So I'm not sure if the current set of AWT libraries could be
>>> simplified any further.
>>>
>>> Hope this helps.
>>
>> Thank you for the clarification, it was very helpful!
>>
>> While the set of AWT libraries probably cannot be simplified as you
>> say, my gut feeling is still that the current layout of files on disk
>> does not optimally match the actual libraries we build. Armed with the
>> help of your description, I'll look into them once again and see if I
>> can make that statement more concrete.
>
> This is my suggestions based on what I found when trying to remove the
> last unnecessary entanglement. Note that all paths are relative to the
> java.desktop module, and  that I have at this stage only looked at
> compiled sources (*.c), not header files.
>
> * The following files are in the windows directory tree, but are
> explicitly excluded on Windows. Thus they will never be built, and
> should be removed instead:
>    ./windows/native/libawt/sun/java2d/d3d/D3DPipeline.cpp
>    ./windows/native/libawt/sun/java2d/d3d/D3DShaderGen.c
>    ./windows/native/libawt/sun/windows/WBufferStrategy.cpp
>
> * The following file is in the share directory tree, but is only used on
> Windows. It should be moved to the corresponding windows directory instead:
>    ./share/native/libawt/sun/java2d/ShaderList.c
>
> * The following directory is in the unix directory tree, but is only
> used on Solaris. It should be moved to the corresponding solaris
> directory instead:
>    ./unix/native/libawt/sun/java2d/loops
>
> * The directory ./unix/native/common/sun/awt contains five more or less
> unrelated .c files. Three of them are only used in libawt_xawt, and
> should be moved there:
>    ./unix/native/common/sun/awt/awt_Font.c
>    ./unix/native/common/sun/awt/fontpath.c
>    ./unix/native/common/sun/awt/X11Color.c
> Of the remaining two CUPSfuncs.c seems correctly placed, since it is
> shared between libawt_xawt and libawt_lwawt. However, I'm wondering
> about initIDs.c. It is compiled in libawt as well as libawt_xawt, but
> when I checked some random functions, they are exported (via the
> mapfile) for libawt only. So I believe it is a mistake to include it in
> libawt_xawt, and that it should be moved to the libawt directory. This
> will need verification from someone on the AWT team.
>
> * The directory ./unix/native/libjawt is included in libawt_xawt (and in
> libjawt, of course). This seems suspicious to me. There is just a single
> file with a single function, JAWT_GetAWT(), which is exported in libjawt
> (via a mapfile), but not in libawt_xawt. I believe it is a mistake to
> include it in libawt_xawt. This will need verification from someone on
> the AWT team.
>
> * All of the awt-related directories (libawt_* and common) include an
> unnecessary extra layer, the "sun" directory. It is not needed anymore,
> and just makes all paths extra long. I suggest that we remove that layer
> and move everything up one step.
>
> * The makefiles include too specific directories. Instead of including
> e.g. ./*/native/common/sun/java2d/opengl and
> ./*/native/common/sun/java2d/x11, we should just include
> ./*/native/common/sun/java2d. This level corresponds to a logical
> grouping of the source code, and not the directory structure in that
> grouping.
>
> * The file ./windows/native/common/awt_makecube.cpp is a bit strange. It
> is not a shared file; instead it's a stand-alone binary with a main()
> function. It is not compiled by any makefile targets. If this file is
> actually used, I suggest moving it to a better location
> (windows/native/launchers?), and starting to compile it with the build.
> (Stuff that's not built regularly is doomed to bit rot.) It if is not
> used, I suggest we remove it.
>
> * And as I stated before, the medlialib directories are typically not
> used by libawt and friends. It is used by libmlib_image and
> libmlib_image_v, and should move away from the awt directory.
>
> /Magnus

From anthony.petrov at oracle.com  Wed Aug 27 11:16:32 2014
From: anthony.petrov at oracle.com (Anthony Petrov)
Date: Wed, 27 Aug 2014 15:16:32 +0400
Subject: <AWT Dev> Review Request for 8039749: Migrate needed
 functionality from all subclasses of java.awt.Robot in jdk/test directory
 to the ancestor
In-Reply-To: <53FC8E65.8060208@oracle.com>
References: <53FC8E65.8060208@oracle.com>
Message-ID: <53FDBE10.8050701@oracle.com>

Hi Dmitriy,

While I realize that all the new methods are useful when writing JDK 
regression tests, do you have any evidence that would suggest that these 
same methods could be useful to and/or have been requested by external 
developers? All of them look like convenient APIs and I'm not entirely 
convinced if we should ultimately add them all to our public Robot API. 
Personally, I don't see a problem with using the custom ExtendedRobot 
class specifically for tests. This also helps reduce the JDK and JRE 
static footprints, btw. But then again, I'm not an SQE engineer.

I don't have a strong opinion on this and I'm leaving the final decision 
to Sergey and other AWT team members, but I just thought I'd bring this 
up here.

As for the implementation, I see that you're adding realSync() calls in 
some places where they were not previously there. For example, calling 
Robot.waitForIdle() before the fix would not cause a realSync() to 
occur, while after your fix it does. This is a significant change from 
threading and native event queue synchronization perspectives, and I'm 
not sure if this should be done. Again, I do know that in tests it is 
useful to call realSync() here and there, but I'm not sure we should 
spread the calls all over the Robot implementation simply because of 
this reason. The calls may in fact produce some unwanted side-effects 
for existing applications employing the Robot (e.g. introducing unwanted 
delays, or performing excessive synchronization while the app didn't 
really need it, etc.) I consider this change very risky.

--
best regards,
Anthony

On 8/26/2014 5:40 PM, Dmitriy Ermashov wrote:
> Hi awt team!
>
> A few months ago we have consolidated methods required by functional and
> regression tests in ExtendedRobot class. After a period of extensive
> testing, it's time to migrate them to java.awt.Robot.
>
> Please review the changeset:
> http://cr.openjdk.java.net/~dermashov/8039749/webrev.00/
>
> Corresponding bug:
> https://bugs.openjdk.java.net/browse/JDK-8039749
>
> Note that this change is an important prerequisite to a massive
> regression and functional test suites change for Jigsaw.
> As one can see the webrev contains changes in class signature. The CCC
> request will take place after the code review.
>
> Thanks,
> Dima

From Alan.Bateman at oracle.com  Wed Aug 27 11:17:27 2014
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Wed, 27 Aug 2014 12:17:27 +0100
Subject: <AWT Dev> RFR [9] Modular Source Code
In-Reply-To: <53FDB999.3030001@oracle.com>
References: <3132CBA0-5920-4DDA-8E69-308D5492F0DD@oracle.com>	<53EDCA54.2090107@oracle.com>	<53EDDD47.2010204@oracle.com>
	<53F203EF.9070907@oracle.com>	<53F20A6C.7090805@oracle.com>
	<53F466E2.7070501@oracle.com>	<53FAFE5C.2060600@oracle.com>
	<53FDB999.3030001@oracle.com>
Message-ID: <53FDBE47.3000701@oracle.com>

On 27/08/2014 11:57, Anthony Petrov wrote:
> Hi Magnus,
>
> Those look like reasonable suggestions. Could you please file separate 
> bugs for each of these issues? Also, please note that most of them 
> belong to 2D, not AWT (e.g. the font-, color-, d3d-, and 
> opengl-related files) even though they're compiled into the awt native 
> libraries.
>
> -- 
> best regards,
> Anthony
Just to add to Magnus' list, there are a few additional AWT and 
libmlib_image source files listed in JDK-8047931 that should be examined 
too.

-Alan.

From dmitriy.ermashov at oracle.com  Wed Aug 27 12:25:15 2014
From: dmitriy.ermashov at oracle.com (Dmitriy Ermashov)
Date: Wed, 27 Aug 2014 16:25:15 +0400
Subject: <AWT Dev> Review Request for 8039749: Migrate needed
 functionality from all subclasses of java.awt.Robot in jdk/test directory
 to the ancestor
In-Reply-To: <53FDBE10.8050701@oracle.com>
References: <53FC8E65.8060208@oracle.com> <53FDBE10.8050701@oracle.com>
Message-ID: <53FDCE2B.3000202@oracle.com>

Hi Anthony,

Thanks for your review.

At first, let me focus on fact that the actual motivation of moving 
functionality to java.awt.Robot is the Jigsaw project. We (SQE) will be 
unable to use internal java API after the project will be finished 
(ExtendedRobot just will not compile, for example) and it will be a 
reason of failing huge amount of regression and functional tests.

As for waitForIdle() method, we do not change it's use-case. The 
java.awt.Robot class is used only for GUI actions. And waitForIdle() is 
used for ensuring of finishing all events in EventQueue.
The implementation with realSync() just flushes native queue as well and 
it is just an improved version of existing one.

Anyway, the changing of waitForIdle() implementation is discussable. The 
other solution may be in adding new method with realSync call.

Thanks,
Dima

On 08/27/2014 03:16 PM, Anthony Petrov wrote:
> Hi Dmitriy,
>
> While I realize that all the new methods are useful when writing JDK 
> regression tests, do you have any evidence that would suggest that 
> these same methods could be useful to and/or have been requested by 
> external developers? All of them look like convenient APIs and I'm not 
> entirely convinced if we should ultimately add them all to our public 
> Robot API. Personally, I don't see a problem with using the custom 
> ExtendedRobot class specifically for tests. This also helps reduce the 
> JDK and JRE static footprints, btw. But then again, I'm not an SQE 
> engineer.
>
> I don't have a strong opinion on this and I'm leaving the final 
> decision to Sergey and other AWT team members, but I just thought I'd 
> bring this up here.
>
> As for the implementation, I see that you're adding realSync() calls 
> in some places where they were not previously there. For example, 
> calling Robot.waitForIdle() before the fix would not cause a 
> realSync() to occur, while after your fix it does. This is a 
> significant change from threading and native event queue 
> synchronization perspectives, and I'm not sure if this should be done. 
> Again, I do know that in tests it is useful to call realSync() here 
> and there, but I'm not sure we should spread the calls all over the 
> Robot implementation simply because of this reason. The calls may in 
> fact produce some unwanted side-effects for existing applications 
> employing the Robot (e.g. introducing unwanted delays, or performing 
> excessive synchronization while the app didn't really need it, etc.) I 
> consider this change very risky.
>
> -- 
> best regards,
> Anthony
>
> On 8/26/2014 5:40 PM, Dmitriy Ermashov wrote:
>> Hi awt team!
>>
>> A few months ago we have consolidated methods required by functional and
>> regression tests in ExtendedRobot class. After a period of extensive
>> testing, it's time to migrate them to java.awt.Robot.
>>
>> Please review the changeset:
>> http://cr.openjdk.java.net/~dermashov/8039749/webrev.00/
>>
>> Corresponding bug:
>> https://bugs.openjdk.java.net/browse/JDK-8039749
>>
>> Note that this change is an important prerequisite to a massive
>> regression and functional test suites change for Jigsaw.
>> As one can see the webrev contains changes in class signature. The CCC
>> request will take place after the code review.
>>
>> Thanks,
>> Dima


From yuri.nesterenko at oracle.com  Wed Aug 27 12:54:50 2014
From: yuri.nesterenko at oracle.com (Yuri Nesterenko)
Date: Wed, 27 Aug 2014 16:54:50 +0400
Subject: <AWT Dev> Review Request for 8039749: Migrate needed
 functionality from all subclasses of java.awt.Robot in jdk/test directory
 to the ancestor
In-Reply-To: <53FDCE2B.3000202@oracle.com>
References: <53FC8E65.8060208@oracle.com> <53FDBE10.8050701@oracle.com>
	<53FDCE2B.3000202@oracle.com>
Message-ID: <53FDD51A.2080800@oracle.com>

On 08/27/2014 04:25 PM, Dmitriy Ermashov wrote:
> Hi Anthony,
>
> Thanks for your review.
>
> At first, let me focus on fact that the actual motivation of moving
> functionality to java.awt.Robot is the Jigsaw project. We (SQE) will be
> unable to use internal java API after the project will be finished
> (ExtendedRobot just will not compile, for example) and it will be a
> reason of failing huge amount of regression and functional tests.
>
> As for waitForIdle() method, we do not change it's use-case. The
> java.awt.Robot class is used only for GUI actions. And waitForIdle() is
> used for ensuring of finishing all events in EventQueue.
> The implementation with realSync() just flushes native queue as well and
> it is just an improved version of existing one.
>
> Anyway, the changing of waitForIdle() implementation is discussable. The
> other solution may be in adding new method with realSync call.

Which would require touching some 340 tests in apprx 950 places, sorry
for statistics.

-yan

>
> Thanks,
> Dima
>
> On 08/27/2014 03:16 PM, Anthony Petrov wrote:
>> Hi Dmitriy,
>>
>> While I realize that all the new methods are useful when writing JDK
>> regression tests, do you have any evidence that would suggest that
>> these same methods could be useful to and/or have been requested by
>> external developers? All of them look like convenient APIs and I'm not
>> entirely convinced if we should ultimately add them all to our public
>> Robot API. Personally, I don't see a problem with using the custom
>> ExtendedRobot class specifically for tests. This also helps reduce the
>> JDK and JRE static footprints, btw. But then again, I'm not an SQE
>> engineer.
>>
>> I don't have a strong opinion on this and I'm leaving the final
>> decision to Sergey and other AWT team members, but I just thought I'd
>> bring this up here.
>>
>> As for the implementation, I see that you're adding realSync() calls
>> in some places where they were not previously there. For example,
>> calling Robot.waitForIdle() before the fix would not cause a
>> realSync() to occur, while after your fix it does. This is a
>> significant change from threading and native event queue
>> synchronization perspectives, and I'm not sure if this should be done.
>> Again, I do know that in tests it is useful to call realSync() here
>> and there, but I'm not sure we should spread the calls all over the
>> Robot implementation simply because of this reason. The calls may in
>> fact produce some unwanted side-effects for existing applications
>> employing the Robot (e.g. introducing unwanted delays, or performing
>> excessive synchronization while the app didn't really need it, etc.) I
>> consider this change very risky.
>>
>> --
>> best regards,
>> Anthony
>>
>> On 8/26/2014 5:40 PM, Dmitriy Ermashov wrote:
>>> Hi awt team!
>>>
>>> A few months ago we have consolidated methods required by functional and
>>> regression tests in ExtendedRobot class. After a period of extensive
>>> testing, it's time to migrate them to java.awt.Robot.
>>>
>>> Please review the changeset:
>>> http://cr.openjdk.java.net/~dermashov/8039749/webrev.00/
>>>
>>> Corresponding bug:
>>> https://bugs.openjdk.java.net/browse/JDK-8039749
>>>
>>> Note that this change is an important prerequisite to a massive
>>> regression and functional test suites change for Jigsaw.
>>> As one can see the webrev contains changes in class signature. The CCC
>>> request will take place after the code review.
>>>
>>> Thanks,
>>> Dima
>


From alexander.zvegintsev at oracle.com  Wed Aug 27 16:31:55 2014
From: alexander.zvegintsev at oracle.com (Alexander Zvegintsev)
Date: Wed, 27 Aug 2014 20:31:55 +0400
Subject: <AWT Dev> [9] Review request for 6624085: Fourth mouse button
 (wheel) is treated like second button - isPopupTrigger returns true
In-Reply-To: <20140825131125.5481031af7406404aab72f3f@gmail.com>
References: <20140825131125.5481031af7406404aab72f3f@gmail.com>
Message-ID: <53FE07FB.7020300@oracle.com>

Hello Alex,

You are welcome and I am glad to see your contribution to OpenJDK project.

Your fix looks good to me, it resolves JDK-6624085 issue too, so let it 
be fixed under this bug ID.
As I can see in jdk9-dev mailing list OCA has been signed by you, so no 
further action is required from your side at this moment.

But we still need a second reviewer to proceed (I've uploaded a webrev 
for convenience [1]).

[1] http://cr.openjdk.java.net/~azvegint/oca/6624085/

Thanks,

Alexander.

On 08/25/2014 11:11 PM, Alex Henrie wrote:
> With this patch applied, only clicks on the mouse's right button and not
> clicks to the mouse's forward or back buttons trigger a context menu
> (MouseEvent.isPopupTrigger() == true).
>
> Class XWindow tried to map physical mouse buttons to logical mouse
> buttons, but this unnecessary because that mapping is already handled
> automatically in Xlib:
> http://www.x.org/archive/X11R7.5/doc/man/man3/XKeyEvent.3.html
>
> Also, XGetPointerMapping returns the total number of physical mouse
> buttons (16 on my computer), not the value of a map entry:
> http://www.x.org/archive/X11R7.5/doc/man/man3/XGetPointerMapping.3.html
>
> This JDK bug has to be fixed before
> https://netbeans.org/bugzilla/show_bug.cgi?id=198885 can be fixed.
>
> This patch will probably also fix
> https://bugs.openjdk.java.net/browse/JDK-6624085
>
> A test program is attached.
>
> This is my first time contributing code to OpenJDK, so if I've done
> something wrong, please be nice ;-)
>
> -Alex
>
> diff --git a/src/java.desktop/unix/classes/sun/awt/X11/XWindow.java b/src/java.desktop/unix/classes/sun/awt/X11/XWindow.java
> --- a/src/java.desktop/unix/classes/sun/awt/X11/XWindow.java
> +++ b/src/java.desktop/unix/classes/sun/awt/X11/XWindow.java
> @@ -50,17 +50,16 @@ class XWindow extends XBaseWindow implem
>       private static final PlatformLogger focusLog = PlatformLogger.getLogger("sun.awt.X11.focus.XWindow");
>       private static PlatformLogger keyEventLog = PlatformLogger.getLogger("sun.awt.X11.kye.XWindow");
>     /* If a motion comes in while a multi-click is pending,
>      * allow a smudge factor so that moving the mouse by a small
>      * amount does not wipe out the multi-click state variables.
>      */
>       private final static int AWT_MULTICLICK_SMUDGE = 4;
>       // ButtonXXX events stuff
> -    static int rbutton = 0;
>       static int lastX = 0, lastY = 0;
>       static long lastTime = 0;
>       static long lastButton = 0;
>       static WeakReference<XWindow> lastWindowRef = null;
>       static int clickCount = 0;
>   
>       // used to check if we need to re-create surfaceData.
>       int oldWidth = -1;
> @@ -627,33 +626,16 @@ class XWindow extends XBaseWindow implem
>               res |= XToolkit.metaMask;
>           }
>           if ((mods & (InputEvent.ALT_GRAPH_DOWN_MASK | InputEvent.ALT_GRAPH_MASK)) != 0) {
>               res |= XToolkit.modeSwitchMask;
>           }
>           return res;
>       }
>   
> -    /**
> -     * Returns true if this event is disabled and shouldn't be passed to Java.
> -     * Default implementation returns false for all events.
> -     */
> -    static int getRightButtonNumber() {
> -        if (rbutton == 0) { // not initialized yet
> -            XToolkit.awtLock();
> -            try {
> -                rbutton = XlibWrapper.XGetPointerMapping(XToolkit.getDisplay(), XlibWrapper.ibuffer, 3);
> -            }
> -            finally {
> -                XToolkit.awtUnlock();
> -            }
> -        }
> -        return rbutton;
> -    }
> -
>       static int getMouseMovementSmudge() {
>           //TODO: It's possible to read corresponding settings
>           return AWT_MULTICLICK_SMUDGE;
>       }
>   
>       public void handleButtonPressRelease(XEvent xev) {
>           super.handleButtonPressRelease(xev);
>           XButtonEvent xbe = xev.get_xbutton();
> @@ -711,21 +693,17 @@ class XWindow extends XBaseWindow implem
>                   lastY = y;
>               }
>               lastTime = when;
>   
>   
>               /*
>                  Check for popup trigger !!
>               */
> -            if (lbutton == getRightButtonNumber() || lbutton > 2) {
> -                popupTrigger = true;
> -            } else {
> -                popupTrigger = false;
> -            }
> +            popupTrigger = (lbutton == 3);
>           }
>   
>           button = XConstants.buttons[lbutton - 1];
>           // 4 and 5 buttons are usually considered assigned to a first wheel
>           if (lbutton == XConstants.buttons[3] ||
>               lbutton == XConstants.buttons[4]) {
>               wheel_mouse = true;
>           }


From alexey.ivanov at oracle.com  Thu Aug 28 07:29:28 2014
From: alexey.ivanov at oracle.com (Alexey Ivanov)
Date: Thu, 28 Aug 2014 11:29:28 +0400
Subject: <AWT Dev> [7u-dev] Request for Approval and Review: 8056156:
 [TEST_BUG] Test javax/swing/JFileChooser/8046391/bug8046391.java fails in
 Windows
Message-ID: <53FEDA58.4030105@oracle.com>

Hello,

Could you please approve the fix of the test in jdk7u-dev?

Could you please review the fix?

   webrev: http://cr.openjdk.java.net/~aivanov/8056156/jdk7/webrev.00/
   JBS: https://bugs.openjdk.java.net/browse/JDK-8056156

Description:
The test fails to compile under jdk7 because of lambda expression.

The fix:
Convert lambda expression to anonymous class.


Thank you in advance,
Alexey.

From anthony.petrov at oracle.com  Thu Aug 28 07:30:53 2014
From: anthony.petrov at oracle.com (Anthony Petrov)
Date: Thu, 28 Aug 2014 11:30:53 +0400
Subject: <AWT Dev> [7u-dev] Request for Approval and Review: 8056156:
 [TEST_BUG] Test javax/swing/JFileChooser/8046391/bug8046391.java fails in
 Windows
In-Reply-To: <53FEDA58.4030105@oracle.com>
References: <53FEDA58.4030105@oracle.com>
Message-ID: <53FEDAAD.9060104@oracle.com>

Hi Alexey,

The fix looks fine.

--
best regards,
Anthony

On 8/28/2014 11:29 AM, Alexey Ivanov wrote:
> Hello,
>
> Could you please approve the fix of the test in jdk7u-dev?
>
> Could you please review the fix?
>
>    webrev: http://cr.openjdk.java.net/~aivanov/8056156/jdk7/webrev.00/
>    JBS: https://bugs.openjdk.java.net/browse/JDK-8056156
>
> Description:
> The test fails to compile under jdk7 because of lambda expression.
>
> The fix:
> Convert lambda expression to anonymous class.
>
>
> Thank you in advance,
> Alexey.

From anthony.petrov at oracle.com  Thu Aug 28 08:09:45 2014
From: anthony.petrov at oracle.com (Anthony Petrov)
Date: Thu, 28 Aug 2014 12:09:45 +0400
Subject: <AWT Dev> Review Request for 8039749: Migrate needed
 functionality from all subclasses of java.awt.Robot in jdk/test directory
 to the ancestor
In-Reply-To: <53FDD51A.2080800@oracle.com>
References: <53FC8E65.8060208@oracle.com>
	<53FDBE10.8050701@oracle.com>	<53FDCE2B.3000202@oracle.com>
	<53FDD51A.2080800@oracle.com>
Message-ID: <53FEE3C9.7090105@oracle.com>

Hi Dmitriy, Yuri,

On 8/27/2014 4:54 PM, Yuri Nesterenko wrote:
> On 08/27/2014 04:25 PM, Dmitriy Ermashov wrote:
>> At first, let me focus on fact that the actual motivation of moving
>> functionality to java.awt.Robot is the Jigsaw project. We (SQE) will be
>> unable to use internal java API after the project will be finished
>> (ExtendedRobot just will not compile, for example) and it will be a
>> reason of failing huge amount of regression and functional tests.

Could you please clarify as to why it won't compile? IIUC, all the GUI 
tests that require Robot will be in a single module (the java.desktop 
one I suppose?), so why wouldn't ExtendedRobot compile while the tests 
themselves would if they all are located in the same module?


>> As for waitForIdle() method, we do not change it's use-case. The
>> java.awt.Robot class is used only for GUI actions. And waitForIdle() is
>> used for ensuring of finishing all events in EventQueue.
>> The implementation with realSync() just flushes native queue as well and
>> it is just an improved version of existing one.
>>
>> Anyway, the changing of waitForIdle() implementation is discussable. The
>> other solution may be in adding new method with realSync call.
>
> Which would require touching some 340 tests in apprx 950 places, sorry
> for statistics.

Yes, I realize that some changes will be needed for this. My concern is 
that having realSync() being called unconditionally from an existing 
public method may have an impact on existing applications that use the 
Robot for tasks other than testing (e.g. for simple automation tasks, 
etc.) And I'm not sure if we're able to estimate all the potential side 
effects that this change can bring.

Again, if the tests go into the java.desktop module, then I don't see a 
problem with calling realSync() from sun.awt.SunToolkit directly as you 
did before. If this is not the case, then I think I'd prefer to 
introduce a separate single public method in the Toolkit (or Robot?) 
class that would allow applications (and tests) to actually perform the 
realSync() operation.

--
best regards,
Anthony

>
> -yan
>
>>
>> Thanks,
>> Dima
>>
>> On 08/27/2014 03:16 PM, Anthony Petrov wrote:
>>> Hi Dmitriy,
>>>
>>> While I realize that all the new methods are useful when writing JDK
>>> regression tests, do you have any evidence that would suggest that
>>> these same methods could be useful to and/or have been requested by
>>> external developers? All of them look like convenient APIs and I'm not
>>> entirely convinced if we should ultimately add them all to our public
>>> Robot API. Personally, I don't see a problem with using the custom
>>> ExtendedRobot class specifically for tests. This also helps reduce the
>>> JDK and JRE static footprints, btw. But then again, I'm not an SQE
>>> engineer.
>>>
>>> I don't have a strong opinion on this and I'm leaving the final
>>> decision to Sergey and other AWT team members, but I just thought I'd
>>> bring this up here.
>>>
>>> As for the implementation, I see that you're adding realSync() calls
>>> in some places where they were not previously there. For example,
>>> calling Robot.waitForIdle() before the fix would not cause a
>>> realSync() to occur, while after your fix it does. This is a
>>> significant change from threading and native event queue
>>> synchronization perspectives, and I'm not sure if this should be done.
>>> Again, I do know that in tests it is useful to call realSync() here
>>> and there, but I'm not sure we should spread the calls all over the
>>> Robot implementation simply because of this reason. The calls may in
>>> fact produce some unwanted side-effects for existing applications
>>> employing the Robot (e.g. introducing unwanted delays, or performing
>>> excessive synchronization while the app didn't really need it, etc.) I
>>> consider this change very risky.
>>>
>>> --
>>> best regards,
>>> Anthony
>>>
>>> On 8/26/2014 5:40 PM, Dmitriy Ermashov wrote:
>>>> Hi awt team!
>>>>
>>>> A few months ago we have consolidated methods required by functional
>>>> and
>>>> regression tests in ExtendedRobot class. After a period of extensive
>>>> testing, it's time to migrate them to java.awt.Robot.
>>>>
>>>> Please review the changeset:
>>>> http://cr.openjdk.java.net/~dermashov/8039749/webrev.00/
>>>>
>>>> Corresponding bug:
>>>> https://bugs.openjdk.java.net/browse/JDK-8039749
>>>>
>>>> Note that this change is an important prerequisite to a massive
>>>> regression and functional test suites change for Jigsaw.
>>>> As one can see the webrev contains changes in class signature. The CCC
>>>> request will take place after the code review.
>>>>
>>>> Thanks,
>>>> Dima
>>
>

From sean.coffey at oracle.com  Thu Aug 28 08:30:16 2014
From: sean.coffey at oracle.com (=?UTF-8?B?U2XDoW4gQ29mZmV5?=)
Date: Thu, 28 Aug 2014 09:30:16 +0100
Subject: <AWT Dev> [7u-dev] Request for Approval and Review: 8056156:
 [TEST_BUG] Test javax/swing/JFileChooser/8046391/bug8046391.java fails in
 Windows
In-Reply-To: <53FEDAAD.9060104@oracle.com>
References: <53FEDA58.4030105@oracle.com> <53FEDAAD.9060104@oracle.com>
Message-ID: <53FEE898.2070609@oracle.com>

Approved.

regards,
Sean.

On 28/08/2014 08:30, Anthony Petrov wrote:
> Hi Alexey,
>
> The fix looks fine.
>
> -- 
> best regards,
> Anthony
>
> On 8/28/2014 11:29 AM, Alexey Ivanov wrote:
>> Hello,
>>
>> Could you please approve the fix of the test in jdk7u-dev?
>>
>> Could you please review the fix?
>>
>>    webrev: http://cr.openjdk.java.net/~aivanov/8056156/jdk7/webrev.00/
>>    JBS: https://bugs.openjdk.java.net/browse/JDK-8056156
>>
>> Description:
>> The test fails to compile under jdk7 because of lambda expression.
>>
>> The fix:
>> Convert lambda expression to anonymous class.
>>
>>
>> Thank you in advance,
>> Alexey.


From magnus.ihse.bursie at oracle.com  Thu Aug 28 09:00:05 2014
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Thu, 28 Aug 2014 11:00:05 +0200
Subject: <AWT Dev> RFR [9] Modular Source Code
In-Reply-To: <53FDB999.3030001@oracle.com>
References: <3132CBA0-5920-4DDA-8E69-308D5492F0DD@oracle.com>	<53EDCA54.2090107@oracle.com>
	<53EDDD47.2010204@oracle.com> <53F203EF.9070907@oracle.com>
	<53F20A6C.7090805@oracle.com> <53F466E2.7070501@oracle.com>
	<53FAFE5C.2060600@oracle.com> <53FDB999.3030001@oracle.com>
Message-ID: <53FEEF95.5000702@oracle.com>

On 2014-08-27 12:57, Anthony Petrov wrote:
> Hi Magnus,
>
> Those look like reasonable suggestions. Could you please file separate 
> bugs for each of these issues? Also, please note that most of them 
> belong to 2D, not AWT (e.g. the font-, color-, d3d-, and 
> opengl-related files) even though they're compiled into the awt native 
> libraries.

I created JDK-8056209, JDK-8056210, JDK-8056212, JDK-8056213, 
JDK-8056214, JDK-8056215, JDK-8056216 and JDK-8056217 for these. After 
some consideration, I choose to put them on the infrastructure/build 
category, since I believe the build part (changes to the makefiles) 
requires most of the work (compared to e.g. removing a file), and that 
we are probably more keen on having them solved :), but they need to be 
resolved in cooperation with the 2D team.

The issue regarding the medialib directories was already reported in 
JDK-8055190.

/Magnus


>
> -- 
> best regards,
> Anthony
>
> On 8/25/2014 1:14 PM, Magnus Ihse Bursie wrote:
>> On 2014-08-20 11:14, Magnus Ihse Bursie wrote:
>>> On 2014-08-18 16:15, Anthony Petrov wrote:
>>>> So I'm not sure if the current set of AWT libraries could be
>>>> simplified any further.
>>>>
>>>> Hope this helps.
>>>
>>> Thank you for the clarification, it was very helpful!
>>>
>>> While the set of AWT libraries probably cannot be simplified as you
>>> say, my gut feeling is still that the current layout of files on disk
>>> does not optimally match the actual libraries we build. Armed with the
>>> help of your description, I'll look into them once again and see if I
>>> can make that statement more concrete.
>>
>> This is my suggestions based on what I found when trying to remove the
>> last unnecessary entanglement. Note that all paths are relative to the
>> java.desktop module, and  that I have at this stage only looked at
>> compiled sources (*.c), not header files.
>>
>> * The following files are in the windows directory tree, but are
>> explicitly excluded on Windows. Thus they will never be built, and
>> should be removed instead:
>>    ./windows/native/libawt/sun/java2d/d3d/D3DPipeline.cpp
>>    ./windows/native/libawt/sun/java2d/d3d/D3DShaderGen.c
>>    ./windows/native/libawt/sun/windows/WBufferStrategy.cpp
>>
>> * The following file is in the share directory tree, but is only used on
>> Windows. It should be moved to the corresponding windows directory 
>> instead:
>>    ./share/native/libawt/sun/java2d/ShaderList.c
>>
>> * The following directory is in the unix directory tree, but is only
>> used on Solaris. It should be moved to the corresponding solaris
>> directory instead:
>>    ./unix/native/libawt/sun/java2d/loops
>>
>> * The directory ./unix/native/common/sun/awt contains five more or less
>> unrelated .c files. Three of them are only used in libawt_xawt, and
>> should be moved there:
>>    ./unix/native/common/sun/awt/awt_Font.c
>>    ./unix/native/common/sun/awt/fontpath.c
>>    ./unix/native/common/sun/awt/X11Color.c
>> Of the remaining two CUPSfuncs.c seems correctly placed, since it is
>> shared between libawt_xawt and libawt_lwawt. However, I'm wondering
>> about initIDs.c. It is compiled in libawt as well as libawt_xawt, but
>> when I checked some random functions, they are exported (via the
>> mapfile) for libawt only. So I believe it is a mistake to include it in
>> libawt_xawt, and that it should be moved to the libawt directory. This
>> will need verification from someone on the AWT team.
>>
>> * The directory ./unix/native/libjawt is included in libawt_xawt (and in
>> libjawt, of course). This seems suspicious to me. There is just a single
>> file with a single function, JAWT_GetAWT(), which is exported in libjawt
>> (via a mapfile), but not in libawt_xawt. I believe it is a mistake to
>> include it in libawt_xawt. This will need verification from someone on
>> the AWT team.
>>
>> * All of the awt-related directories (libawt_* and common) include an
>> unnecessary extra layer, the "sun" directory. It is not needed anymore,
>> and just makes all paths extra long. I suggest that we remove that layer
>> and move everything up one step.
>>
>> * The makefiles include too specific directories. Instead of including
>> e.g. ./*/native/common/sun/java2d/opengl and
>> ./*/native/common/sun/java2d/x11, we should just include
>> ./*/native/common/sun/java2d. This level corresponds to a logical
>> grouping of the source code, and not the directory structure in that
>> grouping.
>>
>> * The file ./windows/native/common/awt_makecube.cpp is a bit strange. It
>> is not a shared file; instead it's a stand-alone binary with a main()
>> function. It is not compiled by any makefile targets. If this file is
>> actually used, I suggest moving it to a better location
>> (windows/native/launchers?), and starting to compile it with the build.
>> (Stuff that's not built regularly is doomed to bit rot.) It if is not
>> used, I suggest we remove it.
>>
>> * And as I stated before, the medlialib directories are typically not
>> used by libawt and friends. It is used by libmlib_image and
>> libmlib_image_v, and should move away from the awt directory.
>>
>> /Magnus


From dmitriy.ermashov at oracle.com  Thu Aug 28 09:14:05 2014
From: dmitriy.ermashov at oracle.com (Dmitriy Ermashov)
Date: Thu, 28 Aug 2014 13:14:05 +0400
Subject: <AWT Dev> Review Request for 8039749: Migrate needed
 functionality from all subclasses of java.awt.Robot in jdk/test directory
 to the ancestor
In-Reply-To: <53FEE3C9.7090105@oracle.com>
References: <53FC8E65.8060208@oracle.com>
	<53FDBE10.8050701@oracle.com>	<53FDCE2B.3000202@oracle.com>
	<53FDD51A.2080800@oracle.com> <53FEE3C9.7090105@oracle.com>
Message-ID: <53FEF2DD.7060306@oracle.com>

Hi Anthony,

On 08/28/2014 12:09 PM, Anthony Petrov wrote:
> Hi Dmitriy, Yuri,
>
> On 8/27/2014 4:54 PM, Yuri Nesterenko wrote:
>> On 08/27/2014 04:25 PM, Dmitriy Ermashov wrote:
>>> At first, let me focus on fact that the actual motivation of moving
>>> functionality to java.awt.Robot is the Jigsaw project. We (SQE) will be
>>> unable to use internal java API after the project will be finished
>>> (ExtendedRobot just will not compile, for example) and it will be a
>>> reason of failing huge amount of regression and functional tests.
>
> Could you please clarify as to why it won't compile? IIUC, all the GUI 
> tests that require Robot will be in a single module (the java.desktop 
> one I suppose?), so why wouldn't ExtendedRobot compile while the tests 
> themselves would if they all are located in the same module?
All jtreg tests are in default package, ExtendedRobot class as well. 
When we trying to run any jtreg test that uses ExtendedRobot it fails 
with the following error:
java.lang.IllegalAccessError: tried to access class sun.awt.SunToolkit 
from class ExtendedRobot

As you can see the problem is not in tests that uses ExtendedRobot, but 
in code that uses sun.* and other internal packages. This is the 
limitation we are trying to deal with.
>>> As for waitForIdle() method, we do not change it's use-case. The
>>> java.awt.Robot class is used only for GUI actions. And waitForIdle() is
>>> used for ensuring of finishing all events in EventQueue.
>>> The implementation with realSync() just flushes native queue as well 
>>> and
>>> it is just an improved version of existing one.
>>>
>>> Anyway, the changing of waitForIdle() implementation is discussable. 
>>> The
>>> other solution may be in adding new method with realSync call.
>>
>> Which would require touching some 340 tests in apprx 950 places, sorry
>> for statistics.
>
> Yes, I realize that some changes will be needed for this. My concern 
> is that having realSync() being called unconditionally from an 
> existing public method may have an impact on existing applications 
> that use the Robot for tasks other than testing (e.g. for simple 
> automation tasks, etc.) And I'm not sure if we're able to estimate all 
> the potential side effects that this change can bring.
We already have a kind of condition: a variable isAutoWaitForIdle.
waitForIdle method for now is called only from inside other Robot 
methods and in case when isAutoWaitForIdle flag is set to true 
(fortunately it's default value is false).

Thanks,
Dima
>
> Again, if the tests go into the java.desktop module, then I don't see 
> a problem with calling realSync() from sun.awt.SunToolkit directly as 
> you did before. If this is not the case, then I think I'd prefer to 
> introduce a separate single public method in the Toolkit (or Robot?) 
> class that would allow applications (and tests) to actually perform 
> the realSync() operation.
>
> -- 
> best regards,
> Anthony
>
>>
>> -yan
>>
>>>
>>> Thanks,
>>> Dima
>>>
>>> On 08/27/2014 03:16 PM, Anthony Petrov wrote:
>>>> Hi Dmitriy,
>>>>
>>>> While I realize that all the new methods are useful when writing JDK
>>>> regression tests, do you have any evidence that would suggest that
>>>> these same methods could be useful to and/or have been requested by
>>>> external developers? All of them look like convenient APIs and I'm not
>>>> entirely convinced if we should ultimately add them all to our public
>>>> Robot API. Personally, I don't see a problem with using the custom
>>>> ExtendedRobot class specifically for tests. This also helps reduce the
>>>> JDK and JRE static footprints, btw. But then again, I'm not an SQE
>>>> engineer.
>>>>
>>>> I don't have a strong opinion on this and I'm leaving the final
>>>> decision to Sergey and other AWT team members, but I just thought I'd
>>>> bring this up here.
>>>>
>>>> As for the implementation, I see that you're adding realSync() calls
>>>> in some places where they were not previously there. For example,
>>>> calling Robot.waitForIdle() before the fix would not cause a
>>>> realSync() to occur, while after your fix it does. This is a
>>>> significant change from threading and native event queue
>>>> synchronization perspectives, and I'm not sure if this should be done.
>>>> Again, I do know that in tests it is useful to call realSync() here
>>>> and there, but I'm not sure we should spread the calls all over the
>>>> Robot implementation simply because of this reason. The calls may in
>>>> fact produce some unwanted side-effects for existing applications
>>>> employing the Robot (e.g. introducing unwanted delays, or performing
>>>> excessive synchronization while the app didn't really need it, etc.) I
>>>> consider this change very risky.
>>>>
>>>> -- 
>>>> best regards,
>>>> Anthony
>>>>
>>>> On 8/26/2014 5:40 PM, Dmitriy Ermashov wrote:
>>>>> Hi awt team!
>>>>>
>>>>> A few months ago we have consolidated methods required by functional
>>>>> and
>>>>> regression tests in ExtendedRobot class. After a period of extensive
>>>>> testing, it's time to migrate them to java.awt.Robot.
>>>>>
>>>>> Please review the changeset:
>>>>> http://cr.openjdk.java.net/~dermashov/8039749/webrev.00/
>>>>>
>>>>> Corresponding bug:
>>>>> https://bugs.openjdk.java.net/browse/JDK-8039749
>>>>>
>>>>> Note that this change is an important prerequisite to a massive
>>>>> regression and functional test suites change for Jigsaw.
>>>>> As one can see the webrev contains changes in class signature. The 
>>>>> CCC
>>>>> request will take place after the code review.
>>>>>
>>>>> Thanks,
>>>>> Dima
>>>
>>


From alexander.potochkin at oracle.com  Thu Aug 28 11:53:58 2014
From: alexander.potochkin at oracle.com (Alexander Potochkin)
Date: Thu, 28 Aug 2014 15:53:58 +0400
Subject: <AWT Dev> [7u-dev] Request for Approval and Review: 8056156:
 [TEST_BUG] Test javax/swing/JFileChooser/8046391/bug8046391.java fails in
 Windows
In-Reply-To: <53FEDA58.4030105@oracle.com>
References: <53FEDA58.4030105@oracle.com>
Message-ID: <53FF1856.2020708@oracle.com>


The fix looks fine

Thanks
alexp

On 8/28/2014 11:29 AM, Alexey Ivanov wrote:
> Hello,
>
> Could you please approve the fix of the test in jdk7u-dev?
>
> Could you please review the fix?
>
>   webrev: http://cr.openjdk.java.net/~aivanov/8056156/jdk7/webrev.00/
>   JBS: https://bugs.openjdk.java.net/browse/JDK-8056156
>
> Description:
> The test fails to compile under jdk7 because of lambda expression.
>
> The fix:
> Convert lambda expression to anonymous class.
>
>
> Thank you in advance,
> Alexey.


From alexander.zvegintsev at oracle.com  Thu Aug 28 13:59:57 2014
From: alexander.zvegintsev at oracle.com (Alexander Zvegintsev)
Date: Thu, 28 Aug 2014 17:59:57 +0400
Subject: <AWT Dev> [9] Review request for 8055664: move 14 tests about
 setLocationRelativeTo to jdk
In-Reply-To: <53FC2C73.4060702@oracle.com>
References: <53F48FF1.3070304@oracle.com> <53FC2C73.4060702@oracle.com>
Message-ID: <53FF35DD.4090906@oracle.com>

Hello Yuri,

IIUC, this test may fail on Ubuntu due to JDK-8036915 [1].

the fix looks good to me in general, but I have some minor comments:

91         testEverything = false; // NB: change this to true to test everything

I think this line can be removed and comment should be at line 41. As 
for me,
it is easier to find this "switch" at the beginning of the test.

Add empty lines between functions for more readability, please.

Text in placeholders looks odd for me: "Hidden is java.awt.Label". I 
think that we should
change order to something like  "java.awt.Label is hidden."


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

--
Thanks,
Alexander.

On 08/26/2014 10:42 AM, Yuri Nesterenko wrote:
> A polite reminder!
>
>
> On 08/20/2014 04:09 PM, Yuri Nesterenko wrote:
>> Hi team,
>>
>> please review this test update in jdk9:
>>
>> http://cr.openjdk.java.net/~yan/8055664/webrev.00
>>
>> ( https://bugs.openjdk.java.net/browse/JDK-8055664 )
>>
>> There's a single test made out of 14 old internal functional tests.
>> Existing tests do verify that a Frame (Dialog, JFrame etc.
>> toplevel) does setLocationRelativeTo(Component) right.
>>
>> As the number of components * toplevels is rather big,
>> the test picks randomly just few of them from the lists.
>> If by chance there will be a failure, a simple option would
>> allow to run all combinations.
>> Also, if we'll have a "switch" controlling this selection
>> behavior, we'll use it here.
>>
>> Thanks,
>> -yan
>


From yuri.nesterenko at oracle.com  Thu Aug 28 14:38:16 2014
From: yuri.nesterenko at oracle.com (Yuri Nesterenko)
Date: Thu, 28 Aug 2014 18:38:16 +0400
Subject: <AWT Dev> [9] Review request for 8055664: move 14 tests about
 setLocationRelativeTo to jdk
In-Reply-To: <53FF35DD.4090906@oracle.com>
References: <53F48FF1.3070304@oracle.com> <53FC2C73.4060702@oracle.com>
	<53FF35DD.4090906@oracle.com>
Message-ID: <53FF3ED8.3070106@oracle.com>


Thank you Alexander!

new version:
http://cr.openjdk.java.net/~yan/8055664/webrev.01

-yan


On 08/28/2014 05:59 PM, Alexander Zvegintsev wrote:
> Hello Yuri,
>
> IIUC, this test may fail on Ubuntu due to JDK-8036915 [1].
Oh yes, I even put it to @bug tag.

>
> the fix looks good to me in general, but I have some minor comments:
>
> 91         testEverything = false; // NB: change this to true to test
> everything
>
> I think this line can be removed and comment should be at line 41. As
> for me,
> it is easier to find this "switch" at the beginning of the test.
Some time ago there was a discussion about too long tests,
mostly in VM I believe, and somebody suggested a systemwide switch to
choose between long and short versions.
I removed line 91.

>
> Add empty lines between functions for more readability, please.
OK.

>
> Text in placeholders looks odd for me: "Hidden is java.awt.Label". I
> think that we should
> change order to something like  "java.awt.Label is hidden."
There should be comma after is to make it less odd:-)
Changed, though!

New version:
http://cr.openjdk.java.net/~yan/8055664/webrev.01

-yan
>
>
> [1] https://bugs.openjdk.java.net/browse/JDK-8036915
>
> --
> Thanks,
> Alexander.
>
> On 08/26/2014 10:42 AM, Yuri Nesterenko wrote:
>> A polite reminder!
>>
>>
>> On 08/20/2014 04:09 PM, Yuri Nesterenko wrote:
>>> Hi team,
>>>
>>> please review this test update in jdk9:
>>>
>>> http://cr.openjdk.java.net/~yan/8055664/webrev.00
>>>
>>> ( https://bugs.openjdk.java.net/browse/JDK-8055664 )
>>>
>>> There's a single test made out of 14 old internal functional tests.
>>> Existing tests do verify that a Frame (Dialog, JFrame etc.
>>> toplevel) does setLocationRelativeTo(Component) right.
>>>
>>> As the number of components * toplevels is rather big,
>>> the test picks randomly just few of them from the lists.
>>> If by chance there will be a failure, a simple option would
>>> allow to run all combinations.
>>> Also, if we'll have a "switch" controlling this selection
>>> behavior, we'll use it here.
>>>
>>> Thanks,
>>> -yan
>>
>


From alexander.zvegintsev at oracle.com  Thu Aug 28 15:04:13 2014
From: alexander.zvegintsev at oracle.com (Alexander Zvegintsev)
Date: Thu, 28 Aug 2014 19:04:13 +0400
Subject: <AWT Dev> [9] Review request for 8055664: move 14 tests about
 setLocationRelativeTo to jdk
In-Reply-To: <53FF3ED8.3070106@oracle.com>
References: <53F48FF1.3070304@oracle.com> <53FC2C73.4060702@oracle.com>
	<53FF35DD.4090906@oracle.com> <53FF3ED8.3070106@oracle.com>
Message-ID: <53FF44ED.8070306@oracle.com>

Still looks good to me.

--
Thanks,
Alexander.

On 08/28/2014 06:38 PM, Yuri Nesterenko wrote:
>
> Thank you Alexander!
>
> new version:
> http://cr.openjdk.java.net/~yan/8055664/webrev.01
>
> -yan
>
>
> On 08/28/2014 05:59 PM, Alexander Zvegintsev wrote:
>> Hello Yuri,
>>
>> IIUC, this test may fail on Ubuntu due to JDK-8036915 [1].
> Oh yes, I even put it to @bug tag.
>
>>
>> the fix looks good to me in general, but I have some minor comments:
>>
>> 91         testEverything = false; // NB: change this to true to test
>> everything
>>
>> I think this line can be removed and comment should be at line 41. As
>> for me,
>> it is easier to find this "switch" at the beginning of the test.
> Some time ago there was a discussion about too long tests,
> mostly in VM I believe, and somebody suggested a systemwide switch to
> choose between long and short versions.
> I removed line 91.
>
>>
>> Add empty lines between functions for more readability, please.
> OK.
>
>>
>> Text in placeholders looks odd for me: "Hidden is java.awt.Label". I
>> think that we should
>> change order to something like  "java.awt.Label is hidden."
> There should be comma after is to make it less odd:-)
> Changed, though!
>
> New version:
> http://cr.openjdk.java.net/~yan/8055664/webrev.01
>
> -yan
>>
>>
>> [1] https://bugs.openjdk.java.net/browse/JDK-8036915
>>
>> -- 
>> Thanks,
>> Alexander.
>>
>> On 08/26/2014 10:42 AM, Yuri Nesterenko wrote:
>>> A polite reminder!
>>>
>>>
>>> On 08/20/2014 04:09 PM, Yuri Nesterenko wrote:
>>>> Hi team,
>>>>
>>>> please review this test update in jdk9:
>>>>
>>>> http://cr.openjdk.java.net/~yan/8055664/webrev.00
>>>>
>>>> ( https://bugs.openjdk.java.net/browse/JDK-8055664 )
>>>>
>>>> There's a single test made out of 14 old internal functional tests.
>>>> Existing tests do verify that a Frame (Dialog, JFrame etc.
>>>> toplevel) does setLocationRelativeTo(Component) right.
>>>>
>>>> As the number of components * toplevels is rather big,
>>>> the test picks randomly just few of them from the lists.
>>>> If by chance there will be a failure, a simple option would
>>>> allow to run all combinations.
>>>> Also, if we'll have a "switch" controlling this selection
>>>> behavior, we'll use it here.
>>>>
>>>> Thanks,
>>>> -yan
>>>
>>
>


From anthony.petrov at oracle.com  Thu Aug 28 18:03:52 2014
From: anthony.petrov at oracle.com (Anthony Petrov)
Date: Thu, 28 Aug 2014 22:03:52 +0400
Subject: <AWT Dev> Review Request for 8039749: Migrate needed
 functionality from all subclasses of java.awt.Robot in jdk/test directory
 to the ancestor
In-Reply-To: <53FEF2DD.7060306@oracle.com>
References: <53FC8E65.8060208@oracle.com>
	<53FDBE10.8050701@oracle.com>	<53FDCE2B.3000202@oracle.com>
	<53FDD51A.2080800@oracle.com> <53FEE3C9.7090105@oracle.com>
	<53FEF2DD.7060306@oracle.com>
Message-ID: <53FF6F08.7040801@oracle.com>

Hi Dmitriy,

On 8/28/2014 1:14 PM, Dmitriy Ermashov wrote:
> On 08/28/2014 12:09 PM, Anthony Petrov wrote:
>> On 8/27/2014 4:54 PM, Yuri Nesterenko wrote:
>>> On 08/27/2014 04:25 PM, Dmitriy Ermashov wrote:
>>>> At first, let me focus on fact that the actual motivation of moving
>>>> functionality to java.awt.Robot is the Jigsaw project. We (SQE) will be
>>>> unable to use internal java API after the project will be finished
>>>> (ExtendedRobot just will not compile, for example) and it will be a
>>>> reason of failing huge amount of regression and functional tests.
>>
>> Could you please clarify as to why it won't compile? IIUC, all the GUI
>> tests that require Robot will be in a single module (the java.desktop
>> one I suppose?), so why wouldn't ExtendedRobot compile while the tests
>> themselves would if they all are located in the same module?
> All jtreg tests are in default package, ExtendedRobot class as well.
> When we trying to run any jtreg test that uses ExtendedRobot it fails
> with the following error:
> java.lang.IllegalAccessError: tried to access class sun.awt.SunToolkit
> from class ExtendedRobot
>
> As you can see the problem is not in tests that uses ExtendedRobot, but
> in code that uses sun.* and other internal packages. This is the
> limitation we are trying to deal with.

Thank you for the clarification. If I read this correctly, I see that 
the only reason to migrate all the code from ExtendedRobot to the public 
Robot class is the fact that you're unable to call one internal method 
from SunToolkit. I really don't think this is a good justification for 
introducing a bunch of new public APIs that external developers never 
requested and that we'll have to support forever.

Please find another way to call realSync() from ExtendedRobot and leave 
the latter alone. One suggestion that I've already proposed is to 
introduce a new method in Toolkit class (Toolkit.nativeEventQueueSync() 
?) that would call the internal realSync() method. Or perhaps the jigsaw 
projects could provide some other mechanisms to access module-private 
APIs - please discuss this with jigsaw folks.


>>>> As for waitForIdle() method, we do not change it's use-case. The
>>>> java.awt.Robot class is used only for GUI actions. And waitForIdle() is
>>>> used for ensuring of finishing all events in EventQueue.
>>>> The implementation with realSync() just flushes native queue as well
>>>> and
>>>> it is just an improved version of existing one.
>>>>
>>>> Anyway, the changing of waitForIdle() implementation is discussable.
>>>> The
>>>> other solution may be in adding new method with realSync call.
>>>
>>> Which would require touching some 340 tests in apprx 950 places, sorry
>>> for statistics.
>>
>> Yes, I realize that some changes will be needed for this. My concern
>> is that having realSync() being called unconditionally from an
>> existing public method may have an impact on existing applications
>> that use the Robot for tasks other than testing (e.g. for simple
>> automation tasks, etc.) And I'm not sure if we're able to estimate all
>> the potential side effects that this change can bring.
> We already have a kind of condition: a variable isAutoWaitForIdle.
> waitForIdle method for now is called only from inside other Robot
> methods and in case when isAutoWaitForIdle flag is set to true
> (fortunately it's default value is false).

Robot.waitForIdle() is a public API. You don't (and can't) know who 
calls this method, when, and why. Changing its implementation the way 
you're proposing looks dangerous to me.

--
best regards,
Anthony


>
> Thanks,
> Dima
>>
>> Again, if the tests go into the java.desktop module, then I don't see
>> a problem with calling realSync() from sun.awt.SunToolkit directly as
>> you did before. If this is not the case, then I think I'd prefer to
>> introduce a separate single public method in the Toolkit (or Robot?)
>> class that would allow applications (and tests) to actually perform
>> the realSync() operation.
>>
>> --
>> best regards,
>> Anthony
>>
>>>
>>> -yan
>>>
>>>>
>>>> Thanks,
>>>> Dima
>>>>
>>>> On 08/27/2014 03:16 PM, Anthony Petrov wrote:
>>>>> Hi Dmitriy,
>>>>>
>>>>> While I realize that all the new methods are useful when writing JDK
>>>>> regression tests, do you have any evidence that would suggest that
>>>>> these same methods could be useful to and/or have been requested by
>>>>> external developers? All of them look like convenient APIs and I'm not
>>>>> entirely convinced if we should ultimately add them all to our public
>>>>> Robot API. Personally, I don't see a problem with using the custom
>>>>> ExtendedRobot class specifically for tests. This also helps reduce the
>>>>> JDK and JRE static footprints, btw. But then again, I'm not an SQE
>>>>> engineer.
>>>>>
>>>>> I don't have a strong opinion on this and I'm leaving the final
>>>>> decision to Sergey and other AWT team members, but I just thought I'd
>>>>> bring this up here.
>>>>>
>>>>> As for the implementation, I see that you're adding realSync() calls
>>>>> in some places where they were not previously there. For example,
>>>>> calling Robot.waitForIdle() before the fix would not cause a
>>>>> realSync() to occur, while after your fix it does. This is a
>>>>> significant change from threading and native event queue
>>>>> synchronization perspectives, and I'm not sure if this should be done.
>>>>> Again, I do know that in tests it is useful to call realSync() here
>>>>> and there, but I'm not sure we should spread the calls all over the
>>>>> Robot implementation simply because of this reason. The calls may in
>>>>> fact produce some unwanted side-effects for existing applications
>>>>> employing the Robot (e.g. introducing unwanted delays, or performing
>>>>> excessive synchronization while the app didn't really need it, etc.) I
>>>>> consider this change very risky.
>>>>>
>>>>> --
>>>>> best regards,
>>>>> Anthony
>>>>>
>>>>> On 8/26/2014 5:40 PM, Dmitriy Ermashov wrote:
>>>>>> Hi awt team!
>>>>>>
>>>>>> A few months ago we have consolidated methods required by functional
>>>>>> and
>>>>>> regression tests in ExtendedRobot class. After a period of extensive
>>>>>> testing, it's time to migrate them to java.awt.Robot.
>>>>>>
>>>>>> Please review the changeset:
>>>>>> http://cr.openjdk.java.net/~dermashov/8039749/webrev.00/
>>>>>>
>>>>>> Corresponding bug:
>>>>>> https://bugs.openjdk.java.net/browse/JDK-8039749
>>>>>>
>>>>>> Note that this change is an important prerequisite to a massive
>>>>>> regression and functional test suites change for Jigsaw.
>>>>>> As one can see the webrev contains changes in class signature. The
>>>>>> CCC
>>>>>> request will take place after the code review.
>>>>>>
>>>>>> Thanks,
>>>>>> Dima
>>>>
>>>
>

From anthony.petrov at oracle.com  Thu Aug 28 18:36:10 2014
From: anthony.petrov at oracle.com (Anthony Petrov)
Date: Thu, 28 Aug 2014 22:36:10 +0400
Subject: <AWT Dev> [9] Review request for 6624085: Fourth mouse button
 (wheel) is treated like second button - isPopupTrigger returns true
In-Reply-To: <53FE07FB.7020300@oracle.com>
References: <20140825131125.5481031af7406404aab72f3f@gmail.com>
	<53FE07FB.7020300@oracle.com>
Message-ID: <53FF769A.9090402@oracle.com>

The fix looks great to me. +1.

--
best regards,
Anthony

On 8/27/2014 8:31 PM, Alexander Zvegintsev wrote:
> Hello Alex,
>
> You are welcome and I am glad to see your contribution to OpenJDK project.
>
> Your fix looks good to me, it resolves JDK-6624085 issue too, so let it
> be fixed under this bug ID.
> As I can see in jdk9-dev mailing list OCA has been signed by you, so no
> further action is required from your side at this moment.
>
> But we still need a second reviewer to proceed (I've uploaded a webrev
> for convenience [1]).
>
> [1] http://cr.openjdk.java.net/~azvegint/oca/6624085/
>
> Thanks,
>
> Alexander.
>
> On 08/25/2014 11:11 PM, Alex Henrie wrote:
>> With this patch applied, only clicks on the mouse's right button and not
>> clicks to the mouse's forward or back buttons trigger a context menu
>> (MouseEvent.isPopupTrigger() == true).
>>
>> Class XWindow tried to map physical mouse buttons to logical mouse
>> buttons, but this unnecessary because that mapping is already handled
>> automatically in Xlib:
>> http://www.x.org/archive/X11R7.5/doc/man/man3/XKeyEvent.3.html
>>
>> Also, XGetPointerMapping returns the total number of physical mouse
>> buttons (16 on my computer), not the value of a map entry:
>> http://www.x.org/archive/X11R7.5/doc/man/man3/XGetPointerMapping.3.html
>>
>> This JDK bug has to be fixed before
>> https://netbeans.org/bugzilla/show_bug.cgi?id=198885 can be fixed.
>>
>> This patch will probably also fix
>> https://bugs.openjdk.java.net/browse/JDK-6624085
>>
>> A test program is attached.
>>
>> This is my first time contributing code to OpenJDK, so if I've done
>> something wrong, please be nice ;-)
>>
>> -Alex
>>
>> diff --git a/src/java.desktop/unix/classes/sun/awt/X11/XWindow.java
>> b/src/java.desktop/unix/classes/sun/awt/X11/XWindow.java
>> --- a/src/java.desktop/unix/classes/sun/awt/X11/XWindow.java
>> +++ b/src/java.desktop/unix/classes/sun/awt/X11/XWindow.java
>> @@ -50,17 +50,16 @@ class XWindow extends XBaseWindow implem
>>       private static final PlatformLogger focusLog =
>> PlatformLogger.getLogger("sun.awt.X11.focus.XWindow");
>>       private static PlatformLogger keyEventLog =
>> PlatformLogger.getLogger("sun.awt.X11.kye.XWindow");
>>     /* If a motion comes in while a multi-click is pending,
>>      * allow a smudge factor so that moving the mouse by a small
>>      * amount does not wipe out the multi-click state variables.
>>      */
>>       private final static int AWT_MULTICLICK_SMUDGE = 4;
>>       // ButtonXXX events stuff
>> -    static int rbutton = 0;
>>       static int lastX = 0, lastY = 0;
>>       static long lastTime = 0;
>>       static long lastButton = 0;
>>       static WeakReference<XWindow> lastWindowRef = null;
>>       static int clickCount = 0;
>>       // used to check if we need to re-create surfaceData.
>>       int oldWidth = -1;
>> @@ -627,33 +626,16 @@ class XWindow extends XBaseWindow implem
>>               res |= XToolkit.metaMask;
>>           }
>>           if ((mods & (InputEvent.ALT_GRAPH_DOWN_MASK |
>> InputEvent.ALT_GRAPH_MASK)) != 0) {
>>               res |= XToolkit.modeSwitchMask;
>>           }
>>           return res;
>>       }
>> -    /**
>> -     * Returns true if this event is disabled and shouldn't be passed
>> to Java.
>> -     * Default implementation returns false for all events.
>> -     */
>> -    static int getRightButtonNumber() {
>> -        if (rbutton == 0) { // not initialized yet
>> -            XToolkit.awtLock();
>> -            try {
>> -                rbutton =
>> XlibWrapper.XGetPointerMapping(XToolkit.getDisplay(),
>> XlibWrapper.ibuffer, 3);
>> -            }
>> -            finally {
>> -                XToolkit.awtUnlock();
>> -            }
>> -        }
>> -        return rbutton;
>> -    }
>> -
>>       static int getMouseMovementSmudge() {
>>           //TODO: It's possible to read corresponding settings
>>           return AWT_MULTICLICK_SMUDGE;
>>       }
>>       public void handleButtonPressRelease(XEvent xev) {
>>           super.handleButtonPressRelease(xev);
>>           XButtonEvent xbe = xev.get_xbutton();
>> @@ -711,21 +693,17 @@ class XWindow extends XBaseWindow implem
>>                   lastY = y;
>>               }
>>               lastTime = when;
>>               /*
>>                  Check for popup trigger !!
>>               */
>> -            if (lbutton == getRightButtonNumber() || lbutton > 2) {
>> -                popupTrigger = true;
>> -            } else {
>> -                popupTrigger = false;
>> -            }
>> +            popupTrigger = (lbutton == 3);
>>           }
>>           button = XConstants.buttons[lbutton - 1];
>>           // 4 and 5 buttons are usually considered assigned to a
>> first wheel
>>           if (lbutton == XConstants.buttons[3] ||
>>               lbutton == XConstants.buttons[4]) {
>>               wheel_mouse = true;
>>           }
>

From anthony.petrov at oracle.com  Thu Aug 28 18:38:07 2014
From: anthony.petrov at oracle.com (Anthony Petrov)
Date: Thu, 28 Aug 2014 22:38:07 +0400
Subject: <AWT Dev> RFR [9] Modular Source Code
In-Reply-To: <53FEEF95.5000702@oracle.com>
References: <3132CBA0-5920-4DDA-8E69-308D5492F0DD@oracle.com>	<53EDCA54.2090107@oracle.com>
	<53EDDD47.2010204@oracle.com> <53F203EF.9070907@oracle.com>
	<53F20A6C.7090805@oracle.com> <53F466E2.7070501@oracle.com>
	<53FAFE5C.2060600@oracle.com> <53FDB999.3030001@oracle.com>
	<53FEEF95.5000702@oracle.com>
Message-ID: <53FF770F.2080305@oracle.com>

Thanks!

--
best regards,
Anthony

On 8/28/2014 1:00 PM, Magnus Ihse Bursie wrote:
> On 2014-08-27 12:57, Anthony Petrov wrote:
>> Hi Magnus,
>>
>> Those look like reasonable suggestions. Could you please file separate
>> bugs for each of these issues? Also, please note that most of them
>> belong to 2D, not AWT (e.g. the font-, color-, d3d-, and
>> opengl-related files) even though they're compiled into the awt native
>> libraries.
>
> I created JDK-8056209, JDK-8056210, JDK-8056212, JDK-8056213,
> JDK-8056214, JDK-8056215, JDK-8056216 and JDK-8056217 for these. After
> some consideration, I choose to put them on the infrastructure/build
> category, since I believe the build part (changes to the makefiles)
> requires most of the work (compared to e.g. removing a file), and that
> we are probably more keen on having them solved :), but they need to be
> resolved in cooperation with the 2D team.
>
> The issue regarding the medialib directories was already reported in
> JDK-8055190.
>
> /Magnus
>
>
>>
>> --
>> best regards,
>> Anthony
>>
>> On 8/25/2014 1:14 PM, Magnus Ihse Bursie wrote:
>>> On 2014-08-20 11:14, Magnus Ihse Bursie wrote:
>>>> On 2014-08-18 16:15, Anthony Petrov wrote:
>>>>> So I'm not sure if the current set of AWT libraries could be
>>>>> simplified any further.
>>>>>
>>>>> Hope this helps.
>>>>
>>>> Thank you for the clarification, it was very helpful!
>>>>
>>>> While the set of AWT libraries probably cannot be simplified as you
>>>> say, my gut feeling is still that the current layout of files on disk
>>>> does not optimally match the actual libraries we build. Armed with the
>>>> help of your description, I'll look into them once again and see if I
>>>> can make that statement more concrete.
>>>
>>> This is my suggestions based on what I found when trying to remove the
>>> last unnecessary entanglement. Note that all paths are relative to the
>>> java.desktop module, and  that I have at this stage only looked at
>>> compiled sources (*.c), not header files.
>>>
>>> * The following files are in the windows directory tree, but are
>>> explicitly excluded on Windows. Thus they will never be built, and
>>> should be removed instead:
>>>    ./windows/native/libawt/sun/java2d/d3d/D3DPipeline.cpp
>>>    ./windows/native/libawt/sun/java2d/d3d/D3DShaderGen.c
>>>    ./windows/native/libawt/sun/windows/WBufferStrategy.cpp
>>>
>>> * The following file is in the share directory tree, but is only used on
>>> Windows. It should be moved to the corresponding windows directory
>>> instead:
>>>    ./share/native/libawt/sun/java2d/ShaderList.c
>>>
>>> * The following directory is in the unix directory tree, but is only
>>> used on Solaris. It should be moved to the corresponding solaris
>>> directory instead:
>>>    ./unix/native/libawt/sun/java2d/loops
>>>
>>> * The directory ./unix/native/common/sun/awt contains five more or less
>>> unrelated .c files. Three of them are only used in libawt_xawt, and
>>> should be moved there:
>>>    ./unix/native/common/sun/awt/awt_Font.c
>>>    ./unix/native/common/sun/awt/fontpath.c
>>>    ./unix/native/common/sun/awt/X11Color.c
>>> Of the remaining two CUPSfuncs.c seems correctly placed, since it is
>>> shared between libawt_xawt and libawt_lwawt. However, I'm wondering
>>> about initIDs.c. It is compiled in libawt as well as libawt_xawt, but
>>> when I checked some random functions, they are exported (via the
>>> mapfile) for libawt only. So I believe it is a mistake to include it in
>>> libawt_xawt, and that it should be moved to the libawt directory. This
>>> will need verification from someone on the AWT team.
>>>
>>> * The directory ./unix/native/libjawt is included in libawt_xawt (and in
>>> libjawt, of course). This seems suspicious to me. There is just a single
>>> file with a single function, JAWT_GetAWT(), which is exported in libjawt
>>> (via a mapfile), but not in libawt_xawt. I believe it is a mistake to
>>> include it in libawt_xawt. This will need verification from someone on
>>> the AWT team.
>>>
>>> * All of the awt-related directories (libawt_* and common) include an
>>> unnecessary extra layer, the "sun" directory. It is not needed anymore,
>>> and just makes all paths extra long. I suggest that we remove that layer
>>> and move everything up one step.
>>>
>>> * The makefiles include too specific directories. Instead of including
>>> e.g. ./*/native/common/sun/java2d/opengl and
>>> ./*/native/common/sun/java2d/x11, we should just include
>>> ./*/native/common/sun/java2d. This level corresponds to a logical
>>> grouping of the source code, and not the directory structure in that
>>> grouping.
>>>
>>> * The file ./windows/native/common/awt_makecube.cpp is a bit strange. It
>>> is not a shared file; instead it's a stand-alone binary with a main()
>>> function. It is not compiled by any makefile targets. If this file is
>>> actually used, I suggest moving it to a better location
>>> (windows/native/launchers?), and starting to compile it with the build.
>>> (Stuff that's not built regularly is doomed to bit rot.) It if is not
>>> used, I suggest we remove it.
>>>
>>> * And as I stated before, the medlialib directories are typically not
>>> used by libawt and friends. It is used by libmlib_image and
>>> libmlib_image_v, and should move away from the awt directory.
>>>
>>> /Magnus
>

From philip.race at oracle.com  Thu Aug 28 19:36:12 2014
From: philip.race at oracle.com (Phil Race)
Date: Thu, 28 Aug 2014 12:36:12 -0700
Subject: <AWT Dev> RFR [9] Modular Source Code
In-Reply-To: <53FF770F.2080305@oracle.com>
References: <3132CBA0-5920-4DDA-8E69-308D5492F0DD@oracle.com>	<53EDCA54.2090107@oracle.com>	<53EDDD47.2010204@oracle.com>
	<53F203EF.9070907@oracle.com>	<53F20A6C.7090805@oracle.com>
	<53F466E2.7070501@oracle.com>	<53FAFE5C.2060600@oracle.com>
	<53FDB999.3030001@oracle.com>	<53FEEF95.5000702@oracle.com>
	<53FF770F.2080305@oracle.com>
Message-ID: <53FF84AC.20401@oracle.com>


* All of the awt-related directories (libawt_* and common) include an
unnecessary extra layer, the "sun" directory. It is not needed anymore,

Let's *not* do that. It also affects the destination package.
Remember sun.* is the protected top-level package .. and
people won't always be running in jigsaw mode. Plus
I recently learned that compact profiles need to be informed when
you do something like this.

 >    ./windows/native/libawt/sun/java2d/d3d/D3DShaderGen.c

Is a tool that is run manually when we need to re-generate the shaders.
It is co-located so that can be found easily. It certainly should not be
deleted, nor should it be moved anywhere obscure.

makecube is similar but is I think on a list to consider deletion since
I don't think we need it anymore. But launchers would be the wrong place.

So, yes, decisions on most of these need to be jointly discussed and 
reviewed
although some may be better 'owned' by 2d and some by build.

-phil.


On 8/28/2014 11:38 AM, Anthony Petrov wrote:
> Thanks!
>
> -- 
> best regards,
> Anthony
>
> On 8/28/2014 1:00 PM, Magnus Ihse Bursie wrote:
>> On 2014-08-27 12:57, Anthony Petrov wrote:
>>> Hi Magnus,
>>>
>>> Those look like reasonable suggestions. Could you please file separate
>>> bugs for each of these issues? Also, please note that most of them
>>> belong to 2D, not AWT (e.g. the font-, color-, d3d-, and
>>> opengl-related files) even though they're compiled into the awt native
>>> libraries.
>>
>> I created JDK-8056209, JDK-8056210, JDK-8056212, JDK-8056213,
>> JDK-8056214, JDK-8056215, JDK-8056216 and JDK-8056217 for these. After
>> some consideration, I choose to put them on the infrastructure/build
>> category, since I believe the build part (changes to the makefiles)
>> requires most of the work (compared to e.g. removing a file), and that
>> we are probably more keen on having them solved :), but they need to be
>> resolved in cooperation with the 2D team.
>>
>> The issue regarding the medialib directories was already reported in
>> JDK-8055190.
>>
>> /Magnus
>>
>>
>>>
>>> -- 
>>> best regards,
>>> Anthony
>>>
>>> On 8/25/2014 1:14 PM, Magnus Ihse Bursie wrote:
>>>> On 2014-08-20 11:14, Magnus Ihse Bursie wrote:
>>>>> On 2014-08-18 16:15, Anthony Petrov wrote:
>>>>>> So I'm not sure if the current set of AWT libraries could be
>>>>>> simplified any further.
>>>>>>
>>>>>> Hope this helps.
>>>>>
>>>>> Thank you for the clarification, it was very helpful!
>>>>>
>>>>> While the set of AWT libraries probably cannot be simplified as you
>>>>> say, my gut feeling is still that the current layout of files on disk
>>>>> does not optimally match the actual libraries we build. Armed with 
>>>>> the
>>>>> help of your description, I'll look into them once again and see if I
>>>>> can make that statement more concrete.
>>>>
>>>> This is my suggestions based on what I found when trying to remove the
>>>> last unnecessary entanglement. Note that all paths are relative to the
>>>> java.desktop module, and  that I have at this stage only looked at
>>>> compiled sources (*.c), not header files.
>>>>
>>>> * The following files are in the windows directory tree, but are
>>>> explicitly excluded on Windows. Thus they will never be built, and
>>>> should be removed instead:
>>>>    ./windows/native/libawt/sun/java2d/d3d/D3DPipeline.cpp
>>>>    ./windows/native/libawt/sun/java2d/d3d/D3DShaderGen.c
>>>>    ./windows/native/libawt/sun/windows/WBufferStrategy.cpp
>>>>
>>>> * The following file is in the share directory tree, but is only 
>>>> used on
>>>> Windows. It should be moved to the corresponding windows directory
>>>> instead:
>>>>    ./share/native/libawt/sun/java2d/ShaderList.c
>>>>
>>>> * The following directory is in the unix directory tree, but is only
>>>> used on Solaris. It should be moved to the corresponding solaris
>>>> directory instead:
>>>>    ./unix/native/libawt/sun/java2d/loops
>>>>
>>>> * The directory ./unix/native/common/sun/awt contains five more or 
>>>> less
>>>> unrelated .c files. Three of them are only used in libawt_xawt, and
>>>> should be moved there:
>>>>    ./unix/native/common/sun/awt/awt_Font.c
>>>>    ./unix/native/common/sun/awt/fontpath.c
>>>>    ./unix/native/common/sun/awt/X11Color.c
>>>> Of the remaining two CUPSfuncs.c seems correctly placed, since it is
>>>> shared between libawt_xawt and libawt_lwawt. However, I'm wondering
>>>> about initIDs.c. It is compiled in libawt as well as libawt_xawt, but
>>>> when I checked some random functions, they are exported (via the
>>>> mapfile) for libawt only. So I believe it is a mistake to include 
>>>> it in
>>>> libawt_xawt, and that it should be moved to the libawt directory. This
>>>> will need verification from someone on the AWT team.
>>>>
>>>> * The directory ./unix/native/libjawt is included in libawt_xawt 
>>>> (and in
>>>> libjawt, of course). This seems suspicious to me. There is just a 
>>>> single
>>>> file with a single function, JAWT_GetAWT(), which is exported in 
>>>> libjawt
>>>> (via a mapfile), but not in libawt_xawt. I believe it is a mistake to
>>>> include it in libawt_xawt. This will need verification from someone on
>>>> the AWT team.
>>>>
>>>> * All of the awt-related directories (libawt_* and common) include an
>>>> unnecessary extra layer, the "sun" directory. It is not needed 
>>>> anymore,
>>>> and just makes all paths extra long. I suggest that we remove that 
>>>> layer
>>>> and move everything up one step.
>>>>
>>>> * The makefiles include too specific directories. Instead of including
>>>> e.g. ./*/native/common/sun/java2d/opengl and
>>>> ./*/native/common/sun/java2d/x11, we should just include
>>>> ./*/native/common/sun/java2d. This level corresponds to a logical
>>>> grouping of the source code, and not the directory structure in that
>>>> grouping.
>>>>
>>>> * The file ./windows/native/common/awt_makecube.cpp is a bit 
>>>> strange. It
>>>> is not a shared file; instead it's a stand-alone binary with a main()
>>>> function. It is not compiled by any makefile targets. If this file is
>>>> actually used, I suggest moving it to a better location
>>>> (windows/native/launchers?), and starting to compile it with the 
>>>> build.
>>>> (Stuff that's not built regularly is doomed to bit rot.) It if is not
>>>> used, I suggest we remove it.
>>>>
>>>> * And as I stated before, the medlialib directories are typically not
>>>> used by libawt and friends. It is used by libmlib_image and
>>>> libmlib_image_v, and should move away from the awt directory.
>>>>
>>>> /Magnus
>>


From philip.race at oracle.com  Thu Aug 28 19:40:09 2014
From: philip.race at oracle.com (Phil Race)
Date: Thu, 28 Aug 2014 12:40:09 -0700
Subject: <AWT Dev> [OpenJDK 2D-Dev]  RFR [9] Modular Source Code
In-Reply-To: <53FF84AC.20401@oracle.com>
References: <3132CBA0-5920-4DDA-8E69-308D5492F0DD@oracle.com>	<53EDCA54.2090107@oracle.com>	<53EDDD47.2010204@oracle.com>	<53F203EF.9070907@oracle.com>	<53F20A6C.7090805@oracle.com>	<53F466E2.7070501@oracle.com>	<53FAFE5C.2060600@oracle.com>	<53FDB999.3030001@oracle.com>	<53FEEF95.5000702@oracle.com>	<53FF770F.2080305@oracle.com>
	<53FF84AC.20401@oracle.com>
Message-ID: <53FF8599.8080007@oracle.com>

On 8/28/2014 12:36 PM, Phil Race wrote:
>
> * All of the awt-related directories (libawt_* and common) include an
> unnecessary extra layer, the "sun" directory. It is not needed anymore,
>
> Let's *not* do that. It also affects the destination package.
> Remember sun.* is the protected top-level package .. and
> people won't always be running in jigsaw mode. Plus
> I recently learned that compact profiles need to be informed when
> you do something like this.

Oh, you refer to the native code that for some reason in libawt 
directories (not the others)
has one extra level ?  I don't see the same for libfontmanager for example
Maybe this is one more case where libawt caused excess head-scratching

-phil.


>
> >    ./windows/native/libawt/sun/java2d/d3d/D3DShaderGen.c
>
> Is a tool that is run manually when we need to re-generate the shaders.
> It is co-located so that can be found easily. It certainly should not be
> deleted, nor should it be moved anywhere obscure.
>
> makecube is similar but is I think on a list to consider deletion since
> I don't think we need it anymore. But launchers would be the wrong place.
>
> So, yes, decisions on most of these need to be jointly discussed and 
> reviewed
> although some may be better 'owned' by 2d and some by build.
>
> -phil.
>
>
> On 8/28/2014 11:38 AM, Anthony Petrov wrote:
>> Thanks!
>>
>> -- 
>> best regards,
>> Anthony
>>
>> On 8/28/2014 1:00 PM, Magnus Ihse Bursie wrote:
>>> On 2014-08-27 12:57, Anthony Petrov wrote:
>>>> Hi Magnus,
>>>>
>>>> Those look like reasonable suggestions. Could you please file separate
>>>> bugs for each of these issues? Also, please note that most of them
>>>> belong to 2D, not AWT (e.g. the font-, color-, d3d-, and
>>>> opengl-related files) even though they're compiled into the awt native
>>>> libraries.
>>>
>>> I created JDK-8056209, JDK-8056210, JDK-8056212, JDK-8056213,
>>> JDK-8056214, JDK-8056215, JDK-8056216 and JDK-8056217 for these. After
>>> some consideration, I choose to put them on the infrastructure/build
>>> category, since I believe the build part (changes to the makefiles)
>>> requires most of the work (compared to e.g. removing a file), and that
>>> we are probably more keen on having them solved :), but they need to be
>>> resolved in cooperation with the 2D team.
>>>
>>> The issue regarding the medialib directories was already reported in
>>> JDK-8055190.
>>>
>>> /Magnus
>>>
>>>
>>>>
>>>> -- 
>>>> best regards,
>>>> Anthony
>>>>
>>>> On 8/25/2014 1:14 PM, Magnus Ihse Bursie wrote:
>>>>> On 2014-08-20 11:14, Magnus Ihse Bursie wrote:
>>>>>> On 2014-08-18 16:15, Anthony Petrov wrote:
>>>>>>> So I'm not sure if the current set of AWT libraries could be
>>>>>>> simplified any further.
>>>>>>>
>>>>>>> Hope this helps.
>>>>>>
>>>>>> Thank you for the clarification, it was very helpful!
>>>>>>
>>>>>> While the set of AWT libraries probably cannot be simplified as you
>>>>>> say, my gut feeling is still that the current layout of files on 
>>>>>> disk
>>>>>> does not optimally match the actual libraries we build. Armed 
>>>>>> with the
>>>>>> help of your description, I'll look into them once again and see 
>>>>>> if I
>>>>>> can make that statement more concrete.
>>>>>
>>>>> This is my suggestions based on what I found when trying to remove 
>>>>> the
>>>>> last unnecessary entanglement. Note that all paths are relative to 
>>>>> the
>>>>> java.desktop module, and  that I have at this stage only looked at
>>>>> compiled sources (*.c), not header files.
>>>>>
>>>>> * The following files are in the windows directory tree, but are
>>>>> explicitly excluded on Windows. Thus they will never be built, and
>>>>> should be removed instead:
>>>>>    ./windows/native/libawt/sun/java2d/d3d/D3DPipeline.cpp
>>>>>    ./windows/native/libawt/sun/java2d/d3d/D3DShaderGen.c
>>>>>    ./windows/native/libawt/sun/windows/WBufferStrategy.cpp
>>>>>
>>>>> * The following file is in the share directory tree, but is only 
>>>>> used on
>>>>> Windows. It should be moved to the corresponding windows directory
>>>>> instead:
>>>>>    ./share/native/libawt/sun/java2d/ShaderList.c
>>>>>
>>>>> * The following directory is in the unix directory tree, but is only
>>>>> used on Solaris. It should be moved to the corresponding solaris
>>>>> directory instead:
>>>>>    ./unix/native/libawt/sun/java2d/loops
>>>>>
>>>>> * The directory ./unix/native/common/sun/awt contains five more or 
>>>>> less
>>>>> unrelated .c files. Three of them are only used in libawt_xawt, and
>>>>> should be moved there:
>>>>>    ./unix/native/common/sun/awt/awt_Font.c
>>>>>    ./unix/native/common/sun/awt/fontpath.c
>>>>>    ./unix/native/common/sun/awt/X11Color.c
>>>>> Of the remaining two CUPSfuncs.c seems correctly placed, since it is
>>>>> shared between libawt_xawt and libawt_lwawt. However, I'm wondering
>>>>> about initIDs.c. It is compiled in libawt as well as libawt_xawt, but
>>>>> when I checked some random functions, they are exported (via the
>>>>> mapfile) for libawt only. So I believe it is a mistake to include 
>>>>> it in
>>>>> libawt_xawt, and that it should be moved to the libawt directory. 
>>>>> This
>>>>> will need verification from someone on the AWT team.
>>>>>
>>>>> * The directory ./unix/native/libjawt is included in libawt_xawt 
>>>>> (and in
>>>>> libjawt, of course). This seems suspicious to me. There is just a 
>>>>> single
>>>>> file with a single function, JAWT_GetAWT(), which is exported in 
>>>>> libjawt
>>>>> (via a mapfile), but not in libawt_xawt. I believe it is a mistake to
>>>>> include it in libawt_xawt. This will need verification from 
>>>>> someone on
>>>>> the AWT team.
>>>>>
>>>>> * All of the awt-related directories (libawt_* and common) include an
>>>>> unnecessary extra layer, the "sun" directory. It is not needed 
>>>>> anymore,
>>>>> and just makes all paths extra long. I suggest that we remove that 
>>>>> layer
>>>>> and move everything up one step.
>>>>>
>>>>> * The makefiles include too specific directories. Instead of 
>>>>> including
>>>>> e.g. ./*/native/common/sun/java2d/opengl and
>>>>> ./*/native/common/sun/java2d/x11, we should just include
>>>>> ./*/native/common/sun/java2d. This level corresponds to a logical
>>>>> grouping of the source code, and not the directory structure in that
>>>>> grouping.
>>>>>
>>>>> * The file ./windows/native/common/awt_makecube.cpp is a bit 
>>>>> strange. It
>>>>> is not a shared file; instead it's a stand-alone binary with a main()
>>>>> function. It is not compiled by any makefile targets. If this file is
>>>>> actually used, I suggest moving it to a better location
>>>>> (windows/native/launchers?), and starting to compile it with the 
>>>>> build.
>>>>> (Stuff that's not built regularly is doomed to bit rot.) It if is not
>>>>> used, I suggest we remove it.
>>>>>
>>>>> * And as I stated before, the medlialib directories are typically not
>>>>> used by libawt and friends. It is used by libmlib_image and
>>>>> libmlib_image_v, and should move away from the awt directory.
>>>>>
>>>>> /Magnus
>>>
>


From Alan.Bateman at oracle.com  Thu Aug 28 19:57:14 2014
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Thu, 28 Aug 2014 20:57:14 +0100
Subject: <AWT Dev> RFR [9] Modular Source Code
In-Reply-To: <53FF84AC.20401@oracle.com>
References: <3132CBA0-5920-4DDA-8E69-308D5492F0DD@oracle.com>	<53EDCA54.2090107@oracle.com>	<53EDDD47.2010204@oracle.com>	<53F203EF.9070907@oracle.com>	<53F20A6C.7090805@oracle.com>	<53F466E2.7070501@oracle.com>	<53FAFE5C.2060600@oracle.com>	<53FDB999.3030001@oracle.com>	<53FEEF95.5000702@oracle.com>	<53FF770F.2080305@oracle.com>
	<53FF84AC.20401@oracle.com>
Message-ID: <53FF899A.2080307@oracle.com>

On 28/08/2014 20:36, Phil Race wrote:
>
> * All of the awt-related directories (libawt_* and common) include an
> unnecessary extra layer, the "sun" directory. It is not needed anymore,
>
> Let's *not* do that. It also affects the destination package.
> Remember sun.* is the protected top-level package .. and
> people won't always be running in jigsaw mode. 
For native/libXXX then there shouldn't be any need to mirror the java 
package structure in the native tree now. The shuffle should have done 
this for most libraries, libawt may be the exception and it would be 
good to get it consistent if possible.

There isn't a "jigsaw mode", and nothing that I can think of that would 
have an impact on the source structure.


> Plus
> I recently learned that compact profiles need to be informed when
> you do something like this.
The profiles build shouldn't be concerned with the source layout as it's 
the equivalent of an images build. So for the native code then it just 
needs to know which already-built native libraries to include. I suspect 
your comment may be related to the refactor of the datatransfer API, in 
which case it was a java package rather than a native libraries that 
just a temporary break (no big deal, easily fixed).

In time we will replace the profiles build, probably when we move to the 
modular image as each of the images (JDK, JRE, compact1, compact2, ...) 
will be just built from a set of modules.

-Alan.

From alexey.ivanov at oracle.com  Fri Aug 29 08:20:00 2014
From: alexey.ivanov at oracle.com (Alexey Ivanov)
Date: Fri, 29 Aug 2014 12:20:00 +0400
Subject: <AWT Dev> [9] Review request for JDK-8056211: JCK test
 api/java_awt/Event/InputMethodEvent/serial fails
Message-ID: <540037B0.5050909@oracle.com>

Hello AWT Team,

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

Description:
When you deserialize InputMethodEvent object serialized with JDK 1.3 or 
earlier, you'll get java.lang.IllegalArgumentException: null source. To 
initialize 'when' field, getMostRecentEventTimeForSource is used in this 
case but 'source' field is always null when object is deserialized.

The fix:
Use the old way to initialize 'when' field where its value is 0, that is 
EventQueue.getMostRecentEventTime().


Thank you in advance,
Alexey.

From magnus.ihse.bursie at oracle.com  Fri Aug 29 08:29:54 2014
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Fri, 29 Aug 2014 10:29:54 +0200
Subject: <AWT Dev> [OpenJDK 2D-Dev]  RFR [9] Modular Source Code
In-Reply-To: <53FF8599.8080007@oracle.com>
References: <3132CBA0-5920-4DDA-8E69-308D5492F0DD@oracle.com>	<53EDCA54.2090107@oracle.com>	<53EDDD47.2010204@oracle.com>	<53F203EF.9070907@oracle.com>	<53F20A6C.7090805@oracle.com>	<53F466E2.7070501@oracle.com>	<53FAFE5C.2060600@oracle.com>	<53FDB999.3030001@oracle.com>	<53FEEF95.5000702@oracle.com>	<53FF770F.2080305@oracle.com>
	<53FF84AC.20401@oracle.com> <53FF8599.8080007@oracle.com>
Message-ID: <54003A02.1040206@oracle.com>

On 2014-08-28 21:40, Phil Race wrote:
> On 8/28/2014 12:36 PM, Phil Race wrote:
>>
>> * All of the awt-related directories (libawt_* and common) include an
>> unnecessary extra layer, the "sun" directory. It is not needed anymore,
>>
>> Let's *not* do that. It also affects the destination package.
>> Remember sun.* is the protected top-level package .. and
>> people won't always be running in jigsaw mode. Plus
>> I recently learned that compact profiles need to be informed when
>> you do something like this.
>
> Oh, you refer to the native code that for some reason in libawt 
> directories (not the others)
> has one extra level ?  I don't see the same for libfontmanager for 
> example
> Maybe this is one more case where libawt caused excess head-scratching

Yes, I am. Sorry if I was not clear on that point -- all my comments 
refered to the native code. The location of the native code does not 
have any effects as such on the product. Most other native libraries 
were "fixed" in this way, but the awt code was left out, probably as you 
say, due to excess head-scratching. :-)

/Mangus

From magnus.ihse.bursie at oracle.com  Fri Aug 29 08:45:22 2014
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Fri, 29 Aug 2014 10:45:22 +0200
Subject: <AWT Dev> RFR [9] Modular Source Code
In-Reply-To: <53FF84AC.20401@oracle.com>
References: <3132CBA0-5920-4DDA-8E69-308D5492F0DD@oracle.com>	<53EDCA54.2090107@oracle.com>	<53EDDD47.2010204@oracle.com>
	<53F203EF.9070907@oracle.com>	<53F20A6C.7090805@oracle.com>
	<53F466E2.7070501@oracle.com>	<53FAFE5C.2060600@oracle.com>
	<53FDB999.3030001@oracle.com>	<53FEEF95.5000702@oracle.com>
	<53FF770F.2080305@oracle.com> <53FF84AC.20401@oracle.com>
Message-ID: <54003DA2.4070109@oracle.com>

On 2014-08-28 21:36, Phil Race wrote:
>
> >    ./windows/native/libawt/sun/java2d/d3d/D3DShaderGen.c
>
> Is a tool that is run manually when we need to re-generate the shaders.
> It is co-located so that can be found easily. It certainly should not be
> deleted, nor should it be moved anywhere obscure.
Oh, I see. There was actually some very good documention in the file 
itself. :)

As a general rule, I think the build system should build all tools that 
is actively used, even if not so frequent, to avoid bit rot. In this 
case, we could for instance let configure detect the presence of the 
DirectX SDK, and if present, compile and run the D3DShaderGen tool. This 
will increase the likelyhood that the tool is actually working when 
needed, and that the generated header file is kept up to date.

> So, yes, decisions on most of these need to be jointly discussed and 
> reviewed
> although some may be better 'owned' by 2d and some by build.

I moved all the bugs but one (that is pure makefile logic) to 
client-libs/2d. I hope that is the correct sub-component.

/Magnus

From alexandr.scherbatiy at oracle.com  Fri Aug 29 10:13:29 2014
From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy)
Date: Fri, 29 Aug 2014 14:13:29 +0400
Subject: <AWT Dev> [9] Review request for 8055664: move 14 tests about
 setLocationRelativeTo to jdk
In-Reply-To: <53FF44ED.8070306@oracle.com>
References: <53F48FF1.3070304@oracle.com> <53FC2C73.4060702@oracle.com>
	<53FF35DD.4090906@oracle.com> <53FF3ED8.3070106@oracle.com>
	<53FF44ED.8070306@oracle.com>
Message-ID: <54005249.6020707@oracle.com>


   The fix looks good to me.

   Thanks,
   Alexandr.

On 8/28/2014 7:04 PM, Alexander Zvegintsev wrote:
> Still looks good to me.
>
> -- 
> Thanks,
> Alexander.
>
> On 08/28/2014 06:38 PM, Yuri Nesterenko wrote:
>>
>> Thank you Alexander!
>>
>> new version:
>> http://cr.openjdk.java.net/~yan/8055664/webrev.01
>>
>> -yan
>>
>>
>> On 08/28/2014 05:59 PM, Alexander Zvegintsev wrote:
>>> Hello Yuri,
>>>
>>> IIUC, this test may fail on Ubuntu due to JDK-8036915 [1].
>> Oh yes, I even put it to @bug tag.
>>
>>>
>>> the fix looks good to me in general, but I have some minor comments:
>>>
>>> 91         testEverything = false; // NB: change this to true to test
>>> everything
>>>
>>> I think this line can be removed and comment should be at line 41. As
>>> for me,
>>> it is easier to find this "switch" at the beginning of the test.
>> Some time ago there was a discussion about too long tests,
>> mostly in VM I believe, and somebody suggested a systemwide switch to
>> choose between long and short versions.
>> I removed line 91.
>>
>>>
>>> Add empty lines between functions for more readability, please.
>> OK.
>>
>>>
>>> Text in placeholders looks odd for me: "Hidden is java.awt.Label". I
>>> think that we should
>>> change order to something like  "java.awt.Label is hidden."
>> There should be comma after is to make it less odd:-)
>> Changed, though!
>>
>> New version:
>> http://cr.openjdk.java.net/~yan/8055664/webrev.01
>>
>> -yan
>>>
>>>
>>> [1] https://bugs.openjdk.java.net/browse/JDK-8036915
>>>
>>> -- 
>>> Thanks,
>>> Alexander.
>>>
>>> On 08/26/2014 10:42 AM, Yuri Nesterenko wrote:
>>>> A polite reminder!
>>>>
>>>>
>>>> On 08/20/2014 04:09 PM, Yuri Nesterenko wrote:
>>>>> Hi team,
>>>>>
>>>>> please review this test update in jdk9:
>>>>>
>>>>> http://cr.openjdk.java.net/~yan/8055664/webrev.00
>>>>>
>>>>> ( https://bugs.openjdk.java.net/browse/JDK-8055664 )
>>>>>
>>>>> There's a single test made out of 14 old internal functional tests.
>>>>> Existing tests do verify that a Frame (Dialog, JFrame etc.
>>>>> toplevel) does setLocationRelativeTo(Component) right.
>>>>>
>>>>> As the number of components * toplevels is rather big,
>>>>> the test picks randomly just few of them from the lists.
>>>>> If by chance there will be a failure, a simple option would
>>>>> allow to run all combinations.
>>>>> Also, if we'll have a "switch" controlling this selection
>>>>> behavior, we'll use it here.
>>>>>
>>>>> Thanks,
>>>>> -yan
>>>>
>>>
>>
>


From dmitriy.ermashov at oracle.com  Fri Aug 29 12:24:53 2014
From: dmitriy.ermashov at oracle.com (Dmitriy Ermashov)
Date: Fri, 29 Aug 2014 16:24:53 +0400
Subject: <AWT Dev> Review Request for 8039749: Migrate needed
 functionality from all subclasses of java.awt.Robot in jdk/test directory
 to the ancestor
In-Reply-To: <53FF6F08.7040801@oracle.com>
References: <53FC8E65.8060208@oracle.com>
	<53FDBE10.8050701@oracle.com>	<53FDCE2B.3000202@oracle.com>
	<53FDD51A.2080800@oracle.com> <53FEE3C9.7090105@oracle.com>
	<53FEF2DD.7060306@oracle.com> <53FF6F08.7040801@oracle.com>
Message-ID: <54007115.5010502@oracle.com>

Hi Anthony,

Ok, let's summarize:
We leave all functionality in ExtendedRobot except of realSync() call, 
which in turn we move to a new method in java.awt.Toolkit.

I believe it could be a reasonable compromise.

Is it ok?

Thanks,
Dima

On 08/28/2014 10:03 PM, Anthony Petrov wrote:
> Hi Dmitriy,
>
> On 8/28/2014 1:14 PM, Dmitriy Ermashov wrote:
>> On 08/28/2014 12:09 PM, Anthony Petrov wrote:
>>> On 8/27/2014 4:54 PM, Yuri Nesterenko wrote:
>>>> On 08/27/2014 04:25 PM, Dmitriy Ermashov wrote:
>>>>> At first, let me focus on fact that the actual motivation of moving
>>>>> functionality to java.awt.Robot is the Jigsaw project. We (SQE) 
>>>>> will be
>>>>> unable to use internal java API after the project will be finished
>>>>> (ExtendedRobot just will not compile, for example) and it will be a
>>>>> reason of failing huge amount of regression and functional tests.
>>>
>>> Could you please clarify as to why it won't compile? IIUC, all the GUI
>>> tests that require Robot will be in a single module (the java.desktop
>>> one I suppose?), so why wouldn't ExtendedRobot compile while the tests
>>> themselves would if they all are located in the same module?
>> All jtreg tests are in default package, ExtendedRobot class as well.
>> When we trying to run any jtreg test that uses ExtendedRobot it fails
>> with the following error:
>> java.lang.IllegalAccessError: tried to access class sun.awt.SunToolkit
>> from class ExtendedRobot
>>
>> As you can see the problem is not in tests that uses ExtendedRobot, but
>> in code that uses sun.* and other internal packages. This is the
>> limitation we are trying to deal with.
>
> Thank you for the clarification. If I read this correctly, I see that 
> the only reason to migrate all the code from ExtendedRobot to the 
> public Robot class is the fact that you're unable to call one internal 
> method from SunToolkit. I really don't think this is a good 
> justification for introducing a bunch of new public APIs that external 
> developers never requested and that we'll have to support forever.
>
> Please find another way to call realSync() from ExtendedRobot and 
> leave the latter alone. One suggestion that I've already proposed is 
> to introduce a new method in Toolkit class 
> (Toolkit.nativeEventQueueSync() ?) that would call the internal 
> realSync() method. Or perhaps the jigsaw projects could provide some 
> other mechanisms to access module-private APIs - please discuss this 
> with jigsaw folks.
>
>
>>>>> As for waitForIdle() method, we do not change it's use-case. The
>>>>> java.awt.Robot class is used only for GUI actions. And 
>>>>> waitForIdle() is
>>>>> used for ensuring of finishing all events in EventQueue.
>>>>> The implementation with realSync() just flushes native queue as well
>>>>> and
>>>>> it is just an improved version of existing one.
>>>>>
>>>>> Anyway, the changing of waitForIdle() implementation is discussable.
>>>>> The
>>>>> other solution may be in adding new method with realSync call.
>>>>
>>>> Which would require touching some 340 tests in apprx 950 places, sorry
>>>> for statistics.
>>>
>>> Yes, I realize that some changes will be needed for this. My concern
>>> is that having realSync() being called unconditionally from an
>>> existing public method may have an impact on existing applications
>>> that use the Robot for tasks other than testing (e.g. for simple
>>> automation tasks, etc.) And I'm not sure if we're able to estimate all
>>> the potential side effects that this change can bring.
>> We already have a kind of condition: a variable isAutoWaitForIdle.
>> waitForIdle method for now is called only from inside other Robot
>> methods and in case when isAutoWaitForIdle flag is set to true
>> (fortunately it's default value is false).
>
> Robot.waitForIdle() is a public API. You don't (and can't) know who 
> calls this method, when, and why. Changing its implementation the way 
> you're proposing looks dangerous to me.
>
> -- 
> best regards,
> Anthony
>
>
>>
>> Thanks,
>> Dima
>>>
>>> Again, if the tests go into the java.desktop module, then I don't see
>>> a problem with calling realSync() from sun.awt.SunToolkit directly as
>>> you did before. If this is not the case, then I think I'd prefer to
>>> introduce a separate single public method in the Toolkit (or Robot?)
>>> class that would allow applications (and tests) to actually perform
>>> the realSync() operation.
>>>
>>> -- 
>>> best regards,
>>> Anthony
>>>
>>>>
>>>> -yan
>>>>
>>>>>
>>>>> Thanks,
>>>>> Dima
>>>>>
>>>>> On 08/27/2014 03:16 PM, Anthony Petrov wrote:
>>>>>> Hi Dmitriy,
>>>>>>
>>>>>> While I realize that all the new methods are useful when writing JDK
>>>>>> regression tests, do you have any evidence that would suggest that
>>>>>> these same methods could be useful to and/or have been requested by
>>>>>> external developers? All of them look like convenient APIs and 
>>>>>> I'm not
>>>>>> entirely convinced if we should ultimately add them all to our 
>>>>>> public
>>>>>> Robot API. Personally, I don't see a problem with using the custom
>>>>>> ExtendedRobot class specifically for tests. This also helps 
>>>>>> reduce the
>>>>>> JDK and JRE static footprints, btw. But then again, I'm not an SQE
>>>>>> engineer.
>>>>>>
>>>>>> I don't have a strong opinion on this and I'm leaving the final
>>>>>> decision to Sergey and other AWT team members, but I just thought 
>>>>>> I'd
>>>>>> bring this up here.
>>>>>>
>>>>>> As for the implementation, I see that you're adding realSync() calls
>>>>>> in some places where they were not previously there. For example,
>>>>>> calling Robot.waitForIdle() before the fix would not cause a
>>>>>> realSync() to occur, while after your fix it does. This is a
>>>>>> significant change from threading and native event queue
>>>>>> synchronization perspectives, and I'm not sure if this should be 
>>>>>> done.
>>>>>> Again, I do know that in tests it is useful to call realSync() here
>>>>>> and there, but I'm not sure we should spread the calls all over the
>>>>>> Robot implementation simply because of this reason. The calls may in
>>>>>> fact produce some unwanted side-effects for existing applications
>>>>>> employing the Robot (e.g. introducing unwanted delays, or performing
>>>>>> excessive synchronization while the app didn't really need it, 
>>>>>> etc.) I
>>>>>> consider this change very risky.
>>>>>>
>>>>>> -- 
>>>>>> best regards,
>>>>>> Anthony
>>>>>>
>>>>>> On 8/26/2014 5:40 PM, Dmitriy Ermashov wrote:
>>>>>>> Hi awt team!
>>>>>>>
>>>>>>> A few months ago we have consolidated methods required by 
>>>>>>> functional
>>>>>>> and
>>>>>>> regression tests in ExtendedRobot class. After a period of 
>>>>>>> extensive
>>>>>>> testing, it's time to migrate them to java.awt.Robot.
>>>>>>>
>>>>>>> Please review the changeset:
>>>>>>> http://cr.openjdk.java.net/~dermashov/8039749/webrev.00/
>>>>>>>
>>>>>>> Corresponding bug:
>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8039749
>>>>>>>
>>>>>>> Note that this change is an important prerequisite to a massive
>>>>>>> regression and functional test suites change for Jigsaw.
>>>>>>> As one can see the webrev contains changes in class signature. The
>>>>>>> CCC
>>>>>>> request will take place after the code review.
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Dima
>>>>>
>>>>
>>


From anthony.petrov at oracle.com  Fri Aug 29 12:35:47 2014
From: anthony.petrov at oracle.com (Anthony Petrov)
Date: Fri, 29 Aug 2014 16:35:47 +0400
Subject: <AWT Dev> Review Request for 8039749: Migrate needed
 functionality from all subclasses of java.awt.Robot in jdk/test directory
 to the ancestor
In-Reply-To: <54007115.5010502@oracle.com>
References: <53FC8E65.8060208@oracle.com>
	<53FDBE10.8050701@oracle.com>	<53FDCE2B.3000202@oracle.com>
	<53FDD51A.2080800@oracle.com> <53FEE3C9.7090105@oracle.com>
	<53FEF2DD.7060306@oracle.com> <53FF6F08.7040801@oracle.com>
	<54007115.5010502@oracle.com>
Message-ID: <540073A3.9010902@oracle.com>

Yes, that sounds good to me. We need to consider whether this should be 
Toolkit or Robot class though, and settle on the name of the new method. 
For example, if we go with Robot, then it could be 
Robot.waitForNativeIdle() or alike.

--
best regards,
Anthony

On 8/29/2014 4:24 PM, Dmitriy Ermashov wrote:
> Hi Anthony,
>
> Ok, let's summarize:
> We leave all functionality in ExtendedRobot except of realSync() call,
> which in turn we move to a new method in java.awt.Toolkit.
>
> I believe it could be a reasonable compromise.
>
> Is it ok?
>
> Thanks,
> Dima
>
> On 08/28/2014 10:03 PM, Anthony Petrov wrote:
>> Hi Dmitriy,
>>
>> On 8/28/2014 1:14 PM, Dmitriy Ermashov wrote:
>>> On 08/28/2014 12:09 PM, Anthony Petrov wrote:
>>>> On 8/27/2014 4:54 PM, Yuri Nesterenko wrote:
>>>>> On 08/27/2014 04:25 PM, Dmitriy Ermashov wrote:
>>>>>> At first, let me focus on fact that the actual motivation of moving
>>>>>> functionality to java.awt.Robot is the Jigsaw project. We (SQE)
>>>>>> will be
>>>>>> unable to use internal java API after the project will be finished
>>>>>> (ExtendedRobot just will not compile, for example) and it will be a
>>>>>> reason of failing huge amount of regression and functional tests.
>>>>
>>>> Could you please clarify as to why it won't compile? IIUC, all the GUI
>>>> tests that require Robot will be in a single module (the java.desktop
>>>> one I suppose?), so why wouldn't ExtendedRobot compile while the tests
>>>> themselves would if they all are located in the same module?
>>> All jtreg tests are in default package, ExtendedRobot class as well.
>>> When we trying to run any jtreg test that uses ExtendedRobot it fails
>>> with the following error:
>>> java.lang.IllegalAccessError: tried to access class sun.awt.SunToolkit
>>> from class ExtendedRobot
>>>
>>> As you can see the problem is not in tests that uses ExtendedRobot, but
>>> in code that uses sun.* and other internal packages. This is the
>>> limitation we are trying to deal with.
>>
>> Thank you for the clarification. If I read this correctly, I see that
>> the only reason to migrate all the code from ExtendedRobot to the
>> public Robot class is the fact that you're unable to call one internal
>> method from SunToolkit. I really don't think this is a good
>> justification for introducing a bunch of new public APIs that external
>> developers never requested and that we'll have to support forever.
>>
>> Please find another way to call realSync() from ExtendedRobot and
>> leave the latter alone. One suggestion that I've already proposed is
>> to introduce a new method in Toolkit class
>> (Toolkit.nativeEventQueueSync() ?) that would call the internal
>> realSync() method. Or perhaps the jigsaw projects could provide some
>> other mechanisms to access module-private APIs - please discuss this
>> with jigsaw folks.
>>
>>
>>>>>> As for waitForIdle() method, we do not change it's use-case. The
>>>>>> java.awt.Robot class is used only for GUI actions. And
>>>>>> waitForIdle() is
>>>>>> used for ensuring of finishing all events in EventQueue.
>>>>>> The implementation with realSync() just flushes native queue as well
>>>>>> and
>>>>>> it is just an improved version of existing one.
>>>>>>
>>>>>> Anyway, the changing of waitForIdle() implementation is discussable.
>>>>>> The
>>>>>> other solution may be in adding new method with realSync call.
>>>>>
>>>>> Which would require touching some 340 tests in apprx 950 places, sorry
>>>>> for statistics.
>>>>
>>>> Yes, I realize that some changes will be needed for this. My concern
>>>> is that having realSync() being called unconditionally from an
>>>> existing public method may have an impact on existing applications
>>>> that use the Robot for tasks other than testing (e.g. for simple
>>>> automation tasks, etc.) And I'm not sure if we're able to estimate all
>>>> the potential side effects that this change can bring.
>>> We already have a kind of condition: a variable isAutoWaitForIdle.
>>> waitForIdle method for now is called only from inside other Robot
>>> methods and in case when isAutoWaitForIdle flag is set to true
>>> (fortunately it's default value is false).
>>
>> Robot.waitForIdle() is a public API. You don't (and can't) know who
>> calls this method, when, and why. Changing its implementation the way
>> you're proposing looks dangerous to me.
>>
>> --
>> best regards,
>> Anthony
>>
>>
>>>
>>> Thanks,
>>> Dima
>>>>
>>>> Again, if the tests go into the java.desktop module, then I don't see
>>>> a problem with calling realSync() from sun.awt.SunToolkit directly as
>>>> you did before. If this is not the case, then I think I'd prefer to
>>>> introduce a separate single public method in the Toolkit (or Robot?)
>>>> class that would allow applications (and tests) to actually perform
>>>> the realSync() operation.
>>>>
>>>> --
>>>> best regards,
>>>> Anthony
>>>>
>>>>>
>>>>> -yan
>>>>>
>>>>>>
>>>>>> Thanks,
>>>>>> Dima
>>>>>>
>>>>>> On 08/27/2014 03:16 PM, Anthony Petrov wrote:
>>>>>>> Hi Dmitriy,
>>>>>>>
>>>>>>> While I realize that all the new methods are useful when writing JDK
>>>>>>> regression tests, do you have any evidence that would suggest that
>>>>>>> these same methods could be useful to and/or have been requested by
>>>>>>> external developers? All of them look like convenient APIs and
>>>>>>> I'm not
>>>>>>> entirely convinced if we should ultimately add them all to our
>>>>>>> public
>>>>>>> Robot API. Personally, I don't see a problem with using the custom
>>>>>>> ExtendedRobot class specifically for tests. This also helps
>>>>>>> reduce the
>>>>>>> JDK and JRE static footprints, btw. But then again, I'm not an SQE
>>>>>>> engineer.
>>>>>>>
>>>>>>> I don't have a strong opinion on this and I'm leaving the final
>>>>>>> decision to Sergey and other AWT team members, but I just thought
>>>>>>> I'd
>>>>>>> bring this up here.
>>>>>>>
>>>>>>> As for the implementation, I see that you're adding realSync() calls
>>>>>>> in some places where they were not previously there. For example,
>>>>>>> calling Robot.waitForIdle() before the fix would not cause a
>>>>>>> realSync() to occur, while after your fix it does. This is a
>>>>>>> significant change from threading and native event queue
>>>>>>> synchronization perspectives, and I'm not sure if this should be
>>>>>>> done.
>>>>>>> Again, I do know that in tests it is useful to call realSync() here
>>>>>>> and there, but I'm not sure we should spread the calls all over the
>>>>>>> Robot implementation simply because of this reason. The calls may in
>>>>>>> fact produce some unwanted side-effects for existing applications
>>>>>>> employing the Robot (e.g. introducing unwanted delays, or performing
>>>>>>> excessive synchronization while the app didn't really need it,
>>>>>>> etc.) I
>>>>>>> consider this change very risky.
>>>>>>>
>>>>>>> --
>>>>>>> best regards,
>>>>>>> Anthony
>>>>>>>
>>>>>>> On 8/26/2014 5:40 PM, Dmitriy Ermashov wrote:
>>>>>>>> Hi awt team!
>>>>>>>>
>>>>>>>> A few months ago we have consolidated methods required by
>>>>>>>> functional
>>>>>>>> and
>>>>>>>> regression tests in ExtendedRobot class. After a period of
>>>>>>>> extensive
>>>>>>>> testing, it's time to migrate them to java.awt.Robot.
>>>>>>>>
>>>>>>>> Please review the changeset:
>>>>>>>> http://cr.openjdk.java.net/~dermashov/8039749/webrev.00/
>>>>>>>>
>>>>>>>> Corresponding bug:
>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8039749
>>>>>>>>
>>>>>>>> Note that this change is an important prerequisite to a massive
>>>>>>>> regression and functional test suites change for Jigsaw.
>>>>>>>> As one can see the webrev contains changes in class signature. The
>>>>>>>> CCC
>>>>>>>> request will take place after the code review.
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>> Dima
>>>>>>
>>>>>
>>>
>

From dmitriy.ermashov at oracle.com  Fri Aug 29 12:52:21 2014
From: dmitriy.ermashov at oracle.com (Dmitriy Ermashov)
Date: Fri, 29 Aug 2014 16:52:21 +0400
Subject: <AWT Dev> Review Request for 8039749: Migrate needed
 functionality from all subclasses of java.awt.Robot in jdk/test directory
 to the ancestor
In-Reply-To: <540073A3.9010902@oracle.com>
References: <53FC8E65.8060208@oracle.com>
	<53FDBE10.8050701@oracle.com>	<53FDCE2B.3000202@oracle.com>
	<53FDD51A.2080800@oracle.com> <53FEE3C9.7090105@oracle.com>
	<53FEF2DD.7060306@oracle.com> <53FF6F08.7040801@oracle.com>
	<54007115.5010502@oracle.com> <540073A3.9010902@oracle.com>
Message-ID: <54007785.6000707@oracle.com>

Or it could be a Toolkit.nativeEventQueueSync. It would allow us to call 
the method in a static way.

Many functional tests have a call like
((SunToolkit) Toolkit.getDefaultToolkit()).realSync()
They call realSync without instantiating a robot.

It would be great just replace it with
Toolkit.getDefaultToolkit().nativeEventQueueSync()
in existing tests and nothing more.

Thanks,
Dima

On 08/29/2014 04:35 PM, Anthony Petrov wrote:
> Yes, that sounds good to me. We need to consider whether this should 
> be Toolkit or Robot class though, and settle on the name of the new 
> method. For example, if we go with Robot, then it could be 
> Robot.waitForNativeIdle() or alike.
>
> -- 
> best regards,
> Anthony
>
> On 8/29/2014 4:24 PM, Dmitriy Ermashov wrote:
>> Hi Anthony,
>>
>> Ok, let's summarize:
>> We leave all functionality in ExtendedRobot except of realSync() call,
>> which in turn we move to a new method in java.awt.Toolkit.
>>
>> I believe it could be a reasonable compromise.
>>
>> Is it ok?
>>
>> Thanks,
>> Dima
>>
>> On 08/28/2014 10:03 PM, Anthony Petrov wrote:
>>> Hi Dmitriy,
>>>
>>> On 8/28/2014 1:14 PM, Dmitriy Ermashov wrote:
>>>> On 08/28/2014 12:09 PM, Anthony Petrov wrote:
>>>>> On 8/27/2014 4:54 PM, Yuri Nesterenko wrote:
>>>>>> On 08/27/2014 04:25 PM, Dmitriy Ermashov wrote:
>>>>>>> At first, let me focus on fact that the actual motivation of moving
>>>>>>> functionality to java.awt.Robot is the Jigsaw project. We (SQE)
>>>>>>> will be
>>>>>>> unable to use internal java API after the project will be finished
>>>>>>> (ExtendedRobot just will not compile, for example) and it will be a
>>>>>>> reason of failing huge amount of regression and functional tests.
>>>>>
>>>>> Could you please clarify as to why it won't compile? IIUC, all the 
>>>>> GUI
>>>>> tests that require Robot will be in a single module (the java.desktop
>>>>> one I suppose?), so why wouldn't ExtendedRobot compile while the 
>>>>> tests
>>>>> themselves would if they all are located in the same module?
>>>> All jtreg tests are in default package, ExtendedRobot class as well.
>>>> When we trying to run any jtreg test that uses ExtendedRobot it fails
>>>> with the following error:
>>>> java.lang.IllegalAccessError: tried to access class sun.awt.SunToolkit
>>>> from class ExtendedRobot
>>>>
>>>> As you can see the problem is not in tests that uses ExtendedRobot, 
>>>> but
>>>> in code that uses sun.* and other internal packages. This is the
>>>> limitation we are trying to deal with.
>>>
>>> Thank you for the clarification. If I read this correctly, I see that
>>> the only reason to migrate all the code from ExtendedRobot to the
>>> public Robot class is the fact that you're unable to call one internal
>>> method from SunToolkit. I really don't think this is a good
>>> justification for introducing a bunch of new public APIs that external
>>> developers never requested and that we'll have to support forever.
>>>
>>> Please find another way to call realSync() from ExtendedRobot and
>>> leave the latter alone. One suggestion that I've already proposed is
>>> to introduce a new method in Toolkit class
>>> (Toolkit.nativeEventQueueSync() ?) that would call the internal
>>> realSync() method. Or perhaps the jigsaw projects could provide some
>>> other mechanisms to access module-private APIs - please discuss this
>>> with jigsaw folks.
>>>
>>>
>>>>>>> As for waitForIdle() method, we do not change it's use-case. The
>>>>>>> java.awt.Robot class is used only for GUI actions. And
>>>>>>> waitForIdle() is
>>>>>>> used for ensuring of finishing all events in EventQueue.
>>>>>>> The implementation with realSync() just flushes native queue as 
>>>>>>> well
>>>>>>> and
>>>>>>> it is just an improved version of existing one.
>>>>>>>
>>>>>>> Anyway, the changing of waitForIdle() implementation is 
>>>>>>> discussable.
>>>>>>> The
>>>>>>> other solution may be in adding new method with realSync call.
>>>>>>
>>>>>> Which would require touching some 340 tests in apprx 950 places, 
>>>>>> sorry
>>>>>> for statistics.
>>>>>
>>>>> Yes, I realize that some changes will be needed for this. My concern
>>>>> is that having realSync() being called unconditionally from an
>>>>> existing public method may have an impact on existing applications
>>>>> that use the Robot for tasks other than testing (e.g. for simple
>>>>> automation tasks, etc.) And I'm not sure if we're able to estimate 
>>>>> all
>>>>> the potential side effects that this change can bring.
>>>> We already have a kind of condition: a variable isAutoWaitForIdle.
>>>> waitForIdle method for now is called only from inside other Robot
>>>> methods and in case when isAutoWaitForIdle flag is set to true
>>>> (fortunately it's default value is false).
>>>
>>> Robot.waitForIdle() is a public API. You don't (and can't) know who
>>> calls this method, when, and why. Changing its implementation the way
>>> you're proposing looks dangerous to me.
>>>
>>> -- 
>>> best regards,
>>> Anthony
>>>
>>>
>>>>
>>>> Thanks,
>>>> Dima
>>>>>
>>>>> Again, if the tests go into the java.desktop module, then I don't see
>>>>> a problem with calling realSync() from sun.awt.SunToolkit directly as
>>>>> you did before. If this is not the case, then I think I'd prefer to
>>>>> introduce a separate single public method in the Toolkit (or Robot?)
>>>>> class that would allow applications (and tests) to actually perform
>>>>> the realSync() operation.
>>>>>
>>>>> -- 
>>>>> best regards,
>>>>> Anthony
>>>>>
>>>>>>
>>>>>> -yan
>>>>>>
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Dima
>>>>>>>
>>>>>>> On 08/27/2014 03:16 PM, Anthony Petrov wrote:
>>>>>>>> Hi Dmitriy,
>>>>>>>>
>>>>>>>> While I realize that all the new methods are useful when 
>>>>>>>> writing JDK
>>>>>>>> regression tests, do you have any evidence that would suggest that
>>>>>>>> these same methods could be useful to and/or have been 
>>>>>>>> requested by
>>>>>>>> external developers? All of them look like convenient APIs and
>>>>>>>> I'm not
>>>>>>>> entirely convinced if we should ultimately add them all to our
>>>>>>>> public
>>>>>>>> Robot API. Personally, I don't see a problem with using the custom
>>>>>>>> ExtendedRobot class specifically for tests. This also helps
>>>>>>>> reduce the
>>>>>>>> JDK and JRE static footprints, btw. But then again, I'm not an SQE
>>>>>>>> engineer.
>>>>>>>>
>>>>>>>> I don't have a strong opinion on this and I'm leaving the final
>>>>>>>> decision to Sergey and other AWT team members, but I just thought
>>>>>>>> I'd
>>>>>>>> bring this up here.
>>>>>>>>
>>>>>>>> As for the implementation, I see that you're adding realSync() 
>>>>>>>> calls
>>>>>>>> in some places where they were not previously there. For example,
>>>>>>>> calling Robot.waitForIdle() before the fix would not cause a
>>>>>>>> realSync() to occur, while after your fix it does. This is a
>>>>>>>> significant change from threading and native event queue
>>>>>>>> synchronization perspectives, and I'm not sure if this should be
>>>>>>>> done.
>>>>>>>> Again, I do know that in tests it is useful to call realSync() 
>>>>>>>> here
>>>>>>>> and there, but I'm not sure we should spread the calls all over 
>>>>>>>> the
>>>>>>>> Robot implementation simply because of this reason. The calls 
>>>>>>>> may in
>>>>>>>> fact produce some unwanted side-effects for existing applications
>>>>>>>> employing the Robot (e.g. introducing unwanted delays, or 
>>>>>>>> performing
>>>>>>>> excessive synchronization while the app didn't really need it,
>>>>>>>> etc.) I
>>>>>>>> consider this change very risky.
>>>>>>>>
>>>>>>>> -- 
>>>>>>>> best regards,
>>>>>>>> Anthony
>>>>>>>>
>>>>>>>> On 8/26/2014 5:40 PM, Dmitriy Ermashov wrote:
>>>>>>>>> Hi awt team!
>>>>>>>>>
>>>>>>>>> A few months ago we have consolidated methods required by
>>>>>>>>> functional
>>>>>>>>> and
>>>>>>>>> regression tests in ExtendedRobot class. After a period of
>>>>>>>>> extensive
>>>>>>>>> testing, it's time to migrate them to java.awt.Robot.
>>>>>>>>>
>>>>>>>>> Please review the changeset:
>>>>>>>>> http://cr.openjdk.java.net/~dermashov/8039749/webrev.00/
>>>>>>>>>
>>>>>>>>> Corresponding bug:
>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8039749
>>>>>>>>>
>>>>>>>>> Note that this change is an important prerequisite to a massive
>>>>>>>>> regression and functional test suites change for Jigsaw.
>>>>>>>>> As one can see the webrev contains changes in class signature. 
>>>>>>>>> The
>>>>>>>>> CCC
>>>>>>>>> request will take place after the code review.
>>>>>>>>>
>>>>>>>>> Thanks,
>>>>>>>>> Dima
>>>>>>>
>>>>>>
>>>>
>>


From anthony.petrov at oracle.com  Fri Aug 29 13:50:24 2014
From: anthony.petrov at oracle.com (Anthony Petrov)
Date: Fri, 29 Aug 2014 17:50:24 +0400
Subject: <AWT Dev> Review Request for 8039749: Migrate needed
 functionality from all subclasses of java.awt.Robot in jdk/test directory
 to the ancestor
In-Reply-To: <54007785.6000707@oracle.com>
References: <53FC8E65.8060208@oracle.com>
	<53FDBE10.8050701@oracle.com>	<53FDCE2B.3000202@oracle.com>
	<53FDD51A.2080800@oracle.com> <53FEE3C9.7090105@oracle.com>
	<53FEF2DD.7060306@oracle.com> <53FF6F08.7040801@oracle.com>
	<54007115.5010502@oracle.com> <540073A3.9010902@oracle.com>
	<54007785.6000707@oracle.com>
Message-ID: <54008520.1080405@oracle.com>

Yeah, that looks good to me too.

--
best regards,
Anthony

On 8/29/2014 4:52 PM, Dmitriy Ermashov wrote:
> Or it could be a Toolkit.nativeEventQueueSync. It would allow us to call
> the method in a static way.
>
> Many functional tests have a call like
> ((SunToolkit) Toolkit.getDefaultToolkit()).realSync()
> They call realSync without instantiating a robot.
>
> It would be great just replace it with
> Toolkit.getDefaultToolkit().nativeEventQueueSync()
> in existing tests and nothing more.
>
> Thanks,
> Dima
>
> On 08/29/2014 04:35 PM, Anthony Petrov wrote:
>> Yes, that sounds good to me. We need to consider whether this should
>> be Toolkit or Robot class though, and settle on the name of the new
>> method. For example, if we go with Robot, then it could be
>> Robot.waitForNativeIdle() or alike.
>>
>> --
>> best regards,
>> Anthony
>>
>> On 8/29/2014 4:24 PM, Dmitriy Ermashov wrote:
>>> Hi Anthony,
>>>
>>> Ok, let's summarize:
>>> We leave all functionality in ExtendedRobot except of realSync() call,
>>> which in turn we move to a new method in java.awt.Toolkit.
>>>
>>> I believe it could be a reasonable compromise.
>>>
>>> Is it ok?
>>>
>>> Thanks,
>>> Dima
>>>
>>> On 08/28/2014 10:03 PM, Anthony Petrov wrote:
>>>> Hi Dmitriy,
>>>>
>>>> On 8/28/2014 1:14 PM, Dmitriy Ermashov wrote:
>>>>> On 08/28/2014 12:09 PM, Anthony Petrov wrote:
>>>>>> On 8/27/2014 4:54 PM, Yuri Nesterenko wrote:
>>>>>>> On 08/27/2014 04:25 PM, Dmitriy Ermashov wrote:
>>>>>>>> At first, let me focus on fact that the actual motivation of moving
>>>>>>>> functionality to java.awt.Robot is the Jigsaw project. We (SQE)
>>>>>>>> will be
>>>>>>>> unable to use internal java API after the project will be finished
>>>>>>>> (ExtendedRobot just will not compile, for example) and it will be a
>>>>>>>> reason of failing huge amount of regression and functional tests.
>>>>>>
>>>>>> Could you please clarify as to why it won't compile? IIUC, all the
>>>>>> GUI
>>>>>> tests that require Robot will be in a single module (the java.desktop
>>>>>> one I suppose?), so why wouldn't ExtendedRobot compile while the
>>>>>> tests
>>>>>> themselves would if they all are located in the same module?
>>>>> All jtreg tests are in default package, ExtendedRobot class as well.
>>>>> When we trying to run any jtreg test that uses ExtendedRobot it fails
>>>>> with the following error:
>>>>> java.lang.IllegalAccessError: tried to access class sun.awt.SunToolkit
>>>>> from class ExtendedRobot
>>>>>
>>>>> As you can see the problem is not in tests that uses ExtendedRobot,
>>>>> but
>>>>> in code that uses sun.* and other internal packages. This is the
>>>>> limitation we are trying to deal with.
>>>>
>>>> Thank you for the clarification. If I read this correctly, I see that
>>>> the only reason to migrate all the code from ExtendedRobot to the
>>>> public Robot class is the fact that you're unable to call one internal
>>>> method from SunToolkit. I really don't think this is a good
>>>> justification for introducing a bunch of new public APIs that external
>>>> developers never requested and that we'll have to support forever.
>>>>
>>>> Please find another way to call realSync() from ExtendedRobot and
>>>> leave the latter alone. One suggestion that I've already proposed is
>>>> to introduce a new method in Toolkit class
>>>> (Toolkit.nativeEventQueueSync() ?) that would call the internal
>>>> realSync() method. Or perhaps the jigsaw projects could provide some
>>>> other mechanisms to access module-private APIs - please discuss this
>>>> with jigsaw folks.
>>>>
>>>>
>>>>>>>> As for waitForIdle() method, we do not change it's use-case. The
>>>>>>>> java.awt.Robot class is used only for GUI actions. And
>>>>>>>> waitForIdle() is
>>>>>>>> used for ensuring of finishing all events in EventQueue.
>>>>>>>> The implementation with realSync() just flushes native queue as
>>>>>>>> well
>>>>>>>> and
>>>>>>>> it is just an improved version of existing one.
>>>>>>>>
>>>>>>>> Anyway, the changing of waitForIdle() implementation is
>>>>>>>> discussable.
>>>>>>>> The
>>>>>>>> other solution may be in adding new method with realSync call.
>>>>>>>
>>>>>>> Which would require touching some 340 tests in apprx 950 places,
>>>>>>> sorry
>>>>>>> for statistics.
>>>>>>
>>>>>> Yes, I realize that some changes will be needed for this. My concern
>>>>>> is that having realSync() being called unconditionally from an
>>>>>> existing public method may have an impact on existing applications
>>>>>> that use the Robot for tasks other than testing (e.g. for simple
>>>>>> automation tasks, etc.) And I'm not sure if we're able to estimate
>>>>>> all
>>>>>> the potential side effects that this change can bring.
>>>>> We already have a kind of condition: a variable isAutoWaitForIdle.
>>>>> waitForIdle method for now is called only from inside other Robot
>>>>> methods and in case when isAutoWaitForIdle flag is set to true
>>>>> (fortunately it's default value is false).
>>>>
>>>> Robot.waitForIdle() is a public API. You don't (and can't) know who
>>>> calls this method, when, and why. Changing its implementation the way
>>>> you're proposing looks dangerous to me.
>>>>
>>>> --
>>>> best regards,
>>>> Anthony
>>>>
>>>>
>>>>>
>>>>> Thanks,
>>>>> Dima
>>>>>>
>>>>>> Again, if the tests go into the java.desktop module, then I don't see
>>>>>> a problem with calling realSync() from sun.awt.SunToolkit directly as
>>>>>> you did before. If this is not the case, then I think I'd prefer to
>>>>>> introduce a separate single public method in the Toolkit (or Robot?)
>>>>>> class that would allow applications (and tests) to actually perform
>>>>>> the realSync() operation.
>>>>>>
>>>>>> --
>>>>>> best regards,
>>>>>> Anthony
>>>>>>
>>>>>>>
>>>>>>> -yan
>>>>>>>
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>> Dima
>>>>>>>>
>>>>>>>> On 08/27/2014 03:16 PM, Anthony Petrov wrote:
>>>>>>>>> Hi Dmitriy,
>>>>>>>>>
>>>>>>>>> While I realize that all the new methods are useful when
>>>>>>>>> writing JDK
>>>>>>>>> regression tests, do you have any evidence that would suggest that
>>>>>>>>> these same methods could be useful to and/or have been
>>>>>>>>> requested by
>>>>>>>>> external developers? All of them look like convenient APIs and
>>>>>>>>> I'm not
>>>>>>>>> entirely convinced if we should ultimately add them all to our
>>>>>>>>> public
>>>>>>>>> Robot API. Personally, I don't see a problem with using the custom
>>>>>>>>> ExtendedRobot class specifically for tests. This also helps
>>>>>>>>> reduce the
>>>>>>>>> JDK and JRE static footprints, btw. But then again, I'm not an SQE
>>>>>>>>> engineer.
>>>>>>>>>
>>>>>>>>> I don't have a strong opinion on this and I'm leaving the final
>>>>>>>>> decision to Sergey and other AWT team members, but I just thought
>>>>>>>>> I'd
>>>>>>>>> bring this up here.
>>>>>>>>>
>>>>>>>>> As for the implementation, I see that you're adding realSync()
>>>>>>>>> calls
>>>>>>>>> in some places where they were not previously there. For example,
>>>>>>>>> calling Robot.waitForIdle() before the fix would not cause a
>>>>>>>>> realSync() to occur, while after your fix it does. This is a
>>>>>>>>> significant change from threading and native event queue
>>>>>>>>> synchronization perspectives, and I'm not sure if this should be
>>>>>>>>> done.
>>>>>>>>> Again, I do know that in tests it is useful to call realSync()
>>>>>>>>> here
>>>>>>>>> and there, but I'm not sure we should spread the calls all over
>>>>>>>>> the
>>>>>>>>> Robot implementation simply because of this reason. The calls
>>>>>>>>> may in
>>>>>>>>> fact produce some unwanted side-effects for existing applications
>>>>>>>>> employing the Robot (e.g. introducing unwanted delays, or
>>>>>>>>> performing
>>>>>>>>> excessive synchronization while the app didn't really need it,
>>>>>>>>> etc.) I
>>>>>>>>> consider this change very risky.
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> best regards,
>>>>>>>>> Anthony
>>>>>>>>>
>>>>>>>>> On 8/26/2014 5:40 PM, Dmitriy Ermashov wrote:
>>>>>>>>>> Hi awt team!
>>>>>>>>>>
>>>>>>>>>> A few months ago we have consolidated methods required by
>>>>>>>>>> functional
>>>>>>>>>> and
>>>>>>>>>> regression tests in ExtendedRobot class. After a period of
>>>>>>>>>> extensive
>>>>>>>>>> testing, it's time to migrate them to java.awt.Robot.
>>>>>>>>>>
>>>>>>>>>> Please review the changeset:
>>>>>>>>>> http://cr.openjdk.java.net/~dermashov/8039749/webrev.00/
>>>>>>>>>>
>>>>>>>>>> Corresponding bug:
>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8039749
>>>>>>>>>>
>>>>>>>>>> Note that this change is an important prerequisite to a massive
>>>>>>>>>> regression and functional test suites change for Jigsaw.
>>>>>>>>>> As one can see the webrev contains changes in class signature.
>>>>>>>>>> The
>>>>>>>>>> CCC
>>>>>>>>>> request will take place after the code review.
>>>>>>>>>>
>>>>>>>>>> Thanks,
>>>>>>>>>> Dima
>>>>>>>>
>>>>>>>
>>>>>
>>>
>

From dmitriy.ermashov at oracle.com  Fri Aug 29 15:11:14 2014
From: dmitriy.ermashov at oracle.com (Dmitriy Ermashov)
Date: Fri, 29 Aug 2014 19:11:14 +0400
Subject: <AWT Dev> Review Request for 8056911: Remove internal API usage
 from ExtendedRobot class
Message-ID: <54009812.1030408@oracle.com>

Hi awt team,

Please review a fix for 8056911, remove internal API usage from 
ExtendedRobot class.
We have to throw out all calls of sun.* packages from tests because of 
incompatibility with Jigsaw project.

http://cr.openjdk.java.net/~dermashov/8056911/webrev.00/

The CCC request will take place after the review process will be completed.

Thanks,
Dima

From philip.race at oracle.com  Fri Aug 29 15:33:17 2014
From: philip.race at oracle.com (Phil Race)
Date: Fri, 29 Aug 2014 08:33:17 -0700
Subject: <AWT Dev> Review Request for 8056911: Remove internal API usage
 from ExtendedRobot class
In-Reply-To: <54009812.1030408@oracle.com>
References: <54009812.1030408@oracle.com>
Message-ID: <54009D3D.3070909@oracle.com>

So you are proposing adding a new *public* API for this narrow purpose.
And it calls out a whole bunch of internal classes in its apI doc !?!

2642      * <p> The method calls {@link sun.awt.SunToolkit#realSync} to
2643      * sync with native event queue

@throws  sun.awt.SunToolkit.IllegalThreadException if called on the AWT event
2646      *          dispatching thread
2647      * @throws  sun.awt.SunToolkit.OperationTimedOut if the
2648      *          {@link sun.awt.SunToolkit.OperationTimedOut} exception occurs in
2649      *          {@link sun.awt.SunToolkit#realSync}
2650      * @throws  sun.awt.SunToolkit.InfiniteLoop if the
2651      *          {@link sun.awt.SunToolkit.InfiniteLoop} exception occurs in
2652      *          {@link sun.awt.SunToolkit#realSync}
2653      * @throws  ClassCastException if default toolkit is not SunToolkit


I am also not sure how confident I am that the statement

his method guarantees that after
2637      * return no additional Java events will be generated, unless
2638      * cause by user.

is actually guaranteed.


My initial reaction to such a proposal is instead look hard for a better
way even if it means re-writing all the tests.
There's also the proposed 'jdk.*' name space that can be considered
but re-writing the tests would be better.

-phil.

On 8/29/14 8:11 AM, Dmitriy Ermashov wrote:
> Hi awt team,
>
> Please review a fix for 8056911, remove internal API usage from 
> ExtendedRobot class.
> We have to throw out all calls of sun.* packages from tests because of 
> incompatibility with Jigsaw project.
>
> http://cr.openjdk.java.net/~dermashov/8056911/webrev.00/
>
> The CCC request will take place after the review process will be 
> completed.
>
> Thanks,
> Dima

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20140829/a3139a24/attachment.html>

From lhochet at gmail.com  Sat Aug 30 20:39:10 2014
From: lhochet at gmail.com (Ludovic HOCHET)
Date: Sat, 30 Aug 2014 22:39:10 +0200
Subject: <AWT Dev> The path to flavormap.properties is currently broken in
	SystemFlavorMap
Message-ID: <CAF4R3a_w9RB=6HN4mJMsU0BaafSK2knhePUNPsf3TZv_1JHYjA@mail.gmail.com>

Hello,
The path to flavormap.properties is currently broken in
SystemFlavorMap (both in jdk9/dev and jdk9/jdk9). Looking at the
history it seems there was some attempt at moving the file to the path
that is in SystemFlavorMap, but that move (if it was complete) didn't
survive the source code modularisation.
The following patch fixes the issue for me for now:
diff -r 02e9b804e671
src/java.desktop/share/classes/java/awt/datatransfer/SystemFlavorMap.java
--- a/src/java.desktop/share/classes/java/awt/datatransfer/SystemFlavorMap.java
   Fri Aug 29 11:59:34 2014 -0700
+++ b/src/java.desktop/share/classes/java/awt/datatransfer/SystemFlavorMap.java
   Sat Aug 30 19:29:53 2014 +0100
@@ -200,7 +200,7 @@
         }
         isMapInitialized = true;

-        InputStream is =
SystemFlavorMap.class.getResourceAsStream("/sun/datatransfer/resources/flavormap.properties");
+        InputStream is =
SystemFlavorMap.class.getResourceAsStream("/sun/awt/datatransfer/flavormap.properties");
         if (is == null) {
             throw new InternalError("Default flavor mapping not found");
         }


-- 
Ludovic
-----------------------------------------

"Les formes qui differencient les etres importent peu
 si leur pensees s'unissent pour batir un univers..."
 Yoko Tsuno (in 'Les titans' by Roger Leloup)
 [The shapes that differenciate beings are not important
 if their thoughts unite to build a universe]