From Sergey.Bylokhov at oracle.com  Tue Jul  1 05:12:30 2014
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Tue, 01 Jul 2014 09:12:30 +0400
Subject: <AWT Dev> [9] Review Request: 8048265 AWT crashes inside
 CCombinedSegTable::In called from
 Java_sun_awt_windows_WDefaultFontCharset_canConvert
Message-ID: <53B2433E.2040502@oracle.com>

Hello.
Please review the fix for jdk 9.
Bug was triggered by the change in JDK-8032435, when WingDings.java was 
changed to non-public class. This class is used in native, and looks 
like some of these places, when executed on powerful systems, caused an 
exception and later a crash.
As I fix I suggest to revert back this part of the JDK-8032435

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

-- 
Best regards, Sergey.


From petr.pchelko at oracle.com  Tue Jul  1 05:39:31 2014
From: petr.pchelko at oracle.com (Petr Pchelko)
Date: Tue, 1 Jul 2014 09:39:31 +0400
Subject: <AWT Dev> [9] Review Request: 8048265 AWT crashes inside
	CCombinedSegTable::In called from
	Java_sun_awt_windows_WDefaultFontCharset_canConvert
In-Reply-To: <53B2433E.2040502@oracle.com>
References: <53B2433E.2040502@oracle.com>
Message-ID: <4A39F38B-9225-4EE1-B880-CA4EF56FA129@oracle.com>

Hello, Sergey.

The fix looks good, although I have absolutely no idea why this could be related.
Could you please file another bug to track further investigation of this problem.

With best regards. Petr.

> On Jul 1, 2014, at 9:12 AM, Sergey Bylokhov <Sergey.Bylokhov at oracle.com> wrote:
> 
> Hello.
> Please review the fix for jdk 9.
> Bug was triggered by the change in JDK-8032435, when WingDings.java was changed to non-public class. This class is used in native, and looks like some of these places, when executed on powerful systems, caused an exception and later a crash.
> As I fix I suggest to revert back this part of the JDK-8032435
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8048265
> Webrev can be found at: http://cr.openjdk.java.net/~serb/8048265/webrev.00
> 
> -- 
> Best regards, Sergey.
> 


From petr.pchelko at oracle.com  Tue Jul  1 08:35:50 2014
From: petr.pchelko at oracle.com (Petr Pchelko)
Date: Tue, 1 Jul 2014 12:35:50 +0400
Subject: <AWT Dev> [9] Review Request: 8047336 Read flavormap.properties
	as resource
In-Reply-To: <53A41FF2.8050705@oracle.com>
References: <59786637-036B-49C3-AB92-0D5742C87AC2@oracle.com>	<53A2D3DA.4030503@oracle.com>	<B543154A-7C00-4024-9478-6D615E828190@oracle.com>
	<53A418B9.6080500@oracle.com> <53A41B16.9020404@oracle.com>
	<18DA96EE-B90D-4BAD-8990-6D4972446019@oracle.com>
	<53A41FF2.8050705@oracle.com>
Message-ID: <977775FE-2CE5-4223-89CC-88F0339CD420@oracle.com>

Hello, 

The changes in the public API have been approved, so let me continue the review process.

For your convenience:
The bug: https://bugs.openjdk.java.net/browse/JDK-8047336
The fix: http://cr.openjdk.java.net/~pchelko/9/8047336/webrev.00/

Until now we've been discussing an abstract question of moving the properties to a different location and agreed that it's possible.
Now it's time for an official code review. Could someone please make one?

Also some feedback from the build team is still required. Could someone from the build team review this fix please? 
(The question is that I've made a separate explicit rule for flavormap.properties file. If I add it to COPY_PATTERNS than the solaris version get's copied on Mac. Is that a bug in the build system? Is my current solution good enough?)

Thank you.
With best regards. Petr.

On 20 ???? 2014 ?., at 15:50, Alan Bateman <Alan.Bateman at oracle.com> wrote:

> On 20/06/2014 12:41, Petr Pchelko wrote:
>> Hello, Anthony, Artem.
>> 
>>>> Do we officially declare that we drop support for this possibility?
>>> This possibility will be dropped regardless of the current Petr's fix, since there will be no single "jre" folder in jigsaw world. Probably, some other mechanism to customize files like flavormap.properties or logging.properties will be introduced.
>> And we can add a system property to set an alternative flavormap.properties file later if someone would request such a feature.
>> 
>>> BTW, the current fix is not about flavormap.properties on its own, but about removing AWT.DnD.flavorMapFileURL toolkit property. I would suggest to push this change as a separate bug fix, not as a part of 8047336.
>> And also about changing flavormap.properties format) The current fix is all the work in datatransfer modularization that needs a CCC. All changes seem related, so I would prefer no to split it further,
>> because it would make it harder to track when all the peaces are integrated to jake repository to continue the work. And it would need more CCC requests which consume time.
>> 
> The forum post looks like is from 2001. If there doesn't appear that many developers have resorted to editing that file then I would suggest just going with what you have. If it really becomes necessary to support having configuration elsewhere (not in the JDK image) then I don't think anything that you have now precludes that.
> 
> -Alan.

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

From dmitriy.ermashov at oracle.com  Tue Jul  1 11:44:49 2014
From: dmitriy.ermashov at oracle.com (Dmitriy Ermashov)
Date: Tue, 01 Jul 2014 15:44:49 +0400
Subject: <AWT Dev> Review Request for 8048246: Move
 AWT_DnD/Clipboard/Automated functional tests to OpenJDK
Message-ID: <53B29F31.6010808@oracle.com>

Hi,

Please review a new batch of functional AWT tests. Clipboard tests this 
time.
http://cr.openjdk.java.net/~dermashov/8048246/webrev.00/

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

The changeset is pretty large, but, as always, it is several times 
smaller than original test suite.
Tests were verified on the following platforms:
Windows 7 x64
Ubuntu 14.04 x64
OS X 10.9.4 x64
Solaris 11 x64
Ubuntu 10.04 arm

-- 
Thanks,
Dima


From alexander.zvegintsev at oracle.com  Tue Jul  1 12:52:53 2014
From: alexander.zvegintsev at oracle.com (Alexander Zvegintsev)
Date: Tue, 01 Jul 2014 16:52:53 +0400
Subject: <AWT Dev> [9] Review Request: 8048265 AWT crashes inside
 CCombinedSegTable::In called from
 Java_sun_awt_windows_WDefaultFontCharset_canConvert
In-Reply-To: <53B2433E.2040502@oracle.com>
References: <53B2433E.2040502@oracle.com>
Message-ID: <53B2AF25.3030407@oracle.com>

Hi Sergey,

the fix looks good to me.

--
Thanks,
Alexander.

01.07.2014 9:12, Sergey Bylokhov wrote:
> Hello.
> Please review the fix for jdk 9.
> Bug was triggered by the change in JDK-8032435, when WingDings.java 
> was changed to non-public class. This class is used in native, and 
> looks like some of these places, when executed on powerful systems, 
> caused an exception and later a crash.
> As I fix I suggest to revert back this part of the JDK-8032435
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8048265
> Webrev can be found at: 
> http://cr.openjdk.java.net/~serb/8048265/webrev.00
>


From anthony.petrov at oracle.com  Tue Jul  1 12:57:16 2014
From: anthony.petrov at oracle.com (Anthony Petrov)
Date: Tue, 01 Jul 2014 16:57:16 +0400
Subject: <AWT Dev> [9] Review Request: 8048265 AWT crashes inside
 CCombinedSegTable::In called from
 Java_sun_awt_windows_WDefaultFontCharset_canConvert
In-Reply-To: <53B2433E.2040502@oracle.com>
References: <53B2433E.2040502@oracle.com>
Message-ID: <53B2B02C.1020701@oracle.com>

Looks fine.

--
best regards,
Anthony

On 7/1/2014 9:12 AM, Sergey Bylokhov wrote:
> Hello.
> Please review the fix for jdk 9.
> Bug was triggered by the change in JDK-8032435, when WingDings.java was
> changed to non-public class. This class is used in native, and looks
> like some of these places, when executed on powerful systems, caused an
> exception and later a crash.
> As I fix I suggest to revert back this part of the JDK-8032435
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8048265
> Webrev can be found at: http://cr.openjdk.java.net/~serb/8048265/webrev.00
>

From artem.malinko at oracle.com  Tue Jul  1 14:34:01 2014
From: artem.malinko at oracle.com (artem malinko)
Date: Tue, 01 Jul 2014 18:34:01 +0400
Subject: <AWT Dev> Review request for 8040076: java.awt.List objects
 allowing multiple selections are not GC-ed
In-Reply-To: <53B17EDD.6090103@oracle.com>
References: <53AC3C7D.8030204@oracle.com> <53AC8CB5.1070806@oracle.com>
	<53B13931.9030104@oracle.com> <53B17EDD.6090103@oracle.com>
Message-ID: <53B2C6D9.8070802@oracle.com>

Hi, Antony and Petr! Thank you for detailed review.  I Hope this version 
is better.

Link:
http://cr.openjdk.java.net/~mcherkas/artem/webrev.05/

Petr:
"4. Lines 37-43. Normally we do not use blocks to group the code together."

As Anthony said it's just for limiting visibility. But maybe code logic would be more clear if explicitly null list reference, so I changed it.

"5. Are you sure that you do not need to wait for a frame to actually 
show up on the screen so that all the peers are guaranteed to get created?"
I'm pretty sure. List peer will be created if it's container peer not 
null. And container peer definitely not null at this stage because it 
was created in the same thread when we invoked setVisible() on JFrame.

Everything else is adjusted according recommendations.

On 30.06.2014 19:14, Anthony Petrov wrote:
> Hi Artem,
>
> 1. Your code still uses wrong formatting. Please just open this page 
> to see the problem with the lines indentation:
>
> http://cr.openjdk.java.net/~mcherkas/artem/webrev.02/src/windows/native/sun/windows/awt_Component.cpp.sdiff.html 
>
>
>
> 2. DASSERT() is only relevant for debug builds which we use very 
> rarely. I'd prefer to make this a run-time check. To compensate for 
> possible performance degradation, I suggest to place it to the else{} 
> branch of your if() statement, so that the check is only performed 
> when it's really needed.
>
>
> 3. A standard copyright header in the test file is missing. Please see 
> other tests for examples.
>
> 4. The test should also contain a @bug jtreg tag and mention the 
> concrete bug id that's being verified with this test.
>
> 5. The dispose() call is better placed to the finally{} block of the 
> try{} statement to ensure it's always executed.
>
> 6. You don't really need a System.exit() call in your test. If the 
> frame is dispose()'d in the finally{} block, the test will terminate 
> by itself.
>
> 7. In the catch{} block in the test() method, the if() statements 
> should either be one-liners, or enclose their "then" branches into 
> blocks {}.
>
> Also, Petr wrote:
>> 4. Lines 37-43. Normally we do not use blocks to group the code 
>> together.
>
> I think this is okay in this case. A block is used to limit the 
> visibility of the strong reference to the List object. We need it to 
> "convert" it into a WeakReference.
>
>
>> Where is the original reference created?
>
> It's created in the same method - CreateHWND(). Please examine the 
> code in AwtList to see that we only need to recreate the native 
> control (i.e. the hwnd) when an app toggles the multiple selection 
> property. So the code and the fix make sense to me. Perhaps we should 
> add a comment before the "if (m_peerObject == NULL)" check to explain 
> why we do this.
>
>
> -- 
> best regards,
> Anthony
>
> On 6/30/2014 2:17 PM, artem malinko wrote:
>> Thank you, Anthony.
>>
>> Yes, I think assertion won't be superfluous to prevent other bugs of
>> same type. Here is a version with assert.
>>
>> http://cr.openjdk.java.net/~mcherkas/artem/webrev.02/
>>
>> On 27.06.2014 1:12, Anthony Petrov wrote:
>>> Hi Artem,
>>>
>>> Please configure you code editor so that it formats the code that you
>>> modify according to Java code conventions used in OpenJDK (4-spaces
>>> line indentation, a space after "if" and before "{", etc.)
>>>
>>> Also, please include the bug id and synopsis to the subject line of
>>> your review requests. Please see other review threads on this mailing
>>> list for examples.
>>>
>>> As for the fix itself, should we add an assertion check to the
>>> CreateHWnd() method to verify that both peer and m_peerObject refer to
>>> the same Java object in case the latter is already set?
>>>
>>> -- 
>>> best regards,
>>> Anthony
>>>
>>> On 6/26/2014 7:30 PM, artem malinko wrote:
>>>> Hello, AWT Team.
>>>>
>>>> Please review a fix for the issue:
>>>> https://bugs.openjdk.java.net/browse/JDK-8040076
>>>> The fix is available at:
>>>> http://cr.openjdk.java.net/~mcherkas/artem/webrev.01/
>>>>
>>>> When method "void AwtList::SetMultiSelect" is invoked it invokes "void
>>>> AwtComponent::CreateHWnd" where m_peerObject initialized. But at this
>>>> stage m_peerObject already initialized and already holds ref to java
>>>> List object. So original m_peerObject is lost and ref to java List 
>>>> lost
>>>> as well. In the fix I've added check whether m_peerObject is 
>>>> initialized
>>>> or not.
>>>>
>>>> Thank you.
>>


From anton.nashatyrev at oracle.com  Tue Jul  1 17:20:42 2014
From: anton.nashatyrev at oracle.com (anton nashatyrev)
Date: Tue, 01 Jul 2014 21:20:42 +0400
Subject: <AWT Dev> [9] Review request for 8046495: KeyEvent can not be
 accepted in quick mouse clicking
Message-ID: <53B2EDEA.3010402@oracle.com>

Hello,
     could you please review the following fix:

fix: http://cr.openjdk.java.net/~anashaty/8046495/9/webrev.00/ 
<http://cr.openjdk.java.net/%7Eanashaty/8046495/9/webrev.00/>
bug: 
https://bugs.openjdk.java.net/browse/JDK-8046495<https://bugs.openjdk.java.net/browse/JDK-8025145>

*Problem:*
On Windows the later InputEvent may have earlier timestamp (getWhen()), 
which results in incorrect processing of enqueued input events and may 
also potentially be the reason of other artifacts

*Evaluation*:
On Windows we have some algorithm for calculating input event timestamp: 
jdk/src/windows/native/sun/windows/awt_Component.cpp:2100
Shortly the timestamp is calculated by the following formula:
     when = JVM_CurrentTimeMillis() - (GetTickCount() - GetMessageTime())

Where:
   JVM_CurrentTimeMillis() - the same as System.currentTimeMillis()
   GetTickCount() - Win32 function, current millis from boot time
   GetMessageTime() - Win32 function, millis from boot time of the 
latest native Message

In theory the formula looks good: we are trying our best to calculate 
the actual time of the OS message by taking the current JVM time 
(JVM_CurrentTimeMillis) and adjusting it with the offset (GetTickCount - 
GetMessageTime) which should indicate how many milliseconds ago from the 
current moment (GetTickCount) the message has been actually issued 
(GetMessageTime).
In practice due to usage of different system timers by the 
JVM_CurrentTimeMillis and GetTickCount their values are not updated 
synchronously and we may get an earlier timestamp for the later event.

*Fix*:
Just to use JVM_CurrentTimeMillis only as events timestamp. On Mac this 
is done in exactly the same way: CPlatformResponder.handleMouse/KeyEvent()

The message time offset calculation has been introduced with the fix for 
JDK-4434193 <https://bugs.openjdk.java.net/browse/JDK-4434193> and it 
seems that the issue has addressed very similar problem (At times 
getWhen()in ActionEvent returns higher value than the CurrentSystemTime) 
which has not been completely resolved in fact.
I also didn't find any benefits in using the existing approach:
- all the usages of the TimerHelper are in fact reduced to the mentioned 
formula: when = JVM_CurrentTimeMillis() - (GetTickCount() - 
GetMessageTime())
- GetMessageTime() always increases (except of the int overflow 
moments), thus we couldn't get earlier OS messages after later ones
- TimerHelper::windowsToUTC(DWORD windowsTime) doesn't guarantee 
returning the same timestamp across different calls for the same message 
time

Thanks!
Anton.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20140701/2fc1e846/attachment.html>

From anthony.petrov at oracle.com  Tue Jul  1 18:40:26 2014
From: anthony.petrov at oracle.com (Anthony Petrov)
Date: Tue, 01 Jul 2014 22:40:26 +0400
Subject: <AWT Dev> Review request for 8040076: java.awt.List objects
 allowing multiple selections are not GC-ed
In-Reply-To: <53B2C6D9.8070802@oracle.com>
References: <53AC3C7D.8030204@oracle.com> <53AC8CB5.1070806@oracle.com>
	<53B13931.9030104@oracle.com> <53B17EDD.6090103@oracle.com>
	<53B2C6D9.8070802@oracle.com>
Message-ID: <53B3009A.70906@oracle.com>

Hi Artem,

Note that assert() [1] is still not a run-time check because we specify 
-DNDEBUG when building Release binaries. To make it a runtime check, the 
code should check the condition explicitly, and if it's false, then 
raise a Java exception (e.g. AWTError) and return from the JNI method. 
However, I realize that our current code never fails the assertion 
anyway. So I'm leaving this issue up to you and other reviewers, in case 
anyone feels strongly about this.

Other than that, the fix looks fine to me. Thanks for your hard work.


[1] http://msdn.microsoft.com/en-us/library/9sb57dw4(v=vs.100).aspx

--
best regards,
Anthony

On 7/1/2014 6:34 PM, artem malinko wrote:
> Hi, Antony and Petr! Thank you for detailed review.  I Hope this version
> is better.
>
> Link:
> http://cr.openjdk.java.net/~mcherkas/artem/webrev.05/
>
> Petr:
> "4. Lines 37-43. Normally we do not use blocks to group the code together."
>
> As Anthony said it's just for limiting visibility. But maybe code logic
> would be more clear if explicitly null list reference, so I changed it.
>
> "5. Are you sure that you do not need to wait for a frame to actually
> show up on the screen so that all the peers are guaranteed to get created?"
> I'm pretty sure. List peer will be created if it's container peer not
> null. And container peer definitely not null at this stage because it
> was created in the same thread when we invoked setVisible() on JFrame.
>
> Everything else is adjusted according recommendations.
>
> On 30.06.2014 19:14, Anthony Petrov wrote:
>> Hi Artem,
>>
>> 1. Your code still uses wrong formatting. Please just open this page
>> to see the problem with the lines indentation:
>>
>> http://cr.openjdk.java.net/~mcherkas/artem/webrev.02/src/windows/native/sun/windows/awt_Component.cpp.sdiff.html
>>
>>
>>
>> 2. DASSERT() is only relevant for debug builds which we use very
>> rarely. I'd prefer to make this a run-time check. To compensate for
>> possible performance degradation, I suggest to place it to the else{}
>> branch of your if() statement, so that the check is only performed
>> when it's really needed.
>>
>>
>> 3. A standard copyright header in the test file is missing. Please see
>> other tests for examples.
>>
>> 4. The test should also contain a @bug jtreg tag and mention the
>> concrete bug id that's being verified with this test.
>>
>> 5. The dispose() call is better placed to the finally{} block of the
>> try{} statement to ensure it's always executed.
>>
>> 6. You don't really need a System.exit() call in your test. If the
>> frame is dispose()'d in the finally{} block, the test will terminate
>> by itself.
>>
>> 7. In the catch{} block in the test() method, the if() statements
>> should either be one-liners, or enclose their "then" branches into
>> blocks {}.
>>
>> Also, Petr wrote:
>>> 4. Lines 37-43. Normally we do not use blocks to group the code
>>> together.
>>
>> I think this is okay in this case. A block is used to limit the
>> visibility of the strong reference to the List object. We need it to
>> "convert" it into a WeakReference.
>>
>>
>>> Where is the original reference created?
>>
>> It's created in the same method - CreateHWND(). Please examine the
>> code in AwtList to see that we only need to recreate the native
>> control (i.e. the hwnd) when an app toggles the multiple selection
>> property. So the code and the fix make sense to me. Perhaps we should
>> add a comment before the "if (m_peerObject == NULL)" check to explain
>> why we do this.
>>
>>
>> --
>> best regards,
>> Anthony
>>
>> On 6/30/2014 2:17 PM, artem malinko wrote:
>>> Thank you, Anthony.
>>>
>>> Yes, I think assertion won't be superfluous to prevent other bugs of
>>> same type. Here is a version with assert.
>>>
>>> http://cr.openjdk.java.net/~mcherkas/artem/webrev.02/
>>>
>>> On 27.06.2014 1:12, Anthony Petrov wrote:
>>>> Hi Artem,
>>>>
>>>> Please configure you code editor so that it formats the code that you
>>>> modify according to Java code conventions used in OpenJDK (4-spaces
>>>> line indentation, a space after "if" and before "{", etc.)
>>>>
>>>> Also, please include the bug id and synopsis to the subject line of
>>>> your review requests. Please see other review threads on this mailing
>>>> list for examples.
>>>>
>>>> As for the fix itself, should we add an assertion check to the
>>>> CreateHWnd() method to verify that both peer and m_peerObject refer to
>>>> the same Java object in case the latter is already set?
>>>>
>>>> --
>>>> best regards,
>>>> Anthony
>>>>
>>>> On 6/26/2014 7:30 PM, artem malinko wrote:
>>>>> Hello, AWT Team.
>>>>>
>>>>> Please review a fix for the issue:
>>>>> https://bugs.openjdk.java.net/browse/JDK-8040076
>>>>> The fix is available at:
>>>>> http://cr.openjdk.java.net/~mcherkas/artem/webrev.01/
>>>>>
>>>>> When method "void AwtList::SetMultiSelect" is invoked it invokes "void
>>>>> AwtComponent::CreateHWnd" where m_peerObject initialized. But at this
>>>>> stage m_peerObject already initialized and already holds ref to java
>>>>> List object. So original m_peerObject is lost and ref to java List
>>>>> lost
>>>>> as well. In the fix I've added check whether m_peerObject is
>>>>> initialized
>>>>> or not.
>>>>>
>>>>> Thank you.
>>>
>

From anthony.petrov at oracle.com  Tue Jul  1 18:53:39 2014
From: anthony.petrov at oracle.com (Anthony Petrov)
Date: Tue, 01 Jul 2014 22:53:39 +0400
Subject: <AWT Dev> [9] Review Request: 8047336 Read flavormap.properties
 as resource
In-Reply-To: <977775FE-2CE5-4223-89CC-88F0339CD420@oracle.com>
References: <59786637-036B-49C3-AB92-0D5742C87AC2@oracle.com>	<53A2D3DA.4030503@oracle.com>	<B543154A-7C00-4024-9478-6D615E828190@oracle.com>
	<53A418B9.6080500@oracle.com> <53A41B16.9020404@oracle.com>
	<18DA96EE-B90D-4BAD-8990-6D4972446019@oracle.com>
	<53A41FF2.8050705@oracle.com>
	<977775FE-2CE5-4223-89CC-88F0339CD420@oracle.com>
Message-ID: <53B303B3.7000209@oracle.com>

Hi Petr,

The fix looks fine to me. Only one question:

src/share/classes/java/awt/datatransfer/SystemFlavorMap.java
>  234         } catch (IOException e) {
>  235             System.err.println("Warning reading flavor mapping: " + e.getMessage());

Is there a reason to hide the stack trace of the exception? Why wouldn't 
a simple call to e.printStackTrace() work? Or why not to throw an 
InternalError(e) in this case? We already throw it at line 228 if the 
resource cannot be open.

--
best regards,
Anthony

On 7/1/2014 12:35 PM, Petr Pchelko wrote:
> Hello,
>
> The changes in the public API have been approved, so let me continue the
> review process.
>
> For your convenience:
> The bug: https://bugs.openjdk.java.net/browse/JDK-8047336
> The fix: http://cr.openjdk.java.net/~pchelko/9/8047336/webrev.00/
>
> Until now we've been discussing an abstract question of moving the
> properties to a different location and agreed that it's possible.
> Now it's time for an official code review. Could someone please make one?
>
> Also some feedback from the build team is still required. Could someone
> from the build team review this fix please?
> (The question is that I've made a separate explicit rule for
> flavormap.properties file. If I add it to COPY_PATTERNS than the solaris
> version get's copied on Mac. Is that a bug in the build system? Is my
> current solution good enough?)
>
> Thank you.
> With best regards. Petr.
>
> On 20 ???? 2014 ?., at 15:50, Alan Bateman <Alan.Bateman at oracle.com
> <mailto:Alan.Bateman at oracle.com>> wrote:
>
>> On 20/06/2014 12:41, Petr Pchelko wrote:
>>> Hello, Anthony, Artem.
>>>
>>>>> Do we officially declare that we drop support for this possibility?
>>>> This possibility will be dropped regardless of the current Petr's
>>>> fix, since there will be no single "jre" folder in jigsaw world.
>>>> Probably, some other mechanism to customize files like
>>>> flavormap.properties or logging.properties will be introduced.
>>> And we can add a system property to set an alternative
>>> flavormap.properties file later if someone would request such a feature.
>>>
>>>> BTW, the current fix is not about flavormap.properties on its own,
>>>> but about removing AWT.DnD.flavorMapFileURL toolkit property. I
>>>> would suggest to push this change as a separate bug fix, not as a
>>>> part of 8047336.
>>> And also about changing flavormap.properties format) The current fix
>>> is all the work in datatransfer modularization that needs a CCC. All
>>> changes seem related, so I would prefer no to split it further,
>>> because it would make it harder to track when all the peaces are
>>> integrated to jake repository to continue the work. And it would need
>>> more CCC requests which consume time.
>>>
>> The forum post looks like is from 2001. If there doesn't appear that
>> many developers have resorted to editing that file then I would
>> suggest just going with what you have. If it really becomes necessary
>> to support having configuration elsewhere (not in the JDK image) then
>> I don't think anything that you have now precludes that.
>>
>> -Alan.
>

From petr.pchelko at oracle.com  Tue Jul  1 20:30:04 2014
From: petr.pchelko at oracle.com (Petr Pchelko)
Date: Wed, 2 Jul 2014 00:30:04 +0400
Subject: <AWT Dev> Review request for 8040076: java.awt.List objects
	allowing multiple selections are not GC-ed
In-Reply-To: <53B3009A.70906@oracle.com>
References: <53AC3C7D.8030204@oracle.com> <53AC8CB5.1070806@oracle.com>
	<53B13931.9030104@oracle.com> <53B17EDD.6090103@oracle.com>
	<53B2C6D9.8070802@oracle.com> <53B3009A.70906@oracle.com>
Message-ID: <AE94C870-3232-48A9-83B1-2193345E39A2@oracle.com>

Hello, Artem.

>> As Anthony said it's just for limiting visibility. 
I didn?t understand this actually. 

The new version looks good to me. 

With best regards. Petr.

> On Jul 1, 2014, at 10:40 PM, Anthony Petrov <anthony.petrov at oracle.com> wrote:
> 
> Hi Artem,
> 
> Note that assert() [1] is still not a run-time check because we specify -DNDEBUG when building Release binaries. To make it a runtime check, the code should check the condition explicitly, and if it's false, then raise a Java exception (e.g. AWTError) and return from the JNI method. However, I realize that our current code never fails the assertion anyway. So I'm leaving this issue up to you and other reviewers, in case anyone feels strongly about this.
> 
> Other than that, the fix looks fine to me. Thanks for your hard work.
> 
> 
> [1] http://msdn.microsoft.com/en-us/library/9sb57dw4(v=vs.100).aspx
> 
> --
> best regards,
> Anthony
> 
> On 7/1/2014 6:34 PM, artem malinko wrote:
>> Hi, Antony and Petr! Thank you for detailed review.  I Hope this version
>> is better.
>> 
>> Link:
>> http://cr.openjdk.java.net/~mcherkas/artem/webrev.05/
>> 
>> Petr:
>> "4. Lines 37-43. Normally we do not use blocks to group the code together."
>> 
>> As Anthony said it's just for limiting visibility. But maybe code logic
>> would be more clear if explicitly null list reference, so I changed it.
>> 
>> "5. Are you sure that you do not need to wait for a frame to actually
>> show up on the screen so that all the peers are guaranteed to get created?"
>> I'm pretty sure. List peer will be created if it's container peer not
>> null. And container peer definitely not null at this stage because it
>> was created in the same thread when we invoked setVisible() on JFrame.
>> 
>> Everything else is adjusted according recommendations.
>> 
>> On 30.06.2014 19:14, Anthony Petrov wrote:
>>> Hi Artem,
>>> 
>>> 1. Your code still uses wrong formatting. Please just open this page
>>> to see the problem with the lines indentation:
>>> 
>>> http://cr.openjdk.java.net/~mcherkas/artem/webrev.02/src/windows/native/sun/windows/awt_Component.cpp.sdiff.html
>>> 
>>> 
>>> 
>>> 2. DASSERT() is only relevant for debug builds which we use very
>>> rarely. I'd prefer to make this a run-time check. To compensate for
>>> possible performance degradation, I suggest to place it to the else{}
>>> branch of your if() statement, so that the check is only performed
>>> when it's really needed.
>>> 
>>> 
>>> 3. A standard copyright header in the test file is missing. Please see
>>> other tests for examples.
>>> 
>>> 4. The test should also contain a @bug jtreg tag and mention the
>>> concrete bug id that's being verified with this test.
>>> 
>>> 5. The dispose() call is better placed to the finally{} block of the
>>> try{} statement to ensure it's always executed.
>>> 
>>> 6. You don't really need a System.exit() call in your test. If the
>>> frame is dispose()'d in the finally{} block, the test will terminate
>>> by itself.
>>> 
>>> 7. In the catch{} block in the test() method, the if() statements
>>> should either be one-liners, or enclose their "then" branches into
>>> blocks {}.
>>> 
>>> Also, Petr wrote:
>>>> 4. Lines 37-43. Normally we do not use blocks to group the code
>>>> together.
>>> 
>>> I think this is okay in this case. A block is used to limit the
>>> visibility of the strong reference to the List object. We need it to
>>> "convert" it into a WeakReference.
>>> 
>>> 
>>>> Where is the original reference created?
>>> 
>>> It's created in the same method - CreateHWND(). Please examine the
>>> code in AwtList to see that we only need to recreate the native
>>> control (i.e. the hwnd) when an app toggles the multiple selection
>>> property. So the code and the fix make sense to me. Perhaps we should
>>> add a comment before the "if (m_peerObject == NULL)" check to explain
>>> why we do this.
>>> 
>>> 
>>> --
>>> best regards,
>>> Anthony
>>> 
>>> On 6/30/2014 2:17 PM, artem malinko wrote:
>>>> Thank you, Anthony.
>>>> 
>>>> Yes, I think assertion won't be superfluous to prevent other bugs of
>>>> same type. Here is a version with assert.
>>>> 
>>>> http://cr.openjdk.java.net/~mcherkas/artem/webrev.02/
>>>> 
>>>> On 27.06.2014 1:12, Anthony Petrov wrote:
>>>>> Hi Artem,
>>>>> 
>>>>> Please configure you code editor so that it formats the code that you
>>>>> modify according to Java code conventions used in OpenJDK (4-spaces
>>>>> line indentation, a space after "if" and before "{", etc.)
>>>>> 
>>>>> Also, please include the bug id and synopsis to the subject line of
>>>>> your review requests. Please see other review threads on this mailing
>>>>> list for examples.
>>>>> 
>>>>> As for the fix itself, should we add an assertion check to the
>>>>> CreateHWnd() method to verify that both peer and m_peerObject refer to
>>>>> the same Java object in case the latter is already set?
>>>>> 
>>>>> --
>>>>> best regards,
>>>>> Anthony
>>>>> 
>>>>> On 6/26/2014 7:30 PM, artem malinko wrote:
>>>>>> Hello, AWT Team.
>>>>>> 
>>>>>> Please review a fix for the issue:
>>>>>> https://bugs.openjdk.java.net/browse/JDK-8040076
>>>>>> The fix is available at:
>>>>>> http://cr.openjdk.java.net/~mcherkas/artem/webrev.01/
>>>>>> 
>>>>>> When method "void AwtList::SetMultiSelect" is invoked it invokes "void
>>>>>> AwtComponent::CreateHWnd" where m_peerObject initialized. But at this
>>>>>> stage m_peerObject already initialized and already holds ref to java
>>>>>> List object. So original m_peerObject is lost and ref to java List
>>>>>> lost
>>>>>> as well. In the fix I've added check whether m_peerObject is
>>>>>> initialized
>>>>>> or not.
>>>>>> 
>>>>>> Thank you.
>>>> 
>> 


From artem.malinko at oracle.com  Wed Jul  2 07:12:41 2014
From: artem.malinko at oracle.com (artem malinko)
Date: Wed, 02 Jul 2014 11:12:41 +0400
Subject: <AWT Dev> Review request for 8040076: java.awt.List objects
 allowing multiple selections are not GC-ed
In-Reply-To: <AE94C870-3232-48A9-83B1-2193345E39A2@oracle.com>
References: <53AC3C7D.8030204@oracle.com> <53AC8CB5.1070806@oracle.com>
	<53B13931.9030104@oracle.com> <53B17EDD.6090103@oracle.com>
	<53B2C6D9.8070802@oracle.com> <53B3009A.70906@oracle.com>
	<AE94C870-3232-48A9-83B1-2193345E39A2@oracle.com>
Message-ID: <53B3B0E9.70909@oracle.com>

Thank you.

Petr:

"I didn?t understand this actually."

// other method code...

{
   List list = new List();
   frame.add(list);
   list.setMultipleMode(true);
   frame.remove(list);
   weakRef = new WeakReference<List>(list);
}

// other method code...

After closed brace "list" does not exist and the only ref to actual list object is "weakRef". If I don't use code block I should explicitly write "list = null;". Both do the same, but code block was just more convenient for me.


On 02.07.2014 0:30, Petr Pchelko wrote:
> Hello, Artem.
>
>>> As Anthony said it's just for limiting visibility.
> I didn?t understand this actually.
>
> The new version looks good to me.
>
> With best regards. Petr.
>
>> On Jul 1, 2014, at 10:40 PM, Anthony Petrov <anthony.petrov at oracle.com> wrote:
>>
>> Hi Artem,
>>
>> Note that assert() [1] is still not a run-time check because we specify -DNDEBUG when building Release binaries. To make it a runtime check, the code should check the condition explicitly, and if it's false, then raise a Java exception (e.g. AWTError) and return from the JNI method. However, I realize that our current code never fails the assertion anyway. So I'm leaving this issue up to you and other reviewers, in case anyone feels strongly about this.
>>
>> Other than that, the fix looks fine to me. Thanks for your hard work.
>>
>>
>> [1] http://msdn.microsoft.com/en-us/library/9sb57dw4(v=vs.100).aspx
>>
>> --
>> best regards,
>> Anthony
>>
>> On 7/1/2014 6:34 PM, artem malinko wrote:
>>> Hi, Antony and Petr! Thank you for detailed review.  I Hope this version
>>> is better.
>>>
>>> Link:
>>> http://cr.openjdk.java.net/~mcherkas/artem/webrev.05/
>>>
>>> Petr:
>>> "4. Lines 37-43. Normally we do not use blocks to group the code together."
>>>
>>> As Anthony said it's just for limiting visibility. But maybe code logic
>>> would be more clear if explicitly null list reference, so I changed it.
>>>
>>> "5. Are you sure that you do not need to wait for a frame to actually
>>> show up on the screen so that all the peers are guaranteed to get created?"
>>> I'm pretty sure. List peer will be created if it's container peer not
>>> null. And container peer definitely not null at this stage because it
>>> was created in the same thread when we invoked setVisible() on JFrame.
>>>
>>> Everything else is adjusted according recommendations.
>>>
>>> On 30.06.2014 19:14, Anthony Petrov wrote:
>>>> Hi Artem,
>>>>
>>>> 1. Your code still uses wrong formatting. Please just open this page
>>>> to see the problem with the lines indentation:
>>>>
>>>> http://cr.openjdk.java.net/~mcherkas/artem/webrev.02/src/windows/native/sun/windows/awt_Component.cpp.sdiff.html
>>>>
>>>>
>>>>
>>>> 2. DASSERT() is only relevant for debug builds which we use very
>>>> rarely. I'd prefer to make this a run-time check. To compensate for
>>>> possible performance degradation, I suggest to place it to the else{}
>>>> branch of your if() statement, so that the check is only performed
>>>> when it's really needed.
>>>>
>>>>
>>>> 3. A standard copyright header in the test file is missing. Please see
>>>> other tests for examples.
>>>>
>>>> 4. The test should also contain a @bug jtreg tag and mention the
>>>> concrete bug id that's being verified with this test.
>>>>
>>>> 5. The dispose() call is better placed to the finally{} block of the
>>>> try{} statement to ensure it's always executed.
>>>>
>>>> 6. You don't really need a System.exit() call in your test. If the
>>>> frame is dispose()'d in the finally{} block, the test will terminate
>>>> by itself.
>>>>
>>>> 7. In the catch{} block in the test() method, the if() statements
>>>> should either be one-liners, or enclose their "then" branches into
>>>> blocks {}.
>>>>
>>>> Also, Petr wrote:
>>>>> 4. Lines 37-43. Normally we do not use blocks to group the code
>>>>> together.
>>>> I think this is okay in this case. A block is used to limit the
>>>> visibility of the strong reference to the List object. We need it to
>>>> "convert" it into a WeakReference.
>>>>
>>>>
>>>>> Where is the original reference created?
>>>> It's created in the same method - CreateHWND(). Please examine the
>>>> code in AwtList to see that we only need to recreate the native
>>>> control (i.e. the hwnd) when an app toggles the multiple selection
>>>> property. So the code and the fix make sense to me. Perhaps we should
>>>> add a comment before the "if (m_peerObject == NULL)" check to explain
>>>> why we do this.
>>>>
>>>>
>>>> --
>>>> best regards,
>>>> Anthony
>>>>
>>>> On 6/30/2014 2:17 PM, artem malinko wrote:
>>>>> Thank you, Anthony.
>>>>>
>>>>> Yes, I think assertion won't be superfluous to prevent other bugs of
>>>>> same type. Here is a version with assert.
>>>>>
>>>>> http://cr.openjdk.java.net/~mcherkas/artem/webrev.02/
>>>>>
>>>>> On 27.06.2014 1:12, Anthony Petrov wrote:
>>>>>> Hi Artem,
>>>>>>
>>>>>> Please configure you code editor so that it formats the code that you
>>>>>> modify according to Java code conventions used in OpenJDK (4-spaces
>>>>>> line indentation, a space after "if" and before "{", etc.)
>>>>>>
>>>>>> Also, please include the bug id and synopsis to the subject line of
>>>>>> your review requests. Please see other review threads on this mailing
>>>>>> list for examples.
>>>>>>
>>>>>> As for the fix itself, should we add an assertion check to the
>>>>>> CreateHWnd() method to verify that both peer and m_peerObject refer to
>>>>>> the same Java object in case the latter is already set?
>>>>>>
>>>>>> --
>>>>>> best regards,
>>>>>> Anthony
>>>>>>
>>>>>> On 6/26/2014 7:30 PM, artem malinko wrote:
>>>>>>> Hello, AWT Team.
>>>>>>>
>>>>>>> Please review a fix for the issue:
>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8040076
>>>>>>> The fix is available at:
>>>>>>> http://cr.openjdk.java.net/~mcherkas/artem/webrev.01/
>>>>>>>
>>>>>>> When method "void AwtList::SetMultiSelect" is invoked it invokes "void
>>>>>>> AwtComponent::CreateHWnd" where m_peerObject initialized. But at this
>>>>>>> stage m_peerObject already initialized and already holds ref to java
>>>>>>> List object. So original m_peerObject is lost and ref to java List
>>>>>>> lost
>>>>>>> as well. In the fix I've added check whether m_peerObject is
>>>>>>> initialized
>>>>>>> or not.
>>>>>>>
>>>>>>> Thank you.


From petr.pchelko at oracle.com  Wed Jul  2 07:44:03 2014
From: petr.pchelko at oracle.com (Petr Pchelko)
Date: Wed, 2 Jul 2014 11:44:03 +0400
Subject: <AWT Dev> [9] Review request for 8046495: KeyEvent can not be
	accepted in quick mouse clicking
In-Reply-To: <53B2EDEA.3010402@oracle.com>
References: <53B2EDEA.3010402@oracle.com>
Message-ID: <B4A1F8A6-25D8-4CA2-A138-95EC14A6A881@oracle.com>

Hello, Anton.

I'm not sure I have a detailed understanding of what's happening. 

Before your fix the timestamp of the event represented the time when the event was created, and now it's the time when it's sent to java.
This might be important if some events cause other events to be issued on the java side. 

So suppose the following:
Toolkit thread: InputEvent#1 created      - timestamp 0
Toolkit thread: InputEvent#2 created      - timestamp 1
Toolkit thread: InputEvent#1 sent           - timestamp 2
EDT:	               InputEvent#1 dispatched - timestamp 3
EDT:               FocusEvent  created        - timestamp 4
Toolkit thread: InputEvent#2 sent           - timestamp 5

Before you fix we had the following event order: InputEvent#1(ts=0), InputEvent#2(ts=1), FocusEvent(ts=4).
But after your fix we will have a different order: InputEvent#1(ts=2), FocusEvent(ts=4), InputEvent#2(ts=5).
So now we would have troubles, because the Input Event will go to the new focused component instead of the old one. 
Do you think that my arguments are correct? I understand that the likelihood of such a situation is very low, but for me it looks possible? Am I missing something?

Another thing I do not understand is why we were used to use the complicated formula instead of initializing the msg.time field with the JVM current time and using it when sending the event?
Wouldn't that resolve both your issue and the issue the original fix was made for?

I have a couple of comments about the code, but let's postpone that until we decide on the approach.

Thank you.
With best regards. Petr.

On 01 ???? 2014 ?., at 21:20, anton nashatyrev <anton.nashatyrev at oracle.com> wrote:

> Hello, 
>     could you please review the following fix:
> 
> fix: http://cr.openjdk.java.net/~anashaty/8046495/9/webrev.00/
> bug: https://bugs.openjdk.java.net/browse/JDK-8046495
> 
>     Problem: 
> On Windows the later InputEvent may have earlier timestamp (getWhen()), which results in incorrect processing of enqueued input events and may also potentially be the reason of other artifacts 
> 
>     Evaluation: 
> On Windows we have some algorithm for calculating input event timestamp: jdk/src/windows/native/sun/windows/awt_Component.cpp:2100
> Shortly the timestamp is calculated by the following formula: 
>     when = JVM_CurrentTimeMillis() - (GetTickCount() - GetMessageTime())
> 
> Where: 
>   JVM_CurrentTimeMillis() - the same as System.currentTimeMillis()
>   GetTickCount() - Win32 function, current millis from boot time
>   GetMessageTime() - Win32 function, millis from boot time of the latest native Message
> 
> In theory the formula looks good: we are trying our best to calculate the actual time of the OS message by taking the current JVM time (JVM_CurrentTimeMillis) and adjusting it with the offset (GetTickCount - GetMessageTime) which should indicate how many milliseconds ago from the current moment (GetTickCount) the message has been actually issued (GetMessageTime).
> In practice due to usage of different system timers by the JVM_CurrentTimeMillis and GetTickCount their values are not updated synchronously and we may get an earlier timestamp for the later event. 
> 
>     Fix: 
> Just to use JVM_CurrentTimeMillis only as events timestamp. On Mac this is done in exactly the same way: CPlatformResponder.handleMouse/KeyEvent()
> 
> The message time offset calculation has been introduced with the fix for JDK-4434193 and it seems that the issue has addressed very similar problem (At times getWhen()in ActionEvent returns higher value than the CurrentSystemTime) which has not been completely resolved in fact.
> I also didn't find any benefits in using the existing approach: 
> - all the usages of the TimerHelper are in fact reduced to the mentioned formula: when = JVM_CurrentTimeMillis() - (GetTickCount() - GetMessageTime())
> - GetMessageTime() always increases (except of the int overflow moments), thus we couldn't get earlier OS messages after later ones
> - TimerHelper::windowsToUTC(DWORD windowsTime) doesn't guarantee returning the same timestamp across different calls for the same message time 
> 
> Thanks! 
> Anton. 

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

From Alan.Bateman at oracle.com  Wed Jul  2 09:52:27 2014
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Wed, 02 Jul 2014 10:52:27 +0100
Subject: <AWT Dev> [9] Review Request: 8047336 Read flavormap.properties
 as resource
In-Reply-To: <977775FE-2CE5-4223-89CC-88F0339CD420@oracle.com>
References: <59786637-036B-49C3-AB92-0D5742C87AC2@oracle.com>	<53A2D3DA.4030503@oracle.com>	<B543154A-7C00-4024-9478-6D615E828190@oracle.com>
	<53A418B9.6080500@oracle.com> <53A41B16.9020404@oracle.com>
	<18DA96EE-B90D-4BAD-8990-6D4972446019@oracle.com>
	<53A41FF2.8050705@oracle.com>
	<977775FE-2CE5-4223-89CC-88F0339CD420@oracle.com>
Message-ID: <53B3D65B.7000500@oracle.com>

On 01/07/2014 09:35, Petr Pchelko wrote:
> Hello,
>
> The changes in the public API have been approved, so let me continue 
> the review process.
>
> For your convenience:
> The bug: https://bugs.openjdk.java.net/browse/JDK-8047336
> The fix: http://cr.openjdk.java.net/~pchelko/9/8047336/webrev.00/ 
> <http://cr.openjdk.java.net/%7Epchelko/9/8047336/webrev.00/>
>
> Until now we've been discussing an abstract question of moving the 
> properties to a different location and agreed that it's possible.
> Now it's time for an official code review. Could someone please make one?
>
> Also some feedback from the build team is still required. Could 
> someone from the build team review this fix please?
> (The question is that I've made a separate explicit rule for 
> flavormap.properties file. If I add it to COPY_PATTERNS than the 
> solaris version get's copied on Mac. Is that a bug in the build 
> system? Is my current solution good enough?)
>
I think this looks okay. I see Anthony's mail asking about the warning 
message and whether it should the print stack trace. I just wonder if it 
might be saner to just throw InternalError here. It throws InternalError 
if flavormap.properties is missing and it might be consistent to do the 
same when the file is corrupt or can't be parsed as a properties file.

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

From dmitry.markov at oracle.com  Wed Jul  2 10:45:05 2014
From: dmitry.markov at oracle.com (dmitry markov)
Date: Wed, 02 Jul 2014 14:45:05 +0400
Subject: <AWT Dev> [9] Review request for 8044614: [macosx] Focus issue with
 2 applets in firefox
Message-ID: <53B3E2B1.1030303@oracle.com>

Hello,

Could you review the fix for jdk9, please?

     bug: https://bugs.openjdk.java.net/browse/JDK-8044614
     webrev: http://cr.openjdk.java.net/~dmarkov/8044614/jdk9/webrev.00/

Problem description: on Mac OSX when switching between several applets 
running in separate browser's windows, the applet in active window does 
not receive focus.
Fix: the method CEmbeddedFrame.handleWindowFocusEvent() should be 
modified. It has to detect the switching between browser's windows and 
update focusedWindow field accordingly.

Thanks,
Dmitry

From petr.pchelko at oracle.com  Wed Jul  2 10:58:34 2014
From: petr.pchelko at oracle.com (Petr Pchelko)
Date: Wed, 2 Jul 2014 14:58:34 +0400
Subject: <AWT Dev> [9] Review Request: 8033367 [macosx] Appletviewer was
	broken in jdk8 b124
In-Reply-To: <539F3831.4060307@oracle.com>
References: <0FFA30BF-BDC5-4B0C-8E8A-B8982A60EE97@oracle.com>
	<538DD4C5.7050401@oracle.com>
	<555DBA9F-86C0-4BCA-A5CA-B19F3CE42828@oracle.com>
	<539F3831.4060307@oracle.com>
Message-ID: <CCB1ACCF-93B3-4142-9118-0A1447A8EC5F@oracle.com>

Hello,

Is anyone willing to make a second review?

Thank you.
With best regards. Petr.

On 16 ???? 2014 ?., at 22:32, Anthony Petrov <anthony.petrov at oracle.com> wrote:

> Hi Petr,
> 
> Thanks for the update. The fix looks fine.
> 
> --
> best regards,
> Anthony
> 
> On 6/16/2014 3:31 PM, Petr Pchelko wrote:
>> Hello, Anthony.
>> 
>> Thanks for the review, the new version is here:
>> http://cr.openjdk.java.net/~pchelko/9/8033367/webrev.01/
>> 
>> I've also made eawt Application start AppKit, I've forgot about this one initially.
>> Now I've made a grep over all loadLibrary("awt") usages and is looks like it's
>> replaced with getDefaultToolkit in all places we need.
>> 
>> With best regards. Petr.
>> 
>> On 03 ???? 2014 ?., at 17:59, Anthony Petrov <anthony.petrov at oracle.com> wrote:
>> 
>>> Hi Petr,
>>> 
>>> The fix looks good to me. One minor nit: every file that includes AWT_debug.h will contain its own copy of the ShouldPrintVerboseDebugging() function and the debug flag. Could we have only one copy instead?
>>> 
>>> --
>>> best regards,
>>> Anthony
>>> 
>>> On 6/3/2014 3:18 PM, Petr Pchelko wrote:
>>>> Hello, AWT Team.
>>>> 
>>>> Please review a little fix for the issue:
>>>> https://bugs.openjdk.java.net/browse/JDK-8033367
>>>> The fix is available here:
>>>> http://cr.openjdk.java.net/~pchelko/9/8033367/webrev/
>>>> 
>>>> The problem:
>>>> We were doing too much in JNI_OnLoad. Loading many classes, making sync calls to Appkit thread, loading classes and native libs from Appkit thread and so on.
>>>> This was causing deadlocks and crashes that we've workarounded for 8. But for 9 I've rewritten the AWT startup code to make JNI_OnLoad do a bit less work.
>>>> 
>>>> The solution:
>>>> Now loading awt native lib does not trigger loading AppKit and starting NSApplication. Instead we just load a library and tell Cocoa we are going to be multithreaded.
>>>> We start Appkit when Toolkit is created, so now we avoid problems with deadlocks on runtime lock.
>>>> 
>>>> An issue with the fix:
>>>> I've made GraphicsEnvironment also load AppKit, because we use an NSView for a scratch surface in an OpenGL context. Really this is quite likely not needed as we are
>>>> (should be) using FBOs for offscreen rendering. But getting rid of an NSView-based scratch surface is a separate big project, so I'll file a bug for it and now let's load
>>>> Appkit when GraphicsEnvironment is initialized too.
>>>> 
>>>> Testing:
>>>> I have run all JCK, all regression tests, sanity-tested JFX interop and SWT interop, checked applets and webstart, tested headless mode. Everything seems to work fine,
>>>> but anyway this fix is extremely risky. But this should be done if we want to avoid a problems like JDK-8033367 or JDK-8031050.
>>>> 
>>>> Thank you.
>>>> With best regards. Petr.
>>>> 
>> 


From Sergey.Bylokhov at oracle.com  Wed Jul  2 11:08:11 2014
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Wed, 02 Jul 2014 15:08:11 +0400
Subject: <AWT Dev> [9] Review Request: 8033367 [macosx] Appletviewer was
 broken in jdk8 b124
In-Reply-To: <CCB1ACCF-93B3-4142-9118-0A1447A8EC5F@oracle.com>
References: <0FFA30BF-BDC5-4B0C-8E8A-B8982A60EE97@oracle.com>
	<538DD4C5.7050401@oracle.com>
	<555DBA9F-86C0-4BCA-A5CA-B19F3CE42828@oracle.com>
	<539F3831.4060307@oracle.com>
	<CCB1ACCF-93B3-4142-9118-0A1447A8EC5F@oracle.com>
Message-ID: <53B3E81B.9040509@oracle.com>

Hi, Petr.
Looks like there are some links to the awt.m in the source code.
In the Awt2dLibraries.gmk and in the java_md_macosx.c

On 02.07.2014 14:58, Petr Pchelko wrote:
> Hello,
>
> Is anyone willing to make a second review?
>
> Thank you.
> With best regards. Petr.
>
> On 16 ???? 2014 ?., at 22:32, Anthony Petrov <anthony.petrov at oracle.com> wrote:
>
>> Hi Petr,
>>
>> Thanks for the update. The fix looks fine.
>>
>> --
>> best regards,
>> Anthony
>>
>> On 6/16/2014 3:31 PM, Petr Pchelko wrote:
>>> Hello, Anthony.
>>>
>>> Thanks for the review, the new version is here:
>>> http://cr.openjdk.java.net/~pchelko/9/8033367/webrev.01/
>>>
>>> I've also made eawt Application start AppKit, I've forgot about this one initially.
>>> Now I've made a grep over all loadLibrary("awt") usages and is looks like it's
>>> replaced with getDefaultToolkit in all places we need.
>>>
>>> With best regards. Petr.
>>>
>>> On 03 ???? 2014 ?., at 17:59, Anthony Petrov <anthony.petrov at oracle.com> wrote:
>>>
>>>> Hi Petr,
>>>>
>>>> The fix looks good to me. One minor nit: every file that includes AWT_debug.h will contain its own copy of the ShouldPrintVerboseDebugging() function and the debug flag. Could we have only one copy instead?
>>>>
>>>> --
>>>> best regards,
>>>> Anthony
>>>>
>>>> On 6/3/2014 3:18 PM, Petr Pchelko wrote:
>>>>> Hello, AWT Team.
>>>>>
>>>>> Please review a little fix for the issue:
>>>>> https://bugs.openjdk.java.net/browse/JDK-8033367
>>>>> The fix is available here:
>>>>> http://cr.openjdk.java.net/~pchelko/9/8033367/webrev/
>>>>>
>>>>> The problem:
>>>>> We were doing too much in JNI_OnLoad. Loading many classes, making sync calls to Appkit thread, loading classes and native libs from Appkit thread and so on.
>>>>> This was causing deadlocks and crashes that we've workarounded for 8. But for 9 I've rewritten the AWT startup code to make JNI_OnLoad do a bit less work.
>>>>>
>>>>> The solution:
>>>>> Now loading awt native lib does not trigger loading AppKit and starting NSApplication. Instead we just load a library and tell Cocoa we are going to be multithreaded.
>>>>> We start Appkit when Toolkit is created, so now we avoid problems with deadlocks on runtime lock.
>>>>>
>>>>> An issue with the fix:
>>>>> I've made GraphicsEnvironment also load AppKit, because we use an NSView for a scratch surface in an OpenGL context. Really this is quite likely not needed as we are
>>>>> (should be) using FBOs for offscreen rendering. But getting rid of an NSView-based scratch surface is a separate big project, so I'll file a bug for it and now let's load
>>>>> Appkit when GraphicsEnvironment is initialized too.
>>>>>
>>>>> Testing:
>>>>> I have run all JCK, all regression tests, sanity-tested JFX interop and SWT interop, checked applets and webstart, tested headless mode. Everything seems to work fine,
>>>>> but anyway this fix is extremely risky. But this should be done if we want to avoid a problems like JDK-8033367 or JDK-8031050.
>>>>>
>>>>> Thank you.
>>>>> With best regards. Petr.
>>>>>


-- 
Best regards, Sergey.


From petr.pchelko at oracle.com  Wed Jul  2 11:10:33 2014
From: petr.pchelko at oracle.com (Petr Pchelko)
Date: Wed, 2 Jul 2014 15:10:33 +0400
Subject: <AWT Dev> [9] Review Request: 8047336 Read flavormap.properties
	as resource
In-Reply-To: <53B3D65B.7000500@oracle.com>
References: <59786637-036B-49C3-AB92-0D5742C87AC2@oracle.com>	<53A2D3DA.4030503@oracle.com>	<B543154A-7C00-4024-9478-6D615E828190@oracle.com>
	<53A418B9.6080500@oracle.com> <53A41B16.9020404@oracle.com>
	<18DA96EE-B90D-4BAD-8990-6D4972446019@oracle.com>
	<53A41FF2.8050705@oracle.com>
	<977775FE-2CE5-4223-89CC-88F0339CD420@oracle.com>
	<53B3D65B.7000500@oracle.com>
Message-ID: <0427C75B-FF62-4E86-818D-924AF164D8AC@oracle.com>

Hello, Anthony, Alan.

Thank you for the review, the new version is located here:
http://cr.openjdk.java.net/~pchelko/9/8047336/webrev.01/

I've changed the code to throw an InternalError if we cannot read properties.
Once I get feedback from the build team - I'll push this fix.

With best regards. Petr.

On 02 ???? 2014 ?., at 13:52, Alan Bateman <Alan.Bateman at oracle.com> wrote:

> On 01/07/2014 09:35, Petr Pchelko wrote:
>> Hello, 
>> 
>> The changes in the public API have been approved, so let me continue the review process.
>> 
>> For your convenience:
>> The bug: https://bugs.openjdk.java.net/browse/JDK-8047336
>> The fix: http://cr.openjdk.java.net/~pchelko/9/8047336/webrev.00/
>> 
>> Until now we've been discussing an abstract question of moving the properties to a different location and agreed that it's possible.
>> Now it's time for an official code review. Could someone please make one?
>> 
>> Also some feedback from the build team is still required. Could someone from the build team review this fix please? 
>> (The question is that I've made a separate explicit rule for flavormap.properties file. If I add it to COPY_PATTERNS than the solaris version get's copied on Mac. Is that a bug in the build system? Is my current solution good enough?)
>> 
> I think this looks okay. I see Anthony's mail asking about the warning message and whether it should the print stack trace. I just wonder if it might be saner to just throw InternalError here. It throws InternalError if flavormap.properties is missing and it might be consistent to do the same when the file is corrupt or can't be parsed as a properties file.
> 
> -Alan.

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

From Alan.Bateman at oracle.com  Wed Jul  2 11:13:02 2014
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Wed, 02 Jul 2014 12:13:02 +0100
Subject: <AWT Dev> [9] Review Request: 8047336 Read flavormap.properties
 as resource
In-Reply-To: <0427C75B-FF62-4E86-818D-924AF164D8AC@oracle.com>
References: <59786637-036B-49C3-AB92-0D5742C87AC2@oracle.com>	<53A2D3DA.4030503@oracle.com>	<B543154A-7C00-4024-9478-6D615E828190@oracle.com>
	<53A418B9.6080500@oracle.com> <53A41B16.9020404@oracle.com>
	<18DA96EE-B90D-4BAD-8990-6D4972446019@oracle.com>
	<53A41FF2.8050705@oracle.com>
	<977775FE-2CE5-4223-89CC-88F0339CD420@oracle.com>
	<53B3D65B.7000500@oracle.com>
	<0427C75B-FF62-4E86-818D-924AF164D8AC@oracle.com>
Message-ID: <53B3E93E.5040400@oracle.com>

On 02/07/2014 12:10, Petr Pchelko wrote:
> Hello, Anthony, Alan.
>
> Thank you for the review, the new version is located here:
> http://cr.openjdk.java.net/~pchelko/9/8047336/webrev.01/ 
> <http://cr.openjdk.java.net/%7Epchelko/9/8047336/webrev.00/>
>
> I've changed the code to throw an InternalError if we cannot read 
> properties.
> Once I get feedback from the build team - I'll push this fix.
>
This looks okay to me now.

-Alan.

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

From anthony.petrov at oracle.com  Wed Jul  2 11:13:08 2014
From: anthony.petrov at oracle.com (Anthony Petrov)
Date: Wed, 02 Jul 2014 15:13:08 +0400
Subject: <AWT Dev> [9] Review Request: 8047336 Read flavormap.properties
 as resource
In-Reply-To: <0427C75B-FF62-4E86-818D-924AF164D8AC@oracle.com>
References: <59786637-036B-49C3-AB92-0D5742C87AC2@oracle.com>	<53A2D3DA.4030503@oracle.com>	<B543154A-7C00-4024-9478-6D615E828190@oracle.com>	<53A418B9.6080500@oracle.com>
	<53A41B16.9020404@oracle.com>	<18DA96EE-B90D-4BAD-8990-6D4972446019@oracle.com>	<53A41FF2.8050705@oracle.com>	<977775FE-2CE5-4223-89CC-88F0339CD420@oracle.com>	<53B3D65B.7000500@oracle.com>
	<0427C75B-FF62-4E86-818D-924AF164D8AC@oracle.com>
Message-ID: <53B3E944.30501@oracle.com>

Thanks. Note that your email editor messed up the HTML part of the email 
(see below a text-only quote), so here's the correct link to the webrev:

http://cr.openjdk.java.net/~pchelko/9/8047336/webrev.01/

The fix looks fine to me.

--
best regards,
Anthony

On 7/2/2014 3:10 PM, Petr Pchelko wrote:
> Hello, Anthony, Alan.
>
> Thank you for the review, the new version is located here:
> http://cr.openjdk.java.net/~pchelko/9/8047336/webrev.01/
> <http://cr.openjdk.java.net/%7Epchelko/9/8047336/webrev.00/>
>
> I've changed the code to throw an InternalError if we cannot read
> properties.
> Once I get feedback from the build team - I'll push this fix.
>
> With best regards. Petr.
>
> On 02 ???? 2014 ?., at 13:52, Alan Bateman <Alan.Bateman at oracle.com
> <mailto:Alan.Bateman at oracle.com>> wrote:
>
>> On 01/07/2014 09:35, Petr Pchelko wrote:
>>> Hello,
>>>
>>> The changes in the public API have been approved, so let me continue
>>> the review process.
>>>
>>> For your convenience:
>>> The bug: https://bugs.openjdk.java.net/browse/JDK-8047336
>>> The fix: http://cr.openjdk.java.net/~pchelko/9/8047336/webrev.00/
>>> <http://cr.openjdk.java.net/%7Epchelko/9/8047336/webrev.00/>
>>>
>>> Until now we've been discussing an abstract question of moving the
>>> properties to a different location and agreed that it's possible.
>>> Now it's time for an official code review. Could someone please make one?
>>>
>>> Also some feedback from the build team is still required. Could
>>> someone from the build team review this fix please?
>>> (The question is that I've made a separate explicit rule for
>>> flavormap.properties file. If I add it to COPY_PATTERNS than the
>>> solaris version get's copied on Mac. Is that a bug in the build
>>> system? Is my current solution good enough?)
>>>
>> I think this looks okay. I see Anthony's mail asking about the warning
>> message and whether it should the print stack trace. I just wonder if
>> it might be saner to just throw InternalError here. It throws
>> InternalError if flavormap.properties is missing and it might be
>> consistent to do the same when the file is corrupt or can't be parsed
>> as a properties file.
>>
>> -Alan.
>

From petr.pchelko at oracle.com  Wed Jul  2 11:20:40 2014
From: petr.pchelko at oracle.com (Petr Pchelko)
Date: Wed, 2 Jul 2014 15:20:40 +0400
Subject: <AWT Dev> [9] Review Request: 8033367 [macosx] Appletviewer was
	broken in jdk8 b124
In-Reply-To: <53B3E81B.9040509@oracle.com>
References: <0FFA30BF-BDC5-4B0C-8E8A-B8982A60EE97@oracle.com>
	<538DD4C5.7050401@oracle.com>
	<555DBA9F-86C0-4BCA-A5CA-B19F3CE42828@oracle.com>
	<539F3831.4060307@oracle.com>
	<CCB1ACCF-93B3-4142-9118-0A1447A8EC5F@oracle.com>
	<53B3E81B.9040509@oracle.com>
Message-ID: <639B483A-1F49-40E9-9A50-22A518199020@oracle.com>

Hello, Sergey.

Thank you for the review, great catch.
The new version is here: http://cr.openjdk.java.net/~pchelko/9/8033367/webrev.02/

I've grepped the sources, there are no other references to the awt.m file.

With best regards. Petr.

On 02 ???? 2014 ?., at 15:08, Sergey Bylokhov <Sergey.Bylokhov at oracle.com> wrote:

> Hi, Petr.
> Looks like there are some links to the awt.m in the source code.
> In the Awt2dLibraries.gmk and in the java_md_macosx.c
> 
> On 02.07.2014 14:58, Petr Pchelko wrote:
>> Hello,
>> 
>> Is anyone willing to make a second review?
>> 
>> Thank you.
>> With best regards. Petr.
>> 
>> On 16 ???? 2014 ?., at 22:32, Anthony Petrov <anthony.petrov at oracle.com> wrote:
>> 
>>> Hi Petr,
>>> 
>>> Thanks for the update. The fix looks fine.
>>> 
>>> --
>>> best regards,
>>> Anthony
>>> 
>>> On 6/16/2014 3:31 PM, Petr Pchelko wrote:
>>>> Hello, Anthony.
>>>> 
>>>> Thanks for the review, the new version is here:
>>>> http://cr.openjdk.java.net/~pchelko/9/8033367/webrev.01/
>>>> 
>>>> I've also made eawt Application start AppKit, I've forgot about this one initially.
>>>> Now I've made a grep over all loadLibrary("awt") usages and is looks like it's
>>>> replaced with getDefaultToolkit in all places we need.
>>>> 
>>>> With best regards. Petr.
>>>> 
>>>> On 03 ???? 2014 ?., at 17:59, Anthony Petrov <anthony.petrov at oracle.com> wrote:
>>>> 
>>>>> Hi Petr,
>>>>> 
>>>>> The fix looks good to me. One minor nit: every file that includes AWT_debug.h will contain its own copy of the ShouldPrintVerboseDebugging() function and the debug flag. Could we have only one copy instead?
>>>>> 
>>>>> --
>>>>> best regards,
>>>>> Anthony
>>>>> 
>>>>> On 6/3/2014 3:18 PM, Petr Pchelko wrote:
>>>>>> Hello, AWT Team.
>>>>>> 
>>>>>> Please review a little fix for the issue:
>>>>>> https://bugs.openjdk.java.net/browse/JDK-8033367
>>>>>> The fix is available here:
>>>>>> http://cr.openjdk.java.net/~pchelko/9/8033367/webrev/
>>>>>> 
>>>>>> The problem:
>>>>>> We were doing too much in JNI_OnLoad. Loading many classes, making sync calls to Appkit thread, loading classes and native libs from Appkit thread and so on.
>>>>>> This was causing deadlocks and crashes that we've workarounded for 8. But for 9 I've rewritten the AWT startup code to make JNI_OnLoad do a bit less work.
>>>>>> 
>>>>>> The solution:
>>>>>> Now loading awt native lib does not trigger loading AppKit and starting NSApplication. Instead we just load a library and tell Cocoa we are going to be multithreaded.
>>>>>> We start Appkit when Toolkit is created, so now we avoid problems with deadlocks on runtime lock.
>>>>>> 
>>>>>> An issue with the fix:
>>>>>> I've made GraphicsEnvironment also load AppKit, because we use an NSView for a scratch surface in an OpenGL context. Really this is quite likely not needed as we are
>>>>>> (should be) using FBOs for offscreen rendering. But getting rid of an NSView-based scratch surface is a separate big project, so I'll file a bug for it and now let's load
>>>>>> Appkit when GraphicsEnvironment is initialized too.
>>>>>> 
>>>>>> Testing:
>>>>>> I have run all JCK, all regression tests, sanity-tested JFX interop and SWT interop, checked applets and webstart, tested headless mode. Everything seems to work fine,
>>>>>> but anyway this fix is extremely risky. But this should be done if we want to avoid a problems like JDK-8033367 or JDK-8031050.
>>>>>> 
>>>>>> Thank you.
>>>>>> With best regards. Petr.
>>>>>> 
> 
> 
> -- 
> Best regards, Sergey.
> 


From anthony.petrov at oracle.com  Wed Jul  2 11:22:23 2014
From: anthony.petrov at oracle.com (Anthony Petrov)
Date: Wed, 02 Jul 2014 15:22:23 +0400
Subject: <AWT Dev> [9] Review Request: 8033367 [macosx] Appletviewer was
 broken in jdk8 b124
In-Reply-To: <639B483A-1F49-40E9-9A50-22A518199020@oracle.com>
References: <0FFA30BF-BDC5-4B0C-8E8A-B8982A60EE97@oracle.com>	<538DD4C5.7050401@oracle.com>	<555DBA9F-86C0-4BCA-A5CA-B19F3CE42828@oracle.com>	<539F3831.4060307@oracle.com>	<CCB1ACCF-93B3-4142-9118-0A1447A8EC5F@oracle.com>	<53B3E81B.9040509@oracle.com>
	<639B483A-1F49-40E9-9A50-22A518199020@oracle.com>
Message-ID: <53B3EB6F.7030208@oracle.com>

The fix still looks fine to me.

--
best regards,
Anthony

On 7/2/2014 3:20 PM, Petr Pchelko wrote:
> Hello, Sergey.
>
> Thank you for the review, great catch.
> The new version is here: http://cr.openjdk.java.net/~pchelko/9/8033367/webrev.02/
>
> I've grepped the sources, there are no other references to the awt.m file.
>
> With best regards. Petr.
>
> On 02 ???? 2014 ?., at 15:08, Sergey Bylokhov <Sergey.Bylokhov at oracle.com> wrote:
>
>> Hi, Petr.
>> Looks like there are some links to the awt.m in the source code.
>> In the Awt2dLibraries.gmk and in the java_md_macosx.c
>>
>> On 02.07.2014 14:58, Petr Pchelko wrote:
>>> Hello,
>>>
>>> Is anyone willing to make a second review?
>>>
>>> Thank you.
>>> With best regards. Petr.
>>>
>>> On 16 ???? 2014 ?., at 22:32, Anthony Petrov <anthony.petrov at oracle.com> wrote:
>>>
>>>> Hi Petr,
>>>>
>>>> Thanks for the update. The fix looks fine.
>>>>
>>>> --
>>>> best regards,
>>>> Anthony
>>>>
>>>> On 6/16/2014 3:31 PM, Petr Pchelko wrote:
>>>>> Hello, Anthony.
>>>>>
>>>>> Thanks for the review, the new version is here:
>>>>> http://cr.openjdk.java.net/~pchelko/9/8033367/webrev.01/
>>>>>
>>>>> I've also made eawt Application start AppKit, I've forgot about this one initially.
>>>>> Now I've made a grep over all loadLibrary("awt") usages and is looks like it's
>>>>> replaced with getDefaultToolkit in all places we need.
>>>>>
>>>>> With best regards. Petr.
>>>>>
>>>>> On 03 ???? 2014 ?., at 17:59, Anthony Petrov <anthony.petrov at oracle.com> wrote:
>>>>>
>>>>>> Hi Petr,
>>>>>>
>>>>>> The fix looks good to me. One minor nit: every file that includes AWT_debug.h will contain its own copy of the ShouldPrintVerboseDebugging() function and the debug flag. Could we have only one copy instead?
>>>>>>
>>>>>> --
>>>>>> best regards,
>>>>>> Anthony
>>>>>>
>>>>>> On 6/3/2014 3:18 PM, Petr Pchelko wrote:
>>>>>>> Hello, AWT Team.
>>>>>>>
>>>>>>> Please review a little fix for the issue:
>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8033367
>>>>>>> The fix is available here:
>>>>>>> http://cr.openjdk.java.net/~pchelko/9/8033367/webrev/
>>>>>>>
>>>>>>> The problem:
>>>>>>> We were doing too much in JNI_OnLoad. Loading many classes, making sync calls to Appkit thread, loading classes and native libs from Appkit thread and so on.
>>>>>>> This was causing deadlocks and crashes that we've workarounded for 8. But for 9 I've rewritten the AWT startup code to make JNI_OnLoad do a bit less work.
>>>>>>>
>>>>>>> The solution:
>>>>>>> Now loading awt native lib does not trigger loading AppKit and starting NSApplication. Instead we just load a library and tell Cocoa we are going to be multithreaded.
>>>>>>> We start Appkit when Toolkit is created, so now we avoid problems with deadlocks on runtime lock.
>>>>>>>
>>>>>>> An issue with the fix:
>>>>>>> I've made GraphicsEnvironment also load AppKit, because we use an NSView for a scratch surface in an OpenGL context. Really this is quite likely not needed as we are
>>>>>>> (should be) using FBOs for offscreen rendering. But getting rid of an NSView-based scratch surface is a separate big project, so I'll file a bug for it and now let's load
>>>>>>> Appkit when GraphicsEnvironment is initialized too.
>>>>>>>
>>>>>>> Testing:
>>>>>>> I have run all JCK, all regression tests, sanity-tested JFX interop and SWT interop, checked applets and webstart, tested headless mode. Everything seems to work fine,
>>>>>>> but anyway this fix is extremely risky. But this should be done if we want to avoid a problems like JDK-8033367 or JDK-8031050.
>>>>>>>
>>>>>>> Thank you.
>>>>>>> With best regards. Petr.
>>>>>>>
>>
>>
>> --
>> Best regards, Sergey.
>>
>

From Sergey.Bylokhov at oracle.com  Wed Jul  2 12:33:43 2014
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Wed, 02 Jul 2014 16:33:43 +0400
Subject: <AWT Dev> [9] Review Request: 8033367 [macosx] Appletviewer was
 broken in jdk8 b124
In-Reply-To: <639B483A-1F49-40E9-9A50-22A518199020@oracle.com>
References: <0FFA30BF-BDC5-4B0C-8E8A-B8982A60EE97@oracle.com>
	<538DD4C5.7050401@oracle.com>
	<555DBA9F-86C0-4BCA-A5CA-B19F3CE42828@oracle.com>
	<539F3831.4060307@oracle.com>
	<CCB1ACCF-93B3-4142-9118-0A1447A8EC5F@oracle.com>
	<53B3E81B.9040509@oracle.com>
	<639B483A-1F49-40E9-9A50-22A518199020@oracle.com>
Message-ID: <53B3FC27.4000204@oracle.com>

Hi, Petr.
The fix looks good.

On 02.07.2014 15:20, Petr Pchelko wrote:
> Hello, Sergey.
>
> Thank you for the review, great catch.
> The new version is here: http://cr.openjdk.java.net/~pchelko/9/8033367/webrev.02/
>
> I've grepped the sources, there are no other references to the awt.m file.
>
> With best regards. Petr.
>
> On 02 ???? 2014 ?., at 15:08, Sergey Bylokhov <Sergey.Bylokhov at oracle.com> wrote:
>
>> Hi, Petr.
>> Looks like there are some links to the awt.m in the source code.
>> In the Awt2dLibraries.gmk and in the java_md_macosx.c
>>
>> On 02.07.2014 14:58, Petr Pchelko wrote:
>>> Hello,
>>>
>>> Is anyone willing to make a second review?
>>>
>>> Thank you.
>>> With best regards. Petr.
>>>
>>> On 16 ???? 2014 ?., at 22:32, Anthony Petrov <anthony.petrov at oracle.com> wrote:
>>>
>>>> Hi Petr,
>>>>
>>>> Thanks for the update. The fix looks fine.
>>>>
>>>> --
>>>> best regards,
>>>> Anthony
>>>>
>>>> On 6/16/2014 3:31 PM, Petr Pchelko wrote:
>>>>> Hello, Anthony.
>>>>>
>>>>> Thanks for the review, the new version is here:
>>>>> http://cr.openjdk.java.net/~pchelko/9/8033367/webrev.01/
>>>>>
>>>>> I've also made eawt Application start AppKit, I've forgot about this one initially.
>>>>> Now I've made a grep over all loadLibrary("awt") usages and is looks like it's
>>>>> replaced with getDefaultToolkit in all places we need.
>>>>>
>>>>> With best regards. Petr.
>>>>>
>>>>> On 03 ???? 2014 ?., at 17:59, Anthony Petrov <anthony.petrov at oracle.com> wrote:
>>>>>
>>>>>> Hi Petr,
>>>>>>
>>>>>> The fix looks good to me. One minor nit: every file that includes AWT_debug.h will contain its own copy of the ShouldPrintVerboseDebugging() function and the debug flag. Could we have only one copy instead?
>>>>>>
>>>>>> --
>>>>>> best regards,
>>>>>> Anthony
>>>>>>
>>>>>> On 6/3/2014 3:18 PM, Petr Pchelko wrote:
>>>>>>> Hello, AWT Team.
>>>>>>>
>>>>>>> Please review a little fix for the issue:
>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8033367
>>>>>>> The fix is available here:
>>>>>>> http://cr.openjdk.java.net/~pchelko/9/8033367/webrev/
>>>>>>>
>>>>>>> The problem:
>>>>>>> We were doing too much in JNI_OnLoad. Loading many classes, making sync calls to Appkit thread, loading classes and native libs from Appkit thread and so on.
>>>>>>> This was causing deadlocks and crashes that we've workarounded for 8. But for 9 I've rewritten the AWT startup code to make JNI_OnLoad do a bit less work.
>>>>>>>
>>>>>>> The solution:
>>>>>>> Now loading awt native lib does not trigger loading AppKit and starting NSApplication. Instead we just load a library and tell Cocoa we are going to be multithreaded.
>>>>>>> We start Appkit when Toolkit is created, so now we avoid problems with deadlocks on runtime lock.
>>>>>>>
>>>>>>> An issue with the fix:
>>>>>>> I've made GraphicsEnvironment also load AppKit, because we use an NSView for a scratch surface in an OpenGL context. Really this is quite likely not needed as we are
>>>>>>> (should be) using FBOs for offscreen rendering. But getting rid of an NSView-based scratch surface is a separate big project, so I'll file a bug for it and now let's load
>>>>>>> Appkit when GraphicsEnvironment is initialized too.
>>>>>>>
>>>>>>> Testing:
>>>>>>> I have run all JCK, all regression tests, sanity-tested JFX interop and SWT interop, checked applets and webstart, tested headless mode. Everything seems to work fine,
>>>>>>> but anyway this fix is extremely risky. But this should be done if we want to avoid a problems like JDK-8033367 or JDK-8031050.
>>>>>>>
>>>>>>> Thank you.
>>>>>>> With best regards. Petr.
>>>>>>>
>>
>> -- 
>> Best regards, Sergey.
>>


-- 
Best regards, Sergey.


From alexandr.scherbatiy at oracle.com  Wed Jul  2 12:36:05 2014
From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy)
Date: Wed, 02 Jul 2014 16:36:05 +0400
Subject: <AWT Dev> [9] Review request for 8044614: [macosx] Focus issue
 with 2 applets in firefox
In-Reply-To: <53B3E2B1.1030303@oracle.com>
References: <53B3E2B1.1030303@oracle.com>
Message-ID: <53B3FCB5.103@oracle.com>


  Let's assume one browser has 3 applets where the second applet has focus.
  I click on the second browser with an applet (the applet receives the 
focus) and then click on the first browser back.
  Should the second applet in the first browser receive the focus?

  Thanks,
  Alexandr.

On 7/2/2014 2:45 PM, dmitry markov wrote:
> Hello,
>
> Could you review the fix for jdk9, please?
>
>     bug: https://bugs.openjdk.java.net/browse/JDK-8044614
>     webrev: http://cr.openjdk.java.net/~dmarkov/8044614/jdk9/webrev.00/
>
> Problem description: on Mac OSX when switching between several applets 
> running in separate browser's windows, the applet in active window 
> does not receive focus.
> Fix: the method CEmbeddedFrame.handleWindowFocusEvent() should be 
> modified. It has to detect the switching between browser's windows and 
> update focusedWindow field accordingly.
>
> Thanks,
> Dmitry


From anton.nashatyrev at oracle.com  Wed Jul  2 13:05:52 2014
From: anton.nashatyrev at oracle.com (anton nashatyrev)
Date: Wed, 02 Jul 2014 17:05:52 +0400
Subject: <AWT Dev> [9] Review request for 8046495: KeyEvent can not be
 accepted in quick mouse clicking
In-Reply-To: <B4A1F8A6-25D8-4CA2-A138-95EC14A6A881@oracle.com>
References: <53B2EDEA.3010402@oracle.com>
	<B4A1F8A6-25D8-4CA2-A138-95EC14A6A881@oracle.com>
Message-ID: <53B403B0.4010202@oracle.com>

Hello Petr,

On 02.07.2014 11:44, Petr Pchelko wrote:
> Hello, Anton.
>
> I'm not sure I have a detailed understanding of what's happening.
>
> Before your fix the timestamp of the event represented the time when 
> the event was created,

It supposed to represent the time when the event is put by OS to its 
native message queue... But in fact due to timers 'quant effects' this 
time might differ by e.g. 15ms for almost simultaneous events (by just 
comparing their GetMessageTime()).  With adding our calculations with 
different timer types those events might even have opposite time order.

> and now it's the time when it's sent to java.

Do we really want to care about what time we would like to use: when the 
message is queued by OS or when the message is dequeued by OS?

> This might be important if some events cause other events to be issued 
> on the java side.
>
> So suppose the following:
> Toolkit thread: InputEvent#1 created      - timestamp 0
> Toolkit thread: InputEvent#2 created      - timestamp 1
> Toolkit thread: InputEvent#1 sent           - timestamp 2
> EDT:             InputEvent#1 dispatched - timestamp 3
> EDT:               FocusEvent  created        - timestamp 4
> Toolkit thread: InputEvent#2 sent           - timestamp 5
>
> Before you fix we had the following event order: InputEvent#1(ts=0), 
> InputEvent#2(ts=1), FocusEvent(ts=4).
> But after your fix we will have a different order: 
> InputEvent#1(ts=2), FocusEvent(ts=4), InputEvent#2(ts=5).
> So now we would have troubles, because the Input Event will go to the 
> new focused component instead of the old one.
> Do you think that my arguments are correct? I understand that the 
> likelihood of such a situation is very low, but for me it looks 
> possible? Am I missing something?

As mentioned above, the same effect we could easily get with the current 
implementation: the system timestamps may differ up to 15ms for almost 
simultaneous events. But I don't think this have some great impact on 
the scenario you've described.
>
> Another thing I do not understand is why we were used to use the 
> complicated formula instead of initializing the msg.time field with 
> the JVM current time and using it when sending the event?

I'm not sure what msg.time you are talking about... As I understood the 
MSG* structure we are creating in native handlers is used for referring 
to an original OS event later. It seems that the time field is never 
used later. Anyways the 'time' field has a concrete meaning in Windows 
docs: number of ms since boot.

It seems that the fix might look risky, but I would like to try making 
the code cleaner first instead of adding additional fuzzy logic to it 
(just for the case I have an initial conservative fix which just makes 
the timestamps sequence non-decreasing).

Do you think we may talk offline to be on the same shape?

Thanks for reviewing!
Anton.

> Wouldn't that resolve both your issue and the issue the original fix 
> was made for?
>
> I have a couple of comments about the code, but let's postpone that 
> until we decide on the approach.
>
> Thank you.
> With best regards. Petr.
>
> On 01 ???? 2014 ?., at 21:20, anton nashatyrev 
> <anton.nashatyrev at oracle.com <mailto:anton.nashatyrev at oracle.com>> wrote:
>
>> Hello,
>>     could you please review the following fix:
>>
>> fix: http://cr.openjdk.java.net/~anashaty/8046495/9/webrev.00/ 
>> <http://cr.openjdk.java.net/%7Eanashaty/8046495/9/webrev.00/>
>> bug: https://bugs.openjdk.java.net/browse/JDK-8046495
>>
>> *Problem:*
>> On Windows the later InputEvent may have earlier timestamp 
>> (getWhen()), which results in incorrect processing of enqueued input 
>> events and may also potentially be the reason of other artifacts
>>
>> *Evaluation*:
>> On Windows we have some algorithm for calculating input event 
>> timestamp: jdk/src/windows/native/sun/windows/awt_Component.cpp:2100
>> Shortly the timestamp is calculated by the following formula:
>>     when = JVM_CurrentTimeMillis() - (GetTickCount() - GetMessageTime())
>>
>> Where:
>>   JVM_CurrentTimeMillis() - the same as System.currentTimeMillis()
>>   GetTickCount() - Win32 function, current millis from boot time
>>   GetMessageTime() - Win32 function, millis from boot time of the 
>> latest native Message
>>
>> In theory the formula looks good: we are trying our best to calculate 
>> the actual time of the OS message by taking the current JVM time 
>> (JVM_CurrentTimeMillis) and adjusting it with the offset 
>> (GetTickCount - GetMessageTime) which should indicate how many 
>> milliseconds ago from the current moment (GetTickCount) the message 
>> has been actually issued (GetMessageTime).
>> In practice due to usage of different system timers by the 
>> JVM_CurrentTimeMillis and GetTickCount their values are not updated 
>> synchronously and we may get an earlier timestamp for the later event.
>>
>> *Fix*:
>> Just to use JVM_CurrentTimeMillis only as events timestamp. On Mac 
>> this is done in exactly the same way: 
>> CPlatformResponder.handleMouse/KeyEvent()
>>
>> The message time offset calculation has been introduced with the fix 
>> for JDK-4434193 <https://bugs.openjdk.java.net/browse/JDK-4434193> 
>> and it seems that the issue has addressed very similar problem (At 
>> times getWhen()in ActionEvent returns higher value than the 
>> CurrentSystemTime) which has not been completely resolved in fact.
>> I also didn't find any benefits in using the existing approach:
>> - all the usages of the TimerHelper are in fact reduced to the 
>> mentioned formula: when = JVM_CurrentTimeMillis() - (GetTickCount() - 
>> GetMessageTime())
>> - GetMessageTime() always increases (except of the int overflow 
>> moments), thus we couldn't get earlier OS messages after later ones
>> - TimerHelper::windowsToUTC(DWORD windowsTime) doesn't guarantee 
>> returning the same timestamp across different calls for the same 
>> message time
>>
>> Thanks!
>> Anton.
>

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

From alexey.ivanov at oracle.com  Wed Jul  2 13:28:01 2014
From: alexey.ivanov at oracle.com (Alexey Ivanov)
Date: Wed, 02 Jul 2014 17:28:01 +0400
Subject: <AWT Dev> <Swing Dev> [9] Review request for JDK-8046559: NPE when
 changing Windows theme
Message-ID: <53B408E1.70008@oracle.com>

Hi AWT, Swing teams,

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

Problem description:
When changing Windows themes from a theme with visual styles (Windows 
Aero or Windows Basic) to a classic one, NullPointerException could be 
thrown from Swing code during component tree validation, or 
InternalError could be thrown during component painting.

Root cause:
Windows theme data are accessed via XPStyle and ThemeReader. When the 
theme is switched to a classic one, theme handles become unavailable, 
and theme data cannot be accessed any more. The change in theme is 
posted to EDT; at the same time, the UI often needs to repaint before 
the theme change is completely handled in Swing. This leads to NPE and 
InternalError as the code tries to access the data that has become 
unavailable.

The fix:
Windows desktop properties are updated right on Windows Toolkit thread, 
and the value of "win.xpstyle.themeActive" is stored in 
ThemeReader.xpStyleEnabled field. PropertyChangeEvents for desktop 
properties are delivered either synchronously on EDT or asynchronously 
via DesktopPropertyChangeSupport, as it used to be.

Getters in XPStyle class check for null values and return dummy defaults 
if ThemeReader returned null. SkinPainters also check whether theming is 
still available before asking ThemeReader to paint.

Access to XPStyle.xp instance is blocked as soon as user switches 
themes. The object will be cleaned when the corresponding 
PropertyChangeEvent is handled by Swing.


This new version of the fix addresses issues found with the initial 
submission of JDK-8039383 fix:
   - JDK-8046239: Build failure in 9-client on all non-Windows platforms
   - JDK-8046391: Hang displaying JFileChooser with Windows L&F

See also 
http://mail.openjdk.java.net/pipermail/awt-dev/2014-June/007975.html
and http://cr.openjdk.java.net/~aivanov/8039383/jdk9/webrev.03/


Regression test:
No regression test is provided due to its complexity. Whether 
NullPointerException or InternalError are thrown depends on the order of 
event handling, sometimes exceptions do not occur when changing theme of 
visual styles enabled theme to a classic theme.

I included regression test for hang in JFileChooser, JDK-8046391.


Thank you,
Alexey.

From anton.tarasov at oracle.com  Wed Jul  2 14:13:59 2014
From: anton.tarasov at oracle.com (Anton V. Tarasov)
Date: Wed, 02 Jul 2014 18:13:59 +0400
Subject: <AWT Dev> [9] Review request for 8046495: KeyEvent can not be
 accepted in quick mouse clicking
In-Reply-To: <B4A1F8A6-25D8-4CA2-A138-95EC14A6A881@oracle.com>
References: <53B2EDEA.3010402@oracle.com>
	<B4A1F8A6-25D8-4CA2-A138-95EC14A6A881@oracle.com>
Message-ID: <53B413A7.4000809@oracle.com>

On 02.07.2014 11:44, Petr Pchelko wrote:
> Hello, Anton.
>
> I'm not sure I have a detailed understanding of what's happening.
>
> Before your fix the timestamp of the event represented the time when the event was created, and 
> now it's the time when it's sent to java.
> This might be important if some events cause other events to be issued on the java side.
>
> So suppose the following:
> Toolkit thread: InputEvent#1 created      - timestamp 0
> Toolkit thread: InputEvent#2 created      - timestamp 1
> Toolkit thread: InputEvent#1 sent           - timestamp 2
> EDT:             InputEvent#1 dispatched - timestamp 3
> EDT:               FocusEvent  created        - timestamp 4
> Toolkit thread: InputEvent#2 sent           - timestamp 5
>
> Before you fix we had the following event order: InputEvent#1(ts=0), 
> InputEvent#2(ts=1), FocusEvent(ts=4).
> But after your fix we will have a different order: InputEvent#1(ts=2), FocusEvent(ts=4), 
> InputEvent#2(ts=5).
> So now we would have troubles, because the Input Event will go to the new focused component 
> instead of the old one.
> Do you think that my arguments are correct? I understand that the likelihood of such a situation 
> is very low, but for me it looks possible? Am I missing something?

A timestamp for a FocusEvent is taken from the_most_recent_KeyEvent_time which is set on EDT when 
the event is dispatched. So the fix shouldn't affect it.

Also, in awt_Window.cpp, when a TimedWindowEvent is created it is passed a timestamp got with 
TimeHelper::getMessageTimeUTC(). It appears, that the fix makes key events times even more 
consistent with it. So, from the kbd focus perspective, it shouldn't make any harm.

Anton, could you just please run the following tests, at least:

test/java/awt/Focus/6981400/*
test/java/awt/KeyboardFocusManager/TypeAhead/*

Thanks,
Anton.

>
> Another thing I do not understand is why we were used to use the complicated formula instead of 
> initializing the msg.time field with the JVM current time and using it when sending the event?
> Wouldn't that resolve both your issue and the issue the original fix was made for?
>
> I have a couple of comments about the code, but let's postpone that until we decide on the approach.
>
> Thank you.
> With best regards. Petr.
>
> On 01 ???? 2014 ?., at 21:20, anton nashatyrev <anton.nashatyrev at oracle.com 
> <mailto:anton.nashatyrev at oracle.com>> wrote:
>
>> Hello,
>>     could you please review the following fix:
>>
>> fix: http://cr.openjdk.java.net/~anashaty/8046495/9/webrev.00/ 
>> <http://cr.openjdk.java.net/%7Eanashaty/8046495/9/webrev.00/>
>> bug: https://bugs.openjdk.java.net/browse/JDK-8046495
>>
>> *Problem:*
>> On Windows the later InputEvent may have earlier timestamp (getWhen()), which results in 
>> incorrect processing of enqueued input events and may also potentially be the reason of other 
>> artifacts
>>
>> *Evaluation*:
>> On Windows we have some algorithm for calculating input event timestamp: 
>> jdk/src/windows/native/sun/windows/awt_Component.cpp:2100
>> Shortly the timestamp is calculated by the following formula:
>>     when = JVM_CurrentTimeMillis() - (GetTickCount() - GetMessageTime())
>>
>> Where:
>>   JVM_CurrentTimeMillis() - the same as System.currentTimeMillis()
>>   GetTickCount() - Win32 function, current millis from boot time
>>   GetMessageTime() - Win32 function, millis from boot time of the latest native Message
>>
>> In theory the formula looks good: we are trying our best to calculate the actual time of the OS 
>> message by taking the current JVM time (JVM_CurrentTimeMillis) and adjusting it with the offset 
>> (GetTickCount - GetMessageTime) which should indicate how many milliseconds ago from the current 
>> moment (GetTickCount) the message has been actually issued (GetMessageTime).
>> In practice due to usage of different system timers by the JVM_CurrentTimeMillis and GetTickCount 
>> their values are not updated synchronously and we may get an earlier timestamp for the later event.
>>
>> *Fix*:
>> Just to use JVM_CurrentTimeMillis only as events timestamp. On Mac this is done in exactly the 
>> same way: CPlatformResponder.handleMouse/KeyEvent()
>>
>> The message time offset calculation has been introduced with the fix for JDK-4434193 
>> <https://bugs.openjdk.java.net/browse/JDK-4434193> and it seems that the issue has addressed very 
>> similar problem (At times getWhen()in ActionEvent returns higher value than the 
>> CurrentSystemTime) which has not been completely resolved in fact.
>> I also didn't find any benefits in using the existing approach:
>> - all the usages of the TimerHelper are in fact reduced to the mentioned formula: when = 
>> JVM_CurrentTimeMillis() - (GetTickCount() - GetMessageTime())
>> - GetMessageTime() always increases (except of the int overflow moments), thus we couldn't get 
>> earlier OS messages after later ones
>> - TimerHelper::windowsToUTC(DWORD windowsTime) doesn't guarantee returning the same timestamp 
>> across different calls for the same message time
>>
>> Thanks!
>> Anton.
>

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

From petr.pchelko at oracle.com  Wed Jul  2 14:25:19 2014
From: petr.pchelko at oracle.com (Petr Pchelko)
Date: Wed, 2 Jul 2014 18:25:19 +0400
Subject: <AWT Dev> [9] Review Request: 8048549 [macosx] Disable usage of
	system menu bar if AWT is embedded in FX
Message-ID: <F2D9BA2A-4E89-48D8-B546-F0C089BACE2F@oracle.com>

Hello, AWT Team.

Please review the fix for the issue:
https://bugs.openjdk.java.net/browse/JDK-8048549
The fix is available at:
http://cr.openjdk.java.net/~pchelko/9/8048549/webrev/

We need to disable the screenMenuBar if AWT is embedded into FX. Only the top-level UI toolkit should work with the global menu bar.
We are already doing the same thing in FX. I've also added some cleanup into the fix. No test provided because we do not have tests for 
embedded mode.

With best regards. Petr.

From Sergey.Bylokhov at oracle.com  Wed Jul  2 14:32:34 2014
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Wed, 02 Jul 2014 18:32:34 +0400
Subject: <AWT Dev> [9] Review Request: 8048549 [macosx] Disable usage of
 system menu bar if AWT is embedded in FX
In-Reply-To: <F2D9BA2A-4E89-48D8-B546-F0C089BACE2F@oracle.com>
References: <F2D9BA2A-4E89-48D8-B546-F0C089BACE2F@oracle.com>
Message-ID: <53B41802.9000307@oracle.com>

Hi, Petr.
The fix looks good. But please add a dot at the and of the description 
isEmbedded(), before @return tag.

On 02.07.2014 18:25, Petr Pchelko wrote:
> Hello, AWT Team.
>
> Please review the fix for the issue:
> https://bugs.openjdk.java.net/browse/JDK-8048549
> The fix is available at:
> http://cr.openjdk.java.net/~pchelko/9/8048549/webrev/
>
> We need to disable the screenMenuBar if AWT is embedded into FX. Only the top-level UI toolkit should work with the global menu bar.
> We are already doing the same thing in FX. I've also added some cleanup into the fix. No test provided because we do not have tests for
> embedded mode.
>
> With best regards. Petr.


-- 
Best regards, Sergey.


From anthony.petrov at oracle.com  Wed Jul  2 14:37:21 2014
From: anthony.petrov at oracle.com (Anthony Petrov)
Date: Wed, 02 Jul 2014 18:37:21 +0400
Subject: <AWT Dev> [9] Review Request: 8048549 [macosx] Disable usage of
 system menu bar if AWT is embedded in FX
In-Reply-To: <F2D9BA2A-4E89-48D8-B546-F0C089BACE2F@oracle.com>
References: <F2D9BA2A-4E89-48D8-B546-F0C089BACE2F@oracle.com>
Message-ID: <53B41921.5060206@oracle.com>

Hi Petr,

The fix looks fine to me.

Note that there's also AWT API to set a menubar, and it seems (I haven't 
investigated deeply) that the LWAWT implementation uses the system menu 
bar unconditionally in this case. I believe we can assume that AWT API 
isn't used widely and we can leave it as it is. But it's worth noting 
this in the bug comments.

--
best regards,
Anthony

On 7/2/2014 6:25 PM, Petr Pchelko wrote:
> Hello, AWT Team.
>
> Please review the fix for the issue:
> https://bugs.openjdk.java.net/browse/JDK-8048549
> The fix is available at:
> http://cr.openjdk.java.net/~pchelko/9/8048549/webrev/
>
> We need to disable the screenMenuBar if AWT is embedded into FX. Only the top-level UI toolkit should work with the global menu bar.
> We are already doing the same thing in FX. I've also added some cleanup into the fix. No test provided because we do not have tests for
> embedded mode.
>
> With best regards. Petr.
>

From petr.pchelko at oracle.com  Wed Jul  2 14:47:35 2014
From: petr.pchelko at oracle.com (Petr Pchelko)
Date: Wed, 2 Jul 2014 18:47:35 +0400
Subject: <AWT Dev> [9] Review Request: 8048549 [macosx] Disable usage of
	system menu bar if AWT is embedded in FX
In-Reply-To: <53B41921.5060206@oracle.com>
References: <F2D9BA2A-4E89-48D8-B546-F0C089BACE2F@oracle.com>
	<53B41921.5060206@oracle.com>
Message-ID: <352E8B9F-3D0D-4DA1-A1F2-F2AADC29BC9B@oracle.com>

Hello, Anthony.

> Note that there's also AWT API to set a menubar, and it seems (I haven't investigated deeply) that the LWAWT implementation uses the system menu bar unconditionally in this case. I believe we can assume that AWT API isn't used widely and we can leave it as it is. But it's worth noting this in the bug comments.
Yes, I've tested this and you are right. I agree that we shouldn't touch this, because it would affect existing AWT applications that could've used this API without the useScreenMenuBar system property. I'll add a not about this to the bug comments.

With best regards. Petr.

On 02 ???? 2014 ?., at 18:37, Anthony Petrov <anthony.petrov at oracle.com> wrote:

> Hi Petr,
> 
> The fix looks fine to me.
> 
> Note that there's also AWT API to set a menubar, and it seems (I haven't investigated deeply) that the LWAWT implementation uses the system menu bar unconditionally in this case. I believe we can assume that AWT API isn't used widely and we can leave it as it is. But it's worth noting this in the bug comments.
> 
> --
> best regards,
> Anthony
> 
> On 7/2/2014 6:25 PM, Petr Pchelko wrote:
>> Hello, AWT Team.
>> 
>> Please review the fix for the issue:
>> https://bugs.openjdk.java.net/browse/JDK-8048549
>> The fix is available at:
>> http://cr.openjdk.java.net/~pchelko/9/8048549/webrev/
>> 
>> We need to disable the screenMenuBar if AWT is embedded into FX. Only the top-level UI toolkit should work with the global menu bar.
>> We are already doing the same thing in FX. I've also added some cleanup into the fix. No test provided because we do not have tests for
>> embedded mode.
>> 
>> With best regards. Petr.
>> 


From anthony.petrov at oracle.com  Wed Jul  2 15:10:41 2014
From: anthony.petrov at oracle.com (Anthony Petrov)
Date: Wed, 02 Jul 2014 19:10:41 +0400
Subject: <AWT Dev> [9] Review Request: 8048549 [macosx] Disable usage of
 system menu bar if AWT is embedded in FX
In-Reply-To: <352E8B9F-3D0D-4DA1-A1F2-F2AADC29BC9B@oracle.com>
References: <F2D9BA2A-4E89-48D8-B546-F0C089BACE2F@oracle.com>
	<53B41921.5060206@oracle.com>
	<352E8B9F-3D0D-4DA1-A1F2-F2AADC29BC9B@oracle.com>
Message-ID: <53B420F1.4020800@oracle.com>

Sounds good. Thanks.

--
best regards,
Anthony

On 7/2/2014 6:47 PM, Petr Pchelko wrote:
> Hello, Anthony.
>
>> Note that there's also AWT API to set a menubar, and it seems (I haven't investigated deeply) that the LWAWT implementation uses the system menu bar unconditionally in this case. I believe we can assume that AWT API isn't used widely and we can leave it as it is. But it's worth noting this in the bug comments.
> Yes, I've tested this and you are right. I agree that we shouldn't touch this, because it would affect existing AWT applications that could've used this API without the useScreenMenuBar system property. I'll add a not about this to the bug comments.
>
> With best regards. Petr.
>
> On 02 ???? 2014 ?., at 18:37, Anthony Petrov <anthony.petrov at oracle.com> wrote:
>
>> Hi Petr,
>>
>> The fix looks fine to me.
>>
>> Note that there's also AWT API to set a menubar, and it seems (I haven't investigated deeply) that the LWAWT implementation uses the system menu bar unconditionally in this case. I believe we can assume that AWT API isn't used widely and we can leave it as it is. But it's worth noting this in the bug comments.
>>
>> --
>> best regards,
>> Anthony
>>
>> On 7/2/2014 6:25 PM, Petr Pchelko wrote:
>>> Hello, AWT Team.
>>>
>>> Please review the fix for the issue:
>>> https://bugs.openjdk.java.net/browse/JDK-8048549
>>> The fix is available at:
>>> http://cr.openjdk.java.net/~pchelko/9/8048549/webrev/
>>>
>>> We need to disable the screenMenuBar if AWT is embedded into FX. Only the top-level UI toolkit should work with the global menu bar.
>>> We are already doing the same thing in FX. I've also added some cleanup into the fix. No test provided because we do not have tests for
>>> embedded mode.
>>>
>>> With best regards. Petr.
>>>
>

From anton.nashatyrev at oracle.com  Wed Jul  2 15:28:58 2014
From: anton.nashatyrev at oracle.com (anton nashatyrev)
Date: Wed, 02 Jul 2014 19:28:58 +0400
Subject: <AWT Dev> [9] Review request for 8046495: KeyEvent can not be
 accepted in quick mouse clicking
In-Reply-To: <53B413A7.4000809@oracle.com>
References: <53B2EDEA.3010402@oracle.com>
	<B4A1F8A6-25D8-4CA2-A138-95EC14A6A881@oracle.com>
	<53B413A7.4000809@oracle.com>
Message-ID: <53B4253A.3040406@oracle.com>

Hello, Anton

On 02.07.2014 18:13, Anton V. Tarasov wrote:
> On 02.07.2014 11:44, Petr Pchelko wrote:
>> Hello, Anton.
>>
>> I'm not sure I have a detailed understanding of what's happening.
>>
>> Before your fix the timestamp of the event represented the time when 
>> the event was created, and now it's the time when it's sent to java.
>> This might be important if some events cause other events to be 
>> issued on the java side.
>>
>> So suppose the following:
>> Toolkit thread: InputEvent#1 created      - timestamp 0
>> Toolkit thread: InputEvent#2 created      - timestamp 1
>> Toolkit thread: InputEvent#1 sent           - timestamp 2
>> EDT:             InputEvent#1 dispatched - timestamp 3
>> EDT:               FocusEvent  created        - timestamp 4
>> Toolkit thread: InputEvent#2 sent           - timestamp 5
>>
>> Before you fix we had the following event order: InputEvent#1(ts=0), 
>> InputEvent#2(ts=1), FocusEvent(ts=4).
>> But after your fix we will have a different order: 
>> InputEvent#1(ts=2), FocusEvent(ts=4), InputEvent#2(ts=5).
>> So now we would have troubles, because the Input Event will go to the 
>> new focused component instead of the old one.
>> Do you think that my arguments are correct? I understand that the 
>> likelihood of such a situation is very low, but for me it looks 
>> possible? Am I missing something?
>
> A timestamp for a FocusEvent is taken from 
> the_most_recent_KeyEvent_time which is set on EDT when the event is 
> dispatched. So the fix shouldn't affect it.
>
> Also, in awt_Window.cpp, when a TimedWindowEvent is created it is 
> passed a timestamp got with TimeHelper::getMessageTimeUTC(). It 
> appears, that the fix makes key events times even more consistent with 
> it. So, from the kbd focus perspective, it shouldn't make any harm.
>
> Anton, could you just please run the following tests, at least:
>
> test/java/awt/Focus/6981400/*
> test/java/awt/KeyboardFocusManager/TypeAhead/*

I've tested with the following set:
[closed]/java/awt/event/*
[closed]/java/awt/Focus/*
[closed]java/awt/KeyboardFocusManager/*

: no unexpected failures here.

I've also verified that my regression test which comes with the fix 
works fine on Linux and Mac (despite the fix is Win specific).

Thanks for review!
Anton.

>
> Thanks,
> Anton.
>
>>
>> Another thing I do not understand is why we were used to use the 
>> complicated formula instead of initializing the msg.time field with 
>> the JVM current time and using it when sending the event?
>> Wouldn't that resolve both your issue and the issue the original fix 
>> was made for?
>>
>> I have a couple of comments about the code, but let's postpone that 
>> until we decide on the approach.
>>
>> Thank you.
>> With best regards. Petr.
>>
>> On 01 ???? 2014 ?., at 21:20, anton nashatyrev 
>> <anton.nashatyrev at oracle.com <mailto:anton.nashatyrev at oracle.com>> wrote:
>>
>>> Hello,
>>>     could you please review the following fix:
>>>
>>> fix: http://cr.openjdk.java.net/~anashaty/8046495/9/webrev.00/ 
>>> <http://cr.openjdk.java.net/%7Eanashaty/8046495/9/webrev.00/>
>>> bug: https://bugs.openjdk.java.net/browse/JDK-8046495
>>>
>>> *Problem:*
>>> On Windows the later InputEvent may have earlier timestamp 
>>> (getWhen()), which results in incorrect processing of enqueued input 
>>> events and may also potentially be the reason of other artifacts
>>>
>>> *Evaluation*:
>>> On Windows we have some algorithm for calculating input event 
>>> timestamp: jdk/src/windows/native/sun/windows/awt_Component.cpp:2100
>>> Shortly the timestamp is calculated by the following formula:
>>>     when = JVM_CurrentTimeMillis() - (GetTickCount() - GetMessageTime())
>>>
>>> Where:
>>>   JVM_CurrentTimeMillis() - the same as System.currentTimeMillis()
>>>   GetTickCount() - Win32 function, current millis from boot time
>>>   GetMessageTime() - Win32 function, millis from boot time of the 
>>> latest native Message
>>>
>>> In theory the formula looks good: we are trying our best to 
>>> calculate the actual time of the OS message by taking the current 
>>> JVM time (JVM_CurrentTimeMillis) and adjusting it with the offset 
>>> (GetTickCount - GetMessageTime) which should indicate how many 
>>> milliseconds ago from the current moment (GetTickCount) the message 
>>> has been actually issued (GetMessageTime).
>>> In practice due to usage of different system timers by the 
>>> JVM_CurrentTimeMillis and GetTickCount their values are not updated 
>>> synchronously and we may get an earlier timestamp for the later event.
>>>
>>> *Fix*:
>>> Just to use JVM_CurrentTimeMillis only as events timestamp. On Mac 
>>> this is done in exactly the same way: 
>>> CPlatformResponder.handleMouse/KeyEvent()
>>>
>>> The message time offset calculation has been introduced with the fix 
>>> for JDK-4434193 <https://bugs.openjdk.java.net/browse/JDK-4434193> 
>>> and it seems that the issue has addressed very similar problem (At 
>>> times getWhen()in ActionEvent returns higher value than the 
>>> CurrentSystemTime) which has not been completely resolved in fact.
>>> I also didn't find any benefits in using the existing approach:
>>> - all the usages of the TimerHelper are in fact reduced to the 
>>> mentioned formula: when = JVM_CurrentTimeMillis() - (GetTickCount() 
>>> - GetMessageTime())
>>> - GetMessageTime() always increases (except of the int overflow 
>>> moments), thus we couldn't get earlier OS messages after later ones
>>> - TimerHelper::windowsToUTC(DWORD windowsTime) doesn't guarantee 
>>> returning the same timestamp across different calls for the same 
>>> message time
>>>
>>> Thanks!
>>> Anton.
>>
>

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

From anton.tarasov at oracle.com  Wed Jul  2 15:34:33 2014
From: anton.tarasov at oracle.com (Anton V. Tarasov)
Date: Wed, 02 Jul 2014 19:34:33 +0400
Subject: <AWT Dev> [9] Review request for 8046495: KeyEvent can not be
 accepted in quick mouse clicking
In-Reply-To: <53B4253A.3040406@oracle.com>
References: <53B2EDEA.3010402@oracle.com>
	<B4A1F8A6-25D8-4CA2-A138-95EC14A6A881@oracle.com>
	<53B413A7.4000809@oracle.com> <53B4253A.3040406@oracle.com>
Message-ID: <53B42689.4090709@oracle.com>

On 02.07.2014 19:28, anton nashatyrev wrote:
> Hello, Anton
>
> On 02.07.2014 18:13, Anton V. Tarasov wrote:
>> On 02.07.2014 11:44, Petr Pchelko wrote:
>>> Hello, Anton.
>>>
>>> I'm not sure I have a detailed understanding of what's happening.
>>>
>>> Before your fix the timestamp of the event represented the time when the event was created, and 
>>> now it's the time when it's sent to java.
>>> This might be important if some events cause other events to be issued on the java side.
>>>
>>> So suppose the following:
>>> Toolkit thread: InputEvent#1 created      - timestamp 0
>>> Toolkit thread: InputEvent#2 created      - timestamp 1
>>> Toolkit thread: InputEvent#1 sent           - timestamp 2
>>> EDT:               InputEvent#1 dispatched - timestamp 3
>>> EDT:               FocusEvent  created        - timestamp 4
>>> Toolkit thread: InputEvent#2 sent           - timestamp 5
>>>
>>> Before you fix we had the following event order: InputEvent#1(ts=0), 
>>> InputEvent#2(ts=1), FocusEvent(ts=4).
>>> But after your fix we will have a different order: InputEvent#1(ts=2), FocusEvent(ts=4), 
>>> InputEvent#2(ts=5).
>>> So now we would have troubles, because the Input Event will go to the new focused component 
>>> instead of the old one.
>>> Do you think that my arguments are correct? I understand that the likelihood of such a situation 
>>> is very low, but for me it looks possible? Am I missing something?
>>
>> A timestamp for a FocusEvent is taken from the_most_recent_KeyEvent_time which is set on EDT when 
>> the event is dispatched. So the fix shouldn't affect it.
>>
>> Also, in awt_Window.cpp, when a TimedWindowEvent is created it is passed a timestamp got with 
>> TimeHelper::getMessageTimeUTC(). It appears, that the fix makes key events times even more 
>> consistent with it. So, from the kbd focus perspective, it shouldn't make any harm.
>>
>> Anton, could you just please run the following tests, at least:
>>
>> test/java/awt/Focus/6981400/*
>> test/java/awt/KeyboardFocusManager/TypeAhead/*
>
> I've tested with the following set:
> [closed]/java/awt/event/*
> [closed]/java/awt/Focus/*
> [closed]java/awt/KeyboardFocusManager/*
>
> : no unexpected failures here.
>
> I've also verified that my regression test which comes with the fix works fine on Linux and Mac 
> (despite the fix is Win specific).

Great, thanks!

Anton.

>
> Thanks for review!
> Anton.
>
>>
>> Thanks,
>> Anton.
>>
>>>
>>> Another thing I do not understand is why we were used to use the complicated formula instead of 
>>> initializing the msg.time field with the JVM current time and using it when sending the event?
>>> Wouldn't that resolve both your issue and the issue the original fix was made for?
>>>
>>> I have a couple of comments about the code, but let's postpone that until we decide on the approach.
>>>
>>> Thank you.
>>> With best regards. Petr.
>>>
>>> On 01 ???? 2014 ?., at 21:20, anton nashatyrev <anton.nashatyrev at oracle.com 
>>> <mailto:anton.nashatyrev at oracle.com>> wrote:
>>>
>>>> Hello,
>>>>     could you please review the following fix:
>>>>
>>>> fix: http://cr.openjdk.java.net/~anashaty/8046495/9/webrev.00/ 
>>>> <http://cr.openjdk.java.net/%7Eanashaty/8046495/9/webrev.00/>
>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8046495
>>>>
>>>> *Problem:*
>>>> On Windows the later InputEvent may have earlier timestamp (getWhen()), which results in 
>>>> incorrect processing of enqueued input events and may also potentially be the reason of other 
>>>> artifacts
>>>>
>>>> *Evaluation*:
>>>> On Windows we have some algorithm for calculating input event timestamp: 
>>>> jdk/src/windows/native/sun/windows/awt_Component.cpp:2100
>>>> Shortly the timestamp is calculated by the following formula:
>>>>     when = JVM_CurrentTimeMillis() - (GetTickCount() - GetMessageTime())
>>>>
>>>> Where:
>>>>   JVM_CurrentTimeMillis() - the same as System.currentTimeMillis()
>>>>   GetTickCount() - Win32 function, current millis from boot time
>>>>   GetMessageTime() - Win32 function, millis from boot time of the latest native Message
>>>>
>>>> In theory the formula looks good: we are trying our best to calculate the actual time of the OS 
>>>> message by taking the current JVM time (JVM_CurrentTimeMillis) and adjusting it with the offset 
>>>> (GetTickCount - GetMessageTime) which should indicate how many milliseconds ago from the 
>>>> current moment (GetTickCount) the message has been actually issued (GetMessageTime).
>>>> In practice due to usage of different system timers by the JVM_CurrentTimeMillis and 
>>>> GetTickCount their values are not updated synchronously and we may get an earlier timestamp for 
>>>> the later event.
>>>>
>>>> *Fix*:
>>>> Just to use JVM_CurrentTimeMillis only as events timestamp. On Mac this is done in exactly the 
>>>> same way: CPlatformResponder.handleMouse/KeyEvent()
>>>>
>>>> The message time offset calculation has been introduced with the fix for JDK-4434193 
>>>> <https://bugs.openjdk.java.net/browse/JDK-4434193> and it seems that the issue has addressed 
>>>> very similar problem (At times getWhen()in ActionEvent returns higher value than the 
>>>> CurrentSystemTime) which has not been completely resolved in fact.
>>>> I also didn't find any benefits in using the existing approach:
>>>> - all the usages of the TimerHelper are in fact reduced to the mentioned formula: when = 
>>>> JVM_CurrentTimeMillis() - (GetTickCount() - GetMessageTime())
>>>> - GetMessageTime() always increases (except of the int overflow moments), thus we couldn't get 
>>>> earlier OS messages after later ones
>>>> - TimerHelper::windowsToUTC(DWORD windowsTime) doesn't guarantee returning the same timestamp 
>>>> across different calls for the same message time
>>>>
>>>> Thanks!
>>>> Anton.
>>>
>>
>

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

From petr.pchelko at oracle.com  Wed Jul  2 15:37:21 2014
From: petr.pchelko at oracle.com (Petr Pchelko)
Date: Wed, 2 Jul 2014 19:37:21 +0400
Subject: <AWT Dev> [9] Review request for 8046495: KeyEvent can not be
	accepted in quick mouse clicking
In-Reply-To: <53B42689.4090709@oracle.com>
References: <53B2EDEA.3010402@oracle.com>
	<B4A1F8A6-25D8-4CA2-A138-95EC14A6A881@oracle.com>
	<53B413A7.4000809@oracle.com> <53B4253A.3040406@oracle.com>
	<53B42689.4090709@oracle.com>
Message-ID: <59E88D9A-2BF9-41CF-9128-5E5A83B39EF3@oracle.com>

Hello, Anton.

Thanks for clarifications and additional testing.
The fix looks good to me too.

With best regards. Petr.

On 02 ???? 2014 ?., at 19:34, Anton V. Tarasov <anton.tarasov at oracle.com> wrote:

> On 02.07.2014 19:28, anton nashatyrev wrote:
>> Hello, Anton
>> 
>> On 02.07.2014 18:13, Anton V. Tarasov wrote:
>>> On 02.07.2014 11:44, Petr Pchelko wrote:
>>>> Hello, Anton.
>>>> 
>>>> I'm not sure I have a detailed understanding of what's happening. 
>>>> 
>>>> Before your fix the timestamp of the event represented the time when the event was created, and now it's the time when it's sent to java.
>>>> This might be important if some events cause other events to be issued on the java side. 
>>>> 
>>>> So suppose the following:
>>>> Toolkit thread: InputEvent#1 created      - timestamp 0
>>>> Toolkit thread: InputEvent#2 created      - timestamp 1
>>>> Toolkit thread: InputEvent#1 sent           - timestamp 2
>>>> EDT:
>>>>                            InputEvent#1 dispatched - timestamp 3
>>>> EDT:               FocusEvent  created        - timestamp 4
>>>> Toolkit thread: InputEvent#2 sent           - timestamp 5
>>>> 
>>>> Before you fix we had the following event order: InputEvent#1(ts=0), InputEvent#2(ts=1), FocusEvent(ts=4).
>>>> But after your fix we will have a different order: InputEvent#1(ts=2), FocusEvent(ts=4), InputEvent#2(ts=5).
>>>> So now we would have troubles, because the Input Event will go to the new focused component instead of the old one. 
>>>> Do you think that my arguments are correct? I understand that the likelihood of such a situation is very low, but for me it looks possible? Am I missing something?
>>> 
>>> A timestamp for a FocusEvent is taken from the_most_recent_KeyEvent_time which is set on EDT when the event is dispatched. So the fix shouldn't affect it.
>>> 
>>> Also, in awt_Window.cpp, when a TimedWindowEvent is created it is passed a timestamp got with TimeHelper::getMessageTimeUTC(). It appears, that the fix makes key events times even more consistent with it. So, from the kbd focus perspective, it shouldn't make any harm.
>>> 
>>> Anton, could you just please run the following tests, at least:
>>> 
>>> test/java/awt/Focus/6981400/*
>>> test/java/awt/KeyboardFocusManager/TypeAhead/*
>> 
>> I've tested with the following set: 
>> [closed]/java/awt/event/* 
>> [closed]/java/awt/Focus/* 
>> [closed]java/awt/KeyboardFocusManager/*
>> 
>> : no unexpected failures here.
>> 
>> I've also verified that my regression test which comes with the fix works fine on Linux and Mac (despite the fix is Win specific). 
> 
> Great, thanks!
> 
> Anton.
> 
>> 
>> Thanks for review!
>> Anton.
>> 
>>> 
>>> Thanks,
>>> Anton.
>>> 
>>>> 
>>>> Another thing I do not understand is why we were used to use the complicated formula instead of initializing the msg.time field with the JVM current time and using it when sending the event?
>>>> Wouldn't that resolve both your issue and the issue the original fix was made for?
>>>> 
>>>> I have a couple of comments about the code, but let's postpone that until we decide on the approach.
>>>> 
>>>> Thank you.
>>>> With best regards. Petr.
>>>> 
>>>> On 01 ???? 2014 ?., at 21:20, anton nashatyrev <anton.nashatyrev at oracle.com> wrote:
>>>> 
>>>>> Hello, 
>>>>>     could you please review the following fix:
>>>>> 
>>>>> fix: http://cr.openjdk.java.net/~anashaty/8046495/9/webrev.00/
>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8046495
>>>>> 
>>>>>     Problem: 
>>>>> On Windows the later InputEvent may have earlier timestamp (getWhen()), which results in incorrect processing of enqueued input events and may also potentially be the reason of other artifacts 
>>>>> 
>>>>>     Evaluation: 
>>>>> On Windows we have some algorithm for calculating input event timestamp: jdk/src/windows/native/sun/windows/awt_Component.cpp:2100
>>>>> Shortly the timestamp is calculated by the following formula: 
>>>>>     when = JVM_CurrentTimeMillis() - (GetTickCount() - GetMessageTime())
>>>>> 
>>>>> Where: 
>>>>>   JVM_CurrentTimeMillis() - the same as System.currentTimeMillis()
>>>>>   GetTickCount() - Win32 function, current millis from boot time
>>>>>   GetMessageTime() - Win32 function, millis from boot time of the latest native Message
>>>>> 
>>>>> In theory the formula looks good: we are trying our best to calculate the actual time of the OS message by taking the current JVM time (JVM_CurrentTimeMillis) and adjusting it with the offset (GetTickCount - GetMessageTime) which should indicate how many milliseconds ago from the current moment (GetTickCount) the message has been actually issued (GetMessageTime).
>>>>> In practice due to usage of different system timers by the JVM_CurrentTimeMillis and GetTickCount their values are not updated synchronously and we may get an earlier timestamp for the later event. 
>>>>> 
>>>>>     Fix: 
>>>>> Just to use JVM_CurrentTimeMillis only as events timestamp. On Mac this is done in exactly the same way: CPlatformResponder.handleMouse/KeyEvent()
>>>>> 
>>>>> The message time offset calculation has been introduced with the fix for JDK-4434193 and it seems that the issue has addressed very similar problem (At times getWhen()in ActionEvent returns higher value than the CurrentSystemTime) which has not been completely resolved in fact.
>>>>> I also didn't find any benefits in using the existing approach: 
>>>>> - all the usages of the TimerHelper are in fact reduced to the mentioned formula: when = JVM_CurrentTimeMillis() - (GetTickCount() - GetMessageTime())
>>>>> - GetMessageTime() always increases (except of the int overflow moments), thus we couldn't get earlier OS messages after later ones
>>>>> - TimerHelper::windowsToUTC(DWORD windowsTime) doesn't guarantee returning the same timestamp across different calls for the same message time 
>>>>> 
>>>>> Thanks! 
>>>>> Anton. 
>>>> 
>>> 
>> 
> 

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

From anton.nashatyrev at oracle.com  Wed Jul  2 18:36:28 2014
From: anton.nashatyrev at oracle.com (anton nashatyrev)
Date: Wed, 02 Jul 2014 22:36:28 +0400
Subject: <AWT Dev> [7] Review request for 6993873:
 java/awt/Focus/FocusOwnerFrameOnClick/FocusOwnerFrameOnClick.java test
 indicates ".a frame wasn't focused on click" jdk7 issue on linux
Message-ID: <53B4512C.1@oracle.com>

Hello,
     could you please review the following fix:

fix: http://cr.openjdk.java.net/~anashaty/6993873/7/webrev.00/ 
<http://cr.openjdk.java.net/%7Eanashaty/6993873/7/webrev.00/>
bug: 
https://bugs.openjdk.java.net/browse/JDK-6993873<https://bugs.openjdk.java.net/browse/JDK-8025145>

     This is actually a partial port of the JDK-6886678 
<https://bugs.openjdk.java.net/browse/JDK-6886678> fix from jdk6 to jdk7 
(the port had been made but not completely)
     Since jdk8 the problem is not reproducible since was fixed with the 
bug JDK-6981400 <https://bugs.openjdk.java.net/browse/JDK-6981400>, but 
again without backport to the jdk7.

Thanks!
Anton.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20140702/7430e1b8/attachment.html>

From dmitry.markov at oracle.com  Thu Jul  3 09:15:56 2014
From: dmitry.markov at oracle.com (dmitry markov)
Date: Thu, 03 Jul 2014 13:15:56 +0400
Subject: <AWT Dev> [9] Review request for 8044614: [macosx] Focus issue
 with 2 applets in firefox
In-Reply-To: <53B3FCB5.103@oracle.com>
References: <53B3E2B1.1030303@oracle.com> <53B3FCB5.103@oracle.com>
Message-ID: <53B51F4C.6060106@oracle.com>

Hi Alexandr,

Thank you for review.
For the use case you described - when we move back to the first browser 
window with 3 applets, the first applet (not the second one) will 
receive the focus. This behavior is incorrect, since the second applet 
should receive the focus.
I have updated the fix, please find new version here: 
http://cr.openjdk.java.net/~dmarkov/8044614/jdk9/webrev.01/
Now we store the information about focused applet when browser window is 
deactivated and restore the focus to the previously focused applet when 
browser window becomes active again

Thanks,
Dmitry

On 02/07/2014 16:36, Alexander Scherbatiy wrote:
>
>  Let's assume one browser has 3 applets where the second applet has 
> focus.
>  I click on the second browser with an applet (the applet receives the 
> focus) and then click on the first browser back.
>  Should the second applet in the first browser receive the focus?
>
>  Thanks,
>  Alexandr.
>
> On 7/2/2014 2:45 PM, dmitry markov wrote:
>> Hello,
>>
>> Could you review the fix for jdk9, please?
>>
>>     bug: https://bugs.openjdk.java.net/browse/JDK-8044614
>>     webrev: http://cr.openjdk.java.net/~dmarkov/8044614/jdk9/webrev.00/
>>
>> Problem description: on Mac OSX when switching between several 
>> applets running in separate browser's windows, the applet in active 
>> window does not receive focus.
>> Fix: the method CEmbeddedFrame.handleWindowFocusEvent() should be 
>> modified. It has to detect the switching between browser's windows 
>> and update focusedWindow field accordingly.
>>
>> Thanks,
>> Dmitry
>


From anton.tarasov at oracle.com  Thu Jul  3 09:23:04 2014
From: anton.tarasov at oracle.com (Anton V. Tarasov)
Date: Thu, 03 Jul 2014 13:23:04 +0400
Subject: <AWT Dev> [7] Review request for 6993873:
 java/awt/Focus/FocusOwnerFrameOnClick/FocusOwnerFrameOnClick.java test
 indicates ".a frame wasn't focused on click" jdk7 issue on linux
In-Reply-To: <53B4512C.1@oracle.com>
References: <53B4512C.1@oracle.com>
Message-ID: <53B520F8.3030906@oracle.com>

Looks fine to me.

Regards,
Anton.

On 02.07.2014 22:36, anton nashatyrev wrote:
> Hello,
>     could you please review the following fix:
>
> fix: http://cr.openjdk.java.net/~anashaty/6993873/7/webrev.00/ 
> <http://cr.openjdk.java.net/%7Eanashaty/6993873/7/webrev.00/>
> bug: https://bugs.openjdk.java.net/browse/JDK-6993873
>
>     This is actually a partial port of the JDK-6886678 
> <https://bugs.openjdk.java.net/browse/JDK-6886678> fix from jdk6 to jdk7 (the port had been made 
> but not completely)
>     Since jdk8 the problem is not reproducible since was fixed with the bug JDK-6981400 
> <https://bugs.openjdk.java.net/browse/JDK-6981400>, but again without backport to the jdk7.
>
> Thanks!
> Anton.

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

From dmitriy.ermashov at oracle.com  Thu Jul  3 09:51:00 2014
From: dmitriy.ermashov at oracle.com (Dmitriy Ermashov)
Date: Thu, 03 Jul 2014 13:51:00 +0400
Subject: <AWT Dev> Review Request for 8048246: Move
 AWT_DnD/Clipboard/Automated functional tests to OpenJDK
In-Reply-To: <53B29F31.6010808@oracle.com>
References: <53B29F31.6010808@oracle.com>
Message-ID: <53B52784.9010303@oracle.com>

Hi all,

Please review the updated version of tests to be colocated.
http://cr.openjdk.java.net/~dermashov/8048246/webrev.01/
http://cr.openjdk.java.net/~dermashov/8048246/webrev.diff.01/

Last changes:
1. Removed 1 test from closed part. New GetContentsInterruptedTest.java 
is an up-to-date copy of it.

Thanks,
Dima

On 07/01/2014 03:44 PM, Dmitriy Ermashov wrote:
> Hi,
>
> Please review a new batch of functional AWT tests. Clipboard tests 
> this time.
> http://cr.openjdk.java.net/~dermashov/8048246/webrev.00/
>
> Corresponding bug:
> https://bugs.openjdk.java.net/browse/JDK-8048246
>
> The changeset is pretty large, but, as always, it is several times 
> smaller than original test suite.
> Tests were verified on the following platforms:
> Windows 7 x64
> Ubuntu 14.04 x64
> OS X 10.9.4 x64
> Solaris 11 x64
> Ubuntu 10.04 arm
>


From petr.pchelko at oracle.com  Thu Jul  3 10:09:01 2014
From: petr.pchelko at oracle.com (Petr Pchelko)
Date: Thu, 3 Jul 2014 14:09:01 +0400
Subject: <AWT Dev> [7] Review request for 6993873:
	java/awt/Focus/FocusOwnerFrameOnClick/FocusOwnerFrameOnClick.java
	test indicates ".a frame wasn't focused on click" jdk7 issue
	on linux
In-Reply-To: <53B520F8.3030906@oracle.com>
References: <53B4512C.1@oracle.com> <53B520F8.3030906@oracle.com>
Message-ID: <B31493CF-88A2-4DC6-BD56-34D303CE439A@oracle.com>

Hello, Anton.

Please add an @Override annotation to the method.
All the rest looks fine, the new webrev is not needed.

With best regards. Petr.

> On Jul 3, 2014, at 1:23 PM, Anton V. Tarasov <anton.tarasov at oracle.com> wrote:
> 
> Looks fine to me.
> 
> Regards,
> Anton.
> 
> On 02.07.2014 22:36, anton nashatyrev wrote:
>> Hello, 
>>     could you please review the following fix:
>> 
>> fix: http://cr.openjdk.java.net/~anashaty/6993873/7/webrev.00/
>> bug: https://bugs.openjdk.java.net/browse/JDK-6993873
>> 
>>     This is actually a partial port of the JDK-6886678 fix from jdk6 to jdk7 (the port had been made but not completely) 
>>     Since jdk8 the problem is not reproducible since was fixed with the bug JDK-6981400, but again without backport to the jdk7.
>> 
>> Thanks! 
>> Anton. 
> 

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

From alexandr.scherbatiy at oracle.com  Thu Jul  3 10:25:37 2014
From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy)
Date: Thu, 03 Jul 2014 14:25:37 +0400
Subject: <AWT Dev> [9] Review request for 8044614: [macosx] Focus issue
 with 2 applets in firefox
In-Reply-To: <53B51F4C.6060106@oracle.com>
References: <53B3E2B1.1030303@oracle.com> <53B3FCB5.103@oracle.com>
	<53B51F4C.6060106@oracle.com>
Message-ID: <53B52FA1.7040001@oracle.com>

On 7/3/2014 1:15 PM, dmitry markov wrote:
> Hi Alexandr,
>
> Thank you for review.
> For the use case you described - when we move back to the first 
> browser window with 3 applets, the first applet (not the second one) 
> will receive the focus. This behavior is incorrect, since the second 
> applet should receive the focus.
> I have updated the fix, please find new version here: 
> http://cr.openjdk.java.net/~dmarkov/8044614/jdk9/webrev.01/
> Now we store the information about focused applet when browser window 
> is deactivated and restore the focus to the previously focused applet 
> when browser window becomes active again

     The case can be more complicated with some browsers where each of 
them has several applets.
     It seems there should be a map between a browser and it's focused 
applet.

     Is it possible to add a manual test for the fix?

    Thanks,
    Alexandr.

>
> Thanks,
> Dmitry
>
> On 02/07/2014 16:36, Alexander Scherbatiy wrote:
>>
>>  Let's assume one browser has 3 applets where the second applet has 
>> focus.
>>  I click on the second browser with an applet (the applet receives 
>> the focus) and then click on the first browser back.
>>  Should the second applet in the first browser receive the focus?
>>
>>  Thanks,
>>  Alexandr.
>>
>> On 7/2/2014 2:45 PM, dmitry markov wrote:
>>> Hello,
>>>
>>> Could you review the fix for jdk9, please?
>>>
>>>     bug: https://bugs.openjdk.java.net/browse/JDK-8044614
>>>     webrev: http://cr.openjdk.java.net/~dmarkov/8044614/jdk9/webrev.00/
>>>
>>> Problem description: on Mac OSX when switching between several 
>>> applets running in separate browser's windows, the applet in active 
>>> window does not receive focus.
>>> Fix: the method CEmbeddedFrame.handleWindowFocusEvent() should be 
>>> modified. It has to detect the switching between browser's windows 
>>> and update focusedWindow field accordingly.
>>>
>>> Thanks,
>>> Dmitry
>>
>


From petr.pchelko at oracle.com  Thu Jul  3 10:30:17 2014
From: petr.pchelko at oracle.com (Petr Pchelko)
Date: Thu, 3 Jul 2014 14:30:17 +0400
Subject: <AWT Dev> Review Request for 8048246: Move
	AWT_DnD/Clipboard/Automated functional tests to OpenJDK
In-Reply-To: <53B52784.9010303@oracle.com>
References: <53B29F31.6010808@oracle.com> <53B52784.9010303@oracle.com>
Message-ID: <7EE72A65-4F4D-4F37-B9AE-86854A79937C@oracle.com>

Hello, Dmitriy.

As we do not have a Clipboard folder yet, could you please put Clipboard tests under java/awt/datatransfer/Clipboard so that all data transfer tests are in the same folder.
AddFlavorTest:80 - here the test is using the private method via reflection. Please remove this part of the test (or the whole test if it looses it?s meaning without it). I will make big changes in the implementation soon, so this test will start to fail. 

I didn?t analyze every assertion, but as long as the tests pass on all platforms I?m OK with the rest of the fix.

With best regards. Petr.


> On Jul 3, 2014, at 1:51 PM, Dmitriy Ermashov <dmitriy.ermashov at oracle.com> wrote:
> 
> Hi all,
> 
> Please review the updated version of tests to be colocated.
> http://cr.openjdk.java.net/~dermashov/8048246/webrev.01/
> http://cr.openjdk.java.net/~dermashov/8048246/webrev.diff.01/
> 
> Last changes:
> 1. Removed 1 test from closed part. New GetContentsInterruptedTest.java is an up-to-date copy of it.
> 
> Thanks,
> Dima
> 
> On 07/01/2014 03:44 PM, Dmitriy Ermashov wrote:
>> Hi,
>> 
>> Please review a new batch of functional AWT tests. Clipboard tests this time.
>> http://cr.openjdk.java.net/~dermashov/8048246/webrev.00/
>> 
>> Corresponding bug:
>> https://bugs.openjdk.java.net/browse/JDK-8048246
>> 
>> The changeset is pretty large, but, as always, it is several times smaller than original test suite.
>> Tests were verified on the following platforms:
>> Windows 7 x64
>> Ubuntu 14.04 x64
>> OS X 10.9.4 x64
>> Solaris 11 x64
>> Ubuntu 10.04 arm
>> 
> 


From dmitriy.ermashov at oracle.com  Thu Jul  3 14:49:09 2014
From: dmitriy.ermashov at oracle.com (Dmitriy Ermashov)
Date: Thu, 03 Jul 2014 18:49:09 +0400
Subject: <AWT Dev> Review Request for 8048246: Move
 AWT_DnD/Clipboard/Automated functional tests to OpenJDK
In-Reply-To: <7EE72A65-4F4D-4F37-B9AE-86854A79937C@oracle.com>
References: <53B29F31.6010808@oracle.com> <53B52784.9010303@oracle.com>
	<7EE72A65-4F4D-4F37-B9AE-86854A79937C@oracle.com>
Message-ID: <53B56D65.8080105@oracle.com>

Hi,
I've updated the webrev, so could you please review it?
http://cr.openjdk.java.net/~dermashov/8048246/webrev.02/

Last changes:
1. Clipboard folder moved to datatransfer folder.
2. Removed private fields/methods call from AddFlavorClipboard test
3. Test GetContentsInterruptedTest.java is a replacement for 
corresponding closed test

Thanks,
Dima

On 07/03/2014 02:30 PM, Petr Pchelko wrote:
> Hello, Dmitriy.
>
> As we do not have a Clipboard folder yet, could you please put Clipboard tests under java/awt/datatransfer/Clipboard so that all data transfer tests are in the same folder.
> AddFlavorTest:80 - here the test is using the private method via reflection. Please remove this part of the test (or the whole test if it looses it?s meaning without it). I will make big changes in the implementation soon, so this test will start to fail.
>
> I didn?t analyze every assertion, but as long as the tests pass on all platforms I?m OK with the rest of the fix.
>
> With best regards. Petr.
>
>
>> On Jul 3, 2014, at 1:51 PM, Dmitriy Ermashov <dmitriy.ermashov at oracle.com> wrote:
>>
>> Hi all,
>>
>> Please review the updated version of tests to be colocated.
>> http://cr.openjdk.java.net/~dermashov/8048246/webrev.01/
>> http://cr.openjdk.java.net/~dermashov/8048246/webrev.diff.01/
>>
>> Last changes:
>> 1. Removed 1 test from closed part. New GetContentsInterruptedTest.java is an up-to-date copy of it.
>>
>> Thanks,
>> Dima
>>
>> On 07/01/2014 03:44 PM, Dmitriy Ermashov wrote:
>>> Hi,
>>>
>>> Please review a new batch of functional AWT tests. Clipboard tests this time.
>>> http://cr.openjdk.java.net/~dermashov/8048246/webrev.00/
>>>
>>> Corresponding bug:
>>> https://bugs.openjdk.java.net/browse/JDK-8048246
>>>
>>> The changeset is pretty large, but, as always, it is several times smaller than original test suite.
>>> Tests were verified on the following platforms:
>>> Windows 7 x64
>>> Ubuntu 14.04 x64
>>> OS X 10.9.4 x64
>>> Solaris 11 x64
>>> Ubuntu 10.04 arm
>>>


From petr.pchelko at oracle.com  Thu Jul  3 14:55:22 2014
From: petr.pchelko at oracle.com (Petr Pchelko)
Date: Thu, 3 Jul 2014 18:55:22 +0400
Subject: <AWT Dev> Review Request for 8048246: Move
	AWT_DnD/Clipboard/Automated functional tests to OpenJDK
In-Reply-To: <53B56D65.8080105@oracle.com>
References: <53B29F31.6010808@oracle.com> <53B52784.9010303@oracle.com>
	<7EE72A65-4F4D-4F37-B9AE-86854A79937C@oracle.com>
	<53B56D65.8080105@oracle.com>
Message-ID: <D3EB634D-252D-4DCA-81FC-2484812BFB51@oracle.com>

Looks good to me.

With best regards. Petr.

> On Jul 3, 2014, at 6:49 PM, Dmitriy Ermashov <dmitriy.ermashov at oracle.com> wrote:
> 
> Hi,
> I've updated the webrev, so could you please review it?
> http://cr.openjdk.java.net/~dermashov/8048246/webrev.02/
> 
> Last changes:
> 1. Clipboard folder moved to datatransfer folder.
> 2. Removed private fields/methods call from AddFlavorClipboard test
> 3. Test GetContentsInterruptedTest.java is a replacement for corresponding closed test
> 
> Thanks,
> Dima
> 
> On 07/03/2014 02:30 PM, Petr Pchelko wrote:
>> Hello, Dmitriy.
>> 
>> As we do not have a Clipboard folder yet, could you please put Clipboard tests under java/awt/datatransfer/Clipboard so that all data transfer tests are in the same folder.
>> AddFlavorTest:80 - here the test is using the private method via reflection. Please remove this part of the test (or the whole test if it looses it?s meaning without it). I will make big changes in the implementation soon, so this test will start to fail.
>> 
>> I didn?t analyze every assertion, but as long as the tests pass on all platforms I?m OK with the rest of the fix.
>> 
>> With best regards. Petr.
>> 
>> 
>>> On Jul 3, 2014, at 1:51 PM, Dmitriy Ermashov <dmitriy.ermashov at oracle.com> wrote:
>>> 
>>> Hi all,
>>> 
>>> Please review the updated version of tests to be colocated.
>>> http://cr.openjdk.java.net/~dermashov/8048246/webrev.01/
>>> http://cr.openjdk.java.net/~dermashov/8048246/webrev.diff.01/
>>> 
>>> Last changes:
>>> 1. Removed 1 test from closed part. New GetContentsInterruptedTest.java is an up-to-date copy of it.
>>> 
>>> Thanks,
>>> Dima
>>> 
>>> On 07/01/2014 03:44 PM, Dmitriy Ermashov wrote:
>>>> Hi,
>>>> 
>>>> Please review a new batch of functional AWT tests. Clipboard tests this time.
>>>> http://cr.openjdk.java.net/~dermashov/8048246/webrev.00/
>>>> 
>>>> Corresponding bug:
>>>> https://bugs.openjdk.java.net/browse/JDK-8048246
>>>> 
>>>> The changeset is pretty large, but, as always, it is several times smaller than original test suite.
>>>> Tests were verified on the following platforms:
>>>> Windows 7 x64
>>>> Ubuntu 14.04 x64
>>>> OS X 10.9.4 x64
>>>> Solaris 11 x64
>>>> Ubuntu 10.04 arm
>>>> 
> 


From anthony.petrov at oracle.com  Fri Jul  4 10:12:30 2014
From: anthony.petrov at oracle.com (Anthony Petrov)
Date: Fri, 04 Jul 2014 14:12:30 +0400
Subject: <AWT Dev> <Swing Dev> [9] Review request for JDK-8046559: NPE
 when changing Windows theme
In-Reply-To: <53B408E1.70008@oracle.com>
References: <53B408E1.70008@oracle.com>
Message-ID: <53B67E0E.1020205@oracle.com>

Hi Alexey,

src/windows/classes/sun/awt/windows/WToolkit.java
>  940         final Map<String, Object> props = getWProps();
>  941         updateXPStyleEnabled(props.get(XPSTYLE_THEME_ACTIVE));

>  971     private synchronized Map<String, Object> getWProps() {
>  972         return (wprops != null) ? wprops.getProperties() : null;

There is a potential NPE at line 941.

--
best regards,
Anthony

On 7/2/2014 5:28 PM, Alexey Ivanov wrote:
> Hi AWT, Swing teams,
>
> Could you please review the fix to JDK-8046559 for jdk9:
>      bug: https://bugs.openjdk.java.net/browse/JDK-8046559
>      webrev: http://cr.openjdk.java.net/~aivanov/8046559/jdk9/webrev.00/
>
> Problem description:
> When changing Windows themes from a theme with visual styles (Windows
> Aero or Windows Basic) to a classic one, NullPointerException could be
> thrown from Swing code during component tree validation, or
> InternalError could be thrown during component painting.
>
> Root cause:
> Windows theme data are accessed via XPStyle and ThemeReader. When the
> theme is switched to a classic one, theme handles become unavailable,
> and theme data cannot be accessed any more. The change in theme is
> posted to EDT; at the same time, the UI often needs to repaint before
> the theme change is completely handled in Swing. This leads to NPE and
> InternalError as the code tries to access the data that has become
> unavailable.
>
> The fix:
> Windows desktop properties are updated right on Windows Toolkit thread,
> and the value of "win.xpstyle.themeActive" is stored in
> ThemeReader.xpStyleEnabled field. PropertyChangeEvents for desktop
> properties are delivered either synchronously on EDT or asynchronously
> via DesktopPropertyChangeSupport, as it used to be.
>
> Getters in XPStyle class check for null values and return dummy defaults
> if ThemeReader returned null. SkinPainters also check whether theming is
> still available before asking ThemeReader to paint.
>
> Access to XPStyle.xp instance is blocked as soon as user switches
> themes. The object will be cleaned when the corresponding
> PropertyChangeEvent is handled by Swing.
>
>
> This new version of the fix addresses issues found with the initial
> submission of JDK-8039383 fix:
>    - JDK-8046239: Build failure in 9-client on all non-Windows platforms
>    - JDK-8046391: Hang displaying JFileChooser with Windows L&F
>
> See also
> http://mail.openjdk.java.net/pipermail/awt-dev/2014-June/007975.html
> and http://cr.openjdk.java.net/~aivanov/8039383/jdk9/webrev.03/
>
>
> Regression test:
> No regression test is provided due to its complexity. Whether
> NullPointerException or InternalError are thrown depends on the order of
> event handling, sometimes exceptions do not occur when changing theme of
> visual styles enabled theme to a classic theme.
>
> I included regression test for hang in JFileChooser, JDK-8046391.
>
>
> Thank you,
> Alexey.

From petr.pchelko at oracle.com  Fri Jul  4 10:28:12 2014
From: petr.pchelko at oracle.com (Petr Pchelko)
Date: Fri, 4 Jul 2014 14:28:12 +0400
Subject: <AWT Dev> <Swing Dev> [9] Review request for JDK-8046559: NPE
	when changing Windows theme
In-Reply-To: <53B67E0E.1020205@oracle.com>
References: <53B408E1.70008@oracle.com> <53B67E0E.1020205@oracle.com>
Message-ID: <DF2CB1AE-CBA0-4729-A6D3-53AA400C7D7F@oracle.com>

Hello, Alexey.

Your test does not test the JFileChooser hang, because the bug is reproducible only in plugin mode where TK thread doesn't 
have an AppContext and we update the ThemeReader on the Toolkit thread. Your test runs in standalone mode
where completely different codepath is used. So I suggest either remove the test or update it to emulate multi-appcontext 
environment. Please see test/javax/swing/JComponent/8043610/bug8043610.java for an example on how to emulate this.

Otherwise the fix looks good assuming the JPRT job runs fine.

With best regards. Petr.

On 04 ???? 2014 ?., at 14:12, Anthony Petrov <anthony.petrov at oracle.com> wrote:

> Hi Alexey,
> 
> src/windows/classes/sun/awt/windows/WToolkit.java
>> 940         final Map<String, Object> props = getWProps();
>> 941         updateXPStyleEnabled(props.get(XPSTYLE_THEME_ACTIVE));
> 
>> 971     private synchronized Map<String, Object> getWProps() {
>> 972         return (wprops != null) ? wprops.getProperties() : null;
> 
> There is a potential NPE at line 941.
> 
> --
> best regards,
> Anthony
> 
> On 7/2/2014 5:28 PM, Alexey Ivanov wrote:
>> Hi AWT, Swing teams,
>> 
>> Could you please review the fix to JDK-8046559 for jdk9:
>>     bug: https://bugs.openjdk.java.net/browse/JDK-8046559
>>     webrev: http://cr.openjdk.java.net/~aivanov/8046559/jdk9/webrev.00/
>> 
>> Problem description:
>> When changing Windows themes from a theme with visual styles (Windows
>> Aero or Windows Basic) to a classic one, NullPointerException could be
>> thrown from Swing code during component tree validation, or
>> InternalError could be thrown during component painting.
>> 
>> Root cause:
>> Windows theme data are accessed via XPStyle and ThemeReader. When the
>> theme is switched to a classic one, theme handles become unavailable,
>> and theme data cannot be accessed any more. The change in theme is
>> posted to EDT; at the same time, the UI often needs to repaint before
>> the theme change is completely handled in Swing. This leads to NPE and
>> InternalError as the code tries to access the data that has become
>> unavailable.
>> 
>> The fix:
>> Windows desktop properties are updated right on Windows Toolkit thread,
>> and the value of "win.xpstyle.themeActive" is stored in
>> ThemeReader.xpStyleEnabled field. PropertyChangeEvents for desktop
>> properties are delivered either synchronously on EDT or asynchronously
>> via DesktopPropertyChangeSupport, as it used to be.
>> 
>> Getters in XPStyle class check for null values and return dummy defaults
>> if ThemeReader returned null. SkinPainters also check whether theming is
>> still available before asking ThemeReader to paint.
>> 
>> Access to XPStyle.xp instance is blocked as soon as user switches
>> themes. The object will be cleaned when the corresponding
>> PropertyChangeEvent is handled by Swing.
>> 
>> 
>> This new version of the fix addresses issues found with the initial
>> submission of JDK-8039383 fix:
>>   - JDK-8046239: Build failure in 9-client on all non-Windows platforms
>>   - JDK-8046391: Hang displaying JFileChooser with Windows L&F
>> 
>> See also
>> http://mail.openjdk.java.net/pipermail/awt-dev/2014-June/007975.html
>> and http://cr.openjdk.java.net/~aivanov/8039383/jdk9/webrev.03/
>> 
>> 
>> Regression test:
>> No regression test is provided due to its complexity. Whether
>> NullPointerException or InternalError are thrown depends on the order of
>> event handling, sometimes exceptions do not occur when changing theme of
>> visual styles enabled theme to a classic theme.
>> 
>> I included regression test for hang in JFileChooser, JDK-8046391.
>> 
>> 
>> Thank you,
>> Alexey.


From alexandr.scherbatiy at oracle.com  Fri Jul  4 10:26:05 2014
From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy)
Date: Fri, 04 Jul 2014 14:26:05 +0400
Subject: <AWT Dev> [9] Review request for 8044614: [macosx] Focus issue
 with 2 applets in firefox
In-Reply-To: <53B52FA1.7040001@oracle.com>
References: <53B3E2B1.1030303@oracle.com> <53B3FCB5.103@oracle.com>
	<53B51F4C.6060106@oracle.com> <53B52FA1.7040001@oracle.com>
Message-ID: <53B6813D.9070700@oracle.com>

On 7/3/2014 2:25 PM, Alexander Scherbatiy wrote:
> On 7/3/2014 1:15 PM, dmitry markov wrote:
>> Hi Alexandr,
>>
>> Thank you for review.
>> For the use case you described - when we move back to the first 
>> browser window with 3 applets, the first applet (not the second one) 
>> will receive the focus. This behavior is incorrect, since the second 
>> applet should receive the focus.
>> I have updated the fix, please find new version here: 
>> http://cr.openjdk.java.net/~dmarkov/8044614/jdk9/webrev.01/
>> Now we store the information about focused applet when browser window 
>> is deactivated and restore the focus to the previously focused applet 
>> when browser window becomes active again
>
>     The case can be more complicated with some browsers where each of 
> them has several applets.
>     It seems there should be a map between a browser and it's focused 
> applet.

    I see that your fix solves these cases.

    One more problem can be with the WindowsFocusEvents order.
    Is it guarantee that order of events WindowsFocusEvent 
(parentwindow=false) to one browser and WindowsFocusEvent 
(parentWindow=true)
    for other browser can't be changed?

   I would suggest to  do a small refactoring.
   Something like focusedWindow to globalFocusedWindow, 
previousFocusedWindow to pluginFocusedWindow, add method like 
isPluginFocused(...)
   and use conditional operator '?' for globalFocusedWindow setting.

   Thanks,
   Alexandr.


>
>
>     Is it possible to add a manual test for the fix?
>
>    Thanks,
>    Alexandr.
>
>>
>> Thanks,
>> Dmitry
>>
>> On 02/07/2014 16:36, Alexander Scherbatiy wrote:
>>>
>>>  Let's assume one browser has 3 applets where the second applet has 
>>> focus.
>>>  I click on the second browser with an applet (the applet receives 
>>> the focus) and then click on the first browser back.
>>>  Should the second applet in the first browser receive the focus?
>>>
>>>  Thanks,
>>>  Alexandr.
>>>
>>> On 7/2/2014 2:45 PM, dmitry markov wrote:
>>>> Hello,
>>>>
>>>> Could you review the fix for jdk9, please?
>>>>
>>>>     bug: https://bugs.openjdk.java.net/browse/JDK-8044614
>>>>     webrev: 
>>>> http://cr.openjdk.java.net/~dmarkov/8044614/jdk9/webrev.00/
>>>>
>>>> Problem description: on Mac OSX when switching between several 
>>>> applets running in separate browser's windows, the applet in active 
>>>> window does not receive focus.
>>>> Fix: the method CEmbeddedFrame.handleWindowFocusEvent() should be 
>>>> modified. It has to detect the switching between browser's windows 
>>>> and update focusedWindow field accordingly.
>>>>
>>>> Thanks,
>>>> Dmitry
>>>
>>
>


From petr.pchelko at oracle.com  Fri Jul  4 11:14:18 2014
From: petr.pchelko at oracle.com (Petr Pchelko)
Date: Fri, 4 Jul 2014 15:14:18 +0400
Subject: <AWT Dev> <Swing Dev> [9] Review request for JDK-8046559: NPE
	when changing Windows theme
In-Reply-To: <DF2CB1AE-CBA0-4729-A6D3-53AA400C7D7F@oracle.com>
References: <53B408E1.70008@oracle.com> <53B67E0E.1020205@oracle.com>
	<DF2CB1AE-CBA0-4729-A6D3-53AA400C7D7F@oracle.com>
Message-ID: <77F8A008-C68C-419B-B329-114D2A12ACFB@oracle.com>

Hello, Alexey.

> Your test does not test the JFileChooser hang, because the bug is reproducible only in plugin mode where TK thread doesn't 
> have an AppContext and we update the ThemeReader on the Toolkit thread. Your test runs in standalone mode
> where completely different codepath is used. So I suggest either remove the test or update it to emulate multi-appcontext 
> environment. Please see test/javax/swing/JComponent/8043610/bug8043610.java for an example on how to emulate this.
Sorry, disregard this comment. You've updated the code so that now it could deadlock in standalone too.

The fix looks good.

With best regards. Petr.

On 04 ???? 2014 ?., at 14:28, Petr Pchelko <petr.pchelko at oracle.com> wrote:

> Hello, Alexey.
> 
> Your test does not test the JFileChooser hang, because the bug is reproducible only in plugin mode where TK thread doesn't 
> have an AppContext and we update the ThemeReader on the Toolkit thread. Your test runs in standalone mode
> where completely different codepath is used. So I suggest either remove the test or update it to emulate multi-appcontext 
> environment. Please see test/javax/swing/JComponent/8043610/bug8043610.java for an example on how to emulate this.
> 
> Otherwise the fix looks good assuming the JPRT job runs fine.
> 
> With best regards. Petr.
> 
> On 04 ???? 2014 ?., at 14:12, Anthony Petrov <anthony.petrov at oracle.com> wrote:
> 
>> Hi Alexey,
>> 
>> src/windows/classes/sun/awt/windows/WToolkit.java
>>> 940         final Map<String, Object> props = getWProps();
>>> 941         updateXPStyleEnabled(props.get(XPSTYLE_THEME_ACTIVE));
>> 
>>> 971     private synchronized Map<String, Object> getWProps() {
>>> 972         return (wprops != null) ? wprops.getProperties() : null;
>> 
>> There is a potential NPE at line 941.
>> 
>> --
>> best regards,
>> Anthony
>> 
>> On 7/2/2014 5:28 PM, Alexey Ivanov wrote:
>>> Hi AWT, Swing teams,
>>> 
>>> Could you please review the fix to JDK-8046559 for jdk9:
>>>    bug: https://bugs.openjdk.java.net/browse/JDK-8046559
>>>    webrev: http://cr.openjdk.java.net/~aivanov/8046559/jdk9/webrev.00/
>>> 
>>> Problem description:
>>> When changing Windows themes from a theme with visual styles (Windows
>>> Aero or Windows Basic) to a classic one, NullPointerException could be
>>> thrown from Swing code during component tree validation, or
>>> InternalError could be thrown during component painting.
>>> 
>>> Root cause:
>>> Windows theme data are accessed via XPStyle and ThemeReader. When the
>>> theme is switched to a classic one, theme handles become unavailable,
>>> and theme data cannot be accessed any more. The change in theme is
>>> posted to EDT; at the same time, the UI often needs to repaint before
>>> the theme change is completely handled in Swing. This leads to NPE and
>>> InternalError as the code tries to access the data that has become
>>> unavailable.
>>> 
>>> The fix:
>>> Windows desktop properties are updated right on Windows Toolkit thread,
>>> and the value of "win.xpstyle.themeActive" is stored in
>>> ThemeReader.xpStyleEnabled field. PropertyChangeEvents for desktop
>>> properties are delivered either synchronously on EDT or asynchronously
>>> via DesktopPropertyChangeSupport, as it used to be.
>>> 
>>> Getters in XPStyle class check for null values and return dummy defaults
>>> if ThemeReader returned null. SkinPainters also check whether theming is
>>> still available before asking ThemeReader to paint.
>>> 
>>> Access to XPStyle.xp instance is blocked as soon as user switches
>>> themes. The object will be cleaned when the corresponding
>>> PropertyChangeEvent is handled by Swing.
>>> 
>>> 
>>> This new version of the fix addresses issues found with the initial
>>> submission of JDK-8039383 fix:
>>>  - JDK-8046239: Build failure in 9-client on all non-Windows platforms
>>>  - JDK-8046391: Hang displaying JFileChooser with Windows L&F
>>> 
>>> See also
>>> http://mail.openjdk.java.net/pipermail/awt-dev/2014-June/007975.html
>>> and http://cr.openjdk.java.net/~aivanov/8039383/jdk9/webrev.03/
>>> 
>>> 
>>> Regression test:
>>> No regression test is provided due to its complexity. Whether
>>> NullPointerException or InternalError are thrown depends on the order of
>>> event handling, sometimes exceptions do not occur when changing theme of
>>> visual styles enabled theme to a classic theme.
>>> 
>>> I included regression test for hang in JFileChooser, JDK-8046391.
>>> 
>>> 
>>> Thank you,
>>> Alexey.
> 


From alexander.v.stepanov at oracle.com  Fri Jul  4 13:10:41 2014
From: alexander.v.stepanov at oracle.com (alexander stepanov)
Date: Fri, 04 Jul 2014 17:10:41 +0400
Subject: <AWT Dev> [9] Review Request for 8043126: move awt automated
 functional tests from AWT_Events/Lw and AWT_Events/AWT to OpenJDK
 repository
In-Reply-To: <5395932F.7060905@oracle.com>
References: <5385CB8B.3080207@oracle.com> <5395932F.7060905@oracle.com>
Message-ID: <53B6A7D1.8030909@oracle.com>

Sorry, just a reminder.

Regards,
Alexander

On 09.06.2014 14:57, alexander stepanov wrote:
> Sorry, just a reminder.
>
> Thanks,
> Alexander
>
> On 28.05.2014 15:42, alexander stepanov wrote:
>> Hello,
>>
>> Could you please review the fix for the following bug:
>> https://bugs.openjdk.java.net/browse/JDK-8043126
>>
>> Webrev:
>> http://cr.openjdk.java.net/~yan/8043126/webrev.00/
>>
>> This is a set of functional AWT tests prepared for migration to 
>> OpenJDK repository.
>>
>> Some tests were refactored / unified to reduce code duplication. 
>> Lightweight component classes should be added as helpers to test base 
>> Component functionality.
>>
>> The tests were checked on Ubuntu 14.04, Solaris 11, Mac OS X 10.8.5 
>> and Windows 7
>>
>> Thanks,
>> Alexander
>


From alexey.ivanov at oracle.com  Fri Jul  4 13:49:13 2014
From: alexey.ivanov at oracle.com (Alexey Ivanov)
Date: Fri, 04 Jul 2014 17:49:13 +0400
Subject: <AWT Dev> <Swing Dev> [9] Review request for JDK-8046559: NPE
 when changing Windows theme
In-Reply-To: <53B67E0E.1020205@oracle.com>
References: <53B408E1.70008@oracle.com> <53B67E0E.1020205@oracle.com>
Message-ID: <53B6B0D9.8020703@oracle.com>

Hi Anthony,

Thank you for your review.
You're right, there's a potential NPE at line 941 in WToolkit.java.

I've added null check to avoid NPE.


Could you please review the updated webrev?
http://cr.openjdk.java.net/~aivanov/8046559/jdk9/webrev.01/


Thank you,
Alexey.

On 04.07.2014 14:12, Anthony Petrov wrote:
> Hi Alexey,
>
> src/windows/classes/sun/awt/windows/WToolkit.java
>>  940         final Map<String, Object> props = getWProps();
>>  941 updateXPStyleEnabled(props.get(XPSTYLE_THEME_ACTIVE));
>
>>  971     private synchronized Map<String, Object> getWProps() {
>>  972         return (wprops != null) ? wprops.getProperties() : null;
>
> There is a potential NPE at line 941.
Yes, you're
>
> -- 
> best regards,
> Anthony
>
> On 7/2/2014 5:28 PM, Alexey Ivanov wrote:
>> Hi AWT, Swing teams,
>>
>> Could you please review the fix to JDK-8046559 for jdk9:
>>      bug: https://bugs.openjdk.java.net/browse/JDK-8046559
>>      webrev: http://cr.openjdk.java.net/~aivanov/8046559/jdk9/webrev.00/
>>
>> Problem description:
>> When changing Windows themes from a theme with visual styles (Windows
>> Aero or Windows Basic) to a classic one, NullPointerException could be
>> thrown from Swing code during component tree validation, or
>> InternalError could be thrown during component painting.
>>
>> Root cause:
>> Windows theme data are accessed via XPStyle and ThemeReader. When the
>> theme is switched to a classic one, theme handles become unavailable,
>> and theme data cannot be accessed any more. The change in theme is
>> posted to EDT; at the same time, the UI often needs to repaint before
>> the theme change is completely handled in Swing. This leads to NPE and
>> InternalError as the code tries to access the data that has become
>> unavailable.
>>
>> The fix:
>> Windows desktop properties are updated right on Windows Toolkit thread,
>> and the value of "win.xpstyle.themeActive" is stored in
>> ThemeReader.xpStyleEnabled field. PropertyChangeEvents for desktop
>> properties are delivered either synchronously on EDT or asynchronously
>> via DesktopPropertyChangeSupport, as it used to be.
>>
>> Getters in XPStyle class check for null values and return dummy defaults
>> if ThemeReader returned null. SkinPainters also check whether theming is
>> still available before asking ThemeReader to paint.
>>
>> Access to XPStyle.xp instance is blocked as soon as user switches
>> themes. The object will be cleaned when the corresponding
>> PropertyChangeEvent is handled by Swing.
>>
>>
>> This new version of the fix addresses issues found with the initial
>> submission of JDK-8039383 fix:
>>    - JDK-8046239: Build failure in 9-client on all non-Windows platforms
>>    - JDK-8046391: Hang displaying JFileChooser with Windows L&F
>>
>> See also
>> http://mail.openjdk.java.net/pipermail/awt-dev/2014-June/007975.html
>> and http://cr.openjdk.java.net/~aivanov/8039383/jdk9/webrev.03/
>>
>>
>> Regression test:
>> No regression test is provided due to its complexity. Whether
>> NullPointerException or InternalError are thrown depends on the order of
>> event handling, sometimes exceptions do not occur when changing theme of
>> visual styles enabled theme to a classic theme.
>>
>> I included regression test for hang in JFileChooser, JDK-8046391.
>>
>>
>> Thank you,
>> Alexey.


From anthony.petrov at oracle.com  Fri Jul  4 13:51:00 2014
From: anthony.petrov at oracle.com (Anthony Petrov)
Date: Fri, 04 Jul 2014 17:51:00 +0400
Subject: <AWT Dev> <Swing Dev> [9] Review request for JDK-8046559: NPE
 when changing Windows theme
In-Reply-To: <53B6B0D9.8020703@oracle.com>
References: <53B408E1.70008@oracle.com> <53B67E0E.1020205@oracle.com>
	<53B6B0D9.8020703@oracle.com>
Message-ID: <53B6B144.4070607@oracle.com>

Thanks for the update. The fix looks good to me.

--
best regards,
Anthony

On 7/4/2014 5:49 PM, Alexey Ivanov wrote:
> Hi Anthony,
>
> Thank you for your review.
> You're right, there's a potential NPE at line 941 in WToolkit.java.
>
> I've added null check to avoid NPE.
>
>
> Could you please review the updated webrev?
> http://cr.openjdk.java.net/~aivanov/8046559/jdk9/webrev.01/
>
>
> Thank you,
> Alexey.
>
> On 04.07.2014 14:12, Anthony Petrov wrote:
>> Hi Alexey,
>>
>> src/windows/classes/sun/awt/windows/WToolkit.java
>>>  940         final Map<String, Object> props = getWProps();
>>>  941 updateXPStyleEnabled(props.get(XPSTYLE_THEME_ACTIVE));
>>
>>>  971     private synchronized Map<String, Object> getWProps() {
>>>  972         return (wprops != null) ? wprops.getProperties() : null;
>>
>> There is a potential NPE at line 941.
> Yes, you're
>>
>> --
>> best regards,
>> Anthony
>>
>> On 7/2/2014 5:28 PM, Alexey Ivanov wrote:
>>> Hi AWT, Swing teams,
>>>
>>> Could you please review the fix to JDK-8046559 for jdk9:
>>>      bug: https://bugs.openjdk.java.net/browse/JDK-8046559
>>>      webrev: http://cr.openjdk.java.net/~aivanov/8046559/jdk9/webrev.00/
>>>
>>> Problem description:
>>> When changing Windows themes from a theme with visual styles (Windows
>>> Aero or Windows Basic) to a classic one, NullPointerException could be
>>> thrown from Swing code during component tree validation, or
>>> InternalError could be thrown during component painting.
>>>
>>> Root cause:
>>> Windows theme data are accessed via XPStyle and ThemeReader. When the
>>> theme is switched to a classic one, theme handles become unavailable,
>>> and theme data cannot be accessed any more. The change in theme is
>>> posted to EDT; at the same time, the UI often needs to repaint before
>>> the theme change is completely handled in Swing. This leads to NPE and
>>> InternalError as the code tries to access the data that has become
>>> unavailable.
>>>
>>> The fix:
>>> Windows desktop properties are updated right on Windows Toolkit thread,
>>> and the value of "win.xpstyle.themeActive" is stored in
>>> ThemeReader.xpStyleEnabled field. PropertyChangeEvents for desktop
>>> properties are delivered either synchronously on EDT or asynchronously
>>> via DesktopPropertyChangeSupport, as it used to be.
>>>
>>> Getters in XPStyle class check for null values and return dummy defaults
>>> if ThemeReader returned null. SkinPainters also check whether theming is
>>> still available before asking ThemeReader to paint.
>>>
>>> Access to XPStyle.xp instance is blocked as soon as user switches
>>> themes. The object will be cleaned when the corresponding
>>> PropertyChangeEvent is handled by Swing.
>>>
>>>
>>> This new version of the fix addresses issues found with the initial
>>> submission of JDK-8039383 fix:
>>>    - JDK-8046239: Build failure in 9-client on all non-Windows platforms
>>>    - JDK-8046391: Hang displaying JFileChooser with Windows L&F
>>>
>>> See also
>>> http://mail.openjdk.java.net/pipermail/awt-dev/2014-June/007975.html
>>> and http://cr.openjdk.java.net/~aivanov/8039383/jdk9/webrev.03/
>>>
>>>
>>> Regression test:
>>> No regression test is provided due to its complexity. Whether
>>> NullPointerException or InternalError are thrown depends on the order of
>>> event handling, sometimes exceptions do not occur when changing theme of
>>> visual styles enabled theme to a classic theme.
>>>
>>> I included regression test for hang in JFileChooser, JDK-8046391.
>>>
>>>
>>> Thank you,
>>> Alexey.
>

From alexey.ivanov at oracle.com  Fri Jul  4 13:53:50 2014
From: alexey.ivanov at oracle.com (Alexey Ivanov)
Date: Fri, 04 Jul 2014 17:53:50 +0400
Subject: <AWT Dev> <Swing Dev> [9] Review request for JDK-8046559: NPE
 when changing Windows theme
In-Reply-To: <77F8A008-C68C-419B-B329-114D2A12ACFB@oracle.com>
References: <53B408E1.70008@oracle.com>
	<53B67E0E.1020205@oracle.com>	<DF2CB1AE-CBA0-4729-A6D3-53AA400C7D7F@oracle.com>
	<77F8A008-C68C-419B-B329-114D2A12ACFB@oracle.com>
Message-ID: <53B6B1EE.4050903@oracle.com>

Hello Petr,

Thank you for your review.

Regards,
Alexey.

On 04.07.2014 15:14, Petr Pchelko wrote:
> Hello, Alexey.
>
>> Your test does not test the JFileChooser hang, because the bug is reproducible only in plugin mode where TK thread doesn't
>> have an AppContext and we update the ThemeReader on the Toolkit thread. Your test runs in standalone mode
>> where completely different codepath is used. So I suggest either remove the test or update it to emulate multi-appcontext
>> environment. Please see test/javax/swing/JComponent/8043610/bug8043610.java for an example on how to emulate this.
> Sorry, disregard this comment. You've updated the code so that now it could deadlock in standalone too.
>
> The fix looks good.
>
> With best regards. Petr.
>
> On 04 ???? 2014 ?., at 14:28, Petr Pchelko <petr.pchelko at oracle.com> wrote:
>
>> Hello, Alexey.
>>
>> Your test does not test the JFileChooser hang, because the bug is reproducible only in plugin mode where TK thread doesn't
>> have an AppContext and we update the ThemeReader on the Toolkit thread. Your test runs in standalone mode
>> where completely different codepath is used. So I suggest either remove the test or update it to emulate multi-appcontext
>> environment. Please see test/javax/swing/JComponent/8043610/bug8043610.java for an example on how to emulate this.
>>
>> Otherwise the fix looks good assuming the JPRT job runs fine.
>>
>> With best regards. Petr.
>>
>> On 04 ???? 2014 ?., at 14:12, Anthony Petrov <anthony.petrov at oracle.com> wrote:
>>
>>> Hi Alexey,
>>>
>>> src/windows/classes/sun/awt/windows/WToolkit.java
>>>> 940         final Map<String, Object> props = getWProps();
>>>> 941         updateXPStyleEnabled(props.get(XPSTYLE_THEME_ACTIVE));
>>>> 971     private synchronized Map<String, Object> getWProps() {
>>>> 972         return (wprops != null) ? wprops.getProperties() : null;
>>> There is a potential NPE at line 941.
>>>
>>> --
>>> best regards,
>>> Anthony
>>>
>>> On 7/2/2014 5:28 PM, Alexey Ivanov wrote:
>>>> Hi AWT, Swing teams,
>>>>
>>>> Could you please review the fix to JDK-8046559 for jdk9:
>>>>     bug: https://bugs.openjdk.java.net/browse/JDK-8046559
>>>>     webrev: http://cr.openjdk.java.net/~aivanov/8046559/jdk9/webrev.00/
>>>>
>>>> Problem description:
>>>> When changing Windows themes from a theme with visual styles (Windows
>>>> Aero or Windows Basic) to a classic one, NullPointerException could be
>>>> thrown from Swing code during component tree validation, or
>>>> InternalError could be thrown during component painting.
>>>>
>>>> Root cause:
>>>> Windows theme data are accessed via XPStyle and ThemeReader. When the
>>>> theme is switched to a classic one, theme handles become unavailable,
>>>> and theme data cannot be accessed any more. The change in theme is
>>>> posted to EDT; at the same time, the UI often needs to repaint before
>>>> the theme change is completely handled in Swing. This leads to NPE and
>>>> InternalError as the code tries to access the data that has become
>>>> unavailable.
>>>>
>>>> The fix:
>>>> Windows desktop properties are updated right on Windows Toolkit thread,
>>>> and the value of "win.xpstyle.themeActive" is stored in
>>>> ThemeReader.xpStyleEnabled field. PropertyChangeEvents for desktop
>>>> properties are delivered either synchronously on EDT or asynchronously
>>>> via DesktopPropertyChangeSupport, as it used to be.
>>>>
>>>> Getters in XPStyle class check for null values and return dummy defaults
>>>> if ThemeReader returned null. SkinPainters also check whether theming is
>>>> still available before asking ThemeReader to paint.
>>>>
>>>> Access to XPStyle.xp instance is blocked as soon as user switches
>>>> themes. The object will be cleaned when the corresponding
>>>> PropertyChangeEvent is handled by Swing.
>>>>
>>>>
>>>> This new version of the fix addresses issues found with the initial
>>>> submission of JDK-8039383 fix:
>>>>   - JDK-8046239: Build failure in 9-client on all non-Windows platforms
>>>>   - JDK-8046391: Hang displaying JFileChooser with Windows L&F
>>>>
>>>> See also
>>>> http://mail.openjdk.java.net/pipermail/awt-dev/2014-June/007975.html
>>>> and http://cr.openjdk.java.net/~aivanov/8039383/jdk9/webrev.03/
>>>>
>>>>
>>>> Regression test:
>>>> No regression test is provided due to its complexity. Whether
>>>> NullPointerException or InternalError are thrown depends on the order of
>>>> event handling, sometimes exceptions do not occur when changing theme of
>>>> visual styles enabled theme to a classic theme.
>>>>
>>>> I included regression test for hang in JFileChooser, JDK-8046391.
>>>>
>>>>
>>>> Thank you,
>>>> Alexey.


From petr.pchelko at oracle.com  Fri Jul  4 14:00:06 2014
From: petr.pchelko at oracle.com (Petr Pchelko)
Date: Fri, 4 Jul 2014 18:00:06 +0400
Subject: <AWT Dev> [9] Review Request for 8043126: move awt automated
	functional tests from AWT_Events/Lw and AWT_Events/AWT to
	OpenJDK repository
In-Reply-To: <53B6A7D1.8030909@oracle.com>
References: <5385CB8B.3080207@oracle.com> <5395932F.7060905@oracle.com>
	<53B6A7D1.8030909@oracle.com>
Message-ID: <D3169D4E-F039-42B8-9057-F27C16141F8E@oracle.com>

Hello, Alexander.

Sorry for the delay.

First of all, could you please describe the approach used in these tests. I'm not quite sure 
I completely understand why do we need these special helper components.

Some comments:
1. LWList: 32  typo LeightWeight
2. MultipleMouseButtonsTest: 219 - you could reuse the robot.type function here. And same comment applies to other tests.

With best regards. Petr.

On 04 ???? 2014 ?., at 17:10, alexander stepanov <alexander.v.stepanov at oracle.com> wrote:

> Sorry, just a reminder.
> 
> Regards,
> Alexander
> 
> On 09.06.2014 14:57, alexander stepanov wrote:
>> Sorry, just a reminder.
>> 
>> Thanks,
>> Alexander
>> 
>> On 28.05.2014 15:42, alexander stepanov wrote:
>>> Hello,
>>> 
>>> Could you please review the fix for the following bug:
>>> https://bugs.openjdk.java.net/browse/JDK-8043126
>>> 
>>> Webrev:
>>> http://cr.openjdk.java.net/~yan/8043126/webrev.00/
>>> 
>>> This is a set of functional AWT tests prepared for migration to OpenJDK repository.
>>> 
>>> Some tests were refactored / unified to reduce code duplication. Lightweight component classes should be added as helpers to test base Component functionality.
>>> 
>>> The tests were checked on Ubuntu 14.04, Solaris 11, Mac OS X 10.8.5 and Windows 7
>>> 
>>> Thanks,
>>> Alexander
>> 
> 


From dmitriy.ermashov at oracle.com  Fri Jul  4 15:13:05 2014
From: dmitriy.ermashov at oracle.com (Dmitriy Ermashov)
Date: Fri, 4 Jul 2014 19:13:05 +0400
Subject: <AWT Dev> Review Request for 8048246: Move
	AWT_DnD/Clipboard/Automated functional tests to OpenJDK
In-Reply-To: <D3EB634D-252D-4DCA-81FC-2484812BFB51@oracle.com>
References: <53B29F31.6010808@oracle.com> <53B52784.9010303@oracle.com>
	<7EE72A65-4F4D-4F37-B9AE-86854A79937C@oracle.com>
	<53B56D65.8080105@oracle.com>
	<D3EB634D-252D-4DCA-81FC-2484812BFB51@oracle.com>
Message-ID: <2A2636C1-1E52-49C6-9A1D-AE8527A9BF0D@oracle.com>

Petr,

Thanks for review!

With regards,
Dmitriy Ermashov

> 03 ???? 2014 ?., ? 18:55, Petr Pchelko <petr.pchelko at oracle.com> ???????(?):
> 
> Looks good to me.
> 
> With best regards. Petr.
> 
>> On Jul 3, 2014, at 6:49 PM, Dmitriy Ermashov <dmitriy.ermashov at oracle.com> wrote:
>> 
>> Hi,
>> I've updated the webrev, so could you please review it?
>> http://cr.openjdk.java.net/~dermashov/8048246/webrev.02/
>> 
>> Last changes:
>> 1. Clipboard folder moved to datatransfer folder.
>> 2. Removed private fields/methods call from AddFlavorClipboard test
>> 3. Test GetContentsInterruptedTest.java is a replacement for corresponding closed test
>> 
>> Thanks,
>> Dima
>> 
>>> On 07/03/2014 02:30 PM, Petr Pchelko wrote:
>>> Hello, Dmitriy.
>>> 
>>> As we do not have a Clipboard folder yet, could you please put Clipboard tests under java/awt/datatransfer/Clipboard so that all data transfer tests are in the same folder.
>>> AddFlavorTest:80 - here the test is using the private method via reflection. Please remove this part of the test (or the whole test if it looses it?s meaning without it). I will make big changes in the implementation soon, so this test will start to fail.
>>> 
>>> I didn?t analyze every assertion, but as long as the tests pass on all platforms I?m OK with the rest of the fix.
>>> 
>>> With best regards. Petr.
>>> 
>>> 
>>>> On Jul 3, 2014, at 1:51 PM, Dmitriy Ermashov <dmitriy.ermashov at oracle.com> wrote:
>>>> 
>>>> Hi all,
>>>> 
>>>> Please review the updated version of tests to be colocated.
>>>> http://cr.openjdk.java.net/~dermashov/8048246/webrev.01/
>>>> http://cr.openjdk.java.net/~dermashov/8048246/webrev.diff.01/
>>>> 
>>>> Last changes:
>>>> 1. Removed 1 test from closed part. New GetContentsInterruptedTest.java is an up-to-date copy of it.
>>>> 
>>>> Thanks,
>>>> Dima
>>>> 
>>>>> On 07/01/2014 03:44 PM, Dmitriy Ermashov wrote:
>>>>> Hi,
>>>>> 
>>>>> Please review a new batch of functional AWT tests. Clipboard tests this time.
>>>>> http://cr.openjdk.java.net/~dermashov/8048246/webrev.00/
>>>>> 
>>>>> Corresponding bug:
>>>>> https://bugs.openjdk.java.net/browse/JDK-8048246
>>>>> 
>>>>> The changeset is pretty large, but, as always, it is several times smaller than original test suite.
>>>>> Tests were verified on the following platforms:
>>>>> Windows 7 x64
>>>>> Ubuntu 14.04 x64
>>>>> OS X 10.9.4 x64
>>>>> Solaris 11 x64
>>>>> Ubuntu 10.04 arm
> 

From alexander.v.stepanov at oracle.com  Fri Jul  4 15:19:09 2014
From: alexander.v.stepanov at oracle.com (alexander stepanov)
Date: Fri, 04 Jul 2014 19:19:09 +0400
Subject: <AWT Dev> [9] Review Request for 8043126: move awt automated
 functional tests from AWT_Events/Lw and AWT_Events/AWT to OpenJDK
 repository
In-Reply-To: <D3169D4E-F039-42B8-9057-F27C16141F8E@oracle.com>
References: <5385CB8B.3080207@oracle.com> <5395932F.7060905@oracle.com>
	<53B6A7D1.8030909@oracle.com>
	<D3169D4E-F039-42B8-9057-F27C16141F8E@oracle.com>
Message-ID: <53B6C5ED.1060701@oracle.com>

Hello Petr,

 > I'm not quite sure I completely understand why do we need these 
special helper components.

At the moment we have a lot of functional tests (not only event-related) 
testing the lightweight components (LWButton, LWList) and having the 
same test logic as the corresponding tests for AWT components.

I asked Sergey Bylokhov about them and his opinion (if I understood him 
correctly) was that the aim of these tests is to check the base 
functionality for Component class (because the user in principle can 
derive his own components from it).

So the final decision was to keep the lightweight components tests and 
unify them with the tests for corresponding AWT components (to reduce 
code duplication); - that's all, I didn't have any other special 
considerations.

The helper classes weren't refactored deeply (only minor cosmetic 
changes like formatting / copyright notice) because at the moment it is 
not clear what methods should be used in future relocation job.


With respect to other notes - I'll fix them and post a new webrev, thanks.

Regards,
Alexander



On 04.07.2014 18:00, Petr Pchelko wrote:
> Hello, Alexander.
>
> Sorry for the delay.
>
> First of all, could you please describe the approach used in these tests. I'm not quite sure
> I completely understand why do we need these special helper components.
>
> Some comments:
> 1. LWList: 32  typo LeightWeight
> 2. MultipleMouseButtonsTest: 219 - you could reuse the robot.type function here. And same comment applies to other tests.
>
> With best regards. Petr.
>
> On 04 ???? 2014 ?., at 17:10, alexander stepanov <alexander.v.stepanov at oracle.com> wrote:
>
>> Sorry, just a reminder.
>>
>> Regards,
>> Alexander
>>
>> On 09.06.2014 14:57, alexander stepanov wrote:
>>> Sorry, just a reminder.
>>>
>>> Thanks,
>>> Alexander
>>>
>>> On 28.05.2014 15:42, alexander stepanov wrote:
>>>> Hello,
>>>>
>>>> Could you please review the fix for the following bug:
>>>> https://bugs.openjdk.java.net/browse/JDK-8043126
>>>>
>>>> Webrev:
>>>> http://cr.openjdk.java.net/~yan/8043126/webrev.00/
>>>>
>>>> This is a set of functional AWT tests prepared for migration to OpenJDK repository.
>>>>
>>>> Some tests were refactored / unified to reduce code duplication. Lightweight component classes should be added as helpers to test base Component functionality.
>>>>
>>>> The tests were checked on Ubuntu 14.04, Solaris 11, Mac OS X 10.8.5 and Windows 7
>>>>
>>>> Thanks,
>>>> Alexander


From petr.pchelko at oracle.com  Mon Jul  7 10:44:08 2014
From: petr.pchelko at oracle.com (Petr Pchelko)
Date: Mon, 7 Jul 2014 14:44:08 +0400
Subject: <AWT Dev> <Swing Dev> [9] Review request for JDK-8046559: NPE
	when changing Windows theme
In-Reply-To: <77F8A008-C68C-419B-B329-114D2A12ACFB@oracle.com>
References: <53B408E1.70008@oracle.com> <53B67E0E.1020205@oracle.com>
	<DF2CB1AE-CBA0-4729-A6D3-53AA400C7D7F@oracle.com>
	<77F8A008-C68C-419B-B329-114D2A12ACFB@oracle.com>
Message-ID: <858CDCED-856D-4434-B0D3-44791F260EA1@oracle.com>

Hello, Alexey.

The new version still looks good.

With best regards. Petr.

> On Jul 4, 2014, at 3:14 PM, Petr Pchelko <petr.pchelko at oracle.com> wrote:
> 
> Hello, Alexey.
> 
>> Your test does not test the JFileChooser hang, because the bug is reproducible only in plugin mode where TK thread doesn't 
>> have an AppContext and we update the ThemeReader on the Toolkit thread. Your test runs in standalone mode
>> where completely different codepath is used. So I suggest either remove the test or update it to emulate multi-appcontext 
>> environment. Please see test/javax/swing/JComponent/8043610/bug8043610.java for an example on how to emulate this.
> Sorry, disregard this comment. You've updated the code so that now it could deadlock in standalone too.
> 
> The fix looks good.
> 
> With best regards. Petr.
> 
> On 04 ???? 2014 ?., at 14:28, Petr Pchelko <petr.pchelko at oracle.com> wrote:
> 
>> Hello, Alexey.
>> 
>> Your test does not test the JFileChooser hang, because the bug is reproducible only in plugin mode where TK thread doesn't 
>> have an AppContext and we update the ThemeReader on the Toolkit thread. Your test runs in standalone mode
>> where completely different codepath is used. So I suggest either remove the test or update it to emulate multi-appcontext 
>> environment. Please see test/javax/swing/JComponent/8043610/bug8043610.java for an example on how to emulate this.
>> 
>> Otherwise the fix looks good assuming the JPRT job runs fine.
>> 
>> With best regards. Petr.
>> 
>> On 04 ???? 2014 ?., at 14:12, Anthony Petrov <anthony.petrov at oracle.com> wrote:
>> 
>>> Hi Alexey,
>>> 
>>> src/windows/classes/sun/awt/windows/WToolkit.java
>>>> 940         final Map<String, Object> props = getWProps();
>>>> 941         updateXPStyleEnabled(props.get(XPSTYLE_THEME_ACTIVE));
>>> 
>>>> 971     private synchronized Map<String, Object> getWProps() {
>>>> 972         return (wprops != null) ? wprops.getProperties() : null;
>>> 
>>> There is a potential NPE at line 941.
>>> 
>>> --
>>> best regards,
>>> Anthony
>>> 
>>> On 7/2/2014 5:28 PM, Alexey Ivanov wrote:
>>>> Hi AWT, Swing teams,
>>>> 
>>>> Could you please review the fix to JDK-8046559 for jdk9:
>>>>   bug: https://bugs.openjdk.java.net/browse/JDK-8046559
>>>>   webrev: http://cr.openjdk.java.net/~aivanov/8046559/jdk9/webrev.00/
>>>> 
>>>> Problem description:
>>>> When changing Windows themes from a theme with visual styles (Windows
>>>> Aero or Windows Basic) to a classic one, NullPointerException could be
>>>> thrown from Swing code during component tree validation, or
>>>> InternalError could be thrown during component painting.
>>>> 
>>>> Root cause:
>>>> Windows theme data are accessed via XPStyle and ThemeReader. When the
>>>> theme is switched to a classic one, theme handles become unavailable,
>>>> and theme data cannot be accessed any more. The change in theme is
>>>> posted to EDT; at the same time, the UI often needs to repaint before
>>>> the theme change is completely handled in Swing. This leads to NPE and
>>>> InternalError as the code tries to access the data that has become
>>>> unavailable.
>>>> 
>>>> The fix:
>>>> Windows desktop properties are updated right on Windows Toolkit thread,
>>>> and the value of "win.xpstyle.themeActive" is stored in
>>>> ThemeReader.xpStyleEnabled field. PropertyChangeEvents for desktop
>>>> properties are delivered either synchronously on EDT or asynchronously
>>>> via DesktopPropertyChangeSupport, as it used to be.
>>>> 
>>>> Getters in XPStyle class check for null values and return dummy defaults
>>>> if ThemeReader returned null. SkinPainters also check whether theming is
>>>> still available before asking ThemeReader to paint.
>>>> 
>>>> Access to XPStyle.xp instance is blocked as soon as user switches
>>>> themes. The object will be cleaned when the corresponding
>>>> PropertyChangeEvent is handled by Swing.
>>>> 
>>>> 
>>>> This new version of the fix addresses issues found with the initial
>>>> submission of JDK-8039383 fix:
>>>> - JDK-8046239: Build failure in 9-client on all non-Windows platforms
>>>> - JDK-8046391: Hang displaying JFileChooser with Windows L&F
>>>> 
>>>> See also
>>>> http://mail.openjdk.java.net/pipermail/awt-dev/2014-June/007975.html
>>>> and http://cr.openjdk.java.net/~aivanov/8039383/jdk9/webrev.03/
>>>> 
>>>> 
>>>> Regression test:
>>>> No regression test is provided due to its complexity. Whether
>>>> NullPointerException or InternalError are thrown depends on the order of
>>>> event handling, sometimes exceptions do not occur when changing theme of
>>>> visual styles enabled theme to a classic theme.
>>>> 
>>>> I included regression test for hang in JFileChooser, JDK-8046391.
>>>> 
>>>> 
>>>> Thank you,
>>>> Alexey.
>> 
> 


From alexander.zvegintsev at oracle.com  Mon Jul  7 14:22:55 2014
From: alexander.zvegintsev at oracle.com (Alexander Zvegintsev)
Date: Mon, 07 Jul 2014 18:22:55 +0400
Subject: <AWT Dev> [9] Review request for 8049418: [macosx]
 PopupMenuListener.popupMenuWillBecomeVisible is not called for empty
 combobox on MacOS/aqua look and feel
Message-ID: <53BAAD3F.3000704@oracle.com>

Hello,

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


The JDK-8041896 [1] fix consists of two part: actual fix in 
LWChoicePeer.java and unrelated improvements in AquaComboBoxPopup.java.
Changes in AquaComboBoxPopup.java was introduced to remove popup window 
blinking(it shows for about 0.1 sec and then closes).
However this introduce another regression: popupMenuWillBecomeVisible 
handler is not called for empty combobox.

This fix simply reverts AquaComboBoxPopup.java to its previous behavior.

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

-- 
Thanks,

Alexander.


From petr.pchelko at oracle.com  Mon Jul  7 14:35:55 2014
From: petr.pchelko at oracle.com (Petr Pchelko)
Date: Mon, 7 Jul 2014 18:35:55 +0400
Subject: <AWT Dev> [9] Review request for 8049418: [macosx]
	PopupMenuListener.popupMenuWillBecomeVisible is not called
	for empty combobox on MacOS/aqua look and feel
In-Reply-To: <53BAAD3F.3000704@oracle.com>
References: <53BAAD3F.3000704@oracle.com>
Message-ID: <3BD8E943-EF63-46A2-9CA2-CDF2923FE2E9@oracle.com>

Hi, Alexander.

The fix looks good, just one question. The blinking problem returns back? Could you please file a P4 bug for it? 

With best regards. Petr.

> On Jul 7, 2014, at 6:22 PM, Alexander Zvegintsev <alexander.zvegintsev at oracle.com> wrote:
> 
> Hello,
> 
> please review the fix
> http://cr.openjdk.java.net/~azvegint/jdk/9/8049418/00/
> for the issue
> https://bugs.openjdk.java.net/browse/JDK-8049418
> 
> 
> The JDK-8041896 [1] fix consists of two part: actual fix in LWChoicePeer.java and unrelated improvements in AquaComboBoxPopup.java.
> Changes in AquaComboBoxPopup.java was introduced to remove popup window blinking(it shows for about 0.1 sec and then closes).
> However this introduce another regression: popupMenuWillBecomeVisible handler is not called for empty combobox.
> 
> This fix simply reverts AquaComboBoxPopup.java to its previous behavior.
> 
> [1] https://bugs.openjdk.java.net/browse/JDK-8041896
> 
> -- 
> Thanks,
> 
> Alexander.
> 


From alexander.zvegintsev at oracle.com  Mon Jul  7 14:50:47 2014
From: alexander.zvegintsev at oracle.com (Alexander Zvegintsev)
Date: Mon, 07 Jul 2014 18:50:47 +0400
Subject: <AWT Dev> [9] Review request for 8049418: [macosx]
 PopupMenuListener.popupMenuWillBecomeVisible is not called for empty
 combobox on MacOS/aqua look and feel
In-Reply-To: <3BD8E943-EF63-46A2-9CA2-CDF2923FE2E9@oracle.com>
References: <53BAAD3F.3000704@oracle.com>
	<3BD8E943-EF63-46A2-9CA2-CDF2923FE2E9@oracle.com>
Message-ID: <53BAB3C7.2020800@oracle.com>

Petr,

Sure, it returns back.

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

Thanks,

Alexander.

On 07/07/2014 06:35 PM, Petr Pchelko wrote:
> Hi, Alexander.
>
> The fix looks good, just one question. The blinking problem returns back? Could you please file a P4 bug for it?
>
> With best regards. Petr.
>
>> On Jul 7, 2014, at 6:22 PM, Alexander Zvegintsev <alexander.zvegintsev at oracle.com> wrote:
>>
>> Hello,
>>
>> please review the fix
>> http://cr.openjdk.java.net/~azvegint/jdk/9/8049418/00/
>> for the issue
>> https://bugs.openjdk.java.net/browse/JDK-8049418
>>
>>
>> The JDK-8041896 [1] fix consists of two part: actual fix in LWChoicePeer.java and unrelated improvements in AquaComboBoxPopup.java.
>> Changes in AquaComboBoxPopup.java was introduced to remove popup window blinking(it shows for about 0.1 sec and then closes).
>> However this introduce another regression: popupMenuWillBecomeVisible handler is not called for empty combobox.
>>
>> This fix simply reverts AquaComboBoxPopup.java to its previous behavior.
>>
>> [1] https://bugs.openjdk.java.net/browse/JDK-8041896
>>
>> -- 
>> Thanks,
>>
>> Alexander.
>>


From anthony.petrov at oracle.com  Mon Jul  7 14:54:03 2014
From: anthony.petrov at oracle.com (Anthony Petrov)
Date: Mon, 07 Jul 2014 18:54:03 +0400
Subject: <AWT Dev> [9] Review request for 8049418: [macosx]
 PopupMenuListener.popupMenuWillBecomeVisible is not called for empty
 combobox on MacOS/aqua look and feel
In-Reply-To: <53BAB3C7.2020800@oracle.com>
References: <53BAAD3F.3000704@oracle.com>	<3BD8E943-EF63-46A2-9CA2-CDF2923FE2E9@oracle.com>
	<53BAB3C7.2020800@oracle.com>
Message-ID: <53BAB48B.5070400@oracle.com>

The fix looks fine to me, too.

--
best regards,
Anthony

On 7/7/2014 6:50 PM, Alexander Zvegintsev wrote:
> Petr,
>
> Sure, it returns back.
>
> https://bugs.openjdk.java.net/browse/JDK-8049439
>
> Thanks,
>
> Alexander.
>
> On 07/07/2014 06:35 PM, Petr Pchelko wrote:
>> Hi, Alexander.
>>
>> The fix looks good, just one question. The blinking problem returns
>> back? Could you please file a P4 bug for it?
>>
>> With best regards. Petr.
>>
>>> On Jul 7, 2014, at 6:22 PM, Alexander Zvegintsev
>>> <alexander.zvegintsev at oracle.com> wrote:
>>>
>>> Hello,
>>>
>>> please review the fix
>>> http://cr.openjdk.java.net/~azvegint/jdk/9/8049418/00/
>>> for the issue
>>> https://bugs.openjdk.java.net/browse/JDK-8049418
>>>
>>>
>>> The JDK-8041896 [1] fix consists of two part: actual fix in
>>> LWChoicePeer.java and unrelated improvements in AquaComboBoxPopup.java.
>>> Changes in AquaComboBoxPopup.java was introduced to remove popup
>>> window blinking(it shows for about 0.1 sec and then closes).
>>> However this introduce another regression: popupMenuWillBecomeVisible
>>> handler is not called for empty combobox.
>>>
>>> This fix simply reverts AquaComboBoxPopup.java to its previous behavior.
>>>
>>> [1] https://bugs.openjdk.java.net/browse/JDK-8041896
>>>
>>> --
>>> Thanks,
>>>
>>> Alexander.
>>>
>

From alexander.v.stepanov at oracle.com  Mon Jul  7 15:35:05 2014
From: alexander.v.stepanov at oracle.com (alexander stepanov)
Date: Mon, 07 Jul 2014 19:35:05 +0400
Subject: <AWT Dev> [9] Review Request for 8047367: move awt automated tests
 from AWT_Modality to OpenJDK repository - part 2
Message-ID: <53BABE29.4040507@oracle.com>

Hello,

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

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

This is a set of functional AWT tests prepared for migration to OpenJDK 
repository.

The tests were checked on OEL 6, Solaris 11, Mac OS X 10.8.5 and Windows 
7. Some of them are failing due to
https://bugs.openjdk.java.net/browse/JDK-8049339
https://bugs.openjdk.java.net/browse/JDK-8048263

Thanks,
Alexander

From petr.pchelko at oracle.com  Tue Jul  8 10:19:00 2014
From: petr.pchelko at oracle.com (Petr Pchelko)
Date: Tue, 8 Jul 2014 14:19:00 +0400
Subject: <AWT Dev> [9] Review Request: 8035568 [macosx] Cursor management
	unification.
Message-ID: <9F76EFF5-02F6-4205-A120-D7ADAF0D7B66@oracle.com>

Hello, AWT Team.

Please review the fix for the issue:
https://bugs.openjdk.java.net/browse/JDK-8035568
The fix is available at:
http://cr.openjdk.java.net/~pchelko/9/8035568/webrev.00/

We are using 2 different methods for getting a cursor position in Robot and in LWAWT. I've changed our implementation to use Carbon method.
nativeGetCursorPosition is a very hot method and changing it's implementation makes it run 35 times faster. Also we will never deadlock on it any more.
However, I needed to change the isWindowUnderMouse implementation. The problem's that LWWindowPeer.windowUnderCursor is updated on mouse events
and generated mouse events, so sometimes it may be not updated when called from a component resize handler. Luckily we can test it using native code. 
isWindowUnderMouse is not a hot method at all, in real apps it's called very rarely (never called after a couple of hours of real IDE usage) so it's not a problem that it
runs slower now.

I've run all cursor/mouse tests. A couple of tests failed because they didn't have proper synchronization and we are too fast for them now. I've fixed it and open-sourced the tests.

With best regards. Petr.

From alexander.v.stepanov at oracle.com  Tue Jul  8 11:27:44 2014
From: alexander.v.stepanov at oracle.com (alexander stepanov)
Date: Tue, 08 Jul 2014 15:27:44 +0400
Subject: <AWT Dev> [9] Review Request for 8043126: move awt automated
 functional tests from AWT_Events/Lw and AWT_Events/AWT to OpenJDK
 repository
In-Reply-To: <53B6C5ED.1060701@oracle.com>
References: <5385CB8B.3080207@oracle.com> <5395932F.7060905@oracle.com>
	<53B6A7D1.8030909@oracle.com>
	<D3169D4E-F039-42B8-9057-F27C16141F8E@oracle.com>
	<53B6C5ED.1060701@oracle.com>
Message-ID: <53BBD5B0.5080902@oracle.com>

Please see also the updated webrev here: 
http://cr.openjdk.java.net/~avstepan/8043126/webrev.01/

Regards,
Alexander

On 04.07.2014 19:19, alexander stepanov wrote:
> Hello Petr,
>
> > I'm not quite sure I completely understand why do we need these 
> special helper components.
>
> At the moment we have a lot of functional tests (not only 
> event-related) testing the lightweight components (LWButton, LWList) 
> and having the same test logic as the corresponding tests for AWT 
> components.
>
> I asked Sergey Bylokhov about them and his opinion (if I understood 
> him correctly) was that the aim of these tests is to check the base 
> functionality for Component class (because the user in principle can 
> derive his own components from it).
>
> So the final decision was to keep the lightweight components tests and 
> unify them with the tests for corresponding AWT components (to reduce 
> code duplication); - that's all, I didn't have any other special 
> considerations.
>
> The helper classes weren't refactored deeply (only minor cosmetic 
> changes like formatting / copyright notice) because at the moment it 
> is not clear what methods should be used in future relocation job.
>
>
> With respect to other notes - I'll fix them and post a new webrev, 
> thanks.
>
> Regards,
> Alexander
>
>
>
> On 04.07.2014 18:00, Petr Pchelko wrote:
>> Hello, Alexander.
>>
>> Sorry for the delay.
>>
>> First of all, could you please describe the approach used in these 
>> tests. I'm not quite sure
>> I completely understand why do we need these special helper components.
>>
>> Some comments:
>> 1. LWList: 32  typo LeightWeight
>> 2. MultipleMouseButtonsTest: 219 - you could reuse the robot.type 
>> function here. And same comment applies to other tests.
>>
>> With best regards. Petr.
>>
>> On 04 ???? 2014 ?., at 17:10, alexander stepanov 
>> <alexander.v.stepanov at oracle.com> wrote:
>>
>>> Sorry, just a reminder.
>>>
>>> Regards,
>>> Alexander
>>>
>>> On 09.06.2014 14:57, alexander stepanov wrote:
>>>> Sorry, just a reminder.
>>>>
>>>> Thanks,
>>>> Alexander
>>>>
>>>> On 28.05.2014 15:42, alexander stepanov wrote:
>>>>> Hello,
>>>>>
>>>>> Could you please review the fix for the following bug:
>>>>> https://bugs.openjdk.java.net/browse/JDK-8043126
>>>>>
>>>>> Webrev:
>>>>> http://cr.openjdk.java.net/~yan/8043126/webrev.00/
>>>>>
>>>>> This is a set of functional AWT tests prepared for migration to 
>>>>> OpenJDK repository.
>>>>>
>>>>> Some tests were refactored / unified to reduce code duplication. 
>>>>> Lightweight component classes should be added as helpers to test 
>>>>> base Component functionality.
>>>>>
>>>>> The tests were checked on Ubuntu 14.04, Solaris 11, Mac OS X 
>>>>> 10.8.5 and Windows 7
>>>>>
>>>>> Thanks,
>>>>> Alexander
>


From petr.pchelko at oracle.com  Tue Jul  8 11:34:20 2014
From: petr.pchelko at oracle.com (Petr Pchelko)
Date: Tue, 8 Jul 2014 15:34:20 +0400
Subject: <AWT Dev> [9] Review Request for 8043126: move awt automated
	functional tests from AWT_Events/Lw and AWT_Events/AWT to
	OpenJDK repository
In-Reply-To: <53BBD5B0.5080902@oracle.com>
References: <5385CB8B.3080207@oracle.com> <5395932F.7060905@oracle.com>
	<53B6A7D1.8030909@oracle.com>
	<D3169D4E-F039-42B8-9057-F27C16141F8E@oracle.com>
	<53B6C5ED.1060701@oracle.com> <53BBD5B0.5080902@oracle.com>
Message-ID: <FB252D04-881A-4B6C-9CF2-BAE1E166FC05@oracle.com>

Hello, Alexander.

The fix looks good to me.

With best regards. Petr.

On 08 ???? 2014 ?., at 15:27, alexander stepanov <alexander.v.stepanov at oracle.com> wrote:

> Please see also the updated webrev here: http://cr.openjdk.java.net/~avstepan/8043126/webrev.01/
> 
> Regards,
> Alexander
> 
> On 04.07.2014 19:19, alexander stepanov wrote:
>> Hello Petr,
>> 
>> > I'm not quite sure I completely understand why do we need these special helper components.
>> 
>> At the moment we have a lot of functional tests (not only event-related) testing the lightweight components (LWButton, LWList) and having the same test logic as the corresponding tests for AWT components.
>> 
>> I asked Sergey Bylokhov about them and his opinion (if I understood him correctly) was that the aim of these tests is to check the base functionality for Component class (because the user in principle can derive his own components from it).
>> 
>> So the final decision was to keep the lightweight components tests and unify them with the tests for corresponding AWT components (to reduce code duplication); - that's all, I didn't have any other special considerations.
>> 
>> The helper classes weren't refactored deeply (only minor cosmetic changes like formatting / copyright notice) because at the moment it is not clear what methods should be used in future relocation job.
>> 
>> 
>> With respect to other notes - I'll fix them and post a new webrev, thanks.
>> 
>> Regards,
>> Alexander
>> 
>> 
>> 
>> On 04.07.2014 18:00, Petr Pchelko wrote:
>>> Hello, Alexander.
>>> 
>>> Sorry for the delay.
>>> 
>>> First of all, could you please describe the approach used in these tests. I'm not quite sure
>>> I completely understand why do we need these special helper components.
>>> 
>>> Some comments:
>>> 1. LWList: 32  typo LeightWeight
>>> 2. MultipleMouseButtonsTest: 219 - you could reuse the robot.type function here. And same comment applies to other tests.
>>> 
>>> With best regards. Petr.
>>> 
>>> On 04 ???? 2014 ?., at 17:10, alexander stepanov <alexander.v.stepanov at oracle.com> wrote:
>>> 
>>>> Sorry, just a reminder.
>>>> 
>>>> Regards,
>>>> Alexander
>>>> 
>>>> On 09.06.2014 14:57, alexander stepanov wrote:
>>>>> Sorry, just a reminder.
>>>>> 
>>>>> Thanks,
>>>>> Alexander
>>>>> 
>>>>> On 28.05.2014 15:42, alexander stepanov wrote:
>>>>>> Hello,
>>>>>> 
>>>>>> Could you please review the fix for the following bug:
>>>>>> https://bugs.openjdk.java.net/browse/JDK-8043126
>>>>>> 
>>>>>> Webrev:
>>>>>> http://cr.openjdk.java.net/~yan/8043126/webrev.00/
>>>>>> 
>>>>>> This is a set of functional AWT tests prepared for migration to OpenJDK repository.
>>>>>> 
>>>>>> Some tests were refactored / unified to reduce code duplication. Lightweight component classes should be added as helpers to test base Component functionality.
>>>>>> 
>>>>>> The tests were checked on Ubuntu 14.04, Solaris 11, Mac OS X 10.8.5 and Windows 7
>>>>>> 
>>>>>> Thanks,
>>>>>> Alexander
>> 
> 


From alexander.v.stepanov at oracle.com  Tue Jul  8 11:36:00 2014
From: alexander.v.stepanov at oracle.com (alexander stepanov)
Date: Tue, 08 Jul 2014 15:36:00 +0400
Subject: <AWT Dev> [9] Review Request for 8043126: move awt automated
 functional tests from AWT_Events/Lw and AWT_Events/AWT to OpenJDK
 repository
In-Reply-To: <FB252D04-881A-4B6C-9CF2-BAE1E166FC05@oracle.com>
References: <5385CB8B.3080207@oracle.com> <5395932F.7060905@oracle.com>
	<53B6A7D1.8030909@oracle.com>
	<D3169D4E-F039-42B8-9057-F27C16141F8E@oracle.com>
	<53B6C5ED.1060701@oracle.com> <53BBD5B0.5080902@oracle.com>
	<FB252D04-881A-4B6C-9CF2-BAE1E166FC05@oracle.com>
Message-ID: <53BBD7A0.4080608@oracle.com>

Thanks!

On 08.07.2014 15:34, Petr Pchelko wrote:
> Hello, Alexander.
>
> The fix looks good to me.
>
> With best regards. Petr.
>
> On 08 ???? 2014 ?., at 15:27, alexander stepanov <alexander.v.stepanov at oracle.com> wrote:
>
>> Please see also the updated webrev here: http://cr.openjdk.java.net/~avstepan/8043126/webrev.01/
>>
>> Regards,
>> Alexander
>>
>> On 04.07.2014 19:19, alexander stepanov wrote:
>>> Hello Petr,
>>>
>>>> I'm not quite sure I completely understand why do we need these special helper components.
>>> At the moment we have a lot of functional tests (not only event-related) testing the lightweight components (LWButton, LWList) and having the same test logic as the corresponding tests for AWT components.
>>>
>>> I asked Sergey Bylokhov about them and his opinion (if I understood him correctly) was that the aim of these tests is to check the base functionality for Component class (because the user in principle can derive his own components from it).
>>>
>>> So the final decision was to keep the lightweight components tests and unify them with the tests for corresponding AWT components (to reduce code duplication); - that's all, I didn't have any other special considerations.
>>>
>>> The helper classes weren't refactored deeply (only minor cosmetic changes like formatting / copyright notice) because at the moment it is not clear what methods should be used in future relocation job.
>>>
>>>
>>> With respect to other notes - I'll fix them and post a new webrev, thanks.
>>>
>>> Regards,
>>> Alexander
>>>
>>>
>>>
>>> On 04.07.2014 18:00, Petr Pchelko wrote:
>>>> Hello, Alexander.
>>>>
>>>> Sorry for the delay.
>>>>
>>>> First of all, could you please describe the approach used in these tests. I'm not quite sure
>>>> I completely understand why do we need these special helper components.
>>>>
>>>> Some comments:
>>>> 1. LWList: 32  typo LeightWeight
>>>> 2. MultipleMouseButtonsTest: 219 - you could reuse the robot.type function here. And same comment applies to other tests.
>>>>
>>>> With best regards. Petr.
>>>>
>>>> On 04 ???? 2014 ?., at 17:10, alexander stepanov <alexander.v.stepanov at oracle.com> wrote:
>>>>
>>>>> Sorry, just a reminder.
>>>>>
>>>>> Regards,
>>>>> Alexander
>>>>>
>>>>> On 09.06.2014 14:57, alexander stepanov wrote:
>>>>>> Sorry, just a reminder.
>>>>>>
>>>>>> Thanks,
>>>>>> Alexander
>>>>>>
>>>>>> On 28.05.2014 15:42, alexander stepanov wrote:
>>>>>>> Hello,
>>>>>>>
>>>>>>> Could you please review the fix for the following bug:
>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8043126
>>>>>>>
>>>>>>> Webrev:
>>>>>>> http://cr.openjdk.java.net/~yan/8043126/webrev.00/
>>>>>>>
>>>>>>> This is a set of functional AWT tests prepared for migration to OpenJDK repository.
>>>>>>>
>>>>>>> Some tests were refactored / unified to reduce code duplication. Lightweight component classes should be added as helpers to test base Component functionality.
>>>>>>>
>>>>>>> The tests were checked on Ubuntu 14.04, Solaris 11, Mac OS X 10.8.5 and Windows 7
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Alexander


From alexandr.scherbatiy at oracle.com  Tue Jul  8 15:02:27 2014
From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy)
Date: Tue, 08 Jul 2014 19:02:27 +0400
Subject: <AWT Dev> [OpenJDK 2D-Dev] [9] Review request for 8029339
 Custom MultiResolution image support on HiDPI displays
In-Reply-To: <53987361.5040903@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>
Message-ID: <53BC0803.6090704@oracle.com>



   Hi Phil,

   Could you review the fix?

   Thanks,
   Alexandr.


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 swingler at apple.com  Tue Jul  8 23:38:21 2014
From: swingler at apple.com (Mike Swingler)
Date: Tue, 08 Jul 2014 16:38:21 -0700
Subject: <AWT Dev> [9] Review Request: 8035568 [macosx] Cursor
 management unification.
In-Reply-To: <9F76EFF5-02F6-4205-A120-D7ADAF0D7B66@oracle.com>
References: <9F76EFF5-02F6-4205-A120-D7ADAF0D7B66@oracle.com>
Message-ID: <F7397199-38E4-4815-94C5-49F84F38ED28@apple.com>

> On Jul 8, 2014, at 3:19 AM, Petr Pchelko <petr.pchelko at oracle.com> wrote:
> 
> Hello, AWT Team.
> 
> Please review the fix for the issue:
> https://bugs.openjdk.java.net/browse/JDK-8035568
> The fix is available at:
> http://cr.openjdk.java.net/~pchelko/9/8035568/webrev.00/
> 
> We are using 2 different methods for getting a cursor position in Robot and in LWAWT. I've changed our implementation to use Carbon method.
> nativeGetCursorPosition is a very hot method and changing it's implementation makes it run 35 times faster. Also we will never deadlock on it any more.
> However, I needed to change the isWindowUnderMouse implementation. The problem's that LWWindowPeer.windowUnderCursor is updated on mouse events
> and generated mouse events, so sometimes it may be not updated when called from a component resize handler. Luckily we can test it using native code. 
> isWindowUnderMouse is not a hot method at all, in real apps it's called very rarely (never called after a couple of hours of real IDE usage) so it's not a problem that it
> runs slower now.
> 
> I've run all cursor/mouse tests. A couple of tests failed because they didn't have proper synchronization and we are too fast for them now. I've fixed it and open-sourced the tests.
> 
> With best regards. Petr.

Has this change been tested on Retina? I don't see any effort to convert in and out of the screen coordinate system.

Regards,
Mike Swingler
Apple Inc.


From petr.pchelko at oracle.com  Wed Jul  9 08:49:06 2014
From: petr.pchelko at oracle.com (Petr Pchelko)
Date: Wed, 9 Jul 2014 12:49:06 +0400
Subject: <AWT Dev> [9] Review Request for 8047367: move awt automated
	tests from AWT_Modality to OpenJDK repository - part 2
In-Reply-To: <53BABE29.4040507@oracle.com>
References: <53BABE29.4040507@oracle.com>
Message-ID: <E903EEFA-6935-433A-9819-F60AD9D25C8E@oracle.com>

Hello, Alexander.

The fix looks good to me.

With best regards. Petr.

On 07 ???? 2014 ?., at 19:35, alexander stepanov <alexander.v.stepanov at oracle.com> wrote:

> Hello,
> 
> Could you please review the fix for
> https://bugs.openjdk.java.net/browse/JDK-8047367
> 
> webrev:
> http://cr.openjdk.java.net/~avstepan/8047367/
> 
> This is a set of functional AWT tests prepared for migration to OpenJDK repository.
> 
> The tests were checked on OEL 6, Solaris 11, Mac OS X 10.8.5 and Windows 7. Some of them are failing due to
> https://bugs.openjdk.java.net/browse/JDK-8049339
> https://bugs.openjdk.java.net/browse/JDK-8048263
> 
> Thanks,
> Alexander


From alexander.v.stepanov at oracle.com  Wed Jul  9 08:48:56 2014
From: alexander.v.stepanov at oracle.com (alexander stepanov)
Date: Wed, 09 Jul 2014 12:48:56 +0400
Subject: <AWT Dev> [9] Review Request for 8047367: move awt automated
 tests from AWT_Modality to OpenJDK repository - part 2
In-Reply-To: <E903EEFA-6935-433A-9819-F60AD9D25C8E@oracle.com>
References: <53BABE29.4040507@oracle.com>
	<E903EEFA-6935-433A-9819-F60AD9D25C8E@oracle.com>
Message-ID: <53BD01F8.5040708@oracle.com>

Thanks!

On 09.07.2014 12:49, Petr Pchelko wrote:
> Hello, Alexander.
>
> The fix looks good to me.
>
> With best regards. Petr.
>
> On 07 ???? 2014 ?., at 19:35, alexander stepanov <alexander.v.stepanov at oracle.com> wrote:
>
>> Hello,
>>
>> Could you please review the fix for
>> https://bugs.openjdk.java.net/browse/JDK-8047367
>>
>> webrev:
>> http://cr.openjdk.java.net/~avstepan/8047367/
>>
>> This is a set of functional AWT tests prepared for migration to OpenJDK repository.
>>
>> The tests were checked on OEL 6, Solaris 11, Mac OS X 10.8.5 and Windows 7. Some of them are failing due to
>> https://bugs.openjdk.java.net/browse/JDK-8049339
>> https://bugs.openjdk.java.net/browse/JDK-8048263
>>
>> Thanks,
>> Alexander


From dmitriy.ermashov at oracle.com  Wed Jul  9 09:29:55 2014
From: dmitriy.ermashov at oracle.com (Dmitriy Ermashov)
Date: Wed, 09 Jul 2014 13:29:55 +0400
Subject: <AWT Dev> Review request for 8049694: Migrate functional
 AWT_DesktopProperties/Automated tests to OpenJDK
Message-ID: <53BD0B93.8040505@oracle.com>

Hi all,

Please review yet another batch of tests. To be precise, just one test.
http://cr.openjdk.java.net/~dermashov/8049694/webrev.00/

The corresponding bug:
https://bugs.openjdk.java.net/browse/JDK-8049694

This test verifies old RFE 4758438. It declares that AWT should provide 
an access to XSETTINGS through the Toolkit.
As you can see, the test consist of .java ans .sh files. The reason for 
it is in different utilities for changing xsettings on different OSes. 
E.g. old systems like Ubuntu 8.04 and Solaris 10 use gconftool-2 utilily 
while Ubuntu 14.04 use gsettings.
So the script decides which utility to use on current platform and pass 
the parameters to java programm.

The test passes on the following platforms:
Solaris 10 sparcv9 (Java Desktop System)
Solaris 11 x64 (Gnome 2)
Ubuntu 8.04 virtualbox (Gnome 2)
Ubuntu 10.04 arm (Gnome 2)
Ubuntu 14.04 x64 (Unity)

Windows 7 x64 (test just exit with 0 code)
OS X 10.9 (test just exit with 0 code)

-- 
Thanks,
Dima


From petr.pchelko at oracle.com  Thu Jul 10 07:26:49 2014
From: petr.pchelko at oracle.com (Petr Pchelko)
Date: Thu, 10 Jul 2014 11:26:49 +0400
Subject: <AWT Dev> [9] Review Request: 8049830 Remove reflection from
	ScreenMenuBar
Message-ID: <6F7B0C9E-07A4-4CA7-BD9C-A4C0FC875764@oracle.com>

Hello, AWT Team.

Please review a simple cleanup:
https://bugs.openjdk.java.net/browse/JDK-8049830
The fix is available here:
http://cr.openjdk.java.net/~pchelko/9/8049830/webrev.00/

Just replacing nasty reflection with proper Accessor pattern.

With best regards. Petr.

From anthony.petrov at oracle.com  Thu Jul 10 08:50:21 2014
From: anthony.petrov at oracle.com (Anthony Petrov)
Date: Thu, 10 Jul 2014 12:50:21 +0400
Subject: <AWT Dev> [9] Review Request: 8049830 Remove reflection from
	ScreenMenuBar
In-Reply-To: <6F7B0C9E-07A4-4CA7-BD9C-A4C0FC875764@oracle.com>
References: <6F7B0C9E-07A4-4CA7-BD9C-A4C0FC875764@oracle.com>
Message-ID: <53BE53CD.5070007@oracle.com>

+1

--
best regards,
Anthony

On 7/10/2014 11:26 AM, Petr Pchelko wrote:
> Hello, AWT Team.
>
> Please review a simple cleanup:
> https://bugs.openjdk.java.net/browse/JDK-8049830
> The fix is available here:
> http://cr.openjdk.java.net/~pchelko/9/8049830/webrev.00/
>
> Just replacing nasty reflection with proper Accessor pattern.
>
> With best regards. Petr.
>

From Sergey.Bylokhov at oracle.com  Thu Jul 10 09:30:20 2014
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Thu, 10 Jul 2014 13:30:20 +0400
Subject: <AWT Dev> [9] Review Request: 8049830 Remove reflection from
	ScreenMenuBar
In-Reply-To: <53BE53CD.5070007@oracle.com>
References: <6F7B0C9E-07A4-4CA7-BD9C-A4C0FC875764@oracle.com>
	<53BE53CD.5070007@oracle.com>
Message-ID: <53BE5D2C.8090008@oracle.com>

Hi, Petr.
The fix looks good.

On 10.07.2014 12:50, Anthony Petrov wrote:
> +1
>
> -- 
> best regards,
> Anthony
>
> On 7/10/2014 11:26 AM, Petr Pchelko wrote:
>> Hello, AWT Team.
>>
>> Please review a simple cleanup:
>> https://bugs.openjdk.java.net/browse/JDK-8049830
>> The fix is available here:
>> http://cr.openjdk.java.net/~pchelko/9/8049830/webrev.00/
>>
>> Just replacing nasty reflection with proper Accessor pattern.
>>
>> With best regards. Petr.
>>


-- 
Best regards, Sergey.


From alexandr.scherbatiy at oracle.com  Thu Jul 10 12:42:32 2014
From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy)
Date: Thu, 10 Jul 2014 16:42:32 +0400
Subject: <AWT Dev> [9] Review request for 8049198 [macosx] Incorrect thread
 access when showing splash screen
Message-ID: <53BE8A38.6070003@oracle.com>


Hello,

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

  NSScreen call is moved to perform on the main thread.

Thanks,
Alexandr.


From petr.pchelko at oracle.com  Thu Jul 10 12:49:24 2014
From: petr.pchelko at oracle.com (Petr Pchelko)
Date: Thu, 10 Jul 2014 16:49:24 +0400
Subject: <AWT Dev> [9] Review request for 8049198 [macosx] Incorrect
	thread access when showing splash screen
In-Reply-To: <53BE8A38.6070003@oracle.com>
References: <53BE8A38.6070003@oracle.com>
Message-ID: <C97238C6-C013-4301-8510-2D53A45E05D7@oracle.com>

Hello, Alexander.

Please use ThreadUtilities instead of the JNFRunLoop. 

With best regards. Petr.

On 10 ???? 2014 ?., at 16:42, Alexander Scherbatiy <alexandr.scherbatiy at oracle.com> wrote:

> 
> Hello,
> 
> Could you review the fix:
>  bug: https://bugs.openjdk.java.net/browse/JDK-8049198
>  webrev: http://cr.openjdk.java.net/~alexsch/8049198/webrev.00
> 
> NSScreen call is moved to perform on the main thread.
> 
> Thanks,
> Alexandr.
> 


From petr.pchelko at oracle.com  Thu Jul 10 13:02:53 2014
From: petr.pchelko at oracle.com (Petr Pchelko)
Date: Thu, 10 Jul 2014 17:02:53 +0400
Subject: <AWT Dev> [9] Review Request: 8032864 [macosx] sigsegv (0Xb) Being
	Generated When Starting JDev With Voiceover Running
Message-ID: <2EF15C2B-3C4B-4A72-97AE-8841C7A5A04C@oracle.com>

Hello, AWT team.

Please review a small fix for the issue:
https://bugs.openjdk.java.net/browse/JDK-8032864
The fix is available at:
http://cr.openjdk.java.net/~pchelko/9/8032864/webrev.01/

I failed to create a general fix for the core problem, so I've made a point fix for this bug. The problem is that CAccessible.getFocusOwner opens a nested loop and goes to EDT. 
This leads to some unknown reordering of selectors, and we crash. retain/releasing the window around the call to getFocusOwner fixes this particular bug. 
I've trued to make a minimal fix as it needs to be backported to 8 and 7. I've checked for memory leaks using Instruments.

With best regards. Petr.

From alexandr.scherbatiy at oracle.com  Thu Jul 10 13:11:41 2014
From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy)
Date: Thu, 10 Jul 2014 17:11:41 +0400
Subject: <AWT Dev> [9] Review request for 8049198 [macosx] Incorrect
 thread access when showing splash screen
In-Reply-To: <C97238C6-C013-4301-8510-2D53A45E05D7@oracle.com>
References: <53BE8A38.6070003@oracle.com>
	<C97238C6-C013-4301-8510-2D53A45E05D7@oracle.com>
Message-ID: <53BE910D.5060306@oracle.com>


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

      ThreadUtilities  is used instead of JNFRunLoop.

     Thanks,
     Alexandr.

On 7/10/2014 4:49 PM, Petr Pchelko wrote:
> Hello, Alexander.
>
> Please use ThreadUtilities instead of the JNFRunLoop.
>
> With best regards. Petr.
>
> On 10 ???? 2014 ?., at 16:42, Alexander Scherbatiy <alexandr.scherbatiy at oracle.com> wrote:
>
>> Hello,
>>
>> Could you review the fix:
>>   bug: https://bugs.openjdk.java.net/browse/JDK-8049198
>>   webrev: http://cr.openjdk.java.net/~alexsch/8049198/webrev.00
>>
>> NSScreen call is moved to perform on the main thread.
>>
>> Thanks,
>> Alexandr.
>>


From petr.pchelko at oracle.com  Thu Jul 10 13:16:21 2014
From: petr.pchelko at oracle.com (Petr Pchelko)
Date: Thu, 10 Jul 2014 17:16:21 +0400
Subject: <AWT Dev> [9] Review request for 8049198 [macosx] Incorrect
	thread access when showing splash screen
In-Reply-To: <53BE910D.5060306@oracle.com>
References: <53BE8A38.6070003@oracle.com>
	<C97238C6-C013-4301-8510-2D53A45E05D7@oracle.com>
	<53BE910D.5060306@oracle.com>
Message-ID: <DB91174B-CEA6-4DF8-B7FA-933FFE9EBC5B@oracle.com>

Hello, Alexander.

The fix looks good.

With best regards. Petr.

On 10 ???? 2014 ?., at 17:11, Alexander Scherbatiy <alexandr.scherbatiy at oracle.com> wrote:

> 
>  Could you review the updated fix:
>    http://cr.openjdk.java.net/~alexsch/8049198/webrev.01
> 
>     ThreadUtilities  is used instead of JNFRunLoop.
> 
>    Thanks,
>    Alexandr.
> 
> On 7/10/2014 4:49 PM, Petr Pchelko wrote:
>> Hello, Alexander.
>> 
>> Please use ThreadUtilities instead of the JNFRunLoop.
>> 
>> With best regards. Petr.
>> 
>> On 10 ???? 2014 ?., at 16:42, Alexander Scherbatiy <alexandr.scherbatiy at oracle.com> wrote:
>> 
>>> Hello,
>>> 
>>> Could you review the fix:
>>>  bug: https://bugs.openjdk.java.net/browse/JDK-8049198
>>>  webrev: http://cr.openjdk.java.net/~alexsch/8049198/webrev.00
>>> 
>>> NSScreen call is moved to perform on the main thread.
>>> 
>>> Thanks,
>>> Alexandr.
>>> 
> 


From Sergey.Bylokhov at oracle.com  Thu Jul 10 14:11:56 2014
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Thu, 10 Jul 2014 18:11:56 +0400
Subject: <AWT Dev> [9] Review Request: 8049583 Test
 closed/java/awt/List/ListMultipleSelectTest/ListMultipleSelectTest fails on
 Window XP
Message-ID: <53BE9F2C.9010809@oracle.com>

Hello.
Please review the fix for jdk 9.
The bug reproduced on xp only, regression of JDK-8035739 
<https://bugs.openjdk.java.net/browse/JDK-8035739>
Description:
void * is 4 bytes
jboolean is 1 byte.

Before the fix we cast to jboolean after the fix not[1]. On XP part of 
the return value is not zeroed. So false became true.
All places where we use  JNI_IS_TRUE and SysCall were reverted.

[1] http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/5d22ffb8b826
Bug: https://bugs.openjdk.java.net/browse/JDK-8049583
Webrev can be found at: http://cr.openjdk.java.net/~serb/8049583/webrev.00

-- 
Best regards, Sergey.

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

From petr.pchelko at oracle.com  Thu Jul 10 14:16:05 2014
From: petr.pchelko at oracle.com (Petr Pchelko)
Date: Thu, 10 Jul 2014 18:16:05 +0400
Subject: <AWT Dev> [9] Review Request: 8049583 Test
	closed/java/awt/List/ListMultipleSelectTest/ListMultipleSelectTest
	fails on Window XP
In-Reply-To: <53BE9F2C.9010809@oracle.com>
References: <53BE9F2C.9010809@oracle.com>
Message-ID: <CF299B5C-4320-42DC-9800-E15CA3548460@oracle.com>

Hello, Sergey.

The fix looks good to me. 
I assume that you will file a separate bug for returning parfait problems.

With best regards. Petr.


On 10 ???? 2014 ?., at 18:11, Sergey Bylokhov <Sergey.Bylokhov at oracle.com> wrote:

> Hello.
> Please review the fix for jdk 9. 
> The bug reproduced on xp only, regression of JDK-8035739
> Description:
> void * is 4 bytes
> jboolean is 1 byte.
> 
> Before the fix we cast to jboolean after the fix not[1]. On XP part of the return value is not zeroed. So false became true.
> All places where we use  JNI_IS_TRUE and SysCall were reverted.
> 
> [1] http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/5d22ffb8b826
> Bug: https://bugs.openjdk.java.net/browse/JDK-8049583
> Webrev can be found at: http://cr.openjdk.java.net/~serb/8049583/webrev.00
> -- 
> Best regards, Sergey. 

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

From Sergey.Bylokhov at oracle.com  Thu Jul 10 14:35:32 2014
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Thu, 10 Jul 2014 18:35:32 +0400
Subject: <AWT Dev> [9] Review request for 8049198 [macosx] Incorrect
 thread access when showing splash screen
In-Reply-To: <53BE910D.5060306@oracle.com>
References: <53BE8A38.6070003@oracle.com>
	<C97238C6-C013-4301-8510-2D53A45E05D7@oracle.com>
	<53BE910D.5060306@oracle.com>
Message-ID: <53BEA4B4.6060807@oracle.com>

Hi, Alexander.
The fix looks good.

On 10.07.2014 17:11, Alexander Scherbatiy wrote:
>
>   Could you review the updated fix:
>     http://cr.openjdk.java.net/~alexsch/8049198/webrev.01
>
>      ThreadUtilities  is used instead of JNFRunLoop.
>
>     Thanks,
>     Alexandr.
>
> On 7/10/2014 4:49 PM, Petr Pchelko wrote:
>> Hello, Alexander.
>>
>> Please use ThreadUtilities instead of the JNFRunLoop.
>>
>> With best regards. Petr.
>>
>> On 10 ???? 2014 ?., at 16:42, Alexander Scherbatiy 
>> <alexandr.scherbatiy at oracle.com> wrote:
>>
>>> Hello,
>>>
>>> Could you review the fix:
>>>   bug: https://bugs.openjdk.java.net/browse/JDK-8049198
>>>   webrev: http://cr.openjdk.java.net/~alexsch/8049198/webrev.00
>>>
>>> NSScreen call is moved to perform on the main thread.
>>>
>>> Thanks,
>>> Alexandr.
>>>
>


-- 
Best regards, Sergey.


From alexey.ivanov at oracle.com  Thu Jul 10 15:59:41 2014
From: alexey.ivanov at oracle.com (Alexey Ivanov)
Date: Thu, 10 Jul 2014 19:59:41 +0400
Subject: <AWT Dev> <Swing Dev> [7u-dev] Review request for JDK-8046559: NPE
 when changing Windows theme
Message-ID: <53BEB86D.3080908@oracle.com>

Hi AWT, Swing teams,

Could you please review the backport of JDK-8046559 to jdk7:
     bug: https://bugs.openjdk.java.net/browse/JDK-8046559
     webrev: http://cr.openjdk.java.net/~aivanov/8046559/jdk7/webrev.00/


Changes between jdk9 and jdk7:

I replaced labmda expression in WToolkit.java with anonymous class.
It is the only change from the previous webrev:
http://mail.openjdk.java.net/pipermail/awt-dev/2014-July/008147.html
http://mail.openjdk.java.net/pipermail/swing-dev/2014-July/003657.html


Latest jdk9 webrev: 
http://cr.openjdk.java.net/~aivanov/8046559/jdk9/webrev.01/


The information is below is copied from jdk9 review for the sake of 
completeness.


Problem description:
When changing Windows themes from a theme with visual styles (Windows 
Aero or Windows Basic) to a classic one, NullPointerException could be 
thrown from Swing code during component tree validation, or 
InternalError could be thrown during component painting.

Root cause:
Windows theme data are accessed via XPStyle and ThemeReader. When the 
theme is switched to a classic one, theme handles become unavailable, 
and theme data cannot be accessed any more. The change in theme is 
posted to EDT; at the same time, the UI often needs to repaint before 
the theme change is completely handled in Swing. This leads to NPE and 
InternalError as the code tries to access the data that has become 
unavailable.

The fix:
Windows desktop properties are updated right on Windows Toolkit thread, 
and the value of "win.xpstyle.themeActive" is stored in 
ThemeReader.xpStyleEnabled field. PropertyChangeEvents for desktop 
properties are delivered either synchronously on EDT or asynchronously 
via DesktopPropertyChangeSupport, as it used to be.

Getters in XPStyle class check for null values and return dummy defaults 
if ThemeReader returned null. SkinPainters also check whether theming is 
still available before asking ThemeReader to paint.

Access to XPStyle.xp instance is blocked as soon as user switches 
themes. The object will be cleaned when the corresponding 
PropertyChangeEvent is handled by Swing.


This new version of the fix addresses issues found with the initial 
submission of JDK-8039383 fix:
   - JDK-8046239: Build failure in 9-client on all non-Windows platforms
   - JDK-8046391: Hang displaying JFileChooser with Windows L&F

See also 
http://mail.openjdk.java.net/pipermail/awt-dev/2014-June/007975.html
and http://cr.openjdk.java.net/~aivanov/8039383/jdk9/webrev.03/


Regression test:
No regression test is provided due to its complexity. Whether 
NullPointerException or InternalError are thrown depends on the order of 
event handling, sometimes exceptions do not occur when changing theme of 
visual styles enabled theme to a classic theme.

I included regression test for hang in JFileChooser, JDK-8046391.


Thank you,
Alexey.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20140710/ada1e43d/attachment-0001.html>

From anthony.petrov at oracle.com  Thu Jul 10 20:30:10 2014
From: anthony.petrov at oracle.com (Anthony Petrov)
Date: Fri, 11 Jul 2014 00:30:10 +0400
Subject: <AWT Dev> [9] Review Request: 8049583 Test
 closed/java/awt/List/ListMultipleSelectTest/ListMultipleSelectTest fails on
 Window XP
In-Reply-To: <53BE9F2C.9010809@oracle.com>
References: <53BE9F2C.9010809@oracle.com>
Message-ID: <53BEF7D2.7030206@oracle.com>

Hi Sergey,

I agree if this change goes to 8u as the least risky thing we can do now.

For 9 I'd prefer to fix the root cause of the problem, which is related 
to the wrong cast of e.g. AwtList::_IsSelected from (jboolean 
(*)(void*)) to (void *(*)(void *)) - we simply should have never 
performed such a type cast because it's wrong.

Alternatively, we could push your fix to 9 now so as to enable its 
back-porting, and then file a new bug against 9 to fix this issue 
properly. If you choose this way, please provide us with the new bug id 
and consider the current fix approved then.

--
best regards,
Anthony

On 7/10/2014 6:11 PM, Sergey Bylokhov wrote:
> Hello.
> Please review the fix for jdk 9.
> The bug reproduced on xp only, regression of JDK-8035739
> <https://bugs.openjdk.java.net/browse/JDK-8035739>
> Description:
> void * is 4 bytes
> jboolean is 1 byte.
>
> Before the fix we cast to jboolean after the fix not[1]. On XP part of
> the return value is not zeroed. So false became true.
> All places where we use  JNI_IS_TRUE and SysCall were reverted.
>
> [1] http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/5d22ffb8b826
> Bug: https://bugs.openjdk.java.net/browse/JDK-8049583
> Webrev can be found at: http://cr.openjdk.java.net/~serb/8049583/webrev.00
>
> --
> Best regards, Sergey.
>

From anthony.petrov at oracle.com  Thu Jul 10 21:43:05 2014
From: anthony.petrov at oracle.com (Anthony Petrov)
Date: Fri, 11 Jul 2014 01:43:05 +0400
Subject: <AWT Dev> <Swing Dev> [7u-dev] Review request for JDK-8046559:
 NPE when changing Windows theme
In-Reply-To: <53BEB86D.3080908@oracle.com>
References: <53BEB86D.3080908@oracle.com>
Message-ID: <53BF08E9.5090003@oracle.com>

Hi Alexey,

I skimmed through the changes and they look fine to me. +1.

--
best regards,
Anthony

On 7/10/2014 7:59 PM, Alexey Ivanov wrote:
> Hi AWT, Swing teams,
>
> Could you please review the backport of JDK-8046559 to jdk7:
>      bug: https://bugs.openjdk.java.net/browse/JDK-8046559
>      webrev: http://cr.openjdk.java.net/~aivanov/8046559/jdk7/webrev.00/
>
>
> Changes between jdk9 and jdk7:
>
> I replaced labmda expression in WToolkit.java with anonymous class.
> It is the only change from the previous webrev:
> http://mail.openjdk.java.net/pipermail/awt-dev/2014-July/008147.html
> http://mail.openjdk.java.net/pipermail/swing-dev/2014-July/003657.html
>
>
> Latest jdk9 webrev:
> http://cr.openjdk.java.net/~aivanov/8046559/jdk9/webrev.01/
>
>
> The information is below is copied from jdk9 review for the sake of
> completeness.
>
>
> Problem description:
> When changing Windows themes from a theme with visual styles (Windows
> Aero or Windows Basic) to a classic one, NullPointerException could be
> thrown from Swing code during component tree validation, or
> InternalError could be thrown during component painting.
>
> Root cause:
> Windows theme data are accessed via XPStyle and ThemeReader. When the
> theme is switched to a classic one, theme handles become unavailable,
> and theme data cannot be accessed any more. The change in theme is
> posted to EDT; at the same time, the UI often needs to repaint before
> the theme change is completely handled in Swing. This leads to NPE and
> InternalError as the code tries to access the data that has become
> unavailable.
>
> The fix:
> Windows desktop properties are updated right on Windows Toolkit thread,
> and the value of "win.xpstyle.themeActive" is stored in
> ThemeReader.xpStyleEnabled field. PropertyChangeEvents for desktop
> properties are delivered either synchronously on EDT or asynchronously
> via DesktopPropertyChangeSupport, as it used to be.
>
> Getters in XPStyle class check for null values and return dummy defaults
> if ThemeReader returned null. SkinPainters also check whether theming is
> still available before asking ThemeReader to paint.
>
> Access to XPStyle.xp instance is blocked as soon as user switches
> themes. The object will be cleaned when the corresponding
> PropertyChangeEvent is handled by Swing.
>
>
> This new version of the fix addresses issues found with the initial
> submission of JDK-8039383 fix:
>    - JDK-8046239: Build failure in 9-client on all non-Windows platforms
>    - JDK-8046391: Hang displaying JFileChooser with Windows L&F
>
> See also
> http://mail.openjdk.java.net/pipermail/awt-dev/2014-June/007975.html
> and http://cr.openjdk.java.net/~aivanov/8039383/jdk9/webrev.03/
>
>
> Regression test:
> No regression test is provided due to its complexity. Whether
> NullPointerException or InternalError are thrown depends on the order of
> event handling, sometimes exceptions do not occur when changing theme of
> visual styles enabled theme to a classic theme.
>
> I included regression test for hang in JFileChooser, JDK-8046391.
>
>
> Thank you,
> Alexey.

From anthony.petrov at oracle.com  Thu Jul 10 21:59:43 2014
From: anthony.petrov at oracle.com (Anthony Petrov)
Date: Fri, 11 Jul 2014 01:59:43 +0400
Subject: <AWT Dev> [9] Review Request: 8032864 [macosx] sigsegv (0Xb)
 Being Generated When Starting JDev With Voiceover Running
In-Reply-To: <2EF15C2B-3C4B-4A72-97AE-8841C7A5A04C@oracle.com>
References: <2EF15C2B-3C4B-4A72-97AE-8841C7A5A04C@oracle.com>
Message-ID: <53BF0CCF.7020405@oracle.com>

Hi Petr,

I'm fine with the targeted fix. We often do a similar thing in JavaFX 
when processing various events, so the approach is proven to work good.

However, generally I agree with your comment from the bug report about 
the necessity to process dispose selectors in the outer event loop only. 
IIRC, we do something similar in the WToolkit native implementation. So 
I suggest to file a separate medium priority bug to investigate this 
further for JDK 9 (or tbd-major).

--
best regards,
Anthony

On 7/10/2014 5:02 PM, Petr Pchelko wrote:
> Hello, AWT team.
>
> Please review a small fix for the issue:
> https://bugs.openjdk.java.net/browse/JDK-8032864
> The fix is available at:
> http://cr.openjdk.java.net/~pchelko/9/8032864/webrev.01/
>
> I failed to create a general fix for the core problem, so I've made a point fix for this bug. The problem is that CAccessible.getFocusOwner opens a nested loop and goes to EDT.
> This leads to some unknown reordering of selectors, and we crash. retain/releasing the window around the call to getFocusOwner fixes this particular bug.
> I've trued to make a minimal fix as it needs to be backported to 8 and 7. I've checked for memory leaks using Instruments.
>
> With best regards. Petr.
>

From petr.pchelko at oracle.com  Fri Jul 11 05:47:49 2014
From: petr.pchelko at oracle.com (Petr Pchelko)
Date: Fri, 11 Jul 2014 09:47:49 +0400
Subject: <AWT Dev> <Swing Dev> [7u-dev] Review request for JDK-8046559:
	NPE when changing Windows theme
In-Reply-To: <53BF08E9.5090003@oracle.com>
References: <53BEB86D.3080908@oracle.com> <53BF08E9.5090003@oracle.com>
Message-ID: <792FFA70-C541-4BC9-8A75-E97EF16916B2@oracle.com>

Hello, Alexey.

Looks OK to me too.

With best regards. Petr.

> On Jul 11, 2014, at 1:43 AM, Anthony Petrov <anthony.petrov at oracle.com> wrote:
> 
> Hi Alexey,
> 
> I skimmed through the changes and they look fine to me. +1.
> 
> --
> best regards,
> Anthony
> 
> On 7/10/2014 7:59 PM, Alexey Ivanov wrote:
>> Hi AWT, Swing teams,
>> 
>> Could you please review the backport of JDK-8046559 to jdk7:
>>     bug: https://bugs.openjdk.java.net/browse/JDK-8046559
>>     webrev: http://cr.openjdk.java.net/~aivanov/8046559/jdk7/webrev.00/
>> 
>> 
>> Changes between jdk9 and jdk7:
>> 
>> I replaced labmda expression in WToolkit.java with anonymous class.
>> It is the only change from the previous webrev:
>> http://mail.openjdk.java.net/pipermail/awt-dev/2014-July/008147.html
>> http://mail.openjdk.java.net/pipermail/swing-dev/2014-July/003657.html
>> 
>> 
>> Latest jdk9 webrev:
>> http://cr.openjdk.java.net/~aivanov/8046559/jdk9/webrev.01/
>> 
>> 
>> The information is below is copied from jdk9 review for the sake of
>> completeness.
>> 
>> 
>> Problem description:
>> When changing Windows themes from a theme with visual styles (Windows
>> Aero or Windows Basic) to a classic one, NullPointerException could be
>> thrown from Swing code during component tree validation, or
>> InternalError could be thrown during component painting.
>> 
>> Root cause:
>> Windows theme data are accessed via XPStyle and ThemeReader. When the
>> theme is switched to a classic one, theme handles become unavailable,
>> and theme data cannot be accessed any more. The change in theme is
>> posted to EDT; at the same time, the UI often needs to repaint before
>> the theme change is completely handled in Swing. This leads to NPE and
>> InternalError as the code tries to access the data that has become
>> unavailable.
>> 
>> The fix:
>> Windows desktop properties are updated right on Windows Toolkit thread,
>> and the value of "win.xpstyle.themeActive" is stored in
>> ThemeReader.xpStyleEnabled field. PropertyChangeEvents for desktop
>> properties are delivered either synchronously on EDT or asynchronously
>> via DesktopPropertyChangeSupport, as it used to be.
>> 
>> Getters in XPStyle class check for null values and return dummy defaults
>> if ThemeReader returned null. SkinPainters also check whether theming is
>> still available before asking ThemeReader to paint.
>> 
>> Access to XPStyle.xp instance is blocked as soon as user switches
>> themes. The object will be cleaned when the corresponding
>> PropertyChangeEvent is handled by Swing.
>> 
>> 
>> This new version of the fix addresses issues found with the initial
>> submission of JDK-8039383 fix:
>>   - JDK-8046239: Build failure in 9-client on all non-Windows platforms
>>   - JDK-8046391: Hang displaying JFileChooser with Windows L&F
>> 
>> See also
>> http://mail.openjdk.java.net/pipermail/awt-dev/2014-June/007975.html
>> and http://cr.openjdk.java.net/~aivanov/8039383/jdk9/webrev.03/
>> 
>> 
>> Regression test:
>> No regression test is provided due to its complexity. Whether
>> NullPointerException or InternalError are thrown depends on the order of
>> event handling, sometimes exceptions do not occur when changing theme of
>> visual styles enabled theme to a classic theme.
>> 
>> I included regression test for hang in JFileChooser, JDK-8046391.
>> 
>> 
>> Thank you,
>> Alexey.


From anthony.petrov at oracle.com  Fri Jul 11 11:15:42 2014
From: anthony.petrov at oracle.com (Anthony Petrov)
Date: Fri, 11 Jul 2014 15:15:42 +0400
Subject: <AWT Dev> [9] Review Request: 8035568 [macosx] Cursor
	management unification.
In-Reply-To: <9F76EFF5-02F6-4205-A120-D7ADAF0D7B66@oracle.com>
References: <9F76EFF5-02F6-4205-A120-D7ADAF0D7B66@oracle.com>
Message-ID: <53BFC75E.80906@oracle.com>

Hi Petr,

The fix looks good to me overall. A few comments:

1. src/macosx/classes/sun/lwawt/LWMouseInfoPeer.java
>   55         // Most likely the cached window under cursor is correct and we do not need the native check.

Perhaps instead it would make sense to describe here when the first 
condition may fail and the native check could actually become useful? 
Otherwise the current comment doesn't add much value to understanding 
the code.


2. src/macosx/native/sun/awt/AWTWindow.m
> -    AWT_ASSERT_APPKIT_THREAD;
>
> +    [ThreadUtilities performOnMainThreadWaiting:YES block:^{

This looks okay. But I'm wondering whether this could cause any dead 
locks potentially? I'd suggest to run other tests that may involve 
(maybe indirectly) calling the nativeGetTopmostPlatformWindowUnderMouse 
method (grab/ungrab? focus? modal dialogs? tooltips/popups? maybe 
something else).


3. src/macosx/native/sun/awt/CCursorManager.m
> -    [ThreadUtilities performOnMainThreadWaiting:YES block:^(){

Is it OK to call Core Graphics functions on a thread other than the main 
thread?

--
best regards,
Anthony

On 7/8/2014 2:19 PM, Petr Pchelko wrote:
> Hello, AWT Team.
>
> Please review the fix for the issue:
> https://bugs.openjdk.java.net/browse/JDK-8035568
> The fix is available at:
> http://cr.openjdk.java.net/~pchelko/9/8035568/webrev.00/
>
> We are using 2 different methods for getting a cursor position in Robot and in LWAWT. I've changed our implementation to use Carbon method.
> nativeGetCursorPosition is a very hot method and changing it's implementation makes it run 35 times faster. Also we will never deadlock on it any more.
> However, I needed to change the isWindowUnderMouse implementation. The problem's that LWWindowPeer.windowUnderCursor is updated on mouse events
> and generated mouse events, so sometimes it may be not updated when called from a component resize handler. Luckily we can test it using native code.
> isWindowUnderMouse is not a hot method at all, in real apps it's called very rarely (never called after a couple of hours of real IDE usage) so it's not a problem that it
> runs slower now.
>
> I've run all cursor/mouse tests. A couple of tests failed because they didn't have proper synchronization and we are too fast for them now. I've fixed it and open-sourced the tests.
>
> With best regards. Petr.
>

From petr.pchelko at oracle.com  Fri Jul 11 11:50:03 2014
From: petr.pchelko at oracle.com (Petr Pchelko)
Date: Fri, 11 Jul 2014 15:50:03 +0400
Subject: <AWT Dev> [9] Review Request: 8049998 [macosx] test
	java/awt/image/ImageIconHang.java fails with NPE
Message-ID: <052FCD09-E0B5-4169-ACA0-5E4F7CBB2D0D@oracle.com>

Hello, AWT Team.

Please review a little fix for the issue:
https://bugs.openjdk.java.net/browse/JDK-8049998
The fix is available at:
http://cr.openjdk.java.net/~pchelko/9/8049998/webrev/

It?s a one-liner adding a missed null check.

With best regards. Petr.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20140711/0226b3bb/attachment.html>

From alexander.zvegintsev at oracle.com  Fri Jul 11 12:40:11 2014
From: alexander.zvegintsev at oracle.com (Alexander Zvegintsev)
Date: Fri, 11 Jul 2014 16:40:11 +0400
Subject: <AWT Dev> [9] Review Request: 8049998 [macosx] test
 java/awt/image/ImageIconHang.java fails with NPE
In-Reply-To: <052FCD09-E0B5-4169-ACA0-5E4F7CBB2D0D@oracle.com>
References: <052FCD09-E0B5-4169-ACA0-5E4F7CBB2D0D@oracle.com>
Message-ID: <53BFDB2B.9020209@oracle.com>

Hello Petr,

the fix looks good.

BTW since you are touching this file maybe we can fix a typo at :547 
within this CR ( fileneame2x -> filename2x )

Thanks,

Alexander.

On 07/11/2014 03:50 PM, Petr Pchelko wrote:
> Hello, AWT Team.
>
> Please review a little fix for the issue:
> https://bugs.openjdk.java.net/browse/JDK-8049998
> The fix is available at:
> http://cr.openjdk.java.net/~pchelko/9/8049998/webrev/ 
> <http://cr.openjdk.java.net/%7Epchelko/9/8049998/webrev/>
>
> It?s a one-liner adding a missed null check.
>
> With best regards. Petr.

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

From alexandr.scherbatiy at oracle.com  Fri Jul 11 12:59:50 2014
From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy)
Date: Fri, 11 Jul 2014 16:59:50 +0400
Subject: <AWT Dev> [9] Review Request: 8049998 [macosx] test
 java/awt/image/ImageIconHang.java fails with NPE
In-Reply-To: <052FCD09-E0B5-4169-ACA0-5E4F7CBB2D0D@oracle.com>
References: <052FCD09-E0B5-4169-ACA0-5E4F7CBB2D0D@oracle.com>
Message-ID: <53BFDFC6.4040406@oracle.com>


   The fix looks good.

   Thanks,
   Alexandr.

On 7/11/2014 3:50 PM, Petr Pchelko wrote:
> Hello, AWT Team.
>
> Please review a little fix for the issue:
> https://bugs.openjdk.java.net/browse/JDK-8049998
> The fix is available at:
> http://cr.openjdk.java.net/~pchelko/9/8049998/webrev/ 
> <http://cr.openjdk.java.net/%7Epchelko/9/8049998/webrev/>
>
> It?s a one-liner adding a missed null check.
>
> With best regards. Petr.


From petr.pchelko at oracle.com  Mon Jul 14 14:23:55 2014
From: petr.pchelko at oracle.com (Petr Pchelko)
Date: Mon, 14 Jul 2014 18:23:55 +0400
Subject: <AWT Dev> [9] Review Request: 8047336 Read flavormap.properties
	as resource
In-Reply-To: <94D52B7E-BE8F-4BD8-A825-8D8328FBD34B@oracle.com>
References: <59786637-036B-49C3-AB92-0D5742C87AC2@oracle.com>	<53A2D3DA.4030503@oracle.com>	<B543154A-7C00-4024-9478-6D615E828190@oracle.com>	<53A418B9.6080500@oracle.com>
	<53A41B16.9020404@oracle.com>	<18DA96EE-B90D-4BAD-8990-6D4972446019@oracle.com>	<53A41FF2.8050705@oracle.com>	<977775FE-2CE5-4223-89CC-88F0339CD420@oracle.com>	<53B3D65B.7000500@oracle.com>
	<0427C75B-FF62-4E86-818D-924AF164D8AC@oracle.com>
	<53B3E944.30501@oracle.com>
	<151706C7-4488-405C-92DE-E0A41019A416@oracle.com>
	<94D52B7E-BE8F-4BD8-A825-8D8328FBD34B@oracle.com>
Message-ID: <A1759330-DDD1-495D-AD35-9A4D06B8478C@oracle.com>

Hello, AWT Team.

My apologies, but I've found a problem in the AWT part of this fix and so I need one more review iteration.

The new version is located here: http://cr.openjdk.java.net/~pchelko/9/8047336/webrev.02/
The only changes comparing to the previous approved version are in SystemFlavorMap.

I've realized that we cannot use Properties to load the flavormap.properties file because Properties doesn't preserve the original order of keys. 
And it's important, because natives that are found in the file first are treated as more important than natives in the end of the file. 
So I've implemented a custom parser for the properties file (see lines 233-243)

Thank you.
With best regards. Petr.

On 10 ???? 2014 ?., at 20:22, Mike Duigou <mike.duigou at oracle.com> wrote:

> The makefile changes look fine to me. (The use of OPENJDK as part of the variable names seems excessive but that's not something your patch adds or changes)
> 
> Mike
> 
> On Jul 9 2014, at 23:55 , Petr Pchelko <petr.pchelko at oracle.com> wrote:
> 
>> Hello, Build Team.
>> 
>> This is a reminder. Could you please review the build part of the following fix:
>> http://cr.openjdk.java.net/~pchelko/9/8047336/webrev.01/
>> 
>> Thank you.
>> With best regards. Petr.
>> 
>> On 02 ???? 2014 ?., at 15:13, Anthony Petrov <anthony.petrov at oracle.com> wrote:
>> 
>>> Thanks. Note that your email editor messed up the HTML part of the email (see below a text-only quote), so here's the correct link to the webrev:
>>> 
>>> http://cr.openjdk.java.net/~pchelko/9/8047336/webrev.01/
>>> 
>>> The fix looks fine to me.
>>> 
>>> --
>>> best regards,
>>> Anthony
>>> 
>>> On 7/2/2014 3:10 PM, Petr Pchelko wrote:
>>>> Hello, Anthony, Alan.
>>>> 
>>>> Thank you for the review, the new version is located here:
>>>> http://cr.openjdk.java.net/~pchelko/9/8047336/webrev.01/
>>>> <http://cr.openjdk.java.net/%7Epchelko/9/8047336/webrev.00/>
>>>> 
>>>> I've changed the code to throw an InternalError if we cannot read
>>>> properties.
>>>> Once I get feedback from the build team - I'll push this fix.
>>>> 
>>>> With best regards. Petr.
>>>> 
>>>> On 02 ???? 2014 ?., at 13:52, Alan Bateman <Alan.Bateman at oracle.com
>>>> <mailto:Alan.Bateman at oracle.com>> wrote:
>>>> 
>>>>> On 01/07/2014 09:35, Petr Pchelko wrote:
>>>>>> Hello,
>>>>>> 
>>>>>> The changes in the public API have been approved, so let me continue
>>>>>> the review process.
>>>>>> 
>>>>>> For your convenience:
>>>>>> The bug: https://bugs.openjdk.java.net/browse/JDK-8047336
>>>>>> The fix: http://cr.openjdk.java.net/~pchelko/9/8047336/webrev.00/
>>>>>> <http://cr.openjdk.java.net/%7Epchelko/9/8047336/webrev.00/>
>>>>>> 
>>>>>> Until now we've been discussing an abstract question of moving the
>>>>>> properties to a different location and agreed that it's possible.
>>>>>> Now it's time for an official code review. Could someone please make one?
>>>>>> 
>>>>>> Also some feedback from the build team is still required. Could
>>>>>> someone from the build team review this fix please?
>>>>>> (The question is that I've made a separate explicit rule for
>>>>>> flavormap.properties file. If I add it to COPY_PATTERNS than the
>>>>>> solaris version get's copied on Mac. Is that a bug in the build
>>>>>> system? Is my current solution good enough?)
>>>>>> 
>>>>> I think this looks okay. I see Anthony's mail asking about the warning
>>>>> message and whether it should the print stack trace. I just wonder if
>>>>> it might be saner to just throw InternalError here. It throws
>>>>> InternalError if flavormap.properties is missing and it might be
>>>>> consistent to do the same when the file is corrupt or can't be parsed
>>>>> as a properties file.
>>>>> 
>>>>> -Alan.
>>>> 
>> 
> 


From anthony.petrov at oracle.com  Mon Jul 14 17:00:43 2014
From: anthony.petrov at oracle.com (Anthony Petrov)
Date: Mon, 14 Jul 2014 21:00:43 +0400
Subject: <AWT Dev> [9] Review Request: 8047336 Read flavormap.properties
 as resource
In-Reply-To: <A1759330-DDD1-495D-AD35-9A4D06B8478C@oracle.com>
References: <59786637-036B-49C3-AB92-0D5742C87AC2@oracle.com>	<53A2D3DA.4030503@oracle.com>	<B543154A-7C00-4024-9478-6D615E828190@oracle.com>	<53A418B9.6080500@oracle.com>
	<53A41B16.9020404@oracle.com>	<18DA96EE-B90D-4BAD-8990-6D4972446019@oracle.com>	<53A41FF2.8050705@oracle.com>	<977775FE-2CE5-4223-89CC-88F0339CD420@oracle.com>	<53B3D65B.7000500@oracle.com>
	<0427C75B-FF62-4E86-818D-924AF164D8AC@oracle.com>
	<53B3E944.30501@oracle.com>
	<151706C7-4488-405C-92DE-E0A41019A416@oracle.com>
	<94D52B7E-BE8F-4BD8-A825-8D8328FBD34B@oracle.com>
	<A1759330-DDD1-495D-AD35-9A4D06B8478C@oracle.com>
Message-ID: <53C40CBB.7080200@oracle.com>

Hi Petr,

I realize that we're parsing our internal resource, however I have a few 
comments regarding the reliability of the parser:

>  235                 if (line.startsWith("#") || line.isEmpty()) continue;

Can a line start with a bunch of spaces, and then start a comment with a 
'#' character? Should we trim() ?


>  236                 while (line.endsWith("\\")) {
>  237                     line = line.trim() + reader.readLine().trim();
>  238                 }
>  239                 line = line.replace("\\", "");

The above code assumes that '\' characters are illegal in the middle of 
the lines because it removes all of them. Would it make sense to only 
remove the actual continuation slashes? For instance, take a look at:

src/windows/classes/sun/awt/datatransfer/flavormap.properties
>   54 UNICODE\ TEXT=text/plain;charset=utf-16le;eoln="\r\n";terminators=2

Your parser will remove the escape slashes from the "\r\n" string.

However, note that we still should handle the '\ ' sequence in the key 
part of each line.

Also, how about processing commas within string literals? There's not a 
case yet, but I can imagine such a mime type definition (e.g. 
...;terminators=",\\\r\n";...) (for the fun of it, i've also added the 
slash character in there.)

--
best regards,
Anthony

On 7/14/2014 6:23 PM, Petr Pchelko wrote:
> Hello, AWT Team.
>
> My apologies, but I've found a problem in the AWT part of this fix and so I need one more review iteration.
>
> The new version is located here: http://cr.openjdk.java.net/~pchelko/9/8047336/webrev.02/
> The only changes comparing to the previous approved version are in SystemFlavorMap.
>
> I've realized that we cannot use Properties to load the flavormap.properties file because Properties doesn't preserve the original order of keys.
> And it's important, because natives that are found in the file first are treated as more important than natives in the end of the file.
> So I've implemented a custom parser for the properties file (see lines 233-243)
>
> Thank you.
> With best regards. Petr.
>
> On 10 ???? 2014 ?., at 20:22, Mike Duigou <mike.duigou at oracle.com> wrote:
>
>> The makefile changes look fine to me. (The use of OPENJDK as part of the variable names seems excessive but that's not something your patch adds or changes)
>>
>> Mike
>>
>> On Jul 9 2014, at 23:55 , Petr Pchelko <petr.pchelko at oracle.com> wrote:
>>
>>> Hello, Build Team.
>>>
>>> This is a reminder. Could you please review the build part of the following fix:
>>> http://cr.openjdk.java.net/~pchelko/9/8047336/webrev.01/
>>>
>>> Thank you.
>>> With best regards. Petr.
>>>
>>> On 02 ???? 2014 ?., at 15:13, Anthony Petrov <anthony.petrov at oracle.com> wrote:
>>>
>>>> Thanks. Note that your email editor messed up the HTML part of the email (see below a text-only quote), so here's the correct link to the webrev:
>>>>
>>>> http://cr.openjdk.java.net/~pchelko/9/8047336/webrev.01/
>>>>
>>>> The fix looks fine to me.
>>>>
>>>> --
>>>> best regards,
>>>> Anthony
>>>>
>>>> On 7/2/2014 3:10 PM, Petr Pchelko wrote:
>>>>> Hello, Anthony, Alan.
>>>>>
>>>>> Thank you for the review, the new version is located here:
>>>>> http://cr.openjdk.java.net/~pchelko/9/8047336/webrev.01/
>>>>> <http://cr.openjdk.java.net/%7Epchelko/9/8047336/webrev.00/>
>>>>>
>>>>> I've changed the code to throw an InternalError if we cannot read
>>>>> properties.
>>>>> Once I get feedback from the build team - I'll push this fix.
>>>>>
>>>>> With best regards. Petr.
>>>>>
>>>>> On 02 ???? 2014 ?., at 13:52, Alan Bateman <Alan.Bateman at oracle.com
>>>>> <mailto:Alan.Bateman at oracle.com>> wrote:
>>>>>
>>>>>> On 01/07/2014 09:35, Petr Pchelko wrote:
>>>>>>> Hello,
>>>>>>>
>>>>>>> The changes in the public API have been approved, so let me continue
>>>>>>> the review process.
>>>>>>>
>>>>>>> For your convenience:
>>>>>>> The bug: https://bugs.openjdk.java.net/browse/JDK-8047336
>>>>>>> The fix: http://cr.openjdk.java.net/~pchelko/9/8047336/webrev.00/
>>>>>>> <http://cr.openjdk.java.net/%7Epchelko/9/8047336/webrev.00/>
>>>>>>>
>>>>>>> Until now we've been discussing an abstract question of moving the
>>>>>>> properties to a different location and agreed that it's possible.
>>>>>>> Now it's time for an official code review. Could someone please make one?
>>>>>>>
>>>>>>> Also some feedback from the build team is still required. Could
>>>>>>> someone from the build team review this fix please?
>>>>>>> (The question is that I've made a separate explicit rule for
>>>>>>> flavormap.properties file. If I add it to COPY_PATTERNS than the
>>>>>>> solaris version get's copied on Mac. Is that a bug in the build
>>>>>>> system? Is my current solution good enough?)
>>>>>>>
>>>>>> I think this looks okay. I see Anthony's mail asking about the warning
>>>>>> message and whether it should the print stack trace. I just wonder if
>>>>>> it might be saner to just throw InternalError here. It throws
>>>>>> InternalError if flavormap.properties is missing and it might be
>>>>>> consistent to do the same when the file is corrupt or can't be parsed
>>>>>> as a properties file.
>>>>>>
>>>>>> -Alan.
>>>>>
>>>
>>
>

From petr.pchelko at oracle.com  Tue Jul 15 07:41:48 2014
From: petr.pchelko at oracle.com (Petr Pchelko)
Date: Tue, 15 Jul 2014 11:41:48 +0400
Subject: <AWT Dev> [9] Review request: 8050465 Remove sun.audio package
Message-ID: <88FC3515-EE2A-4A43-96E3-B3632C4A799F@oracle.com>

Hello, 

Please review the fix for the issue:
https://bugs.openjdk.java.net/browse/JDK-8050465
The fix is available here:
http://cr.openjdk.java.net/~pchelko/9/8050465/webrev/

Simple clean-up. The package is not used any more and can be removed.

With best regards. Petr.

From petr.pchelko at oracle.com  Tue Jul 15 08:19:00 2014
From: petr.pchelko at oracle.com (Petr Pchelko)
Date: Tue, 15 Jul 2014 12:19:00 +0400
Subject: <AWT Dev> [9] Review Request: 8047336 Read flavormap.properties
	as resource
In-Reply-To: <53C40CBB.7080200@oracle.com>
References: <59786637-036B-49C3-AB92-0D5742C87AC2@oracle.com>	<53A2D3DA.4030503@oracle.com>	<B543154A-7C00-4024-9478-6D615E828190@oracle.com>	<53A418B9.6080500@oracle.com>
	<53A41B16.9020404@oracle.com>	<18DA96EE-B90D-4BAD-8990-6D4972446019@oracle.com>	<53A41FF2.8050705@oracle.com>	<977775FE-2CE5-4223-89CC-88F0339CD420@oracle.com>	<53B3D65B.7000500@oracle.com>
	<0427C75B-FF62-4E86-818D-924AF164D8AC@oracle.com>
	<53B3E944.30501@oracle.com>
	<151706C7-4488-405C-92DE-E0A41019A416@oracle.com>
	<94D52B7E-BE8F-4BD8-A825-8D8328FBD34B@oracle.com>
	<A1759330-DDD1-495D-AD35-9A4D06B8478C@oracle.com>
	<53C40CBB.7080200@oracle.com>
Message-ID: <67F58075-0F3B-4BB0-9D6C-142CDEDED44A@oracle.com>

Hello, Anthony.

Thank you for the review.
The new version is here: http://cr.openjdk.java.net/~pchelko/9/8047336/webrev.03/
Only SystemFlavorMap is changed again.

I've fixed the parser according to your comments.

> Also, how about processing commas within string literals? There's not a case yet, but I can imagine such a mime type definition (e.g. ...;terminators=",\\\r\n";...) (for the fun of it, i've also added the slash character in there.)
I don't think we should worry about it now. The properties file is internal and it's highly unlikely we would ever make such a mime-type. And we can update the parser when we need.
If I handle this situation now this would be just dead code and unneeded complexity.

With best regards. Petr.

On 14 ???? 2014 ?., at 21:00, Anthony Petrov <anthony.petrov at oracle.com> wrote:

> Hi Petr,
> 
> I realize that we're parsing our internal resource, however I have a few comments regarding the reliability of the parser:
> 
>> 235                 if (line.startsWith("#") || line.isEmpty()) continue;
> 
> Can a line start with a bunch of spaces, and then start a comment with a '#' character? Should we trim() ?
> 
> 
>> 236                 while (line.endsWith("\\")) {
>> 237                     line = line.trim() + reader.readLine().trim();
>> 238                 }
>> 239                 line = line.replace("\\", "");
> 
> The above code assumes that '\' characters are illegal in the middle of the lines because it removes all of them. Would it make sense to only remove the actual continuation slashes? For instance, take a look at:
> 
> src/windows/classes/sun/awt/datatransfer/flavormap.properties
>>  54 UNICODE\ TEXT=text/plain;charset=utf-16le;eoln="\r\n";terminators=2
> 
> Your parser will remove the escape slashes from the "\r\n" string.
> 
> However, note that we still should handle the '\ ' sequence in the key part of each line.
> 
> Also, how about processing commas within string literals? There's not a case yet, but I can imagine such a mime type definition (e.g. ...;terminators=",\\\r\n";...) (for the fun of it, i've also added the slash character in there.)
> 
> --
> best regards,
> Anthony
> 
> On 7/14/2014 6:23 PM, Petr Pchelko wrote:
>> Hello, AWT Team.
>> 
>> My apologies, but I've found a problem in the AWT part of this fix and so I need one more review iteration.
>> 
>> The new version is located here: http://cr.openjdk.java.net/~pchelko/9/8047336/webrev.02/
>> The only changes comparing to the previous approved version are in SystemFlavorMap.
>> 
>> I've realized that we cannot use Properties to load the flavormap.properties file because Properties doesn't preserve the original order of keys.
>> And it's important, because natives that are found in the file first are treated as more important than natives in the end of the file.
>> So I've implemented a custom parser for the properties file (see lines 233-243)
>> 
>> Thank you.
>> With best regards. Petr.
>> 
>> On 10 ???? 2014 ?., at 20:22, Mike Duigou <mike.duigou at oracle.com> wrote:
>> 
>>> The makefile changes look fine to me. (The use of OPENJDK as part of the variable names seems excessive but that's not something your patch adds or changes)
>>> 
>>> Mike
>>> 
>>> On Jul 9 2014, at 23:55 , Petr Pchelko <petr.pchelko at oracle.com> wrote:
>>> 
>>>> Hello, Build Team.
>>>> 
>>>> This is a reminder. Could you please review the build part of the following fix:
>>>> http://cr.openjdk.java.net/~pchelko/9/8047336/webrev.01/
>>>> 
>>>> Thank you.
>>>> With best regards. Petr.
>>>> 
>>>> On 02 ???? 2014 ?., at 15:13, Anthony Petrov <anthony.petrov at oracle.com> wrote:
>>>> 
>>>>> Thanks. Note that your email editor messed up the HTML part of the email (see below a text-only quote), so here's the correct link to the webrev:
>>>>> 
>>>>> http://cr.openjdk.java.net/~pchelko/9/8047336/webrev.01/
>>>>> 
>>>>> The fix looks fine to me.
>>>>> 
>>>>> --
>>>>> best regards,
>>>>> Anthony
>>>>> 
>>>>> On 7/2/2014 3:10 PM, Petr Pchelko wrote:
>>>>>> Hello, Anthony, Alan.
>>>>>> 
>>>>>> Thank you for the review, the new version is located here:
>>>>>> http://cr.openjdk.java.net/~pchelko/9/8047336/webrev.01/
>>>>>> <http://cr.openjdk.java.net/%7Epchelko/9/8047336/webrev.00/>
>>>>>> 
>>>>>> I've changed the code to throw an InternalError if we cannot read
>>>>>> properties.
>>>>>> Once I get feedback from the build team - I'll push this fix.
>>>>>> 
>>>>>> With best regards. Petr.
>>>>>> 
>>>>>> On 02 ???? 2014 ?., at 13:52, Alan Bateman <Alan.Bateman at oracle.com
>>>>>> <mailto:Alan.Bateman at oracle.com>> wrote:
>>>>>> 
>>>>>>> On 01/07/2014 09:35, Petr Pchelko wrote:
>>>>>>>> Hello,
>>>>>>>> 
>>>>>>>> The changes in the public API have been approved, so let me continue
>>>>>>>> the review process.
>>>>>>>> 
>>>>>>>> For your convenience:
>>>>>>>> The bug: https://bugs.openjdk.java.net/browse/JDK-8047336
>>>>>>>> The fix: http://cr.openjdk.java.net/~pchelko/9/8047336/webrev.00/
>>>>>>>> <http://cr.openjdk.java.net/%7Epchelko/9/8047336/webrev.00/>
>>>>>>>> 
>>>>>>>> Until now we've been discussing an abstract question of moving the
>>>>>>>> properties to a different location and agreed that it's possible.
>>>>>>>> Now it's time for an official code review. Could someone please make one?
>>>>>>>> 
>>>>>>>> Also some feedback from the build team is still required. Could
>>>>>>>> someone from the build team review this fix please?
>>>>>>>> (The question is that I've made a separate explicit rule for
>>>>>>>> flavormap.properties file. If I add it to COPY_PATTERNS than the
>>>>>>>> solaris version get's copied on Mac. Is that a bug in the build
>>>>>>>> system? Is my current solution good enough?)
>>>>>>>> 
>>>>>>> I think this looks okay. I see Anthony's mail asking about the warning
>>>>>>> message and whether it should the print stack trace. I just wonder if
>>>>>>> it might be saner to just throw InternalError here. It throws
>>>>>>> InternalError if flavormap.properties is missing and it might be
>>>>>>> consistent to do the same when the file is corrupt or can't be parsed
>>>>>>> as a properties file.
>>>>>>> 
>>>>>>> -Alan.
>>>>>> 
>>>> 
>>> 
>> 


From petr.pchelko at oracle.com  Tue Jul 15 10:01:52 2014
From: petr.pchelko at oracle.com (Petr Pchelko)
Date: Tue, 15 Jul 2014 14:01:52 +0400
Subject: <AWT Dev> [8u] Review request: 8048549 [macosx] Disable usage of
	system menu bar if AWT is embedded in FX
Message-ID: <AD884FF4-43D5-48B7-B150-A4BE1DD79830@oracle.com>

Hello, AWT team.

Please review the fix for the issue:
https://bugs.openjdk.java.net/browse/JDK-8048549
The 8u version is available here:
http://cr.openjdk.java.net/~pchelko/9/8048549/webrev.8u/
For reference, the 9 version is available here:
http://cr.openjdk.java.net/~pchelko/9/8048549/webrev/

The 8u version is different, so a new review is needed. In 9 we've moved AWT initialization from awt.m to LWCToolkit.m, so we did not need to use ThreadUtilities. 
In 8u we need to use ThreadUtilities to figure out if AWT is running embedded or not. All the rest of the fix is the same as in 9.

Thank you.
With best regards. Petr.

From anthony.petrov at oracle.com  Tue Jul 15 10:31:32 2014
From: anthony.petrov at oracle.com (Anthony Petrov)
Date: Tue, 15 Jul 2014 14:31:32 +0400
Subject: <AWT Dev> [9] Review Request: 8047336 Read flavormap.properties
 as resource
In-Reply-To: <67F58075-0F3B-4BB0-9D6C-142CDEDED44A@oracle.com>
References: <59786637-036B-49C3-AB92-0D5742C87AC2@oracle.com>	<53A2D3DA.4030503@oracle.com>	<B543154A-7C00-4024-9478-6D615E828190@oracle.com>	<53A418B9.6080500@oracle.com>
	<53A41B16.9020404@oracle.com>	<18DA96EE-B90D-4BAD-8990-6D4972446019@oracle.com>	<53A41FF2.8050705@oracle.com>	<977775FE-2CE5-4223-89CC-88F0339CD420@oracle.com>	<53B3D65B.7000500@oracle.com>
	<0427C75B-FF62-4E86-818D-924AF164D8AC@oracle.com>
	<53B3E944.30501@oracle.com>
	<151706C7-4488-405C-92DE-E0A41019A416@oracle.com>
	<94D52B7E-BE8F-4BD8-A825-8D8328FBD34B@oracle.com>
	<A1759330-DDD1-495D-AD35-9A4D06B8478C@oracle.com>
	<53C40CBB.7080200@oracle.com>
	<67F58075-0F3B-4BB0-9D6C-142CDEDED44A@oracle.com>
Message-ID: <53C50304.8020408@oracle.com>

Hi Petr,

I'm still a bit concerned about this line:

>  243                 String[] values = line.substring(delimiterPosition + 1, line.length())
>  244                         .replace(",\\", ",")
>  245                         .split(",");

This code now introduces another assumption, that every continuation 
slash is preceded by a comma. Also it assumes that no such a sequence of 
characters (",\") may occur anywhere else in the parsed lines.

I'm not okay with these assumption. I'll reiterate my suggestion once 
again: would it make sense to only remove the actual continuation slashes?

--
best regards,
Anthony

On 7/15/2014 12:19 PM, Petr Pchelko wrote:
> Hello, Anthony.
>
> Thank you for the review.
> The new version is here: http://cr.openjdk.java.net/~pchelko/9/8047336/webrev.03/
> Only SystemFlavorMap is changed again.
>
> I've fixed the parser according to your comments.
>
>> Also, how about processing commas within string literals? There's not a case yet, but I can imagine such a mime type definition (e.g. ...;terminators=",\\\r\n";...) (for the fun of it, i've also added the slash character in there.)
> I don't think we should worry about it now. The properties file is internal and it's highly unlikely we would ever make such a mime-type. And we can update the parser when we need.
> If I handle this situation now this would be just dead code and unneeded complexity.
>
> With best regards. Petr.
>
> On 14 ???? 2014 ?., at 21:00, Anthony Petrov <anthony.petrov at oracle.com> wrote:
>
>> Hi Petr,
>>
>> I realize that we're parsing our internal resource, however I have a few comments regarding the reliability of the parser:
>>
>>> 235                 if (line.startsWith("#") || line.isEmpty()) continue;
>>
>> Can a line start with a bunch of spaces, and then start a comment with a '#' character? Should we trim() ?
>>
>>
>>> 236                 while (line.endsWith("\\")) {
>>> 237                     line = line.trim() + reader.readLine().trim();
>>> 238                 }
>>> 239                 line = line.replace("\\", "");
>>
>> The above code assumes that '\' characters are illegal in the middle of the lines because it removes all of them. Would it make sense to only remove the actual continuation slashes? For instance, take a look at:
>>
>> src/windows/classes/sun/awt/datatransfer/flavormap.properties
>>>   54 UNICODE\ TEXT=text/plain;charset=utf-16le;eoln="\r\n";terminators=2
>>
>> Your parser will remove the escape slashes from the "\r\n" string.
>>
>> However, note that we still should handle the '\ ' sequence in the key part of each line.
>>
>> Also, how about processing commas within string literals? There's not a case yet, but I can imagine such a mime type definition (e.g. ...;terminators=",\\\r\n";...) (for the fun of it, i've also added the slash character in there.)
>>
>> --
>> best regards,
>> Anthony
>>
>> On 7/14/2014 6:23 PM, Petr Pchelko wrote:
>>> Hello, AWT Team.
>>>
>>> My apologies, but I've found a problem in the AWT part of this fix and so I need one more review iteration.
>>>
>>> The new version is located here: http://cr.openjdk.java.net/~pchelko/9/8047336/webrev.02/
>>> The only changes comparing to the previous approved version are in SystemFlavorMap.
>>>
>>> I've realized that we cannot use Properties to load the flavormap.properties file because Properties doesn't preserve the original order of keys.
>>> And it's important, because natives that are found in the file first are treated as more important than natives in the end of the file.
>>> So I've implemented a custom parser for the properties file (see lines 233-243)
>>>
>>> Thank you.
>>> With best regards. Petr.
>>>
>>> On 10 ???? 2014 ?., at 20:22, Mike Duigou <mike.duigou at oracle.com> wrote:
>>>
>>>> The makefile changes look fine to me. (The use of OPENJDK as part of the variable names seems excessive but that's not something your patch adds or changes)
>>>>
>>>> Mike
>>>>
>>>> On Jul 9 2014, at 23:55 , Petr Pchelko <petr.pchelko at oracle.com> wrote:
>>>>
>>>>> Hello, Build Team.
>>>>>
>>>>> This is a reminder. Could you please review the build part of the following fix:
>>>>> http://cr.openjdk.java.net/~pchelko/9/8047336/webrev.01/
>>>>>
>>>>> Thank you.
>>>>> With best regards. Petr.
>>>>>
>>>>> On 02 ???? 2014 ?., at 15:13, Anthony Petrov <anthony.petrov at oracle.com> wrote:
>>>>>
>>>>>> Thanks. Note that your email editor messed up the HTML part of the email (see below a text-only quote), so here's the correct link to the webrev:
>>>>>>
>>>>>> http://cr.openjdk.java.net/~pchelko/9/8047336/webrev.01/
>>>>>>
>>>>>> The fix looks fine to me.
>>>>>>
>>>>>> --
>>>>>> best regards,
>>>>>> Anthony
>>>>>>
>>>>>> On 7/2/2014 3:10 PM, Petr Pchelko wrote:
>>>>>>> Hello, Anthony, Alan.
>>>>>>>
>>>>>>> Thank you for the review, the new version is located here:
>>>>>>> http://cr.openjdk.java.net/~pchelko/9/8047336/webrev.01/
>>>>>>> <http://cr.openjdk.java.net/%7Epchelko/9/8047336/webrev.00/>
>>>>>>>
>>>>>>> I've changed the code to throw an InternalError if we cannot read
>>>>>>> properties.
>>>>>>> Once I get feedback from the build team - I'll push this fix.
>>>>>>>
>>>>>>> With best regards. Petr.
>>>>>>>
>>>>>>> On 02 ???? 2014 ?., at 13:52, Alan Bateman <Alan.Bateman at oracle.com
>>>>>>> <mailto:Alan.Bateman at oracle.com>> wrote:
>>>>>>>
>>>>>>>> On 01/07/2014 09:35, Petr Pchelko wrote:
>>>>>>>>> Hello,
>>>>>>>>>
>>>>>>>>> The changes in the public API have been approved, so let me continue
>>>>>>>>> the review process.
>>>>>>>>>
>>>>>>>>> For your convenience:
>>>>>>>>> The bug: https://bugs.openjdk.java.net/browse/JDK-8047336
>>>>>>>>> The fix: http://cr.openjdk.java.net/~pchelko/9/8047336/webrev.00/
>>>>>>>>> <http://cr.openjdk.java.net/%7Epchelko/9/8047336/webrev.00/>
>>>>>>>>>
>>>>>>>>> Until now we've been discussing an abstract question of moving the
>>>>>>>>> properties to a different location and agreed that it's possible.
>>>>>>>>> Now it's time for an official code review. Could someone please make one?
>>>>>>>>>
>>>>>>>>> Also some feedback from the build team is still required. Could
>>>>>>>>> someone from the build team review this fix please?
>>>>>>>>> (The question is that I've made a separate explicit rule for
>>>>>>>>> flavormap.properties file. If I add it to COPY_PATTERNS than the
>>>>>>>>> solaris version get's copied on Mac. Is that a bug in the build
>>>>>>>>> system? Is my current solution good enough?)
>>>>>>>>>
>>>>>>>> I think this looks okay. I see Anthony's mail asking about the warning
>>>>>>>> message and whether it should the print stack trace. I just wonder if
>>>>>>>> it might be saner to just throw InternalError here. It throws
>>>>>>>> InternalError if flavormap.properties is missing and it might be
>>>>>>>> consistent to do the same when the file is corrupt or can't be parsed
>>>>>>>> as a properties file.
>>>>>>>>
>>>>>>>> -Alan.
>>>>>>>
>>>>>
>>>>
>>>
>

From petr.pchelko at oracle.com  Tue Jul 15 10:43:49 2014
From: petr.pchelko at oracle.com (Petr Pchelko)
Date: Tue, 15 Jul 2014 14:43:49 +0400
Subject: <AWT Dev> [9] Review Request: 8047336 Read flavormap.properties
	as resource
In-Reply-To: <53C50304.8020408@oracle.com>
References: <59786637-036B-49C3-AB92-0D5742C87AC2@oracle.com>	<53A2D3DA.4030503@oracle.com>	<B543154A-7C00-4024-9478-6D615E828190@oracle.com>	<53A418B9.6080500@oracle.com>
	<53A41B16.9020404@oracle.com>	<18DA96EE-B90D-4BAD-8990-6D4972446019@oracle.com>	<53A41FF2.8050705@oracle.com>	<977775FE-2CE5-4223-89CC-88F0339CD420@oracle.com>	<53B3D65B.7000500@oracle.com>
	<0427C75B-FF62-4E86-818D-924AF164D8AC@oracle.com>
	<53B3E944.30501@oracle.com>
	<151706C7-4488-405C-92DE-E0A41019A416@oracle.com>
	<94D52B7E-BE8F-4BD8-A825-8D8328FBD34B@oracle.com>
	<A1759330-DDD1-495D-AD35-9A4D06B8478C@oracle.com>
	<53C40CBB.7080200@oracle.com>
	<67F58075-0F3B-4BB0-9D6C-142CDEDED44A@oracle.com>
	<53C50304.8020408@oracle.com>
Message-ID: <DA662046-6AB8-4535-A405-2242048594C9@oracle.com>

Hello, Anthony.

How about this:
> line = line.trim();
> if (line.startsWith("#") || line.isEmpty()) continue;
> while (line.endsWith("\\")) {
>     line = line.substring(0, line.length() - 1) + reader.readLine().trim();
> }
> int delimiterPosition = line.indexOf('=');
> String key = line.substring(0, delimiterPosition).replace("\\ ", " ");
> String[] values = line.substring(delimiterPosition + 1, line.length()).split(",");

With best regards. Petr.

On 15 ???? 2014 ?., at 14:31, Anthony Petrov <anthony.petrov at oracle.com> wrote:

> Hi Petr,
> 
> I'm still a bit concerned about this line:
> 
>> 243                 String[] values = line.substring(delimiterPosition + 1, line.length())
>> 244                         .replace(",\\", ",")
>> 245                         .split(",");
> 
> This code now introduces another assumption, that every continuation slash is preceded by a comma. Also it assumes that no such a sequence of characters (",\") may occur anywhere else in the parsed lines.
> 
> I'm not okay with these assumption. I'll reiterate my suggestion once again: would it make sense to only remove the actual continuation slashes?
> 
> --
> best regards,
> Anthony
> 
> On 7/15/2014 12:19 PM, Petr Pchelko wrote:
>> Hello, Anthony.
>> 
>> Thank you for the review.
>> The new version is here: http://cr.openjdk.java.net/~pchelko/9/8047336/webrev.03/
>> Only SystemFlavorMap is changed again.
>> 
>> I've fixed the parser according to your comments.
>> 
>>> Also, how about processing commas within string literals? There's not a case yet, but I can imagine such a mime type definition (e.g. ...;terminators=",\\\r\n";...) (for the fun of it, i've also added the slash character in there.)
>> I don't think we should worry about it now. The properties file is internal and it's highly unlikely we would ever make such a mime-type. And we can update the parser when we need.
>> If I handle this situation now this would be just dead code and unneeded complexity.
>> 
>> With best regards. Petr.
>> 
>> On 14 ???? 2014 ?., at 21:00, Anthony Petrov <anthony.petrov at oracle.com> wrote:
>> 
>>> Hi Petr,
>>> 
>>> I realize that we're parsing our internal resource, however I have a few comments regarding the reliability of the parser:
>>> 
>>>> 235                 if (line.startsWith("#") || line.isEmpty()) continue;
>>> 
>>> Can a line start with a bunch of spaces, and then start a comment with a '#' character? Should we trim() ?
>>> 
>>> 
>>>> 236                 while (line.endsWith("\\")) {
>>>> 237                     line = line.trim() + reader.readLine().trim();
>>>> 238                 }
>>>> 239                 line = line.replace("\\", "");
>>> 
>>> The above code assumes that '\' characters are illegal in the middle of the lines because it removes all of them. Would it make sense to only remove the actual continuation slashes? For instance, take a look at:
>>> 
>>> src/windows/classes/sun/awt/datatransfer/flavormap.properties
>>>>  54 UNICODE\ TEXT=text/plain;charset=utf-16le;eoln="\r\n";terminators=2
>>> 
>>> Your parser will remove the escape slashes from the "\r\n" string.
>>> 
>>> However, note that we still should handle the '\ ' sequence in the key part of each line.
>>> 
>>> Also, how about processing commas within string literals? There's not a case yet, but I can imagine such a mime type definition (e.g. ...;terminators=",\\\r\n";...) (for the fun of it, i've also added the slash character in there.)
>>> 
>>> --
>>> best regards,
>>> Anthony
>>> 
>>> On 7/14/2014 6:23 PM, Petr Pchelko wrote:
>>>> Hello, AWT Team.
>>>> 
>>>> My apologies, but I've found a problem in the AWT part of this fix and so I need one more review iteration.
>>>> 
>>>> The new version is located here: http://cr.openjdk.java.net/~pchelko/9/8047336/webrev.02/
>>>> The only changes comparing to the previous approved version are in SystemFlavorMap.
>>>> 
>>>> I've realized that we cannot use Properties to load the flavormap.properties file because Properties doesn't preserve the original order of keys.
>>>> And it's important, because natives that are found in the file first are treated as more important than natives in the end of the file.
>>>> So I've implemented a custom parser for the properties file (see lines 233-243)
>>>> 
>>>> Thank you.
>>>> With best regards. Petr.
>>>> 
>>>> On 10 ???? 2014 ?., at 20:22, Mike Duigou <mike.duigou at oracle.com> wrote:
>>>> 
>>>>> The makefile changes look fine to me. (The use of OPENJDK as part of the variable names seems excessive but that's not something your patch adds or changes)
>>>>> 
>>>>> Mike
>>>>> 
>>>>> On Jul 9 2014, at 23:55 , Petr Pchelko <petr.pchelko at oracle.com> wrote:
>>>>> 
>>>>>> Hello, Build Team.
>>>>>> 
>>>>>> This is a reminder. Could you please review the build part of the following fix:
>>>>>> http://cr.openjdk.java.net/~pchelko/9/8047336/webrev.01/
>>>>>> 
>>>>>> Thank you.
>>>>>> With best regards. Petr.
>>>>>> 
>>>>>> On 02 ???? 2014 ?., at 15:13, Anthony Petrov <anthony.petrov at oracle.com> wrote:
>>>>>> 
>>>>>>> Thanks. Note that your email editor messed up the HTML part of the email (see below a text-only quote), so here's the correct link to the webrev:
>>>>>>> 
>>>>>>> http://cr.openjdk.java.net/~pchelko/9/8047336/webrev.01/
>>>>>>> 
>>>>>>> The fix looks fine to me.
>>>>>>> 
>>>>>>> --
>>>>>>> best regards,
>>>>>>> Anthony
>>>>>>> 
>>>>>>> On 7/2/2014 3:10 PM, Petr Pchelko wrote:
>>>>>>>> Hello, Anthony, Alan.
>>>>>>>> 
>>>>>>>> Thank you for the review, the new version is located here:
>>>>>>>> http://cr.openjdk.java.net/~pchelko/9/8047336/webrev.01/
>>>>>>>> <http://cr.openjdk.java.net/%7Epchelko/9/8047336/webrev.00/>
>>>>>>>> 
>>>>>>>> I've changed the code to throw an InternalError if we cannot read
>>>>>>>> properties.
>>>>>>>> Once I get feedback from the build team - I'll push this fix.
>>>>>>>> 
>>>>>>>> With best regards. Petr.
>>>>>>>> 
>>>>>>>> On 02 ???? 2014 ?., at 13:52, Alan Bateman <Alan.Bateman at oracle.com
>>>>>>>> <mailto:Alan.Bateman at oracle.com>> wrote:
>>>>>>>> 
>>>>>>>>> On 01/07/2014 09:35, Petr Pchelko wrote:
>>>>>>>>>> Hello,
>>>>>>>>>> 
>>>>>>>>>> The changes in the public API have been approved, so let me continue
>>>>>>>>>> the review process.
>>>>>>>>>> 
>>>>>>>>>> For your convenience:
>>>>>>>>>> The bug: https://bugs.openjdk.java.net/browse/JDK-8047336
>>>>>>>>>> The fix: http://cr.openjdk.java.net/~pchelko/9/8047336/webrev.00/
>>>>>>>>>> <http://cr.openjdk.java.net/%7Epchelko/9/8047336/webrev.00/>
>>>>>>>>>> 
>>>>>>>>>> Until now we've been discussing an abstract question of moving the
>>>>>>>>>> properties to a different location and agreed that it's possible.
>>>>>>>>>> Now it's time for an official code review. Could someone please make one?
>>>>>>>>>> 
>>>>>>>>>> Also some feedback from the build team is still required. Could
>>>>>>>>>> someone from the build team review this fix please?
>>>>>>>>>> (The question is that I've made a separate explicit rule for
>>>>>>>>>> flavormap.properties file. If I add it to COPY_PATTERNS than the
>>>>>>>>>> solaris version get's copied on Mac. Is that a bug in the build
>>>>>>>>>> system? Is my current solution good enough?)
>>>>>>>>>> 
>>>>>>>>> I think this looks okay. I see Anthony's mail asking about the warning
>>>>>>>>> message and whether it should the print stack trace. I just wonder if
>>>>>>>>> it might be saner to just throw InternalError here. It throws
>>>>>>>>> InternalError if flavormap.properties is missing and it might be
>>>>>>>>> consistent to do the same when the file is corrupt or can't be parsed
>>>>>>>>> as a properties file.
>>>>>>>>> 
>>>>>>>>> -Alan.
>>>>>>>> 
>>>>>> 
>>>>> 
>>>> 
>> 


From anthony.petrov at oracle.com  Tue Jul 15 10:44:17 2014
From: anthony.petrov at oracle.com (Anthony Petrov)
Date: Tue, 15 Jul 2014 14:44:17 +0400
Subject: <AWT Dev> [9] Review Request: 8047336 Read flavormap.properties
 as resource
In-Reply-To: <DA662046-6AB8-4535-A405-2242048594C9@oracle.com>
References: <59786637-036B-49C3-AB92-0D5742C87AC2@oracle.com>	<53A2D3DA.4030503@oracle.com>	<B543154A-7C00-4024-9478-6D615E828190@oracle.com>	<53A418B9.6080500@oracle.com>
	<53A41B16.9020404@oracle.com>	<18DA96EE-B90D-4BAD-8990-6D4972446019@oracle.com>	<53A41FF2.8050705@oracle.com>	<977775FE-2CE5-4223-89CC-88F0339CD420@oracle.com>	<53B3D65B.7000500@oracle.com>
	<0427C75B-FF62-4E86-818D-924AF164D8AC@oracle.com>
	<53B3E944.30501@oracle.com>
	<151706C7-4488-405C-92DE-E0A41019A416@oracle.com>
	<94D52B7E-BE8F-4BD8-A825-8D8328FBD34B@oracle.com>
	<A1759330-DDD1-495D-AD35-9A4D06B8478C@oracle.com>
	<53C40CBB.7080200@oracle.com>
	<67F58075-0F3B-4BB0-9D6C-142CDEDED44A@oracle.com>
	<53C50304.8020408@oracle.com>
	<DA662046-6AB8-4535-A405-2242048594C9@oracle.com>
Message-ID: <53C50601.4030904@oracle.com>

That looks good to me.

--
best regards,
Anthony

On 7/15/2014 2:43 PM, Petr Pchelko wrote:
> Hello, Anthony.
>
> How about this:
>> line = line.trim();
>> if (line.startsWith("#") || line.isEmpty()) continue;
>> while (line.endsWith("\\")) {
>>      line = line.substring(0, line.length() - 1) + reader.readLine().trim();
>> }
>> int delimiterPosition = line.indexOf('=');
>> String key = line.substring(0, delimiterPosition).replace("\\ ", " ");
>> String[] values = line.substring(delimiterPosition + 1, line.length()).split(",");
>
> With best regards. Petr.
>
> On 15 ???? 2014 ?., at 14:31, Anthony Petrov <anthony.petrov at oracle.com> wrote:
>
>> Hi Petr,
>>
>> I'm still a bit concerned about this line:
>>
>>> 243                 String[] values = line.substring(delimiterPosition + 1, line.length())
>>> 244                         .replace(",\\", ",")
>>> 245                         .split(",");
>>
>> This code now introduces another assumption, that every continuation slash is preceded by a comma. Also it assumes that no such a sequence of characters (",\") may occur anywhere else in the parsed lines.
>>
>> I'm not okay with these assumption. I'll reiterate my suggestion once again: would it make sense to only remove the actual continuation slashes?
>>
>> --
>> best regards,
>> Anthony
>>
>> On 7/15/2014 12:19 PM, Petr Pchelko wrote:
>>> Hello, Anthony.
>>>
>>> Thank you for the review.
>>> The new version is here: http://cr.openjdk.java.net/~pchelko/9/8047336/webrev.03/
>>> Only SystemFlavorMap is changed again.
>>>
>>> I've fixed the parser according to your comments.
>>>
>>>> Also, how about processing commas within string literals? There's not a case yet, but I can imagine such a mime type definition (e.g. ...;terminators=",\\\r\n";...) (for the fun of it, i've also added the slash character in there.)
>>> I don't think we should worry about it now. The properties file is internal and it's highly unlikely we would ever make such a mime-type. And we can update the parser when we need.
>>> If I handle this situation now this would be just dead code and unneeded complexity.
>>>
>>> With best regards. Petr.
>>>
>>> On 14 ???? 2014 ?., at 21:00, Anthony Petrov <anthony.petrov at oracle.com> wrote:
>>>
>>>> Hi Petr,
>>>>
>>>> I realize that we're parsing our internal resource, however I have a few comments regarding the reliability of the parser:
>>>>
>>>>> 235                 if (line.startsWith("#") || line.isEmpty()) continue;
>>>>
>>>> Can a line start with a bunch of spaces, and then start a comment with a '#' character? Should we trim() ?
>>>>
>>>>
>>>>> 236                 while (line.endsWith("\\")) {
>>>>> 237                     line = line.trim() + reader.readLine().trim();
>>>>> 238                 }
>>>>> 239                 line = line.replace("\\", "");
>>>>
>>>> The above code assumes that '\' characters are illegal in the middle of the lines because it removes all of them. Would it make sense to only remove the actual continuation slashes? For instance, take a look at:
>>>>
>>>> src/windows/classes/sun/awt/datatransfer/flavormap.properties
>>>>>   54 UNICODE\ TEXT=text/plain;charset=utf-16le;eoln="\r\n";terminators=2
>>>>
>>>> Your parser will remove the escape slashes from the "\r\n" string.
>>>>
>>>> However, note that we still should handle the '\ ' sequence in the key part of each line.
>>>>
>>>> Also, how about processing commas within string literals? There's not a case yet, but I can imagine such a mime type definition (e.g. ...;terminators=",\\\r\n";...) (for the fun of it, i've also added the slash character in there.)
>>>>
>>>> --
>>>> best regards,
>>>> Anthony
>>>>
>>>> On 7/14/2014 6:23 PM, Petr Pchelko wrote:
>>>>> Hello, AWT Team.
>>>>>
>>>>> My apologies, but I've found a problem in the AWT part of this fix and so I need one more review iteration.
>>>>>
>>>>> The new version is located here: http://cr.openjdk.java.net/~pchelko/9/8047336/webrev.02/
>>>>> The only changes comparing to the previous approved version are in SystemFlavorMap.
>>>>>
>>>>> I've realized that we cannot use Properties to load the flavormap.properties file because Properties doesn't preserve the original order of keys.
>>>>> And it's important, because natives that are found in the file first are treated as more important than natives in the end of the file.
>>>>> So I've implemented a custom parser for the properties file (see lines 233-243)
>>>>>
>>>>> Thank you.
>>>>> With best regards. Petr.
>>>>>
>>>>> On 10 ???? 2014 ?., at 20:22, Mike Duigou <mike.duigou at oracle.com> wrote:
>>>>>
>>>>>> The makefile changes look fine to me. (The use of OPENJDK as part of the variable names seems excessive but that's not something your patch adds or changes)
>>>>>>
>>>>>> Mike
>>>>>>
>>>>>> On Jul 9 2014, at 23:55 , Petr Pchelko <petr.pchelko at oracle.com> wrote:
>>>>>>
>>>>>>> Hello, Build Team.
>>>>>>>
>>>>>>> This is a reminder. Could you please review the build part of the following fix:
>>>>>>> http://cr.openjdk.java.net/~pchelko/9/8047336/webrev.01/
>>>>>>>
>>>>>>> Thank you.
>>>>>>> With best regards. Petr.
>>>>>>>
>>>>>>> On 02 ???? 2014 ?., at 15:13, Anthony Petrov <anthony.petrov at oracle.com> wrote:
>>>>>>>
>>>>>>>> Thanks. Note that your email editor messed up the HTML part of the email (see below a text-only quote), so here's the correct link to the webrev:
>>>>>>>>
>>>>>>>> http://cr.openjdk.java.net/~pchelko/9/8047336/webrev.01/
>>>>>>>>
>>>>>>>> The fix looks fine to me.
>>>>>>>>
>>>>>>>> --
>>>>>>>> best regards,
>>>>>>>> Anthony
>>>>>>>>
>>>>>>>> On 7/2/2014 3:10 PM, Petr Pchelko wrote:
>>>>>>>>> Hello, Anthony, Alan.
>>>>>>>>>
>>>>>>>>> Thank you for the review, the new version is located here:
>>>>>>>>> http://cr.openjdk.java.net/~pchelko/9/8047336/webrev.01/
>>>>>>>>> <http://cr.openjdk.java.net/%7Epchelko/9/8047336/webrev.00/>
>>>>>>>>>
>>>>>>>>> I've changed the code to throw an InternalError if we cannot read
>>>>>>>>> properties.
>>>>>>>>> Once I get feedback from the build team - I'll push this fix.
>>>>>>>>>
>>>>>>>>> With best regards. Petr.
>>>>>>>>>
>>>>>>>>> On 02 ???? 2014 ?., at 13:52, Alan Bateman <Alan.Bateman at oracle.com
>>>>>>>>> <mailto:Alan.Bateman at oracle.com>> wrote:
>>>>>>>>>
>>>>>>>>>> On 01/07/2014 09:35, Petr Pchelko wrote:
>>>>>>>>>>> Hello,
>>>>>>>>>>>
>>>>>>>>>>> The changes in the public API have been approved, so let me continue
>>>>>>>>>>> the review process.
>>>>>>>>>>>
>>>>>>>>>>> For your convenience:
>>>>>>>>>>> The bug: https://bugs.openjdk.java.net/browse/JDK-8047336
>>>>>>>>>>> The fix: http://cr.openjdk.java.net/~pchelko/9/8047336/webrev.00/
>>>>>>>>>>> <http://cr.openjdk.java.net/%7Epchelko/9/8047336/webrev.00/>
>>>>>>>>>>>
>>>>>>>>>>> Until now we've been discussing an abstract question of moving the
>>>>>>>>>>> properties to a different location and agreed that it's possible.
>>>>>>>>>>> Now it's time for an official code review. Could someone please make one?
>>>>>>>>>>>
>>>>>>>>>>> Also some feedback from the build team is still required. Could
>>>>>>>>>>> someone from the build team review this fix please?
>>>>>>>>>>> (The question is that I've made a separate explicit rule for
>>>>>>>>>>> flavormap.properties file. If I add it to COPY_PATTERNS than the
>>>>>>>>>>> solaris version get's copied on Mac. Is that a bug in the build
>>>>>>>>>>> system? Is my current solution good enough?)
>>>>>>>>>>>
>>>>>>>>>> I think this looks okay. I see Anthony's mail asking about the warning
>>>>>>>>>> message and whether it should the print stack trace. I just wonder if
>>>>>>>>>> it might be saner to just throw InternalError here. It throws
>>>>>>>>>> InternalError if flavormap.properties is missing and it might be
>>>>>>>>>> consistent to do the same when the file is corrupt or can't be parsed
>>>>>>>>>> as a properties file.
>>>>>>>>>>
>>>>>>>>>> -Alan.
>>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>
>

From alexey.ivanov at oracle.com  Tue Jul 15 11:03:04 2014
From: alexey.ivanov at oracle.com (Alexey Ivanov)
Date: Tue, 15 Jul 2014 15:03:04 +0400
Subject: <AWT Dev> <Swing Dev> [7u-dev] Review request for JDK-8046559:
 NPE when changing Windows theme
In-Reply-To: <792FFA70-C541-4BC9-8A75-E97EF16916B2@oracle.com>
References: <53BEB86D.3080908@oracle.com> <53BF08E9.5090003@oracle.com>
	<792FFA70-C541-4BC9-8A75-E97EF16916B2@oracle.com>
Message-ID: <53C50A68.1050008@oracle.com>

Hi Anthony, Petr,

Thank you for your review.

Regards,
Alexey.

On 11.07.2014 9:47, Petr Pchelko wrote:
> Hello, Alexey.
>
> Looks OK to me too.
>
> With best regards. Petr.
>
>> On Jul 11, 2014, at 1:43 AM, Anthony Petrov <anthony.petrov at oracle.com> wrote:
>>
>> Hi Alexey,
>>
>> I skimmed through the changes and they look fine to me. +1.
>>
>> --
>> best regards,
>> Anthony
>>
>> On 7/10/2014 7:59 PM, Alexey Ivanov wrote:
>>> Hi AWT, Swing teams,
>>>
>>> Could you please review the backport of JDK-8046559 to jdk7:
>>>      bug: https://bugs.openjdk.java.net/browse/JDK-8046559
>>>      webrev: http://cr.openjdk.java.net/~aivanov/8046559/jdk7/webrev.00/
>>>
>>>
>>> Changes between jdk9 and jdk7:
>>>
>>> I replaced labmda expression in WToolkit.java with anonymous class.
>>> It is the only change from the previous webrev:
>>> http://mail.openjdk.java.net/pipermail/awt-dev/2014-July/008147.html
>>> http://mail.openjdk.java.net/pipermail/swing-dev/2014-July/003657.html
>>>
>>>
>>> Latest jdk9 webrev:
>>> http://cr.openjdk.java.net/~aivanov/8046559/jdk9/webrev.01/
>>>
>>>
>>> The information is below is copied from jdk9 review for the sake of
>>> completeness.
>>>
>>>
>>> Problem description:
>>> When changing Windows themes from a theme with visual styles (Windows
>>> Aero or Windows Basic) to a classic one, NullPointerException could be
>>> thrown from Swing code during component tree validation, or
>>> InternalError could be thrown during component painting.
>>>
>>> Root cause:
>>> Windows theme data are accessed via XPStyle and ThemeReader. When the
>>> theme is switched to a classic one, theme handles become unavailable,
>>> and theme data cannot be accessed any more. The change in theme is
>>> posted to EDT; at the same time, the UI often needs to repaint before
>>> the theme change is completely handled in Swing. This leads to NPE and
>>> InternalError as the code tries to access the data that has become
>>> unavailable.
>>>
>>> The fix:
>>> Windows desktop properties are updated right on Windows Toolkit thread,
>>> and the value of "win.xpstyle.themeActive" is stored in
>>> ThemeReader.xpStyleEnabled field. PropertyChangeEvents for desktop
>>> properties are delivered either synchronously on EDT or asynchronously
>>> via DesktopPropertyChangeSupport, as it used to be.
>>>
>>> Getters in XPStyle class check for null values and return dummy defaults
>>> if ThemeReader returned null. SkinPainters also check whether theming is
>>> still available before asking ThemeReader to paint.
>>>
>>> Access to XPStyle.xp instance is blocked as soon as user switches
>>> themes. The object will be cleaned when the corresponding
>>> PropertyChangeEvent is handled by Swing.
>>>
>>>
>>> This new version of the fix addresses issues found with the initial
>>> submission of JDK-8039383 fix:
>>>    - JDK-8046239: Build failure in 9-client on all non-Windows platforms
>>>    - JDK-8046391: Hang displaying JFileChooser with Windows L&F
>>>
>>> See also
>>> http://mail.openjdk.java.net/pipermail/awt-dev/2014-June/007975.html
>>> and http://cr.openjdk.java.net/~aivanov/8039383/jdk9/webrev.03/
>>>
>>>
>>> Regression test:
>>> No regression test is provided due to its complexity. Whether
>>> NullPointerException or InternalError are thrown depends on the order of
>>> event handling, sometimes exceptions do not occur when changing theme of
>>> visual styles enabled theme to a classic theme.
>>>
>>> I included regression test for hang in JFileChooser, JDK-8046391.
>>>
>>>
>>> Thank you,
>>> Alexey.


From alexandr.scherbatiy at oracle.com  Tue Jul 15 11:28:12 2014
From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy)
Date: Tue, 15 Jul 2014 15:28:12 +0400
Subject: <AWT Dev> [9] Review request for 8044444 The output's 'Page-n'
 footer does not show completely.
Message-ID: <53C5104C.4020706@oracle.com>


Hello,

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

   Native method printLoop from CPrinterJob calls 
javaPrinterJobToNSPrintInfo(...) method after 
javaPageFormatToNSPrintInfo(...).
   Both methods set the page size. The initial page size is set in 
defaultPage(PageFormat) method.
   After the fix 8011069 the printDialog() initializes attributes which 
leads that new page size is created in the 
attributeToPageFormat(PrintService, PrintRequestAttributeSet) method.

   The fix changes order of the javaPrinterJobToNSPrintInfo(...) 
javaPageFormatToNSPrintInfo(...) call so initial page size is set at the 
end.

   There is the JCK test that covers the issue.

Thanks,
Alexandr.


From anthony.petrov at oracle.com  Tue Jul 15 12:13:25 2014
From: anthony.petrov at oracle.com (Anthony Petrov)
Date: Tue, 15 Jul 2014 16:13:25 +0400
Subject: <AWT Dev> [9] Review request: 8050465 Remove sun.audio package
In-Reply-To: <88FC3515-EE2A-4A43-96E3-B3632C4A799F@oracle.com>
References: <88FC3515-EE2A-4A43-96E3-B3632C4A799F@oracle.com>
Message-ID: <53C51AE5.90402@oracle.com>

Looks fine.

--
best regards,
Anthony

On 7/15/2014 11:41 AM, Petr Pchelko wrote:
> Hello,
>
> Please review the fix for the issue:
> https://bugs.openjdk.java.net/browse/JDK-8050465
> The fix is available here:
> http://cr.openjdk.java.net/~pchelko/9/8050465/webrev/
>
> Simple clean-up. The package is not used any more and can be removed.
>
> With best regards. Petr.
>

From anthony.petrov at oracle.com  Tue Jul 15 12:16:57 2014
From: anthony.petrov at oracle.com (Anthony Petrov)
Date: Tue, 15 Jul 2014 16:16:57 +0400
Subject: <AWT Dev> [8u] Review request: 8048549 [macosx] Disable usage
 of system menu bar if AWT is embedded in FX
In-Reply-To: <AD884FF4-43D5-48B7-B150-A4BE1DD79830@oracle.com>
References: <AD884FF4-43D5-48B7-B150-A4BE1DD79830@oracle.com>
Message-ID: <53C51BB9.2060205@oracle.com>

+1

--
best regards,
Anthony

On 7/15/2014 2:01 PM, Petr Pchelko wrote:
> Hello, AWT team.
>
> Please review the fix for the issue:
> https://bugs.openjdk.java.net/browse/JDK-8048549
> The 8u version is available here:
> http://cr.openjdk.java.net/~pchelko/9/8048549/webrev.8u/
> For reference, the 9 version is available here:
> http://cr.openjdk.java.net/~pchelko/9/8048549/webrev/
>
> The 8u version is different, so a new review is needed. In 9 we've moved AWT initialization from awt.m to LWCToolkit.m, so we did not need to use ThreadUtilities.
> In 8u we need to use ThreadUtilities to figure out if AWT is running embedded or not. All the rest of the fix is the same as in 9.
>
> Thank you.
> With best regards. Petr.
>

From dmitriy.ermashov at oracle.com  Wed Jul 16 11:09:09 2014
From: dmitriy.ermashov at oracle.com (Dmitriy Ermashov)
Date: Wed, 16 Jul 2014 15:09:09 +0400
Subject: <AWT Dev> Review request for 8049694: Migrate functional
 AWT_DesktopProperties/Automated tests to OpenJDK
In-Reply-To: <53BD0B93.8040505@oracle.com>
References: <53BD0B93.8040505@oracle.com>
Message-ID: <53C65D55.1090604@oracle.com>

Hi,

Just a kindly reminder. Please review the test:
http://cr.openjdk.java.net/~dermashov/8049694/webrev.00/

Thanks,
Dima

On 07/09/2014 01:29 PM, Dmitriy Ermashov wrote:
> Hi all,
>
> Please review yet another batch of tests. To be precise, just one test.
> http://cr.openjdk.java.net/~dermashov/8049694/webrev.00/
>
> The corresponding bug:
> https://bugs.openjdk.java.net/browse/JDK-8049694
>
> This test verifies old RFE 4758438. It declares that AWT should 
> provide an access to XSETTINGS through the Toolkit.
> As you can see, the test consist of .java ans .sh files. The reason 
> for it is in different utilities for changing xsettings on different 
> OSes. E.g. old systems like Ubuntu 8.04 and Solaris 10 use gconftool-2 
> utilily while Ubuntu 14.04 use gsettings.
> So the script decides which utility to use on current platform and 
> pass the parameters to java programm.
>
> The test passes on the following platforms:
> Solaris 10 sparcv9 (Java Desktop System)
> Solaris 11 x64 (Gnome 2)
> Ubuntu 8.04 virtualbox (Gnome 2)
> Ubuntu 10.04 arm (Gnome 2)
> Ubuntu 14.04 x64 (Unity)
>
> Windows 7 x64 (test just exit with 0 code)
> OS X 10.9 (test just exit with 0 code)
>


From Sergey.Bylokhov at oracle.com  Wed Jul 16 11:31:47 2014
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Wed, 16 Jul 2014 15:31:47 +0400
Subject: <AWT Dev> [9] Review request: 8050465 Remove sun.audio package
In-Reply-To: <88FC3515-EE2A-4A43-96E3-B3632C4A799F@oracle.com>
References: <88FC3515-EE2A-4A43-96E3-B3632C4A799F@oracle.com>
Message-ID: <53C662A3.6020100@oracle.com>

Hi, Petr.
The fix looks good.

On 7/15/14 11:41 AM, Petr Pchelko wrote:
> Hello,
>
> Please review the fix for the issue:
> https://bugs.openjdk.java.net/browse/JDK-8050465
> The fix is available here:
> http://cr.openjdk.java.net/~pchelko/9/8050465/webrev/
>
> Simple clean-up. The package is not used any more and can be removed.
>
> With best regards. Petr.


-- 
Best regards, Sergey.


From dmitry.markov at oracle.com  Wed Jul 16 12:08:49 2014
From: dmitry.markov at oracle.com (dmitry markov)
Date: Wed, 16 Jul 2014 16:08:49 +0400
Subject: <AWT Dev> [9] Review request for 8044614: [macosx] Focus issue
 with 2 applets in firefox
In-Reply-To: <53B6813D.9070700@oracle.com>
References: <53B3E2B1.1030303@oracle.com> <53B3FCB5.103@oracle.com>
	<53B51F4C.6060106@oracle.com> <53B52FA1.7040001@oracle.com>
	<53B6813D.9070700@oracle.com>
Message-ID: <53C66B51.30308@oracle.com>

Hi Alexandr,

I am sorry for the delay.
When a browser's window becomes active/inactive, the browser generates 
WindowFocusEvent and sends it to the applets via Java Plugin. So the 
order of the events is defined by the browser. I tested several browsers 
- all of them sends WindowFocusEvent(parentWindow=false) to the active 
window and then WindowFocusEvent(parentWindow=true) to inactive window 
during switching between two browser's windows. It looks like this is 
common practice for such operation. However, I did not find any docs 
which can confirm this behavior.

Please find new version of the fix here - 
http://cr.openjdk.java.net/~dmarkov/8044614/jdk9/webrev.02/
Changes:
- Made small refactoring: focusedWindow -> globalFocusedWindow, 
previousFocusedWindow -> pluginFocusedWindow, etc.
- Added manual test

Thanks,
Dmitry

On 04/07/2014 14:26, Alexander Scherbatiy wrote:
> On 7/3/2014 2:25 PM, Alexander Scherbatiy wrote:
>> On 7/3/2014 1:15 PM, dmitry markov wrote:
>>> Hi Alexandr,
>>>
>>> Thank you for review.
>>> For the use case you described - when we move back to the first 
>>> browser window with 3 applets, the first applet (not the second one) 
>>> will receive the focus. This behavior is incorrect, since the second 
>>> applet should receive the focus.
>>> I have updated the fix, please find new version here: 
>>> http://cr.openjdk.java.net/~dmarkov/8044614/jdk9/webrev.01/
>>> Now we store the information about focused applet when browser 
>>> window is deactivated and restore the focus to the previously 
>>> focused applet when browser window becomes active again
>>
>>     The case can be more complicated with some browsers where each of 
>> them has several applets.
>>     It seems there should be a map between a browser and it's focused 
>> applet.
>
>    I see that your fix solves these cases.
>
>    One more problem can be with the WindowsFocusEvents order.
>    Is it guarantee that order of events WindowsFocusEvent 
> (parentwindow=false) to one browser and WindowsFocusEvent 
> (parentWindow=true)
>    for other browser can't be changed?
>
>   I would suggest to  do a small refactoring.
>   Something like focusedWindow to globalFocusedWindow, 
> previousFocusedWindow to pluginFocusedWindow, add method like 
> isPluginFocused(...)
>   and use conditional operator '?' for globalFocusedWindow setting.
>
>   Thanks,
>   Alexandr.
>
>
>>
>>
>>     Is it possible to add a manual test for the fix?
>>
>>    Thanks,
>>    Alexandr.
>>
>>>
>>> Thanks,
>>> Dmitry
>>>
>>> On 02/07/2014 16:36, Alexander Scherbatiy wrote:
>>>>
>>>>  Let's assume one browser has 3 applets where the second applet has 
>>>> focus.
>>>>  I click on the second browser with an applet (the applet receives 
>>>> the focus) and then click on the first browser back.
>>>>  Should the second applet in the first browser receive the focus?
>>>>
>>>>  Thanks,
>>>>  Alexandr.
>>>>
>>>> On 7/2/2014 2:45 PM, dmitry markov wrote:
>>>>> Hello,
>>>>>
>>>>> Could you review the fix for jdk9, please?
>>>>>
>>>>>     bug: https://bugs.openjdk.java.net/browse/JDK-8044614
>>>>>     webrev: 
>>>>> http://cr.openjdk.java.net/~dmarkov/8044614/jdk9/webrev.00/
>>>>>
>>>>> Problem description: on Mac OSX when switching between several 
>>>>> applets running in separate browser's windows, the applet in 
>>>>> active window does not receive focus.
>>>>> Fix: the method CEmbeddedFrame.handleWindowFocusEvent() should be 
>>>>> modified. It has to detect the switching between browser's windows 
>>>>> and update focusedWindow field accordingly.
>>>>>
>>>>> Thanks,
>>>>> Dmitry
>>>>
>>>
>>
>


From alexander.zvegintsev at oracle.com  Wed Jul 16 14:37:40 2014
From: alexander.zvegintsev at oracle.com (Alexander Zvegintsev)
Date: Wed, 16 Jul 2014 18:37:40 +0400
Subject: <AWT Dev> Review request for 8049694: Migrate functional
 AWT_DesktopProperties/Automated tests to OpenJDK
In-Reply-To: <53C65D55.1090604@oracle.com>
References: <53BD0B93.8040505@oracle.com> <53C65D55.1090604@oracle.com>
Message-ID: <53C68E34.4020500@oracle.com>

Hi Dmitriy,

Correct me if I am wrong:
jtreg keeps DISPLAY and strips many environment variables(e.g. 
DBUS_SESSION_BUS_ADDRESS).
DBUS_SESSION_BUS_ADDRESS variable is needed for correct work of 
gconftool-2 and gsettings
That's why we need pargs and /proc/$PID/environ.

But this test fails for me on Ubuntu 14.04.
It happens because pgrep gnome returns a PID of 
/usr/bin/gnome-keyring-daemon at first position on my system
User can't read /proc/$PID/environ due to its access rights:
-r-------- 1 root root 0 Jul 16 16:41 /proc/0000/environ

So I think that the DBUS_SESSION_BUS_ADDRESS determination should be 
improved.
I suggest to add check for DBUS_SESSION_BUS_ADDRESS and replace gnome 
with gnome-session in pgrep call
(it should be verified on all affected platforms).

Thanks,

Alexander.

On 07/16/2014 03:09 PM, Dmitriy Ermashov wrote:
> Hi,
>
> Just a kindly reminder. Please review the test:
> http://cr.openjdk.java.net/~dermashov/8049694/webrev.00/
>
> Thanks,
> Dima
>
> On 07/09/2014 01:29 PM, Dmitriy Ermashov wrote:
>> Hi all,
>>
>> Please review yet another batch of tests. To be precise, just one test.
>> http://cr.openjdk.java.net/~dermashov/8049694/webrev.00/
>>
>> The corresponding bug:
>> https://bugs.openjdk.java.net/browse/JDK-8049694
>>
>> This test verifies old RFE 4758438. It declares that AWT should 
>> provide an access to XSETTINGS through the Toolkit.
>> As you can see, the test consist of .java ans .sh files. The reason 
>> for it is in different utilities for changing xsettings on different 
>> OSes. E.g. old systems like Ubuntu 8.04 and Solaris 10 use 
>> gconftool-2 utilily while Ubuntu 14.04 use gsettings.
>> So the script decides which utility to use on current platform and 
>> pass the parameters to java programm.
>>
>> The test passes on the following platforms:
>> Solaris 10 sparcv9 (Java Desktop System)
>> Solaris 11 x64 (Gnome 2)
>> Ubuntu 8.04 virtualbox (Gnome 2)
>> Ubuntu 10.04 arm (Gnome 2)
>> Ubuntu 14.04 x64 (Unity)
>>
>> Windows 7 x64 (test just exit with 0 code)
>> OS X 10.9 (test just exit with 0 code)
>>
>

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

From dmitriy.ermashov at oracle.com  Wed Jul 16 14:47:58 2014
From: dmitriy.ermashov at oracle.com (Dmitriy Ermashov)
Date: Wed, 16 Jul 2014 18:47:58 +0400
Subject: <AWT Dev> Review request for 8049694: Migrate functional
 AWT_DesktopProperties/Automated tests to OpenJDK
In-Reply-To: <53C68E34.4020500@oracle.com>
References: <53BD0B93.8040505@oracle.com> <53C65D55.1090604@oracle.com>
	<53C68E34.4020500@oracle.com>
Message-ID: <53C6909E.8090605@oracle.com>

Hi Alexander,

On 07/16/2014 06:37 PM, Alexander Zvegintsev wrote:
> Hi Dmitriy,
>
> Correct me if I am wrong:
> jtreg keeps DISPLAY and strips many environment variables(e.g. 
> DBUS_SESSION_BUS_ADDRESS).
> DBUS_SESSION_BUS_ADDRESS variable is needed for correct work of 
> gconftool-2 and gsettings
> That's why we need pargs and /proc/$PID/environ.
Everything is right.
gconftool-2 and gsettings do not work without DBUS_SESSION_BUS_ADDRESS 
or DISPLAY variable set.
>
> But this test fails for me on Ubuntu 14.04.
> It happens because pgrep gnome returns a PID of 
> /usr/bin/gnome-keyring-daemon at first position on my system
> User can't read /proc/$PID/environ due to its access rights:
> -r-------- 1 root root 0 Jul 16 16:41 /proc/0000/environ
>
> So I think that the DBUS_SESSION_BUS_ADDRESS determination should be 
> improved.
> I suggest to add check for DBUS_SESSION_BUS_ADDRESS and replace gnome 
> with gnome-session in pgrep call
> (it should be verified on all affected platforms).
Initially there was "gnome-session" in pgrep call, but Ubuntu 8.04 has 
no such process, so the test failed.
I've changed it to "pgrep gnome | head -1"
If we do not support ubuntu 8.04, I'll just replace "pgrep gnome" with 
"pgrep gnome-session".

So the question is, do we support Ubuntu 8.04?


Thanks,
Dima
> Thanks,
>
> Alexander.
> On 07/16/2014 03:09 PM, Dmitriy Ermashov wrote:
>> Hi,
>>
>> Just a kindly reminder. Please review the test:
>> http://cr.openjdk.java.net/~dermashov/8049694/webrev.00/
>>
>> Thanks,
>> Dima
>>
>> On 07/09/2014 01:29 PM, Dmitriy Ermashov wrote:
>>> Hi all,
>>>
>>> Please review yet another batch of tests. To be precise, just one test.
>>> http://cr.openjdk.java.net/~dermashov/8049694/webrev.00/
>>>
>>> The corresponding bug:
>>> https://bugs.openjdk.java.net/browse/JDK-8049694
>>>
>>> This test verifies old RFE 4758438. It declares that AWT should 
>>> provide an access to XSETTINGS through the Toolkit.
>>> As you can see, the test consist of .java ans .sh files. The reason 
>>> for it is in different utilities for changing xsettings on different 
>>> OSes. E.g. old systems like Ubuntu 8.04 and Solaris 10 use 
>>> gconftool-2 utilily while Ubuntu 14.04 use gsettings.
>>> So the script decides which utility to use on current platform and 
>>> pass the parameters to java programm.
>>>
>>> The test passes on the following platforms:
>>> Solaris 10 sparcv9 (Java Desktop System)
>>> Solaris 11 x64 (Gnome 2)
>>> Ubuntu 8.04 virtualbox (Gnome 2)
>>> Ubuntu 10.04 arm (Gnome 2)
>>> Ubuntu 14.04 x64 (Unity)
>>>
>>> Windows 7 x64 (test just exit with 0 code)
>>> OS X 10.9 (test just exit with 0 code)
>>>
>>
>

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

From alexander.zvegintsev at oracle.com  Wed Jul 16 14:59:13 2014
From: alexander.zvegintsev at oracle.com (Alexander Zvegintsev)
Date: Wed, 16 Jul 2014 18:59:13 +0400
Subject: <AWT Dev> Review request for 8049694: Migrate functional
 AWT_DesktopProperties/Automated tests to OpenJDK
In-Reply-To: <53C6909E.8090605@oracle.com>
References: <53BD0B93.8040505@oracle.com> <53C65D55.1090604@oracle.com>
	<53C68E34.4020500@oracle.com> <53C6909E.8090605@oracle.com>
Message-ID: <53C69341.10700@oracle.com>

Dmitriy,

I think that it is unneeded to complicate the test, since even JDK8 
officially supports Ubuntu 12+ [1].

[1] http://www.oracle.com/technetwork/java/javase/certconfig-2095354.html

Thanks,

Alexander.

On 07/16/2014 06:47 PM, Dmitriy Ermashov wrote:
> Hi Alexander,
>
> On 07/16/2014 06:37 PM, Alexander Zvegintsev wrote:
>> Hi Dmitriy,
>>
>> Correct me if I am wrong:
>> jtreg keeps DISPLAY and strips many environment variables(e.g. 
>> DBUS_SESSION_BUS_ADDRESS).
>> DBUS_SESSION_BUS_ADDRESS variable is needed for correct work of 
>> gconftool-2 and gsettings
>> That's why we need pargs and /proc/$PID/environ.
> Everything is right.
> gconftool-2 and gsettings do not work without DBUS_SESSION_BUS_ADDRESS 
> or DISPLAY variable set.
>>
>> But this test fails for me on Ubuntu 14.04.
>> It happens because pgrep gnome returns a PID of 
>> /usr/bin/gnome-keyring-daemon at first position on my system
>> User can't read /proc/$PID/environ due to its access rights:
>> -r-------- 1 root root 0 Jul 16 16:41 /proc/0000/environ
>>
>> So I think that the DBUS_SESSION_BUS_ADDRESS determination should be 
>> improved.
>> I suggest to add check for DBUS_SESSION_BUS_ADDRESS and replace gnome 
>> with gnome-session in pgrep call
>> (it should be verified on all affected platforms).
> Initially there was "gnome-session" in pgrep call, but Ubuntu 8.04 has 
> no such process, so the test failed.
> I've changed it to "pgrep gnome | head -1"
> If we do not support ubuntu 8.04, I'll just replace "pgrep gnome" with 
> "pgrep gnome-session".
>
> So the question is, do we support Ubuntu 8.04?
>
>
> Thanks,
> Dima
>> Thanks,
>>
>> Alexander.
>> On 07/16/2014 03:09 PM, Dmitriy Ermashov wrote:
>>> Hi,
>>>
>>> Just a kindly reminder. Please review the test:
>>> http://cr.openjdk.java.net/~dermashov/8049694/webrev.00/
>>>
>>> Thanks,
>>> Dima
>>>
>>> On 07/09/2014 01:29 PM, Dmitriy Ermashov wrote:
>>>> Hi all,
>>>>
>>>> Please review yet another batch of tests. To be precise, just one 
>>>> test.
>>>> http://cr.openjdk.java.net/~dermashov/8049694/webrev.00/
>>>>
>>>> The corresponding bug:
>>>> https://bugs.openjdk.java.net/browse/JDK-8049694
>>>>
>>>> This test verifies old RFE 4758438. It declares that AWT should 
>>>> provide an access to XSETTINGS through the Toolkit.
>>>> As you can see, the test consist of .java ans .sh files. The reason 
>>>> for it is in different utilities for changing xsettings on 
>>>> different OSes. E.g. old systems like Ubuntu 8.04 and Solaris 10 
>>>> use gconftool-2 utilily while Ubuntu 14.04 use gsettings.
>>>> So the script decides which utility to use on current platform and 
>>>> pass the parameters to java programm.
>>>>
>>>> The test passes on the following platforms:
>>>> Solaris 10 sparcv9 (Java Desktop System)
>>>> Solaris 11 x64 (Gnome 2)
>>>> Ubuntu 8.04 virtualbox (Gnome 2)
>>>> Ubuntu 10.04 arm (Gnome 2)
>>>> Ubuntu 14.04 x64 (Unity)
>>>>
>>>> Windows 7 x64 (test just exit with 0 code)
>>>> OS X 10.9 (test just exit with 0 code)
>>>>
>>>
>>
>

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

From alexander.zvegintsev at oracle.com  Wed Jul 16 16:56:38 2014
From: alexander.zvegintsev at oracle.com (Alexander Zvegintsev)
Date: Wed, 16 Jul 2014 20:56:38 +0400
Subject: <AWT Dev> [9] Review request for 8048289 Gtk: call to
 UIManager.getSystemLookAndFeelClassName() leads to crash
Message-ID: <53C6AEC6.1040301@oracle.com>

Hello AWT team,

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

UIManager.getSystemLookAndFeelClassName() calls 
UNIXToolkit.isNativeGTKAvailable()
which loads gtk library, checks version, and closes library. Thread 
specific data key is created upon gtk dlopen,
but this key is not deleted at dlclose. This produces a crash at thread 
termination.

So this fix is a workaround for the glib issue [1], it simply doesn't 
close library.
Simple case to reproduce this issue written on C is attached to [1].

[1] https://bugzilla.gnome.org/show_bug.cgi?id=733065

-- 
Thanks,

Alexander.


From Sergey.Bylokhov at oracle.com  Wed Jul 16 16:56:38 2014
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Wed, 16 Jul 2014 20:56:38 +0400
Subject: <AWT Dev> [9] Review Request: 8050852 Javadoc cleanup of
	javax.sound.midi package
Message-ID: <53C6AEC6.7050303@oracle.com>

Hello.
Please review another one javadoc cleanup in jdk 9 in sound area:
  - @param, @return should not end with a dot, except a case when more 
than one sentences are used.
  - @param, @throws, @return now align, to be more readable.
  - @see tags simplified in some places.
  - Description of the class/method/field should be followed by dot.
  - Broken links/typos fixed
  - 80 column limit.
  - sets of spaces in the middle of text were deleted.
  - <tag> replaced by {@tag }.
  - unnecessary imports were removed.

Bug: https://bugs.openjdk.java.net/browse/JDK-8050852
See the full specdiff: 
http://cr.openjdk.java.net/~serb/8050852/javadoc/overview-summary.html
Webrev can be found at: http://cr.openjdk.java.net/~serb/8050852/webrev.02

-- 
Best regards, Sergey.


From petr.pchelko at oracle.com  Thu Jul 17 08:18:42 2014
From: petr.pchelko at oracle.com (Petr Pchelko)
Date: Thu, 17 Jul 2014 12:18:42 +0400
Subject: <AWT Dev> [9] Review Request: 8050852 Javadoc cleanup of
	javax.sound.midi package
In-Reply-To: <53C6AEC6.7050303@oracle.com>
References: <53C6AEC6.7050303@oracle.com>
Message-ID: <9D050722-1DF5-4A9A-BF5A-A1C847061D29@oracle.com>

Hello, Sergey.

The fix looks good to me.

With best regards. Petr.

On 16 ???? 2014 ?., at 20:56, Sergey Bylokhov <Sergey.Bylokhov at oracle.com> wrote:

> Hello.
> Please review another one javadoc cleanup in jdk 9 in sound area:
> - @param, @return should not end with a dot, except a case when more than one sentences are used.
> - @param, @throws, @return now align, to be more readable.
> - @see tags simplified in some places.
> - Description of the class/method/field should be followed by dot.
> - Broken links/typos fixed
> - 80 column limit.
> - sets of spaces in the middle of text were deleted.
> - <tag> replaced by {@tag }.
> - unnecessary imports were removed.
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8050852
> See the full specdiff: http://cr.openjdk.java.net/~serb/8050852/javadoc/overview-summary.html
> Webrev can be found at: http://cr.openjdk.java.net/~serb/8050852/webrev.02
> 
> -- 
> Best regards, Sergey.
> 


From anthony.petrov at oracle.com  Thu Jul 17 08:20:29 2014
From: anthony.petrov at oracle.com (Anthony Petrov)
Date: Thu, 17 Jul 2014 12:20:29 +0400
Subject: <AWT Dev> [9] Review request for 8048289 Gtk: call to
 UIManager.getSystemLookAndFeelClassName() leads to crash
In-Reply-To: <53C6AEC6.1040301@oracle.com>
References: <53C6AEC6.1040301@oracle.com>
Message-ID: <53C7874D.6000205@oracle.com>

Hi Alexander,

The fix looks fine. I'd also mention the JDK bug id in the comment at 
line 436 (no need for a new webrev with this change).

--
best regards,
Anthony

On 7/16/2014 8:56 PM, Alexander Zvegintsev wrote:
> Hello AWT team,
>
> please review the fix
> http://cr.openjdk.java.net/~azvegint/jdk/9/8048289/00/
> for the issue
> https://bugs.openjdk.java.net/browse/JDK-8048289
>
> UIManager.getSystemLookAndFeelClassName() calls
> UNIXToolkit.isNativeGTKAvailable()
> which loads gtk library, checks version, and closes library. Thread
> specific data key is created upon gtk dlopen,
> but this key is not deleted at dlclose. This produces a crash at thread
> termination.
>
> So this fix is a workaround for the glib issue [1], it simply doesn't
> close library.
> Simple case to reproduce this issue written on C is attached to [1].
>
> [1] https://bugzilla.gnome.org/show_bug.cgi?id=733065
>

From anton.nashatyrev at oracle.com  Thu Jul 17 09:14:33 2014
From: anton.nashatyrev at oracle.com (anton nashatyrev)
Date: Thu, 17 Jul 2014 13:14:33 +0400
Subject: <AWT Dev> [9] Review request for 8046495: KeyEvent can not be
 accepted in quick mouse clicking
In-Reply-To: <59E88D9A-2BF9-41CF-9128-5E5A83B39EF3@oracle.com>
References: <53B2EDEA.3010402@oracle.com>
	<B4A1F8A6-25D8-4CA2-A138-95EC14A6A881@oracle.com>
	<53B413A7.4000809@oracle.com> <53B4253A.3040406@oracle.com>
	<53B42689.4090709@oracle.com>
	<59E88D9A-2BF9-41CF-9128-5E5A83B39EF3@oracle.com>
Message-ID: <53C793F9.6010703@oracle.com>

Hello All,

     could please anyone else take a look at the fix?

Thanks!
Anton.

On 02.07.2014 19:37, Petr Pchelko wrote:
> Hello, Anton.
>
> Thanks for clarifications and additional testing.
> The fix looks good to me too.
>
> With best regards. Petr.
>
> On 02 ???? 2014 ?., at 19:34, Anton V. Tarasov 
> <anton.tarasov at oracle.com <mailto:anton.tarasov at oracle.com>> wrote:
>
>> On 02.07.2014 19:28, anton nashatyrev wrote:
>>> Hello, Anton
>>>
>>> On 02.07.2014 18:13, Anton V. Tarasov wrote:
>>>> On 02.07.2014 11:44, Petr Pchelko wrote:
>>>>> Hello, Anton.
>>>>>
>>>>> I'm not sure I have a detailed understanding of what's happening.
>>>>>
>>>>> Before your fix the timestamp of the event represented the time 
>>>>> when the event was created, and now it's the time when it's sent 
>>>>> to java.
>>>>> This might be important if some events cause other events to be 
>>>>> issued on the java side.
>>>>>
>>>>> So suppose the following:
>>>>> Toolkit thread: InputEvent#1 created      - timestamp 0
>>>>> Toolkit thread: InputEvent#2 created      - timestamp 1
>>>>> Toolkit thread: InputEvent#1 sent           - timestamp 2
>>>>> EDT: InputEvent#1 dispatched - timestamp 3
>>>>> EDT:               FocusEvent  created        - timestamp 4
>>>>> Toolkit thread: InputEvent#2 sent           - timestamp 5
>>>>>
>>>>> Before you fix we had the following event order: 
>>>>> InputEvent#1(ts=0), InputEvent#2(ts=1), FocusEvent(ts=4).
>>>>> But after your fix we will have a different order: 
>>>>> InputEvent#1(ts=2), FocusEvent(ts=4), InputEvent#2(ts=5).
>>>>> So now we would have troubles, because the Input Event will go to 
>>>>> the new focused component instead of the old one.
>>>>> Do you think that my arguments are correct? I understand that the 
>>>>> likelihood of such a situation is very low, but for me it looks 
>>>>> possible? Am I missing something?
>>>>
>>>> A timestamp for a FocusEvent is taken from 
>>>> the_most_recent_KeyEvent_time which is set on EDT when the event is 
>>>> dispatched. So the fix shouldn't affect it.
>>>>
>>>> Also, in awt_Window.cpp, when a TimedWindowEvent is created it is 
>>>> passed a timestamp got with TimeHelper::getMessageTimeUTC(). It 
>>>> appears, that the fix makes key events times even more consistent 
>>>> with it. So, from the kbd focus perspective, it shouldn't make any 
>>>> harm.
>>>>
>>>> Anton, could you just please run the following tests, at least:
>>>>
>>>> test/java/awt/Focus/6981400/*
>>>> test/java/awt/KeyboardFocusManager/TypeAhead/*
>>>
>>> I've tested with the following set:
>>> [closed]/java/awt/event/*
>>> [closed]/java/awt/Focus/*
>>> [closed]java/awt/KeyboardFocusManager/*
>>>
>>> : no unexpected failures here.
>>>
>>> I've also verified that my regression test which comes with the fix 
>>> works fine on Linux and Mac (despite the fix is Win specific).
>>
>> Great, thanks!
>>
>> Anton.
>>
>>>
>>> Thanks for review!
>>> Anton.
>>>
>>>>
>>>> Thanks,
>>>> Anton.
>>>>
>>>>>
>>>>> Another thing I do not understand is why we were used to use the 
>>>>> complicated formula instead of initializing the msg.time field 
>>>>> with the JVM current time and using it when sending the event?
>>>>> Wouldn't that resolve both your issue and the issue the original 
>>>>> fix was made for?
>>>>>
>>>>> I have a couple of comments about the code, but let's postpone 
>>>>> that until we decide on the approach.
>>>>>
>>>>> Thank you.
>>>>> With best regards. Petr.
>>>>>
>>>>> On 01 ???? 2014 ?., at 21:20, anton nashatyrev 
>>>>> <anton.nashatyrev at oracle.com <mailto:anton.nashatyrev at oracle.com>> 
>>>>> wrote:
>>>>>
>>>>>> Hello,
>>>>>>     could you please review the following fix:
>>>>>>
>>>>>> fix: http://cr.openjdk.java.net/~anashaty/8046495/9/webrev.00/ 
>>>>>> <http://cr.openjdk.java.net/%7Eanashaty/8046495/9/webrev.00/>
>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8046495
>>>>>>
>>>>>> *Problem:*
>>>>>> On Windows the later InputEvent may have earlier timestamp 
>>>>>> (getWhen()), which results in incorrect processing of enqueued 
>>>>>> input events and may also potentially be the reason of other 
>>>>>> artifacts
>>>>>>
>>>>>> *Evaluation*:
>>>>>> On Windows we have some algorithm for calculating input event 
>>>>>> timestamp: jdk/src/windows/native/sun/windows/awt_Component.cpp:2100
>>>>>> Shortly the timestamp is calculated by the following formula:
>>>>>>     when = JVM_CurrentTimeMillis() - (GetTickCount() - 
>>>>>> GetMessageTime())
>>>>>>
>>>>>> Where:
>>>>>>   JVM_CurrentTimeMillis() - the same as System.currentTimeMillis()
>>>>>>   GetTickCount() - Win32 function, current millis from boot time
>>>>>>   GetMessageTime() - Win32 function, millis from boot time of the 
>>>>>> latest native Message
>>>>>>
>>>>>> In theory the formula looks good: we are trying our best to 
>>>>>> calculate the actual time of the OS message by taking the current 
>>>>>> JVM time (JVM_CurrentTimeMillis) and adjusting it with the offset 
>>>>>> (GetTickCount - GetMessageTime) which should indicate how many 
>>>>>> milliseconds ago from the current moment (GetTickCount) the 
>>>>>> message has been actually issued (GetMessageTime).
>>>>>> In practice due to usage of different system timers by the 
>>>>>> JVM_CurrentTimeMillis and GetTickCount their values are not 
>>>>>> updated synchronously and we may get an earlier timestamp for the 
>>>>>> later event.
>>>>>>
>>>>>> *Fix*:
>>>>>> Just to use JVM_CurrentTimeMillis only as events timestamp. On 
>>>>>> Mac this is done in exactly the same way: 
>>>>>> CPlatformResponder.handleMouse/KeyEvent()
>>>>>>
>>>>>> The message time offset calculation has been introduced with the 
>>>>>> fix for JDK-4434193 
>>>>>> <https://bugs.openjdk.java.net/browse/JDK-4434193> and it seems 
>>>>>> that the issue has addressed very similar problem (At times 
>>>>>> getWhen()in ActionEvent returns higher value than the 
>>>>>> CurrentSystemTime) which has not been completely resolved in fact.
>>>>>> I also didn't find any benefits in using the existing approach:
>>>>>> - all the usages of the TimerHelper are in fact reduced to the 
>>>>>> mentioned formula: when = JVM_CurrentTimeMillis() - 
>>>>>> (GetTickCount() - GetMessageTime())
>>>>>> - GetMessageTime() always increases (except of the int overflow 
>>>>>> moments), thus we couldn't get earlier OS messages after later ones
>>>>>> - TimerHelper::windowsToUTC(DWORD windowsTime) doesn't guarantee 
>>>>>> returning the same timestamp across different calls for the same 
>>>>>> message time
>>>>>>
>>>>>> Thanks!
>>>>>> Anton.
>>>>>
>>>>
>>>
>>
>

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

From alexandr.scherbatiy at oracle.com  Thu Jul 17 10:18:41 2014
From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy)
Date: Thu, 17 Jul 2014 14:18:41 +0400
Subject: <AWT Dev> [9] Review request for 8044614: [macosx] Focus issue
 with 2 applets in firefox
In-Reply-To: <53C66B51.30308@oracle.com>
References: <53B3E2B1.1030303@oracle.com> <53B3FCB5.103@oracle.com>
	<53B51F4C.6060106@oracle.com> <53B52FA1.7040001@oracle.com>
	<53B6813D.9070700@oracle.com> <53C66B51.30308@oracle.com>
Message-ID: <53C7A301.60801@oracle.com>


   The pluginFocusedWindow is only updated after switching from one 
browser to another (after WindowFocusEvent event).
   Should it also be updated after switching from one applet to another 
in the same browser (after FocusEvent)?

   What happens if the focused applet is closed? Does the 
pluginFocusedWindow  correctly updated in this case?
   Does the closed applet receives handleFocusEvent(false) event?

    Thanks,
   Alexandr.


On 7/16/2014 4:08 PM, dmitry markov wrote:
> Hi Alexandr,
>
> I am sorry for the delay.
> When a browser's window becomes active/inactive, the browser generates 
> WindowFocusEvent and sends it to the applets via Java Plugin. So the 
> order of the events is defined by the browser. I tested several 
> browsers - all of them sends WindowFocusEvent(parentWindow=false) to 
> the active window and then WindowFocusEvent(parentWindow=true) to 
> inactive window during switching between two browser's windows. It 
> looks like this is common practice for such operation. However, I did 
> not find any docs which can confirm this behavior.
>
> Please find new version of the fix here - 
> http://cr.openjdk.java.net/~dmarkov/8044614/jdk9/webrev.02/
> Changes:
> - Made small refactoring: focusedWindow -> globalFocusedWindow, 
> previousFocusedWindow -> pluginFocusedWindow, etc.
> - Added manual test
>
> Thanks,
> Dmitry
>
> On 04/07/2014 14:26, Alexander Scherbatiy wrote:
>> On 7/3/2014 2:25 PM, Alexander Scherbatiy wrote:
>>> On 7/3/2014 1:15 PM, dmitry markov wrote:
>>>> Hi Alexandr,
>>>>
>>>> Thank you for review.
>>>> For the use case you described - when we move back to the first 
>>>> browser window with 3 applets, the first applet (not the second 
>>>> one) will receive the focus. This behavior is incorrect, since the 
>>>> second applet should receive the focus.
>>>> I have updated the fix, please find new version here: 
>>>> http://cr.openjdk.java.net/~dmarkov/8044614/jdk9/webrev.01/
>>>> Now we store the information about focused applet when browser 
>>>> window is deactivated and restore the focus to the previously 
>>>> focused applet when browser window becomes active again
>>>
>>>     The case can be more complicated with some browsers where each 
>>> of them has several applets.
>>>     It seems there should be a map between a browser and it's 
>>> focused applet.
>>
>>    I see that your fix solves these cases.
>>
>>    One more problem can be with the WindowsFocusEvents order.
>>    Is it guarantee that order of events WindowsFocusEvent 
>> (parentwindow=false) to one browser and WindowsFocusEvent 
>> (parentWindow=true)
>>    for other browser can't be changed?
>>
>>   I would suggest to  do a small refactoring.
>>   Something like focusedWindow to globalFocusedWindow, 
>> previousFocusedWindow to pluginFocusedWindow, add method like 
>> isPluginFocused(...)
>>   and use conditional operator '?' for globalFocusedWindow setting.
>>
>>   Thanks,
>>   Alexandr.
>>
>>
>>>
>>>
>>>     Is it possible to add a manual test for the fix?
>>>
>>>    Thanks,
>>>    Alexandr.
>>>
>>>>
>>>> Thanks,
>>>> Dmitry
>>>>
>>>> On 02/07/2014 16:36, Alexander Scherbatiy wrote:
>>>>>
>>>>>  Let's assume one browser has 3 applets where the second applet 
>>>>> has focus.
>>>>>  I click on the second browser with an applet (the applet receives 
>>>>> the focus) and then click on the first browser back.
>>>>>  Should the second applet in the first browser receive the focus?
>>>>>
>>>>>  Thanks,
>>>>>  Alexandr.
>>>>>
>>>>> On 7/2/2014 2:45 PM, dmitry markov wrote:
>>>>>> Hello,
>>>>>>
>>>>>> Could you review the fix for jdk9, please?
>>>>>>
>>>>>>     bug: https://bugs.openjdk.java.net/browse/JDK-8044614
>>>>>>     webrev: 
>>>>>> http://cr.openjdk.java.net/~dmarkov/8044614/jdk9/webrev.00/
>>>>>>
>>>>>> Problem description: on Mac OSX when switching between several 
>>>>>> applets running in separate browser's windows, the applet in 
>>>>>> active window does not receive focus.
>>>>>> Fix: the method CEmbeddedFrame.handleWindowFocusEvent() should be 
>>>>>> modified. It has to detect the switching between browser's 
>>>>>> windows and update focusedWindow field accordingly.
>>>>>>
>>>>>> Thanks,
>>>>>> Dmitry
>>>>>
>>>>
>>>
>>
>


From petr.pchelko at oracle.com  Thu Jul 17 11:07:11 2014
From: petr.pchelko at oracle.com (Petr Pchelko)
Date: Thu, 17 Jul 2014 15:07:11 +0400
Subject: <AWT Dev> [9] Review Request: 8037485 Refactor
	java.awt.datatransfer to eliminate dependency on AWT
Message-ID: <AC897956-F1CC-457F-B99D-24082558C011@oracle.com>

Hello,

Please review the fix for the issue:
https://bugs.openjdk.java.net/browse/JDK-8037485
The fix is available at:
http://cr.openjdk.java.net/~pchelko/9/8037485/webrev.00

This fix separates the public datatransfer API from the desktop module. The datatransfer module would contain java.awt.datatransfer and sun.awt.datatransfer packages.
The sun.awt.datatransfer.desktop contains platform-dependent features of the datatransfer system and belongs to the desktop module. So, most of the changes are just package renaming.

DataTransferer class was split into 2 parts:
1. Utilities to work with the DataFlavor is moved to the DataFlavorUtil class. It's just a collection of uility functions and classes
2. Java objects to native representation converters are left in the DataTransferer class and moved to the desktop module. It's needed only with DnD and system clipboard API, so it naturally belong to desktop.

DesktopDatatransferServices was created. This is a collection of services that datatrasfer module could use from desktop if desktop is present. ServiceLoader is used because reflection does not cross module boundaries for non-exported APIs

RMIAccessServices - a collection of services which RMI module might provide to desktop and datatransfer. If RMI module is present we can transfer RMI classes. If not - we cannot. 

The fix was tested on all platforms with jtreg and JCK. No new test failures found. Also the fix was tested without the RMI and without the desktop module.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20140717/2dcf5710/attachment.html>

From petr.pchelko at oracle.com  Thu Jul 17 12:03:07 2014
From: petr.pchelko at oracle.com (Petr Pchelko)
Date: Thu, 17 Jul 2014 16:03:07 +0400
Subject: <AWT Dev> [9] Review Request: 8035568 [macosx] Cursor
	management unification.
In-Reply-To: <53BFC75E.80906@oracle.com>
References: <9F76EFF5-02F6-4205-A120-D7ADAF0D7B66@oracle.com>
	<53BFC75E.80906@oracle.com>
Message-ID: <CCB68BB7-C43B-4B64-AFAB-BF7892C9B2EC@oracle.com>

Hello,

Thank you for the review, the new version is here:
http://cr.openjdk.java.net/~pchelko/9/8035568/webrev.01/

Mike wrote:
> Has this change been tested on Retina? I don't see any effort to convert in and out of the screen coordinate system.
Yes, it works fine on Retina. Where should we convert the coords?  CGEventGetLocation gives us coors in logical pixels and that's exactly what we need. Am I missing something?

Anthony wrote:
> 1. src/macosx/classes/sun/lwawt/LWMouseInfoPeer.java
>>  55         // Most likely the cached window under cursor is correct and we do not need the native check.
> 
> Perhaps instead it would make sense to describe here when the first condition may fail and the native check could actually become useful? Otherwise the current comment doesn't add much value to understanding the code.
Done. I've removed the non-native check as it might be wrong.

> . src/macosx/native/sun/awt/AWTWindow.m
>> -    AWT_ASSERT_APPKIT_THREAD;
>> 
>> +    [ThreadUtilities performOnMainThreadWaiting:YES block:^{
> 
> This looks okay. But I'm wondering whether this could cause any dead locks potentially? I'd suggest to run other tests that may involve (maybe indirectly) calling the nativeGetTopmostPlatformWindowUnderMouse method (grab/ungrab? focus? modal dialogs? tooltips/popups? maybe something else).
Normally nativeGetTopmostPlatformWindowUnderMouse is called on the Appkit thread. It's called from EDT only in isWindowUnderMouse function, and it's not used too much in out code. 

> 3. src/macosx/native/sun/awt/CCursorManager.m
>> -    [ThreadUtilities performOnMainThreadWaiting:YES block:^(){
> 
> Is it OK to call Core Graphics functions on a thread other than the main thread?
According to Apple, yes: "Quartz is thread safe on the whole, but individual Quartz objects are not. In general, you can operate on any object on any thread as long as you guarantee that no two threads are operating on the same object simultaneously. The easiest way to achieve this is to not share your objects between threads."

With best regards. Petr.

On 11 ???? 2014 ?., at 15:15, Anthony Petrov <anthony.petrov at oracle.com> wrote:

> Hi Petr,
> 
> The fix looks good to me overall. A few comments:
> 
> 1. src/macosx/classes/sun/lwawt/LWMouseInfoPeer.java
>>  55         // Most likely the cached window under cursor is correct and we do not need the native check.
> 
> Perhaps instead it would make sense to describe here when the first condition may fail and the native check could actually become useful? Otherwise the current comment doesn't add much value to understanding the code.
> 
> 
> 2. src/macosx/native/sun/awt/AWTWindow.m
>> -    AWT_ASSERT_APPKIT_THREAD;
>> 
>> +    [ThreadUtilities performOnMainThreadWaiting:YES block:^{
> 
> This looks okay. But I'm wondering whether this could cause any dead locks potentially? I'd suggest to run other tests that may involve (maybe indirectly) calling the nativeGetTopmostPlatformWindowUnderMouse method (grab/ungrab? focus? modal dialogs? tooltips/popups? maybe something else).
> 
> 
> 3. src/macosx/native/sun/awt/CCursorManager.m
>> -    [ThreadUtilities performOnMainThreadWaiting:YES block:^(){
> 
> Is it OK to call Core Graphics functions on a thread other than the main thread?
> 
> --
> best regards,
> Anthony
> 
> On 7/8/2014 2:19 PM, Petr Pchelko wrote:
>> Hello, AWT Team.
>> 
>> Please review the fix for the issue:
>> https://bugs.openjdk.java.net/browse/JDK-8035568
>> The fix is available at:
>> http://cr.openjdk.java.net/~pchelko/9/8035568/webrev.00/
>> 
>> We are using 2 different methods for getting a cursor position in Robot and in LWAWT. I've changed our implementation to use Carbon method.
>> nativeGetCursorPosition is a very hot method and changing it's implementation makes it run 35 times faster. Also we will never deadlock on it any more.
>> However, I needed to change the isWindowUnderMouse implementation. The problem's that LWWindowPeer.windowUnderCursor is updated on mouse events
>> and generated mouse events, so sometimes it may be not updated when called from a component resize handler. Luckily we can test it using native code.
>> isWindowUnderMouse is not a hot method at all, in real apps it's called very rarely (never called after a couple of hours of real IDE usage) so it's not a problem that it
>> runs slower now.
>> 
>> I've run all cursor/mouse tests. A couple of tests failed because they didn't have proper synchronization and we are too fast for them now. I've fixed it and open-sourced the tests.
>> 
>> With best regards. Petr.
>> 


From Sergey.Bylokhov at oracle.com  Thu Jul 17 12:15:36 2014
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Thu, 17 Jul 2014 16:15:36 +0400
Subject: <AWT Dev> [9] Review request for 8048289 Gtk: call to
 UIManager.getSystemLookAndFeelClassName() leads to crash
In-Reply-To: <53C6AEC6.1040301@oracle.com>
References: <53C6AEC6.1040301@oracle.com>
Message-ID: <53C7BE68.3090304@oracle.com>

Hi, Alexander.
As far as I remember, we have a code, which closes this lib for the 
usual usage of gtk look and feel. Looks like we never call it, but if we 
call it it will cause the same crash? Can you investigate that? Thanks.

On 7/16/14 8:56 PM, Alexander Zvegintsev wrote:
> Hello AWT team,
>
> please review the fix
> http://cr.openjdk.java.net/~azvegint/jdk/9/8048289/00/
> for the issue
> https://bugs.openjdk.java.net/browse/JDK-8048289
>
> UIManager.getSystemLookAndFeelClassName() calls 
> UNIXToolkit.isNativeGTKAvailable()
> which loads gtk library, checks version, and closes library. Thread 
> specific data key is created upon gtk dlopen,
> but this key is not deleted at dlclose. This produces a crash at 
> thread termination.
>
> So this fix is a workaround for the glib issue [1], it simply doesn't 
> close library.
> Simple case to reproduce this issue written on C is attached to [1].
>
> [1] https://bugzilla.gnome.org/show_bug.cgi?id=733065
>


-- 
Best regards, Sergey.


From Sergey.Bylokhov at oracle.com  Thu Jul 17 12:28:42 2014
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Thu, 17 Jul 2014 16:28:42 +0400
Subject: <AWT Dev> [9] Review Request: 8035568 [macosx] Cursor
	management unification.
In-Reply-To: <CCB68BB7-C43B-4B64-AFAB-BF7892C9B2EC@oracle.com>
References: <9F76EFF5-02F6-4205-A120-D7ADAF0D7B66@oracle.com>
	<53BFC75E.80906@oracle.com>
	<CCB68BB7-C43B-4B64-AFAB-BF7892C9B2EC@oracle.com>
Message-ID: <53C7C17A.1090508@oracle.com>

Hi, Petr.
Is it possible in LWMouseInfoPeer that windowPeer == null?

On 7/17/14 4:03 PM, Petr Pchelko wrote:
> Hello,
>
> Thank you for the review, the new version is here:
> http://cr.openjdk.java.net/~pchelko/9/8035568/webrev.01/
>
> Mike wrote:
>> Has this change been tested on Retina? I don't see any effort to convert in and out of the screen coordinate system.
> Yes, it works fine on Retina. Where should we convert the coords?  CGEventGetLocation gives us coors in logical pixels and that's exactly what we need. Am I missing something?
>
> Anthony wrote:
>> 1. src/macosx/classes/sun/lwawt/LWMouseInfoPeer.java
>>>   55         // Most likely the cached window under cursor is correct and we do not need the native check.
>> Perhaps instead it would make sense to describe here when the first condition may fail and the native check could actually become useful? Otherwise the current comment doesn't add much value to understanding the code.
> Done. I've removed the non-native check as it might be wrong.
>
>> . src/macosx/native/sun/awt/AWTWindow.m
>>> -    AWT_ASSERT_APPKIT_THREAD;
>>>
>>> +    [ThreadUtilities performOnMainThreadWaiting:YES block:^{
>> This looks okay. But I'm wondering whether this could cause any dead locks potentially? I'd suggest to run other tests that may involve (maybe indirectly) calling the nativeGetTopmostPlatformWindowUnderMouse method (grab/ungrab? focus? modal dialogs? tooltips/popups? maybe something else).
> Normally nativeGetTopmostPlatformWindowUnderMouse is called on the Appkit thread. It's called from EDT only in isWindowUnderMouse function, and it's not used too much in out code.
>
>> 3. src/macosx/native/sun/awt/CCursorManager.m
>>> -    [ThreadUtilities performOnMainThreadWaiting:YES block:^(){
>> Is it OK to call Core Graphics functions on a thread other than the main thread?
> According to Apple, yes: "Quartz is thread safe on the whole, but individual Quartz objects are not. In general, you can operate on any object on any thread as long as you guarantee that no two threads are operating on the same object simultaneously. The easiest way to achieve this is to not share your objects between threads."
>
> With best regards. Petr.
>
> On 11 ???? 2014 ?., at 15:15, Anthony Petrov <anthony.petrov at oracle.com> wrote:
>
>> Hi Petr,
>>
>> The fix looks good to me overall. A few comments:
>>
>> 1. src/macosx/classes/sun/lwawt/LWMouseInfoPeer.java
>>>   55         // Most likely the cached window under cursor is correct and we do not need the native check.
>> Perhaps instead it would make sense to describe here when the first condition may fail and the native check could actually become useful? Otherwise the current comment doesn't add much value to understanding the code.
>>
>>
>> 2. src/macosx/native/sun/awt/AWTWindow.m
>>> -    AWT_ASSERT_APPKIT_THREAD;
>>>
>>> +    [ThreadUtilities performOnMainThreadWaiting:YES block:^{
>> This looks okay. But I'm wondering whether this could cause any dead locks potentially? I'd suggest to run other tests that may involve (maybe indirectly) calling the nativeGetTopmostPlatformWindowUnderMouse method (grab/ungrab? focus? modal dialogs? tooltips/popups? maybe something else).
>>
>>
>> 3. src/macosx/native/sun/awt/CCursorManager.m
>>> -    [ThreadUtilities performOnMainThreadWaiting:YES block:^(){
>> Is it OK to call Core Graphics functions on a thread other than the main thread?
>>
>> --
>> best regards,
>> Anthony
>>
>> On 7/8/2014 2:19 PM, Petr Pchelko wrote:
>>> Hello, AWT Team.
>>>
>>> Please review the fix for the issue:
>>> https://bugs.openjdk.java.net/browse/JDK-8035568
>>> The fix is available at:
>>> http://cr.openjdk.java.net/~pchelko/9/8035568/webrev.00/
>>>
>>> We are using 2 different methods for getting a cursor position in Robot and in LWAWT. I've changed our implementation to use Carbon method.
>>> nativeGetCursorPosition is a very hot method and changing it's implementation makes it run 35 times faster. Also we will never deadlock on it any more.
>>> However, I needed to change the isWindowUnderMouse implementation. The problem's that LWWindowPeer.windowUnderCursor is updated on mouse events
>>> and generated mouse events, so sometimes it may be not updated when called from a component resize handler. Luckily we can test it using native code.
>>> isWindowUnderMouse is not a hot method at all, in real apps it's called very rarely (never called after a couple of hours of real IDE usage) so it's not a problem that it
>>> runs slower now.
>>>
>>> I've run all cursor/mouse tests. A couple of tests failed because they didn't have proper synchronization and we are too fast for them now. I've fixed it and open-sourced the tests.
>>>
>>> With best regards. Petr.
>>>


-- 
Best regards, Sergey.

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

From petr.pchelko at oracle.com  Thu Jul 17 12:38:20 2014
From: petr.pchelko at oracle.com (Petr Pchelko)
Date: Thu, 17 Jul 2014 16:38:20 +0400
Subject: <AWT Dev> [9] Review Request: 8035568 [macosx] Cursor
	management unification.
In-Reply-To: <53C7C17A.1090508@oracle.com>
References: <9F76EFF5-02F6-4205-A120-D7ADAF0D7B66@oracle.com>
	<53BFC75E.80906@oracle.com>
	<CCB68BB7-C43B-4B64-AFAB-BF7892C9B2EC@oracle.com>
	<53C7C17A.1090508@oracle.com>
Message-ID: <BF60DD92-9E27-4ABD-849B-441F2E128DF3@oracle.com>

Hello, Sergey.

> Is it possible in  LWMouseInfoPeer that windowPeer == null?
Yes, it's possible. 
Thank you for this catch, updated the webrev:
http://cr.openjdk.java.net/~pchelko/9/8035568/webrev.02/

With best regards. Petr.

On 17 ???? 2014 ?., at 16:28, Sergey Bylokhov <Sergey.Bylokhov at oracle.com> wrote:

> Hi, Petr.
> Is it possible in  LWMouseInfoPeer that windowPeer == null?
> 
> On 7/17/14 4:03 PM, Petr Pchelko wrote:
>> Hello,
>> 
>> Thank you for the review, the new version is here:
>> http://cr.openjdk.java.net/~pchelko/9/8035568/webrev.01/
>> 
>> Mike wrote:
>>> Has this change been tested on Retina? I don't see any effort to convert in and out of the screen coordinate system.
>> Yes, it works fine on Retina. Where should we convert the coords?  CGEventGetLocation gives us coors in logical pixels and that's exactly what we need. Am I missing something?
>> 
>> Anthony wrote:
>>> 1. src/macosx/classes/sun/lwawt/LWMouseInfoPeer.java
>>>>  55         // Most likely the cached window under cursor is correct and we do not need the native check.
>>> Perhaps instead it would make sense to describe here when the first condition may fail and the native check could actually become useful? Otherwise the current comment doesn't add much value to understanding the code.
>> Done. I've removed the non-native check as it might be wrong.
>> 
>>> . src/macosx/native/sun/awt/AWTWindow.m
>>>> -    AWT_ASSERT_APPKIT_THREAD;
>>>> 
>>>> +    [ThreadUtilities performOnMainThreadWaiting:YES block:^{
>>> This looks okay. But I'm wondering whether this could cause any dead locks potentially? I'd suggest to run other tests that may involve (maybe indirectly) calling the nativeGetTopmostPlatformWindowUnderMouse method (grab/ungrab? focus? modal dialogs? tooltips/popups? maybe something else).
>> Normally nativeGetTopmostPlatformWindowUnderMouse is called on the Appkit thread. It's called from EDT only in isWindowUnderMouse function, and it's not used too much in out code. 
>> 
>>> 3. src/macosx/native/sun/awt/CCursorManager.m
>>>> -    [ThreadUtilities performOnMainThreadWaiting:YES block:^(){
>>> Is it OK to call Core Graphics functions on a thread other than the main thread?
>> According to Apple, yes: "Quartz is thread safe on the whole, but individual Quartz objects are not. In general, you can operate on any object on any thread as long as you guarantee that no two threads are operating on the same object simultaneously. The easiest way to achieve this is to not share your objects between threads."
>> 
>> With best regards. Petr.
>> 
>> On 11 ???? 2014 ?., at 15:15, Anthony Petrov <anthony.petrov at oracle.com> wrote:
>> 
>>> Hi Petr,
>>> 
>>> The fix looks good to me overall. A few comments:
>>> 
>>> 1. src/macosx/classes/sun/lwawt/LWMouseInfoPeer.java
>>>>  55         // Most likely the cached window under cursor is correct and we do not need the native check.
>>> Perhaps instead it would make sense to describe here when the first condition may fail and the native check could actually become useful? Otherwise the current comment doesn't add much value to understanding the code.
>>> 
>>> 
>>> 2. src/macosx/native/sun/awt/AWTWindow.m
>>>> -    AWT_ASSERT_APPKIT_THREAD;
>>>> 
>>>> +    [ThreadUtilities performOnMainThreadWaiting:YES block:^{
>>> This looks okay. But I'm wondering whether this could cause any dead locks potentially? I'd suggest to run other tests that may involve (maybe indirectly) calling the nativeGetTopmostPlatformWindowUnderMouse method (grab/ungrab? focus? modal dialogs? tooltips/popups? maybe something else).
>>> 
>>> 
>>> 3. src/macosx/native/sun/awt/CCursorManager.m
>>>> -    [ThreadUtilities performOnMainThreadWaiting:YES block:^(){
>>> Is it OK to call Core Graphics functions on a thread other than the main thread?
>>> 
>>> --
>>> best regards,
>>> Anthony
>>> 
>>> On 7/8/2014 2:19 PM, Petr Pchelko wrote:
>>>> Hello, AWT Team.
>>>> 
>>>> Please review the fix for the issue:
>>>> https://bugs.openjdk.java.net/browse/JDK-8035568
>>>> The fix is available at:
>>>> http://cr.openjdk.java.net/~pchelko/9/8035568/webrev.00/
>>>> 
>>>> We are using 2 different methods for getting a cursor position in Robot and in LWAWT. I've changed our implementation to use Carbon method.
>>>> nativeGetCursorPosition is a very hot method and changing it's implementation makes it run 35 times faster. Also we will never deadlock on it any more.
>>>> However, I needed to change the isWindowUnderMouse implementation. The problem's that LWWindowPeer.windowUnderCursor is updated on mouse events
>>>> and generated mouse events, so sometimes it may be not updated when called from a component resize handler. Luckily we can test it using native code.
>>>> isWindowUnderMouse is not a hot method at all, in real apps it's called very rarely (never called after a couple of hours of real IDE usage) so it's not a problem that it
>>>> runs slower now.
>>>> 
>>>> I've run all cursor/mouse tests. A couple of tests failed because they didn't have proper synchronization and we are too fast for them now. I've fixed it and open-sourced the tests.
>>>> 
>>>> With best regards. Petr.
>>>> 
> 
> 
> -- 
> Best regards, Sergey. 

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

From Sergey.Bylokhov at oracle.com  Thu Jul 17 13:14:22 2014
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Thu, 17 Jul 2014 17:14:22 +0400
Subject: <AWT Dev> [9] Review Request: 8035568 [macosx] Cursor
	management unification.
In-Reply-To: <BF60DD92-9E27-4ABD-849B-441F2E128DF3@oracle.com>
References: <9F76EFF5-02F6-4205-A120-D7ADAF0D7B66@oracle.com>
	<53BFC75E.80906@oracle.com>
	<CCB68BB7-C43B-4B64-AFAB-BF7892C9B2EC@oracle.com>
	<53C7C17A.1090508@oracle.com>
	<BF60DD92-9E27-4ABD-849B-441F2E128DF3@oracle.com>
Message-ID: <53C7CC2E.6010003@oracle.com>

Hi, Petr.
The fix looks good. I assume PlatformLibraries.gmk is from another fixes.
On 7/17/14 4:38 PM, Petr Pchelko wrote:
> Hello, Sergey.
>
>> Is it possible in  LWMouseInfoPeer that windowPeer == null?
> Yes, it's possible.
> Thank you for this catch, updated the webrev:
> http://cr.openjdk.java.net/~pchelko/9/8035568/webrev.02/ 
> <http://cr.openjdk.java.net/%7Epchelko/9/8035568/webrev.02/>
>
> With best regards. Petr.
>
> On 17 ???? 2014 ?., at 16:28, Sergey Bylokhov 
> <Sergey.Bylokhov at oracle.com <mailto:Sergey.Bylokhov at oracle.com>> wrote:
>
>> Hi, Petr.
>> Is it possible in LWMouseInfoPeer that windowPeer == null?
>>
>> On 7/17/14 4:03 PM, Petr Pchelko wrote:
>>> Hello,
>>>
>>> Thank you for the review, the new version is here:
>>> http://cr.openjdk.java.net/~pchelko/9/8035568/webrev.01/
>>>
>>> Mike wrote:
>>>> Has this change been tested on Retina? I don't see any effort to convert in and out of the screen coordinate system.
>>> Yes, it works fine on Retina. Where should we convert the coords?  CGEventGetLocation gives us coors in logical pixels and that's exactly what we need. Am I missing something?
>>>
>>> Anthony wrote:
>>>> 1. src/macosx/classes/sun/lwawt/LWMouseInfoPeer.java
>>>>>   55         // Most likely the cached window under cursor is correct and we do not need the native check.
>>>> Perhaps instead it would make sense to describe here when the first condition may fail and the native check could actually become useful? Otherwise the current comment doesn't add much value to understanding the code.
>>> Done. I've removed the non-native check as it might be wrong.
>>>
>>>> . src/macosx/native/sun/awt/AWTWindow.m
>>>>> -    AWT_ASSERT_APPKIT_THREAD;
>>>>>
>>>>> +    [ThreadUtilities performOnMainThreadWaiting:YES block:^{
>>>> This looks okay. But I'm wondering whether this could cause any dead locks potentially? I'd suggest to run other tests that may involve (maybe indirectly) calling the nativeGetTopmostPlatformWindowUnderMouse method (grab/ungrab? focus? modal dialogs? tooltips/popups? maybe something else).
>>> Normally nativeGetTopmostPlatformWindowUnderMouse is called on the Appkit thread. It's called from EDT only in isWindowUnderMouse function, and it's not used too much in out code.
>>>
>>>> 3. src/macosx/native/sun/awt/CCursorManager.m
>>>>> -    [ThreadUtilities performOnMainThreadWaiting:YES block:^(){
>>>> Is it OK to call Core Graphics functions on a thread other than the main thread?
>>> According to Apple, yes: "Quartz is thread safe on the whole, but individual Quartz objects are not. In general, you can operate on any object on any thread as long as you guarantee that no two threads are operating on the same object simultaneously. The easiest way to achieve this is to not share your objects between threads."
>>>
>>> With best regards. Petr.
>>>
>>> On 11 ???? 2014 ?., at 15:15, Anthony Petrov<anthony.petrov at oracle.com>  wrote:
>>>
>>>> Hi Petr,
>>>>
>>>> The fix looks good to me overall. A few comments:
>>>>
>>>> 1. src/macosx/classes/sun/lwawt/LWMouseInfoPeer.java
>>>>>   55         // Most likely the cached window under cursor is correct and we do not need the native check.
>>>> Perhaps instead it would make sense to describe here when the first condition may fail and the native check could actually become useful? Otherwise the current comment doesn't add much value to understanding the code.
>>>>
>>>>
>>>> 2. src/macosx/native/sun/awt/AWTWindow.m
>>>>> -    AWT_ASSERT_APPKIT_THREAD;
>>>>>
>>>>> +    [ThreadUtilities performOnMainThreadWaiting:YES block:^{
>>>> This looks okay. But I'm wondering whether this could cause any dead locks potentially? I'd suggest to run other tests that may involve (maybe indirectly) calling the nativeGetTopmostPlatformWindowUnderMouse method (grab/ungrab? focus? modal dialogs? tooltips/popups? maybe something else).
>>>>
>>>>
>>>> 3. src/macosx/native/sun/awt/CCursorManager.m
>>>>> -    [ThreadUtilities performOnMainThreadWaiting:YES block:^(){
>>>> Is it OK to call Core Graphics functions on a thread other than the main thread?
>>>>
>>>> --
>>>> best regards,
>>>> Anthony
>>>>
>>>> On 7/8/2014 2:19 PM, Petr Pchelko wrote:
>>>>> Hello, AWT Team.
>>>>>
>>>>> Please review the fix for the issue:
>>>>> https://bugs.openjdk.java.net/browse/JDK-8035568
>>>>> The fix is available at:
>>>>> http://cr.openjdk.java.net/~pchelko/9/8035568/webrev.00/
>>>>>
>>>>> We are using 2 different methods for getting a cursor position in Robot and in LWAWT. I've changed our implementation to use Carbon method.
>>>>> nativeGetCursorPosition is a very hot method and changing it's implementation makes it run 35 times faster. Also we will never deadlock on it any more.
>>>>> However, I needed to change the isWindowUnderMouse implementation. The problem's that LWWindowPeer.windowUnderCursor is updated on mouse events
>>>>> and generated mouse events, so sometimes it may be not updated when called from a component resize handler. Luckily we can test it using native code.
>>>>> isWindowUnderMouse is not a hot method at all, in real apps it's called very rarely (never called after a couple of hours of real IDE usage) so it's not a problem that it
>>>>> runs slower now.
>>>>>
>>>>> I've run all cursor/mouse tests. A couple of tests failed because they didn't have proper synchronization and we are too fast for them now. I've fixed it and open-sourced the tests.
>>>>>
>>>>> With best regards. Petr.
>>>>>
>>
>>
>> -- 
>> Best regards, Sergey.
>


-- 
Best regards, Sergey.

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

From alexander.zvegintsev at oracle.com  Thu Jul 17 15:02:15 2014
From: alexander.zvegintsev at oracle.com (Alexander Zvegintsev)
Date: Thu, 17 Jul 2014 19:02:15 +0400
Subject: <AWT Dev> [9] Review request for 8048289 Gtk: call to
 UIManager.getSystemLookAndFeelClassName() leads to crash
In-Reply-To: <53C7BE68.3090304@oracle.com>
References: <53C6AEC6.1040301@oracle.com> <53C7BE68.3090304@oracle.com>
Message-ID: <53C7E577.9040605@oracle.com>

Hi Sergey,
You are right: UNIXToolkit.unload_gtk() is never called. But it will not 
crash if we call it, somehow gtk-init-check()[1] call allows to avoid crash.
However I want to leave this fix as simple as it is now, since 
gdk_threads_init()[2] should be called prior to gtk_init_check(),
and it is unnecessaryfor a simple version check.

[1] https://developer.gnome.org/gtk2/stable/gtk2-General.html#gtk-init-check
[2] 
https://developer.gnome.org/gdk2/stable/gdk2-Threads.html#gdk-threads-init

--
Thanks,
Alexander.

On 07/17/2014 04:15 PM, Sergey Bylokhov wrote:
> Hi, Alexander.
> As far as I remember, we have a code, which closes this lib for the 
> usual usage of gtk look and feel. Looks like we never call it, but if 
> we call it it will cause the same crash? Can you investigate that? 
> Thanks.
>
> On 7/16/14 8:56 PM, Alexander Zvegintsev wrote:
>> Hello AWT team,
>>
>> please review the fix
>> http://cr.openjdk.java.net/~azvegint/jdk/9/8048289/00/
>> for the issue
>> https://bugs.openjdk.java.net/browse/JDK-8048289
>>
>> UIManager.getSystemLookAndFeelClassName() calls 
>> UNIXToolkit.isNativeGTKAvailable()
>> which loads gtk library, checks version, and closes library. Thread 
>> specific data key is created upon gtk dlopen,
>> but this key is not deleted at dlclose. This produces a crash at 
>> thread termination.
>>
>> So this fix is a workaround for the glib issue [1], it simply doesn't 
>> close library.
>> Simple case to reproduce this issue written on C is attached to [1].
>>
>> [1] https://bugzilla.gnome.org/show_bug.cgi?id=733065
>>
>
>

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

From Sergey.Bylokhov at oracle.com  Thu Jul 17 16:16:50 2014
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Thu, 17 Jul 2014 20:16:50 +0400
Subject: <AWT Dev> [9] Review request for 8048289 Gtk: call to
 UIManager.getSystemLookAndFeelClassName() leads to crash
In-Reply-To: <53C7E577.9040605@oracle.com>
References: <53C6AEC6.1040301@oracle.com> <53C7BE68.3090304@oracle.com>
	<53C7E577.9040605@oracle.com>
Message-ID: <53C7F6F2.2040300@oracle.com>

Hi, Alexander.
Then the fix looks fine. Thanks!

On 7/17/14 7:02 PM, Alexander Zvegintsev wrote:
> Hi Sergey,
> You are right: UNIXToolkit.unload_gtk() is never called. But it will 
> not crash if we call it, somehow gtk-init-check()[1] call allows to 
> avoid crash.
> However I want to leave this fix as simple as it is now, since 
> gdk_threads_init()[2] should be called prior to gtk_init_check(),
> and it is unnecessaryfor a simple version check.
>
> [1] 
> https://developer.gnome.org/gtk2/stable/gtk2-General.html#gtk-init-check
> [2] 
> https://developer.gnome.org/gdk2/stable/gdk2-Threads.html#gdk-threads-init
> --
> Thanks,
> Alexander.
> On 07/17/2014 04:15 PM, Sergey Bylokhov wrote:
>> Hi, Alexander.
>> As far as I remember, we have a code, which closes this lib for the 
>> usual usage of gtk look and feel. Looks like we never call it, but if 
>> we call it it will cause the same crash? Can you investigate that? 
>> Thanks.
>>
>> On 7/16/14 8:56 PM, Alexander Zvegintsev wrote:
>>> Hello AWT team,
>>>
>>> please review the fix
>>> http://cr.openjdk.java.net/~azvegint/jdk/9/8048289/00/
>>> for the issue
>>> https://bugs.openjdk.java.net/browse/JDK-8048289
>>>
>>> UIManager.getSystemLookAndFeelClassName() calls 
>>> UNIXToolkit.isNativeGTKAvailable()
>>> which loads gtk library, checks version, and closes library. Thread 
>>> specific data key is created upon gtk dlopen,
>>> but this key is not deleted at dlclose. This produces a crash at 
>>> thread termination.
>>>
>>> So this fix is a workaround for the glib issue [1], it simply 
>>> doesn't close library.
>>> Simple case to reproduce this issue written on C is attached to [1].
>>>
>>> [1] https://bugzilla.gnome.org/show_bug.cgi?id=733065
>>>
>>
>>
>


-- 
Best regards, Sergey.

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

From anthony.petrov at oracle.com  Thu Jul 17 20:12:37 2014
From: anthony.petrov at oracle.com (Anthony Petrov)
Date: Fri, 18 Jul 2014 00:12:37 +0400
Subject: <AWT Dev> [9] Review Request: 8035568 [macosx] Cursor
	management unification.
In-Reply-To: <CCB68BB7-C43B-4B64-AFAB-BF7892C9B2EC@oracle.com>
References: <9F76EFF5-02F6-4205-A120-D7ADAF0D7B66@oracle.com>
	<53BFC75E.80906@oracle.com>
	<CCB68BB7-C43B-4B64-AFAB-BF7892C9B2EC@oracle.com>
Message-ID: <53C82E35.6020005@oracle.com>

Hi Petr,

Thanks for the clarifications. The fix looks good to me.

--
best regards,
Anthony

On 7/17/2014 4:03 PM, Petr Pchelko wrote:
> Hello,
>
> Thank you for the review, the new version is here:
> http://cr.openjdk.java.net/~pchelko/9/8035568/webrev.01/
>
> Mike wrote:
>> Has this change been tested on Retina? I don't see any effort to convert in and out of the screen coordinate system.
> Yes, it works fine on Retina. Where should we convert the coords?  CGEventGetLocation gives us coors in logical pixels and that's exactly what we need. Am I missing something?
>
> Anthony wrote:
>> 1. src/macosx/classes/sun/lwawt/LWMouseInfoPeer.java
>>>   55         // Most likely the cached window under cursor is correct and we do not need the native check.
>>
>> Perhaps instead it would make sense to describe here when the first condition may fail and the native check could actually become useful? Otherwise the current comment doesn't add much value to understanding the code.
> Done. I've removed the non-native check as it might be wrong.
>
>> . src/macosx/native/sun/awt/AWTWindow.m
>>> -    AWT_ASSERT_APPKIT_THREAD;
>>>
>>> +    [ThreadUtilities performOnMainThreadWaiting:YES block:^{
>>
>> This looks okay. But I'm wondering whether this could cause any dead locks potentially? I'd suggest to run other tests that may involve (maybe indirectly) calling the nativeGetTopmostPlatformWindowUnderMouse method (grab/ungrab? focus? modal dialogs? tooltips/popups? maybe something else).
> Normally nativeGetTopmostPlatformWindowUnderMouse is called on the Appkit thread. It's called from EDT only in isWindowUnderMouse function, and it's not used too much in out code.
>
>> 3. src/macosx/native/sun/awt/CCursorManager.m
>>> -    [ThreadUtilities performOnMainThreadWaiting:YES block:^(){
>>
>> Is it OK to call Core Graphics functions on a thread other than the main thread?
> According to Apple, yes: "Quartz is thread safe on the whole, but individual Quartz objects are not. In general, you can operate on any object on any thread as long as you guarantee that no two threads are operating on the same object simultaneously. The easiest way to achieve this is to not share your objects between threads."
>
> With best regards. Petr.
>
> On 11 ???? 2014 ?., at 15:15, Anthony Petrov <anthony.petrov at oracle.com> wrote:
>
>> Hi Petr,
>>
>> The fix looks good to me overall. A few comments:
>>
>> 1. src/macosx/classes/sun/lwawt/LWMouseInfoPeer.java
>>>   55         // Most likely the cached window under cursor is correct and we do not need the native check.
>>
>> Perhaps instead it would make sense to describe here when the first condition may fail and the native check could actually become useful? Otherwise the current comment doesn't add much value to understanding the code.
>>
>>
>> 2. src/macosx/native/sun/awt/AWTWindow.m
>>> -    AWT_ASSERT_APPKIT_THREAD;
>>>
>>> +    [ThreadUtilities performOnMainThreadWaiting:YES block:^{
>>
>> This looks okay. But I'm wondering whether this could cause any dead locks potentially? I'd suggest to run other tests that may involve (maybe indirectly) calling the nativeGetTopmostPlatformWindowUnderMouse method (grab/ungrab? focus? modal dialogs? tooltips/popups? maybe something else).
>>
>>
>> 3. src/macosx/native/sun/awt/CCursorManager.m
>>> -    [ThreadUtilities performOnMainThreadWaiting:YES block:^(){
>>
>> Is it OK to call Core Graphics functions on a thread other than the main thread?
>>
>> --
>> best regards,
>> Anthony
>>
>> On 7/8/2014 2:19 PM, Petr Pchelko wrote:
>>> Hello, AWT Team.
>>>
>>> Please review the fix for the issue:
>>> https://bugs.openjdk.java.net/browse/JDK-8035568
>>> The fix is available at:
>>> http://cr.openjdk.java.net/~pchelko/9/8035568/webrev.00/
>>>
>>> We are using 2 different methods for getting a cursor position in Robot and in LWAWT. I've changed our implementation to use Carbon method.
>>> nativeGetCursorPosition is a very hot method and changing it's implementation makes it run 35 times faster. Also we will never deadlock on it any more.
>>> However, I needed to change the isWindowUnderMouse implementation. The problem's that LWWindowPeer.windowUnderCursor is updated on mouse events
>>> and generated mouse events, so sometimes it may be not updated when called from a component resize handler. Luckily we can test it using native code.
>>> isWindowUnderMouse is not a hot method at all, in real apps it's called very rarely (never called after a couple of hours of real IDE usage) so it's not a problem that it
>>> runs slower now.
>>>
>>> I've run all cursor/mouse tests. A couple of tests failed because they didn't have proper synchronization and we are too fast for them now. I've fixed it and open-sourced the tests.
>>>
>>> With best regards. Petr.
>>>
>

From anthony.petrov at oracle.com  Thu Jul 17 20:13:53 2014
From: anthony.petrov at oracle.com (Anthony Petrov)
Date: Fri, 18 Jul 2014 00:13:53 +0400
Subject: <AWT Dev> [9] Review Request: 8035568 [macosx] Cursor
	management unification.
In-Reply-To: <53C7CC2E.6010003@oracle.com>
References: <9F76EFF5-02F6-4205-A120-D7ADAF0D7B66@oracle.com>
	<53BFC75E.80906@oracle.com>
	<CCB68BB7-C43B-4B64-AFAB-BF7892C9B2EC@oracle.com>
	<53C7C17A.1090508@oracle.com>
	<BF60DD92-9E27-4ABD-849B-441F2E128DF3@oracle.com>
	<53C7CC2E.6010003@oracle.com>
Message-ID: <53C82E81.7010104@oracle.com>

This one looks even better. +1 (w/o the PlatformLibraries.gmk of course).

--
best regards,
Anthony

On 7/17/2014 5:14 PM, Sergey Bylokhov wrote:
> Hi, Petr.
> The fix looks good. I assume PlatformLibraries.gmk is from another fixes.
> On 7/17/14 4:38 PM, Petr Pchelko wrote:
>> Hello, Sergey.
>>
>>> Is it possible in  LWMouseInfoPeer that windowPeer == null?
>> Yes, it's possible.
>> Thank you for this catch, updated the webrev:
>> http://cr.openjdk.java.net/~pchelko/9/8035568/webrev.02/
>> <http://cr.openjdk.java.net/%7Epchelko/9/8035568/webrev.02/>
>>
>> With best regards. Petr.
>>
>> On 17 ???? 2014 ?., at 16:28, Sergey Bylokhov
>> <Sergey.Bylokhov at oracle.com <mailto:Sergey.Bylokhov at oracle.com>> wrote:
>>
>>> Hi, Petr.
>>> Is it possible in LWMouseInfoPeer that windowPeer == null?
>>>
>>> On 7/17/14 4:03 PM, Petr Pchelko wrote:
>>>> Hello,
>>>>
>>>> Thank you for the review, the new version is here:
>>>> http://cr.openjdk.java.net/~pchelko/9/8035568/webrev.01/
>>>>
>>>> Mike wrote:
>>>>> Has this change been tested on Retina? I don't see any effort to convert in and out of the screen coordinate system.
>>>> Yes, it works fine on Retina. Where should we convert the coords?  CGEventGetLocation gives us coors in logical pixels and that's exactly what we need. Am I missing something?
>>>>
>>>> Anthony wrote:
>>>>> 1. src/macosx/classes/sun/lwawt/LWMouseInfoPeer.java
>>>>>>   55         // Most likely the cached window under cursor is correct and we do not need the native check.
>>>>> Perhaps instead it would make sense to describe here when the first condition may fail and the native check could actually become useful? Otherwise the current comment doesn't add much value to understanding the code.
>>>> Done. I've removed the non-native check as it might be wrong.
>>>>
>>>>> . src/macosx/native/sun/awt/AWTWindow.m
>>>>>> -    AWT_ASSERT_APPKIT_THREAD;
>>>>>>
>>>>>> +    [ThreadUtilities performOnMainThreadWaiting:YES block:^{
>>>>> This looks okay. But I'm wondering whether this could cause any dead locks potentially? I'd suggest to run other tests that may involve (maybe indirectly) calling the nativeGetTopmostPlatformWindowUnderMouse method (grab/ungrab? focus? modal dialogs? tooltips/popups? maybe something else).
>>>> Normally nativeGetTopmostPlatformWindowUnderMouse is called on the Appkit thread. It's called from EDT only in isWindowUnderMouse function, and it's not used too much in out code.
>>>>
>>>>> 3. src/macosx/native/sun/awt/CCursorManager.m
>>>>>> -    [ThreadUtilities performOnMainThreadWaiting:YES block:^(){
>>>>> Is it OK to call Core Graphics functions on a thread other than the main thread?
>>>> According to Apple, yes: "Quartz is thread safe on the whole, but individual Quartz objects are not. In general, you can operate on any object on any thread as long as you guarantee that no two threads are operating on the same object simultaneously. The easiest way to achieve this is to not share your objects between threads."
>>>>
>>>> With best regards. Petr.
>>>>
>>>> On 11 ???? 2014 ?., at 15:15, Anthony Petrov<anthony.petrov at oracle.com>  wrote:
>>>>
>>>>> Hi Petr,
>>>>>
>>>>> The fix looks good to me overall. A few comments:
>>>>>
>>>>> 1. src/macosx/classes/sun/lwawt/LWMouseInfoPeer.java
>>>>>>   55         // Most likely the cached window under cursor is correct and we do not need the native check.
>>>>> Perhaps instead it would make sense to describe here when the first condition may fail and the native check could actually become useful? Otherwise the current comment doesn't add much value to understanding the code.
>>>>>
>>>>>
>>>>> 2. src/macosx/native/sun/awt/AWTWindow.m
>>>>>> -    AWT_ASSERT_APPKIT_THREAD;
>>>>>>
>>>>>> +    [ThreadUtilities performOnMainThreadWaiting:YES block:^{
>>>>> This looks okay. But I'm wondering whether this could cause any dead locks potentially? I'd suggest to run other tests that may involve (maybe indirectly) calling the nativeGetTopmostPlatformWindowUnderMouse method (grab/ungrab? focus? modal dialogs? tooltips/popups? maybe something else).
>>>>>
>>>>>
>>>>> 3. src/macosx/native/sun/awt/CCursorManager.m
>>>>>> -    [ThreadUtilities performOnMainThreadWaiting:YES block:^(){
>>>>> Is it OK to call Core Graphics functions on a thread other than the main thread?
>>>>>
>>>>> --
>>>>> best regards,
>>>>> Anthony
>>>>>
>>>>> On 7/8/2014 2:19 PM, Petr Pchelko wrote:
>>>>>> Hello, AWT Team.
>>>>>>
>>>>>> Please review the fix for the issue:
>>>>>> https://bugs.openjdk.java.net/browse/JDK-8035568
>>>>>> The fix is available at:
>>>>>> http://cr.openjdk.java.net/~pchelko/9/8035568/webrev.00/
>>>>>>
>>>>>> We are using 2 different methods for getting a cursor position in Robot and in LWAWT. I've changed our implementation to use Carbon method.
>>>>>> nativeGetCursorPosition is a very hot method and changing it's implementation makes it run 35 times faster. Also we will never deadlock on it any more.
>>>>>> However, I needed to change the isWindowUnderMouse implementation. The problem's that LWWindowPeer.windowUnderCursor is updated on mouse events
>>>>>> and generated mouse events, so sometimes it may be not updated when called from a component resize handler. Luckily we can test it using native code.
>>>>>> isWindowUnderMouse is not a hot method at all, in real apps it's called very rarely (never called after a couple of hours of real IDE usage) so it's not a problem that it
>>>>>> runs slower now.
>>>>>>
>>>>>> I've run all cursor/mouse tests. A couple of tests failed because they didn't have proper synchronization and we are too fast for them now. I've fixed it and open-sourced the tests.
>>>>>>
>>>>>> With best regards. Petr.
>>>>>>
>>>
>>>
>>> --
>>> Best regards, Sergey.
>>
>
>
> --
> Best regards, Sergey.
>

From Alan.Bateman at oracle.com  Fri Jul 18 09:15:47 2014
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Fri, 18 Jul 2014 10:15:47 +0100
Subject: <AWT Dev> [9] Review Request: 8037485 Refactor
 java.awt.datatransfer to eliminate dependency on AWT
In-Reply-To: <AC897956-F1CC-457F-B99D-24082558C011@oracle.com>
References: <AC897956-F1CC-457F-B99D-24082558C011@oracle.com>
Message-ID: <53C8E5C3.6030903@oracle.com>

On 17/07/2014 12:07, Petr Pchelko wrote:
> Hello,
>
> Please review the fix for the issue:
> https://bugs.openjdk.java.net/browse/JDK-8037485
> The fix is available at:
> http://cr.openjdk.java.net/~pchelko/9/8037485/webrev.00 
> <http://cr.openjdk.java.net/%7Epchelko/9/8037485/webrev.00>
>
> This fix separates the public datatransfer API from the desktop 
> module. The datatransfer module would contain java.awt.datatransfer 
> and sun.awt.datatransfer packages.
> The sun.awt.datatransfer.desktop contains platform-dependent features 
> of the datatransfer system and belongs to the desktop module. So, most 
> of the changes are just package renaming.
>
> DataTransferer class was split into 2 parts:
> 1. Utilities to work with the DataFlavor is moved to the 
> DataFlavorUtil class. It's just a collection of uility functions and 
> classes
> 2. Java objects to native representation converters are left in the 
> DataTransferer class and moved to the desktop module. It's needed only 
> with DnD and system clipboard API, so it naturally belong to desktop.
>
> DesktopDatatransferServices was created. This is a collection of 
> services that datatrasfer module could use from desktop if desktop is 
> present. ServiceLoader is used because reflection does not cross 
> module boundaries for non-exported APIs
>
> RMIAccessServices - a collection of services which RMI module might 
> provide to desktop and datatransfer. If RMI module is present we can 
> transfer RMI classes. If not - we cannot.
>
> The fix was tested on all platforms with jtreg and JCK. No new test 
> failures found. Also the fix was tested without the RMI and without 
> the desktop module.
Mandy and I had a brief discussion with Petr about this. One suggestion 
is to separate out the changes related to RMI as there are other 
approaches there. This would also make it a bit easier to review the 
most important work to factor out the datatransfer API.

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

From dmitriy.ermashov at oracle.com  Fri Jul 18 09:49:27 2014
From: dmitriy.ermashov at oracle.com (Dmitriy Ermashov)
Date: Fri, 18 Jul 2014 13:49:27 +0400
Subject: <AWT Dev> Review request for 8049694: Migrate functional
 AWT_DesktopProperties/Automated tests to OpenJDK
In-Reply-To: <53C69341.10700@oracle.com>
References: <53BD0B93.8040505@oracle.com> <53C65D55.1090604@oracle.com>
	<53C68E34.4020500@oracle.com> <53C6909E.8090605@oracle.com>
	<53C69341.10700@oracle.com>
Message-ID: <53C8EDA7.8040002@oracle.com>

Hi Alexander, team,

Please review the updated version:
http://cr.openjdk.java.net/~dermashov/8049694/webrev.01/

Recent changes:
1. replaced "pgrep gnome | head -1" with "pgrep gnome-session"

The test passes on the following platforms:
Solaris 10 sparcv9 (Java Desktop System)
Solaris 11 x64 (Gnome 2)
Ubuntu 10.04 arm (Gnome 2)
Ubuntu 14.04 x64 (Unity)

Windows 7 x64 (test just exit with 0 code)
OS X 10.9 (test just exit with 0 code)

Thanks,
Dima

On 07/16/2014 06:59 PM, Alexander Zvegintsev wrote:
> Dmitriy,
>
> I think that it is unneeded to complicate the test, since even JDK8 
> officially supports Ubuntu 12+ [1].
>
> [1] http://www.oracle.com/technetwork/java/javase/certconfig-2095354.html
> Thanks,
>
> Alexander.
> On 07/16/2014 06:47 PM, Dmitriy Ermashov wrote:
>> Hi Alexander,
>>
>> On 07/16/2014 06:37 PM, Alexander Zvegintsev wrote:
>>> Hi Dmitriy,
>>>
>>> Correct me if I am wrong:
>>> jtreg keeps DISPLAY and strips many environment variables(e.g. 
>>> DBUS_SESSION_BUS_ADDRESS).
>>> DBUS_SESSION_BUS_ADDRESS variable is needed for correct work of 
>>> gconftool-2 and gsettings
>>> That's why we need pargs and /proc/$PID/environ.
>> Everything is right.
>> gconftool-2 and gsettings do not work without 
>> DBUS_SESSION_BUS_ADDRESS or DISPLAY variable set.
>>>
>>> But this test fails for me on Ubuntu 14.04.
>>> It happens because pgrep gnome returns a PID of 
>>> /usr/bin/gnome-keyring-daemon at first position on my system
>>> User can't read /proc/$PID/environ due to its access rights:
>>> -r-------- 1 root root 0 Jul 16 16:41 /proc/0000/environ
>>>
>>> So I think that the DBUS_SESSION_BUS_ADDRESS determination should be 
>>> improved.
>>> I suggest to add check for DBUS_SESSION_BUS_ADDRESS and replace 
>>> gnome with gnome-session in pgrep call
>>> (it should be verified on all affected platforms).
>> Initially there was "gnome-session" in pgrep call, but Ubuntu 8.04 
>> has no such process, so the test failed.
>> I've changed it to "pgrep gnome | head -1"
>> If we do not support ubuntu 8.04, I'll just replace "pgrep gnome" 
>> with "pgrep gnome-session".
>>
>> So the question is, do we support Ubuntu 8.04?
>>
>>
>> Thanks,
>> Dima
>>> Thanks,
>>>
>>> Alexander.
>>> On 07/16/2014 03:09 PM, Dmitriy Ermashov wrote:
>>>> Hi,
>>>>
>>>> Just a kindly reminder. Please review the test:
>>>> http://cr.openjdk.java.net/~dermashov/8049694/webrev.00/
>>>>
>>>> Thanks,
>>>> Dima
>>>>
>>>> On 07/09/2014 01:29 PM, Dmitriy Ermashov wrote:
>>>>> Hi all,
>>>>>
>>>>> Please review yet another batch of tests. To be precise, just one 
>>>>> test.
>>>>> http://cr.openjdk.java.net/~dermashov/8049694/webrev.00/
>>>>>
>>>>> The corresponding bug:
>>>>> https://bugs.openjdk.java.net/browse/JDK-8049694
>>>>>
>>>>> This test verifies old RFE 4758438. It declares that AWT should 
>>>>> provide an access to XSETTINGS through the Toolkit.
>>>>> As you can see, the test consist of .java ans .sh files. The 
>>>>> reason for it is in different utilities for changing xsettings on 
>>>>> different OSes. E.g. old systems like Ubuntu 8.04 and Solaris 10 
>>>>> use gconftool-2 utilily while Ubuntu 14.04 use gsettings.
>>>>> So the script decides which utility to use on current platform and 
>>>>> pass the parameters to java programm.
>>>>>
>>>>> The test passes on the following platforms:
>>>>> Solaris 10 sparcv9 (Java Desktop System)
>>>>> Solaris 11 x64 (Gnome 2)
>>>>> Ubuntu 8.04 virtualbox (Gnome 2)
>>>>> Ubuntu 10.04 arm (Gnome 2)
>>>>> Ubuntu 14.04 x64 (Unity)
>>>>>
>>>>> Windows 7 x64 (test just exit with 0 code)
>>>>> OS X 10.9 (test just exit with 0 code)
>>>>>
>>>>
>>>
>>
>

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

From alexander.zvegintsev at oracle.com  Fri Jul 18 09:56:39 2014
From: alexander.zvegintsev at oracle.com (Alexander Zvegintsev)
Date: Fri, 18 Jul 2014 13:56:39 +0400
Subject: <AWT Dev> Review request for 8049694: Migrate functional
 AWT_DesktopProperties/Automated tests to OpenJDK
In-Reply-To: <53C8EDA7.8040002@oracle.com>
References: <53BD0B93.8040505@oracle.com> <53C65D55.1090604@oracle.com>
	<53C68E34.4020500@oracle.com> <53C6909E.8090605@oracle.com>
	<53C69341.10700@oracle.com> <53C8EDA7.8040002@oracle.com>
Message-ID: <53C8EF57.2020303@oracle.com>

Hi Dmitriy,

the fix looks good to me.

Thanks,

Alexander.

On 07/18/2014 01:49 PM, Dmitriy Ermashov wrote:
> Hi Alexander, team,
>
> Please review the updated version:
> http://cr.openjdk.java.net/~dermashov/8049694/webrev.01/
>
> Recent changes:
> 1. replaced "pgrep gnome | head -1" with "pgrep gnome-session"
>
> The test passes on the following platforms:
> Solaris 10 sparcv9 (Java Desktop System)
> Solaris 11 x64 (Gnome 2)
> Ubuntu 10.04 arm (Gnome 2)
> Ubuntu 14.04 x64 (Unity)
>
> Windows 7 x64 (test just exit with 0 code)
> OS X 10.9 (test just exit with 0 code)
> Thanks,
> Dima
> On 07/16/2014 06:59 PM, Alexander Zvegintsev wrote:
>> Dmitriy,
>>
>> I think that it is unneeded to complicate the test, since even JDK8 
>> officially supports Ubuntu 12+ [1].
>>
>> [1] http://www.oracle.com/technetwork/java/javase/certconfig-2095354.html
>> Thanks,
>>
>> Alexander.
>> On 07/16/2014 06:47 PM, Dmitriy Ermashov wrote:
>>> Hi Alexander,
>>>
>>> On 07/16/2014 06:37 PM, Alexander Zvegintsev wrote:
>>>> Hi Dmitriy,
>>>>
>>>> Correct me if I am wrong:
>>>> jtreg keeps DISPLAY and strips many environment variables(e.g. 
>>>> DBUS_SESSION_BUS_ADDRESS).
>>>> DBUS_SESSION_BUS_ADDRESS variable is needed for correct work of 
>>>> gconftool-2 and gsettings
>>>> That's why we need pargs and /proc/$PID/environ.
>>> Everything is right.
>>> gconftool-2 and gsettings do not work without 
>>> DBUS_SESSION_BUS_ADDRESS or DISPLAY variable set.
>>>>
>>>> But this test fails for me on Ubuntu 14.04.
>>>> It happens because pgrep gnome returns a PID of 
>>>> /usr/bin/gnome-keyring-daemon at first position on my system
>>>> User can't read /proc/$PID/environ due to its access rights:
>>>> -r-------- 1 root root 0 Jul 16 16:41 /proc/0000/environ
>>>>
>>>> So I think that the DBUS_SESSION_BUS_ADDRESS determination should 
>>>> be improved.
>>>> I suggest to add check for DBUS_SESSION_BUS_ADDRESS and replace 
>>>> gnome with gnome-session in pgrep call
>>>> (it should be verified on all affected platforms).
>>> Initially there was "gnome-session" in pgrep call, but Ubuntu 8.04 
>>> has no such process, so the test failed.
>>> I've changed it to "pgrep gnome | head -1"
>>> If we do not support ubuntu 8.04, I'll just replace "pgrep gnome" 
>>> with "pgrep gnome-session".
>>>
>>> So the question is, do we support Ubuntu 8.04?
>>>
>>>
>>> Thanks,
>>> Dima
>>>> Thanks,
>>>>
>>>> Alexander.
>>>> On 07/16/2014 03:09 PM, Dmitriy Ermashov wrote:
>>>>> Hi,
>>>>>
>>>>> Just a kindly reminder. Please review the test:
>>>>> http://cr.openjdk.java.net/~dermashov/8049694/webrev.00/
>>>>>
>>>>> Thanks,
>>>>> Dima
>>>>>
>>>>> On 07/09/2014 01:29 PM, Dmitriy Ermashov wrote:
>>>>>> Hi all,
>>>>>>
>>>>>> Please review yet another batch of tests. To be precise, just one 
>>>>>> test.
>>>>>> http://cr.openjdk.java.net/~dermashov/8049694/webrev.00/
>>>>>>
>>>>>> The corresponding bug:
>>>>>> https://bugs.openjdk.java.net/browse/JDK-8049694
>>>>>>
>>>>>> This test verifies old RFE 4758438. It declares that AWT should 
>>>>>> provide an access to XSETTINGS through the Toolkit.
>>>>>> As you can see, the test consist of .java ans .sh files. The 
>>>>>> reason for it is in different utilities for changing xsettings on 
>>>>>> different OSes. E.g. old systems like Ubuntu 8.04 and Solaris 10 
>>>>>> use gconftool-2 utilily while Ubuntu 14.04 use gsettings.
>>>>>> So the script decides which utility to use on current platform 
>>>>>> and pass the parameters to java programm.
>>>>>>
>>>>>> The test passes on the following platforms:
>>>>>> Solaris 10 sparcv9 (Java Desktop System)
>>>>>> Solaris 11 x64 (Gnome 2)
>>>>>> Ubuntu 8.04 virtualbox (Gnome 2)
>>>>>> Ubuntu 10.04 arm (Gnome 2)
>>>>>> Ubuntu 14.04 x64 (Unity)
>>>>>>
>>>>>> Windows 7 x64 (test just exit with 0 code)
>>>>>> OS X 10.9 (test just exit with 0 code)
>>>>>>
>>>>>
>>>>
>>>
>>
>

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

From anton.nashatyrev at oracle.com  Fri Jul 18 10:28:02 2014
From: anton.nashatyrev at oracle.com (anton nashatyrev)
Date: Fri, 18 Jul 2014 14:28:02 +0400
Subject: <AWT Dev> [9] Review request for 8046495: KeyEvent can not be
 accepted in quick mouse clicking
In-Reply-To: <53C793F9.6010703@oracle.com>
References: <53B2EDEA.3010402@oracle.com>
	<B4A1F8A6-25D8-4CA2-A138-95EC14A6A881@oracle.com>
	<53B413A7.4000809@oracle.com> <53B4253A.3040406@oracle.com>
	<53B42689.4090709@oracle.com>
	<59E88D9A-2BF9-41CF-9128-5E5A83B39EF3@oracle.com>
	<53C793F9.6010703@oracle.com>
Message-ID: <53C8F6B2.7020008@oracle.com>

Hello,

     in offline discussion with Artem and Petr we decided to further 
clean up the code and completely remove TimeHelper functions from 
awt_Component.cpp in JDK9.

     Could you please review the updated fix: 
http://cr.openjdk.java.net/~anashaty/8046495/9/webrev.01/ 
<http://cr.openjdk.java.net/%7Eanashaty/8046495/9/webrev.01/>

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

Thank you!
Anton.

On 17.07.2014 13:14, anton nashatyrev wrote:
> Hello All,
>
>     could please anyone else take a look at the fix?
>
> Thanks!
> Anton.
>
> On 02.07.2014 19:37, Petr Pchelko wrote:
>> Hello, Anton.
>>
>> Thanks for clarifications and additional testing.
>> The fix looks good to me too.
>>
>> With best regards. Petr.
>>
>> On 02 ???? 2014 ?., at 19:34, Anton V. Tarasov 
>> <anton.tarasov at oracle.com <mailto:anton.tarasov at oracle.com>> wrote:
>>
>>> On 02.07.2014 19:28, anton nashatyrev wrote:
>>>> Hello, Anton
>>>>
>>>> On 02.07.2014 18:13, Anton V. Tarasov wrote:
>>>>> On 02.07.2014 11:44, Petr Pchelko wrote:
>>>>>> Hello, Anton.
>>>>>>
>>>>>> I'm not sure I have a detailed understanding of what's happening.
>>>>>>
>>>>>> Before your fix the timestamp of the event represented the time 
>>>>>> when the event was created, and now it's the time when it's sent 
>>>>>> to java.
>>>>>> This might be important if some events cause other events to be 
>>>>>> issued on the java side.
>>>>>>
>>>>>> So suppose the following:
>>>>>> Toolkit thread: InputEvent#1 created      - timestamp 0
>>>>>> Toolkit thread: InputEvent#2 created      - timestamp 1
>>>>>> Toolkit thread: InputEvent#1 sent           - timestamp 2
>>>>>> EDT: InputEvent#1 dispatched - timestamp 3
>>>>>> EDT:               FocusEvent  created  - timestamp 4
>>>>>> Toolkit thread: InputEvent#2 sent           - timestamp 5
>>>>>>
>>>>>> Before you fix we had the following event order: 
>>>>>> InputEvent#1(ts=0), InputEvent#2(ts=1), FocusEvent(ts=4).
>>>>>> But after your fix we will have a different order: 
>>>>>> InputEvent#1(ts=2), FocusEvent(ts=4), InputEvent#2(ts=5).
>>>>>> So now we would have troubles, because the Input Event will go to 
>>>>>> the new focused component instead of the old one.
>>>>>> Do you think that my arguments are correct? I understand that the 
>>>>>> likelihood of such a situation is very low, but for me it looks 
>>>>>> possible? Am I missing something?
>>>>>
>>>>> A timestamp for a FocusEvent is taken from 
>>>>> the_most_recent_KeyEvent_time which is set on EDT when the event 
>>>>> is dispatched. So the fix shouldn't affect it.
>>>>>
>>>>> Also, in awt_Window.cpp, when a TimedWindowEvent is created it is 
>>>>> passed a timestamp got with TimeHelper::getMessageTimeUTC(). It 
>>>>> appears, that the fix makes key events times even more consistent 
>>>>> with it. So, from the kbd focus perspective, it shouldn't make any 
>>>>> harm.
>>>>>
>>>>> Anton, could you just please run the following tests, at least:
>>>>>
>>>>> test/java/awt/Focus/6981400/*
>>>>> test/java/awt/KeyboardFocusManager/TypeAhead/*
>>>>
>>>> I've tested with the following set:
>>>> [closed]/java/awt/event/*
>>>> [closed]/java/awt/Focus/*
>>>> [closed]java/awt/KeyboardFocusManager/*
>>>>
>>>> : no unexpected failures here.
>>>>
>>>> I've also verified that my regression test which comes with the fix 
>>>> works fine on Linux and Mac (despite the fix is Win specific).
>>>
>>> Great, thanks!
>>>
>>> Anton.
>>>
>>>>
>>>> Thanks for review!
>>>> Anton.
>>>>
>>>>>
>>>>> Thanks,
>>>>> Anton.
>>>>>
>>>>>>
>>>>>> Another thing I do not understand is why we were used to use the 
>>>>>> complicated formula instead of initializing the msg.time field 
>>>>>> with the JVM current time and using it when sending the event?
>>>>>> Wouldn't that resolve both your issue and the issue the original 
>>>>>> fix was made for?
>>>>>>
>>>>>> I have a couple of comments about the code, but let's postpone 
>>>>>> that until we decide on the approach.
>>>>>>
>>>>>> Thank you.
>>>>>> With best regards. Petr.
>>>>>>
>>>>>> On 01 ???? 2014 ?., at 21:20, anton nashatyrev 
>>>>>> <anton.nashatyrev at oracle.com 
>>>>>> <mailto:anton.nashatyrev at oracle.com>> wrote:
>>>>>>
>>>>>>> Hello,
>>>>>>>     could you please review the following fix:
>>>>>>>
>>>>>>> fix: http://cr.openjdk.java.net/~anashaty/8046495/9/webrev.00/ 
>>>>>>> <http://cr.openjdk.java.net/%7Eanashaty/8046495/9/webrev.00/>
>>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8046495
>>>>>>>
>>>>>>> *Problem:*
>>>>>>> On Windows the later InputEvent may have earlier timestamp 
>>>>>>> (getWhen()), which results in incorrect processing of enqueued 
>>>>>>> input events and may also potentially be the reason of other 
>>>>>>> artifacts
>>>>>>>
>>>>>>> *Evaluation*:
>>>>>>> On Windows we have some algorithm for calculating input event 
>>>>>>> timestamp: jdk/src/windows/native/sun/windows/awt_Component.cpp:2100
>>>>>>> Shortly the timestamp is calculated by the following formula:
>>>>>>>     when = JVM_CurrentTimeMillis() - (GetTickCount() - 
>>>>>>> GetMessageTime())
>>>>>>>
>>>>>>> Where:
>>>>>>>   JVM_CurrentTimeMillis() - the same as System.currentTimeMillis()
>>>>>>>   GetTickCount() - Win32 function, current millis from boot time
>>>>>>>   GetMessageTime() - Win32 function, millis from boot time of 
>>>>>>> the latest native Message
>>>>>>>
>>>>>>> In theory the formula looks good: we are trying our best to 
>>>>>>> calculate the actual time of the OS message by taking the 
>>>>>>> current JVM time (JVM_CurrentTimeMillis) and adjusting it with 
>>>>>>> the offset (GetTickCount - GetMessageTime) which should indicate 
>>>>>>> how many milliseconds ago from the current moment (GetTickCount) 
>>>>>>> the message has been actually issued (GetMessageTime).
>>>>>>> In practice due to usage of different system timers by the 
>>>>>>> JVM_CurrentTimeMillis and GetTickCount their values are not 
>>>>>>> updated synchronously and we may get an earlier timestamp for 
>>>>>>> the later event.
>>>>>>>
>>>>>>> *Fix*:
>>>>>>> Just to use JVM_CurrentTimeMillis only as events timestamp. On 
>>>>>>> Mac this is done in exactly the same way: 
>>>>>>> CPlatformResponder.handleMouse/KeyEvent()
>>>>>>>
>>>>>>> The message time offset calculation has been introduced with the 
>>>>>>> fix for JDK-4434193 
>>>>>>> <https://bugs.openjdk.java.net/browse/JDK-4434193> and it seems 
>>>>>>> that the issue has addressed very similar problem (At times 
>>>>>>> getWhen()in ActionEvent returns higher value than the 
>>>>>>> CurrentSystemTime) which has not been completely resolved in fact.
>>>>>>> I also didn't find any benefits in using the existing approach:
>>>>>>> - all the usages of the TimerHelper are in fact reduced to the 
>>>>>>> mentioned formula: when = JVM_CurrentTimeMillis() - 
>>>>>>> (GetTickCount() - GetMessageTime())
>>>>>>> - GetMessageTime() always increases (except of the int overflow 
>>>>>>> moments), thus we couldn't get earlier OS messages after later ones
>>>>>>> - TimerHelper::windowsToUTC(DWORD windowsTime) doesn't guarantee 
>>>>>>> returning the same timestamp across different calls for the same 
>>>>>>> message time
>>>>>>>
>>>>>>> Thanks!
>>>>>>> Anton.
>>>>>>
>>>>>
>>>>
>>>
>>
>

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

From Sergey.Bylokhov at oracle.com  Fri Jul 18 11:01:33 2014
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Fri, 18 Jul 2014 15:01:33 +0400
Subject: <AWT Dev> Review request for 8049694: Migrate functional
 AWT_DesktopProperties/Automated tests to OpenJDK
In-Reply-To: <53C8EF57.2020303@oracle.com>
References: <53BD0B93.8040505@oracle.com>
	<53C65D55.1090604@oracle.com>	<53C68E34.4020500@oracle.com>
	<53C6909E.8090605@oracle.com>	<53C69341.10700@oracle.com>
	<53C8EDA7.8040002@oracle.com> <53C8EF57.2020303@oracle.com>
Message-ID: <53C8FE8D.4050805@oracle.com>

Hi Dmitriy,
The fix looks good.

On 7/18/14 1:56 PM, Alexander Zvegintsev wrote:
> Hi Dmitriy,
>
> the fix looks good to me.
> Thanks,
>
> Alexander.
> On 07/18/2014 01:49 PM, Dmitriy Ermashov wrote:
>> Hi Alexander, team,
>>
>> Please review the updated version:
>> http://cr.openjdk.java.net/~dermashov/8049694/webrev.01/
>>
>> Recent changes:
>> 1. replaced "pgrep gnome | head -1" with "pgrep gnome-session"
>>
>> The test passes on the following platforms:
>> Solaris 10 sparcv9 (Java Desktop System)
>> Solaris 11 x64 (Gnome 2)
>> Ubuntu 10.04 arm (Gnome 2)
>> Ubuntu 14.04 x64 (Unity)
>>
>> Windows 7 x64 (test just exit with 0 code)
>> OS X 10.9 (test just exit with 0 code)
>> Thanks,
>> Dima
>> On 07/16/2014 06:59 PM, Alexander Zvegintsev wrote:
>>> Dmitriy,
>>>
>>> I think that it is unneeded to complicate the test, since even JDK8 
>>> officially supports Ubuntu 12+ [1].
>>>
>>> [1] 
>>> http://www.oracle.com/technetwork/java/javase/certconfig-2095354.html
>>> Thanks,
>>>
>>> Alexander.
>>> On 07/16/2014 06:47 PM, Dmitriy Ermashov wrote:
>>>> Hi Alexander,
>>>>
>>>> On 07/16/2014 06:37 PM, Alexander Zvegintsev wrote:
>>>>> Hi Dmitriy,
>>>>>
>>>>> Correct me if I am wrong:
>>>>> jtreg keeps DISPLAY and strips many environment variables(e.g. 
>>>>> DBUS_SESSION_BUS_ADDRESS).
>>>>> DBUS_SESSION_BUS_ADDRESS variable is needed for correct work of 
>>>>> gconftool-2 and gsettings
>>>>> That's why we need pargs and /proc/$PID/environ.
>>>> Everything is right.
>>>> gconftool-2 and gsettings do not work without 
>>>> DBUS_SESSION_BUS_ADDRESS or DISPLAY variable set.
>>>>>
>>>>> But this test fails for me on Ubuntu 14.04.
>>>>> It happens because pgrep gnome returns a PID of  
>>>>> /usr/bin/gnome-keyring-daemon at first position on my system
>>>>> User can't read /proc/$PID/environ due to its access rights:
>>>>> -r-------- 1 root root 0 Jul 16 16:41 /proc/0000/environ
>>>>>
>>>>> So I think that the DBUS_SESSION_BUS_ADDRESS determination should 
>>>>> be improved.
>>>>> I suggest to add check for DBUS_SESSION_BUS_ADDRESS and replace 
>>>>> gnome with gnome-session in pgrep call
>>>>> (it should be verified on all affected platforms).
>>>> Initially there was "gnome-session" in pgrep call, but Ubuntu 8.04 
>>>> has no such process, so the test failed.
>>>> I've changed it to "pgrep gnome | head -1"
>>>> If we do not support ubuntu 8.04, I'll just replace "pgrep gnome" 
>>>> with "pgrep gnome-session".
>>>>
>>>> So the question is, do we support Ubuntu 8.04?
>>>>
>>>>
>>>> Thanks,
>>>> Dima
>>>>> Thanks,
>>>>>
>>>>> Alexander.
>>>>> On 07/16/2014 03:09 PM, Dmitriy Ermashov wrote:
>>>>>> Hi,
>>>>>>
>>>>>> Just a kindly reminder. Please review the test:
>>>>>> http://cr.openjdk.java.net/~dermashov/8049694/webrev.00/
>>>>>>
>>>>>> Thanks,
>>>>>> Dima
>>>>>>
>>>>>> On 07/09/2014 01:29 PM, Dmitriy Ermashov wrote:
>>>>>>> Hi all,
>>>>>>>
>>>>>>> Please review yet another batch of tests. To be precise, just 
>>>>>>> one test.
>>>>>>> http://cr.openjdk.java.net/~dermashov/8049694/webrev.00/
>>>>>>>
>>>>>>> The corresponding bug:
>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8049694
>>>>>>>
>>>>>>> This test verifies old RFE 4758438. It declares that AWT should 
>>>>>>> provide an access to XSETTINGS through the Toolkit.
>>>>>>> As you can see, the test consist of .java ans .sh files. The 
>>>>>>> reason for it is in different utilities for changing xsettings 
>>>>>>> on different OSes. E.g. old systems like Ubuntu 8.04 and Solaris 
>>>>>>> 10 use gconftool-2 utilily while Ubuntu 14.04 use gsettings.
>>>>>>> So the script decides which utility to use on current platform 
>>>>>>> and pass the parameters to java programm.
>>>>>>>
>>>>>>> The test passes on the following platforms:
>>>>>>> Solaris 10 sparcv9 (Java Desktop System)
>>>>>>> Solaris 11 x64 (Gnome 2)
>>>>>>> Ubuntu 8.04 virtualbox (Gnome 2)
>>>>>>> Ubuntu 10.04 arm (Gnome 2)
>>>>>>> Ubuntu 14.04 x64 (Unity)
>>>>>>>
>>>>>>> Windows 7 x64 (test just exit with 0 code)
>>>>>>> OS X 10.9 (test just exit with 0 code)
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>


-- 
Best regards, Sergey.

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

From dmitriy.ermashov at oracle.com  Fri Jul 18 11:49:58 2014
From: dmitriy.ermashov at oracle.com (Dmitriy Ermashov)
Date: Fri, 18 Jul 2014 15:49:58 +0400
Subject: <AWT Dev> Review request for 8049694: Migrate functional
 AWT_DesktopProperties/Automated tests to OpenJDK
In-Reply-To: <53C8FE8D.4050805@oracle.com>
References: <53BD0B93.8040505@oracle.com>
	<53C65D55.1090604@oracle.com>	<53C68E34.4020500@oracle.com>
	<53C6909E.8090605@oracle.com>	<53C69341.10700@oracle.com>
	<53C8EDA7.8040002@oracle.com> <53C8EF57.2020303@oracle.com>
	<53C8FE8D.4050805@oracle.com>
Message-ID: <53C909E6.3010701@oracle.com>

Thanks for review!
Dima

On 07/18/2014 03:01 PM, Sergey Bylokhov wrote:
> Hi Dmitriy,
> The fix looks good.
>
> On 7/18/14 1:56 PM, Alexander Zvegintsev wrote:
>> Hi Dmitriy,
>>
>> the fix looks good to me.
>> Thanks,
>>
>> Alexander.
>> On 07/18/2014 01:49 PM, Dmitriy Ermashov wrote:
>>> Hi Alexander, team,
>>>
>>> Please review the updated version:
>>> http://cr.openjdk.java.net/~dermashov/8049694/webrev.01/
>>>
>>> Recent changes:
>>> 1. replaced "pgrep gnome | head -1" with "pgrep gnome-session"
>>>
>>> The test passes on the following platforms:
>>> Solaris 10 sparcv9 (Java Desktop System)
>>> Solaris 11 x64 (Gnome 2)
>>> Ubuntu 10.04 arm (Gnome 2)
>>> Ubuntu 14.04 x64 (Unity)
>>>
>>> Windows 7 x64 (test just exit with 0 code)
>>> OS X 10.9 (test just exit with 0 code)
>>> Thanks,
>>> Dima
>>> On 07/16/2014 06:59 PM, Alexander Zvegintsev wrote:
>>>> Dmitriy,
>>>>
>>>> I think that it is unneeded to complicate the test, since even JDK8 
>>>> officially supports Ubuntu 12+ [1].
>>>>
>>>> [1] 
>>>> http://www.oracle.com/technetwork/java/javase/certconfig-2095354.html
>>>> Thanks,
>>>>
>>>> Alexander.
>>>> On 07/16/2014 06:47 PM, Dmitriy Ermashov wrote:
>>>>> Hi Alexander,
>>>>>
>>>>> On 07/16/2014 06:37 PM, Alexander Zvegintsev wrote:
>>>>>> Hi Dmitriy,
>>>>>>
>>>>>> Correct me if I am wrong:
>>>>>> jtreg keeps DISPLAY and strips many environment variables(e.g. 
>>>>>> DBUS_SESSION_BUS_ADDRESS).
>>>>>> DBUS_SESSION_BUS_ADDRESS variable is needed for correct work of 
>>>>>> gconftool-2 and gsettings
>>>>>> That's why we need pargs and /proc/$PID/environ.
>>>>> Everything is right.
>>>>> gconftool-2 and gsettings do not work without 
>>>>> DBUS_SESSION_BUS_ADDRESS or DISPLAY variable set.
>>>>>>
>>>>>> But this test fails for me on Ubuntu 14.04.
>>>>>> It happens because pgrep gnome returns a PID of  
>>>>>> /usr/bin/gnome-keyring-daemon at first position on my system
>>>>>> User can't read /proc/$PID/environ due to its access rights:
>>>>>> -r-------- 1 root root 0 Jul 16 16:41 /proc/0000/environ
>>>>>>
>>>>>> So I think that the DBUS_SESSION_BUS_ADDRESS determination should 
>>>>>> be improved.
>>>>>> I suggest to add check for DBUS_SESSION_BUS_ADDRESS and replace 
>>>>>> gnome with gnome-session in pgrep call
>>>>>> (it should be verified on all affected platforms).
>>>>> Initially there was "gnome-session" in pgrep call, but Ubuntu 8.04 
>>>>> has no such process, so the test failed.
>>>>> I've changed it to "pgrep gnome | head -1"
>>>>> If we do not support ubuntu 8.04, I'll just replace "pgrep gnome" 
>>>>> with "pgrep gnome-session".
>>>>>
>>>>> So the question is, do we support Ubuntu 8.04?
>>>>>
>>>>>
>>>>> Thanks,
>>>>> Dima
>>>>>> Thanks,
>>>>>>
>>>>>> Alexander.
>>>>>> On 07/16/2014 03:09 PM, Dmitriy Ermashov wrote:
>>>>>>> Hi,
>>>>>>>
>>>>>>> Just a kindly reminder. Please review the test:
>>>>>>> http://cr.openjdk.java.net/~dermashov/8049694/webrev.00/
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Dima
>>>>>>>
>>>>>>> On 07/09/2014 01:29 PM, Dmitriy Ermashov wrote:
>>>>>>>> Hi all,
>>>>>>>>
>>>>>>>> Please review yet another batch of tests. To be precise, just 
>>>>>>>> one test.
>>>>>>>> http://cr.openjdk.java.net/~dermashov/8049694/webrev.00/
>>>>>>>>
>>>>>>>> The corresponding bug:
>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8049694
>>>>>>>>
>>>>>>>> This test verifies old RFE 4758438. It declares that AWT should 
>>>>>>>> provide an access to XSETTINGS through the Toolkit.
>>>>>>>> As you can see, the test consist of .java ans .sh files. The 
>>>>>>>> reason for it is in different utilities for changing xsettings 
>>>>>>>> on different OSes. E.g. old systems like Ubuntu 8.04 and 
>>>>>>>> Solaris 10 use gconftool-2 utilily while Ubuntu 14.04 use 
>>>>>>>> gsettings.
>>>>>>>> So the script decides which utility to use on current platform 
>>>>>>>> and pass the parameters to java programm.
>>>>>>>>
>>>>>>>> The test passes on the following platforms:
>>>>>>>> Solaris 10 sparcv9 (Java Desktop System)
>>>>>>>> Solaris 11 x64 (Gnome 2)
>>>>>>>> Ubuntu 8.04 virtualbox (Gnome 2)
>>>>>>>> Ubuntu 10.04 arm (Gnome 2)
>>>>>>>> Ubuntu 14.04 x64 (Unity)
>>>>>>>>
>>>>>>>> Windows 7 x64 (test just exit with 0 code)
>>>>>>>> OS X 10.9 (test just exit with 0 code)
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>
>
> -- 
> Best regards, Sergey.

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

From dmitry.markov at oracle.com  Fri Jul 18 11:52:27 2014
From: dmitry.markov at oracle.com (dmitry markov)
Date: Fri, 18 Jul 2014 15:52:27 +0400
Subject: <AWT Dev> [9] Review request for 8044614: [macosx] Focus issue
 with 2 applets in firefox
In-Reply-To: <53C7A301.60801@oracle.com>
References: <53B3E2B1.1030303@oracle.com> <53B3FCB5.103@oracle.com>
	<53B51F4C.6060106@oracle.com> <53B52FA1.7040001@oracle.com>
	<53B6813D.9070700@oracle.com> <53C66B51.30308@oracle.com>
	<53C7A301.60801@oracle.com>
Message-ID: <53C90A7B.7070100@oracle.com>

Hi Alexandr,

Please find answer below.

Thanks,
Dmitry
On 17/07/2014 14:18, Alexander Scherbatiy wrote:
>
>   The pluginFocusedWindow is only updated after switching from one 
> browser to another (after WindowFocusEvent event).
>   Should it also be updated after switching from one applet to another 
> in the same browser (after FocusEvent)?
It is not necessary, since the pluginFocusedWindow stores information 
about the latest focused applet in the browser's window. This 
information is only used for focus restoring when the window becomes 
active again. So I think that is enough to update pluginFocusedWindow 
only in handleWindowFocusEvent() when the browser's window becomes inactive.

>
>   What happens if the focused applet is closed? Does the 
> pluginFocusedWindow  correctly updated in this case?
>   Does the closed applet receives handleFocusEvent(false) event?
The closing of an applet means that we closed the browser's window 
contained the applet or moved to another web-page. In this case we are 
not interesting in pluginFocusedWindow or focus events anymore, since 
all applets in the window are destroyed. If we go back to the applet's 
page, all applets will be started from scratch.
>
>    Thanks,
>   Alexandr.
>
>
> On 7/16/2014 4:08 PM, dmitry markov wrote:
>> Hi Alexandr,
>>
>> I am sorry for the delay.
>> When a browser's window becomes active/inactive, the browser 
>> generates WindowFocusEvent and sends it to the applets via Java 
>> Plugin. So the order of the events is defined by the browser. I 
>> tested several browsers - all of them sends 
>> WindowFocusEvent(parentWindow=false) to the active window and then 
>> WindowFocusEvent(parentWindow=true) to inactive window during 
>> switching between two browser's windows. It looks like this is common 
>> practice for such operation. However, I did not find any docs which 
>> can confirm this behavior.
>>
>> Please find new version of the fix here - 
>> http://cr.openjdk.java.net/~dmarkov/8044614/jdk9/webrev.02/
>> Changes:
>> - Made small refactoring: focusedWindow -> globalFocusedWindow, 
>> previousFocusedWindow -> pluginFocusedWindow, etc.
>> - Added manual test
>>
>> Thanks,
>> Dmitry
>>
>> On 04/07/2014 14:26, Alexander Scherbatiy wrote:
>>> On 7/3/2014 2:25 PM, Alexander Scherbatiy wrote:
>>>> On 7/3/2014 1:15 PM, dmitry markov wrote:
>>>>> Hi Alexandr,
>>>>>
>>>>> Thank you for review.
>>>>> For the use case you described - when we move back to the first 
>>>>> browser window with 3 applets, the first applet (not the second 
>>>>> one) will receive the focus. This behavior is incorrect, since the 
>>>>> second applet should receive the focus.
>>>>> I have updated the fix, please find new version here: 
>>>>> http://cr.openjdk.java.net/~dmarkov/8044614/jdk9/webrev.01/
>>>>> Now we store the information about focused applet when browser 
>>>>> window is deactivated and restore the focus to the previously 
>>>>> focused applet when browser window becomes active again
>>>>
>>>>     The case can be more complicated with some browsers where each 
>>>> of them has several applets.
>>>>     It seems there should be a map between a browser and it's 
>>>> focused applet.
>>>
>>>    I see that your fix solves these cases.
>>>
>>>    One more problem can be with the WindowsFocusEvents order.
>>>    Is it guarantee that order of events WindowsFocusEvent 
>>> (parentwindow=false) to one browser and WindowsFocusEvent 
>>> (parentWindow=true)
>>>    for other browser can't be changed?
>>>
>>>   I would suggest to  do a small refactoring.
>>>   Something like focusedWindow to globalFocusedWindow, 
>>> previousFocusedWindow to pluginFocusedWindow, add method like 
>>> isPluginFocused(...)
>>>   and use conditional operator '?' for globalFocusedWindow setting.
>>>
>>>   Thanks,
>>>   Alexandr.
>>>
>>>
>>>>
>>>>
>>>>     Is it possible to add a manual test for the fix?
>>>>
>>>>    Thanks,
>>>>    Alexandr.
>>>>
>>>>>
>>>>> Thanks,
>>>>> Dmitry
>>>>>
>>>>> On 02/07/2014 16:36, Alexander Scherbatiy wrote:
>>>>>>
>>>>>>  Let's assume one browser has 3 applets where the second applet 
>>>>>> has focus.
>>>>>>  I click on the second browser with an applet (the applet 
>>>>>> receives the focus) and then click on the first browser back.
>>>>>>  Should the second applet in the first browser receive the focus?
>>>>>>
>>>>>>  Thanks,
>>>>>>  Alexandr.
>>>>>>
>>>>>> On 7/2/2014 2:45 PM, dmitry markov wrote:
>>>>>>> Hello,
>>>>>>>
>>>>>>> Could you review the fix for jdk9, please?
>>>>>>>
>>>>>>>     bug: https://bugs.openjdk.java.net/browse/JDK-8044614
>>>>>>>     webrev: 
>>>>>>> http://cr.openjdk.java.net/~dmarkov/8044614/jdk9/webrev.00/
>>>>>>>
>>>>>>> Problem description: on Mac OSX when switching between several 
>>>>>>> applets running in separate browser's windows, the applet in 
>>>>>>> active window does not receive focus.
>>>>>>> Fix: the method CEmbeddedFrame.handleWindowFocusEvent() should 
>>>>>>> be modified. It has to detect the switching between browser's 
>>>>>>> windows and update focusedWindow field accordingly.
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Dmitry
>>>>>>
>>>>>
>>>>
>>>
>>
>


From alexandr.scherbatiy at oracle.com  Fri Jul 18 11:57:14 2014
From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy)
Date: Fri, 18 Jul 2014 15:57:14 +0400
Subject: <AWT Dev> [9] Review request for 8044614: [macosx] Focus issue
 with 2 applets in firefox
In-Reply-To: <53C90A7B.7070100@oracle.com>
References: <53B3E2B1.1030303@oracle.com> <53B3FCB5.103@oracle.com>
	<53B51F4C.6060106@oracle.com> <53B52FA1.7040001@oracle.com>
	<53B6813D.9070700@oracle.com> <53C66B51.30308@oracle.com>
	<53C7A301.60801@oracle.com> <53C90A7B.7070100@oracle.com>
Message-ID: <53C90B9A.3050402@oracle.com>


   The fix looks good to me.

   Thanks,
   Alexandr.


On 7/18/2014 3:52 PM, dmitry markov wrote:
> Hi Alexandr,
>
> Please find answer below.
>
> Thanks,
> Dmitry
> On 17/07/2014 14:18, Alexander Scherbatiy wrote:
>>
>>   The pluginFocusedWindow is only updated after switching from one 
>> browser to another (after WindowFocusEvent event).
>>   Should it also be updated after switching from one applet to 
>> another in the same browser (after FocusEvent)?
> It is not necessary, since the pluginFocusedWindow stores information 
> about the latest focused applet in the browser's window. This 
> information is only used for focus restoring when the window becomes 
> active again. So I think that is enough to update pluginFocusedWindow 
> only in handleWindowFocusEvent() when the browser's window becomes 
> inactive.
>
>>
>>   What happens if the focused applet is closed? Does the 
>> pluginFocusedWindow  correctly updated in this case?
>>   Does the closed applet receives handleFocusEvent(false) event?
> The closing of an applet means that we closed the browser's window 
> contained the applet or moved to another web-page. In this case we are 
> not interesting in pluginFocusedWindow or focus events anymore, since 
> all applets in the window are destroyed. If we go back to the applet's 
> page, all applets will be started from scratch.
>>
>>    Thanks,
>>   Alexandr.
>>
>>
>> On 7/16/2014 4:08 PM, dmitry markov wrote:
>>> Hi Alexandr,
>>>
>>> I am sorry for the delay.
>>> When a browser's window becomes active/inactive, the browser 
>>> generates WindowFocusEvent and sends it to the applets via Java 
>>> Plugin. So the order of the events is defined by the browser. I 
>>> tested several browsers - all of them sends 
>>> WindowFocusEvent(parentWindow=false) to the active window and then 
>>> WindowFocusEvent(parentWindow=true) to inactive window during 
>>> switching between two browser's windows. It looks like this is 
>>> common practice for such operation. However, I did not find any docs 
>>> which can confirm this behavior.
>>>
>>> Please find new version of the fix here - 
>>> http://cr.openjdk.java.net/~dmarkov/8044614/jdk9/webrev.02/
>>> Changes:
>>> - Made small refactoring: focusedWindow -> globalFocusedWindow, 
>>> previousFocusedWindow -> pluginFocusedWindow, etc.
>>> - Added manual test
>>>
>>> Thanks,
>>> Dmitry
>>>
>>> On 04/07/2014 14:26, Alexander Scherbatiy wrote:
>>>> On 7/3/2014 2:25 PM, Alexander Scherbatiy wrote:
>>>>> On 7/3/2014 1:15 PM, dmitry markov wrote:
>>>>>> Hi Alexandr,
>>>>>>
>>>>>> Thank you for review.
>>>>>> For the use case you described - when we move back to the first 
>>>>>> browser window with 3 applets, the first applet (not the second 
>>>>>> one) will receive the focus. This behavior is incorrect, since 
>>>>>> the second applet should receive the focus.
>>>>>> I have updated the fix, please find new version here: 
>>>>>> http://cr.openjdk.java.net/~dmarkov/8044614/jdk9/webrev.01/
>>>>>> Now we store the information about focused applet when browser 
>>>>>> window is deactivated and restore the focus to the previously 
>>>>>> focused applet when browser window becomes active again
>>>>>
>>>>>     The case can be more complicated with some browsers where each 
>>>>> of them has several applets.
>>>>>     It seems there should be a map between a browser and it's 
>>>>> focused applet.
>>>>
>>>>    I see that your fix solves these cases.
>>>>
>>>>    One more problem can be with the WindowsFocusEvents order.
>>>>    Is it guarantee that order of events WindowsFocusEvent 
>>>> (parentwindow=false) to one browser and WindowsFocusEvent 
>>>> (parentWindow=true)
>>>>    for other browser can't be changed?
>>>>
>>>>   I would suggest to  do a small refactoring.
>>>>   Something like focusedWindow to globalFocusedWindow, 
>>>> previousFocusedWindow to pluginFocusedWindow, add method like 
>>>> isPluginFocused(...)
>>>>   and use conditional operator '?' for globalFocusedWindow setting.
>>>>
>>>>   Thanks,
>>>>   Alexandr.
>>>>
>>>>
>>>>>
>>>>>
>>>>>     Is it possible to add a manual test for the fix?
>>>>>
>>>>>    Thanks,
>>>>>    Alexandr.
>>>>>
>>>>>>
>>>>>> Thanks,
>>>>>> Dmitry
>>>>>>
>>>>>> On 02/07/2014 16:36, Alexander Scherbatiy wrote:
>>>>>>>
>>>>>>>  Let's assume one browser has 3 applets where the second applet 
>>>>>>> has focus.
>>>>>>>  I click on the second browser with an applet (the applet 
>>>>>>> receives the focus) and then click on the first browser back.
>>>>>>>  Should the second applet in the first browser receive the focus?
>>>>>>>
>>>>>>>  Thanks,
>>>>>>>  Alexandr.
>>>>>>>
>>>>>>> On 7/2/2014 2:45 PM, dmitry markov wrote:
>>>>>>>> Hello,
>>>>>>>>
>>>>>>>> Could you review the fix for jdk9, please?
>>>>>>>>
>>>>>>>>     bug: https://bugs.openjdk.java.net/browse/JDK-8044614
>>>>>>>>     webrev: 
>>>>>>>> http://cr.openjdk.java.net/~dmarkov/8044614/jdk9/webrev.00/
>>>>>>>>
>>>>>>>> Problem description: on Mac OSX when switching between several 
>>>>>>>> applets running in separate browser's windows, the applet in 
>>>>>>>> active window does not receive focus.
>>>>>>>> Fix: the method CEmbeddedFrame.handleWindowFocusEvent() should 
>>>>>>>> be modified. It has to detect the switching between browser's 
>>>>>>>> windows and update focusedWindow field accordingly.
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>> Dmitry
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>


From alexander.v.stepanov at oracle.com  Fri Jul 18 12:59:25 2014
From: alexander.v.stepanov at oracle.com (alexander stepanov)
Date: Fri, 18 Jul 2014 16:59:25 +0400
Subject: <AWT Dev> [9] Review Request for 8049617: move awt automated tests
 from AWT_Modality to OpenJDK repository - part 3
Message-ID: <53C91A2D.1070807@oracle.com>

Hello,

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

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

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  Fri Jul 18 14:44:09 2014
From: anthony.petrov at oracle.com (Anthony Petrov)
Date: Fri, 18 Jul 2014 18:44:09 +0400
Subject: <AWT Dev> [9/8u40] Review request for RT-37149 and JDK-8049065 :
 Implement DnD for SwingNode
Message-ID: <53C932B9.1010409@oracle.com>

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 petr.pchelko at oracle.com  Mon Jul 21 06:51:35 2014
From: petr.pchelko at oracle.com (Petr Pchelko)
Date: Mon, 21 Jul 2014 10:51:35 +0400
Subject: <AWT Dev> [9] Review request for 8046495: KeyEvent can not be
	accepted in quick mouse clicking
In-Reply-To: <53C8F6B2.7020008@oracle.com>
References: <53B2EDEA.3010402@oracle.com>
	<B4A1F8A6-25D8-4CA2-A138-95EC14A6A881@oracle.com>
	<53B413A7.4000809@oracle.com> <53B4253A.3040406@oracle.com>
	<53B42689.4090709@oracle.com>
	<59E88D9A-2BF9-41CF-9128-5E5A83B39EF3@oracle.com>
	<53C793F9.6010703@oracle.com> <53C8F6B2.7020008@oracle.com>
Message-ID: <9743F774-9DDF-4DD0-A164-FB77C236CF34@oracle.com>

Hello, Anton.

Thank you for the cleanup, the new version still looks good to me.

With best regards. Petr.

On 18 ???? 2014 ?., at 14:28, anton nashatyrev <anton.nashatyrev at oracle.com> wrote:

> Hello, 
> 
>     in offline discussion with Artem and Petr we decided to further clean up the code and completely remove TimeHelper functions from awt_Component.cpp in JDK9. 
> 
>     Could you please review the updated fix: http://cr.openjdk.java.net/~anashaty/8046495/9/webrev.01/
> 
> bug: https://bugs.openjdk.java.net/browse/JDK-8046495
> 
> Thank you!
> Anton.
> 
> On 17.07.2014 13:14, anton nashatyrev wrote:
>> Hello All, 
>> 
>>     could please anyone else take a look at the fix? 
>> 
>> Thanks!
>> Anton.
>> 
>> On 02.07.2014 19:37, Petr Pchelko wrote:
>>> Hello, Anton.
>>> 
>>> Thanks for clarifications and additional testing.
>>> The fix looks good to me too.
>>> 
>>> With best regards. Petr.
>>> 
>>> On 02 ???? 2014 ?., at 19:34, Anton V. Tarasov <anton.tarasov at oracle.com> wrote:
>>> 
>>>> On 02.07.2014 19:28, anton nashatyrev wrote:
>>>>> Hello, Anton
>>>>> 
>>>>> On 02.07.2014 18:13, Anton V. Tarasov wrote:
>>>>>> On 02.07.2014 11:44, Petr Pchelko wrote:
>>>>>>> Hello, Anton.
>>>>>>> 
>>>>>>> I'm not sure I have a detailed understanding of what's happening. 
>>>>>>> 
>>>>>>> Before your fix the timestamp of the event represented the time when the event was created, and now it's the time when it's sent to java.
>>>>>>> This might be important if some events cause other events to be issued on the java side. 
>>>>>>> 
>>>>>>> So suppose the following:
>>>>>>> Toolkit thread: InputEvent#1 created      - timestamp 0
>>>>>>> Toolkit thread: InputEvent#2 created      - timestamp 1
>>>>>>> Toolkit thread: InputEvent#1 sent           - timestamp 2
>>>>>>> EDT:                InputEvent#1 dispatched - timestamp 3
>>>>>>> EDT:               FocusEvent  created        - timestamp 4
>>>>>>> Toolkit thread: InputEvent#2 sent           - timestamp 5
>>>>>>> 
>>>>>>> Before you fix we had the following event order: InputEvent#1(ts=0), InputEvent#2(ts=1), FocusEvent(ts=4).
>>>>>>> But after your fix we will have a different order: InputEvent#1(ts=2), FocusEvent(ts=4), InputEvent#2(ts=5).
>>>>>>> So now we would have troubles, because the Input Event will go to the new focused component instead of the old one. 
>>>>>>> Do you think that my arguments are correct? I understand that the likelihood of such a situation is very low, but for me it looks possible? Am I missing something?
>>>>>> 
>>>>>> A timestamp for a FocusEvent is taken from the_most_recent_KeyEvent_time which is set on EDT when the event is dispatched. So the fix shouldn't affect it.
>>>>>> 
>>>>>> Also, in awt_Window.cpp, when a TimedWindowEvent is created it is passed a timestamp got with TimeHelper::getMessageTimeUTC(). It appears, that the fix makes key events times even more consistent with it. So, from the kbd focus perspective, it shouldn't make any harm.
>>>>>> 
>>>>>> Anton, could you just please run the following tests, at least:
>>>>>> 
>>>>>> test/java/awt/Focus/6981400/*
>>>>>> test/java/awt/KeyboardFocusManager/TypeAhead/*
>>>>> 
>>>>> I've tested with the following set: 
>>>>> [closed]/java/awt/event/* 
>>>>> [closed]/java/awt/Focus/* 
>>>>> [closed]java/awt/KeyboardFocusManager/*
>>>>> 
>>>>> : no unexpected failures here.
>>>>> 
>>>>> I've also verified that my regression test which comes with the fix works fine on Linux and Mac (despite the fix is Win specific). 
>>>> 
>>>> Great, thanks!
>>>> 
>>>> Anton.
>>>> 
>>>>> 
>>>>> Thanks for review!
>>>>> Anton.
>>>>> 
>>>>>> 
>>>>>> Thanks,
>>>>>> Anton.
>>>>>> 
>>>>>>> 
>>>>>>> Another thing I do not understand is why we were used to use the complicated formula instead of initializing the msg.time field with the JVM current time and using it when sending the event?
>>>>>>> Wouldn't that resolve both your issue and the issue the original fix was made for?
>>>>>>> 
>>>>>>> I have a couple of comments about the code, but let's postpone that until we decide on the approach.
>>>>>>> 
>>>>>>> Thank you.
>>>>>>> With best regards. Petr.
>>>>>>> 
>>>>>>> On 01 ???? 2014 ?., at 21:20, anton nashatyrev <anton.nashatyrev at oracle.com> wrote:
>>>>>>> 
>>>>>>>> Hello, 
>>>>>>>>     could you please review the following fix:
>>>>>>>> 
>>>>>>>> fix: http://cr.openjdk.java.net/~anashaty/8046495/9/webrev.00/
>>>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8046495
>>>>>>>> 
>>>>>>>>     Problem: 
>>>>>>>> On Windows the later InputEvent may have earlier timestamp (getWhen()), which results in incorrect processing of enqueued input events and may also potentially be the reason of other artifacts 
>>>>>>>> 
>>>>>>>>     Evaluation: 
>>>>>>>> On Windows we have some algorithm for calculating input event timestamp: jdk/src/windows/native/sun/windows/awt_Component.cpp:2100
>>>>>>>> Shortly the timestamp is calculated by the following formula: 
>>>>>>>>     when = JVM_CurrentTimeMillis() - (GetTickCount() - GetMessageTime())
>>>>>>>> 
>>>>>>>> Where: 
>>>>>>>>   JVM_CurrentTimeMillis() - the same as System.currentTimeMillis()
>>>>>>>>   GetTickCount() - Win32 function, current millis from boot time
>>>>>>>>   GetMessageTime() - Win32 function, millis from boot time of the latest native Message
>>>>>>>> 
>>>>>>>> In theory the formula looks good: we are trying our best to calculate the actual time of the OS message by taking the current JVM time (JVM_CurrentTimeMillis) and adjusting it with the offset (GetTickCount - GetMessageTime) which should indicate how many milliseconds ago from the current moment (GetTickCount) the message has been actually issued (GetMessageTime).
>>>>>>>> In practice due to usage of different system timers by the JVM_CurrentTimeMillis and GetTickCount their values are not updated synchronously and we may get an earlier timestamp for the later event. 
>>>>>>>> 
>>>>>>>>     Fix: 
>>>>>>>> Just to use JVM_CurrentTimeMillis only as events timestamp. On Mac this is done in exactly the same way: CPlatformResponder.handleMouse/KeyEvent()
>>>>>>>> 
>>>>>>>> The message time offset calculation has been introduced with the fix for JDK-4434193 and it seems that the issue has addressed very similar problem (At times getWhen()in ActionEvent returns higher value than the CurrentSystemTime) which has not been completely resolved in fact.
>>>>>>>> I also didn't find any benefits in using the existing approach: 
>>>>>>>> - all the usages of the TimerHelper are in fact reduced to the mentioned formula: when = JVM_CurrentTimeMillis() - (GetTickCount() - GetMessageTime())
>>>>>>>> - GetMessageTime() always increases (except of the int overflow moments), thus we couldn't get earlier OS messages after later ones
>>>>>>>> - TimerHelper::windowsToUTC(DWORD windowsTime) doesn't guarantee returning the same timestamp across different calls for the same message time 
>>>>>>>> 
>>>>>>>> Thanks! 
>>>>>>>> Anton. 
>>>>>>> 
>>>>>> 
>>>>> 
>>>> 
>>> 
>> 
> 

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

From petr.pchelko at oracle.com  Mon Jul 21 07:01:06 2014
From: petr.pchelko at oracle.com (Petr Pchelko)
Date: Mon, 21 Jul 2014 11:01:06 +0400
Subject: <AWT Dev> [9] Review Request for 8049617: move awt automated
	tests from AWT_Modality to OpenJDK repository - part 3
In-Reply-To: <53C91A2D.1070807@oracle.com>
References: <53C91A2D.1070807@oracle.com>
Message-ID: <6865DABF-6341-48FA-AE6A-6D6D9543CFDE@oracle.com>

Hello, Alexander.

In doTest you are doing closeAll in the end. But if the test is failed and any assert throws an exception, closeAll will not be called and a frame could be left on the screen. I think it's better to call closeAll from a finally block.

With best regards. Petr.

On 18 ???? 2014 ?., at 16:59, alexander stepanov <alexander.v.stepanov at oracle.com> wrote:

> Hello,
> 
> Could you please review the fix for
> https://bugs.openjdk.java.net/browse/JDK-8049617
> 
> webrev:
> http://cr.openjdk.java.net/~avstepan/8049617/
> 
> 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 alexander.v.stepanov at oracle.com  Mon Jul 21 08:52:49 2014
From: alexander.v.stepanov at oracle.com (alexander stepanov)
Date: Mon, 21 Jul 2014 12:52:49 +0400
Subject: <AWT Dev> [9] Review Request for 8049617: move awt automated
 tests from AWT_Modality to OpenJDK repository - part 3
In-Reply-To: <6865DABF-6341-48FA-AE6A-6D6D9543CFDE@oracle.com>
References: <53C91A2D.1070807@oracle.com>
	<6865DABF-6341-48FA-AE6A-6D6D9543CFDE@oracle.com>
Message-ID: <53CCD4E1.6030807@oracle.com>

Hello Petr,

I didn't observe the remaining windows when the tests are running with 
jtreg and failing (jtreg closes them).
But anyway, the version with 'finally' is better, thanks. Please see the 
webrev updated:
http://cr.openjdk.java.net/~avstepan/8049617/webrev.01/

Regards,
Alexander

On 21.07.2014 11:01, Petr Pchelko wrote:
> Hello, Alexander.
>
> In doTest you are doing closeAll in the end. But if the test is failed and any assert throws an exception, closeAll will not be called and a frame could be left on the screen. I think it's better to call closeAll from a finally block.
>
> With best regards. Petr.
>
> On 18 ???? 2014 ?., at 16:59, alexander stepanov <alexander.v.stepanov at oracle.com> wrote:
>
>> Hello,
>>
>> Could you please review the fix for
>> https://bugs.openjdk.java.net/browse/JDK-8049617
>>
>> webrev:
>> http://cr.openjdk.java.net/~avstepan/8049617/
>>
>> 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 petr.pchelko at oracle.com  Mon Jul 21 08:56:40 2014
From: petr.pchelko at oracle.com (Petr Pchelko)
Date: Mon, 21 Jul 2014 12:56:40 +0400
Subject: <AWT Dev> [9] Review Request for 8049617: move awt automated
	tests from AWT_Modality to OpenJDK repository - part 3
In-Reply-To: <53CCD4E1.6030807@oracle.com>
References: <53C91A2D.1070807@oracle.com>
	<6865DABF-6341-48FA-AE6A-6D6D9543CFDE@oracle.com>
	<53CCD4E1.6030807@oracle.com>
Message-ID: <5E975D8E-47D3-4175-9672-9A93BED65378@oracle.com>

Hello, Alexander.

Thank you for the update. The new version looks good to me.

With best regards. Petr.

On 21 ???? 2014 ?., at 12:52, alexander stepanov <alexander.v.stepanov at oracle.com> wrote:

> Hello Petr,
> 
> I didn't observe the remaining windows when the tests are running with jtreg and failing (jtreg closes them).
> But anyway, the version with 'finally' is better, thanks. Please see the webrev updated:
> http://cr.openjdk.java.net/~avstepan/8049617/webrev.01/
> 
> Regards,
> Alexander
> 
> On 21.07.2014 11:01, Petr Pchelko wrote:
>> Hello, Alexander.
>> 
>> In doTest you are doing closeAll in the end. But if the test is failed and any assert throws an exception, closeAll will not be called and a frame could be left on the screen. I think it's better to call closeAll from a finally block.
>> 
>> With best regards. Petr.
>> 
>> On 18 ???? 2014 ?., at 16:59, alexander stepanov <alexander.v.stepanov at oracle.com> wrote:
>> 
>>> Hello,
>>> 
>>> Could you please review the fix for
>>> https://bugs.openjdk.java.net/browse/JDK-8049617
>>> 
>>> webrev:
>>> http://cr.openjdk.java.net/~avstepan/8049617/
>>> 
>>> 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 alexander.v.stepanov at oracle.com  Mon Jul 21 08:55:03 2014
From: alexander.v.stepanov at oracle.com (alexander stepanov)
Date: Mon, 21 Jul 2014 12:55:03 +0400
Subject: <AWT Dev> [9] Review Request for 8049617: move awt automated
 tests from AWT_Modality to OpenJDK repository - part 3
In-Reply-To: <5E975D8E-47D3-4175-9672-9A93BED65378@oracle.com>
References: <53C91A2D.1070807@oracle.com>
	<6865DABF-6341-48FA-AE6A-6D6D9543CFDE@oracle.com>
	<53CCD4E1.6030807@oracle.com>
	<5E975D8E-47D3-4175-9672-9A93BED65378@oracle.com>
Message-ID: <53CCD567.4000304@oracle.com>

Thanks!

On 21.07.2014 12:56, Petr Pchelko wrote:
> Hello, Alexander.
>
> Thank you for the update. The new version looks good to me.
>
> With best regards. Petr.
>
> On 21 ???? 2014 ?., at 12:52, alexander stepanov <alexander.v.stepanov at oracle.com> wrote:
>
>> Hello Petr,
>>
>> I didn't observe the remaining windows when the tests are running with jtreg and failing (jtreg closes them).
>> But anyway, the version with 'finally' is better, thanks. Please see the webrev updated:
>> http://cr.openjdk.java.net/~avstepan/8049617/webrev.01/
>>
>> Regards,
>> Alexander
>>
>> On 21.07.2014 11:01, Petr Pchelko wrote:
>>> Hello, Alexander.
>>>
>>> In doTest you are doing closeAll in the end. But if the test is failed and any assert throws an exception, closeAll will not be called and a frame could be left on the screen. I think it's better to call closeAll from a finally block.
>>>
>>> With best regards. Petr.
>>>
>>> On 18 ???? 2014 ?., at 16:59, alexander stepanov <alexander.v.stepanov at oracle.com> wrote:
>>>
>>>> Hello,
>>>>
>>>> Could you please review the fix for
>>>> https://bugs.openjdk.java.net/browse/JDK-8049617
>>>>
>>>> webrev:
>>>> http://cr.openjdk.java.net/~avstepan/8049617/
>>>>
>>>> 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 alexandr.scherbatiy at oracle.com  Mon Jul 21 09:33:31 2014
From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy)
Date: Mon, 21 Jul 2014 13:33:31 +0400
Subject: <AWT Dev> [9] Review request for 8051359 JPopupMenu creation in
 headless mode with JDK9b23 causes NPE
Message-ID: <53CCDE6B.6020307@oracle.com>


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.


From petr.pchelko at oracle.com  Mon Jul 21 10:01:50 2014
From: petr.pchelko at oracle.com (Petr Pchelko)
Date: Mon, 21 Jul 2014 14:01:50 +0400
Subject: <AWT Dev> [9] Review request for 8051359 JPopupMenu creation in
	headless mode with JDK9b23 causes NPE
In-Reply-To: <53CCDE6B.6020307@oracle.com>
References: <53CCDE6B.6020307@oracle.com>
Message-ID: <A012739E-9161-403C-A628-0F9B30E90FC5@oracle.com>

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.
> 


From yuri.nesterenko at oracle.com  Mon Jul 21 13:10:36 2014
From: yuri.nesterenko at oracle.com (Yuri Nesterenko)
Date: Mon, 21 Jul 2014 17:10:36 +0400
Subject: <AWT Dev> [9] Review request for 8051440: move tests about
 maximizing undecorated to OpenJDK
Message-ID: <53CD114C.7030308@oracle.com>

Hi team,


please review a small test I'm trying to move to OpenJDK:

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

as a fix to https://bugs.openjdk.java.net/browse/JDK-8051440

I did it from two much bigger and hairy functional tests.

Run on Windows 7/8, OS X 10.9, and Linux with Gnome/Xfce4
(failed on Windows which is expected before a fix to
8022302 )

Thanks,
-yan

From Sergey.Bylokhov at oracle.com  Mon Jul 21 13:35:04 2014
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Mon, 21 Jul 2014 17:35:04 +0400
Subject: <AWT Dev> [9] Review Request: 6521783 Unnecessary final modifier
 for a method in a final class
Message-ID: <53CD1708.5010605@oracle.com>

Hello.
Please review a small fix of warnings from another one tool:
I fix all related issues in the client code.

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

-- 
Best regards, Sergey.


From Sergey.Bylokhov at oracle.com  Mon Jul 21 13:51:04 2014
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Mon, 21 Jul 2014 17:51:04 +0400
Subject: <AWT Dev> [9] Review request for 8051440: move tests about
 maximizing undecorated to OpenJDK
In-Reply-To: <53CD114C.7030308@oracle.com>
References: <53CD114C.7030308@oracle.com>
Message-ID: <53CD1AC8.9050407@oracle.com>

Hi, Yuri.
The fix looks good.
I assume that JDK-8022302 should be updated with new RULE.

On 7/21/14 5:10 PM, Yuri Nesterenko wrote:
> Hi team,
>
>
> please review a small test I'm trying to move to OpenJDK:
>
> http://cr.openjdk.java.net/~yan/8051440/webrev.00/
>
> as a fix to https://bugs.openjdk.java.net/browse/JDK-8051440
>
> I did it from two much bigger and hairy functional tests.
>
> Run on Windows 7/8, OS X 10.9, and Linux with Gnome/Xfce4
> (failed on Windows which is expected before a fix to
> 8022302 )
>
> Thanks,
> -yan


-- 
Best regards, Sergey.


From yuri.nesterenko at oracle.com  Mon Jul 21 14:04:53 2014
From: yuri.nesterenko at oracle.com (Yuri Nesterenko)
Date: Mon, 21 Jul 2014 18:04:53 +0400
Subject: <AWT Dev> [9] Review request for 8051440: move tests about
 maximizing undecorated to OpenJDK
In-Reply-To: <53CD1AC8.9050407@oracle.com>
References: <53CD114C.7030308@oracle.com> <53CD1AC8.9050407@oracle.com>
Message-ID: <53CD1E05.3080200@oracle.com>

Thank you Sergey,

yes, I'll take care of that, and that should be
regular practice for moving tests.

-yan

On 07/21/2014 05:51 PM, Sergey Bylokhov wrote:
> Hi, Yuri.
> The fix looks good.
> I assume that JDK-8022302 should be updated with new RULE.
>
> On 7/21/14 5:10 PM, Yuri Nesterenko wrote:
>> Hi team,
>>
>>
>> please review a small test I'm trying to move to OpenJDK:
>>
>> http://cr.openjdk.java.net/~yan/8051440/webrev.00/
>>
>> as a fix to https://bugs.openjdk.java.net/browse/JDK-8051440
>>
>> I did it from two much bigger and hairy functional tests.
>>
>> Run on Windows 7/8, OS X 10.9, and Linux with Gnome/Xfce4
>> (failed on Windows which is expected before a fix to
>> 8022302 )
>>
>> Thanks,
>> -yan
>
>


From petr.pchelko at oracle.com  Mon Jul 21 14:53:45 2014
From: petr.pchelko at oracle.com (Petr Pchelko)
Date: Mon, 21 Jul 2014 18:53:45 +0400
Subject: <AWT Dev> [9] Review Request: 6521783 Unnecessary final
	modifier for a method in a final class
In-Reply-To: <53CD1708.5010605@oracle.com>
References: <53CD1708.5010605@oracle.com>
Message-ID: <1CACBFFA-611E-43F8-8631-AD1EFAEF89CB@oracle.com>

Hello, Sergey.

The fix looks good.

What do you think about filing new CRs for private final methods and static final methods?

With best regards. Petr.

> On Jul 21, 2014, at 5:35 PM, Sergey Bylokhov <Sergey.Bylokhov at oracle.com> wrote:
> 
> Hello.
> Please review a small fix of warnings from another one tool:
> I fix all related issues in the client code.
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-6521783
> Webrev can be found at: http://cr.openjdk.java.net/~serb/6521783/webrev.00
> 
> -- 
> Best regards, Sergey.
> 


From petr.pchelko at oracle.com  Mon Jul 21 14:57:06 2014
From: petr.pchelko at oracle.com (Petr Pchelko)
Date: Mon, 21 Jul 2014 18:57:06 +0400
Subject: <AWT Dev> [9] Review request for 8051440: move tests about
	maximizing undecorated to OpenJDK
In-Reply-To: <53CD1E05.3080200@oracle.com>
References: <53CD114C.7030308@oracle.com> <53CD1AC8.9050407@oracle.com>
	<53CD1E05.3080200@oracle.com>
Message-ID: <EF749384-236A-4EAE-BFBB-CC9071640622@oracle.com>

Hello, Yuri.

The fix looks good to me.

With best regards. Petr.

> On Jul 21, 2014, at 6:04 PM, Yuri Nesterenko <yuri.nesterenko at oracle.com> wrote:
> 
> Thank you Sergey,
> 
> yes, I'll take care of that, and that should be
> regular practice for moving tests.
> 
> -yan
> 
> On 07/21/2014 05:51 PM, Sergey Bylokhov wrote:
>> Hi, Yuri.
>> The fix looks good.
>> I assume that JDK-8022302 should be updated with new RULE.
>> 
>> On 7/21/14 5:10 PM, Yuri Nesterenko wrote:
>>> Hi team,
>>> 
>>> 
>>> please review a small test I'm trying to move to OpenJDK:
>>> 
>>> http://cr.openjdk.java.net/~yan/8051440/webrev.00/
>>> 
>>> as a fix to https://bugs.openjdk.java.net/browse/JDK-8051440
>>> 
>>> I did it from two much bigger and hairy functional tests.
>>> 
>>> Run on Windows 7/8, OS X 10.9, and Linux with Gnome/Xfce4
>>> (failed on Windows which is expected before a fix to
>>> 8022302 )
>>> 
>>> Thanks,
>>> -yan
>> 
>> 
> 


From Sergey.Bylokhov at oracle.com  Mon Jul 21 15:12:38 2014
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Mon, 21 Jul 2014 19:12:38 +0400
Subject: <AWT Dev> [9] Review Request: 6521783 Unnecessary final
 modifier for a method in a final class
In-Reply-To: <1CACBFFA-611E-43F8-8631-AD1EFAEF89CB@oracle.com>
References: <53CD1708.5010605@oracle.com>
	<1CACBFFA-611E-43F8-8631-AD1EFAEF89CB@oracle.com>
Message-ID: <53CD2DE6.4040105@oracle.com>

On 7/21/14 6:53 PM, Petr Pchelko wrote:
> Hello, Sergey.
>
> The fix looks good.
>
> What do you think about filing new CRs for private final methods and static final methods?
Actually I have nothing against private/static final methods. Some times 
I used them
>
> With best regards. Petr.
>
>> On Jul 21, 2014, at 5:35 PM, Sergey Bylokhov <Sergey.Bylokhov at oracle.com> wrote:
>>
>> Hello.
>> Please review a small fix of warnings from another one tool:
>> I fix all related issues in the client code.
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-6521783
>> Webrev can be found at: http://cr.openjdk.java.net/~serb/6521783/webrev.00
>>
>> -- 
>> Best regards, Sergey.
>>


-- 
Best regards, Sergey.


From petr.pchelko at oracle.com  Mon Jul 21 15:22:31 2014
From: petr.pchelko at oracle.com (Petr Pchelko)
Date: Mon, 21 Jul 2014 19:22:31 +0400
Subject: <AWT Dev> [9] Review Request: 6521783 Unnecessary final
	modifier for a method in a final class
In-Reply-To: <53CD2DE6.4040105@oracle.com>
References: <53CD1708.5010605@oracle.com>
	<1CACBFFA-611E-43F8-8631-AD1EFAEF89CB@oracle.com>
	<53CD2DE6.4040105@oracle.com>
Message-ID: <62DDE9AF-5FE4-40D8-BB22-9F60CA373EC3@oracle.com>

>> What do you think about filing new CRs for private final methods and static final methods?
> Actually I have nothing against private/static final methods. Some times I used them
private final is useless because you can?t override it anyway. It?s arguable as we can possibly
change the method to protected and forget to add final, but static methods cannot be overridden 
at all, so final in this case is completely useless and it only annoys as IDEA highlights these issues.

With best regards. Petr.


> On Jul 21, 2014, at 7:12 PM, Sergey Bylokhov <Sergey.Bylokhov at oracle.com> wrote:
> 
> On 7/21/14 6:53 PM, Petr Pchelko wrote:
>> Hello, Sergey.
>> 
>> The fix looks good.
>> 
>> What do you think about filing new CRs for private final methods and static final methods?
> Actually I have nothing against private/static final methods. Some times I used them
>> 
>> With best regards. Petr.
>> 
>>> On Jul 21, 2014, at 5:35 PM, Sergey Bylokhov <Sergey.Bylokhov at oracle.com> wrote:
>>> 
>>> Hello.
>>> Please review a small fix of warnings from another one tool:
>>> I fix all related issues in the client code.
>>> 
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-6521783
>>> Webrev can be found at: http://cr.openjdk.java.net/~serb/6521783/webrev.00
>>> 
>>> -- 
>>> Best regards, Sergey.
>>> 
> 
> 
> -- 
> Best regards, Sergey.

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

From Sergey.Bylokhov at oracle.com  Mon Jul 21 15:31:18 2014
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Mon, 21 Jul 2014 19:31:18 +0400
Subject: <AWT Dev> [9] Review Request: 6521783 Unnecessary final
 modifier for a method in a final class
In-Reply-To: <62DDE9AF-5FE4-40D8-BB22-9F60CA373EC3@oracle.com>
References: <53CD1708.5010605@oracle.com>
	<1CACBFFA-611E-43F8-8631-AD1EFAEF89CB@oracle.com>
	<53CD2DE6.4040105@oracle.com>
	<62DDE9AF-5FE4-40D8-BB22-9F60CA373EC3@oracle.com>
Message-ID: <53CD3246.6040203@oracle.com>

On 7/21/14 7:22 PM, Petr Pchelko wrote:
>>> What do you think about filing new CRs for private final methods and 
>>> static final methods?
>> Actually I have nothing against private/static final methods. Some 
>> times I used them
> private final is useless because you can?t override it anyway. It?s 
> arguable as we can possibly
> change the method to protected and forget to add final,
but subclasses can create the method with the same name , this sometime 
is not obvious for readers.
> but static methods cannot be overridden
> at all, so final in this case is completely useless and it only annoys 
> as IDEA highlights these issues.
Same for static, http://youtrack.jetbrains.com/issue/IDEA-92076
Usually I mark all my static method as final.
>
> With best regards. Petr.
>
>
>> On Jul 21, 2014, at 7:12 PM, Sergey Bylokhov 
>> <Sergey.Bylokhov at oracle.com <mailto:Sergey.Bylokhov at oracle.com>> wrote:
>>
>> On 7/21/14 6:53 PM, Petr Pchelko wrote:
>>> Hello, Sergey.
>>>
>>> The fix looks good.
>>>
>>> What do you think about filing new CRs for private final methods and 
>>> static final methods?
>> Actually I have nothing against private/static final methods. Some 
>> times I used them
>>>
>>> With best regards. Petr.
>>>
>>>> On Jul 21, 2014, at 5:35 PM, Sergey Bylokhov 
>>>> <Sergey.Bylokhov at oracle.com <mailto:Sergey.Bylokhov at oracle.com>> wrote:
>>>>
>>>> Hello.
>>>> Please review a small fix of warnings from another one tool:
>>>> I fix all related issues in the client code.
>>>>
>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-6521783
>>>> Webrev can be found at: 
>>>> http://cr.openjdk.java.net/~serb/6521783/webrev.00 
>>>> <http://cr.openjdk.java.net/%7Eserb/6521783/webrev.00>
>>>>
>>>> --
>>>> Best regards, Sergey.
>>>>
>>
>>
>> --
>> Best regards, Sergey.
>


-- 
Best regards, Sergey.

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

From petr.pchelko at oracle.com  Mon Jul 21 15:41:24 2014
From: petr.pchelko at oracle.com (Petr Pchelko)
Date: Mon, 21 Jul 2014 19:41:24 +0400
Subject: <AWT Dev> [9] Review Request: 6521783 Unnecessary final
	modifier for a method in a final class
In-Reply-To: <53CD3246.6040203@oracle.com>
References: <53CD1708.5010605@oracle.com>
	<1CACBFFA-611E-43F8-8631-AD1EFAEF89CB@oracle.com>
	<53CD2DE6.4040105@oracle.com>
	<62DDE9AF-5FE4-40D8-BB22-9F60CA373EC3@oracle.com>
	<53CD3246.6040203@oracle.com>
Message-ID: <74969411-4754-4BE3-AC40-F603FCE463DD@oracle.com>

> On Jul 21, 2014, at 7:31 PM, Sergey Bylokhov <Sergey.Bylokhov at oracle.com> wrote:
> 
> On 7/21/14 7:22 PM, Petr Pchelko wrote:
>>>> What do you think about filing new CRs for private final methods and static final methods?
>>> Actually I have nothing against private/static final methods. Some times I used them
>> private final is useless because you can?t override it anyway. It?s arguable as we can possibly
>> change the method to protected and forget to add final,
> but subclasses can create the method with the same name , this sometime is not obvious for readers.
>> but static methods cannot be overridden 
>> at all, so final in this case is completely useless and it only annoys as IDEA highlights these issues.
> Same for static, http://youtrack.jetbrains.com/issue/IDEA-92076
> Usually I mark all my static method as final.
Ok, I agree. Idea tricked me a bit) Anyway, it?s not related directly to the current review.

With best regards. Petr.

> On Jul 21, 2014, at 7:31 PM, Sergey Bylokhov <Sergey.Bylokhov at oracle.com> wrote:
> 
> On 7/21/14 7:22 PM, Petr Pchelko wrote:
>>>> What do you think about filing new CRs for private final methods and static final methods?
>>> Actually I have nothing against private/static final methods. Some times I used them
>> private final is useless because you can?t override it anyway. It?s arguable as we can possibly
>> change the method to protected and forget to add final,
> but subclasses can create the method with the same name , this sometime is not obvious for readers.
>> but static methods cannot be overridden 
>> at all, so final in this case is completely useless and it only annoys as IDEA highlights these issues.
> Same for static, http://youtrack.jetbrains.com/issue/IDEA-92076
> Usually I mark all my static method as final.
>> 
>> With best regards. Petr.
>> 
>> 
>>> On Jul 21, 2014, at 7:12 PM, Sergey Bylokhov <Sergey.Bylokhov at oracle.com> wrote:
>>> 
>>> On 7/21/14 6:53 PM, Petr Pchelko wrote:
>>>> Hello, Sergey.
>>>> 
>>>> The fix looks good.
>>>> 
>>>> What do you think about filing new CRs for private final methods and static final methods?
>>> Actually I have nothing against private/static final methods. Some times I used them
>>>> 
>>>> With best regards. Petr.
>>>> 
>>>>> On Jul 21, 2014, at 5:35 PM, Sergey Bylokhov <Sergey.Bylokhov at oracle.com> wrote:
>>>>> 
>>>>> Hello.
>>>>> Please review a small fix of warnings from another one tool:
>>>>> I fix all related issues in the client code.
>>>>> 
>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-6521783
>>>>> Webrev can be found at: http://cr.openjdk.java.net/~serb/6521783/webrev.00
>>>>> 
>>>>> -- 
>>>>> Best regards, Sergey.
>>>>> 
>>> 
>>> 
>>> -- 
>>> Best regards, Sergey.
>> 
> 
> 
> -- 
> Best regards, Sergey. 

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

From alexandr.scherbatiy at oracle.com  Tue Jul 22 11:00:20 2014
From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy)
Date: Tue, 22 Jul 2014 15:00:20 +0400
Subject: <AWT Dev> [9] Review request for 8051359 JPopupMenu creation in
 headless mode with JDK9b23 causes NPE
In-Reply-To: <A012739E-9161-403C-A628-0F9B30E90FC5@oracle.com>
References: <53CCDE6B.6020307@oracle.com>
	<A012739E-9161-403C-A628-0F9B30E90FC5@oracle.com>
Message-ID: <53CE4444.9090102@oracle.com>


   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.
>>


From petr.pchelko at oracle.com  Tue Jul 22 11:06:14 2014
From: petr.pchelko at oracle.com (Petr Pchelko)
Date: Tue, 22 Jul 2014 15:06:14 +0400
Subject: <AWT Dev> [9] Review request for 8051359 JPopupMenu creation in
	headless mode with JDK9b23 causes NPE
In-Reply-To: <53CE4444.9090102@oracle.com>
References: <53CCDE6B.6020307@oracle.com>
	<A012739E-9161-403C-A628-0F9B30E90FC5@oracle.com>
	<53CE4444.9090102@oracle.com>
Message-ID: <04ABA9FE-E79B-439A-9E64-A10AA2E879D8@oracle.com>

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.
>>> 
> 


From petr.pchelko at oracle.com  Tue Jul 22 11:50:42 2014
From: petr.pchelko at oracle.com (Petr Pchelko)
Date: Tue, 22 Jul 2014 15:50:42 +0400
Subject: <AWT Dev> [9] Review Request: 8051449 Incorrect parsing of the
	default flavor mapping
Message-ID: <9F9664FC-8435-408E-9941-10858D1E288B@oracle.com>

Hello, AWT Team.

Please review the fix for the issue:
https://bugs.openjdk.java.net/browse/JDK-8051449
The fix is available at:
http://cr.openjdk.java.net/~pchelko/9/8051449/webrev/webrev/

This is a regression of one of my recent fixes where I've got a bit too brave with a clenup.
Here I've returning back the loadConvert function which translates escaped characters in
a properties file to their actual ASCII representation.

Thank you.
With best regards. Petr.

From petr.pchelko at oracle.com  Tue Jul 22 12:20:53 2014
From: petr.pchelko at oracle.com (Petr Pchelko)
Date: Tue, 22 Jul 2014 16:20:53 +0400
Subject: <AWT Dev> [9] Review Request: 8051588 DataTransferer.getInstance
	throws ClassCastException in headless mode
Message-ID: <F3E802AE-2F7E-4DCD-8B34-85479636C9AB@oracle.com>

Hello, AWT Team.

Please review the fix for the issue:
https://bugs.openjdk.java.net/browse/JDK-8051588
The fix is available at:
http://cr.openjdk.java.net/~pchelko/9/8051588/webrev/

JCK test fails in headless mode because of this issue.

With best regards. Petr.

From petr.pchelko at oracle.com  Tue Jul 22 12:58:29 2014
From: petr.pchelko at oracle.com (Petr Pchelko)
Date: Tue, 22 Jul 2014 16:58:29 +0400
Subject: <AWT Dev> [9] Review Request: 8032864 [macosx] sigsegv (0Xb)
	Being Generated When Starting JDev With Voiceover Running
In-Reply-To: <53BF0CCF.7020405@oracle.com>
References: <2EF15C2B-3C4B-4A72-97AE-8841C7A5A04C@oracle.com>
	<53BF0CCF.7020405@oracle.com>
Message-ID: <E4391BB3-010B-4EAD-8CC1-3879C1B74EDB@oracle.com>

Hello, AWT team.

This is a reminder.

With best regards. Petr.

On 11 ???? 2014 ?., at 1:59, Anthony Petrov <anthony.petrov at oracle.com> wrote:

> Hi Petr,
> 
> I'm fine with the targeted fix. We often do a similar thing in JavaFX when processing various events, so the approach is proven to work good.
> 
> However, generally I agree with your comment from the bug report about the necessity to process dispose selectors in the outer event loop only. IIRC, we do something similar in the WToolkit native implementation. So I suggest to file a separate medium priority bug to investigate this further for JDK 9 (or tbd-major).
> 
> --
> best regards,
> Anthony
> 
> On 7/10/2014 5:02 PM, Petr Pchelko wrote:
>> Hello, AWT team.
>> 
>> Please review a small fix for the issue:
>> https://bugs.openjdk.java.net/browse/JDK-8032864
>> The fix is available at:
>> http://cr.openjdk.java.net/~pchelko/9/8032864/webrev.01/
>> 
>> I failed to create a general fix for the core problem, so I've made a point fix for this bug. The problem is that CAccessible.getFocusOwner opens a nested loop and goes to EDT.
>> This leads to some unknown reordering of selectors, and we crash. retain/releasing the window around the call to getFocusOwner fixes this particular bug.
>> I've trued to make a minimal fix as it needs to be backported to 8 and 7. I've checked for memory leaks using Instruments.
>> 
>> With best regards. Petr.
>> 


From Sergey.Bylokhov at oracle.com  Tue Jul 22 12:58:43 2014
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Tue, 22 Jul 2014 16:58:43 +0400
Subject: <AWT Dev> [9] Review Request: 8032864 [macosx] sigsegv (0Xb)
 Being Generated When Starting JDev With Voiceover Running
In-Reply-To: <E4391BB3-010B-4EAD-8CC1-3879C1B74EDB@oracle.com>
References: <2EF15C2B-3C4B-4A72-97AE-8841C7A5A04C@oracle.com>
	<53BF0CCF.7020405@oracle.com>
	<E4391BB3-010B-4EAD-8CC1-3879C1B74EDB@oracle.com>
Message-ID: <53CE6003.7080706@oracle.com>

Hi, Petr.
The fix looks good.

On 22.07.2014 16:58, Petr Pchelko wrote:
> Hello, AWT team.
>
> This is a reminder.
>
> With best regards. Petr.
>
> On 11 ???? 2014 ?., at 1:59, Anthony Petrov <anthony.petrov at oracle.com> wrote:
>
>> Hi Petr,
>>
>> I'm fine with the targeted fix. We often do a similar thing in JavaFX when processing various events, so the approach is proven to work good.
>>
>> However, generally I agree with your comment from the bug report about the necessity to process dispose selectors in the outer event loop only. IIRC, we do something similar in the WToolkit native implementation. So I suggest to file a separate medium priority bug to investigate this further for JDK 9 (or tbd-major).
>>
>> --
>> best regards,
>> Anthony
>>
>> On 7/10/2014 5:02 PM, Petr Pchelko wrote:
>>> Hello, AWT team.
>>>
>>> Please review a small fix for the issue:
>>> https://bugs.openjdk.java.net/browse/JDK-8032864
>>> The fix is available at:
>>> http://cr.openjdk.java.net/~pchelko/9/8032864/webrev.01/
>>>
>>> I failed to create a general fix for the core problem, so I've made a point fix for this bug. The problem is that CAccessible.getFocusOwner opens a nested loop and goes to EDT.
>>> This leads to some unknown reordering of selectors, and we crash. retain/releasing the window around the call to getFocusOwner fixes this particular bug.
>>> I've trued to make a minimal fix as it needs to be backported to 8 and 7. I've checked for memory leaks using Instruments.
>>>
>>> With best regards. Petr.
>>>


-- 
Best regards, Sergey.


From petr.pchelko at oracle.com  Tue Jul 22 14:04:15 2014
From: petr.pchelko at oracle.com (Petr Pchelko)
Date: Tue, 22 Jul 2014 18:04:15 +0400
Subject: <AWT Dev> [9] Review Request: 8037485 Refactor
	java.awt.datatransfer to eliminate dependency on AWT
In-Reply-To: <53C8E5C3.6030903@oracle.com>
References: <AC897956-F1CC-457F-B99D-24082558C011@oracle.com>
	<53C8E5C3.6030903@oracle.com>
Message-ID: <357393F5-C72C-4122-B753-C8A515116616@oracle.com>

Hello,

I've updated the fix. The new version is located here:
http://cr.openjdk.java.net/~pchelko/9/8037485/webrev.01/

I've reverted RMI changes as they will be handled separately. 
Also I've changed package names, now the internal part of the datatransfer module is called sun.datatransfer. This allowed to make less renamings and leave sun.awt.datatransfer package as is. 

With best regards. Petr.

On 18 ???? 2014 ?., at 13:15, Alan Bateman <Alan.Bateman at oracle.com> wrote:

> On 17/07/2014 12:07, Petr Pchelko wrote:
>> Hello,
>> 
>> Please review the fix for the issue:
>> https://bugs.openjdk.java.net/browse/JDK-8037485
>> The fix is available at:
>> http://cr.openjdk.java.net/~pchelko/9/8037485/webrev.00
>> 
>> This fix separates the public datatransfer API from the desktop module. The datatransfer module would contain java.awt.datatransfer and sun.awt.datatransfer packages.
>> The sun.awt.datatransfer.desktop contains platform-dependent features of the datatransfer system and belongs to the desktop module. So, most of the changes are just package renaming.
>> 
>> DataTransferer class was split into 2 parts:
>> 1. Utilities to work with the DataFlavor is moved to the DataFlavorUtil class. It's just a collection of uility functions and classes
>> 2. Java objects to native representation converters are left in the DataTransferer class and moved to the desktop module. It's needed only with DnD and system clipboard API, so it naturally belong to desktop.
>> 
>> DesktopDatatransferServices was created. This is a collection of services that datatrasfer module could use from desktop if desktop is present. ServiceLoader is used because reflection does not cross module boundaries for non-exported APIs
>> 
>> RMIAccessServices - a collection of services which RMI module might provide to desktop and datatransfer. If RMI module is present we can transfer RMI classes. If not - we cannot. 
>> 
>> The fix was tested on all platforms with jtreg and JCK. No new test failures found. Also the fix was tested without the RMI and without the desktop module.
> Mandy and I had a brief discussion with Petr about this. One suggestion is to separate out the changes related to RMI as there are other approaches there. This would also make it a bit easier to review the most important work to factor out the datatransfer API.
> 
> -Alan.

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

From Alan.Bateman at oracle.com  Tue Jul 22 15:08:24 2014
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Tue, 22 Jul 2014 16:08:24 +0100
Subject: <AWT Dev> [9] Review Request: 8037485 Refactor
 java.awt.datatransfer to eliminate dependency on AWT
In-Reply-To: <357393F5-C72C-4122-B753-C8A515116616@oracle.com>
References: <AC897956-F1CC-457F-B99D-24082558C011@oracle.com>
	<53C8E5C3.6030903@oracle.com>
	<357393F5-C72C-4122-B753-C8A515116616@oracle.com>
Message-ID: <53CE7E68.4020709@oracle.com>

On 22/07/2014 15:04, Petr Pchelko wrote:
> Hello,
>
> I've updated the fix. The new version is located here:
> http://cr.openjdk.java.net/~pchelko/9/8037485/webrev.01/ 
> <http://cr.openjdk.java.net/%7Epchelko/9/8037485/webrev.01/>
>
> I've reverted RMI changes as they will be handled separately.
> Also I've changed package names, now the internal part of the 
> datatransfer module is called sun.datatransfer. This allowed to make 
> less renamings and leave sun.awt.datatransfer package as is.
>
> With best regards. Petr.
>
I'm skimmed over the changes (not a detailed review, best for someone 
working in this area to do that). It looks much better to me. We can 
deal with the optional dependency on RMI separately.

I've mostly focused on the ServiceLoader usage in this webrev. The only 
concern is that getDesktopService is "static synchronized" so that you 
cause contention.  You could replace this with a lazy holder idiom, or 
just make make desktopService volatile, it shouldn't matter if multiple 
threads cause desktopDatatransferService is set more than once. A 
suggestion for getFlavorMap is use "FlavorMap map = this.flavorMap" and 
check it for null to avoid doing two volatile reads.

A minor type on the declaration of flavorMap, it reads "if there is not 
Desktop module", I think you mean "if there is not a desktop" or "if 
there isn't a desktop module".

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

From artem.malinko at oracle.com  Tue Jul 22 16:04:01 2014
From: artem.malinko at oracle.com (artem malinko)
Date: Tue, 22 Jul 2014 20:04:01 +0400
Subject: <AWT Dev> Review request for 8047288: [macosx] Endless loop in EDT
	on Mac
Message-ID: <53CE8B71.8020807@oracle.com>

Hello, AWT Team.

Please review a fix for the issue:
https://bugs.openjdk.java.net/browse/JDK-8047288
The fix is available at:
http://cr.openjdk.java.net/~mcherkas/artem/8047288/webrev.01/ 
<http://cr.openjdk.java.net/%7Emcherkas/artem/8047288/webrev.01/>

Window.isFocusableWindow() could lead to deadlock if it is invoked on 
AppKit thread. Fix caches result of Window.isFocusableWindow() on a peer 
level and method is not invoked on AppkitThread.

Thank you.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20140722/7f1b8102/attachment-0001.html>

From petr.pchelko at oracle.com  Tue Jul 22 16:23:51 2014
From: petr.pchelko at oracle.com (Petr Pchelko)
Date: Tue, 22 Jul 2014 20:23:51 +0400
Subject: <AWT Dev> Review request for 8047288: [macosx] Endless loop in
	EDT on Mac
In-Reply-To: <53CE8B71.8020807@oracle.com>
References: <53CE8B71.8020807@oracle.com>
Message-ID: <D741BDAC-3A69-46D1-A565-53360414E406@oracle.com>

Hello, Artem.

A couple of comments:
1. LWWindowPeer: 268 - please remove an empty line.
2. LWWIndowPeer. isTargetFocusable - the method is not needed at all. 
3. I?m concerned about the test. Do you really need the close button? 
4. frame and window variables are set from main thread and read from EDT. They should be declared volatile.

Also please run all focus regression and JCK tests, because this area is very sensitive.

With best regards. Petr.

> On Jul 22, 2014, at 8:04 PM, artem malinko <artem.malinko at oracle.com> wrote:
> 
> Hello, AWT Team. 
> 
> Please review a fix for the issue: 
> https://bugs.openjdk.java.net/browse/JDK-8047288
> The fix is available at: 
> http://cr.openjdk.java.net/~mcherkas/artem/8047288/webrev.01/
> 
> Window.isFocusableWindow() could lead to deadlock if it is invoked on AppKit thread. Fix caches result of Window.isFocusableWindow() on a peer level and method is not invoked on AppkitThread.
> 
> Thank you.

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

From philip.race at oracle.com  Tue Jul 22 20:36:43 2014
From: philip.race at oracle.com (Phil Race)
Date: Tue, 22 Jul 2014 13:36:43 -0700
Subject: <AWT Dev> [OpenJDK 2D-Dev] [9] Review Request: 6521783
 Unnecessary final modifier for a method in a final class
In-Reply-To: <53CD1708.5010605@oracle.com>
References: <53CD1708.5010605@oracle.com>
Message-ID: <53CECB5B.6050003@oracle.com>

Looks OK. There are a small number of API / javadoc visible changes here
and although I can't imagine this changes the class signatures, you may
want to check this with someone in case the JCK signature tests need to 
be updated.
I don't think it should but best to be safe.

-phil.

On 7/21/14 6:35 AM, Sergey Bylokhov wrote:
> Hello.
> Please review a small fix of warnings from another one tool:
> I fix all related issues in the client code.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-6521783
> Webrev can be found at: 
> http://cr.openjdk.java.net/~serb/6521783/webrev.00
>


From dmitry.markov at oracle.com  Wed Jul 23 07:29:46 2014
From: dmitry.markov at oracle.com (dmitry markov)
Date: Wed, 23 Jul 2014 11:29:46 +0400
Subject: <AWT Dev> [9] Review request for 8044614: [macosx] Focus issue
 with 2 applets in firefox
In-Reply-To: <53C90B9A.3050402@oracle.com>
References: <53B3E2B1.1030303@oracle.com> <53B3FCB5.103@oracle.com>
	<53B51F4C.6060106@oracle.com> <53B52FA1.7040001@oracle.com>
	<53B6813D.9070700@oracle.com> <53C66B51.30308@oracle.com>
	<53C7A301.60801@oracle.com> <53C90A7B.7070100@oracle.com>
	<53C90B9A.3050402@oracle.com>
Message-ID: <53CF646A.3090507@oracle.com>

Hello,

Could anyone else review the fix, please?

https://bugs.openjdk.java.net/browse/JDK-8044614
http://cr.openjdk.java.net/~dmarkov/8044614/jdk9/webrev.02/

Thanks in advance,
Dmitry

On 18/07/2014 15:57, Alexander Scherbatiy wrote:
>
>   The fix looks good to me.
>
>   Thanks,
>   Alexandr.
>
>
> On 7/18/2014 3:52 PM, dmitry markov wrote:
>> Hi Alexandr,
>>
>> Please find answer below.
>>
>> Thanks,
>> Dmitry
>> On 17/07/2014 14:18, Alexander Scherbatiy wrote:
>>>
>>>   The pluginFocusedWindow is only updated after switching from one 
>>> browser to another (after WindowFocusEvent event).
>>>   Should it also be updated after switching from one applet to 
>>> another in the same browser (after FocusEvent)?
>> It is not necessary, since the pluginFocusedWindow stores information 
>> about the latest focused applet in the browser's window. This 
>> information is only used for focus restoring when the window becomes 
>> active again. So I think that is enough to update pluginFocusedWindow 
>> only in handleWindowFocusEvent() when the browser's window becomes 
>> inactive.
>>
>>>
>>>   What happens if the focused applet is closed? Does the 
>>> pluginFocusedWindow  correctly updated in this case?
>>>   Does the closed applet receives handleFocusEvent(false) event?
>> The closing of an applet means that we closed the browser's window 
>> contained the applet or moved to another web-page. In this case we 
>> are not interesting in pluginFocusedWindow or focus events anymore, 
>> since all applets in the window are destroyed. If we go back to the 
>> applet's page, all applets will be started from scratch.
>>>
>>>    Thanks,
>>>   Alexandr.
>>>
>>>
>>> On 7/16/2014 4:08 PM, dmitry markov wrote:
>>>> Hi Alexandr,
>>>>
>>>> I am sorry for the delay.
>>>> When a browser's window becomes active/inactive, the browser 
>>>> generates WindowFocusEvent and sends it to the applets via Java 
>>>> Plugin. So the order of the events is defined by the browser. I 
>>>> tested several browsers - all of them sends 
>>>> WindowFocusEvent(parentWindow=false) to the active window and then 
>>>> WindowFocusEvent(parentWindow=true) to inactive window during 
>>>> switching between two browser's windows. It looks like this is 
>>>> common practice for such operation. However, I did not find any 
>>>> docs which can confirm this behavior.
>>>>
>>>> Please find new version of the fix here - 
>>>> http://cr.openjdk.java.net/~dmarkov/8044614/jdk9/webrev.02/
>>>> Changes:
>>>> - Made small refactoring: focusedWindow -> globalFocusedWindow, 
>>>> previousFocusedWindow -> pluginFocusedWindow, etc.
>>>> - Added manual test
>>>>
>>>> Thanks,
>>>> Dmitry
>>>>
>>>> On 04/07/2014 14:26, Alexander Scherbatiy wrote:
>>>>> On 7/3/2014 2:25 PM, Alexander Scherbatiy wrote:
>>>>>> On 7/3/2014 1:15 PM, dmitry markov wrote:
>>>>>>> Hi Alexandr,
>>>>>>>
>>>>>>> Thank you for review.
>>>>>>> For the use case you described - when we move back to the first 
>>>>>>> browser window with 3 applets, the first applet (not the second 
>>>>>>> one) will receive the focus. This behavior is incorrect, since 
>>>>>>> the second applet should receive the focus.
>>>>>>> I have updated the fix, please find new version here: 
>>>>>>> http://cr.openjdk.java.net/~dmarkov/8044614/jdk9/webrev.01/
>>>>>>> Now we store the information about focused applet when browser 
>>>>>>> window is deactivated and restore the focus to the previously 
>>>>>>> focused applet when browser window becomes active again
>>>>>>
>>>>>>     The case can be more complicated with some browsers where 
>>>>>> each of them has several applets.
>>>>>>     It seems there should be a map between a browser and it's 
>>>>>> focused applet.
>>>>>
>>>>>    I see that your fix solves these cases.
>>>>>
>>>>>    One more problem can be with the WindowsFocusEvents order.
>>>>>    Is it guarantee that order of events WindowsFocusEvent 
>>>>> (parentwindow=false) to one browser and WindowsFocusEvent 
>>>>> (parentWindow=true)
>>>>>    for other browser can't be changed?
>>>>>
>>>>>   I would suggest to  do a small refactoring.
>>>>>   Something like focusedWindow to globalFocusedWindow, 
>>>>> previousFocusedWindow to pluginFocusedWindow, add method like 
>>>>> isPluginFocused(...)
>>>>>   and use conditional operator '?' for globalFocusedWindow setting.
>>>>>
>>>>>   Thanks,
>>>>>   Alexandr.
>>>>>
>>>>>
>>>>>>
>>>>>>
>>>>>>     Is it possible to add a manual test for the fix?
>>>>>>
>>>>>>    Thanks,
>>>>>>    Alexandr.
>>>>>>
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Dmitry
>>>>>>>
>>>>>>> On 02/07/2014 16:36, Alexander Scherbatiy wrote:
>>>>>>>>
>>>>>>>>  Let's assume one browser has 3 applets where the second applet 
>>>>>>>> has focus.
>>>>>>>>  I click on the second browser with an applet (the applet 
>>>>>>>> receives the focus) and then click on the first browser back.
>>>>>>>>  Should the second applet in the first browser receive the focus?
>>>>>>>>
>>>>>>>>  Thanks,
>>>>>>>>  Alexandr.
>>>>>>>>
>>>>>>>> On 7/2/2014 2:45 PM, dmitry markov wrote:
>>>>>>>>> Hello,
>>>>>>>>>
>>>>>>>>> Could you review the fix for jdk9, please?
>>>>>>>>>
>>>>>>>>>     bug: https://bugs.openjdk.java.net/browse/JDK-8044614
>>>>>>>>>     webrev: 
>>>>>>>>> http://cr.openjdk.java.net/~dmarkov/8044614/jdk9/webrev.00/
>>>>>>>>>
>>>>>>>>> Problem description: on Mac OSX when switching between several 
>>>>>>>>> applets running in separate browser's windows, the applet in 
>>>>>>>>> active window does not receive focus.
>>>>>>>>> Fix: the method CEmbeddedFrame.handleWindowFocusEvent() should 
>>>>>>>>> be modified. It has to detect the switching between browser's 
>>>>>>>>> windows and update focusedWindow field accordingly.
>>>>>>>>>
>>>>>>>>> Thanks,
>>>>>>>>> Dmitry
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>


From petr.pchelko at oracle.com  Wed Jul 23 07:58:59 2014
From: petr.pchelko at oracle.com (Petr Pchelko)
Date: Wed, 23 Jul 2014 11:58:59 +0400
Subject: <AWT Dev> [9] Review request for 8044614: [macosx] Focus issue
	with 2 applets in firefox
In-Reply-To: <53CF646A.3090507@oracle.com>
References: <53B3E2B1.1030303@oracle.com> <53B3FCB5.103@oracle.com>
	<53B51F4C.6060106@oracle.com> <53B52FA1.7040001@oracle.com>
	<53B6813D.9070700@oracle.com> <53C66B51.30308@oracle.com>
	<53C7A301.60801@oracle.com> <53C90A7B.7070100@oracle.com>
	<53C90B9A.3050402@oracle.com> <53CF646A.3090507@oracle.com>
Message-ID: <31353659-2B23-4E0C-BBF7-535B9C2DD776@oracle.com>

Hello, Dmitry.

>>  What happens if the focused applet is closed? Does the pluginFocusedWindow  correctly updated in this case?
>>  Does the closed applet receives handleFocusEvent(false) event?
> The closing of an applet means that we closed the browser's window contained the applet or moved to another web-page. In this case we are not interesting in pluginFocusedWindow or focus events anymore, since all applets in the window are destroyed. If we go back to the applet's page, all applets will be started from scratch.
And what would happen if we press "refresh". The VM is not restarted in this case, so couldn't we have a pluginFocusedWindow in an incorrect state after that?

Also, I'm not sure about the naming. pluginFocusedWindow seems not quite self-explanatory to me. In reality it's "browserWindowFocusedApplet" isn't it? Why did you call it "plugin"? 

With best regards. Petr.

On 23 ???? 2014 ?., at 11:29, dmitry markov <dmitry.markov at oracle.com> wrote:

> Hello,
> 
> Could anyone else review the fix, please?
> 
> https://bugs.openjdk.java.net/browse/JDK-8044614
> http://cr.openjdk.java.net/~dmarkov/8044614/jdk9/webrev.02/
> 
> Thanks in advance,
> Dmitry
> 
> On 18/07/2014 15:57, Alexander Scherbatiy wrote:
>> 
>>  The fix looks good to me.
>> 
>>  Thanks,
>>  Alexandr.
>> 
>> 
>> On 7/18/2014 3:52 PM, dmitry markov wrote:
>>> Hi Alexandr,
>>> 
>>> Please find answer below.
>>> 
>>> Thanks,
>>> Dmitry
>>> On 17/07/2014 14:18, Alexander Scherbatiy wrote:
>>>> 
>>>>  The pluginFocusedWindow is only updated after switching from one browser to another (after WindowFocusEvent event).
>>>>  Should it also be updated after switching from one applet to another in the same browser (after FocusEvent)?
>>> It is not necessary, since the pluginFocusedWindow stores information about the latest focused applet in the browser's window. This information is only used for focus restoring when the window becomes active again. So I think that is enough to update pluginFocusedWindow only in handleWindowFocusEvent() when the browser's window becomes inactive.
>>> 
>>>> 
>>>>  What happens if the focused applet is closed? Does the pluginFocusedWindow  correctly updated in this case?
>>>>  Does the closed applet receives handleFocusEvent(false) event?
>>> The closing of an applet means that we closed the browser's window contained the applet or moved to another web-page. In this case we are not interesting in pluginFocusedWindow or focus events anymore, since all applets in the window are destroyed. If we go back to the applet's page, all applets will be started from scratch.
>>>> 
>>>>   Thanks,
>>>>  Alexandr.
>>>> 
>>>> 
>>>> On 7/16/2014 4:08 PM, dmitry markov wrote:
>>>>> Hi Alexandr,
>>>>> 
>>>>> I am sorry for the delay.
>>>>> When a browser's window becomes active/inactive, the browser generates WindowFocusEvent and sends it to the applets via Java Plugin. So the order of the events is defined by the browser. I tested several browsers - all of them sends WindowFocusEvent(parentWindow=false) to the active window and then WindowFocusEvent(parentWindow=true) to inactive window during switching between two browser's windows. It looks like this is common practice for such operation. However, I did not find any docs which can confirm this behavior.
>>>>> 
>>>>> Please find new version of the fix here - http://cr.openjdk.java.net/~dmarkov/8044614/jdk9/webrev.02/
>>>>> Changes:
>>>>> - Made small refactoring: focusedWindow -> globalFocusedWindow, previousFocusedWindow -> pluginFocusedWindow, etc.
>>>>> - Added manual test
>>>>> 
>>>>> Thanks,
>>>>> Dmitry
>>>>> 
>>>>> On 04/07/2014 14:26, Alexander Scherbatiy wrote:
>>>>>> On 7/3/2014 2:25 PM, Alexander Scherbatiy wrote:
>>>>>>> On 7/3/2014 1:15 PM, dmitry markov wrote:
>>>>>>>> Hi Alexandr,
>>>>>>>> 
>>>>>>>> Thank you for review.
>>>>>>>> For the use case you described - when we move back to the first browser window with 3 applets, the first applet (not the second one) will receive the focus. This behavior is incorrect, since the second applet should receive the focus.
>>>>>>>> I have updated the fix, please find new version here: http://cr.openjdk.java.net/~dmarkov/8044614/jdk9/webrev.01/
>>>>>>>> Now we store the information about focused applet when browser window is deactivated and restore the focus to the previously focused applet when browser window becomes active again
>>>>>>> 
>>>>>>>    The case can be more complicated with some browsers where each of them has several applets.
>>>>>>>    It seems there should be a map between a browser and it's focused applet.
>>>>>> 
>>>>>>   I see that your fix solves these cases.
>>>>>> 
>>>>>>   One more problem can be with the WindowsFocusEvents order.
>>>>>>   Is it guarantee that order of events WindowsFocusEvent (parentwindow=false) to one browser and WindowsFocusEvent (parentWindow=true)
>>>>>>   for other browser can't be changed?
>>>>>> 
>>>>>>  I would suggest to  do a small refactoring.
>>>>>>  Something like focusedWindow to globalFocusedWindow, previousFocusedWindow to pluginFocusedWindow, add method like isPluginFocused(...)
>>>>>>  and use conditional operator '?' for globalFocusedWindow setting.
>>>>>> 
>>>>>>  Thanks,
>>>>>>  Alexandr.
>>>>>> 
>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>>    Is it possible to add a manual test for the fix?
>>>>>>> 
>>>>>>>   Thanks,
>>>>>>>   Alexandr.
>>>>>>> 
>>>>>>>> 
>>>>>>>> Thanks,
>>>>>>>> Dmitry
>>>>>>>> 
>>>>>>>> On 02/07/2014 16:36, Alexander Scherbatiy wrote:
>>>>>>>>> 
>>>>>>>>> Let's assume one browser has 3 applets where the second applet has focus.
>>>>>>>>> I click on the second browser with an applet (the applet receives the focus) and then click on the first browser back.
>>>>>>>>> Should the second applet in the first browser receive the focus?
>>>>>>>>> 
>>>>>>>>> Thanks,
>>>>>>>>> Alexandr.
>>>>>>>>> 
>>>>>>>>> On 7/2/2014 2:45 PM, dmitry markov wrote:
>>>>>>>>>> Hello,
>>>>>>>>>> 
>>>>>>>>>> Could you review the fix for jdk9, please?
>>>>>>>>>> 
>>>>>>>>>>    bug: https://bugs.openjdk.java.net/browse/JDK-8044614
>>>>>>>>>>    webrev: http://cr.openjdk.java.net/~dmarkov/8044614/jdk9/webrev.00/
>>>>>>>>>> 
>>>>>>>>>> Problem description: on Mac OSX when switching between several applets running in separate browser's windows, the applet in active window does not receive focus.
>>>>>>>>>> Fix: the method CEmbeddedFrame.handleWindowFocusEvent() should be modified. It has to detect the switching between browser's windows and update focusedWindow field accordingly.
>>>>>>>>>> 
>>>>>>>>>> Thanks,
>>>>>>>>>> Dmitry
>>>>>>>>> 
>>>>>>>> 
>>>>>>> 
>>>>>> 
>>>>> 
>>>> 
>>> 
>> 
> 


From petr.pchelko at oracle.com  Wed Jul 23 08:25:08 2014
From: petr.pchelko at oracle.com (Petr Pchelko)
Date: Wed, 23 Jul 2014 12:25:08 +0400
Subject: <AWT Dev> [9] Review Request: 8037485 Refactor
	java.awt.datatransfer to eliminate dependency on AWT
In-Reply-To: <53CE7E68.4020709@oracle.com>
References: <AC897956-F1CC-457F-B99D-24082558C011@oracle.com>
	<53C8E5C3.6030903@oracle.com>
	<357393F5-C72C-4122-B753-C8A515116616@oracle.com>
	<53CE7E68.4020709@oracle.com>
Message-ID: <8F600339-7CBA-41D4-A7CB-2560B650CA41@oracle.com>

Hello, Alan.

Thank you for the review.
I've updated the fix according to your comments. The new version is here:
http://cr.openjdk.java.net/~pchelko/9/8037485/webrev.02/

Only the DataFlavorUtil file is updated. DesktopService now uses a lazy holder, the doc is fixed, the getFlavorTable method is fixed. 
All the rest is the same as in the previous version.

Thank you.
With best regards. Petr.

On 22 ???? 2014 ?., at 19:08, Alan Bateman <Alan.Bateman at oracle.com> wrote:

> On 22/07/2014 15:04, Petr Pchelko wrote:
>> Hello,
>> 
>> I've updated the fix. The new version is located here:
>> http://cr.openjdk.java.net/~pchelko/9/8037485/webrev.01/
>> 
>> I've reverted RMI changes as they will be handled separately. 
>> Also I've changed package names, now the internal part of the datatransfer module is called sun.datatransfer. This allowed to make less renamings and leave sun.awt.datatransfer package as is. 
>> 
>> With best regards. Petr.
>> 
> I'm skimmed over the changes (not a detailed review, best for someone working in this area to do that). It looks much better to me. We can deal with the optional dependency on RMI separately.
> 
> I've mostly focused on the ServiceLoader usage in this webrev. The only concern is that getDesktopService is "static synchronized" so that you cause contention.  You could replace this with a lazy holder idiom, or just make make desktopService volatile, it shouldn't matter if multiple threads cause desktopDatatransferService is set more than once. A suggestion for getFlavorMap is use "FlavorMap map = this.flavorMap" and check it for null to avoid doing two volatile reads.
> 
> A minor type on the declaration of flavorMap, it reads "if there is not Desktop module", I think you mean "if there is not a desktop" or "if there isn't a desktop module".
> 
> -Alan.

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

From dmitry.markov at oracle.com  Wed Jul 23 09:43:47 2014
From: dmitry.markov at oracle.com (dmitry markov)
Date: Wed, 23 Jul 2014 13:43:47 +0400
Subject: <AWT Dev> [9] Review request for 8044614: [macosx] Focus issue
 with 2 applets in firefox
In-Reply-To: <31353659-2B23-4E0C-BBF7-535B9C2DD776@oracle.com>
References: <53B3E2B1.1030303@oracle.com> <53B3FCB5.103@oracle.com>
	<53B51F4C.6060106@oracle.com> <53B52FA1.7040001@oracle.com>
	<53B6813D.9070700@oracle.com> <53C66B51.30308@oracle.com>
	<53C7A301.60801@oracle.com> <53C90A7B.7070100@oracle.com>
	<53C90B9A.3050402@oracle.com> <53CF646A.3090507@oracle.com>
	<31353659-2B23-4E0C-BBF7-535B9C2DD776@oracle.com>
Message-ID: <53CF83D3.1040306@oracle.com>

Hello Petr,

Thank you for review. Please find my answer below.

Thanks,
Dmitry
On 23/07/2014 11:58, Petr Pchelko wrote:
> Hello, Dmitry.
>
>>>   What happens if the focused applet is closed? Does the pluginFocusedWindow  correctly updated in this case?
>>>   Does the closed applet receives handleFocusEvent(false) event?
>> The closing of an applet means that we closed the browser's window contained the applet or moved to another web-page. In this case we are not interesting in pluginFocusedWindow or focus events anymore, since all applets in the window are destroyed. If we go back to the applet's page, all applets will be started from scratch.
> And what would happen if we press "refresh". The VM is not restarted in this case, so couldn't we have a pluginFocusedWindow in an incorrect state after that?
If the page is refreshed, all applets will be restarted by Java Plugin 
and the focus will be set to the firs applet on the page. We do not care 
about pluginFocusedWindow in this case.
>
> Also, I'm not sure about the naming. pluginFocusedWindow seems not quite self-explanatory to me. In reality it's "browserWindowFocusedApplet" isn't it? Why did you call it "plugin"?
You are right. I updated the field's name. Please find new version here: 
http://cr.openjdk.java.net/~dmarkov/8044614/jdk9/webrev.03/
>
> With best regards. Petr.
>
> On 23 ???? 2014 ?., at 11:29, dmitry markov <dmitry.markov at oracle.com> wrote:
>
>> Hello,
>>
>> Could anyone else review the fix, please?
>>
>> https://bugs.openjdk.java.net/browse/JDK-8044614
>> http://cr.openjdk.java.net/~dmarkov/8044614/jdk9/webrev.02/
>>
>> Thanks in advance,
>> Dmitry
>>
>> On 18/07/2014 15:57, Alexander Scherbatiy wrote:
>>>   The fix looks good to me.
>>>
>>>   Thanks,
>>>   Alexandr.
>>>
>>>
>>> On 7/18/2014 3:52 PM, dmitry markov wrote:
>>>> Hi Alexandr,
>>>>
>>>> Please find answer below.
>>>>
>>>> Thanks,
>>>> Dmitry
>>>> On 17/07/2014 14:18, Alexander Scherbatiy wrote:
>>>>>   The pluginFocusedWindow is only updated after switching from one browser to another (after WindowFocusEvent event).
>>>>>   Should it also be updated after switching from one applet to another in the same browser (after FocusEvent)?
>>>> It is not necessary, since the pluginFocusedWindow stores information about the latest focused applet in the browser's window. This information is only used for focus restoring when the window becomes active again. So I think that is enough to update pluginFocusedWindow only in handleWindowFocusEvent() when the browser's window becomes inactive.
>>>>
>>>>>   What happens if the focused applet is closed? Does the pluginFocusedWindow  correctly updated in this case?
>>>>>   Does the closed applet receives handleFocusEvent(false) event?
>>>> The closing of an applet means that we closed the browser's window contained the applet or moved to another web-page. In this case we are not interesting in pluginFocusedWindow or focus events anymore, since all applets in the window are destroyed. If we go back to the applet's page, all applets will be started from scratch.
>>>>>    Thanks,
>>>>>   Alexandr.
>>>>>
>>>>>
>>>>> On 7/16/2014 4:08 PM, dmitry markov wrote:
>>>>>> Hi Alexandr,
>>>>>>
>>>>>> I am sorry for the delay.
>>>>>> When a browser's window becomes active/inactive, the browser generates WindowFocusEvent and sends it to the applets via Java Plugin. So the order of the events is defined by the browser. I tested several browsers - all of them sends WindowFocusEvent(parentWindow=false) to the active window and then WindowFocusEvent(parentWindow=true) to inactive window during switching between two browser's windows. It looks like this is common practice for such operation. However, I did not find any docs which can confirm this behavior.
>>>>>>
>>>>>> Please find new version of the fix here - http://cr.openjdk.java.net/~dmarkov/8044614/jdk9/webrev.02/
>>>>>> Changes:
>>>>>> - Made small refactoring: focusedWindow -> globalFocusedWindow, previousFocusedWindow -> pluginFocusedWindow, etc.
>>>>>> - Added manual test
>>>>>>
>>>>>> Thanks,
>>>>>> Dmitry
>>>>>>
>>>>>> On 04/07/2014 14:26, Alexander Scherbatiy wrote:
>>>>>>> On 7/3/2014 2:25 PM, Alexander Scherbatiy wrote:
>>>>>>>> On 7/3/2014 1:15 PM, dmitry markov wrote:
>>>>>>>>> Hi Alexandr,
>>>>>>>>>
>>>>>>>>> Thank you for review.
>>>>>>>>> For the use case you described - when we move back to the first browser window with 3 applets, the first applet (not the second one) will receive the focus. This behavior is incorrect, since the second applet should receive the focus.
>>>>>>>>> I have updated the fix, please find new version here: http://cr.openjdk.java.net/~dmarkov/8044614/jdk9/webrev.01/
>>>>>>>>> Now we store the information about focused applet when browser window is deactivated and restore the focus to the previously focused applet when browser window becomes active again
>>>>>>>>     The case can be more complicated with some browsers where each of them has several applets.
>>>>>>>>     It seems there should be a map between a browser and it's focused applet.
>>>>>>>    I see that your fix solves these cases.
>>>>>>>
>>>>>>>    One more problem can be with the WindowsFocusEvents order.
>>>>>>>    Is it guarantee that order of events WindowsFocusEvent (parentwindow=false) to one browser and WindowsFocusEvent (parentWindow=true)
>>>>>>>    for other browser can't be changed?
>>>>>>>
>>>>>>>   I would suggest to  do a small refactoring.
>>>>>>>   Something like focusedWindow to globalFocusedWindow, previousFocusedWindow to pluginFocusedWindow, add method like isPluginFocused(...)
>>>>>>>   and use conditional operator '?' for globalFocusedWindow setting.
>>>>>>>
>>>>>>>   Thanks,
>>>>>>>   Alexandr.
>>>>>>>
>>>>>>>
>>>>>>>>
>>>>>>>>     Is it possible to add a manual test for the fix?
>>>>>>>>
>>>>>>>>    Thanks,
>>>>>>>>    Alexandr.
>>>>>>>>
>>>>>>>>> Thanks,
>>>>>>>>> Dmitry
>>>>>>>>>
>>>>>>>>> On 02/07/2014 16:36, Alexander Scherbatiy wrote:
>>>>>>>>>> Let's assume one browser has 3 applets where the second applet has focus.
>>>>>>>>>> I click on the second browser with an applet (the applet receives the focus) and then click on the first browser back.
>>>>>>>>>> Should the second applet in the first browser receive the focus?
>>>>>>>>>>
>>>>>>>>>> Thanks,
>>>>>>>>>> Alexandr.
>>>>>>>>>>
>>>>>>>>>> On 7/2/2014 2:45 PM, dmitry markov wrote:
>>>>>>>>>>> Hello,
>>>>>>>>>>>
>>>>>>>>>>> Could you review the fix for jdk9, please?
>>>>>>>>>>>
>>>>>>>>>>>     bug: https://bugs.openjdk.java.net/browse/JDK-8044614
>>>>>>>>>>>     webrev: http://cr.openjdk.java.net/~dmarkov/8044614/jdk9/webrev.00/
>>>>>>>>>>>
>>>>>>>>>>> Problem description: on Mac OSX when switching between several applets running in separate browser's windows, the applet in active window does not receive focus.
>>>>>>>>>>> Fix: the method CEmbeddedFrame.handleWindowFocusEvent() should be modified. It has to detect the switching between browser's windows and update focusedWindow field accordingly.
>>>>>>>>>>>
>>>>>>>>>>> Thanks,
>>>>>>>>>>> Dmitry


From Sergey.Bylokhov at oracle.com  Wed Jul 23 09:44:11 2014
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Wed, 23 Jul 2014 13:44:11 +0400
Subject: <AWT Dev> [9] Review Request: 8050852 Javadoc cleanup of
 javax.sound.midi package
In-Reply-To: <9D050722-1DF5-4A9A-BF5A-A1C847061D29@oracle.com>
References: <53C6AEC6.7050303@oracle.com>
	<9D050722-1DF5-4A9A-BF5A-A1C847061D29@oracle.com>
Message-ID: <53CF83EB.9010607@oracle.com>

Hello,
Any volunteers to be a second reviewer?

On 17.07.2014 12:18, Petr Pchelko wrote:
> Hello, Sergey.
>
> The fix looks good to me.
>
> With best regards. Petr.
>
> On 16 ???? 2014 ?., at 20:56, Sergey Bylokhov <Sergey.Bylokhov at oracle.com> wrote:
>
>> Hello.
>> Please review another one javadoc cleanup in jdk 9 in sound area:
>> - @param, @return should not end with a dot, except a case when more than one sentences are used.
>> - @param, @throws, @return now align, to be more readable.
>> - @see tags simplified in some places.
>> - Description of the class/method/field should be followed by dot.
>> - Broken links/typos fixed
>> - 80 column limit.
>> - sets of spaces in the middle of text were deleted.
>> - <tag> replaced by {@tag }.
>> - unnecessary imports were removed.
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8050852
>> See the full specdiff: http://cr.openjdk.java.net/~serb/8050852/javadoc/overview-summary.html
>> Webrev can be found at: http://cr.openjdk.java.net/~serb/8050852/webrev.02
>>
>> -- 
>> Best regards, Sergey.
>>


-- 
Best regards, Sergey.


From petr.pchelko at oracle.com  Wed Jul 23 09:49:30 2014
From: petr.pchelko at oracle.com (Petr Pchelko)
Date: Wed, 23 Jul 2014 13:49:30 +0400
Subject: <AWT Dev> [9] Review request for 8044614: [macosx] Focus issue
	with 2 applets in firefox
In-Reply-To: <53CF83D3.1040306@oracle.com>
References: <53B3E2B1.1030303@oracle.com> <53B3FCB5.103@oracle.com>
	<53B51F4C.6060106@oracle.com> <53B52FA1.7040001@oracle.com>
	<53B6813D.9070700@oracle.com> <53C66B51.30308@oracle.com>
	<53C7A301.60801@oracle.com> <53C90A7B.7070100@oracle.com>
	<53C90B9A.3050402@oracle.com> <53CF646A.3090507@oracle.com>
	<31353659-2B23-4E0C-BBF7-535B9C2DD776@oracle.com>
	<53CF83D3.1040306@oracle.com>
Message-ID: <E31499C6-6F4E-45C0-867E-413348D057B3@oracle.com>

Hello, Dmitry.

Thank you for the updates, the new version looks good to me.

With best regards. Petr.

On 23 ???? 2014 ?., at 13:43, dmitry markov <dmitry.markov at oracle.com> wrote:

> Hello Petr,
> 
> Thank you for review. Please find my answer below.
> 
> Thanks,
> Dmitry
> On 23/07/2014 11:58, Petr Pchelko wrote:
>> Hello, Dmitry.
>> 
>>>>  What happens if the focused applet is closed? Does the pluginFocusedWindow  correctly updated in this case?
>>>>  Does the closed applet receives handleFocusEvent(false) event?
>>> The closing of an applet means that we closed the browser's window contained the applet or moved to another web-page. In this case we are not interesting in pluginFocusedWindow or focus events anymore, since all applets in the window are destroyed. If we go back to the applet's page, all applets will be started from scratch.
>> And what would happen if we press "refresh". The VM is not restarted in this case, so couldn't we have a pluginFocusedWindow in an incorrect state after that?
> If the page is refreshed, all applets will be restarted by Java Plugin and the focus will be set to the firs applet on the page. We do not care about pluginFocusedWindow in this case.
>> 
>> Also, I'm not sure about the naming. pluginFocusedWindow seems not quite self-explanatory to me. In reality it's "browserWindowFocusedApplet" isn't it? Why did you call it "plugin"?
> You are right. I updated the field's name. Please find new version here: http://cr.openjdk.java.net/~dmarkov/8044614/jdk9/webrev.03/
>> 
>> With best regards. Petr.
>> 
>> On 23 ???? 2014 ?., at 11:29, dmitry markov <dmitry.markov at oracle.com> wrote:
>> 
>>> Hello,
>>> 
>>> Could anyone else review the fix, please?
>>> 
>>> https://bugs.openjdk.java.net/browse/JDK-8044614
>>> http://cr.openjdk.java.net/~dmarkov/8044614/jdk9/webrev.02/
>>> 
>>> Thanks in advance,
>>> Dmitry
>>> 
>>> On 18/07/2014 15:57, Alexander Scherbatiy wrote:
>>>>  The fix looks good to me.
>>>> 
>>>>  Thanks,
>>>>  Alexandr.
>>>> 
>>>> 
>>>> On 7/18/2014 3:52 PM, dmitry markov wrote:
>>>>> Hi Alexandr,
>>>>> 
>>>>> Please find answer below.
>>>>> 
>>>>> Thanks,
>>>>> Dmitry
>>>>> On 17/07/2014 14:18, Alexander Scherbatiy wrote:
>>>>>>  The pluginFocusedWindow is only updated after switching from one browser to another (after WindowFocusEvent event).
>>>>>>  Should it also be updated after switching from one applet to another in the same browser (after FocusEvent)?
>>>>> It is not necessary, since the pluginFocusedWindow stores information about the latest focused applet in the browser's window. This information is only used for focus restoring when the window becomes active again. So I think that is enough to update pluginFocusedWindow only in handleWindowFocusEvent() when the browser's window becomes inactive.
>>>>> 
>>>>>>  What happens if the focused applet is closed? Does the pluginFocusedWindow  correctly updated in this case?
>>>>>>  Does the closed applet receives handleFocusEvent(false) event?
>>>>> The closing of an applet means that we closed the browser's window contained the applet or moved to another web-page. In this case we are not interesting in pluginFocusedWindow or focus events anymore, since all applets in the window are destroyed. If we go back to the applet's page, all applets will be started from scratch.
>>>>>>   Thanks,
>>>>>>  Alexandr.
>>>>>> 
>>>>>> 
>>>>>> On 7/16/2014 4:08 PM, dmitry markov wrote:
>>>>>>> Hi Alexandr,
>>>>>>> 
>>>>>>> I am sorry for the delay.
>>>>>>> When a browser's window becomes active/inactive, the browser generates WindowFocusEvent and sends it to the applets via Java Plugin. So the order of the events is defined by the browser. I tested several browsers - all of them sends WindowFocusEvent(parentWindow=false) to the active window and then WindowFocusEvent(parentWindow=true) to inactive window during switching between two browser's windows. It looks like this is common practice for such operation. However, I did not find any docs which can confirm this behavior.
>>>>>>> 
>>>>>>> Please find new version of the fix here - http://cr.openjdk.java.net/~dmarkov/8044614/jdk9/webrev.02/
>>>>>>> Changes:
>>>>>>> - Made small refactoring: focusedWindow -> globalFocusedWindow, previousFocusedWindow -> pluginFocusedWindow, etc.
>>>>>>> - Added manual test
>>>>>>> 
>>>>>>> Thanks,
>>>>>>> Dmitry
>>>>>>> 
>>>>>>> On 04/07/2014 14:26, Alexander Scherbatiy wrote:
>>>>>>>> On 7/3/2014 2:25 PM, Alexander Scherbatiy wrote:
>>>>>>>>> On 7/3/2014 1:15 PM, dmitry markov wrote:
>>>>>>>>>> Hi Alexandr,
>>>>>>>>>> 
>>>>>>>>>> Thank you for review.
>>>>>>>>>> For the use case you described - when we move back to the first browser window with 3 applets, the first applet (not the second one) will receive the focus. This behavior is incorrect, since the second applet should receive the focus.
>>>>>>>>>> I have updated the fix, please find new version here: http://cr.openjdk.java.net/~dmarkov/8044614/jdk9/webrev.01/
>>>>>>>>>> Now we store the information about focused applet when browser window is deactivated and restore the focus to the previously focused applet when browser window becomes active again
>>>>>>>>>    The case can be more complicated with some browsers where each of them has several applets.
>>>>>>>>>    It seems there should be a map between a browser and it's focused applet.
>>>>>>>>   I see that your fix solves these cases.
>>>>>>>> 
>>>>>>>>   One more problem can be with the WindowsFocusEvents order.
>>>>>>>>   Is it guarantee that order of events WindowsFocusEvent (parentwindow=false) to one browser and WindowsFocusEvent (parentWindow=true)
>>>>>>>>   for other browser can't be changed?
>>>>>>>> 
>>>>>>>>  I would suggest to  do a small refactoring.
>>>>>>>>  Something like focusedWindow to globalFocusedWindow, previousFocusedWindow to pluginFocusedWindow, add method like isPluginFocused(...)
>>>>>>>>  and use conditional operator '?' for globalFocusedWindow setting.
>>>>>>>> 
>>>>>>>>  Thanks,
>>>>>>>>  Alexandr.
>>>>>>>> 
>>>>>>>> 
>>>>>>>>> 
>>>>>>>>>    Is it possible to add a manual test for the fix?
>>>>>>>>> 
>>>>>>>>>   Thanks,
>>>>>>>>>   Alexandr.
>>>>>>>>> 
>>>>>>>>>> Thanks,
>>>>>>>>>> Dmitry
>>>>>>>>>> 
>>>>>>>>>> On 02/07/2014 16:36, Alexander Scherbatiy wrote:
>>>>>>>>>>> Let's assume one browser has 3 applets where the second applet has focus.
>>>>>>>>>>> I click on the second browser with an applet (the applet receives the focus) and then click on the first browser back.
>>>>>>>>>>> Should the second applet in the first browser receive the focus?
>>>>>>>>>>> 
>>>>>>>>>>> Thanks,
>>>>>>>>>>> Alexandr.
>>>>>>>>>>> 
>>>>>>>>>>> On 7/2/2014 2:45 PM, dmitry markov wrote:
>>>>>>>>>>>> Hello,
>>>>>>>>>>>> 
>>>>>>>>>>>> Could you review the fix for jdk9, please?
>>>>>>>>>>>> 
>>>>>>>>>>>>    bug: https://bugs.openjdk.java.net/browse/JDK-8044614
>>>>>>>>>>>>    webrev: http://cr.openjdk.java.net/~dmarkov/8044614/jdk9/webrev.00/
>>>>>>>>>>>> 
>>>>>>>>>>>> Problem description: on Mac OSX when switching between several applets running in separate browser's windows, the applet in active window does not receive focus.
>>>>>>>>>>>> Fix: the method CEmbeddedFrame.handleWindowFocusEvent() should be modified. It has to detect the switching between browser's windows and update focusedWindow field accordingly.
>>>>>>>>>>>> 
>>>>>>>>>>>> Thanks,
>>>>>>>>>>>> Dmitry
> 


From alexander.zvegintsev at oracle.com  Wed Jul 23 10:47:49 2014
From: alexander.zvegintsev at oracle.com (Alexander Zvegintsev)
Date: Wed, 23 Jul 2014 14:47:49 +0400
Subject: <AWT Dev> [9] Review Request: 8050852 Javadoc cleanup of
 javax.sound.midi package
In-Reply-To: <53CF83EB.9010607@oracle.com>
References: <53C6AEC6.7050303@oracle.com>	<9D050722-1DF5-4A9A-BF5A-A1C847061D29@oracle.com>
	<53CF83EB.9010607@oracle.com>
Message-ID: <53CF92D5.5090009@oracle.com>

Hi Sergey,

here is the list where I've found trailing dots:

midi/MidiDevice.java:338
midi/SysexMessage.java:127
midi/Synthesizer.java:347
sampled/LineEvent.java:85
sampled/AudioInputStream.java:395


Otherwise the fix looks good to me.


Thanks,

Alexander.

On 07/23/2014 01:44 PM, Sergey Bylokhov wrote:
> Hello,
> Any volunteers to be a second reviewer?
>
> On 17.07.2014 12:18, Petr Pchelko wrote:
>> Hello, Sergey.
>>
>> The fix looks good to me.
>>
>> With best regards. Petr.
>>
>> On 16 ???? 2014 ?., at 20:56, Sergey Bylokhov 
>> <Sergey.Bylokhov at oracle.com> wrote:
>>
>>> Hello.
>>> Please review another one javadoc cleanup in jdk 9 in sound area:
>>> - @param, @return should not end with a dot, except a case when more 
>>> than one sentences are used.
>>> - @param, @throws, @return now align, to be more readable.
>>> - @see tags simplified in some places.
>>> - Description of the class/method/field should be followed by dot.
>>> - Broken links/typos fixed
>>> - 80 column limit.
>>> - sets of spaces in the middle of text were deleted.
>>> - <tag> replaced by {@tag }.
>>> - unnecessary imports were removed.
>>>
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8050852
>>> See the full specdiff: 
>>> http://cr.openjdk.java.net/~serb/8050852/javadoc/overview-summary.html
>>> Webrev can be found at: 
>>> http://cr.openjdk.java.net/~serb/8050852/webrev.02
>>>
>>> -- 
>>> Best regards, Sergey.
>>>
>
>


From alexandr.scherbatiy at oracle.com  Wed Jul 23 11:49:19 2014
From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy)
Date: Wed, 23 Jul 2014 15:49:19 +0400
Subject: <AWT Dev> [9] Review request for 8044614: [macosx] Focus issue
 with 2 applets in firefox
In-Reply-To: <E31499C6-6F4E-45C0-867E-413348D057B3@oracle.com>
References: <53B3E2B1.1030303@oracle.com> <53B3FCB5.103@oracle.com>
	<53B51F4C.6060106@oracle.com> <53B52FA1.7040001@oracle.com>
	<53B6813D.9070700@oracle.com> <53C66B51.30308@oracle.com>
	<53C7A301.60801@oracle.com> <53C90A7B.7070100@oracle.com>
	<53C90B9A.3050402@oracle.com> <53CF646A.3090507@oracle.com>
	<31353659-2B23-4E0C-BBF7-535B9C2DD776@oracle.com>
	<53CF83D3.1040306@oracle.com>
	<E31499C6-6F4E-45C0-867E-413348D057B3@oracle.com>
Message-ID: <53CFA13F.8050307@oracle.com>


  The fix looks good to me.

Thanks,
Alexandr.

On 7/23/2014 1:49 PM, Petr Pchelko wrote:
> Hello, Dmitry.
>
> Thank you for the updates, the new version looks good to me.
>
> With best regards. Petr.
>
> On 23 ???? 2014 ?., at 13:43, dmitry markov <dmitry.markov at oracle.com> wrote:
>
>> Hello Petr,
>>
>> Thank you for review. Please find my answer below.
>>
>> Thanks,
>> Dmitry
>> On 23/07/2014 11:58, Petr Pchelko wrote:
>>> Hello, Dmitry.
>>>
>>>>>   What happens if the focused applet is closed? Does the pluginFocusedWindow  correctly updated in this case?
>>>>>   Does the closed applet receives handleFocusEvent(false) event?
>>>> The closing of an applet means that we closed the browser's window contained the applet or moved to another web-page. In this case we are not interesting in pluginFocusedWindow or focus events anymore, since all applets in the window are destroyed. If we go back to the applet's page, all applets will be started from scratch.
>>> And what would happen if we press "refresh". The VM is not restarted in this case, so couldn't we have a pluginFocusedWindow in an incorrect state after that?
>> If the page is refreshed, all applets will be restarted by Java Plugin and the focus will be set to the firs applet on the page. We do not care about pluginFocusedWindow in this case.
>>> Also, I'm not sure about the naming. pluginFocusedWindow seems not quite self-explanatory to me. In reality it's "browserWindowFocusedApplet" isn't it? Why did you call it "plugin"?
>> You are right. I updated the field's name. Please find new version here: http://cr.openjdk.java.net/~dmarkov/8044614/jdk9/webrev.03/
>>> With best regards. Petr.
>>>
>>> On 23 ???? 2014 ?., at 11:29, dmitry markov <dmitry.markov at oracle.com> wrote:
>>>
>>>> Hello,
>>>>
>>>> Could anyone else review the fix, please?
>>>>
>>>> https://bugs.openjdk.java.net/browse/JDK-8044614
>>>> http://cr.openjdk.java.net/~dmarkov/8044614/jdk9/webrev.02/
>>>>
>>>> Thanks in advance,
>>>> Dmitry
>>>>
>>>> On 18/07/2014 15:57, Alexander Scherbatiy wrote:
>>>>>   The fix looks good to me.
>>>>>
>>>>>   Thanks,
>>>>>   Alexandr.
>>>>>
>>>>>
>>>>> On 7/18/2014 3:52 PM, dmitry markov wrote:
>>>>>> Hi Alexandr,
>>>>>>
>>>>>> Please find answer below.
>>>>>>
>>>>>> Thanks,
>>>>>> Dmitry
>>>>>> On 17/07/2014 14:18, Alexander Scherbatiy wrote:
>>>>>>>   The pluginFocusedWindow is only updated after switching from one browser to another (after WindowFocusEvent event).
>>>>>>>   Should it also be updated after switching from one applet to another in the same browser (after FocusEvent)?
>>>>>> It is not necessary, since the pluginFocusedWindow stores information about the latest focused applet in the browser's window. This information is only used for focus restoring when the window becomes active again. So I think that is enough to update pluginFocusedWindow only in handleWindowFocusEvent() when the browser's window becomes inactive.
>>>>>>
>>>>>>>   What happens if the focused applet is closed? Does the pluginFocusedWindow  correctly updated in this case?
>>>>>>>   Does the closed applet receives handleFocusEvent(false) event?
>>>>>> The closing of an applet means that we closed the browser's window contained the applet or moved to another web-page. In this case we are not interesting in pluginFocusedWindow or focus events anymore, since all applets in the window are destroyed. If we go back to the applet's page, all applets will be started from scratch.
>>>>>>>    Thanks,
>>>>>>>   Alexandr.
>>>>>>>
>>>>>>>
>>>>>>> On 7/16/2014 4:08 PM, dmitry markov wrote:
>>>>>>>> Hi Alexandr,
>>>>>>>>
>>>>>>>> I am sorry for the delay.
>>>>>>>> When a browser's window becomes active/inactive, the browser generates WindowFocusEvent and sends it to the applets via Java Plugin. So the order of the events is defined by the browser. I tested several browsers - all of them sends WindowFocusEvent(parentWindow=false) to the active window and then WindowFocusEvent(parentWindow=true) to inactive window during switching between two browser's windows. It looks like this is common practice for such operation. However, I did not find any docs which can confirm this behavior.
>>>>>>>>
>>>>>>>> Please find new version of the fix here - http://cr.openjdk.java.net/~dmarkov/8044614/jdk9/webrev.02/
>>>>>>>> Changes:
>>>>>>>> - Made small refactoring: focusedWindow -> globalFocusedWindow, previousFocusedWindow -> pluginFocusedWindow, etc.
>>>>>>>> - Added manual test
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>> Dmitry
>>>>>>>>
>>>>>>>> On 04/07/2014 14:26, Alexander Scherbatiy wrote:
>>>>>>>>> On 7/3/2014 2:25 PM, Alexander Scherbatiy wrote:
>>>>>>>>>> On 7/3/2014 1:15 PM, dmitry markov wrote:
>>>>>>>>>>> Hi Alexandr,
>>>>>>>>>>>
>>>>>>>>>>> Thank you for review.
>>>>>>>>>>> For the use case you described - when we move back to the first browser window with 3 applets, the first applet (not the second one) will receive the focus. This behavior is incorrect, since the second applet should receive the focus.
>>>>>>>>>>> I have updated the fix, please find new version here: http://cr.openjdk.java.net/~dmarkov/8044614/jdk9/webrev.01/
>>>>>>>>>>> Now we store the information about focused applet when browser window is deactivated and restore the focus to the previously focused applet when browser window becomes active again
>>>>>>>>>>     The case can be more complicated with some browsers where each of them has several applets.
>>>>>>>>>>     It seems there should be a map between a browser and it's focused applet.
>>>>>>>>>    I see that your fix solves these cases.
>>>>>>>>>
>>>>>>>>>    One more problem can be with the WindowsFocusEvents order.
>>>>>>>>>    Is it guarantee that order of events WindowsFocusEvent (parentwindow=false) to one browser and WindowsFocusEvent (parentWindow=true)
>>>>>>>>>    for other browser can't be changed?
>>>>>>>>>
>>>>>>>>>   I would suggest to  do a small refactoring.
>>>>>>>>>   Something like focusedWindow to globalFocusedWindow, previousFocusedWindow to pluginFocusedWindow, add method like isPluginFocused(...)
>>>>>>>>>   and use conditional operator '?' for globalFocusedWindow setting.
>>>>>>>>>
>>>>>>>>>   Thanks,
>>>>>>>>>   Alexandr.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>     Is it possible to add a manual test for the fix?
>>>>>>>>>>
>>>>>>>>>>    Thanks,
>>>>>>>>>>    Alexandr.
>>>>>>>>>>
>>>>>>>>>>> Thanks,
>>>>>>>>>>> Dmitry
>>>>>>>>>>>
>>>>>>>>>>> On 02/07/2014 16:36, Alexander Scherbatiy wrote:
>>>>>>>>>>>> Let's assume one browser has 3 applets where the second applet has focus.
>>>>>>>>>>>> I click on the second browser with an applet (the applet receives the focus) and then click on the first browser back.
>>>>>>>>>>>> Should the second applet in the first browser receive the focus?
>>>>>>>>>>>>
>>>>>>>>>>>> Thanks,
>>>>>>>>>>>> Alexandr.
>>>>>>>>>>>>
>>>>>>>>>>>> On 7/2/2014 2:45 PM, dmitry markov wrote:
>>>>>>>>>>>>> Hello,
>>>>>>>>>>>>>
>>>>>>>>>>>>> Could you review the fix for jdk9, please?
>>>>>>>>>>>>>
>>>>>>>>>>>>>     bug: https://bugs.openjdk.java.net/browse/JDK-8044614
>>>>>>>>>>>>>     webrev: http://cr.openjdk.java.net/~dmarkov/8044614/jdk9/webrev.00/
>>>>>>>>>>>>>
>>>>>>>>>>>>> Problem description: on Mac OSX when switching between several applets running in separate browser's windows, the applet in active window does not receive focus.
>>>>>>>>>>>>> Fix: the method CEmbeddedFrame.handleWindowFocusEvent() should be modified. It has to detect the switching between browser's windows and update focusedWindow field accordingly.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>> Dmitry


From alexandr.scherbatiy at oracle.com  Wed Jul 23 13:04:14 2014
From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy)
Date: Wed, 23 Jul 2014 17:04:14 +0400
Subject: <AWT Dev> [9] Review Request: 8051588
 DataTransferer.getInstance throws ClassCastException in headless mode
In-Reply-To: <F3E802AE-2F7E-4DCD-8B34-85479636C9AB@oracle.com>
References: <F3E802AE-2F7E-4DCD-8B34-85479636C9AB@oracle.com>
Message-ID: <53CFB2CE.6050505@oracle.com>


  The fix looks good to me.

  Thanks,
  Alexandr.

On 7/22/2014 4:20 PM, Petr Pchelko wrote:
> Hello, AWT Team.
>
> Please review the fix for the issue:
> https://bugs.openjdk.java.net/browse/JDK-8051588
> The fix is available at:
> http://cr.openjdk.java.net/~pchelko/9/8051588/webrev/
>
> JCK test fails in headless mode because of this issue.
>
> With best regards. Petr.


From petr.pchelko at oracle.com  Wed Jul 23 13:14:23 2014
From: petr.pchelko at oracle.com (Petr Pchelko)
Date: Wed, 23 Jul 2014 17:14:23 +0400
Subject: <AWT Dev> [8u] Review request: 8048549 [macosx] Disable usage
	of system menu bar if AWT is embedded in FX
In-Reply-To: <53C51BB9.2060205@oracle.com>
References: <AD884FF4-43D5-48B7-B150-A4BE1DD79830@oracle.com>
	<53C51BB9.2060205@oracle.com>
Message-ID: <B64678DC-9F96-4CFE-ACBA-42FD25E2F74E@oracle.com>

Hello, AWT Team.

This is a reminder.
Could you please review the backport.

Thank you.
With best regards. Petr.

On 15 ???? 2014 ?., at 16:16, Anthony Petrov <anthony.petrov at oracle.com> wrote:

> +1
> 
> --
> best regards,
> Anthony
> 
> On 7/15/2014 2:01 PM, Petr Pchelko wrote:
>> Hello, AWT team.
>> 
>> Please review the fix for the issue:
>> https://bugs.openjdk.java.net/browse/JDK-8048549
>> The 8u version is available here:
>> http://cr.openjdk.java.net/~pchelko/9/8048549/webrev.8u/
>> For reference, the 9 version is available here:
>> http://cr.openjdk.java.net/~pchelko/9/8048549/webrev/
>> 
>> The 8u version is different, so a new review is needed. In 9 we've moved AWT initialization from awt.m to LWCToolkit.m, so we did not need to use ThreadUtilities.
>> In 8u we need to use ThreadUtilities to figure out if AWT is running embedded or not. All the rest of the fix is the same as in 9.
>> 
>> Thank you.
>> With best regards. Petr.
>> 


From Alan.Bateman at oracle.com  Wed Jul 23 13:27:33 2014
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Wed, 23 Jul 2014 14:27:33 +0100
Subject: <AWT Dev> [9] Review Request: 8037485 Refactor
 java.awt.datatransfer to eliminate dependency on AWT
In-Reply-To: <8F600339-7CBA-41D4-A7CB-2560B650CA41@oracle.com>
References: <AC897956-F1CC-457F-B99D-24082558C011@oracle.com>
	<53C8E5C3.6030903@oracle.com>
	<357393F5-C72C-4122-B753-C8A515116616@oracle.com>
	<53CE7E68.4020709@oracle.com>
	<8F600339-7CBA-41D4-A7CB-2560B650CA41@oracle.com>
Message-ID: <53CFB845.7010305@oracle.com>

On 23/07/2014 09:25, Petr Pchelko wrote:
> Hello, Alan.
>
> Thank you for the review.
> I've updated the fix according to your comments. The new version is here:
> http://cr.openjdk.java.net/~pchelko/9/8037485/webrev.02/ 
> <http://cr.openjdk.java.net/%7Epchelko/9/8037485/webrev.02/>
>
> Only the DataFlavorUtil file is updated. DesktopService now uses a 
> lazy holder, the doc is fixed, the getFlavorTable method is fixed.
> All the rest is the same as in the previous version.
I'm skimmed over the updated webrev, it mostly looks good except for 
getFlavorMap where it doesn't set map, I assume you meant to do this:

if (map == null)
     flavorMap = map = supplier.get();

-Alan


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

From petr.pchelko at oracle.com  Wed Jul 23 13:53:53 2014
From: petr.pchelko at oracle.com (Petr Pchelko)
Date: Wed, 23 Jul 2014 17:53:53 +0400
Subject: <AWT Dev> [9] Review Request: 8037485 Refactor
	java.awt.datatransfer to eliminate dependency on AWT
In-Reply-To: <53CFB845.7010305@oracle.com>
References: <AC897956-F1CC-457F-B99D-24082558C011@oracle.com>
	<53C8E5C3.6030903@oracle.com>
	<357393F5-C72C-4122-B753-C8A515116616@oracle.com>
	<53CE7E68.4020709@oracle.com>
	<8F600339-7CBA-41D4-A7CB-2560B650CA41@oracle.com>
	<53CFB845.7010305@oracle.com>
Message-ID: <5032051C-EB18-45B4-B267-4D7BD5D315DC@oracle.com>

Hello, Alan.

> I'm skimmed over the updated webrev, it mostly looks good except for getFlavorMap where it doesn't set map, I assume you meant to do this:
> 
> if (map == null)
>     flavorMap = map = supplier.get();
Thank you! Updated the fix: http://cr.openjdk.java.net/~pchelko/9/8037485/webrev.03/

With best regards. Petr.

On 23 ???? 2014 ?., at 17:27, Alan Bateman <Alan.Bateman at oracle.com> wrote:

> On 23/07/2014 09:25, Petr Pchelko wrote:
>> Hello, Alan.
>> 
>> Thank you for the review.
>> I've updated the fix according to your comments. The new version is here:
>> http://cr.openjdk.java.net/~pchelko/9/8037485/webrev.02/
>> 
>> Only the DataFlavorUtil file is updated. DesktopService now uses a lazy holder, the doc is fixed, the getFlavorTable method is fixed. 
>> All the rest is the same as in the previous version.
> I'm skimmed over the updated webrev, it mostly looks good except for getFlavorMap where it doesn't set map, I assume you meant to do this:
> 
> if (map == null)
>     flavorMap = map = supplier.get();
> 
> -Alan
> 
> 

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

From Alan.Bateman at oracle.com  Wed Jul 23 14:14:12 2014
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Wed, 23 Jul 2014 15:14:12 +0100
Subject: <AWT Dev> [9] Review Request: 8037485 Refactor
 java.awt.datatransfer to eliminate dependency on AWT
In-Reply-To: <5032051C-EB18-45B4-B267-4D7BD5D315DC@oracle.com>
References: <AC897956-F1CC-457F-B99D-24082558C011@oracle.com>
	<53C8E5C3.6030903@oracle.com>
	<357393F5-C72C-4122-B753-C8A515116616@oracle.com>
	<53CE7E68.4020709@oracle.com>
	<8F600339-7CBA-41D4-A7CB-2560B650CA41@oracle.com>
	<53CFB845.7010305@oracle.com>
	<5032051C-EB18-45B4-B267-4D7BD5D315DC@oracle.com>
Message-ID: <53CFC334.8080107@oracle.com>

On 23/07/2014 14:53, Petr Pchelko wrote:
> Hello, Alan.
>
>> I'm skimmed over the updated webrev, it mostly looks good except for 
>> getFlavorMap where it doesn't set map, I assume you meant to do this:
>>
>> if (map == null)
>>     flavorMap = map = supplier.get();
> Thank you! Updated the fix: 
> http://cr.openjdk.java.net/~pchelko/9/8037485/webrev.03 
> <http://cr.openjdk.java.net/%7Epchelko/9/8037485/webrev.03/>
This part looks good to me now.

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

From artem.malinko at oracle.com  Wed Jul 23 14:55:51 2014
From: artem.malinko at oracle.com (artem malinko)
Date: Wed, 23 Jul 2014 18:55:51 +0400
Subject: <AWT Dev> Review request for 8047288: [macosx] Endless loop in
 EDT on Mac
In-Reply-To: <D741BDAC-3A69-46D1-A565-53360414E406@oracle.com>
References: <53CE8B71.8020807@oracle.com>
	<D741BDAC-3A69-46D1-A565-53360414E406@oracle.com>
Message-ID: <53CFCCF7.70500@oracle.com>

Hi, Petr. I ran focus regression tests and jck tests on awt. For fixed 
jdk results is the same. Except my new test, of course which is not 
passed on not fixed jdk:) And also I fixed issues in test. New webrev:
http://cr.openjdk.java.net/~bae/8047288/9/webrev.00/

On 7/22/2014 8:23 PM, Petr Pchelko wrote:
> Hello, Artem.
>
> A couple of comments:
> 1. LWWindowPeer: 268 - please remove an empty line.
> 2. LWWIndowPeer. isTargetFocusable - the method is not needed at all.
> 3. I?m concerned about the test. Do you really need the close button?
> 4. frame and window variables are set from main thread and read from 
> EDT. They should be declared volatile.
>
> Also please run all focus regression and JCK tests, because this area 
> is very sensitive.
>
> With best regards. Petr.
>
>> On Jul 22, 2014, at 8:04 PM, artem malinko <artem.malinko at oracle.com 
>> <mailto:artem.malinko at oracle.com>> wrote:
>>
>> Hello, AWT Team.
>>
>> Please review a fix for the issue:
>> https://bugs.openjdk.java.net/browse/JDK-8047288
>> The fix is available at:
>> http://cr.openjdk.java.net/~mcherkas/artem/8047288/webrev.01/ 
>> <http://cr.openjdk.java.net/%7Emcherkas/artem/8047288/webrev.01/>
>>
>> Window.isFocusableWindow() could lead to deadlock if it is invoked on 
>> AppKit thread. Fix caches result of Window.isFocusableWindow() on a 
>> peer level and method is not invoked on AppkitThread.
>>
>> Thank you.
>

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

From mandy.chung at oracle.com  Wed Jul 23 15:04:09 2014
From: mandy.chung at oracle.com (Mandy Chung)
Date: Wed, 23 Jul 2014 08:04:09 -0700
Subject: <AWT Dev> [9] Review Request: 8037485 Refactor
 java.awt.datatransfer to eliminate dependency on AWT
In-Reply-To: <5032051C-EB18-45B4-B267-4D7BD5D315DC@oracle.com>
References: <AC897956-F1CC-457F-B99D-24082558C011@oracle.com>
	<53C8E5C3.6030903@oracle.com>
	<357393F5-C72C-4122-B753-C8A515116616@oracle.com>
	<53CE7E68.4020709@oracle.com>
	<8F600339-7CBA-41D4-A7CB-2560B650CA41@oracle.com>
	<53CFB845.7010305@oracle.com>
	<5032051C-EB18-45B4-B267-4D7BD5D315DC@oracle.com>
Message-ID: <53CFCEE9.6030001@oracle.com>


On 7/23/2014 6:53 AM, Petr Pchelko wrote:
> Hello, Alan.
>
>> I'm skimmed over the updated webrev, it mostly looks good except for 
>> getFlavorMap where it doesn't set map, I assume you meant to do this:
>>
>> if (map == null)
>>     flavorMap = map = supplier.get();
> Thank you! Updated the fix: 
> http://cr.openjdk.java.net/~pchelko/9/8037485/webrev.03/ 
> <http://cr.openjdk.java.net/%7Epchelko/9/8037485/webrev.03/>
>
>

I skimmed through the webrev and looks good.  It looks like that you 
have cleanly removed the dependency.  You can run jdk9/bin/jdeps [1] on 
the java.awt.datatransfer.** and its implementation classes to double 
check if there is no dependency to the desktop classes.

Minor comments I spotted:

java/awt/datatransfer/SystemFlavorMap.java

line 225 and 238 look like debugging statement to be removed.

DataFlavorUtil.java
    line 544, 549 - some raw types and you may want to check if there are others.

[1] http://docs.oracle.com/javase/8/docs/technotes/tools/unix/jdeps.html

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

From petr.pchelko at oracle.com  Wed Jul 23 18:30:10 2014
From: petr.pchelko at oracle.com (Petr Pchelko)
Date: Wed, 23 Jul 2014 22:30:10 +0400
Subject: <AWT Dev> Review request for 8047288: [macosx] Endless loop in
	EDT on Mac
In-Reply-To: <53CFCCF7.70500@oracle.com>
References: <53CE8B71.8020807@oracle.com>
	<D741BDAC-3A69-46D1-A565-53360414E406@oracle.com>
	<53CFCCF7.70500@oracle.com>
Message-ID: <28B1A970-DBDE-4C63-A519-04A791C22EF7@oracle.com>

Hello, Artem.

The new version (it?s .00 for some reason) looks good.

With best regards. Petr.

> On Jul 23, 2014, at 6:55 PM, artem malinko <artem.malinko at oracle.com> wrote:
> 
> Hi, Petr. I ran focus regression tests and jck tests on awt. For fixed jdk results is the same. Except my new test, of course which is not passed on not fixed jdk:) And also I fixed issues in test. New webrev:
> http://cr.openjdk.java.net/~bae/8047288/9/webrev.00/
> 
> On 7/22/2014 8:23 PM, Petr Pchelko wrote:
>> Hello, Artem.
>> 
>> A couple of comments:
>> 1. LWWindowPeer: 268 - please remove an empty line.
>> 2. LWWIndowPeer. isTargetFocusable - the method is not needed at all. 
>> 3. I?m concerned about the test. Do you really need the close button? 
>> 4. frame and window variables are set from main thread and read from EDT. They should be declared volatile.
>> 
>> Also please run all focus regression and JCK tests, because this area is very sensitive.
>> 
>> With best regards. Petr.
>> 
>>> On Jul 22, 2014, at 8:04 PM, artem malinko <artem.malinko at oracle.com> wrote:
>>> 
>>> Hello, AWT Team. 
>>> 
>>> Please review a fix for the issue: 
>>> https://bugs.openjdk.java.net/browse/JDK-8047288
>>> The fix is available at: 
>>> http://cr.openjdk.java.net/~mcherkas/artem/8047288/webrev.01/
>>> 
>>> Window.isFocusableWindow() could lead to deadlock if it is invoked on AppKit thread. Fix caches result of Window.isFocusableWindow() on a peer level and method is not invoked on AppkitThread.
>>> 
>>> Thank you.
>> 
> 

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

From philip.race at oracle.com  Wed Jul 23 19:27:57 2014
From: philip.race at oracle.com (Phil Race)
Date: Wed, 23 Jul 2014 12:27:57 -0700
Subject: <AWT Dev> [9] Review Request: 8050852 Javadoc cleanup of
 javax.sound.midi package
In-Reply-To: <53CF83EB.9010607@oracle.com>
References: <53C6AEC6.7050303@oracle.com>	<9D050722-1DF5-4A9A-BF5A-A1C847061D29@oracle.com>
	<53CF83EB.9010607@oracle.com>
Message-ID: <53D00CBD.90603@oracle.com>

I had started on this but there was a lot to wade through

Here 
http://cr.openjdk.java.net/~serb/8050852/webrev.02/src/share/classes/javax/sound/midi/MidiDevice.java.sdiff.html

you changed 'public static class Info' -> 'class Info'

This made me think. I presume the point is that a class nested within an 
interface
is implicitly static even if not declared so, so you removed it.
However I have no idea  if JCK signature tests will need to be updated.
I suggest you inquire.

You may want to correct the (pre-existing) spelling mistake
here before you push :-
http://cr.openjdk.java.net/~serb/8050852/webrev.02/src/share/classes/javax/sound/midi/MidiDevice.java.sdiff.html

48  * {@code MidiSystem.getTransmitter} is implementation-dependant unless the

dependant->dependent


Changes (like) this one surprised me too :-

http://cr.openjdk.java.net/~serb/8050852/webrev.02/src/share/classes/javax/sound/sampled/spi/AudioFileWriter.java.sdiff.html

So we add an import statement just to keep some javadoc tool happy ?
Was this from doclint ? Did you question whether that was really something
doclint should enforce rather than just allowing the fully qualified name ?

It wouldn't surprise me if some other tool were to consider this an 
un-used import
and delete it.

-phil

On 7/23/14 2:44 AM, Sergey Bylokhov wrote:
> Hello,
> Any volunteers to be a second reviewer?
>
> On 17.07.2014 12:18, Petr Pchelko wrote:
>> Hello, Sergey.
>>
>> The fix looks good to me.
>>
>> With best regards. Petr.
>>
>> On 16 ???? 2014 ?., at 20:56, Sergey Bylokhov 
>> <Sergey.Bylokhov at oracle.com> wrote:
>>
>>> Hello.
>>> Please review another one javadoc cleanup in jdk 9 in sound area:
>>> - @param, @return should not end with a dot, except a case when more 
>>> than one sentences are used.
>>> - @param, @throws, @return now align, to be more readable.
>>> - @see tags simplified in some places.
>>> - Description of the class/method/field should be followed by dot.
>>> - Broken links/typos fixed
>>> - 80 column limit.
>>> - sets of spaces in the middle of text were deleted.
>>> - <tag> replaced by {@tag }.
>>> - unnecessary imports were removed.
>>>
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8050852
>>> See the full specdiff: 
>>> http://cr.openjdk.java.net/~serb/8050852/javadoc/overview-summary.html
>>> Webrev can be found at: 
>>> http://cr.openjdk.java.net/~serb/8050852/webrev.02
>>>
>>> -- 
>>> Best regards, Sergey.
>>>
>
>

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

From Sergey.Bylokhov at oracle.com  Wed Jul 23 19:45:51 2014
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Wed, 23 Jul 2014 23:45:51 +0400
Subject: <AWT Dev> [9] Review Request: 8050852 Javadoc cleanup of
 javax.sound.midi package
In-Reply-To: <53D00CBD.90603@oracle.com>
References: <53C6AEC6.7050303@oracle.com>	<9D050722-1DF5-4A9A-BF5A-A1C847061D29@oracle.com>
	<53CF83EB.9010607@oracle.com> <53D00CBD.90603@oracle.com>
Message-ID: <53D010EF.4020100@oracle.com>

On 23.07.2014 23:27, Phil Race wrote:
> I had started on this but there was a lot to wade through
>
> Here 
> http://cr.openjdk.java.net/~serb/8050852/webrev.02/src/share/classes/javax/sound/midi/MidiDevice.java.sdiff.html
>
> you changed 'public static class Info' -> 'class Info'
>
> This made me think. I presume the point is that a class nested within 
> an interface
> is implicitly static even if not declared so, so you removed it.
Right.
> However I have no idea  if JCK signature tests will need to be updated.
> I suggest you inquire.
At least class file is not changed.
>
> You may want to correct the (pre-existing) spelling mistake
> here before you push :-
> http://cr.openjdk.java.net/~serb/8050852/webrev.02/src/share/classes/javax/sound/midi/MidiDevice.java.sdiff.html
> 48  * {@code MidiSystem.getTransmitter} is implementation-dependant unless the
>
> dependant->dependent
>
> Changes (like) this one surprised me too :-
>
> http://cr.openjdk.java.net/~serb/8050852/webrev.02/src/share/classes/javax/sound/sampled/spi/AudioFileWriter.java.sdiff.html
>
> So we add an import statement just to keep some javadoc tool happy ?
No, it just to make a reader of this javadoc happy.
> Was this from doclint ? Did you question whether that was really something
> doclint should enforce rather than just allowing the fully qualified 
> name ?
>
> It wouldn't surprise me if some other tool were to consider this an 
> un-used import
> and delete it.
We had a bunch of unused imports in the past in these files, and now all 
of them are removed/used.  I guess, if some tool recognize this as 
unused import, it will be a bad tool.
>
> -phil
>
> On 7/23/14 2:44 AM, Sergey Bylokhov wrote:
>> Hello,
>> Any volunteers to be a second reviewer?
>>
>> On 17.07.2014 12:18, Petr Pchelko wrote:
>>> Hello, Sergey.
>>>
>>> The fix looks good to me.
>>>
>>> With best regards. Petr.
>>>
>>> On 16 ???? 2014 ?., at 20:56, Sergey Bylokhov 
>>> <Sergey.Bylokhov at oracle.com> wrote:
>>>
>>>> Hello.
>>>> Please review another one javadoc cleanup in jdk 9 in sound area:
>>>> - @param, @return should not end with a dot, except a case when 
>>>> more than one sentences are used.
>>>> - @param, @throws, @return now align, to be more readable.
>>>> - @see tags simplified in some places.
>>>> - Description of the class/method/field should be followed by dot.
>>>> - Broken links/typos fixed
>>>> - 80 column limit.
>>>> - sets of spaces in the middle of text were deleted.
>>>> - <tag> replaced by {@tag }.
>>>> - unnecessary imports were removed.
>>>>
>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8050852
>>>> See the full specdiff: 
>>>> http://cr.openjdk.java.net/~serb/8050852/javadoc/overview-summary.html
>>>> Webrev can be found at: 
>>>> http://cr.openjdk.java.net/~serb/8050852/webrev.02
>>>>
>>>> -- 
>>>> Best regards, Sergey.
>>>>
>>
>>
>


-- 
Best regards, Sergey.

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

From philip.race at oracle.com  Wed Jul 23 20:12:46 2014
From: philip.race at oracle.com (Phil Race)
Date: Wed, 23 Jul 2014 13:12:46 -0700
Subject: <AWT Dev> [9] Review Request: 8050852 Javadoc cleanup of
 javax.sound.midi package
In-Reply-To: <53D010EF.4020100@oracle.com>
References: <53C6AEC6.7050303@oracle.com>	<9D050722-1DF5-4A9A-BF5A-A1C847061D29@oracle.com>
	<53CF83EB.9010607@oracle.com> <53D00CBD.90603@oracle.com>
	<53D010EF.4020100@oracle.com>
Message-ID: <53D0173E.2060801@oracle.com>

OK. Approved

-phil.

On 07/23/2014 12:45 PM, Sergey Bylokhov wrote:
> On 23.07.2014 23:27, Phil Race wrote:
>> I had started on this but there was a lot to wade through
>>
>> Here 
>> http://cr.openjdk.java.net/~serb/8050852/webrev.02/src/share/classes/javax/sound/midi/MidiDevice.java.sdiff.html
>>
>> you changed 'public static class Info' -> 'class Info'
>>
>> This made me think. I presume the point is that a class nested within 
>> an interface
>> is implicitly static even if not declared so, so you removed it.
> Right.
>> However I have no idea  if JCK signature tests will need to be updated.
>> I suggest you inquire.
> At least class file is not changed.
>>
>> You may want to correct the (pre-existing) spelling mistake
>> here before you push :-
>> http://cr.openjdk.java.net/~serb/8050852/webrev.02/src/share/classes/javax/sound/midi/MidiDevice.java.sdiff.html
>> 48  * {@code MidiSystem.getTransmitter} is implementation-dependant unless the
>>
>> dependant->dependent
>>
>> Changes (like) this one surprised me too :-
>>
>> http://cr.openjdk.java.net/~serb/8050852/webrev.02/src/share/classes/javax/sound/sampled/spi/AudioFileWriter.java.sdiff.html
>>
>> So we add an import statement just to keep some javadoc tool happy ?
> No, it just to make a reader of this javadoc happy.
>> Was this from doclint ? Did you question whether that was really 
>> something
>> doclint should enforce rather than just allowing the fully qualified 
>> name ?
>>
>> It wouldn't surprise me if some other tool were to consider this an 
>> un-used import
>> and delete it.
> We had a bunch of unused imports in the past in these files, and now 
> all of them are removed/used.  I guess, if some tool recognize this as 
> unused import, it will be a bad tool.
>>
>> -phil
>>
>> On 7/23/14 2:44 AM, Sergey Bylokhov wrote:
>>> Hello,
>>> Any volunteers to be a second reviewer?
>>>
>>> On 17.07.2014 12:18, Petr Pchelko wrote:
>>>> Hello, Sergey.
>>>>
>>>> The fix looks good to me.
>>>>
>>>> With best regards. Petr.
>>>>
>>>> On 16 ???? 2014 ?., at 20:56, Sergey Bylokhov 
>>>> <Sergey.Bylokhov at oracle.com> wrote:
>>>>
>>>>> Hello.
>>>>> Please review another one javadoc cleanup in jdk 9 in sound area:
>>>>> - @param, @return should not end with a dot, except a case when 
>>>>> more than one sentences are used.
>>>>> - @param, @throws, @return now align, to be more readable.
>>>>> - @see tags simplified in some places.
>>>>> - Description of the class/method/field should be followed by dot.
>>>>> - Broken links/typos fixed
>>>>> - 80 column limit.
>>>>> - sets of spaces in the middle of text were deleted.
>>>>> - <tag> replaced by {@tag }.
>>>>> - unnecessary imports were removed.
>>>>>
>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8050852
>>>>> See the full specdiff: 
>>>>> http://cr.openjdk.java.net/~serb/8050852/javadoc/overview-summary.html 
>>>>>
>>>>> Webrev can be found at: 
>>>>> http://cr.openjdk.java.net/~serb/8050852/webrev.02
>>>>>
>>>>> -- 
>>>>> Best regards, Sergey.
>>>>>
>>>
>>>
>>
>
>
> -- 
> Best regards, Sergey.

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

From artem.malinko at oracle.com  Thu Jul 24 06:25:00 2014
From: artem.malinko at oracle.com (artem malinko)
Date: Thu, 24 Jul 2014 10:25:00 +0400
Subject: <AWT Dev> Review request for 8047288: [macosx] Endless loop in
 EDT on Mac
In-Reply-To: <28B1A970-DBDE-4C63-A519-04A791C22EF7@oracle.com>
References: <53CE8B71.8020807@oracle.com>
	<D741BDAC-3A69-46D1-A565-53360414E406@oracle.com>
	<53CFCCF7.70500@oracle.com>
	<28B1A970-DBDE-4C63-A519-04A791C22EF7@oracle.com>
Message-ID: <53D0A6BC.1060902@oracle.com>

Thank you, Petr.

Could anyone else review the fix, please?

On 7/23/2014 10:30 PM, Petr Pchelko wrote:
> Hello, Artem.
>
> The new version (it?s .00 for some reason) looks good.
>
> With best regards. Petr.
>
>> On Jul 23, 2014, at 6:55 PM, artem malinko <artem.malinko at oracle.com 
>> <mailto:artem.malinko at oracle.com>> wrote:
>>
>> Hi, Petr. I ran focus regression tests and jck tests on awt. For 
>> fixed jdk results is the same. Except my new test, of course which is 
>> not passed on not fixed jdk:) And also I fixed issues in test. New 
>> webrev:
>> http://cr.openjdk.java.net/~bae/8047288/9/webrev.00/
>>
>> On 7/22/2014 8:23 PM, Petr Pchelko wrote:
>>> Hello, Artem.
>>>
>>> A couple of comments:
>>> 1. LWWindowPeer: 268 - please remove an empty line.
>>> 2. LWWIndowPeer. isTargetFocusable - the method is not needed at all.
>>> 3. I?m concerned about the test. Do you really need the close button?
>>> 4. frame and window variables are set from main thread and read from 
>>> EDT. They should be declared volatile.
>>>
>>> Also please run all focus regression and JCK tests, because this 
>>> area is very sensitive.
>>>
>>> With best regards. Petr.
>>>
>>>> On Jul 22, 2014, at 8:04 PM, artem malinko 
>>>> <artem.malinko at oracle.com <mailto:artem.malinko at oracle.com>> wrote:
>>>>
>>>> Hello, AWT Team.
>>>>
>>>> Please review a fix for the issue:
>>>> https://bugs.openjdk.java.net/browse/JDK-8047288
>>>> The fix is available at:
>>>> http://cr.openjdk.java.net/~mcherkas/artem/8047288/webrev.01/ 
>>>> <http://cr.openjdk.java.net/%7Emcherkas/artem/8047288/webrev.01/>
>>>>
>>>> Window.isFocusableWindow() could lead to deadlock if it is invoked 
>>>> on AppKit thread. Fix caches result of Window.isFocusableWindow() 
>>>> on a peer level and method is not invoked on AppkitThread.
>>>>
>>>> Thank you.
>>>
>>
>

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

From anton.tarasov at oracle.com  Thu Jul 24 07:42:53 2014
From: anton.tarasov at oracle.com (Anton V. Tarasov)
Date: Thu, 24 Jul 2014 11:42:53 +0400
Subject: <AWT Dev> Review request for 8047288: [macosx] Endless loop in
 EDT on Mac
In-Reply-To: <53D0A6BC.1060902@oracle.com>
References: <53CE8B71.8020807@oracle.com>
	<D741BDAC-3A69-46D1-A565-53360414E406@oracle.com>
	<53CFCCF7.70500@oracle.com>
	<28B1A970-DBDE-4C63-A519-04A791C22EF7@oracle.com>
	<53D0A6BC.1060902@oracle.com>
Message-ID: <53D0B8FD.7070806@oracle.com>

Hi Artem,

I'm Ok with the fix, provided that LWWindowPeer.setVisibleImpl() is called on EDT for applets (if 
I'm not mistaken). Otherwise, we still have a client method (getTarget().isFocusableWindow()) called 
on the toolkit thread, which is generally no good.

Regards,
Anton.

On 24.07.2014 10:25, artem malinko wrote:
> Thank you, Petr.
>
> Could anyone else review the fix, please?
>
> On 7/23/2014 10:30 PM, Petr Pchelko wrote:
>> Hello, Artem.
>>
>> The new version (it?s .00 for some reason) looks good.
>>
>> With best regards. Petr.
>>
>>> On Jul 23, 2014, at 6:55 PM, artem malinko <artem.malinko at oracle.com 
>>> <mailto:artem.malinko at oracle.com>> wrote:
>>>
>>> Hi, Petr. I ran focus regression tests and jck tests on awt. For fixed jdk results is the same. 
>>> Except my new test, of course which is not passed on not fixed jdk:) And also I fixed issues in 
>>> test. New webrev:
>>> http://cr.openjdk.java.net/~bae/8047288/9/webrev.00/
>>>
>>> On 7/22/2014 8:23 PM, Petr Pchelko wrote:
>>>> Hello, Artem.
>>>>
>>>> A couple of comments:
>>>> 1. LWWindowPeer: 268 - please remove an empty line.
>>>> 2. LWWIndowPeer. isTargetFocusable - the method is not needed at all.
>>>> 3. I?m concerned about the test. Do you really need the close button?
>>>> 4. frame and window variables are set from main thread and read from EDT. They should be 
>>>> declared volatile.
>>>>
>>>> Also please run all focus regression and JCK tests, because this area is very sensitive.
>>>>
>>>> With best regards. Petr.
>>>>
>>>>> On Jul 22, 2014, at 8:04 PM, artem malinko <artem.malinko at oracle.com 
>>>>> <mailto:artem.malinko at oracle.com>> wrote:
>>>>>
>>>>> Hello, AWT Team.
>>>>>
>>>>> Please review a fix for the issue:
>>>>> https://bugs.openjdk.java.net/browse/JDK-8047288
>>>>> The fix is available at:
>>>>> http://cr.openjdk.java.net/~mcherkas/artem/8047288/webrev.01/ 
>>>>> <http://cr.openjdk.java.net/%7Emcherkas/artem/8047288/webrev.01/>
>>>>>
>>>>> Window.isFocusableWindow() could lead to deadlock if it is invoked on AppKit thread. Fix 
>>>>> caches result of Window.isFocusableWindow() on a peer level and method is not invoked on 
>>>>> AppkitThread.
>>>>>
>>>>> Thank you.
>>>>
>>>
>>
>

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

From artem.malinko at oracle.com  Thu Jul 24 09:48:55 2014
From: artem.malinko at oracle.com (artem malinko)
Date: Thu, 24 Jul 2014 13:48:55 +0400
Subject: <AWT Dev> Review request for 8047288: [macosx] Endless loop in
 EDT on Mac
In-Reply-To: <53D0B8FD.7070806@oracle.com>
References: <53CE8B71.8020807@oracle.com>
	<D741BDAC-3A69-46D1-A565-53360414E406@oracle.com>
	<53CFCCF7.70500@oracle.com>
	<28B1A970-DBDE-4C63-A519-04A791C22EF7@oracle.com>
	<53D0A6BC.1060902@oracle.com> <53D0B8FD.7070806@oracle.com>
Message-ID: <53D0D687.7000607@oracle.com>

Hi Anton.

Sorry, didn't understand you well. Do you mean we should check(and test) 
that this method(isFocusableWindow()) is also called on EDT if we run 
applet?

On 7/24/2014 11:42 AM, Anton V. Tarasov wrote:
> Hi Artem,
>
> I'm Ok with the fix, provided that LWWindowPeer.setVisibleImpl() is 
> called on EDT for applets (if I'm not mistaken). Otherwise, we still 
> have a client method (getTarget().isFocusableWindow()) called on the 
> toolkit thread, which is generally no good.
>
> Regards,
> Anton.
>
> On 24.07.2014 10:25, artem malinko wrote:
>> Thank you, Petr.
>>
>> Could anyone else review the fix, please?
>>
>> On 7/23/2014 10:30 PM, Petr Pchelko wrote:
>>> Hello, Artem.
>>>
>>> The new version (it?s .00 for some reason) looks good.
>>>
>>> With best regards. Petr.
>>>
>>>> On Jul 23, 2014, at 6:55 PM, artem malinko 
>>>> <artem.malinko at oracle.com <mailto:artem.malinko at oracle.com>> wrote:
>>>>
>>>> Hi, Petr. I ran focus regression tests and jck tests on awt. For 
>>>> fixed jdk results is the same. Except my new test, of course which 
>>>> is not passed on not fixed jdk:) And also I fixed issues in test. 
>>>> New webrev:
>>>> http://cr.openjdk.java.net/~bae/8047288/9/webrev.00/
>>>>
>>>> On 7/22/2014 8:23 PM, Petr Pchelko wrote:
>>>>> Hello, Artem.
>>>>>
>>>>> A couple of comments:
>>>>> 1. LWWindowPeer: 268 - please remove an empty line.
>>>>> 2. LWWIndowPeer. isTargetFocusable - the method is not needed at all.
>>>>> 3. I?m concerned about the test. Do you really need the close button?
>>>>> 4. frame and window variables are set from main thread and read 
>>>>> from EDT. They should be declared volatile.
>>>>>
>>>>> Also please run all focus regression and JCK tests, because this 
>>>>> area is very sensitive.
>>>>>
>>>>> With best regards. Petr.
>>>>>
>>>>>> On Jul 22, 2014, at 8:04 PM, artem malinko 
>>>>>> <artem.malinko at oracle.com <mailto:artem.malinko at oracle.com>> wrote:
>>>>>>
>>>>>> Hello, AWT Team.
>>>>>>
>>>>>> Please review a fix for the issue:
>>>>>> https://bugs.openjdk.java.net/browse/JDK-8047288
>>>>>> The fix is available at:
>>>>>> http://cr.openjdk.java.net/~mcherkas/artem/8047288/webrev.01/ 
>>>>>> <http://cr.openjdk.java.net/%7Emcherkas/artem/8047288/webrev.01/>
>>>>>>
>>>>>> Window.isFocusableWindow() could lead to deadlock if it is 
>>>>>> invoked on AppKit thread. Fix caches result of 
>>>>>> Window.isFocusableWindow() on a peer level and method is not 
>>>>>> invoked on AppkitThread.
>>>>>>
>>>>>> Thank you.
>>>>>
>>>>
>>>
>>
>

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

From anton.tarasov at oracle.com  Thu Jul 24 10:02:35 2014
From: anton.tarasov at oracle.com (Anton V. Tarasov)
Date: Thu, 24 Jul 2014 14:02:35 +0400
Subject: <AWT Dev> Review request for 8047288: [macosx] Endless loop in
 EDT on Mac
In-Reply-To: <53D0D687.7000607@oracle.com>
References: <53CE8B71.8020807@oracle.com>
	<D741BDAC-3A69-46D1-A565-53360414E406@oracle.com>
	<53CFCCF7.70500@oracle.com>
	<28B1A970-DBDE-4C63-A519-04A791C22EF7@oracle.com>
	<53D0A6BC.1060902@oracle.com> <53D0B8FD.7070806@oracle.com>
	<53D0D687.7000607@oracle.com>
Message-ID: <53D0D9BB.6000803@oracle.com>

On 24.07.2014 13:48, artem malinko wrote:
> Hi Anton.
>
> Sorry, didn't understand you well. Do you mean we should check(and test) that this 
> method(isFocusableWindow()) is also called on EDT if we run applet?

IMHO, it's enough to just make sure (via inspecting the sources) that Window.setVisible() is called 
on EDT in case of an applet. That logic is triggered on the plugin side.

Anton.

>
> On 7/24/2014 11:42 AM, Anton V. Tarasov wrote:
>> Hi Artem,
>>
>> I'm Ok with the fix, provided that LWWindowPeer.setVisibleImpl() is called on EDT for applets (if 
>> I'm not mistaken). Otherwise, we still have a client method (getTarget().isFocusableWindow()) 
>> called on the toolkit thread, which is generally no good.
>>
>> Regards,
>> Anton.
>>
>> On 24.07.2014 10:25, artem malinko wrote:
>>> Thank you, Petr.
>>>
>>> Could anyone else review the fix, please?
>>>
>>> On 7/23/2014 10:30 PM, Petr Pchelko wrote:
>>>> Hello, Artem.
>>>>
>>>> The new version (it?s .00 for some reason) looks good.
>>>>
>>>> With best regards. Petr.
>>>>
>>>>> On Jul 23, 2014, at 6:55 PM, artem malinko <artem.malinko at oracle.com 
>>>>> <mailto:artem.malinko at oracle.com>> wrote:
>>>>>
>>>>> Hi, Petr. I ran focus regression tests and jck tests on awt. For fixed jdk results is the 
>>>>> same. Except my new test, of course which is not passed on not fixed jdk:) And also I fixed 
>>>>> issues in test. New webrev:
>>>>> http://cr.openjdk.java.net/~bae/8047288/9/webrev.00/
>>>>>
>>>>> On 7/22/2014 8:23 PM, Petr Pchelko wrote:
>>>>>> Hello, Artem.
>>>>>>
>>>>>> A couple of comments:
>>>>>> 1. LWWindowPeer: 268 - please remove an empty line.
>>>>>> 2. LWWIndowPeer. isTargetFocusable - the method is not needed at all.
>>>>>> 3. I?m concerned about the test. Do you really need the close button?
>>>>>> 4. frame and window variables are set from main thread and read from EDT. They should be 
>>>>>> declared volatile.
>>>>>>
>>>>>> Also please run all focus regression and JCK tests, because this area is very sensitive.
>>>>>>
>>>>>> With best regards. Petr.
>>>>>>
>>>>>>> On Jul 22, 2014, at 8:04 PM, artem malinko <artem.malinko at oracle.com 
>>>>>>> <mailto:artem.malinko at oracle.com>> wrote:
>>>>>>>
>>>>>>> Hello, AWT Team.
>>>>>>>
>>>>>>> Please review a fix for the issue:
>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8047288
>>>>>>> The fix is available at:
>>>>>>> http://cr.openjdk.java.net/~mcherkas/artem/8047288/webrev.01/ 
>>>>>>> <http://cr.openjdk.java.net/%7Emcherkas/artem/8047288/webrev.01/>
>>>>>>>
>>>>>>> Window.isFocusableWindow() could lead to deadlock if it is invoked on AppKit thread. Fix 
>>>>>>> caches result of Window.isFocusableWindow() on a peer level and method is not invoked on 
>>>>>>> AppkitThread.
>>>>>>>
>>>>>>> Thank you.
>>>>>>
>>>>>
>>>>
>>>
>>
>

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

From petr.pchelko at oracle.com  Thu Jul 24 11:22:28 2014
From: petr.pchelko at oracle.com (Petr Pchelko)
Date: Thu, 24 Jul 2014 15:22:28 +0400
Subject: <AWT Dev> [9] Review Request: 8037485 Refactor
	java.awt.datatransfer to eliminate dependency on AWT
In-Reply-To: <53CFCEE9.6030001@oracle.com>
References: <AC897956-F1CC-457F-B99D-24082558C011@oracle.com>
	<53C8E5C3.6030903@oracle.com>
	<357393F5-C72C-4122-B753-C8A515116616@oracle.com>
	<53CE7E68.4020709@oracle.com>
	<8F600339-7CBA-41D4-A7CB-2560B650CA41@oracle.com>
	<53CFB845.7010305@oracle.com>
	<5032051C-EB18-45B4-B267-4D7BD5D315DC@oracle.com>
	<53CFCEE9.6030001@oracle.com>
Message-ID: <F68F359D-8AD2-46A1-A41F-30F0126487BD@oracle.com>

Hello, 

Thank you for the review.
I?ve updated the fix: http://cr.openjdk.java.net/~pchelko/9/8037485/webrev.04/

I?ve fixed all suggestions except one:
> Another optimization/simplification is possible. You could merge the DesktopDatatransferServiceHolder and default implementation into one class:
No, I could not. The default implementation is a member of desktop module while DataFlavorUtil is a part of data transfer module.

> I skimmed through the webrev and looks good.  It looks like that you have cleanly removed the dependency.  You can run jdk9/bin/jdeps [1] on the java.awt.datatransfer.** and its implementation classes to double check if there is no dependency to the desktop classes.
I?ve run the tool on java.awt.datatransfer and sun.datatransfer packages and there are no dependencies on desktop.

> DataFlavorUtil.java
>    line 544, 549 - some raw types and you may want to check if there are others. 
Fixed and checked the patch for another raw/unchecked warning. 

With best regards. Petr.

> On Jul 23, 2014, at 7:04 PM, Mandy Chung <mandy.chung at oracle.com> wrote:
> 
> 
> On 7/23/2014 6:53 AM, Petr Pchelko wrote:
>> Hello, Alan.
>> 
>>> I'm skimmed over the updated webrev, it mostly looks good except for getFlavorMap where it doesn't set map, I assume you meant to do this:
>>> 
>>> if (map == null)
>>>     flavorMap = map = supplier.get();
>> Thank you! Updated the fix: http://cr.openjdk.java.net/~pchelko/9/8037485/webrev.03/
>> 
>> 
> 
> I skimmed through the webrev and looks good.  It looks like that you have cleanly removed the dependency.  You can run jdk9/bin/jdeps [1] on the java.awt.datatransfer.** and its implementation classes to double check if there is no dependency to the desktop classes.
> 
> Minor comments I spotted:
> java/awt/datatransfer/SystemFlavorMap.java
> line 225 and 238 look like debugging statement to be removed.
> 
> DataFlavorUtil.java
>    line 544, 549 - some raw types and you may want to check if there are others. 
> 
> [1] http://docs.oracle.com/javase/8/docs/technotes/tools/unix/jdeps.html

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

From artem.malinko at oracle.com  Thu Jul 24 11:37:44 2014
From: artem.malinko at oracle.com (artem malinko)
Date: Thu, 24 Jul 2014 15:37:44 +0400
Subject: <AWT Dev> Review request for 8047288: [macosx] Endless loop in
 EDT on Mac
In-Reply-To: <53D0D9BB.6000803@oracle.com>
References: <53CE8B71.8020807@oracle.com>
	<D741BDAC-3A69-46D1-A565-53360414E406@oracle.com>
	<53CFCCF7.70500@oracle.com>
	<28B1A970-DBDE-4C63-A519-04A791C22EF7@oracle.com>
	<53D0A6BC.1060902@oracle.com> <53D0B8FD.7070806@oracle.com>
	<53D0D687.7000607@oracle.com> <53D0D9BB.6000803@oracle.com>
Message-ID: <53D0F008.7070901@oracle.com>

Call stack and sysout show that in case of applet Window.setVisible() is 
called from the main thread or from EDT thread. So I think toolkit 
thread won't call this method.

On 7/24/2014 2:02 PM, Anton V. Tarasov wrote:
> On 24.07.2014 13:48, artem malinko wrote:
>> Hi Anton.
>>
>> Sorry, didn't understand you well. Do you mean we should check(and 
>> test) that this method(isFocusableWindow()) is also called on EDT if 
>> we run applet?
>
> IMHO, it's enough to just make sure (via inspecting the sources) that 
> Window.setVisible() is called on EDT in case of an applet. That logic 
> is triggered on the plugin side.
>
> Anton.
>
>>
>> On 7/24/2014 11:42 AM, Anton V. Tarasov wrote:
>>> Hi Artem,
>>>
>>> I'm Ok with the fix, provided that LWWindowPeer.setVisibleImpl() is 
>>> called on EDT for applets (if I'm not mistaken). Otherwise, we still 
>>> have a client method (getTarget().isFocusableWindow()) called on the 
>>> toolkit thread, which is generally no good.
>>>
>>> Regards,
>>> Anton.
>>>
>>> On 24.07.2014 10:25, artem malinko wrote:
>>>> Thank you, Petr.
>>>>
>>>> Could anyone else review the fix, please?
>>>>
>>>> On 7/23/2014 10:30 PM, Petr Pchelko wrote:
>>>>> Hello, Artem.
>>>>>
>>>>> The new version (it?s .00 for some reason) looks good.
>>>>>
>>>>> With best regards. Petr.
>>>>>
>>>>>> On Jul 23, 2014, at 6:55 PM, artem malinko 
>>>>>> <artem.malinko at oracle.com <mailto:artem.malinko at oracle.com>> wrote:
>>>>>>
>>>>>> Hi, Petr. I ran focus regression tests and jck tests on awt. For 
>>>>>> fixed jdk results is the same. Except my new test, of course 
>>>>>> which is not passed on not fixed jdk:) And also I fixed issues in 
>>>>>> test. New webrev:
>>>>>> http://cr.openjdk.java.net/~bae/8047288/9/webrev.00/
>>>>>>
>>>>>> On 7/22/2014 8:23 PM, Petr Pchelko wrote:
>>>>>>> Hello, Artem.
>>>>>>>
>>>>>>> A couple of comments:
>>>>>>> 1. LWWindowPeer: 268 - please remove an empty line.
>>>>>>> 2. LWWIndowPeer. isTargetFocusable - the method is not needed at 
>>>>>>> all.
>>>>>>> 3. I?m concerned about the test. Do you really need the close 
>>>>>>> button?
>>>>>>> 4. frame and window variables are set from main thread and read 
>>>>>>> from EDT. They should be declared volatile.
>>>>>>>
>>>>>>> Also please run all focus regression and JCK tests, because this 
>>>>>>> area is very sensitive.
>>>>>>>
>>>>>>> With best regards. Petr.
>>>>>>>
>>>>>>>> On Jul 22, 2014, at 8:04 PM, artem malinko 
>>>>>>>> <artem.malinko at oracle.com <mailto:artem.malinko at oracle.com>> wrote:
>>>>>>>>
>>>>>>>> Hello, AWT Team.
>>>>>>>>
>>>>>>>> Please review a fix for the issue:
>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8047288
>>>>>>>> The fix is available at:
>>>>>>>> http://cr.openjdk.java.net/~mcherkas/artem/8047288/webrev.01/ 
>>>>>>>> <http://cr.openjdk.java.net/%7Emcherkas/artem/8047288/webrev.01/>
>>>>>>>>
>>>>>>>> Window.isFocusableWindow() could lead to deadlock if it is 
>>>>>>>> invoked on AppKit thread. Fix caches result of 
>>>>>>>> Window.isFocusableWindow() on a peer level and method is not 
>>>>>>>> invoked on AppkitThread.
>>>>>>>>
>>>>>>>> Thank you.
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>

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

From anton.tarasov at oracle.com  Thu Jul 24 13:33:12 2014
From: anton.tarasov at oracle.com (Anton V. Tarasov)
Date: Thu, 24 Jul 2014 17:33:12 +0400
Subject: <AWT Dev> Review request for 8047288: [macosx] Endless loop in
 EDT on Mac
In-Reply-To: <53D0F008.7070901@oracle.com>
References: <53CE8B71.8020807@oracle.com>
	<D741BDAC-3A69-46D1-A565-53360414E406@oracle.com>
	<53CFCCF7.70500@oracle.com>
	<28B1A970-DBDE-4C63-A519-04A791C22EF7@oracle.com>
	<53D0A6BC.1060902@oracle.com> <53D0B8FD.7070806@oracle.com>
	<53D0D687.7000607@oracle.com> <53D0D9BB.6000803@oracle.com>
	<53D0F008.7070901@oracle.com>
Message-ID: <53D10B18.4090600@oracle.com>

Artem,

I've just noticed the Window.isFocusableWindow method is _final_ . So, that was a false alert, 
sorry. And thanks for the check.
No more questions from me.

Regards,
Anton.

On 24.07.2014 15:37, artem malinko wrote:
> Call stack and sysout show that in case of applet Window.setVisible() is called from the main 
> thread or from EDT thread. So I think toolkit thread won't call this method.
>
> On 7/24/2014 2:02 PM, Anton V. Tarasov wrote:
>> On 24.07.2014 13:48, artem malinko wrote:
>>> Hi Anton.
>>>
>>> Sorry, didn't understand you well. Do you mean we should check(and test) that this 
>>> method(isFocusableWindow()) is also called on EDT if we run applet?
>>
>> IMHO, it's enough to just make sure (via inspecting the sources) that Window.setVisible() is 
>> called on EDT in case of an applet. That logic is triggered on the plugin side.
>>
>> Anton.
>>
>>>
>>> On 7/24/2014 11:42 AM, Anton V. Tarasov wrote:
>>>> Hi Artem,
>>>>
>>>> I'm Ok with the fix, provided that LWWindowPeer.setVisibleImpl() is called on EDT for applets 
>>>> (if I'm not mistaken). Otherwise, we still have a client method 
>>>> (getTarget().isFocusableWindow()) called on the toolkit thread, which is generally no good.
>>>>
>>>> Regards,
>>>> Anton.
>>>>
>>>> On 24.07.2014 10:25, artem malinko wrote:
>>>>> Thank you, Petr.
>>>>>
>>>>> Could anyone else review the fix, please?
>>>>>
>>>>> On 7/23/2014 10:30 PM, Petr Pchelko wrote:
>>>>>> Hello, Artem.
>>>>>>
>>>>>> The new version (it?s .00 for some reason) looks good.
>>>>>>
>>>>>> With best regards. Petr.
>>>>>>
>>>>>>> On Jul 23, 2014, at 6:55 PM, artem malinko <artem.malinko at oracle.com 
>>>>>>> <mailto:artem.malinko at oracle.com>> wrote:
>>>>>>>
>>>>>>> Hi, Petr. I ran focus regression tests and jck tests on awt. For fixed jdk results is the 
>>>>>>> same. Except my new test, of course which is not passed on not fixed jdk:) And also I fixed 
>>>>>>> issues in test. New webrev:
>>>>>>> http://cr.openjdk.java.net/~bae/8047288/9/webrev.00/
>>>>>>>
>>>>>>> On 7/22/2014 8:23 PM, Petr Pchelko wrote:
>>>>>>>> Hello, Artem.
>>>>>>>>
>>>>>>>> A couple of comments:
>>>>>>>> 1. LWWindowPeer: 268 - please remove an empty line.
>>>>>>>> 2. LWWIndowPeer. isTargetFocusable - the method is not needed at all.
>>>>>>>> 3. I?m concerned about the test. Do you really need the close button?
>>>>>>>> 4. frame and window variables are set from main thread and read from EDT. They should be 
>>>>>>>> declared volatile.
>>>>>>>>
>>>>>>>> Also please run all focus regression and JCK tests, because this area is very sensitive.
>>>>>>>>
>>>>>>>> With best regards. Petr.
>>>>>>>>
>>>>>>>>> On Jul 22, 2014, at 8:04 PM, artem malinko <artem.malinko at oracle.com 
>>>>>>>>> <mailto:artem.malinko at oracle.com>> wrote:
>>>>>>>>>
>>>>>>>>> Hello, AWT Team.
>>>>>>>>>
>>>>>>>>> Please review a fix for the issue:
>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8047288
>>>>>>>>> The fix is available at:
>>>>>>>>> http://cr.openjdk.java.net/~mcherkas/artem/8047288/webrev.01/ 
>>>>>>>>> <http://cr.openjdk.java.net/%7Emcherkas/artem/8047288/webrev.01/>
>>>>>>>>>
>>>>>>>>> Window.isFocusableWindow() could lead to deadlock if it is invoked on AppKit thread. Fix 
>>>>>>>>> caches result of Window.isFocusableWindow() on a peer level and method is not invoked on 
>>>>>>>>> AppkitThread.
>>>>>>>>>
>>>>>>>>> Thank you.
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>

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

From artem.malinko at oracle.com  Thu Jul 24 13:37:58 2014
From: artem.malinko at oracle.com (artem malinko)
Date: Thu, 24 Jul 2014 17:37:58 +0400
Subject: <AWT Dev> Review request for 8047288: [macosx] Endless loop in
 EDT on Mac
In-Reply-To: <53D10B18.4090600@oracle.com>
References: <53CE8B71.8020807@oracle.com>
	<D741BDAC-3A69-46D1-A565-53360414E406@oracle.com>
	<53CFCCF7.70500@oracle.com>
	<28B1A970-DBDE-4C63-A519-04A791C22EF7@oracle.com>
	<53D0A6BC.1060902@oracle.com> <53D0B8FD.7070806@oracle.com>
	<53D0D687.7000607@oracle.com> <53D0D9BB.6000803@oracle.com>
	<53D0F008.7070901@oracle.com> <53D10B18.4090600@oracle.com>
Message-ID: <53D10C36.5000402@oracle.com>

Thank you, Anton.

On 7/24/2014 5:33 PM, Anton V. Tarasov wrote:
> Artem,
>
> I've just noticed the Window.isFocusableWindow method is _final_ . So, 
> that was a false alert, sorry. And thanks for the check.
> No more questions from me.
>
> Regards,
> Anton.
>
> On 24.07.2014 15:37, artem malinko wrote:
>> Call stack and sysout show that in case of applet Window.setVisible() 
>> is called from the main thread or from EDT thread. So I think toolkit 
>> thread won't call this method.
>>
>> On 7/24/2014 2:02 PM, Anton V. Tarasov wrote:
>>> On 24.07.2014 13:48, artem malinko wrote:
>>>> Hi Anton.
>>>>
>>>> Sorry, didn't understand you well. Do you mean we should check(and 
>>>> test) that this method(isFocusableWindow()) is also called on EDT 
>>>> if we run applet?
>>>
>>> IMHO, it's enough to just make sure (via inspecting the sources) 
>>> that Window.setVisible() is called on EDT in case of an applet. That 
>>> logic is triggered on the plugin side.
>>>
>>> Anton.
>>>
>>>>
>>>> On 7/24/2014 11:42 AM, Anton V. Tarasov wrote:
>>>>> Hi Artem,
>>>>>
>>>>> I'm Ok with the fix, provided that LWWindowPeer.setVisibleImpl() 
>>>>> is called on EDT for applets (if I'm not mistaken). Otherwise, we 
>>>>> still have a client method (getTarget().isFocusableWindow()) 
>>>>> called on the toolkit thread, which is generally no good.
>>>>>
>>>>> Regards,
>>>>> Anton.
>>>>>
>>>>> On 24.07.2014 10:25, artem malinko wrote:
>>>>>> Thank you, Petr.
>>>>>>
>>>>>> Could anyone else review the fix, please?
>>>>>>
>>>>>> On 7/23/2014 10:30 PM, Petr Pchelko wrote:
>>>>>>> Hello, Artem.
>>>>>>>
>>>>>>> The new version (it?s .00 for some reason) looks good.
>>>>>>>
>>>>>>> With best regards. Petr.
>>>>>>>
>>>>>>>> On Jul 23, 2014, at 6:55 PM, artem malinko 
>>>>>>>> <artem.malinko at oracle.com <mailto:artem.malinko at oracle.com>> wrote:
>>>>>>>>
>>>>>>>> Hi, Petr. I ran focus regression tests and jck tests on awt. 
>>>>>>>> For fixed jdk results is the same. Except my new test, of 
>>>>>>>> course which is not passed on not fixed jdk:) And also I fixed 
>>>>>>>> issues in test. New webrev:
>>>>>>>> http://cr.openjdk.java.net/~bae/8047288/9/webrev.00/
>>>>>>>>
>>>>>>>> On 7/22/2014 8:23 PM, Petr Pchelko wrote:
>>>>>>>>> Hello, Artem.
>>>>>>>>>
>>>>>>>>> A couple of comments:
>>>>>>>>> 1. LWWindowPeer: 268 - please remove an empty line.
>>>>>>>>> 2. LWWIndowPeer. isTargetFocusable - the method is not needed 
>>>>>>>>> at all.
>>>>>>>>> 3. I?m concerned about the test. Do you really need the close 
>>>>>>>>> button?
>>>>>>>>> 4. frame and window variables are set from main thread and 
>>>>>>>>> read from EDT. They should be declared volatile.
>>>>>>>>>
>>>>>>>>> Also please run all focus regression and JCK tests, because 
>>>>>>>>> this area is very sensitive.
>>>>>>>>>
>>>>>>>>> With best regards. Petr.
>>>>>>>>>
>>>>>>>>>> On Jul 22, 2014, at 8:04 PM, artem malinko 
>>>>>>>>>> <artem.malinko at oracle.com <mailto:artem.malinko at oracle.com>> 
>>>>>>>>>> wrote:
>>>>>>>>>>
>>>>>>>>>> Hello, AWT Team.
>>>>>>>>>>
>>>>>>>>>> Please review a fix for the issue:
>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8047288
>>>>>>>>>> The fix is available at:
>>>>>>>>>> http://cr.openjdk.java.net/~mcherkas/artem/8047288/webrev.01/ 
>>>>>>>>>> <http://cr.openjdk.java.net/%7Emcherkas/artem/8047288/webrev.01/>
>>>>>>>>>>
>>>>>>>>>> Window.isFocusableWindow() could lead to deadlock if it is 
>>>>>>>>>> invoked on AppKit thread. Fix caches result of 
>>>>>>>>>> Window.isFocusableWindow() on a peer level and method is not 
>>>>>>>>>> invoked on AppkitThread.
>>>>>>>>>>
>>>>>>>>>> Thank you.
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>

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

From artem.ananiev at oracle.com  Thu Jul 24 14:10:08 2014
From: artem.ananiev at oracle.com (Artem Ananiev)
Date: Thu, 24 Jul 2014 18:10:08 +0400
Subject: <AWT Dev> [9] Review request for 8046495: KeyEvent can not be
 accepted in quick mouse clicking
In-Reply-To: <53C8F6B2.7020008@oracle.com>
References: <53B2EDEA.3010402@oracle.com>
	<B4A1F8A6-25D8-4CA2-A138-95EC14A6A881@oracle.com>
	<53B413A7.4000809@oracle.com> <53B4253A.3040406@oracle.com>
	<53B42689.4090709@oracle.com>
	<59E88D9A-2BF9-41CF-9128-5E5A83B39EF3@oracle.com>
	<53C793F9.6010703@oracle.com> <53C8F6B2.7020008@oracle.com>
Message-ID: <53D113C0.9030808@oracle.com>


On 7/18/2014 2:28 PM, anton nashatyrev wrote:
> Hello,
>
>      in offline discussion with Artem and Petr we decided to further
> clean up the code and completely remove TimeHelper functions from
> awt_Component.cpp in JDK9.
>
>      Could you please review the updated fix:
> http://cr.openjdk.java.net/~anashaty/8046495/9/webrev.01/
> <http://cr.openjdk.java.net/%7Eanashaty/8046495/9/webrev.01/>

Looks fine to me.

Thanks,

Artem

> bug: https://bugs.openjdk.java.net/browse/JDK-8046495
>
> Thank you!
> Anton.
>
> On 17.07.2014 13:14, anton nashatyrev wrote:
>> Hello All,
>>
>>     could please anyone else take a look at the fix?
>>
>> Thanks!
>> Anton.
>>
>> On 02.07.2014 19:37, Petr Pchelko wrote:
>>> Hello, Anton.
>>>
>>> Thanks for clarifications and additional testing.
>>> The fix looks good to me too.
>>>
>>> With best regards. Petr.
>>>
>>> On 02 ???? 2014 ?., at 19:34, Anton V. Tarasov
>>> <anton.tarasov at oracle.com <mailto:anton.tarasov at oracle.com>> wrote:
>>>
>>>> On 02.07.2014 19:28, anton nashatyrev wrote:
>>>>> Hello, Anton
>>>>>
>>>>> On 02.07.2014 18:13, Anton V. Tarasov wrote:
>>>>>> On 02.07.2014 11:44, Petr Pchelko wrote:
>>>>>>> Hello, Anton.
>>>>>>>
>>>>>>> I'm not sure I have a detailed understanding of what's happening.
>>>>>>>
>>>>>>> Before your fix the timestamp of the event represented the time
>>>>>>> when the event was created, and now it's the time when it's sent
>>>>>>> to java.
>>>>>>> This might be important if some events cause other events to be
>>>>>>> issued on the java side.
>>>>>>>
>>>>>>> So suppose the following:
>>>>>>> Toolkit thread: InputEvent#1 created      - timestamp 0
>>>>>>> Toolkit thread: InputEvent#2 created      - timestamp 1
>>>>>>> Toolkit thread: InputEvent#1 sent           - timestamp 2
>>>>>>> EDT: InputEvent#1 dispatched - timestamp 3
>>>>>>> EDT:               FocusEvent  created  - timestamp 4
>>>>>>> Toolkit thread: InputEvent#2 sent           - timestamp 5
>>>>>>>
>>>>>>> Before you fix we had the following event order:
>>>>>>> InputEvent#1(ts=0), InputEvent#2(ts=1), FocusEvent(ts=4).
>>>>>>> But after your fix we will have a different order:
>>>>>>> InputEvent#1(ts=2), FocusEvent(ts=4), InputEvent#2(ts=5).
>>>>>>> So now we would have troubles, because the Input Event will go to
>>>>>>> the new focused component instead of the old one.
>>>>>>> Do you think that my arguments are correct? I understand that the
>>>>>>> likelihood of such a situation is very low, but for me it looks
>>>>>>> possible? Am I missing something?
>>>>>>
>>>>>> A timestamp for a FocusEvent is taken from
>>>>>> the_most_recent_KeyEvent_time which is set on EDT when the event
>>>>>> is dispatched. So the fix shouldn't affect it.
>>>>>>
>>>>>> Also, in awt_Window.cpp, when a TimedWindowEvent is created it is
>>>>>> passed a timestamp got with TimeHelper::getMessageTimeUTC(). It
>>>>>> appears, that the fix makes key events times even more consistent
>>>>>> with it. So, from the kbd focus perspective, it shouldn't make any
>>>>>> harm.
>>>>>>
>>>>>> Anton, could you just please run the following tests, at least:
>>>>>>
>>>>>> test/java/awt/Focus/6981400/*
>>>>>> test/java/awt/KeyboardFocusManager/TypeAhead/*
>>>>>
>>>>> I've tested with the following set:
>>>>> [closed]/java/awt/event/*
>>>>> [closed]/java/awt/Focus/*
>>>>> [closed]java/awt/KeyboardFocusManager/*
>>>>>
>>>>> : no unexpected failures here.
>>>>>
>>>>> I've also verified that my regression test which comes with the fix
>>>>> works fine on Linux and Mac (despite the fix is Win specific).
>>>>
>>>> Great, thanks!
>>>>
>>>> Anton.
>>>>
>>>>>
>>>>> Thanks for review!
>>>>> Anton.
>>>>>
>>>>>>
>>>>>> Thanks,
>>>>>> Anton.
>>>>>>
>>>>>>>
>>>>>>> Another thing I do not understand is why we were used to use the
>>>>>>> complicated formula instead of initializing the msg.time field
>>>>>>> with the JVM current time and using it when sending the event?
>>>>>>> Wouldn't that resolve both your issue and the issue the original
>>>>>>> fix was made for?
>>>>>>>
>>>>>>> I have a couple of comments about the code, but let's postpone
>>>>>>> that until we decide on the approach.
>>>>>>>
>>>>>>> Thank you.
>>>>>>> With best regards. Petr.
>>>>>>>
>>>>>>> On 01 ???? 2014 ?., at 21:20, anton nashatyrev
>>>>>>> <anton.nashatyrev at oracle.com
>>>>>>> <mailto:anton.nashatyrev at oracle.com>> wrote:
>>>>>>>
>>>>>>>> Hello,
>>>>>>>>     could you please review the following fix:
>>>>>>>>
>>>>>>>> fix: http://cr.openjdk.java.net/~anashaty/8046495/9/webrev.00/
>>>>>>>> <http://cr.openjdk.java.net/%7Eanashaty/8046495/9/webrev.00/>
>>>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8046495
>>>>>>>>
>>>>>>>> *Problem:*
>>>>>>>> On Windows the later InputEvent may have earlier timestamp
>>>>>>>> (getWhen()), which results in incorrect processing of enqueued
>>>>>>>> input events and may also potentially be the reason of other
>>>>>>>> artifacts
>>>>>>>>
>>>>>>>> *Evaluation*:
>>>>>>>> On Windows we have some algorithm for calculating input event
>>>>>>>> timestamp: jdk/src/windows/native/sun/windows/awt_Component.cpp:2100
>>>>>>>> Shortly the timestamp is calculated by the following formula:
>>>>>>>>     when = JVM_CurrentTimeMillis() - (GetTickCount() -
>>>>>>>> GetMessageTime())
>>>>>>>>
>>>>>>>> Where:
>>>>>>>>   JVM_CurrentTimeMillis() - the same as System.currentTimeMillis()
>>>>>>>>   GetTickCount() - Win32 function, current millis from boot time
>>>>>>>>   GetMessageTime() - Win32 function, millis from boot time of
>>>>>>>> the latest native Message
>>>>>>>>
>>>>>>>> In theory the formula looks good: we are trying our best to
>>>>>>>> calculate the actual time of the OS message by taking the
>>>>>>>> current JVM time (JVM_CurrentTimeMillis) and adjusting it with
>>>>>>>> the offset (GetTickCount - GetMessageTime) which should indicate
>>>>>>>> how many milliseconds ago from the current moment (GetTickCount)
>>>>>>>> the message has been actually issued (GetMessageTime).
>>>>>>>> In practice due to usage of different system timers by the
>>>>>>>> JVM_CurrentTimeMillis and GetTickCount their values are not
>>>>>>>> updated synchronously and we may get an earlier timestamp for
>>>>>>>> the later event.
>>>>>>>>
>>>>>>>> *Fix*:
>>>>>>>> Just to use JVM_CurrentTimeMillis only as events timestamp. On
>>>>>>>> Mac this is done in exactly the same way:
>>>>>>>> CPlatformResponder.handleMouse/KeyEvent()
>>>>>>>>
>>>>>>>> The message time offset calculation has been introduced with the
>>>>>>>> fix for JDK-4434193
>>>>>>>> <https://bugs.openjdk.java.net/browse/JDK-4434193> and it seems
>>>>>>>> that the issue has addressed very similar problem (At times
>>>>>>>> getWhen()in ActionEvent returns higher value than the
>>>>>>>> CurrentSystemTime) which has not been completely resolved in fact.
>>>>>>>> I also didn't find any benefits in using the existing approach:
>>>>>>>> - all the usages of the TimerHelper are in fact reduced to the
>>>>>>>> mentioned formula: when = JVM_CurrentTimeMillis() -
>>>>>>>> (GetTickCount() - GetMessageTime())
>>>>>>>> - GetMessageTime() always increases (except of the int overflow
>>>>>>>> moments), thus we couldn't get earlier OS messages after later ones
>>>>>>>> - TimerHelper::windowsToUTC(DWORD windowsTime) doesn't guarantee
>>>>>>>> returning the same timestamp across different calls for the same
>>>>>>>> message time
>>>>>>>>
>>>>>>>> Thanks!
>>>>>>>> Anton.
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>

From anton.nashatyrev at oracle.com  Thu Jul 24 15:29:50 2014
From: anton.nashatyrev at oracle.com (anton nashatyrev)
Date: Thu, 24 Jul 2014 19:29:50 +0400
Subject: <AWT Dev> [8] Review request for 8046495: KeyEvent can not be
 accepted in quick mouse clicking
In-Reply-To: <53D113C0.9030808@oracle.com>
References: <53B2EDEA.3010402@oracle.com>
	<B4A1F8A6-25D8-4CA2-A138-95EC14A6A881@oracle.com>
	<53B413A7.4000809@oracle.com> <53B4253A.3040406@oracle.com>
	<53B42689.4090709@oracle.com>
	<59E88D9A-2BF9-41CF-9128-5E5A83B39EF3@oracle.com>
	<53C793F9.6010703@oracle.com> <53C8F6B2.7020008@oracle.com>
	<53D113C0.9030808@oracle.com>
Message-ID: <53D1266E.3080708@oracle.com>

Hello,

     Artem, Petr, thanks for the fix discussion and review!

     could you please review the backport to 8u-dev now?

     It is a little bit more conservative variant of the fix to jdk9 and 
was originally proposed for jdk9 as is.

Webrev: http://cr.openjdk.java.net/%7Eanashaty/8046495/8/webrev.00/
Bug: https://bugs.openjdk.java.net/browse/JDK-8046495

Thank you!
Anton.


On 24.07.2014 18:10, Artem Ananiev wrote:
>
> On 7/18/2014 2:28 PM, anton nashatyrev wrote:
>> Hello,
>>
>>      in offline discussion with Artem and Petr we decided to further
>> clean up the code and completely remove TimeHelper functions from
>> awt_Component.cpp in JDK9.
>>
>>      Could you please review the updated fix:
>> http://cr.openjdk.java.net/~anashaty/8046495/9/webrev.01/
>> <http://cr.openjdk.java.net/%7Eanashaty/8046495/9/webrev.01/>
>
> Looks fine to me.
>
> Thanks,
>
> Artem
>
>> bug: https://bugs.openjdk.java.net/browse/JDK-8046495
>>
>> Thank you!
>> Anton.
>>
>> On 17.07.2014 13:14, anton nashatyrev wrote:
>>> Hello All,
>>>
>>>     could please anyone else take a look at the fix?
>>>
>>> Thanks!
>>> Anton.
>>>
>>> On 02.07.2014 19:37, Petr Pchelko wrote:
>>>> Hello, Anton.
>>>>
>>>> Thanks for clarifications and additional testing.
>>>> The fix looks good to me too.
>>>>
>>>> With best regards. Petr.
>>>>
>>>> On 02 ???? 2014 ?., at 19:34, Anton V. Tarasov
>>>> <anton.tarasov at oracle.com <mailto:anton.tarasov at oracle.com>> wrote:
>>>>
>>>>> On 02.07.2014 19:28, anton nashatyrev wrote:
>>>>>> Hello, Anton
>>>>>>
>>>>>> On 02.07.2014 18:13, Anton V. Tarasov wrote:
>>>>>>> On 02.07.2014 11:44, Petr Pchelko wrote:
>>>>>>>> Hello, Anton.
>>>>>>>>
>>>>>>>> I'm not sure I have a detailed understanding of what's happening.
>>>>>>>>
>>>>>>>> Before your fix the timestamp of the event represented the time
>>>>>>>> when the event was created, and now it's the time when it's sent
>>>>>>>> to java.
>>>>>>>> This might be important if some events cause other events to be
>>>>>>>> issued on the java side.
>>>>>>>>
>>>>>>>> So suppose the following:
>>>>>>>> Toolkit thread: InputEvent#1 created      - timestamp 0
>>>>>>>> Toolkit thread: InputEvent#2 created      - timestamp 1
>>>>>>>> Toolkit thread: InputEvent#1 sent           - timestamp 2
>>>>>>>> EDT: InputEvent#1 dispatched - timestamp 3
>>>>>>>> EDT:               FocusEvent  created  - timestamp 4
>>>>>>>> Toolkit thread: InputEvent#2 sent           - timestamp 5
>>>>>>>>
>>>>>>>> Before you fix we had the following event order:
>>>>>>>> InputEvent#1(ts=0), InputEvent#2(ts=1), FocusEvent(ts=4).
>>>>>>>> But after your fix we will have a different order:
>>>>>>>> InputEvent#1(ts=2), FocusEvent(ts=4), InputEvent#2(ts=5).
>>>>>>>> So now we would have troubles, because the Input Event will go to
>>>>>>>> the new focused component instead of the old one.
>>>>>>>> Do you think that my arguments are correct? I understand that the
>>>>>>>> likelihood of such a situation is very low, but for me it looks
>>>>>>>> possible? Am I missing something?
>>>>>>>
>>>>>>> A timestamp for a FocusEvent is taken from
>>>>>>> the_most_recent_KeyEvent_time which is set on EDT when the event
>>>>>>> is dispatched. So the fix shouldn't affect it.
>>>>>>>
>>>>>>> Also, in awt_Window.cpp, when a TimedWindowEvent is created it is
>>>>>>> passed a timestamp got with TimeHelper::getMessageTimeUTC(). It
>>>>>>> appears, that the fix makes key events times even more consistent
>>>>>>> with it. So, from the kbd focus perspective, it shouldn't make any
>>>>>>> harm.
>>>>>>>
>>>>>>> Anton, could you just please run the following tests, at least:
>>>>>>>
>>>>>>> test/java/awt/Focus/6981400/*
>>>>>>> test/java/awt/KeyboardFocusManager/TypeAhead/*
>>>>>>
>>>>>> I've tested with the following set:
>>>>>> [closed]/java/awt/event/*
>>>>>> [closed]/java/awt/Focus/*
>>>>>> [closed]java/awt/KeyboardFocusManager/*
>>>>>>
>>>>>> : no unexpected failures here.
>>>>>>
>>>>>> I've also verified that my regression test which comes with the fix
>>>>>> works fine on Linux and Mac (despite the fix is Win specific).
>>>>>
>>>>> Great, thanks!
>>>>>
>>>>> Anton.
>>>>>
>>>>>>
>>>>>> Thanks for review!
>>>>>> Anton.
>>>>>>
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Anton.
>>>>>>>
>>>>>>>>
>>>>>>>> Another thing I do not understand is why we were used to use the
>>>>>>>> complicated formula instead of initializing the msg.time field
>>>>>>>> with the JVM current time and using it when sending the event?
>>>>>>>> Wouldn't that resolve both your issue and the issue the original
>>>>>>>> fix was made for?
>>>>>>>>
>>>>>>>> I have a couple of comments about the code, but let's postpone
>>>>>>>> that until we decide on the approach.
>>>>>>>>
>>>>>>>> Thank you.
>>>>>>>> With best regards. Petr.
>>>>>>>>
>>>>>>>> On 01 ???? 2014 ?., at 21:20, anton nashatyrev
>>>>>>>> <anton.nashatyrev at oracle.com
>>>>>>>> <mailto:anton.nashatyrev at oracle.com>> wrote:
>>>>>>>>
>>>>>>>>> Hello,
>>>>>>>>>     could you please review the following fix:
>>>>>>>>>
>>>>>>>>> fix: http://cr.openjdk.java.net/~anashaty/8046495/9/webrev.00/
>>>>>>>>> <http://cr.openjdk.java.net/%7Eanashaty/8046495/9/webrev.00/>
>>>>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8046495
>>>>>>>>>
>>>>>>>>> *Problem:*
>>>>>>>>> On Windows the later InputEvent may have earlier timestamp
>>>>>>>>> (getWhen()), which results in incorrect processing of enqueued
>>>>>>>>> input events and may also potentially be the reason of other
>>>>>>>>> artifacts
>>>>>>>>>
>>>>>>>>> *Evaluation*:
>>>>>>>>> On Windows we have some algorithm for calculating input event
>>>>>>>>> timestamp: 
>>>>>>>>> jdk/src/windows/native/sun/windows/awt_Component.cpp:2100
>>>>>>>>> Shortly the timestamp is calculated by the following formula:
>>>>>>>>>     when = JVM_CurrentTimeMillis() - (GetTickCount() -
>>>>>>>>> GetMessageTime())
>>>>>>>>>
>>>>>>>>> Where:
>>>>>>>>>   JVM_CurrentTimeMillis() - the same as 
>>>>>>>>> System.currentTimeMillis()
>>>>>>>>>   GetTickCount() - Win32 function, current millis from boot time
>>>>>>>>>   GetMessageTime() - Win32 function, millis from boot time of
>>>>>>>>> the latest native Message
>>>>>>>>>
>>>>>>>>> In theory the formula looks good: we are trying our best to
>>>>>>>>> calculate the actual time of the OS message by taking the
>>>>>>>>> current JVM time (JVM_CurrentTimeMillis) and adjusting it with
>>>>>>>>> the offset (GetTickCount - GetMessageTime) which should indicate
>>>>>>>>> how many milliseconds ago from the current moment (GetTickCount)
>>>>>>>>> the message has been actually issued (GetMessageTime).
>>>>>>>>> In practice due to usage of different system timers by the
>>>>>>>>> JVM_CurrentTimeMillis and GetTickCount their values are not
>>>>>>>>> updated synchronously and we may get an earlier timestamp for
>>>>>>>>> the later event.
>>>>>>>>>
>>>>>>>>> *Fix*:
>>>>>>>>> Just to use JVM_CurrentTimeMillis only as events timestamp. On
>>>>>>>>> Mac this is done in exactly the same way:
>>>>>>>>> CPlatformResponder.handleMouse/KeyEvent()
>>>>>>>>>
>>>>>>>>> The message time offset calculation has been introduced with the
>>>>>>>>> fix for JDK-4434193
>>>>>>>>> <https://bugs.openjdk.java.net/browse/JDK-4434193> and it seems
>>>>>>>>> that the issue has addressed very similar problem (At times
>>>>>>>>> getWhen()in ActionEvent returns higher value than the
>>>>>>>>> CurrentSystemTime) which has not been completely resolved in 
>>>>>>>>> fact.
>>>>>>>>> I also didn't find any benefits in using the existing approach:
>>>>>>>>> - all the usages of the TimerHelper are in fact reduced to the
>>>>>>>>> mentioned formula: when = JVM_CurrentTimeMillis() -
>>>>>>>>> (GetTickCount() - GetMessageTime())
>>>>>>>>> - GetMessageTime() always increases (except of the int overflow
>>>>>>>>> moments), thus we couldn't get earlier OS messages after later 
>>>>>>>>> ones
>>>>>>>>> - TimerHelper::windowsToUTC(DWORD windowsTime) doesn't guarantee
>>>>>>>>> returning the same timestamp across different calls for the same
>>>>>>>>> message time
>>>>>>>>>
>>>>>>>>> Thanks!
>>>>>>>>> Anton.
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>


From peter.levart at gmail.com  Fri Jul 25 06:41:34 2014
From: peter.levart at gmail.com (Peter Levart)
Date: Fri, 25 Jul 2014 08:41:34 +0200
Subject: <AWT Dev> [9] Review Request: 8037485 Refactor
 java.awt.datatransfer to eliminate dependency on AWT
In-Reply-To: <F68F359D-8AD2-46A1-A41F-30F0126487BD@oracle.com>
References: <AC897956-F1CC-457F-B99D-24082558C011@oracle.com>
	<53C8E5C3.6030903@oracle.com>
	<357393F5-C72C-4122-B753-C8A515116616@oracle.com>
	<53CE7E68.4020709@oracle.com>
	<8F600339-7CBA-41D4-A7CB-2560B650CA41@oracle.com>
	<53CFB845.7010305@oracle.com>
	<5032051C-EB18-45B4-B267-4D7BD5D315DC@oracle.com>
	<53CFCEE9.6030001@oracle.com>
	<F68F359D-8AD2-46A1-A41F-30F0126487BD@oracle.com>
Message-ID: <53D1FC1E.7040602@gmail.com>

On 07/24/2014 01:22 PM, Petr Pchelko wrote:
> Thank you for the review.
> I?ve updated the fix:http://cr.openjdk.java.net/~pchelko/9/8037485/webrev.04/
>
> I?ve fixed all suggestions except one:
>> >Another optimization/simplification is possible. You could merge the DesktopDatatransferServiceHolder and default implementation into one class:
> No, I could not. The default implementation is a member of desktop module while DataFlavorUtil is a part of data transfer module.
>

Hi Petr,

Sorry, I haven't been clear/precise enough. I meant to say that you 
could merge the DesktopDatatransferServiceHolder class and the 
"fall-back" empty implementation into one class (instead of having 
DesktopDatatransferServiceHolder a separate class and "fall-back" 
implementation being anonymous inner class). You save one class and 
eliminate some boilerplate:

public class DataFlavorUtil {

     public static DesktopDatatransferService getDesktopService() {
         return DesktopDatatransferServiceImpl.INSTANCE;
     }

     private static final class DesktopDatatransferServiceImpl 
implements DesktopDatatransferService {
         static final DesktopDatatransferService INSTANCE;
         static {
             ServiceLoader<DesktopDatatransferService> loader =
                 ServiceLoader.load(DesktopDatatransferService.class, 
null);
             Iterator<DesktopDatatransferService> iterator = 
loader.iterator();
             if (iterator.hasNext()) {
                 INSTANCE = iterator.next();
             } else {
                 INSTANCE = new DesktopDatatransferServiceImpl();
             }
         }

                     /**
                      * System singleton FlavorTable.
                      * Only used if there is no desktop
                      * to provide an appropriate FlavorMap.
                      */
                     private volatile FlavorMap flavorMap;

                     @Override
                     public void invokeOnEventThread(Runnable r) {
                         r.run();
                     }

                     @Override
                     public String getDefaultUnicodeEncoding() {
                         return StandardCharsets.UTF_8.name();
                     }

                     @Override
                     public FlavorMap getFlavorMap(Supplier<FlavorMap> 
supplier) {
                         FlavorMap map = flavorMap;
                         if (map == null) {
                             synchronized (this) {
                                 map = flavorMap;
                                 if (map == null) {
                                     flavorMap = map = supplier.get();
                                 }
                             }
                         }
                         return map;
                     }

                     @Override
                     public boolean isDesktopPresent() {
                         return false;
                     }

                     @Override
                     public LinkedHashSet<DataFlavor> 
getPlatformMappingsForNative(String nat) {
                         return new LinkedHashSet<>();
                     }

                     @Override
                     public LinkedHashSet<String> 
getPlatformMappingsForFlavor(DataFlavor df) {
                         return new LinkedHashSet<>();
                     }

                     @Override
                     public void registerTextFlavorProperties(String 
nat, String charset, String eoln, String terminators) {
                         // Not needed if desktop module is absent
                     }
     }




...but it is good as is.

Regards, Peter


From petr.pchelko at oracle.com  Fri Jul 25 08:48:25 2014
From: petr.pchelko at oracle.com (Petr Pchelko)
Date: Fri, 25 Jul 2014 12:48:25 +0400
Subject: <AWT Dev> [9] Review Request: 8037485 Refactor
	java.awt.datatransfer to eliminate dependency on AWT
In-Reply-To: <53D1FC1E.7040602@gmail.com>
References: <AC897956-F1CC-457F-B99D-24082558C011@oracle.com>
	<53C8E5C3.6030903@oracle.com>
	<357393F5-C72C-4122-B753-C8A515116616@oracle.com>
	<53CE7E68.4020709@oracle.com>
	<8F600339-7CBA-41D4-A7CB-2560B650CA41@oracle.com>
	<53CFB845.7010305@oracle.com>
	<5032051C-EB18-45B4-B267-4D7BD5D315DC@oracle.com>
	<53CFCEE9.6030001@oracle.com>
	<F68F359D-8AD2-46A1-A41F-30F0126487BD@oracle.com>
	<53D1FC1E.7040602@gmail.com>
Message-ID: <BD174F88-F236-4E79-8204-D6B2B7520F89@oracle.com>

Hello, Peter.

Sorry for misunderstanding. 
I've updated the review: http://cr.openjdk.java.net/~pchelko/9/8037485/webrev.05/

With best regards. Petr.

On 25 ???? 2014 ?., at 10:41, Peter Levart <peter.levart at gmail.com> wrote:

> On 07/24/2014 01:22 PM, Petr Pchelko wrote:
>> Thank you for the review.
>> I?ve updated the fix:http://cr.openjdk.java.net/~pchelko/9/8037485/webrev.04/
>> 
>> I?ve fixed all suggestions except one:
>>> >Another optimization/simplification is possible. You could merge the DesktopDatatransferServiceHolder and default implementation into one class:
>> No, I could not. The default implementation is a member of desktop module while DataFlavorUtil is a part of data transfer module.
>> 
> 
> Hi Petr,
> 
> Sorry, I haven't been clear/precise enough. I meant to say that you could merge the DesktopDatatransferServiceHolder class and the "fall-back" empty implementation into one class (instead of having DesktopDatatransferServiceHolder a separate class and "fall-back" implementation being anonymous inner class). You save one class and eliminate some boilerplate:
> 
> public class DataFlavorUtil {
> 
>    public static DesktopDatatransferService getDesktopService() {
>        return DesktopDatatransferServiceImpl.INSTANCE;
>    }
> 
>    private static final class DesktopDatatransferServiceImpl implements DesktopDatatransferService {
>        static final DesktopDatatransferService INSTANCE;
>        static {
>            ServiceLoader<DesktopDatatransferService> loader =
>                ServiceLoader.load(DesktopDatatransferService.class, null);
>            Iterator<DesktopDatatransferService> iterator = loader.iterator();
>            if (iterator.hasNext()) {
>                INSTANCE = iterator.next();
>            } else {
>                INSTANCE = new DesktopDatatransferServiceImpl();
>            }
>        }
> 
>                    /**
>                     * System singleton FlavorTable.
>                     * Only used if there is no desktop
>                     * to provide an appropriate FlavorMap.
>                     */
>                    private volatile FlavorMap flavorMap;
> 
>                    @Override
>                    public void invokeOnEventThread(Runnable r) {
>                        r.run();
>                    }
> 
>                    @Override
>                    public String getDefaultUnicodeEncoding() {
>                        return StandardCharsets.UTF_8.name();
>                    }
> 
>                    @Override
>                    public FlavorMap getFlavorMap(Supplier<FlavorMap> supplier) {
>                        FlavorMap map = flavorMap;
>                        if (map == null) {
>                            synchronized (this) {
>                                map = flavorMap;
>                                if (map == null) {
>                                    flavorMap = map = supplier.get();
>                                }
>                            }
>                        }
>                        return map;
>                    }
> 
>                    @Override
>                    public boolean isDesktopPresent() {
>                        return false;
>                    }
> 
>                    @Override
>                    public LinkedHashSet<DataFlavor> getPlatformMappingsForNative(String nat) {
>                        return new LinkedHashSet<>();
>                    }
> 
>                    @Override
>                    public LinkedHashSet<String> getPlatformMappingsForFlavor(DataFlavor df) {
>                        return new LinkedHashSet<>();
>                    }
> 
>                    @Override
>                    public void registerTextFlavorProperties(String nat, String charset, String eoln, String terminators) {
>                        // Not needed if desktop module is absent
>                    }
>    }
> 
> 
> 
> 
> ...but it is good as is.
> 
> Regards, Peter
> 


From Sergey.Bylokhov at oracle.com  Fri Jul 25 08:59:56 2014
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Fri, 25 Jul 2014 12:59:56 +0400
Subject: <AWT Dev> [9] Review Request: 8037485 Refactor
 java.awt.datatransfer to eliminate dependency on AWT
In-Reply-To: <BD174F88-F236-4E79-8204-D6B2B7520F89@oracle.com>
References: <AC897956-F1CC-457F-B99D-24082558C011@oracle.com>
	<53C8E5C3.6030903@oracle.com>
	<357393F5-C72C-4122-B753-C8A515116616@oracle.com>
	<53CE7E68.4020709@oracle.com>
	<8F600339-7CBA-41D4-A7CB-2560B650CA41@oracle.com>
	<53CFB845.7010305@oracle.com>
	<5032051C-EB18-45B4-B267-4D7BD5D315DC@oracle.com>
	<53CFCEE9.6030001@oracle.com>
	<F68F359D-8AD2-46A1-A41F-30F0126487BD@oracle.com>
	<53D1FC1E.7040602@gmail.com>
	<BD174F88-F236-4E79-8204-D6B2B7520F89@oracle.com>
Message-ID: <53D21C8C.7060001@oracle.com>

Hi, Petr.
Why we have a duplicate version of StandardEncodings in AddFlavorTest 
and DataFlavorUtil?

On 25.07.2014 12:48, Petr Pchelko wrote:
> Hello, Peter.
>
> Sorry for misunderstanding.
> I've updated the review: http://cr.openjdk.java.net/~pchelko/9/8037485/webrev.05/
>
> With best regards. Petr.
>
> On 25 ???? 2014 ?., at 10:41, Peter Levart <peter.levart at gmail.com> wrote:
>
>> On 07/24/2014 01:22 PM, Petr Pchelko wrote:
>>> Thank you for the review.
>>> I?ve updated the fix:http://cr.openjdk.java.net/~pchelko/9/8037485/webrev.04/
>>>
>>> I?ve fixed all suggestions except one:
>>>>> Another optimization/simplification is possible. You could merge the DesktopDatatransferServiceHolder and default implementation into one class:
>>> No, I could not. The default implementation is a member of desktop module while DataFlavorUtil is a part of data transfer module.
>>>
>> Hi Petr,
>>
>> Sorry, I haven't been clear/precise enough. I meant to say that you could merge the DesktopDatatransferServiceHolder class and the "fall-back" empty implementation into one class (instead of having DesktopDatatransferServiceHolder a separate class and "fall-back" implementation being anonymous inner class). You save one class and eliminate some boilerplate:
>>
>> public class DataFlavorUtil {
>>
>>     public static DesktopDatatransferService getDesktopService() {
>>         return DesktopDatatransferServiceImpl.INSTANCE;
>>     }
>>
>>     private static final class DesktopDatatransferServiceImpl implements DesktopDatatransferService {
>>         static final DesktopDatatransferService INSTANCE;
>>         static {
>>             ServiceLoader<DesktopDatatransferService> loader =
>>                 ServiceLoader.load(DesktopDatatransferService.class, null);
>>             Iterator<DesktopDatatransferService> iterator = loader.iterator();
>>             if (iterator.hasNext()) {
>>                 INSTANCE = iterator.next();
>>             } else {
>>                 INSTANCE = new DesktopDatatransferServiceImpl();
>>             }
>>         }
>>
>>                     /**
>>                      * System singleton FlavorTable.
>>                      * Only used if there is no desktop
>>                      * to provide an appropriate FlavorMap.
>>                      */
>>                     private volatile FlavorMap flavorMap;
>>
>>                     @Override
>>                     public void invokeOnEventThread(Runnable r) {
>>                         r.run();
>>                     }
>>
>>                     @Override
>>                     public String getDefaultUnicodeEncoding() {
>>                         return StandardCharsets.UTF_8.name();
>>                     }
>>
>>                     @Override
>>                     public FlavorMap getFlavorMap(Supplier<FlavorMap> supplier) {
>>                         FlavorMap map = flavorMap;
>>                         if (map == null) {
>>                             synchronized (this) {
>>                                 map = flavorMap;
>>                                 if (map == null) {
>>                                     flavorMap = map = supplier.get();
>>                                 }
>>                             }
>>                         }
>>                         return map;
>>                     }
>>
>>                     @Override
>>                     public boolean isDesktopPresent() {
>>                         return false;
>>                     }
>>
>>                     @Override
>>                     public LinkedHashSet<DataFlavor> getPlatformMappingsForNative(String nat) {
>>                         return new LinkedHashSet<>();
>>                     }
>>
>>                     @Override
>>                     public LinkedHashSet<String> getPlatformMappingsForFlavor(DataFlavor df) {
>>                         return new LinkedHashSet<>();
>>                     }
>>
>>                     @Override
>>                     public void registerTextFlavorProperties(String nat, String charset, String eoln, String terminators) {
>>                         // Not needed if desktop module is absent
>>                     }
>>     }
>>
>>
>>
>>
>> ...but it is good as is.
>>
>> Regards, Peter
>>


-- 
Best regards, Sergey.


From petr.pchelko at oracle.com  Fri Jul 25 09:03:39 2014
From: petr.pchelko at oracle.com (Petr Pchelko)
Date: Fri, 25 Jul 2014 13:03:39 +0400
Subject: <AWT Dev> [9] Review Request: 8037485 Refactor
	java.awt.datatransfer to eliminate dependency on AWT
In-Reply-To: <53D21C8C.7060001@oracle.com>
References: <AC897956-F1CC-457F-B99D-24082558C011@oracle.com>
	<53C8E5C3.6030903@oracle.com>
	<357393F5-C72C-4122-B753-C8A515116616@oracle.com>
	<53CE7E68.4020709@oracle.com>
	<8F600339-7CBA-41D4-A7CB-2560B650CA41@oracle.com>
	<53CFB845.7010305@oracle.com>
	<5032051C-EB18-45B4-B267-4D7BD5D315DC@oracle.com>
	<53CFCEE9.6030001@oracle.com>
	<F68F359D-8AD2-46A1-A41F-30F0126487BD@oracle.com>
	<53D1FC1E.7040602@gmail.com>
	<BD174F88-F236-4E79-8204-D6B2B7520F89@oracle.com>
	<53D21C8C.7060001@oracle.com>
Message-ID: <8FC66340-87F5-4768-B3CF-1ADA89CC8349@oracle.com>

Hello, Sergey.

> Why we have a duplicate version of StandardEncodings in AddFlavorTest and DataFlavorUtil?
To avoid referencing internal DataFlavorUtil. 

With best regards. Petr.

On 25 ???? 2014 ?., at 12:59, Sergey Bylokhov <Sergey.Bylokhov at oracle.com> wrote:

> Hi, Petr.
> Why we have a duplicate version of StandardEncodings in AddFlavorTest and DataFlavorUtil?
> 
> On 25.07.2014 12:48, Petr Pchelko wrote:
>> Hello, Peter.
>> 
>> Sorry for misunderstanding.
>> I've updated the review: http://cr.openjdk.java.net/~pchelko/9/8037485/webrev.05/
>> 
>> With best regards. Petr.
>> 
>> On 25 ???? 2014 ?., at 10:41, Peter Levart <peter.levart at gmail.com> wrote:
>> 
>>> On 07/24/2014 01:22 PM, Petr Pchelko wrote:
>>>> Thank you for the review.
>>>> I?ve updated the fix:http://cr.openjdk.java.net/~pchelko/9/8037485/webrev.04/
>>>> 
>>>> I?ve fixed all suggestions except one:
>>>>>> Another optimization/simplification is possible. You could merge the DesktopDatatransferServiceHolder and default implementation into one class:
>>>> No, I could not. The default implementation is a member of desktop module while DataFlavorUtil is a part of data transfer module.
>>>> 
>>> Hi Petr,
>>> 
>>> Sorry, I haven't been clear/precise enough. I meant to say that you could merge the DesktopDatatransferServiceHolder class and the "fall-back" empty implementation into one class (instead of having DesktopDatatransferServiceHolder a separate class and "fall-back" implementation being anonymous inner class). You save one class and eliminate some boilerplate:
>>> 
>>> public class DataFlavorUtil {
>>> 
>>>    public static DesktopDatatransferService getDesktopService() {
>>>        return DesktopDatatransferServiceImpl.INSTANCE;
>>>    }
>>> 
>>>    private static final class DesktopDatatransferServiceImpl implements DesktopDatatransferService {
>>>        static final DesktopDatatransferService INSTANCE;
>>>        static {
>>>            ServiceLoader<DesktopDatatransferService> loader =
>>>                ServiceLoader.load(DesktopDatatransferService.class, null);
>>>            Iterator<DesktopDatatransferService> iterator = loader.iterator();
>>>            if (iterator.hasNext()) {
>>>                INSTANCE = iterator.next();
>>>            } else {
>>>                INSTANCE = new DesktopDatatransferServiceImpl();
>>>            }
>>>        }
>>> 
>>>                    /**
>>>                     * System singleton FlavorTable.
>>>                     * Only used if there is no desktop
>>>                     * to provide an appropriate FlavorMap.
>>>                     */
>>>                    private volatile FlavorMap flavorMap;
>>> 
>>>                    @Override
>>>                    public void invokeOnEventThread(Runnable r) {
>>>                        r.run();
>>>                    }
>>> 
>>>                    @Override
>>>                    public String getDefaultUnicodeEncoding() {
>>>                        return StandardCharsets.UTF_8.name();
>>>                    }
>>> 
>>>                    @Override
>>>                    public FlavorMap getFlavorMap(Supplier<FlavorMap> supplier) {
>>>                        FlavorMap map = flavorMap;
>>>                        if (map == null) {
>>>                            synchronized (this) {
>>>                                map = flavorMap;
>>>                                if (map == null) {
>>>                                    flavorMap = map = supplier.get();
>>>                                }
>>>                            }
>>>                        }
>>>                        return map;
>>>                    }
>>> 
>>>                    @Override
>>>                    public boolean isDesktopPresent() {
>>>                        return false;
>>>                    }
>>> 
>>>                    @Override
>>>                    public LinkedHashSet<DataFlavor> getPlatformMappingsForNative(String nat) {
>>>                        return new LinkedHashSet<>();
>>>                    }
>>> 
>>>                    @Override
>>>                    public LinkedHashSet<String> getPlatformMappingsForFlavor(DataFlavor df) {
>>>                        return new LinkedHashSet<>();
>>>                    }
>>> 
>>>                    @Override
>>>                    public void registerTextFlavorProperties(String nat, String charset, String eoln, String terminators) {
>>>                        // Not needed if desktop module is absent
>>>                    }
>>>    }
>>> 
>>> 
>>> 
>>> 
>>> ...but it is good as is.
>>> 
>>> Regards, Peter
>>> 
> 
> 
> -- 
> Best regards, Sergey.
> 


From Sergey.Bylokhov at oracle.com  Fri Jul 25 09:17:50 2014
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Fri, 25 Jul 2014 13:17:50 +0400
Subject: <AWT Dev> [9] Review Request: 8037485 Refactor
 java.awt.datatransfer to eliminate dependency on AWT
In-Reply-To: <8FC66340-87F5-4768-B3CF-1ADA89CC8349@oracle.com>
References: <AC897956-F1CC-457F-B99D-24082558C011@oracle.com>
	<53C8E5C3.6030903@oracle.com>
	<357393F5-C72C-4122-B753-C8A515116616@oracle.com>
	<53CE7E68.4020709@oracle.com>
	<8F600339-7CBA-41D4-A7CB-2560B650CA41@oracle.com>
	<53CFB845.7010305@oracle.com>
	<5032051C-EB18-45B4-B267-4D7BD5D315DC@oracle.com>
	<53CFCEE9.6030001@oracle.com>
	<F68F359D-8AD2-46A1-A41F-30F0126487BD@oracle.com>
	<53D1FC1E.7040602@gmail.com>
	<BD174F88-F236-4E79-8204-D6B2B7520F89@oracle.com>
	<53D21C8C.7060001@oracle.com>
	<8FC66340-87F5-4768-B3CF-1ADA89CC8349@oracle.com>
Message-ID: <53D220BE.4010902@oracle.com>

Hi, Petr.
The fix looks good.
Please update javadoc for:
/**Returns *an Iterator which traverses a* SortedSet of Strings which are*/
public static Set<String> standardEncodings() {}

On 25.07.2014 13:03, Petr Pchelko wrote:
> Hello, Sergey.
>
>> Why we have a duplicate version of StandardEncodings in AddFlavorTest and DataFlavorUtil?
> To avoid referencing internal DataFlavorUtil.
>
> With best regards. Petr.
>
> On 25 ???? 2014 ?., at 12:59, Sergey Bylokhov <Sergey.Bylokhov at oracle.com> wrote:
>
>> Hi, Petr.
>> Why we have a duplicate version of StandardEncodings in AddFlavorTest and DataFlavorUtil?
>>
>> On 25.07.2014 12:48, Petr Pchelko wrote:
>>> Hello, Peter.
>>>
>>> Sorry for misunderstanding.
>>> I've updated the review: http://cr.openjdk.java.net/~pchelko/9/8037485/webrev.05/
>>>
>>> With best regards. Petr.
>>>
>>> On 25 ???? 2014 ?., at 10:41, Peter Levart <peter.levart at gmail.com> wrote:
>>>
>>>> On 07/24/2014 01:22 PM, Petr Pchelko wrote:
>>>>> Thank you for the review.
>>>>> I?ve updated the fix:http://cr.openjdk.java.net/~pchelko/9/8037485/webrev.04/
>>>>>
>>>>> I?ve fixed all suggestions except one:
>>>>>>> Another optimization/simplification is possible. You could merge the DesktopDatatransferServiceHolder and default implementation into one class:
>>>>> No, I could not. The default implementation is a member of desktop module while DataFlavorUtil is a part of data transfer module.
>>>>>
>>>> Hi Petr,
>>>>
>>>> Sorry, I haven't been clear/precise enough. I meant to say that you could merge the DesktopDatatransferServiceHolder class and the "fall-back" empty implementation into one class (instead of having DesktopDatatransferServiceHolder a separate class and "fall-back" implementation being anonymous inner class). You save one class and eliminate some boilerplate:
>>>>
>>>> public class DataFlavorUtil {
>>>>
>>>>     public static DesktopDatatransferService getDesktopService() {
>>>>         return DesktopDatatransferServiceImpl.INSTANCE;
>>>>     }
>>>>
>>>>     private static final class DesktopDatatransferServiceImpl implements DesktopDatatransferService {
>>>>         static final DesktopDatatransferService INSTANCE;
>>>>         static {
>>>>             ServiceLoader<DesktopDatatransferService> loader =
>>>>                 ServiceLoader.load(DesktopDatatransferService.class, null);
>>>>             Iterator<DesktopDatatransferService> iterator = loader.iterator();
>>>>             if (iterator.hasNext()) {
>>>>                 INSTANCE = iterator.next();
>>>>             } else {
>>>>                 INSTANCE = new DesktopDatatransferServiceImpl();
>>>>             }
>>>>         }
>>>>
>>>>                     /**
>>>>                      * System singleton FlavorTable.
>>>>                      * Only used if there is no desktop
>>>>                      * to provide an appropriate FlavorMap.
>>>>                      */
>>>>                     private volatile FlavorMap flavorMap;
>>>>
>>>>                     @Override
>>>>                     public void invokeOnEventThread(Runnable r) {
>>>>                         r.run();
>>>>                     }
>>>>
>>>>                     @Override
>>>>                     public String getDefaultUnicodeEncoding() {
>>>>                         return StandardCharsets.UTF_8.name();
>>>>                     }
>>>>
>>>>                     @Override
>>>>                     public FlavorMap getFlavorMap(Supplier<FlavorMap> supplier) {
>>>>                         FlavorMap map = flavorMap;
>>>>                         if (map == null) {
>>>>                             synchronized (this) {
>>>>                                 map = flavorMap;
>>>>                                 if (map == null) {
>>>>                                     flavorMap = map = supplier.get();
>>>>                                 }
>>>>                             }
>>>>                         }
>>>>                         return map;
>>>>                     }
>>>>
>>>>                     @Override
>>>>                     public boolean isDesktopPresent() {
>>>>                         return false;
>>>>                     }
>>>>
>>>>                     @Override
>>>>                     public LinkedHashSet<DataFlavor> getPlatformMappingsForNative(String nat) {
>>>>                         return new LinkedHashSet<>();
>>>>                     }
>>>>
>>>>                     @Override
>>>>                     public LinkedHashSet<String> getPlatformMappingsForFlavor(DataFlavor df) {
>>>>                         return new LinkedHashSet<>();
>>>>                     }
>>>>
>>>>                     @Override
>>>>                     public void registerTextFlavorProperties(String nat, String charset, String eoln, String terminators) {
>>>>                         // Not needed if desktop module is absent
>>>>                     }
>>>>     }
>>>>
>>>>
>>>>
>>>>
>>>> ...but it is good as is.
>>>>
>>>> Regards, Peter
>>>>
>>
>> -- 
>> Best regards, Sergey.
>>


-- 
Best regards, Sergey.

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

From petr.pchelko at oracle.com  Mon Jul 28 11:35:07 2014
From: petr.pchelko at oracle.com (Petr Pchelko)
Date: Mon, 28 Jul 2014 15:35:07 +0400
Subject: <AWT Dev> [9] Review Request: 8051449 Incorrect parsing of the
	default flavor mapping
In-Reply-To: <9F9664FC-8435-408E-9941-10858D1E288B@oracle.com>
References: <9F9664FC-8435-408E-9941-10858D1E288B@oracle.com>
Message-ID: <913EDBEC-984E-4AB9-B085-FC755C1E56FB@oracle.com>

Hello, AWT Team.

Please review an updated version of this fix:
http://cr.openjdk.java.net/~pchelko/9/8051449/webrev.01/

I've changed the package name for a flavormap.properties file, because it needs to go to the 
datatransfer module and in a parallel review we've decided to change it's package name.
All the rest is the same as in the previous version.

With best regards. Petr.

On 22 ???? 2014 ?., at 15:50, Petr Pchelko <petr.pchelko at oracle.com> wrote:

> Hello, AWT Team.
> 
> Please review the fix for the issue:
> https://bugs.openjdk.java.net/browse/JDK-8051449
> The fix is available at:
> http://cr.openjdk.java.net/~pchelko/9/8051449/webrev/webrev/
> 
> This is a regression of one of my recent fixes where I've got a bit too brave with a clenup.
> Here I've returning back the loadConvert function which translates escaped characters in
> a properties file to their actual ASCII representation.
> 
> Thank you.
> With best regards. Petr.


From Sergey.Bylokhov at oracle.com  Mon Jul 28 12:14:32 2014
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Mon, 28 Jul 2014 16:14:32 +0400
Subject: <AWT Dev> [9] Review Request: 8051449 Incorrect parsing of the
 default flavor mapping
In-Reply-To: <913EDBEC-984E-4AB9-B085-FC755C1E56FB@oracle.com>
References: <9F9664FC-8435-408E-9941-10858D1E288B@oracle.com>
	<913EDBEC-984E-4AB9-B085-FC755C1E56FB@oracle.com>
Message-ID: <53D63EA8.8060306@oracle.com>

Hi, Petr.
The previous version has a note that it was copied from the 
java.util.Properties. Probably we can call it from java.util.Properties 
directly?

On 7/28/14 3:35 PM, Petr Pchelko wrote:
> Hello, AWT Team.
>
> Please review an updated version of this fix:
> http://cr.openjdk.java.net/~pchelko/9/8051449/webrev.01/
>
> I've changed the package name for a flavormap.properties file, because it needs to go to the
> datatransfer module and in a parallel review we've decided to change it's package name.
> All the rest is the same as in the previous version.
>
> With best regards. Petr.
>
> On 22 ???? 2014 ?., at 15:50, Petr Pchelko <petr.pchelko at oracle.com> wrote:
>
>> Hello, AWT Team.
>>
>> Please review the fix for the issue:
>> https://bugs.openjdk.java.net/browse/JDK-8051449
>> The fix is available at:
>> http://cr.openjdk.java.net/~pchelko/9/8051449/webrev/webrev/
>>
>> This is a regression of one of my recent fixes where I've got a bit too brave with a clenup.
>> Here I've returning back the loadConvert function which translates escaped characters in
>> a properties file to their actual ASCII representation.
>>
>> Thank you.
>> With best regards. Petr.


-- 
Best regards, Sergey.


From petr.pchelko at oracle.com  Mon Jul 28 12:20:25 2014
From: petr.pchelko at oracle.com (Petr Pchelko)
Date: Mon, 28 Jul 2014 16:20:25 +0400
Subject: <AWT Dev> [9] Review Request: 8051449 Incorrect parsing of the
	default flavor mapping
In-Reply-To: <53D63EA8.8060306@oracle.com>
References: <9F9664FC-8435-408E-9941-10858D1E288B@oracle.com>
	<913EDBEC-984E-4AB9-B085-FC755C1E56FB@oracle.com>
	<53D63EA8.8060306@oracle.com>
Message-ID: <636579E3-7AB8-4D7C-A223-1FD8EE04EEF8@oracle.com>

Hello, Sergey.

>  Probably we can call it from java.util.Properties directly?

It's private inside Properties class. We could've used an Accessor in sun.misc, but this would add some issues for modules.
Reflection is also a possibility, but again, it's not very good for modules. Here I'm just reverting a piece of my previous fix and I
think it's the safest solution.

With best regards. Petr. 

On 28 ???? 2014 ?., at 16:14, Sergey Bylokhov <Sergey.Bylokhov at oracle.com> wrote:

> Hi, Petr.
> The previous version has a note that it was copied from the java.util.Properties. Probably we can call it from java.util.Properties directly?
> 
> On 7/28/14 3:35 PM, Petr Pchelko wrote:
>> Hello, AWT Team.
>> 
>> Please review an updated version of this fix:
>> http://cr.openjdk.java.net/~pchelko/9/8051449/webrev.01/
>> 
>> I've changed the package name for a flavormap.properties file, because it needs to go to the
>> datatransfer module and in a parallel review we've decided to change it's package name.
>> All the rest is the same as in the previous version.
>> 
>> With best regards. Petr.
>> 
>> On 22 ???? 2014 ?., at 15:50, Petr Pchelko <petr.pchelko at oracle.com> wrote:
>> 
>>> Hello, AWT Team.
>>> 
>>> Please review the fix for the issue:
>>> https://bugs.openjdk.java.net/browse/JDK-8051449
>>> The fix is available at:
>>> http://cr.openjdk.java.net/~pchelko/9/8051449/webrev/webrev/
>>> 
>>> This is a regression of one of my recent fixes where I've got a bit too brave with a clenup.
>>> Here I've returning back the loadConvert function which translates escaped characters in
>>> a properties file to their actual ASCII representation.
>>> 
>>> Thank you.
>>> With best regards. Petr.
> 
> 
> -- 
> Best regards, Sergey.
> 


From dmitriy.ermashov at oracle.com  Mon Jul 28 12:21:12 2014
From: dmitriy.ermashov at oracle.com (Dmitriy Ermashov)
Date: Mon, 28 Jul 2014 16:21:12 +0400
Subject: <AWT Dev> Review Request for 8051716: Move AWT_BAT functional tests
 to OpenJDK (1 of 3)
Message-ID: <53D64038.5040307@oracle.com>

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

-- 
Thanks,
Dima


From Sergey.Bylokhov at oracle.com  Mon Jul 28 12:27:33 2014
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Mon, 28 Jul 2014 16:27:33 +0400
Subject: <AWT Dev> [9] Review Request: 8051449 Incorrect parsing of the
 default flavor mapping
In-Reply-To: <636579E3-7AB8-4D7C-A223-1FD8EE04EEF8@oracle.com>
References: <9F9664FC-8435-408E-9941-10858D1E288B@oracle.com>
	<913EDBEC-984E-4AB9-B085-FC755C1E56FB@oracle.com>
	<53D63EA8.8060306@oracle.com>
	<636579E3-7AB8-4D7C-A223-1FD8EE04EEF8@oracle.com>
Message-ID: <53D641B5.5010000@oracle.com>

On 7/28/14 4:20 PM, Petr Pchelko wrote:
> Hello, Sergey.
>
>>   Probably we can call it from java.util.Properties directly?
> It's private inside Properties class. We could've used an Accessor in sun.misc, but this would add some issues for modules.
> Reflection is also a possibility, but again, it's not very good for modules. Here I'm just reverting a piece of my previous fix and I
> think it's the safest solution.
Ok, then fix looks fine.
>
> With best regards. Petr.
>
> On 28 ???? 2014 ?., at 16:14, Sergey Bylokhov <Sergey.Bylokhov at oracle.com> wrote:
>
>> Hi, Petr.
>> The previous version has a note that it was copied from the java.util.Properties. Probably we can call it from java.util.Properties directly?
>>
>> On 7/28/14 3:35 PM, Petr Pchelko wrote:
>>> Hello, AWT Team.
>>>
>>> Please review an updated version of this fix:
>>> http://cr.openjdk.java.net/~pchelko/9/8051449/webrev.01/
>>>
>>> I've changed the package name for a flavormap.properties file, because it needs to go to the
>>> datatransfer module and in a parallel review we've decided to change it's package name.
>>> All the rest is the same as in the previous version.
>>>
>>> With best regards. Petr.
>>>
>>> On 22 ???? 2014 ?., at 15:50, Petr Pchelko <petr.pchelko at oracle.com> wrote:
>>>
>>>> Hello, AWT Team.
>>>>
>>>> Please review the fix for the issue:
>>>> https://bugs.openjdk.java.net/browse/JDK-8051449
>>>> The fix is available at:
>>>> http://cr.openjdk.java.net/~pchelko/9/8051449/webrev/webrev/
>>>>
>>>> This is a regression of one of my recent fixes where I've got a bit too brave with a clenup.
>>>> Here I've returning back the loadConvert function which translates escaped characters in
>>>> a properties file to their actual ASCII representation.
>>>>
>>>> Thank you.
>>>> With best regards. Petr.
>>
>> -- 
>> Best regards, Sergey.
>>


-- 
Best regards, Sergey.


From alexandr.scherbatiy at oracle.com  Mon Jul 28 12:30:07 2014
From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy)
Date: Mon, 28 Jul 2014 16:30:07 +0400
Subject: <AWT Dev> [9] Review Request: 8051449 Incorrect parsing of the
 default flavor mapping
In-Reply-To: <913EDBEC-984E-4AB9-B085-FC755C1E56FB@oracle.com>
References: <9F9664FC-8435-408E-9941-10858D1E288B@oracle.com>
	<913EDBEC-984E-4AB9-B085-FC755C1E56FB@oracle.com>
Message-ID: <53D6424F.1090505@oracle.com>


   The fix looks good to me.

   Thanks,
   Alexandr.

On 7/28/2014 3:35 PM, Petr Pchelko wrote:
> Hello, AWT Team.
>
> Please review an updated version of this fix:
> http://cr.openjdk.java.net/~pchelko/9/8051449/webrev.01/
>
> I've changed the package name for a flavormap.properties file, because it needs to go to the
> datatransfer module and in a parallel review we've decided to change it's package name.
> All the rest is the same as in the previous version.
>
> With best regards. Petr.
>
> On 22 ???? 2014 ?., at 15:50, Petr Pchelko <petr.pchelko at oracle.com> wrote:
>
>> Hello, AWT Team.
>>
>> Please review the fix for the issue:
>> https://bugs.openjdk.java.net/browse/JDK-8051449
>> The fix is available at:
>> http://cr.openjdk.java.net/~pchelko/9/8051449/webrev/webrev/
>>
>> This is a regression of one of my recent fixes where I've got a bit too brave with a clenup.
>> Here I've returning back the loadConvert function which translates escaped characters in
>> a properties file to their actual ASCII representation.
>>
>> Thank you.
>> With best regards. Petr.


From petr.pchelko at oracle.com  Mon Jul 28 14:52:46 2014
From: petr.pchelko at oracle.com (Petr Pchelko)
Date: Mon, 28 Jul 2014 18:52:46 +0400
Subject: <AWT Dev> [9] Review Request: 8051588
	DataTransferer.getInstance throws ClassCastException in
	headless mode
In-Reply-To: <53CFB2CE.6050505@oracle.com>
References: <F3E802AE-2F7E-4DCD-8B34-85479636C9AB@oracle.com>
	<53CFB2CE.6050505@oracle.com>
Message-ID: <F90314CD-8074-411B-AF51-289808E273D5@oracle.com>

Hello, AWT team.

Could I please get a second review on this?

Thank you.
With bes tregards. Petr.

On 23 ???? 2014 ?., at 17:04, Alexander Scherbatiy <alexandr.scherbatiy at oracle.com> wrote:

> 
> The fix looks good to me.
> 
> Thanks,
> Alexandr.
> 
> On 7/22/2014 4:20 PM, Petr Pchelko wrote:
>> Hello, AWT Team.
>> 
>> Please review the fix for the issue:
>> https://bugs.openjdk.java.net/browse/JDK-8051588
>> The fix is available at:
>> http://cr.openjdk.java.net/~pchelko/9/8051588/webrev/
>> 
>> JCK test fails in headless mode because of this issue.
>> 
>> With best regards. Petr.
> 


From Sergey.Bylokhov at oracle.com  Mon Jul 28 14:57:14 2014
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Mon, 28 Jul 2014 18:57:14 +0400
Subject: <AWT Dev> [9] Review Request: 8051588
 DataTransferer.getInstance throws ClassCastException in headless mode
In-Reply-To: <F90314CD-8074-411B-AF51-289808E273D5@oracle.com>
References: <F3E802AE-2F7E-4DCD-8B34-85479636C9AB@oracle.com>
	<53CFB2CE.6050505@oracle.com>
	<F90314CD-8074-411B-AF51-289808E273D5@oracle.com>
Message-ID: <53D664CA.5060001@oracle.com>

Hi, Petr.
The fix looks good.

On 7/28/14 6:52 PM, Petr Pchelko wrote:
> Hello, AWT team.
>
> Could I please get a second review on this?
>
> Thank you.
> With bes tregards. Petr.
>
> On 23 ???? 2014 ?., at 17:04, Alexander Scherbatiy <alexandr.scherbatiy at oracle.com> wrote:
>
>> The fix looks good to me.
>>
>> Thanks,
>> Alexandr.
>>
>> On 7/22/2014 4:20 PM, Petr Pchelko wrote:
>>> Hello, AWT Team.
>>>
>>> Please review the fix for the issue:
>>> https://bugs.openjdk.java.net/browse/JDK-8051588
>>> The fix is available at:
>>> http://cr.openjdk.java.net/~pchelko/9/8051588/webrev/
>>>
>>> JCK test fails in headless mode because of this issue.
>>>
>>> With best regards. Petr.


-- 
Best regards, Sergey.


From Sergey.Bylokhov at oracle.com  Mon Jul 28 15:03:09 2014
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Mon, 28 Jul 2014 19:03:09 +0400
Subject: <AWT Dev> [9] Review Request: 8033141 Cleanup of sun.awt.X11 package
Message-ID: <53D6662D.7000608@oracle.com>

Hello.
Please review a small KSS fix.

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

-- 
Best regards, Sergey.


From petr.pchelko at oracle.com  Mon Jul 28 15:08:04 2014
From: petr.pchelko at oracle.com (Petr Pchelko)
Date: Mon, 28 Jul 2014 19:08:04 +0400
Subject: <AWT Dev> [9] Review Request: 8033141 Cleanup of sun.awt.X11
	package
In-Reply-To: <53D6662D.7000608@oracle.com>
References: <53D6662D.7000608@oracle.com>
Message-ID: <93CE2A34-853D-4AA4-875D-77208AE29A0D@oracle.com>

Hello, Sergey.

The fix looks good.
Could you please add a space before = in XlibWrapper:51 before the push?

Thank you.
With best regards. Petr.

On 28 ???? 2014 ?., at 19:03, Sergey Bylokhov <Sergey.Bylokhov at oracle.com> wrote:

> Hello.
> Please review a small KSS fix.
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8033141
> Webrev can be found at: http://cr.openjdk.java.net/~serb/8033141/webrev.00
> 
> -- 
> Best regards, Sergey.
> 


From alexander.zvegintsev at oracle.com  Mon Jul 28 15:51:47 2014
From: alexander.zvegintsev at oracle.com (Alexander Zvegintsev)
Date: Mon, 28 Jul 2014 19:51:47 +0400
Subject: <AWT Dev> [9] Review Request: 8033141 Cleanup of sun.awt.X11
	package
In-Reply-To: <53D6662D.7000608@oracle.com>
References: <53D6662D.7000608@oracle.com>
Message-ID: <53D67193.3030201@oracle.com>

Hi Sergey,

the fix looks good to me.

Thanks,

Alexander.

On 07/28/2014 07:03 PM, Sergey Bylokhov wrote:
> Hello.
> Please review a small KSS fix.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8033141
> Webrev can be found at: 
> http://cr.openjdk.java.net/~serb/8033141/webrev.00
>


From Sergey.Bylokhov at oracle.com  Mon Jul 28 15:56:43 2014
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Mon, 28 Jul 2014 19:56:43 +0400
Subject: <AWT Dev> [9] Review Request: 8033141 Cleanup of sun.awt.X11
	package
In-Reply-To: <53D6662D.7000608@oracle.com>
References: <53D6662D.7000608@oracle.com>
Message-ID: <53D672BB.9070304@oracle.com>

Hello.
The fix was updated to make Xtoolkit public again, otherwise runtime 
exception was thrown.

On 7/28/14 7:03 PM, Sergey Bylokhov wrote:
> Hello.
> Please review a small KSS fix.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8033141
> Webrev can be found at: 
> http://cr.openjdk.java.net/~serb/8033141/webrev.00
>


-- 
Best regards, Sergey.


From alexander.v.stepanov at oracle.com  Mon Jul 28 16:13:32 2014
From: alexander.v.stepanov at oracle.com (alexander stepanov)
Date: Mon, 28 Jul 2014 20:13:32 +0400
Subject: <AWT Dev> [9] Review Request for 8050885: move awt automated tests
 from AWT_Modality to OpenJDK repository - part 4
Message-ID: <53D676AC.2010807@oracle.com>

Hello,

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

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

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 petr.pchelko at oracle.com  Tue Jul 29 07:37:42 2014
From: petr.pchelko at oracle.com (Petr Pchelko)
Date: Tue, 29 Jul 2014 11:37:42 +0400
Subject: <AWT Dev> [9] Review Request for 8050885: move awt automated
	tests from AWT_Modality to OpenJDK repository - part 4
In-Reply-To: <53D676AC.2010807@oracle.com>
References: <53D676AC.2010807@oracle.com>
Message-ID: <691AAAAD-71BD-4613-ADE0-7BCC6D920422@oracle.com>

Hello, Alexander.

The fix looks fine.
Just could you please make the fields that hold frames volatile? New review is not needed.

With best regards. Petr.

> On Jul 28, 2014, at 8:13 PM, alexander stepanov <alexander.v.stepanov at oracle.com> wrote:
> 
> Hello,
> 
> Could you please review the fix for
> https://bugs.openjdk.java.net/browse/JDK-8050885
> 
> webrev:
> http://cr.openjdk.java.net/~avstepan/8050885/
> 
> 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 alexander.v.stepanov at oracle.com  Tue Jul 29 11:04:28 2014
From: alexander.v.stepanov at oracle.com (alexander stepanov)
Date: Tue, 29 Jul 2014 15:04:28 +0400
Subject: <AWT Dev> [9] Review Request for 8050885: move awt automated
 tests from AWT_Modality to OpenJDK repository - part 4
In-Reply-To: <691AAAAD-71BD-4613-ADE0-7BCC6D920422@oracle.com>
References: <53D676AC.2010807@oracle.com>
	<691AAAAD-71BD-4613-ADE0-7BCC6D920422@oracle.com>
Message-ID: <53D77FBC.1040808@oracle.com>

Hello Petr,

Fixed. Thank you for review!

Regards,
Alexander

On 29.07.2014 11:37, Petr Pchelko wrote:
> Hello, Alexander.
>
> The fix looks fine.
> Just could you please make the fields that hold frames volatile? New review is not needed.
>
> With best regards. Petr.
>
>> On Jul 28, 2014, at 8:13 PM, alexander stepanov <alexander.v.stepanov at oracle.com> wrote:
>>
>> Hello,
>>
>> Could you please review the fix for
>> https://bugs.openjdk.java.net/browse/JDK-8050885
>>
>> webrev:
>> http://cr.openjdk.java.net/~avstepan/8050885/
>>
>> 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 artem.ananiev at oracle.com  Tue Jul 29 11:35:08 2014
From: artem.ananiev at oracle.com (Artem Ananiev)
Date: Tue, 29 Jul 2014 15:35:08 +0400
Subject: <AWT Dev> [8] Review request for 8046495: KeyEvent can not be
 accepted in quick mouse clicking
In-Reply-To: <53D1266E.3080708@oracle.com>
References: <53B2EDEA.3010402@oracle.com>
	<B4A1F8A6-25D8-4CA2-A138-95EC14A6A881@oracle.com>
	<53B413A7.4000809@oracle.com> <53B4253A.3040406@oracle.com>
	<53B42689.4090709@oracle.com>
	<59E88D9A-2BF9-41CF-9128-5E5A83B39EF3@oracle.com>
	<53C793F9.6010703@oracle.com> <53C8F6B2.7020008@oracle.com>
	<53D113C0.9030808@oracle.com> <53D1266E.3080708@oracle.com>
Message-ID: <53D786EC.2040109@oracle.com>

Hi, Anton,

8u backport looks fine.

Thanks,

Artem

On 7/24/2014 7:29 PM, anton nashatyrev wrote:
> Hello,
>
>      Artem, Petr, thanks for the fix discussion and review!
>
>      could you please review the backport to 8u-dev now?
>
>      It is a little bit more conservative variant of the fix to jdk9 and
> was originally proposed for jdk9 as is.
>
> Webrev: http://cr.openjdk.java.net/%7Eanashaty/8046495/8/webrev.00/
> Bug: https://bugs.openjdk.java.net/browse/JDK-8046495
>
> Thank you!
> Anton.
>
>
> On 24.07.2014 18:10, Artem Ananiev wrote:
>>
>> On 7/18/2014 2:28 PM, anton nashatyrev wrote:
>>> Hello,
>>>
>>>      in offline discussion with Artem and Petr we decided to further
>>> clean up the code and completely remove TimeHelper functions from
>>> awt_Component.cpp in JDK9.
>>>
>>>      Could you please review the updated fix:
>>> http://cr.openjdk.java.net/~anashaty/8046495/9/webrev.01/
>>> <http://cr.openjdk.java.net/%7Eanashaty/8046495/9/webrev.01/>
>>
>> Looks fine to me.
>>
>> Thanks,
>>
>> Artem
>>
>>> bug: https://bugs.openjdk.java.net/browse/JDK-8046495
>>>
>>> Thank you!
>>> Anton.
>>>
>>> On 17.07.2014 13:14, anton nashatyrev wrote:
>>>> Hello All,
>>>>
>>>>     could please anyone else take a look at the fix?
>>>>
>>>> Thanks!
>>>> Anton.
>>>>
>>>> On 02.07.2014 19:37, Petr Pchelko wrote:
>>>>> Hello, Anton.
>>>>>
>>>>> Thanks for clarifications and additional testing.
>>>>> The fix looks good to me too.
>>>>>
>>>>> With best regards. Petr.
>>>>>
>>>>> On 02 ???? 2014 ?., at 19:34, Anton V. Tarasov
>>>>> <anton.tarasov at oracle.com <mailto:anton.tarasov at oracle.com>> wrote:
>>>>>
>>>>>> On 02.07.2014 19:28, anton nashatyrev wrote:
>>>>>>> Hello, Anton
>>>>>>>
>>>>>>> On 02.07.2014 18:13, Anton V. Tarasov wrote:
>>>>>>>> On 02.07.2014 11:44, Petr Pchelko wrote:
>>>>>>>>> Hello, Anton.
>>>>>>>>>
>>>>>>>>> I'm not sure I have a detailed understanding of what's happening.
>>>>>>>>>
>>>>>>>>> Before your fix the timestamp of the event represented the time
>>>>>>>>> when the event was created, and now it's the time when it's sent
>>>>>>>>> to java.
>>>>>>>>> This might be important if some events cause other events to be
>>>>>>>>> issued on the java side.
>>>>>>>>>
>>>>>>>>> So suppose the following:
>>>>>>>>> Toolkit thread: InputEvent#1 created      - timestamp 0
>>>>>>>>> Toolkit thread: InputEvent#2 created      - timestamp 1
>>>>>>>>> Toolkit thread: InputEvent#1 sent           - timestamp 2
>>>>>>>>> EDT: InputEvent#1 dispatched - timestamp 3
>>>>>>>>> EDT:               FocusEvent  created  - timestamp 4
>>>>>>>>> Toolkit thread: InputEvent#2 sent           - timestamp 5
>>>>>>>>>
>>>>>>>>> Before you fix we had the following event order:
>>>>>>>>> InputEvent#1(ts=0), InputEvent#2(ts=1), FocusEvent(ts=4).
>>>>>>>>> But after your fix we will have a different order:
>>>>>>>>> InputEvent#1(ts=2), FocusEvent(ts=4), InputEvent#2(ts=5).
>>>>>>>>> So now we would have troubles, because the Input Event will go to
>>>>>>>>> the new focused component instead of the old one.
>>>>>>>>> Do you think that my arguments are correct? I understand that the
>>>>>>>>> likelihood of such a situation is very low, but for me it looks
>>>>>>>>> possible? Am I missing something?
>>>>>>>>
>>>>>>>> A timestamp for a FocusEvent is taken from
>>>>>>>> the_most_recent_KeyEvent_time which is set on EDT when the event
>>>>>>>> is dispatched. So the fix shouldn't affect it.
>>>>>>>>
>>>>>>>> Also, in awt_Window.cpp, when a TimedWindowEvent is created it is
>>>>>>>> passed a timestamp got with TimeHelper::getMessageTimeUTC(). It
>>>>>>>> appears, that the fix makes key events times even more consistent
>>>>>>>> with it. So, from the kbd focus perspective, it shouldn't make any
>>>>>>>> harm.
>>>>>>>>
>>>>>>>> Anton, could you just please run the following tests, at least:
>>>>>>>>
>>>>>>>> test/java/awt/Focus/6981400/*
>>>>>>>> test/java/awt/KeyboardFocusManager/TypeAhead/*
>>>>>>>
>>>>>>> I've tested with the following set:
>>>>>>> [closed]/java/awt/event/*
>>>>>>> [closed]/java/awt/Focus/*
>>>>>>> [closed]java/awt/KeyboardFocusManager/*
>>>>>>>
>>>>>>> : no unexpected failures here.
>>>>>>>
>>>>>>> I've also verified that my regression test which comes with the fix
>>>>>>> works fine on Linux and Mac (despite the fix is Win specific).
>>>>>>
>>>>>> Great, thanks!
>>>>>>
>>>>>> Anton.
>>>>>>
>>>>>>>
>>>>>>> Thanks for review!
>>>>>>> Anton.
>>>>>>>
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>> Anton.
>>>>>>>>
>>>>>>>>>
>>>>>>>>> Another thing I do not understand is why we were used to use the
>>>>>>>>> complicated formula instead of initializing the msg.time field
>>>>>>>>> with the JVM current time and using it when sending the event?
>>>>>>>>> Wouldn't that resolve both your issue and the issue the original
>>>>>>>>> fix was made for?
>>>>>>>>>
>>>>>>>>> I have a couple of comments about the code, but let's postpone
>>>>>>>>> that until we decide on the approach.
>>>>>>>>>
>>>>>>>>> Thank you.
>>>>>>>>> With best regards. Petr.
>>>>>>>>>
>>>>>>>>> On 01 ???? 2014 ?., at 21:20, anton nashatyrev
>>>>>>>>> <anton.nashatyrev at oracle.com
>>>>>>>>> <mailto:anton.nashatyrev at oracle.com>> wrote:
>>>>>>>>>
>>>>>>>>>> Hello,
>>>>>>>>>>     could you please review the following fix:
>>>>>>>>>>
>>>>>>>>>> fix: http://cr.openjdk.java.net/~anashaty/8046495/9/webrev.00/
>>>>>>>>>> <http://cr.openjdk.java.net/%7Eanashaty/8046495/9/webrev.00/>
>>>>>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8046495
>>>>>>>>>>
>>>>>>>>>> *Problem:*
>>>>>>>>>> On Windows the later InputEvent may have earlier timestamp
>>>>>>>>>> (getWhen()), which results in incorrect processing of enqueued
>>>>>>>>>> input events and may also potentially be the reason of other
>>>>>>>>>> artifacts
>>>>>>>>>>
>>>>>>>>>> *Evaluation*:
>>>>>>>>>> On Windows we have some algorithm for calculating input event
>>>>>>>>>> timestamp:
>>>>>>>>>> jdk/src/windows/native/sun/windows/awt_Component.cpp:2100
>>>>>>>>>> Shortly the timestamp is calculated by the following formula:
>>>>>>>>>>     when = JVM_CurrentTimeMillis() - (GetTickCount() -
>>>>>>>>>> GetMessageTime())
>>>>>>>>>>
>>>>>>>>>> Where:
>>>>>>>>>>   JVM_CurrentTimeMillis() - the same as
>>>>>>>>>> System.currentTimeMillis()
>>>>>>>>>>   GetTickCount() - Win32 function, current millis from boot time
>>>>>>>>>>   GetMessageTime() - Win32 function, millis from boot time of
>>>>>>>>>> the latest native Message
>>>>>>>>>>
>>>>>>>>>> In theory the formula looks good: we are trying our best to
>>>>>>>>>> calculate the actual time of the OS message by taking the
>>>>>>>>>> current JVM time (JVM_CurrentTimeMillis) and adjusting it with
>>>>>>>>>> the offset (GetTickCount - GetMessageTime) which should indicate
>>>>>>>>>> how many milliseconds ago from the current moment (GetTickCount)
>>>>>>>>>> the message has been actually issued (GetMessageTime).
>>>>>>>>>> In practice due to usage of different system timers by the
>>>>>>>>>> JVM_CurrentTimeMillis and GetTickCount their values are not
>>>>>>>>>> updated synchronously and we may get an earlier timestamp for
>>>>>>>>>> the later event.
>>>>>>>>>>
>>>>>>>>>> *Fix*:
>>>>>>>>>> Just to use JVM_CurrentTimeMillis only as events timestamp. On
>>>>>>>>>> Mac this is done in exactly the same way:
>>>>>>>>>> CPlatformResponder.handleMouse/KeyEvent()
>>>>>>>>>>
>>>>>>>>>> The message time offset calculation has been introduced with the
>>>>>>>>>> fix for JDK-4434193
>>>>>>>>>> <https://bugs.openjdk.java.net/browse/JDK-4434193> and it seems
>>>>>>>>>> that the issue has addressed very similar problem (At times
>>>>>>>>>> getWhen()in ActionEvent returns higher value than the
>>>>>>>>>> CurrentSystemTime) which has not been completely resolved in
>>>>>>>>>> fact.
>>>>>>>>>> I also didn't find any benefits in using the existing approach:
>>>>>>>>>> - all the usages of the TimerHelper are in fact reduced to the
>>>>>>>>>> mentioned formula: when = JVM_CurrentTimeMillis() -
>>>>>>>>>> (GetTickCount() - GetMessageTime())
>>>>>>>>>> - GetMessageTime() always increases (except of the int overflow
>>>>>>>>>> moments), thus we couldn't get earlier OS messages after later
>>>>>>>>>> ones
>>>>>>>>>> - TimerHelper::windowsToUTC(DWORD windowsTime) doesn't guarantee
>>>>>>>>>> returning the same timestamp across different calls for the same
>>>>>>>>>> message time
>>>>>>>>>>
>>>>>>>>>> Thanks!
>>>>>>>>>> Anton.
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>

From alexandr.scherbatiy at oracle.com  Tue Jul 29 14:44:43 2014
From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy)
Date: Tue, 29 Jul 2014 18:44:43 +0400
Subject: <AWT Dev> [OpenJDK 2D-Dev] [9] Review request for 8029339
 Custom MultiResolution image support on HiDPI displays
In-Reply-To: <53BC0803.6090704@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>
Message-ID: <53D7B35B.1010703@oracle.com>


  Just friendly remainder.

  Thanks,
  Alexandr.


On 7/8/2014 7:02 PM, Alexander Scherbatiy wrote:
>
>
>   Hi Phil,
>
>   Could you review the fix?
>
>   Thanks,
>   Alexandr.
>
>
> 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 petr.pchelko at oracle.com  Tue Jul 29 16:13:13 2014
From: petr.pchelko at oracle.com (Petr Pchelko)
Date: Tue, 29 Jul 2014 20:13:13 +0400
Subject: <AWT Dev> [8] Review request for 8046495: KeyEvent can not be
	accepted in quick mouse clicking
In-Reply-To: <53D786EC.2040109@oracle.com>
References: <53B2EDEA.3010402@oracle.com>
	<B4A1F8A6-25D8-4CA2-A138-95EC14A6A881@oracle.com>
	<53B413A7.4000809@oracle.com> <53B4253A.3040406@oracle.com>
	<53B42689.4090709@oracle.com>
	<59E88D9A-2BF9-41CF-9128-5E5A83B39EF3@oracle.com>
	<53C793F9.6010703@oracle.com> <53C8F6B2.7020008@oracle.com>
	<53D113C0.9030808@oracle.com> <53D1266E.3080708@oracle.com>
	<53D786EC.2040109@oracle.com>
Message-ID: <E9ABFD44-7384-4F4F-9DAF-A895143D3855@oracle.com>

Hello, Anton.

The fix looks good to me.

With best regards. Petr.

> On Jul 29, 2014, at 3:35 PM, Artem Ananiev <artem.ananiev at oracle.com> wrote:
> 
> Hi, Anton,
> 
> 8u backport looks fine.
> 
> Thanks,
> 
> Artem
> 
> On 7/24/2014 7:29 PM, anton nashatyrev wrote:
>> Hello,
>> 
>>     Artem, Petr, thanks for the fix discussion and review!
>> 
>>     could you please review the backport to 8u-dev now?
>> 
>>     It is a little bit more conservative variant of the fix to jdk9 and
>> was originally proposed for jdk9 as is.
>> 
>> Webrev: http://cr.openjdk.java.net/%7Eanashaty/8046495/8/webrev.00/
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8046495
>> 
>> Thank you!
>> Anton.
>> 
>> 
>> On 24.07.2014 18:10, Artem Ananiev wrote:
>>> 
>>> On 7/18/2014 2:28 PM, anton nashatyrev wrote:
>>>> Hello,
>>>> 
>>>>     in offline discussion with Artem and Petr we decided to further
>>>> clean up the code and completely remove TimeHelper functions from
>>>> awt_Component.cpp in JDK9.
>>>> 
>>>>     Could you please review the updated fix:
>>>> http://cr.openjdk.java.net/~anashaty/8046495/9/webrev.01/
>>>> <http://cr.openjdk.java.net/%7Eanashaty/8046495/9/webrev.01/>
>>> 
>>> Looks fine to me.
>>> 
>>> Thanks,
>>> 
>>> Artem
>>> 
>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8046495
>>>> 
>>>> Thank you!
>>>> Anton.
>>>> 
>>>> On 17.07.2014 13:14, anton nashatyrev wrote:
>>>>> Hello All,
>>>>> 
>>>>>    could please anyone else take a look at the fix?
>>>>> 
>>>>> Thanks!
>>>>> Anton.
>>>>> 
>>>>> On 02.07.2014 19:37, Petr Pchelko wrote:
>>>>>> Hello, Anton.
>>>>>> 
>>>>>> Thanks for clarifications and additional testing.
>>>>>> The fix looks good to me too.
>>>>>> 
>>>>>> With best regards. Petr.
>>>>>> 
>>>>>> On 02 ???? 2014 ?., at 19:34, Anton V. Tarasov
>>>>>> <anton.tarasov at oracle.com <mailto:anton.tarasov at oracle.com>> wrote:
>>>>>> 
>>>>>>> On 02.07.2014 19:28, anton nashatyrev wrote:
>>>>>>>> Hello, Anton
>>>>>>>> 
>>>>>>>> On 02.07.2014 18:13, Anton V. Tarasov wrote:
>>>>>>>>> On 02.07.2014 11:44, Petr Pchelko wrote:
>>>>>>>>>> Hello, Anton.
>>>>>>>>>> 
>>>>>>>>>> I'm not sure I have a detailed understanding of what's happening.
>>>>>>>>>> 
>>>>>>>>>> Before your fix the timestamp of the event represented the time
>>>>>>>>>> when the event was created, and now it's the time when it's sent
>>>>>>>>>> to java.
>>>>>>>>>> This might be important if some events cause other events to be
>>>>>>>>>> issued on the java side.
>>>>>>>>>> 
>>>>>>>>>> So suppose the following:
>>>>>>>>>> Toolkit thread: InputEvent#1 created      - timestamp 0
>>>>>>>>>> Toolkit thread: InputEvent#2 created      - timestamp 1
>>>>>>>>>> Toolkit thread: InputEvent#1 sent           - timestamp 2
>>>>>>>>>> EDT: InputEvent#1 dispatched - timestamp 3
>>>>>>>>>> EDT:               FocusEvent  created  - timestamp 4
>>>>>>>>>> Toolkit thread: InputEvent#2 sent           - timestamp 5
>>>>>>>>>> 
>>>>>>>>>> Before you fix we had the following event order:
>>>>>>>>>> InputEvent#1(ts=0), InputEvent#2(ts=1), FocusEvent(ts=4).
>>>>>>>>>> But after your fix we will have a different order:
>>>>>>>>>> InputEvent#1(ts=2), FocusEvent(ts=4), InputEvent#2(ts=5).
>>>>>>>>>> So now we would have troubles, because the Input Event will go to
>>>>>>>>>> the new focused component instead of the old one.
>>>>>>>>>> Do you think that my arguments are correct? I understand that the
>>>>>>>>>> likelihood of such a situation is very low, but for me it looks
>>>>>>>>>> possible? Am I missing something?
>>>>>>>>> 
>>>>>>>>> A timestamp for a FocusEvent is taken from
>>>>>>>>> the_most_recent_KeyEvent_time which is set on EDT when the event
>>>>>>>>> is dispatched. So the fix shouldn't affect it.
>>>>>>>>> 
>>>>>>>>> Also, in awt_Window.cpp, when a TimedWindowEvent is created it is
>>>>>>>>> passed a timestamp got with TimeHelper::getMessageTimeUTC(). It
>>>>>>>>> appears, that the fix makes key events times even more consistent
>>>>>>>>> with it. So, from the kbd focus perspective, it shouldn't make any
>>>>>>>>> harm.
>>>>>>>>> 
>>>>>>>>> Anton, could you just please run the following tests, at least:
>>>>>>>>> 
>>>>>>>>> test/java/awt/Focus/6981400/*
>>>>>>>>> test/java/awt/KeyboardFocusManager/TypeAhead/*
>>>>>>>> 
>>>>>>>> I've tested with the following set:
>>>>>>>> [closed]/java/awt/event/*
>>>>>>>> [closed]/java/awt/Focus/*
>>>>>>>> [closed]java/awt/KeyboardFocusManager/*
>>>>>>>> 
>>>>>>>> : no unexpected failures here.
>>>>>>>> 
>>>>>>>> I've also verified that my regression test which comes with the fix
>>>>>>>> works fine on Linux and Mac (despite the fix is Win specific).
>>>>>>> 
>>>>>>> Great, thanks!
>>>>>>> 
>>>>>>> Anton.
>>>>>>> 
>>>>>>>> 
>>>>>>>> Thanks for review!
>>>>>>>> Anton.
>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> Thanks,
>>>>>>>>> Anton.
>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> Another thing I do not understand is why we were used to use the
>>>>>>>>>> complicated formula instead of initializing the msg.time field
>>>>>>>>>> with the JVM current time and using it when sending the event?
>>>>>>>>>> Wouldn't that resolve both your issue and the issue the original
>>>>>>>>>> fix was made for?
>>>>>>>>>> 
>>>>>>>>>> I have a couple of comments about the code, but let's postpone
>>>>>>>>>> that until we decide on the approach.
>>>>>>>>>> 
>>>>>>>>>> Thank you.
>>>>>>>>>> With best regards. Petr.
>>>>>>>>>> 
>>>>>>>>>> On 01 ???? 2014 ?., at 21:20, anton nashatyrev
>>>>>>>>>> <anton.nashatyrev at oracle.com
>>>>>>>>>> <mailto:anton.nashatyrev at oracle.com>> wrote:
>>>>>>>>>> 
>>>>>>>>>>> Hello,
>>>>>>>>>>>    could you please review the following fix:
>>>>>>>>>>> 
>>>>>>>>>>> fix: http://cr.openjdk.java.net/~anashaty/8046495/9/webrev.00/
>>>>>>>>>>> <http://cr.openjdk.java.net/%7Eanashaty/8046495/9/webrev.00/>
>>>>>>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8046495
>>>>>>>>>>> 
>>>>>>>>>>> *Problem:*
>>>>>>>>>>> On Windows the later InputEvent may have earlier timestamp
>>>>>>>>>>> (getWhen()), which results in incorrect processing of enqueued
>>>>>>>>>>> input events and may also potentially be the reason of other
>>>>>>>>>>> artifacts
>>>>>>>>>>> 
>>>>>>>>>>> *Evaluation*:
>>>>>>>>>>> On Windows we have some algorithm for calculating input event
>>>>>>>>>>> timestamp:
>>>>>>>>>>> jdk/src/windows/native/sun/windows/awt_Component.cpp:2100
>>>>>>>>>>> Shortly the timestamp is calculated by the following formula:
>>>>>>>>>>>    when = JVM_CurrentTimeMillis() - (GetTickCount() -
>>>>>>>>>>> GetMessageTime())
>>>>>>>>>>> 
>>>>>>>>>>> Where:
>>>>>>>>>>>  JVM_CurrentTimeMillis() - the same as
>>>>>>>>>>> System.currentTimeMillis()
>>>>>>>>>>>  GetTickCount() - Win32 function, current millis from boot time
>>>>>>>>>>>  GetMessageTime() - Win32 function, millis from boot time of
>>>>>>>>>>> the latest native Message
>>>>>>>>>>> 
>>>>>>>>>>> In theory the formula looks good: we are trying our best to
>>>>>>>>>>> calculate the actual time of the OS message by taking the
>>>>>>>>>>> current JVM time (JVM_CurrentTimeMillis) and adjusting it with
>>>>>>>>>>> the offset (GetTickCount - GetMessageTime) which should indicate
>>>>>>>>>>> how many milliseconds ago from the current moment (GetTickCount)
>>>>>>>>>>> the message has been actually issued (GetMessageTime).
>>>>>>>>>>> In practice due to usage of different system timers by the
>>>>>>>>>>> JVM_CurrentTimeMillis and GetTickCount their values are not
>>>>>>>>>>> updated synchronously and we may get an earlier timestamp for
>>>>>>>>>>> the later event.
>>>>>>>>>>> 
>>>>>>>>>>> *Fix*:
>>>>>>>>>>> Just to use JVM_CurrentTimeMillis only as events timestamp. On
>>>>>>>>>>> Mac this is done in exactly the same way:
>>>>>>>>>>> CPlatformResponder.handleMouse/KeyEvent()
>>>>>>>>>>> 
>>>>>>>>>>> The message time offset calculation has been introduced with the
>>>>>>>>>>> fix for JDK-4434193
>>>>>>>>>>> <https://bugs.openjdk.java.net/browse/JDK-4434193> and it seems
>>>>>>>>>>> that the issue has addressed very similar problem (At times
>>>>>>>>>>> getWhen()in ActionEvent returns higher value than the
>>>>>>>>>>> CurrentSystemTime) which has not been completely resolved in
>>>>>>>>>>> fact.
>>>>>>>>>>> I also didn't find any benefits in using the existing approach:
>>>>>>>>>>> - all the usages of the TimerHelper are in fact reduced to the
>>>>>>>>>>> mentioned formula: when = JVM_CurrentTimeMillis() -
>>>>>>>>>>> (GetTickCount() - GetMessageTime())
>>>>>>>>>>> - GetMessageTime() always increases (except of the int overflow
>>>>>>>>>>> moments), thus we couldn't get earlier OS messages after later
>>>>>>>>>>> ones
>>>>>>>>>>> - TimerHelper::windowsToUTC(DWORD windowsTime) doesn't guarantee
>>>>>>>>>>> returning the same timestamp across different calls for the same
>>>>>>>>>>> message time
>>>>>>>>>>> 
>>>>>>>>>>> Thanks!
>>>>>>>>>>> Anton.
>>>>>>>>>> 
>>>>>>>>> 
>>>>>>>> 
>>>>>>> 
>>>>>> 
>>>>> 
>>>> 
>> 


From yuri.nesterenko at oracle.com  Wed Jul 30 06:54:14 2014
From: yuri.nesterenko at oracle.com (Yuri Nesterenko)
Date: Wed, 30 Jul 2014 10:54:14 +0400
Subject: <AWT Dev> [9] Review request for 8053657: [TEST_BUG] move some 5
 tests related to undecorated Frame/JFrame to JDK
Message-ID: <53D89696.5070602@oracle.com>

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  Wed Jul 30 11:00:44 2014
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Wed, 30 Jul 2014 15:00:44 +0400
Subject: <AWT Dev> [8u] Review request: 8048549 [macosx] Disable usage
 of system menu bar if AWT is embedded in FX
In-Reply-To: <B64678DC-9F96-4CFE-ACBA-42FD25E2F74E@oracle.com>
References: <AD884FF4-43D5-48B7-B150-A4BE1DD79830@oracle.com>
	<53C51BB9.2060205@oracle.com>
	<B64678DC-9F96-4CFE-ACBA-42FD25E2F74E@oracle.com>
Message-ID: <53D8D05C.7070602@oracle.com>

Hi, Petr.
The fix looks good.

On 7/23/14 5:14 PM, Petr Pchelko wrote:
> Hello, AWT Team.
>
> This is a reminder.
> Could you please review the backport.
>
> Thank you.
> With best regards. Petr.
>
> On 15 ???? 2014 ?., at 16:16, Anthony Petrov <anthony.petrov at oracle.com> wrote:
>
>> +1
>>
>> --
>> best regards,
>> Anthony
>>
>> On 7/15/2014 2:01 PM, Petr Pchelko wrote:
>>> Hello, AWT team.
>>>
>>> Please review the fix for the issue:
>>> https://bugs.openjdk.java.net/browse/JDK-8048549
>>> The 8u version is available here:
>>> http://cr.openjdk.java.net/~pchelko/9/8048549/webrev.8u/
>>> For reference, the 9 version is available here:
>>> http://cr.openjdk.java.net/~pchelko/9/8048549/webrev/
>>>
>>> The 8u version is different, so a new review is needed. In 9 we've moved AWT initialization from awt.m to LWCToolkit.m, so we did not need to use ThreadUtilities.
>>> In 8u we need to use ThreadUtilities to figure out if AWT is running embedded or not. All the rest of the fix is the same as in 9.
>>>
>>> Thank you.
>>> With best regards. Petr.
>>>


-- 
Best regards, Sergey.


From dmitriy.ermashov at oracle.com  Thu Jul 31 13:47:32 2014
From: dmitriy.ermashov at oracle.com (Dmitriy Ermashov)
Date: Thu, 31 Jul 2014 17:47:32 +0400
Subject: <AWT Dev> Review Request for 8051716: Move AWT_BAT functional
 tests to OpenJDK (1 of 3)
In-Reply-To: <53D64038.5040307@oracle.com>
References: <53D64038.5040307@oracle.com>
Message-ID: <53DA48F4.1070405@oracle.com>

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
>