From Sergey.Bylokhov at oracle.com  Mon Jun  2 09:10:48 2014
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Mon, 02 Jun 2014 13:10:48 +0400
Subject: <AWT Dev> [9] Review Request: JDK-8043513
 Clipboard#getContents(Object) throws IOException
In-Reply-To: <537E6A10.6010105@oracle.com>
References: <A420BD7C-0CF1-4BE8-B115-D52921055B84@oracle.com>
	<537DC5CB.2010203@oracle.com> <537E457E.8070703@oracle.com>
	<3D901DC1-EC3C-4975-9510-E2BADF8E309A@oracle.com>
	<537E6397.9050003@oracle.com>
	<44669C23-99E8-40F8-9282-9932C0EE17FA@oracle.com>
	<537E68DE.7060605@oracle.com>
	<C4E00993-F50E-492D-9F88-1811CCCC32D2@oracle.com>
	<537E6A10.6010105@oracle.com>
Message-ID: <538C3F98.2010307@oracle.com>

Hi, Petr.
The fix looks good to me too.

On 5/23/14 1:20 AM, Anthony Petrov wrote:
> Thanks, Petr. The fix for the stack trace issue still looks fine to me.
>
> -- 
> best regards,
> Anthony
>
> On 5/23/2014 1:19 AM, Petr Pchelko wrote:
>>> Closing this bug as Cannot Reproduce sounds like a good idea to me 
>>> because we'll be able to re-open it if someone reproduces the issue 
>>> again in the future.
>> I have filed https://bugs.openjdk.java.net/browse/JDK-8043807 for 
>> incorrect stack trace issue. This fix will go under that bug ID.
>> The original bug will be closed a cannot reproduce.
>>
>> With best regards. Petr.
>>
>> On May 23, 2014, at 1:15 AM, Anthony Petrov 
>> <anthony.petrov at oracle.com> wrote:
>>
>>> Closing this bug as Cannot Reproduce sounds like a good idea to me 
>>> because we'll be able to re-open it if someone reproduces the issue 
>>> again in the future.
>>>
>>> -- 
>>> best regards,
>>> Anthony
>>>
>>> On 5/23/2014 1:01 AM, Petr Pchelko wrote:
>>>>> If I disable clipboard sharing in RDP it works without problems.
>>>>>> If I copy something into the clipboard after establishing the 
>>>>>> connection but before invoking the code it works without problems.
>>>>>
>>>>> Petr, do you have any comments about this? Perhaps we should fix 
>>>>> the stack trace origin issue under a separate bug id, and leave 
>>>>> this bug open to address the original clipboard-shared-over-RDP 
>>>>> issue?
>>>> I couldn?t reproduce this although I?ve tried really hard. I can 
>>>> fix stack trace origin under separate bugId, but this one I?m going 
>>>> close as cannot reproduce anyway.
>>>>
>>>> More that that, looking at the code which throws the IOException I 
>>>> would say that this is more likely an RDP-client bug, not our bug. 
>>>> All we do here is call winapi function ::EnumClipboardFormats to 
>>>> get all available format and then call ::GetClipboardData for each 
>>>> format from that list. No place for a bug left here..
>>>>
>>>> With best regards. Petr.
>>>>
>>>> On May 23, 2014, at 12:52 AM, Anthony Petrov 
>>>> <anthony.petrov at oracle.com> wrote:
>>>>
>>>>> Interesting. I took a closer look at the bug report and found this:
>>>>>
>>>>>> If I disable clipboard sharing in RDP it works without problems.
>>>>>> If I copy something into the clipboard after establishing the 
>>>>>> connection but before invoking the code it works without problems.
>>>>>
>>>>> Petr, do you have any comments about this? Perhaps we should fix 
>>>>> the stack trace origin issue under a separate bug id, and leave 
>>>>> this bug open to address the original clipboard-shared-over-RDP 
>>>>> issue?
>>>>>
>>>>> -- 
>>>>> best regards,
>>>>> Anthony
>>>>>
>>>>> On 5/22/2014 11:44 PM, Petr Pchelko wrote:
>>>>>> Hello, Sergey.
>>>>>>
>>>>>>> Submitter complains about IOException itself, not about 
>>>>>>> incorrect stack trace.
>>>>>> The IOException is fine.
>>>>>> It?s thrown from a different method (not as the stacktace states) 
>>>>>> and it?s OK by documentation.
>>>>>> Just the stack trace is ?wrong?.
>>>>>> We can?t fix the IOException, because the clipboard was not ready 
>>>>>> and we can?t do anything about it.
>>>>>>
>>>>>> With best regards. Petr.
>>>>>> On May 22, 2014, at 10:44 PM, Sergey Bylokhov 
>>>>>> <Sergey.Bylokhov at oracle.com> wrote:
>>>>>>
>>>>>>> Hi, Petr.
>>>>>>> Submitter complains about IOException itself, not about 
>>>>>>> incorrect stack trace.
>>>>>>>
>>>>>>> On 5/22/14 1:39 PM, Anthony Petrov wrote:
>>>>>>>> Looks fine.
>>>>>>>>
>>>>>>>> -- 
>>>>>>>> best regards,
>>>>>>>> Anthony
>>>>>>>>
>>>>>>>> On 5/21/2014 4:27 PM, Petr Pchelko wrote:
>>>>>>>>> Hello, AWT Team.
>>>>>>>>>
>>>>>>>>> Please review the fox for the issue:
>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8043513
>>>>>>>>> The fix is available at:
>>>>>>>>> http://cr.openjdk.java.net/~pchelko/9/8043513/webrev/
>>>>>>>>>
>>>>>>>>> The problem:
>>>>>>>>> When we fetch all contents from the clipboard we catch 
>>>>>>>>> IOException and store it for later.
>>>>>>>>> In case we would then need the data which caused the exception 
>>>>>>>>> the cached exception would be rethrown.
>>>>>>>>> But the stack trace shows where the exception was created, not 
>>>>>>>>> thrown. Wrapping it helps to
>>>>>>>>> eliminate the misunderstanding.
>>>>>>>>>
>>>>>>>>> With best regards. Petr.
>>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> -- 
>>>>>>> Best regards, Sergey.
>>>>>>>
>>>>>>
>>>>
>>


-- 
Best regards, Sergey.


From Sergey.Bylokhov at oracle.com  Mon Jun  2 09:15:16 2014
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Mon, 02 Jun 2014 13:15:16 +0400
Subject: <AWT Dev> [9] Review Request: 8043979 Javadoc cleanup of
 javax.sound.sampled package
Message-ID: <538C40A4.6020503@oracle.com>

Hello.
Please review another one javadoc "weekend 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.
  - Description of the class/method/field should be followed by dot.
  - Broken links or typos should be fixed (ex. 
http://cr.openjdk.java.net/~serb/8043979/specdiff/FloatControl-report.html#method:getMaxLabel())

See the full specdiff: 
http://cr.openjdk.java.net/~serb/8043979/specdiff/package-summary.html

  - some broken merges from 1999(!!!) were fixed(ex. 
http://cr.openjdk.java.net/~serb/8043979/webrev.00/src/share/classes/javax/sound/sampled/LineListener.java.udiff.html)
  - 80 column limit.
  - empty line after description/before the first tag.
  - sets of spaces in the middle of text were deleted.
  - @param, @throws, @return now align, to be more readable.
  - <tag> should be replaced by {@tag }.
  - unnecessary imports should be removed.
  - @see tags can be simplified in some places.
  - unnecessary spaces and lines can be removed.
  - @Override should be added when necessary.

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

-- 
Best regards, Sergey.


From petr.pchelko at oracle.com  Mon Jun  2 09:42:43 2014
From: petr.pchelko at oracle.com (Petr Pchelko)
Date: Mon, 2 Jun 2014 13:42:43 +0400
Subject: <AWT Dev> [9] Review Request: 8043979 Javadoc cleanup of
	javax.sound.sampled package
In-Reply-To: <538C40A4.6020503@oracle.com>
References: <538C40A4.6020503@oracle.com>
Message-ID: <8E847912-C500-4E85-A225-2FBB5760823F@oracle.com>

Hello, Sergey.

The fix looks good to me.

With best regards. Petr.

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

> Hello.
> Please review another one javadoc "weekend 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.
> - Description of the class/method/field should be followed by dot.
> - Broken links or typos should be fixed (ex. http://cr.openjdk.java.net/~serb/8043979/specdiff/FloatControl-report.html#method:getMaxLabel())
> 
> See the full specdiff: http://cr.openjdk.java.net/~serb/8043979/specdiff/package-summary.html
> 
> - some broken merges from 1999(!!!) were fixed(ex. http://cr.openjdk.java.net/~serb/8043979/webrev.00/src/share/classes/javax/sound/sampled/LineListener.java.udiff.html)
> - 80 column limit.
> - empty line after description/before the first tag.
> - sets of spaces in the middle of text were deleted.
> - @param, @throws, @return now align, to be more readable.
> - <tag> should be replaced by {@tag }.
> - unnecessary imports should be removed.
> - @see tags can be simplified in some places.
> - unnecessary spaces and lines can be removed.
> - @Override should be added when necessary.
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8043979
> Webrev can be found at: http://cr.openjdk.java.net/~serb/8043979/webrev.00
> 
> -- 
> Best regards, Sergey.
> 


From dmitriy.ermashov at oracle.com  Mon Jun  2 12:41:56 2014
From: dmitriy.ermashov at oracle.com (Dmitriy Ermashov)
Date: Mon, 02 Jun 2014 16:41:56 +0400
Subject: <AWT Dev> Review Request for 8041915: Move 8 awt tests to
 OpenJDK regression tests tree
In-Reply-To: <53887569.4080209@oracle.com>
References: <535A5D73.4090002@oracle.com>	<0F2D6903-0F7C-45EA-88C4-1FE9852AA69D@oracle.com>	<535F839C.2080408@oracle.com>	<5A688155-BE6C-4893-A8A7-29CF5413BDF1@oracle.com>	<5370AD8A.8070609@oracle.com>
	<53830C49.70402@oracle.com>	<538315BD.30406@oracle.com>
	<53831913.9030604@oracle.com> <53832DD9.6080201@oracle.com>
	<53833D7D.6030906@oracle.com> <53887569.4080209@oracle.com>
Message-ID: <538C7114.8020701@oracle.com>

On 30.05.2014 16:11, Sergey Bylokhov wrote:
> On 26.05.2014 17:11, Dmitriy Ermashov wrote:
>>
>> On 05/26/2014 04:04 PM, Sergey Bylokhov wrote:
>>> Hi, Dmitriy.
>>> One of the test has incorrect copyright:
>>>
>>>   23 /*
>>>   24  * Copyright (c) 2011, Oracle and/or its affiliates. All rights 
>>> reserved.
>>>   25  * ORACLE PROPRIETARY/CONFIDENTIAL. Use is subject to license 
>>> terms.
>>>   26  */
>> Changes are already pushed. Will create new bug to fix it soon.
>>> I was thinking that the author of these tests is Alexander 
>>> Kouznetsov, no?
>> Sure, but tests of AWT_ShapedAndTranslucentWindows group were fully 
>> rewritten and hardly look like their functional analogues now. So 
>> I've marked them as written by me.
> You can add additional @author tag if you wish.
> Actually you said nothing about reworking in the initial review 
> request. I just compare test before/after and have a question about 
> capure screen functionality, why it was removed? It was useful in bug 
> evaluation.
All unnecessary functionality have been deleted from tests to make them 
as simple as possible. Also tests are much more stable now, and if a bug 
will occur it will be pretty simple to reproduce it.
> Also please do not remove detailed description of the test like it was 
> done in FocusAWTTest.java
I believe I can restore detailed description and @author tag in fix of 
https://bugs.openjdk.java.net/browse/JDK-8043972
-dima
>> Thanks for review!
>> -dima
>>> On 26.05.2014 14:36, Dmitriy Ermashov wrote:
>>>> Thanks for review!
>>>> -dima
>>>>
>>>> On 05/26/2014 02:21 PM, Alexander Scherbatiy wrote:
>>>>>
>>>>>   The fix looks good for me.
>>>>>
>>>>>   Thanks,
>>>>>   Alexandr.
>>>>>
>>>>> On 5/26/2014 1:41 PM, Dmitriy Ermashov wrote:
>>>>>> Hi,
>>>>>>
>>>>>> I still have no second successful review..
>>>>>> Could you please look at the fix of
>>>>>> https://bugs.openjdk.java.net/browse/JDK-8041915
>>>>>>
>>>>>> Webrev is here:
>>>>>> http://cr.openjdk.java.net/~yan/8041915/webrev.01/
>>>>>>
>>>>>> It is a part of test colocation.
>>>>>>
>>>>>> Thanks,
>>>>>> Dima
>>>>>>
>>>>>> On 05/12/2014 03:16 PM, Dmitriy Ermashov wrote:
>>>>>>> Petr, thanks for review.
>>>>>>>
>>>>>>> Guys, could you please also review the changeset?
>>>>>>> Webrev is here:
>>>>>>> http://cr.openjdk.java.net/~yan/8041915/webrev.01/
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Dima
>>>>>>>
>>>>>>> On 29.04.2014 15:08, Petr Pchelko wrote:
>>>>>>>> Hello, Dmitriy.
>>>>>>>>
>>>>>>>> The new version looks good.
>>>>>>>>
>>>>>>>> With best regards. Petr.
>>>>>>>>
>>>>>>>> On 29.04.2014, at 14:49, Dmitriy Ermashov 
>>>>>>>> <dmitriy.ermashov at oracle.com> wrote:
>>>>>>>>
>>>>>>>>> Hi,
>>>>>>>>>
>>>>>>>>> Please review the changeset for
>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8041915
>>>>>>>>>
>>>>>>>>> Webrev is here:
>>>>>>>>> http://cr.openjdk.java.net/~yan/8041915/webrev.01/
>>>>>>>>>
>>>>>>>>> Latest changes:
>>>>>>>>> 1. If some translucency mode is not supported, the test will 
>>>>>>>>> pass with System.out warning message
>>>>>>>>> 2. New method dragAndDrop implemented in ExtendedRobot class
>>>>>>>>>
>>>>>>>>> Thanks,
>>>>>>>>> Dima
>>>>>>>>>
>>>>>>>>> On 04/25/2014 05:19 PM, Petr Pchelko wrote:
>>>>>>>>>> Hello, Dmitriy.
>>>>>>>>>>
>>>>>>>>>> A couple of questions:
>>>>>>>>>>
>>>>>>>>>> 1. checkTranslucencyMode throws an exception if some mode is 
>>>>>>>>>> not supported on the device, so the test would fail. Should 
>>>>>>>>>> it? Normally we just skip the test if some capability is absent.
>>>>>>>>>> 2. Didn't you consider moving the drag method into the 
>>>>>>>>>> ExtendedRobot? I expect it to be very commonly used.
>>>>>>>>>>
>>>>>>>>>> With best regards. Petr.
>>>>>>>>>>
>>>>>>>>>> On 25.04.2014, at 17:04, Dmitriy Ermashov 
>>>>>>>>>> <dmitriy.ermashov at oracle.com> wrote:
>>>>>>>>>>
>>>>>>>>>>> Hi,
>>>>>>>>>>>
>>>>>>>>>>> Please review the changeset for
>>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8041915
>>>>>>>>>>>
>>>>>>>>>>> Webrev is here:
>>>>>>>>>>> http://cr.openjdk.java.net/~yan/8041915/webrev.00/
>>>>>>>>>>>
>>>>>>>>>>> -- 
>>>>>>>>>>> Thanks,
>>>>>>>>>>> Dima
>>>>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>>
>>
>
>


From petr.pchelko at oracle.com  Mon Jun  2 12:50:39 2014
From: petr.pchelko at oracle.com (Petr Pchelko)
Date: Mon, 2 Jun 2014 16:50:39 +0400
Subject: <AWT Dev> [9] Review Request: 8044516 [macosx] ScreenPopupFactory
	uses native method that could be avoided
Message-ID: <A7715964-72E8-4957-A0B9-C61BF35D0830@oracle.com>

Hello, AWT Team.

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

No need to go through native to call a method. Accessor pattern works 
fine here, so we can avoid loading a native library.

Thank you.
With best regards. Petr.

From Sergey.Bylokhov at oracle.com  Mon Jun  2 12:54:25 2014
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Mon, 02 Jun 2014 16:54:25 +0400
Subject: <AWT Dev> [9] Review Request: 8044516 [macosx]
 ScreenPopupFactory uses native method that could be avoided
In-Reply-To: <A7715964-72E8-4957-A0B9-C61BF35D0830@oracle.com>
References: <A7715964-72E8-4957-A0B9-C61BF35D0830@oracle.com>
Message-ID: <538C7401.7040801@oracle.com>

Hi, Petr.
Should we use getPopup() name, since it should be simple accessor?

On 6/2/14 4:50 PM, Petr Pchelko wrote:
> Hello, AWT Team.
>
> Please review a simple cleanup fix for the issue:
> https://bugs.openjdk.java.net/browse/JDK-8044516
> The fix is available at:
> http://cr.openjdk.java.net/~pchelko/9/8044516/webrev/
>
> No need to go through native to call a method. Accessor pattern works
> fine here, so we can avoid loading a native library.
>
> Thank you.
> With best regards. Petr.


-- 
Best regards, Sergey.

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

From petr.pchelko at oracle.com  Mon Jun  2 13:03:48 2014
From: petr.pchelko at oracle.com (Petr Pchelko)
Date: Mon, 2 Jun 2014 17:03:48 +0400
Subject: <AWT Dev> [9] Review Request: 8044516 [macosx]
	ScreenPopupFactory uses native method that could be avoided
In-Reply-To: <538C7401.7040801@oracle.com>
References: <A7715964-72E8-4957-A0B9-C61BF35D0830@oracle.com>
	<538C7401.7040801@oracle.com>
Message-ID: <88DA5BEA-3453-4517-AC41-3213A2D72AF1@oracle.com>

Hello, Sergey.

> Should we use getPopup() name, since it should be simple accessor?
I thought about it. The HEAVYWEIGHT_POPUP constant is package-private, so if we use 
simple getPopup we would need a second method "getHeavyweightPopupType". So I was
not quite sure which is better - use 2 methods or merge them in a single one. I can change
it if you think 2 methods would be better.

With best regards. Petr.

On 02 ???? 2014 ?., at 16:54, Sergey Bylokhov <Sergey.Bylokhov at oracle.com> wrote:

> Hi, Petr.
> Should we use getPopup() name, since it should be simple accessor?
> 
> On 6/2/14 4:50 PM, Petr Pchelko wrote:
>> Hello, AWT Team.
>> 
>> Please review a simple cleanup fix for the issue:
>> https://bugs.openjdk.java.net/browse/JDK-8044516
>> The fix is available at:
>> http://cr.openjdk.java.net/~pchelko/9/8044516/webrev/
>> 
>> No need to go through native to call a method. Accessor pattern works 
>> fine here, so we can avoid loading a native library.
>> 
>> Thank you.
>> With best regards. Petr.
> 
> 
> -- 
> Best regards, Sergey. 

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

From Sergey.Bylokhov at oracle.com  Mon Jun  2 13:13:58 2014
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Mon, 02 Jun 2014 17:13:58 +0400
Subject: <AWT Dev> [9] Review Request: 8044516 [macosx]
 ScreenPopupFactory uses native method that could be avoided
In-Reply-To: <88DA5BEA-3453-4517-AC41-3213A2D72AF1@oracle.com>
References: <A7715964-72E8-4957-A0B9-C61BF35D0830@oracle.com>
	<538C7401.7040801@oracle.com>
	<88DA5BEA-3453-4517-AC41-3213A2D72AF1@oracle.com>
Message-ID: <538C7896.1040208@oracle.com>

On 6/2/14 5:03 PM, Petr Pchelko wrote:
> Hello, Sergey.
>
>> Should we use getPopup() name, since it should be simple accessor?
> I thought about it. The HEAVYWEIGHT_POPUP constant is package-private, 
> so if we use
> simple getPopup we would need a second method 
> "getHeavyweightPopupType". So I was
> not quite sure which is better - use 2 methods or merge them in a 
> single one. I can change
> it if you think 2 methods would be better.
Then why do not call PopupFactory.getHeavyWeightPopup() directly?
>
> With best regards. Petr.
>
> On 02 ???? 2014 ?., at 16:54, Sergey Bylokhov 
> <Sergey.Bylokhov at oracle.com <mailto:Sergey.Bylokhov at oracle.com>> wrote:
>
>> Hi, Petr.
>> Should we use getPopup() name, since it should be simple accessor?
>>
>> On 6/2/14 4:50 PM, Petr Pchelko wrote:
>>> Hello, AWT Team.
>>>
>>> Please review a simple cleanup fix for the issue:
>>> https://bugs.openjdk.java.net/browse/JDK-8044516
>>> The fix is available at:
>>> http://cr.openjdk.java.net/~pchelko/9/8044516/webrev/
>>>
>>> No need to go through native to call a method. Accessor pattern works
>>> fine here, so we can avoid loading a native library.
>>>
>>> Thank you.
>>> 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/20140602/daf0d489/attachment.html>

From Sergey.Bylokhov at oracle.com  Mon Jun  2 13:20:24 2014
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Mon, 02 Jun 2014 17:20:24 +0400
Subject: <AWT Dev> [9] Review Request: 8044516 [macosx]
 ScreenPopupFactory uses native method that could be avoided
In-Reply-To: <538C7896.1040208@oracle.com>
References: <A7715964-72E8-4957-A0B9-C61BF35D0830@oracle.com>
	<538C7401.7040801@oracle.com>
	<88DA5BEA-3453-4517-AC41-3213A2D72AF1@oracle.com>
	<538C7896.1040208@oracle.com>
Message-ID: <538C7A18.20906@oracle.com>

On 6/2/14 5:13 PM, Sergey Bylokhov wrote:
> On 6/2/14 5:03 PM, Petr Pchelko wrote:
>> Hello, Sergey.
>>
>>> Should we use getPopup() name, since it should be simple accessor?
>> I thought about it. The HEAVYWEIGHT_POPUP constant is 
>> package-private, so if we use
>> simple getPopup we would need a second method 
>> "getHeavyweightPopupType". So I was
>> not quite sure which is better - use 2 methods or merge them in a 
>> single one. I can change
>> it if you think 2 methods would be better.
> Then why do not call PopupFactory.getHeavyWeightPopup() directly?
Look like getPopup() covers headless situation as well. Then the fix 
looks good.
Thanks.
>>
>> With best regards. Petr.
>>
>> On 02 ???? 2014 ?., at 16:54, Sergey Bylokhov 
>> <Sergey.Bylokhov at oracle.com <mailto:Sergey.Bylokhov at oracle.com>> wrote:
>>
>>> Hi, Petr.
>>> Should we use getPopup() name, since it should be simple accessor?
>>>
>>> On 6/2/14 4:50 PM, Petr Pchelko wrote:
>>>> Hello, AWT Team.
>>>>
>>>> Please review a simple cleanup fix for the issue:
>>>> https://bugs.openjdk.java.net/browse/JDK-8044516
>>>> The fix is available at:
>>>> http://cr.openjdk.java.net/~pchelko/9/8044516/webrev/
>>>>
>>>> No need to go through native to call a method. Accessor pattern works
>>>> fine here, so we can avoid loading a native library.
>>>>
>>>> Thank you.
>>>> With best regards. Petr.
>>>
>>>
>>> -- 
>>> 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/20140602/778a9707/attachment.html>

From petr.pchelko at oracle.com  Tue Jun  3 11:18:57 2014
From: petr.pchelko at oracle.com (Petr Pchelko)
Date: Tue, 3 Jun 2014 15:18:57 +0400
Subject: <AWT Dev> [9] Review Request: 8033367 [macosx] Appletviewer was
	broken in jdk8 b124
Message-ID: <0FFA30BF-BDC5-4B0C-8E8A-B8982A60EE97@oracle.com>

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 dmitriy.ermashov at oracle.com  Tue Jun  3 11:21:17 2014
From: dmitriy.ermashov at oracle.com (Dmitriy Ermashov)
Date: Tue, 03 Jun 2014 15:21:17 +0400
Subject: <AWT Dev> Review request for JDK-8043131: Move
 ShapedAndTranslucentWindows and GC functional AWT tests to regression tree
In-Reply-To: <5379F43E.8060000@oracle.com>
References: <5379F43E.8060000@oracle.com>
Message-ID: <538DAFAD.3000409@oracle.com>

Hi all,

Please review the last version of fix for
https://bugs.openjdk.java.net/browse/JDK-8043131

The webrev is here:
http://cr.openjdk.java.net/~yan/8043131/webrev.01/

Test colocation for remaining ShapedAndTranslucent part of functional tests.
The fix also includes remarks for the first part of this batch. E.g. 
retrieved "@author mrkam" tag and full description for each test.
GC tests also reverted as they are not similar to 
java/awt/Window/OwnedWindowsLeak/OwnedWindowsLeak.java and could be 
useful for finding bugs.

Thanks,
Dima

On 05/19/2014 04:08 PM, Dmitriy Ermashov wrote:
> Hi,
>
> Please review the changeset for bug:
> https://bugs.openjdk.java.net/browse/JDK-8043131
>
> The webrev is here:
> http://cr.openjdk.java.net/~yan/8043131/webrev.00/
>
> This is one more batch of functional AWT (ShapedAndTranslucentWindows 
> and GC) tests are ought to be moved to regression tree.
>


From petr.pchelko at oracle.com  Tue Jun  3 12:33:46 2014
From: petr.pchelko at oracle.com (Petr Pchelko)
Date: Tue, 3 Jun 2014 16:33:46 +0400
Subject: <AWT Dev> Review request for JDK-8043131: Move
	ShapedAndTranslucentWindows and GC functional AWT tests to
	regression tree
In-Reply-To: <538DAFAD.3000409@oracle.com>
References: <5379F43E.8060000@oracle.com> <538DAFAD.3000409@oracle.com>
Message-ID: <A5DF7FFD-728E-40C9-AE40-50C48216D456@oracle.com>

Hello, Dmitriy.

I think that it worths adding -Xmx option to the GC tests as default max heap size is quite big.
Also could you please add @Override to the initGui method as now it's not obvious where is it called from.

Thank you.
With best regards. Petr.

On 03 ???? 2014 ?., at 15:21, Dmitriy Ermashov <dmitriy.ermashov at oracle.com> wrote:

> Hi all,
> 
> Please review the last version of fix for
> https://bugs.openjdk.java.net/browse/JDK-8043131
> 
> The webrev is here:
> http://cr.openjdk.java.net/~yan/8043131/webrev.01/
> 
> Test colocation for remaining ShapedAndTranslucent part of functional tests.
> The fix also includes remarks for the first part of this batch. E.g. retrieved "@author mrkam" tag and full description for each test.
> GC tests also reverted as they are not similar to java/awt/Window/OwnedWindowsLeak/OwnedWindowsLeak.java and could be useful for finding bugs.
> 
> Thanks,
> Dima
> 
> On 05/19/2014 04:08 PM, Dmitriy Ermashov wrote:
>> Hi,
>> 
>> Please review the changeset for bug:
>> https://bugs.openjdk.java.net/browse/JDK-8043131
>> 
>> The webrev is here:
>> http://cr.openjdk.java.net/~yan/8043131/webrev.00/
>> 
>> This is one more batch of functional AWT (ShapedAndTranslucentWindows and GC) tests are ought to be moved to regression tree.
>> 
> 


From alexander.v.stepanov at oracle.com  Tue Jun  3 12:48:33 2014
From: alexander.v.stepanov at oracle.com (alexander stepanov)
Date: Tue, 03 Jun 2014 16:48:33 +0400
Subject: <AWT Dev> [9] Review request for 8043967: Fix doclint warnings for
 java.awt
Message-ID: <538DC421.7060204@oracle.com>

Hello,

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

Webrev:
http://cr.openjdk.java.net/~avstepan/8043967

Just a cleanup of javadoc to avoid doclint warnings.

Thanks,
Alexander

From alexander.v.stepanov at oracle.com  Tue Jun  3 13:29:50 2014
From: alexander.v.stepanov at oracle.com (alexander stepanov)
Date: Tue, 03 Jun 2014 17:29:50 +0400
Subject: <AWT Dev> [9] Review request for 8040081: Tidy warnings cleanup
 for java.applet
In-Reply-To: <534BB9B5.3070208@oracle.com>
References: <534BB9B5.3070208@oracle.com>
Message-ID: <538DCDCE.6080502@oracle.com>

Sorry, just a reminder.

On 14.04.2014 14:34, alexander stepanov wrote:
> Hello,
>
> Could you please review the fix for the following bug:
> https://bugs.openjdk.java.net/browse/JDK-8040081
>
> Webrev corresponding:
> http://cr.openjdk.java.net/~yan/8040081/webrev.00/
>
> Just a very minor cleanup of javadoc to avoid tidy warnings; no other 
> code affected.
>
> Thanks.
>
> Regards,
> Alexander


From petr.pchelko at oracle.com  Tue Jun  3 13:39:09 2014
From: petr.pchelko at oracle.com (Petr Pchelko)
Date: Tue, 3 Jun 2014 17:39:09 +0400
Subject: <AWT Dev> [9] Review request for 8040081: Tidy warnings cleanup
	for java.applet
In-Reply-To: <538DCDCE.6080502@oracle.com>
References: <534BB9B5.3070208@oracle.com> <538DCDCE.6080502@oracle.com>
Message-ID: <5773873D-77F8-4867-AFD5-7169499C51B5@oracle.com>

Hello, Alexander.

The fix looks good to me.

With best regards. Petr.

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

> Sorry, just a reminder.
> 
> On 14.04.2014 14:34, alexander stepanov wrote:
>> Hello,
>> 
>> Could you please review the fix for the following bug:
>> https://bugs.openjdk.java.net/browse/JDK-8040081
>> 
>> Webrev corresponding:
>> http://cr.openjdk.java.net/~yan/8040081/webrev.00/
>> 
>> Just a very minor cleanup of javadoc to avoid tidy warnings; no other code affected.
>> 
>> Thanks.
>> 
>> Regards,
>> Alexander
> 


From Sergey.Bylokhov at oracle.com  Tue Jun  3 13:36:48 2014
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Tue, 03 Jun 2014 17:36:48 +0400
Subject: <AWT Dev> [9] Review request for 8040081: Tidy warnings cleanup
 for java.applet
In-Reply-To: <5773873D-77F8-4867-AFD5-7169499C51B5@oracle.com>
References: <534BB9B5.3070208@oracle.com> <538DCDCE.6080502@oracle.com>
	<5773873D-77F8-4867-AFD5-7169499C51B5@oracle.com>
Message-ID: <538DCF70.4020203@oracle.com>

Looks fine to me too.

On 6/3/14 5:39 PM, Petr Pchelko wrote:
> Hello, Alexander.
>
> The fix looks good to me.
>
> With best regards. Petr.
>
> On 03 ???? 2014 ?., at 17:29, alexander stepanov <alexander.v.stepanov at oracle.com> wrote:
>
>> Sorry, just a reminder.
>>
>> On 14.04.2014 14:34, alexander stepanov wrote:
>>> Hello,
>>>
>>> Could you please review the fix for the following bug:
>>> https://bugs.openjdk.java.net/browse/JDK-8040081
>>>
>>> Webrev corresponding:
>>> http://cr.openjdk.java.net/~yan/8040081/webrev.00/
>>>
>>> Just a very minor cleanup of javadoc to avoid tidy warnings; no other code affected.
>>>
>>> Thanks.
>>>
>>> Regards,
>>> Alexander


-- 
Best regards, Sergey.


From alexander.v.stepanov at oracle.com  Tue Jun  3 13:43:20 2014
From: alexander.v.stepanov at oracle.com (alexander stepanov)
Date: Tue, 03 Jun 2014 17:43:20 +0400
Subject: <AWT Dev> [9] Review request for 8040081: Tidy warnings cleanup
 for java.applet
In-Reply-To: <5773873D-77F8-4867-AFD5-7169499C51B5@oracle.com>
References: <534BB9B5.3070208@oracle.com> <538DCDCE.6080502@oracle.com>
	<5773873D-77F8-4867-AFD5-7169499C51B5@oracle.com>
Message-ID: <538DD0F8.6070402@oracle.com>

thanks!

On 03.06.2014 17:39, Petr Pchelko wrote:
> Hello, Alexander.
>
> The fix looks good to me.
>
> With best regards. Petr.
>
> On 03 ???? 2014 ?., at 17:29, alexander stepanov <alexander.v.stepanov at oracle.com> wrote:
>
>> Sorry, just a reminder.
>>
>> On 14.04.2014 14:34, alexander stepanov wrote:
>>> Hello,
>>>
>>> Could you please review the fix for the following bug:
>>> https://bugs.openjdk.java.net/browse/JDK-8040081
>>>
>>> Webrev corresponding:
>>> http://cr.openjdk.java.net/~yan/8040081/webrev.00/
>>>
>>> Just a very minor cleanup of javadoc to avoid tidy warnings; no other code affected.
>>>
>>> Thanks.
>>>
>>> Regards,
>>> Alexander


From Sergey.Bylokhov at oracle.com  Tue Jun  3 13:56:13 2014
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Tue, 03 Jun 2014 17:56:13 +0400
Subject: <AWT Dev> [9] Review request for 8043967: Fix doclint warnings
 for java.awt
In-Reply-To: <538DC421.7060204@oracle.com>
References: <538DC421.7060204@oracle.com>
Message-ID: <538DD3FD.8050909@oracle.com>

Hi, Alexander.
A few notes:
  - Use two spaces after @param tag only. in other cases use one space.
  - Do no align names of the @params tag like this:

  390      * position will not be replaced).
  391      * @param   str  the non-{@code null} text to use as
  392      *               the replacement
  393      * @param   start  the start position
  394      * @param   end    the end position
  395      * @deprecated As of JDK version 1.1,

Change them to:

  390      * position will not be replaced).
  391      * @param  str the non-{@code null} text to use as
  392      *         the replacement
  393      * @param  start the start position
  394      * @param  end the end position
  395      * @deprecated As of JDK version 1.1,

- Add empty line after method description before @param tag.
   - Description of the method should ends by dot.

On 6/3/14 4:48 PM, alexander stepanov wrote:
> Hello,
>
> Could you please review the fix for the following bug:
> https://bugs.openjdk.java.net/browse/JDK-8043967
>
> Webrev:
> http://cr.openjdk.java.net/~avstepan/8043967
>
> Just a cleanup of javadoc to avoid doclint warnings.
>
> Thanks,
> Alexander


-- 
Best regards, Sergey.

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

From anthony.petrov at oracle.com  Tue Jun  3 13:59:33 2014
From: anthony.petrov at oracle.com (Anthony Petrov)
Date: Tue, 03 Jun 2014 17:59:33 +0400
Subject: <AWT Dev> [9] Review Request: 8033367 [macosx] Appletviewer was
 broken in jdk8 b124
In-Reply-To: <0FFA30BF-BDC5-4B0C-8E8A-B8982A60EE97@oracle.com>
References: <0FFA30BF-BDC5-4B0C-8E8A-B8982A60EE97@oracle.com>
Message-ID: <538DD4C5.7050401@oracle.com>

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 alexander.v.stepanov at oracle.com  Tue Jun  3 16:46:47 2014
From: alexander.v.stepanov at oracle.com (alexander stepanov)
Date: Tue, 03 Jun 2014 20:46:47 +0400
Subject: <AWT Dev> [9] Review request for 8043967: Fix doclint warnings
 for java.awt
In-Reply-To: <538DD3FD.8050909@oracle.com>
References: <538DC421.7060204@oracle.com> <538DD3FD.8050909@oracle.com>
Message-ID: <538DFBF7.3040502@oracle.com>

Hello Sergey,

Updated; please see
http://cr.openjdk.java.net/~avstepan/8043967/webrev.01/

Thanks,
Alexander

On 03.06.2014 17:56, Sergey Bylokhov wrote:
> Hi, Alexander.
> A few notes:
>  - Use two spaces after @param tag only. in other cases use one space.
>  - Do no align names of the @params tag like this:
>   390      * position will not be replaced).
>   391      * @param   str  the non-{@code null} text to use as
>   392      *               the replacement
>   393      * @param   start  the start position
>   394      * @param   end    the end position
>   395      * @deprecated As of JDK version 1.1,
> Change them to:
>   390      * position will not be replaced).
>   391      * @param  str the non-{@code null} text to use as
>   392      *         the replacement
>   393      * @param  start the start position
>   394      * @param  end the end position
>   395      * @deprecated As of JDK version 1.1,
>   - Add empty line after method description before @param tag.
>   - Description of the method should ends by dot.
>
> On 6/3/14 4:48 PM, alexander stepanov wrote:
>> Hello,
>>
>> Could you please review the fix for the following bug:
>> https://bugs.openjdk.java.net/browse/JDK-8043967
>>
>> Webrev:
>> http://cr.openjdk.java.net/~avstepan/8043967
>>
>> Just a cleanup of javadoc to avoid doclint warnings.
>>
>> Thanks,
>> Alexander
>
>
> -- 
> Best regards, Sergey.


From philip.race at oracle.com  Wed Jun  4 05:16:39 2014
From: philip.race at oracle.com (Phil Race)
Date: Tue, 03 Jun 2014 22:16:39 -0700
Subject: <AWT Dev> RFR: 8044740: Convert all JDK versions used in @since
 tag to 1.n[.n] in jdk repo
In-Reply-To: <4D42051D-D892-48A0-8452-449A7DB4DE92@oracle.com>
References: <538E74B8.20603@oracle.com>
	<4D42051D-D892-48A0-8452-449A7DB4DE92@oracle.com>
Message-ID: <538EABB7.7050900@oracle.com>

On 6/3/14 8:17 PM, Mike Duigou wrote:
> You will need to include awt-dev and security-dev since this patch touches those areas as well. Other impacted groups I missed?

awt-dev is not all. This patch touches 2D and Swing code also.
so awt-dev, 2d-dev & swing-dev.
Those need to be pushed to 9/client and reviewed there.
I wonder if @since on the implementation classes is even worth it or
whether there is a policy there. No one should be reading that part
of the doc. Did you just blindly change everything or did you consider
what is really API ? Its probably inconsistently applied too.
Maybe they should be @Override instead 0- where applicable - else removed.


>
> I would like to see this all go back in one changeset to dev repo though as it would be a lot cleaner that way.
>
> I am concerned a bit that if we retain standard names for non-jdk standards it may be sometimes confusing or lacking in context to see a raw version number. Consistency is trumps all, but I would prefer to see JDK#.#[.#] used to be unambiguous.

That is a high order bit.

If anything is to be touched, the result had better be what is wanted 
long term.

-phil.

>
> I don't see any missteps in the changeset but wouldn't want mine to be the only review.
>
> Mike
>
> On Jun 3 2014, at 18:22 , Henry Jen <henry.jen at oracle.com> wrote:
>
>> Hi,
>>
>> In an effort to determine APIs availability in a given version, it became obvious that a consistent way to express @since tag would be beneficial.
>>
>> So started with the most obvious ones, where we have various expression for JDK version, this webrev make sure we use @since 1.n[.n] for JDK versions.
>>
>> The main focus is on public APIs, private ones are taken care if it is straightforward, otherwise, we try to keep the information.
>>
>> Some public APIs are using @since <STANDARD> <standard version> format, they are also preserved for now, but I think it worth discussion whether we want to change to the version as included in J2SE.
>>
>> There are APIs without @since information, separate webrevs will be coming to complete those information.
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8044740
>> The webrev can be found at
>> http://cr.openjdk.java.net/~henryjen/jdk9/8044740/0/webrev
>>
>> but it's probably easier just look into the raw diff,
>> http://cr.openjdk.java.net/~henryjen/jdk9/8044740/0/webrev/jdk.changeset
>>
>> Cheers,
>> Henry


From dmitriy.ermashov at oracle.com  Wed Jun  4 07:46:21 2014
From: dmitriy.ermashov at oracle.com (Dmitriy Ermashov)
Date: Wed, 04 Jun 2014 11:46:21 +0400
Subject: <AWT Dev> Review request for JDK-8043131: Move
 ShapedAndTranslucentWindows and GC functional AWT tests to regression tree
In-Reply-To: <A5DF7FFD-728E-40C9-AE40-50C48216D456@oracle.com>
References: <5379F43E.8060000@oracle.com> <538DAFAD.3000409@oracle.com>
	<A5DF7FFD-728E-40C9-AE40-50C48216D456@oracle.com>
Message-ID: <538ECECD.90208@oracle.com>

Hi Petr, all,

Please review next revision of webrev:
http://cr.openjdk.java.net/~yan/8043131/webrev.02/

1. Set -Xmx20m key for GC tests
2. Added @Override annotation for all corresponding self written methods.

Thanks,
Dima

On 03.06.2014 16:33, Petr Pchelko wrote:
> Hello, Dmitriy.
>
> I think that it worths adding -Xmx option to the GC tests as default max heap size is quite big.
> Also could you please add @Override to the initGui method as now it's not obvious where is it called from.
>
> Thank you.
> With best regards. Petr.
>
> On 03 ???? 2014 ?., at 15:21, Dmitriy Ermashov <dmitriy.ermashov at oracle.com> wrote:
>
>> Hi all,
>>
>> Please review the last version of fix for
>> https://bugs.openjdk.java.net/browse/JDK-8043131
>>
>> The webrev is here:
>> http://cr.openjdk.java.net/~yan/8043131/webrev.01/
>>
>> Test colocation for remaining ShapedAndTranslucent part of functional tests.
>> The fix also includes remarks for the first part of this batch. E.g. retrieved "@author mrkam" tag and full description for each test.
>> GC tests also reverted as they are not similar to java/awt/Window/OwnedWindowsLeak/OwnedWindowsLeak.java and could be useful for finding bugs.
>>
>> Thanks,
>> Dima
>>
>> On 05/19/2014 04:08 PM, Dmitriy Ermashov wrote:
>>> Hi,
>>>
>>> Please review the changeset for bug:
>>> https://bugs.openjdk.java.net/browse/JDK-8043131
>>>
>>> The webrev is here:
>>> http://cr.openjdk.java.net/~yan/8043131/webrev.00/
>>>
>>> This is one more batch of functional AWT (ShapedAndTranslucentWindows and GC) tests are ought to be moved to regression tree.
>>>


From petr.pchelko at oracle.com  Wed Jun  4 08:00:12 2014
From: petr.pchelko at oracle.com (Petr Pchelko)
Date: Wed, 4 Jun 2014 12:00:12 +0400
Subject: <AWT Dev> Review request for JDK-8043131: Move
	ShapedAndTranslucentWindows and GC functional AWT tests to
	regression tree
In-Reply-To: <538ECECD.90208@oracle.com>
References: <5379F43E.8060000@oracle.com> <538DAFAD.3000409@oracle.com>
	<A5DF7FFD-728E-40C9-AE40-50C48216D456@oracle.com>
	<538ECECD.90208@oracle.com>
Message-ID: <E609129F-6738-4234-822D-F9F21795F498@oracle.com>

Hello, Dmitriy.

The new version looks fine to me.

With best regards. Petr.

On 04 ???? 2014 ?., at 11:46, Dmitriy Ermashov <dmitriy.ermashov at oracle.com> wrote:

> Hi Petr, all,
> 
> Please review next revision of webrev:
> http://cr.openjdk.java.net/~yan/8043131/webrev.02/
> 
> 1. Set -Xmx20m key for GC tests
> 2. Added @Override annotation for all corresponding self written methods.
> 
> Thanks,
> Dima
> 
> On 03.06.2014 16:33, Petr Pchelko wrote:
>> Hello, Dmitriy.
>> 
>> I think that it worths adding -Xmx option to the GC tests as default max heap size is quite big.
>> Also could you please add @Override to the initGui method as now it's not obvious where is it called from.
>> 
>> Thank you.
>> With best regards. Petr.
>> 
>> On 03 ???? 2014 ?., at 15:21, Dmitriy Ermashov <dmitriy.ermashov at oracle.com> wrote:
>> 
>>> Hi all,
>>> 
>>> Please review the last version of fix for
>>> https://bugs.openjdk.java.net/browse/JDK-8043131
>>> 
>>> The webrev is here:
>>> http://cr.openjdk.java.net/~yan/8043131/webrev.01/
>>> 
>>> Test colocation for remaining ShapedAndTranslucent part of functional tests.
>>> The fix also includes remarks for the first part of this batch. E.g. retrieved "@author mrkam" tag and full description for each test.
>>> GC tests also reverted as they are not similar to java/awt/Window/OwnedWindowsLeak/OwnedWindowsLeak.java and could be useful for finding bugs.
>>> 
>>> Thanks,
>>> Dima
>>> 
>>> On 05/19/2014 04:08 PM, Dmitriy Ermashov wrote:
>>>> Hi,
>>>> 
>>>> Please review the changeset for bug:
>>>> https://bugs.openjdk.java.net/browse/JDK-8043131
>>>> 
>>>> The webrev is here:
>>>> http://cr.openjdk.java.net/~yan/8043131/webrev.00/
>>>> 
>>>> This is one more batch of functional AWT (ShapedAndTranslucentWindows and GC) tests are ought to be moved to regression tree.
>>>> 
> 


From yuri.nesterenko at oracle.com  Wed Jun  4 08:23:22 2014
From: yuri.nesterenko at oracle.com (Yuri Nesterenko)
Date: Wed, 04 Jun 2014 12:23:22 +0400
Subject: <AWT Dev> [9] Review request for 8044157: improve recently
 submitted AWT_Mixing tests
In-Reply-To: <5385FB6F.4010704@oracle.com>
References: <5385FB6F.4010704@oracle.com>
Message-ID: <538ED77A.2080303@oracle.com>

Weekly friendly reminder!

Best regards,
-yan

On 05/28/2014 07:06 PM, Yuri Nesterenko wrote:
> Hi,
>
> please review this change for RFE
> https://bugs.openjdk.java.net/browse/JDK-8044157
>
> Webrev is in
> http://cr.openjdk.java.net/~yan/8044157/webrev.00
>
> Thanks,
> -yan
> _______________
> In this change, we remove an exact copy of one helper class
> and change some stray System.exits to RuntimeExceptions.
>
> Tested on 2 different Linux systems, on OS X and
> 2 Windows (7, 8.1).


From petr.pchelko at oracle.com  Wed Jun  4 08:44:31 2014
From: petr.pchelko at oracle.com (Petr Pchelko)
Date: Wed, 4 Jun 2014 12:44:31 +0400
Subject: <AWT Dev> [9] Review request for 8044157: improve recently
	submitted AWT_Mixing tests
In-Reply-To: <538ED77A.2080303@oracle.com>
References: <5385FB6F.4010704@oracle.com> <538ED77A.2080303@oracle.com>
Message-ID: <8C604CAB-78A5-423E-AD40-7FEA1B44F6F6@oracle.com>

Hello, Yuri.

A couple of comments:
1. In HierarchyBoundsListenerMixingTest.java a couple of lines is left commented out. What's going on there? Same with MixingPanelsResizing.java
2. I see that tests open a TestDialog with some useless instructions and obvious info. What do you think about removing it completely together with the dialog code?

With best regards. Petr.

On 04 ???? 2014 ?., at 12:23, Yuri Nesterenko <yuri.nesterenko at oracle.com> wrote:

> Weekly friendly reminder!
> 
> Best regards,
> -yan
> 
> On 05/28/2014 07:06 PM, Yuri Nesterenko wrote:
>> Hi,
>> 
>> please review this change for RFE
>> https://bugs.openjdk.java.net/browse/JDK-8044157
>> 
>> Webrev is in
>> http://cr.openjdk.java.net/~yan/8044157/webrev.00
>> 
>> Thanks,
>> -yan
>> _______________
>> In this change, we remove an exact copy of one helper class
>> and change some stray System.exits to RuntimeExceptions.
>> 
>> Tested on 2 different Linux systems, on OS X and
>> 2 Windows (7, 8.1).
> 


From dmitriy.ermashov at oracle.com  Wed Jun  4 09:24:12 2014
From: dmitriy.ermashov at oracle.com (Dmitriy Ermashov)
Date: Wed, 04 Jun 2014 13:24:12 +0400
Subject: <AWT Dev> Review request for JDK-8044765: Move functional tests
 AWT_SystemTray/Automated to openjdk repository
Message-ID: <538EE5BC.1000304@oracle.com>

Hi team,

It is new batch of functional tests, system tray tests this time.
Please review the change set:
http://cr.openjdk.java.net/~dermashov/8044765/webrev.00/

The fix also contains new test MouseMovedTest for verifying bug 7153700

-- 
Thanks,
Dima


From alexander.zvegintsev at oracle.com  Wed Jun  4 10:46:50 2014
From: alexander.zvegintsev at oracle.com (Alexander Zvegintsev)
Date: Wed, 04 Jun 2014 14:46:50 +0400
Subject: <AWT Dev> [9] Review Request: 8043979 Javadoc cleanup of
 javax.sound.sampled package
In-Reply-To: <538C40A4.6020503@oracle.com>
References: <538C40A4.6020503@oracle.com>
Message-ID: <538EF91A.7030200@oracle.com>

Hi Sergey,

the fix looks good to me too.

Thanks,

Alexander.

On 06/02/2014 01:15 PM, Sergey Bylokhov wrote:
> Hello.
> Please review another one javadoc "weekend 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.
>  - Description of the class/method/field should be followed by dot.
>  - Broken links or typos should be fixed (ex. 
> http://cr.openjdk.java.net/~serb/8043979/specdiff/FloatControl-report.html#method:getMaxLabel())
>
> See the full specdiff: 
> http://cr.openjdk.java.net/~serb/8043979/specdiff/package-summary.html
>
>  - some broken merges from 1999(!!!) were fixed(ex. 
> http://cr.openjdk.java.net/~serb/8043979/webrev.00/src/share/classes/javax/sound/sampled/LineListener.java.udiff.html)
>  - 80 column limit.
>  - empty line after description/before the first tag.
>  - sets of spaces in the middle of text were deleted.
>  - @param, @throws, @return now align, to be more readable.
>  - <tag> should be replaced by {@tag }.
>  - unnecessary imports should be removed.
>  - @see tags can be simplified in some places.
>  - unnecessary spaces and lines can be removed.
>  - @Override should be added when necessary.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8043979
> Webrev can be found at: 
> http://cr.openjdk.java.net/~serb/8043979/webrev.00
>


From yuri.nesterenko at oracle.com  Wed Jun  4 10:50:20 2014
From: yuri.nesterenko at oracle.com (Yuri Nesterenko)
Date: Wed, 04 Jun 2014 14:50:20 +0400
Subject: <AWT Dev> [9] Review request for 8044157: improve recently
 submitted AWT_Mixing tests
In-Reply-To: <8C604CAB-78A5-423E-AD40-7FEA1B44F6F6@oracle.com>
References: <5385FB6F.4010704@oracle.com> <538ED77A.2080303@oracle.com>
	<8C604CAB-78A5-423E-AD40-7FEA1B44F6F6@oracle.com>
Message-ID: <538EF9EC.4090604@oracle.com>

Hi Petr,

that's one and the same question, in fact.
I'm commenting out the useless TestDialog setVisible(true) stuff.
Sure it would be better to trim that off completely.
It seems to me, however, that this well-known easy-to-ignore
garbage found in hundreds of other tests
doesn't hurt the test execution much.
We are trying to avoid refactoring whenever possible.

Let's do this way: if you think I really should do that, say so,
and I'll be back with a new version in a week.

Thank you Petr!
-yan

On 06/04/2014 12:44 PM, Petr Pchelko wrote:
> Hello, Yuri.
>
> A couple of comments:
> 1. In HierarchyBoundsListenerMixingTest.java a couple of lines is left commented out. What's going on there? Same with MixingPanelsResizing.java
> 2. I see that tests open a TestDialog with some useless instructions and obvious info. What do you think about removing it completely together with the dialog code?
>
> With best regards. Petr.
>
> On 04 ???? 2014 ?., at 12:23, Yuri Nesterenko <yuri.nesterenko at oracle.com> wrote:
>
>> Weekly friendly reminder!
>>
>> Best regards,
>> -yan
>>
>> On 05/28/2014 07:06 PM, Yuri Nesterenko wrote:
>>> Hi,
>>>
>>> please review this change for RFE
>>> https://bugs.openjdk.java.net/browse/JDK-8044157
>>>
>>> Webrev is in
>>> http://cr.openjdk.java.net/~yan/8044157/webrev.00
>>>
>>> Thanks,
>>> -yan
>>> _______________
>>> In this change, we remove an exact copy of one helper class
>>> and change some stray System.exits to RuntimeExceptions.
>>>
>>> Tested on 2 different Linux systems, on OS X and
>>> 2 Windows (7, 8.1).
>>
>


From petr.pchelko at oracle.com  Wed Jun  4 11:08:29 2014
From: petr.pchelko at oracle.com (Petr Pchelko)
Date: Wed, 4 Jun 2014 15:08:29 +0400
Subject: <AWT Dev> Review request for JDK-8044765: Move functional tests
	AWT_SystemTray/Automated to openjdk repository
In-Reply-To: <538EE5BC.1000304@oracle.com>
References: <538EE5BC.1000304@oracle.com>
Message-ID: <F66CBFB8-8F4D-4557-9150-887FFF8EADC7@oracle.com>

Hello, Dmitriy.

A couple of comments:
1. Could you please split loooong lines in ActionCommand.java, ModalityTest.java, MouseEventMaskTest.java, TrayIconEventModifiersTest.java, TrayIconEventsTest.java, TrayIconPopupTest.java
2. For interprocess communication we have special helpers in java/awt/regtesthelpers/process. You could reuse them to simplify InterJVM.java
3. MouseMovedTest - moved should be volatile

Thank you.
With best regards. Petr.

On 04 ???? 2014 ?., at 13:24, Dmitriy Ermashov <dmitriy.ermashov at oracle.com> wrote:

> Hi team,
> 
> It is new batch of functional tests, system tray tests this time.
> Please review the change set:
> http://cr.openjdk.java.net/~dermashov/8044765/webrev.00/
> 
> The fix also contains new test MouseMovedTest for verifying bug 7153700
> 
> -- 
> Thanks,
> Dima
> 


From petr.pchelko at oracle.com  Wed Jun  4 11:55:27 2014
From: petr.pchelko at oracle.com (Petr Pchelko)
Date: Wed, 4 Jun 2014 15:55:27 +0400
Subject: <AWT Dev> [9] Review request for 8044157: improve recently
	submitted AWT_Mixing tests
In-Reply-To: <538EF9EC.4090604@oracle.com>
References: <5385FB6F.4010704@oracle.com> <538ED77A.2080303@oracle.com>
	<8C604CAB-78A5-423E-AD40-7FEA1B44F6F6@oracle.com>
	<538EF9EC.4090604@oracle.com>
Message-ID: <662EA39B-1D13-4BBC-B79A-ED8E613541A2@oracle.com>

Hello, Yuri.

> Let's do this way: if you think I really should do that, say so,
> and I'll be back with a new version in a week.
This was a suggestion and it's not critical.
I'm OK with the fix either way.

With best regards. Petr.

On 04 ???? 2014 ?., at 14:50, Yuri Nesterenko <yuri.nesterenko at oracle.com> wrote:

> Hi Petr,
> 
> that's one and the same question, in fact.
> I'm commenting out the useless TestDialog setVisible(true) stuff.
> Sure it would be better to trim that off completely.
> It seems to me, however, that this well-known easy-to-ignore
> garbage found in hundreds of other tests
> doesn't hurt the test execution much.
> We are trying to avoid refactoring whenever possible.
> 
> Let's do this way: if you think I really should do that, say so,
> and I'll be back with a new version in a week.
> 
> Thank you Petr!
> -yan
> 
> On 06/04/2014 12:44 PM, Petr Pchelko wrote:
>> Hello, Yuri.
>> 
>> A couple of comments:
>> 1. In HierarchyBoundsListenerMixingTest.java a couple of lines is left commented out. What's going on there? Same with MixingPanelsResizing.java
>> 2. I see that tests open a TestDialog with some useless instructions and obvious info. What do you think about removing it completely together with the dialog code?
>> 
>> With best regards. Petr.
>> 
>> On 04 ???? 2014 ?., at 12:23, Yuri Nesterenko <yuri.nesterenko at oracle.com> wrote:
>> 
>>> Weekly friendly reminder!
>>> 
>>> Best regards,
>>> -yan
>>> 
>>> On 05/28/2014 07:06 PM, Yuri Nesterenko wrote:
>>>> Hi,
>>>> 
>>>> please review this change for RFE
>>>> https://bugs.openjdk.java.net/browse/JDK-8044157
>>>> 
>>>> Webrev is in
>>>> http://cr.openjdk.java.net/~yan/8044157/webrev.00
>>>> 
>>>> Thanks,
>>>> -yan
>>>> _______________
>>>> In this change, we remove an exact copy of one helper class
>>>> and change some stray System.exits to RuntimeExceptions.
>>>> 
>>>> Tested on 2 different Linux systems, on OS X and
>>>> 2 Windows (7, 8.1).
>>> 
>> 
> 


From yuri.nesterenko at oracle.com  Wed Jun  4 12:56:07 2014
From: yuri.nesterenko at oracle.com (Yuri Nesterenko)
Date: Wed, 04 Jun 2014 16:56:07 +0400
Subject: <AWT Dev> [9] Review request for 8044157: improve recently
 submitted AWT_Mixing tests
In-Reply-To: <662EA39B-1D13-4BBC-B79A-ED8E613541A2@oracle.com>
References: <5385FB6F.4010704@oracle.com> <538ED77A.2080303@oracle.com>
	<8C604CAB-78A5-423E-AD40-7FEA1B44F6F6@oracle.com>
	<538EF9EC.4090604@oracle.com>
	<662EA39B-1D13-4BBC-B79A-ED8E613541A2@oracle.com>
Message-ID: <538F1767.4060901@oracle.com>

On 06/04/2014 03:55 PM, Petr Pchelko wrote:
> Hello, Yuri.
>
>> Let's do this way: if you think I really should do that, say so,
>> and I'll be back with a new version in a week.
> This was a suggestion and it's not critical.
> I'm OK with the fix either way.
That's how we avoid decisions :-)

Thank you!
-yan

>
> With best regards. Petr.
>
> On 04 ???? 2014 ?., at 14:50, Yuri Nesterenko <yuri.nesterenko at oracle.com> wrote:
>
>> Hi Petr,
>>
>> that's one and the same question, in fact.
>> I'm commenting out the useless TestDialog setVisible(true) stuff.
>> Sure it would be better to trim that off completely.
>> It seems to me, however, that this well-known easy-to-ignore
>> garbage found in hundreds of other tests
>> doesn't hurt the test execution much.
>> We are trying to avoid refactoring whenever possible.
>>
>> Let's do this way: if you think I really should do that, say so,
>> and I'll be back with a new version in a week.
>>
>> Thank you Petr!
>> -yan
>>
>> On 06/04/2014 12:44 PM, Petr Pchelko wrote:
>>> Hello, Yuri.
>>>
>>> A couple of comments:
>>> 1. In HierarchyBoundsListenerMixingTest.java a couple of lines is left commented out. What's going on there? Same with MixingPanelsResizing.java
>>> 2. I see that tests open a TestDialog with some useless instructions and obvious info. What do you think about removing it completely together with the dialog code?
>>>
>>> With best regards. Petr.
>>>
>>> On 04 ???? 2014 ?., at 12:23, Yuri Nesterenko <yuri.nesterenko at oracle.com> wrote:
>>>
>>>> Weekly friendly reminder!
>>>>
>>>> Best regards,
>>>> -yan
>>>>
>>>> On 05/28/2014 07:06 PM, Yuri Nesterenko wrote:
>>>>> Hi,
>>>>>
>>>>> please review this change for RFE
>>>>> https://bugs.openjdk.java.net/browse/JDK-8044157
>>>>>
>>>>> Webrev is in
>>>>> http://cr.openjdk.java.net/~yan/8044157/webrev.00
>>>>>
>>>>> Thanks,
>>>>> -yan
>>>>> _______________
>>>>> In this change, we remove an exact copy of one helper class
>>>>> and change some stray System.exits to RuntimeExceptions.
>>>>>
>>>>> Tested on 2 different Linux systems, on OS X and
>>>>> 2 Windows (7, 8.1).
>>>>
>>>
>>
>


From Sergey.Bylokhov at oracle.com  Wed Jun  4 14:10:40 2014
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Wed, 04 Jun 2014 18:10:40 +0400
Subject: <AWT Dev> [9] Review Request: 8039901
 jdk/src/share/classes/com/sun/media/sound/services/<platform> appear not to
 be used
Message-ID: <538F28E0.8090804@oracle.com>

Hello.
Please review the fix for jdk 9.
The old sound configuration files were removed, its were used in the old 
(beatnik) sound engine in old build system.

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

-- 
Best regards, Sergey.


From alexandr.scherbatiy at oracle.com  Wed Jun  4 14:29:42 2014
From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy)
Date: Wed, 04 Jun 2014 18:29:42 +0400
Subject: <AWT Dev> [OpenJDK 2D-Dev] [9] Review request for 8029339
 Custom MultiResolution image support on HiDPI displays
In-Reply-To: <5379E117.6010202@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>
Message-ID: <538F2D56.80609@oracle.com>


   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 henry.jen at oracle.com  Wed Jun  4 17:52:08 2014
From: henry.jen at oracle.com (Henry Jen)
Date: Wed, 04 Jun 2014 10:52:08 -0700
Subject: <AWT Dev> RFR: 8044740: Convert all JDK versions used in @since
 tag to 1.n[.n] in jdk repo
In-Reply-To: <538E74B8.20603@oracle.com>
References: <538E74B8.20603@oracle.com>
Message-ID: <538F5CC8.3050702@oracle.com>

Thanks for all reviewing and feedbacks on core-libs-dev[1], I tried to 
respond to feedbacks with this email and send off to other mailing lists.

I am wondering if jdk9-dev is the appropriate list for such a trivious 
but broad change, so that we can have one instead of many lists, and we 
still probably miss another. Lets follow up this thread on jdk9-dev.

Regarding to whether we should keep JDK, the later convention is 1.#, 
and as David pointed out the document also list @since that way, I think 
we should settle on that.

For other standards such as SAX or JCE, I propose to convert them to the 
version of JDK those APIs are included. To retain that information, we 
can introduce a custom tag, perhaps @standard or @conformingTo?

@conformingTo <Standard name> <version>[, <Standard name> <version>]*
For example, @conformingTo SAX 2.0.

Repo wise, I think it's best if I can commit to jdk9/dev as a single 
commit instead of scattering to dev and client. But I can cope if this 
is absolutely necessary.

Some changes to implementation classes, as I mentioned, only when it is 
straightforward. Essentially, I did a s/(@since *)JDK(.*)/\1\2 against 
all files.

Some changes not obvious are simply remove tailing space, a (positive) 
side effect of the tools I use so I kept them.

Cheers,
Henry


[1] 
http://mail.openjdk.java.net/pipermail/core-libs-dev/2014-June/027113.html

On 06/03/2014 06:22 PM, Henry Jen wrote:
> Hi,
>
> In an effort to determine APIs availability in a given version, it
> became obvious that a consistent way to express @since tag would be
> beneficial.
>
> So started with the most obvious ones, where we have various expression
> for JDK version, this webrev make sure we use @since 1.n[.n] for JDK
> versions.
>
> The main focus is on public APIs, private ones are taken care if it is
> straightforward, otherwise, we try to keep the information.
>
> Some public APIs are using @since <STANDARD> <standard version> format,
> they are also preserved for now, but I think it worth discussion whether
> we want to change to the version as included in J2SE.
>
> There are APIs without @since information, separate webrevs will be
> coming to complete those information.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8044740
> The webrev can be found at
> http://cr.openjdk.java.net/~henryjen/jdk9/8044740/0/webrev
>
> but it's probably easier just look into the raw diff,
> http://cr.openjdk.java.net/~henryjen/jdk9/8044740/0/webrev/jdk.changeset
>
> Cheers,
> Henry

From alexey.ivanov at oracle.com  Thu Jun  5 06:35:19 2014
From: alexey.ivanov at oracle.com (Alexey Ivanov)
Date: Thu, 05 Jun 2014 10:35:19 +0400
Subject: <AWT Dev> <Swing Dev> [9] Review request for JDK-8039383: NPE
 when changing Windows Theme
In-Reply-To: <536899D1.1020501@oracle.com>
References: <5350DDBC.30603@oracle.com>	<5351143C.8010100@oracle.com>	<53513B5B.4050104@oracle.com>	<53513C26.9060305@oracle.com>
	<53590232.4080703@oracle.com> <536899D1.1020501@oracle.com>
Message-ID: <53900FA7.8040508@oracle.com>

Hi AWT and Swing teams,

Could you please review the updated fix:
http://cr.openjdk.java.net/~aivanov/8039383/jdk9/webrev.03/


What has changed since version .02?

During additional testing, I found another scenario where NPE was 
thrown. So the new version adds more checks to prevent access to XPStyle 
and ThemeReader where Windows visual styles become unavailable.

As in previous version, getters in XPStyle class check for null values 
and return dummy defaults if ThemeReader returned null. Skin painters 
also check whether theming is still available before asking ThemeReader 
to paint.

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

Thank you,
Alexey.

On 06.05.2014 12:14, Alexey Ivanov wrote:
> Hi AWT and Swing teams,
>
> Could you please review the updated fix:
> http://cr.openjdk.java.net/~dmarkov/8039383/jdk9/webrev.02/
>
>
> What has changed since version .01?
>
> The issue was still reproducible with the .01 version of the fix, 
> however it was harder to reproduce.
>
> So in version .02 I added checks for null where possible. If theme 
> becomes unavailable, a dummy value will be used; this way applications 
> will be more stable. As soon as the theme change events are handled, 
> the entire UI will update properly.
>
> Thank you,
> Alexey.
>
> On 24.04.2014 16:23, Alexey Ivanov wrote:
>> Hi Anthony, AWT and Swing teams,
>>
>> Here's the updated fix:
>> http://cr.openjdk.java.net/~dmarkov/8039383/jdk9/webrev.01/
>>
>> Description:
>> In the new version of the fix, I use a new xpstyleEnabled field of 
>> AtomicBoolean in WToolkit to track the current value of 
>> "win.xpstyle.themeActive" desktop property. Its value is updated in 
>> windowsSettingChange() and in updateProperties().
>> XPStyle.getXP() checks its cached value in themeActive and the 
>> current value in WToolkit; if the value changes, it schedules 
>> updateAllUIs and invalidates the current style right away, so that 
>> components would not access data from the theme that became unavailable.
>> Two functions in ThemeReader also check this special field from 
>> WToolkit which prevents throwing InternalError when paint is called 
>> before theme change is fully handled.
>>
>> Before updateAllUIs is invoked, it's possible that application will 
>> paint with some values cached from the previous theme. Usually it 
>> happens before "Theme change" dialog disappears from the screen, at 
>> least I noticed no UI glitches during normal theme change.
>>
>>
>> Regression test:
>> No regression test is provided due to its complexity. Additionally, 
>> 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.
>>
>>
>> Thank you,
>> Alexey.
>>
>> On 18.04.2014 18:52, Anthony Petrov wrote:
>>> Hi Alexey,
>>>
>>> No, unfortunately I don't have any suggestions right now.
>>>
>>> As for allowing executing user code on the toolkit thread, we can't 
>>> accept such a fix. Sorry about that.
>>>
>>> -- 
>>> best regards,
>>> Anthony
>>>
>>> On 4/18/2014 6:48 PM, Alexey Ivanov wrote:
>>>> Hi Anthony,
>>>>
>>>> Thank you for your review.
>>>>
>>>> Yes, user code can install a property change listener... It was my
>>>> concern too, that's why I explicitly noted about this.
>>>>
>>>> Do you have any suggestion how this situation can be handled?
>>>> Is it a general rule that all desktop property change listeners 
>>>> must be
>>>> called on EDT?
>>>>
>>>>
>>>> Thanks,
>>>> Alexey.
>>>>
>>>> On 18.04.2014 16:02, Anthony Petrov wrote:
>>>>> Hi Alexey,
>>>>>
>>>>>> With this change, property "win.xpstyle.themeActive" change is fired
>>>>>> on the toolkit thread
>>>>>
>>>>> Is it possible to install a change listener for this property from
>>>>> user code, and hence eventually allow executing some user code on the
>>>>> toolkit thread with your fix?
>>>>>
>>>>> -- 
>>>>> best regards,
>>>>> Anthony
>>>>>
>>>>> On 4/18/2014 12:09 PM, Alexey Ivanov wrote:
>>>>>> Hello Swing and AWT teams,
>>>>>>
>>>>>> Could you please review the fix for jdk9:
>>>>>>      bug: https://bugs.openjdk.java.net/browse/JDK-8039383
>>>>>>      webrev: 
>>>>>> http://cr.openjdk.java.net/~dmarkov/8039383/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 "cached" in XPStyle object. When the theme is
>>>>>> switched to a classic one, HTHEME handle becomes unavailable and 
>>>>>> data
>>>>>> cannot be accessed from the theme any more. The change in theme in
>>>>>> posted to EDT via invokeLater. At the same time, the UI needs to 
>>>>>> repaint
>>>>>> itself as soon as Windows changed the theme, and paint code is often
>>>>>> called before the theme change is handled in Java. This leads to 
>>>>>> NPE and
>>>>>> InternalError as the code tries to access the data that has become
>>>>>> unavailable.
>>>>>>
>>>>>> The fix:
>>>>>> Update "win.xpstyle.themeActive" desktop property and invalidate the
>>>>>> cached XPStyle as soon as windowsSettingChange() is called from 
>>>>>> native
>>>>>> code. Thus when Swing code needs to access theme data, it will 
>>>>>> see no
>>>>>> theme is available and will fallback to classic painting.
>>>>>>
>>>>>> Note: Before the fix, PropertyChangeEvents for desktop properties in
>>>>>> Windows were fired on the Event Dispatch Thread. With this change,
>>>>>> property "win.xpstyle.themeActive" change is fired on the toolkit
>>>>>> thread; all other properties are changed on the EDT as before.
>>>>>>
>>>>>>
>>>>>> Regards,
>>>>>> Alexey.
>>>>
>>
>


From petr.pchelko at oracle.com  Thu Jun  5 07:08:38 2014
From: petr.pchelko at oracle.com (Petr Pchelko)
Date: Thu, 5 Jun 2014 11:08:38 +0400
Subject: <AWT Dev> <Swing Dev> [9] Review request for JDK-8039383: NPE
	when changing Windows Theme
In-Reply-To: <53900FA7.8040508@oracle.com>
References: <5350DDBC.30603@oracle.com>	<5351143C.8010100@oracle.com>	<53513B5B.4050104@oracle.com>	<53513C26.9060305@oracle.com>
	<53590232.4080703@oracle.com> <536899D1.1020501@oracle.com>
	<53900FA7.8040508@oracle.com>
Message-ID: <0FE09EB0-B3A1-43F4-AE48-401DD55F5B09@oracle.com>

Hello, Alexey.

A couple of comments:
1. ThemeReader:64 - I suggest to remove that comment as it does not add any value. The variable name is self explanatory.
2. XPStyle - did you try providing a stub XPStyle object instead of changing many of it's methods? Do I understand correctly that this
is not possible because XPstyle is cached in many place is our code? 
3. In offline discussion you've mentioned that you've found another related issue. Did you have a chance to file a bug about it?

Thank you.
With best regards. Petr.

On 05 ???? 2014 ?., at 10:35, Alexey Ivanov <alexey.ivanov at oracle.com> wrote:

> Hi AWT and Swing teams,
> 
> Could you please review the updated fix:
> http://cr.openjdk.java.net/~aivanov/8039383/jdk9/webrev.03/
> 
> 
> What has changed since version .02?
> 
> During additional testing, I found another scenario where NPE was thrown. So the new version adds more checks to prevent access to XPStyle and ThemeReader where Windows visual styles become unavailable.
> 
> As in previous version, getters in XPStyle class check for null values and return dummy defaults if ThemeReader returned null. Skin painters also check whether theming is still available before asking ThemeReader to paint.
> 
> Access to XPStyle.xp instance is blocked as soon as user switched themes. The object will be cleaned when the corresponding PropertyChangeEvent is handled by Swing.
> 
> Thank you,
> Alexey.
> 
> On 06.05.2014 12:14, Alexey Ivanov wrote:
>> Hi AWT and Swing teams,
>> 
>> Could you please review the updated fix:
>> http://cr.openjdk.java.net/~dmarkov/8039383/jdk9/webrev.02/
>> 
>> 
>> What has changed since version .01?
>> 
>> The issue was still reproducible with the .01 version of the fix, however it was harder to reproduce.
>> 
>> So in version .02 I added checks for null where possible. If theme becomes unavailable, a dummy value will be used; this way applications will be more stable. As soon as the theme change events are handled, the entire UI will update properly.
>> 
>> Thank you,
>> Alexey.
>> 
>> On 24.04.2014 16:23, Alexey Ivanov wrote:
>>> Hi Anthony, AWT and Swing teams,
>>> 
>>> Here's the updated fix:
>>> http://cr.openjdk.java.net/~dmarkov/8039383/jdk9/webrev.01/
>>> 
>>> Description:
>>> In the new version of the fix, I use a new xpstyleEnabled field of AtomicBoolean in WToolkit to track the current value of "win.xpstyle.themeActive" desktop property. Its value is updated in windowsSettingChange() and in updateProperties().
>>> XPStyle.getXP() checks its cached value in themeActive and the current value in WToolkit; if the value changes, it schedules updateAllUIs and invalidates the current style right away, so that components would not access data from the theme that became unavailable.
>>> Two functions in ThemeReader also check this special field from WToolkit which prevents throwing InternalError when paint is called before theme change is fully handled.
>>> 
>>> Before updateAllUIs is invoked, it's possible that application will paint with some values cached from the previous theme. Usually it happens before "Theme change" dialog disappears from the screen, at least I noticed no UI glitches during normal theme change.
>>> 
>>> 
>>> Regression test:
>>> No regression test is provided due to its complexity. Additionally, 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.
>>> 
>>> 
>>> Thank you,
>>> Alexey.
>>> 
>>> On 18.04.2014 18:52, Anthony Petrov wrote:
>>>> Hi Alexey,
>>>> 
>>>> No, unfortunately I don't have any suggestions right now.
>>>> 
>>>> As for allowing executing user code on the toolkit thread, we can't accept such a fix. Sorry about that.
>>>> 
>>>> -- 
>>>> best regards,
>>>> Anthony
>>>> 
>>>> On 4/18/2014 6:48 PM, Alexey Ivanov wrote:
>>>>> Hi Anthony,
>>>>> 
>>>>> Thank you for your review.
>>>>> 
>>>>> Yes, user code can install a property change listener... It was my
>>>>> concern too, that's why I explicitly noted about this.
>>>>> 
>>>>> Do you have any suggestion how this situation can be handled?
>>>>> Is it a general rule that all desktop property change listeners must be
>>>>> called on EDT?
>>>>> 
>>>>> 
>>>>> Thanks,
>>>>> Alexey.
>>>>> 
>>>>> On 18.04.2014 16:02, Anthony Petrov wrote:
>>>>>> Hi Alexey,
>>>>>> 
>>>>>>> With this change, property "win.xpstyle.themeActive" change is fired
>>>>>>> on the toolkit thread
>>>>>> 
>>>>>> Is it possible to install a change listener for this property from
>>>>>> user code, and hence eventually allow executing some user code on the
>>>>>> toolkit thread with your fix?
>>>>>> 
>>>>>> -- 
>>>>>> best regards,
>>>>>> Anthony
>>>>>> 
>>>>>> On 4/18/2014 12:09 PM, Alexey Ivanov wrote:
>>>>>>> Hello Swing and AWT teams,
>>>>>>> 
>>>>>>> Could you please review the fix for jdk9:
>>>>>>>     bug: https://bugs.openjdk.java.net/browse/JDK-8039383
>>>>>>>     webrev: http://cr.openjdk.java.net/~dmarkov/8039383/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 "cached" in XPStyle object. When the theme is
>>>>>>> switched to a classic one, HTHEME handle becomes unavailable and data
>>>>>>> cannot be accessed from the theme any more. The change in theme in
>>>>>>> posted to EDT via invokeLater. At the same time, the UI needs to repaint
>>>>>>> itself as soon as Windows changed the theme, and paint code is often
>>>>>>> called before the theme change is handled in Java. This leads to NPE and
>>>>>>> InternalError as the code tries to access the data that has become
>>>>>>> unavailable.
>>>>>>> 
>>>>>>> The fix:
>>>>>>> Update "win.xpstyle.themeActive" desktop property and invalidate the
>>>>>>> cached XPStyle as soon as windowsSettingChange() is called from native
>>>>>>> code. Thus when Swing code needs to access theme data, it will see no
>>>>>>> theme is available and will fallback to classic painting.
>>>>>>> 
>>>>>>> Note: Before the fix, PropertyChangeEvents for desktop properties in
>>>>>>> Windows were fired on the Event Dispatch Thread. With this change,
>>>>>>> property "win.xpstyle.themeActive" change is fired on the toolkit
>>>>>>> thread; all other properties are changed on the EDT as before.
>>>>>>> 
>>>>>>> 
>>>>>>> Regards,
>>>>>>> Alexey.
>>>>> 
>>> 
>> 
> 


From petr.pchelko at oracle.com  Thu Jun  5 07:59:38 2014
From: petr.pchelko at oracle.com (Petr Pchelko)
Date: Thu, 5 Jun 2014 11:59:38 +0400
Subject: <AWT Dev> [9] Review Request: 8044516 [macosx]
	ScreenPopupFactory uses native method that could be avoided
In-Reply-To: <538C7A18.20906@oracle.com>
References: <A7715964-72E8-4957-A0B9-C61BF35D0830@oracle.com>
	<538C7401.7040801@oracle.com>
	<88DA5BEA-3453-4517-AC41-3213A2D72AF1@oracle.com>
	<538C7896.1040208@oracle.com> <538C7A18.20906@oracle.com>
Message-ID: <8B5B12E3-616F-45C3-8634-53CDBFED592E@oracle.com>

Hello, 

Could somebody please make a second review on this simple cleanup?

Thank you.
With best regards. Petr.

On 02 ???? 2014 ?., at 17:20, Sergey Bylokhov <Sergey.Bylokhov at oracle.com> wrote:

> On 6/2/14 5:13 PM, Sergey Bylokhov wrote:
>> On 6/2/14 5:03 PM, Petr Pchelko wrote:
>>> Hello, Sergey.
>>> 
>>>> Should we use getPopup() name, since it should be simple accessor?
>>> I thought about it. The HEAVYWEIGHT_POPUP constant is package-private, so if we use 
>>> simple getPopup we would need a second method "getHeavyweightPopupType". So I was
>>> not quite sure which is better - use 2 methods or merge them in a single one. I can change
>>> it if you think 2 methods would be better.
>> Then why do not call PopupFactory.getHeavyWeightPopup() directly?
> Look like getPopup() covers headless situation as well. Then the fix looks good.
> Thanks.
>>> 
>>> With best regards. Petr.
>>> 
>>> On 02 ???? 2014 ?., at 16:54, Sergey Bylokhov <Sergey.Bylokhov at oracle.com> wrote:
>>> 
>>>> Hi, Petr.
>>>> Should we use getPopup() name, since it should be simple accessor?
>>>> 
>>>> On 6/2/14 4:50 PM, Petr Pchelko wrote:
>>>>> Hello, AWT Team.
>>>>> 
>>>>> Please review a simple cleanup fix for the issue:
>>>>> https://bugs.openjdk.java.net/browse/JDK-8044516
>>>>> The fix is available at:
>>>>> http://cr.openjdk.java.net/~pchelko/9/8044516/webrev/
>>>>> 
>>>>> No need to go through native to call a method. Accessor pattern works 
>>>>> fine here, so we can avoid loading a native library.
>>>>> 
>>>>> Thank you.
>>>>> With best regards. Petr.
>>>> 
>>>> 
>>>> -- 
>>>> 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/20140605/a6d778a1/attachment-0001.html>

From alexey.ivanov at oracle.com  Thu Jun  5 07:57:29 2014
From: alexey.ivanov at oracle.com (Alexey Ivanov)
Date: Thu, 05 Jun 2014 11:57:29 +0400
Subject: <AWT Dev> <Swing Dev> [9] Review request for JDK-8039383: NPE
 when changing Windows Theme
In-Reply-To: <0FE09EB0-B3A1-43F4-AE48-401DD55F5B09@oracle.com>
References: <5350DDBC.30603@oracle.com>	<5351143C.8010100@oracle.com>	<53513B5B.4050104@oracle.com>	<53513C26.9060305@oracle.com>
	<53590232.4080703@oracle.com> <536899D1.1020501@oracle.com>
	<53900FA7.8040508@oracle.com>
	<0FE09EB0-B3A1-43F4-AE48-401DD55F5B09@oracle.com>
Message-ID: <539022E9.7070907@oracle.com>

Hello Petr,

Thank you for your comments.

1. Sure, I'll remove the comment before the change set is pushed.
2. No, I didn't try stub XPStyle object. First of all, UI delegates 
decide what painting method to use depending on whether XPStyle.getXP() 
returns null or not. If XPStyle.getXP() always returns non-null value, 
we'll have re-implement all UI delegates for Windows plaf, and I believe 
it would result in larger changeset. Additionally, some classes fallback 
to inherited behavior where XPStyle.getXP() is not available.
Another reason is that UI delegates cache Skins: those objects shouldn't 
paint where theming is unavailable.
3. No, I haven't filed any bugs yet. I'll file all the issues I've found 
in the nearest future.

Regards,
Alexey.

On 05.06.2014 11:08, Petr Pchelko wrote:
> Hello, Alexey.
>
> A couple of comments:
> 1. ThemeReader:64 - I suggest to remove that comment as it does not add any value. The variable name is self explanatory.
> 2. XPStyle - did you try providing a stub XPStyle object instead of changing many of it's methods? Do I understand correctly that this
> is not possible because XPstyle is cached in many place is our code?
> 3. In offline discussion you've mentioned that you've found another related issue. Did you have a chance to file a bug about it?
>
> Thank you.
> With best regards. Petr.
>
> On 05 ???? 2014 ?., at 10:35, Alexey Ivanov <alexey.ivanov at oracle.com> wrote:
>
>> Hi AWT and Swing teams,
>>
>> Could you please review the updated fix:
>> http://cr.openjdk.java.net/~aivanov/8039383/jdk9/webrev.03/
>>
>>
>> What has changed since version .02?
>>
>> During additional testing, I found another scenario where NPE was thrown. So the new version adds more checks to prevent access to XPStyle and ThemeReader where Windows visual styles become unavailable.
>>
>> As in previous version, getters in XPStyle class check for null values and return dummy defaults if ThemeReader returned null. Skin painters also check whether theming is still available before asking ThemeReader to paint.
>>
>> Access to XPStyle.xp instance is blocked as soon as user switched themes. The object will be cleaned when the corresponding PropertyChangeEvent is handled by Swing.
>>
>> Thank you,
>> Alexey.
>>
>> On 06.05.2014 12:14, Alexey Ivanov wrote:
>>> Hi AWT and Swing teams,
>>>
>>> Could you please review the updated fix:
>>> http://cr.openjdk.java.net/~dmarkov/8039383/jdk9/webrev.02/
>>>
>>>
>>> What has changed since version .01?
>>>
>>> The issue was still reproducible with the .01 version of the fix, however it was harder to reproduce.
>>>
>>> So in version .02 I added checks for null where possible. If theme becomes unavailable, a dummy value will be used; this way applications will be more stable. As soon as the theme change events are handled, the entire UI will update properly.
>>>
>>> Thank you,
>>> Alexey.
>>>
>>> On 24.04.2014 16:23, Alexey Ivanov wrote:
>>>> Hi Anthony, AWT and Swing teams,
>>>>
>>>> Here's the updated fix:
>>>> http://cr.openjdk.java.net/~dmarkov/8039383/jdk9/webrev.01/
>>>>
>>>> Description:
>>>> In the new version of the fix, I use a new xpstyleEnabled field of AtomicBoolean in WToolkit to track the current value of "win.xpstyle.themeActive" desktop property. Its value is updated in windowsSettingChange() and in updateProperties().
>>>> XPStyle.getXP() checks its cached value in themeActive and the current value in WToolkit; if the value changes, it schedules updateAllUIs and invalidates the current style right away, so that components would not access data from the theme that became unavailable.
>>>> Two functions in ThemeReader also check this special field from WToolkit which prevents throwing InternalError when paint is called before theme change is fully handled.
>>>>
>>>> Before updateAllUIs is invoked, it's possible that application will paint with some values cached from the previous theme. Usually it happens before "Theme change" dialog disappears from the screen, at least I noticed no UI glitches during normal theme change.
>>>>
>>>>
>>>> Regression test:
>>>> No regression test is provided due to its complexity. Additionally, 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.
>>>>
>>>>
>>>> Thank you,
>>>> Alexey.
>>>>
>>>> On 18.04.2014 18:52, Anthony Petrov wrote:
>>>>> Hi Alexey,
>>>>>
>>>>> No, unfortunately I don't have any suggestions right now.
>>>>>
>>>>> As for allowing executing user code on the toolkit thread, we can't accept such a fix. Sorry about that.
>>>>>
>>>>> -- 
>>>>> best regards,
>>>>> Anthony
>>>>>
>>>>> On 4/18/2014 6:48 PM, Alexey Ivanov wrote:
>>>>>> Hi Anthony,
>>>>>>
>>>>>> Thank you for your review.
>>>>>>
>>>>>> Yes, user code can install a property change listener... It was my
>>>>>> concern too, that's why I explicitly noted about this.
>>>>>>
>>>>>> Do you have any suggestion how this situation can be handled?
>>>>>> Is it a general rule that all desktop property change listeners must be
>>>>>> called on EDT?
>>>>>>
>>>>>>
>>>>>> Thanks,
>>>>>> Alexey.
>>>>>>
>>>>>> On 18.04.2014 16:02, Anthony Petrov wrote:
>>>>>>> Hi Alexey,
>>>>>>>
>>>>>>>> With this change, property "win.xpstyle.themeActive" change is fired
>>>>>>>> on the toolkit thread
>>>>>>> Is it possible to install a change listener for this property from
>>>>>>> user code, and hence eventually allow executing some user code on the
>>>>>>> toolkit thread with your fix?
>>>>>>>
>>>>>>> -- 
>>>>>>> best regards,
>>>>>>> Anthony
>>>>>>>
>>>>>>> On 4/18/2014 12:09 PM, Alexey Ivanov wrote:
>>>>>>>> Hello Swing and AWT teams,
>>>>>>>>
>>>>>>>> Could you please review the fix for jdk9:
>>>>>>>>      bug: https://bugs.openjdk.java.net/browse/JDK-8039383
>>>>>>>>      webrev: http://cr.openjdk.java.net/~dmarkov/8039383/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 "cached" in XPStyle object. When the theme is
>>>>>>>> switched to a classic one, HTHEME handle becomes unavailable and data
>>>>>>>> cannot be accessed from the theme any more. The change in theme in
>>>>>>>> posted to EDT via invokeLater. At the same time, the UI needs to repaint
>>>>>>>> itself as soon as Windows changed the theme, and paint code is often
>>>>>>>> called before the theme change is handled in Java. This leads to NPE and
>>>>>>>> InternalError as the code tries to access the data that has become
>>>>>>>> unavailable.
>>>>>>>>
>>>>>>>> The fix:
>>>>>>>> Update "win.xpstyle.themeActive" desktop property and invalidate the
>>>>>>>> cached XPStyle as soon as windowsSettingChange() is called from native
>>>>>>>> code. Thus when Swing code needs to access theme data, it will see no
>>>>>>>> theme is available and will fallback to classic painting.
>>>>>>>>
>>>>>>>> Note: Before the fix, PropertyChangeEvents for desktop properties in
>>>>>>>> Windows were fired on the Event Dispatch Thread. With this change,
>>>>>>>> property "win.xpstyle.themeActive" change is fired on the toolkit
>>>>>>>> thread; all other properties are changed on the EDT as before.
>>>>>>>>
>>>>>>>>
>>>>>>>> Regards,
>>>>>>>> Alexey.


From petr.pchelko at oracle.com  Thu Jun  5 08:16:44 2014
From: petr.pchelko at oracle.com (Petr Pchelko)
Date: Thu, 5 Jun 2014 12:16:44 +0400
Subject: <AWT Dev> <Swing Dev> [9] Review request for JDK-8039383: NPE
	when changing Windows Theme
In-Reply-To: <539022E9.7070907@oracle.com>
References: <5350DDBC.30603@oracle.com>	<5351143C.8010100@oracle.com>	<53513B5B.4050104@oracle.com>	<53513C26.9060305@oracle.com>
	<53590232.4080703@oracle.com> <536899D1.1020501@oracle.com>
	<53900FA7.8040508@oracle.com>
	<0FE09EB0-B3A1-43F4-AE48-401DD55F5B09@oracle.com>
	<539022E9.7070907@oracle.com>
Message-ID: <4240D39D-748C-483F-B447-1FAF6DFA25E4@oracle.com>

Thank you for clarifications, I've been most interested in #2 obviously.

The fix looks good to me.

With best regards. Petr.

On 05 ???? 2014 ?., at 11:57, Alexey Ivanov <alexey.ivanov at oracle.com> wrote:

> Hello Petr,
> 
> Thank you for your comments.
> 
> 1. Sure, I'll remove the comment before the change set is pushed.
> 2. No, I didn't try stub XPStyle object. First of all, UI delegates decide what painting method to use depending on whether XPStyle.getXP() returns null or not. If XPStyle.getXP() always returns non-null value, we'll have re-implement all UI delegates for Windows plaf, and I believe it would result in larger changeset. Additionally, some classes fallback to inherited behavior where XPStyle.getXP() is not available.
> Another reason is that UI delegates cache Skins: those objects shouldn't paint where theming is unavailable.
> 3. No, I haven't filed any bugs yet. I'll file all the issues I've found in the nearest future.
> 
> Regards,
> Alexey.
> 
> On 05.06.2014 11:08, Petr Pchelko wrote:
>> Hello, Alexey.
>> 
>> A couple of comments:
>> 1. ThemeReader:64 - I suggest to remove that comment as it does not add any value. The variable name is self explanatory.
>> 2. XPStyle - did you try providing a stub XPStyle object instead of changing many of it's methods? Do I understand correctly that this
>> is not possible because XPstyle is cached in many place is our code?
>> 3. In offline discussion you've mentioned that you've found another related issue. Did you have a chance to file a bug about it?
>> 
>> Thank you.
>> With best regards. Petr.
>> 
>> On 05 ???? 2014 ?., at 10:35, Alexey Ivanov <alexey.ivanov at oracle.com> wrote:
>> 
>>> Hi AWT and Swing teams,
>>> 
>>> Could you please review the updated fix:
>>> http://cr.openjdk.java.net/~aivanov/8039383/jdk9/webrev.03/
>>> 
>>> 
>>> What has changed since version .02?
>>> 
>>> During additional testing, I found another scenario where NPE was thrown. So the new version adds more checks to prevent access to XPStyle and ThemeReader where Windows visual styles become unavailable.
>>> 
>>> As in previous version, getters in XPStyle class check for null values and return dummy defaults if ThemeReader returned null. Skin painters also check whether theming is still available before asking ThemeReader to paint.
>>> 
>>> Access to XPStyle.xp instance is blocked as soon as user switched themes. The object will be cleaned when the corresponding PropertyChangeEvent is handled by Swing.
>>> 
>>> Thank you,
>>> Alexey.
>>> 
>>> On 06.05.2014 12:14, Alexey Ivanov wrote:
>>>> Hi AWT and Swing teams,
>>>> 
>>>> Could you please review the updated fix:
>>>> http://cr.openjdk.java.net/~dmarkov/8039383/jdk9/webrev.02/
>>>> 
>>>> 
>>>> What has changed since version .01?
>>>> 
>>>> The issue was still reproducible with the .01 version of the fix, however it was harder to reproduce.
>>>> 
>>>> So in version .02 I added checks for null where possible. If theme becomes unavailable, a dummy value will be used; this way applications will be more stable. As soon as the theme change events are handled, the entire UI will update properly.
>>>> 
>>>> Thank you,
>>>> Alexey.
>>>> 
>>>> On 24.04.2014 16:23, Alexey Ivanov wrote:
>>>>> Hi Anthony, AWT and Swing teams,
>>>>> 
>>>>> Here's the updated fix:
>>>>> http://cr.openjdk.java.net/~dmarkov/8039383/jdk9/webrev.01/
>>>>> 
>>>>> Description:
>>>>> In the new version of the fix, I use a new xpstyleEnabled field of AtomicBoolean in WToolkit to track the current value of "win.xpstyle.themeActive" desktop property. Its value is updated in windowsSettingChange() and in updateProperties().
>>>>> XPStyle.getXP() checks its cached value in themeActive and the current value in WToolkit; if the value changes, it schedules updateAllUIs and invalidates the current style right away, so that components would not access data from the theme that became unavailable.
>>>>> Two functions in ThemeReader also check this special field from WToolkit which prevents throwing InternalError when paint is called before theme change is fully handled.
>>>>> 
>>>>> Before updateAllUIs is invoked, it's possible that application will paint with some values cached from the previous theme. Usually it happens before "Theme change" dialog disappears from the screen, at least I noticed no UI glitches during normal theme change.
>>>>> 
>>>>> 
>>>>> Regression test:
>>>>> No regression test is provided due to its complexity. Additionally, 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.
>>>>> 
>>>>> 
>>>>> Thank you,
>>>>> Alexey.
>>>>> 
>>>>> On 18.04.2014 18:52, Anthony Petrov wrote:
>>>>>> Hi Alexey,
>>>>>> 
>>>>>> No, unfortunately I don't have any suggestions right now.
>>>>>> 
>>>>>> As for allowing executing user code on the toolkit thread, we can't accept such a fix. Sorry about that.
>>>>>> 
>>>>>> -- 
>>>>>> best regards,
>>>>>> Anthony
>>>>>> 
>>>>>> On 4/18/2014 6:48 PM, Alexey Ivanov wrote:
>>>>>>> Hi Anthony,
>>>>>>> 
>>>>>>> Thank you for your review.
>>>>>>> 
>>>>>>> Yes, user code can install a property change listener... It was my
>>>>>>> concern too, that's why I explicitly noted about this.
>>>>>>> 
>>>>>>> Do you have any suggestion how this situation can be handled?
>>>>>>> Is it a general rule that all desktop property change listeners must be
>>>>>>> called on EDT?
>>>>>>> 
>>>>>>> 
>>>>>>> Thanks,
>>>>>>> Alexey.
>>>>>>> 
>>>>>>> On 18.04.2014 16:02, Anthony Petrov wrote:
>>>>>>>> Hi Alexey,
>>>>>>>> 
>>>>>>>>> With this change, property "win.xpstyle.themeActive" change is fired
>>>>>>>>> on the toolkit thread
>>>>>>>> Is it possible to install a change listener for this property from
>>>>>>>> user code, and hence eventually allow executing some user code on the
>>>>>>>> toolkit thread with your fix?
>>>>>>>> 
>>>>>>>> -- 
>>>>>>>> best regards,
>>>>>>>> Anthony
>>>>>>>> 
>>>>>>>> On 4/18/2014 12:09 PM, Alexey Ivanov wrote:
>>>>>>>>> Hello Swing and AWT teams,
>>>>>>>>> 
>>>>>>>>> Could you please review the fix for jdk9:
>>>>>>>>>     bug: https://bugs.openjdk.java.net/browse/JDK-8039383
>>>>>>>>>     webrev: http://cr.openjdk.java.net/~dmarkov/8039383/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 "cached" in XPStyle object. When the theme is
>>>>>>>>> switched to a classic one, HTHEME handle becomes unavailable and data
>>>>>>>>> cannot be accessed from the theme any more. The change in theme in
>>>>>>>>> posted to EDT via invokeLater. At the same time, the UI needs to repaint
>>>>>>>>> itself as soon as Windows changed the theme, and paint code is often
>>>>>>>>> called before the theme change is handled in Java. This leads to NPE and
>>>>>>>>> InternalError as the code tries to access the data that has become
>>>>>>>>> unavailable.
>>>>>>>>> 
>>>>>>>>> The fix:
>>>>>>>>> Update "win.xpstyle.themeActive" desktop property and invalidate the
>>>>>>>>> cached XPStyle as soon as windowsSettingChange() is called from native
>>>>>>>>> code. Thus when Swing code needs to access theme data, it will see no
>>>>>>>>> theme is available and will fallback to classic painting.
>>>>>>>>> 
>>>>>>>>> Note: Before the fix, PropertyChangeEvents for desktop properties in
>>>>>>>>> Windows were fired on the Event Dispatch Thread. With this change,
>>>>>>>>> property "win.xpstyle.themeActive" change is fired on the toolkit
>>>>>>>>> thread; all other properties are changed on the EDT as before.
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> Regards,
>>>>>>>>> Alexey.
> 


From anthony.petrov at oracle.com  Thu Jun  5 08:53:47 2014
From: anthony.petrov at oracle.com (Anthony Petrov)
Date: Thu, 05 Jun 2014 12:53:47 +0400
Subject: <AWT Dev> [9] Review Request: 8044516 [macosx]
 ScreenPopupFactory uses native method that could be avoided
In-Reply-To: <8B5B12E3-616F-45C3-8634-53CDBFED592E@oracle.com>
References: <A7715964-72E8-4957-A0B9-C61BF35D0830@oracle.com>
	<538C7401.7040801@oracle.com>
	<88DA5BEA-3453-4517-AC41-3213A2D72AF1@oracle.com>
	<538C7896.1040208@oracle.com> <538C7A18.20906@oracle.com>
	<8B5B12E3-616F-45C3-8634-53CDBFED592E@oracle.com>
Message-ID: <5390301B.6020007@oracle.com>

Hi Petr,

I'm not really an expert in this code, but technically all the changes 
look fine to me. Approved.

--
best regards,
Anthony

On 6/5/2014 11:59 AM, Petr Pchelko wrote:
> Hello,
>
> Could somebody please make a second review on this simple cleanup?
>
> Thank you.
> With best regards. Petr.
>
> On 02 ???? 2014 ?., at 17:20, Sergey Bylokhov
> <Sergey.Bylokhov at oracle.com <mailto:Sergey.Bylokhov at oracle.com>> wrote:
>
>> On 6/2/14 5:13 PM, Sergey Bylokhov wrote:
>>> On 6/2/14 5:03 PM, Petr Pchelko wrote:
>>>> Hello, Sergey.
>>>>
>>>>> Should we use getPopup() name, since it should be simple accessor?
>>>> I thought about it. The HEAVYWEIGHT_POPUP constant is
>>>> package-private, so if we use
>>>> simple getPopup we would need a second method
>>>> "getHeavyweightPopupType". So I was
>>>> not quite sure which is better - use 2 methods or merge them in a
>>>> single one. I can change
>>>> it if you think 2 methods would be better.
>>> Then why do not callPopupFactory.getHeavyWeightPopup() directly?
>> Look like getPopup() covers headless situation as well. Then the fix
>> looks good.
>> Thanks.
>>>>
>>>> With best regards. Petr.
>>>>
>>>> On 02 ???? 2014 ?., at 16:54, Sergey Bylokhov
>>>> <Sergey.Bylokhov at oracle.com <mailto:Sergey.Bylokhov at oracle.com>> wrote:
>>>>
>>>>> Hi,Petr.
>>>>> Should we use getPopup() name, since it should be simple accessor?
>>>>>
>>>>> On 6/2/14 4:50 PM, Petr Pchelko wrote:
>>>>>> Hello, AWT Team.
>>>>>>
>>>>>> Please review a simple cleanup fix for the issue:
>>>>>> https://bugs.openjdk.java.net/browse/JDK-8044516
>>>>>> The fix is available at:
>>>>>> http://cr.openjdk.java.net/~pchelko/9/8044516/webrev/
>>>>>>
>>>>>> No need to go through native to call a method. Accessor pattern works
>>>>>> fine here, so we can avoid loading a native library.
>>>>>>
>>>>>> Thank you.
>>>>>> With best regards. Petr.
>>>>>
>>>>>
>>>>> --
>>>>> Best regards, Sergey.
>>>>
>>>
>>>
>>> --
>>> Best regards, Sergey.
>>
>>
>> --
>> Best regards, Sergey.
>

From alexander.zvegintsev at oracle.com  Thu Jun  5 15:59:08 2014
From: alexander.zvegintsev at oracle.com (Alexander Zvegintsev)
Date: Thu, 05 Jun 2014 19:59:08 +0400
Subject: <AWT Dev> [9] Review Request: 8039901
 jdk/src/share/classes/com/sun/media/sound/services/<platform> appear not to
 be used
In-Reply-To: <538F28E0.8090804@oracle.com>
References: <538F28E0.8090804@oracle.com>
Message-ID: <539093CC.1040506@oracle.com>

Hello Sergey,

the fix looks good to me.

Thanks,

Alexander.

On 06/04/2014 06:10 PM, Sergey Bylokhov wrote:
> Hello.
> Please review the fix for jdk 9.
> The old sound configuration files were removed, its were used in the 
> old (beatnik) sound engine in old build system.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8039901
> Webrev can be found at: 
> http://cr.openjdk.java.net/~serb/8039901/webrev.00
>


From anthony.petrov at oracle.com  Thu Jun  5 21:07:54 2014
From: anthony.petrov at oracle.com (Anthony Petrov)
Date: Fri, 06 Jun 2014 01:07:54 +0400
Subject: <AWT Dev> <Swing Dev> [9] Review request for JDK-8039383: NPE
 when changing Windows Theme
In-Reply-To: <4240D39D-748C-483F-B447-1FAF6DFA25E4@oracle.com>
References: <5350DDBC.30603@oracle.com>	<5351143C.8010100@oracle.com>	<53513B5B.4050104@oracle.com>	<53513C26.9060305@oracle.com>	<53590232.4080703@oracle.com>
	<536899D1.1020501@oracle.com>	<53900FA7.8040508@oracle.com>	<0FE09EB0-B3A1-43F4-AE48-401DD55F5B09@oracle.com>	<539022E9.7070907@oracle.com>
	<4240D39D-748C-483F-B447-1FAF6DFA25E4@oracle.com>
Message-ID: <5390DC2A.1030502@oracle.com>

Hi Alexey,

In WToolkit.java you're removing the synchronized modifier from the 
private updateProperties() method. And it looks like the method itself 
does allow for calling from multiple threads. So I'm concerned about the 
lack of synchronization in this method. Was the removal intentional? How 
is the method supposed to work now when called from multiple threads?

--
best regards,
Anthony

On 6/5/2014 12:16 PM, Petr Pchelko wrote:
> Thank you for clarifications, I've been most interested in #2 obviously.
>
> The fix looks good to me.
>
> With best regards. Petr.
>
> On 05 ???? 2014 ?., at 11:57, Alexey Ivanov <alexey.ivanov at oracle.com> wrote:
>
>> Hello Petr,
>>
>> Thank you for your comments.
>>
>> 1. Sure, I'll remove the comment before the change set is pushed.
>> 2. No, I didn't try stub XPStyle object. First of all, UI delegates decide what painting method to use depending on whether XPStyle.getXP() returns null or not. If XPStyle.getXP() always returns non-null value, we'll have re-implement all UI delegates for Windows plaf, and I believe it would result in larger changeset. Additionally, some classes fallback to inherited behavior where XPStyle.getXP() is not available.
>> Another reason is that UI delegates cache Skins: those objects shouldn't paint where theming is unavailable.
>> 3. No, I haven't filed any bugs yet. I'll file all the issues I've found in the nearest future.
>>
>> Regards,
>> Alexey.
>>
>> On 05.06.2014 11:08, Petr Pchelko wrote:
>>> Hello, Alexey.
>>>
>>> A couple of comments:
>>> 1. ThemeReader:64 - I suggest to remove that comment as it does not add any value. The variable name is self explanatory.
>>> 2. XPStyle - did you try providing a stub XPStyle object instead of changing many of it's methods? Do I understand correctly that this
>>> is not possible because XPstyle is cached in many place is our code?
>>> 3. In offline discussion you've mentioned that you've found another related issue. Did you have a chance to file a bug about it?
>>>
>>> Thank you.
>>> With best regards. Petr.
>>>
>>> On 05 ???? 2014 ?., at 10:35, Alexey Ivanov <alexey.ivanov at oracle.com> wrote:
>>>
>>>> Hi AWT and Swing teams,
>>>>
>>>> Could you please review the updated fix:
>>>> http://cr.openjdk.java.net/~aivanov/8039383/jdk9/webrev.03/
>>>>
>>>>
>>>> What has changed since version .02?
>>>>
>>>> During additional testing, I found another scenario where NPE was thrown. So the new version adds more checks to prevent access to XPStyle and ThemeReader where Windows visual styles become unavailable.
>>>>
>>>> As in previous version, getters in XPStyle class check for null values and return dummy defaults if ThemeReader returned null. Skin painters also check whether theming is still available before asking ThemeReader to paint.
>>>>
>>>> Access to XPStyle.xp instance is blocked as soon as user switched themes. The object will be cleaned when the corresponding PropertyChangeEvent is handled by Swing.
>>>>
>>>> Thank you,
>>>> Alexey.
>>>>
>>>> On 06.05.2014 12:14, Alexey Ivanov wrote:
>>>>> Hi AWT and Swing teams,
>>>>>
>>>>> Could you please review the updated fix:
>>>>> http://cr.openjdk.java.net/~dmarkov/8039383/jdk9/webrev.02/
>>>>>
>>>>>
>>>>> What has changed since version .01?
>>>>>
>>>>> The issue was still reproducible with the .01 version of the fix, however it was harder to reproduce.
>>>>>
>>>>> So in version .02 I added checks for null where possible. If theme becomes unavailable, a dummy value will be used; this way applications will be more stable. As soon as the theme change events are handled, the entire UI will update properly.
>>>>>
>>>>> Thank you,
>>>>> Alexey.
>>>>>
>>>>> On 24.04.2014 16:23, Alexey Ivanov wrote:
>>>>>> Hi Anthony, AWT and Swing teams,
>>>>>>
>>>>>> Here's the updated fix:
>>>>>> http://cr.openjdk.java.net/~dmarkov/8039383/jdk9/webrev.01/
>>>>>>
>>>>>> Description:
>>>>>> In the new version of the fix, I use a new xpstyleEnabled field of AtomicBoolean in WToolkit to track the current value of "win.xpstyle.themeActive" desktop property. Its value is updated in windowsSettingChange() and in updateProperties().
>>>>>> XPStyle.getXP() checks its cached value in themeActive and the current value in WToolkit; if the value changes, it schedules updateAllUIs and invalidates the current style right away, so that components would not access data from the theme that became unavailable.
>>>>>> Two functions in ThemeReader also check this special field from WToolkit which prevents throwing InternalError when paint is called before theme change is fully handled.
>>>>>>
>>>>>> Before updateAllUIs is invoked, it's possible that application will paint with some values cached from the previous theme. Usually it happens before "Theme change" dialog disappears from the screen, at least I noticed no UI glitches during normal theme change.
>>>>>>
>>>>>>
>>>>>> Regression test:
>>>>>> No regression test is provided due to its complexity. Additionally, 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.
>>>>>>
>>>>>>
>>>>>> Thank you,
>>>>>> Alexey.
>>>>>>
>>>>>> On 18.04.2014 18:52, Anthony Petrov wrote:
>>>>>>> Hi Alexey,
>>>>>>>
>>>>>>> No, unfortunately I don't have any suggestions right now.
>>>>>>>
>>>>>>> As for allowing executing user code on the toolkit thread, we can't accept such a fix. Sorry about that.
>>>>>>>
>>>>>>> --
>>>>>>> best regards,
>>>>>>> Anthony
>>>>>>>
>>>>>>> On 4/18/2014 6:48 PM, Alexey Ivanov wrote:
>>>>>>>> Hi Anthony,
>>>>>>>>
>>>>>>>> Thank you for your review.
>>>>>>>>
>>>>>>>> Yes, user code can install a property change listener... It was my
>>>>>>>> concern too, that's why I explicitly noted about this.
>>>>>>>>
>>>>>>>> Do you have any suggestion how this situation can be handled?
>>>>>>>> Is it a general rule that all desktop property change listeners must be
>>>>>>>> called on EDT?
>>>>>>>>
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>> Alexey.
>>>>>>>>
>>>>>>>> On 18.04.2014 16:02, Anthony Petrov wrote:
>>>>>>>>> Hi Alexey,
>>>>>>>>>
>>>>>>>>>> With this change, property "win.xpstyle.themeActive" change is fired
>>>>>>>>>> on the toolkit thread
>>>>>>>>> Is it possible to install a change listener for this property from
>>>>>>>>> user code, and hence eventually allow executing some user code on the
>>>>>>>>> toolkit thread with your fix?
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> best regards,
>>>>>>>>> Anthony
>>>>>>>>>
>>>>>>>>> On 4/18/2014 12:09 PM, Alexey Ivanov wrote:
>>>>>>>>>> Hello Swing and AWT teams,
>>>>>>>>>>
>>>>>>>>>> Could you please review the fix for jdk9:
>>>>>>>>>>      bug: https://bugs.openjdk.java.net/browse/JDK-8039383
>>>>>>>>>>      webrev: http://cr.openjdk.java.net/~dmarkov/8039383/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 "cached" in XPStyle object. When the theme is
>>>>>>>>>> switched to a classic one, HTHEME handle becomes unavailable and data
>>>>>>>>>> cannot be accessed from the theme any more. The change in theme in
>>>>>>>>>> posted to EDT via invokeLater. At the same time, the UI needs to repaint
>>>>>>>>>> itself as soon as Windows changed the theme, and paint code is often
>>>>>>>>>> called before the theme change is handled in Java. This leads to NPE and
>>>>>>>>>> InternalError as the code tries to access the data that has become
>>>>>>>>>> unavailable.
>>>>>>>>>>
>>>>>>>>>> The fix:
>>>>>>>>>> Update "win.xpstyle.themeActive" desktop property and invalidate the
>>>>>>>>>> cached XPStyle as soon as windowsSettingChange() is called from native
>>>>>>>>>> code. Thus when Swing code needs to access theme data, it will see no
>>>>>>>>>> theme is available and will fallback to classic painting.
>>>>>>>>>>
>>>>>>>>>> Note: Before the fix, PropertyChangeEvents for desktop properties in
>>>>>>>>>> Windows were fired on the Event Dispatch Thread. With this change,
>>>>>>>>>> property "win.xpstyle.themeActive" change is fired on the toolkit
>>>>>>>>>> thread; all other properties are changed on the EDT as before.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Regards,
>>>>>>>>>> Alexey.
>>
>

From henry.jen at oracle.com  Thu Jun  5 23:51:27 2014
From: henry.jen at oracle.com (Henry Jen)
Date: Thu, 05 Jun 2014 16:51:27 -0700
Subject: <AWT Dev> RFR: 8044551,
 8044396: Fix raw and unchecked lint warnings in platform-specific
 sun.awt and sun.java2d
Message-ID: <5391027F.8020100@oracle.com>

Hi,

Please review a follow-up to clean up rawtype and unchecked warnings in 
platform-specific code.

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

Webrev:
http://cr.openjdk.java.net/~henryjen/jdk9/8044551/0/webrev/

Cheers,
Henry

From joe.darcy at oracle.com  Fri Jun  6 02:34:29 2014
From: joe.darcy at oracle.com (Joe Darcy)
Date: Thu, 05 Jun 2014 19:34:29 -0700
Subject: <AWT Dev> RFR: 8044551,
 8044396: Fix raw and unchecked lint warnings in platform-specific
 sun.awt and sun.java2d
In-Reply-To: <5391027F.8020100@oracle.com>
References: <5391027F.8020100@oracle.com>
Message-ID: <539128B5.9060907@oracle.com>

Hi Henry,

 From a quick look, the changes seem fine.

Thanks,

-Joe

On 06/05/2014 04:51 PM, Henry Jen wrote:
> Hi,
>
> Please review a follow-up to clean up rawtype and unchecked warnings 
> in platform-specific code.
>
> Bug:
> https://bugs.openjdk.java.net/browse/JDK-8044396
> https://bugs.openjdk.java.net/browse/JDK-8044551
>
> Webrev:
> http://cr.openjdk.java.net/~henryjen/jdk9/8044551/0/webrev/
>
> Cheers,
> Henry


From alexey.ivanov at oracle.com  Fri Jun  6 08:16:36 2014
From: alexey.ivanov at oracle.com (Alexey Ivanov)
Date: Fri, 06 Jun 2014 12:16:36 +0400
Subject: <AWT Dev> <Swing Dev> [9] Review request for JDK-8039383: NPE
 when changing Windows Theme
In-Reply-To: <5390DC2A.1030502@oracle.com>
References: <5350DDBC.30603@oracle.com>	<5351143C.8010100@oracle.com>	<53513B5B.4050104@oracle.com>	<53513C26.9060305@oracle.com>	<53590232.4080703@oracle.com>
	<536899D1.1020501@oracle.com>	<53900FA7.8040508@oracle.com>	<0FE09EB0-B3A1-43F4-AE48-401DD55F5B09@oracle.com>	<539022E9.7070907@oracle.com>
	<4240D39D-748C-483F-B447-1FAF6DFA25E4@oracle.com>
	<5390DC2A.1030502@oracle.com>
Message-ID: <539178E4.6060101@oracle.com>

Hi Anthony,

Thank you for your review.

I've removed synchronized modifier from updateProperties() method which 
protected access to wprops field. Now this field is accessed from 
synchronized methods lazilyInitWProps() and getWProps(); 
setDesktopProperty also has proper synchronization - that was my 
reasoning for removing synchronized.

But you're right, it was not the right decision as the update loop now 
could execute simultaneously which is undesirable. I'll put synchronized 
modifier to updateProperties() method.

Regards,
Alexey.

On 06.06.2014 1:07, Anthony Petrov wrote:
> Hi Alexey,
>
> In WToolkit.java you're removing the synchronized modifier from the 
> private updateProperties() method. And it looks like the method itself 
> does allow for calling from multiple threads. So I'm concerned about 
> the lack of synchronization in this method. Was the removal 
> intentional? How is the method supposed to work now when called from 
> multiple threads?
>
> -- 
> best regards,
> Anthony
>
> On 6/5/2014 12:16 PM, Petr Pchelko wrote:
>> Thank you for clarifications, I've been most interested in #2 obviously.
>>
>> The fix looks good to me.
>>
>> With best regards. Petr.
>>
>> On 05 ???? 2014 ?., at 11:57, Alexey Ivanov 
>> <alexey.ivanov at oracle.com> wrote:
>>
>>> Hello Petr,
>>>
>>> Thank you for your comments.
>>>
>>> 1. Sure, I'll remove the comment before the change set is pushed.
>>> 2. No, I didn't try stub XPStyle object. First of all, UI delegates 
>>> decide what painting method to use depending on whether 
>>> XPStyle.getXP() returns null or not. If XPStyle.getXP() always 
>>> returns non-null value, we'll have re-implement all UI delegates for 
>>> Windows plaf, and I believe it would result in larger changeset. 
>>> Additionally, some classes fallback to inherited behavior where 
>>> XPStyle.getXP() is not available.
>>> Another reason is that UI delegates cache Skins: those objects 
>>> shouldn't paint where theming is unavailable.
>>> 3. No, I haven't filed any bugs yet. I'll file all the issues I've 
>>> found in the nearest future.
>>>
>>> Regards,
>>> Alexey.
>>>
>>> On 05.06.2014 11:08, Petr Pchelko wrote:
>>>> Hello, Alexey.
>>>>
>>>> A couple of comments:
>>>> 1. ThemeReader:64 - I suggest to remove that comment as it does not 
>>>> add any value. The variable name is self explanatory.
>>>> 2. XPStyle - did you try providing a stub XPStyle object instead of 
>>>> changing many of it's methods? Do I understand correctly that this
>>>> is not possible because XPstyle is cached in many place is our code?
>>>> 3. In offline discussion you've mentioned that you've found another 
>>>> related issue. Did you have a chance to file a bug about it?
>>>>
>>>> Thank you.
>>>> With best regards. Petr.
>>>>
>>>> On 05 ???? 2014 ?., at 10:35, Alexey Ivanov 
>>>> <alexey.ivanov at oracle.com> wrote:
>>>>
>>>>> Hi AWT and Swing teams,
>>>>>
>>>>> Could you please review the updated fix:
>>>>> http://cr.openjdk.java.net/~aivanov/8039383/jdk9/webrev.03/
>>>>>
>>>>>
>>>>> What has changed since version .02?
>>>>>
>>>>> During additional testing, I found another scenario where NPE was 
>>>>> thrown. So the new version adds more checks to prevent access to 
>>>>> XPStyle and ThemeReader where Windows visual styles become 
>>>>> unavailable.
>>>>>
>>>>> As in previous version, getters in XPStyle class check for null 
>>>>> values and return dummy defaults if ThemeReader returned null. 
>>>>> Skin painters also check whether theming is still available before 
>>>>> asking ThemeReader to paint.
>>>>>
>>>>> Access to XPStyle.xp instance is blocked as soon as user switched 
>>>>> themes. The object will be cleaned when the corresponding 
>>>>> PropertyChangeEvent is handled by Swing.
>>>>>
>>>>> Thank you,
>>>>> Alexey.
>>>>>
>>>>> On 06.05.2014 12:14, Alexey Ivanov wrote:
>>>>>> Hi AWT and Swing teams,
>>>>>>
>>>>>> Could you please review the updated fix:
>>>>>> http://cr.openjdk.java.net/~dmarkov/8039383/jdk9/webrev.02/
>>>>>>
>>>>>>
>>>>>> What has changed since version .01?
>>>>>>
>>>>>> The issue was still reproducible with the .01 version of the fix, 
>>>>>> however it was harder to reproduce.
>>>>>>
>>>>>> So in version .02 I added checks for null where possible. If 
>>>>>> theme becomes unavailable, a dummy value will be used; this way 
>>>>>> applications will be more stable. As soon as the theme change 
>>>>>> events are handled, the entire UI will update properly.
>>>>>>
>>>>>> Thank you,
>>>>>> Alexey.
>>>>>>
>>>>>> On 24.04.2014 16:23, Alexey Ivanov wrote:
>>>>>>> Hi Anthony, AWT and Swing teams,
>>>>>>>
>>>>>>> Here's the updated fix:
>>>>>>> http://cr.openjdk.java.net/~dmarkov/8039383/jdk9/webrev.01/
>>>>>>>
>>>>>>> Description:
>>>>>>> In the new version of the fix, I use a new xpstyleEnabled field 
>>>>>>> of AtomicBoolean in WToolkit to track the current value of 
>>>>>>> "win.xpstyle.themeActive" desktop property. Its value is updated 
>>>>>>> in windowsSettingChange() and in updateProperties().
>>>>>>> XPStyle.getXP() checks its cached value in themeActive and the 
>>>>>>> current value in WToolkit; if the value changes, it schedules 
>>>>>>> updateAllUIs and invalidates the current style right away, so 
>>>>>>> that components would not access data from the theme that became 
>>>>>>> unavailable.
>>>>>>> Two functions in ThemeReader also check this special field from 
>>>>>>> WToolkit which prevents throwing InternalError when paint is 
>>>>>>> called before theme change is fully handled.
>>>>>>>
>>>>>>> Before updateAllUIs is invoked, it's possible that application 
>>>>>>> will paint with some values cached from the previous theme. 
>>>>>>> Usually it happens before "Theme change" dialog disappears from 
>>>>>>> the screen, at least I noticed no UI glitches during normal 
>>>>>>> theme change.
>>>>>>>
>>>>>>>
>>>>>>> Regression test:
>>>>>>> No regression test is provided due to its complexity. 
>>>>>>> Additionally, 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.
>>>>>>>
>>>>>>>
>>>>>>> Thank you,
>>>>>>> Alexey.
>>>>>>>
>>>>>>> On 18.04.2014 18:52, Anthony Petrov wrote:
>>>>>>>> Hi Alexey,
>>>>>>>>
>>>>>>>> No, unfortunately I don't have any suggestions right now.
>>>>>>>>
>>>>>>>> As for allowing executing user code on the toolkit thread, we 
>>>>>>>> can't accept such a fix. Sorry about that.
>>>>>>>>
>>>>>>>> -- 
>>>>>>>> best regards,
>>>>>>>> Anthony
>>>>>>>>
>>>>>>>> On 4/18/2014 6:48 PM, Alexey Ivanov wrote:
>>>>>>>>> Hi Anthony,
>>>>>>>>>
>>>>>>>>> Thank you for your review.
>>>>>>>>>
>>>>>>>>> Yes, user code can install a property change listener... It 
>>>>>>>>> was my
>>>>>>>>> concern too, that's why I explicitly noted about this.
>>>>>>>>>
>>>>>>>>> Do you have any suggestion how this situation can be handled?
>>>>>>>>> Is it a general rule that all desktop property change 
>>>>>>>>> listeners must be
>>>>>>>>> called on EDT?
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Thanks,
>>>>>>>>> Alexey.
>>>>>>>>>
>>>>>>>>> On 18.04.2014 16:02, Anthony Petrov wrote:
>>>>>>>>>> Hi Alexey,
>>>>>>>>>>
>>>>>>>>>>> With this change, property "win.xpstyle.themeActive" change 
>>>>>>>>>>> is fired
>>>>>>>>>>> on the toolkit thread
>>>>>>>>>> Is it possible to install a change listener for this property 
>>>>>>>>>> from
>>>>>>>>>> user code, and hence eventually allow executing some user 
>>>>>>>>>> code on the
>>>>>>>>>> toolkit thread with your fix?
>>>>>>>>>>
>>>>>>>>>> -- 
>>>>>>>>>> best regards,
>>>>>>>>>> Anthony
>>>>>>>>>>
>>>>>>>>>> On 4/18/2014 12:09 PM, Alexey Ivanov wrote:
>>>>>>>>>>> Hello Swing and AWT teams,
>>>>>>>>>>>
>>>>>>>>>>> Could you please review the fix for jdk9:
>>>>>>>>>>>      bug: https://bugs.openjdk.java.net/browse/JDK-8039383
>>>>>>>>>>>      webrev: 
>>>>>>>>>>> http://cr.openjdk.java.net/~dmarkov/8039383/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 "cached" in XPStyle object. When the 
>>>>>>>>>>> theme is
>>>>>>>>>>> switched to a classic one, HTHEME handle becomes unavailable 
>>>>>>>>>>> and data
>>>>>>>>>>> cannot be accessed from the theme any more. The change in 
>>>>>>>>>>> theme in
>>>>>>>>>>> posted to EDT via invokeLater. At the same time, the UI 
>>>>>>>>>>> needs to repaint
>>>>>>>>>>> itself as soon as Windows changed the theme, and paint code 
>>>>>>>>>>> is often
>>>>>>>>>>> called before the theme change is handled in Java. This 
>>>>>>>>>>> leads to NPE and
>>>>>>>>>>> InternalError as the code tries to access the data that has 
>>>>>>>>>>> become
>>>>>>>>>>> unavailable.
>>>>>>>>>>>
>>>>>>>>>>> The fix:
>>>>>>>>>>> Update "win.xpstyle.themeActive" desktop property and 
>>>>>>>>>>> invalidate the
>>>>>>>>>>> cached XPStyle as soon as windowsSettingChange() is called 
>>>>>>>>>>> from native
>>>>>>>>>>> code. Thus when Swing code needs to access theme data, it 
>>>>>>>>>>> will see no
>>>>>>>>>>> theme is available and will fallback to classic painting.
>>>>>>>>>>>
>>>>>>>>>>> Note: Before the fix, PropertyChangeEvents for desktop 
>>>>>>>>>>> properties in
>>>>>>>>>>> Windows were fired on the Event Dispatch Thread. With this 
>>>>>>>>>>> change,
>>>>>>>>>>> property "win.xpstyle.themeActive" change is fired on the 
>>>>>>>>>>> toolkit
>>>>>>>>>>> thread; all other properties are changed on the EDT as before.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Regards,
>>>>>>>>>>> Alexey.
>>>
>>


From alexandr.scherbatiy at oracle.com  Fri Jun  6 08:25:35 2014
From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy)
Date: Fri, 06 Jun 2014 12:25:35 +0400
Subject: <AWT Dev> [9] Review Request: 8041990 [macosx] Language
 specific keys does not work in applets when opened outside the browser
In-Reply-To: <64B5D2A5-C206-4DFA-80A9-4B3E403CE120@oracle.com>
References: <017EEE29-608D-4838-A8AC-ECCFF4C709E1@oracle.com>
	<538501EB.7060600@oracle.com>
	<64B5D2A5-C206-4DFA-80A9-4B3E403CE120@oracle.com>
Message-ID: <53917AFF.1010803@oracle.com>


   The fix looks good for me.

   Thanks,
   Alexandr.

On 5/28/2014 12:52 PM, Petr Pchelko wrote:
> Hello,
>
> Please review an updated fix:
> http://cr.openjdk.java.net/~pchelko/9/8041990/webrev.01/
>
> I've removed null-checks in EventQueueAccessor, because these could mask bugs.
> All the rest is the same.
>
> With best regards. Petr.
>
> On 28 ??? 2014 ?., at 1:21, Phil Race <philip.race at oracle.com> wrote:
>
>> Is there not some (bad) implication of  returning 0 for the time ?
>>
>> -phil.
>>
>> On 5/27/14 8:45 AM, Petr Pchelko wrote:
>>> Hello, AWT Team.
>>>
>>> Please review a next AppContext issue:
>>> https://bugs.openjdk.java.net/browse/JDK-8041990
>>> The fix is available at:
>>> http://cr.openjdk.java.net/~pchelko/9/8041990/webrev/
>>>
>>> When non-latin characters a typed AWT tries to check if InputMethods are going to handle the key event.
>>> To do it we create an InputMethodEvent on Appkit thread which fails with NPE due to lack of AppContext.
>>>
>>> Thank you.
>>> With best regards. Petr.


From petr.pchelko at oracle.com  Fri Jun  6 10:18:33 2014
From: petr.pchelko at oracle.com (Petr Pchelko)
Date: Fri, 6 Jun 2014 14:18:33 +0400
Subject: <AWT Dev> [9] Review Request: 8041990 [macosx] Language
	specific keys does not work in applets when opened outside
	the browser
In-Reply-To: <53917AFF.1010803@oracle.com>
References: <017EEE29-608D-4838-A8AC-ECCFF4C709E1@oracle.com>
	<538501EB.7060600@oracle.com>
	<64B5D2A5-C206-4DFA-80A9-4B3E403CE120@oracle.com>
	<53917AFF.1010803@oracle.com>
Message-ID: <EDDDCDF8-32FC-4F78-82D1-8CDF72FAD7D7@oracle.com>

Hello, 

Please review the updated fix:
http://cr.openjdk.java.net/~pchelko/9/8041990/webrev.02/

After offline discussion with Sergey we've decided that an Accessor should not contain any logic, 
so it was moved to a separate method in InputMethodEvent.

Thank you.
With best regards. Petr.

On 06 ???? 2014 ?., at 12:25, Alexander Scherbatiy <alexandr.scherbatiy at oracle.com> wrote:

> 
>  The fix looks good for me.
> 
>  Thanks,
>  Alexandr.
> 
> On 5/28/2014 12:52 PM, Petr Pchelko wrote:
>> Hello,
>> 
>> Please review an updated fix:
>> http://cr.openjdk.java.net/~pchelko/9/8041990/webrev.01/
>> 
>> I've removed null-checks in EventQueueAccessor, because these could mask bugs.
>> All the rest is the same.
>> 
>> With best regards. Petr.
>> 
>> On 28 ??? 2014 ?., at 1:21, Phil Race <philip.race at oracle.com> wrote:
>> 
>>> Is there not some (bad) implication of  returning 0 for the time ?
>>> 
>>> -phil.
>>> 
>>> On 5/27/14 8:45 AM, Petr Pchelko wrote:
>>>> Hello, AWT Team.
>>>> 
>>>> Please review a next AppContext issue:
>>>> https://bugs.openjdk.java.net/browse/JDK-8041990
>>>> The fix is available at:
>>>> http://cr.openjdk.java.net/~pchelko/9/8041990/webrev/
>>>> 
>>>> When non-latin characters a typed AWT tries to check if InputMethods are going to handle the key event.
>>>> To do it we create an InputMethodEvent on Appkit thread which fails with NPE due to lack of AppContext.
>>>> 
>>>> Thank you.
>>>> With best regards. Petr.
> 


From petr.pchelko at oracle.com  Fri Jun  6 10:44:00 2014
From: petr.pchelko at oracle.com (Petr Pchelko)
Date: Fri, 6 Jun 2014 14:44:00 +0400
Subject: <AWT Dev> [9] Review Request: 8041990 [macosx] Language
	specific keys does not work in applets when opened outside
	the browser
In-Reply-To: <EDDDCDF8-32FC-4F78-82D1-8CDF72FAD7D7@oracle.com>
References: <017EEE29-608D-4838-A8AC-ECCFF4C709E1@oracle.com>
	<538501EB.7060600@oracle.com>
	<64B5D2A5-C206-4DFA-80A9-4B3E403CE120@oracle.com>
	<53917AFF.1010803@oracle.com>
	<EDDDCDF8-32FC-4F78-82D1-8CDF72FAD7D7@oracle.com>
Message-ID: <D550DDA1-8185-45AC-A7C4-9E38FCEFE0CB@oracle.com>

Hello, 

Please review a yet another version:
http://cr.openjdk.java.net/~pchelko/9/8041990/webrev.03/

Just noticed that according to the spec event should throw IllegalArgumentException if the source is null, not NPE.

With best regards. Petr.

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

> Hello, 
> 
> Please review the updated fix:
> http://cr.openjdk.java.net/~pchelko/9/8041990/webrev.02/
> 
> After offline discussion with Sergey we've decided that an Accessor should not contain any logic, 
> so it was moved to a separate method in InputMethodEvent.
> 
> Thank you.
> With best regards. Petr.
> 
> On 06 ???? 2014 ?., at 12:25, Alexander Scherbatiy <alexandr.scherbatiy at oracle.com> wrote:
> 
>> 
>> The fix looks good for me.
>> 
>> Thanks,
>> Alexandr.
>> 
>> On 5/28/2014 12:52 PM, Petr Pchelko wrote:
>>> Hello,
>>> 
>>> Please review an updated fix:
>>> http://cr.openjdk.java.net/~pchelko/9/8041990/webrev.01/
>>> 
>>> I've removed null-checks in EventQueueAccessor, because these could mask bugs.
>>> All the rest is the same.
>>> 
>>> With best regards. Petr.
>>> 
>>> On 28 ??? 2014 ?., at 1:21, Phil Race <philip.race at oracle.com> wrote:
>>> 
>>>> Is there not some (bad) implication of  returning 0 for the time ?
>>>> 
>>>> -phil.
>>>> 
>>>> On 5/27/14 8:45 AM, Petr Pchelko wrote:
>>>>> Hello, AWT Team.
>>>>> 
>>>>> Please review a next AppContext issue:
>>>>> https://bugs.openjdk.java.net/browse/JDK-8041990
>>>>> The fix is available at:
>>>>> http://cr.openjdk.java.net/~pchelko/9/8041990/webrev/
>>>>> 
>>>>> When non-latin characters a typed AWT tries to check if InputMethods are going to handle the key event.
>>>>> To do it we create an InputMethodEvent on Appkit thread which fails with NPE due to lack of AppContext.
>>>>> 
>>>>> Thank you.
>>>>> With best regards. Petr.
>> 
> 


From Sergey.Bylokhov at oracle.com  Fri Jun  6 10:43:27 2014
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Fri, 06 Jun 2014 14:43:27 +0400
Subject: <AWT Dev> [9] Review Request: 8041990 [macosx] Language
 specific keys does not work in applets when opened outside the browser
In-Reply-To: <D550DDA1-8185-45AC-A7C4-9E38FCEFE0CB@oracle.com>
References: <017EEE29-608D-4838-A8AC-ECCFF4C709E1@oracle.com>
	<538501EB.7060600@oracle.com>
	<64B5D2A5-C206-4DFA-80A9-4B3E403CE120@oracle.com>
	<53917AFF.1010803@oracle.com>
	<EDDDCDF8-32FC-4F78-82D1-8CDF72FAD7D7@oracle.com>
	<D550DDA1-8185-45AC-A7C4-9E38FCEFE0CB@oracle.com>
Message-ID: <53919B4F.1060904@oracle.com>

Hi, Petr.
The fix looks good.

On 6/6/14 2:44 PM, Petr Pchelko wrote:
> Hello,
>
> Please review a yet another version:
> http://cr.openjdk.java.net/~pchelko/9/8041990/webrev.03/
>
> Just noticed that according to the spec event should throw IllegalArgumentException if the source is null, not NPE.
>
> With best regards. Petr.
>
> On 06 ???? 2014 ?., at 14:18, Petr Pchelko <petr.pchelko at oracle.com> wrote:
>
>> Hello,
>>
>> Please review the updated fix:
>> http://cr.openjdk.java.net/~pchelko/9/8041990/webrev.02/
>>
>> After offline discussion with Sergey we've decided that an Accessor should not contain any logic,
>> so it was moved to a separate method in InputMethodEvent.
>>
>> Thank you.
>> With best regards. Petr.
>>
>> On 06 ???? 2014 ?., at 12:25, Alexander Scherbatiy <alexandr.scherbatiy at oracle.com> wrote:
>>
>>> The fix looks good for me.
>>>
>>> Thanks,
>>> Alexandr.
>>>
>>> On 5/28/2014 12:52 PM, Petr Pchelko wrote:
>>>> Hello,
>>>>
>>>> Please review an updated fix:
>>>> http://cr.openjdk.java.net/~pchelko/9/8041990/webrev.01/
>>>>
>>>> I've removed null-checks in EventQueueAccessor, because these could mask bugs.
>>>> All the rest is the same.
>>>>
>>>> With best regards. Petr.
>>>>
>>>> On 28 ??? 2014 ?., at 1:21, Phil Race <philip.race at oracle.com> wrote:
>>>>
>>>>> Is there not some (bad) implication of  returning 0 for the time ?
>>>>>
>>>>> -phil.
>>>>>
>>>>> On 5/27/14 8:45 AM, Petr Pchelko wrote:
>>>>>> Hello, AWT Team.
>>>>>>
>>>>>> Please review a next AppContext issue:
>>>>>> https://bugs.openjdk.java.net/browse/JDK-8041990
>>>>>> The fix is available at:
>>>>>> http://cr.openjdk.java.net/~pchelko/9/8041990/webrev/
>>>>>>
>>>>>> When non-latin characters a typed AWT tries to check if InputMethods are going to handle the key event.
>>>>>> To do it we create an InputMethodEvent on Appkit thread which fails with NPE due to lack of AppContext.
>>>>>>
>>>>>> Thank you.
>>>>>> With best regards. Petr.


-- 
Best regards, Sergey.


From anthony.petrov at oracle.com  Fri Jun  6 10:59:07 2014
From: anthony.petrov at oracle.com (Anthony Petrov)
Date: Fri, 06 Jun 2014 14:59:07 +0400
Subject: <AWT Dev> <Swing Dev> [9] Review request for JDK-8039383: NPE
 when changing Windows Theme
In-Reply-To: <539178E4.6060101@oracle.com>
References: <5350DDBC.30603@oracle.com>	<5351143C.8010100@oracle.com>	<53513B5B.4050104@oracle.com>	<53513C26.9060305@oracle.com>	<53590232.4080703@oracle.com>
	<536899D1.1020501@oracle.com>	<53900FA7.8040508@oracle.com>	<0FE09EB0-B3A1-43F4-AE48-401DD55F5B09@oracle.com>	<539022E9.7070907@oracle.com>
	<4240D39D-748C-483F-B447-1FAF6DFA25E4@oracle.com>
	<5390DC2A.1030502@oracle.com> <539178E4.6060101@oracle.com>
Message-ID: <53919EFB.5040508@oracle.com>

Thanks. The rest of the fix looks good to me.

--
best regards,
Anthony

On 6/6/2014 12:16 PM, Alexey Ivanov wrote:
> Hi Anthony,
>
> Thank you for your review.
>
> I've removed synchronized modifier from updateProperties() method which
> protected access to wprops field. Now this field is accessed from
> synchronized methods lazilyInitWProps() and getWProps();
> setDesktopProperty also has proper synchronization - that was my
> reasoning for removing synchronized.
>
> But you're right, it was not the right decision as the update loop now
> could execute simultaneously which is undesirable. I'll put synchronized
> modifier to updateProperties() method.
>
> Regards,
> Alexey.
>
> On 06.06.2014 1:07, Anthony Petrov wrote:
>> Hi Alexey,
>>
>> In WToolkit.java you're removing the synchronized modifier from the
>> private updateProperties() method. And it looks like the method itself
>> does allow for calling from multiple threads. So I'm concerned about
>> the lack of synchronization in this method. Was the removal
>> intentional? How is the method supposed to work now when called from
>> multiple threads?
>>
>> --
>> best regards,
>> Anthony
>>
>> On 6/5/2014 12:16 PM, Petr Pchelko wrote:
>>> Thank you for clarifications, I've been most interested in #2 obviously.
>>>
>>> The fix looks good to me.
>>>
>>> With best regards. Petr.
>>>
>>> On 05 ???? 2014 ?., at 11:57, Alexey Ivanov
>>> <alexey.ivanov at oracle.com> wrote:
>>>
>>>> Hello Petr,
>>>>
>>>> Thank you for your comments.
>>>>
>>>> 1. Sure, I'll remove the comment before the change set is pushed.
>>>> 2. No, I didn't try stub XPStyle object. First of all, UI delegates
>>>> decide what painting method to use depending on whether
>>>> XPStyle.getXP() returns null or not. If XPStyle.getXP() always
>>>> returns non-null value, we'll have re-implement all UI delegates for
>>>> Windows plaf, and I believe it would result in larger changeset.
>>>> Additionally, some classes fallback to inherited behavior where
>>>> XPStyle.getXP() is not available.
>>>> Another reason is that UI delegates cache Skins: those objects
>>>> shouldn't paint where theming is unavailable.
>>>> 3. No, I haven't filed any bugs yet. I'll file all the issues I've
>>>> found in the nearest future.
>>>>
>>>> Regards,
>>>> Alexey.
>>>>
>>>> On 05.06.2014 11:08, Petr Pchelko wrote:
>>>>> Hello, Alexey.
>>>>>
>>>>> A couple of comments:
>>>>> 1. ThemeReader:64 - I suggest to remove that comment as it does not
>>>>> add any value. The variable name is self explanatory.
>>>>> 2. XPStyle - did you try providing a stub XPStyle object instead of
>>>>> changing many of it's methods? Do I understand correctly that this
>>>>> is not possible because XPstyle is cached in many place is our code?
>>>>> 3. In offline discussion you've mentioned that you've found another
>>>>> related issue. Did you have a chance to file a bug about it?
>>>>>
>>>>> Thank you.
>>>>> With best regards. Petr.
>>>>>
>>>>> On 05 ???? 2014 ?., at 10:35, Alexey Ivanov
>>>>> <alexey.ivanov at oracle.com> wrote:
>>>>>
>>>>>> Hi AWT and Swing teams,
>>>>>>
>>>>>> Could you please review the updated fix:
>>>>>> http://cr.openjdk.java.net/~aivanov/8039383/jdk9/webrev.03/
>>>>>>
>>>>>>
>>>>>> What has changed since version .02?
>>>>>>
>>>>>> During additional testing, I found another scenario where NPE was
>>>>>> thrown. So the new version adds more checks to prevent access to
>>>>>> XPStyle and ThemeReader where Windows visual styles become
>>>>>> unavailable.
>>>>>>
>>>>>> As in previous version, getters in XPStyle class check for null
>>>>>> values and return dummy defaults if ThemeReader returned null.
>>>>>> Skin painters also check whether theming is still available before
>>>>>> asking ThemeReader to paint.
>>>>>>
>>>>>> Access to XPStyle.xp instance is blocked as soon as user switched
>>>>>> themes. The object will be cleaned when the corresponding
>>>>>> PropertyChangeEvent is handled by Swing.
>>>>>>
>>>>>> Thank you,
>>>>>> Alexey.
>>>>>>
>>>>>> On 06.05.2014 12:14, Alexey Ivanov wrote:
>>>>>>> Hi AWT and Swing teams,
>>>>>>>
>>>>>>> Could you please review the updated fix:
>>>>>>> http://cr.openjdk.java.net/~dmarkov/8039383/jdk9/webrev.02/
>>>>>>>
>>>>>>>
>>>>>>> What has changed since version .01?
>>>>>>>
>>>>>>> The issue was still reproducible with the .01 version of the fix,
>>>>>>> however it was harder to reproduce.
>>>>>>>
>>>>>>> So in version .02 I added checks for null where possible. If
>>>>>>> theme becomes unavailable, a dummy value will be used; this way
>>>>>>> applications will be more stable. As soon as the theme change
>>>>>>> events are handled, the entire UI will update properly.
>>>>>>>
>>>>>>> Thank you,
>>>>>>> Alexey.
>>>>>>>
>>>>>>> On 24.04.2014 16:23, Alexey Ivanov wrote:
>>>>>>>> Hi Anthony, AWT and Swing teams,
>>>>>>>>
>>>>>>>> Here's the updated fix:
>>>>>>>> http://cr.openjdk.java.net/~dmarkov/8039383/jdk9/webrev.01/
>>>>>>>>
>>>>>>>> Description:
>>>>>>>> In the new version of the fix, I use a new xpstyleEnabled field
>>>>>>>> of AtomicBoolean in WToolkit to track the current value of
>>>>>>>> "win.xpstyle.themeActive" desktop property. Its value is updated
>>>>>>>> in windowsSettingChange() and in updateProperties().
>>>>>>>> XPStyle.getXP() checks its cached value in themeActive and the
>>>>>>>> current value in WToolkit; if the value changes, it schedules
>>>>>>>> updateAllUIs and invalidates the current style right away, so
>>>>>>>> that components would not access data from the theme that became
>>>>>>>> unavailable.
>>>>>>>> Two functions in ThemeReader also check this special field from
>>>>>>>> WToolkit which prevents throwing InternalError when paint is
>>>>>>>> called before theme change is fully handled.
>>>>>>>>
>>>>>>>> Before updateAllUIs is invoked, it's possible that application
>>>>>>>> will paint with some values cached from the previous theme.
>>>>>>>> Usually it happens before "Theme change" dialog disappears from
>>>>>>>> the screen, at least I noticed no UI glitches during normal
>>>>>>>> theme change.
>>>>>>>>
>>>>>>>>
>>>>>>>> Regression test:
>>>>>>>> No regression test is provided due to its complexity.
>>>>>>>> Additionally, 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.
>>>>>>>>
>>>>>>>>
>>>>>>>> Thank you,
>>>>>>>> Alexey.
>>>>>>>>
>>>>>>>> On 18.04.2014 18:52, Anthony Petrov wrote:
>>>>>>>>> Hi Alexey,
>>>>>>>>>
>>>>>>>>> No, unfortunately I don't have any suggestions right now.
>>>>>>>>>
>>>>>>>>> As for allowing executing user code on the toolkit thread, we
>>>>>>>>> can't accept such a fix. Sorry about that.
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> best regards,
>>>>>>>>> Anthony
>>>>>>>>>
>>>>>>>>> On 4/18/2014 6:48 PM, Alexey Ivanov wrote:
>>>>>>>>>> Hi Anthony,
>>>>>>>>>>
>>>>>>>>>> Thank you for your review.
>>>>>>>>>>
>>>>>>>>>> Yes, user code can install a property change listener... It
>>>>>>>>>> was my
>>>>>>>>>> concern too, that's why I explicitly noted about this.
>>>>>>>>>>
>>>>>>>>>> Do you have any suggestion how this situation can be handled?
>>>>>>>>>> Is it a general rule that all desktop property change
>>>>>>>>>> listeners must be
>>>>>>>>>> called on EDT?
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Thanks,
>>>>>>>>>> Alexey.
>>>>>>>>>>
>>>>>>>>>> On 18.04.2014 16:02, Anthony Petrov wrote:
>>>>>>>>>>> Hi Alexey,
>>>>>>>>>>>
>>>>>>>>>>>> With this change, property "win.xpstyle.themeActive" change
>>>>>>>>>>>> is fired
>>>>>>>>>>>> on the toolkit thread
>>>>>>>>>>> Is it possible to install a change listener for this property
>>>>>>>>>>> from
>>>>>>>>>>> user code, and hence eventually allow executing some user
>>>>>>>>>>> code on the
>>>>>>>>>>> toolkit thread with your fix?
>>>>>>>>>>>
>>>>>>>>>>> --
>>>>>>>>>>> best regards,
>>>>>>>>>>> Anthony
>>>>>>>>>>>
>>>>>>>>>>> On 4/18/2014 12:09 PM, Alexey Ivanov wrote:
>>>>>>>>>>>> Hello Swing and AWT teams,
>>>>>>>>>>>>
>>>>>>>>>>>> Could you please review the fix for jdk9:
>>>>>>>>>>>>      bug: https://bugs.openjdk.java.net/browse/JDK-8039383
>>>>>>>>>>>>      webrev:
>>>>>>>>>>>> http://cr.openjdk.java.net/~dmarkov/8039383/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 "cached" in XPStyle object. When the
>>>>>>>>>>>> theme is
>>>>>>>>>>>> switched to a classic one, HTHEME handle becomes unavailable
>>>>>>>>>>>> and data
>>>>>>>>>>>> cannot be accessed from the theme any more. The change in
>>>>>>>>>>>> theme in
>>>>>>>>>>>> posted to EDT via invokeLater. At the same time, the UI
>>>>>>>>>>>> needs to repaint
>>>>>>>>>>>> itself as soon as Windows changed the theme, and paint code
>>>>>>>>>>>> is often
>>>>>>>>>>>> called before the theme change is handled in Java. This
>>>>>>>>>>>> leads to NPE and
>>>>>>>>>>>> InternalError as the code tries to access the data that has
>>>>>>>>>>>> become
>>>>>>>>>>>> unavailable.
>>>>>>>>>>>>
>>>>>>>>>>>> The fix:
>>>>>>>>>>>> Update "win.xpstyle.themeActive" desktop property and
>>>>>>>>>>>> invalidate the
>>>>>>>>>>>> cached XPStyle as soon as windowsSettingChange() is called
>>>>>>>>>>>> from native
>>>>>>>>>>>> code. Thus when Swing code needs to access theme data, it
>>>>>>>>>>>> will see no
>>>>>>>>>>>> theme is available and will fallback to classic painting.
>>>>>>>>>>>>
>>>>>>>>>>>> Note: Before the fix, PropertyChangeEvents for desktop
>>>>>>>>>>>> properties in
>>>>>>>>>>>> Windows were fired on the Event Dispatch Thread. With this
>>>>>>>>>>>> change,
>>>>>>>>>>>> property "win.xpstyle.themeActive" change is fired on the
>>>>>>>>>>>> toolkit
>>>>>>>>>>>> thread; all other properties are changed on the EDT as before.
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Regards,
>>>>>>>>>>>> Alexey.
>>>>
>>>
>

From alexey.ivanov at oracle.com  Fri Jun  6 11:02:20 2014
From: alexey.ivanov at oracle.com (Alexey Ivanov)
Date: Fri, 06 Jun 2014 15:02:20 +0400
Subject: <AWT Dev> <Swing Dev> [9] Review request for JDK-8039383: NPE
 when changing Windows Theme
In-Reply-To: <539178E4.6060101@oracle.com>
References: <5350DDBC.30603@oracle.com>	<5351143C.8010100@oracle.com>	<53513B5B.4050104@oracle.com>	<53513C26.9060305@oracle.com>	<53590232.4080703@oracle.com>	<536899D1.1020501@oracle.com>	<53900FA7.8040508@oracle.com>	<0FE09EB0-B3A1-43F4-AE48-401DD55F5B09@oracle.com>	<539022E9.7070907@oracle.com>	<4240D39D-748C-483F-B447-1FAF6DFA25E4@oracle.com>	<5390DC2A.1030502@oracle.com>
	<539178E4.6060101@oracle.com>
Message-ID: <53919FBC.9060807@oracle.com>

Hi Anthony, Petr, AWT and Swing teams,

I've addressed Anthony's and Petr's comments in the updated webrev:
http://cr.openjdk.java.net/~aivanov/8039383/jdk9/webrev.04/

Thank you,
Alexey.

On 06.06.2014 12:16, Alexey Ivanov wrote:
> Hi Anthony,
>
> Thank you for your review.
>
> I've removed synchronized modifier from updateProperties() method 
> which protected access to wprops field. Now this field is accessed 
> from synchronized methods lazilyInitWProps() and getWProps(); 
> setDesktopProperty also has proper synchronization - that was my 
> reasoning for removing synchronized.
>
> But you're right, it was not the right decision as the update loop now 
> could execute simultaneously which is undesirable. I'll put 
> synchronized modifier to updateProperties() method.
>
> Regards,
> Alexey.
>
> On 06.06.2014 1:07, Anthony Petrov wrote:
>> Hi Alexey,
>>
>> In WToolkit.java you're removing the synchronized modifier from the 
>> private updateProperties() method. And it looks like the method 
>> itself does allow for calling from multiple threads. So I'm concerned 
>> about the lack of synchronization in this method. Was the removal 
>> intentional? How is the method supposed to work now when called from 
>> multiple threads?
>>
>> -- 
>> best regards,
>> Anthony
>>
>> On 6/5/2014 12:16 PM, Petr Pchelko wrote:
>>> Thank you for clarifications, I've been most interested in #2 
>>> obviously.
>>>
>>> The fix looks good to me.
>>>
>>> With best regards. Petr.
>>>
>>> On 05 ???? 2014 ?., at 11:57, Alexey Ivanov 
>>> <alexey.ivanov at oracle.com> wrote:
>>>
>>>> Hello Petr,
>>>>
>>>> Thank you for your comments.
>>>>
>>>> 1. Sure, I'll remove the comment before the change set is pushed.
>>>> 2. No, I didn't try stub XPStyle object. First of all, UI delegates 
>>>> decide what painting method to use depending on whether 
>>>> XPStyle.getXP() returns null or not. If XPStyle.getXP() always 
>>>> returns non-null value, we'll have re-implement all UI delegates 
>>>> for Windows plaf, and I believe it would result in larger 
>>>> changeset. Additionally, some classes fallback to inherited 
>>>> behavior where XPStyle.getXP() is not available.
>>>> Another reason is that UI delegates cache Skins: those objects 
>>>> shouldn't paint where theming is unavailable.
>>>> 3. No, I haven't filed any bugs yet. I'll file all the issues I've 
>>>> found in the nearest future.
>>>>
>>>> Regards,
>>>> Alexey.
>>>>
>>>> On 05.06.2014 11:08, Petr Pchelko wrote:
>>>>> Hello, Alexey.
>>>>>
>>>>> A couple of comments:
>>>>> 1. ThemeReader:64 - I suggest to remove that comment as it does 
>>>>> not add any value. The variable name is self explanatory.
>>>>> 2. XPStyle - did you try providing a stub XPStyle object instead 
>>>>> of changing many of it's methods? Do I understand correctly that this
>>>>> is not possible because XPstyle is cached in many place is our code?
>>>>> 3. In offline discussion you've mentioned that you've found 
>>>>> another related issue. Did you have a chance to file a bug about it?
>>>>>
>>>>> Thank you.
>>>>> With best regards. Petr.
>>>>>
>>>>> On 05 ???? 2014 ?., at 10:35, Alexey Ivanov 
>>>>> <alexey.ivanov at oracle.com> wrote:
>>>>>
>>>>>> Hi AWT and Swing teams,
>>>>>>
>>>>>> Could you please review the updated fix:
>>>>>> http://cr.openjdk.java.net/~aivanov/8039383/jdk9/webrev.03/
>>>>>>
>>>>>>
>>>>>> What has changed since version .02?
>>>>>>
>>>>>> During additional testing, I found another scenario where NPE was 
>>>>>> thrown. So the new version adds more checks to prevent access to 
>>>>>> XPStyle and ThemeReader where Windows visual styles become 
>>>>>> unavailable.
>>>>>>
>>>>>> As in previous version, getters in XPStyle class check for null 
>>>>>> values and return dummy defaults if ThemeReader returned null. 
>>>>>> Skin painters also check whether theming is still available 
>>>>>> before asking ThemeReader to paint.
>>>>>>
>>>>>> Access to XPStyle.xp instance is blocked as soon as user switched 
>>>>>> themes. The object will be cleaned when the corresponding 
>>>>>> PropertyChangeEvent is handled by Swing.
>>>>>>
>>>>>> Thank you,
>>>>>> Alexey.
>>>>>>
>>>>>> On 06.05.2014 12:14, Alexey Ivanov wrote:
>>>>>>> Hi AWT and Swing teams,
>>>>>>>
>>>>>>> Could you please review the updated fix:
>>>>>>> http://cr.openjdk.java.net/~dmarkov/8039383/jdk9/webrev.02/
>>>>>>>
>>>>>>>
>>>>>>> What has changed since version .01?
>>>>>>>
>>>>>>> The issue was still reproducible with the .01 version of the 
>>>>>>> fix, however it was harder to reproduce.
>>>>>>>
>>>>>>> So in version .02 I added checks for null where possible. If 
>>>>>>> theme becomes unavailable, a dummy value will be used; this way 
>>>>>>> applications will be more stable. As soon as the theme change 
>>>>>>> events are handled, the entire UI will update properly.
>>>>>>>
>>>>>>> Thank you,
>>>>>>> Alexey.
>>>>>>>
>>>>>>> On 24.04.2014 16:23, Alexey Ivanov wrote:
>>>>>>>> Hi Anthony, AWT and Swing teams,
>>>>>>>>
>>>>>>>> Here's the updated fix:
>>>>>>>> http://cr.openjdk.java.net/~dmarkov/8039383/jdk9/webrev.01/
>>>>>>>>
>>>>>>>> Description:
>>>>>>>> In the new version of the fix, I use a new xpstyleEnabled field 
>>>>>>>> of AtomicBoolean in WToolkit to track the current value of 
>>>>>>>> "win.xpstyle.themeActive" desktop property. Its value is 
>>>>>>>> updated in windowsSettingChange() and in updateProperties().
>>>>>>>> XPStyle.getXP() checks its cached value in themeActive and the 
>>>>>>>> current value in WToolkit; if the value changes, it schedules 
>>>>>>>> updateAllUIs and invalidates the current style right away, so 
>>>>>>>> that components would not access data from the theme that 
>>>>>>>> became unavailable.
>>>>>>>> Two functions in ThemeReader also check this special field from 
>>>>>>>> WToolkit which prevents throwing InternalError when paint is 
>>>>>>>> called before theme change is fully handled.
>>>>>>>>
>>>>>>>> Before updateAllUIs is invoked, it's possible that application 
>>>>>>>> will paint with some values cached from the previous theme. 
>>>>>>>> Usually it happens before "Theme change" dialog disappears from 
>>>>>>>> the screen, at least I noticed no UI glitches during normal 
>>>>>>>> theme change.
>>>>>>>>
>>>>>>>>
>>>>>>>> Regression test:
>>>>>>>> No regression test is provided due to its complexity. 
>>>>>>>> Additionally, 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.
>>>>>>>>
>>>>>>>>
>>>>>>>> Thank you,
>>>>>>>> Alexey.
>>>>>>>>
>>>>>>>> On 18.04.2014 18:52, Anthony Petrov wrote:
>>>>>>>>> Hi Alexey,
>>>>>>>>>
>>>>>>>>> No, unfortunately I don't have any suggestions right now.
>>>>>>>>>
>>>>>>>>> As for allowing executing user code on the toolkit thread, we 
>>>>>>>>> can't accept such a fix. Sorry about that.
>>>>>>>>>
>>>>>>>>> -- 
>>>>>>>>> best regards,
>>>>>>>>> Anthony
>>>>>>>>>
>>>>>>>>> On 4/18/2014 6:48 PM, Alexey Ivanov wrote:
>>>>>>>>>> Hi Anthony,
>>>>>>>>>>
>>>>>>>>>> Thank you for your review.
>>>>>>>>>>
>>>>>>>>>> Yes, user code can install a property change listener... It 
>>>>>>>>>> was my
>>>>>>>>>> concern too, that's why I explicitly noted about this.
>>>>>>>>>>
>>>>>>>>>> Do you have any suggestion how this situation can be handled?
>>>>>>>>>> Is it a general rule that all desktop property change 
>>>>>>>>>> listeners must be
>>>>>>>>>> called on EDT?
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Thanks,
>>>>>>>>>> Alexey.
>>>>>>>>>>
>>>>>>>>>> On 18.04.2014 16:02, Anthony Petrov wrote:
>>>>>>>>>>> Hi Alexey,
>>>>>>>>>>>
>>>>>>>>>>>> With this change, property "win.xpstyle.themeActive" change 
>>>>>>>>>>>> is fired
>>>>>>>>>>>> on the toolkit thread
>>>>>>>>>>> Is it possible to install a change listener for this 
>>>>>>>>>>> property from
>>>>>>>>>>> user code, and hence eventually allow executing some user 
>>>>>>>>>>> code on the
>>>>>>>>>>> toolkit thread with your fix?
>>>>>>>>>>>
>>>>>>>>>>> -- 
>>>>>>>>>>> best regards,
>>>>>>>>>>> Anthony
>>>>>>>>>>>
>>>>>>>>>>> On 4/18/2014 12:09 PM, Alexey Ivanov wrote:
>>>>>>>>>>>> Hello Swing and AWT teams,
>>>>>>>>>>>>
>>>>>>>>>>>> Could you please review the fix for jdk9:
>>>>>>>>>>>>      bug: https://bugs.openjdk.java.net/browse/JDK-8039383
>>>>>>>>>>>>      webrev: 
>>>>>>>>>>>> http://cr.openjdk.java.net/~dmarkov/8039383/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 "cached" in XPStyle object. When the 
>>>>>>>>>>>> theme is
>>>>>>>>>>>> switched to a classic one, HTHEME handle becomes 
>>>>>>>>>>>> unavailable and data
>>>>>>>>>>>> cannot be accessed from the theme any more. The change in 
>>>>>>>>>>>> theme in
>>>>>>>>>>>> posted to EDT via invokeLater. At the same time, the UI 
>>>>>>>>>>>> needs to repaint
>>>>>>>>>>>> itself as soon as Windows changed the theme, and paint code 
>>>>>>>>>>>> is often
>>>>>>>>>>>> called before the theme change is handled in Java. This 
>>>>>>>>>>>> leads to NPE and
>>>>>>>>>>>> InternalError as the code tries to access the data that has 
>>>>>>>>>>>> become
>>>>>>>>>>>> unavailable.
>>>>>>>>>>>>
>>>>>>>>>>>> The fix:
>>>>>>>>>>>> Update "win.xpstyle.themeActive" desktop property and 
>>>>>>>>>>>> invalidate the
>>>>>>>>>>>> cached XPStyle as soon as windowsSettingChange() is called 
>>>>>>>>>>>> from native
>>>>>>>>>>>> code. Thus when Swing code needs to access theme data, it 
>>>>>>>>>>>> will see no
>>>>>>>>>>>> theme is available and will fallback to classic painting.
>>>>>>>>>>>>
>>>>>>>>>>>> Note: Before the fix, PropertyChangeEvents for desktop 
>>>>>>>>>>>> properties in
>>>>>>>>>>>> Windows were fired on the Event Dispatch Thread. With this 
>>>>>>>>>>>> change,
>>>>>>>>>>>> property "win.xpstyle.themeActive" change is fired on the 
>>>>>>>>>>>> toolkit
>>>>>>>>>>>> thread; all other properties are changed on the EDT as before.
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Regards,
>>>>>>>>>>>> Alexey.
>>>>
>>>
>


From petr.pchelko at oracle.com  Fri Jun  6 11:20:09 2014
From: petr.pchelko at oracle.com (Petr Pchelko)
Date: Fri, 6 Jun 2014 15:20:09 +0400
Subject: <AWT Dev> <Swing Dev> [9] Review request for JDK-8039383: NPE
	when changing Windows Theme
In-Reply-To: <53919FBC.9060807@oracle.com>
References: <5350DDBC.30603@oracle.com>	<5351143C.8010100@oracle.com>	<53513B5B.4050104@oracle.com>	<53513C26.9060305@oracle.com>	<53590232.4080703@oracle.com>	<536899D1.1020501@oracle.com>	<53900FA7.8040508@oracle.com>	<0FE09EB0-B3A1-43F4-AE48-401DD55F5B09@oracle.com>	<539022E9.7070907@oracle.com>	<4240D39D-748C-483F-B447-1FAF6DFA25E4@oracle.com>	<5390DC2A.1030502@oracle.com>
	<539178E4.6060101@oracle.com> <53919FBC.9060807@oracle.com>
Message-ID: <D9978349-8209-44B2-B0E9-6CD94FBF88A2@oracle.com>

Hello, Alexey.

The final version still looks good.

With best regards. Petr.

On 06 ???? 2014 ?., at 15:02, Alexey Ivanov <alexey.ivanov at oracle.com> wrote:

> Hi Anthony, Petr, AWT and Swing teams,
> 
> I've addressed Anthony's and Petr's comments in the updated webrev:
> http://cr.openjdk.java.net/~aivanov/8039383/jdk9/webrev.04/
> 
> Thank you,
> Alexey.
> 
> On 06.06.2014 12:16, Alexey Ivanov wrote:
>> Hi Anthony,
>> 
>> Thank you for your review.
>> 
>> I've removed synchronized modifier from updateProperties() method which protected access to wprops field. Now this field is accessed from synchronized methods lazilyInitWProps() and getWProps(); setDesktopProperty also has proper synchronization - that was my reasoning for removing synchronized.
>> 
>> But you're right, it was not the right decision as the update loop now could execute simultaneously which is undesirable. I'll put synchronized modifier to updateProperties() method.
>> 
>> Regards,
>> Alexey.
>> 
>> On 06.06.2014 1:07, Anthony Petrov wrote:
>>> Hi Alexey,
>>> 
>>> In WToolkit.java you're removing the synchronized modifier from the private updateProperties() method. And it looks like the method itself does allow for calling from multiple threads. So I'm concerned about the lack of synchronization in this method. Was the removal intentional? How is the method supposed to work now when called from multiple threads?
>>> 
>>> -- 
>>> best regards,
>>> Anthony
>>> 
>>> On 6/5/2014 12:16 PM, Petr Pchelko wrote:
>>>> Thank you for clarifications, I've been most interested in #2 obviously.
>>>> 
>>>> The fix looks good to me.
>>>> 
>>>> With best regards. Petr.
>>>> 
>>>> On 05 ???? 2014 ?., at 11:57, Alexey Ivanov <alexey.ivanov at oracle.com> wrote:
>>>> 
>>>>> Hello Petr,
>>>>> 
>>>>> Thank you for your comments.
>>>>> 
>>>>> 1. Sure, I'll remove the comment before the change set is pushed.
>>>>> 2. No, I didn't try stub XPStyle object. First of all, UI delegates decide what painting method to use depending on whether XPStyle.getXP() returns null or not. If XPStyle.getXP() always returns non-null value, we'll have re-implement all UI delegates for Windows plaf, and I believe it would result in larger changeset. Additionally, some classes fallback to inherited behavior where XPStyle.getXP() is not available.
>>>>> Another reason is that UI delegates cache Skins: those objects shouldn't paint where theming is unavailable.
>>>>> 3. No, I haven't filed any bugs yet. I'll file all the issues I've found in the nearest future.
>>>>> 
>>>>> Regards,
>>>>> Alexey.
>>>>> 
>>>>> On 05.06.2014 11:08, Petr Pchelko wrote:
>>>>>> Hello, Alexey.
>>>>>> 
>>>>>> A couple of comments:
>>>>>> 1. ThemeReader:64 - I suggest to remove that comment as it does not add any value. The variable name is self explanatory.
>>>>>> 2. XPStyle - did you try providing a stub XPStyle object instead of changing many of it's methods? Do I understand correctly that this
>>>>>> is not possible because XPstyle is cached in many place is our code?
>>>>>> 3. In offline discussion you've mentioned that you've found another related issue. Did you have a chance to file a bug about it?
>>>>>> 
>>>>>> Thank you.
>>>>>> With best regards. Petr.
>>>>>> 
>>>>>> On 05 ???? 2014 ?., at 10:35, Alexey Ivanov <alexey.ivanov at oracle.com> wrote:
>>>>>> 
>>>>>>> Hi AWT and Swing teams,
>>>>>>> 
>>>>>>> Could you please review the updated fix:
>>>>>>> http://cr.openjdk.java.net/~aivanov/8039383/jdk9/webrev.03/
>>>>>>> 
>>>>>>> 
>>>>>>> What has changed since version .02?
>>>>>>> 
>>>>>>> During additional testing, I found another scenario where NPE was thrown. So the new version adds more checks to prevent access to XPStyle and ThemeReader where Windows visual styles become unavailable.
>>>>>>> 
>>>>>>> As in previous version, getters in XPStyle class check for null values and return dummy defaults if ThemeReader returned null. Skin painters also check whether theming is still available before asking ThemeReader to paint.
>>>>>>> 
>>>>>>> Access to XPStyle.xp instance is blocked as soon as user switched themes. The object will be cleaned when the corresponding PropertyChangeEvent is handled by Swing.
>>>>>>> 
>>>>>>> Thank you,
>>>>>>> Alexey.
>>>>>>> 
>>>>>>> On 06.05.2014 12:14, Alexey Ivanov wrote:
>>>>>>>> Hi AWT and Swing teams,
>>>>>>>> 
>>>>>>>> Could you please review the updated fix:
>>>>>>>> http://cr.openjdk.java.net/~dmarkov/8039383/jdk9/webrev.02/
>>>>>>>> 
>>>>>>>> 
>>>>>>>> What has changed since version .01?
>>>>>>>> 
>>>>>>>> The issue was still reproducible with the .01 version of the fix, however it was harder to reproduce.
>>>>>>>> 
>>>>>>>> So in version .02 I added checks for null where possible. If theme becomes unavailable, a dummy value will be used; this way applications will be more stable. As soon as the theme change events are handled, the entire UI will update properly.
>>>>>>>> 
>>>>>>>> Thank you,
>>>>>>>> Alexey.
>>>>>>>> 
>>>>>>>> On 24.04.2014 16:23, Alexey Ivanov wrote:
>>>>>>>>> Hi Anthony, AWT and Swing teams,
>>>>>>>>> 
>>>>>>>>> Here's the updated fix:
>>>>>>>>> http://cr.openjdk.java.net/~dmarkov/8039383/jdk9/webrev.01/
>>>>>>>>> 
>>>>>>>>> Description:
>>>>>>>>> In the new version of the fix, I use a new xpstyleEnabled field of AtomicBoolean in WToolkit to track the current value of "win.xpstyle.themeActive" desktop property. Its value is updated in windowsSettingChange() and in updateProperties().
>>>>>>>>> XPStyle.getXP() checks its cached value in themeActive and the current value in WToolkit; if the value changes, it schedules updateAllUIs and invalidates the current style right away, so that components would not access data from the theme that became unavailable.
>>>>>>>>> Two functions in ThemeReader also check this special field from WToolkit which prevents throwing InternalError when paint is called before theme change is fully handled.
>>>>>>>>> 
>>>>>>>>> Before updateAllUIs is invoked, it's possible that application will paint with some values cached from the previous theme. Usually it happens before "Theme change" dialog disappears from the screen, at least I noticed no UI glitches during normal theme change.
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> Regression test:
>>>>>>>>> No regression test is provided due to its complexity. Additionally, 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.
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> Thank you,
>>>>>>>>> Alexey.
>>>>>>>>> 
>>>>>>>>> On 18.04.2014 18:52, Anthony Petrov wrote:
>>>>>>>>>> Hi Alexey,
>>>>>>>>>> 
>>>>>>>>>> No, unfortunately I don't have any suggestions right now.
>>>>>>>>>> 
>>>>>>>>>> As for allowing executing user code on the toolkit thread, we can't accept such a fix. Sorry about that.
>>>>>>>>>> 
>>>>>>>>>> -- 
>>>>>>>>>> best regards,
>>>>>>>>>> Anthony
>>>>>>>>>> 
>>>>>>>>>> On 4/18/2014 6:48 PM, Alexey Ivanov wrote:
>>>>>>>>>>> Hi Anthony,
>>>>>>>>>>> 
>>>>>>>>>>> Thank you for your review.
>>>>>>>>>>> 
>>>>>>>>>>> Yes, user code can install a property change listener... It was my
>>>>>>>>>>> concern too, that's why I explicitly noted about this.
>>>>>>>>>>> 
>>>>>>>>>>> Do you have any suggestion how this situation can be handled?
>>>>>>>>>>> Is it a general rule that all desktop property change listeners must be
>>>>>>>>>>> called on EDT?
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> Thanks,
>>>>>>>>>>> Alexey.
>>>>>>>>>>> 
>>>>>>>>>>> On 18.04.2014 16:02, Anthony Petrov wrote:
>>>>>>>>>>>> Hi Alexey,
>>>>>>>>>>>> 
>>>>>>>>>>>>> With this change, property "win.xpstyle.themeActive" change is fired
>>>>>>>>>>>>> on the toolkit thread
>>>>>>>>>>>> Is it possible to install a change listener for this property from
>>>>>>>>>>>> user code, and hence eventually allow executing some user code on the
>>>>>>>>>>>> toolkit thread with your fix?
>>>>>>>>>>>> 
>>>>>>>>>>>> -- 
>>>>>>>>>>>> best regards,
>>>>>>>>>>>> Anthony
>>>>>>>>>>>> 
>>>>>>>>>>>> On 4/18/2014 12:09 PM, Alexey Ivanov wrote:
>>>>>>>>>>>>> Hello Swing and AWT teams,
>>>>>>>>>>>>> 
>>>>>>>>>>>>> Could you please review the fix for jdk9:
>>>>>>>>>>>>>     bug: https://bugs.openjdk.java.net/browse/JDK-8039383
>>>>>>>>>>>>>     webrev: http://cr.openjdk.java.net/~dmarkov/8039383/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 "cached" in XPStyle object. When the theme is
>>>>>>>>>>>>> switched to a classic one, HTHEME handle becomes unavailable and data
>>>>>>>>>>>>> cannot be accessed from the theme any more. The change in theme in
>>>>>>>>>>>>> posted to EDT via invokeLater. At the same time, the UI needs to repaint
>>>>>>>>>>>>> itself as soon as Windows changed the theme, and paint code is often
>>>>>>>>>>>>> called before the theme change is handled in Java. This leads to NPE and
>>>>>>>>>>>>> InternalError as the code tries to access the data that has become
>>>>>>>>>>>>> unavailable.
>>>>>>>>>>>>> 
>>>>>>>>>>>>> The fix:
>>>>>>>>>>>>> Update "win.xpstyle.themeActive" desktop property and invalidate the
>>>>>>>>>>>>> cached XPStyle as soon as windowsSettingChange() is called from native
>>>>>>>>>>>>> code. Thus when Swing code needs to access theme data, it will see no
>>>>>>>>>>>>> theme is available and will fallback to classic painting.
>>>>>>>>>>>>> 
>>>>>>>>>>>>> Note: Before the fix, PropertyChangeEvents for desktop properties in
>>>>>>>>>>>>> Windows were fired on the Event Dispatch Thread. With this change,
>>>>>>>>>>>>> property "win.xpstyle.themeActive" change is fired on the toolkit
>>>>>>>>>>>>> thread; all other properties are changed on the EDT as before.
>>>>>>>>>>>>> 
>>>>>>>>>>>>> 
>>>>>>>>>>>>> Regards,
>>>>>>>>>>>>> Alexey.
>>>>> 
>>>> 
>> 
> 


From anthony.petrov at oracle.com  Fri Jun  6 11:19:26 2014
From: anthony.petrov at oracle.com (Anthony Petrov)
Date: Fri, 06 Jun 2014 15:19:26 +0400
Subject: <AWT Dev> <Swing Dev> [9] Review request for JDK-8039383: NPE
 when changing Windows Theme
In-Reply-To: <D9978349-8209-44B2-B0E9-6CD94FBF88A2@oracle.com>
References: <5350DDBC.30603@oracle.com>	<5351143C.8010100@oracle.com>	<53513B5B.4050104@oracle.com>	<53513C26.9060305@oracle.com>	<53590232.4080703@oracle.com>	<536899D1.1020501@oracle.com>	<53900FA7.8040508@oracle.com>	<0FE09EB0-B3A1-43F4-AE48-401DD55F5B09@oracle.com>	<539022E9.7070907@oracle.com>	<4240D39D-748C-483F-B447-1FAF6DFA25E4@oracle.com>	<5390DC2A.1030502@oracle.com>
	<539178E4.6060101@oracle.com> <53919FBC.9060807@oracle.com>
	<D9978349-8209-44B2-B0E9-6CD94FBF88A2@oracle.com>
Message-ID: <5391A3BE.3030607@oracle.com>

+1

--
best regards,
Anthony

On 6/6/2014 3:20 PM, Petr Pchelko wrote:
> Hello, Alexey.
>
> The final version still looks good.
>
> With best regards. Petr.
>
> On 06 ???? 2014 ?., at 15:02, Alexey Ivanov <alexey.ivanov at oracle.com> wrote:
>
>> Hi Anthony, Petr, AWT and Swing teams,
>>
>> I've addressed Anthony's and Petr's comments in the updated webrev:
>> http://cr.openjdk.java.net/~aivanov/8039383/jdk9/webrev.04/
>>
>> Thank you,
>> Alexey.
>>
>> On 06.06.2014 12:16, Alexey Ivanov wrote:
>>> Hi Anthony,
>>>
>>> Thank you for your review.
>>>
>>> I've removed synchronized modifier from updateProperties() method which protected access to wprops field. Now this field is accessed from synchronized methods lazilyInitWProps() and getWProps(); setDesktopProperty also has proper synchronization - that was my reasoning for removing synchronized.
>>>
>>> But you're right, it was not the right decision as the update loop now could execute simultaneously which is undesirable. I'll put synchronized modifier to updateProperties() method.
>>>
>>> Regards,
>>> Alexey.
>>>
>>> On 06.06.2014 1:07, Anthony Petrov wrote:
>>>> Hi Alexey,
>>>>
>>>> In WToolkit.java you're removing the synchronized modifier from the private updateProperties() method. And it looks like the method itself does allow for calling from multiple threads. So I'm concerned about the lack of synchronization in this method. Was the removal intentional? How is the method supposed to work now when called from multiple threads?
>>>>
>>>> --
>>>> best regards,
>>>> Anthony
>>>>
>>>> On 6/5/2014 12:16 PM, Petr Pchelko wrote:
>>>>> Thank you for clarifications, I've been most interested in #2 obviously.
>>>>>
>>>>> The fix looks good to me.
>>>>>
>>>>> With best regards. Petr.
>>>>>
>>>>> On 05 ???? 2014 ?., at 11:57, Alexey Ivanov <alexey.ivanov at oracle.com> wrote:
>>>>>
>>>>>> Hello Petr,
>>>>>>
>>>>>> Thank you for your comments.
>>>>>>
>>>>>> 1. Sure, I'll remove the comment before the change set is pushed.
>>>>>> 2. No, I didn't try stub XPStyle object. First of all, UI delegates decide what painting method to use depending on whether XPStyle.getXP() returns null or not. If XPStyle.getXP() always returns non-null value, we'll have re-implement all UI delegates for Windows plaf, and I believe it would result in larger changeset. Additionally, some classes fallback to inherited behavior where XPStyle.getXP() is not available.
>>>>>> Another reason is that UI delegates cache Skins: those objects shouldn't paint where theming is unavailable.
>>>>>> 3. No, I haven't filed any bugs yet. I'll file all the issues I've found in the nearest future.
>>>>>>
>>>>>> Regards,
>>>>>> Alexey.
>>>>>>
>>>>>> On 05.06.2014 11:08, Petr Pchelko wrote:
>>>>>>> Hello, Alexey.
>>>>>>>
>>>>>>> A couple of comments:
>>>>>>> 1. ThemeReader:64 - I suggest to remove that comment as it does not add any value. The variable name is self explanatory.
>>>>>>> 2. XPStyle - did you try providing a stub XPStyle object instead of changing many of it's methods? Do I understand correctly that this
>>>>>>> is not possible because XPstyle is cached in many place is our code?
>>>>>>> 3. In offline discussion you've mentioned that you've found another related issue. Did you have a chance to file a bug about it?
>>>>>>>
>>>>>>> Thank you.
>>>>>>> With best regards. Petr.
>>>>>>>
>>>>>>> On 05 ???? 2014 ?., at 10:35, Alexey Ivanov <alexey.ivanov at oracle.com> wrote:
>>>>>>>
>>>>>>>> Hi AWT and Swing teams,
>>>>>>>>
>>>>>>>> Could you please review the updated fix:
>>>>>>>> http://cr.openjdk.java.net/~aivanov/8039383/jdk9/webrev.03/
>>>>>>>>
>>>>>>>>
>>>>>>>> What has changed since version .02?
>>>>>>>>
>>>>>>>> During additional testing, I found another scenario where NPE was thrown. So the new version adds more checks to prevent access to XPStyle and ThemeReader where Windows visual styles become unavailable.
>>>>>>>>
>>>>>>>> As in previous version, getters in XPStyle class check for null values and return dummy defaults if ThemeReader returned null. Skin painters also check whether theming is still available before asking ThemeReader to paint.
>>>>>>>>
>>>>>>>> Access to XPStyle.xp instance is blocked as soon as user switched themes. The object will be cleaned when the corresponding PropertyChangeEvent is handled by Swing.
>>>>>>>>
>>>>>>>> Thank you,
>>>>>>>> Alexey.
>>>>>>>>
>>>>>>>> On 06.05.2014 12:14, Alexey Ivanov wrote:
>>>>>>>>> Hi AWT and Swing teams,
>>>>>>>>>
>>>>>>>>> Could you please review the updated fix:
>>>>>>>>> http://cr.openjdk.java.net/~dmarkov/8039383/jdk9/webrev.02/
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> What has changed since version .01?
>>>>>>>>>
>>>>>>>>> The issue was still reproducible with the .01 version of the fix, however it was harder to reproduce.
>>>>>>>>>
>>>>>>>>> So in version .02 I added checks for null where possible. If theme becomes unavailable, a dummy value will be used; this way applications will be more stable. As soon as the theme change events are handled, the entire UI will update properly.
>>>>>>>>>
>>>>>>>>> Thank you,
>>>>>>>>> Alexey.
>>>>>>>>>
>>>>>>>>> On 24.04.2014 16:23, Alexey Ivanov wrote:
>>>>>>>>>> Hi Anthony, AWT and Swing teams,
>>>>>>>>>>
>>>>>>>>>> Here's the updated fix:
>>>>>>>>>> http://cr.openjdk.java.net/~dmarkov/8039383/jdk9/webrev.01/
>>>>>>>>>>
>>>>>>>>>> Description:
>>>>>>>>>> In the new version of the fix, I use a new xpstyleEnabled field of AtomicBoolean in WToolkit to track the current value of "win.xpstyle.themeActive" desktop property. Its value is updated in windowsSettingChange() and in updateProperties().
>>>>>>>>>> XPStyle.getXP() checks its cached value in themeActive and the current value in WToolkit; if the value changes, it schedules updateAllUIs and invalidates the current style right away, so that components would not access data from the theme that became unavailable.
>>>>>>>>>> Two functions in ThemeReader also check this special field from WToolkit which prevents throwing InternalError when paint is called before theme change is fully handled.
>>>>>>>>>>
>>>>>>>>>> Before updateAllUIs is invoked, it's possible that application will paint with some values cached from the previous theme. Usually it happens before "Theme change" dialog disappears from the screen, at least I noticed no UI glitches during normal theme change.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Regression test:
>>>>>>>>>> No regression test is provided due to its complexity. Additionally, 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.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Thank you,
>>>>>>>>>> Alexey.
>>>>>>>>>>
>>>>>>>>>> On 18.04.2014 18:52, Anthony Petrov wrote:
>>>>>>>>>>> Hi Alexey,
>>>>>>>>>>>
>>>>>>>>>>> No, unfortunately I don't have any suggestions right now.
>>>>>>>>>>>
>>>>>>>>>>> As for allowing executing user code on the toolkit thread, we can't accept such a fix. Sorry about that.
>>>>>>>>>>>
>>>>>>>>>>> --
>>>>>>>>>>> best regards,
>>>>>>>>>>> Anthony
>>>>>>>>>>>
>>>>>>>>>>> On 4/18/2014 6:48 PM, Alexey Ivanov wrote:
>>>>>>>>>>>> Hi Anthony,
>>>>>>>>>>>>
>>>>>>>>>>>> Thank you for your review.
>>>>>>>>>>>>
>>>>>>>>>>>> Yes, user code can install a property change listener... It was my
>>>>>>>>>>>> concern too, that's why I explicitly noted about this.
>>>>>>>>>>>>
>>>>>>>>>>>> Do you have any suggestion how this situation can be handled?
>>>>>>>>>>>> Is it a general rule that all desktop property change listeners must be
>>>>>>>>>>>> called on EDT?
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Thanks,
>>>>>>>>>>>> Alexey.
>>>>>>>>>>>>
>>>>>>>>>>>> On 18.04.2014 16:02, Anthony Petrov wrote:
>>>>>>>>>>>>> Hi Alexey,
>>>>>>>>>>>>>
>>>>>>>>>>>>>> With this change, property "win.xpstyle.themeActive" change is fired
>>>>>>>>>>>>>> on the toolkit thread
>>>>>>>>>>>>> Is it possible to install a change listener for this property from
>>>>>>>>>>>>> user code, and hence eventually allow executing some user code on the
>>>>>>>>>>>>> toolkit thread with your fix?
>>>>>>>>>>>>>
>>>>>>>>>>>>> --
>>>>>>>>>>>>> best regards,
>>>>>>>>>>>>> Anthony
>>>>>>>>>>>>>
>>>>>>>>>>>>> On 4/18/2014 12:09 PM, Alexey Ivanov wrote:
>>>>>>>>>>>>>> Hello Swing and AWT teams,
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Could you please review the fix for jdk9:
>>>>>>>>>>>>>>      bug: https://bugs.openjdk.java.net/browse/JDK-8039383
>>>>>>>>>>>>>>      webrev: http://cr.openjdk.java.net/~dmarkov/8039383/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 "cached" in XPStyle object. When the theme is
>>>>>>>>>>>>>> switched to a classic one, HTHEME handle becomes unavailable and data
>>>>>>>>>>>>>> cannot be accessed from the theme any more. The change in theme in
>>>>>>>>>>>>>> posted to EDT via invokeLater. At the same time, the UI needs to repaint
>>>>>>>>>>>>>> itself as soon as Windows changed the theme, and paint code is often
>>>>>>>>>>>>>> called before the theme change is handled in Java. This leads to NPE and
>>>>>>>>>>>>>> InternalError as the code tries to access the data that has become
>>>>>>>>>>>>>> unavailable.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> The fix:
>>>>>>>>>>>>>> Update "win.xpstyle.themeActive" desktop property and invalidate the
>>>>>>>>>>>>>> cached XPStyle as soon as windowsSettingChange() is called from native
>>>>>>>>>>>>>> code. Thus when Swing code needs to access theme data, it will see no
>>>>>>>>>>>>>> theme is available and will fallback to classic painting.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Note: Before the fix, PropertyChangeEvents for desktop properties in
>>>>>>>>>>>>>> Windows were fired on the Event Dispatch Thread. With this change,
>>>>>>>>>>>>>> property "win.xpstyle.themeActive" change is fired on the toolkit
>>>>>>>>>>>>>> thread; all other properties are changed on the EDT as before.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Regards,
>>>>>>>>>>>>>> Alexey.
>>>>>>
>>>>>
>>>
>>
>

From dmitriy.ermashov at oracle.com  Fri Jun  6 12:18:45 2014
From: dmitriy.ermashov at oracle.com (Dmitriy Ermashov)
Date: Fri, 06 Jun 2014 16:18:45 +0400
Subject: <AWT Dev> Review request for JDK-8044765: Move functional tests
 AWT_SystemTray/Automated to openjdk repository
In-Reply-To: <F66CBFB8-8F4D-4557-9150-887FFF8EADC7@oracle.com>
References: <538EE5BC.1000304@oracle.com>
	<F66CBFB8-8F4D-4557-9150-887FFF8EADC7@oracle.com>
Message-ID: <5391B1A5.1010709@oracle.com>

Hi all,

Sorry for the delay.
Please review new version of webrev:
http://cr.openjdk.java.net/~dermashov/8044765/webrev.01/

Last changes:
1. Long strings were splitted
2. InterJVM.java test started to use process helpers
3. MouseMovedTest - added volatile modificator to "moved" variable

Thanks,
Dima

On 06/04/2014 03:08 PM, Petr Pchelko wrote:
> Hello, Dmitriy.
>
> A couple of comments:
> 1. Could you please split loooong lines in ActionCommand.java, ModalityTest.java, MouseEventMaskTest.java, TrayIconEventModifiersTest.java, TrayIconEventsTest.java, TrayIconPopupTest.java
> 2. For interprocess communication we have special helpers in java/awt/regtesthelpers/process. You could reuse them to simplify InterJVM.java
> 3. MouseMovedTest - moved should be volatile
>
> Thank you.
> With best regards. Petr.
>
> On 04 ???? 2014 ?., at 13:24, Dmitriy Ermashov <dmitriy.ermashov at oracle.com> wrote:
>
>> Hi team,
>>
>> It is new batch of functional tests, system tray tests this time.
>> Please review the change set:
>> http://cr.openjdk.java.net/~dermashov/8044765/webrev.00/
>>
>> The fix also contains new test MouseMovedTest for verifying bug 7153700
>>
>> -- 
>> Thanks,
>> Dima
>>


From petr.pchelko at oracle.com  Fri Jun  6 13:05:34 2014
From: petr.pchelko at oracle.com (Petr Pchelko)
Date: Fri, 6 Jun 2014 17:05:34 +0400
Subject: <AWT Dev> Review Request: 8046221 [TEST_BUG] Cleanup datatransfer
	tests
Message-ID: <778EB5FC-D8C6-4423-97FE-50C932B00584@oracle.com>

Hello, AWT Team.

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

During my datatransfer modularization work I've needed to run some tests, but all our datatransfer 
tests depend on desktop and fail due to some other bug in jigsaw.  So I've cleaned them up, 
opensourced a bunch of tests and moved other test to the correct locations.

The pass rate in 100% for normal build.

With best regards. Petr.

From alexandr.scherbatiy at oracle.com  Fri Jun  6 12:58:12 2014
From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy)
Date: Fri, 06 Jun 2014 16:58:12 +0400
Subject: <AWT Dev> [9] Review Request: 8041990 [macosx] Language
 specific keys does not work in applets when opened outside the browser
In-Reply-To: <D550DDA1-8185-45AC-A7C4-9E38FCEFE0CB@oracle.com>
References: <017EEE29-608D-4838-A8AC-ECCFF4C709E1@oracle.com>
	<538501EB.7060600@oracle.com>
	<64B5D2A5-C206-4DFA-80A9-4B3E403CE120@oracle.com>
	<53917AFF.1010803@oracle.com>
	<EDDDCDF8-32FC-4F78-82D1-8CDF72FAD7D7@oracle.com>
	<D550DDA1-8185-45AC-A7C4-9E38FCEFE0CB@oracle.com>
Message-ID: <5391BAE4.9020108@oracle.com>


  The fix looks good for me.

  Thanks,
  Alexandr.

On 6/6/2014 2:44 PM, Petr Pchelko wrote:
> Hello,
>
> Please review a yet another version:
> http://cr.openjdk.java.net/~pchelko/9/8041990/webrev.03/
>
> Just noticed that according to the spec event should throw IllegalArgumentException if the source is null, not NPE.
>
> With best regards. Petr.
>
> On 06 ???? 2014 ?., at 14:18, Petr Pchelko <petr.pchelko at oracle.com> wrote:
>
>> Hello,
>>
>> Please review the updated fix:
>> http://cr.openjdk.java.net/~pchelko/9/8041990/webrev.02/
>>
>> After offline discussion with Sergey we've decided that an Accessor should not contain any logic,
>> so it was moved to a separate method in InputMethodEvent.
>>
>> Thank you.
>> With best regards. Petr.
>>
>> On 06 ???? 2014 ?., at 12:25, Alexander Scherbatiy <alexandr.scherbatiy at oracle.com> wrote:
>>
>>> The fix looks good for me.
>>>
>>> Thanks,
>>> Alexandr.
>>>
>>> On 5/28/2014 12:52 PM, Petr Pchelko wrote:
>>>> Hello,
>>>>
>>>> Please review an updated fix:
>>>> http://cr.openjdk.java.net/~pchelko/9/8041990/webrev.01/
>>>>
>>>> I've removed null-checks in EventQueueAccessor, because these could mask bugs.
>>>> All the rest is the same.
>>>>
>>>> With best regards. Petr.
>>>>
>>>> On 28 ??? 2014 ?., at 1:21, Phil Race <philip.race at oracle.com> wrote:
>>>>
>>>>> Is there not some (bad) implication of  returning 0 for the time ?
>>>>>
>>>>> -phil.
>>>>>
>>>>> On 5/27/14 8:45 AM, Petr Pchelko wrote:
>>>>>> Hello, AWT Team.
>>>>>>
>>>>>> Please review a next AppContext issue:
>>>>>> https://bugs.openjdk.java.net/browse/JDK-8041990
>>>>>> The fix is available at:
>>>>>> http://cr.openjdk.java.net/~pchelko/9/8041990/webrev/
>>>>>>
>>>>>> When non-latin characters a typed AWT tries to check if InputMethods are going to handle the key event.
>>>>>> To do it we create an InputMethodEvent on Appkit thread which fails with NPE due to lack of AppContext.
>>>>>>
>>>>>> Thank you.
>>>>>> With best regards. Petr.


From petr.pchelko at oracle.com  Fri Jun  6 13:59:02 2014
From: petr.pchelko at oracle.com (Petr Pchelko)
Date: Fri, 6 Jun 2014 17:59:02 +0400
Subject: <AWT Dev> Review request for JDK-8044765: Move functional tests
	AWT_SystemTray/Automated to openjdk repository
In-Reply-To: <5391B1A5.1010709@oracle.com>
References: <538EE5BC.1000304@oracle.com>
	<F66CBFB8-8F4D-4557-9150-887FFF8EADC7@oracle.com>
	<5391B1A5.1010709@oracle.com>
Message-ID: <5C2C8480-DC87-4138-91D7-2BB65B0A90ED@oracle.com>

Hello, Dmitry.

Thank you. The new version looks good to me.

With best regards. Petr.

On 06 ???? 2014 ?., at 16:18, Dmitriy Ermashov <dmitriy.ermashov at oracle.com> wrote:

> Hi all,
> 
> Sorry for the delay.
> Please review new version of webrev:
> http://cr.openjdk.java.net/~dermashov/8044765/webrev.01/
> 
> Last changes:
> 1. Long strings were splitted
> 2. InterJVM.java test started to use process helpers
> 3. MouseMovedTest - added volatile modificator to "moved" variable
> 
> Thanks,
> Dima
> 
> On 06/04/2014 03:08 PM, Petr Pchelko wrote:
>> Hello, Dmitriy.
>> 
>> A couple of comments:
>> 1. Could you please split loooong lines in ActionCommand.java, ModalityTest.java, MouseEventMaskTest.java, TrayIconEventModifiersTest.java, TrayIconEventsTest.java, TrayIconPopupTest.java
>> 2. For interprocess communication we have special helpers in java/awt/regtesthelpers/process. You could reuse them to simplify InterJVM.java
>> 3. MouseMovedTest - moved should be volatile
>> 
>> Thank you.
>> With best regards. Petr.
>> 
>> On 04 ???? 2014 ?., at 13:24, Dmitriy Ermashov <dmitriy.ermashov at oracle.com> wrote:
>> 
>>> Hi team,
>>> 
>>> It is new batch of functional tests, system tray tests this time.
>>> Please review the change set:
>>> http://cr.openjdk.java.net/~dermashov/8044765/webrev.00/
>>> 
>>> The fix also contains new test MouseMovedTest for verifying bug 7153700
>>> 
>>> -- 
>>> Thanks,
>>> Dima
>>> 
> 


From alexey.ivanov at oracle.com  Fri Jun  6 13:58:03 2014
From: alexey.ivanov at oracle.com (Alexey Ivanov)
Date: Fri, 06 Jun 2014 17:58:03 +0400
Subject: <AWT Dev> <Swing Dev> [9] Review request for JDK-8039383: NPE
 when changing Windows Theme
In-Reply-To: <5391A3BE.3030607@oracle.com>
References: <5350DDBC.30603@oracle.com>	<5351143C.8010100@oracle.com>	<53513B5B.4050104@oracle.com>	<53513C26.9060305@oracle.com>	<53590232.4080703@oracle.com>	<536899D1.1020501@oracle.com>	<53900FA7.8040508@oracle.com>	<0FE09EB0-B3A1-43F4-AE48-401DD55F5B09@oracle.com>	<539022E9.7070907@oracle.com>	<4240D39D-748C-483F-B447-1FAF6DFA25E4@oracle.com>	<5390DC2A.1030502@oracle.com>
	<539178E4.6060101@oracle.com> <53919FBC.9060807@oracle.com>
	<D9978349-8209-44B2-B0E9-6CD94FBF88A2@oracle.com>
	<5391A3BE.3030607@oracle.com>
Message-ID: <5391C8EB.5010501@oracle.com>

Hi Anthony, Petr,

Thank you for reviewing my fix.

Regards,
Alexey.


On 06.06.2014 15:19, Anthony Petrov wrote:
> +1
>
> -- 
> best regards,
> Anthony
>
> On 6/6/2014 3:20 PM, Petr Pchelko wrote:
>> Hello, Alexey.
>>
>> The final version still looks good.
>>
>> With best regards. Petr.
>>
>> On 06 ???? 2014 ?., at 15:02, Alexey Ivanov 
>> <alexey.ivanov at oracle.com> wrote:
>>
>>> Hi Anthony, Petr, AWT and Swing teams,
>>>
>>> I've addressed Anthony's and Petr's comments in the updated webrev:
>>> http://cr.openjdk.java.net/~aivanov/8039383/jdk9/webrev.04/
>>>
>>> Thank you,
>>> Alexey.
>>>
>>> On 06.06.2014 12:16, Alexey Ivanov wrote:
>>>> Hi Anthony,
>>>>
>>>> Thank you for your review.
>>>>
>>>> I've removed synchronized modifier from updateProperties() method 
>>>> which protected access to wprops field. Now this field is accessed 
>>>> from synchronized methods lazilyInitWProps() and getWProps(); 
>>>> setDesktopProperty also has proper synchronization - that was my 
>>>> reasoning for removing synchronized.
>>>>
>>>> But you're right, it was not the right decision as the update loop 
>>>> now could execute simultaneously which is undesirable. I'll put 
>>>> synchronized modifier to updateProperties() method.
>>>>
>>>> Regards,
>>>> Alexey.
>>>>
>>>> On 06.06.2014 1:07, Anthony Petrov wrote:
>>>>> Hi Alexey,
>>>>>
>>>>> In WToolkit.java you're removing the synchronized modifier from 
>>>>> the private updateProperties() method. And it looks like the 
>>>>> method itself does allow for calling from multiple threads. So I'm 
>>>>> concerned about the lack of synchronization in this method. Was 
>>>>> the removal intentional? How is the method supposed to work now 
>>>>> when called from multiple threads?
>>>>>
>>>>> -- 
>>>>> best regards,
>>>>> Anthony
>>>>>
>>>>> On 6/5/2014 12:16 PM, Petr Pchelko wrote:
>>>>>> Thank you for clarifications, I've been most interested in #2 
>>>>>> obviously.
>>>>>>
>>>>>> The fix looks good to me.
>>>>>>
>>>>>> With best regards. Petr.
>>>>>>
>>>>>> On 05 ???? 2014 ?., at 11:57, Alexey Ivanov 
>>>>>> <alexey.ivanov at oracle.com> wrote:
>>>>>>
>>>>>>> Hello Petr,
>>>>>>>
>>>>>>> Thank you for your comments.
>>>>>>>
>>>>>>> 1. Sure, I'll remove the comment before the change set is pushed.
>>>>>>> 2. No, I didn't try stub XPStyle object. First of all, UI 
>>>>>>> delegates decide what painting method to use depending on 
>>>>>>> whether XPStyle.getXP() returns null or not. If XPStyle.getXP() 
>>>>>>> always returns non-null value, we'll have re-implement all UI 
>>>>>>> delegates for Windows plaf, and I believe it would result in 
>>>>>>> larger changeset. Additionally, some classes fallback to 
>>>>>>> inherited behavior where XPStyle.getXP() is not available.
>>>>>>> Another reason is that UI delegates cache Skins: those objects 
>>>>>>> shouldn't paint where theming is unavailable.
>>>>>>> 3. No, I haven't filed any bugs yet. I'll file all the issues 
>>>>>>> I've found in the nearest future.
>>>>>>>
>>>>>>> Regards,
>>>>>>> Alexey.
>>>>>>>
>>>>>>> On 05.06.2014 11:08, Petr Pchelko wrote:
>>>>>>>> Hello, Alexey.
>>>>>>>>
>>>>>>>> A couple of comments:
>>>>>>>> 1. ThemeReader:64 - I suggest to remove that comment as it does 
>>>>>>>> not add any value. The variable name is self explanatory.
>>>>>>>> 2. XPStyle - did you try providing a stub XPStyle object 
>>>>>>>> instead of changing many of it's methods? Do I understand 
>>>>>>>> correctly that this
>>>>>>>> is not possible because XPstyle is cached in many place is our 
>>>>>>>> code?
>>>>>>>> 3. In offline discussion you've mentioned that you've found 
>>>>>>>> another related issue. Did you have a chance to file a bug 
>>>>>>>> about it?
>>>>>>>>
>>>>>>>> Thank you.
>>>>>>>> With best regards. Petr.
>>>>>>>>
>>>>>>>> On 05 ???? 2014 ?., at 10:35, Alexey Ivanov 
>>>>>>>> <alexey.ivanov at oracle.com> wrote:
>>>>>>>>
>>>>>>>>> Hi AWT and Swing teams,
>>>>>>>>>
>>>>>>>>> Could you please review the updated fix:
>>>>>>>>> http://cr.openjdk.java.net/~aivanov/8039383/jdk9/webrev.03/
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> What has changed since version .02?
>>>>>>>>>
>>>>>>>>> During additional testing, I found another scenario where NPE 
>>>>>>>>> was thrown. So the new version adds more checks to prevent 
>>>>>>>>> access to XPStyle and ThemeReader where Windows visual styles 
>>>>>>>>> become unavailable.
>>>>>>>>>
>>>>>>>>> As in previous version, getters in XPStyle class check for 
>>>>>>>>> null values and return dummy defaults if ThemeReader returned 
>>>>>>>>> null. Skin painters also check whether theming is still 
>>>>>>>>> available before asking ThemeReader to paint.
>>>>>>>>>
>>>>>>>>> Access to XPStyle.xp instance is blocked as soon as user 
>>>>>>>>> switched themes. The object will be cleaned when the 
>>>>>>>>> corresponding PropertyChangeEvent is handled by Swing.
>>>>>>>>>
>>>>>>>>> Thank you,
>>>>>>>>> Alexey.
>>>>>>>>>
>>>>>>>>> On 06.05.2014 12:14, Alexey Ivanov wrote:
>>>>>>>>>> Hi AWT and Swing teams,
>>>>>>>>>>
>>>>>>>>>> Could you please review the updated fix:
>>>>>>>>>> http://cr.openjdk.java.net/~dmarkov/8039383/jdk9/webrev.02/
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> What has changed since version .01?
>>>>>>>>>>
>>>>>>>>>> The issue was still reproducible with the .01 version of the 
>>>>>>>>>> fix, however it was harder to reproduce.
>>>>>>>>>>
>>>>>>>>>> So in version .02 I added checks for null where possible. If 
>>>>>>>>>> theme becomes unavailable, a dummy value will be used; this 
>>>>>>>>>> way applications will be more stable. As soon as the theme 
>>>>>>>>>> change events are handled, the entire UI will update properly.
>>>>>>>>>>
>>>>>>>>>> Thank you,
>>>>>>>>>> Alexey.
>>>>>>>>>>
>>>>>>>>>> On 24.04.2014 16:23, Alexey Ivanov wrote:
>>>>>>>>>>> Hi Anthony, AWT and Swing teams,
>>>>>>>>>>>
>>>>>>>>>>> Here's the updated fix:
>>>>>>>>>>> http://cr.openjdk.java.net/~dmarkov/8039383/jdk9/webrev.01/
>>>>>>>>>>>
>>>>>>>>>>> Description:
>>>>>>>>>>> In the new version of the fix, I use a new xpstyleEnabled 
>>>>>>>>>>> field of AtomicBoolean in WToolkit to track the current 
>>>>>>>>>>> value of "win.xpstyle.themeActive" desktop property. Its 
>>>>>>>>>>> value is updated in windowsSettingChange() and in 
>>>>>>>>>>> updateProperties().
>>>>>>>>>>> XPStyle.getXP() checks its cached value in themeActive and 
>>>>>>>>>>> the current value in WToolkit; if the value changes, it 
>>>>>>>>>>> schedules updateAllUIs and invalidates the current style 
>>>>>>>>>>> right away, so that components would not access data from 
>>>>>>>>>>> the theme that became unavailable.
>>>>>>>>>>> Two functions in ThemeReader also check this special field 
>>>>>>>>>>> from WToolkit which prevents throwing InternalError when 
>>>>>>>>>>> paint is called before theme change is fully handled.
>>>>>>>>>>>
>>>>>>>>>>> Before updateAllUIs is invoked, it's possible that 
>>>>>>>>>>> application will paint with some values cached from the 
>>>>>>>>>>> previous theme. Usually it happens before "Theme change" 
>>>>>>>>>>> dialog disappears from the screen, at least I noticed no UI 
>>>>>>>>>>> glitches during normal theme change.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Regression test:
>>>>>>>>>>> No regression test is provided due to its complexity. 
>>>>>>>>>>> Additionally, 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.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Thank you,
>>>>>>>>>>> Alexey.
>>>>>>>>>>>
>>>>>>>>>>> On 18.04.2014 18:52, Anthony Petrov wrote:
>>>>>>>>>>>> Hi Alexey,
>>>>>>>>>>>>
>>>>>>>>>>>> No, unfortunately I don't have any suggestions right now.
>>>>>>>>>>>>
>>>>>>>>>>>> As for allowing executing user code on the toolkit thread, 
>>>>>>>>>>>> we can't accept such a fix. Sorry about that.
>>>>>>>>>>>>
>>>>>>>>>>>> -- 
>>>>>>>>>>>> best regards,
>>>>>>>>>>>> Anthony
>>>>>>>>>>>>
>>>>>>>>>>>> On 4/18/2014 6:48 PM, Alexey Ivanov wrote:
>>>>>>>>>>>>> Hi Anthony,
>>>>>>>>>>>>>
>>>>>>>>>>>>> Thank you for your review.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Yes, user code can install a property change listener... 
>>>>>>>>>>>>> It was my
>>>>>>>>>>>>> concern too, that's why I explicitly noted about this.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Do you have any suggestion how this situation can be handled?
>>>>>>>>>>>>> Is it a general rule that all desktop property change 
>>>>>>>>>>>>> listeners must be
>>>>>>>>>>>>> called on EDT?
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>> Alexey.
>>>>>>>>>>>>>
>>>>>>>>>>>>> On 18.04.2014 16:02, Anthony Petrov wrote:
>>>>>>>>>>>>>> Hi Alexey,
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> With this change, property "win.xpstyle.themeActive" 
>>>>>>>>>>>>>>> change is fired
>>>>>>>>>>>>>>> on the toolkit thread
>>>>>>>>>>>>>> Is it possible to install a change listener for this 
>>>>>>>>>>>>>> property from
>>>>>>>>>>>>>> user code, and hence eventually allow executing some user 
>>>>>>>>>>>>>> code on the
>>>>>>>>>>>>>> toolkit thread with your fix?
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> -- 
>>>>>>>>>>>>>> best regards,
>>>>>>>>>>>>>> Anthony
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On 4/18/2014 12:09 PM, Alexey Ivanov wrote:
>>>>>>>>>>>>>>> Hello Swing and AWT teams,
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Could you please review the fix for jdk9:
>>>>>>>>>>>>>>>      bug: https://bugs.openjdk.java.net/browse/JDK-8039383
>>>>>>>>>>>>>>>      webrev: 
>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~dmarkov/8039383/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 "cached" in XPStyle object. When 
>>>>>>>>>>>>>>> the theme is
>>>>>>>>>>>>>>> switched to a classic one, HTHEME handle becomes 
>>>>>>>>>>>>>>> unavailable and data
>>>>>>>>>>>>>>> cannot be accessed from the theme any more. The change 
>>>>>>>>>>>>>>> in theme in
>>>>>>>>>>>>>>> posted to EDT via invokeLater. At the same time, the UI 
>>>>>>>>>>>>>>> needs to repaint
>>>>>>>>>>>>>>> itself as soon as Windows changed the theme, and paint 
>>>>>>>>>>>>>>> code is often
>>>>>>>>>>>>>>> called before the theme change is handled in Java. This 
>>>>>>>>>>>>>>> leads to NPE and
>>>>>>>>>>>>>>> InternalError as the code tries to access the data that 
>>>>>>>>>>>>>>> has become
>>>>>>>>>>>>>>> unavailable.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> The fix:
>>>>>>>>>>>>>>> Update "win.xpstyle.themeActive" desktop property and 
>>>>>>>>>>>>>>> invalidate the
>>>>>>>>>>>>>>> cached XPStyle as soon as windowsSettingChange() is 
>>>>>>>>>>>>>>> called from native
>>>>>>>>>>>>>>> code. Thus when Swing code needs to access theme data, 
>>>>>>>>>>>>>>> it will see no
>>>>>>>>>>>>>>> theme is available and will fallback to classic painting.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Note: Before the fix, PropertyChangeEvents for desktop 
>>>>>>>>>>>>>>> properties in
>>>>>>>>>>>>>>> Windows were fired on the Event Dispatch Thread. With 
>>>>>>>>>>>>>>> this change,
>>>>>>>>>>>>>>> property "win.xpstyle.themeActive" change is fired on 
>>>>>>>>>>>>>>> the toolkit
>>>>>>>>>>>>>>> thread; all other properties are changed on the EDT as 
>>>>>>>>>>>>>>> before.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Regards,
>>>>>>>>>>>>>>> Alexey.
>>>>>>>
>>>>>>
>>>>
>>>
>>


From anthony.petrov at oracle.com  Fri Jun  6 14:03:36 2014
From: anthony.petrov at oracle.com (Anthony Petrov)
Date: Fri, 06 Jun 2014 18:03:36 +0400
Subject: <AWT Dev> <Swing Dev> [9] Review request for JDK-8039383: NPE
 when changing Windows Theme
In-Reply-To: <5391C8EB.5010501@oracle.com>
References: <5350DDBC.30603@oracle.com>	<5351143C.8010100@oracle.com>	<53513B5B.4050104@oracle.com>	<53513C26.9060305@oracle.com>	<53590232.4080703@oracle.com>	<536899D1.1020501@oracle.com>	<53900FA7.8040508@oracle.com>	<0FE09EB0-B3A1-43F4-AE48-401DD55F5B09@oracle.com>	<539022E9.7070907@oracle.com>	<4240D39D-748C-483F-B447-1FAF6DFA25E4@oracle.com>	<5390DC2A.1030502@oracle.com>
	<539178E4.6060101@oracle.com> <53919FBC.9060807@oracle.com>
	<D9978349-8209-44B2-B0E9-6CD94FBF88A2@oracle.com>
	<5391A3BE.3030607@oracle.com> <5391C8EB.5010501@oracle.com>
Message-ID: <5391CA38.60607@oracle.com>

You're welcome.

--
best regards,
Anthony

On 6/6/2014 5:58 PM, Alexey Ivanov wrote:
> Hi Anthony, Petr,
>
> Thank you for reviewing my fix.
>
> Regards,
> Alexey.
>
>
> On 06.06.2014 15:19, Anthony Petrov wrote:
>> +1
>>
>> --
>> best regards,
>> Anthony
>>
>> On 6/6/2014 3:20 PM, Petr Pchelko wrote:
>>> Hello, Alexey.
>>>
>>> The final version still looks good.
>>>
>>> With best regards. Petr.
>>>
>>> On 06 ???? 2014 ?., at 15:02, Alexey Ivanov
>>> <alexey.ivanov at oracle.com> wrote:
>>>
>>>> Hi Anthony, Petr, AWT and Swing teams,
>>>>
>>>> I've addressed Anthony's and Petr's comments in the updated webrev:
>>>> http://cr.openjdk.java.net/~aivanov/8039383/jdk9/webrev.04/
>>>>
>>>> Thank you,
>>>> Alexey.
>>>>
>>>> On 06.06.2014 12:16, Alexey Ivanov wrote:
>>>>> Hi Anthony,
>>>>>
>>>>> Thank you for your review.
>>>>>
>>>>> I've removed synchronized modifier from updateProperties() method
>>>>> which protected access to wprops field. Now this field is accessed
>>>>> from synchronized methods lazilyInitWProps() and getWProps();
>>>>> setDesktopProperty also has proper synchronization - that was my
>>>>> reasoning for removing synchronized.
>>>>>
>>>>> But you're right, it was not the right decision as the update loop
>>>>> now could execute simultaneously which is undesirable. I'll put
>>>>> synchronized modifier to updateProperties() method.
>>>>>
>>>>> Regards,
>>>>> Alexey.
>>>>>
>>>>> On 06.06.2014 1:07, Anthony Petrov wrote:
>>>>>> Hi Alexey,
>>>>>>
>>>>>> In WToolkit.java you're removing the synchronized modifier from
>>>>>> the private updateProperties() method. And it looks like the
>>>>>> method itself does allow for calling from multiple threads. So I'm
>>>>>> concerned about the lack of synchronization in this method. Was
>>>>>> the removal intentional? How is the method supposed to work now
>>>>>> when called from multiple threads?
>>>>>>
>>>>>> --
>>>>>> best regards,
>>>>>> Anthony
>>>>>>
>>>>>> On 6/5/2014 12:16 PM, Petr Pchelko wrote:
>>>>>>> Thank you for clarifications, I've been most interested in #2
>>>>>>> obviously.
>>>>>>>
>>>>>>> The fix looks good to me.
>>>>>>>
>>>>>>> With best regards. Petr.
>>>>>>>
>>>>>>> On 05 ???? 2014 ?., at 11:57, Alexey Ivanov
>>>>>>> <alexey.ivanov at oracle.com> wrote:
>>>>>>>
>>>>>>>> Hello Petr,
>>>>>>>>
>>>>>>>> Thank you for your comments.
>>>>>>>>
>>>>>>>> 1. Sure, I'll remove the comment before the change set is pushed.
>>>>>>>> 2. No, I didn't try stub XPStyle object. First of all, UI
>>>>>>>> delegates decide what painting method to use depending on
>>>>>>>> whether XPStyle.getXP() returns null or not. If XPStyle.getXP()
>>>>>>>> always returns non-null value, we'll have re-implement all UI
>>>>>>>> delegates for Windows plaf, and I believe it would result in
>>>>>>>> larger changeset. Additionally, some classes fallback to
>>>>>>>> inherited behavior where XPStyle.getXP() is not available.
>>>>>>>> Another reason is that UI delegates cache Skins: those objects
>>>>>>>> shouldn't paint where theming is unavailable.
>>>>>>>> 3. No, I haven't filed any bugs yet. I'll file all the issues
>>>>>>>> I've found in the nearest future.
>>>>>>>>
>>>>>>>> Regards,
>>>>>>>> Alexey.
>>>>>>>>
>>>>>>>> On 05.06.2014 11:08, Petr Pchelko wrote:
>>>>>>>>> Hello, Alexey.
>>>>>>>>>
>>>>>>>>> A couple of comments:
>>>>>>>>> 1. ThemeReader:64 - I suggest to remove that comment as it does
>>>>>>>>> not add any value. The variable name is self explanatory.
>>>>>>>>> 2. XPStyle - did you try providing a stub XPStyle object
>>>>>>>>> instead of changing many of it's methods? Do I understand
>>>>>>>>> correctly that this
>>>>>>>>> is not possible because XPstyle is cached in many place is our
>>>>>>>>> code?
>>>>>>>>> 3. In offline discussion you've mentioned that you've found
>>>>>>>>> another related issue. Did you have a chance to file a bug
>>>>>>>>> about it?
>>>>>>>>>
>>>>>>>>> Thank you.
>>>>>>>>> With best regards. Petr.
>>>>>>>>>
>>>>>>>>> On 05 ???? 2014 ?., at 10:35, Alexey Ivanov
>>>>>>>>> <alexey.ivanov at oracle.com> wrote:
>>>>>>>>>
>>>>>>>>>> Hi AWT and Swing teams,
>>>>>>>>>>
>>>>>>>>>> Could you please review the updated fix:
>>>>>>>>>> http://cr.openjdk.java.net/~aivanov/8039383/jdk9/webrev.03/
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> What has changed since version .02?
>>>>>>>>>>
>>>>>>>>>> During additional testing, I found another scenario where NPE
>>>>>>>>>> was thrown. So the new version adds more checks to prevent
>>>>>>>>>> access to XPStyle and ThemeReader where Windows visual styles
>>>>>>>>>> become unavailable.
>>>>>>>>>>
>>>>>>>>>> As in previous version, getters in XPStyle class check for
>>>>>>>>>> null values and return dummy defaults if ThemeReader returned
>>>>>>>>>> null. Skin painters also check whether theming is still
>>>>>>>>>> available before asking ThemeReader to paint.
>>>>>>>>>>
>>>>>>>>>> Access to XPStyle.xp instance is blocked as soon as user
>>>>>>>>>> switched themes. The object will be cleaned when the
>>>>>>>>>> corresponding PropertyChangeEvent is handled by Swing.
>>>>>>>>>>
>>>>>>>>>> Thank you,
>>>>>>>>>> Alexey.
>>>>>>>>>>
>>>>>>>>>> On 06.05.2014 12:14, Alexey Ivanov wrote:
>>>>>>>>>>> Hi AWT and Swing teams,
>>>>>>>>>>>
>>>>>>>>>>> Could you please review the updated fix:
>>>>>>>>>>> http://cr.openjdk.java.net/~dmarkov/8039383/jdk9/webrev.02/
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> What has changed since version .01?
>>>>>>>>>>>
>>>>>>>>>>> The issue was still reproducible with the .01 version of the
>>>>>>>>>>> fix, however it was harder to reproduce.
>>>>>>>>>>>
>>>>>>>>>>> So in version .02 I added checks for null where possible. If
>>>>>>>>>>> theme becomes unavailable, a dummy value will be used; this
>>>>>>>>>>> way applications will be more stable. As soon as the theme
>>>>>>>>>>> change events are handled, the entire UI will update properly.
>>>>>>>>>>>
>>>>>>>>>>> Thank you,
>>>>>>>>>>> Alexey.
>>>>>>>>>>>
>>>>>>>>>>> On 24.04.2014 16:23, Alexey Ivanov wrote:
>>>>>>>>>>>> Hi Anthony, AWT and Swing teams,
>>>>>>>>>>>>
>>>>>>>>>>>> Here's the updated fix:
>>>>>>>>>>>> http://cr.openjdk.java.net/~dmarkov/8039383/jdk9/webrev.01/
>>>>>>>>>>>>
>>>>>>>>>>>> Description:
>>>>>>>>>>>> In the new version of the fix, I use a new xpstyleEnabled
>>>>>>>>>>>> field of AtomicBoolean in WToolkit to track the current
>>>>>>>>>>>> value of "win.xpstyle.themeActive" desktop property. Its
>>>>>>>>>>>> value is updated in windowsSettingChange() and in
>>>>>>>>>>>> updateProperties().
>>>>>>>>>>>> XPStyle.getXP() checks its cached value in themeActive and
>>>>>>>>>>>> the current value in WToolkit; if the value changes, it
>>>>>>>>>>>> schedules updateAllUIs and invalidates the current style
>>>>>>>>>>>> right away, so that components would not access data from
>>>>>>>>>>>> the theme that became unavailable.
>>>>>>>>>>>> Two functions in ThemeReader also check this special field
>>>>>>>>>>>> from WToolkit which prevents throwing InternalError when
>>>>>>>>>>>> paint is called before theme change is fully handled.
>>>>>>>>>>>>
>>>>>>>>>>>> Before updateAllUIs is invoked, it's possible that
>>>>>>>>>>>> application will paint with some values cached from the
>>>>>>>>>>>> previous theme. Usually it happens before "Theme change"
>>>>>>>>>>>> dialog disappears from the screen, at least I noticed no UI
>>>>>>>>>>>> glitches during normal theme change.
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Regression test:
>>>>>>>>>>>> No regression test is provided due to its complexity.
>>>>>>>>>>>> Additionally, 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.
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Thank you,
>>>>>>>>>>>> Alexey.
>>>>>>>>>>>>
>>>>>>>>>>>> On 18.04.2014 18:52, Anthony Petrov wrote:
>>>>>>>>>>>>> Hi Alexey,
>>>>>>>>>>>>>
>>>>>>>>>>>>> No, unfortunately I don't have any suggestions right now.
>>>>>>>>>>>>>
>>>>>>>>>>>>> As for allowing executing user code on the toolkit thread,
>>>>>>>>>>>>> we can't accept such a fix. Sorry about that.
>>>>>>>>>>>>>
>>>>>>>>>>>>> --
>>>>>>>>>>>>> best regards,
>>>>>>>>>>>>> Anthony
>>>>>>>>>>>>>
>>>>>>>>>>>>> On 4/18/2014 6:48 PM, Alexey Ivanov wrote:
>>>>>>>>>>>>>> Hi Anthony,
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Thank you for your review.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Yes, user code can install a property change listener...
>>>>>>>>>>>>>> It was my
>>>>>>>>>>>>>> concern too, that's why I explicitly noted about this.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Do you have any suggestion how this situation can be handled?
>>>>>>>>>>>>>> Is it a general rule that all desktop property change
>>>>>>>>>>>>>> listeners must be
>>>>>>>>>>>>>> called on EDT?
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>>> Alexey.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On 18.04.2014 16:02, Anthony Petrov wrote:
>>>>>>>>>>>>>>> Hi Alexey,
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> With this change, property "win.xpstyle.themeActive"
>>>>>>>>>>>>>>>> change is fired
>>>>>>>>>>>>>>>> on the toolkit thread
>>>>>>>>>>>>>>> Is it possible to install a change listener for this
>>>>>>>>>>>>>>> property from
>>>>>>>>>>>>>>> user code, and hence eventually allow executing some user
>>>>>>>>>>>>>>> code on the
>>>>>>>>>>>>>>> toolkit thread with your fix?
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>> best regards,
>>>>>>>>>>>>>>> Anthony
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> On 4/18/2014 12:09 PM, Alexey Ivanov wrote:
>>>>>>>>>>>>>>>> Hello Swing and AWT teams,
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Could you please review the fix for jdk9:
>>>>>>>>>>>>>>>>      bug: https://bugs.openjdk.java.net/browse/JDK-8039383
>>>>>>>>>>>>>>>>      webrev:
>>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~dmarkov/8039383/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 "cached" in XPStyle object. When
>>>>>>>>>>>>>>>> the theme is
>>>>>>>>>>>>>>>> switched to a classic one, HTHEME handle becomes
>>>>>>>>>>>>>>>> unavailable and data
>>>>>>>>>>>>>>>> cannot be accessed from the theme any more. The change
>>>>>>>>>>>>>>>> in theme in
>>>>>>>>>>>>>>>> posted to EDT via invokeLater. At the same time, the UI
>>>>>>>>>>>>>>>> needs to repaint
>>>>>>>>>>>>>>>> itself as soon as Windows changed the theme, and paint
>>>>>>>>>>>>>>>> code is often
>>>>>>>>>>>>>>>> called before the theme change is handled in Java. This
>>>>>>>>>>>>>>>> leads to NPE and
>>>>>>>>>>>>>>>> InternalError as the code tries to access the data that
>>>>>>>>>>>>>>>> has become
>>>>>>>>>>>>>>>> unavailable.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> The fix:
>>>>>>>>>>>>>>>> Update "win.xpstyle.themeActive" desktop property and
>>>>>>>>>>>>>>>> invalidate the
>>>>>>>>>>>>>>>> cached XPStyle as soon as windowsSettingChange() is
>>>>>>>>>>>>>>>> called from native
>>>>>>>>>>>>>>>> code. Thus when Swing code needs to access theme data,
>>>>>>>>>>>>>>>> it will see no
>>>>>>>>>>>>>>>> theme is available and will fallback to classic painting.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Note: Before the fix, PropertyChangeEvents for desktop
>>>>>>>>>>>>>>>> properties in
>>>>>>>>>>>>>>>> Windows were fired on the Event Dispatch Thread. With
>>>>>>>>>>>>>>>> this change,
>>>>>>>>>>>>>>>> property "win.xpstyle.themeActive" change is fired on
>>>>>>>>>>>>>>>> the toolkit
>>>>>>>>>>>>>>>> thread; all other properties are changed on the EDT as
>>>>>>>>>>>>>>>> before.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Regards,
>>>>>>>>>>>>>>>> Alexey.
>>>>>>>>
>>>>>>>
>>>>>
>>>>
>>>
>

From anthony.petrov at oracle.com  Fri Jun  6 14:12:30 2014
From: anthony.petrov at oracle.com (Anthony Petrov)
Date: Fri, 06 Jun 2014 18:12:30 +0400
Subject: <AWT Dev> Review Request: 8046221 [TEST_BUG] Cleanup
	datatransfer tests
In-Reply-To: <778EB5FC-D8C6-4423-97FE-50C932B00584@oracle.com>
References: <778EB5FC-D8C6-4423-97FE-50C932B00584@oracle.com>
Message-ID: <5391CC4E.6050505@oracle.com>

Hi Petr,

I've skimmed through a few tests (didn't review all of them), and they 
look fine. The 100% pass rate also sounds optimistic.

So, +1.

--
best regards,
Anthony

On 6/6/2014 5:05 PM, Petr Pchelko wrote:
> Hello, AWT Team.
>
> Please review the fix for the issue:
> https://bugs.openjdk.java.net/browse/JDK-8046221
> The fix is available at:
> http://cr.openjdk.java.net/~pchelko/9/8046221/webrev/
>
> During my datatransfer modularization work I've needed to run some tests, but all our datatransfer
> tests depend on desktop and fail due to some other bug in jigsaw.  So I've cleaned them up,
> opensourced a bunch of tests and moved other test to the correct locations.
>
> The pass rate in 100% for normal build.
>
> With best regards. Petr.
>

From alexander.zvegintsev at oracle.com  Fri Jun  6 16:00:32 2014
From: alexander.zvegintsev at oracle.com (Alexander Zvegintsev)
Date: Fri, 06 Jun 2014 20:00:32 +0400
Subject: <AWT Dev> [9] Review request: 8040007 GtkFileDialog strips user
	inputted filepath
Message-ID: <5391E5A0.4020106@oracle.com>

Hello,

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

With this fix we don't use current folder from native GtkFileChooser 
anymore, now we build it by ourselves.

[1] 
https://developer.gnome.org/gtk2/stable/GtkFileChooser.html#gtk-file-chooser-get-filenames
[2] 
https://developer.gnome.org/glib/stable/glib-Miscellaneous-Utility-Functions.html#g-path-get-dirname

-- 
Thanks,

Alexander.


From philip.race at oracle.com  Fri Jun  6 17:48:32 2014
From: philip.race at oracle.com (Phil Race)
Date: Fri, 06 Jun 2014 10:48:32 -0700
Subject: <AWT Dev> <Swing Dev> [9] Review request for JDK-8039383: NPE
 when changing Windows Theme
In-Reply-To: <5391CA38.60607@oracle.com>
References: <5350DDBC.30603@oracle.com>	<5351143C.8010100@oracle.com>	<53513B5B.4050104@oracle.com>	<53513C26.9060305@oracle.com>	<53590232.4080703@oracle.com>	<536899D1.1020501@oracle.com>	<53900FA7.8040508@oracle.com>	<0FE09EB0-B3A1-43F4-AE48-401DD55F5B09@oracle.com>	<539022E9.7070907@oracle.com>	<4240D39D-748C-483F-B447-1FAF6DFA25E4@oracle.com>	<5390DC2A.1030502@oracle.com>	<539178E4.6060101@oracle.com>
	<53919FBC.9060807@oracle.com>	<D9978349-8209-44B2-B0E9-6CD94FBF88A2@oracle.com>	<5391A3BE.3030607@oracle.com>
	<5391C8EB.5010501@oracle.com> <5391CA38.60607@oracle.com>
Message-ID: <5391FEF0.6080003@oracle.com>

ahem, this is a "bad fix". It has broken all non-windows builds because 
shared code
is now referencing WToolkit and ThemeReader. Please back out this fix 
ASAP ..

-phil.

On 6/6/2014 7:03 AM, Anthony Petrov wrote:
> You're welcome.
>
> -- 
> best regards,
> Anthony
>
> On 6/6/2014 5:58 PM, Alexey Ivanov wrote:
>> Hi Anthony, Petr,
>>
>> Thank you for reviewing my fix.
>>
>> Regards,
>> Alexey.
>>
>>
>> On 06.06.2014 15:19, Anthony Petrov wrote:
>>> +1
>>>
>>> -- 
>>> best regards,
>>> Anthony
>>>
>>> On 6/6/2014 3:20 PM, Petr Pchelko wrote:
>>>> Hello, Alexey.
>>>>
>>>> The final version still looks good.
>>>>
>>>> With best regards. Petr.
>>>>
>>>> On 06 ???? 2014 ?., at 15:02, Alexey Ivanov
>>>> <alexey.ivanov at oracle.com> wrote:
>>>>
>>>>> Hi Anthony, Petr, AWT and Swing teams,
>>>>>
>>>>> I've addressed Anthony's and Petr's comments in the updated webrev:
>>>>> http://cr.openjdk.java.net/~aivanov/8039383/jdk9/webrev.04/
>>>>>
>>>>> Thank you,
>>>>> Alexey.
>>>>>
>>>>> On 06.06.2014 12:16, Alexey Ivanov wrote:
>>>>>> Hi Anthony,
>>>>>>
>>>>>> Thank you for your review.
>>>>>>
>>>>>> I've removed synchronized modifier from updateProperties() method
>>>>>> which protected access to wprops field. Now this field is accessed
>>>>>> from synchronized methods lazilyInitWProps() and getWProps();
>>>>>> setDesktopProperty also has proper synchronization - that was my
>>>>>> reasoning for removing synchronized.
>>>>>>
>>>>>> But you're right, it was not the right decision as the update loop
>>>>>> now could execute simultaneously which is undesirable. I'll put
>>>>>> synchronized modifier to updateProperties() method.
>>>>>>
>>>>>> Regards,
>>>>>> Alexey.
>>>>>>
>>>>>> On 06.06.2014 1:07, Anthony Petrov wrote:
>>>>>>> Hi Alexey,
>>>>>>>
>>>>>>> In WToolkit.java you're removing the synchronized modifier from
>>>>>>> the private updateProperties() method. And it looks like the
>>>>>>> method itself does allow for calling from multiple threads. So I'm
>>>>>>> concerned about the lack of synchronization in this method. Was
>>>>>>> the removal intentional? How is the method supposed to work now
>>>>>>> when called from multiple threads?
>>>>>>>
>>>>>>> -- 
>>>>>>> best regards,
>>>>>>> Anthony
>>>>>>>
>>>>>>> On 6/5/2014 12:16 PM, Petr Pchelko wrote:
>>>>>>>> Thank you for clarifications, I've been most interested in #2
>>>>>>>> obviously.
>>>>>>>>
>>>>>>>> The fix looks good to me.
>>>>>>>>
>>>>>>>> With best regards. Petr.
>>>>>>>>
>>>>>>>> On 05 ???? 2014 ?., at 11:57, Alexey Ivanov
>>>>>>>> <alexey.ivanov at oracle.com> wrote:
>>>>>>>>
>>>>>>>>> Hello Petr,
>>>>>>>>>
>>>>>>>>> Thank you for your comments.
>>>>>>>>>
>>>>>>>>> 1. Sure, I'll remove the comment before the change set is pushed.
>>>>>>>>> 2. No, I didn't try stub XPStyle object. First of all, UI
>>>>>>>>> delegates decide what painting method to use depending on
>>>>>>>>> whether XPStyle.getXP() returns null or not. If XPStyle.getXP()
>>>>>>>>> always returns non-null value, we'll have re-implement all UI
>>>>>>>>> delegates for Windows plaf, and I believe it would result in
>>>>>>>>> larger changeset. Additionally, some classes fallback to
>>>>>>>>> inherited behavior where XPStyle.getXP() is not available.
>>>>>>>>> Another reason is that UI delegates cache Skins: those objects
>>>>>>>>> shouldn't paint where theming is unavailable.
>>>>>>>>> 3. No, I haven't filed any bugs yet. I'll file all the issues
>>>>>>>>> I've found in the nearest future.
>>>>>>>>>
>>>>>>>>> Regards,
>>>>>>>>> Alexey.
>>>>>>>>>
>>>>>>>>> On 05.06.2014 11:08, Petr Pchelko wrote:
>>>>>>>>>> Hello, Alexey.
>>>>>>>>>>
>>>>>>>>>> A couple of comments:
>>>>>>>>>> 1. ThemeReader:64 - I suggest to remove that comment as it does
>>>>>>>>>> not add any value. The variable name is self explanatory.
>>>>>>>>>> 2. XPStyle - did you try providing a stub XPStyle object
>>>>>>>>>> instead of changing many of it's methods? Do I understand
>>>>>>>>>> correctly that this
>>>>>>>>>> is not possible because XPstyle is cached in many place is our
>>>>>>>>>> code?
>>>>>>>>>> 3. In offline discussion you've mentioned that you've found
>>>>>>>>>> another related issue. Did you have a chance to file a bug
>>>>>>>>>> about it?
>>>>>>>>>>
>>>>>>>>>> Thank you.
>>>>>>>>>> With best regards. Petr.
>>>>>>>>>>
>>>>>>>>>> On 05 ???? 2014 ?., at 10:35, Alexey Ivanov
>>>>>>>>>> <alexey.ivanov at oracle.com> wrote:
>>>>>>>>>>
>>>>>>>>>>> Hi AWT and Swing teams,
>>>>>>>>>>>
>>>>>>>>>>> Could you please review the updated fix:
>>>>>>>>>>> http://cr.openjdk.java.net/~aivanov/8039383/jdk9/webrev.03/
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> What has changed since version .02?
>>>>>>>>>>>
>>>>>>>>>>> During additional testing, I found another scenario where NPE
>>>>>>>>>>> was thrown. So the new version adds more checks to prevent
>>>>>>>>>>> access to XPStyle and ThemeReader where Windows visual styles
>>>>>>>>>>> become unavailable.
>>>>>>>>>>>
>>>>>>>>>>> As in previous version, getters in XPStyle class check for
>>>>>>>>>>> null values and return dummy defaults if ThemeReader returned
>>>>>>>>>>> null. Skin painters also check whether theming is still
>>>>>>>>>>> available before asking ThemeReader to paint.
>>>>>>>>>>>
>>>>>>>>>>> Access to XPStyle.xp instance is blocked as soon as user
>>>>>>>>>>> switched themes. The object will be cleaned when the
>>>>>>>>>>> corresponding PropertyChangeEvent is handled by Swing.
>>>>>>>>>>>
>>>>>>>>>>> Thank you,
>>>>>>>>>>> Alexey.
>>>>>>>>>>>
>>>>>>>>>>> On 06.05.2014 12:14, Alexey Ivanov wrote:
>>>>>>>>>>>> Hi AWT and Swing teams,
>>>>>>>>>>>>
>>>>>>>>>>>> Could you please review the updated fix:
>>>>>>>>>>>> http://cr.openjdk.java.net/~dmarkov/8039383/jdk9/webrev.02/
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> What has changed since version .01?
>>>>>>>>>>>>
>>>>>>>>>>>> The issue was still reproducible with the .01 version of the
>>>>>>>>>>>> fix, however it was harder to reproduce.
>>>>>>>>>>>>
>>>>>>>>>>>> So in version .02 I added checks for null where possible. If
>>>>>>>>>>>> theme becomes unavailable, a dummy value will be used; this
>>>>>>>>>>>> way applications will be more stable. As soon as the theme
>>>>>>>>>>>> change events are handled, the entire UI will update properly.
>>>>>>>>>>>>
>>>>>>>>>>>> Thank you,
>>>>>>>>>>>> Alexey.
>>>>>>>>>>>>
>>>>>>>>>>>> On 24.04.2014 16:23, Alexey Ivanov wrote:
>>>>>>>>>>>>> Hi Anthony, AWT and Swing teams,
>>>>>>>>>>>>>
>>>>>>>>>>>>> Here's the updated fix:
>>>>>>>>>>>>> http://cr.openjdk.java.net/~dmarkov/8039383/jdk9/webrev.01/
>>>>>>>>>>>>>
>>>>>>>>>>>>> Description:
>>>>>>>>>>>>> In the new version of the fix, I use a new xpstyleEnabled
>>>>>>>>>>>>> field of AtomicBoolean in WToolkit to track the current
>>>>>>>>>>>>> value of "win.xpstyle.themeActive" desktop property. Its
>>>>>>>>>>>>> value is updated in windowsSettingChange() and in
>>>>>>>>>>>>> updateProperties().
>>>>>>>>>>>>> XPStyle.getXP() checks its cached value in themeActive and
>>>>>>>>>>>>> the current value in WToolkit; if the value changes, it
>>>>>>>>>>>>> schedules updateAllUIs and invalidates the current style
>>>>>>>>>>>>> right away, so that components would not access data from
>>>>>>>>>>>>> the theme that became unavailable.
>>>>>>>>>>>>> Two functions in ThemeReader also check this special field
>>>>>>>>>>>>> from WToolkit which prevents throwing InternalError when
>>>>>>>>>>>>> paint is called before theme change is fully handled.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Before updateAllUIs is invoked, it's possible that
>>>>>>>>>>>>> application will paint with some values cached from the
>>>>>>>>>>>>> previous theme. Usually it happens before "Theme change"
>>>>>>>>>>>>> dialog disappears from the screen, at least I noticed no UI
>>>>>>>>>>>>> glitches during normal theme change.
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> Regression test:
>>>>>>>>>>>>> No regression test is provided due to its complexity.
>>>>>>>>>>>>> Additionally, 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.
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> Thank you,
>>>>>>>>>>>>> Alexey.
>>>>>>>>>>>>>
>>>>>>>>>>>>> On 18.04.2014 18:52, Anthony Petrov wrote:
>>>>>>>>>>>>>> Hi Alexey,
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> No, unfortunately I don't have any suggestions right now.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> As for allowing executing user code on the toolkit thread,
>>>>>>>>>>>>>> we can't accept such a fix. Sorry about that.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> -- 
>>>>>>>>>>>>>> best regards,
>>>>>>>>>>>>>> Anthony
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On 4/18/2014 6:48 PM, Alexey Ivanov wrote:
>>>>>>>>>>>>>>> Hi Anthony,
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Thank you for your review.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Yes, user code can install a property change listener...
>>>>>>>>>>>>>>> It was my
>>>>>>>>>>>>>>> concern too, that's why I explicitly noted about this.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Do you have any suggestion how this situation can be 
>>>>>>>>>>>>>>> handled?
>>>>>>>>>>>>>>> Is it a general rule that all desktop property change
>>>>>>>>>>>>>>> listeners must be
>>>>>>>>>>>>>>> called on EDT?
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>>>> Alexey.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> On 18.04.2014 16:02, Anthony Petrov wrote:
>>>>>>>>>>>>>>>> Hi Alexey,
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> With this change, property "win.xpstyle.themeActive"
>>>>>>>>>>>>>>>>> change is fired
>>>>>>>>>>>>>>>>> on the toolkit thread
>>>>>>>>>>>>>>>> Is it possible to install a change listener for this
>>>>>>>>>>>>>>>> property from
>>>>>>>>>>>>>>>> user code, and hence eventually allow executing some user
>>>>>>>>>>>>>>>> code on the
>>>>>>>>>>>>>>>> toolkit thread with your fix?
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> -- 
>>>>>>>>>>>>>>>> best regards,
>>>>>>>>>>>>>>>> Anthony
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> On 4/18/2014 12:09 PM, Alexey Ivanov wrote:
>>>>>>>>>>>>>>>>> Hello Swing and AWT teams,
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Could you please review the fix for jdk9:
>>>>>>>>>>>>>>>>>      bug: 
>>>>>>>>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8039383
>>>>>>>>>>>>>>>>>      webrev:
>>>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~dmarkov/8039383/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 "cached" in XPStyle object. When
>>>>>>>>>>>>>>>>> the theme is
>>>>>>>>>>>>>>>>> switched to a classic one, HTHEME handle becomes
>>>>>>>>>>>>>>>>> unavailable and data
>>>>>>>>>>>>>>>>> cannot be accessed from the theme any more. The change
>>>>>>>>>>>>>>>>> in theme in
>>>>>>>>>>>>>>>>> posted to EDT via invokeLater. At the same time, the UI
>>>>>>>>>>>>>>>>> needs to repaint
>>>>>>>>>>>>>>>>> itself as soon as Windows changed the theme, and paint
>>>>>>>>>>>>>>>>> code is often
>>>>>>>>>>>>>>>>> called before the theme change is handled in Java. This
>>>>>>>>>>>>>>>>> leads to NPE and
>>>>>>>>>>>>>>>>> InternalError as the code tries to access the data that
>>>>>>>>>>>>>>>>> has become
>>>>>>>>>>>>>>>>> unavailable.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> The fix:
>>>>>>>>>>>>>>>>> Update "win.xpstyle.themeActive" desktop property and
>>>>>>>>>>>>>>>>> invalidate the
>>>>>>>>>>>>>>>>> cached XPStyle as soon as windowsSettingChange() is
>>>>>>>>>>>>>>>>> called from native
>>>>>>>>>>>>>>>>> code. Thus when Swing code needs to access theme data,
>>>>>>>>>>>>>>>>> it will see no
>>>>>>>>>>>>>>>>> theme is available and will fallback to classic painting.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Note: Before the fix, PropertyChangeEvents for desktop
>>>>>>>>>>>>>>>>> properties in
>>>>>>>>>>>>>>>>> Windows were fired on the Event Dispatch Thread. With
>>>>>>>>>>>>>>>>> this change,
>>>>>>>>>>>>>>>>> property "win.xpstyle.themeActive" change is fired on
>>>>>>>>>>>>>>>>> the toolkit
>>>>>>>>>>>>>>>>> thread; all other properties are changed on the EDT as
>>>>>>>>>>>>>>>>> before.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Regards,
>>>>>>>>>>>>>>>>> Alexey.
>>>>>>>>>
>>>>>>>>
>>>>>>
>>>>>
>>>>
>>


From philip.race at oracle.com  Fri Jun  6 17:54:01 2014
From: philip.race at oracle.com (Phil Race)
Date: Fri, 06 Jun 2014 10:54:01 -0700
Subject: <AWT Dev> <Swing Dev> [9] Review request for JDK-8039383: NPE
 when changing Windows Theme
In-Reply-To: <5391FEF0.6080003@oracle.com>
References: <5350DDBC.30603@oracle.com>	<5351143C.8010100@oracle.com>	<53513B5B.4050104@oracle.com>	<53513C26.9060305@oracle.com>	<53590232.4080703@oracle.com>	<536899D1.1020501@oracle.com>	<53900FA7.8040508@oracle.com>	<0FE09EB0-B3A1-43F4-AE48-401DD55F5B09@oracle.com>	<539022E9.7070907@oracle.com>	<4240D39D-748C-483F-B447-1FAF6DFA25E4@oracle.com>	<5390DC2A.1030502@oracle.com>	<539178E4.6060101@oracle.com>	<53919FBC.9060807@oracle.com>	<D9978349-8209-44B2-B0E9-6CD94FBF88A2@oracle.com>	<5391A3BE.3030607@oracle.com>	<5391C8EB.5010501@oracle.com>
	<5391CA38.60607@oracle.com> <5391FEF0.6080003@oracle.com>
Message-ID: <53920039.7080801@oracle.com>

I filed P1 bug https://bugs.openjdk.java.net/browse/JDK-8046239

You really should at least build on other platforms and you can use JPRT 
for that ..
Testing would be good too ..

-phil.

On 6/6/2014 10:48 AM, Phil Race wrote:
> ahem, this is a "bad fix". It has broken all non-windows builds 
> because shared code
> is now referencing WToolkit and ThemeReader. Please back out this fix 
> ASAP ..
>
> -phil.
>
> On 6/6/2014 7:03 AM, Anthony Petrov wrote:
>> You're welcome.
>>
>> -- 
>> best regards,
>> Anthony
>>
>> On 6/6/2014 5:58 PM, Alexey Ivanov wrote:
>>> Hi Anthony, Petr,
>>>
>>> Thank you for reviewing my fix.
>>>
>>> Regards,
>>> Alexey.
>>>
>>>
>>> On 06.06.2014 15:19, Anthony Petrov wrote:
>>>> +1
>>>>
>>>> -- 
>>>> best regards,
>>>> Anthony
>>>>
>>>> On 6/6/2014 3:20 PM, Petr Pchelko wrote:
>>>>> Hello, Alexey.
>>>>>
>>>>> The final version still looks good.
>>>>>
>>>>> With best regards. Petr.
>>>>>
>>>>> On 06 ???? 2014 ?., at 15:02, Alexey Ivanov
>>>>> <alexey.ivanov at oracle.com> wrote:
>>>>>
>>>>>> Hi Anthony, Petr, AWT and Swing teams,
>>>>>>
>>>>>> I've addressed Anthony's and Petr's comments in the updated webrev:
>>>>>> http://cr.openjdk.java.net/~aivanov/8039383/jdk9/webrev.04/
>>>>>>
>>>>>> Thank you,
>>>>>> Alexey.
>>>>>>
>>>>>> On 06.06.2014 12:16, Alexey Ivanov wrote:
>>>>>>> Hi Anthony,
>>>>>>>
>>>>>>> Thank you for your review.
>>>>>>>
>>>>>>> I've removed synchronized modifier from updateProperties() method
>>>>>>> which protected access to wprops field. Now this field is accessed
>>>>>>> from synchronized methods lazilyInitWProps() and getWProps();
>>>>>>> setDesktopProperty also has proper synchronization - that was my
>>>>>>> reasoning for removing synchronized.
>>>>>>>
>>>>>>> But you're right, it was not the right decision as the update loop
>>>>>>> now could execute simultaneously which is undesirable. I'll put
>>>>>>> synchronized modifier to updateProperties() method.
>>>>>>>
>>>>>>> Regards,
>>>>>>> Alexey.
>>>>>>>
>>>>>>> On 06.06.2014 1:07, Anthony Petrov wrote:
>>>>>>>> Hi Alexey,
>>>>>>>>
>>>>>>>> In WToolkit.java you're removing the synchronized modifier from
>>>>>>>> the private updateProperties() method. And it looks like the
>>>>>>>> method itself does allow for calling from multiple threads. So I'm
>>>>>>>> concerned about the lack of synchronization in this method. Was
>>>>>>>> the removal intentional? How is the method supposed to work now
>>>>>>>> when called from multiple threads?
>>>>>>>>
>>>>>>>> -- 
>>>>>>>> best regards,
>>>>>>>> Anthony
>>>>>>>>
>>>>>>>> On 6/5/2014 12:16 PM, Petr Pchelko wrote:
>>>>>>>>> Thank you for clarifications, I've been most interested in #2
>>>>>>>>> obviously.
>>>>>>>>>
>>>>>>>>> The fix looks good to me.
>>>>>>>>>
>>>>>>>>> With best regards. Petr.
>>>>>>>>>
>>>>>>>>> On 05 ???? 2014 ?., at 11:57, Alexey Ivanov
>>>>>>>>> <alexey.ivanov at oracle.com> wrote:
>>>>>>>>>
>>>>>>>>>> Hello Petr,
>>>>>>>>>>
>>>>>>>>>> Thank you for your comments.
>>>>>>>>>>
>>>>>>>>>> 1. Sure, I'll remove the comment before the change set is 
>>>>>>>>>> pushed.
>>>>>>>>>> 2. No, I didn't try stub XPStyle object. First of all, UI
>>>>>>>>>> delegates decide what painting method to use depending on
>>>>>>>>>> whether XPStyle.getXP() returns null or not. If XPStyle.getXP()
>>>>>>>>>> always returns non-null value, we'll have re-implement all UI
>>>>>>>>>> delegates for Windows plaf, and I believe it would result in
>>>>>>>>>> larger changeset. Additionally, some classes fallback to
>>>>>>>>>> inherited behavior where XPStyle.getXP() is not available.
>>>>>>>>>> Another reason is that UI delegates cache Skins: those objects
>>>>>>>>>> shouldn't paint where theming is unavailable.
>>>>>>>>>> 3. No, I haven't filed any bugs yet. I'll file all the issues
>>>>>>>>>> I've found in the nearest future.
>>>>>>>>>>
>>>>>>>>>> Regards,
>>>>>>>>>> Alexey.
>>>>>>>>>>
>>>>>>>>>> On 05.06.2014 11:08, Petr Pchelko wrote:
>>>>>>>>>>> Hello, Alexey.
>>>>>>>>>>>
>>>>>>>>>>> A couple of comments:
>>>>>>>>>>> 1. ThemeReader:64 - I suggest to remove that comment as it does
>>>>>>>>>>> not add any value. The variable name is self explanatory.
>>>>>>>>>>> 2. XPStyle - did you try providing a stub XPStyle object
>>>>>>>>>>> instead of changing many of it's methods? Do I understand
>>>>>>>>>>> correctly that this
>>>>>>>>>>> is not possible because XPstyle is cached in many place is our
>>>>>>>>>>> code?
>>>>>>>>>>> 3. In offline discussion you've mentioned that you've found
>>>>>>>>>>> another related issue. Did you have a chance to file a bug
>>>>>>>>>>> about it?
>>>>>>>>>>>
>>>>>>>>>>> Thank you.
>>>>>>>>>>> With best regards. Petr.
>>>>>>>>>>>
>>>>>>>>>>> On 05 ???? 2014 ?., at 10:35, Alexey Ivanov
>>>>>>>>>>> <alexey.ivanov at oracle.com> wrote:
>>>>>>>>>>>
>>>>>>>>>>>> Hi AWT and Swing teams,
>>>>>>>>>>>>
>>>>>>>>>>>> Could you please review the updated fix:
>>>>>>>>>>>> http://cr.openjdk.java.net/~aivanov/8039383/jdk9/webrev.03/
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> What has changed since version .02?
>>>>>>>>>>>>
>>>>>>>>>>>> During additional testing, I found another scenario where NPE
>>>>>>>>>>>> was thrown. So the new version adds more checks to prevent
>>>>>>>>>>>> access to XPStyle and ThemeReader where Windows visual styles
>>>>>>>>>>>> become unavailable.
>>>>>>>>>>>>
>>>>>>>>>>>> As in previous version, getters in XPStyle class check for
>>>>>>>>>>>> null values and return dummy defaults if ThemeReader returned
>>>>>>>>>>>> null. Skin painters also check whether theming is still
>>>>>>>>>>>> available before asking ThemeReader to paint.
>>>>>>>>>>>>
>>>>>>>>>>>> Access to XPStyle.xp instance is blocked as soon as user
>>>>>>>>>>>> switched themes. The object will be cleaned when the
>>>>>>>>>>>> corresponding PropertyChangeEvent is handled by Swing.
>>>>>>>>>>>>
>>>>>>>>>>>> Thank you,
>>>>>>>>>>>> Alexey.
>>>>>>>>>>>>
>>>>>>>>>>>> On 06.05.2014 12:14, Alexey Ivanov wrote:
>>>>>>>>>>>>> Hi AWT and Swing teams,
>>>>>>>>>>>>>
>>>>>>>>>>>>> Could you please review the updated fix:
>>>>>>>>>>>>> http://cr.openjdk.java.net/~dmarkov/8039383/jdk9/webrev.02/
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> What has changed since version .01?
>>>>>>>>>>>>>
>>>>>>>>>>>>> The issue was still reproducible with the .01 version of the
>>>>>>>>>>>>> fix, however it was harder to reproduce.
>>>>>>>>>>>>>
>>>>>>>>>>>>> So in version .02 I added checks for null where possible. If
>>>>>>>>>>>>> theme becomes unavailable, a dummy value will be used; this
>>>>>>>>>>>>> way applications will be more stable. As soon as the theme
>>>>>>>>>>>>> change events are handled, the entire UI will update 
>>>>>>>>>>>>> properly.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Thank you,
>>>>>>>>>>>>> Alexey.
>>>>>>>>>>>>>
>>>>>>>>>>>>> On 24.04.2014 16:23, Alexey Ivanov wrote:
>>>>>>>>>>>>>> Hi Anthony, AWT and Swing teams,
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Here's the updated fix:
>>>>>>>>>>>>>> http://cr.openjdk.java.net/~dmarkov/8039383/jdk9/webrev.01/
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Description:
>>>>>>>>>>>>>> In the new version of the fix, I use a new xpstyleEnabled
>>>>>>>>>>>>>> field of AtomicBoolean in WToolkit to track the current
>>>>>>>>>>>>>> value of "win.xpstyle.themeActive" desktop property. Its
>>>>>>>>>>>>>> value is updated in windowsSettingChange() and in
>>>>>>>>>>>>>> updateProperties().
>>>>>>>>>>>>>> XPStyle.getXP() checks its cached value in themeActive and
>>>>>>>>>>>>>> the current value in WToolkit; if the value changes, it
>>>>>>>>>>>>>> schedules updateAllUIs and invalidates the current style
>>>>>>>>>>>>>> right away, so that components would not access data from
>>>>>>>>>>>>>> the theme that became unavailable.
>>>>>>>>>>>>>> Two functions in ThemeReader also check this special field
>>>>>>>>>>>>>> from WToolkit which prevents throwing InternalError when
>>>>>>>>>>>>>> paint is called before theme change is fully handled.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Before updateAllUIs is invoked, it's possible that
>>>>>>>>>>>>>> application will paint with some values cached from the
>>>>>>>>>>>>>> previous theme. Usually it happens before "Theme change"
>>>>>>>>>>>>>> dialog disappears from the screen, at least I noticed no UI
>>>>>>>>>>>>>> glitches during normal theme change.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Regression test:
>>>>>>>>>>>>>> No regression test is provided due to its complexity.
>>>>>>>>>>>>>> Additionally, 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.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Thank you,
>>>>>>>>>>>>>> Alexey.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On 18.04.2014 18:52, Anthony Petrov wrote:
>>>>>>>>>>>>>>> Hi Alexey,
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> No, unfortunately I don't have any suggestions right now.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> As for allowing executing user code on the toolkit thread,
>>>>>>>>>>>>>>> we can't accept such a fix. Sorry about that.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> -- 
>>>>>>>>>>>>>>> best regards,
>>>>>>>>>>>>>>> Anthony
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> On 4/18/2014 6:48 PM, Alexey Ivanov wrote:
>>>>>>>>>>>>>>>> Hi Anthony,
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Thank you for your review.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Yes, user code can install a property change listener...
>>>>>>>>>>>>>>>> It was my
>>>>>>>>>>>>>>>> concern too, that's why I explicitly noted about this.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Do you have any suggestion how this situation can be 
>>>>>>>>>>>>>>>> handled?
>>>>>>>>>>>>>>>> Is it a general rule that all desktop property change
>>>>>>>>>>>>>>>> listeners must be
>>>>>>>>>>>>>>>> called on EDT?
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>>>>> Alexey.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> On 18.04.2014 16:02, Anthony Petrov wrote:
>>>>>>>>>>>>>>>>> Hi Alexey,
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> With this change, property "win.xpstyle.themeActive"
>>>>>>>>>>>>>>>>>> change is fired
>>>>>>>>>>>>>>>>>> on the toolkit thread
>>>>>>>>>>>>>>>>> Is it possible to install a change listener for this
>>>>>>>>>>>>>>>>> property from
>>>>>>>>>>>>>>>>> user code, and hence eventually allow executing some user
>>>>>>>>>>>>>>>>> code on the
>>>>>>>>>>>>>>>>> toolkit thread with your fix?
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> -- 
>>>>>>>>>>>>>>>>> best regards,
>>>>>>>>>>>>>>>>> Anthony
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> On 4/18/2014 12:09 PM, Alexey Ivanov wrote:
>>>>>>>>>>>>>>>>>> Hello Swing and AWT teams,
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Could you please review the fix for jdk9:
>>>>>>>>>>>>>>>>>>      bug: 
>>>>>>>>>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8039383
>>>>>>>>>>>>>>>>>>      webrev:
>>>>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~dmarkov/8039383/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 "cached" in XPStyle object. When
>>>>>>>>>>>>>>>>>> the theme is
>>>>>>>>>>>>>>>>>> switched to a classic one, HTHEME handle becomes
>>>>>>>>>>>>>>>>>> unavailable and data
>>>>>>>>>>>>>>>>>> cannot be accessed from the theme any more. The change
>>>>>>>>>>>>>>>>>> in theme in
>>>>>>>>>>>>>>>>>> posted to EDT via invokeLater. At the same time, the UI
>>>>>>>>>>>>>>>>>> needs to repaint
>>>>>>>>>>>>>>>>>> itself as soon as Windows changed the theme, and paint
>>>>>>>>>>>>>>>>>> code is often
>>>>>>>>>>>>>>>>>> called before the theme change is handled in Java. This
>>>>>>>>>>>>>>>>>> leads to NPE and
>>>>>>>>>>>>>>>>>> InternalError as the code tries to access the data that
>>>>>>>>>>>>>>>>>> has become
>>>>>>>>>>>>>>>>>> unavailable.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> The fix:
>>>>>>>>>>>>>>>>>> Update "win.xpstyle.themeActive" desktop property and
>>>>>>>>>>>>>>>>>> invalidate the
>>>>>>>>>>>>>>>>>> cached XPStyle as soon as windowsSettingChange() is
>>>>>>>>>>>>>>>>>> called from native
>>>>>>>>>>>>>>>>>> code. Thus when Swing code needs to access theme data,
>>>>>>>>>>>>>>>>>> it will see no
>>>>>>>>>>>>>>>>>> theme is available and will fallback to classic 
>>>>>>>>>>>>>>>>>> painting.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Note: Before the fix, PropertyChangeEvents for desktop
>>>>>>>>>>>>>>>>>> properties in
>>>>>>>>>>>>>>>>>> Windows were fired on the Event Dispatch Thread. With
>>>>>>>>>>>>>>>>>> this change,
>>>>>>>>>>>>>>>>>> property "win.xpstyle.themeActive" change is fired on
>>>>>>>>>>>>>>>>>> the toolkit
>>>>>>>>>>>>>>>>>> thread; all other properties are changed on the EDT as
>>>>>>>>>>>>>>>>>> before.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Regards,
>>>>>>>>>>>>>>>>>> Alexey.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>
>


From alexander.v.stepanov at oracle.com  Mon Jun  9 10:57:51 2014
From: alexander.v.stepanov at oracle.com (alexander stepanov)
Date: Mon, 09 Jun 2014 14:57:51 +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: <5385CB8B.3080207@oracle.com>
References: <5385CB8B.3080207@oracle.com>
Message-ID: <5395932F.7060905@oracle.com>

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 anthony.petrov at oracle.com  Mon Jun  9 11:27:15 2014
From: anthony.petrov at oracle.com (Anthony Petrov)
Date: Mon, 09 Jun 2014 15:27:15 +0400
Subject: <AWT Dev> <Swing Dev> [9] Review request for JDK-8039383: NPE
 when changing Windows Theme
In-Reply-To: <53920039.7080801@oracle.com>
References: <5350DDBC.30603@oracle.com>	<5351143C.8010100@oracle.com>	<53513B5B.4050104@oracle.com>	<53513C26.9060305@oracle.com>	<53590232.4080703@oracle.com>	<536899D1.1020501@oracle.com>	<53900FA7.8040508@oracle.com>	<0FE09EB0-B3A1-43F4-AE48-401DD55F5B09@oracle.com>	<539022E9.7070907@oracle.com>	<4240D39D-748C-483F-B447-1FAF6DFA25E4@oracle.com>	<5390DC2A.1030502@oracle.com>	<539178E4.6060101@oracle.com>	<53919FBC.9060807@oracle.com>	<D9978349-8209-44B2-B0E9-6CD94FBF88A2@oracle.com>	<5391A3BE.3030607@oracle.com>	<5391C8EB.5010501@oracle.com>
	<5391CA38.60607@oracle.com> <5391FEF0.6080003@oracle.com>
	<53920039.7080801@oracle.com>
Message-ID: <53959A13.7020703@oracle.com>

Oops, I thought that com/sun/java/swing/plaf/windows/XPStyle.java is a 
Windows-specific file since it already imports classes from 
sun.awt.windows...

--
best regards,
Anthony

On 6/6/2014 9:54 PM, Phil Race wrote:
> I filed P1 bug https://bugs.openjdk.java.net/browse/JDK-8046239
>
> You really should at least build on other platforms and you can use JPRT
> for that ..
> Testing would be good too ..
>
> -phil.
>
> On 6/6/2014 10:48 AM, Phil Race wrote:
>> ahem, this is a "bad fix". It has broken all non-windows builds
>> because shared code
>> is now referencing WToolkit and ThemeReader. Please back out this fix
>> ASAP ..
>>
>> -phil.
>>
>> On 6/6/2014 7:03 AM, Anthony Petrov wrote:
>>> You're welcome.
>>>
>>> --
>>> best regards,
>>> Anthony
>>>
>>> On 6/6/2014 5:58 PM, Alexey Ivanov wrote:
>>>> Hi Anthony, Petr,
>>>>
>>>> Thank you for reviewing my fix.
>>>>
>>>> Regards,
>>>> Alexey.
>>>>
>>>>
>>>> On 06.06.2014 15:19, Anthony Petrov wrote:
>>>>> +1
>>>>>
>>>>> --
>>>>> best regards,
>>>>> Anthony
>>>>>
>>>>> On 6/6/2014 3:20 PM, Petr Pchelko wrote:
>>>>>> Hello, Alexey.
>>>>>>
>>>>>> The final version still looks good.
>>>>>>
>>>>>> With best regards. Petr.
>>>>>>
>>>>>> On 06 ???? 2014 ?., at 15:02, Alexey Ivanov
>>>>>> <alexey.ivanov at oracle.com> wrote:
>>>>>>
>>>>>>> Hi Anthony, Petr, AWT and Swing teams,
>>>>>>>
>>>>>>> I've addressed Anthony's and Petr's comments in the updated webrev:
>>>>>>> http://cr.openjdk.java.net/~aivanov/8039383/jdk9/webrev.04/
>>>>>>>
>>>>>>> Thank you,
>>>>>>> Alexey.
>>>>>>>
>>>>>>> On 06.06.2014 12:16, Alexey Ivanov wrote:
>>>>>>>> Hi Anthony,
>>>>>>>>
>>>>>>>> Thank you for your review.
>>>>>>>>
>>>>>>>> I've removed synchronized modifier from updateProperties() method
>>>>>>>> which protected access to wprops field. Now this field is accessed
>>>>>>>> from synchronized methods lazilyInitWProps() and getWProps();
>>>>>>>> setDesktopProperty also has proper synchronization - that was my
>>>>>>>> reasoning for removing synchronized.
>>>>>>>>
>>>>>>>> But you're right, it was not the right decision as the update loop
>>>>>>>> now could execute simultaneously which is undesirable. I'll put
>>>>>>>> synchronized modifier to updateProperties() method.
>>>>>>>>
>>>>>>>> Regards,
>>>>>>>> Alexey.
>>>>>>>>
>>>>>>>> On 06.06.2014 1:07, Anthony Petrov wrote:
>>>>>>>>> Hi Alexey,
>>>>>>>>>
>>>>>>>>> In WToolkit.java you're removing the synchronized modifier from
>>>>>>>>> the private updateProperties() method. And it looks like the
>>>>>>>>> method itself does allow for calling from multiple threads. So I'm
>>>>>>>>> concerned about the lack of synchronization in this method. Was
>>>>>>>>> the removal intentional? How is the method supposed to work now
>>>>>>>>> when called from multiple threads?
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> best regards,
>>>>>>>>> Anthony
>>>>>>>>>
>>>>>>>>> On 6/5/2014 12:16 PM, Petr Pchelko wrote:
>>>>>>>>>> Thank you for clarifications, I've been most interested in #2
>>>>>>>>>> obviously.
>>>>>>>>>>
>>>>>>>>>> The fix looks good to me.
>>>>>>>>>>
>>>>>>>>>> With best regards. Petr.
>>>>>>>>>>
>>>>>>>>>> On 05 ???? 2014 ?., at 11:57, Alexey Ivanov
>>>>>>>>>> <alexey.ivanov at oracle.com> wrote:
>>>>>>>>>>
>>>>>>>>>>> Hello Petr,
>>>>>>>>>>>
>>>>>>>>>>> Thank you for your comments.
>>>>>>>>>>>
>>>>>>>>>>> 1. Sure, I'll remove the comment before the change set is
>>>>>>>>>>> pushed.
>>>>>>>>>>> 2. No, I didn't try stub XPStyle object. First of all, UI
>>>>>>>>>>> delegates decide what painting method to use depending on
>>>>>>>>>>> whether XPStyle.getXP() returns null or not. If XPStyle.getXP()
>>>>>>>>>>> always returns non-null value, we'll have re-implement all UI
>>>>>>>>>>> delegates for Windows plaf, and I believe it would result in
>>>>>>>>>>> larger changeset. Additionally, some classes fallback to
>>>>>>>>>>> inherited behavior where XPStyle.getXP() is not available.
>>>>>>>>>>> Another reason is that UI delegates cache Skins: those objects
>>>>>>>>>>> shouldn't paint where theming is unavailable.
>>>>>>>>>>> 3. No, I haven't filed any bugs yet. I'll file all the issues
>>>>>>>>>>> I've found in the nearest future.
>>>>>>>>>>>
>>>>>>>>>>> Regards,
>>>>>>>>>>> Alexey.
>>>>>>>>>>>
>>>>>>>>>>> On 05.06.2014 11:08, Petr Pchelko wrote:
>>>>>>>>>>>> Hello, Alexey.
>>>>>>>>>>>>
>>>>>>>>>>>> A couple of comments:
>>>>>>>>>>>> 1. ThemeReader:64 - I suggest to remove that comment as it does
>>>>>>>>>>>> not add any value. The variable name is self explanatory.
>>>>>>>>>>>> 2. XPStyle - did you try providing a stub XPStyle object
>>>>>>>>>>>> instead of changing many of it's methods? Do I understand
>>>>>>>>>>>> correctly that this
>>>>>>>>>>>> is not possible because XPstyle is cached in many place is our
>>>>>>>>>>>> code?
>>>>>>>>>>>> 3. In offline discussion you've mentioned that you've found
>>>>>>>>>>>> another related issue. Did you have a chance to file a bug
>>>>>>>>>>>> about it?
>>>>>>>>>>>>
>>>>>>>>>>>> Thank you.
>>>>>>>>>>>> With best regards. Petr.
>>>>>>>>>>>>
>>>>>>>>>>>> On 05 ???? 2014 ?., at 10:35, Alexey Ivanov
>>>>>>>>>>>> <alexey.ivanov at oracle.com> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>> Hi AWT and Swing teams,
>>>>>>>>>>>>>
>>>>>>>>>>>>> Could you please review the updated fix:
>>>>>>>>>>>>> http://cr.openjdk.java.net/~aivanov/8039383/jdk9/webrev.03/
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> What has changed since version .02?
>>>>>>>>>>>>>
>>>>>>>>>>>>> During additional testing, I found another scenario where NPE
>>>>>>>>>>>>> was thrown. So the new version adds more checks to prevent
>>>>>>>>>>>>> access to XPStyle and ThemeReader where Windows visual styles
>>>>>>>>>>>>> become unavailable.
>>>>>>>>>>>>>
>>>>>>>>>>>>> As in previous version, getters in XPStyle class check for
>>>>>>>>>>>>> null values and return dummy defaults if ThemeReader returned
>>>>>>>>>>>>> null. Skin painters also check whether theming is still
>>>>>>>>>>>>> available before asking ThemeReader to paint.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Access to XPStyle.xp instance is blocked as soon as user
>>>>>>>>>>>>> switched themes. The object will be cleaned when the
>>>>>>>>>>>>> corresponding PropertyChangeEvent is handled by Swing.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Thank you,
>>>>>>>>>>>>> Alexey.
>>>>>>>>>>>>>
>>>>>>>>>>>>> On 06.05.2014 12:14, Alexey Ivanov wrote:
>>>>>>>>>>>>>> Hi AWT and Swing teams,
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Could you please review the updated fix:
>>>>>>>>>>>>>> http://cr.openjdk.java.net/~dmarkov/8039383/jdk9/webrev.02/
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> What has changed since version .01?
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> The issue was still reproducible with the .01 version of the
>>>>>>>>>>>>>> fix, however it was harder to reproduce.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> So in version .02 I added checks for null where possible. If
>>>>>>>>>>>>>> theme becomes unavailable, a dummy value will be used; this
>>>>>>>>>>>>>> way applications will be more stable. As soon as the theme
>>>>>>>>>>>>>> change events are handled, the entire UI will update
>>>>>>>>>>>>>> properly.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Thank you,
>>>>>>>>>>>>>> Alexey.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On 24.04.2014 16:23, Alexey Ivanov wrote:
>>>>>>>>>>>>>>> Hi Anthony, AWT and Swing teams,
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Here's the updated fix:
>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~dmarkov/8039383/jdk9/webrev.01/
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Description:
>>>>>>>>>>>>>>> In the new version of the fix, I use a new xpstyleEnabled
>>>>>>>>>>>>>>> field of AtomicBoolean in WToolkit to track the current
>>>>>>>>>>>>>>> value of "win.xpstyle.themeActive" desktop property. Its
>>>>>>>>>>>>>>> value is updated in windowsSettingChange() and in
>>>>>>>>>>>>>>> updateProperties().
>>>>>>>>>>>>>>> XPStyle.getXP() checks its cached value in themeActive and
>>>>>>>>>>>>>>> the current value in WToolkit; if the value changes, it
>>>>>>>>>>>>>>> schedules updateAllUIs and invalidates the current style
>>>>>>>>>>>>>>> right away, so that components would not access data from
>>>>>>>>>>>>>>> the theme that became unavailable.
>>>>>>>>>>>>>>> Two functions in ThemeReader also check this special field
>>>>>>>>>>>>>>> from WToolkit which prevents throwing InternalError when
>>>>>>>>>>>>>>> paint is called before theme change is fully handled.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Before updateAllUIs is invoked, it's possible that
>>>>>>>>>>>>>>> application will paint with some values cached from the
>>>>>>>>>>>>>>> previous theme. Usually it happens before "Theme change"
>>>>>>>>>>>>>>> dialog disappears from the screen, at least I noticed no UI
>>>>>>>>>>>>>>> glitches during normal theme change.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Regression test:
>>>>>>>>>>>>>>> No regression test is provided due to its complexity.
>>>>>>>>>>>>>>> Additionally, 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.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Thank you,
>>>>>>>>>>>>>>> Alexey.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> On 18.04.2014 18:52, Anthony Petrov wrote:
>>>>>>>>>>>>>>>> Hi Alexey,
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> No, unfortunately I don't have any suggestions right now.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> As for allowing executing user code on the toolkit thread,
>>>>>>>>>>>>>>>> we can't accept such a fix. Sorry about that.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>> best regards,
>>>>>>>>>>>>>>>> Anthony
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> On 4/18/2014 6:48 PM, Alexey Ivanov wrote:
>>>>>>>>>>>>>>>>> Hi Anthony,
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Thank you for your review.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Yes, user code can install a property change listener...
>>>>>>>>>>>>>>>>> It was my
>>>>>>>>>>>>>>>>> concern too, that's why I explicitly noted about this.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Do you have any suggestion how this situation can be
>>>>>>>>>>>>>>>>> handled?
>>>>>>>>>>>>>>>>> Is it a general rule that all desktop property change
>>>>>>>>>>>>>>>>> listeners must be
>>>>>>>>>>>>>>>>> called on EDT?
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>>>>>> Alexey.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> On 18.04.2014 16:02, Anthony Petrov wrote:
>>>>>>>>>>>>>>>>>> Hi Alexey,
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> With this change, property "win.xpstyle.themeActive"
>>>>>>>>>>>>>>>>>>> change is fired
>>>>>>>>>>>>>>>>>>> on the toolkit thread
>>>>>>>>>>>>>>>>>> Is it possible to install a change listener for this
>>>>>>>>>>>>>>>>>> property from
>>>>>>>>>>>>>>>>>> user code, and hence eventually allow executing some user
>>>>>>>>>>>>>>>>>> code on the
>>>>>>>>>>>>>>>>>> toolkit thread with your fix?
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>>> best regards,
>>>>>>>>>>>>>>>>>> Anthony
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> On 4/18/2014 12:09 PM, Alexey Ivanov wrote:
>>>>>>>>>>>>>>>>>>> Hello Swing and AWT teams,
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Could you please review the fix for jdk9:
>>>>>>>>>>>>>>>>>>>      bug:
>>>>>>>>>>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8039383
>>>>>>>>>>>>>>>>>>>      webrev:
>>>>>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~dmarkov/8039383/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 "cached" in XPStyle object. When
>>>>>>>>>>>>>>>>>>> the theme is
>>>>>>>>>>>>>>>>>>> switched to a classic one, HTHEME handle becomes
>>>>>>>>>>>>>>>>>>> unavailable and data
>>>>>>>>>>>>>>>>>>> cannot be accessed from the theme any more. The change
>>>>>>>>>>>>>>>>>>> in theme in
>>>>>>>>>>>>>>>>>>> posted to EDT via invokeLater. At the same time, the UI
>>>>>>>>>>>>>>>>>>> needs to repaint
>>>>>>>>>>>>>>>>>>> itself as soon as Windows changed the theme, and paint
>>>>>>>>>>>>>>>>>>> code is often
>>>>>>>>>>>>>>>>>>> called before the theme change is handled in Java. This
>>>>>>>>>>>>>>>>>>> leads to NPE and
>>>>>>>>>>>>>>>>>>> InternalError as the code tries to access the data that
>>>>>>>>>>>>>>>>>>> has become
>>>>>>>>>>>>>>>>>>> unavailable.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> The fix:
>>>>>>>>>>>>>>>>>>> Update "win.xpstyle.themeActive" desktop property and
>>>>>>>>>>>>>>>>>>> invalidate the
>>>>>>>>>>>>>>>>>>> cached XPStyle as soon as windowsSettingChange() is
>>>>>>>>>>>>>>>>>>> called from native
>>>>>>>>>>>>>>>>>>> code. Thus when Swing code needs to access theme data,
>>>>>>>>>>>>>>>>>>> it will see no
>>>>>>>>>>>>>>>>>>> theme is available and will fallback to classic
>>>>>>>>>>>>>>>>>>> painting.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Note: Before the fix, PropertyChangeEvents for desktop
>>>>>>>>>>>>>>>>>>> properties in
>>>>>>>>>>>>>>>>>>> Windows were fired on the Event Dispatch Thread. With
>>>>>>>>>>>>>>>>>>> this change,
>>>>>>>>>>>>>>>>>>> property "win.xpstyle.themeActive" change is fired on
>>>>>>>>>>>>>>>>>>> the toolkit
>>>>>>>>>>>>>>>>>>> thread; all other properties are changed on the EDT as
>>>>>>>>>>>>>>>>>>> before.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Regards,
>>>>>>>>>>>>>>>>>>> Alexey.
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>
>>
>

From alexey.ivanov at oracle.com  Mon Jun  9 13:17:03 2014
From: alexey.ivanov at oracle.com (Alexey Ivanov)
Date: Mon, 09 Jun 2014 17:17:03 +0400
Subject: <AWT Dev> <Swing Dev> [9] Review request for JDK-8039383: NPE
 when changing Windows Theme
In-Reply-To: <53920039.7080801@oracle.com>
References: <5350DDBC.30603@oracle.com>	<5351143C.8010100@oracle.com>	<53513B5B.4050104@oracle.com>	<53513C26.9060305@oracle.com>	<53590232.4080703@oracle.com>	<536899D1.1020501@oracle.com>	<53900FA7.8040508@oracle.com>	<0FE09EB0-B3A1-43F4-AE48-401DD55F5B09@oracle.com>	<539022E9.7070907@oracle.com>	<4240D39D-748C-483F-B447-1FAF6DFA25E4@oracle.com>	<5390DC2A.1030502@oracle.com>	<539178E4.6060101@oracle.com>	<53919FBC.9060807@oracle.com>	<D9978349-8209-44B2-B0E9-6CD94FBF88A2@oracle.com>	<5391A3BE.3030607@oracle.com>	<5391C8EB.5010501@oracle.com>
	<5391CA38.60607@oracle.com> <5391FEF0.6080003@oracle.com>
	<53920039.7080801@oracle.com>
Message-ID: <5395B3CF.6000106@oracle.com>

Hi Phil,

My bad, I didn't pay due attention to other platforms because I modified 
files specific to Windows and Windows LaF. Since Windows LaF is not 
available at other platforms, I was sure these classes are compiled only 
for Windows. My assumption proved to be wrong. In future, I will always 
build all the platforms even if the changes are platform-specific.


Anthony, Petr,

Could you please review my fix for build failure in another thread?

I am really sorry about build failure. I won't make it happen again.


Thanks,
Alexey.

On 06.06.2014 21:54, Phil Race wrote:
> I filed P1 bug https://bugs.openjdk.java.net/browse/JDK-8046239
>
> You really should at least build on other platforms and you can use 
> JPRT for that ..
> Testing would be good too ..
>
> -phil.
>
> On 6/6/2014 10:48 AM, Phil Race wrote:
>> ahem, this is a "bad fix". It has broken all non-windows builds 
>> because shared code
>> is now referencing WToolkit and ThemeReader. Please back out this fix 
>> ASAP ..
>>
>> -phil.
>>
>> On 6/6/2014 7:03 AM, Anthony Petrov wrote:
>>> You're welcome.
>>>
>>> -- 
>>> best regards,
>>> Anthony
>>>
>>> On 6/6/2014 5:58 PM, Alexey Ivanov wrote:
>>>> Hi Anthony, Petr,
>>>>
>>>> Thank you for reviewing my fix.
>>>>
>>>> Regards,
>>>> Alexey.
>>>>
>>>>
>>>> On 06.06.2014 15:19, Anthony Petrov wrote:
>>>>> +1
>>>>>
>>>>> -- 
>>>>> best regards,
>>>>> Anthony
>>>>>
>>>>> On 6/6/2014 3:20 PM, Petr Pchelko wrote:
>>>>>> Hello, Alexey.
>>>>>>
>>>>>> The final version still looks good.
>>>>>>
>>>>>> With best regards. Petr.
>>>>>>
>>>>>> On 06 ???? 2014 ?., at 15:02, Alexey Ivanov
>>>>>> <alexey.ivanov at oracle.com> wrote:
>>>>>>
>>>>>>> Hi Anthony, Petr, AWT and Swing teams,
>>>>>>>
>>>>>>> I've addressed Anthony's and Petr's comments in the updated webrev:
>>>>>>> http://cr.openjdk.java.net/~aivanov/8039383/jdk9/webrev.04/
>>>>>>>
>>>>>>> Thank you,
>>>>>>> Alexey.
>>>>>>>
>>>>>>> On 06.06.2014 12:16, Alexey Ivanov wrote:
>>>>>>>> Hi Anthony,
>>>>>>>>
>>>>>>>> Thank you for your review.
>>>>>>>>
>>>>>>>> I've removed synchronized modifier from updateProperties() method
>>>>>>>> which protected access to wprops field. Now this field is accessed
>>>>>>>> from synchronized methods lazilyInitWProps() and getWProps();
>>>>>>>> setDesktopProperty also has proper synchronization - that was my
>>>>>>>> reasoning for removing synchronized.
>>>>>>>>
>>>>>>>> But you're right, it was not the right decision as the update loop
>>>>>>>> now could execute simultaneously which is undesirable. I'll put
>>>>>>>> synchronized modifier to updateProperties() method.
>>>>>>>>
>>>>>>>> Regards,
>>>>>>>> Alexey.
>>>>>>>>
>>>>>>>> On 06.06.2014 1:07, Anthony Petrov wrote:
>>>>>>>>> Hi Alexey,
>>>>>>>>>
>>>>>>>>> In WToolkit.java you're removing the synchronized modifier from
>>>>>>>>> the private updateProperties() method. And it looks like the
>>>>>>>>> method itself does allow for calling from multiple threads. So 
>>>>>>>>> I'm
>>>>>>>>> concerned about the lack of synchronization in this method. Was
>>>>>>>>> the removal intentional? How is the method supposed to work now
>>>>>>>>> when called from multiple threads?
>>>>>>>>>
>>>>>>>>> -- 
>>>>>>>>> best regards,
>>>>>>>>> Anthony
>>>>>>>>>
>>>>>>>>> On 6/5/2014 12:16 PM, Petr Pchelko wrote:
>>>>>>>>>> Thank you for clarifications, I've been most interested in #2
>>>>>>>>>> obviously.
>>>>>>>>>>
>>>>>>>>>> The fix looks good to me.
>>>>>>>>>>
>>>>>>>>>> With best regards. Petr.
>>>>>>>>>>
>>>>>>>>>> On 05 ???? 2014 ?., at 11:57, Alexey Ivanov
>>>>>>>>>> <alexey.ivanov at oracle.com> wrote:
>>>>>>>>>>
>>>>>>>>>>> Hello Petr,
>>>>>>>>>>>
>>>>>>>>>>> Thank you for your comments.
>>>>>>>>>>>
>>>>>>>>>>> 1. Sure, I'll remove the comment before the change set is 
>>>>>>>>>>> pushed.
>>>>>>>>>>> 2. No, I didn't try stub XPStyle object. First of all, UI
>>>>>>>>>>> delegates decide what painting method to use depending on
>>>>>>>>>>> whether XPStyle.getXP() returns null or not. If XPStyle.getXP()
>>>>>>>>>>> always returns non-null value, we'll have re-implement all UI
>>>>>>>>>>> delegates for Windows plaf, and I believe it would result in
>>>>>>>>>>> larger changeset. Additionally, some classes fallback to
>>>>>>>>>>> inherited behavior where XPStyle.getXP() is not available.
>>>>>>>>>>> Another reason is that UI delegates cache Skins: those objects
>>>>>>>>>>> shouldn't paint where theming is unavailable.
>>>>>>>>>>> 3. No, I haven't filed any bugs yet. I'll file all the issues
>>>>>>>>>>> I've found in the nearest future.
>>>>>>>>>>>
>>>>>>>>>>> Regards,
>>>>>>>>>>> Alexey.
>>>>>>>>>>>
>>>>>>>>>>> On 05.06.2014 11:08, Petr Pchelko wrote:
>>>>>>>>>>>> Hello, Alexey.
>>>>>>>>>>>>
>>>>>>>>>>>> A couple of comments:
>>>>>>>>>>>> 1. ThemeReader:64 - I suggest to remove that comment as it 
>>>>>>>>>>>> does
>>>>>>>>>>>> not add any value. The variable name is self explanatory.
>>>>>>>>>>>> 2. XPStyle - did you try providing a stub XPStyle object
>>>>>>>>>>>> instead of changing many of it's methods? Do I understand
>>>>>>>>>>>> correctly that this
>>>>>>>>>>>> is not possible because XPstyle is cached in many place is our
>>>>>>>>>>>> code?
>>>>>>>>>>>> 3. In offline discussion you've mentioned that you've found
>>>>>>>>>>>> another related issue. Did you have a chance to file a bug
>>>>>>>>>>>> about it?
>>>>>>>>>>>>
>>>>>>>>>>>> Thank you.
>>>>>>>>>>>> With best regards. Petr.
>>>>>>>>>>>>
>>>>>>>>>>>> On 05 ???? 2014 ?., at 10:35, Alexey Ivanov
>>>>>>>>>>>> <alexey.ivanov at oracle.com> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>> Hi AWT and Swing teams,
>>>>>>>>>>>>>
>>>>>>>>>>>>> Could you please review the updated fix:
>>>>>>>>>>>>> http://cr.openjdk.java.net/~aivanov/8039383/jdk9/webrev.03/
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> What has changed since version .02?
>>>>>>>>>>>>>
>>>>>>>>>>>>> During additional testing, I found another scenario where NPE
>>>>>>>>>>>>> was thrown. So the new version adds more checks to prevent
>>>>>>>>>>>>> access to XPStyle and ThemeReader where Windows visual styles
>>>>>>>>>>>>> become unavailable.
>>>>>>>>>>>>>
>>>>>>>>>>>>> As in previous version, getters in XPStyle class check for
>>>>>>>>>>>>> null values and return dummy defaults if ThemeReader returned
>>>>>>>>>>>>> null. Skin painters also check whether theming is still
>>>>>>>>>>>>> available before asking ThemeReader to paint.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Access to XPStyle.xp instance is blocked as soon as user
>>>>>>>>>>>>> switched themes. The object will be cleaned when the
>>>>>>>>>>>>> corresponding PropertyChangeEvent is handled by Swing.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Thank you,
>>>>>>>>>>>>> Alexey.
>>>>>>>>>>>>>
>>>>>>>>>>>>> On 06.05.2014 12:14, Alexey Ivanov wrote:
>>>>>>>>>>>>>> Hi AWT and Swing teams,
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Could you please review the updated fix:
>>>>>>>>>>>>>> http://cr.openjdk.java.net/~dmarkov/8039383/jdk9/webrev.02/
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> What has changed since version .01?
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> The issue was still reproducible with the .01 version of the
>>>>>>>>>>>>>> fix, however it was harder to reproduce.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> So in version .02 I added checks for null where possible. If
>>>>>>>>>>>>>> theme becomes unavailable, a dummy value will be used; this
>>>>>>>>>>>>>> way applications will be more stable. As soon as the theme
>>>>>>>>>>>>>> change events are handled, the entire UI will update 
>>>>>>>>>>>>>> properly.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Thank you,
>>>>>>>>>>>>>> Alexey.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On 24.04.2014 16:23, Alexey Ivanov wrote:
>>>>>>>>>>>>>>> Hi Anthony, AWT and Swing teams,
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Here's the updated fix:
>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~dmarkov/8039383/jdk9/webrev.01/
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Description:
>>>>>>>>>>>>>>> In the new version of the fix, I use a new xpstyleEnabled
>>>>>>>>>>>>>>> field of AtomicBoolean in WToolkit to track the current
>>>>>>>>>>>>>>> value of "win.xpstyle.themeActive" desktop property. Its
>>>>>>>>>>>>>>> value is updated in windowsSettingChange() and in
>>>>>>>>>>>>>>> updateProperties().
>>>>>>>>>>>>>>> XPStyle.getXP() checks its cached value in themeActive and
>>>>>>>>>>>>>>> the current value in WToolkit; if the value changes, it
>>>>>>>>>>>>>>> schedules updateAllUIs and invalidates the current style
>>>>>>>>>>>>>>> right away, so that components would not access data from
>>>>>>>>>>>>>>> the theme that became unavailable.
>>>>>>>>>>>>>>> Two functions in ThemeReader also check this special field
>>>>>>>>>>>>>>> from WToolkit which prevents throwing InternalError when
>>>>>>>>>>>>>>> paint is called before theme change is fully handled.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Before updateAllUIs is invoked, it's possible that
>>>>>>>>>>>>>>> application will paint with some values cached from the
>>>>>>>>>>>>>>> previous theme. Usually it happens before "Theme change"
>>>>>>>>>>>>>>> dialog disappears from the screen, at least I noticed no UI
>>>>>>>>>>>>>>> glitches during normal theme change.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Regression test:
>>>>>>>>>>>>>>> No regression test is provided due to its complexity.
>>>>>>>>>>>>>>> Additionally, 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.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Thank you,
>>>>>>>>>>>>>>> Alexey.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> On 18.04.2014 18:52, Anthony Petrov wrote:
>>>>>>>>>>>>>>>> Hi Alexey,
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> No, unfortunately I don't have any suggestions right now.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> As for allowing executing user code on the toolkit thread,
>>>>>>>>>>>>>>>> we can't accept such a fix. Sorry about that.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> -- 
>>>>>>>>>>>>>>>> best regards,
>>>>>>>>>>>>>>>> Anthony
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> On 4/18/2014 6:48 PM, Alexey Ivanov wrote:
>>>>>>>>>>>>>>>>> Hi Anthony,
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Thank you for your review.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Yes, user code can install a property change listener...
>>>>>>>>>>>>>>>>> It was my
>>>>>>>>>>>>>>>>> concern too, that's why I explicitly noted about this.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Do you have any suggestion how this situation can be 
>>>>>>>>>>>>>>>>> handled?
>>>>>>>>>>>>>>>>> Is it a general rule that all desktop property change
>>>>>>>>>>>>>>>>> listeners must be
>>>>>>>>>>>>>>>>> called on EDT?
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>>>>>> Alexey.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> On 18.04.2014 16:02, Anthony Petrov wrote:
>>>>>>>>>>>>>>>>>> Hi Alexey,
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> With this change, property "win.xpstyle.themeActive"
>>>>>>>>>>>>>>>>>>> change is fired
>>>>>>>>>>>>>>>>>>> on the toolkit thread
>>>>>>>>>>>>>>>>>> Is it possible to install a change listener for this
>>>>>>>>>>>>>>>>>> property from
>>>>>>>>>>>>>>>>>> user code, and hence eventually allow executing some 
>>>>>>>>>>>>>>>>>> user
>>>>>>>>>>>>>>>>>> code on the
>>>>>>>>>>>>>>>>>> toolkit thread with your fix?
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> -- 
>>>>>>>>>>>>>>>>>> best regards,
>>>>>>>>>>>>>>>>>> Anthony
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> On 4/18/2014 12:09 PM, Alexey Ivanov wrote:
>>>>>>>>>>>>>>>>>>> Hello Swing and AWT teams,
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Could you please review the fix for jdk9:
>>>>>>>>>>>>>>>>>>>      bug: 
>>>>>>>>>>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8039383
>>>>>>>>>>>>>>>>>>>      webrev:
>>>>>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~dmarkov/8039383/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 "cached" in XPStyle object. When
>>>>>>>>>>>>>>>>>>> the theme is
>>>>>>>>>>>>>>>>>>> switched to a classic one, HTHEME handle becomes
>>>>>>>>>>>>>>>>>>> unavailable and data
>>>>>>>>>>>>>>>>>>> cannot be accessed from the theme any more. The change
>>>>>>>>>>>>>>>>>>> in theme in
>>>>>>>>>>>>>>>>>>> posted to EDT via invokeLater. At the same time, the UI
>>>>>>>>>>>>>>>>>>> needs to repaint
>>>>>>>>>>>>>>>>>>> itself as soon as Windows changed the theme, and paint
>>>>>>>>>>>>>>>>>>> code is often
>>>>>>>>>>>>>>>>>>> called before the theme change is handled in Java. This
>>>>>>>>>>>>>>>>>>> leads to NPE and
>>>>>>>>>>>>>>>>>>> InternalError as the code tries to access the data that
>>>>>>>>>>>>>>>>>>> has become
>>>>>>>>>>>>>>>>>>> unavailable.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> The fix:
>>>>>>>>>>>>>>>>>>> Update "win.xpstyle.themeActive" desktop property and
>>>>>>>>>>>>>>>>>>> invalidate the
>>>>>>>>>>>>>>>>>>> cached XPStyle as soon as windowsSettingChange() is
>>>>>>>>>>>>>>>>>>> called from native
>>>>>>>>>>>>>>>>>>> code. Thus when Swing code needs to access theme data,
>>>>>>>>>>>>>>>>>>> it will see no
>>>>>>>>>>>>>>>>>>> theme is available and will fallback to classic 
>>>>>>>>>>>>>>>>>>> painting.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Note: Before the fix, PropertyChangeEvents for desktop
>>>>>>>>>>>>>>>>>>> properties in
>>>>>>>>>>>>>>>>>>> Windows were fired on the Event Dispatch Thread. With
>>>>>>>>>>>>>>>>>>> this change,
>>>>>>>>>>>>>>>>>>> property "win.xpstyle.themeActive" change is fired on
>>>>>>>>>>>>>>>>>>> the toolkit
>>>>>>>>>>>>>>>>>>> thread; all other properties are changed on the EDT as
>>>>>>>>>>>>>>>>>>> before.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Regards,
>>>>>>>>>>>>>>>>>>> Alexey.
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>
>>
>


From alexey.ivanov at oracle.com  Mon Jun  9 13:19:40 2014
From: alexey.ivanov at oracle.com (Alexey Ivanov)
Date: Mon, 09 Jun 2014 17:19:40 +0400
Subject: <AWT Dev> <Swing Dev> [9] Review request for JDK-8046239: Build
 failure in 9-client on all non-Windows platforms
Message-ID: <5395B46C.5040904@oracle.com>

Hi Petr, Anthony, AWT and Swing teams,

Could you please review the following webrev for JDK-8046239 to fix 
build failure:
http://cr.openjdk.java.net/~aivanov/8046239/jdk9/webrev.01/

The build failure is caused by my fix to JDK-8039383: NPE when changing 
Windows Theme. I didn't test build thoroughly on other platforms. Sorry 
about that.

There's a stub version of ThemeReader.java in 
src/solaris/classes/sun/awt/windows/ which is used for non-Windows 
builds. I added isXPStyleEnabled() function which always returns false.

Also I removed the dependency on WToolkit from XPStyle: it uses 
"win.xpstyle.themeActive" to access the desktop property as it used to do.

WindowsLookAndFeel can be instantiated on all the platforms but it can 
be used only on Windows because 
WindowsLookAndFeel.isSupportedLookAndFeel() returns false on any other 
platform but Windows.


I am really sorry about build failure. I won't make it happen again.

Thanks,
Alexey.

From anthony.petrov at oracle.com  Mon Jun  9 13:43:01 2014
From: anthony.petrov at oracle.com (Anthony Petrov)
Date: Mon, 09 Jun 2014 17:43:01 +0400
Subject: <AWT Dev> <Swing Dev> [9] Review request for JDK-8046239: Build
 failure in 9-client on all non-Windows platforms
In-Reply-To: <5395B46C.5040904@oracle.com>
References: <5395B46C.5040904@oracle.com>
Message-ID: <5395B9E5.4040106@oracle.com>

Hi Alexey,

The fix looks fine to me.

--
best regards,
Anthony

On 6/9/2014 5:19 PM, Alexey Ivanov wrote:
> Hi Petr, Anthony, AWT and Swing teams,
>
> Could you please review the following webrev for JDK-8046239 to fix
> build failure:
> http://cr.openjdk.java.net/~aivanov/8046239/jdk9/webrev.01/
>
> The build failure is caused by my fix to JDK-8039383: NPE when changing
> Windows Theme. I didn't test build thoroughly on other platforms. Sorry
> about that.
>
> There's a stub version of ThemeReader.java in
> src/solaris/classes/sun/awt/windows/ which is used for non-Windows
> builds. I added isXPStyleEnabled() function which always returns false.
>
> Also I removed the dependency on WToolkit from XPStyle: it uses
> "win.xpstyle.themeActive" to access the desktop property as it used to do.
>
> WindowsLookAndFeel can be instantiated on all the platforms but it can
> be used only on Windows because
> WindowsLookAndFeel.isSupportedLookAndFeel() returns false on any other
> platform but Windows.
>
>
> I am really sorry about build failure. I won't make it happen again.
>
> Thanks,
> Alexey.

From Sergey.Bylokhov at oracle.com  Mon Jun  9 13:51:38 2014
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Mon, 09 Jun 2014 17:51:38 +0400
Subject: <AWT Dev> <Swing Dev> [9] Review request for JDK-8046239: Build
 failure in 9-client on all non-Windows platforms
In-Reply-To: <5395B46C.5040904@oracle.com>
References: <5395B46C.5040904@oracle.com>
Message-ID: <5395BBEA.6050401@oracle.com>

Hi, Alexey.
The fix looks good. I assume all jprt builds were passed.

On 6/9/14 5:19 PM, Alexey Ivanov wrote:
> Hi Petr, Anthony, AWT and Swing teams,
>
> Could you please review the following webrev for JDK-8046239 to fix 
> build failure:
> http://cr.openjdk.java.net/~aivanov/8046239/jdk9/webrev.01/
>
> The build failure is caused by my fix to JDK-8039383: NPE when 
> changing Windows Theme. I didn't test build thoroughly on other 
> platforms. Sorry about that.
>
> There's a stub version of ThemeReader.java in 
> src/solaris/classes/sun/awt/windows/ which is used for non-Windows 
> builds. I added isXPStyleEnabled() function which always returns false.
>
> Also I removed the dependency on WToolkit from XPStyle: it uses 
> "win.xpstyle.themeActive" to access the desktop property as it used to 
> do.
>
> WindowsLookAndFeel can be instantiated on all the platforms but it can 
> be used only on Windows because 
> WindowsLookAndFeel.isSupportedLookAndFeel() returns false on any other 
> platform but Windows.
>
>
> I am really sorry about build failure. I won't make it happen again.
>
> Thanks,
> Alexey.


-- 
Best regards, Sergey.


From alexey.ivanov at oracle.com  Mon Jun  9 14:01:49 2014
From: alexey.ivanov at oracle.com (Alexey Ivanov)
Date: Mon, 09 Jun 2014 18:01:49 +0400
Subject: <AWT Dev> <Swing Dev> [9] Review request for JDK-8046239: Build
 failure in 9-client on all non-Windows platforms
In-Reply-To: <5395BBEA.6050401@oracle.com>
References: <5395B46C.5040904@oracle.com> <5395BBEA.6050401@oracle.com>
Message-ID: <5395BE4D.8060804@oracle.com>

Hi Sergey,

Thank you for reviewing the fix.
Yes, of course all the jprt builds are successful.

Regards,
Alexey.

On 09.06.2014 17:51, Sergey Bylokhov wrote:
> Hi, Alexey.
> The fix looks good. I assume all jprt builds were passed.
>
> On 6/9/14 5:19 PM, Alexey Ivanov wrote:
>> Hi Petr, Anthony, AWT and Swing teams,
>>
>> Could you please review the following webrev for JDK-8046239 to fix 
>> build failure:
>> http://cr.openjdk.java.net/~aivanov/8046239/jdk9/webrev.01/
>>
>> The build failure is caused by my fix to JDK-8039383: NPE when 
>> changing Windows Theme. I didn't test build thoroughly on other 
>> platforms. Sorry about that.
>>
>> There's a stub version of ThemeReader.java in 
>> src/solaris/classes/sun/awt/windows/ which is used for non-Windows 
>> builds. I added isXPStyleEnabled() function which always returns false.
>>
>> Also I removed the dependency on WToolkit from XPStyle: it uses 
>> "win.xpstyle.themeActive" to access the desktop property as it used 
>> to do.
>>
>> WindowsLookAndFeel can be instantiated on all the platforms but it 
>> can be used only on Windows because 
>> WindowsLookAndFeel.isSupportedLookAndFeel() returns false on any 
>> other platform but Windows.
>>
>>
>> I am really sorry about build failure. I won't make it happen again.
>>
>> Thanks,
>> Alexey.
>
>


From anthony.petrov at oracle.com  Mon Jun  9 14:07:09 2014
From: anthony.petrov at oracle.com (Anthony Petrov)
Date: Mon, 09 Jun 2014 18:07:09 +0400
Subject: <AWT Dev> [9] Review request: 8040007 GtkFileDialog strips user
 inputted filepath
In-Reply-To: <5391E5A0.4020106@oracle.com>
References: <5391E5A0.4020106@oracle.com>
Message-ID: <5395BF8D.5040203@oracle.com>

Hi Alexander,

src/solaris/native/sun/awt/sun_awt_X11_GtkFileDialogPeer.c
>  176         free(prevDir);
>  177         prevDir = strdup(dir);

It's unnecessary to re-duplicate the prevDir on each loop iteration 
here. I suggest to initialize it once instead. The less pointer 
operations, the less room for bugs.


>  229         (*env)->ExceptionClear(env);
>  230         JNU_ThrowInternalError(env, "Could not instantiate current folder");

This error message sounds misleading because the code above doesn't 
instantiate a "folder", it tries to instantiate a string. Also, if 
exceptions did occur, I believe it's fine to report them as they are. 
Otherwise, if the pointer is NULL, then this looks more like an OOM than 
an internal error to me.


>  278         //This is a hack for use with "Recent Folders" in gtk where each
>  279         //file could have its own directory.

I assume you've tested this case, and it still works fine, right?

--
best regards,
Anthony

On 6/6/2014 8:00 PM, Alexander Zvegintsev wrote:
> Hello,
>
> please review the fix
> http://cr.openjdk.java.net/~azvegint/jdk/9/8040007/00/
> for the bug
> https://bugs.openjdk.java.net/browse/JDK-8040007
>
> With this fix we don't use current folder from native GtkFileChooser
> anymore, now we build it by ourselves.
>
> [1]
> https://developer.gnome.org/gtk2/stable/GtkFileChooser.html#gtk-file-chooser-get-filenames
>
> [2]
> https://developer.gnome.org/glib/stable/glib-Miscellaneous-Utility-Functions.html#g-path-get-dirname
>
>

From alexander.zvegintsev at oracle.com  Mon Jun  9 15:07:07 2014
From: alexander.zvegintsev at oracle.com (Alexander Zvegintsev)
Date: Mon, 09 Jun 2014 19:07:07 +0400
Subject: <AWT Dev> [9] Review request: 8040007 GtkFileDialog strips user
 inputted filepath
In-Reply-To: <5395BF8D.5040203@oracle.com>
References: <5391E5A0.4020106@oracle.com> <5395BF8D.5040203@oracle.com>
Message-ID: <5395CD9B.9000508@oracle.com>

Hi Anthony,

thanks for the review, please see the updated webrev:
http://cr.openjdk.java.net/~azvegint/jdk/9/8040007/01/

> I assume you've tested this case, and it still works fine, right? 
Sure, it works fine. That is why gtk_file_chooser_get_current_folder() 
is not used and
isFromSameDirectory() was introduced.


--
Thanks,
Alexander.

On 06/09/2014 06:07 PM, Anthony Petrov wrote:
> Hi Alexander,
>
> src/solaris/native/sun/awt/sun_awt_X11_GtkFileDialogPeer.c
>>  176         free(prevDir);
>>  177         prevDir = strdup(dir);
>
> It's unnecessary to re-duplicate the prevDir on each loop iteration 
> here. I suggest to initialize it once instead. The less pointer 
> operations, the less room for bugs.
>
>
>>  229 (*env)->ExceptionClear(env);
>>  230         JNU_ThrowInternalError(env, "Could not instantiate 
>> current folder");
>
> This error message sounds misleading because the code above doesn't 
> instantiate a "folder", it tries to instantiate a string. Also, if 
> exceptions did occur, I believe it's fine to report them as they are. 
> Otherwise, if the pointer is NULL, then this looks more like an OOM 
> than an internal error to me.
>
>
>>  278         //This is a hack for use with "Recent Folders" in gtk 
>> where each
>>  279         //file could have its own directory.
>
> I assume you've tested this case, and it still works fine, right?
>
> -- 
> best regards,
> Anthony
>
> On 6/6/2014 8:00 PM, Alexander Zvegintsev wrote:
>> Hello,
>>
>> please review the fix
>> http://cr.openjdk.java.net/~azvegint/jdk/9/8040007/00/
>> for the bug
>> https://bugs.openjdk.java.net/browse/JDK-8040007
>>
>> With this fix we don't use current folder from native GtkFileChooser
>> anymore, now we build it by ourselves.
>>
>> [1]
>> https://developer.gnome.org/gtk2/stable/GtkFileChooser.html#gtk-file-chooser-get-filenames 
>>
>>
>> [2]
>> https://developer.gnome.org/glib/stable/glib-Miscellaneous-Utility-Functions.html#g-path-get-dirname 
>>
>>
>>


From anthony.petrov at oracle.com  Mon Jun  9 16:58:46 2014
From: anthony.petrov at oracle.com (Anthony Petrov)
Date: Mon, 09 Jun 2014 20:58:46 +0400
Subject: <AWT Dev> [9] Review request: 8040007 GtkFileDialog strips user
 inputted filepath
In-Reply-To: <5395CD9B.9000508@oracle.com>
References: <5391E5A0.4020106@oracle.com> <5395BF8D.5040203@oracle.com>
	<5395CD9B.9000508@oracle.com>
Message-ID: <5395E7C6.9050202@oracle.com>

Hi Alexander,

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

Note that myself, I wouldn't change the existing error handling code 
(e.g. old LN 224-225 and 231-232 in sun_awt_X11_GtkFileDialogPeer.c), 
but I'm still OK with that. Leaving this up to you and other reviewers.

--
best regards,
Anthony

On 6/9/2014 7:07 PM, Alexander Zvegintsev wrote:
> Hi Anthony,
>
> thanks for the review, please see the updated webrev:
> http://cr.openjdk.java.net/~azvegint/jdk/9/8040007/01/
>
>> I assume you've tested this case, and it still works fine, right?
> Sure, it works fine. That is why gtk_file_chooser_get_current_folder()
> is not used and
> isFromSameDirectory() was introduced.
>
>
> --
> Thanks,
> Alexander.
>
> On 06/09/2014 06:07 PM, Anthony Petrov wrote:
>> Hi Alexander,
>>
>> src/solaris/native/sun/awt/sun_awt_X11_GtkFileDialogPeer.c
>>>  176         free(prevDir);
>>>  177         prevDir = strdup(dir);
>>
>> It's unnecessary to re-duplicate the prevDir on each loop iteration
>> here. I suggest to initialize it once instead. The less pointer
>> operations, the less room for bugs.
>>
>>
>>>  229 (*env)->ExceptionClear(env);
>>>  230         JNU_ThrowInternalError(env, "Could not instantiate
>>> current folder");
>>
>> This error message sounds misleading because the code above doesn't
>> instantiate a "folder", it tries to instantiate a string. Also, if
>> exceptions did occur, I believe it's fine to report them as they are.
>> Otherwise, if the pointer is NULL, then this looks more like an OOM
>> than an internal error to me.
>>
>>
>>>  278         //This is a hack for use with "Recent Folders" in gtk
>>> where each
>>>  279         //file could have its own directory.
>>
>> I assume you've tested this case, and it still works fine, right?
>>
>> --
>> best regards,
>> Anthony
>>
>> On 6/6/2014 8:00 PM, Alexander Zvegintsev wrote:
>>> Hello,
>>>
>>> please review the fix
>>> http://cr.openjdk.java.net/~azvegint/jdk/9/8040007/00/
>>> for the bug
>>> https://bugs.openjdk.java.net/browse/JDK-8040007
>>>
>>> With this fix we don't use current folder from native GtkFileChooser
>>> anymore, now we build it by ourselves.
>>>
>>> [1]
>>> https://developer.gnome.org/gtk2/stable/GtkFileChooser.html#gtk-file-chooser-get-filenames
>>>
>>>
>>> [2]
>>> https://developer.gnome.org/glib/stable/glib-Miscellaneous-Utility-Functions.html#g-path-get-dirname
>>>
>>>
>>>
>

From philip.race at oracle.com  Mon Jun  9 21:07:26 2014
From: philip.race at oracle.com (Phil Race)
Date: Mon, 09 Jun 2014 14:07:26 -0700
Subject: <AWT Dev> [OpenJDK 2D-Dev] [9] Review request for 8029339
 Custom MultiResolution image support on HiDPI displays
In-Reply-To: <538F2D56.80609@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>
Message-ID: <5396220E.9030708@oracle.com>

Why the split ?
If you look only at the first part. If you can do that then why is the 
2nd part needed ?

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

I worry about the memory cost of all of this. Can the the implementation 
be "lazy"?
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 ..

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() ? Is it us (the 
implementation) because we
don't trust the app to make the right selection based on the 
parameterised call
getResolutionVariant() ?

Which approach do we use to pick the image ? If its the former, the app 
controls it,
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 ? Why are we, the caller, supposed
to say what that size to the class that has that image.

So I'd really like to see the example of that method in 
CustomMultiResolutionImage
filled out so we can see what is imagined here ..

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 ?

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.

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

And none of this seems to help anyone who calls new BufferedImage(w, h, 
type) ..

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 ..
In any case, without a solid demonstrated need I would not add the API.


-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 philip.race at oracle.com  Mon Jun  9 21:38:57 2014
From: philip.race at oracle.com (Phil Race)
Date: Mon, 09 Jun 2014 14:38:57 -0700
Subject: <AWT Dev> <Swing Dev> [9] Review request for JDK-8039383: NPE
 when changing Windows Theme
In-Reply-To: <5395B3CF.6000106@oracle.com>
References: <5350DDBC.30603@oracle.com>	<5351143C.8010100@oracle.com>	<53513B5B.4050104@oracle.com>	<53513C26.9060305@oracle.com>	<53590232.4080703@oracle.com>	<536899D1.1020501@oracle.com>	<53900FA7.8040508@oracle.com>	<0FE09EB0-B3A1-43F4-AE48-401DD55F5B09@oracle.com>	<539022E9.7070907@oracle.com>	<4240D39D-748C-483F-B447-1FAF6DFA25E4@oracle.com>	<5390DC2A.1030502@oracle.com>	<539178E4.6060101@oracle.com>	<53919FBC.9060807@oracle.com>	<D9978349-8209-44B2-B0E9-6CD94FBF88A2@oracle.com>	<5391A3BE.3030607@oracle.com>	<5391C8EB.5010501@oracle.com>
	<5391CA38.60607@oracle.com> <5391FEF0.6080003@oracle.com>
	<53920039.7080801@oracle.com> <5395B3CF.6000106@oracle.com>
Message-ID: <53962971.6060703@oracle.com>

Hi,
So the repo now builds but when I run SwingSet2 on Windows and select 
the Win L&F and
try to bring up JFileChooser the whole app hangs. Looks like the same 
deadlock/hang that we
saw on 7u60 (I think). I assumed this was to be the fix that addressed 
the NPE *and*
did not hang the app.

"AWT-EventQueue-0" #12 prio=6 os_prio=0 tid=0x0d5d8c00 nid=0x208c 
runnable [0x0d
c1d000]
    java.lang.Thread.State: RUNNABLE
         at sun.awt.windows.ThemeReader.setWindowTheme(Native Method)
         at sun.awt.windows.ThemeReader.getThemeImpl(ThemeReader.java:93)
         at sun.awt.windows.ThemeReader.getTheme(ThemeReader.java:113)
         at sun.awt.windows.ThemeReader.getEnum(ThemeReader.java:189)
         at 
com.sun.java.swing.plaf.windows.XPStyle.getTypeEnumName(XPStyle.java:
149)
         at 
com.sun.java.swing.plaf.windows.XPStyle.getBorder(XPStyle.java:275)
         - locked <0x1021fa90> (a com.sun.java.swing.plaf.windows.XPStyle)
         at 
com.sun.java.swing.plaf.windows.WindowsToolBarUI.getRolloverBorder(Wi
ndowsToolBarUI.java:94)
         at 
javax.swing.plaf.basic.BasicToolBarUI.setBorderToRollover(BasicToolBa
rUI.java:692)
         at 
javax.swing.plaf.basic.BasicToolBarUI$Handler.componentAdded(BasicToo
lBarUI.java:1131)
         at java.awt.Container.processContainerEvent(Container.java:2270)
         at java.awt.Container.processEvent(Container.java:2241)
         at java.awt.Component.dispatchEventImpl(Component.java:4892)
         at java.awt.Container.dispatchEventImpl(Container.java:2302)
         at java.awt.Component.dispatchEvent(Component.java:4714)
         at java.awt.Container.addImpl(Container.java:1146)
         - locked <0x158a6570> (a java.awt.Component$AWTTreeLock)
         at javax.swing.JToolBar.addImpl(JToolBar.java:581)
         at java.awt.Container.add(Container.java:425)
         at sun.swing.WindowsPlacesBar.<init>(WindowsPlacesBar.java:136)
         at 
com.sun.java.swing.plaf.windows.WindowsFileChooserUI.updateUseShellFo
lder(WindowsFileChooserUI.java:508)
         at 
com.sun.java.swing.plaf.windows.WindowsFileChooserUI.installComponent
s(WindowsFileChooserUI.java:213)
         at 
javax.swing.plaf.basic.BasicFileChooserUI.installUI(BasicFileChooserU
I.java:173)
         at 
com.sun.java.swing.plaf.windows.WindowsFileChooserUI.installUI(Window
sFileChooserUI.java:150)
         at javax.swing.JComponent.setUI(JComponent.java:665)
         at javax.swing.JFileChooser.updateUI(JFileChooser.java:1837)
         at javax.swing.JFileChooser.setup(JFileChooser.java:372)
         at javax.swing.JFileChooser.<init>(JFileChooser.java:344)
         at javax.swing.JFileChooser.<init>(JFileChooser.java:297)
         at FileChooserDemo.createFileChooser(FileChooserDemo.java:129)
         at FileChooserDemo$2.actionPerformed(FileChooserDemo.java:148)
         at 
javax.swing.AbstractButton.fireActionPerformed(AbstractButton.java:20
23)
         at 
javax.swing.AbstractButton$Handler.actionPerformed(AbstractButton.jav
a:2347)
         at 
javax.swing.DefaultButtonModel.fireActionPerformed(DefaultButtonModel
.java:403)
         at 
javax.swing.DefaultButtonModel.setPressed(DefaultButtonModel.java:260
)
         at 
javax.swing.plaf.basic.BasicButtonListener.mouseReleased(BasicButtonL
istener.java:252)
         at java.awt.Component.processMouseEvent(Component.java:6536)
         at javax.swing.JComponent.processMouseEvent(JComponent.java:3323)
         at java.awt.Component.processEvent(Component.java:6301)
         at java.awt.Container.processEvent(Container.java:2244)
         at java.awt.Component.dispatchEventImpl(Component.java:4892)
         at java.awt.Container.dispatchEventImpl(Container.java:2302)
         at java.awt.Component.dispatchEvent(Component.java:4714)
         at 
java.awt.LightweightDispatcher.retargetMouseEvent(Container.java:4908
)
         at 
java.awt.LightweightDispatcher.processMouseEvent(Container.java:4543)
         at 
java.awt.LightweightDispatcher.dispatchEvent(Container.java:4472)
         at java.awt.Container.dispatchEventImpl(Container.java:2288)
         at java.awt.Window.dispatchEventImpl(Window.java:2739)
         at java.awt.Component.dispatchEvent(Component.java:4714)
         at java.awt.EventQueue.dispatchEventImpl(EventQueue.java:751)
         at java.awt.EventQueue.access$500(EventQueue.java:97)
         at java.awt.EventQueue$3.run(EventQueue.java:702)
         at java.awt.EventQueue$3.run(EventQueue.java:696)
         at java.security.AccessController.doPrivileged(Native Method)
         at 
java.security.ProtectionDomain$1.doIntersectionPrivilege(ProtectionDo
main.java:75)
         at 
java.security.ProtectionDomain$1.doIntersectionPrivilege(ProtectionDo
main.java:86)
         at java.awt.EventQueue$4.run(EventQueue.java:724)
         at java.awt.EventQueue$4.run(EventQueue.java:722)
         at java.security.AccessController.doPrivileged(Native Method)
         at 
java.security.ProtectionDomain$1.doIntersectionPrivilege(ProtectionDo
main.java:75)
         at java.awt.EventQueue.dispatchEvent(EventQueue.java:721)
         at 
java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThre
ad.java:201)
         at 
java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.
java:116)
         at 
java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThre
ad.java:105)
         at 
java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:101)

         at 
java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:93)
         at java.awt.EventDispatchThread.run(EventDispatchThread.java:82)

"AWT-Windows" #10 daemon prio=6 os_prio=0 tid=0x0d707c00 nid=0x1854 
waiting on c
ondition [0x0be6e000]
    java.lang.Thread.State: WAITING (parking)
         at sun.misc.Unsafe.park(Native Method)
         - parking to wait for  <0x1576d430> (a 
java.util.concurrent.locks.Reentr
antReadWriteLock$NonfairSync)
         at 
java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
         at 
java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInt
errupt(AbstractQueuedSynchronizer.java:836)
         at 
java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireQueued(A
bstractQueuedSynchronizer.java:870)
         at 
java.util.concurrent.locks.AbstractQueuedSynchronizer.acquire(Abstrac
tQueuedSynchronizer.java:1199)
         at 
java.util.concurrent.locks.ReentrantReadWriteLock$WriteLock.lock(Reen
trantReadWriteLock.java:942)
         at sun.awt.windows.ThemeReader.flush(ThemeReader.java:67)
         at 
sun.awt.windows.WDesktopProperties.getProperties(WDesktopProperties.j
ava:244)
         - locked <0x158595d0> (a sun.awt.windows.WDesktopProperties)
         at sun.awt.windows.WToolkit.getWProps(WToolkit.java:966)
         - locked <0x15859538> (a sun.awt.windows.WToolkit)
         at sun.awt.windows.WToolkit.windowsSettingChange(WToolkit.java:938)
         at sun.awt.windows.WToolkit.eventLoop(Native Method)
         at sun.awt.windows.WToolkit.run(WToolkit.java:305)
         at java.lang.Thread.run(Thread.java:745)

-phil.
On 6/9/2014 6:17 AM, Alexey Ivanov wrote:
> Hi Phil,
>
> My bad, I didn't pay due attention to other platforms because I 
> modified files specific to Windows and Windows LaF. Since Windows LaF 
> is not available at other platforms, I was sure these classes are 
> compiled only for Windows. My assumption proved to be wrong. In 
> future, I will always build all the platforms even if the changes are 
> platform-specific.
>
>
> Anthony, Petr,
>
> Could you please review my fix for build failure in another thread?
>
> I am really sorry about build failure. I won't make it happen again.
>
>
> Thanks,
> Alexey.
>
> On 06.06.2014 21:54, Phil Race wrote:
>> I filed P1 bug https://bugs.openjdk.java.net/browse/JDK-8046239
>>
>> You really should at least build on other platforms and you can use 
>> JPRT for that ..
>> Testing would be good too ..
>>
>> -phil.
>>
>> On 6/6/2014 10:48 AM, Phil Race wrote:
>>> ahem, this is a "bad fix". It has broken all non-windows builds 
>>> because shared code
>>> is now referencing WToolkit and ThemeReader. Please back out this 
>>> fix ASAP ..
>>>
>>> -phil.
>>>
>>> On 6/6/2014 7:03 AM, Anthony Petrov wrote:
>>>> You're welcome.
>>>>
>>>> -- 
>>>> best regards,
>>>> Anthony
>>>>
>>>> On 6/6/2014 5:58 PM, Alexey Ivanov wrote:
>>>>> Hi Anthony, Petr,
>>>>>
>>>>> Thank you for reviewing my fix.
>>>>>
>>>>> Regards,
>>>>> Alexey.
>>>>>
>>>>>
>>>>> On 06.06.2014 15:19, Anthony Petrov wrote:
>>>>>> +1
>>>>>>
>>>>>> -- 
>>>>>> best regards,
>>>>>> Anthony
>>>>>>
>>>>>> On 6/6/2014 3:20 PM, Petr Pchelko wrote:
>>>>>>> Hello, Alexey.
>>>>>>>
>>>>>>> The final version still looks good.
>>>>>>>
>>>>>>> With best regards. Petr.
>>>>>>>
>>>>>>> On 06 ???? 2014 ?., at 15:02, Alexey Ivanov
>>>>>>> <alexey.ivanov at oracle.com> wrote:
>>>>>>>
>>>>>>>> Hi Anthony, Petr, AWT and Swing teams,
>>>>>>>>
>>>>>>>> I've addressed Anthony's and Petr's comments in the updated 
>>>>>>>> webrev:
>>>>>>>> http://cr.openjdk.java.net/~aivanov/8039383/jdk9/webrev.04/
>>>>>>>>
>>>>>>>> Thank you,
>>>>>>>> Alexey.
>>>>>>>>
>>>>>>>> On 06.06.2014 12:16, Alexey Ivanov wrote:
>>>>>>>>> Hi Anthony,
>>>>>>>>>
>>>>>>>>> Thank you for your review.
>>>>>>>>>
>>>>>>>>> I've removed synchronized modifier from updateProperties() method
>>>>>>>>> which protected access to wprops field. Now this field is 
>>>>>>>>> accessed
>>>>>>>>> from synchronized methods lazilyInitWProps() and getWProps();
>>>>>>>>> setDesktopProperty also has proper synchronization - that was my
>>>>>>>>> reasoning for removing synchronized.
>>>>>>>>>
>>>>>>>>> But you're right, it was not the right decision as the update 
>>>>>>>>> loop
>>>>>>>>> now could execute simultaneously which is undesirable. I'll put
>>>>>>>>> synchronized modifier to updateProperties() method.
>>>>>>>>>
>>>>>>>>> Regards,
>>>>>>>>> Alexey.
>>>>>>>>>
>>>>>>>>> On 06.06.2014 1:07, Anthony Petrov wrote:
>>>>>>>>>> Hi Alexey,
>>>>>>>>>>
>>>>>>>>>> In WToolkit.java you're removing the synchronized modifier from
>>>>>>>>>> the private updateProperties() method. And it looks like the
>>>>>>>>>> method itself does allow for calling from multiple threads. 
>>>>>>>>>> So I'm
>>>>>>>>>> concerned about the lack of synchronization in this method. Was
>>>>>>>>>> the removal intentional? How is the method supposed to work now
>>>>>>>>>> when called from multiple threads?
>>>>>>>>>>
>>>>>>>>>> -- 
>>>>>>>>>> best regards,
>>>>>>>>>> Anthony
>>>>>>>>>>
>>>>>>>>>> On 6/5/2014 12:16 PM, Petr Pchelko wrote:
>>>>>>>>>>> Thank you for clarifications, I've been most interested in #2
>>>>>>>>>>> obviously.
>>>>>>>>>>>
>>>>>>>>>>> The fix looks good to me.
>>>>>>>>>>>
>>>>>>>>>>> With best regards. Petr.
>>>>>>>>>>>
>>>>>>>>>>> On 05 ???? 2014 ?., at 11:57, Alexey Ivanov
>>>>>>>>>>> <alexey.ivanov at oracle.com> wrote:
>>>>>>>>>>>
>>>>>>>>>>>> Hello Petr,
>>>>>>>>>>>>
>>>>>>>>>>>> Thank you for your comments.
>>>>>>>>>>>>
>>>>>>>>>>>> 1. Sure, I'll remove the comment before the change set is 
>>>>>>>>>>>> pushed.
>>>>>>>>>>>> 2. No, I didn't try stub XPStyle object. First of all, UI
>>>>>>>>>>>> delegates decide what painting method to use depending on
>>>>>>>>>>>> whether XPStyle.getXP() returns null or not. If 
>>>>>>>>>>>> XPStyle.getXP()
>>>>>>>>>>>> always returns non-null value, we'll have re-implement all UI
>>>>>>>>>>>> delegates for Windows plaf, and I believe it would result in
>>>>>>>>>>>> larger changeset. Additionally, some classes fallback to
>>>>>>>>>>>> inherited behavior where XPStyle.getXP() is not available.
>>>>>>>>>>>> Another reason is that UI delegates cache Skins: those objects
>>>>>>>>>>>> shouldn't paint where theming is unavailable.
>>>>>>>>>>>> 3. No, I haven't filed any bugs yet. I'll file all the issues
>>>>>>>>>>>> I've found in the nearest future.
>>>>>>>>>>>>
>>>>>>>>>>>> Regards,
>>>>>>>>>>>> Alexey.
>>>>>>>>>>>>
>>>>>>>>>>>> On 05.06.2014 11:08, Petr Pchelko wrote:
>>>>>>>>>>>>> Hello, Alexey.
>>>>>>>>>>>>>
>>>>>>>>>>>>> A couple of comments:
>>>>>>>>>>>>> 1. ThemeReader:64 - I suggest to remove that comment as it 
>>>>>>>>>>>>> does
>>>>>>>>>>>>> not add any value. The variable name is self explanatory.
>>>>>>>>>>>>> 2. XPStyle - did you try providing a stub XPStyle object
>>>>>>>>>>>>> instead of changing many of it's methods? Do I understand
>>>>>>>>>>>>> correctly that this
>>>>>>>>>>>>> is not possible because XPstyle is cached in many place is 
>>>>>>>>>>>>> our
>>>>>>>>>>>>> code?
>>>>>>>>>>>>> 3. In offline discussion you've mentioned that you've found
>>>>>>>>>>>>> another related issue. Did you have a chance to file a bug
>>>>>>>>>>>>> about it?
>>>>>>>>>>>>>
>>>>>>>>>>>>> Thank you.
>>>>>>>>>>>>> With best regards. Petr.
>>>>>>>>>>>>>
>>>>>>>>>>>>> On 05 ???? 2014 ?., at 10:35, Alexey Ivanov
>>>>>>>>>>>>> <alexey.ivanov at oracle.com> wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>>> Hi AWT and Swing teams,
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Could you please review the updated fix:
>>>>>>>>>>>>>> http://cr.openjdk.java.net/~aivanov/8039383/jdk9/webrev.03/
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> What has changed since version .02?
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> During additional testing, I found another scenario where 
>>>>>>>>>>>>>> NPE
>>>>>>>>>>>>>> was thrown. So the new version adds more checks to prevent
>>>>>>>>>>>>>> access to XPStyle and ThemeReader where Windows visual 
>>>>>>>>>>>>>> styles
>>>>>>>>>>>>>> become unavailable.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> As in previous version, getters in XPStyle class check for
>>>>>>>>>>>>>> null values and return dummy defaults if ThemeReader 
>>>>>>>>>>>>>> returned
>>>>>>>>>>>>>> null. Skin painters also check whether theming is still
>>>>>>>>>>>>>> available before asking ThemeReader to paint.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Access to XPStyle.xp instance is blocked as soon as user
>>>>>>>>>>>>>> switched themes. The object will be cleaned when the
>>>>>>>>>>>>>> corresponding PropertyChangeEvent is handled by Swing.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Thank you,
>>>>>>>>>>>>>> Alexey.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On 06.05.2014 12:14, Alexey Ivanov wrote:
>>>>>>>>>>>>>>> Hi AWT and Swing teams,
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Could you please review the updated fix:
>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~dmarkov/8039383/jdk9/webrev.02/
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> What has changed since version .01?
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> The issue was still reproducible with the .01 version of 
>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>> fix, however it was harder to reproduce.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> So in version .02 I added checks for null where 
>>>>>>>>>>>>>>> possible. If
>>>>>>>>>>>>>>> theme becomes unavailable, a dummy value will be used; this
>>>>>>>>>>>>>>> way applications will be more stable. As soon as the theme
>>>>>>>>>>>>>>> change events are handled, the entire UI will update 
>>>>>>>>>>>>>>> properly.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Thank you,
>>>>>>>>>>>>>>> Alexey.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> On 24.04.2014 16:23, Alexey Ivanov wrote:
>>>>>>>>>>>>>>>> Hi Anthony, AWT and Swing teams,
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Here's the updated fix:
>>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~dmarkov/8039383/jdk9/webrev.01/ 
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Description:
>>>>>>>>>>>>>>>> In the new version of the fix, I use a new xpstyleEnabled
>>>>>>>>>>>>>>>> field of AtomicBoolean in WToolkit to track the current
>>>>>>>>>>>>>>>> value of "win.xpstyle.themeActive" desktop property. Its
>>>>>>>>>>>>>>>> value is updated in windowsSettingChange() and in
>>>>>>>>>>>>>>>> updateProperties().
>>>>>>>>>>>>>>>> XPStyle.getXP() checks its cached value in themeActive and
>>>>>>>>>>>>>>>> the current value in WToolkit; if the value changes, it
>>>>>>>>>>>>>>>> schedules updateAllUIs and invalidates the current style
>>>>>>>>>>>>>>>> right away, so that components would not access data from
>>>>>>>>>>>>>>>> the theme that became unavailable.
>>>>>>>>>>>>>>>> Two functions in ThemeReader also check this special field
>>>>>>>>>>>>>>>> from WToolkit which prevents throwing InternalError when
>>>>>>>>>>>>>>>> paint is called before theme change is fully handled.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Before updateAllUIs is invoked, it's possible that
>>>>>>>>>>>>>>>> application will paint with some values cached from the
>>>>>>>>>>>>>>>> previous theme. Usually it happens before "Theme change"
>>>>>>>>>>>>>>>> dialog disappears from the screen, at least I noticed 
>>>>>>>>>>>>>>>> no UI
>>>>>>>>>>>>>>>> glitches during normal theme change.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Regression test:
>>>>>>>>>>>>>>>> No regression test is provided due to its complexity.
>>>>>>>>>>>>>>>> Additionally, 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.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Thank you,
>>>>>>>>>>>>>>>> Alexey.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> On 18.04.2014 18:52, Anthony Petrov wrote:
>>>>>>>>>>>>>>>>> Hi Alexey,
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> No, unfortunately I don't have any suggestions right now.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> As for allowing executing user code on the toolkit 
>>>>>>>>>>>>>>>>> thread,
>>>>>>>>>>>>>>>>> we can't accept such a fix. Sorry about that.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> -- 
>>>>>>>>>>>>>>>>> best regards,
>>>>>>>>>>>>>>>>> Anthony
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> On 4/18/2014 6:48 PM, Alexey Ivanov wrote:
>>>>>>>>>>>>>>>>>> Hi Anthony,
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Thank you for your review.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Yes, user code can install a property change listener...
>>>>>>>>>>>>>>>>>> It was my
>>>>>>>>>>>>>>>>>> concern too, that's why I explicitly noted about this.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Do you have any suggestion how this situation can be 
>>>>>>>>>>>>>>>>>> handled?
>>>>>>>>>>>>>>>>>> Is it a general rule that all desktop property change
>>>>>>>>>>>>>>>>>> listeners must be
>>>>>>>>>>>>>>>>>> called on EDT?
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>>>>>>> Alexey.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> On 18.04.2014 16:02, Anthony Petrov wrote:
>>>>>>>>>>>>>>>>>>> Hi Alexey,
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> With this change, property "win.xpstyle.themeActive"
>>>>>>>>>>>>>>>>>>>> change is fired
>>>>>>>>>>>>>>>>>>>> on the toolkit thread
>>>>>>>>>>>>>>>>>>> Is it possible to install a change listener for this
>>>>>>>>>>>>>>>>>>> property from
>>>>>>>>>>>>>>>>>>> user code, and hence eventually allow executing some 
>>>>>>>>>>>>>>>>>>> user
>>>>>>>>>>>>>>>>>>> code on the
>>>>>>>>>>>>>>>>>>> toolkit thread with your fix?
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> -- 
>>>>>>>>>>>>>>>>>>> best regards,
>>>>>>>>>>>>>>>>>>> Anthony
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> On 4/18/2014 12:09 PM, Alexey Ivanov wrote:
>>>>>>>>>>>>>>>>>>>> Hello Swing and AWT teams,
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> Could you please review the fix for jdk9:
>>>>>>>>>>>>>>>>>>>>      bug: 
>>>>>>>>>>>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8039383
>>>>>>>>>>>>>>>>>>>>      webrev:
>>>>>>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~dmarkov/8039383/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 "cached" in XPStyle object. 
>>>>>>>>>>>>>>>>>>>> When
>>>>>>>>>>>>>>>>>>>> the theme is
>>>>>>>>>>>>>>>>>>>> switched to a classic one, HTHEME handle becomes
>>>>>>>>>>>>>>>>>>>> unavailable and data
>>>>>>>>>>>>>>>>>>>> cannot be accessed from the theme any more. The change
>>>>>>>>>>>>>>>>>>>> in theme in
>>>>>>>>>>>>>>>>>>>> posted to EDT via invokeLater. At the same time, 
>>>>>>>>>>>>>>>>>>>> the UI
>>>>>>>>>>>>>>>>>>>> needs to repaint
>>>>>>>>>>>>>>>>>>>> itself as soon as Windows changed the theme, and paint
>>>>>>>>>>>>>>>>>>>> code is often
>>>>>>>>>>>>>>>>>>>> called before the theme change is handled in Java. 
>>>>>>>>>>>>>>>>>>>> This
>>>>>>>>>>>>>>>>>>>> leads to NPE and
>>>>>>>>>>>>>>>>>>>> InternalError as the code tries to access the data 
>>>>>>>>>>>>>>>>>>>> that
>>>>>>>>>>>>>>>>>>>> has become
>>>>>>>>>>>>>>>>>>>> unavailable.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> The fix:
>>>>>>>>>>>>>>>>>>>> Update "win.xpstyle.themeActive" desktop property and
>>>>>>>>>>>>>>>>>>>> invalidate the
>>>>>>>>>>>>>>>>>>>> cached XPStyle as soon as windowsSettingChange() is
>>>>>>>>>>>>>>>>>>>> called from native
>>>>>>>>>>>>>>>>>>>> code. Thus when Swing code needs to access theme data,
>>>>>>>>>>>>>>>>>>>> it will see no
>>>>>>>>>>>>>>>>>>>> theme is available and will fallback to classic 
>>>>>>>>>>>>>>>>>>>> painting.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> Note: Before the fix, PropertyChangeEvents for desktop
>>>>>>>>>>>>>>>>>>>> properties in
>>>>>>>>>>>>>>>>>>>> Windows were fired on the Event Dispatch Thread. With
>>>>>>>>>>>>>>>>>>>> this change,
>>>>>>>>>>>>>>>>>>>> property "win.xpstyle.themeActive" change is fired on
>>>>>>>>>>>>>>>>>>>> the toolkit
>>>>>>>>>>>>>>>>>>>> thread; all other properties are changed on the EDT as
>>>>>>>>>>>>>>>>>>>> before.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> Regards,
>>>>>>>>>>>>>>>>>>>> Alexey.
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>
>>>
>>
>


From philip.race at oracle.com  Mon Jun  9 22:18:02 2014
From: philip.race at oracle.com (Phil Race)
Date: Mon, 09 Jun 2014 15:18:02 -0700
Subject: <AWT Dev> <Swing Dev> [9] Review request for JDK-8039383: NPE
 when changing Windows Theme
In-Reply-To: <53962971.6060703@oracle.com>
References: <5350DDBC.30603@oracle.com>	<5351143C.8010100@oracle.com>	<53513B5B.4050104@oracle.com>	<53513C26.9060305@oracle.com>	<53590232.4080703@oracle.com>	<536899D1.1020501@oracle.com>	<53900FA7.8040508@oracle.com>	<0FE09EB0-B3A1-43F4-AE48-401DD55F5B09@oracle.com>	<539022E9.7070907@oracle.com>	<4240D39D-748C-483F-B447-1FAF6DFA25E4@oracle.com>	<5390DC2A.1030502@oracle.com>	<539178E4.6060101@oracle.com>	<53919FBC.9060807@oracle.com>	<D9978349-8209-44B2-B0E9-6CD94FBF88A2@oracle.com>	<5391A3BE.3030607@oracle.com>	<5391C8EB.5010501@oracle.com>	<5391CA38.60607@oracle.com>
	<5391FEF0.6080003@oracle.com>	<53920039.7080801@oracle.com>
	<5395B3CF.6000106@oracle.com> <53962971.6060703@oracle.com>
Message-ID: <5396329A.2020807@oracle.com>

I filed https://bugs.openjdk.java.net/browse/JDK-8046391

-phil.

On 6/9/2014 2:38 PM, Phil Race wrote:
> Hi,
> So the repo now builds but when I run SwingSet2 on Windows and select 
> the Win L&F and
> try to bring up JFileChooser the whole app hangs. Looks like the same 
> deadlock/hang that we
> saw on 7u60 (I think). I assumed this was to be the fix that addressed 
> the NPE *and*
> did not hang the app.
>
> "AWT-EventQueue-0" #12 prio=6 os_prio=0 tid=0x0d5d8c00 nid=0x208c 
> runnable [0x0d
> c1d000]
>    java.lang.Thread.State: RUNNABLE
>         at sun.awt.windows.ThemeReader.setWindowTheme(Native Method)
>         at sun.awt.windows.ThemeReader.getThemeImpl(ThemeReader.java:93)
>         at sun.awt.windows.ThemeReader.getTheme(ThemeReader.java:113)
>         at sun.awt.windows.ThemeReader.getEnum(ThemeReader.java:189)
>         at 
> com.sun.java.swing.plaf.windows.XPStyle.getTypeEnumName(XPStyle.java:
> 149)
>         at 
> com.sun.java.swing.plaf.windows.XPStyle.getBorder(XPStyle.java:275)
>         - locked <0x1021fa90> (a com.sun.java.swing.plaf.windows.XPStyle)
>         at 
> com.sun.java.swing.plaf.windows.WindowsToolBarUI.getRolloverBorder(Wi
> ndowsToolBarUI.java:94)
>         at 
> javax.swing.plaf.basic.BasicToolBarUI.setBorderToRollover(BasicToolBa
> rUI.java:692)
>         at 
> javax.swing.plaf.basic.BasicToolBarUI$Handler.componentAdded(BasicToo
> lBarUI.java:1131)
>         at java.awt.Container.processContainerEvent(Container.java:2270)
>         at java.awt.Container.processEvent(Container.java:2241)
>         at java.awt.Component.dispatchEventImpl(Component.java:4892)
>         at java.awt.Container.dispatchEventImpl(Container.java:2302)
>         at java.awt.Component.dispatchEvent(Component.java:4714)
>         at java.awt.Container.addImpl(Container.java:1146)
>         - locked <0x158a6570> (a java.awt.Component$AWTTreeLock)
>         at javax.swing.JToolBar.addImpl(JToolBar.java:581)
>         at java.awt.Container.add(Container.java:425)
>         at sun.swing.WindowsPlacesBar.<init>(WindowsPlacesBar.java:136)
>         at 
> com.sun.java.swing.plaf.windows.WindowsFileChooserUI.updateUseShellFo
> lder(WindowsFileChooserUI.java:508)
>         at 
> com.sun.java.swing.plaf.windows.WindowsFileChooserUI.installComponent
> s(WindowsFileChooserUI.java:213)
>         at 
> javax.swing.plaf.basic.BasicFileChooserUI.installUI(BasicFileChooserU
> I.java:173)
>         at 
> com.sun.java.swing.plaf.windows.WindowsFileChooserUI.installUI(Window
> sFileChooserUI.java:150)
>         at javax.swing.JComponent.setUI(JComponent.java:665)
>         at javax.swing.JFileChooser.updateUI(JFileChooser.java:1837)
>         at javax.swing.JFileChooser.setup(JFileChooser.java:372)
>         at javax.swing.JFileChooser.<init>(JFileChooser.java:344)
>         at javax.swing.JFileChooser.<init>(JFileChooser.java:297)
>         at FileChooserDemo.createFileChooser(FileChooserDemo.java:129)
>         at FileChooserDemo$2.actionPerformed(FileChooserDemo.java:148)
>         at 
> javax.swing.AbstractButton.fireActionPerformed(AbstractButton.java:20
> 23)
>         at 
> javax.swing.AbstractButton$Handler.actionPerformed(AbstractButton.jav
> a:2347)
>         at 
> javax.swing.DefaultButtonModel.fireActionPerformed(DefaultButtonModel
> .java:403)
>         at 
> javax.swing.DefaultButtonModel.setPressed(DefaultButtonModel.java:260
> )
>         at 
> javax.swing.plaf.basic.BasicButtonListener.mouseReleased(BasicButtonL
> istener.java:252)
>         at java.awt.Component.processMouseEvent(Component.java:6536)
>         at javax.swing.JComponent.processMouseEvent(JComponent.java:3323)
>         at java.awt.Component.processEvent(Component.java:6301)
>         at java.awt.Container.processEvent(Container.java:2244)
>         at java.awt.Component.dispatchEventImpl(Component.java:4892)
>         at java.awt.Container.dispatchEventImpl(Container.java:2302)
>         at java.awt.Component.dispatchEvent(Component.java:4714)
>         at 
> java.awt.LightweightDispatcher.retargetMouseEvent(Container.java:4908
> )
>         at 
> java.awt.LightweightDispatcher.processMouseEvent(Container.java:4543)
>         at 
> java.awt.LightweightDispatcher.dispatchEvent(Container.java:4472)
>         at java.awt.Container.dispatchEventImpl(Container.java:2288)
>         at java.awt.Window.dispatchEventImpl(Window.java:2739)
>         at java.awt.Component.dispatchEvent(Component.java:4714)
>         at java.awt.EventQueue.dispatchEventImpl(EventQueue.java:751)
>         at java.awt.EventQueue.access$500(EventQueue.java:97)
>         at java.awt.EventQueue$3.run(EventQueue.java:702)
>         at java.awt.EventQueue$3.run(EventQueue.java:696)
>         at java.security.AccessController.doPrivileged(Native Method)
>         at 
> java.security.ProtectionDomain$1.doIntersectionPrivilege(ProtectionDo
> main.java:75)
>         at 
> java.security.ProtectionDomain$1.doIntersectionPrivilege(ProtectionDo
> main.java:86)
>         at java.awt.EventQueue$4.run(EventQueue.java:724)
>         at java.awt.EventQueue$4.run(EventQueue.java:722)
>         at java.security.AccessController.doPrivileged(Native Method)
>         at 
> java.security.ProtectionDomain$1.doIntersectionPrivilege(ProtectionDo
> main.java:75)
>         at java.awt.EventQueue.dispatchEvent(EventQueue.java:721)
>         at 
> java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThre
> ad.java:201)
>         at 
> java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.
> java:116)
>         at 
> java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThre
> ad.java:105)
>         at 
> java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:101)
>
>         at 
> java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:93)
>         at java.awt.EventDispatchThread.run(EventDispatchThread.java:82)
>
> "AWT-Windows" #10 daemon prio=6 os_prio=0 tid=0x0d707c00 nid=0x1854 
> waiting on c
> ondition [0x0be6e000]
>    java.lang.Thread.State: WAITING (parking)
>         at sun.misc.Unsafe.park(Native Method)
>         - parking to wait for  <0x1576d430> (a 
> java.util.concurrent.locks.Reentr
> antReadWriteLock$NonfairSync)
>         at 
> java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
>         at 
> java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInt
> errupt(AbstractQueuedSynchronizer.java:836)
>         at 
> java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireQueued(A
> bstractQueuedSynchronizer.java:870)
>         at 
> java.util.concurrent.locks.AbstractQueuedSynchronizer.acquire(Abstrac
> tQueuedSynchronizer.java:1199)
>         at 
> java.util.concurrent.locks.ReentrantReadWriteLock$WriteLock.lock(Reen
> trantReadWriteLock.java:942)
>         at sun.awt.windows.ThemeReader.flush(ThemeReader.java:67)
>         at 
> sun.awt.windows.WDesktopProperties.getProperties(WDesktopProperties.j
> ava:244)
>         - locked <0x158595d0> (a sun.awt.windows.WDesktopProperties)
>         at sun.awt.windows.WToolkit.getWProps(WToolkit.java:966)
>         - locked <0x15859538> (a sun.awt.windows.WToolkit)
>         at 
> sun.awt.windows.WToolkit.windowsSettingChange(WToolkit.java:938)
>         at sun.awt.windows.WToolkit.eventLoop(Native Method)
>         at sun.awt.windows.WToolkit.run(WToolkit.java:305)
>         at java.lang.Thread.run(Thread.java:745)
>
> -phil.
> On 6/9/2014 6:17 AM, Alexey Ivanov wrote:
>> Hi Phil,
>>
>> My bad, I didn't pay due attention to other platforms because I 
>> modified files specific to Windows and Windows LaF. Since Windows LaF 
>> is not available at other platforms, I was sure these classes are 
>> compiled only for Windows. My assumption proved to be wrong. In 
>> future, I will always build all the platforms even if the changes are 
>> platform-specific.
>>
>>
>> Anthony, Petr,
>>
>> Could you please review my fix for build failure in another thread?
>>
>> I am really sorry about build failure. I won't make it happen again.
>>
>>
>> Thanks,
>> Alexey.
>>
>> On 06.06.2014 21:54, Phil Race wrote:
>>> I filed P1 bug https://bugs.openjdk.java.net/browse/JDK-8046239
>>>
>>> You really should at least build on other platforms and you can use 
>>> JPRT for that ..
>>> Testing would be good too ..
>>>
>>> -phil.
>>>
>>> On 6/6/2014 10:48 AM, Phil Race wrote:
>>>> ahem, this is a "bad fix". It has broken all non-windows builds 
>>>> because shared code
>>>> is now referencing WToolkit and ThemeReader. Please back out this 
>>>> fix ASAP ..
>>>>
>>>> -phil.
>>>>
>>>> On 6/6/2014 7:03 AM, Anthony Petrov wrote:
>>>>> You're welcome.
>>>>>
>>>>> -- 
>>>>> best regards,
>>>>> Anthony
>>>>>
>>>>> On 6/6/2014 5:58 PM, Alexey Ivanov wrote:
>>>>>> Hi Anthony, Petr,
>>>>>>
>>>>>> Thank you for reviewing my fix.
>>>>>>
>>>>>> Regards,
>>>>>> Alexey.
>>>>>>
>>>>>>
>>>>>> On 06.06.2014 15:19, Anthony Petrov wrote:
>>>>>>> +1
>>>>>>>
>>>>>>> -- 
>>>>>>> best regards,
>>>>>>> Anthony
>>>>>>>
>>>>>>> On 6/6/2014 3:20 PM, Petr Pchelko wrote:
>>>>>>>> Hello, Alexey.
>>>>>>>>
>>>>>>>> The final version still looks good.
>>>>>>>>
>>>>>>>> With best regards. Petr.
>>>>>>>>
>>>>>>>> On 06 ???? 2014 ?., at 15:02, Alexey Ivanov
>>>>>>>> <alexey.ivanov at oracle.com> wrote:
>>>>>>>>
>>>>>>>>> Hi Anthony, Petr, AWT and Swing teams,
>>>>>>>>>
>>>>>>>>> I've addressed Anthony's and Petr's comments in the updated 
>>>>>>>>> webrev:
>>>>>>>>> http://cr.openjdk.java.net/~aivanov/8039383/jdk9/webrev.04/
>>>>>>>>>
>>>>>>>>> Thank you,
>>>>>>>>> Alexey.
>>>>>>>>>
>>>>>>>>> On 06.06.2014 12:16, Alexey Ivanov wrote:
>>>>>>>>>> Hi Anthony,
>>>>>>>>>>
>>>>>>>>>> Thank you for your review.
>>>>>>>>>>
>>>>>>>>>> I've removed synchronized modifier from updateProperties() 
>>>>>>>>>> method
>>>>>>>>>> which protected access to wprops field. Now this field is 
>>>>>>>>>> accessed
>>>>>>>>>> from synchronized methods lazilyInitWProps() and getWProps();
>>>>>>>>>> setDesktopProperty also has proper synchronization - that was my
>>>>>>>>>> reasoning for removing synchronized.
>>>>>>>>>>
>>>>>>>>>> But you're right, it was not the right decision as the update 
>>>>>>>>>> loop
>>>>>>>>>> now could execute simultaneously which is undesirable. I'll put
>>>>>>>>>> synchronized modifier to updateProperties() method.
>>>>>>>>>>
>>>>>>>>>> Regards,
>>>>>>>>>> Alexey.
>>>>>>>>>>
>>>>>>>>>> On 06.06.2014 1:07, Anthony Petrov wrote:
>>>>>>>>>>> Hi Alexey,
>>>>>>>>>>>
>>>>>>>>>>> In WToolkit.java you're removing the synchronized modifier from
>>>>>>>>>>> the private updateProperties() method. And it looks like the
>>>>>>>>>>> method itself does allow for calling from multiple threads. 
>>>>>>>>>>> So I'm
>>>>>>>>>>> concerned about the lack of synchronization in this method. Was
>>>>>>>>>>> the removal intentional? How is the method supposed to work now
>>>>>>>>>>> when called from multiple threads?
>>>>>>>>>>>
>>>>>>>>>>> -- 
>>>>>>>>>>> best regards,
>>>>>>>>>>> Anthony
>>>>>>>>>>>
>>>>>>>>>>> On 6/5/2014 12:16 PM, Petr Pchelko wrote:
>>>>>>>>>>>> Thank you for clarifications, I've been most interested in #2
>>>>>>>>>>>> obviously.
>>>>>>>>>>>>
>>>>>>>>>>>> The fix looks good to me.
>>>>>>>>>>>>
>>>>>>>>>>>> With best regards. Petr.
>>>>>>>>>>>>
>>>>>>>>>>>> On 05 ???? 2014 ?., at 11:57, Alexey Ivanov
>>>>>>>>>>>> <alexey.ivanov at oracle.com> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>> Hello Petr,
>>>>>>>>>>>>>
>>>>>>>>>>>>> Thank you for your comments.
>>>>>>>>>>>>>
>>>>>>>>>>>>> 1. Sure, I'll remove the comment before the change set is 
>>>>>>>>>>>>> pushed.
>>>>>>>>>>>>> 2. No, I didn't try stub XPStyle object. First of all, UI
>>>>>>>>>>>>> delegates decide what painting method to use depending on
>>>>>>>>>>>>> whether XPStyle.getXP() returns null or not. If 
>>>>>>>>>>>>> XPStyle.getXP()
>>>>>>>>>>>>> always returns non-null value, we'll have re-implement all UI
>>>>>>>>>>>>> delegates for Windows plaf, and I believe it would result in
>>>>>>>>>>>>> larger changeset. Additionally, some classes fallback to
>>>>>>>>>>>>> inherited behavior where XPStyle.getXP() is not available.
>>>>>>>>>>>>> Another reason is that UI delegates cache Skins: those 
>>>>>>>>>>>>> objects
>>>>>>>>>>>>> shouldn't paint where theming is unavailable.
>>>>>>>>>>>>> 3. No, I haven't filed any bugs yet. I'll file all the issues
>>>>>>>>>>>>> I've found in the nearest future.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Regards,
>>>>>>>>>>>>> Alexey.
>>>>>>>>>>>>>
>>>>>>>>>>>>> On 05.06.2014 11:08, Petr Pchelko wrote:
>>>>>>>>>>>>>> Hello, Alexey.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> A couple of comments:
>>>>>>>>>>>>>> 1. ThemeReader:64 - I suggest to remove that comment as 
>>>>>>>>>>>>>> it does
>>>>>>>>>>>>>> not add any value. The variable name is self explanatory.
>>>>>>>>>>>>>> 2. XPStyle - did you try providing a stub XPStyle object
>>>>>>>>>>>>>> instead of changing many of it's methods? Do I understand
>>>>>>>>>>>>>> correctly that this
>>>>>>>>>>>>>> is not possible because XPstyle is cached in many place 
>>>>>>>>>>>>>> is our
>>>>>>>>>>>>>> code?
>>>>>>>>>>>>>> 3. In offline discussion you've mentioned that you've found
>>>>>>>>>>>>>> another related issue. Did you have a chance to file a bug
>>>>>>>>>>>>>> about it?
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Thank you.
>>>>>>>>>>>>>> With best regards. Petr.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On 05 ???? 2014 ?., at 10:35, Alexey Ivanov
>>>>>>>>>>>>>> <alexey.ivanov at oracle.com> wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Hi AWT and Swing teams,
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Could you please review the updated fix:
>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~aivanov/8039383/jdk9/webrev.03/
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> What has changed since version .02?
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> During additional testing, I found another scenario 
>>>>>>>>>>>>>>> where NPE
>>>>>>>>>>>>>>> was thrown. So the new version adds more checks to prevent
>>>>>>>>>>>>>>> access to XPStyle and ThemeReader where Windows visual 
>>>>>>>>>>>>>>> styles
>>>>>>>>>>>>>>> become unavailable.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> As in previous version, getters in XPStyle class check for
>>>>>>>>>>>>>>> null values and return dummy defaults if ThemeReader 
>>>>>>>>>>>>>>> returned
>>>>>>>>>>>>>>> null. Skin painters also check whether theming is still
>>>>>>>>>>>>>>> available before asking ThemeReader to paint.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Access to XPStyle.xp instance is blocked as soon as user
>>>>>>>>>>>>>>> switched themes. The object will be cleaned when the
>>>>>>>>>>>>>>> corresponding PropertyChangeEvent is handled by Swing.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Thank you,
>>>>>>>>>>>>>>> Alexey.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> On 06.05.2014 12:14, Alexey Ivanov wrote:
>>>>>>>>>>>>>>>> Hi AWT and Swing teams,
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Could you please review the updated fix:
>>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~dmarkov/8039383/jdk9/webrev.02/ 
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> What has changed since version .01?
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> The issue was still reproducible with the .01 version 
>>>>>>>>>>>>>>>> of the
>>>>>>>>>>>>>>>> fix, however it was harder to reproduce.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> So in version .02 I added checks for null where 
>>>>>>>>>>>>>>>> possible. If
>>>>>>>>>>>>>>>> theme becomes unavailable, a dummy value will be used; 
>>>>>>>>>>>>>>>> this
>>>>>>>>>>>>>>>> way applications will be more stable. As soon as the theme
>>>>>>>>>>>>>>>> change events are handled, the entire UI will update 
>>>>>>>>>>>>>>>> properly.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Thank you,
>>>>>>>>>>>>>>>> Alexey.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> On 24.04.2014 16:23, Alexey Ivanov wrote:
>>>>>>>>>>>>>>>>> Hi Anthony, AWT and Swing teams,
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Here's the updated fix:
>>>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~dmarkov/8039383/jdk9/webrev.01/ 
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Description:
>>>>>>>>>>>>>>>>> In the new version of the fix, I use a new xpstyleEnabled
>>>>>>>>>>>>>>>>> field of AtomicBoolean in WToolkit to track the current
>>>>>>>>>>>>>>>>> value of "win.xpstyle.themeActive" desktop property. Its
>>>>>>>>>>>>>>>>> value is updated in windowsSettingChange() and in
>>>>>>>>>>>>>>>>> updateProperties().
>>>>>>>>>>>>>>>>> XPStyle.getXP() checks its cached value in themeActive 
>>>>>>>>>>>>>>>>> and
>>>>>>>>>>>>>>>>> the current value in WToolkit; if the value changes, it
>>>>>>>>>>>>>>>>> schedules updateAllUIs and invalidates the current style
>>>>>>>>>>>>>>>>> right away, so that components would not access data from
>>>>>>>>>>>>>>>>> the theme that became unavailable.
>>>>>>>>>>>>>>>>> Two functions in ThemeReader also check this special 
>>>>>>>>>>>>>>>>> field
>>>>>>>>>>>>>>>>> from WToolkit which prevents throwing InternalError when
>>>>>>>>>>>>>>>>> paint is called before theme change is fully handled.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Before updateAllUIs is invoked, it's possible that
>>>>>>>>>>>>>>>>> application will paint with some values cached from the
>>>>>>>>>>>>>>>>> previous theme. Usually it happens before "Theme change"
>>>>>>>>>>>>>>>>> dialog disappears from the screen, at least I noticed 
>>>>>>>>>>>>>>>>> no UI
>>>>>>>>>>>>>>>>> glitches during normal theme change.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Regression test:
>>>>>>>>>>>>>>>>> No regression test is provided due to its complexity.
>>>>>>>>>>>>>>>>> Additionally, 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.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Thank you,
>>>>>>>>>>>>>>>>> Alexey.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> On 18.04.2014 18:52, Anthony Petrov wrote:
>>>>>>>>>>>>>>>>>> Hi Alexey,
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> No, unfortunately I don't have any suggestions right 
>>>>>>>>>>>>>>>>>> now.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> As for allowing executing user code on the toolkit 
>>>>>>>>>>>>>>>>>> thread,
>>>>>>>>>>>>>>>>>> we can't accept such a fix. Sorry about that.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> -- 
>>>>>>>>>>>>>>>>>> best regards,
>>>>>>>>>>>>>>>>>> Anthony
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> On 4/18/2014 6:48 PM, Alexey Ivanov wrote:
>>>>>>>>>>>>>>>>>>> Hi Anthony,
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Thank you for your review.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Yes, user code can install a property change 
>>>>>>>>>>>>>>>>>>> listener...
>>>>>>>>>>>>>>>>>>> It was my
>>>>>>>>>>>>>>>>>>> concern too, that's why I explicitly noted about this.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Do you have any suggestion how this situation can be 
>>>>>>>>>>>>>>>>>>> handled?
>>>>>>>>>>>>>>>>>>> Is it a general rule that all desktop property change
>>>>>>>>>>>>>>>>>>> listeners must be
>>>>>>>>>>>>>>>>>>> called on EDT?
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>>>>>>>> Alexey.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> On 18.04.2014 16:02, Anthony Petrov wrote:
>>>>>>>>>>>>>>>>>>>> Hi Alexey,
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> With this change, property "win.xpstyle.themeActive"
>>>>>>>>>>>>>>>>>>>>> change is fired
>>>>>>>>>>>>>>>>>>>>> on the toolkit thread
>>>>>>>>>>>>>>>>>>>> Is it possible to install a change listener for this
>>>>>>>>>>>>>>>>>>>> property from
>>>>>>>>>>>>>>>>>>>> user code, and hence eventually allow executing 
>>>>>>>>>>>>>>>>>>>> some user
>>>>>>>>>>>>>>>>>>>> code on the
>>>>>>>>>>>>>>>>>>>> toolkit thread with your fix?
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> -- 
>>>>>>>>>>>>>>>>>>>> best regards,
>>>>>>>>>>>>>>>>>>>> Anthony
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> On 4/18/2014 12:09 PM, Alexey Ivanov wrote:
>>>>>>>>>>>>>>>>>>>>> Hello Swing and AWT teams,
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> Could you please review the fix for jdk9:
>>>>>>>>>>>>>>>>>>>>>      bug: 
>>>>>>>>>>>>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8039383
>>>>>>>>>>>>>>>>>>>>>      webrev:
>>>>>>>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~dmarkov/8039383/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 "cached" in XPStyle object. 
>>>>>>>>>>>>>>>>>>>>> When
>>>>>>>>>>>>>>>>>>>>> the theme is
>>>>>>>>>>>>>>>>>>>>> switched to a classic one, HTHEME handle becomes
>>>>>>>>>>>>>>>>>>>>> unavailable and data
>>>>>>>>>>>>>>>>>>>>> cannot be accessed from the theme any more. The 
>>>>>>>>>>>>>>>>>>>>> change
>>>>>>>>>>>>>>>>>>>>> in theme in
>>>>>>>>>>>>>>>>>>>>> posted to EDT via invokeLater. At the same time, 
>>>>>>>>>>>>>>>>>>>>> the UI
>>>>>>>>>>>>>>>>>>>>> needs to repaint
>>>>>>>>>>>>>>>>>>>>> itself as soon as Windows changed the theme, and 
>>>>>>>>>>>>>>>>>>>>> paint
>>>>>>>>>>>>>>>>>>>>> code is often
>>>>>>>>>>>>>>>>>>>>> called before the theme change is handled in Java. 
>>>>>>>>>>>>>>>>>>>>> This
>>>>>>>>>>>>>>>>>>>>> leads to NPE and
>>>>>>>>>>>>>>>>>>>>> InternalError as the code tries to access the data 
>>>>>>>>>>>>>>>>>>>>> that
>>>>>>>>>>>>>>>>>>>>> has become
>>>>>>>>>>>>>>>>>>>>> unavailable.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> The fix:
>>>>>>>>>>>>>>>>>>>>> Update "win.xpstyle.themeActive" desktop property and
>>>>>>>>>>>>>>>>>>>>> invalidate the
>>>>>>>>>>>>>>>>>>>>> cached XPStyle as soon as windowsSettingChange() is
>>>>>>>>>>>>>>>>>>>>> called from native
>>>>>>>>>>>>>>>>>>>>> code. Thus when Swing code needs to access theme 
>>>>>>>>>>>>>>>>>>>>> data,
>>>>>>>>>>>>>>>>>>>>> it will see no
>>>>>>>>>>>>>>>>>>>>> theme is available and will fallback to classic 
>>>>>>>>>>>>>>>>>>>>> painting.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> Note: Before the fix, PropertyChangeEvents for 
>>>>>>>>>>>>>>>>>>>>> desktop
>>>>>>>>>>>>>>>>>>>>> properties in
>>>>>>>>>>>>>>>>>>>>> Windows were fired on the Event Dispatch Thread. With
>>>>>>>>>>>>>>>>>>>>> this change,
>>>>>>>>>>>>>>>>>>>>> property "win.xpstyle.themeActive" change is fired on
>>>>>>>>>>>>>>>>>>>>> the toolkit
>>>>>>>>>>>>>>>>>>>>> thread; all other properties are changed on the 
>>>>>>>>>>>>>>>>>>>>> EDT as
>>>>>>>>>>>>>>>>>>>>> before.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> Regards,
>>>>>>>>>>>>>>>>>>>>> Alexey.
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>
>>>>
>>>
>>
>


From Sergey.Bylokhov at oracle.com  Tue Jun 10 00:22:33 2014
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Tue, 10 Jun 2014 04:22:33 +0400
Subject: <AWT Dev> <Swing Dev> [9] Review request for JDK-8039383: NPE
 when changing Windows Theme
In-Reply-To: <5396329A.2020807@oracle.com>
References: <5350DDBC.30603@oracle.com>	<5351143C.8010100@oracle.com>	<53513B5B.4050104@oracle.com>	<53513C26.9060305@oracle.com>	<53590232.4080703@oracle.com>	<536899D1.1020501@oracle.com>	<53900FA7.8040508@oracle.com>	<0FE09EB0-B3A1-43F4-AE48-401DD55F5B09@oracle.com>	<539022E9.7070907@oracle.com>	<4240D39D-748C-483F-B447-1FAF6DFA25E4@oracle.com>	<5390DC2A.1030502@oracle.com>	<539178E4.6060101@oracle.com>	<53919FBC.9060807@oracle.com>	<D9978349-8209-44B2-B0E9-6CD94FBF88A2@oracle.com>	<5391A3BE.3030607@oracle.com>	<5391C8EB.5010501@oracle.com>	<5391CA38.60607@oracle.com>	<5391FEF0.6080003@oracle.com>	<53920039.7080801@oracle.com>	<5395B3CF.6000106@oracle.com>
	<53962971.6060703@oracle.com> <5396329A.2020807@oracle.com>
Message-ID: <53964FC9.4070301@oracle.com>

On 6/10/14 2:18 AM, Phil Race wrote:
> I filed https://bugs.openjdk.java.net/browse/JDK-8046391
Looks like this is not a regression and duplicate of JDK-8042590
>
> -phil.
>
> On 6/9/2014 2:38 PM, Phil Race wrote:
>> Hi,
>> So the repo now builds but when I run SwingSet2 on Windows and select 
>> the Win L&F and
>> try to bring up JFileChooser the whole app hangs. Looks like the same 
>> deadlock/hang that we
>> saw on 7u60 (I think). I assumed this was to be the fix that 
>> addressed the NPE *and*
>> did not hang the app.
>>
>> "AWT-EventQueue-0" #12 prio=6 os_prio=0 tid=0x0d5d8c00 nid=0x208c 
>> runnable [0x0d
>> c1d000]
>>    java.lang.Thread.State: RUNNABLE
>>         at sun.awt.windows.ThemeReader.setWindowTheme(Native Method)
>>         at sun.awt.windows.ThemeReader.getThemeImpl(ThemeReader.java:93)
>>         at sun.awt.windows.ThemeReader.getTheme(ThemeReader.java:113)
>>         at sun.awt.windows.ThemeReader.getEnum(ThemeReader.java:189)
>>         at 
>> com.sun.java.swing.plaf.windows.XPStyle.getTypeEnumName(XPStyle.java:
>> 149)
>>         at 
>> com.sun.java.swing.plaf.windows.XPStyle.getBorder(XPStyle.java:275)
>>         - locked <0x1021fa90> (a 
>> com.sun.java.swing.plaf.windows.XPStyle)
>>         at 
>> com.sun.java.swing.plaf.windows.WindowsToolBarUI.getRolloverBorder(Wi
>> ndowsToolBarUI.java:94)
>>         at 
>> javax.swing.plaf.basic.BasicToolBarUI.setBorderToRollover(BasicToolBa
>> rUI.java:692)
>>         at 
>> javax.swing.plaf.basic.BasicToolBarUI$Handler.componentAdded(BasicToo
>> lBarUI.java:1131)
>>         at java.awt.Container.processContainerEvent(Container.java:2270)
>>         at java.awt.Container.processEvent(Container.java:2241)
>>         at java.awt.Component.dispatchEventImpl(Component.java:4892)
>>         at java.awt.Container.dispatchEventImpl(Container.java:2302)
>>         at java.awt.Component.dispatchEvent(Component.java:4714)
>>         at java.awt.Container.addImpl(Container.java:1146)
>>         - locked <0x158a6570> (a java.awt.Component$AWTTreeLock)
>>         at javax.swing.JToolBar.addImpl(JToolBar.java:581)
>>         at java.awt.Container.add(Container.java:425)
>>         at sun.swing.WindowsPlacesBar.<init>(WindowsPlacesBar.java:136)
>>         at 
>> com.sun.java.swing.plaf.windows.WindowsFileChooserUI.updateUseShellFo
>> lder(WindowsFileChooserUI.java:508)
>>         at 
>> com.sun.java.swing.plaf.windows.WindowsFileChooserUI.installComponent
>> s(WindowsFileChooserUI.java:213)
>>         at 
>> javax.swing.plaf.basic.BasicFileChooserUI.installUI(BasicFileChooserU
>> I.java:173)
>>         at 
>> com.sun.java.swing.plaf.windows.WindowsFileChooserUI.installUI(Window
>> sFileChooserUI.java:150)
>>         at javax.swing.JComponent.setUI(JComponent.java:665)
>>         at javax.swing.JFileChooser.updateUI(JFileChooser.java:1837)
>>         at javax.swing.JFileChooser.setup(JFileChooser.java:372)
>>         at javax.swing.JFileChooser.<init>(JFileChooser.java:344)
>>         at javax.swing.JFileChooser.<init>(JFileChooser.java:297)
>>         at FileChooserDemo.createFileChooser(FileChooserDemo.java:129)
>>         at FileChooserDemo$2.actionPerformed(FileChooserDemo.java:148)
>>         at 
>> javax.swing.AbstractButton.fireActionPerformed(AbstractButton.java:20
>> 23)
>>         at 
>> javax.swing.AbstractButton$Handler.actionPerformed(AbstractButton.jav
>> a:2347)
>>         at 
>> javax.swing.DefaultButtonModel.fireActionPerformed(DefaultButtonModel
>> .java:403)
>>         at 
>> javax.swing.DefaultButtonModel.setPressed(DefaultButtonModel.java:260
>> )
>>         at 
>> javax.swing.plaf.basic.BasicButtonListener.mouseReleased(BasicButtonL
>> istener.java:252)
>>         at java.awt.Component.processMouseEvent(Component.java:6536)
>>         at 
>> javax.swing.JComponent.processMouseEvent(JComponent.java:3323)
>>         at java.awt.Component.processEvent(Component.java:6301)
>>         at java.awt.Container.processEvent(Container.java:2244)
>>         at java.awt.Component.dispatchEventImpl(Component.java:4892)
>>         at java.awt.Container.dispatchEventImpl(Container.java:2302)
>>         at java.awt.Component.dispatchEvent(Component.java:4714)
>>         at 
>> java.awt.LightweightDispatcher.retargetMouseEvent(Container.java:4908
>> )
>>         at 
>> java.awt.LightweightDispatcher.processMouseEvent(Container.java:4543)
>>         at 
>> java.awt.LightweightDispatcher.dispatchEvent(Container.java:4472)
>>         at java.awt.Container.dispatchEventImpl(Container.java:2288)
>>         at java.awt.Window.dispatchEventImpl(Window.java:2739)
>>         at java.awt.Component.dispatchEvent(Component.java:4714)
>>         at java.awt.EventQueue.dispatchEventImpl(EventQueue.java:751)
>>         at java.awt.EventQueue.access$500(EventQueue.java:97)
>>         at java.awt.EventQueue$3.run(EventQueue.java:702)
>>         at java.awt.EventQueue$3.run(EventQueue.java:696)
>>         at java.security.AccessController.doPrivileged(Native Method)
>>         at 
>> java.security.ProtectionDomain$1.doIntersectionPrivilege(ProtectionDo
>> main.java:75)
>>         at 
>> java.security.ProtectionDomain$1.doIntersectionPrivilege(ProtectionDo
>> main.java:86)
>>         at java.awt.EventQueue$4.run(EventQueue.java:724)
>>         at java.awt.EventQueue$4.run(EventQueue.java:722)
>>         at java.security.AccessController.doPrivileged(Native Method)
>>         at 
>> java.security.ProtectionDomain$1.doIntersectionPrivilege(ProtectionDo
>> main.java:75)
>>         at java.awt.EventQueue.dispatchEvent(EventQueue.java:721)
>>         at 
>> java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThre
>> ad.java:201)
>>         at 
>> java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.
>> java:116)
>>         at 
>> java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThre
>> ad.java:105)
>>         at 
>> java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:101)
>>
>>         at 
>> java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:93)
>>         at java.awt.EventDispatchThread.run(EventDispatchThread.java:82)
>>
>> "AWT-Windows" #10 daemon prio=6 os_prio=0 tid=0x0d707c00 nid=0x1854 
>> waiting on c
>> ondition [0x0be6e000]
>>    java.lang.Thread.State: WAITING (parking)
>>         at sun.misc.Unsafe.park(Native Method)
>>         - parking to wait for  <0x1576d430> (a 
>> java.util.concurrent.locks.Reentr
>> antReadWriteLock$NonfairSync)
>>         at 
>> java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
>>         at 
>> java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInt
>> errupt(AbstractQueuedSynchronizer.java:836)
>>         at 
>> java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireQueued(A
>> bstractQueuedSynchronizer.java:870)
>>         at 
>> java.util.concurrent.locks.AbstractQueuedSynchronizer.acquire(Abstrac
>> tQueuedSynchronizer.java:1199)
>>         at 
>> java.util.concurrent.locks.ReentrantReadWriteLock$WriteLock.lock(Reen
>> trantReadWriteLock.java:942)
>>         at sun.awt.windows.ThemeReader.flush(ThemeReader.java:67)
>>         at 
>> sun.awt.windows.WDesktopProperties.getProperties(WDesktopProperties.j
>> ava:244)
>>         - locked <0x158595d0> (a sun.awt.windows.WDesktopProperties)
>>         at sun.awt.windows.WToolkit.getWProps(WToolkit.java:966)
>>         - locked <0x15859538> (a sun.awt.windows.WToolkit)
>>         at 
>> sun.awt.windows.WToolkit.windowsSettingChange(WToolkit.java:938)
>>         at sun.awt.windows.WToolkit.eventLoop(Native Method)
>>         at sun.awt.windows.WToolkit.run(WToolkit.java:305)
>>         at java.lang.Thread.run(Thread.java:745)
>>
>> -phil.
>> On 6/9/2014 6:17 AM, Alexey Ivanov wrote:
>>> Hi Phil,
>>>
>>> My bad, I didn't pay due attention to other platforms because I 
>>> modified files specific to Windows and Windows LaF. Since Windows 
>>> LaF is not available at other platforms, I was sure these classes 
>>> are compiled only for Windows. My assumption proved to be wrong. In 
>>> future, I will always build all the platforms even if the changes 
>>> are platform-specific.
>>>
>>>
>>> Anthony, Petr,
>>>
>>> Could you please review my fix for build failure in another thread?
>>>
>>> I am really sorry about build failure. I won't make it happen again.
>>>
>>>
>>> Thanks,
>>> Alexey.
>>>
>>> On 06.06.2014 21:54, Phil Race wrote:
>>>> I filed P1 bug https://bugs.openjdk.java.net/browse/JDK-8046239
>>>>
>>>> You really should at least build on other platforms and you can use 
>>>> JPRT for that ..
>>>> Testing would be good too ..
>>>>
>>>> -phil.
>>>>
>>>> On 6/6/2014 10:48 AM, Phil Race wrote:
>>>>> ahem, this is a "bad fix". It has broken all non-windows builds 
>>>>> because shared code
>>>>> is now referencing WToolkit and ThemeReader. Please back out this 
>>>>> fix ASAP ..
>>>>>
>>>>> -phil.
>>>>>
>>>>> On 6/6/2014 7:03 AM, Anthony Petrov wrote:
>>>>>> You're welcome.
>>>>>>
>>>>>> -- 
>>>>>> best regards,
>>>>>> Anthony
>>>>>>
>>>>>> On 6/6/2014 5:58 PM, Alexey Ivanov wrote:
>>>>>>> Hi Anthony, Petr,
>>>>>>>
>>>>>>> Thank you for reviewing my fix.
>>>>>>>
>>>>>>> Regards,
>>>>>>> Alexey.
>>>>>>>
>>>>>>>
>>>>>>> On 06.06.2014 15:19, Anthony Petrov wrote:
>>>>>>>> +1
>>>>>>>>
>>>>>>>> -- 
>>>>>>>> best regards,
>>>>>>>> Anthony
>>>>>>>>
>>>>>>>> On 6/6/2014 3:20 PM, Petr Pchelko wrote:
>>>>>>>>> Hello, Alexey.
>>>>>>>>>
>>>>>>>>> The final version still looks good.
>>>>>>>>>
>>>>>>>>> With best regards. Petr.
>>>>>>>>>
>>>>>>>>> On 06 ???? 2014 ?., at 15:02, Alexey Ivanov
>>>>>>>>> <alexey.ivanov at oracle.com> wrote:
>>>>>>>>>
>>>>>>>>>> Hi Anthony, Petr, AWT and Swing teams,
>>>>>>>>>>
>>>>>>>>>> I've addressed Anthony's and Petr's comments in the updated 
>>>>>>>>>> webrev:
>>>>>>>>>> http://cr.openjdk.java.net/~aivanov/8039383/jdk9/webrev.04/
>>>>>>>>>>
>>>>>>>>>> Thank you,
>>>>>>>>>> Alexey.
>>>>>>>>>>
>>>>>>>>>> On 06.06.2014 12:16, Alexey Ivanov wrote:
>>>>>>>>>>> Hi Anthony,
>>>>>>>>>>>
>>>>>>>>>>> Thank you for your review.
>>>>>>>>>>>
>>>>>>>>>>> I've removed synchronized modifier from updateProperties() 
>>>>>>>>>>> method
>>>>>>>>>>> which protected access to wprops field. Now this field is 
>>>>>>>>>>> accessed
>>>>>>>>>>> from synchronized methods lazilyInitWProps() and getWProps();
>>>>>>>>>>> setDesktopProperty also has proper synchronization - that 
>>>>>>>>>>> was my
>>>>>>>>>>> reasoning for removing synchronized.
>>>>>>>>>>>
>>>>>>>>>>> But you're right, it was not the right decision as the 
>>>>>>>>>>> update loop
>>>>>>>>>>> now could execute simultaneously which is undesirable. I'll put
>>>>>>>>>>> synchronized modifier to updateProperties() method.
>>>>>>>>>>>
>>>>>>>>>>> Regards,
>>>>>>>>>>> Alexey.
>>>>>>>>>>>
>>>>>>>>>>> On 06.06.2014 1:07, Anthony Petrov wrote:
>>>>>>>>>>>> Hi Alexey,
>>>>>>>>>>>>
>>>>>>>>>>>> In WToolkit.java you're removing the synchronized modifier 
>>>>>>>>>>>> from
>>>>>>>>>>>> the private updateProperties() method. And it looks like the
>>>>>>>>>>>> method itself does allow for calling from multiple threads. 
>>>>>>>>>>>> So I'm
>>>>>>>>>>>> concerned about the lack of synchronization in this method. 
>>>>>>>>>>>> Was
>>>>>>>>>>>> the removal intentional? How is the method supposed to work 
>>>>>>>>>>>> now
>>>>>>>>>>>> when called from multiple threads?
>>>>>>>>>>>>
>>>>>>>>>>>> -- 
>>>>>>>>>>>> best regards,
>>>>>>>>>>>> Anthony
>>>>>>>>>>>>
>>>>>>>>>>>> On 6/5/2014 12:16 PM, Petr Pchelko wrote:
>>>>>>>>>>>>> Thank you for clarifications, I've been most interested in #2
>>>>>>>>>>>>> obviously.
>>>>>>>>>>>>>
>>>>>>>>>>>>> The fix looks good to me.
>>>>>>>>>>>>>
>>>>>>>>>>>>> With best regards. Petr.
>>>>>>>>>>>>>
>>>>>>>>>>>>> On 05 ???? 2014 ?., at 11:57, Alexey Ivanov
>>>>>>>>>>>>> <alexey.ivanov at oracle.com> wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>>> Hello Petr,
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Thank you for your comments.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> 1. Sure, I'll remove the comment before the change set is 
>>>>>>>>>>>>>> pushed.
>>>>>>>>>>>>>> 2. No, I didn't try stub XPStyle object. First of all, UI
>>>>>>>>>>>>>> delegates decide what painting method to use depending on
>>>>>>>>>>>>>> whether XPStyle.getXP() returns null or not. If 
>>>>>>>>>>>>>> XPStyle.getXP()
>>>>>>>>>>>>>> always returns non-null value, we'll have re-implement 
>>>>>>>>>>>>>> all UI
>>>>>>>>>>>>>> delegates for Windows plaf, and I believe it would result in
>>>>>>>>>>>>>> larger changeset. Additionally, some classes fallback to
>>>>>>>>>>>>>> inherited behavior where XPStyle.getXP() is not available.
>>>>>>>>>>>>>> Another reason is that UI delegates cache Skins: those 
>>>>>>>>>>>>>> objects
>>>>>>>>>>>>>> shouldn't paint where theming is unavailable.
>>>>>>>>>>>>>> 3. No, I haven't filed any bugs yet. I'll file all the 
>>>>>>>>>>>>>> issues
>>>>>>>>>>>>>> I've found in the nearest future.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Regards,
>>>>>>>>>>>>>> Alexey.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On 05.06.2014 11:08, Petr Pchelko wrote:
>>>>>>>>>>>>>>> Hello, Alexey.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> A couple of comments:
>>>>>>>>>>>>>>> 1. ThemeReader:64 - I suggest to remove that comment as 
>>>>>>>>>>>>>>> it does
>>>>>>>>>>>>>>> not add any value. The variable name is self explanatory.
>>>>>>>>>>>>>>> 2. XPStyle - did you try providing a stub XPStyle object
>>>>>>>>>>>>>>> instead of changing many of it's methods? Do I understand
>>>>>>>>>>>>>>> correctly that this
>>>>>>>>>>>>>>> is not possible because XPstyle is cached in many place 
>>>>>>>>>>>>>>> is our
>>>>>>>>>>>>>>> code?
>>>>>>>>>>>>>>> 3. In offline discussion you've mentioned that you've found
>>>>>>>>>>>>>>> another related issue. Did you have a chance to file a bug
>>>>>>>>>>>>>>> about it?
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Thank you.
>>>>>>>>>>>>>>> With best regards. Petr.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> On 05 ???? 2014 ?., at 10:35, Alexey Ivanov
>>>>>>>>>>>>>>> <alexey.ivanov at oracle.com> wrote:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Hi AWT and Swing teams,
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Could you please review the updated fix:
>>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~aivanov/8039383/jdk9/webrev.03/ 
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> What has changed since version .02?
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> During additional testing, I found another scenario 
>>>>>>>>>>>>>>>> where NPE
>>>>>>>>>>>>>>>> was thrown. So the new version adds more checks to prevent
>>>>>>>>>>>>>>>> access to XPStyle and ThemeReader where Windows visual 
>>>>>>>>>>>>>>>> styles
>>>>>>>>>>>>>>>> become unavailable.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> As in previous version, getters in XPStyle class check for
>>>>>>>>>>>>>>>> null values and return dummy defaults if ThemeReader 
>>>>>>>>>>>>>>>> returned
>>>>>>>>>>>>>>>> null. Skin painters also check whether theming is still
>>>>>>>>>>>>>>>> available before asking ThemeReader to paint.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Access to XPStyle.xp instance is blocked as soon as user
>>>>>>>>>>>>>>>> switched themes. The object will be cleaned when the
>>>>>>>>>>>>>>>> corresponding PropertyChangeEvent is handled by Swing.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Thank you,
>>>>>>>>>>>>>>>> Alexey.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> On 06.05.2014 12:14, Alexey Ivanov wrote:
>>>>>>>>>>>>>>>>> Hi AWT and Swing teams,
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Could you please review the updated fix:
>>>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~dmarkov/8039383/jdk9/webrev.02/ 
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> What has changed since version .01?
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> The issue was still reproducible with the .01 version 
>>>>>>>>>>>>>>>>> of the
>>>>>>>>>>>>>>>>> fix, however it was harder to reproduce.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> So in version .02 I added checks for null where 
>>>>>>>>>>>>>>>>> possible. If
>>>>>>>>>>>>>>>>> theme becomes unavailable, a dummy value will be used; 
>>>>>>>>>>>>>>>>> this
>>>>>>>>>>>>>>>>> way applications will be more stable. As soon as the 
>>>>>>>>>>>>>>>>> theme
>>>>>>>>>>>>>>>>> change events are handled, the entire UI will update 
>>>>>>>>>>>>>>>>> properly.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Thank you,
>>>>>>>>>>>>>>>>> Alexey.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> On 24.04.2014 16:23, Alexey Ivanov wrote:
>>>>>>>>>>>>>>>>>> Hi Anthony, AWT and Swing teams,
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Here's the updated fix:
>>>>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~dmarkov/8039383/jdk9/webrev.01/ 
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Description:
>>>>>>>>>>>>>>>>>> In the new version of the fix, I use a new 
>>>>>>>>>>>>>>>>>> xpstyleEnabled
>>>>>>>>>>>>>>>>>> field of AtomicBoolean in WToolkit to track the current
>>>>>>>>>>>>>>>>>> value of "win.xpstyle.themeActive" desktop property. Its
>>>>>>>>>>>>>>>>>> value is updated in windowsSettingChange() and in
>>>>>>>>>>>>>>>>>> updateProperties().
>>>>>>>>>>>>>>>>>> XPStyle.getXP() checks its cached value in 
>>>>>>>>>>>>>>>>>> themeActive and
>>>>>>>>>>>>>>>>>> the current value in WToolkit; if the value changes, it
>>>>>>>>>>>>>>>>>> schedules updateAllUIs and invalidates the current style
>>>>>>>>>>>>>>>>>> right away, so that components would not access data 
>>>>>>>>>>>>>>>>>> from
>>>>>>>>>>>>>>>>>> the theme that became unavailable.
>>>>>>>>>>>>>>>>>> Two functions in ThemeReader also check this special 
>>>>>>>>>>>>>>>>>> field
>>>>>>>>>>>>>>>>>> from WToolkit which prevents throwing InternalError when
>>>>>>>>>>>>>>>>>> paint is called before theme change is fully handled.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Before updateAllUIs is invoked, it's possible that
>>>>>>>>>>>>>>>>>> application will paint with some values cached from the
>>>>>>>>>>>>>>>>>> previous theme. Usually it happens before "Theme change"
>>>>>>>>>>>>>>>>>> dialog disappears from the screen, at least I noticed 
>>>>>>>>>>>>>>>>>> no UI
>>>>>>>>>>>>>>>>>> glitches during normal theme change.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Regression test:
>>>>>>>>>>>>>>>>>> No regression test is provided due to its complexity.
>>>>>>>>>>>>>>>>>> Additionally, 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.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Thank you,
>>>>>>>>>>>>>>>>>> Alexey.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> On 18.04.2014 18:52, Anthony Petrov wrote:
>>>>>>>>>>>>>>>>>>> Hi Alexey,
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> No, unfortunately I don't have any suggestions right 
>>>>>>>>>>>>>>>>>>> now.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> As for allowing executing user code on the toolkit 
>>>>>>>>>>>>>>>>>>> thread,
>>>>>>>>>>>>>>>>>>> we can't accept such a fix. Sorry about that.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> -- 
>>>>>>>>>>>>>>>>>>> best regards,
>>>>>>>>>>>>>>>>>>> Anthony
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> On 4/18/2014 6:48 PM, Alexey Ivanov wrote:
>>>>>>>>>>>>>>>>>>>> Hi Anthony,
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> Thank you for your review.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> Yes, user code can install a property change 
>>>>>>>>>>>>>>>>>>>> listener...
>>>>>>>>>>>>>>>>>>>> It was my
>>>>>>>>>>>>>>>>>>>> concern too, that's why I explicitly noted about this.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> Do you have any suggestion how this situation can 
>>>>>>>>>>>>>>>>>>>> be handled?
>>>>>>>>>>>>>>>>>>>> Is it a general rule that all desktop property change
>>>>>>>>>>>>>>>>>>>> listeners must be
>>>>>>>>>>>>>>>>>>>> called on EDT?
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>>>>>>>>> Alexey.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> On 18.04.2014 16:02, Anthony Petrov wrote:
>>>>>>>>>>>>>>>>>>>>> Hi Alexey,
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> With this change, property "win.xpstyle.themeActive"
>>>>>>>>>>>>>>>>>>>>>> change is fired
>>>>>>>>>>>>>>>>>>>>>> on the toolkit thread
>>>>>>>>>>>>>>>>>>>>> Is it possible to install a change listener for this
>>>>>>>>>>>>>>>>>>>>> property from
>>>>>>>>>>>>>>>>>>>>> user code, and hence eventually allow executing 
>>>>>>>>>>>>>>>>>>>>> some user
>>>>>>>>>>>>>>>>>>>>> code on the
>>>>>>>>>>>>>>>>>>>>> toolkit thread with your fix?
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> -- 
>>>>>>>>>>>>>>>>>>>>> best regards,
>>>>>>>>>>>>>>>>>>>>> Anthony
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> On 4/18/2014 12:09 PM, Alexey Ivanov wrote:
>>>>>>>>>>>>>>>>>>>>>> Hello Swing and AWT teams,
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> Could you please review the fix for jdk9:
>>>>>>>>>>>>>>>>>>>>>>      bug: 
>>>>>>>>>>>>>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8039383
>>>>>>>>>>>>>>>>>>>>>>      webrev:
>>>>>>>>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~dmarkov/8039383/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 "cached" in XPStyle 
>>>>>>>>>>>>>>>>>>>>>> object. When
>>>>>>>>>>>>>>>>>>>>>> the theme is
>>>>>>>>>>>>>>>>>>>>>> switched to a classic one, HTHEME handle becomes
>>>>>>>>>>>>>>>>>>>>>> unavailable and data
>>>>>>>>>>>>>>>>>>>>>> cannot be accessed from the theme any more. The 
>>>>>>>>>>>>>>>>>>>>>> change
>>>>>>>>>>>>>>>>>>>>>> in theme in
>>>>>>>>>>>>>>>>>>>>>> posted to EDT via invokeLater. At the same time, 
>>>>>>>>>>>>>>>>>>>>>> the UI
>>>>>>>>>>>>>>>>>>>>>> needs to repaint
>>>>>>>>>>>>>>>>>>>>>> itself as soon as Windows changed the theme, and 
>>>>>>>>>>>>>>>>>>>>>> paint
>>>>>>>>>>>>>>>>>>>>>> code is often
>>>>>>>>>>>>>>>>>>>>>> called before the theme change is handled in 
>>>>>>>>>>>>>>>>>>>>>> Java. This
>>>>>>>>>>>>>>>>>>>>>> leads to NPE and
>>>>>>>>>>>>>>>>>>>>>> InternalError as the code tries to access the 
>>>>>>>>>>>>>>>>>>>>>> data that
>>>>>>>>>>>>>>>>>>>>>> has become
>>>>>>>>>>>>>>>>>>>>>> unavailable.
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> The fix:
>>>>>>>>>>>>>>>>>>>>>> Update "win.xpstyle.themeActive" desktop property 
>>>>>>>>>>>>>>>>>>>>>> and
>>>>>>>>>>>>>>>>>>>>>> invalidate the
>>>>>>>>>>>>>>>>>>>>>> cached XPStyle as soon as windowsSettingChange() is
>>>>>>>>>>>>>>>>>>>>>> called from native
>>>>>>>>>>>>>>>>>>>>>> code. Thus when Swing code needs to access theme 
>>>>>>>>>>>>>>>>>>>>>> data,
>>>>>>>>>>>>>>>>>>>>>> it will see no
>>>>>>>>>>>>>>>>>>>>>> theme is available and will fallback to classic 
>>>>>>>>>>>>>>>>>>>>>> painting.
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> Note: Before the fix, PropertyChangeEvents for 
>>>>>>>>>>>>>>>>>>>>>> desktop
>>>>>>>>>>>>>>>>>>>>>> properties in
>>>>>>>>>>>>>>>>>>>>>> Windows were fired on the Event Dispatch Thread. 
>>>>>>>>>>>>>>>>>>>>>> With
>>>>>>>>>>>>>>>>>>>>>> this change,
>>>>>>>>>>>>>>>>>>>>>> property "win.xpstyle.themeActive" change is 
>>>>>>>>>>>>>>>>>>>>>> fired on
>>>>>>>>>>>>>>>>>>>>>> the toolkit
>>>>>>>>>>>>>>>>>>>>>> thread; all other properties are changed on the 
>>>>>>>>>>>>>>>>>>>>>> EDT as
>>>>>>>>>>>>>>>>>>>>>> before.
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> Regards,
>>>>>>>>>>>>>>>>>>>>>> Alexey.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>
>>>>>
>>>>
>>>
>>
>


-- 
Best regards, Sergey.


From alexandr.scherbatiy at oracle.com  Tue Jun 10 14:37:00 2014
From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy)
Date: Tue, 10 Jun 2014 18:37:00 +0400
Subject: <AWT Dev> [OpenJDK 2D-Dev] [9] Review request for 8029339
 Custom MultiResolution image support on HiDPI displays
In-Reply-To: <5396220E.9030708@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>
Message-ID: <5397180C.5040105@oracle.com>

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 alexey.ivanov at oracle.com  Tue Jun 10 15:21:56 2014
From: alexey.ivanov at oracle.com (Alexey Ivanov)
Date: Tue, 10 Jun 2014 19:21:56 +0400
Subject: <AWT Dev> [9] Review request for JDK-8046391: Hang displaying
 JFileChooser with Windows L&F
Message-ID: <53972294.1070901@oracle.com>

Hello AWT team,

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

Description:
The fix for JDK-8039383 "NPE when changing Windows Theme" caused a 
regression where JFileChooser hung. The root cause is the deadlock 
between Windows Toolkit thread and AWT Event Queue which is caused by 
the fact that ThemeReader.flush() is called on the toolkit thread.

The fix:
Modify ThemeReader so that flush() does not do the real work but marks 
the current state as invalid. The old theme data are removed when 
getTheme() is called which is done only from an Event Dispatch thread.

Regards,
Alexey.

From Sergey.Bylokhov at oracle.com  Tue Jun 10 16:22:44 2014
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Tue, 10 Jun 2014 20:22:44 +0400
Subject: <AWT Dev> [9] Review request for JDK-8046391: Hang displaying
 JFileChooser with Windows L&F
In-Reply-To: <53972294.1070901@oracle.com>
References: <53972294.1070901@oracle.com>
Message-ID: <539730D4.6080406@oracle.com>

This fix is identical to JDK-8042590, which was fixed in cpu workspace.
I guess the push under the new bugid will lead to integration problems 
in case of merge.

On 6/10/14 7:21 PM, Alexey Ivanov wrote:
> Hello AWT team,
>
> Could you please review the fix for bug:
>     bug: https://bugs.openjdk.java.net/browse/JDK-8046391
>     webrev: http://cr.openjdk.java.net/~aivanov/8046391/jdk9/webrev.01/
>
> Description:
> The fix for JDK-8039383 "NPE when changing Windows Theme" caused a 
> regression where JFileChooser hung. The root cause is the deadlock 
> between Windows Toolkit thread and AWT Event Queue which is caused by 
> the fact that ThemeReader.flush() is called on the toolkit thread.
>
> The fix:
> Modify ThemeReader so that flush() does not do the real work but marks 
> the current state as invalid. The old theme data are removed when 
> getTheme() is called which is done only from an Event Dispatch thread.
>
> Regards,
> Alexey.


-- 
Best regards, Sergey.


From alexey.ivanov at oracle.com  Tue Jun 10 17:52:53 2014
From: alexey.ivanov at oracle.com (Alexey Ivanov)
Date: Tue, 10 Jun 2014 21:52:53 +0400
Subject: <AWT Dev> [9] Review request for JDK-8046391: Hang displaying
 JFileChooser with Windows L&F
In-Reply-To: <539730D4.6080406@oracle.com>
References: <53972294.1070901@oracle.com> <539730D4.6080406@oracle.com>
Message-ID: <539745F5.5030302@oracle.com>

Hello AWT team,

Could you please review the reverse changeset:
http://cr.openjdk.java.net/~aivanov/8046391/jdk9/webrev.02/

This undoes the fixes for
     - JDK-8039383 "NPE when changing Windows Theme", and
     - JDK-8046239 "Build failure in 9-client on all non-Windows platforms"
which cause a regression where JFileChooser hangs in Windows Look-and-Feel.

The proper fix for JDK-8039383 requires some more time.


Thank you in advance,
Alexey.

On 10.06.2014 20:22, Sergey Bylokhov wrote:
> This fix is identical to JDK-8042590, which was fixed in cpu workspace.
> I guess the push under the new bugid will lead to integration problems 
> in case of merge.
>
> On 6/10/14 7:21 PM, Alexey Ivanov wrote:
>> Hello AWT team,
>>
>> Could you please review the fix for bug:
>>     bug: https://bugs.openjdk.java.net/browse/JDK-8046391
>>     webrev: http://cr.openjdk.java.net/~aivanov/8046391/jdk9/webrev.01/
>>
>> Description:
>> The fix for JDK-8039383 "NPE when changing Windows Theme" caused a 
>> regression where JFileChooser hung. The root cause is the deadlock 
>> between Windows Toolkit thread and AWT Event Queue which is caused by 
>> the fact that ThemeReader.flush() is called on the toolkit thread.
>>
>> The fix:
>> Modify ThemeReader so that flush() does not do the real work but 
>> marks the current state as invalid. The old theme data are removed 
>> when getTheme() is called which is done only from an Event Dispatch 
>> thread.
>>
>> Regards,
>> Alexey.
>
>


From anthony.petrov at oracle.com  Tue Jun 10 17:58:43 2014
From: anthony.petrov at oracle.com (Anthony Petrov)
Date: Tue, 10 Jun 2014 21:58:43 +0400
Subject: <AWT Dev> [9] Review request for JDK-8046391: Hang displaying
 JFileChooser with Windows L&F
In-Reply-To: <539745F5.5030302@oracle.com>
References: <53972294.1070901@oracle.com> <539730D4.6080406@oracle.com>
	<539745F5.5030302@oracle.com>
Message-ID: <53974753.4090109@oracle.com>

+1

--
best regards,
Anthony

On 6/10/2014 9:52 PM, Alexey Ivanov wrote:
> Hello AWT team,
>
> Could you please review the reverse changeset:
> http://cr.openjdk.java.net/~aivanov/8046391/jdk9/webrev.02/
>
> This undoes the fixes for
>      - JDK-8039383 "NPE when changing Windows Theme", and
>      - JDK-8046239 "Build failure in 9-client on all non-Windows platforms"
> which cause a regression where JFileChooser hangs in Windows Look-and-Feel.
>
> The proper fix for JDK-8039383 requires some more time.
>
>
> Thank you in advance,
> Alexey.
>
> On 10.06.2014 20:22, Sergey Bylokhov wrote:
>> This fix is identical to JDK-8042590, which was fixed in cpu workspace.
>> I guess the push under the new bugid will lead to integration problems
>> in case of merge.
>>
>> On 6/10/14 7:21 PM, Alexey Ivanov wrote:
>>> Hello AWT team,
>>>
>>> Could you please review the fix for bug:
>>>     bug: https://bugs.openjdk.java.net/browse/JDK-8046391
>>>     webrev: http://cr.openjdk.java.net/~aivanov/8046391/jdk9/webrev.01/
>>>
>>> Description:
>>> The fix for JDK-8039383 "NPE when changing Windows Theme" caused a
>>> regression where JFileChooser hung. The root cause is the deadlock
>>> between Windows Toolkit thread and AWT Event Queue which is caused by
>>> the fact that ThemeReader.flush() is called on the toolkit thread.
>>>
>>> The fix:
>>> Modify ThemeReader so that flush() does not do the real work but
>>> marks the current state as invalid. The old theme data are removed
>>> when getTheme() is called which is done only from an Event Dispatch
>>> thread.
>>>
>>> Regards,
>>> Alexey.
>>
>>
>

From Sergey.Bylokhov at oracle.com  Tue Jun 10 18:14:51 2014
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Tue, 10 Jun 2014 22:14:51 +0400
Subject: <AWT Dev> [9] Review request for JDK-8046391: Hang displaying
 JFileChooser with Windows L&F
In-Reply-To: <53974753.4090109@oracle.com>
References: <53972294.1070901@oracle.com> <539730D4.6080406@oracle.com>
	<539745F5.5030302@oracle.com> <53974753.4090109@oracle.com>
Message-ID: <53974B1B.90208@oracle.com>

Looks fine,
But double check, probably Phil already rolled back these changes.

On 6/10/14 9:58 PM, Anthony Petrov wrote:
> +1
>
> -- 
> best regards,
> Anthony
>
> On 6/10/2014 9:52 PM, Alexey Ivanov wrote:
>> Hello AWT team,
>>
>> Could you please review the reverse changeset:
>> http://cr.openjdk.java.net/~aivanov/8046391/jdk9/webrev.02/
>>
>> This undoes the fixes for
>>      - JDK-8039383 "NPE when changing Windows Theme", and
>>      - JDK-8046239 "Build failure in 9-client on all non-Windows 
>> platforms"
>> which cause a regression where JFileChooser hangs in Windows 
>> Look-and-Feel.
>>
>> The proper fix for JDK-8039383 requires some more time.
>>
>>
>> Thank you in advance,
>> Alexey.
>>
>> On 10.06.2014 20:22, Sergey Bylokhov wrote:
>>> This fix is identical to JDK-8042590, which was fixed in cpu workspace.
>>> I guess the push under the new bugid will lead to integration problems
>>> in case of merge.
>>>
>>> On 6/10/14 7:21 PM, Alexey Ivanov wrote:
>>>> Hello AWT team,
>>>>
>>>> Could you please review the fix for bug:
>>>>     bug: https://bugs.openjdk.java.net/browse/JDK-8046391
>>>>     webrev: 
>>>> http://cr.openjdk.java.net/~aivanov/8046391/jdk9/webrev.01/
>>>>
>>>> Description:
>>>> The fix for JDK-8039383 "NPE when changing Windows Theme" caused a
>>>> regression where JFileChooser hung. The root cause is the deadlock
>>>> between Windows Toolkit thread and AWT Event Queue which is caused by
>>>> the fact that ThemeReader.flush() is called on the toolkit thread.
>>>>
>>>> The fix:
>>>> Modify ThemeReader so that flush() does not do the real work but
>>>> marks the current state as invalid. The old theme data are removed
>>>> when getTheme() is called which is done only from an Event Dispatch
>>>> thread.
>>>>
>>>> Regards,
>>>> Alexey.
>>>
>>>
>>


-- 
Best regards, Sergey.


From alexey.ivanov at oracle.com  Tue Jun 10 18:20:57 2014
From: alexey.ivanov at oracle.com (Alexey Ivanov)
Date: Tue, 10 Jun 2014 22:20:57 +0400
Subject: <AWT Dev> [9] Review request for JDK-8046391: Hang displaying
 JFileChooser with Windows L&F
In-Reply-To: <53974B1B.90208@oracle.com>
References: <53972294.1070901@oracle.com> <539730D4.6080406@oracle.com>
	<539745F5.5030302@oracle.com> <53974753.4090109@oracle.com>
	<53974B1B.90208@oracle.com>
Message-ID: <53974C89.7030808@oracle.com>

Thank you Anthony and Sergey.

Phil hasn't rolled back them yet.
Now anyone with committer rights can do it.

Regards,
Alexey.

On 10.06.2014 22:14, Sergey Bylokhov wrote:
> Looks fine,
> But double check, probably Phil already rolled back these changes.
>
> On 6/10/14 9:58 PM, Anthony Petrov wrote:
>> +1
>>
>> -- 
>> best regards,
>> Anthony
>>
>> On 6/10/2014 9:52 PM, Alexey Ivanov wrote:
>>> Hello AWT team,
>>>
>>> Could you please review the reverse changeset:
>>> http://cr.openjdk.java.net/~aivanov/8046391/jdk9/webrev.02/
>>>
>>> This undoes the fixes for
>>>      - JDK-8039383 "NPE when changing Windows Theme", and
>>>      - JDK-8046239 "Build failure in 9-client on all non-Windows 
>>> platforms"
>>> which cause a regression where JFileChooser hangs in Windows 
>>> Look-and-Feel.
>>>
>>> The proper fix for JDK-8039383 requires some more time.
>>>
>>>
>>> Thank you in advance,
>>> Alexey.
>>>
>>> On 10.06.2014 20:22, Sergey Bylokhov wrote:
>>>> This fix is identical to JDK-8042590, which was fixed in cpu 
>>>> workspace.
>>>> I guess the push under the new bugid will lead to integration problems
>>>> in case of merge.
>>>>
>>>> On 6/10/14 7:21 PM, Alexey Ivanov wrote:
>>>>> Hello AWT team,
>>>>>
>>>>> Could you please review the fix for bug:
>>>>>     bug: https://bugs.openjdk.java.net/browse/JDK-8046391
>>>>>     webrev: 
>>>>> http://cr.openjdk.java.net/~aivanov/8046391/jdk9/webrev.01/
>>>>>
>>>>> Description:
>>>>> The fix for JDK-8039383 "NPE when changing Windows Theme" caused a
>>>>> regression where JFileChooser hung. The root cause is the deadlock
>>>>> between Windows Toolkit thread and AWT Event Queue which is caused by
>>>>> the fact that ThemeReader.flush() is called on the toolkit thread.
>>>>>
>>>>> The fix:
>>>>> Modify ThemeReader so that flush() does not do the real work but
>>>>> marks the current state as invalid. The old theme data are removed
>>>>> when getTheme() is called which is done only from an Event Dispatch
>>>>> thread.
>>>>>
>>>>> Regards,
>>>>> Alexey.
>>>>
>>>>
>>>
>
>


From philip.race at oracle.com  Tue Jun 10 21:48:22 2014
From: philip.race at oracle.com (Phil Race)
Date: Tue, 10 Jun 2014 14:48:22 -0700
Subject: <AWT Dev> [9] Review request for JDK-8046391: Hang displaying
 JFileChooser with Windows L&F
In-Reply-To: <53974C89.7030808@oracle.com>
References: <53972294.1070901@oracle.com> <539730D4.6080406@oracle.com>
	<539745F5.5030302@oracle.com> <53974753.4090109@oracle.com>
	<53974B1B.90208@oracle.com> <53974C89.7030808@oracle.com>
Message-ID: <53977D26.1020409@oracle.com>

I didn't roll back .. I am leaving that to you guys.

-phil.

On 6/10/2014 11:20 AM, Alexey Ivanov wrote:
> Thank you Anthony and Sergey.
>
> Phil hasn't rolled back them yet.
> Now anyone with committer rights can do it.
>
> Regards,
> Alexey.
>
> On 10.06.2014 22:14, Sergey Bylokhov wrote:
>> Looks fine,
>> But double check, probably Phil already rolled back these changes.
>>
>> On 6/10/14 9:58 PM, Anthony Petrov wrote:
>>> +1
>>>
>>> -- 
>>> best regards,
>>> Anthony
>>>
>>> On 6/10/2014 9:52 PM, Alexey Ivanov wrote:
>>>> Hello AWT team,
>>>>
>>>> Could you please review the reverse changeset:
>>>> http://cr.openjdk.java.net/~aivanov/8046391/jdk9/webrev.02/
>>>>
>>>> This undoes the fixes for
>>>>      - JDK-8039383 "NPE when changing Windows Theme", and
>>>>      - JDK-8046239 "Build failure in 9-client on all non-Windows 
>>>> platforms"
>>>> which cause a regression where JFileChooser hangs in Windows 
>>>> Look-and-Feel.
>>>>
>>>> The proper fix for JDK-8039383 requires some more time.
>>>>
>>>>
>>>> Thank you in advance,
>>>> Alexey.
>>>>
>>>> On 10.06.2014 20:22, Sergey Bylokhov wrote:
>>>>> This fix is identical to JDK-8042590, which was fixed in cpu 
>>>>> workspace.
>>>>> I guess the push under the new bugid will lead to integration 
>>>>> problems
>>>>> in case of merge.
>>>>>
>>>>> On 6/10/14 7:21 PM, Alexey Ivanov wrote:
>>>>>> Hello AWT team,
>>>>>>
>>>>>> Could you please review the fix for bug:
>>>>>>     bug: https://bugs.openjdk.java.net/browse/JDK-8046391
>>>>>>     webrev: 
>>>>>> http://cr.openjdk.java.net/~aivanov/8046391/jdk9/webrev.01/
>>>>>>
>>>>>> Description:
>>>>>> The fix for JDK-8039383 "NPE when changing Windows Theme" caused a
>>>>>> regression where JFileChooser hung. The root cause is the deadlock
>>>>>> between Windows Toolkit thread and AWT Event Queue which is 
>>>>>> caused by
>>>>>> the fact that ThemeReader.flush() is called on the toolkit thread.
>>>>>>
>>>>>> The fix:
>>>>>> Modify ThemeReader so that flush() does not do the real work but
>>>>>> marks the current state as invalid. The old theme data are removed
>>>>>> when getTheme() is called which is done only from an Event Dispatch
>>>>>> thread.
>>>>>>
>>>>>> Regards,
>>>>>> Alexey.
>>>>>
>>>>>
>>>>
>>
>>
>


From philip.race at oracle.com  Wed Jun 11 03:45:21 2014
From: philip.race at oracle.com (Phil Race)
Date: Tue, 10 Jun 2014 20:45:21 -0700
Subject: <AWT Dev> RFR: 8044551,
 8044396: Fix raw and unchecked lint warnings in platform-specific
 sun.awt and sun.java2d
In-Reply-To: <539128B5.9060907@oracle.com>
References: <5391027F.8020100@oracle.com> <539128B5.9060907@oracle.com>
Message-ID: <5397D0D1.2040404@oracle.com>

Ditto

-phil.

On 6/5/14 7:34 PM, Joe Darcy wrote:
> Hi Henry,
>
> From a quick look, the changes seem fine.
>
> Thanks,
>
> -Joe
>
> On 06/05/2014 04:51 PM, Henry Jen wrote:
>> Hi,
>>
>> Please review a follow-up to clean up rawtype and unchecked warnings 
>> in platform-specific code.
>>
>> Bug:
>> https://bugs.openjdk.java.net/browse/JDK-8044396
>> https://bugs.openjdk.java.net/browse/JDK-8044551
>>
>> Webrev:
>> http://cr.openjdk.java.net/~henryjen/jdk9/8044551/0/webrev/
>>
>> Cheers,
>> Henry
>


From dmitriy.ermashov at oracle.com  Wed Jun 11 06:28:23 2014
From: dmitriy.ermashov at oracle.com (Dmitriy Ermashov)
Date: Wed, 11 Jun 2014 10:28:23 +0400
Subject: <AWT Dev> Review Request for 8043972: Remove wrong copyright
 notice in
 jdk/test/java/awt/Frame/DecoratedExceptions/DecoratedExceptions.java
In-Reply-To: <538346BD.3040703@oracle.com>
References: <538346BD.3040703@oracle.com>
Message-ID: <5397F707.1040103@oracle.com>

Just a reminder.
Please, review the changeset.

Thanks,
Dima

On 26.05.2014 17:50, Dmitriy Ermashov wrote:
> Hi,
>
> Please review the changeset for:
> https://bugs.openjdk.java.net/browse/JDK-8043972
>
> The webrev is here:
> http://cr.openjdk.java.net/~dermashov/8043972/webrev.00/
>
> In addition to https://bugs.openjdk.java.net/browse/JDK-8041915
> There was a wrong copyright in test header.
>


From dmitriy.ermashov at oracle.com  Wed Jun 11 06:57:41 2014
From: dmitriy.ermashov at oracle.com (Dmitriy Ermashov)
Date: Wed, 11 Jun 2014 10:57:41 +0400
Subject: <AWT Dev> Review request for JDK-8043131: Move
 ShapedAndTranslucentWindows and GC functional AWT tests to regression tree
In-Reply-To: <E609129F-6738-4234-822D-F9F21795F498@oracle.com>
References: <5379F43E.8060000@oracle.com> <538DAFAD.3000409@oracle.com>
	<A5DF7FFD-728E-40C9-AE40-50C48216D456@oracle.com>
	<538ECECD.90208@oracle.com>
	<E609129F-6738-4234-822D-F9F21795F498@oracle.com>
Message-ID: <5397FDE5.30703@oracle.com>

Petr, thanks for review!

Sergey, could you please look at the fix?
http://cr.openjdk.java.net/~yan/8043131/webrev.02/
You had some notices for the previous bug 8041915 
(http://mail.openjdk.java.net/pipermail/awt-dev/2014-June/007944.html)

Thanks,
Dima

On 04.06.2014 12:00, Petr Pchelko wrote:
> Hello, Dmitriy.
>
> The new version looks fine to me.
>
> With best regards. Petr.
>
> On 04 ???? 2014 ?., at 11:46, Dmitriy Ermashov <dmitriy.ermashov at oracle.com> wrote:
>
>> Hi Petr, all,
>>
>> Please review next revision of webrev:
>> http://cr.openjdk.java.net/~yan/8043131/webrev.02/
>>
>> 1. Set -Xmx20m key for GC tests
>> 2. Added @Override annotation for all corresponding self written methods.
>>
>> Thanks,
>> Dima
>>
>> On 03.06.2014 16:33, Petr Pchelko wrote:
>>> Hello, Dmitriy.
>>>
>>> I think that it worths adding -Xmx option to the GC tests as default max heap size is quite big.
>>> Also could you please add @Override to the initGui method as now it's not obvious where is it called from.
>>>
>>> Thank you.
>>> With best regards. Petr.
>>>
>>> On 03 ???? 2014 ?., at 15:21, Dmitriy Ermashov <dmitriy.ermashov at oracle.com> wrote:
>>>
>>>> Hi all,
>>>>
>>>> Please review the last version of fix for
>>>> https://bugs.openjdk.java.net/browse/JDK-8043131
>>>>
>>>> The webrev is here:
>>>> http://cr.openjdk.java.net/~yan/8043131/webrev.01/
>>>>
>>>> Test colocation for remaining ShapedAndTranslucent part of functional tests.
>>>> The fix also includes remarks for the first part of this batch. E.g. retrieved "@author mrkam" tag and full description for each test.
>>>> GC tests also reverted as they are not similar to java/awt/Window/OwnedWindowsLeak/OwnedWindowsLeak.java and could be useful for finding bugs.
>>>>
>>>> Thanks,
>>>> Dima
>>>>
>>>> On 05/19/2014 04:08 PM, Dmitriy Ermashov wrote:
>>>>> Hi,
>>>>>
>>>>> Please review the changeset for bug:
>>>>> https://bugs.openjdk.java.net/browse/JDK-8043131
>>>>>
>>>>> The webrev is here:
>>>>> http://cr.openjdk.java.net/~yan/8043131/webrev.00/
>>>>>
>>>>> This is one more batch of functional AWT (ShapedAndTranslucentWindows and GC) tests are ought to be moved to regression tree.
>>>>>


From alexander.v.stepanov at oracle.com  Wed Jun 11 07:01:05 2014
From: alexander.v.stepanov at oracle.com (alexander stepanov)
Date: Wed, 11 Jun 2014 11:01:05 +0400
Subject: <AWT Dev> [9] Review request for 8043967: Fix doclint warnings for
 java.awt
In-Reply-To: <538DFBF7.3040502@oracle.com>
References: <538DC421.7060204@oracle.com> <538DD3FD.8050909@oracle.com>
	<538DFBF7.3040502@oracle.com>
Message-ID: <5397FEB1.2080906@oracle.com>

Sorry, just a reminder.

On 03.06.2014 20:46, alexander stepanov wrote:
> Hello Sergey,
>
> Updated; please see
> http://cr.openjdk.java.net/~avstepan/8043967/webrev.01/
>
> Thanks,
> Alexander
>
> On 03.06.2014 17:56, Sergey Bylokhov wrote:
>> Hi, Alexander.
>> A few notes:
>>  - Use two spaces after @param tag only. in other cases use one space.
>>  - Do no align names of the @params tag like this:
>>   390      * position will not be replaced).
>>   391      * @param   str  the non-{@code null} text to use as
>>   392      *               the replacement
>>   393      * @param   start  the start position
>>   394      * @param   end    the end position
>>   395      * @deprecated As of JDK version 1.1,
>> Change them to:
>>   390      * position will not be replaced).
>>   391      * @param  str the non-{@code null} text to use as
>>   392      *         the replacement
>>   393      * @param  start the start position
>>   394      * @param  end the end position
>>   395      * @deprecated As of JDK version 1.1,
>>   - Add empty line after method description before @param tag.
>>   - Description of the method should ends by dot.
>>
>> On 6/3/14 4:48 PM, alexander stepanov wrote:
>>> Hello,
>>>
>>> Could you please review the fix for the following bug:
>>> https://bugs.openjdk.java.net/browse/JDK-8043967
>>>
>>> Webrev:
>>> http://cr.openjdk.java.net/~avstepan/8043967
>>>
>>> Just a cleanup of javadoc to avoid doclint warnings.
>>>
>>> Thanks,
>>> Alexander
>>
>>
>> -- 
>> Best regards, Sergey.
>


From anthony.petrov at oracle.com  Wed Jun 11 09:17:34 2014
From: anthony.petrov at oracle.com (Anthony Petrov)
Date: Wed, 11 Jun 2014 13:17:34 +0400
Subject: <AWT Dev> Review Request for 8043972: Remove wrong copyright
 notice in
 jdk/test/java/awt/Frame/DecoratedExceptions/DecoratedExceptions.java
In-Reply-To: <5397F707.1040103@oracle.com>
References: <538346BD.3040703@oracle.com> <5397F707.1040103@oracle.com>
Message-ID: <53981EAE.3060606@oracle.com>

Hi Dmitriy,

The fix looks fine.

--
best regards,
Anthony

On 6/11/2014 10:28 AM, Dmitriy Ermashov wrote:
> Just a reminder.
> Please, review the changeset.
>
> Thanks,
> Dima
>
> On 26.05.2014 17:50, Dmitriy Ermashov wrote:
>> Hi,
>>
>> Please review the changeset for:
>> https://bugs.openjdk.java.net/browse/JDK-8043972
>>
>> The webrev is here:
>> http://cr.openjdk.java.net/~dermashov/8043972/webrev.00/
>>
>> In addition to https://bugs.openjdk.java.net/browse/JDK-8041915
>> There was a wrong copyright in test header.
>>
>

From Sergey.Bylokhov at oracle.com  Wed Jun 11 13:01:18 2014
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Wed, 11 Jun 2014 17:01:18 +0400
Subject: <AWT Dev> [9] Review Request: 8029253 [macosx] Performance problems
 with Retina display on Mac OS X
Message-ID: <5398531E.2050207@oracle.com>

Hello.
Please review the fix for jdk 9, which is also targeted for jdk 8u20.
Description:
We have two codepaths to draw a raster to the opengl:
  - via glDrawPixels
  - via intermediate texture.
We empirically checked, what way is better, based on benchmarks. Became 
obvious that on intel devices the glDrawPixels is slower than 
intermediate texture, and this is a bottleneck when the scrolling is used.

j2bench is not properly cover retina case, but according to some of my 
tests results is 2-3 times better.

There is no regressions on windows:
Summary:
   ogl-base:
     Number of tests:  60
     Overall average:  1452524.357368045
     Best spread:      0.17% variance
     Worst spread:     248.44% variance
     (Basis for results comparison)

   ogl-fix:
     Number of tests:  60
     Overall average:  1469528.5484618822
     Best spread:      0.12% variance
     Worst spread:     246.59% variance
     Comparison to basis:
       Best result:      161.48% of basis
       Worst result:     93.54% of basis
       Number of wins:   38
       Number of ties:   17
       Number of losses: 5

http://cr.openjdk.java.net/~serb/8029253/perf/windows.txt

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

-- 
Best regards, Sergey.


From Sergey.Bylokhov at oracle.com  Wed Jun 11 13:13:12 2014
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Wed, 11 Jun 2014 17:13:12 +0400
Subject: <AWT Dev> [9] Review Request: 8033786 White flashing when opening
 Dialogs and Menus using Nimbus with dark background
Message-ID: <539855E8.6070607@oracle.com>

Hello.
Please review the fix for jdk 9, which is also targeted for jdk 8u20.
Problems description:
JDialog does not set background color of the peer, like JFrame does + 
there is a lag between the showing of the window and the first repaint 
action(when the swing paints its own background). We should change the 
color of the native window to the color of the Component to fix flashing.
I need a review a swing and awt part.

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

-- 
Best regards, Sergey.


From andrew.brygin at oracle.com  Wed Jun 11 13:35:14 2014
From: andrew.brygin at oracle.com (Andrew Brygin)
Date: Wed, 11 Jun 2014 17:35:14 +0400
Subject: <AWT Dev> [9] Review Request: 8029253 [macosx] Performance
 problems with Retina display on Mac OS X
In-Reply-To: <5398531E.2050207@oracle.com>
References: <5398531E.2050207@oracle.com>
Message-ID: <53985B12.8010403@oracle.com>

Hi Sergey,

  could you please clarify why you have eliminated OGLC_VENDOR_SUN?

Thanks,
Andrew

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


From Sergey.Bylokhov at oracle.com  Wed Jun 11 13:43:55 2014
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Wed, 11 Jun 2014 17:43:55 +0400
Subject: <AWT Dev> [9] Review Request: 8029253 [macosx] Performance
 problems with Retina display on Mac OS X
In-Reply-To: <53985B12.8010403@oracle.com>
References: <5398531E.2050207@oracle.com> <53985B12.8010403@oracle.com>
Message-ID: <53985D1B.8070807@oracle.com>

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


-- 
Best regards, Sergey.


From Sergey.Bylokhov at oracle.com  Wed Jun 11 13:59:01 2014
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Wed, 11 Jun 2014 17:59:01 +0400
Subject: <AWT Dev> [9] Review request: 8040007 GtkFileDialog strips user
 inputted filepath
In-Reply-To: <5395E7C6.9050202@oracle.com>
References: <5391E5A0.4020106@oracle.com>
	<5395BF8D.5040203@oracle.com>	<5395CD9B.9000508@oracle.com>
	<5395E7C6.9050202@oracle.com>
Message-ID: <539860A5.3070900@oracle.com>

Hi, Alexander.
The fix looks good.

On 6/9/14 8:58 PM, Anthony Petrov wrote:
> Hi Alexander,
>
> Thanks for the update. The fix looks good to me.
>
> Note that myself, I wouldn't change the existing error handling code 
> (e.g. old LN 224-225 and 231-232 in sun_awt_X11_GtkFileDialogPeer.c), 
> but I'm still OK with that. Leaving this up to you and other reviewers.
>
> -- 
> best regards,
> Anthony
>
> On 6/9/2014 7:07 PM, Alexander Zvegintsev wrote:
>> Hi Anthony,
>>
>> thanks for the review, please see the updated webrev:
>> http://cr.openjdk.java.net/~azvegint/jdk/9/8040007/01/
>>
>>> I assume you've tested this case, and it still works fine, right?
>> Sure, it works fine. That is why gtk_file_chooser_get_current_folder()
>> is not used and
>> isFromSameDirectory() was introduced.
>>
>>
>> -- 
>> Thanks,
>> Alexander.
>>
>> On 06/09/2014 06:07 PM, Anthony Petrov wrote:
>>> Hi Alexander,
>>>
>>> src/solaris/native/sun/awt/sun_awt_X11_GtkFileDialogPeer.c
>>>>  176         free(prevDir);
>>>>  177         prevDir = strdup(dir);
>>>
>>> It's unnecessary to re-duplicate the prevDir on each loop iteration
>>> here. I suggest to initialize it once instead. The less pointer
>>> operations, the less room for bugs.
>>>
>>>
>>>>  229 (*env)->ExceptionClear(env);
>>>>  230         JNU_ThrowInternalError(env, "Could not instantiate
>>>> current folder");
>>>
>>> This error message sounds misleading because the code above doesn't
>>> instantiate a "folder", it tries to instantiate a string. Also, if
>>> exceptions did occur, I believe it's fine to report them as they are.
>>> Otherwise, if the pointer is NULL, then this looks more like an OOM
>>> than an internal error to me.
>>>
>>>
>>>>  278         //This is a hack for use with "Recent Folders" in gtk
>>>> where each
>>>>  279         //file could have its own directory.
>>>
>>> I assume you've tested this case, and it still works fine, right?
>>>
>>> -- 
>>> best regards,
>>> Anthony
>>>
>>> On 6/6/2014 8:00 PM, Alexander Zvegintsev wrote:
>>>> Hello,
>>>>
>>>> please review the fix
>>>> http://cr.openjdk.java.net/~azvegint/jdk/9/8040007/00/
>>>> for the bug
>>>> https://bugs.openjdk.java.net/browse/JDK-8040007
>>>>
>>>> With this fix we don't use current folder from native GtkFileChooser
>>>> anymore, now we build it by ourselves.
>>>>
>>>> [1]
>>>> https://developer.gnome.org/gtk2/stable/GtkFileChooser.html#gtk-file-chooser-get-filenames 
>>>>
>>>>
>>>>
>>>> [2]
>>>> https://developer.gnome.org/glib/stable/glib-Miscellaneous-Utility-Functions.html#g-path-get-dirname 
>>>>
>>>>
>>>>
>>>>
>>


-- 
Best regards, Sergey.


From alexandr.scherbatiy at oracle.com  Wed Jun 11 14:17:54 2014
From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy)
Date: Wed, 11 Jun 2014 18:17:54 +0400
Subject: <AWT Dev> [9] Review Request: 8033786 White flashing when
 opening Dialogs and Menus using Nimbus with dark background
In-Reply-To: <539855E8.6070607@oracle.com>
References: <539855E8.6070607@oracle.com>
Message-ID: <53986512.4050404@oracle.com>


  The swing part looks good for me.

   Thanks,
   Alexandr.

On 6/11/2014 5:13 PM, Sergey Bylokhov wrote:
> Hello.
> Please review the fix for jdk 9, which is also targeted for jdk 8u20.
> Problems description:
> JDialog does not set background color of the peer, like JFrame does + 
> there is a lag between the showing of the window and the first repaint 
> action(when the swing paints its own background). We should change the 
> color of the native window to the color of the Component to fix flashing.
> I need a review a swing and awt part.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8033786
> Webrev can be found at: 
> http://cr.openjdk.java.net/~serb/8033786/webrev.00
>


From alexandr.scherbatiy at oracle.com  Wed Jun 11 15:18:57 2014
From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy)
Date: Wed, 11 Jun 2014 19:18:57 +0400
Subject: <AWT Dev> [OpenJDK 2D-Dev] [9] Review request for 8029339
 Custom MultiResolution image support on HiDPI displays
In-Reply-To: <5397180C.5040105@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>
Message-ID: <53987361.5040903@oracle.com>


  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 henry.jen at oracle.com  Wed Jun 11 16:26:23 2014
From: henry.jen at oracle.com (Henry Jen)
Date: Wed, 11 Jun 2014 09:26:23 -0700
Subject: <AWT Dev> RFR: 8044551,
 8044396: Fix raw and unchecked lint warnings in platform-specific
 sun.awt and sun.java2d
In-Reply-To: <5397D0D1.2040404@oracle.com>
References: <5391027F.8020100@oracle.com> <539128B5.9060907@oracle.com>
	<5397D0D1.2040404@oracle.com>
Message-ID: <5398832F.8000607@oracle.com>

Thanks Joe and Phil for reviewing.

Cheers,
Henry

On 06/10/2014 08:45 PM, Phil Race wrote:
> Ditto
>
> -phil.
>
> On 6/5/14 7:34 PM, Joe Darcy wrote:
>> Hi Henry,
>>
>> From a quick look, the changes seem fine.
>>
>> Thanks,
>>
>> -Joe
>>
>> On 06/05/2014 04:51 PM, Henry Jen wrote:
>>> Hi,
>>>
>>> Please review a follow-up to clean up rawtype and unchecked warnings
>>> in platform-specific code.
>>>
>>> Bug:
>>> https://bugs.openjdk.java.net/browse/JDK-8044396
>>> https://bugs.openjdk.java.net/browse/JDK-8044551
>>>
>>> Webrev:
>>> http://cr.openjdk.java.net/~henryjen/jdk9/8044551/0/webrev/
>>>
>>> Cheers,
>>> Henry
>>
>

From anthony.petrov at oracle.com  Wed Jun 11 19:00:04 2014
From: anthony.petrov at oracle.com (Anthony Petrov)
Date: Wed, 11 Jun 2014 23:00:04 +0400
Subject: <AWT Dev> [9] Review Request: 8033786 White flashing when
 opening Dialogs and Menus using Nimbus with dark background
In-Reply-To: <539855E8.6070607@oracle.com>
References: <539855E8.6070607@oracle.com>
Message-ID: <5398A734.8050104@oracle.com>

Hi Sergey,

I suggest to add a comment/javadoc to 
CWrapper.NSWindow.setBackgroundColor() to document the format of the 
integer argument (the order of the color components, to be precise, or 
the color model.) No need for a new webrev with this change.

Other than that, the fix looks good to me.

--
best regards,
Anthony

On 6/11/2014 5:13 PM, Sergey Bylokhov wrote:
> Hello.
> Please review the fix for jdk 9, which is also targeted for jdk 8u20.
> Problems description:
> JDialog does not set background color of the peer, like JFrame does +
> there is a lag between the showing of the window and the first repaint
> action(when the swing paints its own background). We should change the
> color of the native window to the color of the Component to fix flashing.
> I need a review a swing and awt part.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8033786
> Webrev can be found at: http://cr.openjdk.java.net/~serb/8033786/webrev.00
>

From david.dehaven at oracle.com  Fri Jun 13 21:43:10 2014
From: david.dehaven at oracle.com (David DeHaven)
Date: Fri, 13 Jun 2014 14:43:10 -0700
Subject: <AWT Dev> [8u20] RFR: 8042440: awt_Plugin.h no longer needed
In-Reply-To: <4FA85391-53F0-41B3-97D9-C6E32C933023@oracle.com>
References: <4FA85391-53F0-41B3-97D9-C6E32C933023@oracle.com>
Message-ID: <9BAC6F0F-E54D-41E0-89DE-2D73C65CD35E@oracle.com>


In my haste I forgot to post to awt-dev...

Can someone please review this backport to 8u? The differences are trivial from the 9 changes.

-DrD-

> 
> Please review the backport of JDK-8042440. The changes are identical to the JDK9 changes except for exactly one line:
> 
> $ diff -Narup ~/Desktop/8042440-{8u,9}
> @@ -143,7 +143,7 @@ diff --git a/src/solaris/native/sun/awt/
> -
> -
> -#define REFLECT_VOID_FUNCTION(name, arglist, paramlist)                 \
> --typedef name##_type arglist;                                            \
> +-typedef void name##_type arglist;                                       \
> -void name arglist                                                       \
> -{                                                                       \
> -    static name##_type *name##_ptr = NULL;                              \
> 
> It seems someone added a void return type to the function being deleted, which resulted in the patch conflict, the end result is the same, all that code is deleted.
> 
> 
> JBS Issue:
> https://bugs.openjdk.java.net/browse/JDK-8042440
> 
> JDK 9 review:
> http://mail.openjdk.java.net/pipermail/awt-dev/2014-May/007671.html
> 
> Existing JDK9 patch:
> http://hg.openjdk.java.net/jdk9/client/jdk/rev/75206fa5a43e
> 
> JDK 8u-dev webrev:
> http://cr.openjdk.java.net/~ddehaven/8042440/8u-bp/
> 
> -DrD-
> 


From petr.pchelko at oracle.com  Mon Jun 16 07:05:00 2014
From: petr.pchelko at oracle.com (Petr Pchelko)
Date: Mon, 16 Jun 2014 11:05:00 +0400
Subject: <AWT Dev> Review Request for 8043972: Remove wrong copyright
	notice in
	jdk/test/java/awt/Frame/DecoratedExceptions/DecoratedExceptions.java
In-Reply-To: <5397F707.1040103@oracle.com>
References: <538346BD.3040703@oracle.com> <5397F707.1040103@oracle.com>
Message-ID: <7B091BFD-AA2F-4A44-AF13-A862A7082819@oracle.com>

Hello, Dmitriy.

Looks good to me too.

With best regards. Petr.

On 11 ???? 2014 ?., at 10:28, Dmitriy Ermashov <dmitriy.ermashov at oracle.com> wrote:

> Just a reminder.
> Please, review the changeset.
> 
> Thanks,
> Dima
> 
> On 26.05.2014 17:50, Dmitriy Ermashov wrote:
>> Hi,
>> 
>> Please review the changeset for:
>> https://bugs.openjdk.java.net/browse/JDK-8043972
>> 
>> The webrev is here:
>> http://cr.openjdk.java.net/~dermashov/8043972/webrev.00/
>> 
>> In addition to https://bugs.openjdk.java.net/browse/JDK-8041915
>> There was a wrong copyright in test header.
>> 
> 


From jvanek at redhat.com  Mon Jun 16 09:34:42 2014
From: jvanek at redhat.com (Jiri Vanek)
Date: Mon, 16 Jun 2014 11:34:42 +0200
Subject: <AWT Dev> Fwd: RFR: make life easier for general java plugin
In-Reply-To: <537CBFEB.6070104@redhat.com>
References: <5379FFBB.4050406@redhat.com> <537CBFEB.6070104@redhat.com>
Message-ID: <539EBA32.30502@redhat.com>

ping?

On 05/21/2014 05:02 PM, Jiri Vanek wrote:
>
> Hi!
>
> IcedTea-Web [1] have now patch [3] from [2] thread,  to work pretty smooth with all Icedteas, all
> Openjdks and all Oracle javas.  It even do work with IBM java.
> However, we needed to include few lines of copypasted code [3] line 274-283. Well it is not so much,
> but is potentially dangerous.
>
> If this mini changeset -  http://jvanek.fedorapeople.org/oracle/jdk9/applet-minipatch/1/webrev/ may
> go in, it would be awesome and will make icedtea-web true Openjdk plugin. Do you think it is possible?
>
> Just note - there already was a discussion about unnecessary complex version of similar patch -  [4]
> thread. As result it forbid any touches to sun.applet package. However current webrev do not add any
> more visibility. It changes from private to package private. I hope it is much more suitable
>
> I sent this message originally to jdk9-dev.. It/I was wrong I guess. Sorry
>
> Best regards,
>    J.
>
> [1] http://icedtea.classpath.org/wiki/IcedTea-Web
> [2] http://mail.openjdk.java.net/pipermail/distro-pkg-dev/2014-May/027577.html thread
> [3]
> http://mail.openjdk.java.net/pipermail/distro-pkg-dev/attachments/20140513/a47d6d04/allOpenJdk-0001.patch
>
> [4] http://mail.openjdk.java.net/pipermail/jdk9-dev/2014-January/000320.html
>
>


From petr.pchelko at oracle.com  Mon Jun 16 11:31:16 2014
From: petr.pchelko at oracle.com (Petr Pchelko)
Date: Mon, 16 Jun 2014 15:31:16 +0400
Subject: <AWT Dev> [9] Review Request: 8033367 [macosx] Appletviewer was
	broken in jdk8 b124
In-Reply-To: <538DD4C5.7050401@oracle.com>
References: <0FFA30BF-BDC5-4B0C-8E8A-B8982A60EE97@oracle.com>
	<538DD4C5.7050401@oracle.com>
Message-ID: <555DBA9F-86C0-4BCA-A5CA-B19F3CE42828@oracle.com>

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 alexandr.scherbatiy at oracle.com  Mon Jun 16 11:39:11 2014
From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy)
Date: Mon, 16 Jun 2014 15:39:11 +0400
Subject: <AWT Dev> Review Request: 8046221 [TEST_BUG] Cleanup
	datatransfer tests
In-Reply-To: <778EB5FC-D8C6-4423-97FE-50C932B00584@oracle.com>
References: <778EB5FC-D8C6-4423-97FE-50C932B00584@oracle.com>
Message-ID: <539ED75F.9080301@oracle.com>


  The fix looks good for me.

   Thanks,
   Alexandr.

On 6/6/2014 5:05 PM, Petr Pchelko wrote:
> Hello, AWT Team.
>
> Please review the fix for the issue:
> https://bugs.openjdk.java.net/browse/JDK-8046221
> The fix is available at:
> http://cr.openjdk.java.net/~pchelko/9/8046221/webrev/
>
> During my datatransfer modularization work I've needed to run some tests, but all our datatransfer
> tests depend on desktop and fail due to some other bug in jigsaw.  So I've cleaned them up,
> opensourced a bunch of tests and moved other test to the correct locations.
>
> The pass rate in 100% for normal build.
>
> With best regards. Petr.


From paul.sandoz at oracle.com  Mon Jun 16 16:51:04 2014
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Mon, 16 Jun 2014 17:51:04 +0100
Subject: <AWT Dev> [OpenJDK 2D-Dev] JDK-8041679 Replace uses of
	StringBuffer with StringBuilder within the JDK
In-Reply-To: <68F1F3CD-502A-4CBC-ABD6-7B1A24F9D3D8@oracle.com>
References: <0CB20945-D7D7-4151-A546-80634F014A46@oracle.com>	<5371FDBD.9020002@oracle.com>	<0522DF2A-F91C-43D3-ABCF-CA74F8971DB5@oracle.com>	<53728B83.1060307@oracle.com>	<8A20EC45-A21E-49C8-9A8A-BDC16ED97B91@oracle.com>	<537331E5.4070108@oracle.com>	<007101BF-30BC-4761-A13A-0AE1EAD36DF5@oracle.com>	<53766815.40600@oracle.com>	<6F7CE86A-E4B7-4F6B-B698-6426890D1409@oracle.com>
	<5379B7DC.2020206@oracle.com> <537A3CF5.5010401@oracle.com>
	<68F1F3CD-502A-4CBC-ABD6-7B1A24F9D3D8@oracle.com>
Message-ID: <93462213-92CF-46A3-B465-7A52E4193775@oracle.com>

After some further reflection i have decided to not separate this out and some bits going to client and some bits going to dev, and have pushed all changes to dev. I realise this might cause some friction but believe it the right thing to do.

I remain unconvinced that the separate process for patches such as this scales and is a valuable use of our development time and resources. A merging process is surely fundamentally more efficient (and anyway has to be performed) over N developers having to use a slightly different process [*].

Call me human and flawed in my management of time :-( but higher priority things keep getting pushed to the top of my stack before getting around to following this separate process and i really don't want the code to bit rot. I suspect i am not unique in this regard.

Paul.

[*] Is it documented? I have never managed to obtain a definitive answer, nor an explicit white-list of Java package names (external yes, internal no).

On May 20, 2014, at 7:45 AM, Paul Sandoz <Paul.Sandoz at oracle.com> wrote:

> 
> On May 19, 2014, at 6:18 PM, Phil Race <philip.race at oracle.com> wrote:
> 
>> On 5/19/2014 12:50 AM, Alan Bateman wrote:
>>> On 19/05/2014 07:53, Paul Sandoz wrote:
>>>> If i don't have permission to push to the client repo (which might be likely) i will need to hand over the patch to yourself or Sergey to commit. And i presume this will have to be a separate issue.
>>> If you do decide to split this then it will require creating a second issue JIRA to avoid running foul of jcheck when jdk/client eventually pushes to jdk/dev. I don't know how often jdk9/client integrates into jdk9/dev but it doesn't seem to be very frequent (hg incoming suggests there is currently about a month of changes backed up in jdk9/client but there may be issues to explain this).
>>> 
>>> For this specific case then it doesn't seem worth it, it would be much less effort to just push the lot to jdk9/dev. Clearly if there were substantive changes then it would be important to push the changes to the forest where they are most likely to get tested but it hardly seems worth it here. From what I can tell then Phil or others sync up jdk9/client regularly and that might be the most efficient way to get these changes into jdk9/client.
>>> 
>> The changes should go through client for the reasons I already gave.
> 
> IIUC these were the reasons you gave in a previous email on this thread:
> 
> "I would not push hotspot changes to client either. Also lots of files
> are being updated in client and doing it this way will minimise merges ..."
> 
> I don't find either very convincing.
> 
> 
>> No new permissions are needed but it will need a unique bug id.
>> 
> 
> Ok.
> 
> 
>> FWIW integrations are intended to be bi-weekly but holidays interfered this time.
>> 
> 
> Why does it take so long?
> 
> Paul.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 841 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20140616/a744c6b6/signature-0001.asc>

From anthony.petrov at oracle.com  Mon Jun 16 18:32:17 2014
From: anthony.petrov at oracle.com (Anthony Petrov)
Date: Mon, 16 Jun 2014 22:32:17 +0400
Subject: <AWT Dev> [9] Review Request: 8033367 [macosx] Appletviewer was
 broken in jdk8 b124
In-Reply-To: <555DBA9F-86C0-4BCA-A5CA-B19F3CE42828@oracle.com>
References: <0FFA30BF-BDC5-4B0C-8E8A-B8982A60EE97@oracle.com>
	<538DD4C5.7050401@oracle.com>
	<555DBA9F-86C0-4BCA-A5CA-B19F3CE42828@oracle.com>
Message-ID: <539F3831.4060307@oracle.com>

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 anthony.petrov at oracle.com  Mon Jun 16 18:43:06 2014
From: anthony.petrov at oracle.com (Anthony Petrov)
Date: Mon, 16 Jun 2014 22:43:06 +0400
Subject: <AWT Dev> [8u20] RFR: 8042440: awt_Plugin.h no longer needed
In-Reply-To: <9BAC6F0F-E54D-41E0-89DE-2D73C65CD35E@oracle.com>
References: <4FA85391-53F0-41B3-97D9-C6E32C933023@oracle.com>
	<9BAC6F0F-E54D-41E0-89DE-2D73C65CD35E@oracle.com>
Message-ID: <539F3ABA.9010703@oracle.com>

Looks fine to me. Approved.

--
best regards,
Anthony

On 6/14/2014 1:43 AM, David DeHaven wrote:
>
> In my haste I forgot to post to awt-dev...
>
> Can someone please review this backport to 8u? The differences are trivial from the 9 changes.
>
> -DrD-
>
>>
>> Please review the backport of JDK-8042440. The changes are identical to the JDK9 changes except for exactly one line:
>>
>> $ diff -Narup ~/Desktop/8042440-{8u,9}
>> @@ -143,7 +143,7 @@ diff --git a/src/solaris/native/sun/awt/
>> -
>> -
>> -#define REFLECT_VOID_FUNCTION(name, arglist, paramlist)                 \
>> --typedef name##_type arglist;                                            \
>> +-typedef void name##_type arglist;                                       \
>> -void name arglist                                                       \
>> -{                                                                       \
>> -    static name##_type *name##_ptr = NULL;                              \
>>
>> It seems someone added a void return type to the function being deleted, which resulted in the patch conflict, the end result is the same, all that code is deleted.
>>
>>
>> JBS Issue:
>> https://bugs.openjdk.java.net/browse/JDK-8042440
>>
>> JDK 9 review:
>> http://mail.openjdk.java.net/pipermail/awt-dev/2014-May/007671.html
>>
>> Existing JDK9 patch:
>> http://hg.openjdk.java.net/jdk9/client/jdk/rev/75206fa5a43e
>>
>> JDK 8u-dev webrev:
>> http://cr.openjdk.java.net/~ddehaven/8042440/8u-bp/
>>
>> -DrD-
>>
>

From alexandr.scherbatiy at oracle.com  Tue Jun 17 11:36:13 2014
From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy)
Date: Tue, 17 Jun 2014 15:36:13 +0400
Subject: <AWT Dev> [9] Review request for 8043869 [macosx] java -splash does
 not honor @2x hi dpi notation for retina support
Message-ID: <53A0282D.80709@oracle.com>


Hello,

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

   The scaleFactor field is added to the Splash struct.
   The SplahsScreen class scales the graphics and the size according to 
the scale factor.
   The native system tries to load high resolution splash image on HiDPI 
display.

Thanks,
Alexandr.


From petr.pchelko at oracle.com  Tue Jun 17 12:22:34 2014
From: petr.pchelko at oracle.com (Petr Pchelko)
Date: Tue, 17 Jun 2014 16:22:34 +0400
Subject: <AWT Dev> [9] Review request for 8043869 [macosx] java -splash
	does not honor @2x hi dpi notation for retina support
In-Reply-To: <53A0282D.80709@oracle.com>
References: <53A0282D.80709@oracle.com>
Message-ID: <F4D88430-7FBA-4D5F-8C63-A34E4AD63220@oracle.com>

Hello, Alexander.

CCed Kumar as I believe he's the owner of the launcher code.

1. In splashscreen_sys.m you autorelease the fileName. But I do not see where the autoreleasepool is set up.
Wouldn't it be better to set up an autoreleasepool in this method explicitly?

2. In java.c:1859 DoSplashSetFileJarName sets the name of the file which was used for a splash. It can be
retrieved via public API SplashScreen.getImageURL. Is it correct to always set the file_name disregards the real 
name we've used?

Thank you.
With best regards. Petr.

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

> 
> Hello,
> 
> Could you review the fix:
>  bug: https://bugs.openjdk.java.net/browse/JDK-8043869
>  webrev: http://cr.openjdk.java.net/~alexsch/8043869/webrev.00
> 
>  The scaleFactor field is added to the Splash struct.
>  The SplahsScreen class scales the graphics and the size according to the scale factor.
>  The native system tries to load high resolution splash image on HiDPI display.
> 
> Thanks,
> Alexandr.
> 


From petr.pchelko at oracle.com  Tue Jun 17 12:43:34 2014
From: petr.pchelko at oracle.com (Petr Pchelko)
Date: Tue, 17 Jun 2014 16:43:34 +0400
Subject: <AWT Dev> [9] Review Request: 8047061 [macosx] Crash when setting
	display mode
Message-ID: <016036DE-A555-4EED-8D15-3A1B920A8187@oracle.com>

Hello, AWT Team.

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

When we are searching through valid display modes we are storing them in an array. Before the fix we were passing NULL 
CFArrayCallbacks structure making an array of weak references.  (the CFArrayCallbacks is a structure of the function pointers 
which are called to retain and release elements of the array) So we were relying on the fact that Carbon also retains the pointers 
we are using internally. But sometimes it's not the case. The solution is simple - pass default array callbacks structure to create 
an array of strong references which can be passed around.

I've checked that no native memory leak is introduced with this change.

With best regards. Petr.

From anthony.petrov at oracle.com  Tue Jun 17 13:51:31 2014
From: anthony.petrov at oracle.com (Anthony Petrov)
Date: Tue, 17 Jun 2014 17:51:31 +0400
Subject: <AWT Dev> [9] Review Request: 8047061 [macosx] Crash when
 setting display mode
In-Reply-To: <016036DE-A555-4EED-8D15-3A1B920A8187@oracle.com>
References: <016036DE-A555-4EED-8D15-3A1B920A8187@oracle.com>
Message-ID: <53A047E3.9050700@oracle.com>

Hi Petr,

The fix looks fine to me.

--
best regards,
Anthony

On 6/17/2014 4:43 PM, Petr Pchelko wrote:
> Hello, AWT Team.
>
> Please review the fix for the issue:
> https://bugs.openjdk.java.net/browse/JDK-8047061
> The fix is available at:
> http://cr.openjdk.java.net/~pchelko/9/8047061/webrev/
>
> When we are searching through valid display modes we are storing them in an array. Before the fix we were passing NULL
> CFArrayCallbacks structure making an array of weak references.  (the CFArrayCallbacks is a structure of the function pointers
> which are called to retain and release elements of the array) So we were relying on the fact that Carbon also retains the pointers
> we are using internally. But sometimes it's not the case. The solution is simple - pass default array callbacks structure to create
> an array of strong references which can be passed around.
>
> I've checked that no native memory leak is introduced with this change.
>
> With best regards. Petr.
>

From alexandr.scherbatiy at oracle.com  Tue Jun 17 14:16:25 2014
From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy)
Date: Tue, 17 Jun 2014 18:16:25 +0400
Subject: <AWT Dev> [9] Review request for 8043869 [macosx] java -splash
 does not honor @2x hi dpi notation for retina support
In-Reply-To: <F4D88430-7FBA-4D5F-8C63-A34E4AD63220@oracle.com>
References: <53A0282D.80709@oracle.com>
	<F4D88430-7FBA-4D5F-8C63-A34E4AD63220@oracle.com>
Message-ID: <53A04DB9.2060509@oracle.com>


Hello,

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


On 6/17/2014 4:22 PM, Petr Pchelko wrote:
> Hello, Alexander.
>
> CCed Kumar as I believe he's the owner of the launcher code.
>
> 1. In splashscreen_sys.m you autorelease the fileName. But I do not see where the autoreleasepool is set up.
> Wouldn't it be better to set up an autoreleasepool in this method explicitly?
      NSAutoreleasePool is added.
> 2. In java.c:1859 DoSplashSetFileJarName sets the name of the file which was used for a splash. It can be
> retrieved via public API SplashScreen.getImageURL. Is it correct to always set the file_name disregards the real
> name we've used?

     Yes. The original splash screen image name and size are provided 
for the developer even the high resolution splash screen is shown.

     Thanks,
     Alexandr.
> Thank you.
> With best regards. Petr.
>
> On 17 ???? 2014 ?., at 15:36, Alexander Scherbatiy <alexandr.scherbatiy at oracle.com> wrote:
>
>> Hello,
>>
>> Could you review the fix:
>>   bug: https://bugs.openjdk.java.net/browse/JDK-8043869
>>   webrev: http://cr.openjdk.java.net/~alexsch/8043869/webrev.00
>>
>>   The scaleFactor field is added to the Splash struct.
>>   The SplahsScreen class scales the graphics and the size according to the scale factor.
>>   The native system tries to load high resolution splash image on HiDPI display.
>>
>> Thanks,
>> Alexandr.
>>


From petr.pchelko at oracle.com  Tue Jun 17 14:20:50 2014
From: petr.pchelko at oracle.com (Petr Pchelko)
Date: Tue, 17 Jun 2014 18:20:50 +0400
Subject: <AWT Dev> [9] Review request for 8043869 [macosx] java -splash
	does not honor @2x hi dpi notation for retina support
In-Reply-To: <53A04DB9.2060509@oracle.com>
References: <53A0282D.80709@oracle.com>
	<F4D88430-7FBA-4D5F-8C63-A34E4AD63220@oracle.com>
	<53A04DB9.2060509@oracle.com>
Message-ID: <D650DAE1-852C-4B7F-B7B2-F03B05F3F6A8@oracle.com>

Hello, Alexander.

>> 2. In java.c:1859 DoSplashSetFileJarName sets the name of the file which was used for a splash. It can be
>> retrieved via public API SplashScreen.getImageURL. Is it correct to always set the file_name disregards the real
>> name we've used?
> 
>    Yes. The original splash screen image name and size are provided for the developer even the high resolution splash screen is shown.
Thank you for the clarification.

The updated version looks fine to me.

With best regards. Petr.

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

> 
> Hello,
> 
> Could you review the updated fix:
>  http://cr.openjdk.java.net/~alexsch/8043869/webrev.01/
> 
> 
> On 6/17/2014 4:22 PM, Petr Pchelko wrote:
>> Hello, Alexander.
>> 
>> CCed Kumar as I believe he's the owner of the launcher code.
>> 
>> 1. In splashscreen_sys.m you autorelease the fileName. But I do not see where the autoreleasepool is set up.
>> Wouldn't it be better to set up an autoreleasepool in this method explicitly?
>     NSAutoreleasePool is added.
>> 2. In java.c:1859 DoSplashSetFileJarName sets the name of the file which was used for a splash. It can be
>> retrieved via public API SplashScreen.getImageURL. Is it correct to always set the file_name disregards the real
>> name we've used?
> 
>    Yes. The original splash screen image name and size are provided for the developer even the high resolution splash screen is shown.
> 
>    Thanks,
>    Alexandr.
>> Thank you.
>> With best regards. Petr.
>> 
>> On 17 ???? 2014 ?., at 15:36, Alexander Scherbatiy <alexandr.scherbatiy at oracle.com> wrote:
>> 
>>> Hello,
>>> 
>>> Could you review the fix:
>>>  bug: https://bugs.openjdk.java.net/browse/JDK-8043869
>>>  webrev: http://cr.openjdk.java.net/~alexsch/8043869/webrev.00
>>> 
>>>  The scaleFactor field is added to the Splash struct.
>>>  The SplahsScreen class scales the graphics and the size according to the scale factor.
>>>  The native system tries to load high resolution splash image on HiDPI display.
>>> 
>>> Thanks,
>>> Alexandr.
>>> 
> 


From anthony.petrov at oracle.com  Tue Jun 17 14:45:45 2014
From: anthony.petrov at oracle.com (Anthony Petrov)
Date: Tue, 17 Jun 2014 18:45:45 +0400
Subject: <AWT Dev> [9] Review request for 8043869 [macosx] java -splash
 does not honor @2x hi dpi notation for retina support
In-Reply-To: <D650DAE1-852C-4B7F-B7B2-F03B05F3F6A8@oracle.com>
References: <53A0282D.80709@oracle.com>	<F4D88430-7FBA-4D5F-8C63-A34E4AD63220@oracle.com>	<53A04DB9.2060509@oracle.com>
	<D650DAE1-852C-4B7F-B7B2-F03B05F3F6A8@oracle.com>
Message-ID: <53A05499.4000109@oracle.com>

Hi Alexander,

[ I'm also adding Neil who's taking over the launcher code ]

1. There's a few code formatting issues that should be fixed. For instance:
src/share/bin/java.c
> 1846             if(scaled_splash_name){
> 1853         if(scaled_splash_name){

src/windows/native/sun/awt/splashscreen/splashscreen_sys.c
>  571     *scaleFactor=1;

In all the above lines required spaces are missing. I believe there's a 
number of other occurrences of the same issue in your patch. Please 
check it carefully and fix the formatting on all lines.

2. Webrev shows 236 changed lines for java_awt_SplashScreen.c. I suspect 
you've changed the EOL characters because you've edited your code on MS 
Windows. Please configure your editor to use LF characters for line ends 
and revert the unnecessary changes (note that jcheck won't let you push 
CR-LF line endings anyway).

3. splashscreen_sys.m
>  135     if (1 < screenScaleFactor) {

For consistency and clarity, I'd suggest to rewrite the condition as

	if (screenScaleFactor > 1) {

--
best regards,
Anthony

On 6/17/2014 6:20 PM, Petr Pchelko wrote:
> Hello, Alexander.
>
>>> 2. In java.c:1859 DoSplashSetFileJarName sets the name of the file which was used for a splash. It can be
>>> retrieved via public API SplashScreen.getImageURL. Is it correct to always set the file_name disregards the real
>>> name we've used?
>>
>>     Yes. The original splash screen image name and size are provided for the developer even the high resolution splash screen is shown.
> Thank you for the clarification.
>
> The updated version looks fine to me.
>
> With best regards. Petr.
>
> On 17 ???? 2014 ?., at 18:16, Alexander Scherbatiy <alexandr.scherbatiy at oracle.com> wrote:
>
>>
>> Hello,
>>
>> Could you review the updated fix:
>>   http://cr.openjdk.java.net/~alexsch/8043869/webrev.01/
>>
>>
>> On 6/17/2014 4:22 PM, Petr Pchelko wrote:
>>> Hello, Alexander.
>>>
>>> CCed Kumar as I believe he's the owner of the launcher code.
>>>
>>> 1. In splashscreen_sys.m you autorelease the fileName. But I do not see where the autoreleasepool is set up.
>>> Wouldn't it be better to set up an autoreleasepool in this method explicitly?
>>      NSAutoreleasePool is added.
>>> 2. In java.c:1859 DoSplashSetFileJarName sets the name of the file which was used for a splash. It can be
>>> retrieved via public API SplashScreen.getImageURL. Is it correct to always set the file_name disregards the real
>>> name we've used?
>>
>>     Yes. The original splash screen image name and size are provided for the developer even the high resolution splash screen is shown.
>>
>>     Thanks,
>>     Alexandr.
>>> Thank you.
>>> With best regards. Petr.
>>>
>>> On 17 ???? 2014 ?., at 15:36, Alexander Scherbatiy <alexandr.scherbatiy at oracle.com> wrote:
>>>
>>>> Hello,
>>>>
>>>> Could you review the fix:
>>>>   bug: https://bugs.openjdk.java.net/browse/JDK-8043869
>>>>   webrev: http://cr.openjdk.java.net/~alexsch/8043869/webrev.00
>>>>
>>>>   The scaleFactor field is added to the Splash struct.
>>>>   The SplahsScreen class scales the graphics and the size according to the scale factor.
>>>>   The native system tries to load high resolution splash image on HiDPI display.
>>>>
>>>> Thanks,
>>>> Alexandr.
>>>>
>>
>

From kumar.x.srinivasan at oracle.com  Tue Jun 17 16:21:18 2014
From: kumar.x.srinivasan at oracle.com (Kumar Srinivasan)
Date: Tue, 17 Jun 2014 09:21:18 -0700
Subject: <AWT Dev> [9] Review request for 8043869 [macosx] java -splash
 does not honor @2x hi dpi notation for retina support
In-Reply-To: <53A05499.4000109@oracle.com>
References: <53A0282D.80709@oracle.com>	<F4D88430-7FBA-4D5F-8C63-A34E4AD63220@oracle.com>	<53A04DB9.2060509@oracle.com>
	<D650DAE1-852C-4B7F-B7B2-F03B05F3F6A8@oracle.com>
	<53A05499.4000109@oracle.com>
Message-ID: <53A06AFE.5070304@oracle.com>

Hello,

As Anthony already commented, there are some formatting issues 
throughout, please
retain the existing convention and formatting.

src/share/bin/java.c
at 1822, if you add
if (file_name == NULL){
     return;
}
and removing the else, at the bottom we can reduce the indent of the 
exist if block.

make/mapfiles/libsplashscreen/mapfile-vers
+1, good to note this, always trips people up.


Otherwise looks good.

Kumar




On 6/17/2014 7:45 AM, Anthony Petrov wrote:
> Hi Alexander,
>
> [ I'm also adding Neil who's taking over the launcher code ]
>
> 1. There's a few code formatting issues that should be fixed. For 
> instance:
> src/share/bin/java.c
>> 1846             if(scaled_splash_name){
>> 1853         if(scaled_splash_name){
>
> src/windows/native/sun/awt/splashscreen/splashscreen_sys.c
>>  571     *scaleFactor=1;
>
> In all the above lines required spaces are missing. I believe there's 
> a number of other occurrences of the same issue in your patch. Please 
> check it carefully and fix the formatting on all lines.
>
> 2. Webrev shows 236 changed lines for java_awt_SplashScreen.c. I 
> suspect you've changed the EOL characters because you've edited your 
> code on MS Windows. Please configure your editor to use LF characters 
> for line ends and revert the unnecessary changes (note that jcheck 
> won't let you push CR-LF line endings anyway).
>
> 3. splashscreen_sys.m
>>  135     if (1 < screenScaleFactor) {
>
> For consistency and clarity, I'd suggest to rewrite the condition as
>
>     if (screenScaleFactor > 1) {
>
> -- 
> best regards,
> Anthony
>
> On 6/17/2014 6:20 PM, Petr Pchelko wrote:
>> Hello, Alexander.
>>
>>>> 2. In java.c:1859 DoSplashSetFileJarName sets the name of the file 
>>>> which was used for a splash. It can be
>>>> retrieved via public API SplashScreen.getImageURL. Is it correct to 
>>>> always set the file_name disregards the real
>>>> name we've used?
>>>
>>>     Yes. The original splash screen image name and size are provided 
>>> for the developer even the high resolution splash screen is shown.
>> Thank you for the clarification.
>>
>> The updated version looks fine to me.
>>
>> With best regards. Petr.
>>
>> On 17 ???? 2014 ?., at 18:16, Alexander Scherbatiy 
>> <alexandr.scherbatiy at oracle.com> wrote:
>>
>>>
>>> Hello,
>>>
>>> Could you review the updated fix:
>>>   http://cr.openjdk.java.net/~alexsch/8043869/webrev.01/
>>>
>>>
>>> On 6/17/2014 4:22 PM, Petr Pchelko wrote:
>>>> Hello, Alexander.
>>>>
>>>> CCed Kumar as I believe he's the owner of the launcher code.
>>>>
>>>> 1. In splashscreen_sys.m you autorelease the fileName. But I do not 
>>>> see where the autoreleasepool is set up.
>>>> Wouldn't it be better to set up an autoreleasepool in this method 
>>>> explicitly?
>>>      NSAutoreleasePool is added.
>>>> 2. In java.c:1859 DoSplashSetFileJarName sets the name of the file 
>>>> which was used for a splash. It can be
>>>> retrieved via public API SplashScreen.getImageURL. Is it correct to 
>>>> always set the file_name disregards the real
>>>> name we've used?
>>>
>>>     Yes. The original splash screen image name and size are provided 
>>> for the developer even the high resolution splash screen is shown.
>>>
>>>     Thanks,
>>>     Alexandr.
>>>> Thank you.
>>>> With best regards. Petr.
>>>>
>>>> On 17 ???? 2014 ?., at 15:36, Alexander Scherbatiy 
>>>> <alexandr.scherbatiy at oracle.com> wrote:
>>>>
>>>>> Hello,
>>>>>
>>>>> Could you review the fix:
>>>>>   bug: https://bugs.openjdk.java.net/browse/JDK-8043869
>>>>>   webrev: http://cr.openjdk.java.net/~alexsch/8043869/webrev.00
>>>>>
>>>>>   The scaleFactor field is added to the Splash struct.
>>>>>   The SplahsScreen class scales the graphics and the size 
>>>>> according to the scale factor.
>>>>>   The native system tries to load high resolution splash image on 
>>>>> HiDPI display.
>>>>>
>>>>> Thanks,
>>>>> Alexandr.
>>>>>
>>>
>>


From alexandr.scherbatiy at oracle.com  Wed Jun 18 09:02:29 2014
From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy)
Date: Wed, 18 Jun 2014 13:02:29 +0400
Subject: <AWT Dev> [9] Review Request: 8047061 [macosx] Crash when
 setting display mode
In-Reply-To: <016036DE-A555-4EED-8D15-3A1B920A8187@oracle.com>
References: <016036DE-A555-4EED-8D15-3A1B920A8187@oracle.com>
Message-ID: <53A155A5.9050505@oracle.com>


   The fix looks good to me.

   Thanks,
   Alexandr.

On 6/17/2014 4:43 PM, Petr Pchelko wrote:
> Hello, AWT Team.
>
> Please review the fix for the issue:
> https://bugs.openjdk.java.net/browse/JDK-8047061
> The fix is available at:
> http://cr.openjdk.java.net/~pchelko/9/8047061/webrev/
>
> When we are searching through valid display modes we are storing them in an array. Before the fix we were passing NULL
> CFArrayCallbacks structure making an array of weak references.  (the CFArrayCallbacks is a structure of the function pointers
> which are called to retain and release elements of the array) So we were relying on the fact that Carbon also retains the pointers
> we are using internally. But sometimes it's not the case. The solution is simple - pass default array callbacks structure to create
> an array of strong references which can be passed around.
>
> I've checked that no native memory leak is introduced with this change.
>
> With best regards. Petr.


From alexey.menkov at oracle.com  Thu Jun  5 16:02:25 2014
From: alexey.menkov at oracle.com (alexey menkov)
Date: Thu, 05 Jun 2014 20:02:25 +0400
Subject: <AWT Dev> APPROVED - Re: [9] Review Request: 8039901
 jdk/src/share/classes/com/sun/media/sound/services/<platform> appear not to
 be used
In-Reply-To: <538F28E0.8090804@oracle.com>
References: <538F28E0.8090804@oracle.com>
Message-ID: <53909491.2080705@oracle.com>

looks good.

regards
Alex

On 04.06.2014 18:10, Sergey Bylokhov wrote:
> Hello.
> Please review the fix for jdk 9.
> The old sound configuration files were removed, its were used in the old
> (beatnik) sound engine in old build system.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8039901
> Webrev can be found at: http://cr.openjdk.java.net/~serb/8039901/webrev.00
>

From alexander.v.stepanov at oracle.com  Wed Jun 18 12:35:53 2014
From: alexander.v.stepanov at oracle.com (alexander stepanov)
Date: Wed, 18 Jun 2014 16:35:53 +0400
Subject: <AWT Dev> [9] Review Request for 8044429: move awt automated tests
 for AWT_Modality to OpenJDK repository
Message-ID: <53A187A9.7060400@oracle.com>

Hello,

Could you please review the webrev:
http://cr.openjdk.java.net/~avstepan/8044429/

This is the 1st portion of functional AWT modality tests prepared for 
migration to OpenJDK repository in accordance with
https://bugs.openjdk.java.net/browse/JDK-8044429

Some helper classes were moved too.

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

At the moment the tests are failing on Mac OS X due to
https://bugs.openjdk.java.net/browse/JDK-7125054
https://bugs.openjdk.java.net/browse/JDK-8047179

Thanks,
Alexander

From alexandr.scherbatiy at oracle.com  Wed Jun 18 13:03:40 2014
From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy)
Date: Wed, 18 Jun 2014 17:03:40 +0400
Subject: <AWT Dev> [9] Review request for 8043869 [macosx] java -splash
 does not honor @2x hi dpi notation for retina support
In-Reply-To: <53A06AFE.5070304@oracle.com>
References: <53A0282D.80709@oracle.com>	<F4D88430-7FBA-4D5F-8C63-A34E4AD63220@oracle.com>	<53A04DB9.2060509@oracle.com>
	<D650DAE1-852C-4B7F-B7B2-F03B05F3F6A8@oracle.com>
	<53A05499.4000109@oracle.com> <53A06AFE.5070304@oracle.com>
Message-ID: <53A18E2C.3090005@oracle.com>


  Hello,

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

   - formatting and CR-LF line endings are fixed
   - the condition if (1 < screenScaleFactor) is rewritten in 
splashscreen_sys.m file
   - file_name == NULL chec is added in the java.c
   - [NSScreen mainScreen] is changed to SplashNSScreen() in the 
SplashGetScaledImageName() from splashscreen_sys.m file

Thanks,
Alexandr.

On 6/17/2014 8:21 PM, Kumar Srinivasan wrote:
> Hello,
>
> As Anthony already commented, there are some formatting issues 
> throughout, please
> retain the existing convention and formatting.
>
> src/share/bin/java.c
> at 1822, if you add
> if (file_name == NULL){
>     return;
> }
> and removing the else, at the bottom we can reduce the indent of the 
> exist if block.
>
> make/mapfiles/libsplashscreen/mapfile-vers
> +1, good to note this, always trips people up.
>
>
> Otherwise looks good.
>
> Kumar
>
>
>
>
> On 6/17/2014 7:45 AM, Anthony Petrov wrote:
>> Hi Alexander,
>>
>> [ I'm also adding Neil who's taking over the launcher code ]
>>
>> 1. There's a few code formatting issues that should be fixed. For 
>> instance:
>> src/share/bin/java.c
>>> 1846             if(scaled_splash_name){
>>> 1853         if(scaled_splash_name){
>>
>> src/windows/native/sun/awt/splashscreen/splashscreen_sys.c
>>>  571     *scaleFactor=1;
>>
>> In all the above lines required spaces are missing. I believe there's 
>> a number of other occurrences of the same issue in your patch. Please 
>> check it carefully and fix the formatting on all lines.
>>
>> 2. Webrev shows 236 changed lines for java_awt_SplashScreen.c. I 
>> suspect you've changed the EOL characters because you've edited your 
>> code on MS Windows. Please configure your editor to use LF characters 
>> for line ends and revert the unnecessary changes (note that jcheck 
>> won't let you push CR-LF line endings anyway).
>>
>> 3. splashscreen_sys.m
>>>  135     if (1 < screenScaleFactor) {
>>
>> For consistency and clarity, I'd suggest to rewrite the condition as
>>
>>     if (screenScaleFactor > 1) {
>>
>> -- 
>> best regards,
>> Anthony
>>
>> On 6/17/2014 6:20 PM, Petr Pchelko wrote:
>>> Hello, Alexander.
>>>
>>>>> 2. In java.c:1859 DoSplashSetFileJarName sets the name of the file 
>>>>> which was used for a splash. It can be
>>>>> retrieved via public API SplashScreen.getImageURL. Is it correct 
>>>>> to always set the file_name disregards the real
>>>>> name we've used?
>>>>
>>>>     Yes. The original splash screen image name and size are 
>>>> provided for the developer even the high resolution splash screen 
>>>> is shown.
>>> Thank you for the clarification.
>>>
>>> The updated version looks fine to me.
>>>
>>> With best regards. Petr.
>>>
>>> On 17 ???? 2014 ?., at 18:16, Alexander Scherbatiy 
>>> <alexandr.scherbatiy at oracle.com> wrote:
>>>
>>>>
>>>> Hello,
>>>>
>>>> Could you review the updated fix:
>>>>   http://cr.openjdk.java.net/~alexsch/8043869/webrev.01/
>>>>
>>>>
>>>> On 6/17/2014 4:22 PM, Petr Pchelko wrote:
>>>>> Hello, Alexander.
>>>>>
>>>>> CCed Kumar as I believe he's the owner of the launcher code.
>>>>>
>>>>> 1. In splashscreen_sys.m you autorelease the fileName. But I do 
>>>>> not see where the autoreleasepool is set up.
>>>>> Wouldn't it be better to set up an autoreleasepool in this method 
>>>>> explicitly?
>>>>      NSAutoreleasePool is added.
>>>>> 2. In java.c:1859 DoSplashSetFileJarName sets the name of the file 
>>>>> which was used for a splash. It can be
>>>>> retrieved via public API SplashScreen.getImageURL. Is it correct 
>>>>> to always set the file_name disregards the real
>>>>> name we've used?
>>>>
>>>>     Yes. The original splash screen image name and size are 
>>>> provided for the developer even the high resolution splash screen 
>>>> is shown.
>>>>
>>>>     Thanks,
>>>>     Alexandr.
>>>>> Thank you.
>>>>> With best regards. Petr.
>>>>>
>>>>> On 17 ???? 2014 ?., at 15:36, Alexander Scherbatiy 
>>>>> <alexandr.scherbatiy at oracle.com> wrote:
>>>>>
>>>>>> Hello,
>>>>>>
>>>>>> Could you review the fix:
>>>>>>   bug: https://bugs.openjdk.java.net/browse/JDK-8043869
>>>>>>   webrev: http://cr.openjdk.java.net/~alexsch/8043869/webrev.00
>>>>>>
>>>>>>   The scaleFactor field is added to the Splash struct.
>>>>>>   The SplahsScreen class scales the graphics and the size 
>>>>>> according to the scale factor.
>>>>>>   The native system tries to load high resolution splash image on 
>>>>>> HiDPI display.
>>>>>>
>>>>>> Thanks,
>>>>>> Alexandr.
>>>>>>
>>>>
>>>
>


From petr.pchelko at oracle.com  Wed Jun 18 13:57:44 2014
From: petr.pchelko at oracle.com (Petr Pchelko)
Date: Wed, 18 Jun 2014 17:57:44 +0400
Subject: <AWT Dev> [9] Review Request for 8044429: move awt automated
	tests for AWT_Modality to OpenJDK repository
In-Reply-To: <53A187A9.7060400@oracle.com>
References: <53A187A9.7060400@oracle.com>
Message-ID: <AFEDAB31-1357-4933-9979-7B58674042ED@oracle.com>

Hello, Alexander.

In ExcludeDialogTest and ExcludeFrameTest you are emulating key type manually while ExtendedRobot can do that.
Same in TestWindow, TestFrame and TestDialog : 206 - You are manually emulating the click while ExtendedRobot provides this feature.
typeTab method duplicates functionality in ExtendedRobot.

With best regards. Petr.

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

> Hello,
> 
> Could you please review the webrev:
> http://cr.openjdk.java.net/~avstepan/8044429/
> 
> This is the 1st portion of functional AWT modality tests prepared for migration to OpenJDK repository in accordance with
> https://bugs.openjdk.java.net/browse/JDK-8044429
> 
> Some helper classes were moved too.
> 
> The tests were checked on Ubuntu 14.04, Solaris 11, and Windows 7.
> 
> At the moment the tests are failing on Mac OS X due to
> https://bugs.openjdk.java.net/browse/JDK-7125054
> https://bugs.openjdk.java.net/browse/JDK-8047179
> 
> Thanks,
> Alexander


From kumar.x.srinivasan at oracle.com  Wed Jun 18 14:10:18 2014
From: kumar.x.srinivasan at oracle.com (Kumar Srinivasan)
Date: Wed, 18 Jun 2014 07:10:18 -0700
Subject: <AWT Dev> [9] Review request for 8043869 [macosx] java -splash
 does not honor @2x hi dpi notation for retina support
In-Reply-To: <53A18E2C.3090005@oracle.com>
References: <53A0282D.80709@oracle.com>	<F4D88430-7FBA-4D5F-8C63-A34E4AD63220@oracle.com>	<53A04DB9.2060509@oracle.com>
	<D650DAE1-852C-4B7F-B7B2-F03B05F3F6A8@oracle.com>
	<53A05499.4000109@oracle.com> <53A06AFE.5070304@oracle.com>
	<53A18E2C.3090005@oracle.com>
Message-ID: <53A19DCA.7090307@oracle.com>

Hi Alexander,

Thanks for making that change in java.c

splashscreen_stubs.c:

<Sorry I should have caught this earlier>
I would change the 0 to NULL as as you have already done on line 89...

64     INVOKE(SplashLoadMemory,0)(pdata, size);
68     INVOKE(SplashLoadFile,0)(filename);

SplashScreen.java:

Is it possible to get a divide by zero here ? I realize you are 
intializing to 1 elsewhere
what happens  if you "read" a zero ? Ex:  What happens if you call 
generateImage(0) in the test ?

  248             float scale = _getScaleFactor(splashPtr);
  249             Rectangle bounds = _getBounds(splashPtr);
  250             if (scale != 1) {
  251                 bounds.setSize((int) (bounds.getWidth() / scale),
  252                         (int) (bounds.getWidth() / scale));
  253             }
  254             return bounds;


Should we have some more validations of the input data ? since these 
items are
being read from a user generated image file.

One last thing, I am assuming you have run all the launcher regressions 
including the SplashScreen tests in
the jdk/test/closed ?

Kumar



On 6/18/2014 6:03 AM, Alexander Scherbatiy wrote:
>
>  Hello,
>
>  Could you review the updated fix:
>     http://cr.openjdk.java.net/~alexsch/8043869/webrev.02
>
>   - formatting and CR-LF line endings are fixed
>   - the condition if (1 < screenScaleFactor) is rewritten in 
> splashscreen_sys.m file
>   - file_name == NULL chec is added in the java.c
>   - [NSScreen mainScreen] is changed to SplashNSScreen() in the 
> SplashGetScaledImageName() from splashscreen_sys.m file
>
> Thanks,
> Alexandr.
>
> On 6/17/2014 8:21 PM, Kumar Srinivasan wrote:
>> Hello,
>>
>> As Anthony already commented, there are some formatting issues 
>> throughout, please
>> retain the existing convention and formatting.
>>
>> src/share/bin/java.c
>> at 1822, if you add
>> if (file_name == NULL){
>>     return;
>> }
>> and removing the else, at the bottom we can reduce the indent of the 
>> exist if block.
>>
>> make/mapfiles/libsplashscreen/mapfile-vers
>> +1, good to note this, always trips people up.
>>
>>
>> Otherwise looks good.
>>
>> Kumar
>>
>>
>>
>>
>> On 6/17/2014 7:45 AM, Anthony Petrov wrote:
>>> Hi Alexander,
>>>
>>> [ I'm also adding Neil who's taking over the launcher code ]
>>>
>>> 1. There's a few code formatting issues that should be fixed. For 
>>> instance:
>>> src/share/bin/java.c
>>>> 1846 if(scaled_splash_name){
>>>> 1853         if(scaled_splash_name){
>>>
>>> src/windows/native/sun/awt/splashscreen/splashscreen_sys.c
>>>>  571     *scaleFactor=1;
>>>
>>> In all the above lines required spaces are missing. I believe 
>>> there's a number of other occurrences of the same issue in your 
>>> patch. Please check it carefully and fix the formatting on all lines.
>>>
>>> 2. Webrev shows 236 changed lines for java_awt_SplashScreen.c. I 
>>> suspect you've changed the EOL characters because you've edited your 
>>> code on MS Windows. Please configure your editor to use LF 
>>> characters for line ends and revert the unnecessary changes (note 
>>> that jcheck won't let you push CR-LF line endings anyway).
>>>
>>> 3. splashscreen_sys.m
>>>>  135     if (1 < screenScaleFactor) {
>>>
>>> For consistency and clarity, I'd suggest to rewrite the condition as
>>>
>>>     if (screenScaleFactor > 1) {
>>>
>>> -- 
>>> best regards,
>>> Anthony
>>>
>>> On 6/17/2014 6:20 PM, Petr Pchelko wrote:
>>>> Hello, Alexander.
>>>>
>>>>>> 2. In java.c:1859 DoSplashSetFileJarName sets the name of the 
>>>>>> file which was used for a splash. It can be
>>>>>> retrieved via public API SplashScreen.getImageURL. Is it correct 
>>>>>> to always set the file_name disregards the real
>>>>>> name we've used?
>>>>>
>>>>>     Yes. The original splash screen image name and size are 
>>>>> provided for the developer even the high resolution splash screen 
>>>>> is shown.
>>>> Thank you for the clarification.
>>>>
>>>> The updated version looks fine to me.
>>>>
>>>> With best regards. Petr.
>>>>
>>>> On 17 ???? 2014 ?., at 18:16, Alexander Scherbatiy 
>>>> <alexandr.scherbatiy at oracle.com> wrote:
>>>>
>>>>>
>>>>> Hello,
>>>>>
>>>>> Could you review the updated fix:
>>>>>   http://cr.openjdk.java.net/~alexsch/8043869/webrev.01/
>>>>>
>>>>>
>>>>> On 6/17/2014 4:22 PM, Petr Pchelko wrote:
>>>>>> Hello, Alexander.
>>>>>>
>>>>>> CCed Kumar as I believe he's the owner of the launcher code.
>>>>>>
>>>>>> 1. In splashscreen_sys.m you autorelease the fileName. But I do 
>>>>>> not see where the autoreleasepool is set up.
>>>>>> Wouldn't it be better to set up an autoreleasepool in this method 
>>>>>> explicitly?
>>>>>      NSAutoreleasePool is added.
>>>>>> 2. In java.c:1859 DoSplashSetFileJarName sets the name of the 
>>>>>> file which was used for a splash. It can be
>>>>>> retrieved via public API SplashScreen.getImageURL. Is it correct 
>>>>>> to always set the file_name disregards the real
>>>>>> name we've used?
>>>>>
>>>>>     Yes. The original splash screen image name and size are 
>>>>> provided for the developer even the high resolution splash screen 
>>>>> is shown.
>>>>>
>>>>>     Thanks,
>>>>>     Alexandr.
>>>>>> Thank you.
>>>>>> With best regards. Petr.
>>>>>>
>>>>>> On 17 ???? 2014 ?., at 15:36, Alexander Scherbatiy 
>>>>>> <alexandr.scherbatiy at oracle.com> wrote:
>>>>>>
>>>>>>> Hello,
>>>>>>>
>>>>>>> Could you review the fix:
>>>>>>>   bug: https://bugs.openjdk.java.net/browse/JDK-8043869
>>>>>>>   webrev: http://cr.openjdk.java.net/~alexsch/8043869/webrev.00
>>>>>>>
>>>>>>>   The scaleFactor field is added to the Splash struct.
>>>>>>>   The SplahsScreen class scales the graphics and the size 
>>>>>>> according to the scale factor.
>>>>>>>   The native system tries to load high resolution splash image 
>>>>>>> on HiDPI display.
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Alexandr.
>>>>>>>
>>>>>
>>>>
>>
>


From anthony.petrov at oracle.com  Wed Jun 18 15:07:16 2014
From: anthony.petrov at oracle.com (Anthony Petrov)
Date: Wed, 18 Jun 2014 19:07:16 +0400
Subject: <AWT Dev> [9] Review request for 8043869 [macosx] java -splash
 does not honor @2x hi dpi notation for retina support
In-Reply-To: <53A18E2C.3090005@oracle.com>
References: <53A0282D.80709@oracle.com>	<F4D88430-7FBA-4D5F-8C63-A34E4AD63220@oracle.com>	<53A04DB9.2060509@oracle.com>
	<D650DAE1-852C-4B7F-B7B2-F03B05F3F6A8@oracle.com>
	<53A05499.4000109@oracle.com> <53A06AFE.5070304@oracle.com>
	<53A18E2C.3090005@oracle.com>
Message-ID: <53A1AB24.1080102@oracle.com>

Hi Alexander,

The fix looks good to me overall. One question though, regarding the 
file name-related logic in splashscreen_sys.m:

>  136         NSString *fileName = [NSString stringWithUTF8String: file];
>  137         NSUInteger length = [fileName length];
>  138         NSRange range = [fileName rangeOfString: @"."
>  139                                         options:NSBackwardsSearch];
>  140         int index = range.location;
>  141
>  142         if (index != NSNotFound && index != 0 && index != length-1) {
>  143             NSString *fileName2x = [fileName substringToIndex: index];
>  144             fileName2x = [fileName2x stringByAppendingString: @"@2x"];
>  145             fileName2x = [fileName2x stringByAppendingString:
>  146                           [fileName substringFromIndex: index]];
>  147
>  148             if (jar || [[NSFileManager defaultManager]
>  149                           fileExistsAtPath: fileName2x]){

Does this code work well if the image file name doesn't have an 
extension? There was a related issue in FX and it was fixed with the 
following changeset:
http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/d202ef8951c9
Please check if your code is ready to handle similar situations.

--
best regards,
Anthony

On 6/18/2014 5:03 PM, Alexander Scherbatiy wrote:
>
>   Hello,
>
>   Could you review the updated fix:
>      http://cr.openjdk.java.net/~alexsch/8043869/webrev.02
>
>    - formatting and CR-LF line endings are fixed
>    - the condition if (1 < screenScaleFactor) is rewritten in
> splashscreen_sys.m file
>    - file_name == NULL chec is added in the java.c
>    - [NSScreen mainScreen] is changed to SplashNSScreen() in the
> SplashGetScaledImageName() from splashscreen_sys.m file
>
> Thanks,
> Alexandr.
>
> On 6/17/2014 8:21 PM, Kumar Srinivasan wrote:
>> Hello,
>>
>> As Anthony already commented, there are some formatting issues
>> throughout, please
>> retain the existing convention and formatting.
>>
>> src/share/bin/java.c
>> at 1822, if you add
>> if (file_name == NULL){
>>     return;
>> }
>> and removing the else, at the bottom we can reduce the indent of the
>> exist if block.
>>
>> make/mapfiles/libsplashscreen/mapfile-vers
>> +1, good to note this, always trips people up.
>>
>>
>> Otherwise looks good.
>>
>> Kumar
>>
>>
>>
>>
>> On 6/17/2014 7:45 AM, Anthony Petrov wrote:
>>> Hi Alexander,
>>>
>>> [ I'm also adding Neil who's taking over the launcher code ]
>>>
>>> 1. There's a few code formatting issues that should be fixed. For
>>> instance:
>>> src/share/bin/java.c
>>>> 1846             if(scaled_splash_name){
>>>> 1853         if(scaled_splash_name){
>>>
>>> src/windows/native/sun/awt/splashscreen/splashscreen_sys.c
>>>>  571     *scaleFactor=1;
>>>
>>> In all the above lines required spaces are missing. I believe there's
>>> a number of other occurrences of the same issue in your patch. Please
>>> check it carefully and fix the formatting on all lines.
>>>
>>> 2. Webrev shows 236 changed lines for java_awt_SplashScreen.c. I
>>> suspect you've changed the EOL characters because you've edited your
>>> code on MS Windows. Please configure your editor to use LF characters
>>> for line ends and revert the unnecessary changes (note that jcheck
>>> won't let you push CR-LF line endings anyway).
>>>
>>> 3. splashscreen_sys.m
>>>>  135     if (1 < screenScaleFactor) {
>>>
>>> For consistency and clarity, I'd suggest to rewrite the condition as
>>>
>>>     if (screenScaleFactor > 1) {
>>>
>>> --
>>> best regards,
>>> Anthony
>>>
>>> On 6/17/2014 6:20 PM, Petr Pchelko wrote:
>>>> Hello, Alexander.
>>>>
>>>>>> 2. In java.c:1859 DoSplashSetFileJarName sets the name of the file
>>>>>> which was used for a splash. It can be
>>>>>> retrieved via public API SplashScreen.getImageURL. Is it correct
>>>>>> to always set the file_name disregards the real
>>>>>> name we've used?
>>>>>
>>>>>     Yes. The original splash screen image name and size are
>>>>> provided for the developer even the high resolution splash screen
>>>>> is shown.
>>>> Thank you for the clarification.
>>>>
>>>> The updated version looks fine to me.
>>>>
>>>> With best regards. Petr.
>>>>
>>>> On 17 ???? 2014 ?., at 18:16, Alexander Scherbatiy
>>>> <alexandr.scherbatiy at oracle.com> wrote:
>>>>
>>>>>
>>>>> Hello,
>>>>>
>>>>> Could you review the updated fix:
>>>>>   http://cr.openjdk.java.net/~alexsch/8043869/webrev.01/
>>>>>
>>>>>
>>>>> On 6/17/2014 4:22 PM, Petr Pchelko wrote:
>>>>>> Hello, Alexander.
>>>>>>
>>>>>> CCed Kumar as I believe he's the owner of the launcher code.
>>>>>>
>>>>>> 1. In splashscreen_sys.m you autorelease the fileName. But I do
>>>>>> not see where the autoreleasepool is set up.
>>>>>> Wouldn't it be better to set up an autoreleasepool in this method
>>>>>> explicitly?
>>>>>      NSAutoreleasePool is added.
>>>>>> 2. In java.c:1859 DoSplashSetFileJarName sets the name of the file
>>>>>> which was used for a splash. It can be
>>>>>> retrieved via public API SplashScreen.getImageURL. Is it correct
>>>>>> to always set the file_name disregards the real
>>>>>> name we've used?
>>>>>
>>>>>     Yes. The original splash screen image name and size are
>>>>> provided for the developer even the high resolution splash screen
>>>>> is shown.
>>>>>
>>>>>     Thanks,
>>>>>     Alexandr.
>>>>>> Thank you.
>>>>>> With best regards. Petr.
>>>>>>
>>>>>> On 17 ???? 2014 ?., at 15:36, Alexander Scherbatiy
>>>>>> <alexandr.scherbatiy at oracle.com> wrote:
>>>>>>
>>>>>>> Hello,
>>>>>>>
>>>>>>> Could you review the fix:
>>>>>>>   bug: https://bugs.openjdk.java.net/browse/JDK-8043869
>>>>>>>   webrev: http://cr.openjdk.java.net/~alexsch/8043869/webrev.00
>>>>>>>
>>>>>>>   The scaleFactor field is added to the Splash struct.
>>>>>>>   The SplahsScreen class scales the graphics and the size
>>>>>>> according to the scale factor.
>>>>>>>   The native system tries to load high resolution splash image on
>>>>>>> HiDPI display.
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Alexandr.
>>>>>>>
>>>>>
>>>>
>>
>

From alexander.v.stepanov at oracle.com  Wed Jun 18 15:14:05 2014
From: alexander.v.stepanov at oracle.com (alexander stepanov)
Date: Wed, 18 Jun 2014 19:14:05 +0400
Subject: <AWT Dev> [9] Review Request for 8044429: move awt automated
 tests for AWT_Modality to OpenJDK repository
In-Reply-To: <AFEDAB31-1357-4933-9979-7B58674042ED@oracle.com>
References: <53A187A9.7060400@oracle.com>
	<AFEDAB31-1357-4933-9979-7B58674042ED@oracle.com>
Message-ID: <53A1ACBD.1020106@oracle.com>

Hello Petr,

Thank you for the note; fixed. Please see the updated webrev:
http://cr.openjdk.java.net/~avstepan/8044429/webrev.01/

Regards,
Alexander

On 18.06.2014 17:57, Petr Pchelko wrote:
> Hello, Alexander.
>
> In ExcludeDialogTest and ExcludeFrameTest you are emulating key type manually while ExtendedRobot can do that.
> Same in TestWindow, TestFrame and TestDialog : 206 - You are manually emulating the click while ExtendedRobot provides this feature.
> typeTab method duplicates functionality in ExtendedRobot.
>
> With best regards. Petr.
>
> On 18 ???? 2014 ?., at 16:35, alexander stepanov <alexander.v.stepanov at oracle.com> wrote:
>
>> Hello,
>>
>> Could you please review the webrev:
>> http://cr.openjdk.java.net/~avstepan/8044429/
>>
>> This is the 1st portion of functional AWT modality tests prepared for migration to OpenJDK repository in accordance with
>> https://bugs.openjdk.java.net/browse/JDK-8044429
>>
>> Some helper classes were moved too.
>>
>> The tests were checked on Ubuntu 14.04, Solaris 11, and Windows 7.
>>
>> At the moment the tests are failing on Mac OS X due to
>> https://bugs.openjdk.java.net/browse/JDK-7125054
>> https://bugs.openjdk.java.net/browse/JDK-8047179
>>
>> Thanks,
>> Alexander


From petr.pchelko at oracle.com  Wed Jun 18 15:18:45 2014
From: petr.pchelko at oracle.com (Petr Pchelko)
Date: Wed, 18 Jun 2014 19:18:45 +0400
Subject: <AWT Dev> [9] Review Request for 8044429: move awt automated
	tests for AWT_Modality to OpenJDK repository
In-Reply-To: <53A1ACBD.1020106@oracle.com>
References: <53A187A9.7060400@oracle.com>
	<AFEDAB31-1357-4933-9979-7B58674042ED@oracle.com>
	<53A1ACBD.1020106@oracle.com>
Message-ID: <3D6D6E1E-9A8A-4C53-9E4A-058CBCFD6E5E@oracle.com>

Hello, Alexander.

I didn't look at every line, but overall the fix looks fine to me.

With best regards. Petr.

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

> Hello Petr,
> 
> Thank you for the note; fixed. Please see the updated webrev:
> http://cr.openjdk.java.net/~avstepan/8044429/webrev.01/
> 
> Regards,
> Alexander
> 
> On 18.06.2014 17:57, Petr Pchelko wrote:
>> Hello, Alexander.
>> 
>> In ExcludeDialogTest and ExcludeFrameTest you are emulating key type manually while ExtendedRobot can do that.
>> Same in TestWindow, TestFrame and TestDialog : 206 - You are manually emulating the click while ExtendedRobot provides this feature.
>> typeTab method duplicates functionality in ExtendedRobot.
>> 
>> With best regards. Petr.
>> 
>> On 18 ???? 2014 ?., at 16:35, alexander stepanov <alexander.v.stepanov at oracle.com> wrote:
>> 
>>> Hello,
>>> 
>>> Could you please review the webrev:
>>> http://cr.openjdk.java.net/~avstepan/8044429/
>>> 
>>> This is the 1st portion of functional AWT modality tests prepared for migration to OpenJDK repository in accordance with
>>> https://bugs.openjdk.java.net/browse/JDK-8044429
>>> 
>>> Some helper classes were moved too.
>>> 
>>> The tests were checked on Ubuntu 14.04, Solaris 11, and Windows 7.
>>> 
>>> At the moment the tests are failing on Mac OS X due to
>>> https://bugs.openjdk.java.net/browse/JDK-7125054
>>> https://bugs.openjdk.java.net/browse/JDK-8047179
>>> 
>>> Thanks,
>>> Alexander
> 


From alexander.v.stepanov at oracle.com  Wed Jun 18 15:53:04 2014
From: alexander.v.stepanov at oracle.com (alexander stepanov)
Date: Wed, 18 Jun 2014 19:53:04 +0400
Subject: <AWT Dev> [9] Review Request for 8044429: move awt automated
 tests for AWT_Modality to OpenJDK repository
In-Reply-To: <3D6D6E1E-9A8A-4C53-9E4A-058CBCFD6E5E@oracle.com>
References: <53A187A9.7060400@oracle.com>
	<AFEDAB31-1357-4933-9979-7B58674042ED@oracle.com>
	<53A1ACBD.1020106@oracle.com>
	<3D6D6E1E-9A8A-4C53-9E4A-058CBCFD6E5E@oracle.com>
Message-ID: <53A1B5E0.8060306@oracle.com>

Thanks!

On 18.06.2014 19:18, Petr Pchelko wrote:
> Hello, Alexander.
>
> I didn't look at every line, but overall the fix looks fine to me.
>
> With best regards. Petr.
>
> On 18 ???? 2014 ?., at 19:14, alexander stepanov <alexander.v.stepanov at oracle.com> wrote:
>
>> Hello Petr,
>>
>> Thank you for the note; fixed. Please see the updated webrev:
>> http://cr.openjdk.java.net/~avstepan/8044429/webrev.01/
>>
>> Regards,
>> Alexander
>>
>> On 18.06.2014 17:57, Petr Pchelko wrote:
>>> Hello, Alexander.
>>>
>>> In ExcludeDialogTest and ExcludeFrameTest you are emulating key type manually while ExtendedRobot can do that.
>>> Same in TestWindow, TestFrame and TestDialog : 206 - You are manually emulating the click while ExtendedRobot provides this feature.
>>> typeTab method duplicates functionality in ExtendedRobot.
>>>
>>> With best regards. Petr.
>>>
>>> On 18 ???? 2014 ?., at 16:35, alexander stepanov <alexander.v.stepanov at oracle.com> wrote:
>>>
>>>> Hello,
>>>>
>>>> Could you please review the webrev:
>>>> http://cr.openjdk.java.net/~avstepan/8044429/
>>>>
>>>> This is the 1st portion of functional AWT modality tests prepared for migration to OpenJDK repository in accordance with
>>>> https://bugs.openjdk.java.net/browse/JDK-8044429
>>>>
>>>> Some helper classes were moved too.
>>>>
>>>> The tests were checked on Ubuntu 14.04, Solaris 11, and Windows 7.
>>>>
>>>> At the moment the tests are failing on Mac OS X due to
>>>> https://bugs.openjdk.java.net/browse/JDK-7125054
>>>> https://bugs.openjdk.java.net/browse/JDK-8047179
>>>>
>>>> Thanks,
>>>> Alexander


From petr.pchelko at oracle.com  Thu Jun 19 11:17:41 2014
From: petr.pchelko at oracle.com (Petr Pchelko)
Date: Thu, 19 Jun 2014 15:17:41 +0400
Subject: <AWT Dev> [9] Review Request: 8047336 Read flavormap.properties as
	resource
Message-ID: <59786637-036B-49C3-AB92-0D5742C87AC2@oracle.com>

Hello, 

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

This is another step in datatransfer modularization work. This part of the work needs a CCC, so I've moved it out to a separate fix. The CCC will be filed once the fix is settled.

Multiple changes are happening here:
1. After http://ccc.us.oracle.com/8005250 the flavormap.properties and AWT.DnD.flavorMapFileURL Toolkit property was removed from the public API. However one mention was forgotten and I'm removing it now, see changes in Toolkit.java
2. For modules we need to move flavormap.properties out of the jre/lib. I'm not sure about the new location. Can I add properties to the java.awt.datatransfer package? Wouldn't they be considered public in this case?
3. The AWT.DnD.flavorMapFileURL Toolkit property cannot be set by the user and it's not used by us. So I'm removing it.
4. As flavormap.properties is not editable by the user any more, I'm changing it's format to get significant simplification of the parsing code.

There's no way left to change the default mappings now, but we have public supported API to create new mappings in the Java code. System property could be added to provide alternative properties location, but I don't think it's required.

The fix was tested on Windows, Linux and Mac with JCK and all regression tests related to datatransfer, dnd and clipboard. The JPRT build succeeds.

A question for the build team: as you see I'm creating an explicit rule for the properties file. The problem's that if I add flavormap.properties to the COPY_PATTERNS, the solaris version is used on Mac for some reason. Is that a bug and is there any way to avoid it?

Thank you. 
With best regards. Petr.



From Alan.Bateman at oracle.com  Thu Jun 19 12:13:14 2014
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Thu, 19 Jun 2014 13:13:14 +0100
Subject: <AWT Dev> [9] Review Request: 8047336 Read flavormap.properties
	as resource
In-Reply-To: <59786637-036B-49C3-AB92-0D5742C87AC2@oracle.com>
References: <59786637-036B-49C3-AB92-0D5742C87AC2@oracle.com>
Message-ID: <53A2D3DA.4030503@oracle.com>

On 19/06/2014 12:17, Petr Pchelko wrote:
> Hello,
>
> Please review the fix for the issue:
> https://bugs.openjdk.java.net/browse/JDK-8047336
> The fix is available at:
> http://cr.openjdk.java.net/~pchelko/9/8047336/webrev.00/
>
> This is another step in datatransfer modularization work. This part of the work needs a CCC, so I've moved it out to a separate fix. The CCC will be filed once the fix is settled.
>
> Multiple changes are happening here:
> 1. After http://ccc.us.oracle.com/8005250 the flavormap.properties and AWT.DnD.flavorMapFileURL Toolkit property was removed from the public API. However one mention was forgotten and I'm removing it now, see changes in Toolkit.java
> 2. For modules we need to move flavormap.properties out of the jre/lib. I'm not sure about the new location. Can I add properties to the java.awt.datatransfer package? Wouldn't they be considered public in this case?
> 3. The AWT.DnD.flavorMapFileURL Toolkit property cannot be set by the user and it's not used by us. So I'm removing it.
> 4. As flavormap.properties is not editable by the user any more, I'm changing it's format to get significant simplification of the parsing code.
>
> There's no way left to change the default mappings now, but we have public supported API to create new mappings in the Java code. System property could be added to provide alternative properties location, but I don't think it's required.
>
The dropping of the reference to flavormap.properties from 
java.awt.Toolkit looks okay to me.

I skimmed through the changes to java.awt.datatransfer.SystemFlavorMap 
(not a detailed review) and it looks okay. I cannot comment on the 
changes to format as I don't know the history in this area to understand 
the issues around duplicates.

On your question about introducing a system property to allow the 
configuration be picked up from some other (non-JDK) location then it 
doesn't sound like there is a strong case. Do we know if anyone has been 
editing the file in ${java.home}/lib? I assume that if there is a strong 
need then it could be possible to introducing it in the future without 
conflicting with anything that you are doing here.

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

From petr.pchelko at oracle.com  Thu Jun 19 12:24:28 2014
From: petr.pchelko at oracle.com (Petr Pchelko)
Date: Thu, 19 Jun 2014 16:24:28 +0400
Subject: <AWT Dev> [9] Review Request: 8047336 Read flavormap.properties
	as resource
In-Reply-To: <53A2D3DA.4030503@oracle.com>
References: <59786637-036B-49C3-AB92-0D5742C87AC2@oracle.com>
	<53A2D3DA.4030503@oracle.com>
Message-ID: <B543154A-7C00-4024-9478-6D615E828190@oracle.com>

Hello, Alan.

Thank you for the review.

> Do we know if anyone has been editing the file in ${java.home}/lib?
I couldn't find any examples on the internet although I've done a very extensive search, so I we could add a property later if someone would request it.

With best regards. Petr.

On 19 ???? 2014 ?., at 16:13, Alan Bateman <Alan.Bateman at oracle.com> wrote:

> On 19/06/2014 12:17, Petr Pchelko wrote:
>> Hello, 
>> 
>> Please review the fix for the issue:
>> https://bugs.openjdk.java.net/browse/JDK-8047336
>> The fix is available at:
>> http://cr.openjdk.java.net/~pchelko/9/8047336/webrev.00/
>> 
>> This is another step in datatransfer modularization work. This part of the work needs a CCC, so I've moved it out to a separate fix. The CCC will be filed once the fix is settled.
>> 
>> Multiple changes are happening here:
>> 1. After http://ccc.us.oracle.com/8005250 the flavormap.properties and AWT.DnD.flavorMapFileURL Toolkit property was removed from the public API. However one mention was forgotten and I'm removing it now, see changes in Toolkit.java
>> 2. For modules we need to move flavormap.properties out of the jre/lib. I'm not sure about the new location. Can I add properties to the java.awt.datatransfer package? Wouldn't they be considered public in this case?
>> 3. The AWT.DnD.flavorMapFileURL Toolkit property cannot be set by the user and it's not used by us. So I'm removing it.
>> 4. As flavormap.properties is not editable by the user any more, I'm changing it's format to get significant simplification of the parsing code.
>> 
>> There's no way left to change the default mappings now, but we have public supported API to create new mappings in the Java code. System property could be added to provide alternative properties location, but I don't think it's required.
>> 
> The dropping of the reference to flavormap.properties from java.awt.Toolkit looks okay to me.
> 
> I skimmed through the changes to java.awt.datatransfer.SystemFlavorMap (not a detailed review) and it looks okay. I cannot comment on the changes to format as I don't know the history in this area to understand the issues around duplicates.
> 
> On your question about introducing a system property to allow the configuration be picked up from some other (non-JDK) location then it doesn't sound like there is a strong case. Do we know if anyone has been editing the file in ${java.home}/lib? I assume that if there is a strong need then it could be possible to introducing it in the future without conflicting with anything that you are doing here.
> 
> -Alan.

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

From dmitriy.ermashov at oracle.com  Thu Jun 19 14:21:04 2014
From: dmitriy.ermashov at oracle.com (Dmitriy Ermashov)
Date: Thu, 19 Jun 2014 18:21:04 +0400
Subject: <AWT Dev> Review Request for 8047180: Move functional tests
 AWT_Headless/Automated to OpenJDK repository
Message-ID: <53A2F1D0.2030300@oracle.com>

Hi AWT team, Swing team,

Please review the fix for
https://bugs.openjdk.java.net/browse/JDK-8047180

Webrev is here:
http://cr.openjdk.java.net/~dermashov/8047180/webrev.00/

It is one more batch of functional tests moving to OpenJDK repo.
This batch covers just one functional test 
AWT_Headless/Automated/Headless_BAT.
The changeset is pretty large, but the initial test consists of ~220'000 
lines of java code split on many files.

Thanks for your understanding!

-dima

From jvanek at redhat.com  Thu Jun 19 14:35:50 2014
From: jvanek at redhat.com (Jiri Vanek)
Date: Thu, 19 Jun 2014 16:35:50 +0200
Subject: <AWT Dev> Fwd: RFR: make life easier for general java plugin
In-Reply-To: <539EBA32.30502@redhat.com>
References: <5379FFBB.4050406@redhat.com> <537CBFEB.6070104@redhat.com>
	<539EBA32.30502@redhat.com>
Message-ID: <53A2F546.5080101@redhat.com>

On 06/16/2014 11:34 AM, Jiri Vanek wrote:
ping??

> ping?
>
> On 05/21/2014 05:02 PM, Jiri Vanek wrote:
>>
>> Hi!
>>
>> IcedTea-Web [1] have now patch [3] from [2] thread,  to work pretty smooth with all Icedteas, all
>> Openjdks and all Oracle javas.  It even do work with IBM java.
>> However, we needed to include few lines of copypasted code [3] line 274-283. Well it is not so much,
>> but is potentially dangerous.
>>
>> If this mini changeset -  http://jvanek.fedorapeople.org/oracle/jdk9/applet-minipatch/1/webrev/ may
>> go in, it would be awesome and will make icedtea-web true Openjdk plugin. Do you think it is
>> possible?
>>
>> Just note - there already was a discussion about unnecessary complex version of similar patch -  [4]
>> thread. As result it forbid any touches to sun.applet package. However current webrev do not add any
>> more visibility. It changes from private to package private. I hope it is much more suitable
>>
>> I sent this message originally to jdk9-dev.. It/I was wrong I guess. Sorry
>>
>> Best regards,
>>    J.
>>
>> [1] http://icedtea.classpath.org/wiki/IcedTea-Web
>> [2] http://mail.openjdk.java.net/pipermail/distro-pkg-dev/2014-May/027577.html thread
>> [3]
>> http://mail.openjdk.java.net/pipermail/distro-pkg-dev/attachments/20140513/a47d6d04/allOpenJdk-0001.patch
>>
>>
>> [4] http://mail.openjdk.java.net/pipermail/jdk9-dev/2014-January/000320.html
>>
>>
>


From petr.pchelko at oracle.com  Thu Jun 19 14:39:36 2014
From: petr.pchelko at oracle.com (Petr Pchelko)
Date: Thu, 19 Jun 2014 18:39:36 +0400
Subject: <AWT Dev> <Swing Dev> Review Request for 8047180: Move
	functional tests AWT_Headless/Automated to OpenJDK repository
In-Reply-To: <53A2F1D0.2030300@oracle.com>
References: <53A2F1D0.2030300@oracle.com>
Message-ID: <225EE240-E8D5-4BB5-8267-FA886E7E96BA@oracle.com>

Hello, Dmitriy.

It's impossible to review))
I've briefly skimmed the classes and didn't see any problems with the tests. Looks like these are pretty much the same)

Did you check that these tests pass on all platforms? 

Thank you.
With best regards. Petr.

On 19 ???? 2014 ?., at 18:21, Dmitriy Ermashov <dmitriy.ermashov at oracle.com> wrote:

> Hi AWT team, Swing team,
> 
> Please review the fix for
> https://bugs.openjdk.java.net/browse/JDK-8047180
> 
> Webrev is here:
> http://cr.openjdk.java.net/~dermashov/8047180/webrev.00/
> 
> It is one more batch of functional tests moving to OpenJDK repo.
> This batch covers just one functional test AWT_Headless/Automated/Headless_BAT.
> The changeset is pretty large, but the initial test consists of ~220'000 lines of java code split on many files.
> 
> Thanks for your understanding!
> 
> -dima


From petr.pchelko at oracle.com  Thu Jun 19 14:46:55 2014
From: petr.pchelko at oracle.com (Petr Pchelko)
Date: Thu, 19 Jun 2014 18:46:55 +0400
Subject: <AWT Dev> Fwd: RFR: make life easier for general java plugin
In-Reply-To: <53A2F546.5080101@redhat.com>
References: <5379FFBB.4050406@redhat.com> <537CBFEB.6070104@redhat.com>
	<539EBA32.30502@redhat.com> <53A2F546.5080101@redhat.com>
Message-ID: <C708A811-E5F9-48AA-8B27-486B4684596A@oracle.com>

Hello, Jiri.

Sorry for the delayed answer.
From the code point of view you current change looks OK to me. It's an internal package and we can change the access modifier easily.

The more general question is what are you going to achieve by making this change?
In JDK-9 we would have modules and you will not be able to use the sun.* packages at all, so this changeset is useless for JDK9. 
Do you want this to go to JDK8?

In the original discussion there was a suggestion about providing a standard public interface for alternative plugins. 
This path looks more promising to me, because it will work in JDK9. Did any progress happen in that direction?

Thank you.
With best regards. Petr.

On 19 ???? 2014 ?., at 18:35, Jiri Vanek <jvanek at redhat.com> wrote:

> On 06/16/2014 11:34 AM, Jiri Vanek wrote:
> ping??
> 
>> ping?
>> 
>> On 05/21/2014 05:02 PM, Jiri Vanek wrote:
>>> 
>>> Hi!
>>> 
>>> IcedTea-Web [1] have now patch [3] from [2] thread,  to work pretty smooth with all Icedteas, all
>>> Openjdks and all Oracle javas.  It even do work with IBM java.
>>> However, we needed to include few lines of copypasted code [3] line 274-283. Well it is not so much,
>>> but is potentially dangerous.
>>> 
>>> If this mini changeset -  http://jvanek.fedorapeople.org/oracle/jdk9/applet-minipatch/1/webrev/ may
>>> go in, it would be awesome and will make icedtea-web true Openjdk plugin. Do you think it is
>>> possible?
>>> 
>>> Just note - there already was a discussion about unnecessary complex version of similar patch -  [4]
>>> thread. As result it forbid any touches to sun.applet package. However current webrev do not add any
>>> more visibility. It changes from private to package private. I hope it is much more suitable
>>> 
>>> I sent this message originally to jdk9-dev.. It/I was wrong I guess. Sorry
>>> 
>>> Best regards,
>>>   J.
>>> 
>>> [1] http://icedtea.classpath.org/wiki/IcedTea-Web
>>> [2] http://mail.openjdk.java.net/pipermail/distro-pkg-dev/2014-May/027577.html thread
>>> [3]
>>> http://mail.openjdk.java.net/pipermail/distro-pkg-dev/attachments/20140513/a47d6d04/allOpenJdk-0001.patch
>>> 
>>> 
>>> [4] http://mail.openjdk.java.net/pipermail/jdk9-dev/2014-January/000320.html
>>> 
>>> 
>> 
> 


From jvanek at redhat.com  Thu Jun 19 15:26:11 2014
From: jvanek at redhat.com (Jiri Vanek)
Date: Thu, 19 Jun 2014 17:26:11 +0200
Subject: <AWT Dev> Fwd: RFR: make life easier for general java plugin
In-Reply-To: <C708A811-E5F9-48AA-8B27-486B4684596A@oracle.com>
References: <5379FFBB.4050406@redhat.com> <537CBFEB.6070104@redhat.com>
	<539EBA32.30502@redhat.com> <53A2F546.5080101@redhat.com>
	<C708A811-E5F9-48AA-8B27-486B4684596A@oracle.com>
Message-ID: <53A30113.90403@redhat.com>

On 06/19/2014 04:46 PM, Petr Pchelko wrote:
> Hello, Jiri.
>
> Sorry for the delayed answer.

np :) Thank you for Answer!

>  From the code point of view you current change looks OK to me. It's an internal package and we can change the access modifier easily.
>
> The more general question is what are you going to achieve by making this change?
> In JDK-9 we would have modules and you will not be able to use the sun.* packages at all, so this changeset is useless for JDK9.
> Do you want this to go to JDK8?

Well I would guess it needs to go to jdk9 first, and then to jdk8, and maybe also to jdk7.
I would be happy to have it in all three :) (but yes, 8 is priority) And I also guess that it can 
not go to 8 without being in 9 (?).

I know that in jdk9 the modules are coming, and that this will  become an serious issue. The API 
suggested in original discussion will be the only chance.
>
> In the original discussion there was a suggestion about providing a standard public interface for alternative plugins.
> This path looks more promising to me, because it will work in JDK9. Did any progress happen in that direction?
>

Nope. My Apologies. I will focus on this API in close future. Actually I'm not sure where to begin, 
but also I guess Mario will be able to provide those hints.  In meantime this one liner would be 
nice to have.


For now, I'm going to derive the API from original plugin-applet-hole patch little bit reduced by 
experience from [3]


Best regards from CZ, and thank you for trying to help us.
   J.

> Thank you.
> With best regards. Petr.h
>
> On 19 ???? 2014 ?., at 18:35, Jiri Vanek <jvanek at redhat.com> wrote:
>
>> On 06/16/2014 11:34 AM, Jiri Vanek wrote:
>> ping??
>>
>>> ping?
>>>
>>> On 05/21/2014 05:02 PM, Jiri Vanek wrote:
>>>>
>>>> Hi!
>>>>
>>>> IcedTea-Web [1] have now patch [3] from [2] thread,  to work pretty smooth with all Icedteas, all
>>>> Openjdks and all Oracle javas.  It even do work with IBM java.
>>>> However, we needed to include few lines of copypasted code [3] line 274-283. Well it is not so much,
>>>> but is potentially dangerous.
>>>>
>>>> If this mini changeset -  http://jvanek.fedorapeople.org/oracle/jdk9/applet-minipatch/1/webrev/ may
>>>> go in, it would be awesome and will make icedtea-web true Openjdk plugin. Do you think it is
>>>> possible?
>>>>
>>>> Just note - there already was a discussion about unnecessary complex version of similar patch -  [4]
>>>> thread. As result it forbid any touches to sun.applet package. However current webrev do not add any
>>>> more visibility. It changes from private to package private. I hope it is much more suitable
>>>>
>>>> I sent this message originally to jdk9-dev.. It/I was wrong I guess. Sorry
>>>>
>>>> Best regards,
>>>>    J.
>>>>
>>>> [1] http://icedtea.classpath.org/wiki/IcedTea-Web
>>>> [2] http://mail.openjdk.java.net/pipermail/distro-pkg-dev/2014-May/027577.html thread
>>>> [3]
>>>> http://mail.openjdk.java.net/pipermail/distro-pkg-dev/attachments/20140513/a47d6d04/allOpenJdk-0001.patch
>>>>
>>>>
>>>> [4] http://mail.openjdk.java.net/pipermail/jdk9-dev/2014-January/000320.html
>>>>
>>>>
>>>
>>
>


From neugens at redhat.com  Thu Jun 19 16:02:32 2014
From: neugens at redhat.com (Mario Torre)
Date: Thu, 19 Jun 2014 18:02:32 +0200
Subject: <AWT Dev> Fwd: RFR: make life easier for general java plugin
In-Reply-To: <53A30113.90403@redhat.com>
References: <5379FFBB.4050406@redhat.com> <537CBFEB.6070104@redhat.com>
	<539EBA32.30502@redhat.com> <53A2F546.5080101@redhat.com>
	<C708A811-E5F9-48AA-8B27-486B4684596A@oracle.com>
	<53A30113.90403@redhat.com>
Message-ID: <1403193752.8747.5.camel@nirvana.localdomain>

On Thu, 2014-06-19 at 17:26 +0200, Jiri Vanek wrote:

> For now, I'm going to derive the API from original plugin-applet-hole
> patch little bit reduced by 
> experience from [3]

I don't have myself a lot of experience with the Plugin API (from an
implementation POV), but I would guess that the requirement for all the
plugins should be pretty much similar, so starting from your patch seems
a great way to tackle this issue.

Looks to me that at the very basic you would need some kind of interface
that the current sun.applet.AppletViewerPanel could implement. Then you
would likely need some PluginManager to retrieve this.

I guess this would be the most conservative approach, assuming other
plugins have similar needs or are implemented in a similar way than
IcedTea-Web.

Does it make sense to you?

Finally, I'm not sure if we need a JEP here or we can do without, after
all we're defining a new API?

Cheers,
Mario



From dmitriy.ermashov at oracle.com  Fri Jun 20 06:26:57 2014
From: dmitriy.ermashov at oracle.com (Dmitriy Ermashov)
Date: Fri, 20 Jun 2014 10:26:57 +0400
Subject: <AWT Dev> <Swing Dev> Review Request for 8047180: Move
 functional tests AWT_Headless/Automated to OpenJDK repository
In-Reply-To: <225EE240-E8D5-4BB5-8267-FA886E7E96BA@oracle.com>
References: <53A2F1D0.2030300@oracle.com>
	<225EE240-E8D5-4BB5-8267-FA886E7E96BA@oracle.com>
Message-ID: <53A3D431.80703@oracle.com>

On 06/19/2014 06:39 PM, Petr Pchelko wrote:
> Hello, Dmitriy.
>
> It's impossible to review))
Impossible is nothing! (c))
> I've briefly skimmed the classes and didn't see any problems with the tests. Looks like these are pretty much the same)
These tests verify that GUI (AWT & Swing) components do not throw 
unexpected exceptions in JVM headless mode and, on the other hand, throw 
HeadlessException or IllegalStateException when it is documented.
No rocket science.
> Did you check that these tests pass on all platforms?
Sure. I've verified tests on Windows 7, Ubuntu 14.04, OS X 10.9, Solaris 
11 and Ubuntu 10.04 (arm CPU).
Pass rate is 100% everywhere.

Thanks,
Dima
> Thank you.
> With best regards. Petr.
>
> On 19 ???? 2014 ?., at 18:21, Dmitriy Ermashov <dmitriy.ermashov at oracle.com> wrote:
>
>> Hi AWT team, Swing team,
>>
>> Please review the fix for
>> https://bugs.openjdk.java.net/browse/JDK-8047180
>>
>> Webrev is here:
>> http://cr.openjdk.java.net/~dermashov/8047180/webrev.00/
>>
>> It is one more batch of functional tests moving to OpenJDK repo.
>> This batch covers just one functional test AWT_Headless/Automated/Headless_BAT.
>> The changeset is pretty large, but the initial test consists of ~220'000 lines of java code split on many files.
>>
>> Thanks for your understanding!
>>
>> -dima


From petr.pchelko at oracle.com  Fri Jun 20 06:59:23 2014
From: petr.pchelko at oracle.com (Petr Pchelko)
Date: Fri, 20 Jun 2014 10:59:23 +0400
Subject: <AWT Dev> <Swing Dev> Review Request for 8047180: Move
	functional tests AWT_Headless/Automated to OpenJDK repository
In-Reply-To: <53A3D431.80703@oracle.com>
References: <53A2F1D0.2030300@oracle.com>
	<225EE240-E8D5-4BB5-8267-FA886E7E96BA@oracle.com>
	<53A3D431.80703@oracle.com>
Message-ID: <F24E43B6-233E-4826-8BE4-54C2953F3777@oracle.com>

>> Did you check that these tests pass on all platforms?
> Sure. I've verified tests on Windows 7, Ubuntu 14.04, OS X 10.9, Solaris 11 and Ubuntu 10.04 (arm CPU).
> Pass rate is 100% everywhere.
Nice to hear that.

The fix looks good to me.

With best regards. Petr.

On 20 ???? 2014 ?., at 10:26, Dmitriy Ermashov <dmitriy.ermashov at oracle.com> wrote:

> On 06/19/2014 06:39 PM, Petr Pchelko wrote:
>> Hello, Dmitriy.
>> 
>> It's impossible to review))
> Impossible is nothing! (c))
>> I've briefly skimmed the classes and didn't see any problems with the tests. Looks like these are pretty much the same)
> These tests verify that GUI (AWT & Swing) components do not throw unexpected exceptions in JVM headless mode and, on the other hand, throw HeadlessException or IllegalStateException when it is documented.
> No rocket science.
>> Did you check that these tests pass on all platforms?
> Sure. I've verified tests on Windows 7, Ubuntu 14.04, OS X 10.9, Solaris 11 and Ubuntu 10.04 (arm CPU).
> Pass rate is 100% everywhere.
> 
> Thanks,
> Dima
>> Thank you.
>> With best regards. Petr.
>> 
>> On 19 ???? 2014 ?., at 18:21, Dmitriy Ermashov <dmitriy.ermashov at oracle.com> wrote:
>> 
>>> Hi AWT team, Swing team,
>>> 
>>> Please review the fix for
>>> https://bugs.openjdk.java.net/browse/JDK-8047180
>>> 
>>> Webrev is here:
>>> http://cr.openjdk.java.net/~dermashov/8047180/webrev.00/
>>> 
>>> It is one more batch of functional tests moving to OpenJDK repo.
>>> This batch covers just one functional test AWT_Headless/Automated/Headless_BAT.
>>> The changeset is pretty large, but the initial test consists of ~220'000 lines of java code split on many files.
>>> 
>>> Thanks for your understanding!
>>> 
>>> -dima
> 


From anthony.petrov at oracle.com  Fri Jun 20 11:19:21 2014
From: anthony.petrov at oracle.com (Anthony Petrov)
Date: Fri, 20 Jun 2014 15:19:21 +0400
Subject: <AWT Dev> [9] Review Request: 8047336 Read flavormap.properties
	as resource
In-Reply-To: <B543154A-7C00-4024-9478-6D615E828190@oracle.com>
References: <59786637-036B-49C3-AB92-0D5742C87AC2@oracle.com>
	<53A2D3DA.4030503@oracle.com>
	<B543154A-7C00-4024-9478-6D615E828190@oracle.com>
Message-ID: <53A418B9.6080500@oracle.com>

Hi Petr,

I ran the following query:

https://www.google.com/#q=custom+flavormap.properties

and the search yielded the following forum thread:

https://community.oracle.com/thread/1293314?start=0&tstart=0

where developers seem to suggest they do edit the 
$JDKHOME/jre/lib/flavormap.properties file sometimes.


Do we officially declare that we drop support for this possibility?

--
best regards,
Anthony

On 6/19/2014 4:24 PM, Petr Pchelko wrote:
> Hello, Alan.
>
> Thank you for the review.
>
>> Do we know if anyone has been editing the file in ${java.home}/lib?
> I couldn't find any examples on the internet although I've done a very
> extensive search, so I we could add a property later if someone would
> request it.
>
> With best regards. Petr.
>
> On 19 ???? 2014 ?., at 16:13, Alan Bateman <Alan.Bateman at oracle.com
> <mailto:Alan.Bateman at oracle.com>> wrote:
>
>> On 19/06/2014 12:17, Petr Pchelko wrote:
>>> Hello,
>>>
>>> Please review the fix for the issue:
>>> https://bugs.openjdk.java.net/browse/JDK-8047336
>>> The fix is available at:
>>> http://cr.openjdk.java.net/~pchelko/9/8047336/webrev.00/
>>>
>>> This is another step in datatransfer modularization work. This part of the work needs a CCC, so I've moved it out to a separate fix. The CCC will be filed once the fix is settled.
>>>
>>> Multiple changes are happening here:
>>> 1. Afterhttp://ccc.us.oracle.com/8005250  the flavormap.properties and AWT.DnD.flavorMapFileURL Toolkit property was removed from the public API. However one mention was forgotten and I'm removing it now, see changes in Toolkit.java
>>> 2. For modules we need to move flavormap.properties out of the jre/lib. I'm not sure about the new location. Can I add properties to the java.awt.datatransfer package? Wouldn't they be considered public in this case?
>>> 3. The AWT.DnD.flavorMapFileURL Toolkit property cannot be set by the user and it's not used by us. So I'm removing it.
>>> 4. As flavormap.properties is not editable by the user any more, I'm changing it's format to get significant simplification of the parsing code.
>>>
>>> There's no way left to change the default mappings now, but we have public supported API to create new mappings in the Java code. System property could be added to provide alternative properties location, but I don't think it's required.
>>>
>> The dropping of the reference to flavormap.properties from
>> java.awt.Toolkit looks okay to me.
>>
>> I skimmed through the changes to java.awt.datatransfer.SystemFlavorMap
>> (not a detailed review) and it looks okay. I cannot comment on the
>> changes to format as I don't know the history in this area to
>> understand the issues around duplicates.
>>
>> On your question about introducing a system property to allow the
>> configuration be picked up from some other (non-JDK) location then it
>> doesn't sound like there is a strong case. Do we know if anyone has
>> been editing the file in ${java.home}/lib? I assume that if there is a
>> strong need then it could be possible to introducing it in the future
>> without conflicting with anything that you are doing here.
>>
>> -Alan.
>

From artem.ananiev at oracle.com  Fri Jun 20 11:29:26 2014
From: artem.ananiev at oracle.com (Artem Ananiev)
Date: Fri, 20 Jun 2014 15:29:26 +0400
Subject: <AWT Dev> [9] Review Request: 8047336 Read flavormap.properties
 as resource
In-Reply-To: <53A418B9.6080500@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>
Message-ID: <53A41B16.9020404@oracle.com>


On 6/20/2014 3:19 PM, Anthony Petrov wrote:
> Hi Petr,
>
> I ran the following query:
>
> https://www.google.com/#q=custom+flavormap.properties
>
> and the search yielded the following forum thread:
>
> https://community.oracle.com/thread/1293314?start=0&tstart=0
>
> where developers seem to suggest they do edit the
> $JDKHOME/jre/lib/flavormap.properties file sometimes.
>
> 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.

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.

Thanks,

Artem

> --
> best regards,
> Anthony
>
> On 6/19/2014 4:24 PM, Petr Pchelko wrote:
>> Hello, Alan.
>>
>> Thank you for the review.
>>
>>> Do we know if anyone has been editing the file in ${java.home}/lib?
>> I couldn't find any examples on the internet although I've done a very
>> extensive search, so I we could add a property later if someone would
>> request it.
>>
>> With best regards. Petr.
>>
>> On 19 ???? 2014 ?., at 16:13, Alan Bateman <Alan.Bateman at oracle.com
>> <mailto:Alan.Bateman at oracle.com>> wrote:
>>
>>> On 19/06/2014 12:17, Petr Pchelko wrote:
>>>> Hello,
>>>>
>>>> Please review the fix for the issue:
>>>> https://bugs.openjdk.java.net/browse/JDK-8047336
>>>> The fix is available at:
>>>> http://cr.openjdk.java.net/~pchelko/9/8047336/webrev.00/
>>>>
>>>> This is another step in datatransfer modularization work. This part
>>>> of the work needs a CCC, so I've moved it out to a separate fix. The
>>>> CCC will be filed once the fix is settled.
>>>>
>>>> Multiple changes are happening here:
>>>> 1. Afterhttp://ccc.us.oracle.com/8005250  the flavormap.properties
>>>> and AWT.DnD.flavorMapFileURL Toolkit property was removed from the
>>>> public API. However one mention was forgotten and I'm removing it
>>>> now, see changes in Toolkit.java
>>>> 2. For modules we need to move flavormap.properties out of the
>>>> jre/lib. I'm not sure about the new location. Can I add properties
>>>> to the java.awt.datatransfer package? Wouldn't they be considered
>>>> public in this case?
>>>> 3. The AWT.DnD.flavorMapFileURL Toolkit property cannot be set by
>>>> the user and it's not used by us. So I'm removing it.
>>>> 4. As flavormap.properties is not editable by the user any more, I'm
>>>> changing it's format to get significant simplification of the
>>>> parsing code.
>>>>
>>>> There's no way left to change the default mappings now, but we have
>>>> public supported API to create new mappings in the Java code. System
>>>> property could be added to provide alternative properties location,
>>>> but I don't think it's required.
>>>>
>>> The dropping of the reference to flavormap.properties from
>>> java.awt.Toolkit looks okay to me.
>>>
>>> I skimmed through the changes to java.awt.datatransfer.SystemFlavorMap
>>> (not a detailed review) and it looks okay. I cannot comment on the
>>> changes to format as I don't know the history in this area to
>>> understand the issues around duplicates.
>>>
>>> On your question about introducing a system property to allow the
>>> configuration be picked up from some other (non-JDK) location then it
>>> doesn't sound like there is a strong case. Do we know if anyone has
>>> been editing the file in ${java.home}/lib? I assume that if there is a
>>> strong need then it could be possible to introducing it in the future
>>> without conflicting with anything that you are doing here.
>>>
>>> -Alan.
>>

From anthony.petrov at oracle.com  Fri Jun 20 11:37:16 2014
From: anthony.petrov at oracle.com (Anthony Petrov)
Date: Fri, 20 Jun 2014 15:37:16 +0400
Subject: <AWT Dev> [9] Review Request: 8047336 Read flavormap.properties
 as resource
In-Reply-To: <53A41B16.9020404@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>
Message-ID: <53A41CEC.3060102@oracle.com>

On 6/20/2014 3:29 PM, Artem Ananiev wrote:
> On 6/20/2014 3:19 PM, Anthony Petrov wrote:
>> I ran the following query:
>>
>> https://www.google.com/#q=custom+flavormap.properties
>>
>> and the search yielded the following forum thread:
>>
>> https://community.oracle.com/thread/1293314?start=0&tstart=0
>>
>> where developers seem to suggest they do edit the
>> $JDKHOME/jre/lib/flavormap.properties file sometimes.
>>
>> 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.

Can we file an RFE for this feature now please?


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

+1

--
best regards,
Anthony

>
> Thanks,
>
> Artem
>
>> --
>> best regards,
>> Anthony
>>
>> On 6/19/2014 4:24 PM, Petr Pchelko wrote:
>>> Hello, Alan.
>>>
>>> Thank you for the review.
>>>
>>>> Do we know if anyone has been editing the file in ${java.home}/lib?
>>> I couldn't find any examples on the internet although I've done a very
>>> extensive search, so I we could add a property later if someone would
>>> request it.
>>>
>>> With best regards. Petr.
>>>
>>> On 19 ???? 2014 ?., at 16:13, Alan Bateman <Alan.Bateman at oracle.com
>>> <mailto:Alan.Bateman at oracle.com>> wrote:
>>>
>>>> On 19/06/2014 12:17, Petr Pchelko wrote:
>>>>> Hello,
>>>>>
>>>>> Please review the fix for the issue:
>>>>> https://bugs.openjdk.java.net/browse/JDK-8047336
>>>>> The fix is available at:
>>>>> http://cr.openjdk.java.net/~pchelko/9/8047336/webrev.00/
>>>>>
>>>>> This is another step in datatransfer modularization work. This part
>>>>> of the work needs a CCC, so I've moved it out to a separate fix. The
>>>>> CCC will be filed once the fix is settled.
>>>>>
>>>>> Multiple changes are happening here:
>>>>> 1. Afterhttp://ccc.us.oracle.com/8005250  the flavormap.properties
>>>>> and AWT.DnD.flavorMapFileURL Toolkit property was removed from the
>>>>> public API. However one mention was forgotten and I'm removing it
>>>>> now, see changes in Toolkit.java
>>>>> 2. For modules we need to move flavormap.properties out of the
>>>>> jre/lib. I'm not sure about the new location. Can I add properties
>>>>> to the java.awt.datatransfer package? Wouldn't they be considered
>>>>> public in this case?
>>>>> 3. The AWT.DnD.flavorMapFileURL Toolkit property cannot be set by
>>>>> the user and it's not used by us. So I'm removing it.
>>>>> 4. As flavormap.properties is not editable by the user any more, I'm
>>>>> changing it's format to get significant simplification of the
>>>>> parsing code.
>>>>>
>>>>> There's no way left to change the default mappings now, but we have
>>>>> public supported API to create new mappings in the Java code. System
>>>>> property could be added to provide alternative properties location,
>>>>> but I don't think it's required.
>>>>>
>>>> The dropping of the reference to flavormap.properties from
>>>> java.awt.Toolkit looks okay to me.
>>>>
>>>> I skimmed through the changes to java.awt.datatransfer.SystemFlavorMap
>>>> (not a detailed review) and it looks okay. I cannot comment on the
>>>> changes to format as I don't know the history in this area to
>>>> understand the issues around duplicates.
>>>>
>>>> On your question about introducing a system property to allow the
>>>> configuration be picked up from some other (non-JDK) location then it
>>>> doesn't sound like there is a strong case. Do we know if anyone has
>>>> been editing the file in ${java.home}/lib? I assume that if there is a
>>>> strong need then it could be possible to introducing it in the future
>>>> without conflicting with anything that you are doing here.
>>>>
>>>> -Alan.
>>>

From petr.pchelko at oracle.com  Fri Jun 20 11:41:18 2014
From: petr.pchelko at oracle.com (Petr Pchelko)
Date: Fri, 20 Jun 2014 15:41:18 +0400
Subject: <AWT Dev> [9] Review Request: 8047336 Read flavormap.properties
	as resource
In-Reply-To: <53A41B16.9020404@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>
Message-ID: <18DA96EE-B90D-4BAD-8990-6D4972446019@oracle.com>

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.

Thank you.
With best regards. Petr.

On 20 ???? 2014 ?., at 15:29, Artem Ananiev <artem.ananiev at oracle.com> wrote:

> 
> On 6/20/2014 3:19 PM, Anthony Petrov wrote:
>> Hi Petr,
>> 
>> I ran the following query:
>> 
>> https://www.google.com/#q=custom+flavormap.properties
>> 
>> and the search yielded the following forum thread:
>> 
>> https://community.oracle.com/thread/1293314?start=0&tstart=0
>> 
>> where developers seem to suggest they do edit the
>> $JDKHOME/jre/lib/flavormap.properties file sometimes.
>> 
>> 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.
> 
> 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.
> 
> Thanks,
> 
> Artem
> 
>> --
>> best regards,
>> Anthony
>> 
>> On 6/19/2014 4:24 PM, Petr Pchelko wrote:
>>> Hello, Alan.
>>> 
>>> Thank you for the review.
>>> 
>>>> Do we know if anyone has been editing the file in ${java.home}/lib?
>>> I couldn't find any examples on the internet although I've done a very
>>> extensive search, so I we could add a property later if someone would
>>> request it.
>>> 
>>> With best regards. Petr.
>>> 
>>> On 19 ???? 2014 ?., at 16:13, Alan Bateman <Alan.Bateman at oracle.com
>>> <mailto:Alan.Bateman at oracle.com>> wrote:
>>> 
>>>> On 19/06/2014 12:17, Petr Pchelko wrote:
>>>>> Hello,
>>>>> 
>>>>> Please review the fix for the issue:
>>>>> https://bugs.openjdk.java.net/browse/JDK-8047336
>>>>> The fix is available at:
>>>>> http://cr.openjdk.java.net/~pchelko/9/8047336/webrev.00/
>>>>> 
>>>>> This is another step in datatransfer modularization work. This part
>>>>> of the work needs a CCC, so I've moved it out to a separate fix. The
>>>>> CCC will be filed once the fix is settled.
>>>>> 
>>>>> Multiple changes are happening here:
>>>>> 1. Afterhttp://ccc.us.oracle.com/8005250  the flavormap.properties
>>>>> and AWT.DnD.flavorMapFileURL Toolkit property was removed from the
>>>>> public API. However one mention was forgotten and I'm removing it
>>>>> now, see changes in Toolkit.java
>>>>> 2. For modules we need to move flavormap.properties out of the
>>>>> jre/lib. I'm not sure about the new location. Can I add properties
>>>>> to the java.awt.datatransfer package? Wouldn't they be considered
>>>>> public in this case?
>>>>> 3. The AWT.DnD.flavorMapFileURL Toolkit property cannot be set by
>>>>> the user and it's not used by us. So I'm removing it.
>>>>> 4. As flavormap.properties is not editable by the user any more, I'm
>>>>> changing it's format to get significant simplification of the
>>>>> parsing code.
>>>>> 
>>>>> There's no way left to change the default mappings now, but we have
>>>>> public supported API to create new mappings in the Java code. System
>>>>> property could be added to provide alternative properties location,
>>>>> but I don't think it's required.
>>>>> 
>>>> The dropping of the reference to flavormap.properties from
>>>> java.awt.Toolkit looks okay to me.
>>>> 
>>>> I skimmed through the changes to java.awt.datatransfer.SystemFlavorMap
>>>> (not a detailed review) and it looks okay. I cannot comment on the
>>>> changes to format as I don't know the history in this area to
>>>> understand the issues around duplicates.
>>>> 
>>>> On your question about introducing a system property to allow the
>>>> configuration be picked up from some other (non-JDK) location then it
>>>> doesn't sound like there is a strong case. Do we know if anyone has
>>>> been editing the file in ${java.home}/lib? I assume that if there is a
>>>> strong need then it could be possible to introducing it in the future
>>>> without conflicting with anything that you are doing here.
>>>> 
>>>> -Alan.
>>> 


From anthony.petrov at oracle.com  Fri Jun 20 11:43:13 2014
From: anthony.petrov at oracle.com (Anthony Petrov)
Date: Fri, 20 Jun 2014 15:43:13 +0400
Subject: <AWT Dev> [9] Review Request: 8047336 Read flavormap.properties
 as resource
In-Reply-To: <18DA96EE-B90D-4BAD-8990-6D4972446019@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>
Message-ID: <53A41E51.1060205@oracle.com>

I see. OK then. But this looks like something that needs to be 
release-noted.

--
best regards,
Anthony

On 6/20/2014 3:41 PM, 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.
>
> Thank you.
> With best regards. Petr.
>
> On 20 ???? 2014 ?., at 15:29, Artem Ananiev <artem.ananiev at oracle.com> wrote:
>
>>
>> On 6/20/2014 3:19 PM, Anthony Petrov wrote:
>>> Hi Petr,
>>>
>>> I ran the following query:
>>>
>>> https://www.google.com/#q=custom+flavormap.properties
>>>
>>> and the search yielded the following forum thread:
>>>
>>> https://community.oracle.com/thread/1293314?start=0&tstart=0
>>>
>>> where developers seem to suggest they do edit the
>>> $JDKHOME/jre/lib/flavormap.properties file sometimes.
>>>
>>> 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.
>>
>> 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.
>>
>> Thanks,
>>
>> Artem
>>
>>> --
>>> best regards,
>>> Anthony
>>>
>>> On 6/19/2014 4:24 PM, Petr Pchelko wrote:
>>>> Hello, Alan.
>>>>
>>>> Thank you for the review.
>>>>
>>>>> Do we know if anyone has been editing the file in ${java.home}/lib?
>>>> I couldn't find any examples on the internet although I've done a very
>>>> extensive search, so I we could add a property later if someone would
>>>> request it.
>>>>
>>>> With best regards. Petr.
>>>>
>>>> On 19 ???? 2014 ?., at 16:13, Alan Bateman <Alan.Bateman at oracle.com
>>>> <mailto:Alan.Bateman at oracle.com>> wrote:
>>>>
>>>>> On 19/06/2014 12:17, Petr Pchelko wrote:
>>>>>> Hello,
>>>>>>
>>>>>> Please review the fix for the issue:
>>>>>> https://bugs.openjdk.java.net/browse/JDK-8047336
>>>>>> The fix is available at:
>>>>>> http://cr.openjdk.java.net/~pchelko/9/8047336/webrev.00/
>>>>>>
>>>>>> This is another step in datatransfer modularization work. This part
>>>>>> of the work needs a CCC, so I've moved it out to a separate fix. The
>>>>>> CCC will be filed once the fix is settled.
>>>>>>
>>>>>> Multiple changes are happening here:
>>>>>> 1. Afterhttp://ccc.us.oracle.com/8005250  the flavormap.properties
>>>>>> and AWT.DnD.flavorMapFileURL Toolkit property was removed from the
>>>>>> public API. However one mention was forgotten and I'm removing it
>>>>>> now, see changes in Toolkit.java
>>>>>> 2. For modules we need to move flavormap.properties out of the
>>>>>> jre/lib. I'm not sure about the new location. Can I add properties
>>>>>> to the java.awt.datatransfer package? Wouldn't they be considered
>>>>>> public in this case?
>>>>>> 3. The AWT.DnD.flavorMapFileURL Toolkit property cannot be set by
>>>>>> the user and it's not used by us. So I'm removing it.
>>>>>> 4. As flavormap.properties is not editable by the user any more, I'm
>>>>>> changing it's format to get significant simplification of the
>>>>>> parsing code.
>>>>>>
>>>>>> There's no way left to change the default mappings now, but we have
>>>>>> public supported API to create new mappings in the Java code. System
>>>>>> property could be added to provide alternative properties location,
>>>>>> but I don't think it's required.
>>>>>>
>>>>> The dropping of the reference to flavormap.properties from
>>>>> java.awt.Toolkit looks okay to me.
>>>>>
>>>>> I skimmed through the changes to java.awt.datatransfer.SystemFlavorMap
>>>>> (not a detailed review) and it looks okay. I cannot comment on the
>>>>> changes to format as I don't know the history in this area to
>>>>> understand the issues around duplicates.
>>>>>
>>>>> On your question about introducing a system property to allow the
>>>>> configuration be picked up from some other (non-JDK) location then it
>>>>> doesn't sound like there is a strong case. Do we know if anyone has
>>>>> been editing the file in ${java.home}/lib? I assume that if there is a
>>>>> strong need then it could be possible to introducing it in the future
>>>>> without conflicting with anything that you are doing here.
>>>>>
>>>>> -Alan.
>>>>
>

From Alan.Bateman at oracle.com  Fri Jun 20 11:50:10 2014
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Fri, 20 Jun 2014 12:50:10 +0100
Subject: <AWT Dev> [9] Review Request: 8047336 Read flavormap.properties
 as resource
In-Reply-To: <18DA96EE-B90D-4BAD-8990-6D4972446019@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>
Message-ID: <53A41FF2.8050705@oracle.com>

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 alexandr.scherbatiy at oracle.com  Fri Jun 20 12:37:29 2014
From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy)
Date: Fri, 20 Jun 2014 16:37:29 +0400
Subject: <AWT Dev> <Swing Dev> Review Request for 8047180: Move
 functional tests AWT_Headless/Automated to OpenJDK repository
In-Reply-To: <53A3D431.80703@oracle.com>
References: <53A2F1D0.2030300@oracle.com>
	<225EE240-E8D5-4BB5-8267-FA886E7E96BA@oracle.com>
	<53A3D431.80703@oracle.com>
Message-ID: <53A42B09.7090309@oracle.com>


  The fix looks good to me.

  Thanks,
  Alexandr.

On 6/20/2014 10:26 AM, Dmitriy Ermashov wrote:
> On 06/19/2014 06:39 PM, Petr Pchelko wrote:
>> Hello, Dmitriy.
>>
>> It's impossible to review))
> Impossible is nothing! (c))
>> I've briefly skimmed the classes and didn't see any problems with the 
>> tests. Looks like these are pretty much the same)
> These tests verify that GUI (AWT & Swing) components do not throw 
> unexpected exceptions in JVM headless mode and, on the other hand, 
> throw HeadlessException or IllegalStateException when it is documented.
> No rocket science.
>> Did you check that these tests pass on all platforms?
> Sure. I've verified tests on Windows 7, Ubuntu 14.04, OS X 10.9, 
> Solaris 11 and Ubuntu 10.04 (arm CPU).
> Pass rate is 100% everywhere.
>
> Thanks,
> Dima
>> Thank you.
>> With best regards. Petr.
>>
>> On 19 ???? 2014 ?., at 18:21, Dmitriy Ermashov 
>> <dmitriy.ermashov at oracle.com> wrote:
>>
>>> Hi AWT team, Swing team,
>>>
>>> Please review the fix for
>>> https://bugs.openjdk.java.net/browse/JDK-8047180
>>>
>>> Webrev is here:
>>> http://cr.openjdk.java.net/~dermashov/8047180/webrev.00/
>>>
>>> It is one more batch of functional tests moving to OpenJDK repo.
>>> This batch covers just one functional test 
>>> AWT_Headless/Automated/Headless_BAT.
>>> The changeset is pretty large, but the initial test consists of 
>>> ~220'000 lines of java code split on many files.
>>>
>>> Thanks for your understanding!
>>>
>>> -dima
>


From dmitriy.ermashov at oracle.com  Mon Jun 23 07:51:47 2014
From: dmitriy.ermashov at oracle.com (Dmitriy Ermashov)
Date: Mon, 23 Jun 2014 11:51:47 +0400
Subject: <AWT Dev> <Swing Dev> Review Request for 8047180: Move
 functional tests AWT_Headless/Automated to OpenJDK repository
In-Reply-To: <53A42B09.7090309@oracle.com>
References: <53A2F1D0.2030300@oracle.com>
	<225EE240-E8D5-4BB5-8267-FA886E7E96BA@oracle.com>
	<53A3D431.80703@oracle.com> <53A42B09.7090309@oracle.com>
Message-ID: <CFCDC53D.35A2%dmitriy.ermashov@oracle.com>

Thanks for review!
-dima

20.06.14, 16:37 ???????????? "Alexander Scherbatiy"
<alexandr.scherbatiy at oracle.com> ???????:

>
>  The fix looks good to me.
>
>  Thanks,
>  Alexandr.
>
>On 6/20/2014 10:26 AM, Dmitriy Ermashov wrote:
>> On 06/19/2014 06:39 PM, Petr Pchelko wrote:
>>> Hello, Dmitriy.
>>>
>>> It's impossible to review))
>> Impossible is nothing! (c))
>>> I've briefly skimmed the classes and didn't see any problems with the
>>> tests. Looks like these are pretty much the same)
>> These tests verify that GUI (AWT & Swing) components do not throw
>> unexpected exceptions in JVM headless mode and, on the other hand,
>> throw HeadlessException or IllegalStateException when it is documented.
>> No rocket science.
>>> Did you check that these tests pass on all platforms?
>> Sure. I've verified tests on Windows 7, Ubuntu 14.04, OS X 10.9,
>> Solaris 11 and Ubuntu 10.04 (arm CPU).
>> Pass rate is 100% everywhere.
>>
>> Thanks,
>> Dima
>>> Thank you.
>>> With best regards. Petr.
>>>
>>> On 19 ???? 2014 ?., at 18:21, Dmitriy Ermashov
>>> <dmitriy.ermashov at oracle.com> wrote:
>>>
>>>> Hi AWT team, Swing team,
>>>>
>>>> Please review the fix for
>>>> https://bugs.openjdk.java.net/browse/JDK-8047180
>>>>
>>>> Webrev is here:
>>>> http://cr.openjdk.java.net/~dermashov/8047180/webrev.00/
>>>>
>>>> It is one more batch of functional tests moving to OpenJDK repo.
>>>> This batch covers just one functional test
>>>> AWT_Headless/Automated/Headless_BAT.
>>>> The changeset is pretty large, but the initial test consists of
>>>> ~220'000 lines of java code split on many files.
>>>>
>>>> Thanks for your understanding!
>>>>
>>>> -dima
>>
>



From alexander.v.stepanov at oracle.com  Mon Jun 23 09:35:15 2014
From: alexander.v.stepanov at oracle.com (alexander stepanov)
Date: Mon, 23 Jun 2014 13:35:15 +0400
Subject: <AWT Dev> [9] Review request for 8043967: Fix doclint warnings
 for java.awt
In-Reply-To: <5397FEB1.2080906@oracle.com>
References: <538DC421.7060204@oracle.com> <538DD3FD.8050909@oracle.com>
	<538DFBF7.3040502@oracle.com> <5397FEB1.2080906@oracle.com>
Message-ID: <53A7F4D3.1090505@oracle.com>

Sorry, just a reminder.
>
> On 03.06.2014 20:46, alexander stepanov wrote:
>> Hello Sergey,
>>
>> Updated; please see
>> http://cr.openjdk.java.net/~avstepan/8043967/webrev.01/
>>
>> Thanks,
>> Alexander
>>
>> On 03.06.2014 17:56, Sergey Bylokhov wrote:
>>> Hi, Alexander.
>>> A few notes:
>>>  - Use two spaces after @param tag only. in other cases use one space.
>>>  - Do no align names of the @params tag like this:
>>>   390      * position will not be replaced).
>>>   391      * @param   str  the non-{@code null} text to use as
>>>   392      *               the replacement
>>>   393      * @param   start  the start position
>>>   394      * @param   end    the end position
>>>   395      * @deprecated As of JDK version 1.1,
>>> Change them to:
>>>   390      * position will not be replaced).
>>>   391      * @param  str the non-{@code null} text to use as
>>>   392      *         the replacement
>>>   393      * @param  start the start position
>>>   394      * @param  end the end position
>>>   395      * @deprecated As of JDK version 1.1,
>>>   - Add empty line after method description before @param tag.
>>>   - Description of the method should ends by dot.
>>>
>>> On 6/3/14 4:48 PM, alexander stepanov wrote:
>>>> Hello,
>>>>
>>>> Could you please review the fix for the following bug:
>>>> https://bugs.openjdk.java.net/browse/JDK-8043967
>>>>
>>>> Webrev:
>>>> http://cr.openjdk.java.net/~avstepan/8043967
>>>>
>>>> Just a cleanup of javadoc to avoid doclint warnings.
>>>>
>>>> Thanks,
>>>> Alexander
>>>
>>>
>>> -- 
>>> Best regards, Sergey.
>>
>


From petr.pchelko at oracle.com  Mon Jun 23 09:46:00 2014
From: petr.pchelko at oracle.com (Petr Pchelko)
Date: Mon, 23 Jun 2014 13:46:00 +0400
Subject: <AWT Dev> [9] Review Request: JDK-8047799 Remove
	WindowClosingSupport
Message-ID: <7C886EA2-4BE1-4DCA-8329-C47AC6DC2AA8@oracle.com>

Hello, AWT Team.

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

This feature was added for plugin in 1.4. I've grepped the sources and the interfaces and methods are not used any more.
I've run modality JTREG and checked the test for an original bug, everything seems to work fine. JPRT build succeeds.

With best regards. Petr.

From andrei.eremeev at oracle.com  Mon Jun 23 11:22:42 2014
From: andrei.eremeev at oracle.com (andrei.eremeev)
Date: Mon, 23 Jun 2014 15:22:42 +0400
Subject: <AWT Dev> [9] Review Request: JDK-7112454 Fix for TEST_BUG:
 java/awt/Choice/PopdownGeneratesMouseEvents/PopdownGeneratesMouseEvents.html
 failed
In-Reply-To: <90D5C6D4-5792-468F-B1A2-4CE6AF6F2164@oracle.com>
References: <52DE6495.2010904@oracle.com>
	<90D5C6D4-5792-468F-B1A2-4CE6AF6F2164@oracle.com>
Message-ID: <53A80E02.6050502@oracle.com>

Fixed Petr's remarks.

The fix:
http://cr.openjdk.java.net/~yan/7112454/webrev.diff.04/

Test moved to open:
http://cr.openjdk.java.net/~yan/7112454/webrev.04/

Andrei

On 01/21/2014 04:41 PM, Petr Pchelko wrote:
> Hello, Andrei.
>
> Please update the copyright header, it should say 2014. And the header is missing in an html file.
>
> As you?ve added Util you could replace the dragMouse method with Util.drag and remove the method.
>
> With best regards. Petr.
>
> 21 ???. 2014 ?., ? 4:14 ????? ???????, andrei.eremeev <andrei.eremeev at oracle.com> ???????(?):
>
>> Hi, AWT team.
>>
>> Please review the fix for the issue:
>> https://bugs.openjdk.java.net/browse/JDK-7112454
>>
>> The fix is available at:
>> http://cr.openjdk.java.net/~yan/7112454/webrev.diff.03/
>>
>> Test moved to open:
>> http://cr.openjdk.java.net/~yan/7112454/webrev.03/


From dmitriy.ermashov at oracle.com  Mon Jun 23 11:40:53 2014
From: dmitriy.ermashov at oracle.com (Dmitriy Ermashov)
Date: Mon, 23 Jun 2014 15:40:53 +0400
Subject: <AWT Dev> Review request for JDK-8043131: Move
 ShapedAndTranslucentWindows and GC functional AWT tests to regression tree
In-Reply-To: <5397FDE5.30703@oracle.com>
References: <5379F43E.8060000@oracle.com> <538DAFAD.3000409@oracle.com>
	<A5DF7FFD-728E-40C9-AE40-50C48216D456@oracle.com>
	<538ECECD.90208@oracle.com>
	<E609129F-6738-4234-822D-F9F21795F498@oracle.com>
	<5397FDE5.30703@oracle.com>
Message-ID: <CFCDFAD2.35BA%dmitriy.ermashov@oracle.com>

Hi,

Just a kindly reminder.
Please, review the changeset.

Thanks,
Dima

11.06.14, 10:57 ???????????? "Dmitriy Ermashov"
<dmitriy.ermashov at oracle.com> ???????:

>Petr, thanks for review!
>
>Sergey, could you please look at the fix?
>http://cr.openjdk.java.net/~yan/8043131/webrev.02/
>You had some notices for the previous bug 8041915
>(http://mail.openjdk.java.net/pipermail/awt-dev/2014-June/007944.html)
>
>Thanks,
>Dima
>
>On 04.06.2014 12:00, Petr Pchelko wrote:
>> Hello, Dmitriy.
>>
>> The new version looks fine to me.
>>
>> With best regards. Petr.
>>
>> On 04 ???? 2014 ?., at 11:46, Dmitriy Ermashov
>><dmitriy.ermashov at oracle.com> wrote:
>>
>>> Hi Petr, all,
>>>
>>> Please review next revision of webrev:
>>> http://cr.openjdk.java.net/~yan/8043131/webrev.02/
>>>
>>> 1. Set -Xmx20m key for GC tests
>>> 2. Added @Override annotation for all corresponding self written
>>>methods.
>>>
>>> Thanks,
>>> Dima
>>>
>>> On 03.06.2014 16:33, Petr Pchelko wrote:
>>>> Hello, Dmitriy.
>>>>
>>>> I think that it worths adding -Xmx option to the GC tests as default
>>>>max heap size is quite big.
>>>> Also could you please add @Override to the initGui method as now it's
>>>>not obvious where is it called from.
>>>>
>>>> Thank you.
>>>> With best regards. Petr.
>>>>
>>>> On 03 ???? 2014 ?., at 15:21, Dmitriy Ermashov
>>>><dmitriy.ermashov at oracle.com> wrote:
>>>>
>>>>> Hi all,
>>>>>
>>>>> Please review the last version of fix for
>>>>> https://bugs.openjdk.java.net/browse/JDK-8043131
>>>>>
>>>>> The webrev is here:
>>>>> http://cr.openjdk.java.net/~yan/8043131/webrev.01/
>>>>>
>>>>> Test colocation for remaining ShapedAndTranslucent part of
>>>>>functional tests.
>>>>> The fix also includes remarks for the first part of this batch. E.g.
>>>>>retrieved "@author mrkam" tag and full description for each test.
>>>>> GC tests also reverted as they are not similar to
>>>>>java/awt/Window/OwnedWindowsLeak/OwnedWindowsLeak.java and could be
>>>>>useful for finding bugs.
>>>>>
>>>>> Thanks,
>>>>> Dima
>>>>>
>>>>> On 05/19/2014 04:08 PM, Dmitriy Ermashov wrote:
>>>>>> Hi,
>>>>>>
>>>>>> Please review the changeset for bug:
>>>>>> https://bugs.openjdk.java.net/browse/JDK-8043131
>>>>>>
>>>>>> The webrev is here:
>>>>>> http://cr.openjdk.java.net/~yan/8043131/webrev.00/
>>>>>>
>>>>>> This is one more batch of functional AWT
>>>>>>(ShapedAndTranslucentWindows and GC) tests are ought to be moved to
>>>>>>regression tree.
>>>>>>
>



From alexandr.scherbatiy at oracle.com  Mon Jun 23 11:54:29 2014
From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy)
Date: Mon, 23 Jun 2014 15:54:29 +0400
Subject: <AWT Dev> [9] Review request for 8043869 [macosx] java -splash
 does not honor @2x hi dpi notation for retina support
In-Reply-To: <53A19DCA.7090307@oracle.com>
References: <53A0282D.80709@oracle.com>	<F4D88430-7FBA-4D5F-8C63-A34E4AD63220@oracle.com>	<53A04DB9.2060509@oracle.com>
	<D650DAE1-852C-4B7F-B7B2-F03B05F3F6A8@oracle.com>
	<53A05499.4000109@oracle.com> <53A06AFE.5070304@oracle.com>
	<53A18E2C.3090005@oracle.com> <53A19DCA.7090307@oracle.com>
Message-ID: <53A81575.20107@oracle.com>


   Hello,

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

  - a splash screen path that has a dot at the end or does not have a 
dot at the end is now correctly parsed on Mac OS X
  - 0 is changed to NULL in the splashscreen_stubs.c
  - dividing by scaleFactor: this parameter is provided by our code, not 
by splash screen image file (for example it 2 for images splash at 2x.png 
on Mac OS X).
    It should never be zero. However, I have added assert (0 < 
scaleFactor) and set it to default value in opposite case to be sure
    that  the scaleFactor has consistent value.
  - I run open and closed launcher/splash screen tests. They passed 
except one that also fails with jdk without the fix.
    The command line splash screen tests should be updated to check 
Darwin system to be run on Mac OS X.

  Thanks,
  Alexandr.


On 6/18/2014 6:10 PM, Kumar Srinivasan wrote:
> Hi Alexander,
>
> Thanks for making that change in java.c
>
> splashscreen_stubs.c:
>
> <Sorry I should have caught this earlier>
> I would change the 0 to NULL as as you have already done on line 89...
>
> 64     INVOKE(SplashLoadMemory,0)(pdata, size);
> 68     INVOKE(SplashLoadFile,0)(filename);
>
> SplashScreen.java:
>
> Is it possible to get a divide by zero here ? I realize you are 
> intializing to 1 elsewhere
> what happens  if you "read" a zero ? Ex:  What happens if you call 
> generateImage(0) in the test ?
>
>  248             float scale = _getScaleFactor(splashPtr);
>  249             Rectangle bounds = _getBounds(splashPtr);
>  250             if (scale != 1) {
>  251                 bounds.setSize((int) (bounds.getWidth() / scale),
>  252                         (int) (bounds.getWidth() / scale));
>  253             }
>  254             return bounds;
>
>
> Should we have some more validations of the input data ? since these 
> items are
> being read from a user generated image file.
>
> One last thing, I am assuming you have run all the launcher 
> regressions including the SplashScreen tests in
> the jdk/test/closed ?
>
> Kumar
>
>
>
> On 6/18/2014 6:03 AM, Alexander Scherbatiy wrote:
>>
>>  Hello,
>>
>>  Could you review the updated fix:
>>     http://cr.openjdk.java.net/~alexsch/8043869/webrev.02
>>
>>   - formatting and CR-LF line endings are fixed
>>   - the condition if (1 < screenScaleFactor) is rewritten in 
>> splashscreen_sys.m file
>>   - file_name == NULL chec is added in the java.c
>>   - [NSScreen mainScreen] is changed to SplashNSScreen() in the 
>> SplashGetScaledImageName() from splashscreen_sys.m file
>>
>> Thanks,
>> Alexandr.
>>
>> On 6/17/2014 8:21 PM, Kumar Srinivasan wrote:
>>> Hello,
>>>
>>> As Anthony already commented, there are some formatting issues 
>>> throughout, please
>>> retain the existing convention and formatting.
>>>
>>> src/share/bin/java.c
>>> at 1822, if you add
>>> if (file_name == NULL){
>>>     return;
>>> }
>>> and removing the else, at the bottom we can reduce the indent of the 
>>> exist if block.
>>>
>>> make/mapfiles/libsplashscreen/mapfile-vers
>>> +1, good to note this, always trips people up.
>>>
>>>
>>> Otherwise looks good.
>>>
>>> Kumar
>>>
>>>
>>>
>>>
>>> On 6/17/2014 7:45 AM, Anthony Petrov wrote:
>>>> Hi Alexander,
>>>>
>>>> [ I'm also adding Neil who's taking over the launcher code ]
>>>>
>>>> 1. There's a few code formatting issues that should be fixed. For 
>>>> instance:
>>>> src/share/bin/java.c
>>>>> 1846 if(scaled_splash_name){
>>>>> 1853         if(scaled_splash_name){
>>>>
>>>> src/windows/native/sun/awt/splashscreen/splashscreen_sys.c
>>>>>  571     *scaleFactor=1;
>>>>
>>>> In all the above lines required spaces are missing. I believe 
>>>> there's a number of other occurrences of the same issue in your 
>>>> patch. Please check it carefully and fix the formatting on all lines.
>>>>
>>>> 2. Webrev shows 236 changed lines for java_awt_SplashScreen.c. I 
>>>> suspect you've changed the EOL characters because you've edited 
>>>> your code on MS Windows. Please configure your editor to use LF 
>>>> characters for line ends and revert the unnecessary changes (note 
>>>> that jcheck won't let you push CR-LF line endings anyway).
>>>>
>>>> 3. splashscreen_sys.m
>>>>>  135     if (1 < screenScaleFactor) {
>>>>
>>>> For consistency and clarity, I'd suggest to rewrite the condition as
>>>>
>>>>     if (screenScaleFactor > 1) {
>>>>
>>>> -- 
>>>> best regards,
>>>> Anthony
>>>>
>>>> On 6/17/2014 6:20 PM, Petr Pchelko wrote:
>>>>> Hello, Alexander.
>>>>>
>>>>>>> 2. In java.c:1859 DoSplashSetFileJarName sets the name of the 
>>>>>>> file which was used for a splash. It can be
>>>>>>> retrieved via public API SplashScreen.getImageURL. Is it correct 
>>>>>>> to always set the file_name disregards the real
>>>>>>> name we've used?
>>>>>>
>>>>>>     Yes. The original splash screen image name and size are 
>>>>>> provided for the developer even the high resolution splash screen 
>>>>>> is shown.
>>>>> Thank you for the clarification.
>>>>>
>>>>> The updated version looks fine to me.
>>>>>
>>>>> With best regards. Petr.
>>>>>
>>>>> On 17 ???? 2014 ?., at 18:16, Alexander Scherbatiy 
>>>>> <alexandr.scherbatiy at oracle.com> wrote:
>>>>>
>>>>>>
>>>>>> Hello,
>>>>>>
>>>>>> Could you review the updated fix:
>>>>>>   http://cr.openjdk.java.net/~alexsch/8043869/webrev.01/
>>>>>>
>>>>>>
>>>>>> On 6/17/2014 4:22 PM, Petr Pchelko wrote:
>>>>>>> Hello, Alexander.
>>>>>>>
>>>>>>> CCed Kumar as I believe he's the owner of the launcher code.
>>>>>>>
>>>>>>> 1. In splashscreen_sys.m you autorelease the fileName. But I do 
>>>>>>> not see where the autoreleasepool is set up.
>>>>>>> Wouldn't it be better to set up an autoreleasepool in this 
>>>>>>> method explicitly?
>>>>>>      NSAutoreleasePool is added.
>>>>>>> 2. In java.c:1859 DoSplashSetFileJarName sets the name of the 
>>>>>>> file which was used for a splash. It can be
>>>>>>> retrieved via public API SplashScreen.getImageURL. Is it correct 
>>>>>>> to always set the file_name disregards the real
>>>>>>> name we've used?
>>>>>>
>>>>>>     Yes. The original splash screen image name and size are 
>>>>>> provided for the developer even the high resolution splash screen 
>>>>>> is shown.
>>>>>>
>>>>>>     Thanks,
>>>>>>     Alexandr.
>>>>>>> Thank you.
>>>>>>> With best regards. Petr.
>>>>>>>
>>>>>>> On 17 ???? 2014 ?., at 15:36, Alexander Scherbatiy 
>>>>>>> <alexandr.scherbatiy at oracle.com> wrote:
>>>>>>>
>>>>>>>> Hello,
>>>>>>>>
>>>>>>>> Could you review the fix:
>>>>>>>>   bug: https://bugs.openjdk.java.net/browse/JDK-8043869
>>>>>>>>   webrev: http://cr.openjdk.java.net/~alexsch/8043869/webrev.00
>>>>>>>>
>>>>>>>>   The scaleFactor field is added to the Splash struct.
>>>>>>>>   The SplahsScreen class scales the graphics and the size 
>>>>>>>> according to the scale factor.
>>>>>>>>   The native system tries to load high resolution splash image 
>>>>>>>> on HiDPI display.
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>> Alexandr.
>>>>>>>>
>>>>>>
>>>>>
>>>
>>
>


From petr.pchelko at oracle.com  Mon Jun 23 12:39:39 2014
From: petr.pchelko at oracle.com (Petr Pchelko)
Date: Mon, 23 Jun 2014 16:39:39 +0400
Subject: <AWT Dev> [9] Review Request: JDK-7112454 Fix for TEST_BUG:
	java/awt/Choice/PopdownGeneratesMouseEvents/PopdownGeneratesMouseEvents.html
	failed
In-Reply-To: <53A80E02.6050502@oracle.com>
References: <52DE6495.2010904@oracle.com>
	<90D5C6D4-5792-468F-B1A2-4CE6AF6F2164@oracle.com>
	<53A80E02.6050502@oracle.com>
Message-ID: <590C61FD-EBCD-4FE1-B54F-CB69FD8B9C45@oracle.com>

Hello, Andrei.

HTML file still lacks copyright header.

With best regards. Petr.

On 23 ???? 2014 ?., at 15:22, andrei.eremeev <andrei.eremeev at oracle.com> wrote:

> Fixed Petr's remarks.
> 
> The fix:
> http://cr.openjdk.java.net/~yan/7112454/webrev.diff.04/
> 
> Test moved to open:
> http://cr.openjdk.java.net/~yan/7112454/webrev.04/
> 
> Andrei
> 
> On 01/21/2014 04:41 PM, Petr Pchelko wrote:
>> Hello, Andrei.
>> 
>> Please update the copyright header, it should say 2014. And the header is missing in an html file.
>> 
>> As you?ve added Util you could replace the dragMouse method with Util.drag and remove the method.
>> 
>> With best regards. Petr.
>> 
>> 21 ???. 2014 ?., ? 4:14 ????? ???????, andrei.eremeev <andrei.eremeev at oracle.com> ???????(?):
>> 
>>> Hi, AWT team.
>>> 
>>> Please review the fix for the issue:
>>> https://bugs.openjdk.java.net/browse/JDK-7112454
>>> 
>>> The fix is available at:
>>> http://cr.openjdk.java.net/~yan/7112454/webrev.diff.03/
>>> 
>>> Test moved to open:
>>> http://cr.openjdk.java.net/~yan/7112454/webrev.03/
> 


From petr.pchelko at oracle.com  Mon Jun 23 12:58:54 2014
From: petr.pchelko at oracle.com (Petr Pchelko)
Date: Mon, 23 Jun 2014 16:58:54 +0400
Subject: <AWT Dev> [9] Review request for 8043967: Fix doclint warnings
	for java.awt
In-Reply-To: <53A7F4D3.1090505@oracle.com>
References: <538DC421.7060204@oracle.com> <538DD3FD.8050909@oracle.com>
	<538DFBF7.3040502@oracle.com> <5397FEB1.2080906@oracle.com>
	<53A7F4D3.1090505@oracle.com>
Message-ID: <FC104E8A-B5C9-4769-8888-9C2C80398836@oracle.com>

Hello, Alexander.

A couple of comments:

AWTKeyStroke why do you use a full name in @throws?
HeadlessException.getMessage you could use @inheritDoc here.
KeyboardFocusManager: 1463 Why did you add an extra line here?
Robot: 513 - the line is not aligned

With best regards. Petr.

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

> Sorry, just a reminder.
>> 
>> On 03.06.2014 20:46, alexander stepanov wrote:
>>> Hello Sergey,
>>> 
>>> Updated; please see
>>> http://cr.openjdk.java.net/~avstepan/8043967/webrev.01/
>>> 
>>> Thanks,
>>> Alexander
>>> 
>>> On 03.06.2014 17:56, Sergey Bylokhov wrote:
>>>> Hi, Alexander.
>>>> A few notes:
>>>> - Use two spaces after @param tag only. in other cases use one space.
>>>> - Do no align names of the @params tag like this:
>>>>  390      * position will not be replaced).
>>>>  391      * @param   str  the non-{@code null} text to use as
>>>>  392      *               the replacement
>>>>  393      * @param   start  the start position
>>>>  394      * @param   end    the end position
>>>>  395      * @deprecated As of JDK version 1.1,
>>>> Change them to:
>>>>  390      * position will not be replaced).
>>>>  391      * @param  str the non-{@code null} text to use as
>>>>  392      *         the replacement
>>>>  393      * @param  start the start position
>>>>  394      * @param  end the end position
>>>>  395      * @deprecated As of JDK version 1.1,
>>>>  - Add empty line after method description before @param tag.
>>>>  - Description of the method should ends by dot.
>>>> 
>>>> On 6/3/14 4:48 PM, alexander stepanov wrote:
>>>>> Hello,
>>>>> 
>>>>> Could you please review the fix for the following bug:
>>>>> https://bugs.openjdk.java.net/browse/JDK-8043967
>>>>> 
>>>>> Webrev:
>>>>> http://cr.openjdk.java.net/~avstepan/8043967
>>>>> 
>>>>> Just a cleanup of javadoc to avoid doclint warnings.
>>>>> 
>>>>> Thanks,
>>>>> Alexander
>>>> 
>>>> 
>>>> -- 
>>>> Best regards, Sergey.
>>> 
>> 
> 


From andrei.eremeev at oracle.com  Mon Jun 23 13:33:11 2014
From: andrei.eremeev at oracle.com (andrei.eremeev)
Date: Mon, 23 Jun 2014 17:33:11 +0400
Subject: <AWT Dev> [9] Review Request: JDK-7112454 Fix for TEST_BUG:
 java/awt/Choice/PopdownGeneratesMouseEvents/PopdownGeneratesMouseEvents.html
 failed
In-Reply-To: <590C61FD-EBCD-4FE1-B54F-CB69FD8B9C45@oracle.com>
References: <52DE6495.2010904@oracle.com>
	<90D5C6D4-5792-468F-B1A2-4CE6AF6F2164@oracle.com>
	<53A80E02.6050502@oracle.com>
	<590C61FD-EBCD-4FE1-B54F-CB69FD8B9C45@oracle.com>
Message-ID: <53A82C97.9070708@oracle.com>

Ok, fixed.

The fix:
http://cr.openjdk.java.net/~yan/7112454/webrev.diff.05/
Test moved to open:
http://cr.openjdk.java.net/~yan/7112454/webrev.05/

Thanks,
Andrei

On 06/23/2014 04:39 PM, Petr Pchelko wrote:
> Hello, Andrei.
>
> HTML file still lacks copyright header.
>
> With best regards. Petr.
>
> On 23 ???? 2014 ?., at 15:22, andrei.eremeev <andrei.eremeev at oracle.com> wrote:
>
>> Fixed Petr's remarks.
>>
>> The fix:
>> http://cr.openjdk.java.net/~yan/7112454/webrev.diff.04/
>>
>> Test moved to open:
>> http://cr.openjdk.java.net/~yan/7112454/webrev.04/
>>
>> Andrei
>>
>> On 01/21/2014 04:41 PM, Petr Pchelko wrote:
>>> Hello, Andrei.
>>>
>>> Please update the copyright header, it should say 2014. And the header is missing in an html file.
>>>
>>> As you?ve added Util you could replace the dragMouse method with Util.drag and remove the method.
>>>
>>> With best regards. Petr.
>>>
>>> 21 ???. 2014 ?., ? 4:14 ????? ???????, andrei.eremeev <andrei.eremeev at oracle.com> ???????(?):
>>>
>>>> Hi, AWT team.
>>>>
>>>> Please review the fix for the issue:
>>>> https://bugs.openjdk.java.net/browse/JDK-7112454
>>>>
>>>> The fix is available at:
>>>> http://cr.openjdk.java.net/~yan/7112454/webrev.diff.03/
>>>>
>>>> Test moved to open:
>>>> http://cr.openjdk.java.net/~yan/7112454/webrev.03/


From petr.pchelko at oracle.com  Mon Jun 23 13:52:44 2014
From: petr.pchelko at oracle.com (Petr Pchelko)
Date: Mon, 23 Jun 2014 17:52:44 +0400
Subject: <AWT Dev> [9] Review Request: JDK-7112454 Fix for TEST_BUG:
	java/awt/Choice/PopdownGeneratesMouseEvents/PopdownGeneratesMouseEvents.html
	failed
In-Reply-To: <53A82C97.9070708@oracle.com>
References: <52DE6495.2010904@oracle.com>
	<90D5C6D4-5792-468F-B1A2-4CE6AF6F2164@oracle.com>
	<53A80E02.6050502@oracle.com>
	<590C61FD-EBCD-4FE1-B54F-CB69FD8B9C45@oracle.com>
	<53A82C97.9070708@oracle.com>
Message-ID: <01F3CD3A-CE61-43C4-BE14-138A3397BDF9@oracle.com>

Hello, Andrei.

Looks good.

With best regards. Petr.

On 23 ???? 2014 ?., at 17:33, andrei.eremeev <andrei.eremeev at oracle.com> wrote:

> Ok, fixed.
> 
> The fix:
> http://cr.openjdk.java.net/~yan/7112454/webrev.diff.05/
> Test moved to open:
> http://cr.openjdk.java.net/~yan/7112454/webrev.05/
> 
> Thanks,
> Andrei
> 
> On 06/23/2014 04:39 PM, Petr Pchelko wrote:
>> Hello, Andrei.
>> 
>> HTML file still lacks copyright header.
>> 
>> With best regards. Petr.
>> 
>> On 23 ???? 2014 ?., at 15:22, andrei.eremeev <andrei.eremeev at oracle.com> wrote:
>> 
>>> Fixed Petr's remarks.
>>> 
>>> The fix:
>>> http://cr.openjdk.java.net/~yan/7112454/webrev.diff.04/
>>> 
>>> Test moved to open:
>>> http://cr.openjdk.java.net/~yan/7112454/webrev.04/
>>> 
>>> Andrei
>>> 
>>> On 01/21/2014 04:41 PM, Petr Pchelko wrote:
>>>> Hello, Andrei.
>>>> 
>>>> Please update the copyright header, it should say 2014. And the header is missing in an html file.
>>>> 
>>>> As you?ve added Util you could replace the dragMouse method with Util.drag and remove the method.
>>>> 
>>>> With best regards. Petr.
>>>> 
>>>> 21 ???. 2014 ?., ? 4:14 ????? ???????, andrei.eremeev <andrei.eremeev at oracle.com> ???????(?):
>>>> 
>>>>> Hi, AWT team.
>>>>> 
>>>>> Please review the fix for the issue:
>>>>> https://bugs.openjdk.java.net/browse/JDK-7112454
>>>>> 
>>>>> The fix is available at:
>>>>> http://cr.openjdk.java.net/~yan/7112454/webrev.diff.03/
>>>>> 
>>>>> Test moved to open:
>>>>> http://cr.openjdk.java.net/~yan/7112454/webrev.03/
> 


From kumar.x.srinivasan at oracle.com  Mon Jun 23 13:59:55 2014
From: kumar.x.srinivasan at oracle.com (Kumar Srinivasan)
Date: Mon, 23 Jun 2014 06:59:55 -0700
Subject: <AWT Dev> [9] Review request for 8043869 [macosx] java -splash
 does not honor @2x hi dpi notation for retina support
In-Reply-To: <53A81575.20107@oracle.com>
References: <53A0282D.80709@oracle.com>	<F4D88430-7FBA-4D5F-8C63-A34E4AD63220@oracle.com>	<53A04DB9.2060509@oracle.com>
	<D650DAE1-852C-4B7F-B7B2-F03B05F3F6A8@oracle.com>
	<53A05499.4000109@oracle.com> <53A06AFE.5070304@oracle.com>
	<53A18E2C.3090005@oracle.com> <53A19DCA.7090307@oracle.com>
	<53A81575.20107@oracle.com>
Message-ID: <53A832DB.4020700@oracle.com>

Hi Alexander,

Looks good to me.

>
>   Hello,
>
>   Could you review the updated fix:
>      http://cr.openjdk.java.net/~alexsch/8043869/webrev.03/
>
>  - a splash screen path that has a dot at the end or does not have a 
> dot at the end is now correctly parsed on Mac OS X
>  - 0 is changed to NULL in the splashscreen_stubs.c
>  - dividing by scaleFactor: this parameter is provided by our code, 
> not by splash screen image file (for example it 2 for images 
> splash at 2x.png on Mac OS X).
>    It should never be zero. However, I have added assert (0 < 
> scaleFactor) and set it to default value in opposite case to be sure
>    that  the scaleFactor has consistent value.
>  - I run open and closed launcher/splash screen tests. They passed 
> except one that also fails with jdk without the fix.
>    The command line splash screen tests should be updated to check 
> Darwin system to be run on Mac OS X.

There are many things wrong with these tests besides Darwin, they also 
don't run on 64-bit solaris I think.
I thought I filed a bug.

Kumar

>
>  Thanks,
>  Alexandr.
>
>
> On 6/18/2014 6:10 PM, Kumar Srinivasan wrote:
>> Hi Alexander,
>>
>> Thanks for making that change in java.c
>>
>> splashscreen_stubs.c:
>>
>> <Sorry I should have caught this earlier>
>> I would change the 0 to NULL as as you have already done on line 89...
>>
>> 64     INVOKE(SplashLoadMemory,0)(pdata, size);
>> 68     INVOKE(SplashLoadFile,0)(filename);
>>
>> SplashScreen.java:
>>
>> Is it possible to get a divide by zero here ? I realize you are 
>> intializing to 1 elsewhere
>> what happens  if you "read" a zero ? Ex:  What happens if you call 
>> generateImage(0) in the test ?
>>
>>  248             float scale = _getScaleFactor(splashPtr);
>>  249             Rectangle bounds = _getBounds(splashPtr);
>>  250             if (scale != 1) {
>>  251                 bounds.setSize((int) (bounds.getWidth() / scale),
>>  252                         (int) (bounds.getWidth() / scale));
>>  253             }
>>  254             return bounds;
>>
>>
>> Should we have some more validations of the input data ? since these 
>> items are
>> being read from a user generated image file.
>>
>> One last thing, I am assuming you have run all the launcher 
>> regressions including the SplashScreen tests in
>> the jdk/test/closed ?
>>
>> Kumar
>>
>>
>>
>> On 6/18/2014 6:03 AM, Alexander Scherbatiy wrote:
>>>
>>>  Hello,
>>>
>>>  Could you review the updated fix:
>>>     http://cr.openjdk.java.net/~alexsch/8043869/webrev.02
>>>
>>>   - formatting and CR-LF line endings are fixed
>>>   - the condition if (1 < screenScaleFactor) is rewritten in 
>>> splashscreen_sys.m file
>>>   - file_name == NULL chec is added in the java.c
>>>   - [NSScreen mainScreen] is changed to SplashNSScreen() in the 
>>> SplashGetScaledImageName() from splashscreen_sys.m file
>>>
>>> Thanks,
>>> Alexandr.
>>>
>>> On 6/17/2014 8:21 PM, Kumar Srinivasan wrote:
>>>> Hello,
>>>>
>>>> As Anthony already commented, there are some formatting issues 
>>>> throughout, please
>>>> retain the existing convention and formatting.
>>>>
>>>> src/share/bin/java.c
>>>> at 1822, if you add
>>>> if (file_name == NULL){
>>>>     return;
>>>> }
>>>> and removing the else, at the bottom we can reduce the indent of 
>>>> the exist if block.
>>>>
>>>> make/mapfiles/libsplashscreen/mapfile-vers
>>>> +1, good to note this, always trips people up.
>>>>
>>>>
>>>> Otherwise looks good.
>>>>
>>>> Kumar
>>>>
>>>>
>>>>
>>>>
>>>> On 6/17/2014 7:45 AM, Anthony Petrov wrote:
>>>>> Hi Alexander,
>>>>>
>>>>> [ I'm also adding Neil who's taking over the launcher code ]
>>>>>
>>>>> 1. There's a few code formatting issues that should be fixed. For 
>>>>> instance:
>>>>> src/share/bin/java.c
>>>>>> 1846 if(scaled_splash_name){
>>>>>> 1853         if(scaled_splash_name){
>>>>>
>>>>> src/windows/native/sun/awt/splashscreen/splashscreen_sys.c
>>>>>>  571     *scaleFactor=1;
>>>>>
>>>>> In all the above lines required spaces are missing. I believe 
>>>>> there's a number of other occurrences of the same issue in your 
>>>>> patch. Please check it carefully and fix the formatting on all lines.
>>>>>
>>>>> 2. Webrev shows 236 changed lines for java_awt_SplashScreen.c. I 
>>>>> suspect you've changed the EOL characters because you've edited 
>>>>> your code on MS Windows. Please configure your editor to use LF 
>>>>> characters for line ends and revert the unnecessary changes (note 
>>>>> that jcheck won't let you push CR-LF line endings anyway).
>>>>>
>>>>> 3. splashscreen_sys.m
>>>>>>  135     if (1 < screenScaleFactor) {
>>>>>
>>>>> For consistency and clarity, I'd suggest to rewrite the condition as
>>>>>
>>>>>     if (screenScaleFactor > 1) {
>>>>>
>>>>> -- 
>>>>> best regards,
>>>>> Anthony
>>>>>
>>>>> On 6/17/2014 6:20 PM, Petr Pchelko wrote:
>>>>>> Hello, Alexander.
>>>>>>
>>>>>>>> 2. In java.c:1859 DoSplashSetFileJarName sets the name of the 
>>>>>>>> file which was used for a splash. It can be
>>>>>>>> retrieved via public API SplashScreen.getImageURL. Is it 
>>>>>>>> correct to always set the file_name disregards the real
>>>>>>>> name we've used?
>>>>>>>
>>>>>>>     Yes. The original splash screen image name and size are 
>>>>>>> provided for the developer even the high resolution splash 
>>>>>>> screen is shown.
>>>>>> Thank you for the clarification.
>>>>>>
>>>>>> The updated version looks fine to me.
>>>>>>
>>>>>> With best regards. Petr.
>>>>>>
>>>>>> On 17 ???? 2014 ?., at 18:16, Alexander Scherbatiy 
>>>>>> <alexandr.scherbatiy at oracle.com> wrote:
>>>>>>
>>>>>>>
>>>>>>> Hello,
>>>>>>>
>>>>>>> Could you review the updated fix:
>>>>>>> http://cr.openjdk.java.net/~alexsch/8043869/webrev.01/
>>>>>>>
>>>>>>>
>>>>>>> On 6/17/2014 4:22 PM, Petr Pchelko wrote:
>>>>>>>> Hello, Alexander.
>>>>>>>>
>>>>>>>> CCed Kumar as I believe he's the owner of the launcher code.
>>>>>>>>
>>>>>>>> 1. In splashscreen_sys.m you autorelease the fileName. But I do 
>>>>>>>> not see where the autoreleasepool is set up.
>>>>>>>> Wouldn't it be better to set up an autoreleasepool in this 
>>>>>>>> method explicitly?
>>>>>>>      NSAutoreleasePool is added.
>>>>>>>> 2. In java.c:1859 DoSplashSetFileJarName sets the name of the 
>>>>>>>> file which was used for a splash. It can be
>>>>>>>> retrieved via public API SplashScreen.getImageURL. Is it 
>>>>>>>> correct to always set the file_name disregards the real
>>>>>>>> name we've used?
>>>>>>>
>>>>>>>     Yes. The original splash screen image name and size are 
>>>>>>> provided for the developer even the high resolution splash 
>>>>>>> screen is shown.
>>>>>>>
>>>>>>>     Thanks,
>>>>>>>     Alexandr.
>>>>>>>> Thank you.
>>>>>>>> With best regards. Petr.
>>>>>>>>
>>>>>>>> On 17 ???? 2014 ?., at 15:36, Alexander Scherbatiy 
>>>>>>>> <alexandr.scherbatiy at oracle.com> wrote:
>>>>>>>>
>>>>>>>>> Hello,
>>>>>>>>>
>>>>>>>>> Could you review the fix:
>>>>>>>>>   bug: https://bugs.openjdk.java.net/browse/JDK-8043869
>>>>>>>>>   webrev: http://cr.openjdk.java.net/~alexsch/8043869/webrev.00
>>>>>>>>>
>>>>>>>>>   The scaleFactor field is added to the Splash struct.
>>>>>>>>>   The SplahsScreen class scales the graphics and the size 
>>>>>>>>> according to the scale factor.
>>>>>>>>>   The native system tries to load high resolution splash image 
>>>>>>>>> on HiDPI display.
>>>>>>>>>
>>>>>>>>> Thanks,
>>>>>>>>> Alexandr.
>>>>>>>>>
>>>>>>>
>>>>>>
>>>>
>>>
>>
>


From petr.pchelko at oracle.com  Mon Jun 23 14:13:47 2014
From: petr.pchelko at oracle.com (Petr Pchelko)
Date: Mon, 23 Jun 2014 18:13:47 +0400
Subject: <AWT Dev> [9] Review Request: JDK-8047798 Remove EventQueueDelegate
Message-ID: <B37C1748-191B-4D7B-9C58-2057D24860E5@oracle.com>

Hello, AWT Team.

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

One more weekly clenup. The EventQueueDelegate was added for JavaFXScript to manipulate EDT in unconventional ways. 
Now it's not used and can be removed. Grepped the sources for the raminings and built a JPRT.

With best regards. Petr.

From andrei.eremeev at oracle.com  Mon Jun 23 14:13:43 2014
From: andrei.eremeev at oracle.com (andrei.eremeev)
Date: Mon, 23 Jun 2014 18:13:43 +0400
Subject: <AWT Dev> [9] Review Request: JDK-7112454 Fix for TEST_BUG:
 java/awt/Choice/PopdownGeneratesMouseEvents/PopdownGeneratesMouseEvents.html
 failed
In-Reply-To: <01F3CD3A-CE61-43C4-BE14-138A3397BDF9@oracle.com>
References: <52DE6495.2010904@oracle.com>
	<90D5C6D4-5792-468F-B1A2-4CE6AF6F2164@oracle.com>
	<53A80E02.6050502@oracle.com>
	<590C61FD-EBCD-4FE1-B54F-CB69FD8B9C45@oracle.com>
	<53A82C97.9070708@oracle.com>
	<01F3CD3A-CE61-43C4-BE14-138A3397BDF9@oracle.com>
Message-ID: <53A83617.6030507@oracle.com>

Thanks for review.

Andrei

On 06/23/2014 05:52 PM, Petr Pchelko wrote:
> Hello, Andrei.
>
> Looks good.
>
> With best regards. Petr.
>
> On 23 ???? 2014 ?., at 17:33, andrei.eremeev <andrei.eremeev at oracle.com> wrote:
>
>> Ok, fixed.
>>
>> The fix:
>> http://cr.openjdk.java.net/~yan/7112454/webrev.diff.05/
>> Test moved to open:
>> http://cr.openjdk.java.net/~yan/7112454/webrev.05/
>>
>> Thanks,
>> Andrei
>>
>> On 06/23/2014 04:39 PM, Petr Pchelko wrote:
>>> Hello, Andrei.
>>>
>>> HTML file still lacks copyright header.
>>>
>>> With best regards. Petr.
>>>
>>> On 23 ???? 2014 ?., at 15:22, andrei.eremeev <andrei.eremeev at oracle.com> wrote:
>>>
>>>> Fixed Petr's remarks.
>>>>
>>>> The fix:
>>>> http://cr.openjdk.java.net/~yan/7112454/webrev.diff.04/
>>>>
>>>> Test moved to open:
>>>> http://cr.openjdk.java.net/~yan/7112454/webrev.04/
>>>>
>>>> Andrei
>>>>
>>>> On 01/21/2014 04:41 PM, Petr Pchelko wrote:
>>>>> Hello, Andrei.
>>>>>
>>>>> Please update the copyright header, it should say 2014. And the header is missing in an html file.
>>>>>
>>>>> As you?ve added Util you could replace the dragMouse method with Util.drag and remove the method.
>>>>>
>>>>> With best regards. Petr.
>>>>>
>>>>> 21 ???. 2014 ?., ? 4:14 ????? ???????, andrei.eremeev <andrei.eremeev at oracle.com> ???????(?):
>>>>>
>>>>>> Hi, AWT team.
>>>>>>
>>>>>> Please review the fix for the issue:
>>>>>> https://bugs.openjdk.java.net/browse/JDK-7112454
>>>>>>
>>>>>> The fix is available at:
>>>>>> http://cr.openjdk.java.net/~yan/7112454/webrev.diff.03/
>>>>>>
>>>>>> Test moved to open:
>>>>>> http://cr.openjdk.java.net/~yan/7112454/webrev.03/


From artem.ananiev at oracle.com  Mon Jun 23 14:32:05 2014
From: artem.ananiev at oracle.com (Artem Ananiev)
Date: Mon, 23 Jun 2014 18:32:05 +0400
Subject: <AWT Dev> [9] Review Request: JDK-8047798 Remove
	EventQueueDelegate
In-Reply-To: <B37C1748-191B-4D7B-9C58-2057D24860E5@oracle.com>
References: <B37C1748-191B-4D7B-9C58-2057D24860E5@oracle.com>
Message-ID: <53A83A65.9030406@oracle.com>

Hi, Petr,

the fix looks fine to me.

I would also suggest you to find the initial fix, when 
EventQueueDelegate was introduced (in 6u10?), to check if anything else 
can be wiped out.

Thanks,

Artem

On 6/23/2014 6:13 PM, Petr Pchelko wrote:
> Hello, AWT Team.
>
> Please review the fix for the issue:
> https://bugs.openjdk.java.net/browse/JDK-8047798
> The fix is available at:
> http://cr.openjdk.java.net/~pchelko/9/8047798/webrev/
>
> One more weekly clenup. The EventQueueDelegate was added for JavaFXScript to manipulate EDT in unconventional ways.
> Now it's not used and can be removed. Grepped the sources for the raminings and built a JPRT.
>
> With best regards. Petr.
>

From petr.pchelko at oracle.com  Mon Jun 23 14:40:33 2014
From: petr.pchelko at oracle.com (Petr Pchelko)
Date: Mon, 23 Jun 2014 18:40:33 +0400
Subject: <AWT Dev> [9] Review Request: JDK-8047798 Remove
	EventQueueDelegate
In-Reply-To: <53A83A65.9030406@oracle.com>
References: <B37C1748-191B-4D7B-9C58-2057D24860E5@oracle.com>
	<53A83A65.9030406@oracle.com>
Message-ID: <6253A33A-C26A-4BDB-AD07-56F433F5DDC5@oracle.com>

Hello, Anthony.

Thank you for the review.
I've checked that this fix is a reverse-changeset for JDK-6638195 where the class was introduced.

With best regards. Petr.

On 23 ???? 2014 ?., at 18:32, Artem Ananiev <artem.ananiev at oracle.com> wrote:

> Hi, Petr,
> 
> the fix looks fine to me.
> 
> I would also suggest you to find the initial fix, when EventQueueDelegate was introduced (in 6u10?), to check if anything else can be wiped out.
> 
> Thanks,
> 
> Artem
> 
> On 6/23/2014 6:13 PM, Petr Pchelko wrote:
>> Hello, AWT Team.
>> 
>> Please review the fix for the issue:
>> https://bugs.openjdk.java.net/browse/JDK-8047798
>> The fix is available at:
>> http://cr.openjdk.java.net/~pchelko/9/8047798/webrev/
>> 
>> One more weekly clenup. The EventQueueDelegate was added for JavaFXScript to manipulate EDT in unconventional ways.
>> Now it's not used and can be removed. Grepped the sources for the raminings and built a JPRT.
>> 
>> With best regards. Petr.
>> 


From alexander.v.stepanov at oracle.com  Mon Jun 23 15:47:40 2014
From: alexander.v.stepanov at oracle.com (alexander stepanov)
Date: Mon, 23 Jun 2014 19:47:40 +0400
Subject: <AWT Dev> [9] Review request for 8043967: Fix doclint warnings
 for java.awt
In-Reply-To: <FC104E8A-B5C9-4769-8888-9C2C80398836@oracle.com>
References: <538DC421.7060204@oracle.com> <538DD3FD.8050909@oracle.com>
	<538DFBF7.3040502@oracle.com> <5397FEB1.2080906@oracle.com>
	<53A7F4D3.1090505@oracle.com>
	<FC104E8A-B5C9-4769-8888-9C2C80398836@oracle.com>
Message-ID: <53A84C1C.1080107@oracle.com>

Hello Petr,

 > AWTKeyStroke why do you use a full name in @throws?

In case of short name the following error occurs:

/home/user/hd2/doclint/current/src/jdk/src/share/classes/java/awt/AWTKeyStroke.java:805: 
error: reference not found
      * @throws ObjectStreamException if a serialization problem occurs
        ^
/home/user/hd2/doclint/current/src/jdk/src/share/classes/java/awt/AWTKeyStroke.java:807: 
warning: no @throws for java.io.ObjectStreamException
     protected Object readResolve() throws java.io.ObjectStreamException {
                      ^

So it seems that javadoc is happy here only if the full exception name 
is used. It doesn't affect the resulting html.

The other notes were fixed, thanks:
http://cr.openjdk.java.net/~avstepan/8043967/webrev.02/

Regards,
Alexander


On 23.06.2014 16:58, Petr Pchelko wrote:
> Hello, Alexander.
>
> A couple of comments:
>
> AWTKeyStroke why do you use a full name in @throws?
> HeadlessException.getMessage you could use @inheritDoc here.
> KeyboardFocusManager: 1463 Why did you add an extra line here?
> Robot: 513 - the line is not aligned
>
> With best regards. Petr.
>
> On 23 ???? 2014 ?., at 13:35, alexander stepanov <alexander.v.stepanov at oracle.com> wrote:
>
>> Sorry, just a reminder.
>>> On 03.06.2014 20:46, alexander stepanov wrote:
>>>> Hello Sergey,
>>>>
>>>> Updated; please see
>>>> http://cr.openjdk.java.net/~avstepan/8043967/webrev.01/
>>>>
>>>> Thanks,
>>>> Alexander
>>>>
>>>> On 03.06.2014 17:56, Sergey Bylokhov wrote:
>>>>> Hi, Alexander.
>>>>> A few notes:
>>>>> - Use two spaces after @param tag only. in other cases use one space.
>>>>> - Do no align names of the @params tag like this:
>>>>>   390      * position will not be replaced).
>>>>>   391      * @param   str  the non-{@code null} text to use as
>>>>>   392      *               the replacement
>>>>>   393      * @param   start  the start position
>>>>>   394      * @param   end    the end position
>>>>>   395      * @deprecated As of JDK version 1.1,
>>>>> Change them to:
>>>>>   390      * position will not be replaced).
>>>>>   391      * @param  str the non-{@code null} text to use as
>>>>>   392      *         the replacement
>>>>>   393      * @param  start the start position
>>>>>   394      * @param  end the end position
>>>>>   395      * @deprecated As of JDK version 1.1,
>>>>>   - Add empty line after method description before @param tag.
>>>>>   - Description of the method should ends by dot.
>>>>>
>>>>> On 6/3/14 4:48 PM, alexander stepanov wrote:
>>>>>> Hello,
>>>>>>
>>>>>> Could you please review the fix for the following bug:
>>>>>> https://bugs.openjdk.java.net/browse/JDK-8043967
>>>>>>
>>>>>> Webrev:
>>>>>> http://cr.openjdk.java.net/~avstepan/8043967
>>>>>>
>>>>>> Just a cleanup of javadoc to avoid doclint warnings.
>>>>>>
>>>>>> Thanks,
>>>>>> Alexander
>>>>>
>>>>> -- 
>>>>> Best regards, Sergey.


From petr.pchelko at oracle.com  Mon Jun 23 17:13:38 2014
From: petr.pchelko at oracle.com (Petr Pchelko)
Date: Mon, 23 Jun 2014 21:13:38 +0400
Subject: <AWT Dev> [9] Review request for 8043967: Fix doclint warnings
	for java.awt
In-Reply-To: <53A84C1C.1080107@oracle.com>
References: <538DC421.7060204@oracle.com> <538DD3FD.8050909@oracle.com>
	<538DFBF7.3040502@oracle.com> <5397FEB1.2080906@oracle.com>
	<53A7F4D3.1090505@oracle.com>
	<FC104E8A-B5C9-4769-8888-9C2C80398836@oracle.com>
	<53A84C1C.1080107@oracle.com>
Message-ID: <6DA06D10-C742-4A7E-98ED-D5C612A471E0@oracle.com>

Looks good. 

With best regards. Petr.

> On Jun 23, 2014, at 7:47 PM, alexander stepanov <alexander.v.stepanov at oracle.com> wrote:
> 
> Hello Petr,
> 
> > AWTKeyStroke why do you use a full name in @throws?
> 
> In case of short name the following error occurs:
> 
> /home/user/hd2/doclint/current/src/jdk/src/share/classes/java/awt/AWTKeyStroke.java:805: error: reference not found
>     * @throws ObjectStreamException if a serialization problem occurs
>       ^
> /home/user/hd2/doclint/current/src/jdk/src/share/classes/java/awt/AWTKeyStroke.java:807: warning: no @throws for java.io.ObjectStreamException
>    protected Object readResolve() throws java.io.ObjectStreamException {
>                     ^
> 
> So it seems that javadoc is happy here only if the full exception name is used. It doesn't affect the resulting html.
> 
> The other notes were fixed, thanks:
> http://cr.openjdk.java.net/~avstepan/8043967/webrev.02/
> 
> Regards,
> Alexander
> 
> 
> On 23.06.2014 16:58, Petr Pchelko wrote:
>> Hello, Alexander.
>> 
>> A couple of comments:
>> 
>> AWTKeyStroke why do you use a full name in @throws?
>> HeadlessException.getMessage you could use @inheritDoc here.
>> KeyboardFocusManager: 1463 Why did you add an extra line here?
>> Robot: 513 - the line is not aligned
>> 
>> With best regards. Petr.
>> 
>> On 23 ???? 2014 ?., at 13:35, alexander stepanov <alexander.v.stepanov at oracle.com> wrote:
>> 
>>> Sorry, just a reminder.
>>>> On 03.06.2014 20:46, alexander stepanov wrote:
>>>>> Hello Sergey,
>>>>> 
>>>>> Updated; please see
>>>>> http://cr.openjdk.java.net/~avstepan/8043967/webrev.01/
>>>>> 
>>>>> Thanks,
>>>>> Alexander
>>>>> 
>>>>> On 03.06.2014 17:56, Sergey Bylokhov wrote:
>>>>>> Hi, Alexander.
>>>>>> A few notes:
>>>>>> - Use two spaces after @param tag only. in other cases use one space.
>>>>>> - Do no align names of the @params tag like this:
>>>>>>  390      * position will not be replaced).
>>>>>>  391      * @param   str  the non-{@code null} text to use as
>>>>>>  392      *               the replacement
>>>>>>  393      * @param   start  the start position
>>>>>>  394      * @param   end    the end position
>>>>>>  395      * @deprecated As of JDK version 1.1,
>>>>>> Change them to:
>>>>>>  390      * position will not be replaced).
>>>>>>  391      * @param  str the non-{@code null} text to use as
>>>>>>  392      *         the replacement
>>>>>>  393      * @param  start the start position
>>>>>>  394      * @param  end the end position
>>>>>>  395      * @deprecated As of JDK version 1.1,
>>>>>>  - Add empty line after method description before @param tag.
>>>>>>  - Description of the method should ends by dot.
>>>>>> 
>>>>>> On 6/3/14 4:48 PM, alexander stepanov wrote:
>>>>>>> Hello,
>>>>>>> 
>>>>>>> Could you please review the fix for the following bug:
>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8043967
>>>>>>> 
>>>>>>> Webrev:
>>>>>>> http://cr.openjdk.java.net/~avstepan/8043967
>>>>>>> 
>>>>>>> Just a cleanup of javadoc to avoid doclint warnings.
>>>>>>> 
>>>>>>> Thanks,
>>>>>>> Alexander
>>>>>> 
>>>>>> -- 
>>>>>> Best regards, Sergey.
> 


From anthony.petrov at oracle.com  Mon Jun 23 17:38:28 2014
From: anthony.petrov at oracle.com (Anthony Petrov)
Date: Mon, 23 Jun 2014 21:38:28 +0400
Subject: <AWT Dev> [9] Review request for 8043869 [macosx] java -splash
 does not honor @2x hi dpi notation for retina support
In-Reply-To: <53A832DB.4020700@oracle.com>
References: <53A0282D.80709@oracle.com>	<F4D88430-7FBA-4D5F-8C63-A34E4AD63220@oracle.com>	<53A04DB9.2060509@oracle.com>
	<D650DAE1-852C-4B7F-B7B2-F03B05F3F6A8@oracle.com>
	<53A05499.4000109@oracle.com> <53A06AFE.5070304@oracle.com>
	<53A18E2C.3090005@oracle.com> <53A19DCA.7090307@oracle.com>
	<53A81575.20107@oracle.com> <53A832DB.4020700@oracle.com>
Message-ID: <53A86614.9070702@oracle.com>

Hi Alexander,

The fix looks good to me, too. However, before you push the fix, please 
revert the order of the first part of the condition at

src/macosx/native/sun/awt/splashscreen/splashscreen_sys.m
>  262         if (0 < scaleFactor && scaleFactor != 1) {

It should read "if (scaleFactor > 0 && ..." instead.

And the same issue at src/share/classes/java/awt/SplashScreen.java:
>  251             if (0 < scale && scale != 1) {

and also at lines 304 and 305 in the same file. Thanks in advance.

--
best regards,
Anthony

On 6/23/2014 5:59 PM, Kumar Srinivasan wrote:
> Hi Alexander,
>
> Looks good to me.
>
>>
>>   Hello,
>>
>>   Could you review the updated fix:
>>      http://cr.openjdk.java.net/~alexsch/8043869/webrev.03/
>>
>>  - a splash screen path that has a dot at the end or does not have a
>> dot at the end is now correctly parsed on Mac OS X
>>  - 0 is changed to NULL in the splashscreen_stubs.c
>>  - dividing by scaleFactor: this parameter is provided by our code,
>> not by splash screen image file (for example it 2 for images
>> splash at 2x.png on Mac OS X).
>>    It should never be zero. However, I have added assert (0 <
>> scaleFactor) and set it to default value in opposite case to be sure
>>    that  the scaleFactor has consistent value.
>>  - I run open and closed launcher/splash screen tests. They passed
>> except one that also fails with jdk without the fix.
>>    The command line splash screen tests should be updated to check
>> Darwin system to be run on Mac OS X.
>
> There are many things wrong with these tests besides Darwin, they also
> don't run on 64-bit solaris I think.
> I thought I filed a bug.
>
> Kumar
>
>>
>>  Thanks,
>>  Alexandr.
>>
>>
>> On 6/18/2014 6:10 PM, Kumar Srinivasan wrote:
>>> Hi Alexander,
>>>
>>> Thanks for making that change in java.c
>>>
>>> splashscreen_stubs.c:
>>>
>>> <Sorry I should have caught this earlier>
>>> I would change the 0 to NULL as as you have already done on line 89...
>>>
>>> 64     INVOKE(SplashLoadMemory,0)(pdata, size);
>>> 68     INVOKE(SplashLoadFile,0)(filename);
>>>
>>> SplashScreen.java:
>>>
>>> Is it possible to get a divide by zero here ? I realize you are
>>> intializing to 1 elsewhere
>>> what happens  if you "read" a zero ? Ex:  What happens if you call
>>> generateImage(0) in the test ?
>>>
>>>  248             float scale = _getScaleFactor(splashPtr);
>>>  249             Rectangle bounds = _getBounds(splashPtr);
>>>  250             if (scale != 1) {
>>>  251                 bounds.setSize((int) (bounds.getWidth() / scale),
>>>  252                         (int) (bounds.getWidth() / scale));
>>>  253             }
>>>  254             return bounds;
>>>
>>>
>>> Should we have some more validations of the input data ? since these
>>> items are
>>> being read from a user generated image file.
>>>
>>> One last thing, I am assuming you have run all the launcher
>>> regressions including the SplashScreen tests in
>>> the jdk/test/closed ?
>>>
>>> Kumar
>>>
>>>
>>>
>>> On 6/18/2014 6:03 AM, Alexander Scherbatiy wrote:
>>>>
>>>>  Hello,
>>>>
>>>>  Could you review the updated fix:
>>>>     http://cr.openjdk.java.net/~alexsch/8043869/webrev.02
>>>>
>>>>   - formatting and CR-LF line endings are fixed
>>>>   - the condition if (1 < screenScaleFactor) is rewritten in
>>>> splashscreen_sys.m file
>>>>   - file_name == NULL chec is added in the java.c
>>>>   - [NSScreen mainScreen] is changed to SplashNSScreen() in the
>>>> SplashGetScaledImageName() from splashscreen_sys.m file
>>>>
>>>> Thanks,
>>>> Alexandr.
>>>>
>>>> On 6/17/2014 8:21 PM, Kumar Srinivasan wrote:
>>>>> Hello,
>>>>>
>>>>> As Anthony already commented, there are some formatting issues
>>>>> throughout, please
>>>>> retain the existing convention and formatting.
>>>>>
>>>>> src/share/bin/java.c
>>>>> at 1822, if you add
>>>>> if (file_name == NULL){
>>>>>     return;
>>>>> }
>>>>> and removing the else, at the bottom we can reduce the indent of
>>>>> the exist if block.
>>>>>
>>>>> make/mapfiles/libsplashscreen/mapfile-vers
>>>>> +1, good to note this, always trips people up.
>>>>>
>>>>>
>>>>> Otherwise looks good.
>>>>>
>>>>> Kumar
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> On 6/17/2014 7:45 AM, Anthony Petrov wrote:
>>>>>> Hi Alexander,
>>>>>>
>>>>>> [ I'm also adding Neil who's taking over the launcher code ]
>>>>>>
>>>>>> 1. There's a few code formatting issues that should be fixed. For
>>>>>> instance:
>>>>>> src/share/bin/java.c
>>>>>>> 1846 if(scaled_splash_name){
>>>>>>> 1853         if(scaled_splash_name){
>>>>>>
>>>>>> src/windows/native/sun/awt/splashscreen/splashscreen_sys.c
>>>>>>>  571     *scaleFactor=1;
>>>>>>
>>>>>> In all the above lines required spaces are missing. I believe
>>>>>> there's a number of other occurrences of the same issue in your
>>>>>> patch. Please check it carefully and fix the formatting on all lines.
>>>>>>
>>>>>> 2. Webrev shows 236 changed lines for java_awt_SplashScreen.c. I
>>>>>> suspect you've changed the EOL characters because you've edited
>>>>>> your code on MS Windows. Please configure your editor to use LF
>>>>>> characters for line ends and revert the unnecessary changes (note
>>>>>> that jcheck won't let you push CR-LF line endings anyway).
>>>>>>
>>>>>> 3. splashscreen_sys.m
>>>>>>>  135     if (1 < screenScaleFactor) {
>>>>>>
>>>>>> For consistency and clarity, I'd suggest to rewrite the condition as
>>>>>>
>>>>>>     if (screenScaleFactor > 1) {
>>>>>>
>>>>>> --
>>>>>> best regards,
>>>>>> Anthony
>>>>>>
>>>>>> On 6/17/2014 6:20 PM, Petr Pchelko wrote:
>>>>>>> Hello, Alexander.
>>>>>>>
>>>>>>>>> 2. In java.c:1859 DoSplashSetFileJarName sets the name of the
>>>>>>>>> file which was used for a splash. It can be
>>>>>>>>> retrieved via public API SplashScreen.getImageURL. Is it
>>>>>>>>> correct to always set the file_name disregards the real
>>>>>>>>> name we've used?
>>>>>>>>
>>>>>>>>     Yes. The original splash screen image name and size are
>>>>>>>> provided for the developer even the high resolution splash
>>>>>>>> screen is shown.
>>>>>>> Thank you for the clarification.
>>>>>>>
>>>>>>> The updated version looks fine to me.
>>>>>>>
>>>>>>> With best regards. Petr.
>>>>>>>
>>>>>>> On 17 ???? 2014 ?., at 18:16, Alexander Scherbatiy
>>>>>>> <alexandr.scherbatiy at oracle.com> wrote:
>>>>>>>
>>>>>>>>
>>>>>>>> Hello,
>>>>>>>>
>>>>>>>> Could you review the updated fix:
>>>>>>>> http://cr.openjdk.java.net/~alexsch/8043869/webrev.01/
>>>>>>>>
>>>>>>>>
>>>>>>>> On 6/17/2014 4:22 PM, Petr Pchelko wrote:
>>>>>>>>> Hello, Alexander.
>>>>>>>>>
>>>>>>>>> CCed Kumar as I believe he's the owner of the launcher code.
>>>>>>>>>
>>>>>>>>> 1. In splashscreen_sys.m you autorelease the fileName. But I do
>>>>>>>>> not see where the autoreleasepool is set up.
>>>>>>>>> Wouldn't it be better to set up an autoreleasepool in this
>>>>>>>>> method explicitly?
>>>>>>>>      NSAutoreleasePool is added.
>>>>>>>>> 2. In java.c:1859 DoSplashSetFileJarName sets the name of the
>>>>>>>>> file which was used for a splash. It can be
>>>>>>>>> retrieved via public API SplashScreen.getImageURL. Is it
>>>>>>>>> correct to always set the file_name disregards the real
>>>>>>>>> name we've used?
>>>>>>>>
>>>>>>>>     Yes. The original splash screen image name and size are
>>>>>>>> provided for the developer even the high resolution splash
>>>>>>>> screen is shown.
>>>>>>>>
>>>>>>>>     Thanks,
>>>>>>>>     Alexandr.
>>>>>>>>> Thank you.
>>>>>>>>> With best regards. Petr.
>>>>>>>>>
>>>>>>>>> On 17 ???? 2014 ?., at 15:36, Alexander Scherbatiy
>>>>>>>>> <alexandr.scherbatiy at oracle.com> wrote:
>>>>>>>>>
>>>>>>>>>> Hello,
>>>>>>>>>>
>>>>>>>>>> Could you review the fix:
>>>>>>>>>>   bug: https://bugs.openjdk.java.net/browse/JDK-8043869
>>>>>>>>>>   webrev: http://cr.openjdk.java.net/~alexsch/8043869/webrev.00
>>>>>>>>>>
>>>>>>>>>>   The scaleFactor field is added to the Splash struct.
>>>>>>>>>>   The SplahsScreen class scales the graphics and the size
>>>>>>>>>> according to the scale factor.
>>>>>>>>>>   The native system tries to load high resolution splash image
>>>>>>>>>> on HiDPI display.
>>>>>>>>>>
>>>>>>>>>> Thanks,
>>>>>>>>>> Alexandr.
>>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>
>>>>
>>>
>>
>

From anthony.petrov at oracle.com  Mon Jun 23 17:50:58 2014
From: anthony.petrov at oracle.com (Anthony Petrov)
Date: Mon, 23 Jun 2014 21:50:58 +0400
Subject: <AWT Dev> [9] Review Request: JDK-8047799 Remove
	WindowClosingSupport
In-Reply-To: <7C886EA2-4BE1-4DCA-8329-C47AC6DC2AA8@oracle.com>
References: <7C886EA2-4BE1-4DCA-8329-C47AC6DC2AA8@oracle.com>
Message-ID: <53A86902.30809@oracle.com>

Looks fine.

Out of curiosity, is the import BooleanSupplier statement in Dialog.java 
only needed to please the compiler when using "() -> true"? Does the 
code not compile w/o the import?

--
best regards,
Anthony

On 6/23/2014 1:46 PM, Petr Pchelko wrote:
> Hello, AWT Team.
>
> Please review a weekly-cleanup fix for the issue:
> https://bugs.openjdk.java.net/browse/JDK-8047799
> The fix is available at:
> http://cr.openjdk.java.net/~pchelko/9/8047799/webrev/
>
> This feature was added for plugin in 1.4. I've grepped the sources and the interfaces and methods are not used any more.
> I've run modality JTREG and checked the test for an original bug, everything seems to work fine. JPRT build succeeds.
>
> With best regards. Petr.
>

From anthony.petrov at oracle.com  Mon Jun 23 17:59:26 2014
From: anthony.petrov at oracle.com (Anthony Petrov)
Date: Mon, 23 Jun 2014 21:59:26 +0400
Subject: <AWT Dev> [9] Review Request: JDK-8047798 Remove
	EventQueueDelegate
In-Reply-To: <6253A33A-C26A-4BDB-AD07-56F433F5DDC5@oracle.com>
References: <B37C1748-191B-4D7B-9C58-2057D24860E5@oracle.com>
	<53A83A65.9030406@oracle.com>
	<6253A33A-C26A-4BDB-AD07-56F433F5DDC5@oracle.com>
Message-ID: <53A86AFE.2030901@oracle.com>

The fix looks fine to me.

> this fix is a reverse-changeset for JDK-6638195

And I assume it also reverses JDK-6699328 ?

--
best regards,
Anthony

On 6/23/2014 6:40 PM, Petr Pchelko wrote:
> Hello, Anthony.
>
> Thank you for the review.
> I've checked that this fix is a reverse-changeset for JDK-6638195 where the class was introduced.
>
> With best regards. Petr.
>
> On 23 ???? 2014 ?., at 18:32, Artem Ananiev <artem.ananiev at oracle.com> wrote:
>
>> Hi, Petr,
>>
>> the fix looks fine to me.
>>
>> I would also suggest you to find the initial fix, when EventQueueDelegate was introduced (in 6u10?), to check if anything else can be wiped out.
>>
>> Thanks,
>>
>> Artem
>>
>> On 6/23/2014 6:13 PM, Petr Pchelko wrote:
>>> Hello, AWT Team.
>>>
>>> Please review the fix for the issue:
>>> https://bugs.openjdk.java.net/browse/JDK-8047798
>>> The fix is available at:
>>> http://cr.openjdk.java.net/~pchelko/9/8047798/webrev/
>>>
>>> One more weekly clenup. The EventQueueDelegate was added for JavaFXScript to manipulate EDT in unconventional ways.
>>> Now it's not used and can be removed. Grepped the sources for the raminings and built a JPRT.
>>>
>>> With best regards. Petr.
>>>
>

From petr.pchelko at oracle.com  Mon Jun 23 18:03:12 2014
From: petr.pchelko at oracle.com (Petr Pchelko)
Date: Mon, 23 Jun 2014 22:03:12 +0400
Subject: <AWT Dev> [9] Review Request: JDK-8047798 Remove
	EventQueueDelegate
In-Reply-To: <53A86AFE.2030901@oracle.com>
References: <B37C1748-191B-4D7B-9C58-2057D24860E5@oracle.com>
	<53A83A65.9030406@oracle.com>
	<6253A33A-C26A-4BDB-AD07-56F433F5DDC5@oracle.com>
	<53A86AFE.2030901@oracle.com>
Message-ID: <82462D9B-84E3-436F-A68D-3FB0BAC61792@oracle.com>

Hello, Anthony.

Thank you for the review.

> And I assume it also reverses JDK-6699328 ?
In a certain way. I?ve deleted all the code where that fix was made.

With best regards. Petr.

> On Jun 23, 2014, at 9:59 PM, Anthony Petrov <anthony.petrov at oracle.com> wrote:
> 
> The fix looks fine to me.
> 
>> this fix is a reverse-changeset for JDK-6638195
> 
> And I assume it also reverses JDK-6699328 ?
> 
> --
> best regards,
> Anthony
> 
> On 6/23/2014 6:40 PM, Petr Pchelko wrote:
>> Hello, Anthony.
>> 
>> Thank you for the review.
>> I've checked that this fix is a reverse-changeset for JDK-6638195 where the class was introduced.
>> 
>> With best regards. Petr.
>> 
>> On 23 ???? 2014 ?., at 18:32, Artem Ananiev <artem.ananiev at oracle.com> wrote:
>> 
>>> Hi, Petr,
>>> 
>>> the fix looks fine to me.
>>> 
>>> I would also suggest you to find the initial fix, when EventQueueDelegate was introduced (in 6u10?), to check if anything else can be wiped out.
>>> 
>>> Thanks,
>>> 
>>> Artem
>>> 
>>> On 6/23/2014 6:13 PM, Petr Pchelko wrote:
>>>> Hello, AWT Team.
>>>> 
>>>> Please review the fix for the issue:
>>>> https://bugs.openjdk.java.net/browse/JDK-8047798
>>>> The fix is available at:
>>>> http://cr.openjdk.java.net/~pchelko/9/8047798/webrev/
>>>> 
>>>> One more weekly clenup. The EventQueueDelegate was added for JavaFXScript to manipulate EDT in unconventional ways.
>>>> Now it's not used and can be removed. Grepped the sources for the raminings and built a JPRT.
>>>> 
>>>> With best regards. Petr.
>>>> 
>> 


From petr.pchelko at oracle.com  Mon Jun 23 18:04:00 2014
From: petr.pchelko at oracle.com (Petr Pchelko)
Date: Mon, 23 Jun 2014 22:04:00 +0400
Subject: <AWT Dev> [9] Review Request: JDK-8047799 Remove
	WindowClosingSupport
In-Reply-To: <53A86902.30809@oracle.com>
References: <7C886EA2-4BE1-4DCA-8329-C47AC6DC2AA8@oracle.com>
	<53A86902.30809@oracle.com>
Message-ID: <1655AE38-8AD4-4D97-BB0C-D20F38360BE4@oracle.com>

Hello, Anthony.

> Out of curiosity, is the import BooleanSupplier statement in Dialog.java only needed to please the compiler when using "() -> true"? Does the code not compile w/o the import?
IDE has put it there for some reason. It?s not needed, I?ll remove it before the push.

With best regards. Petr.

> On Jun 23, 2014, at 9:50 PM, Anthony Petrov <anthony.petrov at oracle.com> wrote:
> 
> Looks fine.
> 
> Out of curiosity, is the import BooleanSupplier statement in Dialog.java only needed to please the compiler when using "() -> true"? Does the code not compile w/o the import?
> 
> --
> best regards,
> Anthony
> 
> On 6/23/2014 1:46 PM, Petr Pchelko wrote:
>> Hello, AWT Team.
>> 
>> Please review a weekly-cleanup fix for the issue:
>> https://bugs.openjdk.java.net/browse/JDK-8047799
>> The fix is available at:
>> http://cr.openjdk.java.net/~pchelko/9/8047799/webrev/
>> 
>> This feature was added for plugin in 1.4. I've grepped the sources and the interfaces and methods are not used any more.
>> I've run modality JTREG and checked the test for an original bug, everything seems to work fine. JPRT build succeeds.
>> 
>> With best regards. Petr.
>> 


From alexander.v.stepanov at oracle.com  Tue Jun 24 08:03:12 2014
From: alexander.v.stepanov at oracle.com (alexander stepanov)
Date: Tue, 24 Jun 2014 12:03:12 +0400
Subject: <AWT Dev> [9] Review request for 8043967: Fix doclint warnings
 for java.awt
In-Reply-To: <6DA06D10-C742-4A7E-98ED-D5C612A471E0@oracle.com>
References: <538DC421.7060204@oracle.com> <538DD3FD.8050909@oracle.com>
	<538DFBF7.3040502@oracle.com> <5397FEB1.2080906@oracle.com>
	<53A7F4D3.1090505@oracle.com>
	<FC104E8A-B5C9-4769-8888-9C2C80398836@oracle.com>
	<53A84C1C.1080107@oracle.com>
	<6DA06D10-C742-4A7E-98ED-D5C612A471E0@oracle.com>
Message-ID: <53A930C0.7010603@oracle.com>

Thanks!

On 23.06.2014 21:13, Petr Pchelko wrote:
> Looks good.
>
> With best regards. Petr.
>
>> On Jun 23, 2014, at 7:47 PM, alexander stepanov <alexander.v.stepanov at oracle.com> wrote:
>>
>> Hello Petr,
>>
>>> AWTKeyStroke why do you use a full name in @throws?
>> In case of short name the following error occurs:
>>
>> /home/user/hd2/doclint/current/src/jdk/src/share/classes/java/awt/AWTKeyStroke.java:805: error: reference not found
>>      * @throws ObjectStreamException if a serialization problem occurs
>>        ^
>> /home/user/hd2/doclint/current/src/jdk/src/share/classes/java/awt/AWTKeyStroke.java:807: warning: no @throws for java.io.ObjectStreamException
>>     protected Object readResolve() throws java.io.ObjectStreamException {
>>                      ^
>>
>> So it seems that javadoc is happy here only if the full exception name is used. It doesn't affect the resulting html.
>>
>> The other notes were fixed, thanks:
>> http://cr.openjdk.java.net/~avstepan/8043967/webrev.02/
>>
>> Regards,
>> Alexander
>>
>>
>> On 23.06.2014 16:58, Petr Pchelko wrote:
>>> Hello, Alexander.
>>>
>>> A couple of comments:
>>>
>>> AWTKeyStroke why do you use a full name in @throws?
>>> HeadlessException.getMessage you could use @inheritDoc here.
>>> KeyboardFocusManager: 1463 Why did you add an extra line here?
>>> Robot: 513 - the line is not aligned
>>>
>>> With best regards. Petr.
>>>
>>> On 23 ???? 2014 ?., at 13:35, alexander stepanov <alexander.v.stepanov at oracle.com> wrote:
>>>
>>>> Sorry, just a reminder.
>>>>> On 03.06.2014 20:46, alexander stepanov wrote:
>>>>>> Hello Sergey,
>>>>>>
>>>>>> Updated; please see
>>>>>> http://cr.openjdk.java.net/~avstepan/8043967/webrev.01/
>>>>>>
>>>>>> Thanks,
>>>>>> Alexander
>>>>>>
>>>>>> On 03.06.2014 17:56, Sergey Bylokhov wrote:
>>>>>>> Hi, Alexander.
>>>>>>> A few notes:
>>>>>>> - Use two spaces after @param tag only. in other cases use one space.
>>>>>>> - Do no align names of the @params tag like this:
>>>>>>>   390      * position will not be replaced).
>>>>>>>   391      * @param   str  the non-{@code null} text to use as
>>>>>>>   392      *               the replacement
>>>>>>>   393      * @param   start  the start position
>>>>>>>   394      * @param   end    the end position
>>>>>>>   395      * @deprecated As of JDK version 1.1,
>>>>>>> Change them to:
>>>>>>>   390      * position will not be replaced).
>>>>>>>   391      * @param  str the non-{@code null} text to use as
>>>>>>>   392      *         the replacement
>>>>>>>   393      * @param  start the start position
>>>>>>>   394      * @param  end the end position
>>>>>>>   395      * @deprecated As of JDK version 1.1,
>>>>>>>   - Add empty line after method description before @param tag.
>>>>>>>   - Description of the method should ends by dot.
>>>>>>>
>>>>>>> On 6/3/14 4:48 PM, alexander stepanov wrote:
>>>>>>>> Hello,
>>>>>>>>
>>>>>>>> Could you please review the fix for the following bug:
>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8043967
>>>>>>>>
>>>>>>>> Webrev:
>>>>>>>> http://cr.openjdk.java.net/~avstepan/8043967
>>>>>>>>
>>>>>>>> Just a cleanup of javadoc to avoid doclint warnings.
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>> Alexander
>>>>>>> -- 
>>>>>>> Best regards, Sergey.


From anthony.petrov at oracle.com  Tue Jun 24 11:33:49 2014
From: anthony.petrov at oracle.com (Anthony Petrov)
Date: Tue, 24 Jun 2014 15:33:49 +0400
Subject: <AWT Dev> [9] Review Request: JDK-8047799 Remove
	WindowClosingSupport
In-Reply-To: <1655AE38-8AD4-4D97-BB0C-D20F38360BE4@oracle.com>
References: <7C886EA2-4BE1-4DCA-8329-C47AC6DC2AA8@oracle.com>
	<53A86902.30809@oracle.com>
	<1655AE38-8AD4-4D97-BB0C-D20F38360BE4@oracle.com>
Message-ID: <53A9621D.2000009@oracle.com>

Thanks!

--
best regards,
Anthony

On 6/23/2014 10:04 PM, Petr Pchelko wrote:
> Hello, Anthony.
>
>> Out of curiosity, is the import BooleanSupplier statement in Dialog.java only needed to please the compiler when using "() -> true"? Does the code not compile w/o the import?
> IDE has put it there for some reason. It?s not needed, I?ll remove it before the push.
>
> With best regards. Petr.
>
>> On Jun 23, 2014, at 9:50 PM, Anthony Petrov <anthony.petrov at oracle.com> wrote:
>>
>> Looks fine.
>>
>> Out of curiosity, is the import BooleanSupplier statement in Dialog.java only needed to please the compiler when using "() -> true"? Does the code not compile w/o the import?
>>
>> --
>> best regards,
>> Anthony
>>
>> On 6/23/2014 1:46 PM, Petr Pchelko wrote:
>>> Hello, AWT Team.
>>>
>>> Please review a weekly-cleanup fix for the issue:
>>> https://bugs.openjdk.java.net/browse/JDK-8047799
>>> The fix is available at:
>>> http://cr.openjdk.java.net/~pchelko/9/8047799/webrev/
>>>
>>> This feature was added for plugin in 1.4. I've grepped the sources and the interfaces and methods are not used any more.
>>> I've run modality JTREG and checked the test for an original bug, everything seems to work fine. JPRT build succeeds.
>>>
>>> With best regards. Petr.
>>>
>

From petr.pchelko at oracle.com  Thu Jun 26 09:12:38 2014
From: petr.pchelko at oracle.com (Petr Pchelko)
Date: Thu, 26 Jun 2014 13:12:38 +0400
Subject: <AWT Dev> [9] Review Request: JDK-8047799 Remove
	WindowClosingSupport
In-Reply-To: <53A9621D.2000009@oracle.com>
References: <7C886EA2-4BE1-4DCA-8329-C47AC6DC2AA8@oracle.com>
	<53A86902.30809@oracle.com>
	<1655AE38-8AD4-4D97-BB0C-D20F38360BE4@oracle.com>
	<53A9621D.2000009@oracle.com>
Message-ID: <7445B86E-E7FB-4982-942E-797F40EB7879@oracle.com>

Hello,

Please review the updated version: http://cr.openjdk.java.net/~pchelko/9/8047799/webrev.01/

I've removed the unused import as Anthony suggested.
Also the Component.windowClosingException is not used any more, so the variable was removed.

With best regards. Petr.

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

> Thanks!
> 
> --
> best regards,
> Anthony
> 
> On 6/23/2014 10:04 PM, Petr Pchelko wrote:
>> Hello, Anthony.
>> 
>>> Out of curiosity, is the import BooleanSupplier statement in Dialog.java only needed to please the compiler when using "() -> true"? Does the code not compile w/o the import?
>> IDE has put it there for some reason. It?s not needed, I?ll remove it before the push.
>> 
>> With best regards. Petr.
>> 
>>> On Jun 23, 2014, at 9:50 PM, Anthony Petrov <anthony.petrov at oracle.com> wrote:
>>> 
>>> Looks fine.
>>> 
>>> Out of curiosity, is the import BooleanSupplier statement in Dialog.java only needed to please the compiler when using "() -> true"? Does the code not compile w/o the import?
>>> 
>>> --
>>> best regards,
>>> Anthony
>>> 
>>> On 6/23/2014 1:46 PM, Petr Pchelko wrote:
>>>> Hello, AWT Team.
>>>> 
>>>> Please review a weekly-cleanup fix for the issue:
>>>> https://bugs.openjdk.java.net/browse/JDK-8047799
>>>> The fix is available at:
>>>> http://cr.openjdk.java.net/~pchelko/9/8047799/webrev/
>>>> 
>>>> This feature was added for plugin in 1.4. I've grepped the sources and the interfaces and methods are not used any more.
>>>> I've run modality JTREG and checked the test for an original bug, everything seems to work fine. JPRT build succeeds.
>>>> 
>>>> With best regards. Petr.
>>>> 
>> 


From alexandr.scherbatiy at oracle.com  Thu Jun 26 09:20:07 2014
From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy)
Date: Thu, 26 Jun 2014 13:20:07 +0400
Subject: <AWT Dev> [9] Review Request: JDK-8047799 Remove
	WindowClosingSupport
In-Reply-To: <7445B86E-E7FB-4982-942E-797F40EB7879@oracle.com>
References: <7C886EA2-4BE1-4DCA-8329-C47AC6DC2AA8@oracle.com>
	<53A86902.30809@oracle.com>
	<1655AE38-8AD4-4D97-BB0C-D20F38360BE4@oracle.com>
	<53A9621D.2000009@oracle.com>
	<7445B86E-E7FB-4982-942E-797F40EB7879@oracle.com>
Message-ID: <53ABE5C7.1090100@oracle.com>


   The fix looks good to me.

   Thanks,
   Alexandr.

On 6/26/2014 1:12 PM, Petr Pchelko wrote:
> Hello,
>
> Please review the updated version: http://cr.openjdk.java.net/~pchelko/9/8047799/webrev.01/
>
> I've removed the unused import as Anthony suggested.
> Also the Component.windowClosingException is not used any more, so the variable was removed.
>
> With best regards. Petr.
>
> On 24 ???? 2014 ?., at 15:33, Anthony Petrov <anthony.petrov at oracle.com> wrote:
>
>> Thanks!
>>
>> --
>> best regards,
>> Anthony
>>
>> On 6/23/2014 10:04 PM, Petr Pchelko wrote:
>>> Hello, Anthony.
>>>
>>>> Out of curiosity, is the import BooleanSupplier statement in Dialog.java only needed to please the compiler when using "() -> true"? Does the code not compile w/o the import?
>>> IDE has put it there for some reason. It?s not needed, I?ll remove it before the push.
>>>
>>> With best regards. Petr.
>>>
>>>> On Jun 23, 2014, at 9:50 PM, Anthony Petrov <anthony.petrov at oracle.com> wrote:
>>>>
>>>> Looks fine.
>>>>
>>>> Out of curiosity, is the import BooleanSupplier statement in Dialog.java only needed to please the compiler when using "() -> true"? Does the code not compile w/o the import?
>>>>
>>>> --
>>>> best regards,
>>>> Anthony
>>>>
>>>> On 6/23/2014 1:46 PM, Petr Pchelko wrote:
>>>>> Hello, AWT Team.
>>>>>
>>>>> Please review a weekly-cleanup fix for the issue:
>>>>> https://bugs.openjdk.java.net/browse/JDK-8047799
>>>>> The fix is available at:
>>>>> http://cr.openjdk.java.net/~pchelko/9/8047799/webrev/
>>>>>
>>>>> This feature was added for plugin in 1.4. I've grepped the sources and the interfaces and methods are not used any more.
>>>>> I've run modality JTREG and checked the test for an original bug, everything seems to work fine. JPRT build succeeds.
>>>>>
>>>>> With best regards. Petr.
>>>>>


From anthony.petrov at oracle.com  Thu Jun 26 10:10:58 2014
From: anthony.petrov at oracle.com (Anthony Petrov)
Date: Thu, 26 Jun 2014 14:10:58 +0400
Subject: <AWT Dev> [9] Review Request: JDK-8047799 Remove
	WindowClosingSupport
In-Reply-To: <7445B86E-E7FB-4982-942E-797F40EB7879@oracle.com>
References: <7C886EA2-4BE1-4DCA-8329-C47AC6DC2AA8@oracle.com>	<53A86902.30809@oracle.com>	<1655AE38-8AD4-4D97-BB0C-D20F38360BE4@oracle.com>	<53A9621D.2000009@oracle.com>
	<7445B86E-E7FB-4982-942E-797F40EB7879@oracle.com>
Message-ID: <53ABF1B2.9010305@oracle.com>

> I've removed the unused import as Anthony suggested.

http://cr.openjdk.java.net/~pchelko/9/8047799/webrev.01/src/share/classes/java/awt/Dialog.java.sdiff.html
>  43 import java.util.function.BooleanSupplier;

Kinda haven't... :)


Although the rest of the fix still looks good to me.

--
best regards,
Anthony

On 6/26/2014 1:12 PM, Petr Pchelko wrote:
> Hello,
>
> Please review the updated version: http://cr.openjdk.java.net/~pchelko/9/8047799/webrev.01/
>
> I've removed the unused import as Anthony suggested.
> Also the Component.windowClosingException is not used any more, so the variable was removed.
>
> With best regards. Petr.
>
> On 24 ???? 2014 ?., at 15:33, Anthony Petrov <anthony.petrov at oracle.com> wrote:
>
>> Thanks!
>>
>> --
>> best regards,
>> Anthony
>>
>> On 6/23/2014 10:04 PM, Petr Pchelko wrote:
>>> Hello, Anthony.
>>>
>>>> Out of curiosity, is the import BooleanSupplier statement in Dialog.java only needed to please the compiler when using "() -> true"? Does the code not compile w/o the import?
>>> IDE has put it there for some reason. It?s not needed, I?ll remove it before the push.
>>>
>>> With best regards. Petr.
>>>
>>>> On Jun 23, 2014, at 9:50 PM, Anthony Petrov <anthony.petrov at oracle.com> wrote:
>>>>
>>>> Looks fine.
>>>>
>>>> Out of curiosity, is the import BooleanSupplier statement in Dialog.java only needed to please the compiler when using "() -> true"? Does the code not compile w/o the import?
>>>>
>>>> --
>>>> best regards,
>>>> Anthony
>>>>
>>>> On 6/23/2014 1:46 PM, Petr Pchelko wrote:
>>>>> Hello, AWT Team.
>>>>>
>>>>> Please review a weekly-cleanup fix for the issue:
>>>>> https://bugs.openjdk.java.net/browse/JDK-8047799
>>>>> The fix is available at:
>>>>> http://cr.openjdk.java.net/~pchelko/9/8047799/webrev/
>>>>>
>>>>> This feature was added for plugin in 1.4. I've grepped the sources and the interfaces and methods are not used any more.
>>>>> I've run modality JTREG and checked the test for an original bug, everything seems to work fine. JPRT build succeeds.
>>>>>
>>>>> With best regards. Petr.
>>>>>
>>>
>

From kb at jetbrains.com  Thu Jun 26 12:15:36 2014
From: kb at jetbrains.com (Konstantin Bulenkov)
Date: Thu, 26 Jun 2014 16:15:36 +0400
Subject: <AWT Dev> nativeGetCursorPosition() locks EDT
Message-ID: <09AFBBDE-FC8D-486E-95D3-034D6418CA07@jetbrains.com>

Hi, 

After switching to 1.8.0_20-ea-b19 x86_64 (Mac OS X 10.9.3) I got EDT locked very often in my desktop application (IntelliJ IDEA). I don?t have this problem in stable versions of 1.8/1.7

Symptoms: EDT stops responding 
Could you please take a look? Looks like regression. Here is the stack trace:

"JobScheduler FJ pool 0/4" prio=0 tid=0x0 nid=0x0 waiting on condition
     java.lang.Thread.State: TIMED_WAITING
 on jsr166e.ForkJoinPool at 1e356543
	at sun.misc.Unsafe.park(Native Method)
	at jsr166e.ForkJoinPool.awaitWork(ForkJoinPool.java:1756)
	at jsr166e.ForkJoinPool.scan(ForkJoinPool.java:1694)
	at jsr166e.ForkJoinPool.runWorker(ForkJoinPool.java:1642)
	at jsr166e.ForkJoinWorkerThread.run(ForkJoinWorkerThread.java:109)

"YJPAgent-OOMESnapshotDetector" prio=0 tid=0x0 nid=0x0 runnable
     java.lang.Thread.State: RUNNABLE
 (in native)

"YJPAgent-CPUSampler" prio=0 tid=0x0 nid=0x0 runnable
     java.lang.Thread.State: RUNNABLE


"YJPAgent-RequestListener" prio=0 tid=0x0 nid=0x0 runnable
     java.lang.Thread.State: RUNNABLE
 (in native)
	at java.net.PlainSocketImpl.socketAccept(Native Method)
	at java.net.AbstractPlainSocketImpl.accept(AbstractPlainSocketImpl.java:404)
	at java.net.ServerSocket.implAccept(ServerSocket.java:545)
	at java.net.ServerSocket.accept(ServerSocket.java:513)
	at com.yourkit.runtime.Core$4.run(Core.java:710)
	at java.lang.Thread.null(Unknown Source)

"YJPAgent-Telemetry" prio=0 tid=0x0 nid=0x0 waiting on condition
     java.lang.Thread.State: TIMED_WAITING

	at java.lang.Thread.sleep(Native Method)
	at com.yourkit.util.Util.sleep(Util.java:55)
	at com.yourkit.runtime.TelemetryThread.run(TelemetryThread.java:541)

"Attach Listener" prio=0 tid=0x0 nid=0x0 runnable
     java.lang.Thread.State: RUNNABLE


"ApplicationImpl pooled thread 87" prio=0 tid=0x0 nid=0x0 waiting on condition
     java.lang.Thread.State: TIMED_WAITING
 on java.util.concurrent.SynchronousQueue$TransferStack at 667921bf
	at sun.misc.Unsafe.park(Native Method)
	at java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215)
	at java.util.concurrent.SynchronousQueue$TransferStack.awaitFulfill(SynchronousQueue.java:460)
	at java.util.concurrent.SynchronousQueue$TransferStack.transfer(SynchronousQueue.java:362)
	at java.util.concurrent.SynchronousQueue.poll(SynchronousQueue.java:941)
	at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1066)
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1127)
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
	at java.lang.Thread.null(Unknown Source)
	at com.intellij.openapi.application.impl.ApplicationImpl$1$1.run(ApplicationImpl.java:149)

"ApplicationImpl pooled thread 85" prio=0 tid=0x0 nid=0x0 waiting on condition
     java.lang.Thread.State: TIMED_WAITING
 on java.util.concurrent.SynchronousQueue$TransferStack at 667921bf
	at sun.misc.Unsafe.park(Native Method)
	at java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215)
	at java.util.concurrent.SynchronousQueue$TransferStack.awaitFulfill(SynchronousQueue.java:460)
	at java.util.concurrent.SynchronousQueue$TransferStack.transfer(SynchronousQueue.java:362)
	at java.util.concurrent.SynchronousQueue.poll(SynchronousQueue.java:941)
	at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1066)
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1127)
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
	at java.lang.Thread.null(Unknown Source)
	at com.intellij.openapi.application.impl.ApplicationImpl$1$1.run(ApplicationImpl.java:149)

"ApplicationImpl pooled thread 84" prio=0 tid=0x0 nid=0x0 waiting on condition
     java.lang.Thread.State: TIMED_WAITING
 on java.util.concurrent.SynchronousQueue$TransferStack at 667921bf
	at sun.misc.Unsafe.park(Native Method)
	at java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215)
	at java.util.concurrent.SynchronousQueue$TransferStack.awaitFulfill(SynchronousQueue.java:460)
	at java.util.concurrent.SynchronousQueue$TransferStack.transfer(SynchronousQueue.java:362)
	at java.util.concurrent.SynchronousQueue.poll(SynchronousQueue.java:941)
	at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1066)
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1127)
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
	at java.lang.Thread.null(Unknown Source)
	at com.intellij.openapi.application.impl.ApplicationImpl$1$1.run(ApplicationImpl.java:149)

"ApplicationImpl pooled thread 83" prio=0 tid=0x0 nid=0x0 waiting on condition
     java.lang.Thread.State: TIMED_WAITING
 on java.util.concurrent.SynchronousQueue$TransferStack at 667921bf
	at sun.misc.Unsafe.park(Native Method)
	at java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215)
	at java.util.concurrent.SynchronousQueue$TransferStack.awaitFulfill(SynchronousQueue.java:460)
	at java.util.concurrent.SynchronousQueue$TransferStack.transfer(SynchronousQueue.java:362)
	at java.util.concurrent.SynchronousQueue.poll(SynchronousQueue.java:941)
	at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1066)
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1127)
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
	at java.lang.Thread.null(Unknown Source)
	at com.intellij.openapi.application.impl.ApplicationImpl$1$1.run(ApplicationImpl.java:149)

"ApplicationImpl pooled thread 81" prio=0 tid=0x0 nid=0x0 waiting on condition
     java.lang.Thread.State: TIMED_WAITING
 on java.util.concurrent.SynchronousQueue$TransferStack at 667921bf
	at sun.misc.Unsafe.park(Native Method)
	at java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215)
	at java.util.concurrent.SynchronousQueue$TransferStack.awaitFulfill(SynchronousQueue.java:460)
	at java.util.concurrent.SynchronousQueue$TransferStack.transfer(SynchronousQueue.java:362)
	at java.util.concurrent.SynchronousQueue.poll(SynchronousQueue.java:941)
	at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1066)
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1127)
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
	at java.lang.Thread.null(Unknown Source)
	at com.intellij.openapi.application.impl.ApplicationImpl$1$1.run(ApplicationImpl.java:149)

"Action Updater" prio=0 tid=0x0 nid=0x0 waiting on condition
     java.lang.Thread.State: WAITING
 on java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject at 6c9990ec
	at sun.misc.Unsafe.park(Native Method)
	at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
	at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039)
	at java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:442)
	at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1067)
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1127)
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
	at java.lang.Thread.null(Unknown Source)

"globalEventExecutor-1-3" prio=0 tid=0x0 nid=0x0 waiting on condition
     java.lang.Thread.State: TIMED_WAITING
 on java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject at e8a4982
	at sun.misc.Unsafe.park(Native Method)
	at java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215)
	at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(AbstractQueuedSynchronizer.java:2078)
	at java.util.concurrent.LinkedBlockingQueue.poll(LinkedBlockingQueue.java:467)
	at io.netty.util.concurrent.GlobalEventExecutor.takeTask(GlobalEventExecutor.java:89)
	at io.netty.util.concurrent.GlobalEventExecutor$TaskRunner.run(GlobalEventExecutor.java:318)
	at java.lang.Thread.null(Unknown Source)

"RefCountingStorage write content helper" prio=0 tid=0x0 nid=0x0 waiting on condition
     java.lang.Thread.State: WAITING
 on java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject at 4eb490de
	at sun.misc.Unsafe.park(Native Method)
	at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
	at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039)
	at java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:442)
	at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1067)
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1127)
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
	at java.lang.Thread.null(Unknown Source)

"File type re-detect" prio=0 tid=0x0 nid=0x0 waiting on condition
     java.lang.Thread.State: WAITING
 on java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject at 68ecdc47
	at sun.misc.Unsafe.park(Native Method)
	at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
	at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039)
	at java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:1081)
	at java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:809)
	at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1067)
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1127)
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
	at java.lang.Thread.null(Unknown Source)

"FS Synchronizer" prio=0 tid=0x0 nid=0x0 waiting on condition
     java.lang.Thread.State: WAITING
 on java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject at 3e6f0bdd
	at sun.misc.Unsafe.park(Native Method)
	at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
	at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039)
	at java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:442)
	at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1067)
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1127)
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
	at java.lang.Thread.null(Unknown Source)

"Change List Updater" prio=0 tid=0x0 nid=0x0 waiting on condition
     java.lang.Thread.State: WAITING
 on java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject at 7021b508
	at sun.misc.Unsafe.park(Native Method)
	at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
	at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039)
	at java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:1081)
	at java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:809)
	at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1067)
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1127)
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
	at java.lang.Thread.null(Unknown Source)

"EditorNotifications executor" prio=0 tid=0x0 nid=0x0 waiting on condition
     java.lang.Thread.State: WAITING
 on java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject at 40daf476
	at sun.misc.Unsafe.park(Native Method)
	at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
	at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039)
	at java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:442)
	at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1067)
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1127)
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
	at java.lang.Thread.null(Unknown Source)

"ApplicationImpl pooled thread 8" prio=0 tid=0x0 nid=0x0 runnable
     java.lang.Thread.State: RUNNABLE
 (in native)
	at sun.nio.ch.KQueueArrayWrapper.kevent0(Native Method)
	at sun.nio.ch.KQueueArrayWrapper.poll(KQueueArrayWrapper.java:198)
	at sun.nio.ch.KQueueSelectorImpl.doSelect(KQueueSelectorImpl.java:103)
	at sun.nio.ch.SelectorImpl.lockAndDoSelect(SelectorImpl.java:86)
	at sun.nio.ch.SelectorImpl.select(SelectorImpl.java:97)
	at io.netty.channel.nio.NioEventLoop.select(NioEventLoop.java:618)
	at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:306)
	at io.netty.util.concurrent.SingleThreadEventExecutor$5.run(SingleThreadEventExecutor.java:824)
	at com.intellij.openapi.application.impl.ApplicationImpl$9.run(ApplicationImpl.java:446)
	at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
	at java.util.concurrent.FutureTask.run(FutureTask.java:266)
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
	at java.lang.Thread.null(Unknown Source)
	at com.intellij.openapi.application.impl.ApplicationImpl$1$1.run(ApplicationImpl.java:149)

"Encoding detection thread" prio=0 tid=0x0 nid=0x0 waiting on condition
     java.lang.Thread.State: WAITING
 on java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject at 685d1c9c
	at sun.misc.Unsafe.park(Native Method)
	at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
	at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039)
	at java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:1081)
	at java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:809)
	at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1067)
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1127)
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
	at java.lang.Thread.null(Unknown Source)

"Document commit thread" prio=0 tid=0x0 nid=0x0 waiting on condition
     java.lang.Thread.State: WAITING
 on com.intellij.util.containers.Queue at 7ab56c4
	at java.lang.Object.wait(Native Method)
	at java.lang.Object.wait(Object.java:502)
	at com.intellij.psi.impl.DocumentCommitThread.pollQueue(DocumentCommitThread.java:262)
	at com.intellij.psi.impl.DocumentCommitThread.run(DocumentCommitThread.java:238)
	at java.lang.Thread.null(Unknown Source)

"TimerQueue" prio=0 tid=0x0 nid=0x0 waiting on condition
     java.lang.Thread.State: TIMED_WAITING
 on java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject at 10457b03
	at sun.misc.Unsafe.park(Native Method)
	at java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215)
	at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(AbstractQueuedSynchronizer.java:2078)
	at java.util.concurrent.DelayQueue.take(DelayQueue.java:223)
	at javax.swing.TimerQueue.run(TimerQueue.java:171)
	at java.lang.Thread.null(Unknown Source)

"Alarm pool(shared)" prio=0 tid=0x0 nid=0x0 waiting on condition
     java.lang.Thread.State: WAITING
 on java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject at 602951d2
	at sun.misc.Unsafe.park(Native Method)
	at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
	at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039)
	at java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:442)
	at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1067)
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1127)
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
	at java.lang.Thread.null(Unknown Source)

"Animations" prio=0 tid=0x0 nid=0x0 waiting on condition
     java.lang.Thread.State: TIMED_WAITING
 on java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject at 609008b7
	at sun.misc.Unsafe.park(Native Method)
	at java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215)
	at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(AbstractQueuedSynchronizer.java:2078)
	at java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:1093)
	at java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:809)
	at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1067)
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1127)
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
	at java.lang.Thread.null(Unknown Source)

"FocusManager timer" prio=0 tid=0x0 nid=0x0 waiting on condition
     java.lang.Thread.State: WAITING
 on java.util.TaskQueue at 3d507f17
	at java.lang.Object.wait(Native Method)
	at java.lang.Object.wait(Object.java:502)
	at java.util.TimerThread.mainLoop(Timer.java:526)
	at java.util.TimerThread.run(Timer.java:505)

"Shared SimpleTimer" prio=0 tid=0x0 nid=0x0 waiting on condition
     java.lang.Thread.State: WAITING
 on java.util.TaskQueue at 6f686dd
	at java.lang.Object.wait(Native Method)
	at java.lang.Object.wait(Object.java:502)
	at java.util.TimerThread.mainLoop(Timer.java:526)
	at java.util.TimerThread.run(Timer.java:505)

"Performance watcher" prio=0 tid=0x0 nid=0x0 runnable
     java.lang.Thread.State: RUNNABLE

	at sun.management.ThreadImpl.dumpThreads0(Native Method)
	at sun.management.ThreadImpl.dumpAllThreads(ThreadImpl.java:446)
	at com.intellij.diagnostic.ThreadDumper.dumpThreadsToFile(ThreadDumper.java:47)
	at com.intellij.diagnostic.PerformanceWatcher.dumpThreads(PerformanceWatcher.java:219)
	at com.intellij.diagnostic.PerformanceWatcher.checkEDTResponsiveness(PerformanceWatcher.java:172)
	at com.intellij.diagnostic.PerformanceWatcher.access$100(PerformanceWatcher.java:40)
	at com.intellij.diagnostic.PerformanceWatcher$2.run(PerformanceWatcher.java:113)
	at java.lang.Thread.null(Unknown Source)

"ApplicationImpl pooled thread 3" prio=0 tid=0x0 nid=0x0 runnable
     java.lang.Thread.State: RUNNABLE
 (in native)
	at sun.nio.ch.KQueueArrayWrapper.kevent0(Native Method)
	at sun.nio.ch.KQueueArrayWrapper.poll(KQueueArrayWrapper.java:198)
	at sun.nio.ch.KQueueSelectorImpl.doSelect(KQueueSelectorImpl.java:103)
	at sun.nio.ch.SelectorImpl.lockAndDoSelect(SelectorImpl.java:86)
	at sun.nio.ch.SelectorImpl.select(SelectorImpl.java:97)
	at io.netty.channel.nio.NioEventLoop.select(NioEventLoop.java:618)
	at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:306)
	at io.netty.util.concurrent.SingleThreadEventExecutor$5.run(SingleThreadEventExecutor.java:824)
	at com.intellij.openapi.application.impl.ApplicationImpl$9.run(ApplicationImpl.java:446)
	at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
	at java.util.concurrent.FutureTask.run(FutureTask.java:266)
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
	at java.lang.Thread.null(Unknown Source)
	at com.intellij.openapi.application.impl.ApplicationImpl$1$1.run(ApplicationImpl.java:149)

"StoreRefreshStatusThread" prio=0 tid=0x0 nid=0x0 waiting on condition
     java.lang.Thread.State: TIMED_WAITING

	at java.lang.Thread.sleep(Native Method)
	at com.intellij.util.TimeoutUtil.sleep(TimeoutUtil.java:58)
	at com.intellij.openapi.vfs.impl.local.LocalFileSystemImpl$StoreRefreshStatusThread.run(LocalFileSystemImpl.java:355)

"ApplicationImpl pooled thread 2" prio=0 tid=0x0 nid=0x0 waiting on condition
     java.lang.Thread.State: TIMED_WAITING

	at java.lang.Thread.sleep(Native Method)
	at com.intellij.util.TimeoutUtil.sleep(TimeoutUtil.java:58)
	at com.intellij.util.io.BaseDataReader.doRun(BaseDataReader.java:105)
	at com.intellij.util.io.BaseDataReader$1.run(BaseDataReader.java:46)
	at com.intellij.openapi.application.impl.ApplicationImpl$9.run(ApplicationImpl.java:446)
	at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
	at java.util.concurrent.FutureTask.run(FutureTask.java:266)
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
	at java.lang.Thread.null(Unknown Source)
	at com.intellij.openapi.application.impl.ApplicationImpl$1$1.run(ApplicationImpl.java:149)

"ApplicationImpl pooled thread 1" prio=0 tid=0x0 nid=0x0 waiting on condition
     java.lang.Thread.State: TIMED_WAITING

	at java.lang.Thread.sleep(Native Method)
	at com.intellij.util.TimeoutUtil.sleep(TimeoutUtil.java:58)
	at com.intellij.util.io.BaseDataReader.doRun(BaseDataReader.java:105)
	at com.intellij.util.io.BaseDataReader$1.run(BaseDataReader.java:46)
	at com.intellij.openapi.application.impl.ApplicationImpl$9.run(ApplicationImpl.java:446)
	at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
	at java.util.concurrent.FutureTask.run(FutureTask.java:266)
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
	at java.lang.Thread.null(Unknown Source)
	at com.intellij.openapi.application.impl.ApplicationImpl$1$1.run(ApplicationImpl.java:149)

"ApplicationImpl pooled thread 0" prio=0 tid=0x0 nid=0x0 waiting on condition
     java.lang.Thread.State: WAITING
 on java.lang.UNIXProcess at 4c4e9088
	at java.lang.Object.wait(Native Method)
	at java.lang.Object.wait(Object.java:502)
	at java.lang.UNIXProcess.null(Unknown Source)
	at com.intellij.execution.process.ProcessWaitFor$1.run(ProcessWaitFor.java:30)
	at com.intellij.openapi.application.impl.ApplicationImpl$9.run(ApplicationImpl.java:446)
	at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
	at java.util.concurrent.FutureTask.run(FutureTask.java:266)
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
	at java.lang.Thread.null(Unknown Source)
	at com.intellij.openapi.application.impl.ApplicationImpl$1$1.run(ApplicationImpl.java:149)

"process reaper" prio=0 tid=0x0 nid=0x0 runnable
     java.lang.Thread.State: RUNNABLE
 (in native)
	at java.lang.UNIXProcess.waitForProcessExit(Native Method)
	at java.lang.UNIXProcess.null(Unknown Source)
	at java.lang.UNIXProcess$4.run(UNIXProcess.java:226)
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
	at java.lang.Thread.null(Unknown Source)

"Flushing thread" prio=0 tid=0x0 nid=0x0 waiting on condition
     java.lang.Thread.State: TIMED_WAITING
 on java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject at 7258e6d1
	at sun.misc.Unsafe.park(Native Method)
	at java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215)
	at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(AbstractQueuedSynchronizer.java:2078)
	at java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:1093)
	at java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:809)
	at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1067)
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1127)
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
	at java.lang.Thread.null(Unknown Source)

"ZipFileCache Dispose" prio=0 tid=0x0 nid=0x0 waiting on condition
     java.lang.Thread.State: TIMED_WAITING
 on java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject at 402a4629
	at sun.misc.Unsafe.park(Native Method)
	at java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215)
	at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(AbstractQueuedSynchronizer.java:2078)
	at java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:1093)
	at java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:809)
	at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1067)
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1127)
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
	at java.lang.Thread.null(Unknown Source)

"Periodic tasks thread" prio=0 tid=0x0 nid=0x0 waiting on condition
     java.lang.Thread.State: TIMED_WAITING
 on java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject at 33a2c55c
	at sun.misc.Unsafe.park(Native Method)
	at java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215)
	at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(AbstractQueuedSynchronizer.java:2078)
	at java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:1093)
	at java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:809)
	at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1067)
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1127)
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
	at java.lang.Thread.null(Unknown Source)

"AWT-EventQueue-0 14.0#IU-138.SNAPSHOT, eap:true" prio=0 tid=0x0 nid=0x0 runnable
     java.lang.Thread.State: RUNNABLE
 (in native)
	at sun.lwawt.macosx.CCursorManager.nativeGetCursorPosition(Native Method)
	at sun.lwawt.macosx.CCursorManager.getCursorPosition(CCursorManager.java:54)
	at sun.lwawt.LWCursorManager.updateCursorImpl(LWCursorManager.java:80)
	at sun.lwawt.LWCursorManager.updateCursor(LWCursorManager.java:57)
	at sun.lwawt.LWComponentPeer.updateCursorImmediately(LWComponentPeer.java:894)
	at java.awt.Component.updateCursorImmediately(Component.java:3137)
	at java.awt.Container.validate(Container.java:1640)
	at javax.swing.CellRendererPane.paintComponent(CellRendererPane.java:140)
	at com.intellij.util.ui.tree.WideSelectionTreeUI$4.paintComponent(WideSelectionTreeUI.java:439)
	at javax.swing.plaf.basic.BasicTreeUI.paintRow(BasicTreeUI.java:1540)
	at com.intellij.util.ui.tree.WideSelectionTreeUI.paintRow(WideSelectionTreeUI.java:382)
	at javax.swing.plaf.basic.BasicTreeUI.paint(BasicTreeUI.java:1224)
	at com.intellij.util.ui.tree.WideSelectionTreeUI.paint(WideSelectionTreeUI.java:410)
	at javax.swing.plaf.ComponentUI.update(ComponentUI.java:161)
	at javax.swing.JComponent.paintComponent(JComponent.java:777)
	at com.intellij.ui.treeStructure.Tree.paintComponent(Tree.java:328)
	at javax.swing.JComponent.paint(JComponent.java:1053)
	at com.intellij.ui.treeStructure.Tree.paint(Tree.java:244)
	at javax.swing.JComponent.paintChildren(JComponent.java:886)
	at javax.swing.JComponent.paint(JComponent.java:1062)
	at javax.swing.JViewport.paint(JViewport.java:744)
	at com.intellij.ui.components.JBViewport.paint(JBViewport.java:119)
	at javax.swing.JComponent.paintChildren(JComponent.java:886)
	at javax.swing.JComponent.paint(JComponent.java:1062)
	at javax.swing.JComponent.paintChildren(JComponent.java:886)
	at javax.swing.JComponent.paint(JComponent.java:1062)
	at javax.swing.JComponent.paintChildren(JComponent.java:886)
	at javax.swing.JComponent.paint(JComponent.java:1062)
	at javax.swing.JComponent.paintChildren(JComponent.java:886)
	at com.intellij.ui.tabs.impl.JBTabsImpl.paintChildren(JBTabsImpl.java:2271)
	at javax.swing.JComponent.paint(JComponent.java:1062)
	at com.intellij.ui.tabs.impl.JBTabsImpl.paint(JBTabsImpl.java:2266)
	at javax.swing.JComponent.paintChildren(JComponent.java:886)
	at javax.swing.JComponent.paint(JComponent.java:1062)
	at javax.swing.JComponent.paintChildren(JComponent.java:886)
	at javax.swing.JComponent.paint(JComponent.java:1062)
	at javax.swing.JComponent.paintChildren(JComponent.java:886)
	at javax.swing.JComponent.paint(JComponent.java:1062)
	at javax.swing.JComponent.paintChildren(JComponent.java:886)
	at javax.swing.JComponent.paint(JComponent.java:1062)
	at javax.swing.JComponent.paintChildren(JComponent.java:886)
	at com.intellij.ui.tabs.impl.JBTabsImpl.paintChildren(JBTabsImpl.java:2271)
	at javax.swing.JComponent.paint(JComponent.java:1062)
	at com.intellij.ui.tabs.impl.JBTabsImpl.paint(JBTabsImpl.java:2266)
	at javax.swing.JComponent.paintToOffscreen(JComponent.java:5228)
	at javax.swing.RepaintManager$PaintManager.paintDoubleBuffered(RepaintManager.java:1532)
	at javax.swing.RepaintManager$PaintManager.paint(RepaintManager.java:1455)
	at javax.swing.RepaintManager.paint(RepaintManager.java:1252)
	at javax.swing.JComponent._paintImmediately(JComponent.java:5176)
	at javax.swing.JComponent.paintImmediately(JComponent.java:4987)
	at javax.swing.RepaintManager$3.run(RepaintManager.java:811)
	at javax.swing.RepaintManager$3.run(RepaintManager.java:794)
	at java.security.AccessController.doPrivileged(Native Method)
	at java.security.ProtectionDomain$1.doIntersectionPrivilege(ProtectionDomain.java:75)
	at javax.swing.RepaintManager.paintDirtyRegions(RepaintManager.java:794)
	at javax.swing.RepaintManager.paintDirtyRegions(RepaintManager.java:769)
	at javax.swing.RepaintManager.prePaintDirtyRegions(RepaintManager.java:718)
	at javax.swing.RepaintManager.access$1100(RepaintManager.java:62)
	at javax.swing.RepaintManager$ProcessingRunnable.run(RepaintManager.java:1680)
	at java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:311)
	at java.awt.EventQueue.null(Unknown Source)
	at java.awt.EventQueue.null(Unknown Source)
	at java.awt.EventQueue$3.run(EventQueue.java:697)
	at java.awt.EventQueue$3.run(EventQueue.java:691)
	at java.security.AccessController.doPrivileged(Native Method)
	at java.security.ProtectionDomain$1.doIntersectionPrivilege(ProtectionDomain.java:75)
	at java.awt.EventQueue.null(Unknown Source)
	at com.intellij.ide.IdeEventQueue.defaultDispatchEvent(IdeEventQueue.java:722)
	at com.intellij.ide.IdeEventQueue._dispatchEvent(IdeEventQueue.java:549)
	at com.intellij.ide.IdeEventQueue.dispatchEvent(IdeEventQueue.java:360)
	at java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:201)
	at java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:116)
	at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:105)
	at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:101)
	at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:93)
	at java.awt.EventDispatchThread.run(EventDispatchThread.java:82)

"Lock thread" prio=0 tid=0x0 nid=0x0 runnable
     java.lang.Thread.State: RUNNABLE
 (in native)
	at java.net.PlainSocketImpl.socketAccept(Native Method)
	at java.net.AbstractPlainSocketImpl.accept(AbstractPlainSocketImpl.java:404)
	at java.net.ServerSocket.null(Unknown Source)
	at java.net.ServerSocket.null(Unknown Source)
	at com.intellij.idea.SocketLock$MyRunnable.run(SocketLock.java:224)
	at java.lang.Thread.null(Unknown Source)

"DestroyJavaVM" prio=0 tid=0x0 nid=0x0 runnable
     java.lang.Thread.State: RUNNABLE


"Java2D Disposer" prio=0 tid=0x0 nid=0x0 waiting on condition
     java.lang.Thread.State: WAITING
 on java.lang.ref.ReferenceQueue$Lock at 3e0bc8b5
	at java.lang.Object.wait(Native Method)
	at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:142)
	at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:158)
	at sun.java2d.Disposer.run(Disposer.java:148)
	at java.lang.Thread.null(Unknown Source)

"Java2D Queue Flusher" prio=0 tid=0x0 nid=0x0 waiting on condition
     java.lang.Thread.State: TIMED_WAITING
 on sun.java2d.opengl.OGLRenderQueue$QueueFlusher at bd0c970
	at java.lang.Object.wait(Native Method)
	at sun.java2d.opengl.OGLRenderQueue$QueueFlusher.run(OGLRenderQueue.java:203)

"AWT-Shutdown" prio=0 tid=0x0 nid=0x0 waiting on condition
     java.lang.Thread.State: WAITING
 on java.lang.Object at 2c82ca53
	at java.lang.Object.wait(Native Method)
	at java.lang.Object.wait(Object.java:502)
	at sun.awt.AWTAutoShutdown.run(AWTAutoShutdown.java:295)
	at java.lang.Thread.null(Unknown Source)

"AWT-AppKit" prio=0 tid=0x0 nid=0x0 blocked
     java.lang.Thread.State: BLOCKED
 on java.awt.Component$AWTTreeLock at ec5c064 owned by "AWT-EventQueue-0 14.0#IU-138.SNAPSHOT, eap:true" Id=24
	at java.awt.Container.getComponentZOrder(Container.java:938)
	at javax.swing.LayoutComparator.compare(LayoutComparator.java:116)
	at javax.swing.LayoutComparator.compare(LayoutComparator.java:42)
	at java.util.TimSort.countRunAndMakeAscending(TimSort.java:356)
	at java.util.TimSort.sort(TimSort.java:216)
	at java.util.Arrays.sort(Arrays.java:1512)
	at java.util.ArrayList.sort(ArrayList.java:1454)
	at java.util.Collections.sort(Collections.java:175)
	at javax.swing.SortingFocusTraversalPolicy.enumerateAndSortCycle(SortingFocusTraversalPolicy.java:136)
	at javax.swing.SortingFocusTraversalPolicy.getFocusTraversalCycle(SortingFocusTraversalPolicy.java:110)
	at javax.swing.SortingFocusTraversalPolicy.getFirstComponent(SortingFocusTraversalPolicy.java:445)
	at javax.swing.LayoutFocusTraversalPolicy.getFirstComponent(LayoutFocusTraversalPolicy.java:166)
	at javax.swing.SortingFocusTraversalPolicy.getDefaultComponent(SortingFocusTraversalPolicy.java:535)
	at java.awt.Window.isFocusableWindow(Window.java:2496)
	at sun.lwawt.LWWindowPeer.isFocusableWindow(LWWindowPeer.java:1217)
	at sun.lwawt.LWWindowPeer.focusAllowedFor(LWWindowPeer.java:1213)
	at sun.lwawt.LWWindowPeer.requestWindowFocus(LWWindowPeer.java:1151)
	at sun.lwawt.LWWindowPeer.notifyMouseEvent(LWWindowPeer.java:799)
	at sun.lwawt.macosx.CPlatformResponder.handleMouseEvent(CPlatformResponder.java:83)
	at sun.lwawt.macosx.CPlatformView.deliverMouseEvent(CPlatformView.java:197)

"ZipFileCache Dispose" prio=0 tid=0x0 nid=0x0 waiting on condition
     java.lang.Thread.State: TIMED_WAITING
 on java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject at 9af62ba
	at sun.misc.Unsafe.park(Native Method)
	at java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215)
	at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(AbstractQueuedSynchronizer.java:2078)
	at java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:1093)
	at java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:809)
	at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1067)
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1127)
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
	at java.lang.Thread.null(Unknown Source)

"JDWP Event Helper Thread" prio=0 tid=0x0 nid=0x0 runnable
     java.lang.Thread.State: RUNNABLE


"JDWP Transport Listener: dt_socket" prio=0 tid=0x0 nid=0x0 runnable
     java.lang.Thread.State: RUNNABLE
 (in native)

"Signal Dispatcher" prio=0 tid=0x0 nid=0x0 runnable
     java.lang.Thread.State: RUNNABLE


"Finalizer" prio=0 tid=0x0 nid=0x0 waiting on condition
     java.lang.Thread.State: WAITING
 on java.lang.ref.ReferenceQueue$Lock at 4b9a1b6
	at java.lang.Object.wait(Native Method)
	at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:142)
	at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:158)
	at java.lang.ref.Finalizer$FinalizerThread.run(Finalizer.java:209)

"Reference Handler" prio=0 tid=0x0 nid=0x0 waiting on condition
     java.lang.Thread.State: WAITING
 on java.lang.ref.Reference$Lock at 64178ff4
	at java.lang.Object.wait(Native Method)
	at java.lang.Object.wait(Object.java:502)
	at java.lang.ref.Reference$ReferenceHandler.run(Reference.java:157)


__
Konstantin Bulenkov
IntelliJ Platform UI Lead
JetBrains




From dmitriy.ermashov at oracle.com  Thu Jun 26 12:25:10 2014
From: dmitriy.ermashov at oracle.com (Dmitriy Ermashov)
Date: Thu, 26 Jun 2014 16:25:10 +0400
Subject: <AWT Dev> nativeGetCursorPosition() locks EDT
In-Reply-To: <09AFBBDE-FC8D-486E-95D3-034D6418CA07@jetbrains.com>
References: <09AFBBDE-FC8D-486E-95D3-034D6418CA07@jetbrains.com>
Message-ID: <53AC1126.8050806@oracle.com>

Hi all,

The bug can be related with https://bugs.openjdk.java.net/browse/JDK-8047288

Thanks,
Dima

On 06/26/2014 04:15 PM, Konstantin Bulenkov wrote:
> Hi,
>
> After switching to 1.8.0_20-ea-b19 x86_64 (Mac OS X 10.9.3) I got EDT locked very often in my desktop application (IntelliJ IDEA). I don?t have this problem in stable versions of 1.8/1.7
>
> Symptoms: EDT stops responding
> Could you please take a look? Looks like regression. Here is the stack trace:
>
> "JobScheduler FJ pool 0/4" prio=0 tid=0x0 nid=0x0 waiting on condition
>       java.lang.Thread.State: TIMED_WAITING
>   on jsr166e.ForkJoinPool at 1e356543
> 	at sun.misc.Unsafe.park(Native Method)
> 	at jsr166e.ForkJoinPool.awaitWork(ForkJoinPool.java:1756)
> 	at jsr166e.ForkJoinPool.scan(ForkJoinPool.java:1694)
> 	at jsr166e.ForkJoinPool.runWorker(ForkJoinPool.java:1642)
> 	at jsr166e.ForkJoinWorkerThread.run(ForkJoinWorkerThread.java:109)
>
> "YJPAgent-OOMESnapshotDetector" prio=0 tid=0x0 nid=0x0 runnable
>       java.lang.Thread.State: RUNNABLE
>   (in native)
>
> "YJPAgent-CPUSampler" prio=0 tid=0x0 nid=0x0 runnable
>       java.lang.Thread.State: RUNNABLE
>
>
> "YJPAgent-RequestListener" prio=0 tid=0x0 nid=0x0 runnable
>       java.lang.Thread.State: RUNNABLE
>   (in native)
> 	at java.net.PlainSocketImpl.socketAccept(Native Method)
> 	at java.net.AbstractPlainSocketImpl.accept(AbstractPlainSocketImpl.java:404)
> 	at java.net.ServerSocket.implAccept(ServerSocket.java:545)
> 	at java.net.ServerSocket.accept(ServerSocket.java:513)
> 	at com.yourkit.runtime.Core$4.run(Core.java:710)
> 	at java.lang.Thread.null(Unknown Source)
>
> "YJPAgent-Telemetry" prio=0 tid=0x0 nid=0x0 waiting on condition
>       java.lang.Thread.State: TIMED_WAITING
>
> 	at java.lang.Thread.sleep(Native Method)
> 	at com.yourkit.util.Util.sleep(Util.java:55)
> 	at com.yourkit.runtime.TelemetryThread.run(TelemetryThread.java:541)
>
> "Attach Listener" prio=0 tid=0x0 nid=0x0 runnable
>       java.lang.Thread.State: RUNNABLE
>
>
> "ApplicationImpl pooled thread 87" prio=0 tid=0x0 nid=0x0 waiting on condition
>       java.lang.Thread.State: TIMED_WAITING
>   on java.util.concurrent.SynchronousQueue$TransferStack at 667921bf
> 	at sun.misc.Unsafe.park(Native Method)
> 	at java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215)
> 	at java.util.concurrent.SynchronousQueue$TransferStack.awaitFulfill(SynchronousQueue.java:460)
> 	at java.util.concurrent.SynchronousQueue$TransferStack.transfer(SynchronousQueue.java:362)
> 	at java.util.concurrent.SynchronousQueue.poll(SynchronousQueue.java:941)
> 	at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1066)
> 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1127)
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> 	at java.lang.Thread.null(Unknown Source)
> 	at com.intellij.openapi.application.impl.ApplicationImpl$1$1.run(ApplicationImpl.java:149)
>
> "ApplicationImpl pooled thread 85" prio=0 tid=0x0 nid=0x0 waiting on condition
>       java.lang.Thread.State: TIMED_WAITING
>   on java.util.concurrent.SynchronousQueue$TransferStack at 667921bf
> 	at sun.misc.Unsafe.park(Native Method)
> 	at java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215)
> 	at java.util.concurrent.SynchronousQueue$TransferStack.awaitFulfill(SynchronousQueue.java:460)
> 	at java.util.concurrent.SynchronousQueue$TransferStack.transfer(SynchronousQueue.java:362)
> 	at java.util.concurrent.SynchronousQueue.poll(SynchronousQueue.java:941)
> 	at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1066)
> 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1127)
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> 	at java.lang.Thread.null(Unknown Source)
> 	at com.intellij.openapi.application.impl.ApplicationImpl$1$1.run(ApplicationImpl.java:149)
>
> "ApplicationImpl pooled thread 84" prio=0 tid=0x0 nid=0x0 waiting on condition
>       java.lang.Thread.State: TIMED_WAITING
>   on java.util.concurrent.SynchronousQueue$TransferStack at 667921bf
> 	at sun.misc.Unsafe.park(Native Method)
> 	at java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215)
> 	at java.util.concurrent.SynchronousQueue$TransferStack.awaitFulfill(SynchronousQueue.java:460)
> 	at java.util.concurrent.SynchronousQueue$TransferStack.transfer(SynchronousQueue.java:362)
> 	at java.util.concurrent.SynchronousQueue.poll(SynchronousQueue.java:941)
> 	at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1066)
> 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1127)
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> 	at java.lang.Thread.null(Unknown Source)
> 	at com.intellij.openapi.application.impl.ApplicationImpl$1$1.run(ApplicationImpl.java:149)
>
> "ApplicationImpl pooled thread 83" prio=0 tid=0x0 nid=0x0 waiting on condition
>       java.lang.Thread.State: TIMED_WAITING
>   on java.util.concurrent.SynchronousQueue$TransferStack at 667921bf
> 	at sun.misc.Unsafe.park(Native Method)
> 	at java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215)
> 	at java.util.concurrent.SynchronousQueue$TransferStack.awaitFulfill(SynchronousQueue.java:460)
> 	at java.util.concurrent.SynchronousQueue$TransferStack.transfer(SynchronousQueue.java:362)
> 	at java.util.concurrent.SynchronousQueue.poll(SynchronousQueue.java:941)
> 	at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1066)
> 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1127)
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> 	at java.lang.Thread.null(Unknown Source)
> 	at com.intellij.openapi.application.impl.ApplicationImpl$1$1.run(ApplicationImpl.java:149)
>
> "ApplicationImpl pooled thread 81" prio=0 tid=0x0 nid=0x0 waiting on condition
>       java.lang.Thread.State: TIMED_WAITING
>   on java.util.concurrent.SynchronousQueue$TransferStack at 667921bf
> 	at sun.misc.Unsafe.park(Native Method)
> 	at java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215)
> 	at java.util.concurrent.SynchronousQueue$TransferStack.awaitFulfill(SynchronousQueue.java:460)
> 	at java.util.concurrent.SynchronousQueue$TransferStack.transfer(SynchronousQueue.java:362)
> 	at java.util.concurrent.SynchronousQueue.poll(SynchronousQueue.java:941)
> 	at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1066)
> 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1127)
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> 	at java.lang.Thread.null(Unknown Source)
> 	at com.intellij.openapi.application.impl.ApplicationImpl$1$1.run(ApplicationImpl.java:149)
>
> "Action Updater" prio=0 tid=0x0 nid=0x0 waiting on condition
>       java.lang.Thread.State: WAITING
>   on java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject at 6c9990ec
> 	at sun.misc.Unsafe.park(Native Method)
> 	at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
> 	at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039)
> 	at java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:442)
> 	at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1067)
> 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1127)
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> 	at java.lang.Thread.null(Unknown Source)
>
> "globalEventExecutor-1-3" prio=0 tid=0x0 nid=0x0 waiting on condition
>       java.lang.Thread.State: TIMED_WAITING
>   on java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject at e8a4982
> 	at sun.misc.Unsafe.park(Native Method)
> 	at java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215)
> 	at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(AbstractQueuedSynchronizer.java:2078)
> 	at java.util.concurrent.LinkedBlockingQueue.poll(LinkedBlockingQueue.java:467)
> 	at io.netty.util.concurrent.GlobalEventExecutor.takeTask(GlobalEventExecutor.java:89)
> 	at io.netty.util.concurrent.GlobalEventExecutor$TaskRunner.run(GlobalEventExecutor.java:318)
> 	at java.lang.Thread.null(Unknown Source)
>
> "RefCountingStorage write content helper" prio=0 tid=0x0 nid=0x0 waiting on condition
>       java.lang.Thread.State: WAITING
>   on java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject at 4eb490de
> 	at sun.misc.Unsafe.park(Native Method)
> 	at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
> 	at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039)
> 	at java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:442)
> 	at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1067)
> 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1127)
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> 	at java.lang.Thread.null(Unknown Source)
>
> "File type re-detect" prio=0 tid=0x0 nid=0x0 waiting on condition
>       java.lang.Thread.State: WAITING
>   on java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject at 68ecdc47
> 	at sun.misc.Unsafe.park(Native Method)
> 	at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
> 	at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039)
> 	at java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:1081)
> 	at java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:809)
> 	at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1067)
> 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1127)
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> 	at java.lang.Thread.null(Unknown Source)
>
> "FS Synchronizer" prio=0 tid=0x0 nid=0x0 waiting on condition
>       java.lang.Thread.State: WAITING
>   on java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject at 3e6f0bdd
> 	at sun.misc.Unsafe.park(Native Method)
> 	at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
> 	at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039)
> 	at java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:442)
> 	at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1067)
> 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1127)
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> 	at java.lang.Thread.null(Unknown Source)
>
> "Change List Updater" prio=0 tid=0x0 nid=0x0 waiting on condition
>       java.lang.Thread.State: WAITING
>   on java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject at 7021b508
> 	at sun.misc.Unsafe.park(Native Method)
> 	at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
> 	at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039)
> 	at java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:1081)
> 	at java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:809)
> 	at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1067)
> 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1127)
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> 	at java.lang.Thread.null(Unknown Source)
>
> "EditorNotifications executor" prio=0 tid=0x0 nid=0x0 waiting on condition
>       java.lang.Thread.State: WAITING
>   on java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject at 40daf476
> 	at sun.misc.Unsafe.park(Native Method)
> 	at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
> 	at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039)
> 	at java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:442)
> 	at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1067)
> 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1127)
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> 	at java.lang.Thread.null(Unknown Source)
>
> "ApplicationImpl pooled thread 8" prio=0 tid=0x0 nid=0x0 runnable
>       java.lang.Thread.State: RUNNABLE
>   (in native)
> 	at sun.nio.ch.KQueueArrayWrapper.kevent0(Native Method)
> 	at sun.nio.ch.KQueueArrayWrapper.poll(KQueueArrayWrapper.java:198)
> 	at sun.nio.ch.KQueueSelectorImpl.doSelect(KQueueSelectorImpl.java:103)
> 	at sun.nio.ch.SelectorImpl.lockAndDoSelect(SelectorImpl.java:86)
> 	at sun.nio.ch.SelectorImpl.select(SelectorImpl.java:97)
> 	at io.netty.channel.nio.NioEventLoop.select(NioEventLoop.java:618)
> 	at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:306)
> 	at io.netty.util.concurrent.SingleThreadEventExecutor$5.run(SingleThreadEventExecutor.java:824)
> 	at com.intellij.openapi.application.impl.ApplicationImpl$9.run(ApplicationImpl.java:446)
> 	at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> 	at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> 	at java.lang.Thread.null(Unknown Source)
> 	at com.intellij.openapi.application.impl.ApplicationImpl$1$1.run(ApplicationImpl.java:149)
>
> "Encoding detection thread" prio=0 tid=0x0 nid=0x0 waiting on condition
>       java.lang.Thread.State: WAITING
>   on java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject at 685d1c9c
> 	at sun.misc.Unsafe.park(Native Method)
> 	at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
> 	at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039)
> 	at java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:1081)
> 	at java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:809)
> 	at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1067)
> 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1127)
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> 	at java.lang.Thread.null(Unknown Source)
>
> "Document commit thread" prio=0 tid=0x0 nid=0x0 waiting on condition
>       java.lang.Thread.State: WAITING
>   on com.intellij.util.containers.Queue at 7ab56c4
> 	at java.lang.Object.wait(Native Method)
> 	at java.lang.Object.wait(Object.java:502)
> 	at com.intellij.psi.impl.DocumentCommitThread.pollQueue(DocumentCommitThread.java:262)
> 	at com.intellij.psi.impl.DocumentCommitThread.run(DocumentCommitThread.java:238)
> 	at java.lang.Thread.null(Unknown Source)
>
> "TimerQueue" prio=0 tid=0x0 nid=0x0 waiting on condition
>       java.lang.Thread.State: TIMED_WAITING
>   on java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject at 10457b03
> 	at sun.misc.Unsafe.park(Native Method)
> 	at java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215)
> 	at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(AbstractQueuedSynchronizer.java:2078)
> 	at java.util.concurrent.DelayQueue.take(DelayQueue.java:223)
> 	at javax.swing.TimerQueue.run(TimerQueue.java:171)
> 	at java.lang.Thread.null(Unknown Source)
>
> "Alarm pool(shared)" prio=0 tid=0x0 nid=0x0 waiting on condition
>       java.lang.Thread.State: WAITING
>   on java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject at 602951d2
> 	at sun.misc.Unsafe.park(Native Method)
> 	at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
> 	at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039)
> 	at java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:442)
> 	at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1067)
> 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1127)
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> 	at java.lang.Thread.null(Unknown Source)
>
> "Animations" prio=0 tid=0x0 nid=0x0 waiting on condition
>       java.lang.Thread.State: TIMED_WAITING
>   on java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject at 609008b7
> 	at sun.misc.Unsafe.park(Native Method)
> 	at java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215)
> 	at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(AbstractQueuedSynchronizer.java:2078)
> 	at java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:1093)
> 	at java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:809)
> 	at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1067)
> 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1127)
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> 	at java.lang.Thread.null(Unknown Source)
>
> "FocusManager timer" prio=0 tid=0x0 nid=0x0 waiting on condition
>       java.lang.Thread.State: WAITING
>   on java.util.TaskQueue at 3d507f17
> 	at java.lang.Object.wait(Native Method)
> 	at java.lang.Object.wait(Object.java:502)
> 	at java.util.TimerThread.mainLoop(Timer.java:526)
> 	at java.util.TimerThread.run(Timer.java:505)
>
> "Shared SimpleTimer" prio=0 tid=0x0 nid=0x0 waiting on condition
>       java.lang.Thread.State: WAITING
>   on java.util.TaskQueue at 6f686dd
> 	at java.lang.Object.wait(Native Method)
> 	at java.lang.Object.wait(Object.java:502)
> 	at java.util.TimerThread.mainLoop(Timer.java:526)
> 	at java.util.TimerThread.run(Timer.java:505)
>
> "Performance watcher" prio=0 tid=0x0 nid=0x0 runnable
>       java.lang.Thread.State: RUNNABLE
>
> 	at sun.management.ThreadImpl.dumpThreads0(Native Method)
> 	at sun.management.ThreadImpl.dumpAllThreads(ThreadImpl.java:446)
> 	at com.intellij.diagnostic.ThreadDumper.dumpThreadsToFile(ThreadDumper.java:47)
> 	at com.intellij.diagnostic.PerformanceWatcher.dumpThreads(PerformanceWatcher.java:219)
> 	at com.intellij.diagnostic.PerformanceWatcher.checkEDTResponsiveness(PerformanceWatcher.java:172)
> 	at com.intellij.diagnostic.PerformanceWatcher.access$100(PerformanceWatcher.java:40)
> 	at com.intellij.diagnostic.PerformanceWatcher$2.run(PerformanceWatcher.java:113)
> 	at java.lang.Thread.null(Unknown Source)
>
> "ApplicationImpl pooled thread 3" prio=0 tid=0x0 nid=0x0 runnable
>       java.lang.Thread.State: RUNNABLE
>   (in native)
> 	at sun.nio.ch.KQueueArrayWrapper.kevent0(Native Method)
> 	at sun.nio.ch.KQueueArrayWrapper.poll(KQueueArrayWrapper.java:198)
> 	at sun.nio.ch.KQueueSelectorImpl.doSelect(KQueueSelectorImpl.java:103)
> 	at sun.nio.ch.SelectorImpl.lockAndDoSelect(SelectorImpl.java:86)
> 	at sun.nio.ch.SelectorImpl.select(SelectorImpl.java:97)
> 	at io.netty.channel.nio.NioEventLoop.select(NioEventLoop.java:618)
> 	at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:306)
> 	at io.netty.util.concurrent.SingleThreadEventExecutor$5.run(SingleThreadEventExecutor.java:824)
> 	at com.intellij.openapi.application.impl.ApplicationImpl$9.run(ApplicationImpl.java:446)
> 	at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> 	at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> 	at java.lang.Thread.null(Unknown Source)
> 	at com.intellij.openapi.application.impl.ApplicationImpl$1$1.run(ApplicationImpl.java:149)
>
> "StoreRefreshStatusThread" prio=0 tid=0x0 nid=0x0 waiting on condition
>       java.lang.Thread.State: TIMED_WAITING
>
> 	at java.lang.Thread.sleep(Native Method)
> 	at com.intellij.util.TimeoutUtil.sleep(TimeoutUtil.java:58)
> 	at com.intellij.openapi.vfs.impl.local.LocalFileSystemImpl$StoreRefreshStatusThread.run(LocalFileSystemImpl.java:355)
>
> "ApplicationImpl pooled thread 2" prio=0 tid=0x0 nid=0x0 waiting on condition
>       java.lang.Thread.State: TIMED_WAITING
>
> 	at java.lang.Thread.sleep(Native Method)
> 	at com.intellij.util.TimeoutUtil.sleep(TimeoutUtil.java:58)
> 	at com.intellij.util.io.BaseDataReader.doRun(BaseDataReader.java:105)
> 	at com.intellij.util.io.BaseDataReader$1.run(BaseDataReader.java:46)
> 	at com.intellij.openapi.application.impl.ApplicationImpl$9.run(ApplicationImpl.java:446)
> 	at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> 	at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> 	at java.lang.Thread.null(Unknown Source)
> 	at com.intellij.openapi.application.impl.ApplicationImpl$1$1.run(ApplicationImpl.java:149)
>
> "ApplicationImpl pooled thread 1" prio=0 tid=0x0 nid=0x0 waiting on condition
>       java.lang.Thread.State: TIMED_WAITING
>
> 	at java.lang.Thread.sleep(Native Method)
> 	at com.intellij.util.TimeoutUtil.sleep(TimeoutUtil.java:58)
> 	at com.intellij.util.io.BaseDataReader.doRun(BaseDataReader.java:105)
> 	at com.intellij.util.io.BaseDataReader$1.run(BaseDataReader.java:46)
> 	at com.intellij.openapi.application.impl.ApplicationImpl$9.run(ApplicationImpl.java:446)
> 	at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> 	at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> 	at java.lang.Thread.null(Unknown Source)
> 	at com.intellij.openapi.application.impl.ApplicationImpl$1$1.run(ApplicationImpl.java:149)
>
> "ApplicationImpl pooled thread 0" prio=0 tid=0x0 nid=0x0 waiting on condition
>       java.lang.Thread.State: WAITING
>   on java.lang.UNIXProcess at 4c4e9088
> 	at java.lang.Object.wait(Native Method)
> 	at java.lang.Object.wait(Object.java:502)
> 	at java.lang.UNIXProcess.null(Unknown Source)
> 	at com.intellij.execution.process.ProcessWaitFor$1.run(ProcessWaitFor.java:30)
> 	at com.intellij.openapi.application.impl.ApplicationImpl$9.run(ApplicationImpl.java:446)
> 	at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> 	at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> 	at java.lang.Thread.null(Unknown Source)
> 	at com.intellij.openapi.application.impl.ApplicationImpl$1$1.run(ApplicationImpl.java:149)
>
> "process reaper" prio=0 tid=0x0 nid=0x0 runnable
>       java.lang.Thread.State: RUNNABLE
>   (in native)
> 	at java.lang.UNIXProcess.waitForProcessExit(Native Method)
> 	at java.lang.UNIXProcess.null(Unknown Source)
> 	at java.lang.UNIXProcess$4.run(UNIXProcess.java:226)
> 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> 	at java.lang.Thread.null(Unknown Source)
>
> "Flushing thread" prio=0 tid=0x0 nid=0x0 waiting on condition
>       java.lang.Thread.State: TIMED_WAITING
>   on java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject at 7258e6d1
> 	at sun.misc.Unsafe.park(Native Method)
> 	at java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215)
> 	at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(AbstractQueuedSynchronizer.java:2078)
> 	at java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:1093)
> 	at java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:809)
> 	at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1067)
> 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1127)
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> 	at java.lang.Thread.null(Unknown Source)
>
> "ZipFileCache Dispose" prio=0 tid=0x0 nid=0x0 waiting on condition
>       java.lang.Thread.State: TIMED_WAITING
>   on java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject at 402a4629
> 	at sun.misc.Unsafe.park(Native Method)
> 	at java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215)
> 	at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(AbstractQueuedSynchronizer.java:2078)
> 	at java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:1093)
> 	at java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:809)
> 	at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1067)
> 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1127)
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> 	at java.lang.Thread.null(Unknown Source)
>
> "Periodic tasks thread" prio=0 tid=0x0 nid=0x0 waiting on condition
>       java.lang.Thread.State: TIMED_WAITING
>   on java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject at 33a2c55c
> 	at sun.misc.Unsafe.park(Native Method)
> 	at java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215)
> 	at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(AbstractQueuedSynchronizer.java:2078)
> 	at java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:1093)
> 	at java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:809)
> 	at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1067)
> 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1127)
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> 	at java.lang.Thread.null(Unknown Source)
>
> "AWT-EventQueue-0 14.0#IU-138.SNAPSHOT, eap:true" prio=0 tid=0x0 nid=0x0 runnable
>       java.lang.Thread.State: RUNNABLE
>   (in native)
> 	at sun.lwawt.macosx.CCursorManager.nativeGetCursorPosition(Native Method)
> 	at sun.lwawt.macosx.CCursorManager.getCursorPosition(CCursorManager.java:54)
> 	at sun.lwawt.LWCursorManager.updateCursorImpl(LWCursorManager.java:80)
> 	at sun.lwawt.LWCursorManager.updateCursor(LWCursorManager.java:57)
> 	at sun.lwawt.LWComponentPeer.updateCursorImmediately(LWComponentPeer.java:894)
> 	at java.awt.Component.updateCursorImmediately(Component.java:3137)
> 	at java.awt.Container.validate(Container.java:1640)
> 	at javax.swing.CellRendererPane.paintComponent(CellRendererPane.java:140)
> 	at com.intellij.util.ui.tree.WideSelectionTreeUI$4.paintComponent(WideSelectionTreeUI.java:439)
> 	at javax.swing.plaf.basic.BasicTreeUI.paintRow(BasicTreeUI.java:1540)
> 	at com.intellij.util.ui.tree.WideSelectionTreeUI.paintRow(WideSelectionTreeUI.java:382)
> 	at javax.swing.plaf.basic.BasicTreeUI.paint(BasicTreeUI.java:1224)
> 	at com.intellij.util.ui.tree.WideSelectionTreeUI.paint(WideSelectionTreeUI.java:410)
> 	at javax.swing.plaf.ComponentUI.update(ComponentUI.java:161)
> 	at javax.swing.JComponent.paintComponent(JComponent.java:777)
> 	at com.intellij.ui.treeStructure.Tree.paintComponent(Tree.java:328)
> 	at javax.swing.JComponent.paint(JComponent.java:1053)
> 	at com.intellij.ui.treeStructure.Tree.paint(Tree.java:244)
> 	at javax.swing.JComponent.paintChildren(JComponent.java:886)
> 	at javax.swing.JComponent.paint(JComponent.java:1062)
> 	at javax.swing.JViewport.paint(JViewport.java:744)
> 	at com.intellij.ui.components.JBViewport.paint(JBViewport.java:119)
> 	at javax.swing.JComponent.paintChildren(JComponent.java:886)
> 	at javax.swing.JComponent.paint(JComponent.java:1062)
> 	at javax.swing.JComponent.paintChildren(JComponent.java:886)
> 	at javax.swing.JComponent.paint(JComponent.java:1062)
> 	at javax.swing.JComponent.paintChildren(JComponent.java:886)
> 	at javax.swing.JComponent.paint(JComponent.java:1062)
> 	at javax.swing.JComponent.paintChildren(JComponent.java:886)
> 	at com.intellij.ui.tabs.impl.JBTabsImpl.paintChildren(JBTabsImpl.java:2271)
> 	at javax.swing.JComponent.paint(JComponent.java:1062)
> 	at com.intellij.ui.tabs.impl.JBTabsImpl.paint(JBTabsImpl.java:2266)
> 	at javax.swing.JComponent.paintChildren(JComponent.java:886)
> 	at javax.swing.JComponent.paint(JComponent.java:1062)
> 	at javax.swing.JComponent.paintChildren(JComponent.java:886)
> 	at javax.swing.JComponent.paint(JComponent.java:1062)
> 	at javax.swing.JComponent.paintChildren(JComponent.java:886)
> 	at javax.swing.JComponent.paint(JComponent.java:1062)
> 	at javax.swing.JComponent.paintChildren(JComponent.java:886)
> 	at javax.swing.JComponent.paint(JComponent.java:1062)
> 	at javax.swing.JComponent.paintChildren(JComponent.java:886)
> 	at com.intellij.ui.tabs.impl.JBTabsImpl.paintChildren(JBTabsImpl.java:2271)
> 	at javax.swing.JComponent.paint(JComponent.java:1062)
> 	at com.intellij.ui.tabs.impl.JBTabsImpl.paint(JBTabsImpl.java:2266)
> 	at javax.swing.JComponent.paintToOffscreen(JComponent.java:5228)
> 	at javax.swing.RepaintManager$PaintManager.paintDoubleBuffered(RepaintManager.java:1532)
> 	at javax.swing.RepaintManager$PaintManager.paint(RepaintManager.java:1455)
> 	at javax.swing.RepaintManager.paint(RepaintManager.java:1252)
> 	at javax.swing.JComponent._paintImmediately(JComponent.java:5176)
> 	at javax.swing.JComponent.paintImmediately(JComponent.java:4987)
> 	at javax.swing.RepaintManager$3.run(RepaintManager.java:811)
> 	at javax.swing.RepaintManager$3.run(RepaintManager.java:794)
> 	at java.security.AccessController.doPrivileged(Native Method)
> 	at java.security.ProtectionDomain$1.doIntersectionPrivilege(ProtectionDomain.java:75)
> 	at javax.swing.RepaintManager.paintDirtyRegions(RepaintManager.java:794)
> 	at javax.swing.RepaintManager.paintDirtyRegions(RepaintManager.java:769)
> 	at javax.swing.RepaintManager.prePaintDirtyRegions(RepaintManager.java:718)
> 	at javax.swing.RepaintManager.access$1100(RepaintManager.java:62)
> 	at javax.swing.RepaintManager$ProcessingRunnable.run(RepaintManager.java:1680)
> 	at java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:311)
> 	at java.awt.EventQueue.null(Unknown Source)
> 	at java.awt.EventQueue.null(Unknown Source)
> 	at java.awt.EventQueue$3.run(EventQueue.java:697)
> 	at java.awt.EventQueue$3.run(EventQueue.java:691)
> 	at java.security.AccessController.doPrivileged(Native Method)
> 	at java.security.ProtectionDomain$1.doIntersectionPrivilege(ProtectionDomain.java:75)
> 	at java.awt.EventQueue.null(Unknown Source)
> 	at com.intellij.ide.IdeEventQueue.defaultDispatchEvent(IdeEventQueue.java:722)
> 	at com.intellij.ide.IdeEventQueue._dispatchEvent(IdeEventQueue.java:549)
> 	at com.intellij.ide.IdeEventQueue.dispatchEvent(IdeEventQueue.java:360)
> 	at java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:201)
> 	at java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:116)
> 	at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:105)
> 	at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:101)
> 	at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:93)
> 	at java.awt.EventDispatchThread.run(EventDispatchThread.java:82)
>
> "Lock thread" prio=0 tid=0x0 nid=0x0 runnable
>       java.lang.Thread.State: RUNNABLE
>   (in native)
> 	at java.net.PlainSocketImpl.socketAccept(Native Method)
> 	at java.net.AbstractPlainSocketImpl.accept(AbstractPlainSocketImpl.java:404)
> 	at java.net.ServerSocket.null(Unknown Source)
> 	at java.net.ServerSocket.null(Unknown Source)
> 	at com.intellij.idea.SocketLock$MyRunnable.run(SocketLock.java:224)
> 	at java.lang.Thread.null(Unknown Source)
>
> "DestroyJavaVM" prio=0 tid=0x0 nid=0x0 runnable
>       java.lang.Thread.State: RUNNABLE
>
>
> "Java2D Disposer" prio=0 tid=0x0 nid=0x0 waiting on condition
>       java.lang.Thread.State: WAITING
>   on java.lang.ref.ReferenceQueue$Lock at 3e0bc8b5
> 	at java.lang.Object.wait(Native Method)
> 	at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:142)
> 	at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:158)
> 	at sun.java2d.Disposer.run(Disposer.java:148)
> 	at java.lang.Thread.null(Unknown Source)
>
> "Java2D Queue Flusher" prio=0 tid=0x0 nid=0x0 waiting on condition
>       java.lang.Thread.State: TIMED_WAITING
>   on sun.java2d.opengl.OGLRenderQueue$QueueFlusher at bd0c970
> 	at java.lang.Object.wait(Native Method)
> 	at sun.java2d.opengl.OGLRenderQueue$QueueFlusher.run(OGLRenderQueue.java:203)
>
> "AWT-Shutdown" prio=0 tid=0x0 nid=0x0 waiting on condition
>       java.lang.Thread.State: WAITING
>   on java.lang.Object at 2c82ca53
> 	at java.lang.Object.wait(Native Method)
> 	at java.lang.Object.wait(Object.java:502)
> 	at sun.awt.AWTAutoShutdown.run(AWTAutoShutdown.java:295)
> 	at java.lang.Thread.null(Unknown Source)
>
> "AWT-AppKit" prio=0 tid=0x0 nid=0x0 blocked
>       java.lang.Thread.State: BLOCKED
>   on java.awt.Component$AWTTreeLock at ec5c064 owned by "AWT-EventQueue-0 14.0#IU-138.SNAPSHOT, eap:true" Id=24
> 	at java.awt.Container.getComponentZOrder(Container.java:938)
> 	at javax.swing.LayoutComparator.compare(LayoutComparator.java:116)
> 	at javax.swing.LayoutComparator.compare(LayoutComparator.java:42)
> 	at java.util.TimSort.countRunAndMakeAscending(TimSort.java:356)
> 	at java.util.TimSort.sort(TimSort.java:216)
> 	at java.util.Arrays.sort(Arrays.java:1512)
> 	at java.util.ArrayList.sort(ArrayList.java:1454)
> 	at java.util.Collections.sort(Collections.java:175)
> 	at javax.swing.SortingFocusTraversalPolicy.enumerateAndSortCycle(SortingFocusTraversalPolicy.java:136)
> 	at javax.swing.SortingFocusTraversalPolicy.getFocusTraversalCycle(SortingFocusTraversalPolicy.java:110)
> 	at javax.swing.SortingFocusTraversalPolicy.getFirstComponent(SortingFocusTraversalPolicy.java:445)
> 	at javax.swing.LayoutFocusTraversalPolicy.getFirstComponent(LayoutFocusTraversalPolicy.java:166)
> 	at javax.swing.SortingFocusTraversalPolicy.getDefaultComponent(SortingFocusTraversalPolicy.java:535)
> 	at java.awt.Window.isFocusableWindow(Window.java:2496)
> 	at sun.lwawt.LWWindowPeer.isFocusableWindow(LWWindowPeer.java:1217)
> 	at sun.lwawt.LWWindowPeer.focusAllowedFor(LWWindowPeer.java:1213)
> 	at sun.lwawt.LWWindowPeer.requestWindowFocus(LWWindowPeer.java:1151)
> 	at sun.lwawt.LWWindowPeer.notifyMouseEvent(LWWindowPeer.java:799)
> 	at sun.lwawt.macosx.CPlatformResponder.handleMouseEvent(CPlatformResponder.java:83)
> 	at sun.lwawt.macosx.CPlatformView.deliverMouseEvent(CPlatformView.java:197)
>
> "ZipFileCache Dispose" prio=0 tid=0x0 nid=0x0 waiting on condition
>       java.lang.Thread.State: TIMED_WAITING
>   on java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject at 9af62ba
> 	at sun.misc.Unsafe.park(Native Method)
> 	at java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215)
> 	at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(AbstractQueuedSynchronizer.java:2078)
> 	at java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:1093)
> 	at java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:809)
> 	at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1067)
> 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1127)
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> 	at java.lang.Thread.null(Unknown Source)
>
> "JDWP Event Helper Thread" prio=0 tid=0x0 nid=0x0 runnable
>       java.lang.Thread.State: RUNNABLE
>
>
> "JDWP Transport Listener: dt_socket" prio=0 tid=0x0 nid=0x0 runnable
>       java.lang.Thread.State: RUNNABLE
>   (in native)
>
> "Signal Dispatcher" prio=0 tid=0x0 nid=0x0 runnable
>       java.lang.Thread.State: RUNNABLE
>
>
> "Finalizer" prio=0 tid=0x0 nid=0x0 waiting on condition
>       java.lang.Thread.State: WAITING
>   on java.lang.ref.ReferenceQueue$Lock at 4b9a1b6
> 	at java.lang.Object.wait(Native Method)
> 	at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:142)
> 	at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:158)
> 	at java.lang.ref.Finalizer$FinalizerThread.run(Finalizer.java:209)
>
> "Reference Handler" prio=0 tid=0x0 nid=0x0 waiting on condition
>       java.lang.Thread.State: WAITING
>   on java.lang.ref.Reference$Lock at 64178ff4
> 	at java.lang.Object.wait(Native Method)
> 	at java.lang.Object.wait(Object.java:502)
> 	at java.lang.ref.Reference$ReferenceHandler.run(Reference.java:157)
>
>
> __
> Konstantin Bulenkov
> IntelliJ Platform UI Lead
> JetBrains
>
>
>


From petr.pchelko at oracle.com  Thu Jun 26 12:45:13 2014
From: petr.pchelko at oracle.com (Petr Pchelko)
Date: Thu, 26 Jun 2014 16:45:13 +0400
Subject: <AWT Dev> nativeGetCursorPosition() locks EDT
In-Reply-To: <53AC1126.8050806@oracle.com>
References: <09AFBBDE-FC8D-486E-95D3-034D6418CA07@jetbrains.com>
	<53AC1126.8050806@oracle.com>
Message-ID: <F8EEEACC-9AE3-4979-AE20-D8AABB2DBB3F@oracle.com>

Hello, Konstantin.

> The bug can be related with https://bugs.openjdk.java.net/browse/JDK-8047288
Yes. It's the same bug. I highly doubt it's a regression as nothing related was changed recently. I'm currently working on this issue.
Unfortunately I can't suggest any viable workaround.

Thank you for the report.
With best regards. Petr.

On 26 ???? 2014 ?., at 16:25, Dmitriy Ermashov <dmitriy.ermashov at oracle.com> wrote:

> Hi all,
> 
> The bug can be related with https://bugs.openjdk.java.net/browse/JDK-8047288
> 
> Thanks,
> Dima
> 
> On 06/26/2014 04:15 PM, Konstantin Bulenkov wrote:
>> Hi,
>> 
>> After switching to 1.8.0_20-ea-b19 x86_64 (Mac OS X 10.9.3) I got EDT locked very often in my desktop application (IntelliJ IDEA). I don?t have this problem in stable versions of 1.8/1.7
>> 
>> Symptoms: EDT stops responding
>> Could you please take a look? Looks like regression. Here is the stack trace:
>> 
>> "JobScheduler FJ pool 0/4" prio=0 tid=0x0 nid=0x0 waiting on condition
>>      java.lang.Thread.State: TIMED_WAITING
>>  on jsr166e.ForkJoinPool at 1e356543
>> 	at sun.misc.Unsafe.park(Native Method)
>> 	at jsr166e.ForkJoinPool.awaitWork(ForkJoinPool.java:1756)
>> 	at jsr166e.ForkJoinPool.scan(ForkJoinPool.java:1694)
>> 	at jsr166e.ForkJoinPool.runWorker(ForkJoinPool.java:1642)
>> 	at jsr166e.ForkJoinWorkerThread.run(ForkJoinWorkerThread.java:109)
>> 
>> "YJPAgent-OOMESnapshotDetector" prio=0 tid=0x0 nid=0x0 runnable
>>      java.lang.Thread.State: RUNNABLE
>>  (in native)
>> 
>> "YJPAgent-CPUSampler" prio=0 tid=0x0 nid=0x0 runnable
>>      java.lang.Thread.State: RUNNABLE
>> 
>> 
>> "YJPAgent-RequestListener" prio=0 tid=0x0 nid=0x0 runnable
>>      java.lang.Thread.State: RUNNABLE
>>  (in native)
>> 	at java.net.PlainSocketImpl.socketAccept(Native Method)
>> 	at java.net.AbstractPlainSocketImpl.accept(AbstractPlainSocketImpl.java:404)
>> 	at java.net.ServerSocket.implAccept(ServerSocket.java:545)
>> 	at java.net.ServerSocket.accept(ServerSocket.java:513)
>> 	at com.yourkit.runtime.Core$4.run(Core.java:710)
>> 	at java.lang.Thread.null(Unknown Source)
>> 
>> "YJPAgent-Telemetry" prio=0 tid=0x0 nid=0x0 waiting on condition
>>      java.lang.Thread.State: TIMED_WAITING
>> 
>> 	at java.lang.Thread.sleep(Native Method)
>> 	at com.yourkit.util.Util.sleep(Util.java:55)
>> 	at com.yourkit.runtime.TelemetryThread.run(TelemetryThread.java:541)
>> 
>> "Attach Listener" prio=0 tid=0x0 nid=0x0 runnable
>>      java.lang.Thread.State: RUNNABLE
>> 
>> 
>> "ApplicationImpl pooled thread 87" prio=0 tid=0x0 nid=0x0 waiting on condition
>>      java.lang.Thread.State: TIMED_WAITING
>>  on java.util.concurrent.SynchronousQueue$TransferStack at 667921bf
>> 	at sun.misc.Unsafe.park(Native Method)
>> 	at java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215)
>> 	at java.util.concurrent.SynchronousQueue$TransferStack.awaitFulfill(SynchronousQueue.java:460)
>> 	at java.util.concurrent.SynchronousQueue$TransferStack.transfer(SynchronousQueue.java:362)
>> 	at java.util.concurrent.SynchronousQueue.poll(SynchronousQueue.java:941)
>> 	at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1066)
>> 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1127)
>> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
>> 	at java.lang.Thread.null(Unknown Source)
>> 	at com.intellij.openapi.application.impl.ApplicationImpl$1$1.run(ApplicationImpl.java:149)
>> 
>> "ApplicationImpl pooled thread 85" prio=0 tid=0x0 nid=0x0 waiting on condition
>>      java.lang.Thread.State: TIMED_WAITING
>>  on java.util.concurrent.SynchronousQueue$TransferStack at 667921bf
>> 	at sun.misc.Unsafe.park(Native Method)
>> 	at java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215)
>> 	at java.util.concurrent.SynchronousQueue$TransferStack.awaitFulfill(SynchronousQueue.java:460)
>> 	at java.util.concurrent.SynchronousQueue$TransferStack.transfer(SynchronousQueue.java:362)
>> 	at java.util.concurrent.SynchronousQueue.poll(SynchronousQueue.java:941)
>> 	at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1066)
>> 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1127)
>> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
>> 	at java.lang.Thread.null(Unknown Source)
>> 	at com.intellij.openapi.application.impl.ApplicationImpl$1$1.run(ApplicationImpl.java:149)
>> 
>> "ApplicationImpl pooled thread 84" prio=0 tid=0x0 nid=0x0 waiting on condition
>>      java.lang.Thread.State: TIMED_WAITING
>>  on java.util.concurrent.SynchronousQueue$TransferStack at 667921bf
>> 	at sun.misc.Unsafe.park(Native Method)
>> 	at java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215)
>> 	at java.util.concurrent.SynchronousQueue$TransferStack.awaitFulfill(SynchronousQueue.java:460)
>> 	at java.util.concurrent.SynchronousQueue$TransferStack.transfer(SynchronousQueue.java:362)
>> 	at java.util.concurrent.SynchronousQueue.poll(SynchronousQueue.java:941)
>> 	at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1066)
>> 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1127)
>> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
>> 	at java.lang.Thread.null(Unknown Source)
>> 	at com.intellij.openapi.application.impl.ApplicationImpl$1$1.run(ApplicationImpl.java:149)
>> 
>> "ApplicationImpl pooled thread 83" prio=0 tid=0x0 nid=0x0 waiting on condition
>>      java.lang.Thread.State: TIMED_WAITING
>>  on java.util.concurrent.SynchronousQueue$TransferStack at 667921bf
>> 	at sun.misc.Unsafe.park(Native Method)
>> 	at java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215)
>> 	at java.util.concurrent.SynchronousQueue$TransferStack.awaitFulfill(SynchronousQueue.java:460)
>> 	at java.util.concurrent.SynchronousQueue$TransferStack.transfer(SynchronousQueue.java:362)
>> 	at java.util.concurrent.SynchronousQueue.poll(SynchronousQueue.java:941)
>> 	at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1066)
>> 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1127)
>> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
>> 	at java.lang.Thread.null(Unknown Source)
>> 	at com.intellij.openapi.application.impl.ApplicationImpl$1$1.run(ApplicationImpl.java:149)
>> 
>> "ApplicationImpl pooled thread 81" prio=0 tid=0x0 nid=0x0 waiting on condition
>>      java.lang.Thread.State: TIMED_WAITING
>>  on java.util.concurrent.SynchronousQueue$TransferStack at 667921bf
>> 	at sun.misc.Unsafe.park(Native Method)
>> 	at java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215)
>> 	at java.util.concurrent.SynchronousQueue$TransferStack.awaitFulfill(SynchronousQueue.java:460)
>> 	at java.util.concurrent.SynchronousQueue$TransferStack.transfer(SynchronousQueue.java:362)
>> 	at java.util.concurrent.SynchronousQueue.poll(SynchronousQueue.java:941)
>> 	at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1066)
>> 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1127)
>> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
>> 	at java.lang.Thread.null(Unknown Source)
>> 	at com.intellij.openapi.application.impl.ApplicationImpl$1$1.run(ApplicationImpl.java:149)
>> 
>> "Action Updater" prio=0 tid=0x0 nid=0x0 waiting on condition
>>      java.lang.Thread.State: WAITING
>>  on java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject at 6c9990ec
>> 	at sun.misc.Unsafe.park(Native Method)
>> 	at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
>> 	at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039)
>> 	at java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:442)
>> 	at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1067)
>> 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1127)
>> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
>> 	at java.lang.Thread.null(Unknown Source)
>> 
>> "globalEventExecutor-1-3" prio=0 tid=0x0 nid=0x0 waiting on condition
>>      java.lang.Thread.State: TIMED_WAITING
>>  on java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject at e8a4982
>> 	at sun.misc.Unsafe.park(Native Method)
>> 	at java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215)
>> 	at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(AbstractQueuedSynchronizer.java:2078)
>> 	at java.util.concurrent.LinkedBlockingQueue.poll(LinkedBlockingQueue.java:467)
>> 	at io.netty.util.concurrent.GlobalEventExecutor.takeTask(GlobalEventExecutor.java:89)
>> 	at io.netty.util.concurrent.GlobalEventExecutor$TaskRunner.run(GlobalEventExecutor.java:318)
>> 	at java.lang.Thread.null(Unknown Source)
>> 
>> "RefCountingStorage write content helper" prio=0 tid=0x0 nid=0x0 waiting on condition
>>      java.lang.Thread.State: WAITING
>>  on java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject at 4eb490de
>> 	at sun.misc.Unsafe.park(Native Method)
>> 	at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
>> 	at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039)
>> 	at java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:442)
>> 	at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1067)
>> 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1127)
>> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
>> 	at java.lang.Thread.null(Unknown Source)
>> 
>> "File type re-detect" prio=0 tid=0x0 nid=0x0 waiting on condition
>>      java.lang.Thread.State: WAITING
>>  on java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject at 68ecdc47
>> 	at sun.misc.Unsafe.park(Native Method)
>> 	at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
>> 	at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039)
>> 	at java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:1081)
>> 	at java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:809)
>> 	at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1067)
>> 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1127)
>> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
>> 	at java.lang.Thread.null(Unknown Source)
>> 
>> "FS Synchronizer" prio=0 tid=0x0 nid=0x0 waiting on condition
>>      java.lang.Thread.State: WAITING
>>  on java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject at 3e6f0bdd
>> 	at sun.misc.Unsafe.park(Native Method)
>> 	at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
>> 	at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039)
>> 	at java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:442)
>> 	at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1067)
>> 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1127)
>> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
>> 	at java.lang.Thread.null(Unknown Source)
>> 
>> "Change List Updater" prio=0 tid=0x0 nid=0x0 waiting on condition
>>      java.lang.Thread.State: WAITING
>>  on java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject at 7021b508
>> 	at sun.misc.Unsafe.park(Native Method)
>> 	at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
>> 	at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039)
>> 	at java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:1081)
>> 	at java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:809)
>> 	at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1067)
>> 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1127)
>> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
>> 	at java.lang.Thread.null(Unknown Source)
>> 
>> "EditorNotifications executor" prio=0 tid=0x0 nid=0x0 waiting on condition
>>      java.lang.Thread.State: WAITING
>>  on java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject at 40daf476
>> 	at sun.misc.Unsafe.park(Native Method)
>> 	at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
>> 	at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039)
>> 	at java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:442)
>> 	at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1067)
>> 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1127)
>> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
>> 	at java.lang.Thread.null(Unknown Source)
>> 
>> "ApplicationImpl pooled thread 8" prio=0 tid=0x0 nid=0x0 runnable
>>      java.lang.Thread.State: RUNNABLE
>>  (in native)
>> 	at sun.nio.ch.KQueueArrayWrapper.kevent0(Native Method)
>> 	at sun.nio.ch.KQueueArrayWrapper.poll(KQueueArrayWrapper.java:198)
>> 	at sun.nio.ch.KQueueSelectorImpl.doSelect(KQueueSelectorImpl.java:103)
>> 	at sun.nio.ch.SelectorImpl.lockAndDoSelect(SelectorImpl.java:86)
>> 	at sun.nio.ch.SelectorImpl.select(SelectorImpl.java:97)
>> 	at io.netty.channel.nio.NioEventLoop.select(NioEventLoop.java:618)
>> 	at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:306)
>> 	at io.netty.util.concurrent.SingleThreadEventExecutor$5.run(SingleThreadEventExecutor.java:824)
>> 	at com.intellij.openapi.application.impl.ApplicationImpl$9.run(ApplicationImpl.java:446)
>> 	at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
>> 	at java.util.concurrent.FutureTask.run(FutureTask.java:266)
>> 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
>> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
>> 	at java.lang.Thread.null(Unknown Source)
>> 	at com.intellij.openapi.application.impl.ApplicationImpl$1$1.run(ApplicationImpl.java:149)
>> 
>> "Encoding detection thread" prio=0 tid=0x0 nid=0x0 waiting on condition
>>      java.lang.Thread.State: WAITING
>>  on java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject at 685d1c9c
>> 	at sun.misc.Unsafe.park(Native Method)
>> 	at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
>> 	at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039)
>> 	at java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:1081)
>> 	at java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:809)
>> 	at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1067)
>> 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1127)
>> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
>> 	at java.lang.Thread.null(Unknown Source)
>> 
>> "Document commit thread" prio=0 tid=0x0 nid=0x0 waiting on condition
>>      java.lang.Thread.State: WAITING
>>  on com.intellij.util.containers.Queue at 7ab56c4
>> 	at java.lang.Object.wait(Native Method)
>> 	at java.lang.Object.wait(Object.java:502)
>> 	at com.intellij.psi.impl.DocumentCommitThread.pollQueue(DocumentCommitThread.java:262)
>> 	at com.intellij.psi.impl.DocumentCommitThread.run(DocumentCommitThread.java:238)
>> 	at java.lang.Thread.null(Unknown Source)
>> 
>> "TimerQueue" prio=0 tid=0x0 nid=0x0 waiting on condition
>>      java.lang.Thread.State: TIMED_WAITING
>>  on java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject at 10457b03
>> 	at sun.misc.Unsafe.park(Native Method)
>> 	at java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215)
>> 	at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(AbstractQueuedSynchronizer.java:2078)
>> 	at java.util.concurrent.DelayQueue.take(DelayQueue.java:223)
>> 	at javax.swing.TimerQueue.run(TimerQueue.java:171)
>> 	at java.lang.Thread.null(Unknown Source)
>> 
>> "Alarm pool(shared)" prio=0 tid=0x0 nid=0x0 waiting on condition
>>      java.lang.Thread.State: WAITING
>>  on java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject at 602951d2
>> 	at sun.misc.Unsafe.park(Native Method)
>> 	at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
>> 	at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039)
>> 	at java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:442)
>> 	at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1067)
>> 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1127)
>> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
>> 	at java.lang.Thread.null(Unknown Source)
>> 
>> "Animations" prio=0 tid=0x0 nid=0x0 waiting on condition
>>      java.lang.Thread.State: TIMED_WAITING
>>  on java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject at 609008b7
>> 	at sun.misc.Unsafe.park(Native Method)
>> 	at java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215)
>> 	at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(AbstractQueuedSynchronizer.java:2078)
>> 	at java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:1093)
>> 	at java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:809)
>> 	at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1067)
>> 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1127)
>> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
>> 	at java.lang.Thread.null(Unknown Source)
>> 
>> "FocusManager timer" prio=0 tid=0x0 nid=0x0 waiting on condition
>>      java.lang.Thread.State: WAITING
>>  on java.util.TaskQueue at 3d507f17
>> 	at java.lang.Object.wait(Native Method)
>> 	at java.lang.Object.wait(Object.java:502)
>> 	at java.util.TimerThread.mainLoop(Timer.java:526)
>> 	at java.util.TimerThread.run(Timer.java:505)
>> 
>> "Shared SimpleTimer" prio=0 tid=0x0 nid=0x0 waiting on condition
>>      java.lang.Thread.State: WAITING
>>  on java.util.TaskQueue at 6f686dd
>> 	at java.lang.Object.wait(Native Method)
>> 	at java.lang.Object.wait(Object.java:502)
>> 	at java.util.TimerThread.mainLoop(Timer.java:526)
>> 	at java.util.TimerThread.run(Timer.java:505)
>> 
>> "Performance watcher" prio=0 tid=0x0 nid=0x0 runnable
>>      java.lang.Thread.State: RUNNABLE
>> 
>> 	at sun.management.ThreadImpl.dumpThreads0(Native Method)
>> 	at sun.management.ThreadImpl.dumpAllThreads(ThreadImpl.java:446)
>> 	at com.intellij.diagnostic.ThreadDumper.dumpThreadsToFile(ThreadDumper.java:47)
>> 	at com.intellij.diagnostic.PerformanceWatcher.dumpThreads(PerformanceWatcher.java:219)
>> 	at com.intellij.diagnostic.PerformanceWatcher.checkEDTResponsiveness(PerformanceWatcher.java:172)
>> 	at com.intellij.diagnostic.PerformanceWatcher.access$100(PerformanceWatcher.java:40)
>> 	at com.intellij.diagnostic.PerformanceWatcher$2.run(PerformanceWatcher.java:113)
>> 	at java.lang.Thread.null(Unknown Source)
>> 
>> "ApplicationImpl pooled thread 3" prio=0 tid=0x0 nid=0x0 runnable
>>      java.lang.Thread.State: RUNNABLE
>>  (in native)
>> 	at sun.nio.ch.KQueueArrayWrapper.kevent0(Native Method)
>> 	at sun.nio.ch.KQueueArrayWrapper.poll(KQueueArrayWrapper.java:198)
>> 	at sun.nio.ch.KQueueSelectorImpl.doSelect(KQueueSelectorImpl.java:103)
>> 	at sun.nio.ch.SelectorImpl.lockAndDoSelect(SelectorImpl.java:86)
>> 	at sun.nio.ch.SelectorImpl.select(SelectorImpl.java:97)
>> 	at io.netty.channel.nio.NioEventLoop.select(NioEventLoop.java:618)
>> 	at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:306)
>> 	at io.netty.util.concurrent.SingleThreadEventExecutor$5.run(SingleThreadEventExecutor.java:824)
>> 	at com.intellij.openapi.application.impl.ApplicationImpl$9.run(ApplicationImpl.java:446)
>> 	at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
>> 	at java.util.concurrent.FutureTask.run(FutureTask.java:266)
>> 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
>> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
>> 	at java.lang.Thread.null(Unknown Source)
>> 	at com.intellij.openapi.application.impl.ApplicationImpl$1$1.run(ApplicationImpl.java:149)
>> 
>> "StoreRefreshStatusThread" prio=0 tid=0x0 nid=0x0 waiting on condition
>>      java.lang.Thread.State: TIMED_WAITING
>> 
>> 	at java.lang.Thread.sleep(Native Method)
>> 	at com.intellij.util.TimeoutUtil.sleep(TimeoutUtil.java:58)
>> 	at com.intellij.openapi.vfs.impl.local.LocalFileSystemImpl$StoreRefreshStatusThread.run(LocalFileSystemImpl.java:355)
>> 
>> "ApplicationImpl pooled thread 2" prio=0 tid=0x0 nid=0x0 waiting on condition
>>      java.lang.Thread.State: TIMED_WAITING
>> 
>> 	at java.lang.Thread.sleep(Native Method)
>> 	at com.intellij.util.TimeoutUtil.sleep(TimeoutUtil.java:58)
>> 	at com.intellij.util.io.BaseDataReader.doRun(BaseDataReader.java:105)
>> 	at com.intellij.util.io.BaseDataReader$1.run(BaseDataReader.java:46)
>> 	at com.intellij.openapi.application.impl.ApplicationImpl$9.run(ApplicationImpl.java:446)
>> 	at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
>> 	at java.util.concurrent.FutureTask.run(FutureTask.java:266)
>> 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
>> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
>> 	at java.lang.Thread.null(Unknown Source)
>> 	at com.intellij.openapi.application.impl.ApplicationImpl$1$1.run(ApplicationImpl.java:149)
>> 
>> "ApplicationImpl pooled thread 1" prio=0 tid=0x0 nid=0x0 waiting on condition
>>      java.lang.Thread.State: TIMED_WAITING
>> 
>> 	at java.lang.Thread.sleep(Native Method)
>> 	at com.intellij.util.TimeoutUtil.sleep(TimeoutUtil.java:58)
>> 	at com.intellij.util.io.BaseDataReader.doRun(BaseDataReader.java:105)
>> 	at com.intellij.util.io.BaseDataReader$1.run(BaseDataReader.java:46)
>> 	at com.intellij.openapi.application.impl.ApplicationImpl$9.run(ApplicationImpl.java:446)
>> 	at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
>> 	at java.util.concurrent.FutureTask.run(FutureTask.java:266)
>> 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
>> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
>> 	at java.lang.Thread.null(Unknown Source)
>> 	at com.intellij.openapi.application.impl.ApplicationImpl$1$1.run(ApplicationImpl.java:149)
>> 
>> "ApplicationImpl pooled thread 0" prio=0 tid=0x0 nid=0x0 waiting on condition
>>      java.lang.Thread.State: WAITING
>>  on java.lang.UNIXProcess at 4c4e9088
>> 	at java.lang.Object.wait(Native Method)
>> 	at java.lang.Object.wait(Object.java:502)
>> 	at java.lang.UNIXProcess.null(Unknown Source)
>> 	at com.intellij.execution.process.ProcessWaitFor$1.run(ProcessWaitFor.java:30)
>> 	at com.intellij.openapi.application.impl.ApplicationImpl$9.run(ApplicationImpl.java:446)
>> 	at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
>> 	at java.util.concurrent.FutureTask.run(FutureTask.java:266)
>> 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
>> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
>> 	at java.lang.Thread.null(Unknown Source)
>> 	at com.intellij.openapi.application.impl.ApplicationImpl$1$1.run(ApplicationImpl.java:149)
>> 
>> "process reaper" prio=0 tid=0x0 nid=0x0 runnable
>>      java.lang.Thread.State: RUNNABLE
>>  (in native)
>> 	at java.lang.UNIXProcess.waitForProcessExit(Native Method)
>> 	at java.lang.UNIXProcess.null(Unknown Source)
>> 	at java.lang.UNIXProcess$4.run(UNIXProcess.java:226)
>> 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
>> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
>> 	at java.lang.Thread.null(Unknown Source)
>> 
>> "Flushing thread" prio=0 tid=0x0 nid=0x0 waiting on condition
>>      java.lang.Thread.State: TIMED_WAITING
>>  on java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject at 7258e6d1
>> 	at sun.misc.Unsafe.park(Native Method)
>> 	at java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215)
>> 	at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(AbstractQueuedSynchronizer.java:2078)
>> 	at java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:1093)
>> 	at java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:809)
>> 	at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1067)
>> 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1127)
>> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
>> 	at java.lang.Thread.null(Unknown Source)
>> 
>> "ZipFileCache Dispose" prio=0 tid=0x0 nid=0x0 waiting on condition
>>      java.lang.Thread.State: TIMED_WAITING
>>  on java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject at 402a4629
>> 	at sun.misc.Unsafe.park(Native Method)
>> 	at java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215)
>> 	at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(AbstractQueuedSynchronizer.java:2078)
>> 	at java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:1093)
>> 	at java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:809)
>> 	at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1067)
>> 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1127)
>> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
>> 	at java.lang.Thread.null(Unknown Source)
>> 
>> "Periodic tasks thread" prio=0 tid=0x0 nid=0x0 waiting on condition
>>      java.lang.Thread.State: TIMED_WAITING
>>  on java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject at 33a2c55c
>> 	at sun.misc.Unsafe.park(Native Method)
>> 	at java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215)
>> 	at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(AbstractQueuedSynchronizer.java:2078)
>> 	at java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:1093)
>> 	at java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:809)
>> 	at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1067)
>> 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1127)
>> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
>> 	at java.lang.Thread.null(Unknown Source)
>> 
>> "AWT-EventQueue-0 14.0#IU-138.SNAPSHOT, eap:true" prio=0 tid=0x0 nid=0x0 runnable
>>      java.lang.Thread.State: RUNNABLE
>>  (in native)
>> 	at sun.lwawt.macosx.CCursorManager.nativeGetCursorPosition(Native Method)
>> 	at sun.lwawt.macosx.CCursorManager.getCursorPosition(CCursorManager.java:54)
>> 	at sun.lwawt.LWCursorManager.updateCursorImpl(LWCursorManager.java:80)
>> 	at sun.lwawt.LWCursorManager.updateCursor(LWCursorManager.java:57)
>> 	at sun.lwawt.LWComponentPeer.updateCursorImmediately(LWComponentPeer.java:894)
>> 	at java.awt.Component.updateCursorImmediately(Component.java:3137)
>> 	at java.awt.Container.validate(Container.java:1640)
>> 	at javax.swing.CellRendererPane.paintComponent(CellRendererPane.java:140)
>> 	at com.intellij.util.ui.tree.WideSelectionTreeUI$4.paintComponent(WideSelectionTreeUI.java:439)
>> 	at javax.swing.plaf.basic.BasicTreeUI.paintRow(BasicTreeUI.java:1540)
>> 	at com.intellij.util.ui.tree.WideSelectionTreeUI.paintRow(WideSelectionTreeUI.java:382)
>> 	at javax.swing.plaf.basic.BasicTreeUI.paint(BasicTreeUI.java:1224)
>> 	at com.intellij.util.ui.tree.WideSelectionTreeUI.paint(WideSelectionTreeUI.java:410)
>> 	at javax.swing.plaf.ComponentUI.update(ComponentUI.java:161)
>> 	at javax.swing.JComponent.paintComponent(JComponent.java:777)
>> 	at com.intellij.ui.treeStructure.Tree.paintComponent(Tree.java:328)
>> 	at javax.swing.JComponent.paint(JComponent.java:1053)
>> 	at com.intellij.ui.treeStructure.Tree.paint(Tree.java:244)
>> 	at javax.swing.JComponent.paintChildren(JComponent.java:886)
>> 	at javax.swing.JComponent.paint(JComponent.java:1062)
>> 	at javax.swing.JViewport.paint(JViewport.java:744)
>> 	at com.intellij.ui.components.JBViewport.paint(JBViewport.java:119)
>> 	at javax.swing.JComponent.paintChildren(JComponent.java:886)
>> 	at javax.swing.JComponent.paint(JComponent.java:1062)
>> 	at javax.swing.JComponent.paintChildren(JComponent.java:886)
>> 	at javax.swing.JComponent.paint(JComponent.java:1062)
>> 	at javax.swing.JComponent.paintChildren(JComponent.java:886)
>> 	at javax.swing.JComponent.paint(JComponent.java:1062)
>> 	at javax.swing.JComponent.paintChildren(JComponent.java:886)
>> 	at com.intellij.ui.tabs.impl.JBTabsImpl.paintChildren(JBTabsImpl.java:2271)
>> 	at javax.swing.JComponent.paint(JComponent.java:1062)
>> 	at com.intellij.ui.tabs.impl.JBTabsImpl.paint(JBTabsImpl.java:2266)
>> 	at javax.swing.JComponent.paintChildren(JComponent.java:886)
>> 	at javax.swing.JComponent.paint(JComponent.java:1062)
>> 	at javax.swing.JComponent.paintChildren(JComponent.java:886)
>> 	at javax.swing.JComponent.paint(JComponent.java:1062)
>> 	at javax.swing.JComponent.paintChildren(JComponent.java:886)
>> 	at javax.swing.JComponent.paint(JComponent.java:1062)
>> 	at javax.swing.JComponent.paintChildren(JComponent.java:886)
>> 	at javax.swing.JComponent.paint(JComponent.java:1062)
>> 	at javax.swing.JComponent.paintChildren(JComponent.java:886)
>> 	at com.intellij.ui.tabs.impl.JBTabsImpl.paintChildren(JBTabsImpl.java:2271)
>> 	at javax.swing.JComponent.paint(JComponent.java:1062)
>> 	at com.intellij.ui.tabs.impl.JBTabsImpl.paint(JBTabsImpl.java:2266)
>> 	at javax.swing.JComponent.paintToOffscreen(JComponent.java:5228)
>> 	at javax.swing.RepaintManager$PaintManager.paintDoubleBuffered(RepaintManager.java:1532)
>> 	at javax.swing.RepaintManager$PaintManager.paint(RepaintManager.java:1455)
>> 	at javax.swing.RepaintManager.paint(RepaintManager.java:1252)
>> 	at javax.swing.JComponent._paintImmediately(JComponent.java:5176)
>> 	at javax.swing.JComponent.paintImmediately(JComponent.java:4987)
>> 	at javax.swing.RepaintManager$3.run(RepaintManager.java:811)
>> 	at javax.swing.RepaintManager$3.run(RepaintManager.java:794)
>> 	at java.security.AccessController.doPrivileged(Native Method)
>> 	at java.security.ProtectionDomain$1.doIntersectionPrivilege(ProtectionDomain.java:75)
>> 	at javax.swing.RepaintManager.paintDirtyRegions(RepaintManager.java:794)
>> 	at javax.swing.RepaintManager.paintDirtyRegions(RepaintManager.java:769)
>> 	at javax.swing.RepaintManager.prePaintDirtyRegions(RepaintManager.java:718)
>> 	at javax.swing.RepaintManager.access$1100(RepaintManager.java:62)
>> 	at javax.swing.RepaintManager$ProcessingRunnable.run(RepaintManager.java:1680)
>> 	at java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:311)
>> 	at java.awt.EventQueue.null(Unknown Source)
>> 	at java.awt.EventQueue.null(Unknown Source)
>> 	at java.awt.EventQueue$3.run(EventQueue.java:697)
>> 	at java.awt.EventQueue$3.run(EventQueue.java:691)
>> 	at java.security.AccessController.doPrivileged(Native Method)
>> 	at java.security.ProtectionDomain$1.doIntersectionPrivilege(ProtectionDomain.java:75)
>> 	at java.awt.EventQueue.null(Unknown Source)
>> 	at com.intellij.ide.IdeEventQueue.defaultDispatchEvent(IdeEventQueue.java:722)
>> 	at com.intellij.ide.IdeEventQueue._dispatchEvent(IdeEventQueue.java:549)
>> 	at com.intellij.ide.IdeEventQueue.dispatchEvent(IdeEventQueue.java:360)
>> 	at java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:201)
>> 	at java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:116)
>> 	at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:105)
>> 	at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:101)
>> 	at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:93)
>> 	at java.awt.EventDispatchThread.run(EventDispatchThread.java:82)
>> 
>> "Lock thread" prio=0 tid=0x0 nid=0x0 runnable
>>      java.lang.Thread.State: RUNNABLE
>>  (in native)
>> 	at java.net.PlainSocketImpl.socketAccept(Native Method)
>> 	at java.net.AbstractPlainSocketImpl.accept(AbstractPlainSocketImpl.java:404)
>> 	at java.net.ServerSocket.null(Unknown Source)
>> 	at java.net.ServerSocket.null(Unknown Source)
>> 	at com.intellij.idea.SocketLock$MyRunnable.run(SocketLock.java:224)
>> 	at java.lang.Thread.null(Unknown Source)
>> 
>> "DestroyJavaVM" prio=0 tid=0x0 nid=0x0 runnable
>>      java.lang.Thread.State: RUNNABLE
>> 
>> 
>> "Java2D Disposer" prio=0 tid=0x0 nid=0x0 waiting on condition
>>      java.lang.Thread.State: WAITING
>>  on java.lang.ref.ReferenceQueue$Lock at 3e0bc8b5
>> 	at java.lang.Object.wait(Native Method)
>> 	at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:142)
>> 	at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:158)
>> 	at sun.java2d.Disposer.run(Disposer.java:148)
>> 	at java.lang.Thread.null(Unknown Source)
>> 
>> "Java2D Queue Flusher" prio=0 tid=0x0 nid=0x0 waiting on condition
>>      java.lang.Thread.State: TIMED_WAITING
>>  on sun.java2d.opengl.OGLRenderQueue$QueueFlusher at bd0c970
>> 	at java.lang.Object.wait(Native Method)
>> 	at sun.java2d.opengl.OGLRenderQueue$QueueFlusher.run(OGLRenderQueue.java:203)
>> 
>> "AWT-Shutdown" prio=0 tid=0x0 nid=0x0 waiting on condition
>>      java.lang.Thread.State: WAITING
>>  on java.lang.Object at 2c82ca53
>> 	at java.lang.Object.wait(Native Method)
>> 	at java.lang.Object.wait(Object.java:502)
>> 	at sun.awt.AWTAutoShutdown.run(AWTAutoShutdown.java:295)
>> 	at java.lang.Thread.null(Unknown Source)
>> 
>> "AWT-AppKit" prio=0 tid=0x0 nid=0x0 blocked
>>      java.lang.Thread.State: BLOCKED
>>  on java.awt.Component$AWTTreeLock at ec5c064 owned by "AWT-EventQueue-0 14.0#IU-138.SNAPSHOT, eap:true" Id=24
>> 	at java.awt.Container.getComponentZOrder(Container.java:938)
>> 	at javax.swing.LayoutComparator.compare(LayoutComparator.java:116)
>> 	at javax.swing.LayoutComparator.compare(LayoutComparator.java:42)
>> 	at java.util.TimSort.countRunAndMakeAscending(TimSort.java:356)
>> 	at java.util.TimSort.sort(TimSort.java:216)
>> 	at java.util.Arrays.sort(Arrays.java:1512)
>> 	at java.util.ArrayList.sort(ArrayList.java:1454)
>> 	at java.util.Collections.sort(Collections.java:175)
>> 	at javax.swing.SortingFocusTraversalPolicy.enumerateAndSortCycle(SortingFocusTraversalPolicy.java:136)
>> 	at javax.swing.SortingFocusTraversalPolicy.getFocusTraversalCycle(SortingFocusTraversalPolicy.java:110)
>> 	at javax.swing.SortingFocusTraversalPolicy.getFirstComponent(SortingFocusTraversalPolicy.java:445)
>> 	at javax.swing.LayoutFocusTraversalPolicy.getFirstComponent(LayoutFocusTraversalPolicy.java:166)
>> 	at javax.swing.SortingFocusTraversalPolicy.getDefaultComponent(SortingFocusTraversalPolicy.java:535)
>> 	at java.awt.Window.isFocusableWindow(Window.java:2496)
>> 	at sun.lwawt.LWWindowPeer.isFocusableWindow(LWWindowPeer.java:1217)
>> 	at sun.lwawt.LWWindowPeer.focusAllowedFor(LWWindowPeer.java:1213)
>> 	at sun.lwawt.LWWindowPeer.requestWindowFocus(LWWindowPeer.java:1151)
>> 	at sun.lwawt.LWWindowPeer.notifyMouseEvent(LWWindowPeer.java:799)
>> 	at sun.lwawt.macosx.CPlatformResponder.handleMouseEvent(CPlatformResponder.java:83)
>> 	at sun.lwawt.macosx.CPlatformView.deliverMouseEvent(CPlatformView.java:197)
>> 
>> "ZipFileCache Dispose" prio=0 tid=0x0 nid=0x0 waiting on condition
>>      java.lang.Thread.State: TIMED_WAITING
>>  on java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject at 9af62ba
>> 	at sun.misc.Unsafe.park(Native Method)
>> 	at java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215)
>> 	at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(AbstractQueuedSynchronizer.java:2078)
>> 	at java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:1093)
>> 	at java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:809)
>> 	at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1067)
>> 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1127)
>> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
>> 	at java.lang.Thread.null(Unknown Source)
>> 
>> "JDWP Event Helper Thread" prio=0 tid=0x0 nid=0x0 runnable
>>      java.lang.Thread.State: RUNNABLE
>> 
>> 
>> "JDWP Transport Listener: dt_socket" prio=0 tid=0x0 nid=0x0 runnable
>>      java.lang.Thread.State: RUNNABLE
>>  (in native)
>> 
>> "Signal Dispatcher" prio=0 tid=0x0 nid=0x0 runnable
>>      java.lang.Thread.State: RUNNABLE
>> 
>> 
>> "Finalizer" prio=0 tid=0x0 nid=0x0 waiting on condition
>>      java.lang.Thread.State: WAITING
>>  on java.lang.ref.ReferenceQueue$Lock at 4b9a1b6
>> 	at java.lang.Object.wait(Native Method)
>> 	at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:142)
>> 	at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:158)
>> 	at java.lang.ref.Finalizer$FinalizerThread.run(Finalizer.java:209)
>> 
>> "Reference Handler" prio=0 tid=0x0 nid=0x0 waiting on condition
>>      java.lang.Thread.State: WAITING
>>  on java.lang.ref.Reference$Lock at 64178ff4
>> 	at java.lang.Object.wait(Native Method)
>> 	at java.lang.Object.wait(Object.java:502)
>> 	at java.lang.ref.Reference$ReferenceHandler.run(Reference.java:157)
>> 
>> 
>> __
>> Konstantin Bulenkov
>> IntelliJ Platform UI Lead
>> JetBrains
>> 
>> 
>> 
> 


From Sergey.Bylokhov at oracle.com  Thu Jun 26 13:01:57 2014
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Thu, 26 Jun 2014 17:01:57 +0400
Subject: <AWT Dev> [9] Review request for 8043967: Fix doclint warnings
 for java.awt
In-Reply-To: <53A84C1C.1080107@oracle.com>
References: <538DC421.7060204@oracle.com>
	<538DD3FD.8050909@oracle.com>	<538DFBF7.3040502@oracle.com>
	<5397FEB1.2080906@oracle.com>	<53A7F4D3.1090505@oracle.com>	<FC104E8A-B5C9-4769-8888-9C2C80398836@oracle.com>
	<53A84C1C.1080107@oracle.com>
Message-ID: <53AC19C5.7020703@oracle.com>

Hi, Alexander.
Please use client's workspace for client's fixes next time.
In the problem below "import" will solve your problem.

On 23.06.2014 19:47, alexander stepanov wrote:
> Hello Petr,
>
> > AWTKeyStroke why do you use a full name in @throws?
>
> In case of short name the following error occurs:
>
> /home/user/hd2/doclint/current/src/jdk/src/share/classes/java/awt/AWTKeyStroke.java:805: 
> error: reference not found
>      * @throws ObjectStreamException if a serialization problem occurs
>        ^
> /home/user/hd2/doclint/current/src/jdk/src/share/classes/java/awt/AWTKeyStroke.java:807: 
> warning: no @throws for java.io.ObjectStreamException
>     protected Object readResolve() throws java.io.ObjectStreamException {
>                      ^
>
> So it seems that javadoc is happy here only if the full exception name 
> is used. It doesn't affect the resulting html.
>
> The other notes were fixed, thanks:
> http://cr.openjdk.java.net/~avstepan/8043967/webrev.02/
>
> Regards,
> Alexander
>
>
> On 23.06.2014 16:58, Petr Pchelko wrote:
>> Hello, Alexander.
>>
>> A couple of comments:
>>
>> AWTKeyStroke why do you use a full name in @throws?
>> HeadlessException.getMessage you could use @inheritDoc here.
>> KeyboardFocusManager: 1463 Why did you add an extra line here?
>> Robot: 513 - the line is not aligned
>>
>> With best regards. Petr.
>>
>> On 23 ???? 2014 ?., at 13:35, alexander stepanov 
>> <alexander.v.stepanov at oracle.com> wrote:
>>
>>> Sorry, just a reminder.
>>>> On 03.06.2014 20:46, alexander stepanov wrote:
>>>>> Hello Sergey,
>>>>>
>>>>> Updated; please see
>>>>> http://cr.openjdk.java.net/~avstepan/8043967/webrev.01/
>>>>>
>>>>> Thanks,
>>>>> Alexander
>>>>>
>>>>> On 03.06.2014 17:56, Sergey Bylokhov wrote:
>>>>>> Hi, Alexander.
>>>>>> A few notes:
>>>>>> - Use two spaces after @param tag only. in other cases use one 
>>>>>> space.
>>>>>> - Do no align names of the @params tag like this:
>>>>>>   390      * position will not be replaced).
>>>>>>   391      * @param   str  the non-{@code null} text to use as
>>>>>>   392      *               the replacement
>>>>>>   393      * @param   start  the start position
>>>>>>   394      * @param   end    the end position
>>>>>>   395      * @deprecated As of JDK version 1.1,
>>>>>> Change them to:
>>>>>>   390      * position will not be replaced).
>>>>>>   391      * @param  str the non-{@code null} text to use as
>>>>>>   392      *         the replacement
>>>>>>   393      * @param  start the start position
>>>>>>   394      * @param  end the end position
>>>>>>   395      * @deprecated As of JDK version 1.1,
>>>>>>   - Add empty line after method description before @param tag.
>>>>>>   - Description of the method should ends by dot.
>>>>>>
>>>>>> On 6/3/14 4:48 PM, alexander stepanov wrote:
>>>>>>> Hello,
>>>>>>>
>>>>>>> Could you please review the fix for the following bug:
>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8043967
>>>>>>>
>>>>>>> Webrev:
>>>>>>> http://cr.openjdk.java.net/~avstepan/8043967
>>>>>>>
>>>>>>> Just a cleanup of javadoc to avoid doclint warnings.
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Alexander
>>>>>>
>>>>>> -- 
>>>>>> Best regards, Sergey.
>


-- 
Best regards, Sergey.


From yuri.nesterenko at oracle.com  Thu Jun 26 13:15:42 2014
From: yuri.nesterenko at oracle.com (Yuri Nesterenko)
Date: Thu, 26 Jun 2014 17:15:42 +0400
Subject: <AWT Dev> [9] Review request for 8043967: Fix doclint warnings
 for java.awt
In-Reply-To: <53AC19C5.7020703@oracle.com>
References: <538DC421.7060204@oracle.com>	<538DD3FD.8050909@oracle.com>	<538DFBF7.3040502@oracle.com>	<5397FEB1.2080906@oracle.com>	<53A7F4D3.1090505@oracle.com>	<FC104E8A-B5C9-4769-8888-9C2C80398836@oracle.com>	<53A84C1C.1080107@oracle.com>
	<53AC19C5.7020703@oracle.com>
Message-ID: <53AC1CFE.7090400@oracle.com>

Hi Sergey,

unfortunately, it's a requirement to use dev workspace for
all doclint changes. Fortunately, the task is ALMOST finished!
Well, just kidding: it's effectively endless.

Cheers,
-yan


On 06/26/2014 05:01 PM, Sergey Bylokhov wrote:
> Hi, Alexander.
> Please use client's workspace for client's fixes next time.
> In the problem below "import" will solve your problem.
>
> On 23.06.2014 19:47, alexander stepanov wrote:
>> Hello Petr,
>>
>> > AWTKeyStroke why do you use a full name in @throws?
>>
>> In case of short name the following error occurs:
>>
>> /home/user/hd2/doclint/current/src/jdk/src/share/classes/java/awt/AWTKeyStroke.java:805:
>> error: reference not found
>>      * @throws ObjectStreamException if a serialization problem occurs
>>        ^
>> /home/user/hd2/doclint/current/src/jdk/src/share/classes/java/awt/AWTKeyStroke.java:807:
>> warning: no @throws for java.io.ObjectStreamException
>>     protected Object readResolve() throws java.io.ObjectStreamException {
>>                      ^
>>
>> So it seems that javadoc is happy here only if the full exception name
>> is used. It doesn't affect the resulting html.
>>
>> The other notes were fixed, thanks:
>> http://cr.openjdk.java.net/~avstepan/8043967/webrev.02/
>>
>> Regards,
>> Alexander
>>
>>
>> On 23.06.2014 16:58, Petr Pchelko wrote:
>>> Hello, Alexander.
>>>
>>> A couple of comments:
>>>
>>> AWTKeyStroke why do you use a full name in @throws?
>>> HeadlessException.getMessage you could use @inheritDoc here.
>>> KeyboardFocusManager: 1463 Why did you add an extra line here?
>>> Robot: 513 - the line is not aligned
>>>
>>> With best regards. Petr.
>>>
>>> On 23 ???? 2014 ?., at 13:35, alexander stepanov
>>> <alexander.v.stepanov at oracle.com> wrote:
>>>
>>>> Sorry, just a reminder.
>>>>> On 03.06.2014 20:46, alexander stepanov wrote:
>>>>>> Hello Sergey,
>>>>>>
>>>>>> Updated; please see
>>>>>> http://cr.openjdk.java.net/~avstepan/8043967/webrev.01/
>>>>>>
>>>>>> Thanks,
>>>>>> Alexander
>>>>>>
>>>>>> On 03.06.2014 17:56, Sergey Bylokhov wrote:
>>>>>>> Hi, Alexander.
>>>>>>> A few notes:
>>>>>>> - Use two spaces after @param tag only. in other cases use one
>>>>>>> space.
>>>>>>> - Do no align names of the @params tag like this:
>>>>>>>   390      * position will not be replaced).
>>>>>>>   391      * @param   str  the non-{@code null} text to use as
>>>>>>>   392      *               the replacement
>>>>>>>   393      * @param   start  the start position
>>>>>>>   394      * @param   end    the end position
>>>>>>>   395      * @deprecated As of JDK version 1.1,
>>>>>>> Change them to:
>>>>>>>   390      * position will not be replaced).
>>>>>>>   391      * @param  str the non-{@code null} text to use as
>>>>>>>   392      *         the replacement
>>>>>>>   393      * @param  start the start position
>>>>>>>   394      * @param  end the end position
>>>>>>>   395      * @deprecated As of JDK version 1.1,
>>>>>>>   - Add empty line after method description before @param tag.
>>>>>>>   - Description of the method should ends by dot.
>>>>>>>
>>>>>>> On 6/3/14 4:48 PM, alexander stepanov wrote:
>>>>>>>> Hello,
>>>>>>>>
>>>>>>>> Could you please review the fix for the following bug:
>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8043967
>>>>>>>>
>>>>>>>> Webrev:
>>>>>>>> http://cr.openjdk.java.net/~avstepan/8043967
>>>>>>>>
>>>>>>>> Just a cleanup of javadoc to avoid doclint warnings.
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>> Alexander
>>>>>>>
>>>>>>> --
>>>>>>> Best regards, Sergey.
>>
>
>


From philip.race at oracle.com  Thu Jun 26 14:11:54 2014
From: philip.race at oracle.com (Phil Race)
Date: Thu, 26 Jun 2014 07:11:54 -0700
Subject: <AWT Dev> [9] Review request for 8043967: Fix doclint warnings
 for java.awt
In-Reply-To: <53AC1CFE.7090400@oracle.com>
References: <538DC421.7060204@oracle.com>	<538DD3FD.8050909@oracle.com>	<538DFBF7.3040502@oracle.com>	<5397FEB1.2080906@oracle.com>	<53A7F4D3.1090505@oracle.com>	<FC104E8A-B5C9-4769-8888-9C2C80398836@oracle.com>	<53A84C1C.1080107@oracle.com>	<53AC19C5.7020703@oracle.com>
	<53AC1CFE.7090400@oracle.com>
Message-ID: <53AC2A2A.30109@oracle.com>

On 6/26/14 6:15 AM, Yuri Nesterenko wrote:
> Hi Sergey,
>
> unfortunately, it's a requirement to use dev workspace for

Actually its not. I don't know who told you that but they are dead wrong.
This is causing merge pain. client file changes go via client.

-phil.

> all doclint changes. Fortunately, the task is ALMOST finished!
> Well, just kidding: it's effectively endless.
>
> Cheers,
> -yan
>
>
> On 06/26/2014 05:01 PM, Sergey Bylokhov wrote:
>> Hi, Alexander.
>> Please use client's workspace for client's fixes next time.
>> In the problem below "import" will solve your problem.
>>
>> On 23.06.2014 19:47, alexander stepanov wrote:
>>> Hello Petr,
>>>
>>> > AWTKeyStroke why do you use a full name in @throws?
>>>
>>> In case of short name the following error occurs:
>>>
>>> /home/user/hd2/doclint/current/src/jdk/src/share/classes/java/awt/AWTKeyStroke.java:805: 
>>>
>>> error: reference not found
>>>      * @throws ObjectStreamException if a serialization problem occurs
>>>        ^
>>> /home/user/hd2/doclint/current/src/jdk/src/share/classes/java/awt/AWTKeyStroke.java:807: 
>>>
>>> warning: no @throws for java.io.ObjectStreamException
>>>     protected Object readResolve() throws 
>>> java.io.ObjectStreamException {
>>>                      ^
>>>
>>> So it seems that javadoc is happy here only if the full exception name
>>> is used. It doesn't affect the resulting html.
>>>
>>> The other notes were fixed, thanks:
>>> http://cr.openjdk.java.net/~avstepan/8043967/webrev.02/
>>>
>>> Regards,
>>> Alexander
>>>
>>>
>>> On 23.06.2014 16:58, Petr Pchelko wrote:
>>>> Hello, Alexander.
>>>>
>>>> A couple of comments:
>>>>
>>>> AWTKeyStroke why do you use a full name in @throws?
>>>> HeadlessException.getMessage you could use @inheritDoc here.
>>>> KeyboardFocusManager: 1463 Why did you add an extra line here?
>>>> Robot: 513 - the line is not aligned
>>>>
>>>> With best regards. Petr.
>>>>
>>>> On 23 ???? 2014 ?., at 13:35, alexander stepanov
>>>> <alexander.v.stepanov at oracle.com> wrote:
>>>>
>>>>> Sorry, just a reminder.
>>>>>> On 03.06.2014 20:46, alexander stepanov wrote:
>>>>>>> Hello Sergey,
>>>>>>>
>>>>>>> Updated; please see
>>>>>>> http://cr.openjdk.java.net/~avstepan/8043967/webrev.01/
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Alexander
>>>>>>>
>>>>>>> On 03.06.2014 17:56, Sergey Bylokhov wrote:
>>>>>>>> Hi, Alexander.
>>>>>>>> A few notes:
>>>>>>>> - Use two spaces after @param tag only. in other cases use one
>>>>>>>> space.
>>>>>>>> - Do no align names of the @params tag like this:
>>>>>>>>   390      * position will not be replaced).
>>>>>>>>   391      * @param   str  the non-{@code null} text to use as
>>>>>>>>   392      *               the replacement
>>>>>>>>   393      * @param   start  the start position
>>>>>>>>   394      * @param   end    the end position
>>>>>>>>   395      * @deprecated As of JDK version 1.1,
>>>>>>>> Change them to:
>>>>>>>>   390      * position will not be replaced).
>>>>>>>>   391      * @param  str the non-{@code null} text to use as
>>>>>>>>   392      *         the replacement
>>>>>>>>   393      * @param  start the start position
>>>>>>>>   394      * @param  end the end position
>>>>>>>>   395      * @deprecated As of JDK version 1.1,
>>>>>>>>   - Add empty line after method description before @param tag.
>>>>>>>>   - Description of the method should ends by dot.
>>>>>>>>
>>>>>>>> On 6/3/14 4:48 PM, alexander stepanov wrote:
>>>>>>>>> Hello,
>>>>>>>>>
>>>>>>>>> Could you please review the fix for the following bug:
>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8043967
>>>>>>>>>
>>>>>>>>> Webrev:
>>>>>>>>> http://cr.openjdk.java.net/~avstepan/8043967
>>>>>>>>>
>>>>>>>>> Just a cleanup of javadoc to avoid doclint warnings.
>>>>>>>>>
>>>>>>>>> Thanks,
>>>>>>>>> Alexander
>>>>>>>>
>>>>>>>> -- 
>>>>>>>> Best regards, Sergey.
>>>
>>
>>
>


From artem.malinko at oracle.com  Thu Jun 26 15:30:05 2014
From: artem.malinko at oracle.com (artem malinko)
Date: Thu, 26 Jun 2014 19:30:05 +0400
Subject: <AWT Dev> Review a fix for List leak
Message-ID: <53AC3C7D.8030204@oracle.com>

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  Thu Jun 26 21:12:21 2014
From: anthony.petrov at oracle.com (Anthony Petrov)
Date: Fri, 27 Jun 2014 01:12:21 +0400
Subject: <AWT Dev> Review a fix for List leak
In-Reply-To: <53AC3C7D.8030204@oracle.com>
References: <53AC3C7D.8030204@oracle.com>
Message-ID: <53AC8CB5.1070806@oracle.com>

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  Mon Jun 30 10:17:21 2014
From: artem.malinko at oracle.com (artem malinko)
Date: Mon, 30 Jun 2014 14:17:21 +0400
Subject: <AWT Dev> Review a fix for List leak
In-Reply-To: <53AC8CB5.1070806@oracle.com>
References: <53AC3C7D.8030204@oracle.com> <53AC8CB5.1070806@oracle.com>
Message-ID: <53B13931.9030104@oracle.com>

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  Mon Jun 30 10:40:22 2014
From: petr.pchelko at oracle.com (Petr Pchelko)
Date: Mon, 30 Jun 2014 14:40:22 +0400
Subject: <AWT Dev> Review a fix for List leak
In-Reply-To: <53B13931.9030104@oracle.com>
References: <53AC3C7D.8030204@oracle.com> <53AC8CB5.1070806@oracle.com>
	<53B13931.9030104@oracle.com>
Message-ID: <0B943DB7-A76B-48C2-8076-9AA60B6CB8AB@oracle.com>

Hello, Artem.

I have a number of comments about the test:
1. The test lacks a copyright header. Could you please add it. You can use any other test to get an example of a correct header.
2. Please limit the maximum heap size for the test with -Xmx option. 100mb should be enough, it's pointless to fill the whole system memory.
3. The pattern in the test's main method is quite strange. It's better to dispose the frame in a finally block
4. Lines 37-43. Normally we do not use blocks to group the code together.
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?
6. Do not use System.exit in the tests. Please remove lines 26 to 31.
7. You need to add @bug with the bug id in the test header.

As for you initial evaluation:
>>> 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.
Why is is already initialized? Does this mean that the CreateHWND is called multiple times on the same component? 
I'm not sure it's correct, because this means we are creating multiple native components for the same AWT component and leaking native HWNDs.
Where is the original reference created?

Thank you.
With best regards. Petr.

On 30 ???? 2014 ?., at 14:17, artem malinko <artem.malinko at oracle.com> 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  Mon Jun 30 15:14:37 2014
From: anthony.petrov at oracle.com (Anthony Petrov)
Date: Mon, 30 Jun 2014 19:14:37 +0400
Subject: <AWT Dev> Review a fix for List leak
In-Reply-To: <53B13931.9030104@oracle.com>
References: <53AC3C7D.8030204@oracle.com> <53AC8CB5.1070806@oracle.com>
	<53B13931.9030104@oracle.com>
Message-ID: <53B17EDD.6090103@oracle.com>

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