From semyon.sadetsky at oracle.com  Wed Jun  1 06:57:01 2016
From: semyon.sadetsky at oracle.com (Semyon Sadetsky)
Date: Wed, 1 Jun 2016 09:57:01 +0300
Subject: <AWT Dev> <AWT dev>[9] Review request for 8022810: Cannot list
 all the available display modes on Ubuntu linux in case of two screen
 devices
In-Reply-To: <4f58051d-a76b-4d4f-c8c4-2aa71a3c1295@oracle.com>
References: <573579EC.6000105@oracle.com>
	<ad449d68-fd9a-0078-626c-d515cc344775@oracle.com>
	<f8acf699-0296-4013-7c17-841c1ff45325@oracle.com>
	<acf4ee13-8d76-f4a3-76b3-ee8bbae8f652@oracle.com>
	<1e8b8362-9813-4ef9-d46d-9d87f5c2ac0f@oracle.com>
	<a6db7025-e6c4-01c1-8f5f-04207edb15aa@oracle.com>
	<7d72df28-6063-871c-2b76-dc040a1011c9@oracle.com>
	<210dbdfe-a115-61e7-2e8e-8c388913812b@oracle.com>
	<ed10bf97-e37c-76d2-7542-e1013de1e871@oracle.com>
	<5d40566d-70e2-0d46-0d2a-b375e80eedd6@oracle.com>
	<74670508-fc12-7423-812c-313161ee3e59@oracle.com>
	<9cd3e850-51fb-40a0-be98-47e9d2841491@oracle.com>
	<4f58051d-a76b-4d4f-c8c4-2aa71a3c1295@oracle.com>
Message-ID: <74a58110-73d6-8ffa-2b98-8a196f655d57@oracle.com>



On 5/31/2016 6:54 PM, Sergey Bylokhov wrote:
> On 31.05.16 18:49, Semyon Sadetsky wrote:
>>> Can you please provide the output of the test from the CR before/after
>>> the fix on your system?
>> it is not necessary. You can run the provided test before and the fix
>> and see that the list returned by getDisplayModes() is identical to
>> xrandr output for any screen number on linux. There is nothing else to
>> prove for this bug fix.
>
> I cannot do that because I have no multi-monitor linux configuration. 
> And you mentioned that on you system the output is different from what 
> was added to the bug description. So provide it here or add as a 
> comment to JBS.
I don't have access to such hardware as well. I'm using linux VMs with 
several virtual screens. Adding a new screen to a VM configuration can 
be done in 10 seconds in most VMMs.
The result of the getDisplayModes() for 2-screen Ubuntu VM before the 
fix looked like:
for device[0]: <current screen 0 mode>, <<the rest modes of 
screen-0>>,<<all modes of screen-1>>
for device[1]: <current screen 1 mode>

--Semyon
>
>>>>> ============================
>>>>> Compile and run it on a system with two displays. Here is output when
>>>>> both display are switched on (note: only current resolutions are
>>>>> listed):
>>>>> Device: X11GraphicsDevice[screen=0]
>>>>> Resolutions:
>>>>> 966x1280
>>>>> Device: X11GraphicsDevice[screen=1]
>>>>> Resolutions:
>>>>> 920x1280
>>>>> ============================
>>>>> Then try to switch one of the displays (e.g., System
>>>>> Settings->Displays etc.) off and run the test again. The test output
>>>>> looks like:
>>>>> Device: X11GraphicsDevice[screen=0]
>>>>> Resolutions:
>>>>> 966x1280
>>>>> 960x1280
>>>>> 768x1024
>>>>> 600x800
>>>>> 480x640
>>>>> ============================
>>>>>
>>>>>>> the list of supported modes changed and my question was: what 
>>>>>>> happens
>>>>>>> when these modes will be passed to setDisplayMode() (of course 
>>>>>>> modes
>>>>>>> and setDisplayMode should be from one GraphicsDevice object).
>>>>>> the same as before the fix.
>>>>>> ---
>>>>>> Do you see any other concerns to the fix?
>>>>>
>>>>>
>>>>
>>>
>>>
>>
>
>


From semyon.sadetsky at oracle.com  Wed Jun  1 11:23:22 2016
From: semyon.sadetsky at oracle.com (Semyon Sadetsky)
Date: Wed, 1 Jun 2016 14:23:22 +0300
Subject: <AWT Dev> Taking screenshots on x11 composite desktop produce
 wrong result
In-Reply-To: <131c0e73-8fc9-2db2-b4bf-b110d4fcdbeb@oracle.com>
References: <CAJwKKmZ__GVT6aVRA+gNJ=gYnwNAmkG18BLmju2A05Vrkr+QrQ@mail.gmail.com>
	<56D713BB.5030305@oracle.com>
	<CAJwKKmaTc2Oe9E3y57y5iG1keqA9jU_NJCy1yQEe0GTG3QXokg@mail.gmail.com>
	<CAJwKKmb9USyRxSmEw_U2ur6cAAkmPJDBmhQN=4EV0u9wkqw5hA@mail.gmail.com>
	<CAJwKKmYDYGcgdtZLTaimE=8Y_PDdB22dB1C+58CfXDnA-t6n+w@mail.gmail.com>
	<5704EA02.1090500@oracle.com>
	<CAJwKKmaxvNMTfSrz1Tk0ChMC8ZcRWkRXbo9ZU1dKbwerKb_ymw@mail.gmail.com>
	<5704FAD9.50805@oracle.com>
	<CAGUMyaSERCsb2KrumOGxLALHqgWM=uT=FrrKSBxPFM-3WAR3VA@mail.gmail.com>
	<a33b671c-f478-f430-431e-8fc5e589c5d9@oracle.com>
	<CAGUMyaROjZ33O2yRtvdRWf9UBG7r7823A9me6rh-5zEmt7bGWQ@mail.gmail.com>
	<5594e799-8935-f079-2fe3-60b5079eab4a@oracle.com>
	<131c0e73-8fc9-2db2-b4bf-b110d4fcdbeb@oracle.com>
Message-ID: <b7d3a594-9fca-ad39-71c8-eed46acbc138@oracle.com>

I ran JPRT build. It seems that the build server does not have the 
requested header:

/opt/jprt/T/P1/102200.ssadetsk/s/jdk/src/java.desktop/unix/native/libawt_xawt/awt/awt_Robot.c:40:39: fatal error: X11/extensions/Xcomposite.h: No such file or directory
  #include <X11/extensions/Xcomposite.h>

someone need to install Xcomposite library there

--Semyon


On 5/31/2016 5:29 PM, Sergey Bylokhov wrote:
> Hi, Mario.
> Thanks for your contribution! there is tiny typo in the native: 
> isGtkSupported should be useGtk. It will be good if someone run jprt 
> job to confirm that the build is ok, since make file was changed.
>
> On 31.05.16 13:45, Semyon Sadetsky wrote:
>>
>>
>> On 5/31/2016 1:36 PM, Mario Torre wrote:
>>> 2016-05-30 17:53 GMT+02:00 Semyon Sadetsky 
>>> <semyon.sadetsky at oracle.com>:
>>>
>>>> The rest is OK to me.
>>> Great, thanks!
>>>
>>> This is the final webrev:
>>>
>>> http://cr.openjdk.java.net/~neugens/8150954/webrev.04/
>> Thanks a lot!
>>>
>>> Assuming it's still OK for you, I believe I need another reviewer's OK
>>> to push?
>> Yes, reviewing is not that fast currently. Probably azvegint could help,
>> he is an author of the GTK screenshoting code. I'll ping him.
>>
>> --Semyon
>>>
>>> Cheers,
>>> Mario
>>
>
>

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

From neugens at redhat.com  Wed Jun  1 11:39:34 2016
From: neugens at redhat.com (Mario Torre)
Date: Wed, 1 Jun 2016 13:39:34 +0200
Subject: <AWT Dev> Taking screenshots on x11 composite desktop produce
 wrong result
In-Reply-To: <b7d3a594-9fca-ad39-71c8-eed46acbc138@oracle.com>
References: <CAJwKKmZ__GVT6aVRA+gNJ=gYnwNAmkG18BLmju2A05Vrkr+QrQ@mail.gmail.com>
	<56D713BB.5030305@oracle.com>
	<CAJwKKmaTc2Oe9E3y57y5iG1keqA9jU_NJCy1yQEe0GTG3QXokg@mail.gmail.com>
	<CAJwKKmb9USyRxSmEw_U2ur6cAAkmPJDBmhQN=4EV0u9wkqw5hA@mail.gmail.com>
	<CAJwKKmYDYGcgdtZLTaimE=8Y_PDdB22dB1C+58CfXDnA-t6n+w@mail.gmail.com>
	<5704EA02.1090500@oracle.com>
	<CAJwKKmaxvNMTfSrz1Tk0ChMC8ZcRWkRXbo9ZU1dKbwerKb_ymw@mail.gmail.com>
	<5704FAD9.50805@oracle.com>
	<CAGUMyaSERCsb2KrumOGxLALHqgWM=uT=FrrKSBxPFM-3WAR3VA@mail.gmail.com>
	<a33b671c-f478-f430-431e-8fc5e589c5d9@oracle.com>
	<CAGUMyaROjZ33O2yRtvdRWf9UBG7r7823A9me6rh-5zEmt7bGWQ@mail.gmail.com>
	<5594e799-8935-f079-2fe3-60b5079eab4a@oracle.com>
	<131c0e73-8fc9-2db2-b4bf-b110d4fcdbeb@oracle.com>
	<b7d3a594-9fca-ad39-71c8-eed46acbc138@oracle.com>
Message-ID: <CAJwKKmb7CpgcOQdLviOm3SxtV37K7YaotZZpDpG6w3Ryc1Lzug@mail.gmail.com>

On Wed, Jun 1, 2016 at 1:23 PM, Semyon Sadetsky
<semyon.sadetsky at oracle.com> wrote:
> I ran JPRT build. It seems that the build server does not have the requested
> header:
>
> /opt/jprt/T/P1/102200.ssadetsk/s/jdk/src/java.desktop/unix/native/libawt_xawt/awt/awt_Robot.c:40:39:
> fatal error: X11/extensions/Xcomposite.h: No such file or directory
>  #include <X11/extensions/Xcomposite.h>
>
> someone need to install Xcomposite library there
>

Should this be made optional?

I can do some dlsym hack if necessary (I would prefer to avoid that though).

Cheers,
Mario

From semyon.sadetsky at oracle.com  Wed Jun  1 11:52:57 2016
From: semyon.sadetsky at oracle.com (Semyon Sadetsky)
Date: Wed, 1 Jun 2016 14:52:57 +0300
Subject: <AWT Dev> Taking screenshots on x11 composite desktop produce
 wrong result
In-Reply-To: <CAJwKKmb7CpgcOQdLviOm3SxtV37K7YaotZZpDpG6w3Ryc1Lzug@mail.gmail.com>
References: <CAJwKKmZ__GVT6aVRA+gNJ=gYnwNAmkG18BLmju2A05Vrkr+QrQ@mail.gmail.com>
	<56D713BB.5030305@oracle.com>
	<CAJwKKmaTc2Oe9E3y57y5iG1keqA9jU_NJCy1yQEe0GTG3QXokg@mail.gmail.com>
	<CAJwKKmb9USyRxSmEw_U2ur6cAAkmPJDBmhQN=4EV0u9wkqw5hA@mail.gmail.com>
	<CAJwKKmYDYGcgdtZLTaimE=8Y_PDdB22dB1C+58CfXDnA-t6n+w@mail.gmail.com>
	<5704EA02.1090500@oracle.com>
	<CAJwKKmaxvNMTfSrz1Tk0ChMC8ZcRWkRXbo9ZU1dKbwerKb_ymw@mail.gmail.com>
	<5704FAD9.50805@oracle.com>
	<CAGUMyaSERCsb2KrumOGxLALHqgWM=uT=FrrKSBxPFM-3WAR3VA@mail.gmail.com>
	<a33b671c-f478-f430-431e-8fc5e589c5d9@oracle.com>
	<CAGUMyaROjZ33O2yRtvdRWf9UBG7r7823A9me6rh-5zEmt7bGWQ@mail.gmail.com>
	<5594e799-8935-f079-2fe3-60b5079eab4a@oracle.com>
	<131c0e73-8fc9-2db2-b4bf-b110d4fcdbeb@oracle.com>
	<b7d3a594-9fca-ad39-71c8-eed46acbc138@oracle.com>
	<CAJwKKmb7CpgcOQdLviOm3SxtV37K7YaotZZpDpG6w3Ryc1Lzug@mail.gmail.com>
Message-ID: <d9e526c0-b7ad-45af-df67-23407490b96c@oracle.com>



On 6/1/2016 2:39 PM, Mario Torre wrote:
> On Wed, Jun 1, 2016 at 1:23 PM, Semyon Sadetsky
> <semyon.sadetsky at oracle.com> wrote:
>> I ran JPRT build. It seems that the build server does not have the requested
>> header:
>>
>> /opt/jprt/T/P1/102200.ssadetsk/s/jdk/src/java.desktop/unix/native/libawt_xawt/awt/awt_Robot.c:40:39:
>> fatal error: X11/extensions/Xcomposite.h: No such file or directory
>>   #include <X11/extensions/Xcomposite.h>
>>
>> someone need to install Xcomposite library there
>>
> Should this be made optional?
>
> I can do some dlsym hack if necessary (I would prefer to avoid that though).
Apparently dlsym is the shortest way to fix that issue and you don't 
need to modify the makefile in that case.

--Semyon
> Cheers,
> Mario


From manajit.halder at oracle.com  Wed Jun  1 13:46:36 2016
From: manajit.halder at oracle.com (Manajit Halder)
Date: Wed, 1 Jun 2016 19:16:36 +0530
Subject: <AWT Dev> <AWT dev>[9] Review request for JDK-8155740: [macosx]
	robot.keyPress and robot.keyRelease do not generate key event
	for Alt-Graph key VK_ALT_GRAPH.
In-Reply-To: <082a4f05-f5f2-01d0-5951-dc36b3dafbe5@oracle.com>
References: <538F0C0F-2C53-49CD-96B5-F78A794E3177@oracle.com>
	<5734A835.80908@oracle.com>
	<75CD4BD9-983C-4315-A5FC-3518C37BECF7@oracle.com>
	<573E06C5.5040807@oracle.com>
	<4CFAD53C-0E2F-43B4-854C-BFF1CEB944A5@oracle.com>
	<082a4f05-f5f2-01d0-5951-dc36b3dafbe5@oracle.com>
Message-ID: <F3869358-BE09-42E0-8F39-ED1E40210B18@oracle.com>

Hi  Semyon and Sergey,

After running the tests shared by Sergey I found that the second webrev (webrev.01) shared by me solves the problem.

http://cr.openjdk.java.net/~mhalder/8155740/webrev.01/ <http://cr.openjdk.java.net/~mhalder/8155740/webrev.01/>

Following tests were present in https://java.net/jira/browse/MACOSX_PORT-621 <https://java.net/jira/browse/MACOSX_PORT-621>:
closed/java/awt/KeyboardFocusmanager/ConsumeNextMnemonicKeyTypedTest/ConsumeNextMnemonicKeyTypedTest
java/awt/Dialog/NestedDialogs/Modal/NestedModalDialogTest.java
java/awt/Dialog/NestedDialogs/Modeless/NestedModelessDialogTest.java

But only first test (which is now present as part of open code) could be performed and the remaining tests were not found in the present code.
The first test fails due to another issue (JDK-8156460), whose fix is in progress and will be send for after this issue. This fix (JDK-8155740) is not related to the failure of the first test case.

The new location of the first test:
java/awt/KeyboardFocusmanager/ConsumeNextMnemonicKeyTypedTest/ConsumeNextMnemonicKeyTypedTest

 Please review the webrev.01.

Thanks,
Manajit

> On 26-May-2016, at 1:05 pm, Semyon Sadetsky <semyon.sadetsky at oracle.com> wrote:
> 
> On 5/24/2016 2:09 PM, Manajit Halder wrote:
>> Hi Semyon,
>> 
>> It is not clear in the comment what was the problem, but it looks like the problem was observed just by using CGEventCreateKeyboardEvent/CGEventPost. In my case I don?t see any issues just by using the fix. It posts all the key events and all the key events are tested in the test file modified along with the fix.
> If you found the comment is not actual anymore, why did you preserve it?
> 
> --Semyon
>> 
>> Apart from the unknown problem mentioned in the existing comment this fix has following advantages:
>> Key codes for modifier key are required to distinguish between Alt and Alt-Gr key, which is not possible by using existing solution as it doesn?t post key codes for modifier keys. And also keys can?t be distinguished base on modifier value, which is same for both keys (Alt and Alt-Gr).
>> As mentioned in the existing comment CGEventCreateKeyboardEvent/CGEventPost is a better solution.
>> Online search about keyboard simulation showed that CGEventCreateKeyboardEvent/CGEventPost is used to simulate key stores in most of the cases.
>> Tested the key codes, didn?t observe any problem.
>> 
>> Regarding number keys not working with CGEventCreateKeyboardEvent/CGEventPost:
>> 	Solved the problem by providing event source to CGEventCreateKeyboardEvent. Code is modified. 
>> 
>> Please review the modified code:
>>  <http://cr.openjdk.java.net/%7Emhalder/8155740/webrev.02/>http://cr.openjdk.java.net/~mhalder/8155740/webrev.02/ <http://cr.openjdk.java.net/~mhalder/8155740/webrev.02/>
>> 
>> Thanks,
>> Manajit
>> 
>>> On 20-May-2016, at 12:02 am, Semyon Sadetsky <semyon.sadetsky at oracle.com <mailto:semyon.sadetsky at oracle.com>> wrote:
>>> 
>>> Hi Manajit,
>>> 
>>> Before your fix all key codes wa sent using
>>> 
>>> AXUIElementCreateSystemWide();
>>> 
>>> and CGEventCreateKeyboardEvent was commented or excluded from compilation:
>>> 
>>> 274 #if 0
>>>  275     CGEventRef event = CGEventCreateKeyboardEvent(NULL, keyCode, keyPressed);
>>>  276     if (event != NULL) {
>>>  277         CGEventPost(kCGSessionEventTap, event);
>>>  278         CFRelease(event);
>>>  279     }
>>>  280 #endif
>>> 
>>> I just wonder why it was done. Maybe that was some other issue fix. The comment above states:
>>> 
>>>  262      * Well, using CGEventCreateKeyboardEvent/CGEventPost would have been
>>>  263      * a better solution, however, it gives me all kinds of trouble and I have
>>>  264      * no idea how to solve them without inserting delays between simulated
>>>  265      * events. So, I've ended up disabling it and opted for another approach
>>>  266      * that uses Accessibility API instead.
>>> 
>>> I don't understand what trouble is mentioned in the comment above. But in your fix you've put the CGEventCreateKeyboardEvent back, may it return this trouble back?
>>> 
>>> Also as I understand Numpad number keys did not work as well. Could you add the corresponding test case since you provide a fix this extra issue?
>>> 
>>> --Semyon
>>> 
>>> 
>>> On 5/13/2016 11:50 PM, Manajit Halder wrote:
>>>> Hi Semyon,
>>>> 
>>>> The fix is changed a bit because it was observed that the modifier keys plus alphabet keys were not working together. In the modified fix only Num keys are posted by AXUIElementPostKeyboardEvent and remaining keys are posted by CGPostKeyboardEvent/CGEventPost. The fix is explained in the comment in file CRobot.m.
>>>> 
>>>> Please review the new changes:
>>>>  <http://cr.openjdk.java.net/%7Emhalder/8155740/webrev.01/>http://cr.openjdk.java.net/~mhalder/8155740/webrev.01/ <http://cr.openjdk.java.net/~mhalder/8155740/webrev.01/>
>>>> 
>>>> 
>>>> Answers to your questions:
>>>> 
>>>> What is difference between AXUIElementPostKeyboardEvent and CGEventCreateKeyboardEvent?
>>>> 
>>>> Difference as per the documentation:
>>>> 	AXUIElementPostKeyboardEvent is similar to CGPostKeyboardEvent (which synthesizes a low-level keyboard event on the local machine), but it allows you to specify the target application as opposed to always sending the events to the active application. If the system-wide accessibility object is passed in the application parameter, the event is sent to the active application. 
>>>> 
>>>> Difference behaviour as per the implementation observed while debugging the code:
>>>> 	
>>>> AXUIElementPostKeyboardEvent:
>>>> 	AXUIElementPostKeyboardEvent posts 0 key code for all the modifier keys with key codes 16, 17,18, 20, 157 and also for newly added modifier key VK_ALT_GRAPH. But it posts correct key code for all the remaining keys.
>>>> 	While debugging it was that for modifier keys keyDown and keyUp events are not generated, but flagsChanged event (flagsChanged: (NSEvent *)event) is generated. But for all other keys keyDown followed by keyUp events are generated.
>>>> 
>>>> CGEventCreateKeyboardEvent:
>>>> 	CGEventCreateKeyboardEvent posts correct key code for all the keys except for numeric keys (numbers 0 to 9 on normal keyboard). CGEventCreateKeyboardEvent posts wrong key codes for the number keys 0 to 9. Instead of posting number key codes it posts Numpad key codes for the corresponding number key. For example Numpad0 key code is posted for number 0, Numpad1 key code is posted for number 1 and simillarly for remaining num keys.
>>>> 	
>>>> Why the latter was commented? Does it mean that valid modifier keys have not been sent by AWT robot?
>>>> 
>>>> I didn?t get your question clearly. If you meant why in the current implementation the later part (fix using CGPostKeyboardEvent) of fix was commented.
>>>> 	I am not very sure about it. As per the comment it is only clear that CGPostKeyboardEvent/CGEventPost would have been a better solution and I agree with that, perhaps reason could be related to the difference in behaviour observed while debugging the code as mentioned above.
>>>> 
>>>> Thanks,
>>>> Manajit
>>>> 
>>>>> Hi Manajit,
>>>>> 
>>>>> Just a few questions to clarify on the fix.
>>>>> What is difference between AXUIElementPostKeyboardEvent and CGEventCreateKeyboardEvent?
>>>> 	
>>>>> Why the latter was commented? Does it mean that valid modifier keys have not been sent by AWT robot?
>>>>> 
>>>>> --Semyon
>>>>> 
>>>>> 
>>>>> On 5/12/2016 10:45 AM, Manajit Halder wrote:
>>>>>> Hi All,
>>>>>> 
>>>>>> Kindly review the fix for JDK9.
>>>>>> 
>>>>>> Bug: 
>>>>>> https://bugs.openjdk.java.net/browse/JDK-8155740 <https://bugs.openjdk.java.net/browse/JDK-8155740>
>>>>>> 
>>>>>> Webrev: 
>>>>>> http://cr.openjdk.java.net/~mhalder/8155740/webrev.00/ <http://cr.openjdk.java.net/%7Emhalder/8155740/webrev.00/>
>>>>>> 
>>>>>> Issue: 
>>>>>> [macosx] robot.keyPress and robot.keyRelease do not generate key event for Alt-Graph key VK_ALT_GRAPH.
>>>>>> 
>>>>>> Cause: 
>>>>>> VK_ALT_GRAPH is a new key added to the Mac OS X platform and it is not mapped to any key on the OS X platform.
>>>>>> 
>>>>>> Fix: 
>>>>>> VK_ALT_GRAPH is mapped to right option (OSX_RightOption) key on Mac OS X.
>>>>>> 
>>>>>> Method Java_sun_lwawt_macosx_CRobot_keyEvent is modified for the following reason:
>>>>>> AXUIElementPostKeyboardEvent posts 0 key code for all  the modifier keys with key codes (16, 17,18, 20, 157) and also for newly added modifier key VK_ALT_GRAPH.
>>>>>> But it posts correct key code for all the other keys. On the other hand CGEventCreateKeyboardEvent posts correct key code for all the modifier keys and 
>>>>>> hence it is used to post modifier key events and AXUIElementPostKeyboardEvent is used to post all the remaining key events.
>>>>>> 
>>>>>> Regards,
>>>>>> Manajit
>>>>> 
>>>> 
>>> 
>> 
> 

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

From semyon.sadetsky at oracle.com  Wed Jun  1 17:54:27 2016
From: semyon.sadetsky at oracle.com (Semyon Sadetsky)
Date: Wed, 1 Jun 2016 20:54:27 +0300
Subject: <AWT Dev> <AWT dev>[9] Review request for JDK-8155740: [macosx]
 robot.keyPress and robot.keyRelease do not generate key event for Alt-Graph
 key VK_ALT_GRAPH.
In-Reply-To: <F3869358-BE09-42E0-8F39-ED1E40210B18@oracle.com>
References: <538F0C0F-2C53-49CD-96B5-F78A794E3177@oracle.com>
	<5734A835.80908@oracle.com>
	<75CD4BD9-983C-4315-A5FC-3518C37BECF7@oracle.com>
	<573E06C5.5040807@oracle.com>
	<4CFAD53C-0E2F-43B4-854C-BFF1CEB944A5@oracle.com>
	<082a4f05-f5f2-01d0-5951-dc36b3dafbe5@oracle.com>
	<F3869358-BE09-42E0-8F39-ED1E40210B18@oracle.com>
Message-ID: <8655c6e1-0cfb-01b1-9081-f656970eeafc@oracle.com>

Hi Manaji,

Okay, back to werev.01.

Could you remove the comment in lines 262-268 since you assume that it 
is not true anymore and so CGEventCreateKeyboardEvent/CGEventPost will 
not cause any troubles.

Did you analyze why werev.02 fix did not pass those tests?

--Semyon


On 6/1/2016 4:46 PM, Manajit Halder wrote:
> Hi  Semyon and Sergey,
>
> After running the tests shared by Sergey I found that the second 
> webrev (webrev.01) shared by me solves the problem.
>
> http://cr.openjdk.java.net/~mhalder/8155740/webrev.01/ 
> <http://cr.openjdk.java.net/%7Emhalder/8155740/webrev.01/>
>
> Following tests were present in 
> https://java.net/jira/browse/MACOSX_PORT-621:
> closed/java/awt/KeyboardFocusmanager/ConsumeNextMnemonicKeyTypedTest/ConsumeNextMnemonicKeyTypedTest
> java/awt/Dialog/NestedDialogs/Modal/NestedModalDialogTest.java
> java/awt/Dialog/NestedDialogs/Modeless/NestedModelessDialogTest.java
>
> But only first test (which is now present as part of open code) could 
> be performed and the remaining tests were not found in the present code.
> The first test fails due to another issue (JDK-8156460), whose fix is 
> in progress and will be send for after this issue. This fix 
> (JDK-8155740) is not related to the failure of the first test case.
>
> The new location of the first test:
> java/awt/KeyboardFocusmanager/ConsumeNextMnemonicKeyTypedTest/ConsumeNextMnemonicKeyTypedTest
>
>  Please review the webrev.01.
>
> Thanks,
> Manajit
>
>> On 26-May-2016, at 1:05 pm, Semyon Sadetsky 
>> <semyon.sadetsky at oracle.com <mailto:semyon.sadetsky at oracle.com>> wrote:
>>
>> On 5/24/2016 2:09 PM, Manajit Halder wrote:
>>
>>> Hi Semyon,
>>>
>>> It is not clear in the comment what was the problem, but it looks 
>>> like the problem was observed just by 
>>> using CGEventCreateKeyboardEvent/CGEventPost. In my case I don?t see 
>>> any issues just by using the fix. It posts all the key events and 
>>> all the key events are tested in the test file modified along with 
>>> the fix.
>> If you found the comment is not actual anymore, why did you preserve it?
>>
>> --Semyon
>>>
>>> Apart from the unknown problem mentioned in the existing comment 
>>> this fix has following advantages:
>>>
>>>   * Key codes for modifier key are required to distinguish between
>>>     Alt and Alt-Gr key, which is not possible by using existing
>>>     solution as it doesn?t post key codes for modifier keys. And
>>>     also keys can?t be distinguished base on modifier value, which
>>>     is same for both keys (Alt and Alt-Gr).
>>>   * As mentioned in the existing
>>>     comment CGEventCreateKeyboardEvent/CGEventPost is a better solution.
>>>   * Online search about keyboard simulation showed
>>>     that CGEventCreateKeyboardEvent/CGEventPost is used to simulate
>>>     key stores in most of the cases.
>>>   * Tested the key codes, didn?t observe any problem.
>>>
>>>
>>> Regarding number keys not working 
>>> with CGEventCreateKeyboardEvent/CGEventPost:
>>> Solved the problem by providing event source 
>>> to CGEventCreateKeyboardEvent. Code is modified.
>>>
>>> Please review the modified code:
>>> http://cr.openjdk.java.net/~mhalder/8155740/webrev.02/
>>>
>>> Thanks,
>>> Manajit
>>>
>>>> On 20-May-2016, at 12:02 am, Semyon Sadetsky 
>>>> <semyon.sadetsky at oracle.com <mailto:semyon.sadetsky at oracle.com>> wrote:
>>>>
>>>> Hi Manajit,
>>>>
>>>> Before your fix all key codes wa sent using
>>>>
>>>> AXUIElementCreateSystemWide();
>>>>
>>>> and CGEventCreateKeyboardEvent was commented or excluded from 
>>>> compilation:
>>>>
>>>> 274 #if 0
>>>>  275     CGEventRef event = CGEventCreateKeyboardEvent(NULL, 
>>>> keyCode, keyPressed);
>>>>  276     if (event != NULL) {
>>>>  277 CGEventPost(kCGSessionEventTap, event);
>>>>  278         CFRelease(event);
>>>>  279     }
>>>>  280 #endif
>>>>
>>>> I just wonder why it was done. Maybe that was some other issue fix. 
>>>> The comment above states:
>>>>
>>>>  262      * Well, using CGEventCreateKeyboardEvent/CGEventPost 
>>>> would have been
>>>>  263      * a better solution, however, it gives me all kinds of 
>>>> trouble and I have
>>>>  264      * no idea how to solve them without inserting delays 
>>>> between simulated
>>>>  265      * events. So, I've ended up disabling it and opted for 
>>>> another approach
>>>>  266      * that uses Accessibility API instead.
>>>>
>>>> I don't understand what trouble is mentioned in the comment above. 
>>>> But in your fix you've put the CGEventCreateKeyboardEvent back, may 
>>>> it return this trouble back?
>>>>
>>>> Also as I understand Numpad number keys did not work as well. Could 
>>>> you add the corresponding test case since you provide a fix this 
>>>> extra issue?
>>>>
>>>> --Semyon
>>>>
>>>>
>>>> On 5/13/2016 11:50 PM, Manajit Halder wrote:
>>>>> Hi Semyon,
>>>>>
>>>>> The fix is changed a bit because it was observed that the modifier 
>>>>> keys plus alphabet keys were not working together. In the modified 
>>>>> fix only Num keys are posted by AXUIElementPostKeyboardEvent and 
>>>>> remaining keys are posted by CGPostKeyboardEvent/CGEventPost. The 
>>>>> fix is explained in the comment in file CRobot.m.
>>>>>
>>>>> Please review the new changes:
>>>>> _http://cr.openjdk.java.net/~mhalder/8155740/webrev.01/_
>>>>> _
>>>>> _
>>>>>
>>>>> Answers to your questions:
>>>>>
>>>>> What is difference between AXUIElementPostKeyboardEvent and 
>>>>> CGEventCreateKeyboardEvent?
>>>>>
>>>>> Difference as per the documentation:
>>>>> AXUIElementPostKeyboardEvent is similar to CGPostKeyboardEvent 
>>>>> (which synthesizes a low-level keyboard event on the local 
>>>>> machine), but it allows you to specify the target application as 
>>>>> opposed to always sending the events to the active application. If 
>>>>> the system-wide accessibility object is passed in the application 
>>>>> parameter, the event is sent to the active application.
>>>>>
>>>>> Difference behaviour as per the implementation observed while 
>>>>> debugging the code:
>>>>> AXUIElementPostKeyboardEvent:
>>>>> AXUIElementPostKeyboardEvent posts 0 key code for all the modifier 
>>>>> keys with key codes 16, 17,18, 20, 157 and also for newly added 
>>>>> modifier key VK_ALT_GRAPH. But it posts correct key code for all 
>>>>> the remaining keys.
>>>>> While debugging it was that for modifier keys keyDown and keyUp 
>>>>> events are not generated, but flagsChanged event (flagsChanged: 
>>>>> (NSEvent *)event) is generated. But for all other keys keyDown 
>>>>> followed by keyUp events are generated.
>>>>>
>>>>> CGEventCreateKeyboardEvent:
>>>>> CGEventCreateKeyboardEvent posts correct key code for all the keys 
>>>>> except for numeric keys (numbers 0 to 9 on normal 
>>>>> keyboard). CGEventCreateKeyboardEvent posts wrong key codes for 
>>>>> the number keys 0 to 9. Instead of posting number key codes it 
>>>>> posts Numpad key codes for the corresponding number key. For 
>>>>> example Numpad0 key code is posted for number 0, Numpad1 key code 
>>>>> is posted for number 1 and simillarly for remaining num keys.
>>>>> Why the latter was commented? Does it mean that valid modifier 
>>>>> keys have not been sent by AWT robot?
>>>>>
>>>>> I didn?t get your question clearly. If you meant why in the 
>>>>> current implementation the later part (fix using 
>>>>> CGPostKeyboardEvent) of fix was commented.
>>>>> I am not very sure about it. As per the comment it is only clear 
>>>>> that CGPostKeyboardEvent/CGEventPost would have been a better 
>>>>> solution and I agree with that, perhaps reason could be related to 
>>>>> the difference in behaviour observed while debugging the code as 
>>>>> mentioned above.
>>>>>
>>>>> Thanks,
>>>>> Manajit
>>>>>
>>>>>> Hi Manajit,
>>>>>>
>>>>>> Just a few questions to clarify on the fix.
>>>>>> What is difference between AXUIElementPostKeyboardEvent and 
>>>>>> CGEventCreateKeyboardEvent?
>>>>>
>>>>>> Why the latter was commented? Does it mean that valid modifier 
>>>>>> keys have not been sent by AWT robot?
>>>>>>
>>>>>> --Semyon
>>>>>>
>>>>>>
>>>>>> On 5/12/2016 10:45 AM, Manajit Halder wrote:
>>>>>>> Hi All,
>>>>>>>
>>>>>>> Kindly review the fix for JDK9.
>>>>>>>
>>>>>>> *Bug*:
>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8155740
>>>>>>> _
>>>>>>> _
>>>>>>> *Webrev*:
>>>>>>> http://cr.openjdk.java.net/~mhalder/8155740/webrev.00/ 
>>>>>>> <http://cr.openjdk.java.net/%7Emhalder/8155740/webrev.00/>
>>>>>>>
>>>>>>> *Issue: *
>>>>>>> [macosx] robot.keyPress and robot.keyRelease do not generate key 
>>>>>>> event for Alt-Graph key VK_ALT_GRAPH.
>>>>>>>
>>>>>>> *Cause: *
>>>>>>> VK_ALT_GRAPH is a new key added to the Mac OS X platform and it 
>>>>>>> is not mapped to any key on the OS X platform.
>>>>>>>
>>>>>>> *Fix: *
>>>>>>> VK_ALT_GRAPH is mapped to right option (OSX_RightOption) key on 
>>>>>>> Mac OS X.
>>>>>>>
>>>>>>> Method Java_sun_lwawt_macosx_CRobot_keyEvent is modified for the 
>>>>>>> following reason:
>>>>>>> AXUIElementPostKeyboardEvent posts 0 key code for all  the 
>>>>>>> modifier keys with key codes (16, 17,18, 20, 157) and also for 
>>>>>>> newly added modifier key VK_ALT_GRAPH.
>>>>>>> But it posts correct key code for all the other keys. On the 
>>>>>>> other hand CGEventCreateKeyboardEvent posts correct key code for 
>>>>>>> all the modifier keys and
>>>>>>> hence it is used to post modifier key events and 
>>>>>>> AXUIElementPostKeyboardEvent is used to post all the remaining 
>>>>>>> key events.
>>>>>>>
>>>>>>> Regards,
>>>>>>> Manajit
>>>>>>
>>>>>
>>>>
>>>
>>
>

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

From philip.race at oracle.com  Wed Jun  1 18:37:45 2016
From: philip.race at oracle.com (Phil Race)
Date: Wed, 01 Jun 2016 11:37:45 -0700
Subject: <AWT Dev> <AWT dev>[9] Review request for 8156121: "Fail
 forward" fails for GTK3 if no GTK2 available
In-Reply-To: <c66106c1-4cc0-bb1a-0bda-d1789bbbc724@oracle.com>
References: <872c02c6-6dab-74a1-5d34-458e21503a2c@oracle.com>
	<57487632.9010406@oracle.com>
	<c66106c1-4cc0-bb1a-0bda-d1789bbbc724@oracle.com>
Message-ID: <574F2B79.6040308@oracle.com>

+1

-phil.

On 05/30/2016 02:00 AM, Semyon Sadetsky wrote:
> Please review the updated webrev:
>
> http://cr.openjdk.java.net/~ssadetsky/8156121/webrev.01/
>
> --Semyon
>
>
> On 5/27/2016 7:30 PM, Phil Race wrote:
>>  67 n_libs = sizeof(gtk_libs) / sizeof(GtkLib);
>>   68         load_order = malloc(1 + n_libs * sizeof(GtkLib *));
>>   69         load_order[n_libs] = 0;
>>
>> I think you meant
>>
>>  malloc((1 + n_libs) * sizeof(GtkLib *));
>>
>> since otherwise you are only allocating one byte for the pointer
>> and will have a buffer overrun.
>>
>> But it would be better to use calloc :-
>>
>>
>> calloc(n_libs+1,sizeof(GtkLib *));
>>
>> and then you can dispense with line 69 since calloc zero initialises 
>> memory.
>>
>> -phil.
>>
>>
>> On 05/26/2016 05:33 AM, Semyon Sadetsky wrote:
>>> Hello,
>>>
>>> Please review fix for JDK9:
>>>
>>> bug: https://bugs.openjdk.java.net/browse/JDK-8156121
>>>
>>> webrev: http://cr.openjdk.java.net/~ssadetsky/8156121/webrev.00/
>>>
>>> The issue is caused by changes in -Djdk.gtk.version=<gtk version> 
>>> specification. Initially it should be working as a constraint:  only 
>>> allow the specified version of GTK lib (don't use GTK if this 
>>> version is not available). Then after discussions the specification 
>>> was amended to use this property as a advise: the GTK version to 
>>> start loading with (if it fails the next available GTK version will 
>>> be attempted). So that, the code need be harmonized with the 
>>> specification.
>>>
>>> --Semyon
>>>
>>
>


From iris.clark at oracle.com  Thu Jun  2 01:17:10 2016
From: iris.clark at oracle.com (Iris Clark)
Date: Wed, 1 Jun 2016 18:17:10 -0700 (PDT)
Subject: <AWT Dev> RFR: 8158458: Update references from "1.9" to "9"
Message-ID: <debc6713-f24e-4483-94fa-707853742266@default>

Hi.

I'm taking another pass at replacing instances of "@since 1.9" with
"@since 9" and discovered a couple of jdk (AWT?) and langtools (DocTree)
files which need to be updated.  I've filed the following but to 
address this problem:

    8158458: Update references from "1.9" to "9" (closed code))
    https://bugs.openjdk.java.net/browse/JDK-8158458

This is the necessary diff, against jdk9/dev:

[/w/iclark/verona/javadoc/jdk]: 
diff -r 0bd06ec69c5b src/java.desktop/macosx/classes/com/apple/eawt/Application.java 
--- a/src/java.desktop/macosx/classes/com/apple/eawt/Application.java Wed Jun 01 11:22:06 2016 -0700 
+++ b/src/java.desktop/macosx/classes/com/apple/eawt/Application.java Wed Jun 01 17:40:09 2016 -0700 
@@ -372,7 +372,7 @@ 
  * Acceptable values are from 0 to 100, any other disables progress indication. 
  * 
  * @param value progress value 
- * @since 1.9 
+ * @since 9 
      */ 
     public void setDockIconProgress(final int value) { 
         iconHandler.setDockIconProgress(value); 

[/w/iclark/verona/javadoc/langtools]: 
diff -r 2d1a6b746310 src/jdk.compiler/share/classes/com/sun/source/doctree/HiddenTree.java 
--- a/src/jdk.compiler/share/classes/com/sun/source/doctree/HiddenTree.java Wed Jun 01 12:39:24 2016 +0100 
+++ b/src/jdk.compiler/share/classes/com/sun/source/doctree/HiddenTree.java Wed Jun 01 17:40:09 2016 -0700 
@@ -34,7 +34,7 @@ 
  * <p> 
  * &#064;hidden 
  * 
- * @since 1.9 
+ * @since 9 
  */ 
 public interface HiddenTree extends BlockTagTree { 
     /**

Build and test runs show no regressions.

Thanks,
Iris

From philip.race at oracle.com  Thu Jun  2 03:29:31 2016
From: philip.race at oracle.com (Philip Race)
Date: Wed, 01 Jun 2016 20:29:31 -0700
Subject: <AWT Dev> RFR: 8158458: Update references from "1.9" to "9"
In-Reply-To: <debc6713-f24e-4483-94fa-707853742266@default>
References: <debc6713-f24e-4483-94fa-707853742266@default>
Message-ID: <574FA81B.1040706@oracle.com>

I don't see why @since matters on internal classes ...

-phil.

On 6/1/16, 6:17 PM, Iris Clark wrote:
> Hi.
>
> I'm taking another pass at replacing instances of "@since 1.9" with
> "@since 9" and discovered a couple of jdk (AWT?) and langtools (DocTree)
> files which need to be updated.  I've filed the following but to
> address this problem:
>
>      8158458: Update references from "1.9" to "9" (closed code))
>      https://bugs.openjdk.java.net/browse/JDK-8158458
>
> This is the necessary diff, against jdk9/dev:
>
> [/w/iclark/verona/javadoc/jdk]:
> diff -r 0bd06ec69c5b src/java.desktop/macosx/classes/com/apple/eawt/Application.java
> --- a/src/java.desktop/macosx/classes/com/apple/eawt/Application.java Wed Jun 01 11:22:06 2016 -0700
> +++ b/src/java.desktop/macosx/classes/com/apple/eawt/Application.java Wed Jun 01 17:40:09 2016 -0700
> @@ -372,7 +372,7 @@
>    * Acceptable values are from 0 to 100, any other disables progress indication.
>    *
>    * @param value progress value
> - * @since 1.9
> + * @since 9
>        */
>       public void setDockIconProgress(final int value) {
>           iconHandler.setDockIconProgress(value);
>
> [/w/iclark/verona/javadoc/langtools]:
> diff -r 2d1a6b746310 src/jdk.compiler/share/classes/com/sun/source/doctree/HiddenTree.java
> --- a/src/jdk.compiler/share/classes/com/sun/source/doctree/HiddenTree.java Wed Jun 01 12:39:24 2016 +0100
> +++ b/src/jdk.compiler/share/classes/com/sun/source/doctree/HiddenTree.java Wed Jun 01 17:40:09 2016 -0700
> @@ -34,7 +34,7 @@
>    *<p>
>    *&#064;hidden
>    *
> - * @since 1.9
> + * @since 9
>    */
>   public interface HiddenTree extends BlockTagTree {
>       /**
>
> Build and test runs show no regressions.
>
> Thanks,
> Iris

From philip.race at oracle.com  Thu Jun  2 03:42:00 2016
From: philip.race at oracle.com (Philip Race)
Date: Wed, 01 Jun 2016 20:42:00 -0700
Subject: <AWT Dev> RFR: 8158458: Update references from "1.9" to "9"
In-Reply-To: <574FA81B.1040706@oracle.com>
References: <debc6713-f24e-4483-94fa-707853742266@default>
	<574FA81B.1040706@oracle.com>
Message-ID: <574FAB08.9000205@oracle.com>

By which I mean "delete" is as good as "update'

-phil

On 6/1/16, 8:29 PM, Philip Race wrote:
> I don't see why @since matters on internal classes ...
>
> -phil.
>
> On 6/1/16, 6:17 PM, Iris Clark wrote:
>> Hi.
>>
>> I'm taking another pass at replacing instances of "@since 1.9" with
>> "@since 9" and discovered a couple of jdk (AWT?) and langtools (DocTree)
>> files which need to be updated.  I've filed the following but to
>> address this problem:
>>
>>      8158458: Update references from "1.9" to "9" (closed code))
>>      https://bugs.openjdk.java.net/browse/JDK-8158458
>>
>> This is the necessary diff, against jdk9/dev:
>>
>> [/w/iclark/verona/javadoc/jdk]:
>> diff -r 0bd06ec69c5b 
>> src/java.desktop/macosx/classes/com/apple/eawt/Application.java
>> --- a/src/java.desktop/macosx/classes/com/apple/eawt/Application.java 
>> Wed Jun 01 11:22:06 2016 -0700
>> +++ b/src/java.desktop/macosx/classes/com/apple/eawt/Application.java 
>> Wed Jun 01 17:40:09 2016 -0700
>> @@ -372,7 +372,7 @@
>>    * Acceptable values are from 0 to 100, any other disables progress 
>> indication.
>>    *
>>    * @param value progress value
>> - * @since 1.9
>> + * @since 9
>>        */
>>       public void setDockIconProgress(final int value) {
>>           iconHandler.setDockIconProgress(value);
>>
>> [/w/iclark/verona/javadoc/langtools]:
>> diff -r 2d1a6b746310 
>> src/jdk.compiler/share/classes/com/sun/source/doctree/HiddenTree.java
>> --- 
>> a/src/jdk.compiler/share/classes/com/sun/source/doctree/HiddenTree.java 
>> Wed Jun 01 12:39:24 2016 +0100
>> +++ 
>> b/src/jdk.compiler/share/classes/com/sun/source/doctree/HiddenTree.java 
>> Wed Jun 01 17:40:09 2016 -0700
>> @@ -34,7 +34,7 @@
>>    *<p>
>>    *&#064;hidden
>>    *
>> - * @since 1.9
>> + * @since 9
>>    */
>>   public interface HiddenTree extends BlockTagTree {
>>       /**
>>
>> Build and test runs show no regressions.
>>
>> Thanks,
>> Iris

From dmitry.markov at oracle.com  Thu Jun  2 08:18:34 2016
From: dmitry.markov at oracle.com (dmitry markov)
Date: Thu, 02 Jun 2016 11:18:34 +0300
Subject: <AWT Dev> [9] Review request for 8025130: [macosx] Frame
 setLocationByPlatform has no effect under Mac OS X
Message-ID: <574FEBDA.6060605@oracle.com>

Hello,

Could you review a fix for jdk9, please?

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

Problem description:
Invocation of setLocationByPlatform() has no effect under Mac OS X, 
(i.e. the feature is not fully implemented for this platform).

Fix:
Introduce new method nativeSetNSWindowLocationByPlatform(). It moves a 
window to 'default location' calculated by platform using 
cascadeTopLeftFromPoint function from NSWindow.
Add check of locationByPlatform flag to CPlatformWindow.setVisible(). If 
the flag is set, a window will be moved to 'default location'.

Thanks,
Dmitry

From Sergey.Bylokhov at oracle.com  Thu Jun  2 09:24:18 2016
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Thu, 2 Jun 2016 12:24:18 +0300
Subject: <AWT Dev> <AWT dev>[9] Review request for JDK-8155740: [macosx]
 robot.keyPress and robot.keyRelease do not generate key event for Alt-Graph
 key VK_ALT_GRAPH.
In-Reply-To: <F3869358-BE09-42E0-8F39-ED1E40210B18@oracle.com>
References: <538F0C0F-2C53-49CD-96B5-F78A794E3177@oracle.com>
	<5734A835.80908@oracle.com>
	<75CD4BD9-983C-4315-A5FC-3518C37BECF7@oracle.com>
	<573E06C5.5040807@oracle.com>
	<4CFAD53C-0E2F-43B4-854C-BFF1CEB944A5@oracle.com>
	<082a4f05-f5f2-01d0-5951-dc36b3dafbe5@oracle.com>
	<F3869358-BE09-42E0-8F39-ED1E40210B18@oracle.com>
Message-ID: <2cef258d-368b-a8a5-dd82-c6708d63007b@oracle.com>

On 01.06.16 16:46, Manajit Halder wrote:
> Following tests were present
> in https://java.net/jira/browse/MACOSX_PORT-621:
> closed/java/awt/KeyboardFocusmanager/ConsumeNextMnemonicKeyTypedTest/ConsumeNextMnemonicKeyTypedTest
> java/awt/Dialog/NestedDialogs/Modal/NestedModalDialogTest.java
> java/awt/Dialog/NestedDialogs/Modeless/NestedModelessDialogTest.java
>
> But only first test (which is now present as part of open code) could be
> performed and the remaining tests were not found in the present code.
> The first test fails due to another issue (JDK-8156460), whose fix is in
> progress and will be send for after this issue. This fix (JDK-8155740)
> is not related to the failure of the first test case.

Other tests are located here:
http://hg.openjdk.java.net/macosx-port/macosx-port/jdk/file/048edd7100b7/test/java/awt/Dialog/NestedDialogs

Note that both tests needs an additional files from:
http://hg.openjdk.java.net/macosx-port/macosx-port/jdk/file/048edd7100b7/test/java/awt/regtesthelpers


>
> The new location of the first test:
> java/awt/KeyboardFocusmanager/ConsumeNextMnemonicKeyTypedTest/ConsumeNextMnemonicKeyTypedTest
>
>  Please review the webrev.01.
>
> Thanks,
> Manajit
>
>> On 26-May-2016, at 1:05 pm, Semyon Sadetsky
>> <semyon.sadetsky at oracle.com <mailto:semyon.sadetsky at oracle.com>> wrote:
>>
>> On 5/24/2016 2:09 PM, Manajit Halder wrote:
>>
>>> Hi Semyon,
>>>
>>> It is not clear in the comment what was the problem, but it looks
>>> like the problem was observed just by
>>> using CGEventCreateKeyboardEvent/CGEventPost. In my case I don?t see
>>> any issues just by using the fix. It posts all the key events and all
>>> the key events are tested in the test file modified along with the fix.
>> If you found the comment is not actual anymore, why did you preserve it?
>>
>> --Semyon
>>>
>>> Apart from the unknown problem mentioned in the existing comment this
>>> fix has following advantages:
>>>
>>>   * Key codes for modifier key are required to distinguish between
>>>     Alt and Alt-Gr key, which is not possible by using existing
>>>     solution as it doesn?t post key codes for modifier keys. And also
>>>     keys can?t be distinguished base on modifier value, which is same
>>>     for both keys (Alt and Alt-Gr).
>>>   * As mentioned in the existing
>>>     comment CGEventCreateKeyboardEvent/CGEventPost is a better solution.
>>>   * Online search about keyboard simulation showed
>>>     that CGEventCreateKeyboardEvent/CGEventPost is used to simulate
>>>     key stores in most of the cases.
>>>   * Tested the key codes, didn?t observe any problem.
>>>
>>>
>>> Regarding number keys not working
>>> with CGEventCreateKeyboardEvent/CGEventPost:
>>> Solved the problem by providing event source
>>> to CGEventCreateKeyboardEvent. Code is modified.
>>>
>>> Please review the modified code:
>>> <http://cr.openjdk.java.net/%7Emhalder/8155740/webrev.02/>http://cr.openjdk.java.net/~mhalder/8155740/webrev.02/
>>>
>>> Thanks,
>>> Manajit
>>>
>>>> On 20-May-2016, at 12:02 am, Semyon Sadetsky
>>>> <semyon.sadetsky at oracle.com <mailto:semyon.sadetsky at oracle.com>> wrote:
>>>>
>>>> Hi Manajit,
>>>>
>>>> Before your fix all key codes wa sent using
>>>>
>>>> AXUIElementCreateSystemWide();
>>>>
>>>> and CGEventCreateKeyboardEvent was commented or excluded from
>>>> compilation:
>>>>
>>>> 274 #if 0
>>>>  275     CGEventRef event = CGEventCreateKeyboardEvent(NULL,
>>>> keyCode, keyPressed);
>>>>  276     if (event != NULL) {
>>>>  277         CGEventPost(kCGSessionEventTap, event);
>>>>  278         CFRelease(event);
>>>>  279     }
>>>>  280 #endif
>>>>
>>>> I just wonder why it was done. Maybe that was some other issue fix.
>>>> The comment above states:
>>>>
>>>>  262      * Well, using CGEventCreateKeyboardEvent/CGEventPost would
>>>> have been
>>>>  263      * a better solution, however, it gives me all kinds of
>>>> trouble and I have
>>>>  264      * no idea how to solve them without inserting delays
>>>> between simulated
>>>>  265      * events. So, I've ended up disabling it and opted for
>>>> another approach
>>>>  266      * that uses Accessibility API instead.
>>>>
>>>> I don't understand what trouble is mentioned in the comment above.
>>>> But in your fix you've put the CGEventCreateKeyboardEvent back, may
>>>> it return this trouble back?
>>>>
>>>> Also as I understand Numpad number keys did not work as well. Could
>>>> you add the corresponding test case since you provide a fix this
>>>> extra issue?
>>>>
>>>> --Semyon
>>>>
>>>>
>>>> On 5/13/2016 11:50 PM, Manajit Halder wrote:
>>>>> Hi Semyon,
>>>>>
>>>>> The fix is changed a bit because it was observed that the modifier
>>>>> keys plus alphabet keys were not working together. In the modified
>>>>> fix only Num keys are posted by AXUIElementPostKeyboardEvent and
>>>>> remaining keys are posted by CGPostKeyboardEvent/CGEventPost. The
>>>>> fix is explained in the comment in file CRobot.m.
>>>>>
>>>>> Please review the new changes:
>>>>> _<http://cr.openjdk.java.net/%7Emhalder/8155740/webrev.01/>http://cr.openjdk.java.net/~mhalder/8155740/webrev.01/_
>>>>> _
>>>>> _
>>>>>
>>>>> Answers to your questions:
>>>>>
>>>>> What is difference between AXUIElementPostKeyboardEvent and
>>>>> CGEventCreateKeyboardEvent?
>>>>>
>>>>> Difference as per the documentation:
>>>>> AXUIElementPostKeyboardEvent is similar to CGPostKeyboardEvent
>>>>> (which synthesizes a low-level keyboard event on the local
>>>>> machine), but it allows you to specify the target application as
>>>>> opposed to always sending the events to the active application. If
>>>>> the system-wide accessibility object is passed in the application
>>>>> parameter, the event is sent to the active application.
>>>>>
>>>>> Difference behaviour as per the implementation observed while
>>>>> debugging the code:
>>>>> AXUIElementPostKeyboardEvent:
>>>>> AXUIElementPostKeyboardEvent posts 0 key code for all the modifier
>>>>> keys with key codes 16, 17,18, 20, 157 and also for newly added
>>>>> modifier key VK_ALT_GRAPH. But it posts correct key code for all
>>>>> the remaining keys.
>>>>> While debugging it was that for modifier keys keyDown and keyUp
>>>>> events are not generated, but flagsChanged event (flagsChanged:
>>>>> (NSEvent *)event) is generated. But for all other keys keyDown
>>>>> followed by keyUp events are generated.
>>>>>
>>>>> CGEventCreateKeyboardEvent:
>>>>> CGEventCreateKeyboardEvent posts correct key code for all the keys
>>>>> except for numeric keys (numbers 0 to 9 on normal
>>>>> keyboard). CGEventCreateKeyboardEvent posts wrong key codes for the
>>>>> number keys 0 to 9. Instead of posting number key codes it posts
>>>>> Numpad key codes for the corresponding number key. For example
>>>>> Numpad0 key code is posted for number 0, Numpad1 key code is posted
>>>>> for number 1 and simillarly for remaining num keys.
>>>>> Why the latter was commented? Does it mean that valid modifier keys
>>>>> have not been sent by AWT robot?
>>>>>
>>>>> I didn?t get your question clearly. If you meant why in the current
>>>>> implementation the later part (fix using CGPostKeyboardEvent) of
>>>>> fix was commented.
>>>>> I am not very sure about it. As per the comment it is only clear
>>>>> that CGPostKeyboardEvent/CGEventPost would have been a better
>>>>> solution and I agree with that, perhaps reason could be related to
>>>>> the difference in behaviour observed while debugging the code as
>>>>> mentioned above.
>>>>>
>>>>> Thanks,
>>>>> Manajit
>>>>>
>>>>>> Hi Manajit,
>>>>>>
>>>>>> Just a few questions to clarify on the fix.
>>>>>> What is difference between AXUIElementPostKeyboardEvent and
>>>>>> CGEventCreateKeyboardEvent?
>>>>>
>>>>>> Why the latter was commented? Does it mean that valid modifier
>>>>>> keys have not been sent by AWT robot?
>>>>>>
>>>>>> --Semyon
>>>>>>
>>>>>>
>>>>>> On 5/12/2016 10:45 AM, Manajit Halder wrote:
>>>>>>> Hi All,
>>>>>>>
>>>>>>> Kindly review the fix for JDK9.
>>>>>>>
>>>>>>> *Bug*:
>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8155740
>>>>>>> _
>>>>>>> _
>>>>>>> *Webrev*:
>>>>>>> http://cr.openjdk.java.net/~mhalder/8155740/webrev.00/
>>>>>>> <http://cr.openjdk.java.net/%7Emhalder/8155740/webrev.00/>
>>>>>>>
>>>>>>> *Issue: *
>>>>>>> [macosx] robot.keyPress and robot.keyRelease do not generate key
>>>>>>> event for Alt-Graph key VK_ALT_GRAPH.
>>>>>>>
>>>>>>> *Cause: *
>>>>>>> VK_ALT_GRAPH is a new key added to the Mac OS X platform and it
>>>>>>> is not mapped to any key on the OS X platform.
>>>>>>>
>>>>>>> *Fix: *
>>>>>>> VK_ALT_GRAPH is mapped to right option (OSX_RightOption) key on
>>>>>>> Mac OS X.
>>>>>>>
>>>>>>> Method Java_sun_lwawt_macosx_CRobot_keyEvent is modified for the
>>>>>>> following reason:
>>>>>>> AXUIElementPostKeyboardEvent posts 0 key code for all  the
>>>>>>> modifier keys with key codes (16, 17,18, 20, 157) and also for
>>>>>>> newly added modifier key VK_ALT_GRAPH.
>>>>>>> But it posts correct key code for all the other keys. On the
>>>>>>> other hand CGEventCreateKeyboardEvent posts correct key code for
>>>>>>> all the modifier keys and
>>>>>>> hence it is used to post modifier key events and
>>>>>>> AXUIElementPostKeyboardEvent is used to post all the remaining
>>>>>>> key events.
>>>>>>>
>>>>>>> Regards,
>>>>>>> Manajit
>>>>>>
>>>>>
>>>>
>>>
>>
>


-- 
Best regards, Sergey.

From Sergey.Bylokhov at oracle.com  Thu Jun  2 19:11:45 2016
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Thu, 2 Jun 2016 22:11:45 +0300
Subject: <AWT Dev> Review request for JDK-8157476
 -Wlogical-not-parentheses warnings in JRSUIConstantSync.m
In-Reply-To: <EBCF2BF8-3EBE-4C04-81F8-E3B7E445596B@oracle.com>
References: <385B0DD3-EB23-4470-BB75-65CC8417F87B@oracle.com>
	<EBCF2BF8-3EBE-4C04-81F8-E3B7E445596B@oracle.com>
Message-ID: <5a5be019-0fe5-3f74-68df-677967515aaf@oracle.com>

Looks fine.
Note that this change should be pushed to jdk9-client ws:
http://hg.openjdk.java.net/jdk9/client/jdk/

On 31.05.16 21:35, Dan Smith wrote:
> Can I get somebody to look at this?  Just point me in the right direction if I'm in the wrong place, please.
>
> ?Dan
>
>> On May 20, 2016, at 1:52 PM, Dan Smith <daniel.smith at oracle.com> wrote:
>>
>> https://bugs.openjdk.java.net/browse/JDK-8157476
>>
>> I noticed this code triggering a LOT of warnings when building under Xcode 7.3 in Mac OS X, and the fix is trivial.
>>
>> (I'm guessing this native file belongs to AWT, but please redirect me if I'm wrong.)
>>
>> -----
>>
>> diff -r 8c75ff8185c6 src/java.desktop/macosx/native/libosxui/JRSUIConstantSync.m
>> --- a/src/java.desktop/macosx/native/libosxui/JRSUIConstantSync.m	Fri May 20 11:12:02 2016 -0700
>> +++ b/src/java.desktop/macosx/native/libosxui/JRSUIConstantSync.m	Fri May 20 13:41:53 2016 -0600
>> @@ -90,7 +90,7 @@
>>     apple_laf_JRSUIConstants_ ## clazz ## __ ## constant
>>
>> #define CONSTANT_CHECK(clazz, constant)                                \
>> -    JRS_CONSTANT(clazz, constant) == JNI_CONSTANT(clazz, constant)
>> +    ( JRS_CONSTANT(clazz, constant) == JNI_CONSTANT(clazz, constant) )
>>
>> #define CONSISTENCY_CHECK(clazz, constant)                            \
>>     if ( !CONSTANT_CHECK(clazz, constant) ) return NO;
>>
>> -----
>>
>> If that looks okay, I'm happy to push this myself.  As noted in the bug comments, I think this is a legitimate bug fix, though -- so if somebody wants to write a test exposing the bug, you may just want to assign to yourself and take responsibility for pushing.
>>
>> Thanks,
>> Dan
>


-- 
Best regards, Sergey.

From iris.clark at oracle.com  Fri Jun  3 03:39:32 2016
From: iris.clark at oracle.com (Iris Clark)
Date: Thu, 2 Jun 2016 20:39:32 -0700 (PDT)
Subject: <AWT Dev> RFR: 8158458: Update references from "1.9" to "9"
In-Reply-To: <574FAB08.9000205@oracle.com>
References: <debc6713-f24e-4483-94fa-707853742266@default>
	<574FA81B.1040706@oracle.com> <574FAB08.9000205@oracle.com>
Message-ID: <569c3e80-d59e-4880-bcf4-11717fd5d821@default>

Hi, Phil.

Thanks for looking that this tiny change.

I agree with you regarding the usefulness of this tag, but I just noticed that they are @since tags exist for every single method in the class.  Since you are the owner of the code, it's your call to keep it or remove it.

Here's the alternative changeset with the @since tag removed:

src/java.desktop/macosx/classes/com/apple/eawt/Application.java
--- a/src/java.desktop/macosx/classes/com/apple/eawt/Application.java   Wed Jun 01 11:22:06 2016 -0700
+++ b/src/java.desktop/macosx/classes/com/apple/eawt/Application.java   Thu Jun 02 20:35:37 2016 -0700
@@ -372,7 +372,6 @@
      * Acceptable values are from 0 to 100, any other disables progress indication.
      *
      * @param value progress value
-     * @since 1.9
      */
     public void setDockIconProgress(final int value) {
         iconHandler.setDockIconProgress(value);

I'll use this unless you instruct me otherwise.  As discussed today, the plan is to push this small change to jdk9/dev.

Thanks,
iris

-----Original Message-----
From: Philip Race 
Sent: Wednesday, June 01, 2016 8:42 PM
To: Iris Clark
Cc: awt-dev at openjdk.java.net; compiler-dev at openjdk.java.net
Subject: Re: <AWT Dev> RFR: 8158458: Update references from "1.9" to "9"

By which I mean "delete" is as good as "update'

-phil

On 6/1/16, 8:29 PM, Philip Race wrote:
> I don't see why @since matters on internal classes ...
>
> -phil.
>
> On 6/1/16, 6:17 PM, Iris Clark wrote:
>> Hi.
>>
>> I'm taking another pass at replacing instances of "@since 1.9" with 
>> "@since 9" and discovered a couple of jdk (AWT?) and langtools 
>> (DocTree) files which need to be updated.  I've filed the following 
>> but to address this problem:
>>
>>      8158458: Update references from "1.9" to "9" (closed code))
>>      https://bugs.openjdk.java.net/browse/JDK-8158458
>>
>> This is the necessary diff, against jdk9/dev:
>>
>> [/w/iclark/verona/javadoc/jdk]:
>> diff -r 0bd06ec69c5b
>> src/java.desktop/macosx/classes/com/apple/eawt/Application.java
>> --- a/src/java.desktop/macosx/classes/com/apple/eawt/Application.java
>> Wed Jun 01 11:22:06 2016 -0700
>> +++ b/src/java.desktop/macosx/classes/com/apple/eawt/Application.java
>> Wed Jun 01 17:40:09 2016 -0700
>> @@ -372,7 +372,7 @@
>>    * Acceptable values are from 0 to 100, any other disables progress 
>> indication.
>>    *
>>    * @param value progress value
>> - * @since 1.9
>> + * @since 9
>>        */
>>       public void setDockIconProgress(final int value) {
>>           iconHandler.setDockIconProgress(value);
>>
>> [/w/iclark/verona/javadoc/langtools]:
>> diff -r 2d1a6b746310
>> src/jdk.compiler/share/classes/com/sun/source/doctree/HiddenTree.java
>> ---
>> a/src/jdk.compiler/share/classes/com/sun/source/doctree/HiddenTree.ja
>> va
>> Wed Jun 01 12:39:24 2016 +0100
>> +++ 
>> b/src/jdk.compiler/share/classes/com/sun/source/doctree/HiddenTree.ja
>> va
>> Wed Jun 01 17:40:09 2016 -0700
>> @@ -34,7 +34,7 @@
>>    *<p>
>>    *&#064;hidden
>>    *
>> - * @since 1.9
>> + * @since 9
>>    */
>>   public interface HiddenTree extends BlockTagTree {
>>       /**
>>
>> Build and test runs show no regressions.
>>
>> Thanks,
>> Iris

From prem.balakrishnan at oracle.com  Mon Jun  6 10:20:00 2016
From: prem.balakrishnan at oracle.com (Prem Balakrishnan)
Date: Mon, 6 Jun 2016 03:20:00 -0700 (PDT)
Subject: <AWT Dev> Review Request: JDK-8158478 : X11 keysym XK_topt maps to
 the wrong Unicode character
Message-ID: <01958dab-24a1-457d-9e44-07d8b1d9f71a@default>

Hi,

Please review fix for JDK9,

?

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

?

Webrev: http://cr.openjdk.java.net/~pkbalakr/8158478/webrev.00/ 

?

?

Issue:

X11 keysym XK_topt maps to the wrong Unicode character.

?

?

Cause:

XK_topt ?is set to Display the Symbol ?? ( U+242C un defined)

?

Fix:

XK_topt ?is set to Displays the Symbol ? (U+252C: BOX DRAWINGS LIGHT DOWN AND HORIZONTAL)

?

Thanks,

Prem

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

From yuri.nesterenko at oracle.com  Mon Jun  6 15:48:02 2016
From: yuri.nesterenko at oracle.com (Yuri Nesterenko)
Date: Mon, 6 Jun 2016 18:48:02 +0300
Subject: <AWT Dev> [9] Review Request: 8004693 TEST_BUG:
 java/awt/KeyboardFocusmanager/DefaultPolicyChange/DefaultPolicyChange_Swing.java
 fails
In-Reply-To: <eb5fd302-ada9-0032-3560-ce8589797ff0@oracle.com>
References: <eb5fd302-ada9-0032-3560-ce8589797ff0@oracle.com>
Message-ID: <57559B32.70100@oracle.com>

+1

-yan

On 05/30/2016 07:39 PM, Sergey Bylokhov wrote:
> Hello.
> Please review the fix for jdk9.
>
> The test DefaultPolicyChange_Swing.java has two issues:
>   - It uses invokeLater(), so the test usually pass before the code is
> executed on the EDT, because the main thread completes before.
>   - The test fetches the FocusTraversalPolicy from the current
> KeyboardFocusManager. But default FocusTraversalPolicy can be changed
> during the Swing initialization(JDK-7125044). The test should save the
> state before setDefaultFocusTraversalPolicy() but after the Swing
> initialization, and validate that the FocusTraversalPolicy was not
> changed for windows which were already shown.
>
> The fix proposed in the CR is applied + small cleanup(regtesthelpers
> removed and InvokeAndWait is used instead of InvokeLater+realSync)
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8004693
> Webrev can be found at: http://cr.openjdk.java.net/~serb/8004693/webrev.01
>


From alexander.v.stepanov at oracle.com  Mon Jun  6 15:58:03 2016
From: alexander.v.stepanov at oracle.com (Alexander Stepanov)
Date: Mon, 6 Jun 2016 18:58:03 +0300
Subject: <AWT Dev> [9] Review Request: 8004693 TEST_BUG:
 java/awt/KeyboardFocusmanager/DefaultPolicyChange/DefaultPolicyChange_Swing.java
 fails
In-Reply-To: <eb5fd302-ada9-0032-3560-ce8589797ff0@oracle.com>
References: <eb5fd302-ada9-0032-3560-ce8589797ff0@oracle.com>
Message-ID: <d271d6d1-f279-cf67-421f-9727fd655a8d@oracle.com>

Hello Sergey,

The fix looks good (not a reviewer).

Thanks,
Alexander

On 5/30/2016 7:39 PM, Sergey Bylokhov wrote:
> Hello.
> Please review the fix for jdk9.
>
> The test DefaultPolicyChange_Swing.java has two issues:
>  - It uses invokeLater(), so the test usually pass before the code is 
> executed on the EDT, because the main thread completes before.
>  - The test fetches the FocusTraversalPolicy from the current 
> KeyboardFocusManager. But default FocusTraversalPolicy can be changed 
> during the Swing initialization(JDK-7125044). The test should save the 
> state before setDefaultFocusTraversalPolicy() but after the Swing 
> initialization, and validate that the FocusTraversalPolicy was not 
> changed for windows which were already shown.
>
> The fix proposed in the CR is applied + small cleanup(regtesthelpers 
> removed and InvokeAndWait is used instead of InvokeLater+realSync)
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8004693
> Webrev can be found at: 
> http://cr.openjdk.java.net/~serb/8004693/webrev.01
>


From semyon.sadetsky at oracle.com  Tue Jun  7 07:23:07 2016
From: semyon.sadetsky at oracle.com (Semyon Sadetsky)
Date: Tue, 7 Jun 2016 10:23:07 +0300
Subject: <AWT Dev> [9] Review Request: 8004693 TEST_BUG:
 java/awt/KeyboardFocusmanager/DefaultPolicyChange/DefaultPolicyChange_Swing.java
 fails
In-Reply-To: <eb5fd302-ada9-0032-3560-ce8589797ff0@oracle.com>
References: <eb5fd302-ada9-0032-3560-ce8589797ff0@oracle.com>
Message-ID: <bf339c16-f8c8-a957-753f-13a271d7b60c@oracle.com>

Sergey,

- You need to compare with the original policy by reference. Only by 
that you may prove that the original policies were not affected.

- Please remove the printouts of policies objects before and after the 
default policy change. It looks too verbose.

- It would be nice to have a check if the default policy has been really 
changed to the new one.

- What is purpose of jb1, jt1, jp1? They are created but never used.

--Semyon


On 5/30/2016 7:39 PM, Sergey Bylokhov wrote:
> Hello.
> Please review the fix for jdk9.
>
> The test DefaultPolicyChange_Swing.java has two issues:
>  - It uses invokeLater(), so the test usually pass before the code is 
> executed on the EDT, because the main thread completes before.
>  - The test fetches the FocusTraversalPolicy from the current 
> KeyboardFocusManager. But default FocusTraversalPolicy can be changed 
> during the Swing initialization(JDK-7125044). The test should save the 
> state before setDefaultFocusTraversalPolicy() but after the Swing 
> initialization, and validate that the FocusTraversalPolicy was not 
> changed for windows which were already shown.
>
> The fix proposed in the CR is applied + small cleanup(regtesthelpers 
> removed and InvokeAndWait is used instead of InvokeLater+realSync)
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8004693
> Webrev can be found at: 
> http://cr.openjdk.java.net/~serb/8004693/webrev.01
>


From Sergey.Bylokhov at oracle.com  Tue Jun  7 08:48:51 2016
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Tue, 7 Jun 2016 11:48:51 +0300
Subject: <AWT Dev> [9] Review Request: 8004693 TEST_BUG:
 java/awt/KeyboardFocusmanager/DefaultPolicyChange/DefaultPolicyChange_Swing.java
 fails
In-Reply-To: <bf339c16-f8c8-a957-753f-13a271d7b60c@oracle.com>
References: <eb5fd302-ada9-0032-3560-ce8589797ff0@oracle.com>
	<bf339c16-f8c8-a957-753f-13a271d7b60c@oracle.com>
Message-ID: <7e49d08b-06ba-8a0d-8932-7d82b7db3ee2@oracle.com>

On 07.06.16 10:23, Semyon Sadetsky wrote:
> Sergey,
>
> - You need to compare with the original policy by reference. Only by
> that you may prove that the original policies were not affected.

I do not see the reason why the equal cannot be used, if some policy 
will override equal and return true then two policies will be treated as 
equal/unchanged.

>
> - Please remove the printouts of policies objects before and after the
> default policy change. It looks too verbose.

It was there before, and I found it quite useful during the fix.

>
> - It would be nice to have a check if the default policy has been really
> changed to the new one.

I did not get it, the bug which was bound to this test is about the 
incorrect changing the policy by setDefaultFocusTraversalPolicy(). the 
tests which cover other behavior are bound to other bugs like JDK-7125044

>
> - What is purpose of jb1, jt1, jp1? They are created but never used.

They are used as dummy content for JFrame jf.

> On 5/30/2016 7:39 PM, Sergey Bylokhov wrote:
>> Hello.
>> Please review the fix for jdk9.
>>
>> The test DefaultPolicyChange_Swing.java has two issues:
>>  - It uses invokeLater(), so the test usually pass before the code is
>> executed on the EDT, because the main thread completes before.
>>  - The test fetches the FocusTraversalPolicy from the current
>> KeyboardFocusManager. But default FocusTraversalPolicy can be changed
>> during the Swing initialization(JDK-7125044). The test should save the
>> state before setDefaultFocusTraversalPolicy() but after the Swing
>> initialization, and validate that the FocusTraversalPolicy was not
>> changed for windows which were already shown.
>>
>> The fix proposed in the CR is applied + small cleanup(regtesthelpers
>> removed and InvokeAndWait is used instead of InvokeLater+realSync)
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8004693
>> Webrev can be found at:
>> http://cr.openjdk.java.net/~serb/8004693/webrev.01
>>
>


-- 
Best regards, Sergey.

From semyon.sadetsky at oracle.com  Tue Jun  7 09:31:14 2016
From: semyon.sadetsky at oracle.com (Semyon Sadetsky)
Date: Tue, 7 Jun 2016 12:31:14 +0300
Subject: <AWT Dev> [9] Review Request: 8004693 TEST_BUG:
 java/awt/KeyboardFocusmanager/DefaultPolicyChange/DefaultPolicyChange_Swing.java
 fails
In-Reply-To: <7e49d08b-06ba-8a0d-8932-7d82b7db3ee2@oracle.com>
References: <eb5fd302-ada9-0032-3560-ce8589797ff0@oracle.com>
	<bf339c16-f8c8-a957-753f-13a271d7b60c@oracle.com>
	<7e49d08b-06ba-8a0d-8932-7d82b7db3ee2@oracle.com>
Message-ID: <832eae6a-481c-28bc-5686-dbdb3cb10770@oracle.com>



On 6/7/2016 11:48 AM, Sergey Bylokhov wrote:
> On 07.06.16 10:23, Semyon Sadetsky wrote:
>> Sergey,
>>
>> - You need to compare with the original policy by reference. Only by
>> that you may prove that the original policies were not affected.
>
> I do not see the reason why the equal cannot be used, if some policy 
> will override equal and return true then two policies will be treated 
> as equal/unchanged.
>
I cannot agree with this assumption. Since the policy should not be 
touched for the existing components, the test should prove that the 
policy object instances are the same, other behavior is an error.

>>
>> - Please remove the printouts of policies objects before and after the
>> default policy change. It looks too verbose.
>
> It was there before, and I found it quite useful during the fix.
And how is it useful? The toString() method is not implemented for the 
printed objects, so the printouts are not readable. I found this print 
out as excessive. If it invites to compare the memory addresses, that 
has no sense, because it is automatically executed at the end of the 
test and the same printout is produced in case of error.

>
>>
>> - It would be nice to have a check if the default policy has been really
>> changed to the new one.
>
> I did not get it, the bug which was bound to this test is about the 
> incorrect changing the policy by setDefaultFocusTraversalPolicy(). the 
> tests which cover other behavior are bound to other bugs like JDK-7125044
In this case, please, provide a link to the test which covers the 
KFM#setDefaultFocusTraversalPolicy() method.

>
>>
>> - What is purpose of jb1, jt1, jp1? They are created but never used.
>
> They are used as dummy content for JFrame jf.
That is what I asked. For what purpose this dummy content is added? Can 
you clarify that?

--Semyon
>
>> On 5/30/2016 7:39 PM, Sergey Bylokhov wrote:
>>> Hello.
>>> Please review the fix for jdk9.
>>>
>>> The test DefaultPolicyChange_Swing.java has two issues:
>>>  - It uses invokeLater(), so the test usually pass before the code is
>>> executed on the EDT, because the main thread completes before.
>>>  - The test fetches the FocusTraversalPolicy from the current
>>> KeyboardFocusManager. But default FocusTraversalPolicy can be changed
>>> during the Swing initialization(JDK-7125044). The test should save the
>>> state before setDefaultFocusTraversalPolicy() but after the Swing
>>> initialization, and validate that the FocusTraversalPolicy was not
>>> changed for windows which were already shown.
>>>
>>> The fix proposed in the CR is applied + small cleanup(regtesthelpers
>>> removed and InvokeAndWait is used instead of InvokeLater+realSync)
>>>
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8004693
>>> Webrev can be found at:
>>> http://cr.openjdk.java.net/~serb/8004693/webrev.01
>>>
>>
>
>


From Sergey.Bylokhov at oracle.com  Tue Jun  7 12:31:32 2016
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Tue, 7 Jun 2016 15:31:32 +0300
Subject: <AWT Dev> [9] Review Request: 8004693 TEST_BUG:
 java/awt/KeyboardFocusmanager/DefaultPolicyChange/DefaultPolicyChange_Swing.java
 fails
In-Reply-To: <832eae6a-481c-28bc-5686-dbdb3cb10770@oracle.com>
References: <eb5fd302-ada9-0032-3560-ce8589797ff0@oracle.com>
	<bf339c16-f8c8-a957-753f-13a271d7b60c@oracle.com>
	<7e49d08b-06ba-8a0d-8932-7d82b7db3ee2@oracle.com>
	<832eae6a-481c-28bc-5686-dbdb3cb10770@oracle.com>
Message-ID: <63249335-46d1-63e0-7942-757c192c4e6c@oracle.com>

On 07.06.16 12:31, Semyon Sadetsky wrote:
> I cannot agree with this assumption. Since the policy should not be
> touched for the existing components, the test should prove that the
> policy object instances are the same, other behavior is an error.

The policy will be the same if two policies will return true in equals, 
by default our policy do not implement the equal, so == is used. But if 
some of them will implemented it and return true will mean that the same 
policy is used, but the different instance.

> And how is it useful? The toString() method is not implemented for the
> printed objects, so the printouts are not readable. I found this print
> out as excessive. If it invites to compare the memory addresses, that
> has no sense, because it is automatically executed at the end of the
> test and the same printout is produced in case of error.

It print the class of the policy, which is different for awt and swing.

> In this case, please, provide a link to the test which covers the
> KFM#setDefaultFocusTraversalPolicy() method.

It is tested in FocusPolicyTest.java

>> They are used as dummy content for JFrame jf.
> That is what I asked. For what purpose this dummy content is added? Can
> you clarify that?

By the same reason why JDialog, JWindow and JFrame are added, it 
increase the coverage if any side affects exists.

>>> On 5/30/2016 7:39 PM, Sergey Bylokhov wrote:
>>>> Hello.
>>>> Please review the fix for jdk9.
>>>>
>>>> The test DefaultPolicyChange_Swing.java has two issues:
>>>>  - It uses invokeLater(), so the test usually pass before the code is
>>>> executed on the EDT, because the main thread completes before.
>>>>  - The test fetches the FocusTraversalPolicy from the current
>>>> KeyboardFocusManager. But default FocusTraversalPolicy can be changed
>>>> during the Swing initialization(JDK-7125044). The test should save the
>>>> state before setDefaultFocusTraversalPolicy() but after the Swing
>>>> initialization, and validate that the FocusTraversalPolicy was not
>>>> changed for windows which were already shown.
>>>>
>>>> The fix proposed in the CR is applied + small cleanup(regtesthelpers
>>>> removed and InvokeAndWait is used instead of InvokeLater+realSync)
>>>>
>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8004693
>>>> Webrev can be found at:
>>>> http://cr.openjdk.java.net/~serb/8004693/webrev.01
>>>>
>>>
>>
>>
>


-- 
Best regards, Sergey.

From alexandr.scherbatiy at oracle.com  Tue Jun  7 15:44:59 2016
From: alexandr.scherbatiy at oracle.com (Alexandr Scherbatiy)
Date: Tue, 7 Jun 2016 18:44:59 +0300
Subject: <AWT Dev> Review request for 8151385: [hidpi] JOptionPane-Icons
 only partially visible when using Windows 10 L&F
In-Reply-To: <7E17C804-7EA7-4F42-8A1E-C50093C4F40E@tagtraum.com>
References: <898AFD4C-3717-48C0-BBB2-24287F7C0512@tagtraum.com>
	<36184957-6682-4F71-BDD4-2EA35BE49209@tagtraum.com>
	<56E3092F.6040905@oracle.com>
	<CBC1EF8D-5853-42F8-B416-A6364D5BB8BD@tagtraum.com>
	<56E8EE58.1010006@oracle.com>
	<337E07D9-EC25-4BE7-B387-F11473A8BB26@tagtraum.com>
	<56F0628A.5030908@oracle.com>
	<1D2830BA-9610-407B-9C4C-424E6B57074D@tagtraum.com>
	<56F17285.7020506@oracle.com>
	<9D18EE88-883B-4428-8CD5-347232761D3F@tagtraum.com>
	<7E17C804-7EA7-4F42-8A1E-C50093C4F40E@tagtraum.com>
Message-ID: <83c01190-e06e-8bbd-b685-772ad2bb8cfb@oracle.com>


Hello Hendrik,

I slightly updated your fix to return a multi-resolution image with base 
icon size when icon size is greater than the real icon size. This allows 
to draw a high-resolution icon to the same bounds on JOptionPane.
http://cr.openjdk.java.net/~alexsch/hendrik.schreiber/8151385/webrev.01

I have not found the solution for the native toolbar icons yet. An icon 
with IDB_VIEW_SMALL_COLOR has size 16x16 on my Windows 8.1. The 
GetSystemMetrics(SM_CXSMICON) returns 32. It is a question for me should 
IDB_VIEW_SMALL_COLOR icon has the same size as the 
GetSystemMetrics(SM_CXSMICON).
An icon with IDB_VIEW_LARGE_COLOR returns also icon with size 16x16 and 
the returned image contains only one quarter of the original picture.

I left the code for the toolbar icons as it was before so it uses low 
resolution IDB_VIEW_SMALL_COLOR icons.
I think it can be fixed as a separated issue.

Thanks,
Alexandr.

On 4/19/2016 2:30 PM, Hendrik Schreiber wrote:
>> On Mar 22, 2016, at 17:43, Hendrik Schreiber <hs at tagtraum.com> wrote:
>>
>>> I created an application in Visual Studio and try to check the returned icon size.
>>> It returns the same size 16 for both IDB_VIEW_SMALL_COLOR and IDB_VIEW_LARGE_COLOR.
>> Really? That would contradict the documentation. Unfortunately, I currently don?t have access to a working Visual Studio installation. Next week will be better.
> Hey Alexandr,
>
> I finally had a chance to look at this again and can only confirm your findings. For some reason, Windows always returns a 16x16 icon, regardless of whether you asked for IDB_VIEW_SMALL_COLOR or IDB_VIEW_LARGE_COLOR.
>
> I?m at a loss. If Windows does not provide appropriate icons, what should we do?
>
> -hendrik


From Sergey.Bylokhov at oracle.com  Tue Jun  7 16:06:42 2016
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Tue, 7 Jun 2016 19:06:42 +0300
Subject: <AWT Dev> <AWT dev>[9] Review request for 8022810: Cannot list
 all the available display modes on Ubuntu linux in case of two screen
 devices
In-Reply-To: <74a58110-73d6-8ffa-2b98-8a196f655d57@oracle.com>
References: <573579EC.6000105@oracle.com>
	<ad449d68-fd9a-0078-626c-d515cc344775@oracle.com>
	<f8acf699-0296-4013-7c17-841c1ff45325@oracle.com>
	<acf4ee13-8d76-f4a3-76b3-ee8bbae8f652@oracle.com>
	<1e8b8362-9813-4ef9-d46d-9d87f5c2ac0f@oracle.com>
	<a6db7025-e6c4-01c1-8f5f-04207edb15aa@oracle.com>
	<7d72df28-6063-871c-2b76-dc040a1011c9@oracle.com>
	<210dbdfe-a115-61e7-2e8e-8c388913812b@oracle.com>
	<ed10bf97-e37c-76d2-7542-e1013de1e871@oracle.com>
	<5d40566d-70e2-0d46-0d2a-b375e80eedd6@oracle.com>
	<74670508-fc12-7423-812c-313161ee3e59@oracle.com>
	<9cd3e850-51fb-40a0-be98-47e9d2841491@oracle.com>
	<4f58051d-a76b-4d4f-c8c4-2aa71a3c1295@oracle.com>
	<74a58110-73d6-8ffa-2b98-8a196f655d57@oracle.com>
Message-ID: <0b9b2d18-61ea-c6f9-8a21-63947d477cc8@oracle.com>

On 01.06.16 9:57, Semyon Sadetsky wrote:
> I don't have access to such hardware as well. I'm using linux VMs with
> several virtual screens. Adding a new screen to a VM configuration can
> be done in 10 seconds in most VMMs.
> The result of the getDisplayModes() for 2-screen Ubuntu VM before the
> fix looked like:
> for device[0]: <current screen 0 mode>, <<the rest modes of
> screen-0>>,<<all modes of screen-1>>
> for device[1]: <current screen 1 mode>

So can you confirm that after the fix the next code will work w/o 
exceptions?
http://cr.openjdk.java.net/~serb/tmp/Test.java

I am worried since we updated the enumDisplayModes(), but did not update 
the getCurrentDisplayMode() which still uses the old code.

>>>>>>>> the list of supported modes changed and my question was: what
>>>>>>>> happens
>>>>>>>> when these modes will be passed to setDisplayMode() (of course
>>>>>>>> modes
>>>>>>>> and setDisplayMode should be from one GraphicsDevice object).
>>>>>>> the same as before the fix.

Actually it seems that setDisplayMode() should not work since 
JDK-8131752. probably someday we should change the code in 
X11GraphicsDevice.isDisplayChangeSupported(), which skip the xinerama case.

-- 
Best regards, Sergey.

From dmitry.markov at oracle.com  Wed Jun  8 07:07:50 2016
From: dmitry.markov at oracle.com (dmitry markov)
Date: Wed, 08 Jun 2016 10:07:50 +0300
Subject: <AWT Dev> [9] Review request for 8025130: [macosx] Frame
 setLocationByPlatform has no effect under Mac OS X
In-Reply-To: <574FEBDA.6060605@oracle.com>
References: <574FEBDA.6060605@oracle.com>
Message-ID: <5757C446.7050409@oracle.com>

Any volunteers to review the fix?

Thanks in advance,
Dmitry
On 02/06/2016 11:18, dmitry markov wrote:
> Hello,
>
> Could you review a fix for jdk9, please?
>
>     bug: https://bugs.openjdk.java.net/browse/JDK-8025130
>     webrev: http://cr.openjdk.java.net/~dmarkov/8025130/webrev.00/
>
> Problem description:
> Invocation of setLocationByPlatform() has no effect under Mac OS X, 
> (i.e. the feature is not fully implemented for this platform).
>
> Fix:
> Introduce new method nativeSetNSWindowLocationByPlatform(). It moves a 
> window to 'default location' calculated by platform using 
> cascadeTopLeftFromPoint function from NSWindow.
> Add check of locationByPlatform flag to CPlatformWindow.setVisible(). 
> If the flag is set, a window will be moved to 'default location'.
>
> Thanks,
> Dmitry


From semyon.sadetsky at oracle.com  Wed Jun  8 07:12:32 2016
From: semyon.sadetsky at oracle.com (Semyon Sadetsky)
Date: Wed, 8 Jun 2016 10:12:32 +0300
Subject: <AWT Dev> [9] Review Request: 8004693 TEST_BUG:
 java/awt/KeyboardFocusmanager/DefaultPolicyChange/DefaultPolicyChange_Swing.java
 fails
In-Reply-To: <63249335-46d1-63e0-7942-757c192c4e6c@oracle.com>
References: <eb5fd302-ada9-0032-3560-ce8589797ff0@oracle.com>
	<bf339c16-f8c8-a957-753f-13a271d7b60c@oracle.com>
	<7e49d08b-06ba-8a0d-8932-7d82b7db3ee2@oracle.com>
	<832eae6a-481c-28bc-5686-dbdb3cb10770@oracle.com>
	<63249335-46d1-63e0-7942-757c192c4e6c@oracle.com>
Message-ID: <308b6441-222f-9d85-3286-fcc695a01eb5@oracle.com>

On 6/7/2016 3:31 PM, Sergey Bylokhov wrote:

> On 07.06.16 12:31, Semyon Sadetsky wrote:
>> I cannot agree with this assumption. Since the policy should not be
>> touched for the existing components, the test should prove that the
>> policy object instances are the same, other behavior is an error.
>
> The policy will be the same if two policies will return true in 
> equals, by default our policy do not implement the equal, so == is 
> used. But if some of them will implemented it and return true will 
> mean that the same policy is used, but the different instance.
Since method equals() is not specified in the FTP class, you cannot make 
any assumption how it is implemented, it may return true for different 
classes instances. So in the test the policy untouchability should be 
checked by ==, without any additional assumptions about the equals() 
method implementation.
>
>> And how is it useful? The toString() method is not implemented for the
>> printed objects, so the printouts are not readable. I found this print
>> out as excessive. If it invites to compare the memory addresses, that
>> has no sense, because it is automatically executed at the end of the
>> test and the same printout is produced in case of error.
>
> It print the class of the policy, which is different for awt and swing.
I know. But this is not needed because it does not produce any valuable 
information for a normal test execution (when it is passed).
>
>> In this case, please, provide a link to the test which covers the
>> KFM#setDefaultFocusTraversalPolicy() method.
>
> It is tested in FocusPolicyTest.java
>
>>> They are used as dummy content for JFrame jf.
>> That is what I asked. For what purpose this dummy content is added? Can
>> you clarify that?
>
> By the same reason why JDialog, JWindow and JFrame are added, it 
> increase the coverage if any side affects exists.
JDialog, JWindow and JFrame are focus traversal cycle roots by default, 
but those "dummy" components are not, i.e. their FTPs are not used and 
are nulls by default.
So could you point to the code related to the handling of the default 
FTP change, that is additionally covered by the test due to those 
"dummy" components?

--Semyon
>
>>>> On 5/30/2016 7:39 PM, Sergey Bylokhov wrote:
>>>>> Hello.
>>>>> Please review the fix for jdk9.
>>>>>
>>>>> The test DefaultPolicyChange_Swing.java has two issues:
>>>>>  - It uses invokeLater(), so the test usually pass before the code is
>>>>> executed on the EDT, because the main thread completes before.
>>>>>  - The test fetches the FocusTraversalPolicy from the current
>>>>> KeyboardFocusManager. But default FocusTraversalPolicy can be changed
>>>>> during the Swing initialization(JDK-7125044). The test should save 
>>>>> the
>>>>> state before setDefaultFocusTraversalPolicy() but after the Swing
>>>>> initialization, and validate that the FocusTraversalPolicy was not
>>>>> changed for windows which were already shown.
>>>>>
>>>>> The fix proposed in the CR is applied + small cleanup(regtesthelpers
>>>>> removed and InvokeAndWait is used instead of InvokeLater+realSync)
>>>>>
>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8004693
>>>>> Webrev can be found at:
>>>>> http://cr.openjdk.java.net/~serb/8004693/webrev.01
>>>>>
>>>>
>>>
>>>
>>
>
>


From semyon.sadetsky at oracle.com  Wed Jun  8 07:44:26 2016
From: semyon.sadetsky at oracle.com (Semyon Sadetsky)
Date: Wed, 8 Jun 2016 10:44:26 +0300
Subject: <AWT Dev> [9] Review request for 8025130: [macosx] Frame
 setLocationByPlatform has no effect under Mac OS X
In-Reply-To: <5757C446.7050409@oracle.com>
References: <574FEBDA.6060605@oracle.com> <5757C446.7050409@oracle.com>
Message-ID: <bd620d96-565b-63c3-e3bc-9de050d9ceb5@oracle.com>

Hi Dmitri,

The fix looks good to me.

In the test please dispose frames in case of exception

and don't forget to set the correct GPL year in AWTWindow.m.

--Semyon

On 6/8/2016 10:07 AM, dmitry markov wrote:
> Any volunteers to review the fix?
>
> Thanks in advance,
> Dmitry
> On 02/06/2016 11:18, dmitry markov wrote:
>> Hello,
>>
>> Could you review a fix for jdk9, please?
>>
>>     bug: https://bugs.openjdk.java.net/browse/JDK-8025130
>>     webrev: http://cr.openjdk.java.net/~dmarkov/8025130/webrev.00/
>>
>> Problem description:
>> Invocation of setLocationByPlatform() has no effect under Mac OS X, 
>> (i.e. the feature is not fully implemented for this platform).
>>
>> Fix:
>> Introduce new method nativeSetNSWindowLocationByPlatform(). It moves 
>> a window to 'default location' calculated by platform using 
>> cascadeTopLeftFromPoint function from NSWindow.
>> Add check of locationByPlatform flag to CPlatformWindow.setVisible(). 
>> If the flag is set, a window will be moved to 'default location'.
>>
>> Thanks,
>> Dmitry
>


From hs at tagtraum.com  Wed Jun  8 07:57:01 2016
From: hs at tagtraum.com (Hendrik Schreiber)
Date: Wed, 8 Jun 2016 09:57:01 +0200
Subject: <AWT Dev> Review request for 8151385: [hidpi] JOptionPane-Icons
	only partially visible when using Windows 10 L&F
In-Reply-To: <83c01190-e06e-8bbd-b685-772ad2bb8cfb@oracle.com>
References: <898AFD4C-3717-48C0-BBB2-24287F7C0512@tagtraum.com>
	<36184957-6682-4F71-BDD4-2EA35BE49209@tagtraum.com>
	<56E3092F.6040905@oracle.com>
	<CBC1EF8D-5853-42F8-B416-A6364D5BB8BD@tagtraum.com>
	<56E8EE58.1010006@oracle.com>
	<337E07D9-EC25-4BE7-B387-F11473A8BB26@tagtraum.com>
	<56F0628A.5030908@oracle.com>
	<1D2830BA-9610-407B-9C4C-424E6B57074D@tagtraum.com>
	<56F17285.7020506@oracle.com>
	<9D18EE88-883B-4428-8CD5-347232761D3F@tagtraum.com>
	<7E17C804-7EA7-4F42-8A1E-C50093C4F40E@tagtraum.com>
	<83c01190-e06e-8bbd-b685-772ad2bb8cfb@oracle.com>
Message-ID: <BC4ADF37-F25A-4D13-A096-9DFD017D8EB3@tagtraum.com>

Hey Alexandr,

> On Jun 7, 2016, at 17:44, Alexandr Scherbatiy <alexandr.scherbatiy at oracle.com> wrote:
> 
> I slightly updated your fix to return a multi-resolution image with base icon size when icon size is greater than the real icon size. This allows to draw a high-resolution icon to the same bounds on JOptionPane.
> http://cr.openjdk.java.net/~alexsch/hendrik.schreiber/8151385/webrev.01

Thanks. That looks good to me.

> I have not found the solution for the native toolbar icons yet. An icon with IDB_VIEW_SMALL_COLOR has size 16x16 on my Windows 8.1. The GetSystemMetrics(SM_CXSMICON) returns 32. It is a question for me should IDB_VIEW_SMALL_COLOR icon has the same size as the GetSystemMetrics(SM_CXSMICON).
> An icon with IDB_VIEW_LARGE_COLOR returns also icon with size 16x16 and the returned image contains only one quarter of the original picture.
> 
> I left the code for the toolbar icons as it was before so it uses low resolution IDB_VIEW_SMALL_COLOR icons.
> I think it can be fixed as a separated issue.

Perhaps that?s the best approach, even though I fear that that means it will never get fixed?
But having the other fixes in the JDK, is already some progress I appreciate very much.

Are you going to create a new bug report?

Eventually, we simply need a more modern FileDialog. See http://mail.openjdk.java.net/pipermail/awt-dev/2016-March/010778.html

Cheers,

-hendrik

From dmitry.markov at oracle.com  Wed Jun  8 09:16:16 2016
From: dmitry.markov at oracle.com (dmitry markov)
Date: Wed, 08 Jun 2016 12:16:16 +0300
Subject: <AWT Dev> [9] Review request for 8025130: [macosx] Frame
 setLocationByPlatform has no effect under Mac OS X
In-Reply-To: <bd620d96-565b-63c3-e3bc-9de050d9ceb5@oracle.com>
References: <574FEBDA.6060605@oracle.com> <5757C446.7050409@oracle.com>
	<bd620d96-565b-63c3-e3bc-9de050d9ceb5@oracle.com>
Message-ID: <5757E260.40800@oracle.com>

Hi Semyon,

Thank you for the review. I have updated the fix based on your 
suggestions. Just in case the updated webrev is located at 
http://cr.openjdk.java.net/~dmarkov/8025130/webrev.01/

Thanks,
Dmitry
On 08/06/2016 10:44, Semyon Sadetsky wrote:
> Hi Dmitri,
>
> The fix looks good to me.
>
> In the test please dispose frames in case of exception
>
> and don't forget to set the correct GPL year in AWTWindow.m.
>
> --Semyon
>
> On 6/8/2016 10:07 AM, dmitry markov wrote:
>> Any volunteers to review the fix?
>>
>> Thanks in advance,
>> Dmitry
>> On 02/06/2016 11:18, dmitry markov wrote:
>>> Hello,
>>>
>>> Could you review a fix for jdk9, please?
>>>
>>>     bug: https://bugs.openjdk.java.net/browse/JDK-8025130
>>>     webrev: http://cr.openjdk.java.net/~dmarkov/8025130/webrev.00/
>>>
>>> Problem description:
>>> Invocation of setLocationByPlatform() has no effect under Mac OS X, 
>>> (i.e. the feature is not fully implemented for this platform).
>>>
>>> Fix:
>>> Introduce new method nativeSetNSWindowLocationByPlatform(). It moves 
>>> a window to 'default location' calculated by platform using 
>>> cascadeTopLeftFromPoint function from NSWindow.
>>> Add check of locationByPlatform flag to 
>>> CPlatformWindow.setVisible(). If the flag is set, a window will be 
>>> moved to 'default location'.
>>>
>>> Thanks,
>>> Dmitry
>>
>


From semyon.sadetsky at oracle.com  Wed Jun  8 09:21:17 2016
From: semyon.sadetsky at oracle.com (Semyon Sadetsky)
Date: Wed, 8 Jun 2016 12:21:17 +0300
Subject: <AWT Dev> [9] Review request for 8025130: [macosx] Frame
 setLocationByPlatform has no effect under Mac OS X
In-Reply-To: <5757E260.40800@oracle.com>
References: <574FEBDA.6060605@oracle.com> <5757C446.7050409@oracle.com>
	<bd620d96-565b-63c3-e3bc-9de050d9ceb5@oracle.com>
	<5757E260.40800@oracle.com>
Message-ID: <d621121a-f561-ef39-a4b6-0dbdfd8da1c2@oracle.com>

Thank you Dmitry. You could change it upon the push.

Still looks good to me.

--Semyon


On 6/8/2016 12:16 PM, dmitry markov wrote:
> Hi Semyon,
>
> Thank you for the review. I have updated the fix based on your 
> suggestions. Just in case the updated webrev is located at 
> http://cr.openjdk.java.net/~dmarkov/8025130/webrev.01/
>
> Thanks,
> Dmitry
> On 08/06/2016 10:44, Semyon Sadetsky wrote:
>> Hi Dmitri,
>>
>> The fix looks good to me.
>>
>> In the test please dispose frames in case of exception
>>
>> and don't forget to set the correct GPL year in AWTWindow.m.
>>
>> --Semyon
>>
>> On 6/8/2016 10:07 AM, dmitry markov wrote:
>>> Any volunteers to review the fix?
>>>
>>> Thanks in advance,
>>> Dmitry
>>> On 02/06/2016 11:18, dmitry markov wrote:
>>>> Hello,
>>>>
>>>> Could you review a fix for jdk9, please?
>>>>
>>>>     bug: https://bugs.openjdk.java.net/browse/JDK-8025130
>>>>     webrev: http://cr.openjdk.java.net/~dmarkov/8025130/webrev.00/
>>>>
>>>> Problem description:
>>>> Invocation of setLocationByPlatform() has no effect under Mac OS X, 
>>>> (i.e. the feature is not fully implemented for this platform).
>>>>
>>>> Fix:
>>>> Introduce new method nativeSetNSWindowLocationByPlatform(). It 
>>>> moves a window to 'default location' calculated by platform using 
>>>> cascadeTopLeftFromPoint function from NSWindow.
>>>> Add check of locationByPlatform flag to 
>>>> CPlatformWindow.setVisible(). If the flag is set, a window will be 
>>>> moved to 'default location'.
>>>>
>>>> Thanks,
>>>> Dmitry
>>>
>>
>


From alexander.potochkin at oracle.com  Wed Jun  8 13:13:35 2016
From: alexander.potochkin at oracle.com (Alexander Potochkin)
Date: Wed, 8 Jun 2016 16:13:35 +0300
Subject: <AWT Dev> [9] Review request for 8025130: [macosx] Frame
 setLocationByPlatform has no effect under Mac OS X
In-Reply-To: <5757E260.40800@oracle.com>
References: <574FEBDA.6060605@oracle.com> <5757C446.7050409@oracle.com>
	<bd620d96-565b-63c3-e3bc-9de050d9ceb5@oracle.com>
	<5757E260.40800@oracle.com>
Message-ID: <03f5339c-4d0f-5cb9-f0d2-fb71e4db2584@oracle.com>


Hello Dmitry

Looks good!

Thanks
alexp

On 6/8/2016 12:16, dmitry markov wrote:
> Hi Semyon,
>
> Thank you for the review. I have updated the fix based on your 
> suggestions. Just in case the updated webrev is located at 
> http://cr.openjdk.java.net/~dmarkov/8025130/webrev.01/
>
> Thanks,
> Dmitry
> On 08/06/2016 10:44, Semyon Sadetsky wrote:
>> Hi Dmitri,
>>
>> The fix looks good to me.
>>
>> In the test please dispose frames in case of exception
>>
>> and don't forget to set the correct GPL year in AWTWindow.m.
>>
>> --Semyon
>>
>> On 6/8/2016 10:07 AM, dmitry markov wrote:
>>> Any volunteers to review the fix?
>>>
>>> Thanks in advance,
>>> Dmitry
>>> On 02/06/2016 11:18, dmitry markov wrote:
>>>> Hello,
>>>>
>>>> Could you review a fix for jdk9, please?
>>>>
>>>>     bug: https://bugs.openjdk.java.net/browse/JDK-8025130
>>>>     webrev: http://cr.openjdk.java.net/~dmarkov/8025130/webrev.00/
>>>>
>>>> Problem description:
>>>> Invocation of setLocationByPlatform() has no effect under Mac OS X, 
>>>> (i.e. the feature is not fully implemented for this platform).
>>>>
>>>> Fix:
>>>> Introduce new method nativeSetNSWindowLocationByPlatform(). It 
>>>> moves a window to 'default location' calculated by platform using 
>>>> cascadeTopLeftFromPoint function from NSWindow.
>>>> Add check of locationByPlatform flag to 
>>>> CPlatformWindow.setVisible(). If the flag is set, a window will be 
>>>> moved to 'default location'.
>>>>
>>>> Thanks,
>>>> Dmitry
>>>
>>
>


From Sergey.Bylokhov at oracle.com  Wed Jun  8 14:37:02 2016
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Wed, 8 Jun 2016 17:37:02 +0300
Subject: <AWT Dev> [9] Review Request: 8004693 TEST_BUG:
 java/awt/KeyboardFocusmanager/DefaultPolicyChange/DefaultPolicyChange_Swing.java
 fails
In-Reply-To: <308b6441-222f-9d85-3286-fcc695a01eb5@oracle.com>
References: <eb5fd302-ada9-0032-3560-ce8589797ff0@oracle.com>
	<bf339c16-f8c8-a957-753f-13a271d7b60c@oracle.com>
	<7e49d08b-06ba-8a0d-8932-7d82b7db3ee2@oracle.com>
	<832eae6a-481c-28bc-5686-dbdb3cb10770@oracle.com>
	<63249335-46d1-63e0-7942-757c192c4e6c@oracle.com>
	<308b6441-222f-9d85-3286-fcc695a01eb5@oracle.com>
Message-ID: <ecac2276-9b80-ff1b-b2ee-95e8132be922@oracle.com>

On 08.06.16 10:12, Semyon Sadetsky wrote:
> Since method equals() is not specified in the FTP class, you cannot make
> any assumption how it is implemented, it may return true for different
> classes instances. So in the test the policy untouchability should be
> checked by ==, without any additional assumptions about the equals()
> method implementation.

Above I describe that the different instances of the same policy is 
fine, because this is the same policy. Also I do not get it why the 
equals is not specified, you can open specification of Object.equals() 
and read it.

> I know. But this is not needed because it does not produce any valuable
> information for a normal test execution (when it is passed).

Why? It is useful to know what policy is used when the test passed.

>>> That is what I asked. For what purpose this dummy content is added? Can
>>> you clarify that?

This is an emulation of the common dialog used by the application which 
have some components which can be focused inside.


>> By the same reason why JDialog, JWindow and JFrame are added, it
>> increase the coverage if any side affects exists.
> JDialog, JWindow and JFrame are focus traversal cycle roots by default,
> but those "dummy" components are not, i.e. their FTPs are not used and
> are nulls by default.
> So could you point to the code related to the handling of the default
> FTP change, that is additionally covered by the test due to those
> "dummy" components?
>
> --Semyon
>>
>>>>> On 5/30/2016 7:39 PM, Sergey Bylokhov wrote:
>>>>>> Hello.
>>>>>> Please review the fix for jdk9.
>>>>>>
>>>>>> The test DefaultPolicyChange_Swing.java has two issues:
>>>>>>  - It uses invokeLater(), so the test usually pass before the code is
>>>>>> executed on the EDT, because the main thread completes before.
>>>>>>  - The test fetches the FocusTraversalPolicy from the current
>>>>>> KeyboardFocusManager. But default FocusTraversalPolicy can be changed
>>>>>> during the Swing initialization(JDK-7125044). The test should save
>>>>>> the
>>>>>> state before setDefaultFocusTraversalPolicy() but after the Swing
>>>>>> initialization, and validate that the FocusTraversalPolicy was not
>>>>>> changed for windows which were already shown.
>>>>>>
>>>>>> The fix proposed in the CR is applied + small cleanup(regtesthelpers
>>>>>> removed and InvokeAndWait is used instead of InvokeLater+realSync)
>>>>>>
>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8004693
>>>>>> Webrev can be found at:
>>>>>> http://cr.openjdk.java.net/~serb/8004693/webrev.01
>>>>>>
>>>>>
>>>>
>>>>
>>>
>>
>>
>


-- 
Best regards, Sergey.

From Sergey.Bylokhov at oracle.com  Wed Jun  8 15:04:22 2016
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Wed, 8 Jun 2016 18:04:22 +0300
Subject: <AWT Dev> hg: jdk9/client/jdk: 8139218: Dialog that opens and
 closes quickly changes focus in original focusowner
In-Reply-To: <f8346f8c-5609-0629-b37c-2c727b4d1367@oracle.com>
References: <201605311257.u4VCvNuJ013163@aojmv0008.oracle.com>
	<f8346f8c-5609-0629-b37c-2c727b4d1367@oracle.com>
Message-ID: <c6279706-08dd-a1ad-9476-d831de83bbc0@oracle.com>

Please clarify, or revert the fix, or file the new CR.

On 31.05.16 16:31, Sergey Bylokhov wrote:
> I recall that we had a discussion that this fix version should be
> updated to take into account possibility of race of messages, when the
> focus was changed when we run SLoop and after exit we incorrectly clear
> it(we have to check timeout exit). Why it was pushed?
>
> On 31.05.16 15:57, semyon.sadetsky at oracle.com wrote:
>> Changeset: 209dfceab2e3
>> Author:    ssadetsky
>> Date:      2016-05-31 15:57 +0300
>> URL:       http://hg.openjdk.java.net/jdk9/client/jdk/rev/209dfceab2e3
>>
>> 8139218: Dialog that opens and closes quickly changes focus in
>> original focusowner
>> Reviewed-by: alexsch
>>
>> !
>> src/java.desktop/share/classes/java/awt/DefaultKeyboardFocusManager.java
>> +
>> test/java/awt/Focus/RollbackFocusFromAnotherWindowTest/RollbackFocusFromAnotherWindowTest.java
>>
>>
>
>


-- 
Best regards, Sergey.

From semyon.sadetsky at oracle.com  Wed Jun  8 16:53:54 2016
From: semyon.sadetsky at oracle.com (Semyon Sadetsky)
Date: Wed, 8 Jun 2016 19:53:54 +0300
Subject: <AWT Dev> [9] Review Request: 8004693 TEST_BUG:
 java/awt/KeyboardFocusmanager/DefaultPolicyChange/DefaultPolicyChange_Swing.java
 fails
In-Reply-To: <ecac2276-9b80-ff1b-b2ee-95e8132be922@oracle.com>
References: <eb5fd302-ada9-0032-3560-ce8589797ff0@oracle.com>
	<bf339c16-f8c8-a957-753f-13a271d7b60c@oracle.com>
	<7e49d08b-06ba-8a0d-8932-7d82b7db3ee2@oracle.com>
	<832eae6a-481c-28bc-5686-dbdb3cb10770@oracle.com>
	<63249335-46d1-63e0-7942-757c192c4e6c@oracle.com>
	<308b6441-222f-9d85-3286-fcc695a01eb5@oracle.com>
	<ecac2276-9b80-ff1b-b2ee-95e8132be922@oracle.com>
Message-ID: <1312561b-1692-140e-8ddb-90323543cf12@oracle.com>

On 6/8/2016 5:37 PM, Sergey Bylokhov wrote:

> On 08.06.16 10:12, Semyon Sadetsky wrote:
>> Since method equals() is not specified in the FTP class, you cannot make
>> any assumption how it is implemented, it may return true for different
>> classes instances. So in the test the policy untouchability should be
>> checked by ==, without any additional assumptions about the equals()
>> method implementation.
>
> Above I describe that the different instances of the same policy is 
> fine, because this is the same policy. Also I do not get it why the 
> equals is not specified, you can open specification of Object.equals() 
> and read it.
Yes, but the Object#equlas() does not prohibit different class instances 
to be equal. The purpose of the test is to prove that existing 
component's FTP instances remain untouchable during the default FTP 
change regardless of the specific FTP implementation. This may be tested 
only by == operator. Or please provide a scenario when they are allowed 
be replaced by some equivalent FTP's.
>
>> I know. But this is not needed because it does not produce any valuable
>> information for a normal test execution (when it is passed).
>
> Why? It is useful to know what policy is used when the test passed.
Because the main purpose of the test is to automatically compare FTPs, 
so this verbose output is not necessary and this extra printout 
duplicates printout in case the test is failed.
>
>>>> That is what I asked. For what purpose this dummy content is added? 
>>>> Can
>>>> you clarify that?
>
> This is an emulation of the common dialog used by the application 
> which have some components which can be focused inside.
>
>
>>> By the same reason why JDialog, JWindow and JFrame are added, it
>>> increase the coverage if any side affects exists.
>> JDialog, JWindow and JFrame are focus traversal cycle roots by default,
>> but those "dummy" components are not, i.e. their FTPs are not used and
>> are nulls by default.
>> So could you point to the code related to the handling of the default
>> FTP change, that is additionally covered by the test due to those
>> "dummy" components?
Please answer the above question to avoid incoherence in the discussion.
>>
>> --Semyon
>>>
>>>>>> On 5/30/2016 7:39 PM, Sergey Bylokhov wrote:
>>>>>>> Hello.
>>>>>>> Please review the fix for jdk9.
>>>>>>>
>>>>>>> The test DefaultPolicyChange_Swing.java has two issues:
>>>>>>>  - It uses invokeLater(), so the test usually pass before the 
>>>>>>> code is
>>>>>>> executed on the EDT, because the main thread completes before.
>>>>>>>  - The test fetches the FocusTraversalPolicy from the current
>>>>>>> KeyboardFocusManager. But default FocusTraversalPolicy can be 
>>>>>>> changed
>>>>>>> during the Swing initialization(JDK-7125044). The test should save
>>>>>>> the
>>>>>>> state before setDefaultFocusTraversalPolicy() but after the Swing
>>>>>>> initialization, and validate that the FocusTraversalPolicy was not
>>>>>>> changed for windows which were already shown.
>>>>>>>
>>>>>>> The fix proposed in the CR is applied + small 
>>>>>>> cleanup(regtesthelpers
>>>>>>> removed and InvokeAndWait is used instead of InvokeLater+realSync)
>>>>>>>
>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8004693
>>>>>>> Webrev can be found at:
>>>>>>> http://cr.openjdk.java.net/~serb/8004693/webrev.01
>>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>
>>>
>>
>
>


From mandy.chung at oracle.com  Wed Jun  8 19:41:59 2016
From: mandy.chung at oracle.com (Mandy Chung)
Date: Wed, 8 Jun 2016 12:41:59 -0700
Subject: <AWT Dev> Review Request: 8156960 Deprecate
	JSObject.getWindow(Applet) method
In-Reply-To: <1f05a2b9-a68b-4684-a58a-163189c710af@default>
References: <1f05a2b9-a68b-4684-a58a-163189c710af@default>
Message-ID: <FDD6B460-8071-40CA-8FC3-AECF9E0C4ABF@oracle.com>

The client team owns jdk.jsobject module and so I add awt-dev to this thread.  And bcc jdk9-dev.

It is not Java SE API and it should not add to CORE-PKGS.gmk.  As for @Deprecated, I believe the plan is to remove the getWindows method in a future release. Kevin and Dave can confirm.

Mandy

> On Jun 8, 2016, at 12:33 PM, Daniil Titov <daniil.x.titov at oracle.com> wrote:
> 
> Hello,
> 
> 
> 
> Please review the fix for JDK 9.
> 
> 
> 
> The fix adds @Deprecated annotation to netscape.javascript.JSObject.getWindow(Applet) method and ensures that netscape.javascript package is included in the generated docs.
> 
> 
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8156960
> 
> 
> 
> Webrev:   http://cr.openjdk.java.net/~dtitov/8156960/jdk/webrev.00/
> 
>          http://cr.openjdk.java.net/~dtitov/8156960/webrev.00/
> 
> 
> 
> 
> 
> Best regards,
> 
> Daniil


From kevin.rushforth at oracle.com  Wed Jun  8 20:13:38 2016
From: kevin.rushforth at oracle.com (Kevin Rushforth)
Date: Wed, 08 Jun 2016 13:13:38 -0700
Subject: <AWT Dev> Review Request: 8156960 Deprecate
 JSObject.getWindow(Applet) method
In-Reply-To: <FDD6B460-8071-40CA-8FC3-AECF9E0C4ABF@oracle.com>
References: <1f05a2b9-a68b-4684-a58a-163189c710af@default>
	<FDD6B460-8071-40CA-8FC3-AECF9E0C4ABF@oracle.com>
Message-ID: <57587C72.20201@oracle.com>

Yes, the plan is to deprecate it in 9 and remove it in a future release.

-- Kevin


Mandy Chung wrote:
> The client team owns jdk.jsobject module and so I add awt-dev to this thread.  And bcc jdk9-dev.
>
> It is not Java SE API and it should not add to CORE-PKGS.gmk.  As for @Deprecated, I believe the plan is to remove the getWindows method in a future release. Kevin and Dave can confirm.
>
> Mandy
>
>   
>> On Jun 8, 2016, at 12:33 PM, Daniil Titov <daniil.x.titov at oracle.com> wrote:
>>
>> Hello,
>>
>>
>>
>> Please review the fix for JDK 9.
>>
>>
>>
>> The fix adds @Deprecated annotation to netscape.javascript.JSObject.getWindow(Applet) method and ensures that netscape.javascript package is included in the generated docs.
>>
>>
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8156960
>>
>>
>>
>> Webrev:   http://cr.openjdk.java.net/~dtitov/8156960/jdk/webrev.00/
>>
>>          http://cr.openjdk.java.net/~dtitov/8156960/webrev.00/
>>
>>
>>
>>
>>
>> Best regards,
>>
>> Daniil
>>     
>
>   
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20160608/388bb5da/attachment.html>

From david.dehaven at oracle.com  Wed Jun  8 20:18:10 2016
From: david.dehaven at oracle.com (David DeHaven)
Date: Wed, 8 Jun 2016 13:18:10 -0700
Subject: <AWT Dev> Review Request: 8156960 Deprecate
	JSObject.getWindow(Applet) method
In-Reply-To: <57587C72.20201@oracle.com>
References: <1f05a2b9-a68b-4684-a58a-163189c710af@default>
	<FDD6B460-8071-40CA-8FC3-AECF9E0C4ABF@oracle.com>
	<57587C72.20201@oracle.com>
Message-ID: <7804DCC3-CFF3-465D-A9C9-07B16828A119@oracle.com>


Clarification: in a future *as of yet unspecified* release :)

-DrD-

> On Jun 8, 2016, at 1:13 PM, Kevin Rushforth <kevin.rushforth at oracle.com> wrote:
> 
> Yes, the plan is to deprecate it in 9 and remove it in a future release.
> 
> -- Kevin
> 
> 
> Mandy Chung wrote:
>> The client team owns jdk.jsobject module and so I add awt-dev to this thread.  And bcc jdk9-dev.
>> 
>> It is not Java SE API and it should not add to CORE-PKGS.gmk.  As for @Deprecated, I believe the plan is to remove the getWindows method in a future release. Kevin and Dave can confirm.
>> 
>> Mandy
>> 
>>   
>> 
>>> On Jun 8, 2016, at 12:33 PM, Daniil Titov <daniil.x.titov at oracle.com>
>>>  wrote:
>>> 
>>> Hello,
>>> 
>>> 
>>> 
>>> Please review the fix for JDK 9.
>>> 
>>> 
>>> 
>>> The fix adds @Deprecated annotation to netscape.javascript.JSObject.getWindow(Applet) method and ensures that netscape.javascript package is included in the generated docs.
>>> 
>>> 
>>> 
>>> Bug: 
>>> https://bugs.openjdk.java.net/browse/JDK-8156960
>>> 
>>> 
>>> 
>>> 
>>> Webrev:   
>>> http://cr.openjdk.java.net/~dtitov/8156960/jdk/webrev.00/
>>> 
>>> 
>>>          
>>> http://cr.openjdk.java.net/~dtitov/8156960/webrev.00/
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> Best regards,
>>> 
>>> Daniil
>>>     
>>> 
>> 
>>   
>> 


From david.dehaven at oracle.com  Wed Jun  8 20:23:22 2016
From: david.dehaven at oracle.com (David DeHaven)
Date: Wed, 8 Jun 2016 13:23:22 -0700
Subject: <AWT Dev> Review Request: 8156960 Deprecate
	JSObject.getWindow(Applet) method
In-Reply-To: <FDD6B460-8071-40CA-8FC3-AECF9E0C4ABF@oracle.com>
References: <1f05a2b9-a68b-4684-a58a-163189c710af@default>
	<FDD6B460-8071-40CA-8FC3-AECF9E0C4ABF@oracle.com>
Message-ID: <6CB5C96E-8B7F-4093-BA02-94702BA53047@oracle.com>


How about NON_CORE_PKGS.gmk for javadoc?

Something like:

diff --git a/make/common/NON_CORE_PKGS.gmk b/make/common/NON_CORE_PKGS.gmk
--- a/make/common/NON_CORE_PKGS.gmk
+++ b/make/common/NON_CORE_PKGS.gmk
@@ -44,6 +44,8 @@
     org.w3c.dom.events \
     org.w3c.dom.views
 
+JSOBJECT_PKGS = netscape.javascript
+
 JDI_PKGS = com.sun.jdi \
     com.sun.jdi.event \
     com.sun.jdi.request \
@@ -113,6 +115,7 @@
 
 # non-core packages in rt.jar
 NON_CORE_PKGS = $(DOMAPI_PKGS) \
+    $(JSOBJECT_PKGS) \
     $(MGMT_PKGS) \
     $(JAAS_PKGS) \
     $(JGSS_PKGS) \

-DrD-

> The client team owns jdk.jsobject module and so I add awt-dev to this thread.  And bcc jdk9-dev.
> 
> It is not Java SE API and it should not add to CORE-PKGS.gmk.  As for @Deprecated, I believe the plan is to remove the getWindows method in a future release. Kevin and Dave can confirm.
> 
> Mandy
> 
>> On Jun 8, 2016, at 12:33 PM, Daniil Titov <daniil.x.titov at oracle.com> wrote:
>> 
>> Hello,
>> 
>> 
>> 
>> Please review the fix for JDK 9.
>> 
>> 
>> 
>> The fix adds @Deprecated annotation to netscape.javascript.JSObject.getWindow(Applet) method and ensures that netscape.javascript package is included in the generated docs.
>> 
>> 
>> 
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8156960
>> 
>> 
>> 
>> Webrev:   http://cr.openjdk.java.net/~dtitov/8156960/jdk/webrev.00/
>> 
>>         http://cr.openjdk.java.net/~dtitov/8156960/webrev.00/
>> 
>> 
>> 
>> 
>> 
>> Best regards,
>> 
>> Daniil
> 


From david.dehaven at oracle.com  Wed Jun  8 20:25:58 2016
From: david.dehaven at oracle.com (David DeHaven)
Date: Wed, 8 Jun 2016 13:25:58 -0700
Subject: <AWT Dev> Review Request: 8156960 Deprecate
	JSObject.getWindow(Applet) method
In-Reply-To: <6CB5C96E-8B7F-4093-BA02-94702BA53047@oracle.com>
References: <1f05a2b9-a68b-4684-a58a-163189c710af@default>
	<FDD6B460-8071-40CA-8FC3-AECF9E0C4ABF@oracle.com>
	<6CB5C96E-8B7F-4093-BA02-94702BA53047@oracle.com>
Message-ID: <68C3C87E-5787-417B-A37E-925D37F4CAF1@oracle.com>

Sorry, we had LIVECONNECT_PKGS previously...

-DrD-

> How about NON_CORE_PKGS.gmk for javadoc?
> 
> Something like:
> 
> diff --git a/make/common/NON_CORE_PKGS.gmk b/make/common/NON_CORE_PKGS.gmk
> --- a/make/common/NON_CORE_PKGS.gmk
> +++ b/make/common/NON_CORE_PKGS.gmk
> @@ -44,6 +44,8 @@
>     org.w3c.dom.events \
>     org.w3c.dom.views
> 
> +JSOBJECT_PKGS = netscape.javascript
> +
> JDI_PKGS = com.sun.jdi \
>     com.sun.jdi.event \
>     com.sun.jdi.request \
> @@ -113,6 +115,7 @@
> 
> # non-core packages in rt.jar
> NON_CORE_PKGS = $(DOMAPI_PKGS) \
> +    $(JSOBJECT_PKGS) \
>     $(MGMT_PKGS) \
>     $(JAAS_PKGS) \
>     $(JGSS_PKGS) \
> 
> -DrD-
> 
>> The client team owns jdk.jsobject module and so I add awt-dev to this thread.  And bcc jdk9-dev.
>> 
>> It is not Java SE API and it should not add to CORE-PKGS.gmk.  As for @Deprecated, I believe the plan is to remove the getWindows method in a future release. Kevin and Dave can confirm.
>> 
>> Mandy
>> 
>>> On Jun 8, 2016, at 12:33 PM, Daniil Titov <daniil.x.titov at oracle.com> wrote:
>>> 
>>> Hello,
>>> 
>>> 
>>> 
>>> Please review the fix for JDK 9.
>>> 
>>> 
>>> 
>>> The fix adds @Deprecated annotation to netscape.javascript.JSObject.getWindow(Applet) method and ensures that netscape.javascript package is included in the generated docs.
>>> 
>>> 
>>> 
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8156960
>>> 
>>> 
>>> 
>>> Webrev:   http://cr.openjdk.java.net/~dtitov/8156960/jdk/webrev.00/
>>> 
>>>        http://cr.openjdk.java.net/~dtitov/8156960/webrev.00/
>>> 
>>> 
>>> 
>>> 
>>> 
>>> Best regards,
>>> 
>>> Daniil
>> 
> 


From mandy.chung at oracle.com  Wed Jun  8 20:36:39 2016
From: mandy.chung at oracle.com (Mandy Chung)
Date: Wed, 8 Jun 2016 13:36:39 -0700
Subject: <AWT Dev> Review Request: 8156960 Deprecate
	JSObject.getWindow(Applet) method
In-Reply-To: <57587C72.20201@oracle.com>
References: <1f05a2b9-a68b-4684-a58a-163189c710af@default>
	<FDD6B460-8071-40CA-8FC3-AECF9E0C4ABF@oracle.com>
	<57587C72.20201@oracle.com>
Message-ID: <6C1D0A8F-A416-46FC-B479-33DB7F48364B@oracle.com>

Goo.d It should have forRemoval=true in @Deprecated then.

Mandy

> On Jun 8, 2016, at 1:13 PM, Kevin Rushforth <kevin.rushforth at oracle.com> wrote:
> 
> Yes, the plan is to deprecate it in 9 and remove it in a future release.
> 
> -- Kevin
> 
> 
> Mandy Chung wrote:
>> The client team owns jdk.jsobject module and so I add awt-dev to this thread.  And bcc jdk9-dev.
>> 
>> It is not Java SE API and it should not add to CORE-PKGS.gmk.  As for @Deprecated, I believe the plan is to remove the getWindows method in a future release. Kevin and Dave can confirm.
>> 
>> Mandy
>> 
>>   
>> 
>>> On Jun 8, 2016, at 12:33 PM, Daniil Titov <daniil.x.titov at oracle.com>
>>>  wrote:
>>> 
>>> Hello,
>>> 
>>> 
>>> 
>>> Please review the fix for JDK 9.
>>> 
>>> 
>>> 
>>> The fix adds @Deprecated annotation to netscape.javascript.JSObject.getWindow(Applet) method and ensures that netscape.javascript package is included in the generated docs.
>>> 
>>> 
>>> 
>>> Bug: 
>>> https://bugs.openjdk.java.net/browse/JDK-8156960
>>> 
>>> 
>>> 
>>> 
>>> Webrev:   
>>> http://cr.openjdk.java.net/~dtitov/8156960/jdk/webrev.00/
>>> 
>>> 
>>>          
>>> http://cr.openjdk.java.net/~dtitov/8156960/webrev.00/
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> Best regards,
>>> 
>>> Daniil
>>>     
>>> 
>> 
>>   
>> 


From kevin.rushforth at oracle.com  Wed Jun  8 21:09:41 2016
From: kevin.rushforth at oracle.com (Kevin Rushforth)
Date: Wed, 08 Jun 2016 14:09:41 -0700
Subject: <AWT Dev> Review Request: 8156960 Deprecate
 JSObject.getWindow(Applet) method
In-Reply-To: <7804DCC3-CFF3-465D-A9C9-07B16828A119@oracle.com>
References: <1f05a2b9-a68b-4684-a58a-163189c710af@default>
	<FDD6B460-8071-40CA-8FC3-AECF9E0C4ABF@oracle.com>
	<57587C72.20201@oracle.com>
	<7804DCC3-CFF3-465D-A9C9-07B16828A119@oracle.com>
Message-ID: <57588995.3090706@oracle.com>

Yes, exactly.

-- Kevin


David DeHaven wrote:
> Clarification: in a future *as of yet unspecified* release :)
>
> -DrD-
>
>   
>> On Jun 8, 2016, at 1:13 PM, Kevin Rushforth <kevin.rushforth at oracle.com> wrote:
>>
>> Yes, the plan is to deprecate it in 9 and remove it in a future release.
>>
>> -- Kevin
>>
>>
>> Mandy Chung wrote:
>>     
>>> The client team owns jdk.jsobject module and so I add awt-dev to this thread.  And bcc jdk9-dev.
>>>
>>> It is not Java SE API and it should not add to CORE-PKGS.gmk.  As for @Deprecated, I believe the plan is to remove the getWindows method in a future release. Kevin and Dave can confirm.
>>>
>>> Mandy
>>>
>>>   
>>>
>>>       
>>>> On Jun 8, 2016, at 12:33 PM, Daniil Titov <daniil.x.titov at oracle.com>
>>>>  wrote:
>>>>
>>>> Hello,
>>>>
>>>>
>>>>
>>>> Please review the fix for JDK 9.
>>>>
>>>>
>>>>
>>>> The fix adds @Deprecated annotation to netscape.javascript.JSObject.getWindow(Applet) method and ensures that netscape.javascript package is included in the generated docs.
>>>>
>>>>
>>>>
>>>> Bug: 
>>>> https://bugs.openjdk.java.net/browse/JDK-8156960
>>>>
>>>>
>>>>
>>>>
>>>> Webrev:   
>>>> http://cr.openjdk.java.net/~dtitov/8156960/jdk/webrev.00/
>>>>
>>>>
>>>>          
>>>> http://cr.openjdk.java.net/~dtitov/8156960/webrev.00/
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> Best regards,
>>>>
>>>> Daniil
>>>>     
>>>>
>>>>         
>>>   
>>>
>>>       
>
>   
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20160608/30288ad2/attachment.html>

From daniil.x.titov at oracle.com  Wed Jun  8 21:48:19 2016
From: daniil.x.titov at oracle.com (Daniil Titov)
Date: Wed, 8 Jun 2016 14:48:19 -0700 (PDT)
Subject: <AWT Dev> Review Request: 8156960 Deprecate
 JSObject.getWindow(Applet) method
In-Reply-To: <6CB5C96E-8B7F-4093-BA02-94702BA53047@oracle.com>
References: <1f05a2b9-a68b-4684-a58a-163189c710af@default>
	<FDD6B460-8071-40CA-8FC3-AECF9E0C4ABF@oracle.com>
	<6CB5C96E-8B7F-4093-BA02-94702BA53047@oracle.com>
Message-ID: <99907f0c-961d-4d66-950f-9b4de4fc96f7@default>

NON_CORE_PKGS variable is not used in make/Javadoc.gmk, so just adding a new package in this variable will not make this package included in any docs. We will need to create a new javadoc target for JSObject documentation ( or add it to some existing target, but it doesn't look like there is one that fits it). For example:


diff -r 389c2d2842a5 make/Javadoc.gmk
--- a/make/Javadoc.gmk	Wed May 25 12:53:26 2016 +0200
+++ b/make/Javadoc.gmk	Thu Jun 02 16:20:35 2016 -0700
@@ -82,7 +82,7 @@
 PLUGIN2_FIRST_COPYRIGHT_YEAR = 2007
 JDKNET_FIRST_COPYRIGHT_YEAR = 2014
 JACCESSAPI_FIRST_COPYRIGHT_YEAR = 2002
-
+JSOBJECT_FIRST_COPYRIGHT_YEAR = 1993
 
 # Oracle name
 FULL_COMPANY_NAME = Oracle and/or its affiliates
@@ -1031,6 +1031,64 @@
 
 #############################################################
 #
+# jsobjectdocs
+#
+
+ALL_OTHER_TARGETS += jsobjectdoc
+
+JSOBJECT_DOCDIR := $(JRE_API_DOCSDIR)/plugin/jsobject
+JSOBJECT2COREAPI := ../../../$(JDKJRE2COREAPI)
+JSOBJECT_DOCTITLE := Java$(TRADEMARK) JSObject Doc
+JSOBJECT_WINDOWTITLE := Java JSObect Doc
+JSOBJECT_HEADER := <strong>Java JSObject Doc</strong>
+JSOBJECT_BOTTOM := $(call CommonBottom,$(JSOBJECT_FIRST_COPYRIGHT_YEAR))
+# JSOBJECT_PKGS is located in NON_CORE_PKGS.gmk
+
+JSOBJECT_INDEX_HTML = $(JSOBJECT_DOCDIR)/index.html
+JSOBJECT_OPTIONS_FILE = $(DOCSTMPDIR)/jsobject.options
+JSOBJECT_PACKAGES_FILE = $(DOCSTMPDIR)/jsobject.packages
+
+# The modules required to be documented
+JSOBJECT_MODULES = jdk.jsobject
+
+jsobjectdocs: $(JSOBJECT_INDEX_HTML)
+
+# Set relative location to core api document root
+$(JSOBJECT_INDEX_HTML): GET2DOCSDIR=$(JSOBJECT2COREAPI)/..
+
+# Run javadoc if the index file is out of date or missing
+$(JSOBJECT_INDEX_HTML): $(JSOBJECT_OPTIONS_FILE) $(JSOBJECT_PACKAGES_FILE) $(COREAPI_INDEX_FILE)
+	$(prep-javadoc)
+	$(call JavadocSummary,$(JSOBJECT_OPTIONS_FILE),$(JSOBJECT_PACKAGES_FILE))
+	$(JAVADOC_CMD_SMALL) -d $(@D) \
+	    @$(JSOBJECT_OPTIONS_FILE) @$(JSOBJECT_PACKAGES_FILE)
+
+# Create file with javadoc options in it
+$(JSOBJECT_OPTIONS_FILE):
+	$(prep-target)
+	@($(call COMMON_JAVADOCFLAGS) ; \
+          $(call COMMON_JAVADOCTAGS) ; \
+	  $(call OptionOnly,-Xdoclint:none) ; \
+          $(call OptionPair,-system,none) ; \
+	  $(call OptionPair,-modulesourcepath,$(RELEASEDOCS_MODULESOURCEPATH)) ; \
+	  $(call OptionPair,-addmods,$(JSOBJECT_MODULES)) ; \
+	  $(call OptionPair,-encoding,ascii) ; \
+	  $(call OptionOnly,-nodeprecatedlist) ; \
+	  $(call OptionPair,-doctitle,$(JSOBJECT_DOCTITLE)) ; \
+	  $(call OptionPair,-windowtitle,$(JSOBJECT_WINDOWTITLE) $(DRAFT_WINTITLE)); \
+	  $(call OptionPair,-header,$(JSOBJECT_HEADER)$(DRAFT_HEADER)); \
+	  $(call OptionPair,-bottom,$(JSOBJECT_BOTTOM)$(DRAFT_BOTTOM)); \
+	  $(call OptionTrip,-linkoffline,$(JSOBJECT2COREAPI),$(COREAPI_DOCSDIR)/); \
+	) >> $@
+
+# Create a file with the package names in it
+$(JSOBJECT_PACKAGES_FILE): $(call PackageDependencies,$(JSOBJECT_PKGS))
+	$(prep-target)
+	$(call PackageFilter,$(JSOBJECT_PKGS))
+
+
+#############################################################
+#
 # mgmtdocs
 #


Best regards,
Daniil



-----Original Message-----
From: David DeHaven 
Sent: Wednesday, June 08, 2016 1:23 PM
To: Mandy Chung
Cc: Daniil Titov; Stuart Marks; Erik Joelsson; build-dev; build-infa-dev at openjdk.java.net; awt-dev; Kevin Rushforth
Subject: Re: Review Request: 8156960 Deprecate JSObject.getWindow(Applet) method


How about NON_CORE_PKGS.gmk for javadoc?

Something like:

diff --git a/make/common/NON_CORE_PKGS.gmk b/make/common/NON_CORE_PKGS.gmk
--- a/make/common/NON_CORE_PKGS.gmk
+++ b/make/common/NON_CORE_PKGS.gmk
@@ -44,6 +44,8 @@
     org.w3c.dom.events \
     org.w3c.dom.views
 
+JSOBJECT_PKGS = netscape.javascript
+
 JDI_PKGS = com.sun.jdi \
     com.sun.jdi.event \
     com.sun.jdi.request \
@@ -113,6 +115,7 @@
 
 # non-core packages in rt.jar
 NON_CORE_PKGS = $(DOMAPI_PKGS) \
+    $(JSOBJECT_PKGS) \
     $(MGMT_PKGS) \
     $(JAAS_PKGS) \
     $(JGSS_PKGS) \

-DrD-

> The client team owns jdk.jsobject module and so I add awt-dev to this thread.  And bcc jdk9-dev.
> 
> It is not Java SE API and it should not add to CORE-PKGS.gmk.  As for @Deprecated, I believe the plan is to remove the getWindows method in a future release. Kevin and Dave can confirm.
> 
> Mandy
> 
>> On Jun 8, 2016, at 12:33 PM, Daniil Titov <daniil.x.titov at oracle.com> wrote:
>> 
>> Hello,
>> 
>> 
>> 
>> Please review the fix for JDK 9.
>> 
>> 
>> 
>> The fix adds @Deprecated annotation to netscape.javascript.JSObject.getWindow(Applet) method and ensures that netscape.javascript package is included in the generated docs.
>> 
>> 
>> 
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8156960
>> 
>> 
>> 
>> Webrev:   http://cr.openjdk.java.net/~dtitov/8156960/jdk/webrev.00/
>> 
>>         http://cr.openjdk.java.net/~dtitov/8156960/webrev.00/
>> 
>> 
>> 
>> 
>> 
>> Best regards,
>> 
>> Daniil
> 


From mandy.chung at oracle.com  Wed Jun  8 22:08:37 2016
From: mandy.chung at oracle.com (Mandy Chung)
Date: Wed, 8 Jun 2016 15:08:37 -0700
Subject: <AWT Dev> Review Request: 8156960 Deprecate
	JSObject.getWindow(Applet) method
In-Reply-To: <99907f0c-961d-4d66-950f-9b4de4fc96f7@default>
References: <1f05a2b9-a68b-4684-a58a-163189c710af@default>
	<FDD6B460-8071-40CA-8FC3-AECF9E0C4ABF@oracle.com>
	<6CB5C96E-8B7F-4093-BA02-94702BA53047@oracle.com>
	<99907f0c-961d-4d66-950f-9b4de4fc96f7@default>
Message-ID: <EAF37B66-F1D5-44D0-82AB-DFB4120AB8E4@oracle.com>

That?s right.  It requires to add a new doc bundle in the docs build.  What you did was the right direction.  Can you update the webrev?

FYI.  There is an effort under discussion to revisit the number of docs bundle generated and clean up the docs build.

Mandy

> On Jun 8, 2016, at 2:48 PM, Daniil Titov <daniil.x.titov at oracle.com> wrote:
> 
> NON_CORE_PKGS variable is not used in make/Javadoc.gmk, so just adding a new package in this variable will not make this package included in any docs. We will need to create a new javadoc target for JSObject documentation ( or add it to some existing target, but it doesn't look like there is one that fits it). For example:
> 
> 
> diff -r 389c2d2842a5 make/Javadoc.gmk
> --- a/make/Javadoc.gmk	Wed May 25 12:53:26 2016 +0200
> +++ b/make/Javadoc.gmk	Thu Jun 02 16:20:35 2016 -0700
> @@ -82,7 +82,7 @@
> PLUGIN2_FIRST_COPYRIGHT_YEAR = 2007
> JDKNET_FIRST_COPYRIGHT_YEAR = 2014
> JACCESSAPI_FIRST_COPYRIGHT_YEAR = 2002
> -
> +JSOBJECT_FIRST_COPYRIGHT_YEAR = 1993
> 
> # Oracle name
> FULL_COMPANY_NAME = Oracle and/or its affiliates
> @@ -1031,6 +1031,64 @@
> 
> #############################################################
> #
> +# jsobjectdocs
> +#
> +
> +ALL_OTHER_TARGETS += jsobjectdoc
> +
> +JSOBJECT_DOCDIR := $(JRE_API_DOCSDIR)/plugin/jsobject
> +JSOBJECT2COREAPI := ../../../$(JDKJRE2COREAPI)
> +JSOBJECT_DOCTITLE := Java$(TRADEMARK) JSObject Doc
> +JSOBJECT_WINDOWTITLE := Java JSObect Doc
> +JSOBJECT_HEADER := <strong>Java JSObject Doc</strong>
> +JSOBJECT_BOTTOM := $(call CommonBottom,$(JSOBJECT_FIRST_COPYRIGHT_YEAR))
> +# JSOBJECT_PKGS is located in NON_CORE_PKGS.gmk
> +
> +JSOBJECT_INDEX_HTML = $(JSOBJECT_DOCDIR)/index.html
> +JSOBJECT_OPTIONS_FILE = $(DOCSTMPDIR)/jsobject.options
> +JSOBJECT_PACKAGES_FILE = $(DOCSTMPDIR)/jsobject.packages
> +
> +# The modules required to be documented
> +JSOBJECT_MODULES = jdk.jsobject
> +
> +jsobjectdocs: $(JSOBJECT_INDEX_HTML)
> +
> +# Set relative location to core api document root
> +$(JSOBJECT_INDEX_HTML): GET2DOCSDIR=$(JSOBJECT2COREAPI)/..
> +
> +# Run javadoc if the index file is out of date or missing
> +$(JSOBJECT_INDEX_HTML): $(JSOBJECT_OPTIONS_FILE) $(JSOBJECT_PACKAGES_FILE) $(COREAPI_INDEX_FILE)
> +	$(prep-javadoc)
> +	$(call JavadocSummary,$(JSOBJECT_OPTIONS_FILE),$(JSOBJECT_PACKAGES_FILE))
> +	$(JAVADOC_CMD_SMALL) -d $(@D) \
> +	    @$(JSOBJECT_OPTIONS_FILE) @$(JSOBJECT_PACKAGES_FILE)
> +
> +# Create file with javadoc options in it
> +$(JSOBJECT_OPTIONS_FILE):
> +	$(prep-target)
> +	@($(call COMMON_JAVADOCFLAGS) ; \
> +          $(call COMMON_JAVADOCTAGS) ; \
> +	  $(call OptionOnly,-Xdoclint:none) ; \
> +          $(call OptionPair,-system,none) ; \
> +	  $(call OptionPair,-modulesourcepath,$(RELEASEDOCS_MODULESOURCEPATH)) ; \
> +	  $(call OptionPair,-addmods,$(JSOBJECT_MODULES)) ; \
> +	  $(call OptionPair,-encoding,ascii) ; \
> +	  $(call OptionOnly,-nodeprecatedlist) ; \
> +	  $(call OptionPair,-doctitle,$(JSOBJECT_DOCTITLE)) ; \
> +	  $(call OptionPair,-windowtitle,$(JSOBJECT_WINDOWTITLE) $(DRAFT_WINTITLE)); \
> +	  $(call OptionPair,-header,$(JSOBJECT_HEADER)$(DRAFT_HEADER)); \
> +	  $(call OptionPair,-bottom,$(JSOBJECT_BOTTOM)$(DRAFT_BOTTOM)); \
> +	  $(call OptionTrip,-linkoffline,$(JSOBJECT2COREAPI),$(COREAPI_DOCSDIR)/); \
> +	) >> $@
> +
> +# Create a file with the package names in it
> +$(JSOBJECT_PACKAGES_FILE): $(call PackageDependencies,$(JSOBJECT_PKGS))
> +	$(prep-target)
> +	$(call PackageFilter,$(JSOBJECT_PKGS))
> +
> +
> +#############################################################
> +#
> # mgmtdocs
> #
> 
> 
> Best regards,
> Daniil
> 
> 
> 
> -----Original Message-----
> From: David DeHaven 
> Sent: Wednesday, June 08, 2016 1:23 PM
> To: Mandy Chung
> Cc: Daniil Titov; Stuart Marks; Erik Joelsson; build-dev; build-infa-dev at openjdk.java.net; awt-dev; Kevin Rushforth
> Subject: Re: Review Request: 8156960 Deprecate JSObject.getWindow(Applet) method
> 
> 
> How about NON_CORE_PKGS.gmk for javadoc?
> 
> Something like:
> 
> diff --git a/make/common/NON_CORE_PKGS.gmk b/make/common/NON_CORE_PKGS.gmk
> --- a/make/common/NON_CORE_PKGS.gmk
> +++ b/make/common/NON_CORE_PKGS.gmk
> @@ -44,6 +44,8 @@
>     org.w3c.dom.events \
>     org.w3c.dom.views
> 
> +JSOBJECT_PKGS = netscape.javascript
> +
> JDI_PKGS = com.sun.jdi \
>     com.sun.jdi.event \
>     com.sun.jdi.request \
> @@ -113,6 +115,7 @@
> 
> # non-core packages in rt.jar
> NON_CORE_PKGS = $(DOMAPI_PKGS) \
> +    $(JSOBJECT_PKGS) \
>     $(MGMT_PKGS) \
>     $(JAAS_PKGS) \
>     $(JGSS_PKGS) \
> 
> -DrD-
> 
>> The client team owns jdk.jsobject module and so I add awt-dev to this thread.  And bcc jdk9-dev.
>> 
>> It is not Java SE API and it should not add to CORE-PKGS.gmk.  As for @Deprecated, I believe the plan is to remove the getWindows method in a future release. Kevin and Dave can confirm.
>> 
>> Mandy
>> 
>>> On Jun 8, 2016, at 12:33 PM, Daniil Titov <daniil.x.titov at oracle.com> wrote:
>>> 
>>> Hello,
>>> 
>>> 
>>> 
>>> Please review the fix for JDK 9.
>>> 
>>> 
>>> 
>>> The fix adds @Deprecated annotation to netscape.javascript.JSObject.getWindow(Applet) method and ensures that netscape.javascript package is included in the generated docs.
>>> 
>>> 
>>> 
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8156960
>>> 
>>> 
>>> 
>>> Webrev:   http://cr.openjdk.java.net/~dtitov/8156960/jdk/webrev.00/
>>> 
>>>        http://cr.openjdk.java.net/~dtitov/8156960/webrev.00/
>>> 
>>> 
>>> 
>>> 
>>> 
>>> Best regards,
>>> 
>>> Daniil
>> 
> 


From daniil.x.titov at oracle.com  Thu Jun  9 00:34:48 2016
From: daniil.x.titov at oracle.com (Daniil Titov)
Date: Wed, 8 Jun 2016 17:34:48 -0700 (PDT)
Subject: <AWT Dev> Review Request: 8156960 Deprecate
 JSObject.getWindow(Applet) method
In-Reply-To: <EAF37B66-F1D5-44D0-82AB-DFB4120AB8E4@oracle.com>
References: <1f05a2b9-a68b-4684-a58a-163189c710af@default>
	<FDD6B460-8071-40CA-8FC3-AECF9E0C4ABF@oracle.com>
	<6CB5C96E-8B7F-4093-BA02-94702BA53047@oracle.com>
	<99907f0c-961d-4d66-950f-9b4de4fc96f7@default>
	<EAF37B66-F1D5-44D0-82AB-DFB4120AB8E4@oracle.com>
Message-ID: <61539153-a0c6-474d-aded-d34b6266a1c1@default>

Hello,

Please review the new version of the fix for JDK9.

1. "forRemoval = true" is added to @Deprecated annotation for JSObject.getWindow(Applet) method.
2.  A new doc bundle for JSObject documentation is added in the docs build.

Webrev: http://cr.openjdk.java.net/~dtitov/8156960/jdk/webrev.01
        http://cr.openjdk.java.net/~dtitov/8156960/webrev.01


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

Thank you!

Best regards,
Daniil

-----Original Message-----
From: Mandy Chung 
Sent: Wednesday, June 08, 2016 3:09 PM
To: Daniil Titov
Cc: David Dehaven; Stuart Marks; Erik Joelsson; build-dev; build-infa-dev at openjdk.java.net; awt-dev; Kevin Rushforth
Subject: Re: Review Request: 8156960 Deprecate JSObject.getWindow(Applet) method

That?s right.  It requires to add a new doc bundle in the docs build.  What you did was the right direction.  Can you update the webrev?

FYI.  There is an effort under discussion to revisit the number of docs bundle generated and clean up the docs build.

Mandy

> On Jun 8, 2016, at 2:48 PM, Daniil Titov <daniil.x.titov at oracle.com> wrote:
> 
> NON_CORE_PKGS variable is not used in make/Javadoc.gmk, so just adding a new package in this variable will not make this package included in any docs. We will need to create a new javadoc target for JSObject documentation ( or add it to some existing target, but it doesn't look like there is one that fits it). For example:
> 
> 
> diff -r 389c2d2842a5 make/Javadoc.gmk
> --- a/make/Javadoc.gmk	Wed May 25 12:53:26 2016 +0200
> +++ b/make/Javadoc.gmk	Thu Jun 02 16:20:35 2016 -0700
> @@ -82,7 +82,7 @@
> PLUGIN2_FIRST_COPYRIGHT_YEAR = 2007
> JDKNET_FIRST_COPYRIGHT_YEAR = 2014
> JACCESSAPI_FIRST_COPYRIGHT_YEAR = 2002
> -
> +JSOBJECT_FIRST_COPYRIGHT_YEAR = 1993
> 
> # Oracle name
> FULL_COMPANY_NAME = Oracle and/or its affiliates @@ -1031,6 +1031,64 
> @@
> 
> #############################################################
> #
> +# jsobjectdocs
> +#
> +
> +ALL_OTHER_TARGETS += jsobjectdoc
> +
> +JSOBJECT_DOCDIR := $(JRE_API_DOCSDIR)/plugin/jsobject
> +JSOBJECT2COREAPI := ../../../$(JDKJRE2COREAPI) JSOBJECT_DOCTITLE := 
> +Java$(TRADEMARK) JSObject Doc JSOBJECT_WINDOWTITLE := Java JSObect 
> +Doc JSOBJECT_HEADER := <strong>Java JSObject Doc</strong> 
> +JSOBJECT_BOTTOM := $(call 
> +CommonBottom,$(JSOBJECT_FIRST_COPYRIGHT_YEAR))
> +# JSOBJECT_PKGS is located in NON_CORE_PKGS.gmk
> +
> +JSOBJECT_INDEX_HTML = $(JSOBJECT_DOCDIR)/index.html 
> +JSOBJECT_OPTIONS_FILE = $(DOCSTMPDIR)/jsobject.options 
> +JSOBJECT_PACKAGES_FILE = $(DOCSTMPDIR)/jsobject.packages
> +
> +# The modules required to be documented JSOBJECT_MODULES = 
> +jdk.jsobject
> +
> +jsobjectdocs: $(JSOBJECT_INDEX_HTML)
> +
> +# Set relative location to core api document root
> +$(JSOBJECT_INDEX_HTML): GET2DOCSDIR=$(JSOBJECT2COREAPI)/..
> +
> +# Run javadoc if the index file is out of date or missing
> +$(JSOBJECT_INDEX_HTML): $(JSOBJECT_OPTIONS_FILE) $(JSOBJECT_PACKAGES_FILE) $(COREAPI_INDEX_FILE)
> +	$(prep-javadoc)
> +	$(call JavadocSummary,$(JSOBJECT_OPTIONS_FILE),$(JSOBJECT_PACKAGES_FILE))
> +	$(JAVADOC_CMD_SMALL) -d $(@D) \
> +	    @$(JSOBJECT_OPTIONS_FILE) @$(JSOBJECT_PACKAGES_FILE)
> +
> +# Create file with javadoc options in it
> +$(JSOBJECT_OPTIONS_FILE):
> +	$(prep-target)
> +	@($(call COMMON_JAVADOCFLAGS) ; \
> +          $(call COMMON_JAVADOCTAGS) ; \
> +	  $(call OptionOnly,-Xdoclint:none) ; \
> +          $(call OptionPair,-system,none) ; \
> +	  $(call OptionPair,-modulesourcepath,$(RELEASEDOCS_MODULESOURCEPATH)) ; \
> +	  $(call OptionPair,-addmods,$(JSOBJECT_MODULES)) ; \
> +	  $(call OptionPair,-encoding,ascii) ; \
> +	  $(call OptionOnly,-nodeprecatedlist) ; \
> +	  $(call OptionPair,-doctitle,$(JSOBJECT_DOCTITLE)) ; \
> +	  $(call OptionPair,-windowtitle,$(JSOBJECT_WINDOWTITLE) $(DRAFT_WINTITLE)); \
> +	  $(call OptionPair,-header,$(JSOBJECT_HEADER)$(DRAFT_HEADER)); \
> +	  $(call OptionPair,-bottom,$(JSOBJECT_BOTTOM)$(DRAFT_BOTTOM)); \
> +	  $(call OptionTrip,-linkoffline,$(JSOBJECT2COREAPI),$(COREAPI_DOCSDIR)/); \
> +	) >> $@
> +
> +# Create a file with the package names in it
> +$(JSOBJECT_PACKAGES_FILE): $(call PackageDependencies,$(JSOBJECT_PKGS))
> +	$(prep-target)
> +	$(call PackageFilter,$(JSOBJECT_PKGS))
> +
> +
> +#############################################################
> +#
> # mgmtdocs
> #
> 
> 
> Best regards,
> Daniil
> 
> 
> 
> -----Original Message-----
> From: David DeHaven
> Sent: Wednesday, June 08, 2016 1:23 PM
> To: Mandy Chung
> Cc: Daniil Titov; Stuart Marks; Erik Joelsson; build-dev; 
> build-infa-dev at openjdk.java.net; awt-dev; Kevin Rushforth
> Subject: Re: Review Request: 8156960 Deprecate 
> JSObject.getWindow(Applet) method
> 
> 
> How about NON_CORE_PKGS.gmk for javadoc?
> 
> Something like:
> 
> diff --git a/make/common/NON_CORE_PKGS.gmk 
> b/make/common/NON_CORE_PKGS.gmk
> --- a/make/common/NON_CORE_PKGS.gmk
> +++ b/make/common/NON_CORE_PKGS.gmk
> @@ -44,6 +44,8 @@
>     org.w3c.dom.events \
>     org.w3c.dom.views
> 
> +JSOBJECT_PKGS = netscape.javascript
> +
> JDI_PKGS = com.sun.jdi \
>     com.sun.jdi.event \
>     com.sun.jdi.request \
> @@ -113,6 +115,7 @@
> 
> # non-core packages in rt.jar
> NON_CORE_PKGS = $(DOMAPI_PKGS) \
> +    $(JSOBJECT_PKGS) \
>     $(MGMT_PKGS) \
>     $(JAAS_PKGS) \
>     $(JGSS_PKGS) \
> 
> -DrD-
> 
>> The client team owns jdk.jsobject module and so I add awt-dev to this thread.  And bcc jdk9-dev.
>> 
>> It is not Java SE API and it should not add to CORE-PKGS.gmk.  As for @Deprecated, I believe the plan is to remove the getWindows method in a future release. Kevin and Dave can confirm.
>> 
>> Mandy
>> 
>>> On Jun 8, 2016, at 12:33 PM, Daniil Titov <daniil.x.titov at oracle.com> wrote:
>>> 
>>> Hello,
>>> 
>>> 
>>> 
>>> Please review the fix for JDK 9.
>>> 
>>> 
>>> 
>>> The fix adds @Deprecated annotation to netscape.javascript.JSObject.getWindow(Applet) method and ensures that netscape.javascript package is included in the generated docs.
>>> 
>>> 
>>> 
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8156960
>>> 
>>> 
>>> 
>>> Webrev:   http://cr.openjdk.java.net/~dtitov/8156960/jdk/webrev.00/
>>> 
>>>        http://cr.openjdk.java.net/~dtitov/8156960/webrev.00/
>>> 
>>> 
>>> 
>>> 
>>> 
>>> Best regards,
>>> 
>>> Daniil
>> 
> 


From erik.joelsson at oracle.com  Thu Jun  9 07:33:55 2016
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Thu, 9 Jun 2016 09:33:55 +0200
Subject: <AWT Dev> Review Request: 8156960 Deprecate
 JSObject.getWindow(Applet) method
In-Reply-To: <61539153-a0c6-474d-aded-d34b6266a1c1@default>
References: <1f05a2b9-a68b-4684-a58a-163189c710af@default>
	<FDD6B460-8071-40CA-8FC3-AECF9E0C4ABF@oracle.com>
	<6CB5C96E-8B7F-4093-BA02-94702BA53047@oracle.com>
	<99907f0c-961d-4d66-950f-9b4de4fc96f7@default>
	<EAF37B66-F1D5-44D0-82AB-DFB4120AB8E4@oracle.com>
	<61539153-a0c6-474d-aded-d34b6266a1c1@default>
Message-ID: <57591BE3.5060003@oracle.com>

Hello,

Generally looks good, but I do think this needs to be changed:

JSOBJECT_DOCDIR := $(JRE_API_DOCSDIR)/plugin/jsobject
JSOBJECT2COREAPI := ../../../$(JDKJRE2COREAPI)

The number of ../ should probably match the directory level depth of the 
variable before it, at least it looks that way for the other setups:

JSOBJECT2COREAPI := ../../$(JDKJRE2COREAPI)

/Erik

On 2016-06-09 02:34, Daniil Titov wrote:
> Hello,
>
> Please review the new version of the fix for JDK9.
>
> 1. "forRemoval = true" is added to @Deprecated annotation for JSObject.getWindow(Applet) method.
> 2.  A new doc bundle for JSObject documentation is added in the docs build.
>
> Webrev: http://cr.openjdk.java.net/~dtitov/8156960/jdk/webrev.01
>          http://cr.openjdk.java.net/~dtitov/8156960/webrev.01
>
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8156960
>
> Thank you!
>
> Best regards,
> Daniil
>
> -----Original Message-----
> From: Mandy Chung
> Sent: Wednesday, June 08, 2016 3:09 PM
> To: Daniil Titov
> Cc: David Dehaven; Stuart Marks; Erik Joelsson; build-dev; build-infa-dev at openjdk.java.net; awt-dev; Kevin Rushforth
> Subject: Re: Review Request: 8156960 Deprecate JSObject.getWindow(Applet) method
>
> That?s right.  It requires to add a new doc bundle in the docs build.  What you did was the right direction.  Can you update the webrev?
>
> FYI.  There is an effort under discussion to revisit the number of docs bundle generated and clean up the docs build.
>
> Mandy
>
>> On Jun 8, 2016, at 2:48 PM, Daniil Titov <daniil.x.titov at oracle.com> wrote:
>>
>> NON_CORE_PKGS variable is not used in make/Javadoc.gmk, so just adding a new package in this variable will not make this package included in any docs. We will need to create a new javadoc target for JSObject documentation ( or add it to some existing target, but it doesn't look like there is one that fits it). For example:
>>
>>
>> diff -r 389c2d2842a5 make/Javadoc.gmk
>> --- a/make/Javadoc.gmk	Wed May 25 12:53:26 2016 +0200
>> +++ b/make/Javadoc.gmk	Thu Jun 02 16:20:35 2016 -0700
>> @@ -82,7 +82,7 @@
>> PLUGIN2_FIRST_COPYRIGHT_YEAR = 2007
>> JDKNET_FIRST_COPYRIGHT_YEAR = 2014
>> JACCESSAPI_FIRST_COPYRIGHT_YEAR = 2002
>> -
>> +JSOBJECT_FIRST_COPYRIGHT_YEAR = 1993
>>
>> # Oracle name
>> FULL_COMPANY_NAME = Oracle and/or its affiliates @@ -1031,6 +1031,64
>> @@
>>
>> #############################################################
>> #
>> +# jsobjectdocs
>> +#
>> +
>> +ALL_OTHER_TARGETS += jsobjectdoc
>> +
>> +JSOBJECT_DOCDIR := $(JRE_API_DOCSDIR)/plugin/jsobject
>> +JSOBJECT2COREAPI := ../../../$(JDKJRE2COREAPI) JSOBJECT_DOCTITLE :=
>> +Java$(TRADEMARK) JSObject Doc JSOBJECT_WINDOWTITLE := Java JSObect
>> +Doc JSOBJECT_HEADER := <strong>Java JSObject Doc</strong>
>> +JSOBJECT_BOTTOM := $(call
>> +CommonBottom,$(JSOBJECT_FIRST_COPYRIGHT_YEAR))
>> +# JSOBJECT_PKGS is located in NON_CORE_PKGS.gmk
>> +
>> +JSOBJECT_INDEX_HTML = $(JSOBJECT_DOCDIR)/index.html
>> +JSOBJECT_OPTIONS_FILE = $(DOCSTMPDIR)/jsobject.options
>> +JSOBJECT_PACKAGES_FILE = $(DOCSTMPDIR)/jsobject.packages
>> +
>> +# The modules required to be documented JSOBJECT_MODULES =
>> +jdk.jsobject
>> +
>> +jsobjectdocs: $(JSOBJECT_INDEX_HTML)
>> +
>> +# Set relative location to core api document root
>> +$(JSOBJECT_INDEX_HTML): GET2DOCSDIR=$(JSOBJECT2COREAPI)/..
>> +
>> +# Run javadoc if the index file is out of date or missing
>> +$(JSOBJECT_INDEX_HTML): $(JSOBJECT_OPTIONS_FILE) $(JSOBJECT_PACKAGES_FILE) $(COREAPI_INDEX_FILE)
>> +	$(prep-javadoc)
>> +	$(call JavadocSummary,$(JSOBJECT_OPTIONS_FILE),$(JSOBJECT_PACKAGES_FILE))
>> +	$(JAVADOC_CMD_SMALL) -d $(@D) \
>> +	    @$(JSOBJECT_OPTIONS_FILE) @$(JSOBJECT_PACKAGES_FILE)
>> +
>> +# Create file with javadoc options in it
>> +$(JSOBJECT_OPTIONS_FILE):
>> +	$(prep-target)
>> +	@($(call COMMON_JAVADOCFLAGS) ; \
>> +          $(call COMMON_JAVADOCTAGS) ; \
>> +	  $(call OptionOnly,-Xdoclint:none) ; \
>> +          $(call OptionPair,-system,none) ; \
>> +	  $(call OptionPair,-modulesourcepath,$(RELEASEDOCS_MODULESOURCEPATH)) ; \
>> +	  $(call OptionPair,-addmods,$(JSOBJECT_MODULES)) ; \
>> +	  $(call OptionPair,-encoding,ascii) ; \
>> +	  $(call OptionOnly,-nodeprecatedlist) ; \
>> +	  $(call OptionPair,-doctitle,$(JSOBJECT_DOCTITLE)) ; \
>> +	  $(call OptionPair,-windowtitle,$(JSOBJECT_WINDOWTITLE) $(DRAFT_WINTITLE)); \
>> +	  $(call OptionPair,-header,$(JSOBJECT_HEADER)$(DRAFT_HEADER)); \
>> +	  $(call OptionPair,-bottom,$(JSOBJECT_BOTTOM)$(DRAFT_BOTTOM)); \
>> +	  $(call OptionTrip,-linkoffline,$(JSOBJECT2COREAPI),$(COREAPI_DOCSDIR)/); \
>> +	) >> $@
>> +
>> +# Create a file with the package names in it
>> +$(JSOBJECT_PACKAGES_FILE): $(call PackageDependencies,$(JSOBJECT_PKGS))
>> +	$(prep-target)
>> +	$(call PackageFilter,$(JSOBJECT_PKGS))
>> +
>> +
>> +#############################################################
>> +#
>> # mgmtdocs
>> #
>>
>>
>> Best regards,
>> Daniil
>>
>>
>>
>> -----Original Message-----
>> From: David DeHaven
>> Sent: Wednesday, June 08, 2016 1:23 PM
>> To: Mandy Chung
>> Cc: Daniil Titov; Stuart Marks; Erik Joelsson; build-dev;
>> build-infa-dev at openjdk.java.net; awt-dev; Kevin Rushforth
>> Subject: Re: Review Request: 8156960 Deprecate
>> JSObject.getWindow(Applet) method
>>
>>
>> How about NON_CORE_PKGS.gmk for javadoc?
>>
>> Something like:
>>
>> diff --git a/make/common/NON_CORE_PKGS.gmk
>> b/make/common/NON_CORE_PKGS.gmk
>> --- a/make/common/NON_CORE_PKGS.gmk
>> +++ b/make/common/NON_CORE_PKGS.gmk
>> @@ -44,6 +44,8 @@
>>      org.w3c.dom.events \
>>      org.w3c.dom.views
>>
>> +JSOBJECT_PKGS = netscape.javascript
>> +
>> JDI_PKGS = com.sun.jdi \
>>      com.sun.jdi.event \
>>      com.sun.jdi.request \
>> @@ -113,6 +115,7 @@
>>
>> # non-core packages in rt.jar
>> NON_CORE_PKGS = $(DOMAPI_PKGS) \
>> +    $(JSOBJECT_PKGS) \
>>      $(MGMT_PKGS) \
>>      $(JAAS_PKGS) \
>>      $(JGSS_PKGS) \
>>
>> -DrD-
>>
>>> The client team owns jdk.jsobject module and so I add awt-dev to this thread.  And bcc jdk9-dev.
>>>
>>> It is not Java SE API and it should not add to CORE-PKGS.gmk.  As for @Deprecated, I believe the plan is to remove the getWindows method in a future release. Kevin and Dave can confirm.
>>>
>>> Mandy
>>>
>>>> On Jun 8, 2016, at 12:33 PM, Daniil Titov <daniil.x.titov at oracle.com> wrote:
>>>>
>>>> Hello,
>>>>
>>>>
>>>>
>>>> Please review the fix for JDK 9.
>>>>
>>>>
>>>>
>>>> The fix adds @Deprecated annotation to netscape.javascript.JSObject.getWindow(Applet) method and ensures that netscape.javascript package is included in the generated docs.
>>>>
>>>>
>>>>
>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8156960
>>>>
>>>>
>>>>
>>>> Webrev:   http://cr.openjdk.java.net/~dtitov/8156960/jdk/webrev.00/
>>>>
>>>>         http://cr.openjdk.java.net/~dtitov/8156960/webrev.00/
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> Best regards,
>>>>
>>>> Daniil


From Sergey.Bylokhov at oracle.com  Thu Jun  9 09:37:59 2016
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Thu, 9 Jun 2016 12:37:59 +0300
Subject: <AWT Dev> [9] Review Request: 8004693 TEST_BUG:
 java/awt/KeyboardFocusmanager/DefaultPolicyChange/DefaultPolicyChange_Swing.java
 fails
In-Reply-To: <1312561b-1692-140e-8ddb-90323543cf12@oracle.com>
References: <eb5fd302-ada9-0032-3560-ce8589797ff0@oracle.com>
	<bf339c16-f8c8-a957-753f-13a271d7b60c@oracle.com>
	<7e49d08b-06ba-8a0d-8932-7d82b7db3ee2@oracle.com>
	<832eae6a-481c-28bc-5686-dbdb3cb10770@oracle.com>
	<63249335-46d1-63e0-7942-757c192c4e6c@oracle.com>
	<308b6441-222f-9d85-3286-fcc695a01eb5@oracle.com>
	<ecac2276-9b80-ff1b-b2ee-95e8132be922@oracle.com>
	<1312561b-1692-140e-8ddb-90323543cf12@oracle.com>
Message-ID: <2bec697e-5fc4-8887-3511-9bb91e330f17@oracle.com>

On 08.06.16 19:53, Semyon Sadetsky wrote:
> Yes, but the Object#equlas() does not prohibit different class instances
> to be equal. The purpose of the test is to prove that existing
> component's FTP instances remain untouchable during the default FTP
> change regardless of the specific FTP implementation. This may be tested
> only by == operator. Or please provide a scenario when they are allowed
> be replaced by some equivalent FTP's.

For our policies the different instances will be different because   our 
classes do not override equals. If we override at some point the equal 
for our public classes then we will consider the different instances as 
the same policy. Do you have some other comments?

>> Why? It is useful to know what policy is used when the test passed.
> Because the main purpose of the test is to automatically compare FTPs,
> so this verbose output is not necessary and this extra printout
> duplicates printout in case the test is failed.

The author of the test and the author of this fix, consider this output 
useful. Do you have some other comments?

> Please answer the above question to avoid incoherence in the discussion.

I already asked your question, "This is an emulation of the common 
dialog used by the application which have some components inside which 
can be focused". Do you have some other comments?


>>>
>>> --Semyon
>>>>
>>>>>>> On 5/30/2016 7:39 PM, Sergey Bylokhov wrote:
>>>>>>>> Hello.
>>>>>>>> Please review the fix for jdk9.
>>>>>>>>
>>>>>>>> The test DefaultPolicyChange_Swing.java has two issues:
>>>>>>>>  - It uses invokeLater(), so the test usually pass before the
>>>>>>>> code is
>>>>>>>> executed on the EDT, because the main thread completes before.
>>>>>>>>  - The test fetches the FocusTraversalPolicy from the current
>>>>>>>> KeyboardFocusManager. But default FocusTraversalPolicy can be
>>>>>>>> changed
>>>>>>>> during the Swing initialization(JDK-7125044). The test should save
>>>>>>>> the
>>>>>>>> state before setDefaultFocusTraversalPolicy() but after the Swing
>>>>>>>> initialization, and validate that the FocusTraversalPolicy was not
>>>>>>>> changed for windows which were already shown.
>>>>>>>>
>>>>>>>> The fix proposed in the CR is applied + small
>>>>>>>> cleanup(regtesthelpers
>>>>>>>> removed and InvokeAndWait is used instead of InvokeLater+realSync)
>>>>>>>>
>>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8004693
>>>>>>>> Webrev can be found at:
>>>>>>>> http://cr.openjdk.java.net/~serb/8004693/webrev.01
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>
>>>>
>>>
>>
>>
>


-- 
Best regards, Sergey.

From Sergey.Bylokhov at oracle.com  Thu Jun  9 09:43:51 2016
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Thu, 9 Jun 2016 12:43:51 +0300
Subject: <AWT Dev> Review request for 8151385: [hidpi] JOptionPane-Icons
 only partially visible when using Windows 10 L&F
In-Reply-To: <BC4ADF37-F25A-4D13-A096-9DFD017D8EB3@tagtraum.com>
References: <898AFD4C-3717-48C0-BBB2-24287F7C0512@tagtraum.com>
	<36184957-6682-4F71-BDD4-2EA35BE49209@tagtraum.com>
	<56E3092F.6040905@oracle.com>
	<CBC1EF8D-5853-42F8-B416-A6364D5BB8BD@tagtraum.com>
	<56E8EE58.1010006@oracle.com>
	<337E07D9-EC25-4BE7-B387-F11473A8BB26@tagtraum.com>
	<56F0628A.5030908@oracle.com>
	<1D2830BA-9610-407B-9C4C-424E6B57074D@tagtraum.com>
	<56F17285.7020506@oracle.com>
	<9D18EE88-883B-4428-8CD5-347232761D3F@tagtraum.com>
	<7E17C804-7EA7-4F42-8A1E-C50093C4F40E@tagtraum.com>
	<83c01190-e06e-8bbd-b685-772ad2bb8cfb@oracle.com>
	<BC4ADF37-F25A-4D13-A096-9DFD017D8EB3@tagtraum.com>
Message-ID: <10c553d4-e411-4e48-ef9d-4506103fc100@oracle.com>

+1

On 08.06.16 10:57, Hendrik Schreiber wrote:
> Hey Alexandr,
>
>> On Jun 7, 2016, at 17:44, Alexandr Scherbatiy <alexandr.scherbatiy at oracle.com> wrote:
>>
>> I slightly updated your fix to return a multi-resolution image with base icon size when icon size is greater than the real icon size. This allows to draw a high-resolution icon to the same bounds on JOptionPane.
>> http://cr.openjdk.java.net/~alexsch/hendrik.schreiber/8151385/webrev.01
>
> Thanks. That looks good to me.
>
>> I have not found the solution for the native toolbar icons yet. An icon with IDB_VIEW_SMALL_COLOR has size 16x16 on my Windows 8.1. The GetSystemMetrics(SM_CXSMICON) returns 32. It is a question for me should IDB_VIEW_SMALL_COLOR icon has the same size as the GetSystemMetrics(SM_CXSMICON).
>> An icon with IDB_VIEW_LARGE_COLOR returns also icon with size 16x16 and the returned image contains only one quarter of the original picture.
>>
>> I left the code for the toolbar icons as it was before so it uses low resolution IDB_VIEW_SMALL_COLOR icons.
>> I think it can be fixed as a separated issue.
>
> Perhaps that?s the best approach, even though I fear that that means it will never get fixed?
> But having the other fixes in the JDK, is already some progress I appreciate very much.
>
> Are you going to create a new bug report?
>
> Eventually, we simply need a more modern FileDialog. See http://mail.openjdk.java.net/pipermail/awt-dev/2016-March/010778.html
>
> Cheers,
>
> -hendrik
>


-- 
Best regards, Sergey.

From daniil.x.titov at oracle.com  Thu Jun  9 16:08:13 2016
From: daniil.x.titov at oracle.com (Daniil Titov)
Date: Thu, 9 Jun 2016 09:08:13 -0700 (PDT)
Subject: <AWT Dev> Review Request: 8156960 Deprecate
 JSObject.getWindow(Applet) method
In-Reply-To: <57591BE3.5060003@oracle.com>
References: <1f05a2b9-a68b-4684-a58a-163189c710af@default>
	<FDD6B460-8071-40CA-8FC3-AECF9E0C4ABF@oracle.com>
	<6CB5C96E-8B7F-4093-BA02-94702BA53047@oracle.com>
	<99907f0c-961d-4d66-950f-9b4de4fc96f7@default>
	<EAF37B66-F1D5-44D0-82AB-DFB4120AB8E4@oracle.com>
	<61539153-a0c6-474d-aded-d34b6266a1c1@default>
	<57591BE3.5060003@oracle.com>
Message-ID: <783dd081-c75e-464d-8b01-baccb9d85156@default>

Thank you, Erik!

Please review the new version of the patch that has "../" fixed:

Webrev: http://cr.openjdk.java.net/~dtitov/8156960/jdk/webrev.02
        http://cr.openjdk.java.net/~dtitov/8156960/webrev.02/


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

Best regards,
Daniil

-----Original Message-----
From: Erik Joelsson 
Sent: Thursday, June 09, 2016 12:34 AM
To: Daniil Titov; Mandy Chung
Cc: David Dehaven; Stuart Marks; build-dev; build-infa-dev at openjdk.java.net; awt-dev; Kevin Rushforth
Subject: Re: Review Request: 8156960 Deprecate JSObject.getWindow(Applet) method

Hello,

Generally looks good, but I do think this needs to be changed:

JSOBJECT_DOCDIR := $(JRE_API_DOCSDIR)/plugin/jsobject
JSOBJECT2COREAPI := ../../../$(JDKJRE2COREAPI)

The number of ../ should probably match the directory level depth of the variable before it, at least it looks that way for the other setups:

JSOBJECT2COREAPI := ../../$(JDKJRE2COREAPI)

/Erik

On 2016-06-09 02:34, Daniil Titov wrote:
> Hello,
>
> Please review the new version of the fix for JDK9.
>
> 1. "forRemoval = true" is added to @Deprecated annotation for JSObject.getWindow(Applet) method.
> 2.  A new doc bundle for JSObject documentation is added in the docs build.
>
> Webrev: http://cr.openjdk.java.net/~dtitov/8156960/jdk/webrev.01
>          http://cr.openjdk.java.net/~dtitov/8156960/webrev.01
>
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8156960
>
> Thank you!
>
> Best regards,
> Daniil
>
> -----Original Message-----
> From: Mandy Chung
> Sent: Wednesday, June 08, 2016 3:09 PM
> To: Daniil Titov
> Cc: David Dehaven; Stuart Marks; Erik Joelsson; build-dev; 
> build-infa-dev at openjdk.java.net; awt-dev; Kevin Rushforth
> Subject: Re: Review Request: 8156960 Deprecate 
> JSObject.getWindow(Applet) method
>
> That?s right.  It requires to add a new doc bundle in the docs build.  What you did was the right direction.  Can you update the webrev?
>
> FYI.  There is an effort under discussion to revisit the number of docs bundle generated and clean up the docs build.
>
> Mandy
>
>> On Jun 8, 2016, at 2:48 PM, Daniil Titov <daniil.x.titov at oracle.com> wrote:
>>
>> NON_CORE_PKGS variable is not used in make/Javadoc.gmk, so just adding a new package in this variable will not make this package included in any docs. We will need to create a new javadoc target for JSObject documentation ( or add it to some existing target, but it doesn't look like there is one that fits it). For example:
>>
>>
>> diff -r 389c2d2842a5 make/Javadoc.gmk
>> --- a/make/Javadoc.gmk	Wed May 25 12:53:26 2016 +0200
>> +++ b/make/Javadoc.gmk	Thu Jun 02 16:20:35 2016 -0700
>> @@ -82,7 +82,7 @@
>> PLUGIN2_FIRST_COPYRIGHT_YEAR = 2007
>> JDKNET_FIRST_COPYRIGHT_YEAR = 2014
>> JACCESSAPI_FIRST_COPYRIGHT_YEAR = 2002
>> -
>> +JSOBJECT_FIRST_COPYRIGHT_YEAR = 1993
>>
>> # Oracle name
>> FULL_COMPANY_NAME = Oracle and/or its affiliates @@ -1031,6 +1031,64 
>> @@
>>
>> #############################################################
>> #
>> +# jsobjectdocs
>> +#
>> +
>> +ALL_OTHER_TARGETS += jsobjectdoc
>> +
>> +JSOBJECT_DOCDIR := $(JRE_API_DOCSDIR)/plugin/jsobject
>> +JSOBJECT2COREAPI := ../../../$(JDKJRE2COREAPI) JSOBJECT_DOCTITLE :=
>> +Java$(TRADEMARK) JSObject Doc JSOBJECT_WINDOWTITLE := Java JSObect 
>> +Doc JSOBJECT_HEADER := <strong>Java JSObject Doc</strong> 
>> +JSOBJECT_BOTTOM := $(call
>> +CommonBottom,$(JSOBJECT_FIRST_COPYRIGHT_YEAR))
>> +# JSOBJECT_PKGS is located in NON_CORE_PKGS.gmk
>> +
>> +JSOBJECT_INDEX_HTML = $(JSOBJECT_DOCDIR)/index.html 
>> +JSOBJECT_OPTIONS_FILE = $(DOCSTMPDIR)/jsobject.options 
>> +JSOBJECT_PACKAGES_FILE = $(DOCSTMPDIR)/jsobject.packages
>> +
>> +# The modules required to be documented JSOBJECT_MODULES = 
>> +jdk.jsobject
>> +
>> +jsobjectdocs: $(JSOBJECT_INDEX_HTML)
>> +
>> +# Set relative location to core api document root
>> +$(JSOBJECT_INDEX_HTML): GET2DOCSDIR=$(JSOBJECT2COREAPI)/..
>> +
>> +# Run javadoc if the index file is out of date or missing
>> +$(JSOBJECT_INDEX_HTML): $(JSOBJECT_OPTIONS_FILE) $(JSOBJECT_PACKAGES_FILE) $(COREAPI_INDEX_FILE)
>> +	$(prep-javadoc)
>> +	$(call JavadocSummary,$(JSOBJECT_OPTIONS_FILE),$(JSOBJECT_PACKAGES_FILE))
>> +	$(JAVADOC_CMD_SMALL) -d $(@D) \
>> +	    @$(JSOBJECT_OPTIONS_FILE) @$(JSOBJECT_PACKAGES_FILE)
>> +
>> +# Create file with javadoc options in it
>> +$(JSOBJECT_OPTIONS_FILE):
>> +	$(prep-target)
>> +	@($(call COMMON_JAVADOCFLAGS) ; \
>> +          $(call COMMON_JAVADOCTAGS) ; \
>> +	  $(call OptionOnly,-Xdoclint:none) ; \
>> +          $(call OptionPair,-system,none) ; \
>> +	  $(call OptionPair,-modulesourcepath,$(RELEASEDOCS_MODULESOURCEPATH)) ; \
>> +	  $(call OptionPair,-addmods,$(JSOBJECT_MODULES)) ; \
>> +	  $(call OptionPair,-encoding,ascii) ; \
>> +	  $(call OptionOnly,-nodeprecatedlist) ; \
>> +	  $(call OptionPair,-doctitle,$(JSOBJECT_DOCTITLE)) ; \
>> +	  $(call OptionPair,-windowtitle,$(JSOBJECT_WINDOWTITLE) $(DRAFT_WINTITLE)); \
>> +	  $(call OptionPair,-header,$(JSOBJECT_HEADER)$(DRAFT_HEADER)); \
>> +	  $(call OptionPair,-bottom,$(JSOBJECT_BOTTOM)$(DRAFT_BOTTOM)); \
>> +	  $(call OptionTrip,-linkoffline,$(JSOBJECT2COREAPI),$(COREAPI_DOCSDIR)/); \
>> +	) >> $@
>> +
>> +# Create a file with the package names in it
>> +$(JSOBJECT_PACKAGES_FILE): $(call PackageDependencies,$(JSOBJECT_PKGS))
>> +	$(prep-target)
>> +	$(call PackageFilter,$(JSOBJECT_PKGS))
>> +
>> +
>> +#############################################################
>> +#
>> # mgmtdocs
>> #
>>
>>
>> Best regards,
>> Daniil
>>
>>
>>
>> -----Original Message-----
>> From: David DeHaven
>> Sent: Wednesday, June 08, 2016 1:23 PM
>> To: Mandy Chung
>> Cc: Daniil Titov; Stuart Marks; Erik Joelsson; build-dev; 
>> build-infa-dev at openjdk.java.net; awt-dev; Kevin Rushforth
>> Subject: Re: Review Request: 8156960 Deprecate
>> JSObject.getWindow(Applet) method
>>
>>
>> How about NON_CORE_PKGS.gmk for javadoc?
>>
>> Something like:
>>
>> diff --git a/make/common/NON_CORE_PKGS.gmk 
>> b/make/common/NON_CORE_PKGS.gmk
>> --- a/make/common/NON_CORE_PKGS.gmk
>> +++ b/make/common/NON_CORE_PKGS.gmk
>> @@ -44,6 +44,8 @@
>>      org.w3c.dom.events \
>>      org.w3c.dom.views
>>
>> +JSOBJECT_PKGS = netscape.javascript
>> +
>> JDI_PKGS = com.sun.jdi \
>>      com.sun.jdi.event \
>>      com.sun.jdi.request \
>> @@ -113,6 +115,7 @@
>>
>> # non-core packages in rt.jar
>> NON_CORE_PKGS = $(DOMAPI_PKGS) \
>> +    $(JSOBJECT_PKGS) \
>>      $(MGMT_PKGS) \
>>      $(JAAS_PKGS) \
>>      $(JGSS_PKGS) \
>>
>> -DrD-
>>
>>> The client team owns jdk.jsobject module and so I add awt-dev to this thread.  And bcc jdk9-dev.
>>>
>>> It is not Java SE API and it should not add to CORE-PKGS.gmk.  As for @Deprecated, I believe the plan is to remove the getWindows method in a future release. Kevin and Dave can confirm.
>>>
>>> Mandy
>>>
>>>> On Jun 8, 2016, at 12:33 PM, Daniil Titov <daniil.x.titov at oracle.com> wrote:
>>>>
>>>> Hello,
>>>>
>>>>
>>>>
>>>> Please review the fix for JDK 9.
>>>>
>>>>
>>>>
>>>> The fix adds @Deprecated annotation to netscape.javascript.JSObject.getWindow(Applet) method and ensures that netscape.javascript package is included in the generated docs.
>>>>
>>>>
>>>>
>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8156960
>>>>
>>>>
>>>>
>>>> Webrev:   http://cr.openjdk.java.net/~dtitov/8156960/jdk/webrev.00/
>>>>
>>>>         http://cr.openjdk.java.net/~dtitov/8156960/webrev.00/
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> Best regards,
>>>>
>>>> Daniil


From mandy.chung at oracle.com  Thu Jun  9 16:22:42 2016
From: mandy.chung at oracle.com (Mandy Chung)
Date: Thu, 9 Jun 2016 09:22:42 -0700
Subject: <AWT Dev> Review Request: 8156960 Deprecate
	JSObject.getWindow(Applet) method
In-Reply-To: <783dd081-c75e-464d-8b01-baccb9d85156@default>
References: <1f05a2b9-a68b-4684-a58a-163189c710af@default>
	<FDD6B460-8071-40CA-8FC3-AECF9E0C4ABF@oracle.com>
	<6CB5C96E-8B7F-4093-BA02-94702BA53047@oracle.com>
	<99907f0c-961d-4d66-950f-9b4de4fc96f7@default>
	<EAF37B66-F1D5-44D0-82AB-DFB4120AB8E4@oracle.com>
	<61539153-a0c6-474d-aded-d34b6266a1c1@default>
	<57591BE3.5060003@oracle.com>
	<783dd081-c75e-464d-8b01-baccb9d85156@default>
Message-ID: <4CDCB0A1-CF7B-4490-A76D-16C339C0F8D6@oracle.com>


> On Jun 9, 2016, at 9:08 AM, Daniil Titov <daniil.x.titov at oracle.com> wrote:
> 
> Thank you, Erik!
> 
> Please review the new version of the patch that has "../" fixed:
> 
> Webrev: http://cr.openjdk.java.net/~dtitov/8156960/jdk/webrev.02
>        http://cr.openjdk.java.net/~dtitov/8156960/webrev.02/
> 

Looks okay.  Nit: in JSObject.java - line 154 long line to be wrapped. 

Mandy

From daniil.x.titov at oracle.com  Thu Jun  9 17:58:29 2016
From: daniil.x.titov at oracle.com (Daniil Titov)
Date: Thu, 9 Jun 2016 10:58:29 -0700 (PDT)
Subject: <AWT Dev> Review Request: 8156960 Deprecate
 JSObject.getWindow(Applet) method
In-Reply-To: <4CDCB0A1-CF7B-4490-A76D-16C339C0F8D6@oracle.com>
References: <1f05a2b9-a68b-4684-a58a-163189c710af@default>
	<FDD6B460-8071-40CA-8FC3-AECF9E0C4ABF@oracle.com>
	<6CB5C96E-8B7F-4093-BA02-94702BA53047@oracle.com>
	<99907f0c-961d-4d66-950f-9b4de4fc96f7@default>
	<EAF37B66-F1D5-44D0-82AB-DFB4120AB8E4@oracle.com>
	<61539153-a0c6-474d-aded-d34b6266a1c1@default>
	<57591BE3.5060003@oracle.com>
	<783dd081-c75e-464d-8b01-baccb9d85156@default>
	<4CDCB0A1-CF7B-4490-A76D-16C339C0F8D6@oracle.com>
Message-ID: <4ab9c5da-7dc5-459b-ba0a-6f4f1d39fce4@default>

Thank you, Mandy!

The long line is corrected.

Webrev: http://cr.openjdk.java.net/~dtitov/8156960/jdk/webrev.03
        http://cr.openjdk.java.net/~dtitov/8156960/webrev.03

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

Best regards,
Daniil




-----Original Message-----
From: Mandy Chung 
Sent: Thursday, June 09, 2016 9:23 AM
To: Daniil Titov
Cc: Erik Joelsson; David Dehaven; Stuart Marks; build-dev; build-infa-dev at openjdk.java.net; awt-dev; Kevin Rushforth
Subject: Re: Review Request: 8156960 Deprecate JSObject.getWindow(Applet) method


> On Jun 9, 2016, at 9:08 AM, Daniil Titov <daniil.x.titov at oracle.com> wrote:
> 
> Thank you, Erik!
> 
> Please review the new version of the patch that has "../" fixed:
> 
> Webrev: http://cr.openjdk.java.net/~dtitov/8156960/jdk/webrev.02
>        http://cr.openjdk.java.net/~dtitov/8156960/webrev.02/
> 

Looks okay.  Nit: in JSObject.java - line 154 long line to be wrapped. 

Mandy

From kevin.rushforth at oracle.com  Thu Jun  9 18:07:35 2016
From: kevin.rushforth at oracle.com (Kevin Rushforth)
Date: Thu, 09 Jun 2016 11:07:35 -0700
Subject: <AWT Dev> Review Request: 8156960 Deprecate
 JSObject.getWindow(Applet) method
In-Reply-To: <4ab9c5da-7dc5-459b-ba0a-6f4f1d39fce4@default>
References: <1f05a2b9-a68b-4684-a58a-163189c710af@default>
	<FDD6B460-8071-40CA-8FC3-AECF9E0C4ABF@oracle.com>
	<6CB5C96E-8B7F-4093-BA02-94702BA53047@oracle.com>
	<99907f0c-961d-4d66-950f-9b4de4fc96f7@default>
	<EAF37B66-F1D5-44D0-82AB-DFB4120AB8E4@oracle.com>
	<61539153-a0c6-474d-aded-d34b6266a1c1@default>
	<57591BE3.5060003@oracle.com>
	<783dd081-c75e-464d-8b01-baccb9d85156@default>
	<4CDCB0A1-CF7B-4490-A76D-16C339C0F8D6@oracle.com>
	<4ab9c5da-7dc5-459b-ba0a-6f4f1d39fce4@default>
Message-ID: <5759B067.3020209@oracle.com>

Looks fine to me.

-- Kevin


Daniil Titov wrote:
> Thank you, Mandy!
>
> The long line is corrected.
>
> Webrev: http://cr.openjdk.java.net/~dtitov/8156960/jdk/webrev.03
>         http://cr.openjdk.java.net/~dtitov/8156960/webrev.03
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8156960
>
> Best regards,
> Daniil
>
>
>
>
> -----Original Message-----
> From: Mandy Chung 
> Sent: Thursday, June 09, 2016 9:23 AM
> To: Daniil Titov
> Cc: Erik Joelsson; David Dehaven; Stuart Marks; build-dev; build-infa-dev at openjdk.java.net; awt-dev; Kevin Rushforth
> Subject: Re: Review Request: 8156960 Deprecate JSObject.getWindow(Applet) method
>
>
>   
>> On Jun 9, 2016, at 9:08 AM, Daniil Titov <daniil.x.titov at oracle.com> wrote:
>>
>> Thank you, Erik!
>>
>> Please review the new version of the patch that has "../" fixed:
>>
>> Webrev: http://cr.openjdk.java.net/~dtitov/8156960/jdk/webrev.02
>>        http://cr.openjdk.java.net/~dtitov/8156960/webrev.02/
>>
>>     
>
> Looks okay.  Nit: in JSObject.java - line 154 long line to be wrapped. 
>
> Mandy
>   
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20160609/60139061/attachment.html>

From semyon.sadetsky at oracle.com  Fri Jun 10 07:16:28 2016
From: semyon.sadetsky at oracle.com (Semyon Sadetsky)
Date: Fri, 10 Jun 2016 10:16:28 +0300
Subject: <AWT Dev> [9] Review Request: 8004693 TEST_BUG:
 java/awt/KeyboardFocusmanager/DefaultPolicyChange/DefaultPolicyChange_Swing.java
 fails
In-Reply-To: <2bec697e-5fc4-8887-3511-9bb91e330f17@oracle.com>
References: <eb5fd302-ada9-0032-3560-ce8589797ff0@oracle.com>
	<bf339c16-f8c8-a957-753f-13a271d7b60c@oracle.com>
	<7e49d08b-06ba-8a0d-8932-7d82b7db3ee2@oracle.com>
	<832eae6a-481c-28bc-5686-dbdb3cb10770@oracle.com>
	<63249335-46d1-63e0-7942-757c192c4e6c@oracle.com>
	<308b6441-222f-9d85-3286-fcc695a01eb5@oracle.com>
	<ecac2276-9b80-ff1b-b2ee-95e8132be922@oracle.com>
	<1312561b-1692-140e-8ddb-90323543cf12@oracle.com>
	<2bec697e-5fc4-8887-3511-9bb91e330f17@oracle.com>
Message-ID: <cb2c5acb-e33a-f3ce-c8b0-d542dab96966@oracle.com>

On 6/9/2016 12:37 PM, Sergey Bylokhov wrote:

> On 08.06.16 19:53, Semyon Sadetsky wrote:
>> Yes, but the Object#equlas() does not prohibit different class instances
>> to be equal. The purpose of the test is to prove that existing
>> component's FTP instances remain untouchable during the default FTP
>> change regardless of the specific FTP implementation. This may be tested
>> only by == operator. Or please provide a scenario when they are allowed
>> be replaced by some equivalent FTP's.
>
> For our policies the different instances will be different because   
> our classes do not override equals. If we override at some point the 
> equal for our public classes then we will consider the different 
> instances as the same policy. Do you have some other comments?
These class instances may be replaced later. Since the fix pretends to 
improve the test quality, it is desirable that the limitations, like 
this, have been corrected in the fix.  equals() is not needed and should 
be replaced by ==.
>>> Why? It is useful to know what policy is used when the test passed.
>> Because the main purpose of the test is to automatically compare FTPs,
>> so this verbose output is not necessary and this extra printout
>> duplicates printout in case the test is failed.
>
> The author of the test and the author of this fix, consider this 
> output useful. Do you have some other comments?
But you could not answer: "how is it useful?".
Any test is a small product which is used for execution. This debug 
output might be useful for the test development, but for the test 
execution it is parasitic, because it consumes tester's attention when 
the test passes, which means that the FTPs are equal and there are no 
need to compare them using this output.
If the test fails the similar output is printed, so there will be the 
same information printed twice, and this will consumes more time to sort 
out the output.
To improve the test quality, please consider to remove this output or to 
make it optional.
>
>> Please answer the above question to avoid incoherence in the discussion.
>
> I already asked your question, "This is an emulation of the common 
> dialog used by the application which have some components inside which 
> can be focused". Do you have some other comments?
Since, you could not show how those dummy component are involved in the 
default FTP change, it is absolutely unclear what benefits may be 
achieved by adding those components, and hence, they may be discarded 
without any loss in the test coverage, but with a real improvement in 
test clearness.
>
>
>>>>
>>>> --Semyon
>>>>>
>>>>>>>> On 5/30/2016 7:39 PM, Sergey Bylokhov wrote:
>>>>>>>>> Hello.
>>>>>>>>> Please review the fix for jdk9.
>>>>>>>>>
>>>>>>>>> The test DefaultPolicyChange_Swing.java has two issues:
>>>>>>>>>  - It uses invokeLater(), so the test usually pass before the
>>>>>>>>> code is
>>>>>>>>> executed on the EDT, because the main thread completes before.
>>>>>>>>>  - The test fetches the FocusTraversalPolicy from the current
>>>>>>>>> KeyboardFocusManager. But default FocusTraversalPolicy can be
>>>>>>>>> changed
>>>>>>>>> during the Swing initialization(JDK-7125044). The test should 
>>>>>>>>> save
>>>>>>>>> the
>>>>>>>>> state before setDefaultFocusTraversalPolicy() but after the Swing
>>>>>>>>> initialization, and validate that the FocusTraversalPolicy was 
>>>>>>>>> not
>>>>>>>>> changed for windows which were already shown.
>>>>>>>>>
>>>>>>>>> The fix proposed in the CR is applied + small
>>>>>>>>> cleanup(regtesthelpers
>>>>>>>>> removed and InvokeAndWait is used instead of 
>>>>>>>>> InvokeLater+realSync)
>>>>>>>>>
>>>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8004693
>>>>>>>>> Webrev can be found at:
>>>>>>>>> http://cr.openjdk.java.net/~serb/8004693/webrev.01
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>
>>>
>>
>
>


From alexandr.scherbatiy at oracle.com  Fri Jun 10 07:30:30 2016
From: alexandr.scherbatiy at oracle.com (Alexandr Scherbatiy)
Date: Fri, 10 Jun 2016 10:30:30 +0300
Subject: <AWT Dev> Review Request: 8156960 Deprecate
 JSObject.getWindow(Applet) method
In-Reply-To: <4ab9c5da-7dc5-459b-ba0a-6f4f1d39fce4@default>
References: <1f05a2b9-a68b-4684-a58a-163189c710af@default>
	<FDD6B460-8071-40CA-8FC3-AECF9E0C4ABF@oracle.com>
	<6CB5C96E-8B7F-4093-BA02-94702BA53047@oracle.com>
	<99907f0c-961d-4d66-950f-9b4de4fc96f7@default>
	<EAF37B66-F1D5-44D0-82AB-DFB4120AB8E4@oracle.com>
	<61539153-a0c6-474d-aded-d34b6266a1c1@default>
	<57591BE3.5060003@oracle.com>
	<783dd081-c75e-464d-8b01-baccb9d85156@default>
	<4CDCB0A1-CF7B-4490-A76D-16C339C0F8D6@oracle.com>
	<4ab9c5da-7dc5-459b-ba0a-6f4f1d39fce4@default>
Message-ID: <07d0b991-d5b5-98f9-897f-4dde49b052ff@oracle.com>

The fix looks good to me.

Thanks,
Alexandr.

On 6/9/2016 8:58 PM, Daniil Titov wrote:
> Thank you, Mandy!
>
> The long line is corrected.
>
> Webrev: http://cr.openjdk.java.net/~dtitov/8156960/jdk/webrev.03
>          http://cr.openjdk.java.net/~dtitov/8156960/webrev.03
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8156960
>
> Best regards,
> Daniil
>
>
>
>
> -----Original Message-----
> From: Mandy Chung
> Sent: Thursday, June 09, 2016 9:23 AM
> To: Daniil Titov
> Cc: Erik Joelsson; David Dehaven; Stuart Marks; build-dev; build-infa-dev at openjdk.java.net; awt-dev; Kevin Rushforth
> Subject: Re: Review Request: 8156960 Deprecate JSObject.getWindow(Applet) method
>
>
>> On Jun 9, 2016, at 9:08 AM, Daniil Titov <daniil.x.titov at oracle.com> wrote:
>>
>> Thank you, Erik!
>>
>> Please review the new version of the patch that has "../" fixed:
>>
>> Webrev: http://cr.openjdk.java.net/~dtitov/8156960/jdk/webrev.02
>>         http://cr.openjdk.java.net/~dtitov/8156960/webrev.02/
>>
> Looks okay.  Nit: in JSObject.java - line 154 long line to be wrapped.
>
> Mandy


From erik.joelsson at oracle.com  Fri Jun 10 09:04:57 2016
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Fri, 10 Jun 2016 11:04:57 +0200
Subject: <AWT Dev> Review Request: 8156960 Deprecate
 JSObject.getWindow(Applet) method
In-Reply-To: <4ab9c5da-7dc5-459b-ba0a-6f4f1d39fce4@default>
References: <1f05a2b9-a68b-4684-a58a-163189c710af@default>
	<FDD6B460-8071-40CA-8FC3-AECF9E0C4ABF@oracle.com>
	<6CB5C96E-8B7F-4093-BA02-94702BA53047@oracle.com>
	<99907f0c-961d-4d66-950f-9b4de4fc96f7@default>
	<EAF37B66-F1D5-44D0-82AB-DFB4120AB8E4@oracle.com>
	<61539153-a0c6-474d-aded-d34b6266a1c1@default>
	<57591BE3.5060003@oracle.com>
	<783dd081-c75e-464d-8b01-baccb9d85156@default>
	<4CDCB0A1-CF7B-4490-A76D-16C339C0F8D6@oracle.com>
	<4ab9c5da-7dc5-459b-ba0a-6f4f1d39fce4@default>
Message-ID: <575A82B9.9030602@oracle.com>

Looks good.

/Erik

On 2016-06-09 19:58, Daniil Titov wrote:
> Thank you, Mandy!
>
> The long line is corrected.
>
> Webrev: http://cr.openjdk.java.net/~dtitov/8156960/jdk/webrev.03
>          http://cr.openjdk.java.net/~dtitov/8156960/webrev.03
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8156960
>
> Best regards,
> Daniil
>
>
>
>
> -----Original Message-----
> From: Mandy Chung
> Sent: Thursday, June 09, 2016 9:23 AM
> To: Daniil Titov
> Cc: Erik Joelsson; David Dehaven; Stuart Marks; build-dev; build-infa-dev at openjdk.java.net; awt-dev; Kevin Rushforth
> Subject: Re: Review Request: 8156960 Deprecate JSObject.getWindow(Applet) method
>
>
>> On Jun 9, 2016, at 9:08 AM, Daniil Titov <daniil.x.titov at oracle.com> wrote:
>>
>> Thank you, Erik!
>>
>> Please review the new version of the patch that has "../" fixed:
>>
>> Webrev: http://cr.openjdk.java.net/~dtitov/8156960/jdk/webrev.02
>>         http://cr.openjdk.java.net/~dtitov/8156960/webrev.02/
>>
> Looks okay.  Nit: in JSObject.java - line 154 long line to be wrapped.
>
> Mandy


From artem.ananiev at oracle.com  Fri Jun 10 15:31:12 2016
From: artem.ananiev at oracle.com (Artem Ananiev)
Date: Fri, 10 Jun 2016 18:31:12 +0300
Subject: <AWT Dev> Request to resign as AWT group lead
Message-ID: <191131ab-0aaa-8085-7728-f966d3bfa142@oracle.com>

Hi, AWT group,

for quite a while, I haven't been involved into AWT group activities as 
much as I used to be. For the group to move on, I request to resign as 
the group leader, as described in OpenJDK Bylaws:

http://openjdk.java.net/bylaws#group-lead

Thanks,

Artem

From artem.ananiev at oracle.com  Fri Jun 10 15:39:01 2016
From: artem.ananiev at oracle.com (Artem Ananiev)
Date: Fri, 10 Jun 2016 18:39:01 +0300
Subject: <AWT Dev> CFV: New AWT Group Lead: Sergey Bylokhov
Message-ID: <bf5be81e-870c-5288-8ca2-e511d5d236e0@oracle.com>

Hi, AWT team,

I hereby nominate Sergey Bylokhov (OpenJDK user name: serb) to AWT Group 
Lead [1].

Sergey is a member of Java Client group at Oracle. He has been one of 
the most active contributors to AWT (and other Java client libs: Swing, 
Java2D, JavaFX, Java Sound, Java Beans) last few years and demonstrated 
very deep knowledge of the library, its architecture and implementation 
on various platforms.

Votes are due by June 24, 2016.

Only current AWT group members [2] are eligible to vote on this 
nomination. Votes must be cast in the open by replying to this mailing list.

For Two-Thirds Majority voting instructions, see [3]

[1] http://openjdk.java.net/bylaws#group-lead
[2] http://openjdk.java.net/census#awt
[3] http://openjdk.java.net/bylaws#two-thirds-majority

Thanks,

Artem

From artem.ananiev at oracle.com  Fri Jun 10 15:43:13 2016
From: artem.ananiev at oracle.com (Artem Ananiev)
Date: Fri, 10 Jun 2016 18:43:13 +0300
Subject: <AWT Dev> CFV: New AWT Group Lead: Sergey Bylokhov
In-Reply-To: <bf5be81e-870c-5288-8ca2-e511d5d236e0@oracle.com>
References: <bf5be81e-870c-5288-8ca2-e511d5d236e0@oracle.com>
Message-ID: <1c0c8b37-77b8-5fe2-20b7-bf9934b0ed63@oracle.com>


Vote: yes (obviously)

Arten

On 6/10/16 6:39 PM, Artem Ananiev wrote:
> Hi, AWT team,
>
> I hereby nominate Sergey Bylokhov (OpenJDK user name: serb) to AWT Group
> Lead [1].
>
> Sergey is a member of Java Client group at Oracle. He has been one of
> the most active contributors to AWT (and other Java client libs: Swing,
> Java2D, JavaFX, Java Sound, Java Beans) last few years and demonstrated
> very deep knowledge of the library, its architecture and implementation
> on various platforms.
>
> Votes are due by June 24, 2016.
>
> Only current AWT group members [2] are eligible to vote on this
> nomination. Votes must be cast in the open by replying to this mailing
> list.
>
> For Two-Thirds Majority voting instructions, see [3]
>
> [1] http://openjdk.java.net/bylaws#group-lead
> [2] http://openjdk.java.net/census#awt
> [3] http://openjdk.java.net/bylaws#two-thirds-majority
>
> Thanks,
>
> Artem

From yuri.nesterenko at oracle.com  Fri Jun 10 15:57:42 2016
From: yuri.nesterenko at oracle.com (Yuri Nesterenko)
Date: Fri, 10 Jun 2016 18:57:42 +0300
Subject: <AWT Dev> CFV: New AWT Group Lead: Sergey Bylokhov
In-Reply-To: <bf5be81e-870c-5288-8ca2-e511d5d236e0@oracle.com>
References: <bf5be81e-870c-5288-8ca2-e511d5d236e0@oracle.com>
Message-ID: <575AE376.2000103@oracle.com>

Vote: yes

-yan

On 06/10/2016 06:39 PM, Artem Ananiev wrote:
> Hi, AWT team,
>
> I hereby nominate Sergey Bylokhov (OpenJDK user name: serb) to AWT Group
> Lead [1].
>
> Sergey is a member of Java Client group at Oracle. He has been one of
> the most active contributors to AWT (and other Java client libs: Swing,
> Java2D, JavaFX, Java Sound, Java Beans) last few years and demonstrated
> very deep knowledge of the library, its architecture and implementation
> on various platforms.
>
> Votes are due by June 24, 2016.
>
> Only current AWT group members [2] are eligible to vote on this
> nomination. Votes must be cast in the open by replying to this mailing
> list.
>
> For Two-Thirds Majority voting instructions, see [3]
>
> [1] http://openjdk.java.net/bylaws#group-lead
> [2] http://openjdk.java.net/census#awt
> [3] http://openjdk.java.net/bylaws#two-thirds-majority
>
> Thanks,
>
> Artem


From alexander.zuev at oracle.com  Fri Jun 10 15:58:26 2016
From: alexander.zuev at oracle.com (Alexander Zuev)
Date: Fri, 10 Jun 2016 08:58:26 -0700
Subject: <AWT Dev> CFV: New AWT Group Lead: Sergey Bylokhov
Message-ID: <575AE3A2.6020107@oracle.com>

Vote: yes

From stuart.marks at oracle.com  Fri Jun 10 16:58:07 2016
From: stuart.marks at oracle.com (Stuart Marks)
Date: Fri, 10 Jun 2016 09:58:07 -0700
Subject: <AWT Dev> Review Request: 8156960 Deprecate
 JSObject.getWindow(Applet) method
In-Reply-To: <61539153-a0c6-474d-aded-d34b6266a1c1@default>
References: <1f05a2b9-a68b-4684-a58a-163189c710af@default>
	<FDD6B460-8071-40CA-8FC3-AECF9E0C4ABF@oracle.com>
	<6CB5C96E-8B7F-4093-BA02-94702BA53047@oracle.com>
	<99907f0c-961d-4d66-950f-9b4de4fc96f7@default>
	<EAF37B66-F1D5-44D0-82AB-DFB4120AB8E4@oracle.com>
	<61539153-a0c6-474d-aded-d34b6266a1c1@default>
Message-ID: <3d7b40f9-6c2c-340d-cd75-0050ae0d857c@oracle.com>

Hi, sorry I had missed this earlier.

It's surprising if forRemoval=true were to be added to this API when the rest of 
the Applet API has forRemoval=false. Is it the intent, for example, to have 
JSObject.getWindow() removed from JDK 10 but to have the rest of the Applet API 
remain?

My understanding of the plan was to deprecate the Applet API in JDK 9 with 
forRemoval=false. Then, in a future release, when removal plans become more 
definite, to change forRemoval to true, and in a subsequent release, to remove 
the Applet APIs. I'd think that plan would apply here as well.

Put another way, I'd recommend that we set forRemoval=true only when the plan is 
more definite than "we plan to remove this in some future, as yet unspecified 
release."

s'marks


On 6/8/16 5:34 PM, Daniil Titov wrote:
> Hello,
>
> Please review the new version of the fix for JDK9.
>
> 1. "forRemoval = true" is added to @Deprecated annotation for JSObject.getWindow(Applet) method.
> 2.  A new doc bundle for JSObject documentation is added in the docs build.
>
> Webrev: http://cr.openjdk.java.net/~dtitov/8156960/jdk/webrev.01
>         http://cr.openjdk.java.net/~dtitov/8156960/webrev.01
>
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8156960
>
> Thank you!
>
> Best regards,
> Daniil
>
> -----Original Message-----
> From: Mandy Chung
> Sent: Wednesday, June 08, 2016 3:09 PM
> To: Daniil Titov
> Cc: David Dehaven; Stuart Marks; Erik Joelsson; build-dev; build-infa-dev at openjdk.java.net; awt-dev; Kevin Rushforth
> Subject: Re: Review Request: 8156960 Deprecate JSObject.getWindow(Applet) method
>
> That?s right.  It requires to add a new doc bundle in the docs build.  What you did was the right direction.  Can you update the webrev?
>
> FYI.  There is an effort under discussion to revisit the number of docs bundle generated and clean up the docs build.
>
> Mandy
>
>> On Jun 8, 2016, at 2:48 PM, Daniil Titov <daniil.x.titov at oracle.com> wrote:
>>
>> NON_CORE_PKGS variable is not used in make/Javadoc.gmk, so just adding a new package in this variable will not make this package included in any docs. We will need to create a new javadoc target for JSObject documentation ( or add it to some existing target, but it doesn't look like there is one that fits it). For example:
>>
>>
>> diff -r 389c2d2842a5 make/Javadoc.gmk
>> --- a/make/Javadoc.gmk	Wed May 25 12:53:26 2016 +0200
>> +++ b/make/Javadoc.gmk	Thu Jun 02 16:20:35 2016 -0700
>> @@ -82,7 +82,7 @@
>> PLUGIN2_FIRST_COPYRIGHT_YEAR = 2007
>> JDKNET_FIRST_COPYRIGHT_YEAR = 2014
>> JACCESSAPI_FIRST_COPYRIGHT_YEAR = 2002
>> -
>> +JSOBJECT_FIRST_COPYRIGHT_YEAR = 1993
>>
>> # Oracle name
>> FULL_COMPANY_NAME = Oracle and/or its affiliates @@ -1031,6 +1031,64
>> @@
>>
>> #############################################################
>> #
>> +# jsobjectdocs
>> +#
>> +
>> +ALL_OTHER_TARGETS += jsobjectdoc
>> +
>> +JSOBJECT_DOCDIR := $(JRE_API_DOCSDIR)/plugin/jsobject
>> +JSOBJECT2COREAPI := ../../../$(JDKJRE2COREAPI) JSOBJECT_DOCTITLE :=
>> +Java$(TRADEMARK) JSObject Doc JSOBJECT_WINDOWTITLE := Java JSObect
>> +Doc JSOBJECT_HEADER := <strong>Java JSObject Doc</strong>
>> +JSOBJECT_BOTTOM := $(call
>> +CommonBottom,$(JSOBJECT_FIRST_COPYRIGHT_YEAR))
>> +# JSOBJECT_PKGS is located in NON_CORE_PKGS.gmk
>> +
>> +JSOBJECT_INDEX_HTML = $(JSOBJECT_DOCDIR)/index.html
>> +JSOBJECT_OPTIONS_FILE = $(DOCSTMPDIR)/jsobject.options
>> +JSOBJECT_PACKAGES_FILE = $(DOCSTMPDIR)/jsobject.packages
>> +
>> +# The modules required to be documented JSOBJECT_MODULES =
>> +jdk.jsobject
>> +
>> +jsobjectdocs: $(JSOBJECT_INDEX_HTML)
>> +
>> +# Set relative location to core api document root
>> +$(JSOBJECT_INDEX_HTML): GET2DOCSDIR=$(JSOBJECT2COREAPI)/..
>> +
>> +# Run javadoc if the index file is out of date or missing
>> +$(JSOBJECT_INDEX_HTML): $(JSOBJECT_OPTIONS_FILE) $(JSOBJECT_PACKAGES_FILE) $(COREAPI_INDEX_FILE)
>> +	$(prep-javadoc)
>> +	$(call JavadocSummary,$(JSOBJECT_OPTIONS_FILE),$(JSOBJECT_PACKAGES_FILE))
>> +	$(JAVADOC_CMD_SMALL) -d $(@D) \
>> +	    @$(JSOBJECT_OPTIONS_FILE) @$(JSOBJECT_PACKAGES_FILE)
>> +
>> +# Create file with javadoc options in it
>> +$(JSOBJECT_OPTIONS_FILE):
>> +	$(prep-target)
>> +	@($(call COMMON_JAVADOCFLAGS) ; \
>> +          $(call COMMON_JAVADOCTAGS) ; \
>> +	  $(call OptionOnly,-Xdoclint:none) ; \
>> +          $(call OptionPair,-system,none) ; \
>> +	  $(call OptionPair,-modulesourcepath,$(RELEASEDOCS_MODULESOURCEPATH)) ; \
>> +	  $(call OptionPair,-addmods,$(JSOBJECT_MODULES)) ; \
>> +	  $(call OptionPair,-encoding,ascii) ; \
>> +	  $(call OptionOnly,-nodeprecatedlist) ; \
>> +	  $(call OptionPair,-doctitle,$(JSOBJECT_DOCTITLE)) ; \
>> +	  $(call OptionPair,-windowtitle,$(JSOBJECT_WINDOWTITLE) $(DRAFT_WINTITLE)); \
>> +	  $(call OptionPair,-header,$(JSOBJECT_HEADER)$(DRAFT_HEADER)); \
>> +	  $(call OptionPair,-bottom,$(JSOBJECT_BOTTOM)$(DRAFT_BOTTOM)); \
>> +	  $(call OptionTrip,-linkoffline,$(JSOBJECT2COREAPI),$(COREAPI_DOCSDIR)/); \
>> +	) >> $@
>> +
>> +# Create a file with the package names in it
>> +$(JSOBJECT_PACKAGES_FILE): $(call PackageDependencies,$(JSOBJECT_PKGS))
>> +	$(prep-target)
>> +	$(call PackageFilter,$(JSOBJECT_PKGS))
>> +
>> +
>> +#############################################################
>> +#
>> # mgmtdocs
>> #
>>
>>
>> Best regards,
>> Daniil
>>
>>
>>
>> -----Original Message-----
>> From: David DeHaven
>> Sent: Wednesday, June 08, 2016 1:23 PM
>> To: Mandy Chung
>> Cc: Daniil Titov; Stuart Marks; Erik Joelsson; build-dev;
>> build-infa-dev at openjdk.java.net; awt-dev; Kevin Rushforth
>> Subject: Re: Review Request: 8156960 Deprecate
>> JSObject.getWindow(Applet) method
>>
>>
>> How about NON_CORE_PKGS.gmk for javadoc?
>>
>> Something like:
>>
>> diff --git a/make/common/NON_CORE_PKGS.gmk
>> b/make/common/NON_CORE_PKGS.gmk
>> --- a/make/common/NON_CORE_PKGS.gmk
>> +++ b/make/common/NON_CORE_PKGS.gmk
>> @@ -44,6 +44,8 @@
>>     org.w3c.dom.events \
>>     org.w3c.dom.views
>>
>> +JSOBJECT_PKGS = netscape.javascript
>> +
>> JDI_PKGS = com.sun.jdi \
>>     com.sun.jdi.event \
>>     com.sun.jdi.request \
>> @@ -113,6 +115,7 @@
>>
>> # non-core packages in rt.jar
>> NON_CORE_PKGS = $(DOMAPI_PKGS) \
>> +    $(JSOBJECT_PKGS) \
>>     $(MGMT_PKGS) \
>>     $(JAAS_PKGS) \
>>     $(JGSS_PKGS) \
>>
>> -DrD-
>>
>>> The client team owns jdk.jsobject module and so I add awt-dev to this thread.  And bcc jdk9-dev.
>>>
>>> It is not Java SE API and it should not add to CORE-PKGS.gmk.  As for @Deprecated, I believe the plan is to remove the getWindows method in a future release. Kevin and Dave can confirm.
>>>
>>> Mandy
>>>
>>>> On Jun 8, 2016, at 12:33 PM, Daniil Titov <daniil.x.titov at oracle.com> wrote:
>>>>
>>>> Hello,
>>>>
>>>>
>>>>
>>>> Please review the fix for JDK 9.
>>>>
>>>>
>>>>
>>>> The fix adds @Deprecated annotation to netscape.javascript.JSObject.getWindow(Applet) method and ensures that netscape.javascript package is included in the generated docs.
>>>>
>>>>
>>>>
>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8156960
>>>>
>>>>
>>>>
>>>> Webrev:   http://cr.openjdk.java.net/~dtitov/8156960/jdk/webrev.00/
>>>>
>>>>        http://cr.openjdk.java.net/~dtitov/8156960/webrev.00/
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> Best regards,
>>>>
>>>> Daniil
>>>
>>
>

From kumar.x.srinivasan at oracle.com  Fri Jun 10 17:51:28 2016
From: kumar.x.srinivasan at oracle.com (Kumar Srinivasan)
Date: Fri, 10 Jun 2016 10:51:28 -0700
Subject: <AWT Dev> RFR: 8158458: Update references from "1.9" to "9"
In-Reply-To: <debc6713-f24e-4483-94fa-707853742266@default>
References: <debc6713-f24e-4483-94fa-707853742266@default>
Message-ID: <575AFE20.7080607@oracle.com>


Hi Iris,

Apologies for the tardy reply, the HiddenTree change looks fine.

Thanks
Kumar

> Hi.
>
> I'm taking another pass at replacing instances of "@since 1.9" with
> "@since 9" and discovered a couple of jdk (AWT?) and langtools (DocTree)
> files which need to be updated.  I've filed the following but to
> address this problem:
>
>      8158458: Update references from "1.9" to "9" (closed code))
>      https://bugs.openjdk.java.net/browse/JDK-8158458
>
> This is the necessary diff, against jdk9/dev:
>
> [/w/iclark/verona/javadoc/jdk]:
> diff -r 0bd06ec69c5b src/java.desktop/macosx/classes/com/apple/eawt/Application.java
> --- a/src/java.desktop/macosx/classes/com/apple/eawt/Application.java Wed Jun 01 11:22:06 2016 -0700
> +++ b/src/java.desktop/macosx/classes/com/apple/eawt/Application.java Wed Jun 01 17:40:09 2016 -0700
> @@ -372,7 +372,7 @@
>    * Acceptable values are from 0 to 100, any other disables progress indication.
>    *
>    * @param value progress value
> - * @since 1.9
> + * @since 9
>        */
>       public void setDockIconProgress(final int value) {
>           iconHandler.setDockIconProgress(value);
>
> [/w/iclark/verona/javadoc/langtools]:
> diff -r 2d1a6b746310 src/jdk.compiler/share/classes/com/sun/source/doctree/HiddenTree.java
> --- a/src/jdk.compiler/share/classes/com/sun/source/doctree/HiddenTree.java Wed Jun 01 12:39:24 2016 +0100
> +++ b/src/jdk.compiler/share/classes/com/sun/source/doctree/HiddenTree.java Wed Jun 01 17:40:09 2016 -0700
> @@ -34,7 +34,7 @@
>    * <p>
>    * &#064;hidden
>    *
> - * @since 1.9
> + * @since 9
>    */
>   public interface HiddenTree extends BlockTagTree {
>       /**
>
> Build and test runs show no regressions.
>
> Thanks,
> Iris


From david.dehaven at oracle.com  Fri Jun 10 17:56:05 2016
From: david.dehaven at oracle.com (David DeHaven)
Date: Fri, 10 Jun 2016 10:56:05 -0700
Subject: <AWT Dev> Review Request: 8156960 Deprecate
	JSObject.getWindow(Applet) method
In-Reply-To: <3d7b40f9-6c2c-340d-cd75-0050ae0d857c@oracle.com>
References: <1f05a2b9-a68b-4684-a58a-163189c710af@default>
	<FDD6B460-8071-40CA-8FC3-AECF9E0C4ABF@oracle.com>
	<6CB5C96E-8B7F-4093-BA02-94702BA53047@oracle.com>
	<99907f0c-961d-4d66-950f-9b4de4fc96f7@default>
	<EAF37B66-F1D5-44D0-82AB-DFB4120AB8E4@oracle.com>
	<61539153-a0c6-474d-aded-d34b6266a1c1@default>
	<3d7b40f9-6c2c-340d-cd75-0050ae0d857c@oracle.com>
Message-ID: <F54ED567-9778-47B0-97C5-C9F68ACE4ADB@oracle.com>


That was also my understanding. I'm a bit surprised this is coming up since I thought we'd settled that when deprecating Applet...

-DrD-

> Hi, sorry I had missed this earlier.
> 
> It's surprising if forRemoval=true were to be added to this API when the rest of the Applet API has forRemoval=false. Is it the intent, for example, to have JSObject.getWindow() removed from JDK 10 but to have the rest of the Applet API remain?
> 
> My understanding of the plan was to deprecate the Applet API in JDK 9 with forRemoval=false. Then, in a future release, when removal plans become more definite, to change forRemoval to true, and in a subsequent release, to remove the Applet APIs. I'd think that plan would apply here as well.
> 
> Put another way, I'd recommend that we set forRemoval=true only when the plan is more definite than "we plan to remove this in some future, as yet unspecified release."
> 
> s'marks
> 
> 
> On 6/8/16 5:34 PM, Daniil Titov wrote:
>> Hello,
>> 
>> Please review the new version of the fix for JDK9.
>> 
>> 1. "forRemoval = true" is added to @Deprecated annotation for JSObject.getWindow(Applet) method.
>> 2.  A new doc bundle for JSObject documentation is added in the docs build.
>> 
>> Webrev: http://cr.openjdk.java.net/~dtitov/8156960/jdk/webrev.01
>>        http://cr.openjdk.java.net/~dtitov/8156960/webrev.01
>> 
>> 
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8156960
>> 
>> Thank you!
>> 
>> Best regards,
>> Daniil
>> 
>> -----Original Message-----
>> From: Mandy Chung
>> Sent: Wednesday, June 08, 2016 3:09 PM
>> To: Daniil Titov
>> Cc: David Dehaven; Stuart Marks; Erik Joelsson; build-dev; build-infa-dev at openjdk.java.net; awt-dev; Kevin Rushforth
>> Subject: Re: Review Request: 8156960 Deprecate JSObject.getWindow(Applet) method
>> 
>> That?s right.  It requires to add a new doc bundle in the docs build.  What you did was the right direction.  Can you update the webrev?
>> 
>> FYI.  There is an effort under discussion to revisit the number of docs bundle generated and clean up the docs build.
>> 
>> Mandy
>> 
>>> On Jun 8, 2016, at 2:48 PM, Daniil Titov <daniil.x.titov at oracle.com> wrote:
>>> 
>>> NON_CORE_PKGS variable is not used in make/Javadoc.gmk, so just adding a new package in this variable will not make this package included in any docs. We will need to create a new javadoc target for JSObject documentation ( or add it to some existing target, but it doesn't look like there is one that fits it). For example:
>>> 
>>> 
>>> diff -r 389c2d2842a5 make/Javadoc.gmk
>>> --- a/make/Javadoc.gmk	Wed May 25 12:53:26 2016 +0200
>>> +++ b/make/Javadoc.gmk	Thu Jun 02 16:20:35 2016 -0700
>>> @@ -82,7 +82,7 @@
>>> PLUGIN2_FIRST_COPYRIGHT_YEAR = 2007
>>> JDKNET_FIRST_COPYRIGHT_YEAR = 2014
>>> JACCESSAPI_FIRST_COPYRIGHT_YEAR = 2002
>>> -
>>> +JSOBJECT_FIRST_COPYRIGHT_YEAR = 1993
>>> 
>>> # Oracle name
>>> FULL_COMPANY_NAME = Oracle and/or its affiliates @@ -1031,6 +1031,64
>>> @@
>>> 
>>> #############################################################
>>> #
>>> +# jsobjectdocs
>>> +#
>>> +
>>> +ALL_OTHER_TARGETS += jsobjectdoc
>>> +
>>> +JSOBJECT_DOCDIR := $(JRE_API_DOCSDIR)/plugin/jsobject
>>> +JSOBJECT2COREAPI := ../../../$(JDKJRE2COREAPI) JSOBJECT_DOCTITLE :=
>>> +Java$(TRADEMARK) JSObject Doc JSOBJECT_WINDOWTITLE := Java JSObect
>>> +Doc JSOBJECT_HEADER := <strong>Java JSObject Doc</strong>
>>> +JSOBJECT_BOTTOM := $(call
>>> +CommonBottom,$(JSOBJECT_FIRST_COPYRIGHT_YEAR))
>>> +# JSOBJECT_PKGS is located in NON_CORE_PKGS.gmk
>>> +
>>> +JSOBJECT_INDEX_HTML = $(JSOBJECT_DOCDIR)/index.html
>>> +JSOBJECT_OPTIONS_FILE = $(DOCSTMPDIR)/jsobject.options
>>> +JSOBJECT_PACKAGES_FILE = $(DOCSTMPDIR)/jsobject.packages
>>> +
>>> +# The modules required to be documented JSOBJECT_MODULES =
>>> +jdk.jsobject
>>> +
>>> +jsobjectdocs: $(JSOBJECT_INDEX_HTML)
>>> +
>>> +# Set relative location to core api document root
>>> +$(JSOBJECT_INDEX_HTML): GET2DOCSDIR=$(JSOBJECT2COREAPI)/..
>>> +
>>> +# Run javadoc if the index file is out of date or missing
>>> +$(JSOBJECT_INDEX_HTML): $(JSOBJECT_OPTIONS_FILE) $(JSOBJECT_PACKAGES_FILE) $(COREAPI_INDEX_FILE)
>>> +	$(prep-javadoc)
>>> +	$(call JavadocSummary,$(JSOBJECT_OPTIONS_FILE),$(JSOBJECT_PACKAGES_FILE))
>>> +	$(JAVADOC_CMD_SMALL) -d $(@D) \
>>> +	    @$(JSOBJECT_OPTIONS_FILE) @$(JSOBJECT_PACKAGES_FILE)
>>> +
>>> +# Create file with javadoc options in it
>>> +$(JSOBJECT_OPTIONS_FILE):
>>> +	$(prep-target)
>>> +	@($(call COMMON_JAVADOCFLAGS) ; \
>>> +          $(call COMMON_JAVADOCTAGS) ; \
>>> +	  $(call OptionOnly,-Xdoclint:none) ; \
>>> +          $(call OptionPair,-system,none) ; \
>>> +	  $(call OptionPair,-modulesourcepath,$(RELEASEDOCS_MODULESOURCEPATH)) ; \
>>> +	  $(call OptionPair,-addmods,$(JSOBJECT_MODULES)) ; \
>>> +	  $(call OptionPair,-encoding,ascii) ; \
>>> +	  $(call OptionOnly,-nodeprecatedlist) ; \
>>> +	  $(call OptionPair,-doctitle,$(JSOBJECT_DOCTITLE)) ; \
>>> +	  $(call OptionPair,-windowtitle,$(JSOBJECT_WINDOWTITLE) $(DRAFT_WINTITLE)); \
>>> +	  $(call OptionPair,-header,$(JSOBJECT_HEADER)$(DRAFT_HEADER)); \
>>> +	  $(call OptionPair,-bottom,$(JSOBJECT_BOTTOM)$(DRAFT_BOTTOM)); \
>>> +	  $(call OptionTrip,-linkoffline,$(JSOBJECT2COREAPI),$(COREAPI_DOCSDIR)/); \
>>> +	) >> $@
>>> +
>>> +# Create a file with the package names in it
>>> +$(JSOBJECT_PACKAGES_FILE): $(call PackageDependencies,$(JSOBJECT_PKGS))
>>> +	$(prep-target)
>>> +	$(call PackageFilter,$(JSOBJECT_PKGS))
>>> +
>>> +
>>> +#############################################################
>>> +#
>>> # mgmtdocs
>>> #
>>> 
>>> 
>>> Best regards,
>>> Daniil
>>> 
>>> 
>>> 
>>> -----Original Message-----
>>> From: David DeHaven
>>> Sent: Wednesday, June 08, 2016 1:23 PM
>>> To: Mandy Chung
>>> Cc: Daniil Titov; Stuart Marks; Erik Joelsson; build-dev;
>>> build-infa-dev at openjdk.java.net; awt-dev; Kevin Rushforth
>>> Subject: Re: Review Request: 8156960 Deprecate
>>> JSObject.getWindow(Applet) method
>>> 
>>> 
>>> How about NON_CORE_PKGS.gmk for javadoc?
>>> 
>>> Something like:
>>> 
>>> diff --git a/make/common/NON_CORE_PKGS.gmk
>>> b/make/common/NON_CORE_PKGS.gmk
>>> --- a/make/common/NON_CORE_PKGS.gmk
>>> +++ b/make/common/NON_CORE_PKGS.gmk
>>> @@ -44,6 +44,8 @@
>>>    org.w3c.dom.events \
>>>    org.w3c.dom.views
>>> 
>>> +JSOBJECT_PKGS = netscape.javascript
>>> +
>>> JDI_PKGS = com.sun.jdi \
>>>    com.sun.jdi.event \
>>>    com.sun.jdi.request \
>>> @@ -113,6 +115,7 @@
>>> 
>>> # non-core packages in rt.jar
>>> NON_CORE_PKGS = $(DOMAPI_PKGS) \
>>> +    $(JSOBJECT_PKGS) \
>>>    $(MGMT_PKGS) \
>>>    $(JAAS_PKGS) \
>>>    $(JGSS_PKGS) \
>>> 
>>> -DrD-
>>> 
>>>> The client team owns jdk.jsobject module and so I add awt-dev to this thread.  And bcc jdk9-dev.
>>>> 
>>>> It is not Java SE API and it should not add to CORE-PKGS.gmk.  As for @Deprecated, I believe the plan is to remove the getWindows method in a future release. Kevin and Dave can confirm.
>>>> 
>>>> Mandy
>>>> 
>>>>> On Jun 8, 2016, at 12:33 PM, Daniil Titov <daniil.x.titov at oracle.com> wrote:
>>>>> 
>>>>> Hello,
>>>>> 
>>>>> 
>>>>> 
>>>>> Please review the fix for JDK 9.
>>>>> 
>>>>> 
>>>>> 
>>>>> The fix adds @Deprecated annotation to netscape.javascript.JSObject.getWindow(Applet) method and ensures that netscape.javascript package is included in the generated docs.
>>>>> 
>>>>> 
>>>>> 
>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8156960
>>>>> 
>>>>> 
>>>>> 
>>>>> Webrev:   http://cr.openjdk.java.net/~dtitov/8156960/jdk/webrev.00/
>>>>> 
>>>>>       http://cr.openjdk.java.net/~dtitov/8156960/webrev.00/
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> Best regards,
>>>>> 
>>>>> Daniil
>>>> 
>>> 
>> 


From daniil.x.titov at oracle.com  Fri Jun 10 17:57:37 2016
From: daniil.x.titov at oracle.com (Daniil Titov)
Date: Fri, 10 Jun 2016 10:57:37 -0700 (PDT)
Subject: <AWT Dev> Review Request: 8156960 Deprecate
 JSObject.getWindow(Applet) method
In-Reply-To: <3d7b40f9-6c2c-340d-cd75-0050ae0d857c@oracle.com>
References: <1f05a2b9-a68b-4684-a58a-163189c710af@default>
	<FDD6B460-8071-40CA-8FC3-AECF9E0C4ABF@oracle.com>
	<6CB5C96E-8B7F-4093-BA02-94702BA53047@oracle.com>
	<99907f0c-961d-4d66-950f-9b4de4fc96f7@default>
	<EAF37B66-F1D5-44D0-82AB-DFB4120AB8E4@oracle.com>
	<61539153-a0c6-474d-aded-d34b6266a1c1@default>
	<3d7b40f9-6c2c-340d-cd75-0050ae0d857c@oracle.com>
Message-ID: <291714b8-0703-4d29-9486-b2cc7c868321@default>

Thank you, Stuart!


Please review the new version of the patch that has "forRemoval=true" removed.


Webrev: http://cr.openjdk.java.net/~dtitov/8156960/jdk/webrev.04/
        http://cr.openjdk.java.net/~dtitov/8156960/webrev.04/

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


Best regards,
Daniil



-----Original Message-----
From: Stuart Marks 
Sent: Friday, June 10, 2016 9:58 AM
To: Daniil Titov
Cc: Mandy Chung; David Dehaven; Erik Joelsson; build-dev; build-infa-dev at openjdk.java.net; awt-dev; Kevin Rushforth
Subject: Re: Review Request: 8156960 Deprecate JSObject.getWindow(Applet) method

Hi, sorry I had missed this earlier.

It's surprising if forRemoval=true were to be added to this API when the rest of the Applet API has forRemoval=false. Is it the intent, for example, to have
JSObject.getWindow() removed from JDK 10 but to have the rest of the Applet API remain?

My understanding of the plan was to deprecate the Applet API in JDK 9 with forRemoval=false. Then, in a future release, when removal plans become more definite, to change forRemoval to true, and in a subsequent release, to remove the Applet APIs. I'd think that plan would apply here as well.

Put another way, I'd recommend that we set forRemoval=true only when the plan is more definite than "we plan to remove this in some future, as yet unspecified release."

s'marks


On 6/8/16 5:34 PM, Daniil Titov wrote:
> Hello,
>
> Please review the new version of the fix for JDK9.
>
> 1. "forRemoval = true" is added to @Deprecated annotation for JSObject.getWindow(Applet) method.
> 2.  A new doc bundle for JSObject documentation is added in the docs build.
>
> Webrev: http://cr.openjdk.java.net/~dtitov/8156960/jdk/webrev.01
>         http://cr.openjdk.java.net/~dtitov/8156960/webrev.01
>
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8156960
>
> Thank you!
>
> Best regards,
> Daniil
>
> -----Original Message-----
> From: Mandy Chung
> Sent: Wednesday, June 08, 2016 3:09 PM
> To: Daniil Titov
> Cc: David Dehaven; Stuart Marks; Erik Joelsson; build-dev; 
> build-infa-dev at openjdk.java.net; awt-dev; Kevin Rushforth
> Subject: Re: Review Request: 8156960 Deprecate 
> JSObject.getWindow(Applet) method
>
> That?s right.  It requires to add a new doc bundle in the docs build.  What you did was the right direction.  Can you update the webrev?
>
> FYI.  There is an effort under discussion to revisit the number of docs bundle generated and clean up the docs build.
>
> Mandy
>
>> On Jun 8, 2016, at 2:48 PM, Daniil Titov <daniil.x.titov at oracle.com> wrote:
>>
>> NON_CORE_PKGS variable is not used in make/Javadoc.gmk, so just adding a new package in this variable will not make this package included in any docs. We will need to create a new javadoc target for JSObject documentation ( or add it to some existing target, but it doesn't look like there is one that fits it). For example:
>>
>>
>> diff -r 389c2d2842a5 make/Javadoc.gmk
>> --- a/make/Javadoc.gmk	Wed May 25 12:53:26 2016 +0200
>> +++ b/make/Javadoc.gmk	Thu Jun 02 16:20:35 2016 -0700
>> @@ -82,7 +82,7 @@
>> PLUGIN2_FIRST_COPYRIGHT_YEAR = 2007
>> JDKNET_FIRST_COPYRIGHT_YEAR = 2014
>> JACCESSAPI_FIRST_COPYRIGHT_YEAR = 2002
>> -
>> +JSOBJECT_FIRST_COPYRIGHT_YEAR = 1993
>>
>> # Oracle name
>> FULL_COMPANY_NAME = Oracle and/or its affiliates @@ -1031,6 +1031,64 
>> @@
>>
>> #############################################################
>> #
>> +# jsobjectdocs
>> +#
>> +
>> +ALL_OTHER_TARGETS += jsobjectdoc
>> +
>> +JSOBJECT_DOCDIR := $(JRE_API_DOCSDIR)/plugin/jsobject
>> +JSOBJECT2COREAPI := ../../../$(JDKJRE2COREAPI) JSOBJECT_DOCTITLE :=
>> +Java$(TRADEMARK) JSObject Doc JSOBJECT_WINDOWTITLE := Java JSObect 
>> +Doc JSOBJECT_HEADER := <strong>Java JSObject Doc</strong> 
>> +JSOBJECT_BOTTOM := $(call
>> +CommonBottom,$(JSOBJECT_FIRST_COPYRIGHT_YEAR))
>> +# JSOBJECT_PKGS is located in NON_CORE_PKGS.gmk
>> +
>> +JSOBJECT_INDEX_HTML = $(JSOBJECT_DOCDIR)/index.html 
>> +JSOBJECT_OPTIONS_FILE = $(DOCSTMPDIR)/jsobject.options 
>> +JSOBJECT_PACKAGES_FILE = $(DOCSTMPDIR)/jsobject.packages
>> +
>> +# The modules required to be documented JSOBJECT_MODULES = 
>> +jdk.jsobject
>> +
>> +jsobjectdocs: $(JSOBJECT_INDEX_HTML)
>> +
>> +# Set relative location to core api document root
>> +$(JSOBJECT_INDEX_HTML): GET2DOCSDIR=$(JSOBJECT2COREAPI)/..
>> +
>> +# Run javadoc if the index file is out of date or missing
>> +$(JSOBJECT_INDEX_HTML): $(JSOBJECT_OPTIONS_FILE) $(JSOBJECT_PACKAGES_FILE) $(COREAPI_INDEX_FILE)
>> +	$(prep-javadoc)
>> +	$(call JavadocSummary,$(JSOBJECT_OPTIONS_FILE),$(JSOBJECT_PACKAGES_FILE))
>> +	$(JAVADOC_CMD_SMALL) -d $(@D) \
>> +	    @$(JSOBJECT_OPTIONS_FILE) @$(JSOBJECT_PACKAGES_FILE)
>> +
>> +# Create file with javadoc options in it
>> +$(JSOBJECT_OPTIONS_FILE):
>> +	$(prep-target)
>> +	@($(call COMMON_JAVADOCFLAGS) ; \
>> +          $(call COMMON_JAVADOCTAGS) ; \
>> +	  $(call OptionOnly,-Xdoclint:none) ; \
>> +          $(call OptionPair,-system,none) ; \
>> +	  $(call OptionPair,-modulesourcepath,$(RELEASEDOCS_MODULESOURCEPATH)) ; \
>> +	  $(call OptionPair,-addmods,$(JSOBJECT_MODULES)) ; \
>> +	  $(call OptionPair,-encoding,ascii) ; \
>> +	  $(call OptionOnly,-nodeprecatedlist) ; \
>> +	  $(call OptionPair,-doctitle,$(JSOBJECT_DOCTITLE)) ; \
>> +	  $(call OptionPair,-windowtitle,$(JSOBJECT_WINDOWTITLE) $(DRAFT_WINTITLE)); \
>> +	  $(call OptionPair,-header,$(JSOBJECT_HEADER)$(DRAFT_HEADER)); \
>> +	  $(call OptionPair,-bottom,$(JSOBJECT_BOTTOM)$(DRAFT_BOTTOM)); \
>> +	  $(call OptionTrip,-linkoffline,$(JSOBJECT2COREAPI),$(COREAPI_DOCSDIR)/); \
>> +	) >> $@
>> +
>> +# Create a file with the package names in it
>> +$(JSOBJECT_PACKAGES_FILE): $(call PackageDependencies,$(JSOBJECT_PKGS))
>> +	$(prep-target)
>> +	$(call PackageFilter,$(JSOBJECT_PKGS))
>> +
>> +
>> +#############################################################
>> +#
>> # mgmtdocs
>> #
>>
>>
>> Best regards,
>> Daniil
>>
>>
>>
>> -----Original Message-----
>> From: David DeHaven
>> Sent: Wednesday, June 08, 2016 1:23 PM
>> To: Mandy Chung
>> Cc: Daniil Titov; Stuart Marks; Erik Joelsson; build-dev; 
>> build-infa-dev at openjdk.java.net; awt-dev; Kevin Rushforth
>> Subject: Re: Review Request: 8156960 Deprecate
>> JSObject.getWindow(Applet) method
>>
>>
>> How about NON_CORE_PKGS.gmk for javadoc?
>>
>> Something like:
>>
>> diff --git a/make/common/NON_CORE_PKGS.gmk 
>> b/make/common/NON_CORE_PKGS.gmk
>> --- a/make/common/NON_CORE_PKGS.gmk
>> +++ b/make/common/NON_CORE_PKGS.gmk
>> @@ -44,6 +44,8 @@
>>     org.w3c.dom.events \
>>     org.w3c.dom.views
>>
>> +JSOBJECT_PKGS = netscape.javascript
>> +
>> JDI_PKGS = com.sun.jdi \
>>     com.sun.jdi.event \
>>     com.sun.jdi.request \
>> @@ -113,6 +115,7 @@
>>
>> # non-core packages in rt.jar
>> NON_CORE_PKGS = $(DOMAPI_PKGS) \
>> +    $(JSOBJECT_PKGS) \
>>     $(MGMT_PKGS) \
>>     $(JAAS_PKGS) \
>>     $(JGSS_PKGS) \
>>
>> -DrD-
>>
>>> The client team owns jdk.jsobject module and so I add awt-dev to this thread.  And bcc jdk9-dev.
>>>
>>> It is not Java SE API and it should not add to CORE-PKGS.gmk.  As for @Deprecated, I believe the plan is to remove the getWindows method in a future release. Kevin and Dave can confirm.
>>>
>>> Mandy
>>>
>>>> On Jun 8, 2016, at 12:33 PM, Daniil Titov <daniil.x.titov at oracle.com> wrote:
>>>>
>>>> Hello,
>>>>
>>>>
>>>>
>>>> Please review the fix for JDK 9.
>>>>
>>>>
>>>>
>>>> The fix adds @Deprecated annotation to netscape.javascript.JSObject.getWindow(Applet) method and ensures that netscape.javascript package is included in the generated docs.
>>>>
>>>>
>>>>
>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8156960
>>>>
>>>>
>>>>
>>>> Webrev:   http://cr.openjdk.java.net/~dtitov/8156960/jdk/webrev.00/
>>>>
>>>>        http://cr.openjdk.java.net/~dtitov/8156960/webrev.00/
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> Best regards,
>>>>
>>>> Daniil
>>>
>>
>

From mandy.chung at oracle.com  Fri Jun 10 18:30:59 2016
From: mandy.chung at oracle.com (Mandy Chung)
Date: Fri, 10 Jun 2016 11:30:59 -0700
Subject: <AWT Dev> Review Request: 8156960 Deprecate
	JSObject.getWindow(Applet) method
In-Reply-To: <3d7b40f9-6c2c-340d-cd75-0050ae0d857c@oracle.com>
References: <1f05a2b9-a68b-4684-a58a-163189c710af@default>
	<FDD6B460-8071-40CA-8FC3-AECF9E0C4ABF@oracle.com>
	<6CB5C96E-8B7F-4093-BA02-94702BA53047@oracle.com>
	<99907f0c-961d-4d66-950f-9b4de4fc96f7@default>
	<EAF37B66-F1D5-44D0-82AB-DFB4120AB8E4@oracle.com>
	<61539153-a0c6-474d-aded-d34b6266a1c1@default>
	<3d7b40f9-6c2c-340d-cd75-0050ae0d857c@oracle.com>
Message-ID: <798891A9-B63A-4DF1-B8FE-D9F9AAC4855A@oracle.com>

This method is about the fate of plugin support in a future regardless of the presence of java.applet.Applet API. The @deprecated note may cause the confusion.

What I understand from the past discussion with Kevin and Dave, we want this method to be removed in a future release - the earliest possible release would be N+1 when it?s deprecated for removal in JDK N.

I?ll let Kevin and Dave to clear this up and make the final call.

Mandy

> On Jun 10, 2016, at 9:58 AM, Stuart Marks <stuart.marks at oracle.com> wrote:
> 
> Hi, sorry I had missed this earlier.
> 
> It's surprising if forRemoval=true were to be added to this API when the rest of the Applet API has forRemoval=false. Is it the intent, for example, to have JSObject.getWindow() removed from JDK 10 but to have the rest of the Applet API remain?
> 
> My understanding of the plan was to deprecate the Applet API in JDK 9 with forRemoval=false. Then, in a future release, when removal plans become more definite, to change forRemoval to true, and in a subsequent release, to remove the Applet APIs. I'd think that plan would apply here as well.
> 
> Put another way, I'd recommend that we set forRemoval=true only when the plan is more definite than "we plan to remove this in some future, as yet unspecified release."
> 
> s'marks
> 
> 
> On 6/8/16 5:34 PM, Daniil Titov wrote:
>> Hello,
>> 
>> Please review the new version of the fix for JDK9.
>> 
>> 1. "forRemoval = true" is added to @Deprecated annotation for JSObject.getWindow(Applet) method.
>> 2.  A new doc bundle for JSObject documentation is added in the docs build.
>> 
>> Webrev: http://cr.openjdk.java.net/~dtitov/8156960/jdk/webrev.01
>>        http://cr.openjdk.java.net/~dtitov/8156960/webrev.01
>> 
>> 
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8156960
>> 
>> Thank you!
>> 
>> Best regards,
>> Daniil
>> 
>> -----Original Message-----
>> From: Mandy Chung
>> Sent: Wednesday, June 08, 2016 3:09 PM
>> To: Daniil Titov
>> Cc: David Dehaven; Stuart Marks; Erik Joelsson; build-dev; build-infa-dev at openjdk.java.net; awt-dev; Kevin Rushforth
>> Subject: Re: Review Request: 8156960 Deprecate JSObject.getWindow(Applet) method
>> 
>> That?s right.  It requires to add a new doc bundle in the docs build.  What you did was the right direction.  Can you update the webrev?
>> 
>> FYI.  There is an effort under discussion to revisit the number of docs bundle generated and clean up the docs build.
>> 
>> Mandy
>> 
>>> On Jun 8, 2016, at 2:48 PM, Daniil Titov <daniil.x.titov at oracle.com> wrote:
>>> 
>>> NON_CORE_PKGS variable is not used in make/Javadoc.gmk, so just adding a new package in this variable will not make this package included in any docs. We will need to create a new javadoc target for JSObject documentation ( or add it to some existing target, but it doesn't look like there is one that fits it). For example:
>>> 
>>> 
>>> diff -r 389c2d2842a5 make/Javadoc.gmk
>>> --- a/make/Javadoc.gmk	Wed May 25 12:53:26 2016 +0200
>>> +++ b/make/Javadoc.gmk	Thu Jun 02 16:20:35 2016 -0700
>>> @@ -82,7 +82,7 @@
>>> PLUGIN2_FIRST_COPYRIGHT_YEAR = 2007
>>> JDKNET_FIRST_COPYRIGHT_YEAR = 2014
>>> JACCESSAPI_FIRST_COPYRIGHT_YEAR = 2002
>>> -
>>> +JSOBJECT_FIRST_COPYRIGHT_YEAR = 1993
>>> 
>>> # Oracle name
>>> FULL_COMPANY_NAME = Oracle and/or its affiliates @@ -1031,6 +1031,64
>>> @@
>>> 
>>> #############################################################
>>> #
>>> +# jsobjectdocs
>>> +#
>>> +
>>> +ALL_OTHER_TARGETS += jsobjectdoc
>>> +
>>> +JSOBJECT_DOCDIR := $(JRE_API_DOCSDIR)/plugin/jsobject
>>> +JSOBJECT2COREAPI := ../../../$(JDKJRE2COREAPI) JSOBJECT_DOCTITLE :=
>>> +Java$(TRADEMARK) JSObject Doc JSOBJECT_WINDOWTITLE := Java JSObect
>>> +Doc JSOBJECT_HEADER := <strong>Java JSObject Doc</strong>
>>> +JSOBJECT_BOTTOM := $(call
>>> +CommonBottom,$(JSOBJECT_FIRST_COPYRIGHT_YEAR))
>>> +# JSOBJECT_PKGS is located in NON_CORE_PKGS.gmk
>>> +
>>> +JSOBJECT_INDEX_HTML = $(JSOBJECT_DOCDIR)/index.html
>>> +JSOBJECT_OPTIONS_FILE = $(DOCSTMPDIR)/jsobject.options
>>> +JSOBJECT_PACKAGES_FILE = $(DOCSTMPDIR)/jsobject.packages
>>> +
>>> +# The modules required to be documented JSOBJECT_MODULES =
>>> +jdk.jsobject
>>> +
>>> +jsobjectdocs: $(JSOBJECT_INDEX_HTML)
>>> +
>>> +# Set relative location to core api document root
>>> +$(JSOBJECT_INDEX_HTML): GET2DOCSDIR=$(JSOBJECT2COREAPI)/..
>>> +
>>> +# Run javadoc if the index file is out of date or missing
>>> +$(JSOBJECT_INDEX_HTML): $(JSOBJECT_OPTIONS_FILE) $(JSOBJECT_PACKAGES_FILE) $(COREAPI_INDEX_FILE)
>>> +	$(prep-javadoc)
>>> +	$(call JavadocSummary,$(JSOBJECT_OPTIONS_FILE),$(JSOBJECT_PACKAGES_FILE))
>>> +	$(JAVADOC_CMD_SMALL) -d $(@D) \
>>> +	    @$(JSOBJECT_OPTIONS_FILE) @$(JSOBJECT_PACKAGES_FILE)
>>> +
>>> +# Create file with javadoc options in it
>>> +$(JSOBJECT_OPTIONS_FILE):
>>> +	$(prep-target)
>>> +	@($(call COMMON_JAVADOCFLAGS) ; \
>>> +          $(call COMMON_JAVADOCTAGS) ; \
>>> +	  $(call OptionOnly,-Xdoclint:none) ; \
>>> +          $(call OptionPair,-system,none) ; \
>>> +	  $(call OptionPair,-modulesourcepath,$(RELEASEDOCS_MODULESOURCEPATH)) ; \
>>> +	  $(call OptionPair,-addmods,$(JSOBJECT_MODULES)) ; \
>>> +	  $(call OptionPair,-encoding,ascii) ; \
>>> +	  $(call OptionOnly,-nodeprecatedlist) ; \
>>> +	  $(call OptionPair,-doctitle,$(JSOBJECT_DOCTITLE)) ; \
>>> +	  $(call OptionPair,-windowtitle,$(JSOBJECT_WINDOWTITLE) $(DRAFT_WINTITLE)); \
>>> +	  $(call OptionPair,-header,$(JSOBJECT_HEADER)$(DRAFT_HEADER)); \
>>> +	  $(call OptionPair,-bottom,$(JSOBJECT_BOTTOM)$(DRAFT_BOTTOM)); \
>>> +	  $(call OptionTrip,-linkoffline,$(JSOBJECT2COREAPI),$(COREAPI_DOCSDIR)/); \
>>> +	) >> $@
>>> +
>>> +# Create a file with the package names in it
>>> +$(JSOBJECT_PACKAGES_FILE): $(call PackageDependencies,$(JSOBJECT_PKGS))
>>> +	$(prep-target)
>>> +	$(call PackageFilter,$(JSOBJECT_PKGS))
>>> +
>>> +
>>> +#############################################################
>>> +#
>>> # mgmtdocs
>>> #
>>> 
>>> 
>>> Best regards,
>>> Daniil
>>> 
>>> 
>>> 
>>> -----Original Message-----
>>> From: David DeHaven
>>> Sent: Wednesday, June 08, 2016 1:23 PM
>>> To: Mandy Chung
>>> Cc: Daniil Titov; Stuart Marks; Erik Joelsson; build-dev;
>>> build-infa-dev at openjdk.java.net; awt-dev; Kevin Rushforth
>>> Subject: Re: Review Request: 8156960 Deprecate
>>> JSObject.getWindow(Applet) method
>>> 
>>> 
>>> How about NON_CORE_PKGS.gmk for javadoc?
>>> 
>>> Something like:
>>> 
>>> diff --git a/make/common/NON_CORE_PKGS.gmk
>>> b/make/common/NON_CORE_PKGS.gmk
>>> --- a/make/common/NON_CORE_PKGS.gmk
>>> +++ b/make/common/NON_CORE_PKGS.gmk
>>> @@ -44,6 +44,8 @@
>>>    org.w3c.dom.events \
>>>    org.w3c.dom.views
>>> 
>>> +JSOBJECT_PKGS = netscape.javascript
>>> +
>>> JDI_PKGS = com.sun.jdi \
>>>    com.sun.jdi.event \
>>>    com.sun.jdi.request \
>>> @@ -113,6 +115,7 @@
>>> 
>>> # non-core packages in rt.jar
>>> NON_CORE_PKGS = $(DOMAPI_PKGS) \
>>> +    $(JSOBJECT_PKGS) \
>>>    $(MGMT_PKGS) \
>>>    $(JAAS_PKGS) \
>>>    $(JGSS_PKGS) \
>>> 
>>> -DrD-
>>> 
>>>> The client team owns jdk.jsobject module and so I add awt-dev to this thread.  And bcc jdk9-dev.
>>>> 
>>>> It is not Java SE API and it should not add to CORE-PKGS.gmk.  As for @Deprecated, I believe the plan is to remove the getWindows method in a future release. Kevin and Dave can confirm.
>>>> 
>>>> Mandy
>>>> 
>>>>> On Jun 8, 2016, at 12:33 PM, Daniil Titov <daniil.x.titov at oracle.com> wrote:
>>>>> 
>>>>> Hello,
>>>>> 
>>>>> 
>>>>> 
>>>>> Please review the fix for JDK 9.
>>>>> 
>>>>> 
>>>>> 
>>>>> The fix adds @Deprecated annotation to netscape.javascript.JSObject.getWindow(Applet) method and ensures that netscape.javascript package is included in the generated docs.
>>>>> 
>>>>> 
>>>>> 
>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8156960
>>>>> 
>>>>> 
>>>>> 
>>>>> Webrev:   http://cr.openjdk.java.net/~dtitov/8156960/jdk/webrev.00/
>>>>> 
>>>>>       http://cr.openjdk.java.net/~dtitov/8156960/webrev.00/
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> Best regards,
>>>>> 
>>>>> Daniil
>>>> 
>>> 
>> 


From alexander.zvegintsev at oracle.com  Fri Jun 10 20:54:02 2016
From: alexander.zvegintsev at oracle.com (Alexander Zvegintsev)
Date: Fri, 10 Jun 2016 23:54:02 +0300
Subject: <AWT Dev> CFV: New AWT Group Lead: Sergey Bylokhov
In-Reply-To: <bf5be81e-870c-5288-8ca2-e511d5d236e0@oracle.com>
References: <bf5be81e-870c-5288-8ca2-e511d5d236e0@oracle.com>
Message-ID: <151064a8-aab1-9b78-7ef4-199df4d119c9@oracle.com>

Vote: yes

--
Thanks,
Alexander.

On 10.06.2016 18:39, Artem Ananiev wrote:
> Hi, AWT team,
>
> I hereby nominate Sergey Bylokhov (OpenJDK user name: serb) to AWT 
> Group Lead [1].
>
> Sergey is a member of Java Client group at Oracle. He has been one of 
> the most active contributors to AWT (and other Java client libs: 
> Swing, Java2D, JavaFX, Java Sound, Java Beans) last few years and 
> demonstrated very deep knowledge of the library, its architecture and 
> implementation on various platforms.
>
> Votes are due by June 24, 2016.
>
> Only current AWT group members [2] are eligible to vote on this 
> nomination. Votes must be cast in the open by replying to this mailing 
> list.
>
> For Two-Thirds Majority voting instructions, see [3]
>
> [1] http://openjdk.java.net/bylaws#group-lead
> [2] http://openjdk.java.net/census#awt
> [3] http://openjdk.java.net/bylaws#two-thirds-majority
>
> Thanks,
>
> Artem


From stuart.marks at oracle.com  Fri Jun 10 21:32:22 2016
From: stuart.marks at oracle.com (Stuart Marks)
Date: Fri, 10 Jun 2016 14:32:22 -0700
Subject: <AWT Dev> Review Request: 8156960 Deprecate
 JSObject.getWindow(Applet) method
In-Reply-To: <798891A9-B63A-4DF1-B8FE-D9F9AAC4855A@oracle.com>
References: <1f05a2b9-a68b-4684-a58a-163189c710af@default>
	<FDD6B460-8071-40CA-8FC3-AECF9E0C4ABF@oracle.com>
	<6CB5C96E-8B7F-4093-BA02-94702BA53047@oracle.com>
	<99907f0c-961d-4d66-950f-9b4de4fc96f7@default>
	<EAF37B66-F1D5-44D0-82AB-DFB4120AB8E4@oracle.com>
	<61539153-a0c6-474d-aded-d34b6266a1c1@default>
	<3d7b40f9-6c2c-340d-cd75-0050ae0d857c@oracle.com>
	<798891A9-B63A-4DF1-B8FE-D9F9AAC4855A@oracle.com>
Message-ID: <1ec98193-7a52-c73a-e07c-dfed7d02c7a1@oracle.com>

Yes, ultimately the decision is up to Kevin and Dave (or whoever is in charge of 
technical decision-making in this area).

I wanted to provide some clarity on the use of forRemoval=true.

The specification is fairly neutral, saying only that there is "intent to 
remove" the API "in a future version."

In practice, for the JDK, I'm trying to make sure we set forRemoval=true only 
when there are definite plans for removal in the near future, for example, in 
the following release. I want to avoid a situation where there are a bunch of 
APIs in the JDK that have forRemoval=true but that are hanging around for 
several releases before they are eventually removed. (Or not.)

When I discussed this issue with the team with respect to the Applet API, I 
asked whether Applets would be removed in the next release (after JDK 9). There 
was some hemming and hawing, and eventually it emerged that there were still 
some narrow use cases that would probably still need to be supported even in the 
next release, and they weren't entirely sure when Applet could actually be 
removed. Based on that discussion we deprecated Applet with forRemoval=false in 
JDK 9, and we'll revisit this in the future when plans are more definite.

I had thought that the plugin and Applets were closely related enough so that 
they ought to be treated the same. This would argue that this API should also be 
deprecated in JDK 9 with forRemoval=false, and revisited at the same time as 
Applet. But I could be mistaken, and it might make sense to treat the plugin 
separately from Applet.

s'marks

On 6/10/16 11:30 AM, Mandy Chung wrote:
> This method is about the fate of plugin support in a future regardless of the presence of java.applet.Applet API. The @deprecated note may cause the confusion.
>
> What I understand from the past discussion with Kevin and Dave, we want this method to be removed in a future release - the earliest possible release would be N+1 when it?s deprecated for removal in JDK N.
>
> I?ll let Kevin and Dave to clear this up and make the final call.
>
> Mandy
>
>> On Jun 10, 2016, at 9:58 AM, Stuart Marks <stuart.marks at oracle.com> wrote:
>>
>> Hi, sorry I had missed this earlier.
>>
>> It's surprising if forRemoval=true were to be added to this API when the rest of the Applet API has forRemoval=false. Is it the intent, for example, to have JSObject.getWindow() removed from JDK 10 but to have the rest of the Applet API remain?
>>
>> My understanding of the plan was to deprecate the Applet API in JDK 9 with forRemoval=false. Then, in a future release, when removal plans become more definite, to change forRemoval to true, and in a subsequent release, to remove the Applet APIs. I'd think that plan would apply here as well.
>>
>> Put another way, I'd recommend that we set forRemoval=true only when the plan is more definite than "we plan to remove this in some future, as yet unspecified release."
>>
>> s'marks
>>
>>
>> On 6/8/16 5:34 PM, Daniil Titov wrote:
>>> Hello,
>>>
>>> Please review the new version of the fix for JDK9.
>>>
>>> 1. "forRemoval = true" is added to @Deprecated annotation for JSObject.getWindow(Applet) method.
>>> 2.  A new doc bundle for JSObject documentation is added in the docs build.
>>>
>>> Webrev: http://cr.openjdk.java.net/~dtitov/8156960/jdk/webrev.01
>>>        http://cr.openjdk.java.net/~dtitov/8156960/webrev.01
>>>
>>>
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8156960
>>>
>>> Thank you!
>>>
>>> Best regards,
>>> Daniil
>>>
>>> -----Original Message-----
>>> From: Mandy Chung
>>> Sent: Wednesday, June 08, 2016 3:09 PM
>>> To: Daniil Titov
>>> Cc: David Dehaven; Stuart Marks; Erik Joelsson; build-dev; build-infa-dev at openjdk.java.net; awt-dev; Kevin Rushforth
>>> Subject: Re: Review Request: 8156960 Deprecate JSObject.getWindow(Applet) method
>>>
>>> That?s right.  It requires to add a new doc bundle in the docs build.  What you did was the right direction.  Can you update the webrev?
>>>
>>> FYI.  There is an effort under discussion to revisit the number of docs bundle generated and clean up the docs build.
>>>
>>> Mandy
>>>
>>>> On Jun 8, 2016, at 2:48 PM, Daniil Titov <daniil.x.titov at oracle.com> wrote:
>>>>
>>>> NON_CORE_PKGS variable is not used in make/Javadoc.gmk, so just adding a new package in this variable will not make this package included in any docs. We will need to create a new javadoc target for JSObject documentation ( or add it to some existing target, but it doesn't look like there is one that fits it). For example:
>>>>
>>>>
>>>> diff -r 389c2d2842a5 make/Javadoc.gmk
>>>> --- a/make/Javadoc.gmk	Wed May 25 12:53:26 2016 +0200
>>>> +++ b/make/Javadoc.gmk	Thu Jun 02 16:20:35 2016 -0700
>>>> @@ -82,7 +82,7 @@
>>>> PLUGIN2_FIRST_COPYRIGHT_YEAR = 2007
>>>> JDKNET_FIRST_COPYRIGHT_YEAR = 2014
>>>> JACCESSAPI_FIRST_COPYRIGHT_YEAR = 2002
>>>> -
>>>> +JSOBJECT_FIRST_COPYRIGHT_YEAR = 1993
>>>>
>>>> # Oracle name
>>>> FULL_COMPANY_NAME = Oracle and/or its affiliates @@ -1031,6 +1031,64
>>>> @@
>>>>
>>>> #############################################################
>>>> #
>>>> +# jsobjectdocs
>>>> +#
>>>> +
>>>> +ALL_OTHER_TARGETS += jsobjectdoc
>>>> +
>>>> +JSOBJECT_DOCDIR := $(JRE_API_DOCSDIR)/plugin/jsobject
>>>> +JSOBJECT2COREAPI := ../../../$(JDKJRE2COREAPI) JSOBJECT_DOCTITLE :=
>>>> +Java$(TRADEMARK) JSObject Doc JSOBJECT_WINDOWTITLE := Java JSObect
>>>> +Doc JSOBJECT_HEADER := <strong>Java JSObject Doc</strong>
>>>> +JSOBJECT_BOTTOM := $(call
>>>> +CommonBottom,$(JSOBJECT_FIRST_COPYRIGHT_YEAR))
>>>> +# JSOBJECT_PKGS is located in NON_CORE_PKGS.gmk
>>>> +
>>>> +JSOBJECT_INDEX_HTML = $(JSOBJECT_DOCDIR)/index.html
>>>> +JSOBJECT_OPTIONS_FILE = $(DOCSTMPDIR)/jsobject.options
>>>> +JSOBJECT_PACKAGES_FILE = $(DOCSTMPDIR)/jsobject.packages
>>>> +
>>>> +# The modules required to be documented JSOBJECT_MODULES =
>>>> +jdk.jsobject
>>>> +
>>>> +jsobjectdocs: $(JSOBJECT_INDEX_HTML)
>>>> +
>>>> +# Set relative location to core api document root
>>>> +$(JSOBJECT_INDEX_HTML): GET2DOCSDIR=$(JSOBJECT2COREAPI)/..
>>>> +
>>>> +# Run javadoc if the index file is out of date or missing
>>>> +$(JSOBJECT_INDEX_HTML): $(JSOBJECT_OPTIONS_FILE) $(JSOBJECT_PACKAGES_FILE) $(COREAPI_INDEX_FILE)
>>>> +	$(prep-javadoc)
>>>> +	$(call JavadocSummary,$(JSOBJECT_OPTIONS_FILE),$(JSOBJECT_PACKAGES_FILE))
>>>> +	$(JAVADOC_CMD_SMALL) -d $(@D) \
>>>> +	    @$(JSOBJECT_OPTIONS_FILE) @$(JSOBJECT_PACKAGES_FILE)
>>>> +
>>>> +# Create file with javadoc options in it
>>>> +$(JSOBJECT_OPTIONS_FILE):
>>>> +	$(prep-target)
>>>> +	@($(call COMMON_JAVADOCFLAGS) ; \
>>>> +          $(call COMMON_JAVADOCTAGS) ; \
>>>> +	  $(call OptionOnly,-Xdoclint:none) ; \
>>>> +          $(call OptionPair,-system,none) ; \
>>>> +	  $(call OptionPair,-modulesourcepath,$(RELEASEDOCS_MODULESOURCEPATH)) ; \
>>>> +	  $(call OptionPair,-addmods,$(JSOBJECT_MODULES)) ; \
>>>> +	  $(call OptionPair,-encoding,ascii) ; \
>>>> +	  $(call OptionOnly,-nodeprecatedlist) ; \
>>>> +	  $(call OptionPair,-doctitle,$(JSOBJECT_DOCTITLE)) ; \
>>>> +	  $(call OptionPair,-windowtitle,$(JSOBJECT_WINDOWTITLE) $(DRAFT_WINTITLE)); \
>>>> +	  $(call OptionPair,-header,$(JSOBJECT_HEADER)$(DRAFT_HEADER)); \
>>>> +	  $(call OptionPair,-bottom,$(JSOBJECT_BOTTOM)$(DRAFT_BOTTOM)); \
>>>> +	  $(call OptionTrip,-linkoffline,$(JSOBJECT2COREAPI),$(COREAPI_DOCSDIR)/); \
>>>> +	) >> $@
>>>> +
>>>> +# Create a file with the package names in it
>>>> +$(JSOBJECT_PACKAGES_FILE): $(call PackageDependencies,$(JSOBJECT_PKGS))
>>>> +	$(prep-target)
>>>> +	$(call PackageFilter,$(JSOBJECT_PKGS))
>>>> +
>>>> +
>>>> +#############################################################
>>>> +#
>>>> # mgmtdocs
>>>> #
>>>>
>>>>
>>>> Best regards,
>>>> Daniil
>>>>
>>>>
>>>>
>>>> -----Original Message-----
>>>> From: David DeHaven
>>>> Sent: Wednesday, June 08, 2016 1:23 PM
>>>> To: Mandy Chung
>>>> Cc: Daniil Titov; Stuart Marks; Erik Joelsson; build-dev;
>>>> build-infa-dev at openjdk.java.net; awt-dev; Kevin Rushforth
>>>> Subject: Re: Review Request: 8156960 Deprecate
>>>> JSObject.getWindow(Applet) method
>>>>
>>>>
>>>> How about NON_CORE_PKGS.gmk for javadoc?
>>>>
>>>> Something like:
>>>>
>>>> diff --git a/make/common/NON_CORE_PKGS.gmk
>>>> b/make/common/NON_CORE_PKGS.gmk
>>>> --- a/make/common/NON_CORE_PKGS.gmk
>>>> +++ b/make/common/NON_CORE_PKGS.gmk
>>>> @@ -44,6 +44,8 @@
>>>>    org.w3c.dom.events \
>>>>    org.w3c.dom.views
>>>>
>>>> +JSOBJECT_PKGS = netscape.javascript
>>>> +
>>>> JDI_PKGS = com.sun.jdi \
>>>>    com.sun.jdi.event \
>>>>    com.sun.jdi.request \
>>>> @@ -113,6 +115,7 @@
>>>>
>>>> # non-core packages in rt.jar
>>>> NON_CORE_PKGS = $(DOMAPI_PKGS) \
>>>> +    $(JSOBJECT_PKGS) \
>>>>    $(MGMT_PKGS) \
>>>>    $(JAAS_PKGS) \
>>>>    $(JGSS_PKGS) \
>>>>
>>>> -DrD-
>>>>
>>>>> The client team owns jdk.jsobject module and so I add awt-dev to this thread.  And bcc jdk9-dev.
>>>>>
>>>>> It is not Java SE API and it should not add to CORE-PKGS.gmk.  As for @Deprecated, I believe the plan is to remove the getWindows method in a future release. Kevin and Dave can confirm.
>>>>>
>>>>> Mandy
>>>>>
>>>>>> On Jun 8, 2016, at 12:33 PM, Daniil Titov <daniil.x.titov at oracle.com> wrote:
>>>>>>
>>>>>> Hello,
>>>>>>
>>>>>>
>>>>>>
>>>>>> Please review the fix for JDK 9.
>>>>>>
>>>>>>
>>>>>>
>>>>>> The fix adds @Deprecated annotation to netscape.javascript.JSObject.getWindow(Applet) method and ensures that netscape.javascript package is included in the generated docs.
>>>>>>
>>>>>>
>>>>>>
>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8156960
>>>>>>
>>>>>>
>>>>>>
>>>>>> Webrev:   http://cr.openjdk.java.net/~dtitov/8156960/jdk/webrev.00/
>>>>>>
>>>>>>       http://cr.openjdk.java.net/~dtitov/8156960/webrev.00/
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> Best regards,
>>>>>>
>>>>>> Daniil
>>>>>
>>>>
>>>
>

From iris.clark at oracle.com  Fri Jun 10 21:46:09 2016
From: iris.clark at oracle.com (Iris Clark)
Date: Fri, 10 Jun 2016 14:46:09 -0700 (PDT)
Subject: <AWT Dev> RFR: 8158458: Update references from "1.9" to "9"
In-Reply-To: <575AFE20.7080607@oracle.com>
References: <debc6713-f24e-4483-94fa-707853742266@default>
	<575AFE20.7080607@oracle.com>
Message-ID: <445042d0-bba1-4d2f-bcdd-ae8a8be0c9ea@default>

Hi, Kumar.

Thanks for the Review.  

I think this change is now ready to push.  Jon has graciously offered to push these changes to jdk9/dev.

Regards,
iris

-----Original Message-----
From: Kumar Srinivasan 
Sent: Friday, June 10, 2016 10:51 AM
To: Iris Clark
Cc: compiler-dev at openjdk.java.net; awt-dev at openjdk.java.net
Subject: Re: RFR: 8158458: Update references from "1.9" to "9"


Hi Iris,

Apologies for the tardy reply, the HiddenTree change looks fine.

Thanks
Kumar

From manajit.halder at oracle.com  Mon Jun 13 11:29:04 2016
From: manajit.halder at oracle.com (Manajit Halder)
Date: Mon, 13 Jun 2016 16:59:04 +0530
Subject: <AWT Dev> <AWT dev>[9] Review request for JDK-8155740: [macosx]
	robot.keyPress and robot.keyRelease do not generate key event
	for Alt-Graph key VK_ALT_GRAPH.
In-Reply-To: <8655c6e1-0cfb-01b1-9081-f656970eeafc@oracle.com>
References: <538F0C0F-2C53-49CD-96B5-F78A794E3177@oracle.com>
	<5734A835.80908@oracle.com>
	<75CD4BD9-983C-4315-A5FC-3518C37BECF7@oracle.com>
	<573E06C5.5040807@oracle.com>
	<4CFAD53C-0E2F-43B4-854C-BFF1CEB944A5@oracle.com>
	<082a4f05-f5f2-01d0-5951-dc36b3dafbe5@oracle.com>
	<F3869358-BE09-42E0-8F39-ED1E40210B18@oracle.com>
	<8655c6e1-0cfb-01b1-9081-f656970eeafc@oracle.com>
Message-ID: <6C54D895-737D-4731-BE16-06F4658ADE49@oracle.com>

Hi Semyon and Sergey,

Code is modified as per the comment. Please review the modified webrev.

http://cr.openjdk.java.net/~mhalder/8155740/webrev.04/ <http://cr.openjdk.java.net/~mhalder/8155740/webrev.04/>

webrev.02 did not work because -
	The input nsFlag (modifier value) passed to the function NsKeyModifiersToJavaModifiers was not correct. The calculation of modifier was not wrong and hence wrong modifier values was returned from the method.

Test cases run:
Remaining two tests present in https://java.net/jira/browse/MACOSX_PORT <https://java.net/jira/browse/MACOSX_PORT> passed with the fix.
java/awt/Dialog/NestedDialogs/Modal/NestedModalDialogTest.java
java/awt/Dialog/NestedDialogs/Modeless/NestedModelessDialogTest.java

Thanks,
Manajit

> On 01-Jun-2016, at 11:24 pm, Semyon Sadetsky <semyon.sadetsky at oracle.com> wrote:
> 
> Hi Manaji,
> 
> Okay, back to werev.01.
> 
> Could you remove the comment in lines 262-268 since you assume that it is not true anymore and so CGEventCreateKeyboardEvent/CGEventPost will not cause any troubles.  
> Did you analyze why werev.02 fix did not pass those tests?
> 
> --Semyon
> 
> On 6/1/2016 4:46 PM, Manajit Halder wrote:
>> Hi  Semyon and Sergey,
>> 
>> After running the tests shared by Sergey I found that the second webrev (webrev.01) shared by me solves the problem.
>> 
>> http://cr.openjdk.java.net/~mhalder/8155740/webrev.01/ <http://cr.openjdk.java.net/%7Emhalder/8155740/webrev.01/>
>> 
>> Following tests were present in  <https://java.net/jira/browse/MACOSX_PORT-621>https://java.net/jira/browse/MACOSX_PORT-621 <https://java.net/jira/browse/MACOSX_PORT-621>:
>> closed/java/awt/KeyboardFocusmanager/ConsumeNextMnemonicKeyTypedTest/ConsumeNextMnemonicKeyTypedTest
>> java/awt/Dialog/NestedDialogs/Modal/NestedModalDialogTest.java
>> java/awt/Dialog/NestedDialogs/Modeless/NestedModelessDialogTest.java
>> 
>> But only first test (which is now present as part of open code) could be performed and the remaining tests were not found in the present code.
>> The first test fails due to another issue (JDK-8156460), whose fix is in progress and will be send for after this issue. This fix (JDK-8155740) is not related to the failure of the first test case.
>> 
>> The new location of the first test:
>> java/awt/KeyboardFocusmanager/ConsumeNextMnemonicKeyTypedTest/ConsumeNextMnemonicKeyTypedTest
>> 
>>  Please review the webrev.01.
>> 
>> Thanks,
>> Manajit
>> 
>>> On 26-May-2016, at 1:05 pm, Semyon Sadetsky <semyon.sadetsky at oracle.com <mailto:semyon.sadetsky at oracle.com>> wrote:
>>> 
>>> On 5/24/2016 2:09 PM, Manajit Halder wrote:
>>>> Hi Semyon,
>>>> 
>>>> It is not clear in the comment what was the problem, but it looks like the problem was observed just by using CGEventCreateKeyboardEvent/CGEventPost. In my case I don?t see any issues just by using the fix. It posts all the key events and all the key events are tested in the test file modified along with the fix.
>>> If you found the comment is not actual anymore, why did you preserve it?
>>> 
>>> --Semyon
>>>> 
>>>> Apart from the unknown problem mentioned in the existing comment this fix has following advantages:
>>>> Key codes for modifier key are required to distinguish between Alt and Alt-Gr key, which is not possible by using existing solution as it doesn?t post key codes for modifier keys. And also keys can?t be distinguished base on modifier value, which is same for both keys (Alt and Alt-Gr).
>>>> As mentioned in the existing comment CGEventCreateKeyboardEvent/CGEventPost is a better solution.
>>>> Online search about keyboard simulation showed that CGEventCreateKeyboardEvent/CGEventPost is used to simulate key stores in most of the cases.
>>>> Tested the key codes, didn?t observe any problem.
>>>> 
>>>> Regarding number keys not working with CGEventCreateKeyboardEvent/CGEventPost:
>>>> 	Solved the problem by providing event source to CGEventCreateKeyboardEvent. Code is modified. 
>>>> 
>>>> Please review the modified code:
>>>>  <http://cr.openjdk.java.net/%7Emhalder/8155740/webrev.02/>http://cr.openjdk.java.net/~mhalder/8155740/webrev.02/ <http://cr.openjdk.java.net/~mhalder/8155740/webrev.02/>
>>>> 
>>>> Thanks,
>>>> Manajit
>>>> 
>>>>> On 20-May-2016, at 12:02 am, Semyon Sadetsky <semyon.sadetsky at oracle.com <mailto:semyon.sadetsky at oracle.com>> wrote:
>>>>> 
>>>>> Hi Manajit,
>>>>> 
>>>>> Before your fix all key codes wa sent using
>>>>> 
>>>>> AXUIElementCreateSystemWide();
>>>>> 
>>>>> and CGEventCreateKeyboardEvent was commented or excluded from compilation:
>>>>> 
>>>>> 274 #if 0
>>>>>  275     CGEventRef event = CGEventCreateKeyboardEvent(NULL, keyCode, keyPressed);
>>>>>  276     if (event != NULL) {
>>>>>  277         CGEventPost(kCGSessionEventTap, event);
>>>>>  278         CFRelease(event);
>>>>>  279     }
>>>>>  280 #endif
>>>>> 
>>>>> I just wonder why it was done. Maybe that was some other issue fix. The comment above states:
>>>>> 
>>>>>  262      * Well, using CGEventCreateKeyboardEvent/CGEventPost would have been
>>>>>  263      * a better solution, however, it gives me all kinds of trouble and I have
>>>>>  264      * no idea how to solve them without inserting delays between simulated
>>>>>  265      * events. So, I've ended up disabling it and opted for another approach
>>>>>  266      * that uses Accessibility API instead.
>>>>> 
>>>>> I don't understand what trouble is mentioned in the comment above. But in your fix you've put the CGEventCreateKeyboardEvent back, may it return this trouble back?
>>>>> 
>>>>> Also as I understand Numpad number keys did not work as well. Could you add the corresponding test case since you provide a fix this extra issue?
>>>>> 
>>>>> --Semyon
>>>>> 
>>>>> 
>>>>> On 5/13/2016 11:50 PM, Manajit Halder wrote:
>>>>>> Hi Semyon,
>>>>>> 
>>>>>> The fix is changed a bit because it was observed that the modifier keys plus alphabet keys were not working together. In the modified fix only Num keys are posted by AXUIElementPostKeyboardEvent and remaining keys are posted by CGPostKeyboardEvent/CGEventPost. The fix is explained in the comment in file CRobot.m.
>>>>>> 
>>>>>> Please review the new changes:
>>>>>>  <http://cr.openjdk.java.net/%7Emhalder/8155740/webrev.01/>http://cr.openjdk.java.net/~mhalder/8155740/webrev.01/ <http://cr.openjdk.java.net/~mhalder/8155740/webrev.01/>
>>>>>> 
>>>>>> 
>>>>>> Answers to your questions:
>>>>>> 
>>>>>> What is difference between AXUIElementPostKeyboardEvent and CGEventCreateKeyboardEvent?
>>>>>> 
>>>>>> Difference as per the documentation:
>>>>>> 	AXUIElementPostKeyboardEvent is similar to CGPostKeyboardEvent (which synthesizes a low-level keyboard event on the local machine), but it allows you to specify the target application as opposed to always sending the events to the active application. If the system-wide accessibility object is passed in the application parameter, the event is sent to the active application. 
>>>>>> 
>>>>>> Difference behaviour as per the implementation observed while debugging the code:
>>>>>> 	
>>>>>> AXUIElementPostKeyboardEvent:
>>>>>> 	AXUIElementPostKeyboardEvent posts 0 key code for all the modifier keys with key codes 16, 17,18, 20, 157 and also for newly added modifier key VK_ALT_GRAPH. But it posts correct key code for all the remaining keys.
>>>>>> 	While debugging it was that for modifier keys keyDown and keyUp events are not generated, but flagsChanged event (flagsChanged: (NSEvent *)event) is generated. But for all other keys keyDown followed by keyUp events are generated.
>>>>>> 
>>>>>> CGEventCreateKeyboardEvent:
>>>>>> 	CGEventCreateKeyboardEvent posts correct key code for all the keys except for numeric keys (numbers 0 to 9 on normal keyboard). CGEventCreateKeyboardEvent                                   posts wrong key codes for the number keys 0 to 9. Instead of posting number key codes it posts Numpad key codes for the corresponding number key. For example Numpad0 key code is posted for number 0, Numpad1 key code is posted for number 1 and simillarly for remaining num keys.
>>>>>> 	
>>>>>> Why the latter was commented? Does it mean that valid modifier keys have not been sent by AWT robot?
>>>>>> 
>>>>>> I didn?t get your question clearly. If you meant why in the current implementation the later part (fix using CGPostKeyboardEvent) of fix was commented.
>>>>>> 	I am not very sure about it. As per the comment it is only clear that CGPostKeyboardEvent/CGEventPost would have been a better solution and I agree with that, perhaps reason could be related to the difference in behaviour observed while debugging the code as mentioned above.
>>>>>> 
>>>>>> Thanks,
>>>>>> Manajit
>>>>>> 
>>>>>>> Hi Manajit,
>>>>>>> 
>>>>>>> Just a few questions to clarify on the fix.
>>>>>>> What is difference between AXUIElementPostKeyboardEvent and CGEventCreateKeyboardEvent?
>>>>>> 	
>>>>>>> Why the latter was commented? Does it mean that valid modifier keys have not been sent by AWT robot?
>>>>>>> 
>>>>>>> --Semyon
>>>>>>> 
>>>>>>> 
>>>>>>> On 5/12/2016 10:45 AM, Manajit Halder wrote:
>>>>>>>> Hi All,
>>>>>>>> 
>>>>>>>> Kindly review the fix for JDK9.
>>>>>>>> 
>>>>>>>> Bug: 
>>>>>>>>  <https://bugs.openjdk.java.net/browse/JDK-8155740>https://bugs.openjdk.java.net/browse/JDK-8155740 <https://bugs.openjdk.java.net/browse/JDK-8155740>
>>>>>>>> 
>>>>>>>> Webrev: 
>>>>>>>>  <http://cr.openjdk.java.net/%7Emhalder/8155740/webrev.00/>http://cr.openjdk.java.net/~mhalder/8155740/webrev.00/ <http://cr.openjdk.java.net/~mhalder/8155740/webrev.00/>
>>>>>>>> 
>>>>>>>> Issue: 
>>>>>>>> [macosx] robot.keyPress and robot.keyRelease do not generate key event for Alt-Graph key VK_ALT_GRAPH.
>>>>>>>> 
>>>>>>>> Cause: 
>>>>>>>> VK_ALT_GRAPH is a new key added to the Mac OS X platform and it is not mapped to any key on the OS X platform.
>>>>>>>> 
>>>>>>>> Fix: 
>>>>>>>> VK_ALT_GRAPH is mapped to right option (OSX_RightOption) key on Mac OS X.
>>>>>>>> 
>>>>>>>> Method Java_sun_lwawt_macosx_CRobot_keyEvent is modified for the following reason:
>>>>>>>> AXUIElementPostKeyboardEvent posts 0 key code for all  the modifier keys with key codes (16, 17,18, 20, 157) and also for newly added modifier key VK_ALT_GRAPH.
>>>>>>>> But it posts correct key code for all the other keys. On the other hand CGEventCreateKeyboardEvent posts correct key code for all the modifier keys and 
>>>>>>>> hence it is used to post modifier key events and AXUIElementPostKeyboardEvent is used to post all the remaining key events.
>>>>>>>> 
>>>>>>>> Regards,
>>>>>>>> Manajit
>>>>>>> 
>>>>>> 
>>>>> 
>>>> 
>>> 
>> 
> 

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

From david.dehaven at oracle.com  Mon Jun 13 16:17:40 2016
From: david.dehaven at oracle.com (David DeHaven)
Date: Mon, 13 Jun 2016 09:17:40 -0700
Subject: <AWT Dev> Review Request: 8156960 Deprecate
	JSObject.getWindow(Applet) method
In-Reply-To: <1ec98193-7a52-c73a-e07c-dfed7d02c7a1@oracle.com>
References: <1f05a2b9-a68b-4684-a58a-163189c710af@default>
	<FDD6B460-8071-40CA-8FC3-AECF9E0C4ABF@oracle.com>
	<6CB5C96E-8B7F-4093-BA02-94702BA53047@oracle.com>
	<99907f0c-961d-4d66-950f-9b4de4fc96f7@default>
	<EAF37B66-F1D5-44D0-82AB-DFB4120AB8E4@oracle.com>
	<61539153-a0c6-474d-aded-d34b6266a1c1@default>
	<3d7b40f9-6c2c-340d-cd75-0050ae0d857c@oracle.com>
	<798891A9-B63A-4DF1-B8FE-D9F9AAC4855A@oracle.com>
	<1ec98193-7a52-c73a-e07c-dfed7d02c7a1@oracle.com>
Message-ID: <A6933CAA-732E-4EC4-9C78-97A12CAC20FD@oracle.com>

[removed bad email address..]

Ok, my understanding was that forRemoval was intended for the next release, so setting it to true meant we were saying "removing in JDK 10." If that's NOT the case then we should set it to true for this particular case since this method is tied specifically to the plugin and not Applet.

I just don't want to hear any whining when it comes around to JDK 11 and it hasn't been removed yet ;)

I still don't know about Applet as anyone using it outside of plugin has been very quiet and I suspect we WON'T hear anything until JDK 9 gets released and developers start using it, it seems safer to leave it false for now and revisit marking for removal in 10 when hopefully we've had some feedback.

-DrD-

> Yes, ultimately the decision is up to Kevin and Dave (or whoever is in charge of technical decision-making in this area).
> 
> I wanted to provide some clarity on the use of forRemoval=true.
> 
> The specification is fairly neutral, saying only that there is "intent to remove" the API "in a future version."
> 
> In practice, for the JDK, I'm trying to make sure we set forRemoval=true only when there are definite plans for removal in the near future, for example, in the following release. I want to avoid a situation where there are a bunch of APIs in the JDK that have forRemoval=true but that are hanging around for several releases before they are eventually removed. (Or not.)
> 
> When I discussed this issue with the team with respect to the Applet API, I asked whether Applets would be removed in the next release (after JDK 9). There was some hemming and hawing, and eventually it emerged that there were still some narrow use cases that would probably still need to be supported even in the next release, and they weren't entirely sure when Applet could actually be removed. Based on that discussion we deprecated Applet with forRemoval=false in JDK 9, and we'll revisit this in the future when plans are more definite.
> 
> I had thought that the plugin and Applets were closely related enough so that they ought to be treated the same. This would argue that this API should also be deprecated in JDK 9 with forRemoval=false, and revisited at the same time as Applet. But I could be mistaken, and it might make sense to treat the plugin separately from Applet.
> 
> s'marks
> 
> On 6/10/16 11:30 AM, Mandy Chung wrote:
>> This method is about the fate of plugin support in a future regardless of the presence of java.applet.Applet API. The @deprecated note may cause the confusion.
>> 
>> What I understand from the past discussion with Kevin and Dave, we want this method to be removed in a future release - the earliest possible release would be N+1 when it?s deprecated for removal in JDK N.
>> 
>> I?ll let Kevin and Dave to clear this up and make the final call.
>> 
>> Mandy
>> 
>>> On Jun 10, 2016, at 9:58 AM, Stuart Marks <stuart.marks at oracle.com> wrote:
>>> 
>>> Hi, sorry I had missed this earlier.
>>> 
>>> It's surprising if forRemoval=true were to be added to this API when the rest of the Applet API has forRemoval=false. Is it the intent, for example, to have JSObject.getWindow() removed from JDK 10 but to have the rest of the Applet API remain?
>>> 
>>> My understanding of the plan was to deprecate the Applet API in JDK 9 with forRemoval=false. Then, in a future release, when removal plans become more definite, to change forRemoval to true, and in a subsequent release, to remove the Applet APIs. I'd think that plan would apply here as well.
>>> 
>>> Put another way, I'd recommend that we set forRemoval=true only when the plan is more definite than "we plan to remove this in some future, as yet unspecified release."
>>> 
>>> s'marks
>>> 
>>> 
>>> On 6/8/16 5:34 PM, Daniil Titov wrote:
>>>> Hello,
>>>> 
>>>> Please review the new version of the fix for JDK9.
>>>> 
>>>> 1. "forRemoval = true" is added to @Deprecated annotation for JSObject.getWindow(Applet) method.
>>>> 2.  A new doc bundle for JSObject documentation is added in the docs build.
>>>> 
>>>> Webrev: http://cr.openjdk.java.net/~dtitov/8156960/jdk/webrev.01
>>>>       http://cr.openjdk.java.net/~dtitov/8156960/webrev.01
>>>> 
>>>> 
>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8156960
>>>> 
>>>> Thank you!
>>>> 
>>>> Best regards,
>>>> Daniil
>>>> 
>>>> -----Original Message-----
>>>> From: Mandy Chung
>>>> Sent: Wednesday, June 08, 2016 3:09 PM
>>>> To: Daniil Titov
>>>> Cc: David Dehaven; Stuart Marks; Erik Joelsson; build-dev; build-infa-dev at openjdk.java.net; awt-dev; Kevin Rushforth
>>>> Subject: Re: Review Request: 8156960 Deprecate JSObject.getWindow(Applet) method
>>>> 
>>>> That?s right.  It requires to add a new doc bundle in the docs build.  What you did was the right direction.  Can you update the webrev?
>>>> 
>>>> FYI.  There is an effort under discussion to revisit the number of docs bundle generated and clean up the docs build.
>>>> 
>>>> Mandy
>>>> 
>>>>> On Jun 8, 2016, at 2:48 PM, Daniil Titov <daniil.x.titov at oracle.com> wrote:
>>>>> 
>>>>> NON_CORE_PKGS variable is not used in make/Javadoc.gmk, so just adding a new package in this variable will not make this package included in any docs. We will need to create a new javadoc target for JSObject documentation ( or add it to some existing target, but it doesn't look like there is one that fits it). For example:
>>>>> 
>>>>> 
>>>>> diff -r 389c2d2842a5 make/Javadoc.gmk
>>>>> --- a/make/Javadoc.gmk	Wed May 25 12:53:26 2016 +0200
>>>>> +++ b/make/Javadoc.gmk	Thu Jun 02 16:20:35 2016 -0700
>>>>> @@ -82,7 +82,7 @@
>>>>> PLUGIN2_FIRST_COPYRIGHT_YEAR = 2007
>>>>> JDKNET_FIRST_COPYRIGHT_YEAR = 2014
>>>>> JACCESSAPI_FIRST_COPYRIGHT_YEAR = 2002
>>>>> -
>>>>> +JSOBJECT_FIRST_COPYRIGHT_YEAR = 1993
>>>>> 
>>>>> # Oracle name
>>>>> FULL_COMPANY_NAME = Oracle and/or its affiliates @@ -1031,6 +1031,64
>>>>> @@
>>>>> 
>>>>> #############################################################
>>>>> #
>>>>> +# jsobjectdocs
>>>>> +#
>>>>> +
>>>>> +ALL_OTHER_TARGETS += jsobjectdoc
>>>>> +
>>>>> +JSOBJECT_DOCDIR := $(JRE_API_DOCSDIR)/plugin/jsobject
>>>>> +JSOBJECT2COREAPI := ../../../$(JDKJRE2COREAPI) JSOBJECT_DOCTITLE :=
>>>>> +Java$(TRADEMARK) JSObject Doc JSOBJECT_WINDOWTITLE := Java JSObect
>>>>> +Doc JSOBJECT_HEADER := <strong>Java JSObject Doc</strong>
>>>>> +JSOBJECT_BOTTOM := $(call
>>>>> +CommonBottom,$(JSOBJECT_FIRST_COPYRIGHT_YEAR))
>>>>> +# JSOBJECT_PKGS is located in NON_CORE_PKGS.gmk
>>>>> +
>>>>> +JSOBJECT_INDEX_HTML = $(JSOBJECT_DOCDIR)/index.html
>>>>> +JSOBJECT_OPTIONS_FILE = $(DOCSTMPDIR)/jsobject.options
>>>>> +JSOBJECT_PACKAGES_FILE = $(DOCSTMPDIR)/jsobject.packages
>>>>> +
>>>>> +# The modules required to be documented JSOBJECT_MODULES =
>>>>> +jdk.jsobject
>>>>> +
>>>>> +jsobjectdocs: $(JSOBJECT_INDEX_HTML)
>>>>> +
>>>>> +# Set relative location to core api document root
>>>>> +$(JSOBJECT_INDEX_HTML): GET2DOCSDIR=$(JSOBJECT2COREAPI)/..
>>>>> +
>>>>> +# Run javadoc if the index file is out of date or missing
>>>>> +$(JSOBJECT_INDEX_HTML): $(JSOBJECT_OPTIONS_FILE) $(JSOBJECT_PACKAGES_FILE) $(COREAPI_INDEX_FILE)
>>>>> +	$(prep-javadoc)
>>>>> +	$(call JavadocSummary,$(JSOBJECT_OPTIONS_FILE),$(JSOBJECT_PACKAGES_FILE))
>>>>> +	$(JAVADOC_CMD_SMALL) -d $(@D) \
>>>>> +	    @$(JSOBJECT_OPTIONS_FILE) @$(JSOBJECT_PACKAGES_FILE)
>>>>> +
>>>>> +# Create file with javadoc options in it
>>>>> +$(JSOBJECT_OPTIONS_FILE):
>>>>> +	$(prep-target)
>>>>> +	@($(call COMMON_JAVADOCFLAGS) ; \
>>>>> +          $(call COMMON_JAVADOCTAGS) ; \
>>>>> +	  $(call OptionOnly,-Xdoclint:none) ; \
>>>>> +          $(call OptionPair,-system,none) ; \
>>>>> +	  $(call OptionPair,-modulesourcepath,$(RELEASEDOCS_MODULESOURCEPATH)) ; \
>>>>> +	  $(call OptionPair,-addmods,$(JSOBJECT_MODULES)) ; \
>>>>> +	  $(call OptionPair,-encoding,ascii) ; \
>>>>> +	  $(call OptionOnly,-nodeprecatedlist) ; \
>>>>> +	  $(call OptionPair,-doctitle,$(JSOBJECT_DOCTITLE)) ; \
>>>>> +	  $(call OptionPair,-windowtitle,$(JSOBJECT_WINDOWTITLE) $(DRAFT_WINTITLE)); \
>>>>> +	  $(call OptionPair,-header,$(JSOBJECT_HEADER)$(DRAFT_HEADER)); \
>>>>> +	  $(call OptionPair,-bottom,$(JSOBJECT_BOTTOM)$(DRAFT_BOTTOM)); \
>>>>> +	  $(call OptionTrip,-linkoffline,$(JSOBJECT2COREAPI),$(COREAPI_DOCSDIR)/); \
>>>>> +	) >> $@
>>>>> +
>>>>> +# Create a file with the package names in it
>>>>> +$(JSOBJECT_PACKAGES_FILE): $(call PackageDependencies,$(JSOBJECT_PKGS))
>>>>> +	$(prep-target)
>>>>> +	$(call PackageFilter,$(JSOBJECT_PKGS))
>>>>> +
>>>>> +
>>>>> +#############################################################
>>>>> +#
>>>>> # mgmtdocs
>>>>> #
>>>>> 
>>>>> 
>>>>> Best regards,
>>>>> Daniil
>>>>> 
>>>>> 
>>>>> 
>>>>> -----Original Message-----
>>>>> From: David DeHaven
>>>>> Sent: Wednesday, June 08, 2016 1:23 PM
>>>>> To: Mandy Chung
>>>>> Cc: Daniil Titov; Stuart Marks; Erik Joelsson; build-dev;
>>>>> build-infa-dev at openjdk.java.net; awt-dev; Kevin Rushforth
>>>>> Subject: Re: Review Request: 8156960 Deprecate
>>>>> JSObject.getWindow(Applet) method
>>>>> 
>>>>> 
>>>>> How about NON_CORE_PKGS.gmk for javadoc?
>>>>> 
>>>>> Something like:
>>>>> 
>>>>> diff --git a/make/common/NON_CORE_PKGS.gmk
>>>>> b/make/common/NON_CORE_PKGS.gmk
>>>>> --- a/make/common/NON_CORE_PKGS.gmk
>>>>> +++ b/make/common/NON_CORE_PKGS.gmk
>>>>> @@ -44,6 +44,8 @@
>>>>>   org.w3c.dom.events \
>>>>>   org.w3c.dom.views
>>>>> 
>>>>> +JSOBJECT_PKGS = netscape.javascript
>>>>> +
>>>>> JDI_PKGS = com.sun.jdi \
>>>>>   com.sun.jdi.event \
>>>>>   com.sun.jdi.request \
>>>>> @@ -113,6 +115,7 @@
>>>>> 
>>>>> # non-core packages in rt.jar
>>>>> NON_CORE_PKGS = $(DOMAPI_PKGS) \
>>>>> +    $(JSOBJECT_PKGS) \
>>>>>   $(MGMT_PKGS) \
>>>>>   $(JAAS_PKGS) \
>>>>>   $(JGSS_PKGS) \
>>>>> 
>>>>> -DrD-
>>>>> 
>>>>>> The client team owns jdk.jsobject module and so I add awt-dev to this thread.  And bcc jdk9-dev.
>>>>>> 
>>>>>> It is not Java SE API and it should not add to CORE-PKGS.gmk.  As for @Deprecated, I believe the plan is to remove the getWindows method in a future release. Kevin and Dave can confirm.
>>>>>> 
>>>>>> Mandy
>>>>>> 
>>>>>>> On Jun 8, 2016, at 12:33 PM, Daniil Titov <daniil.x.titov at oracle.com> wrote:
>>>>>>> 
>>>>>>> Hello,
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> Please review the fix for JDK 9.
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> The fix adds @Deprecated annotation to netscape.javascript.JSObject.getWindow(Applet) method and ensures that netscape.javascript package is included in the generated docs.
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8156960
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> Webrev:   http://cr.openjdk.java.net/~dtitov/8156960/jdk/webrev.00/
>>>>>>> 
>>>>>>>      http://cr.openjdk.java.net/~dtitov/8156960/webrev.00/
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> Best regards,
>>>>>>> 
>>>>>>> Daniil
>>>>>> 
>>>>> 
>>>> 
>> 


From kevin.rushforth at oracle.com  Mon Jun 13 16:23:36 2016
From: kevin.rushforth at oracle.com (Kevin Rushforth)
Date: Mon, 13 Jun 2016 09:23:36 -0700
Subject: <AWT Dev> Review Request: 8156960 Deprecate
 JSObject.getWindow(Applet) method
In-Reply-To: <A6933CAA-732E-4EC4-9C78-97A12CAC20FD@oracle.com>
References: <1f05a2b9-a68b-4684-a58a-163189c710af@default>
	<FDD6B460-8071-40CA-8FC3-AECF9E0C4ABF@oracle.com>
	<6CB5C96E-8B7F-4093-BA02-94702BA53047@oracle.com>
	<99907f0c-961d-4d66-950f-9b4de4fc96f7@default>
	<EAF37B66-F1D5-44D0-82AB-DFB4120AB8E4@oracle.com>
	<61539153-a0c6-474d-aded-d34b6266a1c1@default>
	<3d7b40f9-6c2c-340d-cd75-0050ae0d857c@oracle.com>
	<798891A9-B63A-4DF1-B8FE-D9F9AAC4855A@oracle.com>
	<1ec98193-7a52-c73a-e07c-dfed7d02c7a1@oracle.com>
	<A6933CAA-732E-4EC4-9C78-97A12CAC20FD@oracle.com>
Message-ID: <575EDE08.2090902@oracle.com>

That makes sense to me. I very much hope we can remove the getWindow 
method in JDK 10.

-- Kevin


David DeHaven wrote:
> [removed bad email address..]
>
> Ok, my understanding was that forRemoval was intended for the next release, so setting it to true meant we were saying "removing in JDK 10." If that's NOT the case then we should set it to true for this particular case since this method is tied specifically to the plugin and not Applet.
>
> I just don't want to hear any whining when it comes around to JDK 11 and it hasn't been removed yet ;)
>
> I still don't know about Applet as anyone using it outside of plugin has been very quiet and I suspect we WON'T hear anything until JDK 9 gets released and developers start using it, it seems safer to leave it false for now and revisit marking for removal in 10 when hopefully we've had some feedback.
>
> -DrD-
>
>   
>> Yes, ultimately the decision is up to Kevin and Dave (or whoever is in charge of technical decision-making in this area).
>>
>> I wanted to provide some clarity on the use of forRemoval=true.
>>
>> The specification is fairly neutral, saying only that there is "intent to remove" the API "in a future version."
>>
>> In practice, for the JDK, I'm trying to make sure we set forRemoval=true only when there are definite plans for removal in the near future, for example, in the following release. I want to avoid a situation where there are a bunch of APIs in the JDK that have forRemoval=true but that are hanging around for several releases before they are eventually removed. (Or not.)
>>
>> When I discussed this issue with the team with respect to the Applet API, I asked whether Applets would be removed in the next release (after JDK 9). There was some hemming and hawing, and eventually it emerged that there were still some narrow use cases that would probably still need to be supported even in the next release, and they weren't entirely sure when Applet could actually be removed. Based on that discussion we deprecated Applet with forRemoval=false in JDK 9, and we'll revisit this in the future when plans are more definite.
>>
>> I had thought that the plugin and Applets were closely related enough so that they ought to be treated the same. This would argue that this API should also be deprecated in JDK 9 with forRemoval=false, and revisited at the same time as Applet. But I could be mistaken, and it might make sense to treat the plugin separately from Applet.
>>
>> s'marks
>>
>> On 6/10/16 11:30 AM, Mandy Chung wrote:
>>     
>>> This method is about the fate of plugin support in a future regardless of the presence of java.applet.Applet API. The @deprecated note may cause the confusion.
>>>
>>> What I understand from the past discussion with Kevin and Dave, we want this method to be removed in a future release - the earliest possible release would be N+1 when it?s deprecated for removal in JDK N.
>>>
>>> I?ll let Kevin and Dave to clear this up and make the final call.
>>>
>>> Mandy
>>>
>>>       
>>>> On Jun 10, 2016, at 9:58 AM, Stuart Marks <stuart.marks at oracle.com> wrote:
>>>>
>>>> Hi, sorry I had missed this earlier.
>>>>
>>>> It's surprising if forRemoval=true were to be added to this API when the rest of the Applet API has forRemoval=false. Is it the intent, for example, to have JSObject.getWindow() removed from JDK 10 but to have the rest of the Applet API remain?
>>>>
>>>> My understanding of the plan was to deprecate the Applet API in JDK 9 with forRemoval=false. Then, in a future release, when removal plans become more definite, to change forRemoval to true, and in a subsequent release, to remove the Applet APIs. I'd think that plan would apply here as well.
>>>>
>>>> Put another way, I'd recommend that we set forRemoval=true only when the plan is more definite than "we plan to remove this in some future, as yet unspecified release."
>>>>
>>>> s'marks
>>>>
>>>>
>>>> On 6/8/16 5:34 PM, Daniil Titov wrote:
>>>>         
>>>>> Hello,
>>>>>
>>>>> Please review the new version of the fix for JDK9.
>>>>>
>>>>> 1. "forRemoval = true" is added to @Deprecated annotation for JSObject.getWindow(Applet) method.
>>>>> 2.  A new doc bundle for JSObject documentation is added in the docs build.
>>>>>
>>>>> Webrev: http://cr.openjdk.java.net/~dtitov/8156960/jdk/webrev.01
>>>>>       http://cr.openjdk.java.net/~dtitov/8156960/webrev.01
>>>>>
>>>>>
>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8156960
>>>>>
>>>>> Thank you!
>>>>>
>>>>> Best regards,
>>>>> Daniil
>>>>>
>>>>> -----Original Message-----
>>>>> From: Mandy Chung
>>>>> Sent: Wednesday, June 08, 2016 3:09 PM
>>>>> To: Daniil Titov
>>>>> Cc: David Dehaven; Stuart Marks; Erik Joelsson; build-dev; build-infa-dev at openjdk.java.net; awt-dev; Kevin Rushforth
>>>>> Subject: Re: Review Request: 8156960 Deprecate JSObject.getWindow(Applet) method
>>>>>
>>>>> That?s right.  It requires to add a new doc bundle in the docs build.  What you did was the right direction.  Can you update the webrev?
>>>>>
>>>>> FYI.  There is an effort under discussion to revisit the number of docs bundle generated and clean up the docs build.
>>>>>
>>>>> Mandy
>>>>>
>>>>>           
>>>>>> On Jun 8, 2016, at 2:48 PM, Daniil Titov <daniil.x.titov at oracle.com> wrote:
>>>>>>
>>>>>> NON_CORE_PKGS variable is not used in make/Javadoc.gmk, so just adding a new package in this variable will not make this package included in any docs. We will need to create a new javadoc target for JSObject documentation ( or add it to some existing target, but it doesn't look like there is one that fits it). For example:
>>>>>>
>>>>>>
>>>>>> diff -r 389c2d2842a5 make/Javadoc.gmk
>>>>>> --- a/make/Javadoc.gmk	Wed May 25 12:53:26 2016 +0200
>>>>>> +++ b/make/Javadoc.gmk	Thu Jun 02 16:20:35 2016 -0700
>>>>>> @@ -82,7 +82,7 @@
>>>>>> PLUGIN2_FIRST_COPYRIGHT_YEAR = 2007
>>>>>> JDKNET_FIRST_COPYRIGHT_YEAR = 2014
>>>>>> JACCESSAPI_FIRST_COPYRIGHT_YEAR = 2002
>>>>>> -
>>>>>> +JSOBJECT_FIRST_COPYRIGHT_YEAR = 1993
>>>>>>
>>>>>> # Oracle name
>>>>>> FULL_COMPANY_NAME = Oracle and/or its affiliates @@ -1031,6 +1031,64
>>>>>> @@
>>>>>>
>>>>>> #############################################################
>>>>>> #
>>>>>> +# jsobjectdocs
>>>>>> +#
>>>>>> +
>>>>>> +ALL_OTHER_TARGETS += jsobjectdoc
>>>>>> +
>>>>>> +JSOBJECT_DOCDIR := $(JRE_API_DOCSDIR)/plugin/jsobject
>>>>>> +JSOBJECT2COREAPI := ../../../$(JDKJRE2COREAPI) JSOBJECT_DOCTITLE :=
>>>>>> +Java$(TRADEMARK) JSObject Doc JSOBJECT_WINDOWTITLE := Java JSObect
>>>>>> +Doc JSOBJECT_HEADER := <strong>Java JSObject Doc</strong>
>>>>>> +JSOBJECT_BOTTOM := $(call
>>>>>> +CommonBottom,$(JSOBJECT_FIRST_COPYRIGHT_YEAR))
>>>>>> +# JSOBJECT_PKGS is located in NON_CORE_PKGS.gmk
>>>>>> +
>>>>>> +JSOBJECT_INDEX_HTML = $(JSOBJECT_DOCDIR)/index.html
>>>>>> +JSOBJECT_OPTIONS_FILE = $(DOCSTMPDIR)/jsobject.options
>>>>>> +JSOBJECT_PACKAGES_FILE = $(DOCSTMPDIR)/jsobject.packages
>>>>>> +
>>>>>> +# The modules required to be documented JSOBJECT_MODULES =
>>>>>> +jdk.jsobject
>>>>>> +
>>>>>> +jsobjectdocs: $(JSOBJECT_INDEX_HTML)
>>>>>> +
>>>>>> +# Set relative location to core api document root
>>>>>> +$(JSOBJECT_INDEX_HTML): GET2DOCSDIR=$(JSOBJECT2COREAPI)/..
>>>>>> +
>>>>>> +# Run javadoc if the index file is out of date or missing
>>>>>> +$(JSOBJECT_INDEX_HTML): $(JSOBJECT_OPTIONS_FILE) $(JSOBJECT_PACKAGES_FILE) $(COREAPI_INDEX_FILE)
>>>>>> +	$(prep-javadoc)
>>>>>> +	$(call JavadocSummary,$(JSOBJECT_OPTIONS_FILE),$(JSOBJECT_PACKAGES_FILE))
>>>>>> +	$(JAVADOC_CMD_SMALL) -d $(@D) \
>>>>>> +	    @$(JSOBJECT_OPTIONS_FILE) @$(JSOBJECT_PACKAGES_FILE)
>>>>>> +
>>>>>> +# Create file with javadoc options in it
>>>>>> +$(JSOBJECT_OPTIONS_FILE):
>>>>>> +	$(prep-target)
>>>>>> +	@($(call COMMON_JAVADOCFLAGS) ; \
>>>>>> +          $(call COMMON_JAVADOCTAGS) ; \
>>>>>> +	  $(call OptionOnly,-Xdoclint:none) ; \
>>>>>> +          $(call OptionPair,-system,none) ; \
>>>>>> +	  $(call OptionPair,-modulesourcepath,$(RELEASEDOCS_MODULESOURCEPATH)) ; \
>>>>>> +	  $(call OptionPair,-addmods,$(JSOBJECT_MODULES)) ; \
>>>>>> +	  $(call OptionPair,-encoding,ascii) ; \
>>>>>> +	  $(call OptionOnly,-nodeprecatedlist) ; \
>>>>>> +	  $(call OptionPair,-doctitle,$(JSOBJECT_DOCTITLE)) ; \
>>>>>> +	  $(call OptionPair,-windowtitle,$(JSOBJECT_WINDOWTITLE) $(DRAFT_WINTITLE)); \
>>>>>> +	  $(call OptionPair,-header,$(JSOBJECT_HEADER)$(DRAFT_HEADER)); \
>>>>>> +	  $(call OptionPair,-bottom,$(JSOBJECT_BOTTOM)$(DRAFT_BOTTOM)); \
>>>>>> +	  $(call OptionTrip,-linkoffline,$(JSOBJECT2COREAPI),$(COREAPI_DOCSDIR)/); \
>>>>>> +	) >> $@
>>>>>> +
>>>>>> +# Create a file with the package names in it
>>>>>> +$(JSOBJECT_PACKAGES_FILE): $(call PackageDependencies,$(JSOBJECT_PKGS))
>>>>>> +	$(prep-target)
>>>>>> +	$(call PackageFilter,$(JSOBJECT_PKGS))
>>>>>> +
>>>>>> +
>>>>>> +#############################################################
>>>>>> +#
>>>>>> # mgmtdocs
>>>>>> #
>>>>>>
>>>>>>
>>>>>> Best regards,
>>>>>> Daniil
>>>>>>
>>>>>>
>>>>>>
>>>>>> -----Original Message-----
>>>>>> From: David DeHaven
>>>>>> Sent: Wednesday, June 08, 2016 1:23 PM
>>>>>> To: Mandy Chung
>>>>>> Cc: Daniil Titov; Stuart Marks; Erik Joelsson; build-dev;
>>>>>> build-infa-dev at openjdk.java.net; awt-dev; Kevin Rushforth
>>>>>> Subject: Re: Review Request: 8156960 Deprecate
>>>>>> JSObject.getWindow(Applet) method
>>>>>>
>>>>>>
>>>>>> How about NON_CORE_PKGS.gmk for javadoc?
>>>>>>
>>>>>> Something like:
>>>>>>
>>>>>> diff --git a/make/common/NON_CORE_PKGS.gmk
>>>>>> b/make/common/NON_CORE_PKGS.gmk
>>>>>> --- a/make/common/NON_CORE_PKGS.gmk
>>>>>> +++ b/make/common/NON_CORE_PKGS.gmk
>>>>>> @@ -44,6 +44,8 @@
>>>>>>   org.w3c.dom.events \
>>>>>>   org.w3c.dom.views
>>>>>>
>>>>>> +JSOBJECT_PKGS = netscape.javascript
>>>>>> +
>>>>>> JDI_PKGS = com.sun.jdi \
>>>>>>   com.sun.jdi.event \
>>>>>>   com.sun.jdi.request \
>>>>>> @@ -113,6 +115,7 @@
>>>>>>
>>>>>> # non-core packages in rt.jar
>>>>>> NON_CORE_PKGS = $(DOMAPI_PKGS) \
>>>>>> +    $(JSOBJECT_PKGS) \
>>>>>>   $(MGMT_PKGS) \
>>>>>>   $(JAAS_PKGS) \
>>>>>>   $(JGSS_PKGS) \
>>>>>>
>>>>>> -DrD-
>>>>>>
>>>>>>             
>>>>>>> The client team owns jdk.jsobject module and so I add awt-dev to this thread.  And bcc jdk9-dev.
>>>>>>>
>>>>>>> It is not Java SE API and it should not add to CORE-PKGS.gmk.  As for @Deprecated, I believe the plan is to remove the getWindows method in a future release. Kevin and Dave can confirm.
>>>>>>>
>>>>>>> Mandy
>>>>>>>
>>>>>>>               
>>>>>>>> On Jun 8, 2016, at 12:33 PM, Daniil Titov <daniil.x.titov at oracle.com> wrote:
>>>>>>>>
>>>>>>>> Hello,
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> Please review the fix for JDK 9.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> The fix adds @Deprecated annotation to netscape.javascript.JSObject.getWindow(Applet) method and ensures that netscape.javascript package is included in the generated docs.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8156960
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> Webrev:   http://cr.openjdk.java.net/~dtitov/8156960/jdk/webrev.00/
>>>>>>>>
>>>>>>>>      http://cr.openjdk.java.net/~dtitov/8156960/webrev.00/
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> Best regards,
>>>>>>>>
>>>>>>>> Daniil
>>>>>>>>                 
>
>   
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20160613/6468f039/attachment-0001.html>

From mandy.chung at oracle.com  Mon Jun 13 20:00:58 2016
From: mandy.chung at oracle.com (Mandy Chung)
Date: Mon, 13 Jun 2016 13:00:58 -0700
Subject: <AWT Dev> Review Request: 8156960 Deprecate
	JSObject.getWindow(Applet) method
In-Reply-To: <A6933CAA-732E-4EC4-9C78-97A12CAC20FD@oracle.com>
References: <1f05a2b9-a68b-4684-a58a-163189c710af@default>
	<FDD6B460-8071-40CA-8FC3-AECF9E0C4ABF@oracle.com>
	<6CB5C96E-8B7F-4093-BA02-94702BA53047@oracle.com>
	<99907f0c-961d-4d66-950f-9b4de4fc96f7@default>
	<EAF37B66-F1D5-44D0-82AB-DFB4120AB8E4@oracle.com>
	<61539153-a0c6-474d-aded-d34b6266a1c1@default>
	<3d7b40f9-6c2c-340d-cd75-0050ae0d857c@oracle.com>
	<798891A9-B63A-4DF1-B8FE-D9F9AAC4855A@oracle.com>
	<1ec98193-7a52-c73a-e07c-dfed7d02c7a1@oracle.com>
	<A6933CAA-732E-4EC4-9C78-97A12CAC20FD@oracle.com>
Message-ID: <5015B87E-4029-4538-9CD7-FDFD5F52D163@oracle.com>

forRemoval=true indicates that the API will be removed in a future release and does not mean it will be removed in N+1.

Hope this clears the confusion. 

Mandy

> On Jun 13, 2016, at 9:17 AM, David DeHaven <david.dehaven at oracle.com> wrote:
> 
> [removed bad email address..]
> 
> Ok, my understanding was that forRemoval was intended for the next release, so setting it to true meant we were saying "removing in JDK 10." If that's NOT the case then we should set it to true for this particular case since this method is tied specifically to the plugin and not Applet.
> 
> I just don't want to hear any whining when it comes around to JDK 11 and it hasn't been removed yet ;)
> 
> I still don't know about Applet as anyone using it outside of plugin has been very quiet and I suspect we WON'T hear anything until JDK 9 gets released and developers start using it, it seems safer to leave it false for now and revisit marking for removal in 10 when hopefully we've had some feedback.
> 
> -DrD-
> 
>> Yes, ultimately the decision is up to Kevin and Dave (or whoever is in charge of technical decision-making in this area).
>> 
>> I wanted to provide some clarity on the use of forRemoval=true.
>> 
>> The specification is fairly neutral, saying only that there is "intent to remove" the API "in a future version."
>> 
>> In practice, for the JDK, I'm trying to make sure we set forRemoval=true only when there are definite plans for removal in the near future, for example, in the following release. I want to avoid a situation where there are a bunch of APIs in the JDK that have forRemoval=true but that are hanging around for several releases before they are eventually removed. (Or not.)
>> 
>> When I discussed this issue with the team with respect to the Applet API, I asked whether Applets would be removed in the next release (after JDK 9). There was some hemming and hawing, and eventually it emerged that there were still some narrow use cases that would probably still need to be supported even in the next release, and they weren't entirely sure when Applet could actually be removed. Based on that discussion we deprecated Applet with forRemoval=false in JDK 9, and we'll revisit this in the future when plans are more definite.
>> 
>> I had thought that the plugin and Applets were closely related enough so that they ought to be treated the same. This would argue that this API should also be deprecated in JDK 9 with forRemoval=false, and revisited at the same time as Applet. But I could be mistaken, and it might make sense to treat the plugin separately from Applet.
>> 
>> s'marks
>> 
>> On 6/10/16 11:30 AM, Mandy Chung wrote:
>>> This method is about the fate of plugin support in a future regardless of the presence of java.applet.Applet API. The @deprecated note may cause the confusion.
>>> 
>>> What I understand from the past discussion with Kevin and Dave, we want this method to be removed in a future release - the earliest possible release would be N+1 when it?s deprecated for removal in JDK N.
>>> 
>>> I?ll let Kevin and Dave to clear this up and make the final call.
>>> 
>>> Mandy
>>> 
>>>> On Jun 10, 2016, at 9:58 AM, Stuart Marks <stuart.marks at oracle.com> wrote:
>>>> 
>>>> Hi, sorry I had missed this earlier.
>>>> 
>>>> It's surprising if forRemoval=true were to be added to this API when the rest of the Applet API has forRemoval=false. Is it the intent, for example, to have JSObject.getWindow() removed from JDK 10 but to have the rest of the Applet API remain?
>>>> 
>>>> My understanding of the plan was to deprecate the Applet API in JDK 9 with forRemoval=false. Then, in a future release, when removal plans become more definite, to change forRemoval to true, and in a subsequent release, to remove the Applet APIs. I'd think that plan would apply here as well.
>>>> 
>>>> Put another way, I'd recommend that we set forRemoval=true only when the plan is more definite than "we plan to remove this in some future, as yet unspecified release."
>>>> 
>>>> s'marks
>>>> 
>>>> 
>>>> On 6/8/16 5:34 PM, Daniil Titov wrote:
>>>>> Hello,
>>>>> 
>>>>> Please review the new version of the fix for JDK9.
>>>>> 
>>>>> 1. "forRemoval = true" is added to @Deprecated annotation for JSObject.getWindow(Applet) method.
>>>>> 2.  A new doc bundle for JSObject documentation is added in the docs build.
>>>>> 
>>>>> Webrev: http://cr.openjdk.java.net/~dtitov/8156960/jdk/webrev.01
>>>>>      http://cr.openjdk.java.net/~dtitov/8156960/webrev.01
>>>>> 
>>>>> 
>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8156960
>>>>> 
>>>>> Thank you!
>>>>> 
>>>>> Best regards,
>>>>> Daniil
>>>>> 
>>>>> -----Original Message-----
>>>>> From: Mandy Chung
>>>>> Sent: Wednesday, June 08, 2016 3:09 PM
>>>>> To: Daniil Titov
>>>>> Cc: David Dehaven; Stuart Marks; Erik Joelsson; build-dev; build-infa-dev at openjdk.java.net; awt-dev; Kevin Rushforth
>>>>> Subject: Re: Review Request: 8156960 Deprecate JSObject.getWindow(Applet) method
>>>>> 
>>>>> That?s right.  It requires to add a new doc bundle in the docs build.  What you did was the right direction.  Can you update the webrev?
>>>>> 
>>>>> FYI.  There is an effort under discussion to revisit the number of docs bundle generated and clean up the docs build.
>>>>> 
>>>>> Mandy
>>>>> 
>>>>>> On Jun 8, 2016, at 2:48 PM, Daniil Titov <daniil.x.titov at oracle.com> wrote:
>>>>>> 
>>>>>> NON_CORE_PKGS variable is not used in make/Javadoc.gmk, so just adding a new package in this variable will not make this package included in any docs. We will need to create a new javadoc target for JSObject documentation ( or add it to some existing target, but it doesn't look like there is one that fits it). For example:
>>>>>> 
>>>>>> 
>>>>>> diff -r 389c2d2842a5 make/Javadoc.gmk
>>>>>> --- a/make/Javadoc.gmk	Wed May 25 12:53:26 2016 +0200
>>>>>> +++ b/make/Javadoc.gmk	Thu Jun 02 16:20:35 2016 -0700
>>>>>> @@ -82,7 +82,7 @@
>>>>>> PLUGIN2_FIRST_COPYRIGHT_YEAR = 2007
>>>>>> JDKNET_FIRST_COPYRIGHT_YEAR = 2014
>>>>>> JACCESSAPI_FIRST_COPYRIGHT_YEAR = 2002
>>>>>> -
>>>>>> +JSOBJECT_FIRST_COPYRIGHT_YEAR = 1993
>>>>>> 
>>>>>> # Oracle name
>>>>>> FULL_COMPANY_NAME = Oracle and/or its affiliates @@ -1031,6 +1031,64
>>>>>> @@
>>>>>> 
>>>>>> #############################################################
>>>>>> #
>>>>>> +# jsobjectdocs
>>>>>> +#
>>>>>> +
>>>>>> +ALL_OTHER_TARGETS += jsobjectdoc
>>>>>> +
>>>>>> +JSOBJECT_DOCDIR := $(JRE_API_DOCSDIR)/plugin/jsobject
>>>>>> +JSOBJECT2COREAPI := ../../../$(JDKJRE2COREAPI) JSOBJECT_DOCTITLE :=
>>>>>> +Java$(TRADEMARK) JSObject Doc JSOBJECT_WINDOWTITLE := Java JSObect
>>>>>> +Doc JSOBJECT_HEADER := <strong>Java JSObject Doc</strong>
>>>>>> +JSOBJECT_BOTTOM := $(call
>>>>>> +CommonBottom,$(JSOBJECT_FIRST_COPYRIGHT_YEAR))
>>>>>> +# JSOBJECT_PKGS is located in NON_CORE_PKGS.gmk
>>>>>> +
>>>>>> +JSOBJECT_INDEX_HTML = $(JSOBJECT_DOCDIR)/index.html
>>>>>> +JSOBJECT_OPTIONS_FILE = $(DOCSTMPDIR)/jsobject.options
>>>>>> +JSOBJECT_PACKAGES_FILE = $(DOCSTMPDIR)/jsobject.packages
>>>>>> +
>>>>>> +# The modules required to be documented JSOBJECT_MODULES =
>>>>>> +jdk.jsobject
>>>>>> +
>>>>>> +jsobjectdocs: $(JSOBJECT_INDEX_HTML)
>>>>>> +
>>>>>> +# Set relative location to core api document root
>>>>>> +$(JSOBJECT_INDEX_HTML): GET2DOCSDIR=$(JSOBJECT2COREAPI)/..
>>>>>> +
>>>>>> +# Run javadoc if the index file is out of date or missing
>>>>>> +$(JSOBJECT_INDEX_HTML): $(JSOBJECT_OPTIONS_FILE) $(JSOBJECT_PACKAGES_FILE) $(COREAPI_INDEX_FILE)
>>>>>> +	$(prep-javadoc)
>>>>>> +	$(call JavadocSummary,$(JSOBJECT_OPTIONS_FILE),$(JSOBJECT_PACKAGES_FILE))
>>>>>> +	$(JAVADOC_CMD_SMALL) -d $(@D) \
>>>>>> +	    @$(JSOBJECT_OPTIONS_FILE) @$(JSOBJECT_PACKAGES_FILE)
>>>>>> +
>>>>>> +# Create file with javadoc options in it
>>>>>> +$(JSOBJECT_OPTIONS_FILE):
>>>>>> +	$(prep-target)
>>>>>> +	@($(call COMMON_JAVADOCFLAGS) ; \
>>>>>> +          $(call COMMON_JAVADOCTAGS) ; \
>>>>>> +	  $(call OptionOnly,-Xdoclint:none) ; \
>>>>>> +          $(call OptionPair,-system,none) ; \
>>>>>> +	  $(call OptionPair,-modulesourcepath,$(RELEASEDOCS_MODULESOURCEPATH)) ; \
>>>>>> +	  $(call OptionPair,-addmods,$(JSOBJECT_MODULES)) ; \
>>>>>> +	  $(call OptionPair,-encoding,ascii) ; \
>>>>>> +	  $(call OptionOnly,-nodeprecatedlist) ; \
>>>>>> +	  $(call OptionPair,-doctitle,$(JSOBJECT_DOCTITLE)) ; \
>>>>>> +	  $(call OptionPair,-windowtitle,$(JSOBJECT_WINDOWTITLE) $(DRAFT_WINTITLE)); \
>>>>>> +	  $(call OptionPair,-header,$(JSOBJECT_HEADER)$(DRAFT_HEADER)); \
>>>>>> +	  $(call OptionPair,-bottom,$(JSOBJECT_BOTTOM)$(DRAFT_BOTTOM)); \
>>>>>> +	  $(call OptionTrip,-linkoffline,$(JSOBJECT2COREAPI),$(COREAPI_DOCSDIR)/); \
>>>>>> +	) >> $@
>>>>>> +
>>>>>> +# Create a file with the package names in it
>>>>>> +$(JSOBJECT_PACKAGES_FILE): $(call PackageDependencies,$(JSOBJECT_PKGS))
>>>>>> +	$(prep-target)
>>>>>> +	$(call PackageFilter,$(JSOBJECT_PKGS))
>>>>>> +
>>>>>> +
>>>>>> +#############################################################
>>>>>> +#
>>>>>> # mgmtdocs
>>>>>> #
>>>>>> 
>>>>>> 
>>>>>> Best regards,
>>>>>> Daniil
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> -----Original Message-----
>>>>>> From: David DeHaven
>>>>>> Sent: Wednesday, June 08, 2016 1:23 PM
>>>>>> To: Mandy Chung
>>>>>> Cc: Daniil Titov; Stuart Marks; Erik Joelsson; build-dev;
>>>>>> build-infa-dev at openjdk.java.net; awt-dev; Kevin Rushforth
>>>>>> Subject: Re: Review Request: 8156960 Deprecate
>>>>>> JSObject.getWindow(Applet) method
>>>>>> 
>>>>>> 
>>>>>> How about NON_CORE_PKGS.gmk for javadoc?
>>>>>> 
>>>>>> Something like:
>>>>>> 
>>>>>> diff --git a/make/common/NON_CORE_PKGS.gmk
>>>>>> b/make/common/NON_CORE_PKGS.gmk
>>>>>> --- a/make/common/NON_CORE_PKGS.gmk
>>>>>> +++ b/make/common/NON_CORE_PKGS.gmk
>>>>>> @@ -44,6 +44,8 @@
>>>>>>  org.w3c.dom.events \
>>>>>>  org.w3c.dom.views
>>>>>> 
>>>>>> +JSOBJECT_PKGS = netscape.javascript
>>>>>> +
>>>>>> JDI_PKGS = com.sun.jdi \
>>>>>>  com.sun.jdi.event \
>>>>>>  com.sun.jdi.request \
>>>>>> @@ -113,6 +115,7 @@
>>>>>> 
>>>>>> # non-core packages in rt.jar
>>>>>> NON_CORE_PKGS = $(DOMAPI_PKGS) \
>>>>>> +    $(JSOBJECT_PKGS) \
>>>>>>  $(MGMT_PKGS) \
>>>>>>  $(JAAS_PKGS) \
>>>>>>  $(JGSS_PKGS) \
>>>>>> 
>>>>>> -DrD-
>>>>>> 
>>>>>>> The client team owns jdk.jsobject module and so I add awt-dev to this thread.  And bcc jdk9-dev.
>>>>>>> 
>>>>>>> It is not Java SE API and it should not add to CORE-PKGS.gmk.  As for @Deprecated, I believe the plan is to remove the getWindows method in a future release. Kevin and Dave can confirm.
>>>>>>> 
>>>>>>> Mandy
>>>>>>> 
>>>>>>>> On Jun 8, 2016, at 12:33 PM, Daniil Titov <daniil.x.titov at oracle.com> wrote:
>>>>>>>> 
>>>>>>>> Hello,
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>>> Please review the fix for JDK 9.
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>>> The fix adds @Deprecated annotation to netscape.javascript.JSObject.getWindow(Applet) method and ensures that netscape.javascript package is included in the generated docs.
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8156960
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>>> Webrev:   http://cr.openjdk.java.net/~dtitov/8156960/jdk/webrev.00/
>>>>>>>> 
>>>>>>>>     http://cr.openjdk.java.net/~dtitov/8156960/webrev.00/
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>>> Best regards,
>>>>>>>> 
>>>>>>>> Daniil
>>>>>>> 
>>>>>> 
>>>>> 
>>> 
> 


From stuart.marks at oracle.com  Mon Jun 13 22:03:15 2016
From: stuart.marks at oracle.com (Stuart Marks)
Date: Mon, 13 Jun 2016 15:03:15 -0700
Subject: <AWT Dev> Review Request: 8156960 Deprecate
 JSObject.getWindow(Applet) method
In-Reply-To: <5015B87E-4029-4538-9CD7-FDFD5F52D163@oracle.com>
References: <1f05a2b9-a68b-4684-a58a-163189c710af@default>
	<FDD6B460-8071-40CA-8FC3-AECF9E0C4ABF@oracle.com>
	<6CB5C96E-8B7F-4093-BA02-94702BA53047@oracle.com>
	<99907f0c-961d-4d66-950f-9b4de4fc96f7@default>
	<EAF37B66-F1D5-44D0-82AB-DFB4120AB8E4@oracle.com>
	<61539153-a0c6-474d-aded-d34b6266a1c1@default>
	<3d7b40f9-6c2c-340d-cd75-0050ae0d857c@oracle.com>
	<798891A9-B63A-4DF1-B8FE-D9F9AAC4855A@oracle.com>
	<1ec98193-7a52-c73a-e07c-dfed7d02c7a1@oracle.com>
	<A6933CAA-732E-4EC4-9C78-97A12CAC20FD@oracle.com>
	<5015B87E-4029-4538-9CD7-FDFD5F52D163@oracle.com>
Message-ID: <53d819ee-a8f6-5d93-2660-1fd3e0939b41@oracle.com>

Strictly speaking, Mandy is correct. The @Deprecated specification can't require 
its clients to commit to removing something in the next release.

However, as a matter of JDK policy, we're trying to set forRemoval=true only on 
stuff where there's a definite plan to remove it in the next release.

JSObject.getWindow(Applet) could still be either. I'm not sure where we ended up 
based on the exchange between David and Kevin.

David had said,

> it seems safer to leave it false for now and revisit marking for removal in 10

I think this means, "set forRemoval=false in 9, set forRemoval=true in 10, and 
actually remove it in 11".

Whereas Kevin had said,

> I very much hope we can remove the getWindow method in JDK 10.

which implies that forRemoval should be set to true in 9.

s'marks


On 6/13/16 1:00 PM, Mandy Chung wrote:
> forRemoval=true indicates that the API will be removed in a future release and does not mean it will be removed in N+1.
>
> Hope this clears the confusion.
>
> Mandy
>
>> On Jun 13, 2016, at 9:17 AM, David DeHaven <david.dehaven at oracle.com> wrote:
>>
>> [removed bad email address..]
>>
>> Ok, my understanding was that forRemoval was intended for the next release, so setting it to true meant we were saying "removing in JDK 10." If that's NOT the case then we should set it to true for this particular case since this method is tied specifically to the plugin and not Applet.
>>
>> I just don't want to hear any whining when it comes around to JDK 11 and it hasn't been removed yet ;)
>>
>> I still don't know about Applet as anyone using it outside of plugin has been very quiet and I suspect we WON'T hear anything until JDK 9 gets released and developers start using it, it seems safer to leave it false for now and revisit marking for removal in 10 when hopefully we've had some feedback.
>>
>> -DrD-
>>
>>> Yes, ultimately the decision is up to Kevin and Dave (or whoever is in charge of technical decision-making in this area).
>>>
>>> I wanted to provide some clarity on the use of forRemoval=true.
>>>
>>> The specification is fairly neutral, saying only that there is "intent to remove" the API "in a future version."
>>>
>>> In practice, for the JDK, I'm trying to make sure we set forRemoval=true only when there are definite plans for removal in the near future, for example, in the following release. I want to avoid a situation where there are a bunch of APIs in the JDK that have forRemoval=true but that are hanging around for several releases before they are eventually removed. (Or not.)
>>>
>>> When I discussed this issue with the team with respect to the Applet API, I asked whether Applets would be removed in the next release (after JDK 9). There was some hemming and hawing, and eventually it emerged that there were still some narrow use cases that would probably still need to be supported even in the next release, and they weren't entirely sure when Applet could actually be removed. Based on that discussion we deprecated Applet with forRemoval=false in JDK 9, and we'll revisit this in the future when plans are more definite.
>>>
>>> I had thought that the plugin and Applets were closely related enough so that they ought to be treated the same. This would argue that this API should also be deprecated in JDK 9 with forRemoval=false, and revisited at the same time as Applet. But I could be mistaken, and it might make sense to treat the plugin separately from Applet.
>>>
>>> s'marks
>>>
>>> On 6/10/16 11:30 AM, Mandy Chung wrote:
>>>> This method is about the fate of plugin support in a future regardless of the presence of java.applet.Applet API. The @deprecated note may cause the confusion.
>>>>
>>>> What I understand from the past discussion with Kevin and Dave, we want this method to be removed in a future release - the earliest possible release would be N+1 when it?s deprecated for removal in JDK N.
>>>>
>>>> I?ll let Kevin and Dave to clear this up and make the final call.
>>>>
>>>> Mandy
>>>>
>>>>> On Jun 10, 2016, at 9:58 AM, Stuart Marks <stuart.marks at oracle.com> wrote:
>>>>>
>>>>> Hi, sorry I had missed this earlier.
>>>>>
>>>>> It's surprising if forRemoval=true were to be added to this API when the rest of the Applet API has forRemoval=false. Is it the intent, for example, to have JSObject.getWindow() removed from JDK 10 but to have the rest of the Applet API remain?
>>>>>
>>>>> My understanding of the plan was to deprecate the Applet API in JDK 9 with forRemoval=false. Then, in a future release, when removal plans become more definite, to change forRemoval to true, and in a subsequent release, to remove the Applet APIs. I'd think that plan would apply here as well.
>>>>>
>>>>> Put another way, I'd recommend that we set forRemoval=true only when the plan is more definite than "we plan to remove this in some future, as yet unspecified release."
>>>>>
>>>>> s'marks
>>>>>
>>>>>
>>>>> On 6/8/16 5:34 PM, Daniil Titov wrote:
>>>>>> Hello,
>>>>>>
>>>>>> Please review the new version of the fix for JDK9.
>>>>>>
>>>>>> 1. "forRemoval = true" is added to @Deprecated annotation for JSObject.getWindow(Applet) method.
>>>>>> 2.  A new doc bundle for JSObject documentation is added in the docs build.
>>>>>>
>>>>>> Webrev: http://cr.openjdk.java.net/~dtitov/8156960/jdk/webrev.01
>>>>>>      http://cr.openjdk.java.net/~dtitov/8156960/webrev.01
>>>>>>
>>>>>>
>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8156960
>>>>>>
>>>>>> Thank you!
>>>>>>
>>>>>> Best regards,
>>>>>> Daniil
>>>>>>
>>>>>> -----Original Message-----
>>>>>> From: Mandy Chung
>>>>>> Sent: Wednesday, June 08, 2016 3:09 PM
>>>>>> To: Daniil Titov
>>>>>> Cc: David Dehaven; Stuart Marks; Erik Joelsson; build-dev; build-infa-dev at openjdk.java.net; awt-dev; Kevin Rushforth
>>>>>> Subject: Re: Review Request: 8156960 Deprecate JSObject.getWindow(Applet) method
>>>>>>
>>>>>> That?s right.  It requires to add a new doc bundle in the docs build.  What you did was the right direction.  Can you update the webrev?
>>>>>>
>>>>>> FYI.  There is an effort under discussion to revisit the number of docs bundle generated and clean up the docs build.
>>>>>>
>>>>>> Mandy
>>>>>>
>>>>>>> On Jun 8, 2016, at 2:48 PM, Daniil Titov <daniil.x.titov at oracle.com> wrote:
>>>>>>>
>>>>>>> NON_CORE_PKGS variable is not used in make/Javadoc.gmk, so just adding a new package in this variable will not make this package included in any docs. We will need to create a new javadoc target for JSObject documentation ( or add it to some existing target, but it doesn't look like there is one that fits it). For example:
>>>>>>>
>>>>>>>
>>>>>>> diff -r 389c2d2842a5 make/Javadoc.gmk
>>>>>>> --- a/make/Javadoc.gmk	Wed May 25 12:53:26 2016 +0200
>>>>>>> +++ b/make/Javadoc.gmk	Thu Jun 02 16:20:35 2016 -0700
>>>>>>> @@ -82,7 +82,7 @@
>>>>>>> PLUGIN2_FIRST_COPYRIGHT_YEAR = 2007
>>>>>>> JDKNET_FIRST_COPYRIGHT_YEAR = 2014
>>>>>>> JACCESSAPI_FIRST_COPYRIGHT_YEAR = 2002
>>>>>>> -
>>>>>>> +JSOBJECT_FIRST_COPYRIGHT_YEAR = 1993
>>>>>>>
>>>>>>> # Oracle name
>>>>>>> FULL_COMPANY_NAME = Oracle and/or its affiliates @@ -1031,6 +1031,64
>>>>>>> @@
>>>>>>>
>>>>>>> #############################################################
>>>>>>> #
>>>>>>> +# jsobjectdocs
>>>>>>> +#
>>>>>>> +
>>>>>>> +ALL_OTHER_TARGETS += jsobjectdoc
>>>>>>> +
>>>>>>> +JSOBJECT_DOCDIR := $(JRE_API_DOCSDIR)/plugin/jsobject
>>>>>>> +JSOBJECT2COREAPI := ../../../$(JDKJRE2COREAPI) JSOBJECT_DOCTITLE :=
>>>>>>> +Java$(TRADEMARK) JSObject Doc JSOBJECT_WINDOWTITLE := Java JSObect
>>>>>>> +Doc JSOBJECT_HEADER := <strong>Java JSObject Doc</strong>
>>>>>>> +JSOBJECT_BOTTOM := $(call
>>>>>>> +CommonBottom,$(JSOBJECT_FIRST_COPYRIGHT_YEAR))
>>>>>>> +# JSOBJECT_PKGS is located in NON_CORE_PKGS.gmk
>>>>>>> +
>>>>>>> +JSOBJECT_INDEX_HTML = $(JSOBJECT_DOCDIR)/index.html
>>>>>>> +JSOBJECT_OPTIONS_FILE = $(DOCSTMPDIR)/jsobject.options
>>>>>>> +JSOBJECT_PACKAGES_FILE = $(DOCSTMPDIR)/jsobject.packages
>>>>>>> +
>>>>>>> +# The modules required to be documented JSOBJECT_MODULES =
>>>>>>> +jdk.jsobject
>>>>>>> +
>>>>>>> +jsobjectdocs: $(JSOBJECT_INDEX_HTML)
>>>>>>> +
>>>>>>> +# Set relative location to core api document root
>>>>>>> +$(JSOBJECT_INDEX_HTML): GET2DOCSDIR=$(JSOBJECT2COREAPI)/..
>>>>>>> +
>>>>>>> +# Run javadoc if the index file is out of date or missing
>>>>>>> +$(JSOBJECT_INDEX_HTML): $(JSOBJECT_OPTIONS_FILE) $(JSOBJECT_PACKAGES_FILE) $(COREAPI_INDEX_FILE)
>>>>>>> +	$(prep-javadoc)
>>>>>>> +	$(call JavadocSummary,$(JSOBJECT_OPTIONS_FILE),$(JSOBJECT_PACKAGES_FILE))
>>>>>>> +	$(JAVADOC_CMD_SMALL) -d $(@D) \
>>>>>>> +	    @$(JSOBJECT_OPTIONS_FILE) @$(JSOBJECT_PACKAGES_FILE)
>>>>>>> +
>>>>>>> +# Create file with javadoc options in it
>>>>>>> +$(JSOBJECT_OPTIONS_FILE):
>>>>>>> +	$(prep-target)
>>>>>>> +	@($(call COMMON_JAVADOCFLAGS) ; \
>>>>>>> +          $(call COMMON_JAVADOCTAGS) ; \
>>>>>>> +	  $(call OptionOnly,-Xdoclint:none) ; \
>>>>>>> +          $(call OptionPair,-system,none) ; \
>>>>>>> +	  $(call OptionPair,-modulesourcepath,$(RELEASEDOCS_MODULESOURCEPATH)) ; \
>>>>>>> +	  $(call OptionPair,-addmods,$(JSOBJECT_MODULES)) ; \
>>>>>>> +	  $(call OptionPair,-encoding,ascii) ; \
>>>>>>> +	  $(call OptionOnly,-nodeprecatedlist) ; \
>>>>>>> +	  $(call OptionPair,-doctitle,$(JSOBJECT_DOCTITLE)) ; \
>>>>>>> +	  $(call OptionPair,-windowtitle,$(JSOBJECT_WINDOWTITLE) $(DRAFT_WINTITLE)); \
>>>>>>> +	  $(call OptionPair,-header,$(JSOBJECT_HEADER)$(DRAFT_HEADER)); \
>>>>>>> +	  $(call OptionPair,-bottom,$(JSOBJECT_BOTTOM)$(DRAFT_BOTTOM)); \
>>>>>>> +	  $(call OptionTrip,-linkoffline,$(JSOBJECT2COREAPI),$(COREAPI_DOCSDIR)/); \
>>>>>>> +	) >> $@
>>>>>>> +
>>>>>>> +# Create a file with the package names in it
>>>>>>> +$(JSOBJECT_PACKAGES_FILE): $(call PackageDependencies,$(JSOBJECT_PKGS))
>>>>>>> +	$(prep-target)
>>>>>>> +	$(call PackageFilter,$(JSOBJECT_PKGS))
>>>>>>> +
>>>>>>> +
>>>>>>> +#############################################################
>>>>>>> +#
>>>>>>> # mgmtdocs
>>>>>>> #
>>>>>>>
>>>>>>>
>>>>>>> Best regards,
>>>>>>> Daniil
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> -----Original Message-----
>>>>>>> From: David DeHaven
>>>>>>> Sent: Wednesday, June 08, 2016 1:23 PM
>>>>>>> To: Mandy Chung
>>>>>>> Cc: Daniil Titov; Stuart Marks; Erik Joelsson; build-dev;
>>>>>>> build-infa-dev at openjdk.java.net; awt-dev; Kevin Rushforth
>>>>>>> Subject: Re: Review Request: 8156960 Deprecate
>>>>>>> JSObject.getWindow(Applet) method
>>>>>>>
>>>>>>>
>>>>>>> How about NON_CORE_PKGS.gmk for javadoc?
>>>>>>>
>>>>>>> Something like:
>>>>>>>
>>>>>>> diff --git a/make/common/NON_CORE_PKGS.gmk
>>>>>>> b/make/common/NON_CORE_PKGS.gmk
>>>>>>> --- a/make/common/NON_CORE_PKGS.gmk
>>>>>>> +++ b/make/common/NON_CORE_PKGS.gmk
>>>>>>> @@ -44,6 +44,8 @@
>>>>>>>  org.w3c.dom.events \
>>>>>>>  org.w3c.dom.views
>>>>>>>
>>>>>>> +JSOBJECT_PKGS = netscape.javascript
>>>>>>> +
>>>>>>> JDI_PKGS = com.sun.jdi \
>>>>>>>  com.sun.jdi.event \
>>>>>>>  com.sun.jdi.request \
>>>>>>> @@ -113,6 +115,7 @@
>>>>>>>
>>>>>>> # non-core packages in rt.jar
>>>>>>> NON_CORE_PKGS = $(DOMAPI_PKGS) \
>>>>>>> +    $(JSOBJECT_PKGS) \
>>>>>>>  $(MGMT_PKGS) \
>>>>>>>  $(JAAS_PKGS) \
>>>>>>>  $(JGSS_PKGS) \
>>>>>>>
>>>>>>> -DrD-
>>>>>>>
>>>>>>>> The client team owns jdk.jsobject module and so I add awt-dev to this thread.  And bcc jdk9-dev.
>>>>>>>>
>>>>>>>> It is not Java SE API and it should not add to CORE-PKGS.gmk.  As for @Deprecated, I believe the plan is to remove the getWindows method in a future release. Kevin and Dave can confirm.
>>>>>>>>
>>>>>>>> Mandy
>>>>>>>>
>>>>>>>>> On Jun 8, 2016, at 12:33 PM, Daniil Titov <daniil.x.titov at oracle.com> wrote:
>>>>>>>>>
>>>>>>>>> Hello,
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Please review the fix for JDK 9.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> The fix adds @Deprecated annotation to netscape.javascript.JSObject.getWindow(Applet) method and ensures that netscape.javascript package is included in the generated docs.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8156960
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Webrev:   http://cr.openjdk.java.net/~dtitov/8156960/jdk/webrev.00/
>>>>>>>>>
>>>>>>>>>     http://cr.openjdk.java.net/~dtitov/8156960/webrev.00/
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Best regards,
>>>>>>>>>
>>>>>>>>> Daniil
>>>>>>>>
>>>>>>>
>>>>>>
>>>>
>>
>

From alexandr.scherbatiy at oracle.com  Tue Jun 14 08:32:04 2016
From: alexandr.scherbatiy at oracle.com (Alexandr Scherbatiy)
Date: Tue, 14 Jun 2016 11:32:04 +0300
Subject: <AWT Dev> Review request for 8151385: [hidpi] JOptionPane-Icons
 only partially visible when using Windows 10 L&F
In-Reply-To: <10c553d4-e411-4e48-ef9d-4506103fc100@oracle.com>
References: <898AFD4C-3717-48C0-BBB2-24287F7C0512@tagtraum.com>
	<36184957-6682-4F71-BDD4-2EA35BE49209@tagtraum.com>
	<56E3092F.6040905@oracle.com>
	<CBC1EF8D-5853-42F8-B416-A6364D5BB8BD@tagtraum.com>
	<56E8EE58.1010006@oracle.com>
	<337E07D9-EC25-4BE7-B387-F11473A8BB26@tagtraum.com>
	<56F0628A.5030908@oracle.com>
	<1D2830BA-9610-407B-9C4C-424E6B57074D@tagtraum.com>
	<56F17285.7020506@oracle.com>
	<9D18EE88-883B-4428-8CD5-347232761D3F@tagtraum.com>
	<7E17C804-7EA7-4F42-8A1E-C50093C4F40E@tagtraum.com>
	<83c01190-e06e-8bbd-b685-772ad2bb8cfb@oracle.com>
	<BC4ADF37-F25A-4D13-A096-9DFD017D8EB3@tagtraum.com>
	<10c553d4-e411-4e48-ef9d-4506103fc100@oracle.com>
Message-ID: <494ca537-73ab-2491-abd5-5a44cc00b013@oracle.com>


The fix looks good to me.

Thanks,
Alexandr.

On 6/9/2016 12:43 PM, Sergey Bylokhov wrote:
> +1
>
> On 08.06.16 10:57, Hendrik Schreiber wrote:
>> Hey Alexandr,
>>
>>> On Jun 7, 2016, at 17:44, Alexandr Scherbatiy 
>>> <alexandr.scherbatiy at oracle.com> wrote:
>>>
>>> I slightly updated your fix to return a multi-resolution image with 
>>> base icon size when icon size is greater than the real icon size. 
>>> This allows to draw a high-resolution icon to the same bounds on 
>>> JOptionPane.
>>> http://cr.openjdk.java.net/~alexsch/hendrik.schreiber/8151385/webrev.01
>>
>> Thanks. That looks good to me.
>>
>>> I have not found the solution for the native toolbar icons yet. An 
>>> icon with IDB_VIEW_SMALL_COLOR has size 16x16 on my Windows 8.1. The 
>>> GetSystemMetrics(SM_CXSMICON) returns 32. It is a question for me 
>>> should IDB_VIEW_SMALL_COLOR icon has the same size as the 
>>> GetSystemMetrics(SM_CXSMICON).
>>> An icon with IDB_VIEW_LARGE_COLOR returns also icon with size 16x16 
>>> and the returned image contains only one quarter of the original 
>>> picture.
>>>
>>> I left the code for the toolbar icons as it was before so it uses 
>>> low resolution IDB_VIEW_SMALL_COLOR icons.
>>> I think it can be fixed as a separated issue.
>>
>> Perhaps that?s the best approach, even though I fear that that means 
>> it will never get fixed?
>> But having the other fixes in the JDK, is already some progress I 
>> appreciate very much.
>>
>> Are you going to create a new bug report?
>>
>> Eventually, we simply need a more modern FileDialog. See 
>> http://mail.openjdk.java.net/pipermail/awt-dev/2016-March/010778.html
>>
>> Cheers,
>>
>> -hendrik
>>
>
>


From semyon.sadetsky at oracle.com  Tue Jun 14 09:47:05 2016
From: semyon.sadetsky at oracle.com (Semyon Sadetsky)
Date: Tue, 14 Jun 2016 12:47:05 +0300
Subject: <AWT Dev> <AWT dev>[9] Review request for JDK-8155740: [macosx]
 robot.keyPress and robot.keyRelease do not generate key event for Alt-Graph
 key VK_ALT_GRAPH.
In-Reply-To: <6C54D895-737D-4731-BE16-06F4658ADE49@oracle.com>
References: <538F0C0F-2C53-49CD-96B5-F78A794E3177@oracle.com>
	<5734A835.80908@oracle.com>
	<75CD4BD9-983C-4315-A5FC-3518C37BECF7@oracle.com>
	<573E06C5.5040807@oracle.com>
	<4CFAD53C-0E2F-43B4-854C-BFF1CEB944A5@oracle.com>
	<082a4f05-f5f2-01d0-5951-dc36b3dafbe5@oracle.com>
	<F3869358-BE09-42E0-8F39-ED1E40210B18@oracle.com>
	<8655c6e1-0cfb-01b1-9081-f656970eeafc@oracle.com>
	<6C54D895-737D-4731-BE16-06F4658ADE49@oracle.com>
Message-ID: <d1da8509-523c-a4ad-4282-aacf0f7f4bcd@oracle.com>

Hi Manajit,

Could you improve the alignment of lines 272-286?

--Semyon


On 6/13/2016 2:29 PM, Manajit Halder wrote:
> Hi Semyon and Sergey,
>
> Code is modified as per the comment. Please review the modified webrev.
>
> http://cr.openjdk.java.net/~mhalder/8155740/webrev.04/ 
> <http://cr.openjdk.java.net/%7Emhalder/8155740/webrev.04/>
>
> webrev.02 did not work because -
> The input nsFlag (modifier value) passed to the function 
> NsKeyModifiersToJavaModifiers was not correct. The calculation of 
> modifierwas not wrong and hence wrong modifier values was returned 
> from the method.
>
> Test cases run:
> Remaining two tests present in 
> https://java.net/jira/browse/MACOSX_PORT passed with the fix.
> java/awt/Dialog/NestedDialogs/Modal/NestedModalDialogTest.java
> java/awt/Dialog/NestedDialogs/Modeless/NestedModelessDialogTest.java
>
> Thanks,
> Manajit
>
>> On 01-Jun-2016, at 11:24 pm, Semyon Sadetsky 
>> <semyon.sadetsky at oracle.com <mailto:semyon.sadetsky at oracle.com>> wrote:
>>
>> Hi Manaji,
>>
>> Okay, back to werev.01.
>>
>> Could you remove the comment in lines 262-268 since you assume that 
>> it is not true anymore and so CGEventCreateKeyboardEvent/CGEventPost 
>> will not cause any troubles.
>>
>> Did you analyze why werev.02 fix did not pass those tests?
>>
>> --Semyon
>>
>>
>> On 6/1/2016 4:46 PM, Manajit Halder wrote:
>>> Hi  Semyon and Sergey,
>>>
>>> After running the tests shared by Sergey I found that the second 
>>> webrev (webrev.01) shared by me solves the problem.
>>>
>>> http://cr.openjdk.java.net/~mhalder/8155740/webrev.01/ 
>>> <http://cr.openjdk.java.net/%7Emhalder/8155740/webrev.01/>
>>>
>>> Following tests were present in 
>>> https://java.net/jira/browse/MACOSX_PORT-621:
>>> closed/java/awt/KeyboardFocusmanager/ConsumeNextMnemonicKeyTypedTest/ConsumeNextMnemonicKeyTypedTest
>>> java/awt/Dialog/NestedDialogs/Modal/NestedModalDialogTest.java
>>> java/awt/Dialog/NestedDialogs/Modeless/NestedModelessDialogTest.java
>>>
>>> But only first test (which is now present as part of open code) 
>>> could be performed and the remaining tests were not found in the 
>>> present code.
>>> The first test fails due to another issue (JDK-8156460), whose fix 
>>> is in progress and will be send for after this issue. This fix 
>>> (JDK-8155740) is not related to the failure of the first test case.
>>>
>>> The new location of the first test:
>>> java/awt/KeyboardFocusmanager/ConsumeNextMnemonicKeyTypedTest/ConsumeNextMnemonicKeyTypedTest
>>>
>>>  Please review the webrev.01.
>>>
>>> Thanks,
>>> Manajit
>>>
>>>> On 26-May-2016, at 1:05 pm, Semyon Sadetsky 
>>>> <semyon.sadetsky at oracle.com <mailto:semyon.sadetsky at oracle.com>> wrote:
>>>>
>>>> On 5/24/2016 2:09 PM, Manajit Halder wrote:
>>>>
>>>>> Hi Semyon,
>>>>>
>>>>> It is not clear in the comment what was the problem, but it looks 
>>>>> like the problem was observed just by 
>>>>> using CGEventCreateKeyboardEvent/CGEventPost. In my case I don?t 
>>>>> see any issues just by using the fix. It posts all the key events 
>>>>> and all the key events are tested in the test file modified along 
>>>>> with the fix.
>>>> If you found the comment is not actual anymore, why did you 
>>>> preserve it?
>>>>
>>>> --Semyon
>>>>>
>>>>> Apart from the unknown problem mentioned in the existing comment 
>>>>> this fix has following advantages:
>>>>>
>>>>>   * Key codes for modifier key are required to distinguish between
>>>>>     Alt and Alt-Gr key, which is not possible by using existing
>>>>>     solution as it doesn?t post key codes for modifier keys. And
>>>>>     also keys can?t be distinguished base on modifier value, which
>>>>>     is same for both keys (Alt and Alt-Gr).
>>>>>   * As mentioned in the existing
>>>>>     comment CGEventCreateKeyboardEvent/CGEventPost is a better
>>>>>     solution.
>>>>>   * Online search about keyboard simulation showed
>>>>>     that CGEventCreateKeyboardEvent/CGEventPost is used to
>>>>>     simulate key stores in most of the cases.
>>>>>   * Tested the key codes, didn?t observe any problem.
>>>>>
>>>>>
>>>>> Regarding number keys not working 
>>>>> with CGEventCreateKeyboardEvent/CGEventPost:
>>>>> Solved the problem by providing event source 
>>>>> to CGEventCreateKeyboardEvent. Code is modified.
>>>>>
>>>>> Please review the modified code:
>>>>> http://cr.openjdk.java.net/~mhalder/8155740/webrev.02/
>>>>>
>>>>> Thanks,
>>>>> Manajit
>>>>>
>>>>>> On 20-May-2016, at 12:02 am, Semyon Sadetsky 
>>>>>> <semyon.sadetsky at oracle.com <mailto:semyon.sadetsky at oracle.com>> 
>>>>>> wrote:
>>>>>>
>>>>>> Hi Manajit,
>>>>>>
>>>>>> Before your fix all key codes wa sent using
>>>>>>
>>>>>> AXUIElementCreateSystemWide();
>>>>>>
>>>>>> and CGEventCreateKeyboardEvent was commented or excluded from 
>>>>>> compilation:
>>>>>>
>>>>>> 274 #if 0
>>>>>>  275     CGEventRef event = CGEventCreateKeyboardEvent(NULL, 
>>>>>> keyCode, keyPressed);
>>>>>>  276     if (event != NULL) {
>>>>>>  277 CGEventPost(kCGSessionEventTap, event);
>>>>>>  278         CFRelease(event);
>>>>>>  279     }
>>>>>>  280 #endif
>>>>>>
>>>>>> I just wonder why it was done. Maybe that was some other issue 
>>>>>> fix. The comment above states:
>>>>>>
>>>>>>  262      * Well, using CGEventCreateKeyboardEvent/CGEventPost 
>>>>>> would have been
>>>>>>  263      * a better solution, however, it gives me all kinds of 
>>>>>> trouble and I have
>>>>>>  264      * no idea how to solve them without inserting delays 
>>>>>> between simulated
>>>>>>  265      * events. So, I've ended up disabling it and opted for 
>>>>>> another approach
>>>>>>  266      * that uses Accessibility API instead.
>>>>>>
>>>>>> I don't understand what trouble is mentioned in the comment 
>>>>>> above. But in your fix you've put the CGEventCreateKeyboardEvent 
>>>>>> back, may it return this trouble back?
>>>>>>
>>>>>> Also as I understand Numpad number keys did not work as well. 
>>>>>> Could you add the corresponding test case since you provide a fix 
>>>>>> this extra issue?
>>>>>>
>>>>>> --Semyon
>>>>>>
>>>>>>
>>>>>> On 5/13/2016 11:50 PM, Manajit Halder wrote:
>>>>>>> Hi Semyon,
>>>>>>>
>>>>>>> The fix is changed a bit because it was observed that the 
>>>>>>> modifier keys plus alphabet keys were not working together. In 
>>>>>>> the modified fix only Num keys are posted by 
>>>>>>> AXUIElementPostKeyboardEvent and remaining keys are posted by 
>>>>>>> CGPostKeyboardEvent/CGEventPost. The fix is explained in the 
>>>>>>> comment in file CRobot.m.
>>>>>>>
>>>>>>> Please review the new changes:
>>>>>>> _http://cr.openjdk.java.net/~mhalder/8155740/webrev.01/_
>>>>>>> _
>>>>>>> _
>>>>>>>
>>>>>>> Answers to your questions:
>>>>>>>
>>>>>>> What is difference between AXUIElementPostKeyboardEvent and 
>>>>>>> CGEventCreateKeyboardEvent?
>>>>>>>
>>>>>>> Difference as per the documentation:
>>>>>>> AXUIElementPostKeyboardEvent is similar to CGPostKeyboardEvent 
>>>>>>> (which synthesizes a low-level keyboard event on the local 
>>>>>>> machine), but it allows you to specify the target application as 
>>>>>>> opposed to always sending the events to the active application. 
>>>>>>> If the system-wide accessibility object is passed in the 
>>>>>>> application parameter, the event is sent to the active application.
>>>>>>>
>>>>>>> Difference behaviour as per the implementation observed while 
>>>>>>> debugging the code:
>>>>>>> AXUIElementPostKeyboardEvent:
>>>>>>> AXUIElementPostKeyboardEvent posts 0 key code for all the 
>>>>>>> modifier keys with key codes 16, 17,18, 20, 157 and also for 
>>>>>>> newly added modifier key VK_ALT_GRAPH. But it posts correct key 
>>>>>>> code for all the remaining keys.
>>>>>>> While debugging it was that for modifier keys keyDown and keyUp 
>>>>>>> events are not generated, but flagsChanged event (flagsChanged: 
>>>>>>> (NSEvent *)event) is generated. But for all other keys keyDown 
>>>>>>> followed by keyUp events are generated.
>>>>>>>
>>>>>>> CGEventCreateKeyboardEvent:
>>>>>>> CGEventCreateKeyboardEvent posts correct key code for all the 
>>>>>>> keys except for numeric keys (numbers 0 to 9 on normal 
>>>>>>> keyboard). CGEventCreateKeyboardEvent posts wrong key codes for 
>>>>>>> the number keys 0 to 9. Instead of posting number key codes it 
>>>>>>> posts Numpad key codes for the corresponding number key. For 
>>>>>>> example Numpad0 key code is posted for number 0, Numpad1 key 
>>>>>>> code is posted for number 1 and simillarly for remaining num keys.
>>>>>>> Why the latter was commented? Does it mean that valid modifier 
>>>>>>> keys have not been sent by AWT robot?
>>>>>>>
>>>>>>> I didn?t get your question clearly. If you meant why in the 
>>>>>>> current implementation the later part (fix using 
>>>>>>> CGPostKeyboardEvent) of fix was commented.
>>>>>>> I am not very sure about it. As per the comment it is only clear 
>>>>>>> that CGPostKeyboardEvent/CGEventPost would have been a better 
>>>>>>> solution and I agree with that, perhaps reason could be related 
>>>>>>> to the difference in behaviour observed while debugging the code 
>>>>>>> as mentioned above.
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Manajit
>>>>>>>
>>>>>>>> Hi Manajit,
>>>>>>>>
>>>>>>>> Just a few questions to clarify on the fix.
>>>>>>>> What is difference between AXUIElementPostKeyboardEvent and 
>>>>>>>> CGEventCreateKeyboardEvent?
>>>>>>>
>>>>>>>> Why the latter was commented? Does it mean that valid modifier 
>>>>>>>> keys have not been sent by AWT robot?
>>>>>>>>
>>>>>>>> --Semyon
>>>>>>>>
>>>>>>>>
>>>>>>>> On 5/12/2016 10:45 AM, Manajit Halder wrote:
>>>>>>>>> Hi All,
>>>>>>>>>
>>>>>>>>> Kindly review the fix for JDK9.
>>>>>>>>>
>>>>>>>>> *Bug*:
>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8155740
>>>>>>>>> _
>>>>>>>>> _
>>>>>>>>> *Webrev*:
>>>>>>>>> http://cr.openjdk.java.net/~mhalder/8155740/webrev.00/
>>>>>>>>>
>>>>>>>>> *Issue: *
>>>>>>>>> [macosx] robot.keyPress and robot.keyRelease do not generate 
>>>>>>>>> key event for Alt-Graph key VK_ALT_GRAPH.
>>>>>>>>>
>>>>>>>>> *Cause: *
>>>>>>>>> VK_ALT_GRAPH is a new key added to the Mac OS X platform and 
>>>>>>>>> it is not mapped to any key on the OS X platform.
>>>>>>>>>
>>>>>>>>> *Fix: *
>>>>>>>>> VK_ALT_GRAPH is mapped to right option (OSX_RightOption) key 
>>>>>>>>> on Mac OS X.
>>>>>>>>>
>>>>>>>>> Method Java_sun_lwawt_macosx_CRobot_keyEvent is modified for 
>>>>>>>>> the following reason:
>>>>>>>>> AXUIElementPostKeyboardEvent posts 0 key code for all  the 
>>>>>>>>> modifier keys with key codes (16, 17,18, 20, 157) and also for 
>>>>>>>>> newly added modifier key VK_ALT_GRAPH.
>>>>>>>>> But it posts correct key code for all the other keys. On the 
>>>>>>>>> other hand CGEventCreateKeyboardEvent posts correct key code 
>>>>>>>>> for all the modifier keys and
>>>>>>>>> hence it is used to post modifier key events and 
>>>>>>>>> AXUIElementPostKeyboardEvent is used to post all the remaining 
>>>>>>>>> key events.
>>>>>>>>>
>>>>>>>>> Regards,
>>>>>>>>> Manajit
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>

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

From semyon.sadetsky at oracle.com  Tue Jun 14 14:23:16 2016
From: semyon.sadetsky at oracle.com (Semyon Sadetsky)
Date: Tue, 14 Jun 2016 17:23:16 +0300
Subject: <AWT Dev> <AWT dev>[9] Review request for 8117886: There is no
 tooltip while moving the mouse on the tray icon.
Message-ID: <293d6978-fb6c-9307-a53e-17e0bb9b8a37@oracle.com>

Hello,

Please review fix for JDK9:

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

webrev: http://cr.openjdk.java.net/~ssadetsky/8117886/webrev.00/

gnome3 DE got a new DE notifications bar, so the tooltips for tray icons 
have gone.

Just note about that in the TrayIcon's javadoc.

--Semyon


From semyon.sadetsky at oracle.com  Tue Jun 14 14:27:58 2016
From: semyon.sadetsky at oracle.com (Semyon Sadetsky)
Date: Tue, 14 Jun 2016 17:27:58 +0300
Subject: <AWT Dev> <AWT dev>[9] Review request for 8016313:
 java.awt.Headless exception has no spec since its creation
Message-ID: <eaf42488-1a84-7718-7b28-ecf753716366@oracle.com>

Hello,

Please review fix for JDK9:

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

webrev: http://cr.openjdk.java.net/~ssadetsky/8016313/webrev.00/

HeadlessException was poorly specified. The improved javadocs are added 
to the class.

--Semyon


From philip.race at oracle.com  Tue Jun 14 17:44:24 2016
From: philip.race at oracle.com (Phil Race)
Date: Tue, 14 Jun 2016 10:44:24 -0700
Subject: <AWT Dev> <AWT dev>[9] Review request for 8016313:
 java.awt.Headless exception has no spec since its creation
In-Reply-To: <eaf42488-1a84-7718-7b28-ecf753716366@oracle.com>
References: <eaf42488-1a84-7718-7b28-ecf753716366@oracle.com>
Message-ID: <57604278.6060501@oracle.com>

My reading of the original complaint about this is that the "extra" default
message occurs only if the environment is considered to actually be 
headless.
Your update to the specification does not seem to explicitly account for 
this.

You need to add words along the lines of
"The text of the default headless message may depend on
whether the GraphicsEnvironment is in fact headless.
That is, the default headless message is both system and environmentally
dependent."

-phil.

On 06/14/2016 07:27 AM, Semyon Sadetsky wrote:
> Hello,
>
> Please review fix for JDK9:
>
> bug: https://bugs.openjdk.java.net/browse/JDK-8016313
>
> webrev: http://cr.openjdk.java.net/~ssadetsky/8016313/webrev.00/
>
> HeadlessException was poorly specified. The improved javadocs are 
> added to the class.
>
> --Semyon
>


From manajit.halder at oracle.com  Tue Jun 14 18:48:16 2016
From: manajit.halder at oracle.com (Manajit Halder)
Date: Wed, 15 Jun 2016 00:18:16 +0530
Subject: <AWT Dev> <AWT dev>[9] Review request for JDK-8155740: [macosx]
	robot.keyPress and robot.keyRelease do not generate key event
	for Alt-Graph key VK_ALT_GRAPH.
In-Reply-To: <d1da8509-523c-a4ad-4282-aacf0f7f4bcd@oracle.com>
References: <538F0C0F-2C53-49CD-96B5-F78A794E3177@oracle.com>
	<5734A835.80908@oracle.com>
	<75CD4BD9-983C-4315-A5FC-3518C37BECF7@oracle.com>
	<573E06C5.5040807@oracle.com>
	<4CFAD53C-0E2F-43B4-854C-BFF1CEB944A5@oracle.com>
	<082a4f05-f5f2-01d0-5951-dc36b3dafbe5@oracle.com>
	<F3869358-BE09-42E0-8F39-ED1E40210B18@oracle.com>
	<8655c6e1-0cfb-01b1-9081-f656970eeafc@oracle.com>
	<6C54D895-737D-4731-BE16-06F4658ADE49@oracle.com>
	<d1da8509-523c-a4ad-4282-aacf0f7f4bcd@oracle.com>
Message-ID: <D132FC13-E80E-43AF-A62A-E92BE6028C8B@oracle.com>

Hi Semyon,

Alignement is improved and it looks correct on Xcode and Netbeans.
Please review the latest webrev:

http://cr.openjdk.java.net/~mhalder/8155740/webrev.05/ <http://cr.openjdk.java.net/~mhalder/8155740/webrev.05/>

Thanks,
Manajit

> On 14-Jun-2016, at 3:17 pm, Semyon Sadetsky <semyon.sadetsky at oracle.com> wrote:
> 
> Hi Manajit,
> 
> Could you improve the alignment of lines 272-286?
> 
> --Semyon
> 
> On 6/13/2016 2:29 PM, Manajit Halder wrote:
>> Hi Semyon and Sergey,
>> 
>> Code is modified as per the comment. Please review the modified webrev.
>> 
>> http://cr.openjdk.java.net/~mhalder/8155740/webrev.04/ <http://cr.openjdk.java.net/%7Emhalder/8155740/webrev.04/>
>> 
>> webrev.02 did not work because -
>> 	The input nsFlag (modifier value) passed to the function NsKeyModifiersToJavaModifiers was not correct. The calculation of modifier was not wrong and hence wrong modifier values was returned from the method.
>> 
>> Test cases run:
>> Remaining two tests present in  <https://java.net/jira/browse/MACOSX_PORT>https://java.net/jira/browse/MACOSX_PORT <https://java.net/jira/browse/MACOSX_PORT> passed with the fix.
>> java/awt/Dialog/NestedDialogs/Modal/NestedModalDialogTest.java
>> java/awt/Dialog/NestedDialogs/Modeless/NestedModelessDialogTest.java
>> 
>> Thanks,
>> Manajit
>> 
>>> On 01-Jun-2016, at 11:24 pm, Semyon Sadetsky <semyon.sadetsky at oracle.com <mailto:semyon.sadetsky at oracle.com>> wrote:
>>> 
>>> Hi Manaji,
>>> 
>>> Okay, back to werev.01.
>>> 
>>> Could you remove the comment in lines 262-268 since you assume that it is not true anymore and so CGEventCreateKeyboardEvent/CGEventPost will not cause any troubles.  
>>> Did you analyze why werev.02 fix did not pass those tests?
>>> 
>>> --Semyon
>>> 
>>> On 6/1/2016 4:46 PM, Manajit Halder wrote:
>>>> Hi  Semyon and Sergey,
>>>> 
>>>> After running the tests shared by Sergey I found that the second webrev (webrev.01) shared by me solves the problem.
>>>> 
>>>> http://cr.openjdk.java.net/~mhalder/8155740/webrev.01/ <http://cr.openjdk.java.net/%7Emhalder/8155740/webrev.01/>
>>>> 
>>>> Following tests were present in  <https://java.net/jira/browse/MACOSX_PORT-621>https://java.net/jira/browse/MACOSX_PORT-621 <https://java.net/jira/browse/MACOSX_PORT-621>:
>>>> closed/java/awt/KeyboardFocusmanager/ConsumeNextMnemonicKeyTypedTest/ConsumeNextMnemonicKeyTypedTest
>>>> java/awt/Dialog/NestedDialogs/Modal/NestedModalDialogTest.java
>>>> java/awt/Dialog/NestedDialogs/Modeless/NestedModelessDialogTest.java
>>>> 
>>>> But only first test (which is now present as part of open code) could be performed and the remaining tests were not found in the present code.
>>>> The first test fails due to another issue (JDK-8156460), whose fix is in progress and will be send for after this issue. This fix (JDK-8155740) is not related to the failure of the first test case.
>>>> 
>>>> The new location of the first test:
>>>> java/awt/KeyboardFocusmanager/ConsumeNextMnemonicKeyTypedTest/ConsumeNextMnemonicKeyTypedTest
>>>> 
>>>>  Please review the webrev.01.
>>>> 
>>>> Thanks,
>>>> Manajit
>>>> 
>>>>> On 26-May-2016, at 1:05 pm, Semyon Sadetsky <semyon.sadetsky at oracle.com <mailto:semyon.sadetsky at oracle.com>> wrote:
>>>>> 
>>>>> On 5/24/2016 2:09 PM, Manajit Halder wrote:
>>>>>> Hi Semyon,
>>>>>> 
>>>>>> It is not clear in the comment what was the problem, but it looks like the problem was observed just by using CGEventCreateKeyboardEvent/CGEventPost. In my case I don?t see any issues just by using the fix. It posts all the key events and all the key events are tested in the test file modified along with the fix.
>>>>> If you found the comment is not actual anymore, why did you preserve it?
>>>>> 
>>>>> --Semyon
>>>>>> 
>>>>>> Apart from the unknown problem mentioned in the existing comment this fix has following advantages:
>>>>>> Key codes for modifier key are required to distinguish between Alt and Alt-Gr key, which is not possible by using existing solution as it doesn?t post key codes for modifier keys. And also keys can?t be distinguished base on modifier value, which is same for both keys (Alt and Alt-Gr).
>>>>>> As mentioned in the existing comment CGEventCreateKeyboardEvent/CGEventPost is a better solution.
>>>>>> Online search about keyboard simulation showed that CGEventCreateKeyboardEvent/CGEventPost is used to simulate key stores in most of the cases.
>>>>>> Tested the key codes, didn?t observe any problem.
>>>>>> 
>>>>>> Regarding number keys not working with CGEventCreateKeyboardEvent/CGEventPost:
>>>>>> 	Solved the problem by providing event source to CGEventCreateKeyboardEvent. Code is modified. 
>>>>>> 
>>>>>> Please review the modified code:
>>>>>>  <http://cr.openjdk.java.net/%7Emhalder/8155740/webrev.02/>http://cr.openjdk.java.net/~mhalder/8155740/webrev.02/ <http://cr.openjdk.java.net/~mhalder/8155740/webrev.02/>
>>>>>> 
>>>>>> Thanks,
>>>>>> Manajit
>>>>>> 
>>>>>>> On 20-May-2016, at 12:02 am, Semyon Sadetsky < <mailto:semyon.sadetsky at oracle.com>semyon.sadetsky at oracle.com <mailto:semyon.sadetsky at oracle.com>> wrote:
>>>>>>> 
>>>>>>> Hi Manajit,
>>>>>>> 
>>>>>>> Before your fix all key codes wa sent using
>>>>>>> 
>>>>>>> AXUIElementCreateSystemWide();
>>>>>>> 
>>>>>>> and CGEventCreateKeyboardEvent was commented or excluded from compilation:
>>>>>>> 
>>>>>>> 274 #if 0
>>>>>>>  275     CGEventRef event = CGEventCreateKeyboardEvent(NULL, keyCode, keyPressed);
>>>>>>>  276     if (event != NULL) {
>>>>>>>  277         CGEventPost(kCGSessionEventTap, event);
>>>>>>>  278         CFRelease(event);
>>>>>>>  279     }
>>>>>>>  280 #endif
>>>>>>> 
>>>>>>> I just wonder why it was done. Maybe that was some other issue fix. The comment above states:
>>>>>>> 
>>>>>>>  262      * Well, using CGEventCreateKeyboardEvent/CGEventPost would have been
>>>>>>>  263      * a better solution, however, it gives me all kinds of trouble and I have
>>>>>>>  264      * no idea how to solve them without inserting delays between simulated
>>>>>>>  265      * events. So, I've ended up disabling it and opted for another approach
>>>>>>>  266      * that uses Accessibility API instead.
>>>>>>> 
>>>>>>> I don't understand what trouble is mentioned in the comment above. But in your fix you've put the CGEventCreateKeyboardEvent back, may it return this trouble back?
>>>>>>> 
>>>>>>> Also as I understand Numpad number keys did not work as well. Could you add the corresponding test case since you provide a fix this extra issue?
>>>>>>> 
>>>>>>> --Semyon
>>>>>>> 
>>>>>>> 
>>>>>>> On 5/13/2016 11:50 PM, Manajit Halder wrote:
>>>>>>>> Hi Semyon,
>>>>>>>> 
>>>>>>>> The fix is changed a bit because it was observed that the modifier keys plus alphabet keys were not working together. In the modified fix only Num keys are posted by AXUIElementPostKeyboardEvent and remaining keys are posted by CGPostKeyboardEvent/CGEventPost. The fix is explained in the comment in file CRobot.m.
>>>>>>>> 
>>>>>>>> Please review the new changes:
>>>>>>>>  <http://cr.openjdk.java.net/%7Emhalder/8155740/webrev.01/>http://cr.openjdk.java.net/~mhalder/8155740/webrev.01/ <http://cr.openjdk.java.net/~mhalder/8155740/webrev.01/>
>>>>>>>> 
>>>>>>>> 
>>>>>>>> Answers to your questions:
>>>>>>>> 
>>>>>>>> What is difference between AXUIElementPostKeyboardEvent and CGEventCreateKeyboardEvent?
>>>>>>>> 
>>>>>>>> Difference as per the documentation:
>>>>>>>> 	AXUIElementPostKeyboardEvent is similar to CGPostKeyboardEvent (which synthesizes a low-level keyboard event on the local machine), but it allows you to specify the target application as opposed to always sending the events to the active application. If the system-wide accessibility object is passed in the application parameter, the event is sent to the active application. 
>>>>>>>> 
>>>>>>>> Difference behaviour as per the implementation observed while debugging the code:
>>>>>>>> 	
>>>>>>>> AXUIElementPostKeyboardEvent:
>>>>>>>> 	AXUIElementPostKeyboardEvent posts 0 key code for all the modifier keys with key codes 16, 17,18, 20, 157 and also for newly added modifier key VK_ALT_GRAPH. But it posts correct key code for all the remaining keys.
>>>>>>>> 	While debugging it was that for modifier keys keyDown and keyUp events are not generated, but flagsChanged event (flagsChanged: (NSEvent *)event) is generated. But for all other keys keyDown followed by keyUp events are generated.
>>>>>>>> 
>>>>>>>> CGEventCreateKeyboardEvent:
>>>>>>>> 	CGEventCreateKeyboardEvent posts correct key code for all the keys except for numeric keys (numbers 0 to 9 on normal keyboard). CGEventCreateKeyboardEvent posts wrong key codes for the number keys 0 to 9. Instead of posting number key codes it posts Numpad key codes for the corresponding number key. For example Numpad0 key code is posted for number 0, Numpad1 key code is posted for number 1 and simillarly for remaining num keys.
>>>>>>>> 	
>>>>>>>> Why the latter was commented? Does it mean that valid modifier keys have not been sent by AWT robot?
>>>>>>>> 
>>>>>>>> I didn?t get your question clearly. If you meant why in the current implementation the later part (fix using CGPostKeyboardEvent) of fix was commented.
>>>>>>>> 	I am not very sure about it. As per the comment it is only clear that CGPostKeyboardEvent/CGEventPost would have been a better solution and I agree with that, perhaps reason could be related to the difference in behaviour observed while debugging the code as mentioned above.
>>>>>>>> 
>>>>>>>> Thanks,
>>>>>>>> Manajit
>>>>>>>> 
>>>>>>>>> Hi Manajit,
>>>>>>>>> 
>>>>>>>>> Just a few questions to clarify on the fix.
>>>>>>>>> What is difference between AXUIElementPostKeyboardEvent and CGEventCreateKeyboardEvent?
>>>>>>>> 	
>>>>>>>>> Why the latter was commented? Does it mean that valid modifier keys have not been sent by AWT robot?
>>>>>>>>> 
>>>>>>>>> --Semyon
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> On 5/12/2016 10:45 AM, Manajit Halder wrote:
>>>>>>>>>> Hi All,
>>>>>>>>>> 
>>>>>>>>>> Kindly review the fix for JDK9.
>>>>>>>>>> 
>>>>>>>>>> Bug: 
>>>>>>>>>>  <https://bugs.openjdk.java.net/browse/JDK-8155740>https://bugs.openjdk.java.net/browse/JDK-8155740 <https://bugs.openjdk.java.net/browse/JDK-8155740>
>>>>>>>>>> 
>>>>>>>>>> Webrev: 
>>>>>>>>>>  <http://cr.openjdk.java.net/%7Emhalder/8155740/webrev.00/>http://cr.openjdk.java.net/~mhalder/8155740/webrev.00/ <http://cr.openjdk.java.net/~mhalder/8155740/webrev.00/>
>>>>>>>>>> 
>>>>>>>>>> Issue: 
>>>>>>>>>> [macosx] robot.keyPress and robot.keyRelease do not generate key event for Alt-Graph key VK_ALT_GRAPH.
>>>>>>>>>> 
>>>>>>>>>> Cause: 
>>>>>>>>>> VK_ALT_GRAPH is a new key added to the Mac OS X platform and it is not mapped to any key on the OS X platform.
>>>>>>>>>> 
>>>>>>>>>> Fix: 
>>>>>>>>>> VK_ALT_GRAPH is mapped to right option (OSX_RightOption) key on Mac OS X.
>>>>>>>>>> 
>>>>>>>>>> Method Java_sun_lwawt_macosx_CRobot_keyEvent is modified for the following reason:
>>>>>>>>>> AXUIElementPostKeyboardEvent posts 0 key code for all  the modifier keys with key codes (16, 17,18, 20, 157) and also for newly added modifier key VK_ALT_GRAPH.
>>>>>>>>>> But it posts correct key code for all the other keys. On the other hand CGEventCreateKeyboardEvent posts correct key code for all the modifier keys and 
>>>>>>>>>> hence it is used to post modifier key events and AXUIElementPostKeyboardEvent is used to post all the remaining key events.
>>>>>>>>>> 
>>>>>>>>>> Regards,
>>>>>>>>>> Manajit
>>>>>>>>> 
>>>>>>>> 
>>>>>>> 
>>>>>> 
>>>>> 
>>>> 
>>> 
>> 
> 

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

From david.dehaven at oracle.com  Tue Jun 14 23:11:44 2016
From: david.dehaven at oracle.com (David DeHaven)
Date: Tue, 14 Jun 2016 16:11:44 -0700
Subject: <AWT Dev> Review Request: 8156960 Deprecate
	JSObject.getWindow(Applet) method
In-Reply-To: <53d819ee-a8f6-5d93-2660-1fd3e0939b41@oracle.com>
References: <1f05a2b9-a68b-4684-a58a-163189c710af@default>
	<FDD6B460-8071-40CA-8FC3-AECF9E0C4ABF@oracle.com>
	<6CB5C96E-8B7F-4093-BA02-94702BA53047@oracle.com>
	<99907f0c-961d-4d66-950f-9b4de4fc96f7@default>
	<EAF37B66-F1D5-44D0-82AB-DFB4120AB8E4@oracle.com>
	<61539153-a0c6-474d-aded-d34b6266a1c1@default>
	<3d7b40f9-6c2c-340d-cd75-0050ae0d857c@oracle.com>
	<798891A9-B63A-4DF1-B8FE-D9F9AAC4855A@oracle.com>
	<1ec98193-7a52-c73a-e07c-dfed7d02c7a1@oracle.com>
	<A6933CAA-732E-4EC4-9C78-97A12CAC20FD@oracle.com>
	<5015B87E-4029-4538-9CD7-FDFD5F52D163@oracle.com>
	<53d819ee-a8f6-5d93-2660-1fd3e0939b41@oracle.com>
Message-ID: <55FFCD3D-A4A4-4B71-B6D7-3C66B35C615B@oracle.com>


> David had said,
> 
>> it seems safer to leave it false for now and revisit marking for removal in 10
> 
> I think this means, "set forRemoval=false in 9, set forRemoval=true in 10, and actually remove it in 11".

I said that in reference to Applet, not JSObject.

I now think JSObject should be marked for removal.

-DrD-


From kevin.rushforth at oracle.com  Tue Jun 14 23:21:27 2016
From: kevin.rushforth at oracle.com (Kevin Rushforth)
Date: Tue, 14 Jun 2016 16:21:27 -0700
Subject: <AWT Dev> Review Request: 8156960 Deprecate
 JSObject.getWindow(Applet) method
In-Reply-To: <55FFCD3D-A4A4-4B71-B6D7-3C66B35C615B@oracle.com>
References: <1f05a2b9-a68b-4684-a58a-163189c710af@default>
	<FDD6B460-8071-40CA-8FC3-AECF9E0C4ABF@oracle.com>
	<6CB5C96E-8B7F-4093-BA02-94702BA53047@oracle.com>
	<99907f0c-961d-4d66-950f-9b4de4fc96f7@default>
	<EAF37B66-F1D5-44D0-82AB-DFB4120AB8E4@oracle.com>
	<61539153-a0c6-474d-aded-d34b6266a1c1@default>
	<3d7b40f9-6c2c-340d-cd75-0050ae0d857c@oracle.com>
	<798891A9-B63A-4DF1-B8FE-D9F9AAC4855A@oracle.com>
	<1ec98193-7a52-c73a-e07c-dfed7d02c7a1@oracle.com>
	<A6933CAA-732E-4EC4-9C78-97A12CAC20FD@oracle.com>
	<5015B87E-4029-4538-9CD7-FDFD5F52D163@oracle.com>
	<53d819ee-a8f6-5d93-2660-1fd3e0939b41@oracle.com>
	<55FFCD3D-A4A4-4B71-B6D7-3C66B35C615B@oracle.com>
Message-ID: <57609177.9030308@oracle.com>



David DeHaven wrote:
>> David had said,
>>
>>     
>>> it seems safer to leave it false for now and revisit marking for removal in 10
>>>       
>> I think this means, "set forRemoval=false in 9, set forRemoval=true in 10, and actually remove it in 11".
>>     
>
> I said that in reference to Applet, not JSObject.
>
> I now think JSObject should be marked for removal.
>   

Agreed.

-- Kevin

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

From semyon.sadetsky at oracle.com  Wed Jun 15 06:41:12 2016
From: semyon.sadetsky at oracle.com (Semyon Sadetsky)
Date: Wed, 15 Jun 2016 09:41:12 +0300
Subject: <AWT Dev> <AWT dev>[9] Review request for JDK-8155740: [macosx]
 robot.keyPress and robot.keyRelease do not generate key event for Alt-Graph
 key VK_ALT_GRAPH.
In-Reply-To: <D132FC13-E80E-43AF-A62A-E92BE6028C8B@oracle.com>
References: <538F0C0F-2C53-49CD-96B5-F78A794E3177@oracle.com>
	<5734A835.80908@oracle.com>
	<75CD4BD9-983C-4315-A5FC-3518C37BECF7@oracle.com>
	<573E06C5.5040807@oracle.com>
	<4CFAD53C-0E2F-43B4-854C-BFF1CEB944A5@oracle.com>
	<082a4f05-f5f2-01d0-5951-dc36b3dafbe5@oracle.com>
	<F3869358-BE09-42E0-8F39-ED1E40210B18@oracle.com>
	<8655c6e1-0cfb-01b1-9081-f656970eeafc@oracle.com>
	<6C54D895-737D-4731-BE16-06F4658ADE49@oracle.com>
	<d1da8509-523c-a4ad-4282-aacf0f7f4bcd@oracle.com>
	<D132FC13-E80E-43AF-A62A-E92BE6028C8B@oracle.com>
Message-ID: <44da048f-32d0-db9d-c44b-9420141ef2f9@oracle.com>

OK, Thanks.

Looks good to me.

--Semyon


On 6/14/2016 9:48 PM, Manajit Halder wrote:
> Hi Semyon,
>
> Alignement is improved and it looks correct on Xcode and Netbeans.
> Please review the latest webrev:
>
> http://cr.openjdk.java.net/~mhalder/8155740/webrev.05/ 
> <http://cr.openjdk.java.net/%7Emhalder/8155740/webrev.05/>
>
> Thanks,
> Manajit
>
>> On 14-Jun-2016, at 3:17 pm, Semyon Sadetsky 
>> <semyon.sadetsky at oracle.com <mailto:semyon.sadetsky at oracle.com>> wrote:
>>
>> Hi Manajit,
>>
>> Could you improve the alignment of lines 272-286?
>>
>> --Semyon
>>
>>
>> On 6/13/2016 2:29 PM, Manajit Halder wrote:
>>> Hi Semyon and Sergey,
>>>
>>> Code is modified as per the comment. Please review the modified webrev.
>>>
>>> http://cr.openjdk.java.net/~mhalder/8155740/webrev.04/ 
>>> <http://cr.openjdk.java.net/%7Emhalder/8155740/webrev.04/>
>>>
>>> webrev.02 did not work because -
>>> The input nsFlag (modifier value) passed to the function 
>>> NsKeyModifiersToJavaModifiers was not correct. The calculation of 
>>> modifierwas not wrong and hence wrong modifier values was returned 
>>> from the method.
>>>
>>> Test cases run:
>>> Remaining two tests present in 
>>> https://java.net/jira/browse/MACOSX_PORT passed with the fix.
>>> java/awt/Dialog/NestedDialogs/Modal/NestedModalDialogTest.java
>>> java/awt/Dialog/NestedDialogs/Modeless/NestedModelessDialogTest.java
>>>
>>> Thanks,
>>> Manajit
>>>
>>>> On 01-Jun-2016, at 11:24 pm, Semyon Sadetsky 
>>>> <semyon.sadetsky at oracle.com <mailto:semyon.sadetsky at oracle.com>> wrote:
>>>>
>>>> Hi Manaji,
>>>>
>>>> Okay, back to werev.01.
>>>>
>>>> Could you remove the comment in lines 262-268 since you assume that 
>>>> it is not true anymore and so 
>>>> CGEventCreateKeyboardEvent/CGEventPost will not cause any troubles.
>>>>
>>>> Did you analyze why werev.02 fix did not pass those tests?
>>>>
>>>> --Semyon
>>>>
>>>>
>>>> On 6/1/2016 4:46 PM, Manajit Halder wrote:
>>>>> Hi  Semyon and Sergey,
>>>>>
>>>>> After running the tests shared by Sergey I found that the second 
>>>>> webrev (webrev.01) shared by me solves the problem.
>>>>>
>>>>> http://cr.openjdk.java.net/~mhalder/8155740/webrev.01/ 
>>>>> <http://cr.openjdk.java.net/%7Emhalder/8155740/webrev.01/>
>>>>>
>>>>> Following tests were present in 
>>>>> https://java.net/jira/browse/MACOSX_PORT-621:
>>>>> closed/java/awt/KeyboardFocusmanager/ConsumeNextMnemonicKeyTypedTest/ConsumeNextMnemonicKeyTypedTest
>>>>> java/awt/Dialog/NestedDialogs/Modal/NestedModalDialogTest.java
>>>>> java/awt/Dialog/NestedDialogs/Modeless/NestedModelessDialogTest.java
>>>>>
>>>>> But only first test (which is now present as part of open code) 
>>>>> could be performed and the remaining tests were not found in the 
>>>>> present code.
>>>>> The first test fails due to another issue (JDK-8156460), whose fix 
>>>>> is in progress and will be send for after this issue. This fix 
>>>>> (JDK-8155740) is not related to the failure of the first test case.
>>>>>
>>>>> The new location of the first test:
>>>>> java/awt/KeyboardFocusmanager/ConsumeNextMnemonicKeyTypedTest/ConsumeNextMnemonicKeyTypedTest
>>>>>
>>>>>  Please review the webrev.01.
>>>>>
>>>>> Thanks,
>>>>> Manajit
>>>>>
>>>>>> On 26-May-2016, at 1:05 pm, Semyon Sadetsky 
>>>>>> <semyon.sadetsky at oracle.com <mailto:semyon.sadetsky at oracle.com>> 
>>>>>> wrote:
>>>>>>
>>>>>> On 5/24/2016 2:09 PM, Manajit Halder wrote:
>>>>>>
>>>>>>> Hi Semyon,
>>>>>>>
>>>>>>> It is not clear in the comment what was the problem, but it 
>>>>>>> looks like the problem was observed just by 
>>>>>>> using CGEventCreateKeyboardEvent/CGEventPost. In my case I don?t 
>>>>>>> see any issues just by using the fix. It posts all the key 
>>>>>>> events and all the key events are tested in the test file 
>>>>>>> modified along with the fix.
>>>>>> If you found the comment is not actual anymore, why did you 
>>>>>> preserve it?
>>>>>>
>>>>>> --Semyon
>>>>>>>
>>>>>>> Apart from the unknown problem mentioned in the existing comment 
>>>>>>> this fix has following advantages:
>>>>>>>
>>>>>>>   * Key codes for modifier key are required to distinguish
>>>>>>>     between Alt and Alt-Gr key, which is not possible by using
>>>>>>>     existing solution as it doesn?t post key codes for modifier
>>>>>>>     keys. And also keys can?t be distinguished base on modifier
>>>>>>>     value, which is same for both keys (Alt and Alt-Gr).
>>>>>>>   * As mentioned in the existing
>>>>>>>     comment CGEventCreateKeyboardEvent/CGEventPost is a better
>>>>>>>     solution.
>>>>>>>   * Online search about keyboard simulation showed
>>>>>>>     that CGEventCreateKeyboardEvent/CGEventPost is used to
>>>>>>>     simulate key stores in most of the cases.
>>>>>>>   * Tested the key codes, didn?t observe any problem.
>>>>>>>
>>>>>>>
>>>>>>> Regarding number keys not working 
>>>>>>> with CGEventCreateKeyboardEvent/CGEventPost:
>>>>>>> Solved the problem by providing event source 
>>>>>>> to CGEventCreateKeyboardEvent. Code is modified.
>>>>>>>
>>>>>>> Please review the modified code:
>>>>>>> http://cr.openjdk.java.net/~mhalder/8155740/webrev.02/
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Manajit
>>>>>>>
>>>>>>>> On 20-May-2016, at 12:02 am, Semyon Sadetsky 
>>>>>>>> <semyon.sadetsky at oracle.com> wrote:
>>>>>>>>
>>>>>>>> Hi Manajit,
>>>>>>>>
>>>>>>>> Before your fix all key codes wa sent using
>>>>>>>>
>>>>>>>> AXUIElementCreateSystemWide();
>>>>>>>>
>>>>>>>> and CGEventCreateKeyboardEvent was commented or excluded from 
>>>>>>>> compilation:
>>>>>>>>
>>>>>>>> 274 #if 0
>>>>>>>>  275     CGEventRef event = CGEventCreateKeyboardEvent(NULL, 
>>>>>>>> keyCode, keyPressed);
>>>>>>>>  276     if (event != NULL) {
>>>>>>>>  277 CGEventPost(kCGSessionEventTap, event);
>>>>>>>>  278 CFRelease(event);
>>>>>>>>  279     }
>>>>>>>>  280 #endif
>>>>>>>>
>>>>>>>> I just wonder why it was done. Maybe that was some other issue 
>>>>>>>> fix. The comment above states:
>>>>>>>>
>>>>>>>>  262      * Well, using CGEventCreateKeyboardEvent/CGEventPost 
>>>>>>>> would have been
>>>>>>>>  263      * a better solution, however, it gives me all kinds 
>>>>>>>> of trouble and I have
>>>>>>>>  264      * no idea how to solve them without inserting delays 
>>>>>>>> between simulated
>>>>>>>>  265      * events. So, I've ended up disabling it and opted 
>>>>>>>> for another approach
>>>>>>>>  266      * that uses Accessibility API instead.
>>>>>>>>
>>>>>>>> I don't understand what trouble is mentioned in the comment 
>>>>>>>> above. But in your fix you've put the 
>>>>>>>> CGEventCreateKeyboardEvent back, may it return this trouble back?
>>>>>>>>
>>>>>>>> Also as I understand Numpad number keys did not work as well. 
>>>>>>>> Could you add the corresponding test case since you provide a 
>>>>>>>> fix this extra issue?
>>>>>>>>
>>>>>>>> --Semyon
>>>>>>>>
>>>>>>>>
>>>>>>>> On 5/13/2016 11:50 PM, Manajit Halder wrote:
>>>>>>>>> Hi Semyon,
>>>>>>>>>
>>>>>>>>> The fix is changed a bit because it was observed that the 
>>>>>>>>> modifier keys plus alphabet keys were not working together. In 
>>>>>>>>> the modified fix only Num keys are posted by 
>>>>>>>>> AXUIElementPostKeyboardEvent and remaining keys are posted by 
>>>>>>>>> CGPostKeyboardEvent/CGEventPost. The fix is explained in the 
>>>>>>>>> comment in file CRobot.m.
>>>>>>>>>
>>>>>>>>> Please review the new changes:
>>>>>>>>> _http://cr.openjdk.java.net/~mhalder/8155740/webrev.01/_
>>>>>>>>> _
>>>>>>>>> _
>>>>>>>>>
>>>>>>>>> Answers to your questions:
>>>>>>>>>
>>>>>>>>> What is difference between AXUIElementPostKeyboardEvent and 
>>>>>>>>> CGEventCreateKeyboardEvent?
>>>>>>>>>
>>>>>>>>> Difference as per the documentation:
>>>>>>>>> AXUIElementPostKeyboardEvent is similar to CGPostKeyboardEvent 
>>>>>>>>> (which synthesizes a low-level keyboard event on the local 
>>>>>>>>> machine), but it allows you to specify the target application 
>>>>>>>>> as opposed to always sending the events to the active 
>>>>>>>>> application. If the system-wide accessibility object is passed 
>>>>>>>>> in the application parameter, the event is sent to the active 
>>>>>>>>> application.
>>>>>>>>>
>>>>>>>>> Difference behaviour as per the implementation observed while 
>>>>>>>>> debugging the code:
>>>>>>>>> AXUIElementPostKeyboardEvent:
>>>>>>>>> AXUIElementPostKeyboardEvent posts 0 key code for all the 
>>>>>>>>> modifier keys with key codes 16, 17,18, 20, 157 and also for 
>>>>>>>>> newly added modifier key VK_ALT_GRAPH. But it posts correct 
>>>>>>>>> key code for all the remaining keys.
>>>>>>>>> While debugging it was that for modifier keys keyDown and 
>>>>>>>>> keyUp events are not generated, but flagsChanged event 
>>>>>>>>> (flagsChanged: (NSEvent *)event) is generated. But for all 
>>>>>>>>> other keys keyDown followed by keyUp events are generated.
>>>>>>>>>
>>>>>>>>> CGEventCreateKeyboardEvent:
>>>>>>>>> CGEventCreateKeyboardEvent posts correct key code for all the 
>>>>>>>>> keys except for numeric keys (numbers 0 to 9 on normal 
>>>>>>>>> keyboard). CGEventCreateKeyboardEvent posts wrong key codes 
>>>>>>>>> for the number keys 0 to 9. Instead of posting number key 
>>>>>>>>> codes it posts Numpad key codes for the corresponding number 
>>>>>>>>> key. For example Numpad0 key code is posted for number 0, 
>>>>>>>>> Numpad1 key code is posted for number 1 and simillarly for 
>>>>>>>>> remaining num keys.
>>>>>>>>> Why the latter was commented? Does it mean that valid modifier 
>>>>>>>>> keys have not been sent by AWT robot?
>>>>>>>>>
>>>>>>>>> I didn?t get your question clearly. If you meant why in the 
>>>>>>>>> current implementation the later part (fix using 
>>>>>>>>> CGPostKeyboardEvent) of fix was commented.
>>>>>>>>> I am not very sure about it. As per the comment it is only 
>>>>>>>>> clear that CGPostKeyboardEvent/CGEventPost would have been a 
>>>>>>>>> better solution and I agree with that, perhaps reason could be 
>>>>>>>>> related to the difference in behaviour observed while 
>>>>>>>>> debugging the code as mentioned above.
>>>>>>>>>
>>>>>>>>> Thanks,
>>>>>>>>> Manajit
>>>>>>>>>
>>>>>>>>>> Hi Manajit,
>>>>>>>>>>
>>>>>>>>>> Just a few questions to clarify on the fix.
>>>>>>>>>> What is difference between AXUIElementPostKeyboardEvent and 
>>>>>>>>>> CGEventCreateKeyboardEvent?
>>>>>>>>>
>>>>>>>>>> Why the latter was commented? Does it mean that valid 
>>>>>>>>>> modifier keys have not been sent by AWT robot?
>>>>>>>>>>
>>>>>>>>>> --Semyon
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On 5/12/2016 10:45 AM, Manajit Halder wrote:
>>>>>>>>>>> Hi All,
>>>>>>>>>>>
>>>>>>>>>>> Kindly review the fix for JDK9.
>>>>>>>>>>>
>>>>>>>>>>> *Bug*:
>>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8155740
>>>>>>>>>>> _
>>>>>>>>>>> _
>>>>>>>>>>> *Webrev*:
>>>>>>>>>>> http://cr.openjdk.java.net/~mhalder/8155740/webrev.00/
>>>>>>>>>>>
>>>>>>>>>>> *Issue: *
>>>>>>>>>>> [macosx] robot.keyPress and robot.keyRelease do not generate 
>>>>>>>>>>> key event for Alt-Graph key VK_ALT_GRAPH.
>>>>>>>>>>>
>>>>>>>>>>> *Cause: *
>>>>>>>>>>> VK_ALT_GRAPH is a new key added to the Mac OS X platform and 
>>>>>>>>>>> it is not mapped to any key on the OS X platform.
>>>>>>>>>>>
>>>>>>>>>>> *Fix: *
>>>>>>>>>>> VK_ALT_GRAPH is mapped to right option (OSX_RightOption) key 
>>>>>>>>>>> on Mac OS X.
>>>>>>>>>>>
>>>>>>>>>>> Method Java_sun_lwawt_macosx_CRobot_keyEvent is modified for 
>>>>>>>>>>> the following reason:
>>>>>>>>>>> AXUIElementPostKeyboardEvent posts 0 key code for all  the 
>>>>>>>>>>> modifier keys with key codes (16, 17,18, 20, 157) and also 
>>>>>>>>>>> for newly added modifier key VK_ALT_GRAPH.
>>>>>>>>>>> But it posts correct key code for all the other keys. On the 
>>>>>>>>>>> other hand CGEventCreateKeyboardEvent posts correct key code 
>>>>>>>>>>> for all the modifier keys and
>>>>>>>>>>> hence it is used to post modifier key events and 
>>>>>>>>>>> AXUIElementPostKeyboardEvent is used to post all the 
>>>>>>>>>>> remaining key events.
>>>>>>>>>>>
>>>>>>>>>>> Regards,
>>>>>>>>>>> Manajit
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>

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

From semyon.sadetsky at oracle.com  Wed Jun 15 07:11:28 2016
From: semyon.sadetsky at oracle.com (Semyon Sadetsky)
Date: Wed, 15 Jun 2016 10:11:28 +0300
Subject: <AWT Dev> <AWT dev>[9] Review request for 8016313:
 java.awt.Headless exception has no spec since its creation
In-Reply-To: <57604278.6060501@oracle.com>
References: <eaf42488-1a84-7718-7b28-ecf753716366@oracle.com>
	<57604278.6060501@oracle.com>
Message-ID: <ed322620-0f97-1ee0-195d-2862f27135fc@oracle.com>

Thanks for review. Please look at the updated webrev: 
http://cr.openjdk.java.net/~ssadetsky/8016313/webrev.01/

--Semyon


On 6/14/2016 8:44 PM, Phil Race wrote:
> My reading of the original complaint about this is that the "extra" 
> default
> message occurs only if the environment is considered to actually be 
> headless.
> Your update to the specification does not seem to explicitly account 
> for this.
>
> You need to add words along the lines of
> "The text of the default headless message may depend on
> whether the GraphicsEnvironment is in fact headless.
> That is, the default headless message is both system and environmentally
> dependent."
>
> -phil.
>
> On 06/14/2016 07:27 AM, Semyon Sadetsky wrote:
>> Hello,
>>
>> Please review fix for JDK9:
>>
>> bug: https://bugs.openjdk.java.net/browse/JDK-8016313
>>
>> webrev: http://cr.openjdk.java.net/~ssadetsky/8016313/webrev.00/
>>
>> HeadlessException was poorly specified. The improved javadocs are 
>> added to the class.
>>
>> --Semyon
>>
>


From ambarish.rapte at oracle.com  Wed Jun 15 09:13:00 2016
From: ambarish.rapte at oracle.com (Ambarish Rapte)
Date: Wed, 15 Jun 2016 02:13:00 -0700 (PDT)
Subject: <AWT Dev> Review request for 8158616: [TEST_BUG] There is only
 "Fail" button on the description dialog
Message-ID: <0208ff0e-d357-41b3-b8ec-dceaefca3e8a@default>

Hi ,

Please review the test bug fix for JDK9,

Webrev: http://cr.openjdk.java.net/~arapte/8158616/webrev.00/

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

 

 

Issue: 

Misleading description to click pass button in test steps for Windows.

But there is no pass button.

As the pass criteria is verified programmatically, there is no need of Pass button.

 

Fix:

Corrected the description &

Skipping the test execution for Windows platform, as the test is automated under Robot class.

 

Verification:

Test executes successfully on Windows, Ubunu & Mac

 

 

Regards,

Ambarish

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

From semyon.sadetsky at oracle.com  Wed Jun 15 09:37:47 2016
From: semyon.sadetsky at oracle.com (Semyon Sadetsky)
Date: Wed, 15 Jun 2016 12:37:47 +0300
Subject: <AWT Dev> Review request for 8158616: [TEST_BUG] There is only
 "Fail" button on the description dialog
In-Reply-To: <0208ff0e-d357-41b3-b8ec-dceaefca3e8a@default>
References: <0208ff0e-d357-41b3-b8ec-dceaefca3e8a@default>
Message-ID: <20eed0d6-b5b6-6d94-f5ec-a68916c03bea@oracle.com>

Hi Ambarish,

Does it mean that the test was automatic on Windows and manual on other 
OSes?

--Semyon


On 6/15/2016 12:13 PM, Ambarish Rapte wrote:
>
> Hi ,
>
> Please review the test bug fix for JDK9,
>
> Webrev: http://cr.openjdk.java.net/~arapte/8158616/webrev.00/ 
> <http://cr.openjdk.java.net/%7Earapte/8158616/webrev.00/>
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8158616
>
> Issue:
>
> Misleading description to click pass button in test steps for Windows.
>
> But there is no pass button.
>
> As the pass criteria is verified programmatically, there is no need of 
> Pass button.
>
> Fix:
>
> Corrected the description &
>
> Skipping the test execution for Windows platform, as the test is 
> automated under Robot class.
>
> Verification:
>
> Test executes successfully on Windows, Ubunu & Mac
>
> Regards,
>
> Ambarish
>

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

From ambarish.rapte at oracle.com  Wed Jun 15 11:05:24 2016
From: ambarish.rapte at oracle.com (Ambarish Rapte)
Date: Wed, 15 Jun 2016 04:05:24 -0700 (PDT)
Subject: <AWT Dev> Review request for 8158616: [TEST_BUG] There is only
 "Fail" button on the description dialog
In-Reply-To: <20eed0d6-b5b6-6d94-f5ec-a68916c03bea@oracle.com>
References: <0208ff0e-d357-41b3-b8ec-dceaefca3e8a@default>
	<20eed0d6-b5b6-6d94-f5ec-a68916c03bea@oracle.com>
Message-ID: <c6efe01e-2dbb-44b8-9a6d-efffafa9206a@default>

Hi Semyon,

 

Yes, the test is automatic for windows and it is tested with the test: test/java/awt/Robot/ModifierRobotKey/ModifierRobotKeyTest.java

Windows robot supports Alt-Gr key press: http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/80766aba7d32

Hence the test could be automated.

 

But on Linux and mac robot does not support Alt-Gr key press yet, hence the test is manual.

 

Regards,

Ambarish

 

From: Semyon Sadetsky 
Sent: Wednesday, June 15, 2016 3:08 PM
To: Ambarish Rapte; Prasanta Sadhukhan; Sergey Bylokhov; awt-dev at openjdk.java.net
Subject: Re: Review request for 8158616: [TEST_BUG] There is only "Fail" button on the description dialog

 

Hi Ambarish,

Does it mean that the test was automatic on Windows and manual on other OSes?

--Semyon

 

On 6/15/2016 12:13 PM, Ambarish Rapte wrote:

Hi ,

Please review the test bug fix for JDK9,

Webrev: http://cr.openjdk.java.net/~arapte/8158616/webrev.00/

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

 

 

Issue: 

Misleading description to click pass button in test steps for Windows.

But there is no pass button.

As the pass criteria is verified programmatically, there is no need of Pass button.

 

Fix:

Corrected the description &

Skipping the test execution for Windows platform, as the test is automated under Robot class.

 

Verification:

Test executes successfully on Windows, Ubunu & Mac

 

 

Regards,

Ambarish

 

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

From ambarish.rapte at oracle.com  Wed Jun 15 15:09:54 2016
From: ambarish.rapte at oracle.com (Ambarish Rapte)
Date: Wed, 15 Jun 2016 08:09:54 -0700 (PDT)
Subject: <AWT Dev> Review request for 8151588: Press the button first two
 times, the 'First' and 'Next' didn't show
Message-ID: <1473e148-0210-45e2-88dc-d77cd4106170@default>

Hi,

Please review this fix for JDK9,

Webrev: http://cr.openjdk.java.net/~arapte/8151588/webrev.00/

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

 

 

Issue:

When Text Area is not in focus, If select or append is called on Text Area and if the desired text is not in visible area

then the Text Area should auto scroll to make the desired text visible.

But this behavior was broken due to fix of,

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

Patch(1): http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/b9f91de8ae43

 

 

Fix:

Issue JDK-6180449 is also fixed by fix of,

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

http://hg.openjdk.java.net/jdk9/client/jdk/rev/4a1e160a12c3

 

Hence reverting the fix Patch(1) for JDK-6180449 to fix this regression.

 

 

Verification:

All JCK tests for Text Area pass, no other test fails due to this change.

The newly added test with this fix, fails without the patch and passes after merging the patch.

 

 

Regards,

Ambarish

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

From semyon.sadetsky at oracle.com  Wed Jun 15 15:23:20 2016
From: semyon.sadetsky at oracle.com (Semyon Sadetsky)
Date: Wed, 15 Jun 2016 18:23:20 +0300
Subject: <AWT Dev> Review request for 8158616: [TEST_BUG] There is only
 "Fail" button on the description dialog
In-Reply-To: <c6efe01e-2dbb-44b8-9a6d-efffafa9206a@default>
References: <0208ff0e-d357-41b3-b8ec-dceaefca3e8a@default>
	<20eed0d6-b5b6-6d94-f5ec-a68916c03bea@oracle.com>
	<c6efe01e-2dbb-44b8-9a6d-efffafa9206a@default>
Message-ID: <5332c203-1809-0300-29c8-57daed73b241@oracle.com>



On 6/15/2016 2:05 PM, Ambarish Rapte wrote:
>
> Hi Semyon,
>
> Yes, the test is automatic for windows and it is tested with the test: 
> test/java/awt/Robot/ModifierRobotKey/ModifierRobotKeyTest.java
>
> Windows robot supports Alt-Gr key press: 
> http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/80766aba7d32
>
> Hence the test could be automated.
>
> But on Linux and mac robot does not support Alt-Gr key press yet, 
> hence the test is manual.
>
It seems for mac this also will fixed as JDK-8155740 is pushed, right?

--Semyon
>
> Regards,
>
> Ambarish
>
> *From:*Semyon Sadetsky
> *Sent:* Wednesday, June 15, 2016 3:08 PM
> *To:* Ambarish Rapte; Prasanta Sadhukhan; Sergey Bylokhov; 
> awt-dev at openjdk.java.net
> *Subject:* Re: Review request for 8158616: [TEST_BUG] There is only 
> "Fail" button on the description dialog
>
> Hi Ambarish,
>
> Does it mean that the test was automatic on Windows and manual on 
> other OSes?
>
> --Semyon
>
> On 6/15/2016 12:13 PM, Ambarish Rapte wrote:
>
>     Hi ,
>
>     Please review the test bug fix for JDK9,
>
>     Webrev: http://cr.openjdk.java.net/~arapte/8158616/webrev.00/
>     <http://cr.openjdk.java.net/%7Earapte/8158616/webrev.00/>
>
>     Bug: https://bugs.openjdk.java.net/browse/JDK-8158616
>
>     Issue:
>
>     Misleading description to click pass button in test steps for Windows.
>
>     But there is no pass button.
>
>     As the pass criteria is verified programmatically, there is no
>     need of Pass button.
>
>     Fix:
>
>     Corrected the description &
>
>     Skipping the test execution for Windows platform, as the test is
>     automated under Robot class.
>
>     Verification:
>
>     Test executes successfully on Windows, Ubunu & Mac
>
>     Regards,
>
>     Ambarish
>

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

From prem.balakrishnan at oracle.com  Thu Jun 16 05:58:48 2016
From: prem.balakrishnan at oracle.com (Prem Balakrishnan)
Date: Wed, 15 Jun 2016 22:58:48 -0700 (PDT)
Subject: <AWT Dev> Review Request: JDK-8158478 : X11 keysym XK_topt maps
 to the wrong Unicode character
In-Reply-To: <01958dab-24a1-457d-9e44-07d8b1d9f71a@default>
References: <01958dab-24a1-457d-9e44-07d8b1d9f71a@default>
Message-ID: <2b335df9-711a-44c9-96e6-dc21cbaa02ab@default>

Reminder

?

From: Prem Balakrishnan 
Sent: Monday, June 06, 2016 3:50 PM
To: Sergey Bylokhov; Semyon Sadetsky; Ambarish Rapte; awt-dev at openjdk.java.net
Subject: Review Request: JDK-8158478 : X11 keysym XK_topt maps to the wrong Unicode character

?

Hi,

Please review fix for JDK9,

?

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

?

Webrev: http://cr.openjdk.java.net/~pkbalakr/8158478/webrev.00/ 

?

?

Issue:

X11 keysym XK_topt maps to the wrong Unicode character.

?

?

Cause:

XK_topt ?is set to Display the Symbol ?? ( U+242C un defined)

?

Fix:

XK_topt ?is set to Displays the Symbol ? (U+252C: BOX DRAWINGS LIGHT DOWN AND HORIZONTAL)

?

Thanks,

Prem

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

From goetz.lindenmaier at sap.com  Thu Jun 16 14:40:53 2016
From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz)
Date: Thu, 16 Jun 2016 14:40:53 +0000
Subject: <AWT Dev> RFR(L): 8159690: [TESTBUG] Mark headful tests with @key
	headful.
Message-ID: <906afad52c284df2bc8a509e00007912@DEWDFE13DE09.global.corp.sap>

Hi,

we have test machines without X server. On these many of the jdk
jtreg tests fail with a headless exception.
We grepped for this exception in the test output and identified
about 450 tests.

In these tests, we added with another script "@key headful".
So that the script generates better output, I adapted the
formatting of some of the test descriptions.
see also the text in the webrev, where I posted some incremental diffs
of the changes I more or less edited by hand.  I hope this eases
reviewing :)

Last, I updated the Copyrights with the script by Coleen.

Please review this change.
http://cr.openjdk.java.net/~goetz/wr16/8159690-headful/webrev.01/

Best regards,
  Goetz.


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

From volker.simonis at gmail.com  Thu Jun 16 15:02:09 2016
From: volker.simonis at gmail.com (Volker Simonis)
Date: Thu, 16 Jun 2016 17:02:09 +0200
Subject: <AWT Dev> <Swing Dev> RFR(L): 8159690: [TESTBUG] Mark headful
 tests with @key headful.
In-Reply-To: <906afad52c284df2bc8a509e00007912@DEWDFE13DE09.global.corp.sap>
References: <906afad52c284df2bc8a509e00007912@DEWDFE13DE09.global.corp.sap>
Message-ID: <CA+3eh121kaSySnaVj2o8UwRymsV5cneZ-WcgQncHmTHPju93HA@mail.gmail.com>

Hi Goetz,

the change looks good.
Thanks for doing this Sisyphean task!

We should nevertheless wait for another review from somebody from the
AWT/Swing team.

Regards,
Volker


On Thu, Jun 16, 2016 at 4:40 PM, Lindenmaier, Goetz
<goetz.lindenmaier at sap.com> wrote:
> Hi,
>
>
>
> we have test machines without X server. On these many of the jdk
>
> jtreg tests fail with a headless exception.
>
> We grepped for this exception in the test output and identified
>
> about 450 tests.
>
>
>
> In these tests, we added with another script "@key headful".
>
> So that the script generates better output, I adapted the
>
> formatting of some of the test descriptions.
>
> see also the text in the webrev, where I posted some incremental diffs
>
> of the changes I more or less edited by hand.  I hope this eases
>
> reviewing :)
>
>
>
> Last, I updated the Copyrights with the script by Coleen.
>
>
>
> Please review this change.
>
> http://cr.openjdk.java.net/~goetz/wr16/8159690-headful/webrev.01/
>
>
>
> Best regards,
>
>   Goetz.
>
>
>
>

From alexandr.scherbatiy at oracle.com  Thu Jun 16 15:55:46 2016
From: alexandr.scherbatiy at oracle.com (Alexandr Scherbatiy)
Date: Thu, 16 Jun 2016 18:55:46 +0300
Subject: <AWT Dev> RFR(L): 8159690: [TESTBUG] Mark headful tests with
 @key headful.
In-Reply-To: <906afad52c284df2bc8a509e00007912@DEWDFE13DE09.global.corp.sap>
References: <906afad52c284df2bc8a509e00007912@DEWDFE13DE09.global.corp.sap>
Message-ID: <791258f1-0e1a-9b09-7021-816137e1146b@oracle.com>

On 6/16/2016 5:40 PM, Lindenmaier, Goetz wrote:
>
> Hi,
>
> we have test machines without X server. On these many of the jdk
>
> jtreg tests fail with a headless exception.
>
> We grepped for this exception in the test output and identified
>
> about 450 tests.
>
> In these tests, we added with another script "@key headful".
>
    What is a number of tests which passe in headless mode?

   I would expect that an ordinary client test which use Frame and fails 
in headless mode does not require a special key by default.

   Thanks,
   Alexandr.

> So that the script generates better output, I adapted the
>
> formatting of some of the test descriptions.
>
> see also the text in the webrev, where I posted some incremental diffs
>
> of the changes I more or less edited by hand.  I hope this eases
>
> reviewing :)
>
> Last, I updated the Copyrights with the script by Coleen.
>
> Please review this change.
>
> http://cr.openjdk.java.net/~goetz/wr16/8159690-headful/webrev.01/ 
> <http://cr.openjdk.java.net/%7Egoetz/wr16/8159690-headful/webrev.01/>
>
> Best regards,
>
>   Goetz.
>

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

From neugens at redhat.com  Thu Jun 16 16:47:29 2016
From: neugens at redhat.com (Mario Torre)
Date: Thu, 16 Jun 2016 18:47:29 +0200
Subject: <AWT Dev> Taking screenshots on x11 composite desktop produce
 wrong result
In-Reply-To: <d9e526c0-b7ad-45af-df67-23407490b96c@oracle.com>
References: <CAJwKKmZ__GVT6aVRA+gNJ=gYnwNAmkG18BLmju2A05Vrkr+QrQ@mail.gmail.com>
	<56D713BB.5030305@oracle.com>
	<CAJwKKmaTc2Oe9E3y57y5iG1keqA9jU_NJCy1yQEe0GTG3QXokg@mail.gmail.com>
	<CAJwKKmb9USyRxSmEw_U2ur6cAAkmPJDBmhQN=4EV0u9wkqw5hA@mail.gmail.com>
	<CAJwKKmYDYGcgdtZLTaimE=8Y_PDdB22dB1C+58CfXDnA-t6n+w@mail.gmail.com>
	<5704EA02.1090500@oracle.com>
	<CAJwKKmaxvNMTfSrz1Tk0ChMC8ZcRWkRXbo9ZU1dKbwerKb_ymw@mail.gmail.com>
	<5704FAD9.50805@oracle.com>
	<CAGUMyaSERCsb2KrumOGxLALHqgWM=uT=FrrKSBxPFM-3WAR3VA@mail.gmail.com>
	<a33b671c-f478-f430-431e-8fc5e589c5d9@oracle.com>
	<CAGUMyaROjZ33O2yRtvdRWf9UBG7r7823A9me6rh-5zEmt7bGWQ@mail.gmail.com>
	<5594e799-8935-f079-2fe3-60b5079eab4a@oracle.com>
	<131c0e73-8fc9-2db2-b4bf-b110d4fcdbeb@oracle.com>
	<b7d3a594-9fca-ad39-71c8-eed46acbc138@oracle.com>
	<CAJwKKmb7CpgcOQdLviOm3SxtV37K7YaotZZpDpG6w3Ryc1Lzug@mail.gmail.com>
	<d9e526c0-b7ad-45af-df67-23407490b96c@oracle.com>
Message-ID: <CAJwKKmYXarJo_CCSOQKoK4ofY7XRAkGq+fzfP33Vk05STWYffg@mail.gmail.com>

On Wed, Jun 1, 2016 at 1:52 PM, Semyon Sadetsky
<semyon.sadetsky at oracle.com> wrote:
>
>
> On 6/1/2016 2:39 PM, Mario Torre wrote:
>>
>> On Wed, Jun 1, 2016 at 1:23 PM, Semyon Sadetsky
>> <semyon.sadetsky at oracle.com> wrote:
>>>
>>> I ran JPRT build. It seems that the build server does not have the
>>> requested
>>> header:
>>>
>>>
>>> /opt/jprt/T/P1/102200.ssadetsk/s/jdk/src/java.desktop/unix/native/libawt_xawt/awt/awt_Robot.c:40:39:
>>> fatal error: X11/extensions/Xcomposite.h: No such file or directory
>>>   #include <X11/extensions/Xcomposite.h>
>>>
>>> someone need to install Xcomposite library there
>>>
>> Should this be made optional?
>>
>> I can do some dlsym hack if necessary (I would prefer to avoid that
>> though).
>
> Apparently dlsym is the shortest way to fix that issue and you don't need to
> modify the makefile in that case.

Well, to be honest, I think Xcomposite should just be a requirement, I
believe all the systems that OpenJDK 9 targets as "supported" have
that library, it just needs to be installed.

Anyway, this is the patch with the dl-stuff hacks:

http://cr.openjdk.java.net/~neugens/8150954/webrev.06/

The only question I have is where to unload the library, I gave a look
at what the XToolkit code does with GTK, and it seems that it's just
never unloaded (there's a method to unload the library, but looks like
it's never used anywhere, except, of course, if some functions fail to
load in the first place, which is what I also do here). I think this
is not a real problem though, so rather than making the whole code a
lot more complex I would keep it that way, YMMV.

I believe I need again two approvals now.

Cheers,
Mario

From volker.simonis at gmail.com  Fri Jun 17 08:36:27 2016
From: volker.simonis at gmail.com (Volker Simonis)
Date: Fri, 17 Jun 2016 10:36:27 +0200
Subject: <AWT Dev> <Swing Dev> RFR(L): 8159690: [TESTBUG] Mark headful
 tests with @key headful.
In-Reply-To: <791258f1-0e1a-9b09-7021-816137e1146b@oracle.com>
References: <906afad52c284df2bc8a509e00007912@DEWDFE13DE09.global.corp.sap>
	<791258f1-0e1a-9b09-7021-816137e1146b@oracle.com>
Message-ID: <CA+3eh13uvD2dpc0dk5kN-WgpdiLmjS=LtzA3=ZTJ3xcYV+=b0g@mail.gmail.com>

On Thu, Jun 16, 2016 at 5:55 PM, Alexandr Scherbatiy
<alexandr.scherbatiy at oracle.com> wrote:
> On 6/16/2016 5:40 PM, Lindenmaier, Goetz wrote:
>
> Hi,
>
>
>
> we have test machines without X server. On these many of the jdk
>
> jtreg tests fail with a headless exception.
>
> We grepped for this exception in the test output and identified
>
> about 450 tests.
>
>
>
> In these tests, we added with another script "@key headful".
>
>    What is a number of tests which passe in headless mode?
>
>   I would expect that an ordinary client test which use Frame and fails in
> headless mode does not require a special key by default.
>

Hi Alexandr,

I don't quite understand your concerns, but the purpose of this change
is to make it possible to simply exclude all tests which require a
"headful" environment from a jtreg run.

There are AWT/Swing tests which can be run even without X server. For example:

java/awt/image/DrawImage/DrawImageCoordsTest.java

Others, like for example:

java/awt/image/DrawImage/EABlitTest.jtr

will throw a Headless exception and fail:

java.awt.HeadlessException:
No X11 DISPLAY variable was set, but this program performed an
operation which requires it.

With Goetz's change we can simply exclude all the test which require a
headful environment by specifying "-keywords:\!headful" to jtreg.
After all, I think that's the purpose why the "headful" keyword has
been introduced.

If there's any other simple way of excluding all tests which require a
headful environment, please let us now.

Regards,
Volker

>   Thanks,
>   Alexandr.
>
>
> So that the script generates better output, I adapted the
>
> formatting of some of the test descriptions.
>
> see also the text in the webrev, where I posted some incremental diffs
>
> of the changes I more or less edited by hand.  I hope this eases
>
> reviewing :)
>
>
>
> Last, I updated the Copyrights with the script by Coleen.
>
>
>
> Please review this change.
>
> http://cr.openjdk.java.net/~goetz/wr16/8159690-headful/webrev.01/
>
>
>
> Best regards,
>
>   Goetz.
>
>
>
>
>
>

From semyon.sadetsky at oracle.com  Fri Jun 17 08:42:21 2016
From: semyon.sadetsky at oracle.com (Semyon Sadetsky)
Date: Fri, 17 Jun 2016 11:42:21 +0300
Subject: <AWT Dev> [9] Review request for 8159460: On Ubuntu Unity,
 problem with java/awt/Window/FindOwner/FindOwnerTest
Message-ID: <25427b06-a42f-fd3b-a33d-e2a1c6dd9aea@oracle.com>

Hello,

Please review fix for JDK9:

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

webrev: http://cr.openjdk.java.net/~ssadetsky/8159460/webrev.00/

On Unity WM_TAKE_FOCUS notification is sent to the decorated parent 
window if its undecorated child window is clicked by mouse, after that 
ButtonPress notification is sent. Those notifications causes two 
parallel sequences of AWT events to gain focus to different windows. 
Since focus requests are asynchronous the resulting focus may by 
obtained randomly by the clicked child window or by its owner.

The fix solution is : in case of Unity WM, do not change the current 
focused window if the incoming WM_TAKE_FOCUS is addressed the current 
active window and the current focused window owned by the active 
window.  This solution should prevent racing focus requests on Unity.

--Semyon




From goetz.lindenmaier at sap.com  Fri Jun 17 08:42:44 2016
From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz)
Date: Fri, 17 Jun 2016 08:42:44 +0000
Subject: <AWT Dev> RFR(L): 8159690: [TESTBUG] Mark headful tests with
 @key headful.
In-Reply-To: <791258f1-0e1a-9b09-7021-816137e1146b@oracle.com>
References: <906afad52c284df2bc8a509e00007912@DEWDFE13DE09.global.corp.sap>
	<791258f1-0e1a-9b09-7021-816137e1146b@oracle.com>
Message-ID: <e49392281e3249cd8ae6e73a6f17eba5@DEWDFE13DE09.global.corp.sap>

Hi Alexandr,

> What is a number of tests which passe in headless mode?
Do you mean you want to know wheter there are awt/swing tests that are
passing in headless mode and if yes, how many?
  javax/swing: 223 passing
  sun/java2d:   34 passing
  java/awt:    312 pasing

> I would expect that an ordinary client test which use Frame and 
> fails in headless mode does not require a special key by default.
You mean the jtreg runner somehow finds out that the failure is
caused by running headless, after having the test executed? I 
don't think that's possible.  
Or do you exclude these tests by another mechanism?

I did this change following the pattern of 
http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/1cce0248f3e1
https://bugs.openjdk.java.net/browse/JDK-8081547

Best regards,
  Goetz.

> -----Original Message-----
> From: Alexandr Scherbatiy [mailto:alexandr.scherbatiy at oracle.com]
> Sent: Donnerstag, 16. Juni 2016 17:56
> To: Lindenmaier, Goetz <goetz.lindenmaier at sap.com>; swing-
> dev at openjdk.java.net; awt-dev at openjdk.java.net
> Subject: Re: <AWT Dev> RFR(L): 8159690: [TESTBUG] Mark headful tests with
> @key headful.
> 
> On 6/16/2016 5:40 PM, Lindenmaier, Goetz wrote:
> 
> 
> 	Hi,
> 
> 
> 
> 	we have test machines without X server. On these many of the jdk
> 
> 	jtreg tests fail with a headless exception.
> 
> 	We grepped for this exception in the test output and identified
> 
> 	about 450 tests.
> 
> 
> 
> 	In these tests, we added with another script "@key headful".
> 
>    What is a number of tests which passe in headless mode?
> 
>   I would expect that an ordinary client test which use Frame and fails in
> headless mode does not require a special key by default.
> 
>   Thanks,
>   Alexandr.
> 
> 
> 
> 
> 
> 	So that the script generates better output, I adapted the
> 
> 	formatting of some of the test descriptions.
> 
> 	see also the text in the webrev, where I posted some incremental
> diffs
> 
> 	of the changes I more or less edited by hand.  I hope this eases
> 
> 	reviewing :)
> 
> 
> 
> 	Last, I updated the Copyrights with the script by Coleen.
> 
> 
> 
> 	Please review this change.
> 
> 	<http://cr.openjdk.java.net/%7Egoetz/wr16/8159690-
> headful/webrev.01/> http://cr.openjdk.java.net/~goetz/wr16/8159690-
> headful/webrev.01/
> 
> 
> 
> 	Best regards,
> 
> 	  Goetz.
> 
> 
> 
> 
> 


From dmitry.markov at oracle.com  Fri Jun 17 10:45:04 2016
From: dmitry.markov at oracle.com (dmitry markov)
Date: Fri, 17 Jun 2016 13:45:04 +0300
Subject: <AWT Dev> [9] Review request for 8154816: Caps Lock doesn't work as
 expected when using Pinyin Simplified input method
Message-ID: <5763D4B0.4030209@oracle.com>

Hello,

Could you review a fix for jdk9, please?

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

Problem description:
When Pinyin Simplified input method is selected and 'Caps Lock' is on, 
input is switched to latin letters, but letters are entered in uppercase.

Fix:
It is necessary to ignore 'Caps Lock' modifier in 
CPlatformResponder.handleKeyEvent() method, if Pinyin Simplified input 
method is selected and 'Caps Lock' is on.

Thanks,
Dmitry

From dmitry.markov at oracle.com  Fri Jun 17 12:39:41 2016
From: dmitry.markov at oracle.com (dmitry markov)
Date: Fri, 17 Jun 2016 15:39:41 +0300
Subject: <AWT Dev> [9] Review request for 8148984: [macosx] Chinese Comma
 cannot be entered using Pinyin Input Method on OS X
Message-ID: <5763EF8D.5010309@oracle.com>

Hello,

Could you review a fix for jdk9, please?

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

Problem description:
'Latin comma' character is entered in text component instead of the 
required 'fullwidth comma' character, when ',' character is pressed on 
the keyboard and Pinyin ? Traditional or Simplified IM is enabled, 
because KeyEvent is generated instead of InputMethodEvent.

Fix:
It is necessary to generate InputMethodEvent for the characters from 
'Halfwidth and Fullwidth Forms' Unicode block (U+FF00 - U+FFEF). So the 
method isCodePointInUnicodeBlockNeedingIMEvent() in AWTView.m should be 
updated.

Thanks,
Dmitry

From alexandr.scherbatiy at oracle.com  Fri Jun 17 12:53:22 2016
From: alexandr.scherbatiy at oracle.com (Alexandr Scherbatiy)
Date: Fri, 17 Jun 2016 15:53:22 +0300
Subject: <AWT Dev> <Swing Dev> RFR(L): 8159690: [TESTBUG] Mark headful
 tests with @key headful.
In-Reply-To: <CA+3eh13uvD2dpc0dk5kN-WgpdiLmjS=LtzA3=ZTJ3xcYV+=b0g@mail.gmail.com>
References: <906afad52c284df2bc8a509e00007912@DEWDFE13DE09.global.corp.sap>
	<791258f1-0e1a-9b09-7021-816137e1146b@oracle.com>
	<CA+3eh13uvD2dpc0dk5kN-WgpdiLmjS=LtzA3=ZTJ3xcYV+=b0g@mail.gmail.com>
Message-ID: <67f94b06-23fb-a280-f706-20808cab000e@oracle.com>

On 6/17/2016 11:36 AM, Volker Simonis wrote:
> On Thu, Jun 16, 2016 at 5:55 PM, Alexandr Scherbatiy
> <alexandr.scherbatiy at oracle.com> wrote:
>> On 6/16/2016 5:40 PM, Lindenmaier, Goetz wrote:
>>
>> Hi,
>>
>>
>>
>> we have test machines without X server. On these many of the jdk
>>
>> jtreg tests fail with a headless exception.
>>
>> We grepped for this exception in the test output and identified
>>
>> about 450 tests.
>>
>>
>>
>> In these tests, we added with another script "@key headful".
>>
>>     What is a number of tests which passe in headless mode?
>>
>>    I would expect that an ordinary client test which use Frame and fails in
>> headless mode does not require a special key by default.
>>
> Hi Alexandr,
>
> I don't quite understand your concerns, but the purpose of this change
> is to make it possible to simply exclude all tests which require a
> "headful" environment from a jtreg run.
>
> There are AWT/Swing tests which can be run even without X server. For example:
>
> java/awt/image/DrawImage/DrawImageCoordsTest.java
>
> Others, like for example:
>
> java/awt/image/DrawImage/EABlitTest.jtr
>
> will throw a Headless exception and fail:
>
> java.awt.HeadlessException:
> No X11 DISPLAY variable was set, but this program performed an
> operation which requires it.
>
> With Goetz's change we can simply exclude all the test which require a
> headful environment by specifying "-keywords:\!headful" to jtreg.
> After all, I think that's the purpose why the "headful" keyword has
> been introduced.
>
> If there's any other simple way of excluding all tests which require a
> headful environment, please let us now.
    For example, the test 
jdk/test/javax/swing/AbstractButton/6711682/bug6711682.java when it is 
run with -Djava.awt.headless=true option fails with exception 
"java.awt.AWTException: headless environment".

   The test is not listed in the proposed patch. Is it correct that this 
test requires the "headful" environment and should be marked with the 
"headful" keyword?

   Thanks,
   Alexandr.

>
> Regards,
> Volker
>
>>    Thanks,
>>    Alexandr.
>>
>>
>> So that the script generates better output, I adapted the
>>
>> formatting of some of the test descriptions.
>>
>> see also the text in the webrev, where I posted some incremental diffs
>>
>> of the changes I more or less edited by hand.  I hope this eases
>>
>> reviewing :)
>>
>>
>>
>> Last, I updated the Copyrights with the script by Coleen.
>>
>>
>>
>> Please review this change.
>>
>> http://cr.openjdk.java.net/~goetz/wr16/8159690-headful/webrev.01/
>>
>>
>>
>> Best regards,
>>
>>    Goetz.
>>
>>
>>
>>
>>
>>


From goetz.lindenmaier at sap.com  Fri Jun 17 13:17:18 2016
From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz)
Date: Fri, 17 Jun 2016 13:17:18 +0000
Subject: <AWT Dev> <Swing Dev> RFR(L): 8159690: [TESTBUG] Mark headful
 tests with @key headful.
In-Reply-To: <67f94b06-23fb-a280-f706-20808cab000e@oracle.com>
References: <906afad52c284df2bc8a509e00007912@DEWDFE13DE09.global.corp.sap>
	<791258f1-0e1a-9b09-7021-816137e1146b@oracle.com>
	<CA+3eh13uvD2dpc0dk5kN-WgpdiLmjS=LtzA3=ZTJ3xcYV+=b0g@mail.gmail.com>
	<67f94b06-23fb-a280-f706-20808cab000e@oracle.com>
Message-ID: <503e07b1c4c5469d8a0ed516cb5bb01c@DEWDFE13DE09.global.corp.sap>

Hi Alexandr,

yes, you are right, the test you mention is missing in this change.
There are others, too, and we still have lots of failures for other 
reasons.

We are currently working on getting all the tests green in
our test environment where we test linuxppc64, linuxppc64le
and aixppc64 (and, for reference, the Oracle platforms).
So I will address all the remaining issues at some point.

If you basically agree on this change, I would appreciate if we
could push this one and I make a follow up change.  Handling
changes with this many files is a pain point.  But I can also 
extend this change so that we get all of them at once.

Best regards,
 Goetz.



> -----Original Message-----
> From: Alexandr Scherbatiy [mailto:alexandr.scherbatiy at oracle.com]
> Sent: Freitag, 17. Juni 2016 14:53
> To: Volker Simonis <volker.simonis at gmail.com>
> Cc: Lindenmaier, Goetz <goetz.lindenmaier at sap.com>; swing-
> dev at openjdk.java.net; awt-dev at openjdk.java.net
> Subject: Re: <Swing Dev> <AWT Dev> RFR(L): 8159690: [TESTBUG] Mark
> headful tests with @key headful.
> 
> On 6/17/2016 11:36 AM, Volker Simonis wrote:
> > On Thu, Jun 16, 2016 at 5:55 PM, Alexandr Scherbatiy
> > <alexandr.scherbatiy at oracle.com> wrote:
> >> On 6/16/2016 5:40 PM, Lindenmaier, Goetz wrote:
> >>
> >> Hi,
> >>
> >>
> >>
> >> we have test machines without X server. On these many of the jdk
> >>
> >> jtreg tests fail with a headless exception.
> >>
> >> We grepped for this exception in the test output and identified
> >>
> >> about 450 tests.
> >>
> >>
> >>
> >> In these tests, we added with another script "@key headful".
> >>
> >>     What is a number of tests which passe in headless mode?
> >>
> >>    I would expect that an ordinary client test which use Frame and fails in
> >> headless mode does not require a special key by default.
> >>
> > Hi Alexandr,
> >
> > I don't quite understand your concerns, but the purpose of this change
> > is to make it possible to simply exclude all tests which require a
> > "headful" environment from a jtreg run.
> >
> > There are AWT/Swing tests which can be run even without X server. For
> example:
> >
> > java/awt/image/DrawImage/DrawImageCoordsTest.java
> >
> > Others, like for example:
> >
> > java/awt/image/DrawImage/EABlitTest.jtr
> >
> > will throw a Headless exception and fail:
> >
> > java.awt.HeadlessException:
> > No X11 DISPLAY variable was set, but this program performed an
> > operation which requires it.
> >
> > With Goetz's change we can simply exclude all the test which require a
> > headful environment by specifying "-keywords:\!headful" to jtreg.
> > After all, I think that's the purpose why the "headful" keyword has
> > been introduced.
> >
> > If there's any other simple way of excluding all tests which require a
> > headful environment, please let us now.
>     For example, the test
> jdk/test/javax/swing/AbstractButton/6711682/bug6711682.java when it is
> run with -Djava.awt.headless=true option fails with exception
> "java.awt.AWTException: headless environment".
> 
>    The test is not listed in the proposed patch. Is it correct that this
> test requires the "headful" environment and should be marked with the
> "headful" keyword?
> 
>    Thanks,
>    Alexandr.
> 
> >
> > Regards,
> > Volker
> >
> >>    Thanks,
> >>    Alexandr.
> >>
> >>
> >> So that the script generates better output, I adapted the
> >>
> >> formatting of some of the test descriptions.
> >>
> >> see also the text in the webrev, where I posted some incremental diffs
> >>
> >> of the changes I more or less edited by hand.  I hope this eases
> >>
> >> reviewing :)
> >>
> >>
> >>
> >> Last, I updated the Copyrights with the script by Coleen.
> >>
> >>
> >>
> >> Please review this change.
> >>
> >> http://cr.openjdk.java.net/~goetz/wr16/8159690-headful/webrev.01/
> >>
> >>
> >>
> >> Best regards,
> >>
> >>    Goetz.
> >>
> >>
> >>
> >>
> >>
> >>


From alexandr.scherbatiy at oracle.com  Fri Jun 17 13:40:59 2016
From: alexandr.scherbatiy at oracle.com (Alexandr Scherbatiy)
Date: Fri, 17 Jun 2016 16:40:59 +0300
Subject: <AWT Dev> <Swing Dev> RFR(L): 8159690: [TESTBUG] Mark headful
 tests with @key headful.
In-Reply-To: <503e07b1c4c5469d8a0ed516cb5bb01c@DEWDFE13DE09.global.corp.sap>
References: <906afad52c284df2bc8a509e00007912@DEWDFE13DE09.global.corp.sap>
	<791258f1-0e1a-9b09-7021-816137e1146b@oracle.com>
	<CA+3eh13uvD2dpc0dk5kN-WgpdiLmjS=LtzA3=ZTJ3xcYV+=b0g@mail.gmail.com>
	<67f94b06-23fb-a280-f706-20808cab000e@oracle.com>
	<503e07b1c4c5469d8a0ed516cb5bb01c@DEWDFE13DE09.global.corp.sap>
Message-ID: <32a8ced1-f5f5-d3e1-4834-254bcb106165@oracle.com>

On 6/17/2016 4:17 PM, Lindenmaier, Goetz wrote:
> Hi Alexandr,
>
> yes, you are right, the test you mention is missing in this change.
> There are others, too, and we still have lots of failures for other
> reasons.
>
> We are currently working on getting all the tests green in
> our test environment where we test linuxppc64, linuxppc64le
> and aixppc64 (and, for reference, the Oracle platforms).
> So I will address all the remaining issues at some point.
>
> If you basically agree on this change, I would appreciate if we
> could push this one and I make a follow up change.  Handling
> changes with this many files is a pain point.  But I can also
> extend this change so that we get all of them at once.

    As I see there are areas like jdk_beans or jdk_imageio which usually 
does not require headful environment and jdk_awt or jdk_swing which 
usually requires it. It seems that ordinary AWT/Swing tests require the 
"headful" keyword.

   May be it is more appropriate to have "headful" keyword for areas 
like jdk_beans and "headless" keyword for areas like jdk_awt and 
jdk_swing? This will allow to mark only small part of tests with 
necessary keyword for each area.

   In other way almost all AWT/Swing tests should be marked by "headful" 
keyword.

   Thanks,
   Alexandr.

>
> Best regards,
>   Goetz.
>
>
>
>> -----Original Message-----
>> From: Alexandr Scherbatiy [mailto:alexandr.scherbatiy at oracle.com]
>> Sent: Freitag, 17. Juni 2016 14:53
>> To: Volker Simonis <volker.simonis at gmail.com>
>> Cc: Lindenmaier, Goetz <goetz.lindenmaier at sap.com>; swing-
>> dev at openjdk.java.net; awt-dev at openjdk.java.net
>> Subject: Re: <Swing Dev> <AWT Dev> RFR(L): 8159690: [TESTBUG] Mark
>> headful tests with @key headful.
>>
>> On 6/17/2016 11:36 AM, Volker Simonis wrote:
>>> On Thu, Jun 16, 2016 at 5:55 PM, Alexandr Scherbatiy
>>> <alexandr.scherbatiy at oracle.com> wrote:
>>>> On 6/16/2016 5:40 PM, Lindenmaier, Goetz wrote:
>>>>
>>>> Hi,
>>>>
>>>>
>>>>
>>>> we have test machines without X server. On these many of the jdk
>>>>
>>>> jtreg tests fail with a headless exception.
>>>>
>>>> We grepped for this exception in the test output and identified
>>>>
>>>> about 450 tests.
>>>>
>>>>
>>>>
>>>> In these tests, we added with another script "@key headful".
>>>>
>>>>      What is a number of tests which passe in headless mode?
>>>>
>>>>     I would expect that an ordinary client test which use Frame and fails in
>>>> headless mode does not require a special key by default.
>>>>
>>> Hi Alexandr,
>>>
>>> I don't quite understand your concerns, but the purpose of this change
>>> is to make it possible to simply exclude all tests which require a
>>> "headful" environment from a jtreg run.
>>>
>>> There are AWT/Swing tests which can be run even without X server. For
>> example:
>>> java/awt/image/DrawImage/DrawImageCoordsTest.java
>>>
>>> Others, like for example:
>>>
>>> java/awt/image/DrawImage/EABlitTest.jtr
>>>
>>> will throw a Headless exception and fail:
>>>
>>> java.awt.HeadlessException:
>>> No X11 DISPLAY variable was set, but this program performed an
>>> operation which requires it.
>>>
>>> With Goetz's change we can simply exclude all the test which require a
>>> headful environment by specifying "-keywords:\!headful" to jtreg.
>>> After all, I think that's the purpose why the "headful" keyword has
>>> been introduced.
>>>
>>> If there's any other simple way of excluding all tests which require a
>>> headful environment, please let us now.
>>      For example, the test
>> jdk/test/javax/swing/AbstractButton/6711682/bug6711682.java when it is
>> run with -Djava.awt.headless=true option fails with exception
>> "java.awt.AWTException: headless environment".
>>
>>     The test is not listed in the proposed patch. Is it correct that this
>> test requires the "headful" environment and should be marked with the
>> "headful" keyword?
>>
>>     Thanks,
>>     Alexandr.
>>
>>> Regards,
>>> Volker
>>>
>>>>     Thanks,
>>>>     Alexandr.
>>>>
>>>>
>>>> So that the script generates better output, I adapted the
>>>>
>>>> formatting of some of the test descriptions.
>>>>
>>>> see also the text in the webrev, where I posted some incremental diffs
>>>>
>>>> of the changes I more or less edited by hand.  I hope this eases
>>>>
>>>> reviewing :)
>>>>
>>>>
>>>>
>>>> Last, I updated the Copyrights with the script by Coleen.
>>>>
>>>>
>>>>
>>>> Please review this change.
>>>>
>>>> http://cr.openjdk.java.net/~goetz/wr16/8159690-headful/webrev.01/
>>>>
>>>>
>>>>
>>>> Best regards,
>>>>
>>>>     Goetz.
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>


From volker.simonis at gmail.com  Fri Jun 17 13:54:51 2016
From: volker.simonis at gmail.com (Volker Simonis)
Date: Fri, 17 Jun 2016 15:54:51 +0200
Subject: <AWT Dev> <Swing Dev> RFR(L): 8159690: [TESTBUG] Mark headful
 tests with @key headful.
In-Reply-To: <32a8ced1-f5f5-d3e1-4834-254bcb106165@oracle.com>
References: <906afad52c284df2bc8a509e00007912@DEWDFE13DE09.global.corp.sap>
	<791258f1-0e1a-9b09-7021-816137e1146b@oracle.com>
	<CA+3eh13uvD2dpc0dk5kN-WgpdiLmjS=LtzA3=ZTJ3xcYV+=b0g@mail.gmail.com>
	<67f94b06-23fb-a280-f706-20808cab000e@oracle.com>
	<503e07b1c4c5469d8a0ed516cb5bb01c@DEWDFE13DE09.global.corp.sap>
	<32a8ced1-f5f5-d3e1-4834-254bcb106165@oracle.com>
Message-ID: <CA+3eh12qQtoto-rqSGdcDvXvM07z0AwjGVuNFmSo0-ajGZs-sQ@mail.gmail.com>

On Fri, Jun 17, 2016 at 3:40 PM, Alexandr Scherbatiy
<alexandr.scherbatiy at oracle.com> wrote:
> On 6/17/2016 4:17 PM, Lindenmaier, Goetz wrote:
>>
>> Hi Alexandr,
>>
>> yes, you are right, the test you mention is missing in this change.
>> There are others, too, and we still have lots of failures for other
>> reasons.
>>
>> We are currently working on getting all the tests green in
>> our test environment where we test linuxppc64, linuxppc64le
>> and aixppc64 (and, for reference, the Oracle platforms).
>> So I will address all the remaining issues at some point.
>>
>> If you basically agree on this change, I would appreciate if we
>> could push this one and I make a follow up change.  Handling
>> changes with this many files is a pain point.  But I can also
>> extend this change so that we get all of them at once.
>
>
>    As I see there are areas like jdk_beans or jdk_imageio which usually does
> not require headful environment and jdk_awt or jdk_swing which usually
> requires it. It seems that ordinary AWT/Swing tests require the "headful"
> keyword.
>
>   May be it is more appropriate to have "headful" keyword for areas like
> jdk_beans and "headless" keyword for areas like jdk_awt and jdk_swing? This
> will allow to mark only small part of tests with necessary keyword for each
> area.
>

While this approach sounds desirable, I'm not aware of functionality
in jtreg which allows marking all the tests in a test group (e.g.
jdk_awt) with a special default keyword which can be override in the
test itself.

After all, the author of a test should know best if his test requires
a headful environment or not. I think after we've gone trough the
initial pain of marking all headful test, the future development
should then be straightforward and simple.

>   In other way almost all AWT/Swing tests should be marked by "headful"
> keyword.
>
>   Thanks,
>   Alexandr.
>
>
>>
>> Best regards,
>>   Goetz.
>>
>>
>>
>>> -----Original Message-----
>>> From: Alexandr Scherbatiy [mailto:alexandr.scherbatiy at oracle.com]
>>> Sent: Freitag, 17. Juni 2016 14:53
>>> To: Volker Simonis <volker.simonis at gmail.com>
>>> Cc: Lindenmaier, Goetz <goetz.lindenmaier at sap.com>; swing-
>>> dev at openjdk.java.net; awt-dev at openjdk.java.net
>>> Subject: Re: <Swing Dev> <AWT Dev> RFR(L): 8159690: [TESTBUG] Mark
>>> headful tests with @key headful.
>>>
>>> On 6/17/2016 11:36 AM, Volker Simonis wrote:
>>>>
>>>> On Thu, Jun 16, 2016 at 5:55 PM, Alexandr Scherbatiy
>>>> <alexandr.scherbatiy at oracle.com> wrote:
>>>>>
>>>>> On 6/16/2016 5:40 PM, Lindenmaier, Goetz wrote:
>>>>>
>>>>> Hi,
>>>>>
>>>>>
>>>>>
>>>>> we have test machines without X server. On these many of the jdk
>>>>>
>>>>> jtreg tests fail with a headless exception.
>>>>>
>>>>> We grepped for this exception in the test output and identified
>>>>>
>>>>> about 450 tests.
>>>>>
>>>>>
>>>>>
>>>>> In these tests, we added with another script "@key headful".
>>>>>
>>>>>      What is a number of tests which passe in headless mode?
>>>>>
>>>>>     I would expect that an ordinary client test which use Frame and
>>>>> fails in
>>>>> headless mode does not require a special key by default.
>>>>>
>>>> Hi Alexandr,
>>>>
>>>> I don't quite understand your concerns, but the purpose of this change
>>>> is to make it possible to simply exclude all tests which require a
>>>> "headful" environment from a jtreg run.
>>>>
>>>> There are AWT/Swing tests which can be run even without X server. For
>>>
>>> example:
>>>>
>>>> java/awt/image/DrawImage/DrawImageCoordsTest.java
>>>>
>>>> Others, like for example:
>>>>
>>>> java/awt/image/DrawImage/EABlitTest.jtr
>>>>
>>>> will throw a Headless exception and fail:
>>>>
>>>> java.awt.HeadlessException:
>>>> No X11 DISPLAY variable was set, but this program performed an
>>>> operation which requires it.
>>>>
>>>> With Goetz's change we can simply exclude all the test which require a
>>>> headful environment by specifying "-keywords:\!headful" to jtreg.
>>>> After all, I think that's the purpose why the "headful" keyword has
>>>> been introduced.
>>>>
>>>> If there's any other simple way of excluding all tests which require a
>>>> headful environment, please let us now.
>>>
>>>      For example, the test
>>> jdk/test/javax/swing/AbstractButton/6711682/bug6711682.java when it is
>>> run with -Djava.awt.headless=true option fails with exception
>>> "java.awt.AWTException: headless environment".
>>>
>>>     The test is not listed in the proposed patch. Is it correct that this
>>> test requires the "headful" environment and should be marked with the
>>> "headful" keyword?
>>>
>>>     Thanks,
>>>     Alexandr.
>>>
>>>> Regards,
>>>> Volker
>>>>
>>>>>     Thanks,
>>>>>     Alexandr.
>>>>>
>>>>>
>>>>> So that the script generates better output, I adapted the
>>>>>
>>>>> formatting of some of the test descriptions.
>>>>>
>>>>> see also the text in the webrev, where I posted some incremental diffs
>>>>>
>>>>> of the changes I more or less edited by hand.  I hope this eases
>>>>>
>>>>> reviewing :)
>>>>>
>>>>>
>>>>>
>>>>> Last, I updated the Copyrights with the script by Coleen.
>>>>>
>>>>>
>>>>>
>>>>> Please review this change.
>>>>>
>>>>> http://cr.openjdk.java.net/~goetz/wr16/8159690-headful/webrev.01/
>>>>>
>>>>>
>>>>>
>>>>> Best regards,
>>>>>
>>>>>     Goetz.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>

From alexandr.scherbatiy at oracle.com  Fri Jun 17 14:03:37 2016
From: alexandr.scherbatiy at oracle.com (Alexandr Scherbatiy)
Date: Fri, 17 Jun 2016 17:03:37 +0300
Subject: <AWT Dev> <Swing Dev> RFR(L): 8159690: [TESTBUG] Mark headful
 tests with @key headful.
In-Reply-To: <CA+3eh12qQtoto-rqSGdcDvXvM07z0AwjGVuNFmSo0-ajGZs-sQ@mail.gmail.com>
References: <906afad52c284df2bc8a509e00007912@DEWDFE13DE09.global.corp.sap>
	<791258f1-0e1a-9b09-7021-816137e1146b@oracle.com>
	<CA+3eh13uvD2dpc0dk5kN-WgpdiLmjS=LtzA3=ZTJ3xcYV+=b0g@mail.gmail.com>
	<67f94b06-23fb-a280-f706-20808cab000e@oracle.com>
	<503e07b1c4c5469d8a0ed516cb5bb01c@DEWDFE13DE09.global.corp.sap>
	<32a8ced1-f5f5-d3e1-4834-254bcb106165@oracle.com>
	<CA+3eh12qQtoto-rqSGdcDvXvM07z0AwjGVuNFmSo0-ajGZs-sQ@mail.gmail.com>
Message-ID: <726f6bd0-6463-0515-9a81-328785694b5d@oracle.com>


The change looks good to me.

Thanks,
Alexandr.

On 6/17/2016 4:54 PM, Volker Simonis wrote:
> On Fri, Jun 17, 2016 at 3:40 PM, Alexandr Scherbatiy
> <alexandr.scherbatiy at oracle.com> wrote:
>> On 6/17/2016 4:17 PM, Lindenmaier, Goetz wrote:
>>> Hi Alexandr,
>>>
>>> yes, you are right, the test you mention is missing in this change.
>>> There are others, too, and we still have lots of failures for other
>>> reasons.
>>>
>>> We are currently working on getting all the tests green in
>>> our test environment where we test linuxppc64, linuxppc64le
>>> and aixppc64 (and, for reference, the Oracle platforms).
>>> So I will address all the remaining issues at some point.
>>>
>>> If you basically agree on this change, I would appreciate if we
>>> could push this one and I make a follow up change.  Handling
>>> changes with this many files is a pain point.  But I can also
>>> extend this change so that we get all of them at once.
>>
>>     As I see there are areas like jdk_beans or jdk_imageio which usually does
>> not require headful environment and jdk_awt or jdk_swing which usually
>> requires it. It seems that ordinary AWT/Swing tests require the "headful"
>> keyword.
>>
>>    May be it is more appropriate to have "headful" keyword for areas like
>> jdk_beans and "headless" keyword for areas like jdk_awt and jdk_swing? This
>> will allow to mark only small part of tests with necessary keyword for each
>> area.
>>
> While this approach sounds desirable, I'm not aware of functionality
> in jtreg which allows marking all the tests in a test group (e.g.
> jdk_awt) with a special default keyword which can be override in the
> test itself.
>
> After all, the author of a test should know best if his test requires
> a headful environment or not. I think after we've gone trough the
> initial pain of marking all headful test, the future development
> should then be straightforward and simple.
>
>>    In other way almost all AWT/Swing tests should be marked by "headful"
>> keyword.
>>
>>    Thanks,
>>    Alexandr.
>>
>>
>>> Best regards,
>>>    Goetz.
>>>
>>>
>>>
>>>> -----Original Message-----
>>>> From: Alexandr Scherbatiy [mailto:alexandr.scherbatiy at oracle.com]
>>>> Sent: Freitag, 17. Juni 2016 14:53
>>>> To: Volker Simonis <volker.simonis at gmail.com>
>>>> Cc: Lindenmaier, Goetz <goetz.lindenmaier at sap.com>; swing-
>>>> dev at openjdk.java.net; awt-dev at openjdk.java.net
>>>> Subject: Re: <Swing Dev> <AWT Dev> RFR(L): 8159690: [TESTBUG] Mark
>>>> headful tests with @key headful.
>>>>
>>>> On 6/17/2016 11:36 AM, Volker Simonis wrote:
>>>>> On Thu, Jun 16, 2016 at 5:55 PM, Alexandr Scherbatiy
>>>>> <alexandr.scherbatiy at oracle.com> wrote:
>>>>>> On 6/16/2016 5:40 PM, Lindenmaier, Goetz wrote:
>>>>>>
>>>>>> Hi,
>>>>>>
>>>>>>
>>>>>>
>>>>>> we have test machines without X server. On these many of the jdk
>>>>>>
>>>>>> jtreg tests fail with a headless exception.
>>>>>>
>>>>>> We grepped for this exception in the test output and identified
>>>>>>
>>>>>> about 450 tests.
>>>>>>
>>>>>>
>>>>>>
>>>>>> In these tests, we added with another script "@key headful".
>>>>>>
>>>>>>       What is a number of tests which passe in headless mode?
>>>>>>
>>>>>>      I would expect that an ordinary client test which use Frame and
>>>>>> fails in
>>>>>> headless mode does not require a special key by default.
>>>>>>
>>>>> Hi Alexandr,
>>>>>
>>>>> I don't quite understand your concerns, but the purpose of this change
>>>>> is to make it possible to simply exclude all tests which require a
>>>>> "headful" environment from a jtreg run.
>>>>>
>>>>> There are AWT/Swing tests which can be run even without X server. For
>>>> example:
>>>>> java/awt/image/DrawImage/DrawImageCoordsTest.java
>>>>>
>>>>> Others, like for example:
>>>>>
>>>>> java/awt/image/DrawImage/EABlitTest.jtr
>>>>>
>>>>> will throw a Headless exception and fail:
>>>>>
>>>>> java.awt.HeadlessException:
>>>>> No X11 DISPLAY variable was set, but this program performed an
>>>>> operation which requires it.
>>>>>
>>>>> With Goetz's change we can simply exclude all the test which require a
>>>>> headful environment by specifying "-keywords:\!headful" to jtreg.
>>>>> After all, I think that's the purpose why the "headful" keyword has
>>>>> been introduced.
>>>>>
>>>>> If there's any other simple way of excluding all tests which require a
>>>>> headful environment, please let us now.
>>>>       For example, the test
>>>> jdk/test/javax/swing/AbstractButton/6711682/bug6711682.java when it is
>>>> run with -Djava.awt.headless=true option fails with exception
>>>> "java.awt.AWTException: headless environment".
>>>>
>>>>      The test is not listed in the proposed patch. Is it correct that this
>>>> test requires the "headful" environment and should be marked with the
>>>> "headful" keyword?
>>>>
>>>>      Thanks,
>>>>      Alexandr.
>>>>
>>>>> Regards,
>>>>> Volker
>>>>>
>>>>>>      Thanks,
>>>>>>      Alexandr.
>>>>>>
>>>>>>
>>>>>> So that the script generates better output, I adapted the
>>>>>>
>>>>>> formatting of some of the test descriptions.
>>>>>>
>>>>>> see also the text in the webrev, where I posted some incremental diffs
>>>>>>
>>>>>> of the changes I more or less edited by hand.  I hope this eases
>>>>>>
>>>>>> reviewing :)
>>>>>>
>>>>>>
>>>>>>
>>>>>> Last, I updated the Copyrights with the script by Coleen.
>>>>>>
>>>>>>
>>>>>>
>>>>>> Please review this change.
>>>>>>
>>>>>> http://cr.openjdk.java.net/~goetz/wr16/8159690-headful/webrev.01/
>>>>>>
>>>>>>
>>>>>>
>>>>>> Best regards,
>>>>>>
>>>>>>      Goetz.
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>


From goetz.lindenmaier at sap.com  Fri Jun 17 14:17:37 2016
From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz)
Date: Fri, 17 Jun 2016 14:17:37 +0000
Subject: <AWT Dev> <Swing Dev> RFR(L): 8159690: [TESTBUG] Mark headful
 tests with @key headful.
In-Reply-To: <726f6bd0-6463-0515-9a81-328785694b5d@oracle.com>
References: <906afad52c284df2bc8a509e00007912@DEWDFE13DE09.global.corp.sap>
	<791258f1-0e1a-9b09-7021-816137e1146b@oracle.com>
	<CA+3eh13uvD2dpc0dk5kN-WgpdiLmjS=LtzA3=ZTJ3xcYV+=b0g@mail.gmail.com>
	<67f94b06-23fb-a280-f706-20808cab000e@oracle.com>
	<503e07b1c4c5469d8a0ed516cb5bb01c@DEWDFE13DE09.global.corp.sap>
	<32a8ced1-f5f5-d3e1-4834-254bcb106165@oracle.com>
	<CA+3eh12qQtoto-rqSGdcDvXvM07z0AwjGVuNFmSo0-ajGZs-sQ@mail.gmail.com>
	<726f6bd0-6463-0515-9a81-328785694b5d@oracle.com>
Message-ID: <0682a62cf09045b5a394dbcf70cd2ebc@DEWDFE13DE09.global.corp.sap>

Hi Alexandr, 

Thanks for reviewing!

Best regards,
  Goetz.

> -----Original Message-----
> From: Alexandr Scherbatiy [mailto:alexandr.scherbatiy at oracle.com]
> Sent: Freitag, 17. Juni 2016 16:04
> To: Volker Simonis <volker.simonis at gmail.com>
> Cc: Lindenmaier, Goetz <goetz.lindenmaier at sap.com>; swing-
> dev at openjdk.java.net; awt-dev at openjdk.java.net
> Subject: Re: <Swing Dev> <AWT Dev> RFR(L): 8159690: [TESTBUG] Mark
> headful tests with @key headful.
> 
> 
> The change looks good to me.
> 
> Thanks,
> Alexandr.
> 
> On 6/17/2016 4:54 PM, Volker Simonis wrote:
> > On Fri, Jun 17, 2016 at 3:40 PM, Alexandr Scherbatiy
> > <alexandr.scherbatiy at oracle.com> wrote:
> >> On 6/17/2016 4:17 PM, Lindenmaier, Goetz wrote:
> >>> Hi Alexandr,
> >>>
> >>> yes, you are right, the test you mention is missing in this change.
> >>> There are others, too, and we still have lots of failures for other
> >>> reasons.
> >>>
> >>> We are currently working on getting all the tests green in
> >>> our test environment where we test linuxppc64, linuxppc64le
> >>> and aixppc64 (and, for reference, the Oracle platforms).
> >>> So I will address all the remaining issues at some point.
> >>>
> >>> If you basically agree on this change, I would appreciate if we
> >>> could push this one and I make a follow up change.  Handling
> >>> changes with this many files is a pain point.  But I can also
> >>> extend this change so that we get all of them at once.
> >>
> >>     As I see there are areas like jdk_beans or jdk_imageio which usually
> does
> >> not require headful environment and jdk_awt or jdk_swing which usually
> >> requires it. It seems that ordinary AWT/Swing tests require the "headful"
> >> keyword.
> >>
> >>    May be it is more appropriate to have "headful" keyword for areas like
> >> jdk_beans and "headless" keyword for areas like jdk_awt and jdk_swing?
> This
> >> will allow to mark only small part of tests with necessary keyword for each
> >> area.
> >>
> > While this approach sounds desirable, I'm not aware of functionality
> > in jtreg which allows marking all the tests in a test group (e.g.
> > jdk_awt) with a special default keyword which can be override in the
> > test itself.
> >
> > After all, the author of a test should know best if his test requires
> > a headful environment or not. I think after we've gone trough the
> > initial pain of marking all headful test, the future development
> > should then be straightforward and simple.
> >
> >>    In other way almost all AWT/Swing tests should be marked by "headful"
> >> keyword.
> >>
> >>    Thanks,
> >>    Alexandr.
> >>
> >>
> >>> Best regards,
> >>>    Goetz.
> >>>
> >>>
> >>>
> >>>> -----Original Message-----
> >>>> From: Alexandr Scherbatiy [mailto:alexandr.scherbatiy at oracle.com]
> >>>> Sent: Freitag, 17. Juni 2016 14:53
> >>>> To: Volker Simonis <volker.simonis at gmail.com>
> >>>> Cc: Lindenmaier, Goetz <goetz.lindenmaier at sap.com>; swing-
> >>>> dev at openjdk.java.net; awt-dev at openjdk.java.net
> >>>> Subject: Re: <Swing Dev> <AWT Dev> RFR(L): 8159690: [TESTBUG]
> Mark
> >>>> headful tests with @key headful.
> >>>>
> >>>> On 6/17/2016 11:36 AM, Volker Simonis wrote:
> >>>>> On Thu, Jun 16, 2016 at 5:55 PM, Alexandr Scherbatiy
> >>>>> <alexandr.scherbatiy at oracle.com> wrote:
> >>>>>> On 6/16/2016 5:40 PM, Lindenmaier, Goetz wrote:
> >>>>>>
> >>>>>> Hi,
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> we have test machines without X server. On these many of the jdk
> >>>>>>
> >>>>>> jtreg tests fail with a headless exception.
> >>>>>>
> >>>>>> We grepped for this exception in the test output and identified
> >>>>>>
> >>>>>> about 450 tests.
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> In these tests, we added with another script "@key headful".
> >>>>>>
> >>>>>>       What is a number of tests which passe in headless mode?
> >>>>>>
> >>>>>>      I would expect that an ordinary client test which use Frame and
> >>>>>> fails in
> >>>>>> headless mode does not require a special key by default.
> >>>>>>
> >>>>> Hi Alexandr,
> >>>>>
> >>>>> I don't quite understand your concerns, but the purpose of this
> change
> >>>>> is to make it possible to simply exclude all tests which require a
> >>>>> "headful" environment from a jtreg run.
> >>>>>
> >>>>> There are AWT/Swing tests which can be run even without X server.
> For
> >>>> example:
> >>>>> java/awt/image/DrawImage/DrawImageCoordsTest.java
> >>>>>
> >>>>> Others, like for example:
> >>>>>
> >>>>> java/awt/image/DrawImage/EABlitTest.jtr
> >>>>>
> >>>>> will throw a Headless exception and fail:
> >>>>>
> >>>>> java.awt.HeadlessException:
> >>>>> No X11 DISPLAY variable was set, but this program performed an
> >>>>> operation which requires it.
> >>>>>
> >>>>> With Goetz's change we can simply exclude all the test which require
> a
> >>>>> headful environment by specifying "-keywords:\!headful" to jtreg.
> >>>>> After all, I think that's the purpose why the "headful" keyword has
> >>>>> been introduced.
> >>>>>
> >>>>> If there's any other simple way of excluding all tests which require a
> >>>>> headful environment, please let us now.
> >>>>       For example, the test
> >>>> jdk/test/javax/swing/AbstractButton/6711682/bug6711682.java when
> it is
> >>>> run with -Djava.awt.headless=true option fails with exception
> >>>> "java.awt.AWTException: headless environment".
> >>>>
> >>>>      The test is not listed in the proposed patch. Is it correct that this
> >>>> test requires the "headful" environment and should be marked with
> the
> >>>> "headful" keyword?
> >>>>
> >>>>      Thanks,
> >>>>      Alexandr.
> >>>>
> >>>>> Regards,
> >>>>> Volker
> >>>>>
> >>>>>>      Thanks,
> >>>>>>      Alexandr.
> >>>>>>
> >>>>>>
> >>>>>> So that the script generates better output, I adapted the
> >>>>>>
> >>>>>> formatting of some of the test descriptions.
> >>>>>>
> >>>>>> see also the text in the webrev, where I posted some incremental
> diffs
> >>>>>>
> >>>>>> of the changes I more or less edited by hand.  I hope this eases
> >>>>>>
> >>>>>> reviewing :)
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> Last, I updated the Copyrights with the script by Coleen.
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> Please review this change.
> >>>>>>
> >>>>>> http://cr.openjdk.java.net/~goetz/wr16/8159690-
> headful/webrev.01/
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> Best regards,
> >>>>>>
> >>>>>>      Goetz.
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>


From Sergey.Bylokhov at oracle.com  Fri Jun 17 14:20:53 2016
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Fri, 17 Jun 2016 17:20:53 +0300
Subject: <AWT Dev> <Swing Dev> RFR(L): 8159690: [TESTBUG] Mark headful
 tests with @key headful.
In-Reply-To: <0682a62cf09045b5a394dbcf70cd2ebc@DEWDFE13DE09.global.corp.sap>
References: <906afad52c284df2bc8a509e00007912@DEWDFE13DE09.global.corp.sap>
	<791258f1-0e1a-9b09-7021-816137e1146b@oracle.com>
	<CA+3eh13uvD2dpc0dk5kN-WgpdiLmjS=LtzA3=ZTJ3xcYV+=b0g@mail.gmail.com>
	<67f94b06-23fb-a280-f706-20808cab000e@oracle.com>
	<503e07b1c4c5469d8a0ed516cb5bb01c@DEWDFE13DE09.global.corp.sap>
	<32a8ced1-f5f5-d3e1-4834-254bcb106165@oracle.com>
	<CA+3eh12qQtoto-rqSGdcDvXvM07z0AwjGVuNFmSo0-ajGZs-sQ@mail.gmail.com>
	<726f6bd0-6463-0515-9a81-328785694b5d@oracle.com>
	<0682a62cf09045b5a394dbcf70cd2ebc@DEWDFE13DE09.global.corp.sap>
Message-ID: <4e4dca16-76e4-d9fc-12f2-fad347f9e13a@oracle.com>

I guess that 2d team should review it as well (cc)

On 17.06.16 17:17, Lindenmaier, Goetz wrote:
> Hi Alexandr,
>
> Thanks for reviewing!
>
> Best regards,
>   Goetz.
>
>> -----Original Message-----
>> From: Alexandr Scherbatiy [mailto:alexandr.scherbatiy at oracle.com]
>> Sent: Freitag, 17. Juni 2016 16:04
>> To: Volker Simonis <volker.simonis at gmail.com>
>> Cc: Lindenmaier, Goetz <goetz.lindenmaier at sap.com>; swing-
>> dev at openjdk.java.net; awt-dev at openjdk.java.net
>> Subject: Re: <Swing Dev> <AWT Dev> RFR(L): 8159690: [TESTBUG] Mark
>> headful tests with @key headful.
>>
>>
>> The change looks good to me.
>>
>> Thanks,
>> Alexandr.
>>
>> On 6/17/2016 4:54 PM, Volker Simonis wrote:
>>> On Fri, Jun 17, 2016 at 3:40 PM, Alexandr Scherbatiy
>>> <alexandr.scherbatiy at oracle.com> wrote:
>>>> On 6/17/2016 4:17 PM, Lindenmaier, Goetz wrote:
>>>>> Hi Alexandr,
>>>>>
>>>>> yes, you are right, the test you mention is missing in this change.
>>>>> There are others, too, and we still have lots of failures for other
>>>>> reasons.
>>>>>
>>>>> We are currently working on getting all the tests green in
>>>>> our test environment where we test linuxppc64, linuxppc64le
>>>>> and aixppc64 (and, for reference, the Oracle platforms).
>>>>> So I will address all the remaining issues at some point.
>>>>>
>>>>> If you basically agree on this change, I would appreciate if we
>>>>> could push this one and I make a follow up change.  Handling
>>>>> changes with this many files is a pain point.  But I can also
>>>>> extend this change so that we get all of them at once.
>>>>
>>>>     As I see there are areas like jdk_beans or jdk_imageio which usually
>> does
>>>> not require headful environment and jdk_awt or jdk_swing which usually
>>>> requires it. It seems that ordinary AWT/Swing tests require the "headful"
>>>> keyword.
>>>>
>>>>    May be it is more appropriate to have "headful" keyword for areas like
>>>> jdk_beans and "headless" keyword for areas like jdk_awt and jdk_swing?
>> This
>>>> will allow to mark only small part of tests with necessary keyword for each
>>>> area.
>>>>
>>> While this approach sounds desirable, I'm not aware of functionality
>>> in jtreg which allows marking all the tests in a test group (e.g.
>>> jdk_awt) with a special default keyword which can be override in the
>>> test itself.
>>>
>>> After all, the author of a test should know best if his test requires
>>> a headful environment or not. I think after we've gone trough the
>>> initial pain of marking all headful test, the future development
>>> should then be straightforward and simple.
>>>
>>>>    In other way almost all AWT/Swing tests should be marked by "headful"
>>>> keyword.
>>>>
>>>>    Thanks,
>>>>    Alexandr.
>>>>
>>>>
>>>>> Best regards,
>>>>>    Goetz.
>>>>>
>>>>>
>>>>>
>>>>>> -----Original Message-----
>>>>>> From: Alexandr Scherbatiy [mailto:alexandr.scherbatiy at oracle.com]
>>>>>> Sent: Freitag, 17. Juni 2016 14:53
>>>>>> To: Volker Simonis <volker.simonis at gmail.com>
>>>>>> Cc: Lindenmaier, Goetz <goetz.lindenmaier at sap.com>; swing-
>>>>>> dev at openjdk.java.net; awt-dev at openjdk.java.net
>>>>>> Subject: Re: <Swing Dev> <AWT Dev> RFR(L): 8159690: [TESTBUG]
>> Mark
>>>>>> headful tests with @key headful.
>>>>>>
>>>>>> On 6/17/2016 11:36 AM, Volker Simonis wrote:
>>>>>>> On Thu, Jun 16, 2016 at 5:55 PM, Alexandr Scherbatiy
>>>>>>> <alexandr.scherbatiy at oracle.com> wrote:
>>>>>>>> On 6/16/2016 5:40 PM, Lindenmaier, Goetz wrote:
>>>>>>>>
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> we have test machines without X server. On these many of the jdk
>>>>>>>>
>>>>>>>> jtreg tests fail with a headless exception.
>>>>>>>>
>>>>>>>> We grepped for this exception in the test output and identified
>>>>>>>>
>>>>>>>> about 450 tests.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> In these tests, we added with another script "@key headful".
>>>>>>>>
>>>>>>>>       What is a number of tests which passe in headless mode?
>>>>>>>>
>>>>>>>>      I would expect that an ordinary client test which use Frame and
>>>>>>>> fails in
>>>>>>>> headless mode does not require a special key by default.
>>>>>>>>
>>>>>>> Hi Alexandr,
>>>>>>>
>>>>>>> I don't quite understand your concerns, but the purpose of this
>> change
>>>>>>> is to make it possible to simply exclude all tests which require a
>>>>>>> "headful" environment from a jtreg run.
>>>>>>>
>>>>>>> There are AWT/Swing tests which can be run even without X server.
>> For
>>>>>> example:
>>>>>>> java/awt/image/DrawImage/DrawImageCoordsTest.java
>>>>>>>
>>>>>>> Others, like for example:
>>>>>>>
>>>>>>> java/awt/image/DrawImage/EABlitTest.jtr
>>>>>>>
>>>>>>> will throw a Headless exception and fail:
>>>>>>>
>>>>>>> java.awt.HeadlessException:
>>>>>>> No X11 DISPLAY variable was set, but this program performed an
>>>>>>> operation which requires it.
>>>>>>>
>>>>>>> With Goetz's change we can simply exclude all the test which require
>> a
>>>>>>> headful environment by specifying "-keywords:\!headful" to jtreg.
>>>>>>> After all, I think that's the purpose why the "headful" keyword has
>>>>>>> been introduced.
>>>>>>>
>>>>>>> If there's any other simple way of excluding all tests which require a
>>>>>>> headful environment, please let us now.
>>>>>>       For example, the test
>>>>>> jdk/test/javax/swing/AbstractButton/6711682/bug6711682.java when
>> it is
>>>>>> run with -Djava.awt.headless=true option fails with exception
>>>>>> "java.awt.AWTException: headless environment".
>>>>>>
>>>>>>      The test is not listed in the proposed patch. Is it correct that this
>>>>>> test requires the "headful" environment and should be marked with
>> the
>>>>>> "headful" keyword?
>>>>>>
>>>>>>      Thanks,
>>>>>>      Alexandr.
>>>>>>
>>>>>>> Regards,
>>>>>>> Volker
>>>>>>>
>>>>>>>>      Thanks,
>>>>>>>>      Alexandr.
>>>>>>>>
>>>>>>>>
>>>>>>>> So that the script generates better output, I adapted the
>>>>>>>>
>>>>>>>> formatting of some of the test descriptions.
>>>>>>>>
>>>>>>>> see also the text in the webrev, where I posted some incremental
>> diffs
>>>>>>>>
>>>>>>>> of the changes I more or less edited by hand.  I hope this eases
>>>>>>>>
>>>>>>>> reviewing :)
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> Last, I updated the Copyrights with the script by Coleen.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> Please review this change.
>>>>>>>>
>>>>>>>> http://cr.openjdk.java.net/~goetz/wr16/8159690-
>> headful/webrev.01/
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> Best regards,
>>>>>>>>
>>>>>>>>      Goetz.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>


-- 
Best regards, Sergey.

From goetz.lindenmaier at sap.com  Fri Jun 17 14:23:36 2016
From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz)
Date: Fri, 17 Jun 2016 14:23:36 +0000
Subject: <AWT Dev> <Swing Dev> RFR(L): 8159690: [TESTBUG] Mark headful
 tests with @key headful.
In-Reply-To: <4e4dca16-76e4-d9fc-12f2-fad347f9e13a@oracle.com>
References: <906afad52c284df2bc8a509e00007912@DEWDFE13DE09.global.corp.sap>
	<791258f1-0e1a-9b09-7021-816137e1146b@oracle.com>
	<CA+3eh13uvD2dpc0dk5kN-WgpdiLmjS=LtzA3=ZTJ3xcYV+=b0g@mail.gmail.com>
	<67f94b06-23fb-a280-f706-20808cab000e@oracle.com>
	<503e07b1c4c5469d8a0ed516cb5bb01c@DEWDFE13DE09.global.corp.sap>
	<32a8ced1-f5f5-d3e1-4834-254bcb106165@oracle.com>
	<CA+3eh12qQtoto-rqSGdcDvXvM07z0AwjGVuNFmSo0-ajGZs-sQ@mail.gmail.com>
	<726f6bd0-6463-0515-9a81-328785694b5d@oracle.com>
	<0682a62cf09045b5a394dbcf70cd2ebc@DEWDFE13DE09.global.corp.sap>
	<4e4dca16-76e4-d9fc-12f2-fad347f9e13a@oracle.com>
Message-ID: <9cefe7d5e8c947a997d8dd4ac2286382@DEWDFE13DE09.global.corp.sap>

Hi Sergey,

Sorry, I pushed it just now!  If you (or anybody else) has any objections
I can revert this or do a follow-up to correct it.  Please let me know.

Best regards,
  Goetz.



> -----Original Message-----
> From: Sergey Bylokhov [mailto:Sergey.Bylokhov at oracle.com]
> Sent: Freitag, 17. Juni 2016 16:21
> To: Lindenmaier, Goetz <goetz.lindenmaier at sap.com>; Alexandr Scherbatiy
> <alexandr.scherbatiy at oracle.com>; Volker Simonis
> <volker.simonis at gmail.com>
> Cc: awt-dev at openjdk.java.net; swing-dev at openjdk.java.net; 2d-dev <2d-
> dev at openjdk.java.net>
> Subject: Re: <Swing Dev> <AWT Dev> RFR(L): 8159690: [TESTBUG] Mark
> headful tests with @key headful.
> 
> I guess that 2d team should review it as well (cc)
> 
> On 17.06.16 17:17, Lindenmaier, Goetz wrote:
> > Hi Alexandr,
> >
> > Thanks for reviewing!
> >
> > Best regards,
> >   Goetz.
> >
> >> -----Original Message-----
> >> From: Alexandr Scherbatiy [mailto:alexandr.scherbatiy at oracle.com]
> >> Sent: Freitag, 17. Juni 2016 16:04
> >> To: Volker Simonis <volker.simonis at gmail.com>
> >> Cc: Lindenmaier, Goetz <goetz.lindenmaier at sap.com>; swing-
> >> dev at openjdk.java.net; awt-dev at openjdk.java.net
> >> Subject: Re: <Swing Dev> <AWT Dev> RFR(L): 8159690: [TESTBUG] Mark
> >> headful tests with @key headful.
> >>
> >>
> >> The change looks good to me.
> >>
> >> Thanks,
> >> Alexandr.
> >>
> >> On 6/17/2016 4:54 PM, Volker Simonis wrote:
> >>> On Fri, Jun 17, 2016 at 3:40 PM, Alexandr Scherbatiy
> >>> <alexandr.scherbatiy at oracle.com> wrote:
> >>>> On 6/17/2016 4:17 PM, Lindenmaier, Goetz wrote:
> >>>>> Hi Alexandr,
> >>>>>
> >>>>> yes, you are right, the test you mention is missing in this change.
> >>>>> There are others, too, and we still have lots of failures for other
> >>>>> reasons.
> >>>>>
> >>>>> We are currently working on getting all the tests green in
> >>>>> our test environment where we test linuxppc64, linuxppc64le
> >>>>> and aixppc64 (and, for reference, the Oracle platforms).
> >>>>> So I will address all the remaining issues at some point.
> >>>>>
> >>>>> If you basically agree on this change, I would appreciate if we
> >>>>> could push this one and I make a follow up change.  Handling
> >>>>> changes with this many files is a pain point.  But I can also
> >>>>> extend this change so that we get all of them at once.
> >>>>
> >>>>     As I see there are areas like jdk_beans or jdk_imageio which usually
> >> does
> >>>> not require headful environment and jdk_awt or jdk_swing which
> usually
> >>>> requires it. It seems that ordinary AWT/Swing tests require the
> "headful"
> >>>> keyword.
> >>>>
> >>>>    May be it is more appropriate to have "headful" keyword for areas
> like
> >>>> jdk_beans and "headless" keyword for areas like jdk_awt and
> jdk_swing?
> >> This
> >>>> will allow to mark only small part of tests with necessary keyword for
> each
> >>>> area.
> >>>>
> >>> While this approach sounds desirable, I'm not aware of functionality
> >>> in jtreg which allows marking all the tests in a test group (e.g.
> >>> jdk_awt) with a special default keyword which can be override in the
> >>> test itself.
> >>>
> >>> After all, the author of a test should know best if his test requires
> >>> a headful environment or not. I think after we've gone trough the
> >>> initial pain of marking all headful test, the future development
> >>> should then be straightforward and simple.
> >>>
> >>>>    In other way almost all AWT/Swing tests should be marked by
> "headful"
> >>>> keyword.
> >>>>
> >>>>    Thanks,
> >>>>    Alexandr.
> >>>>
> >>>>
> >>>>> Best regards,
> >>>>>    Goetz.
> >>>>>
> >>>>>
> >>>>>
> >>>>>> -----Original Message-----
> >>>>>> From: Alexandr Scherbatiy [mailto:alexandr.scherbatiy at oracle.com]
> >>>>>> Sent: Freitag, 17. Juni 2016 14:53
> >>>>>> To: Volker Simonis <volker.simonis at gmail.com>
> >>>>>> Cc: Lindenmaier, Goetz <goetz.lindenmaier at sap.com>; swing-
> >>>>>> dev at openjdk.java.net; awt-dev at openjdk.java.net
> >>>>>> Subject: Re: <Swing Dev> <AWT Dev> RFR(L): 8159690: [TESTBUG]
> >> Mark
> >>>>>> headful tests with @key headful.
> >>>>>>
> >>>>>> On 6/17/2016 11:36 AM, Volker Simonis wrote:
> >>>>>>> On Thu, Jun 16, 2016 at 5:55 PM, Alexandr Scherbatiy
> >>>>>>> <alexandr.scherbatiy at oracle.com> wrote:
> >>>>>>>> On 6/16/2016 5:40 PM, Lindenmaier, Goetz wrote:
> >>>>>>>>
> >>>>>>>> Hi,
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> we have test machines without X server. On these many of the
> jdk
> >>>>>>>>
> >>>>>>>> jtreg tests fail with a headless exception.
> >>>>>>>>
> >>>>>>>> We grepped for this exception in the test output and identified
> >>>>>>>>
> >>>>>>>> about 450 tests.
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> In these tests, we added with another script "@key headful".
> >>>>>>>>
> >>>>>>>>       What is a number of tests which passe in headless mode?
> >>>>>>>>
> >>>>>>>>      I would expect that an ordinary client test which use Frame and
> >>>>>>>> fails in
> >>>>>>>> headless mode does not require a special key by default.
> >>>>>>>>
> >>>>>>> Hi Alexandr,
> >>>>>>>
> >>>>>>> I don't quite understand your concerns, but the purpose of this
> >> change
> >>>>>>> is to make it possible to simply exclude all tests which require a
> >>>>>>> "headful" environment from a jtreg run.
> >>>>>>>
> >>>>>>> There are AWT/Swing tests which can be run even without X
> server.
> >> For
> >>>>>> example:
> >>>>>>> java/awt/image/DrawImage/DrawImageCoordsTest.java
> >>>>>>>
> >>>>>>> Others, like for example:
> >>>>>>>
> >>>>>>> java/awt/image/DrawImage/EABlitTest.jtr
> >>>>>>>
> >>>>>>> will throw a Headless exception and fail:
> >>>>>>>
> >>>>>>> java.awt.HeadlessException:
> >>>>>>> No X11 DISPLAY variable was set, but this program performed an
> >>>>>>> operation which requires it.
> >>>>>>>
> >>>>>>> With Goetz's change we can simply exclude all the test which
> require
> >> a
> >>>>>>> headful environment by specifying "-keywords:\!headful" to jtreg.
> >>>>>>> After all, I think that's the purpose why the "headful" keyword has
> >>>>>>> been introduced.
> >>>>>>>
> >>>>>>> If there's any other simple way of excluding all tests which require a
> >>>>>>> headful environment, please let us now.
> >>>>>>       For example, the test
> >>>>>> jdk/test/javax/swing/AbstractButton/6711682/bug6711682.java
> when
> >> it is
> >>>>>> run with -Djava.awt.headless=true option fails with exception
> >>>>>> "java.awt.AWTException: headless environment".
> >>>>>>
> >>>>>>      The test is not listed in the proposed patch. Is it correct that this
> >>>>>> test requires the "headful" environment and should be marked with
> >> the
> >>>>>> "headful" keyword?
> >>>>>>
> >>>>>>      Thanks,
> >>>>>>      Alexandr.
> >>>>>>
> >>>>>>> Regards,
> >>>>>>> Volker
> >>>>>>>
> >>>>>>>>      Thanks,
> >>>>>>>>      Alexandr.
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> So that the script generates better output, I adapted the
> >>>>>>>>
> >>>>>>>> formatting of some of the test descriptions.
> >>>>>>>>
> >>>>>>>> see also the text in the webrev, where I posted some incremental
> >> diffs
> >>>>>>>>
> >>>>>>>> of the changes I more or less edited by hand.  I hope this eases
> >>>>>>>>
> >>>>>>>> reviewing :)
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> Last, I updated the Copyrights with the script by Coleen.
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> Please review this change.
> >>>>>>>>
> >>>>>>>> http://cr.openjdk.java.net/~goetz/wr16/8159690-
> >> headful/webrev.01/
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> Best regards,
> >>>>>>>>
> >>>>>>>>      Goetz.
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >
> 
> 
> --
> Best regards, Sergey.

From manajit.halder at oracle.com  Sun Jun 19 20:25:34 2016
From: manajit.halder at oracle.com (Manajit Halder)
Date: Mon, 20 Jun 2016 01:55:34 +0530
Subject: <AWT Dev> <AWT dev>[9] Review request for JDK-8156460 [macosx] Test
	case javax/swing/JPopupMenu/6827786/bug6827786.java fails
Message-ID: <3412A11C-7C9B-4661-8E24-410F31403C86@oracle.com>

Hi All,

Please review the regression fix for issue JDK-8156460 <https://bugs.openjdk.java.net/browse/JDK-8156460> which fixes below mentioned test cases.
http://cr.openjdk.java.net/~mhalder/8156460/webrev.00/ <http://cr.openjdk.java.net/~mhalder/8156460/webrev.00/>

This fix resolves the following 3 JCK failures and 7 test failures:

JCK tests:
https://bugs.openjdk.java.net/browse/JDK-8158621 <https://bugs.openjdk.java.net/browse/JDK-8158621>
https://bugs.openjdk.java.net/browse/JDK-8158485 <https://bugs.openjdk.java.net/browse/JDK-8158485>
https://bugs.openjdk.java.net/browse/JDK-8158501 <https://bugs.openjdk.java.net/browse/JDK-8158501>

Jtreg tests:
https://bugs.openjdk.java.net/browse/JDK-8158389 <https://bugs.openjdk.java.net/browse/JDK-8158389>
https://bugs.openjdk.java.net/browse/JDK-8158526 <https://bugs.openjdk.java.net/browse/JDK-8158526>
https://bugs.openjdk.java.net/browse/JDK-8158496 <https://bugs.openjdk.java.net/browse/JDK-8158496>
https://bugs.openjdk.java.net/browse/JDK-8158362 <https://bugs.openjdk.java.net/browse/JDK-8158362>
https://bugs.openjdk.java.net/browse/JDK-8158512 <https://bugs.openjdk.java.net/browse/JDK-8158512>
https://bugs.openjdk.java.net/browse/JDK-8156460 <https://bugs.openjdk.java.net/browse/JDK-8156460>
https://bugs.openjdk.java.net/browse/JDK-8158377 <https://bugs.openjdk.java.net/browse/JDK-8158377>

Reason of failure:
	The modifier value calculation was wrong.

Note that with this fix the test /java/awt/keyboard/AllKeyCode/AllKeyCode.java will fail due to the reason that pressing number (0 to 9) after pressing arrow keys( up, down, left and right) will generate corresponding Numpad keys code for number keys (0 to 9). Whereas if the arrow key are pressed after number keys are pressed then there is no problem. An issue will be created for this issue once this fix is accepted.

Thanks,
Manajit
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20160620/f2eb37c6/attachment.html>

From semyon.sadetsky at oracle.com  Mon Jun 20 08:29:41 2016
From: semyon.sadetsky at oracle.com (Semyon Sadetsky)
Date: Mon, 20 Jun 2016 11:29:41 +0300
Subject: <AWT Dev> [9] Review request for 8154816: Caps Lock doesn't
 work as expected when using Pinyin Simplified input method
In-Reply-To: <5763D4B0.4030209@oracle.com>
References: <5763D4B0.4030209@oracle.com>
Message-ID: <5ae1b2a4-dc24-9f2e-c3c7-cd4dc61646c4@oracle.com>

Hi Dmitry,

The fix looks good.

I am only not sure that an applet based test is suitable since applets 
are deprecated.

--Semyon


On 6/17/2016 1:45 PM, dmitry markov wrote:
> Hello,
>
> Could you review a fix for jdk9, please?
>
>     bug: https://bugs.openjdk.java.net/browse/JDK-8154816
>     webrev: http://cr.openjdk.java.net/~dmarkov/8154816/webrev.00/
>
> Problem description:
> When Pinyin Simplified input method is selected and 'Caps Lock' is on, 
> input is switched to latin letters, but letters are entered in uppercase.
>
> Fix:
> It is necessary to ignore 'Caps Lock' modifier in 
> CPlatformResponder.handleKeyEvent() method, if Pinyin Simplified input 
> method is selected and 'Caps Lock' is on.
>
> Thanks,
> Dmitry


From anton.tarasov at jetbrains.com  Mon Jun 20 09:57:29 2016
From: anton.tarasov at jetbrains.com (Anton Tarasov)
Date: Mon, 20 Jun 2016 12:57:29 +0300
Subject: <AWT Dev> CFV: New AWT Group Lead: Sergey Bylokhov
In-Reply-To: <bf5be81e-870c-5288-8ca2-e511d5d236e0@oracle.com>
References: <bf5be81e-870c-5288-8ca2-e511d5d236e0@oracle.com>
Message-ID: <0751E1DD-49F6-49F9-AA0D-E2713443B6E3@jetbrains.com>

Vote: YES



> On 10 Jun 2016, at 18:39, Artem Ananiev <artem.ananiev at oracle.com> wrote:
> 
> Hi, AWT team,
> 
> I hereby nominate Sergey Bylokhov (OpenJDK user name: serb) to AWT Group Lead [1].
> 
> Sergey is a member of Java Client group at Oracle. He has been one of the most active contributors to AWT (and other Java client libs: Swing, Java2D, JavaFX, Java Sound, Java Beans) last few years and demonstrated very deep knowledge of the library, its architecture and implementation on various platforms.
> 
> Votes are due by June 24, 2016.
> 
> Only current AWT group members [2] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list.
> 
> For Two-Thirds Majority voting instructions, see [3]
> 
> [1] http://openjdk.java.net/bylaws#group-lead
> [2] http://openjdk.java.net/census#awt
> [3] http://openjdk.java.net/bylaws#two-thirds-majority
> 
> Thanks,
> 
> Artem


From semyon.sadetsky at oracle.com  Mon Jun 20 10:29:30 2016
From: semyon.sadetsky at oracle.com (Semyon Sadetsky)
Date: Mon, 20 Jun 2016 13:29:30 +0300
Subject: <AWT Dev> <AWT dev>[9] Review request for 8022810: Cannot list
 all the available display modes on Ubuntu linux in case of two screen
 devices
In-Reply-To: <0b9b2d18-61ea-c6f9-8a21-63947d477cc8@oracle.com>
References: <573579EC.6000105@oracle.com>
	<ad449d68-fd9a-0078-626c-d515cc344775@oracle.com>
	<f8acf699-0296-4013-7c17-841c1ff45325@oracle.com>
	<acf4ee13-8d76-f4a3-76b3-ee8bbae8f652@oracle.com>
	<1e8b8362-9813-4ef9-d46d-9d87f5c2ac0f@oracle.com>
	<a6db7025-e6c4-01c1-8f5f-04207edb15aa@oracle.com>
	<7d72df28-6063-871c-2b76-dc040a1011c9@oracle.com>
	<210dbdfe-a115-61e7-2e8e-8c388913812b@oracle.com>
	<ed10bf97-e37c-76d2-7542-e1013de1e871@oracle.com>
	<5d40566d-70e2-0d46-0d2a-b375e80eedd6@oracle.com>
	<74670508-fc12-7423-812c-313161ee3e59@oracle.com>
	<9cd3e850-51fb-40a0-be98-47e9d2841491@oracle.com>
	<4f58051d-a76b-4d4f-c8c4-2aa71a3c1295@oracle.com>
	<74a58110-73d6-8ffa-2b98-8a196f655d57@oracle.com>
	<0b9b2d18-61ea-c6f9-8a21-63947d477cc8@oracle.com>
Message-ID: <9a546bb9-dd3f-260b-5234-955c882ec436@oracle.com>

On 6/7/2016 7:06 PM, Sergey Bylokhov wrote:

> On 01.06.16 9:57, Semyon Sadetsky wrote:
>> I don't have access to such hardware as well. I'm using linux VMs with
>> several virtual screens. Adding a new screen to a VM configuration can
>> be done in 10 seconds in most VMMs.
>> The result of the getDisplayModes() for 2-screen Ubuntu VM before the
>> fix looked like:
>> for device[0]: <current screen 0 mode>, <<the rest modes of
>> screen-0>>,<<all modes of screen-1>>
>> for device[1]: <current screen 1 mode>
>
> So can you confirm that after the fix the next code will work w/o 
> exceptions?
> http://cr.openjdk.java.net/~serb/tmp/Test.java
Yes, for the single screen configuration.
This test has no use for multimonitor config because display mode change 
is not supported in case of Xinerama.
And I'm planing to fix that, including get/setDisplayMode().

--Semyon
>
> I am worried since we updated the enumDisplayModes(), but did not 
> update the getCurrentDisplayMode() which still uses the old code.
>
>>>>>>>>> the list of supported modes changed and my question was: what
>>>>>>>>> happens
>>>>>>>>> when these modes will be passed to setDisplayMode() (of course
>>>>>>>>> modes
>>>>>>>>> and setDisplayMode should be from one GraphicsDevice object).
>>>>>>>> the same as before the fix.
>
> Actually it seems that setDisplayMode() should not work since 
> JDK-8131752. probably someday we should change the code in 
> X11GraphicsDevice.isDisplayChangeSupported(), which skip the xinerama 
> case.
>


From Sergey.Bylokhov at oracle.com  Mon Jun 20 12:48:10 2016
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Mon, 20 Jun 2016 15:48:10 +0300
Subject: <AWT Dev> <AWT dev>[9] Review request for 8022810: Cannot list
 all the available display modes on Ubuntu linux in case of two screen
 devices
In-Reply-To: <9a546bb9-dd3f-260b-5234-955c882ec436@oracle.com>
References: <573579EC.6000105@oracle.com>
	<ad449d68-fd9a-0078-626c-d515cc344775@oracle.com>
	<f8acf699-0296-4013-7c17-841c1ff45325@oracle.com>
	<acf4ee13-8d76-f4a3-76b3-ee8bbae8f652@oracle.com>
	<1e8b8362-9813-4ef9-d46d-9d87f5c2ac0f@oracle.com>
	<a6db7025-e6c4-01c1-8f5f-04207edb15aa@oracle.com>
	<7d72df28-6063-871c-2b76-dc040a1011c9@oracle.com>
	<210dbdfe-a115-61e7-2e8e-8c388913812b@oracle.com>
	<ed10bf97-e37c-76d2-7542-e1013de1e871@oracle.com>
	<5d40566d-70e2-0d46-0d2a-b375e80eedd6@oracle.com>
	<74670508-fc12-7423-812c-313161ee3e59@oracle.com>
	<9cd3e850-51fb-40a0-be98-47e9d2841491@oracle.com>
	<4f58051d-a76b-4d4f-c8c4-2aa71a3c1295@oracle.com>
	<74a58110-73d6-8ffa-2b98-8a196f655d57@oracle.com>
	<0b9b2d18-61ea-c6f9-8a21-63947d477cc8@oracle.com>
	<9a546bb9-dd3f-260b-5234-955c882ec436@oracle.com>
Message-ID: <bfd8241b-dd21-7ccd-d1a7-1540895086db@oracle.com>

On 20.06.16 13:29, Semyon Sadetsky wrote:
>> So can you confirm that after the fix the next code will work w/o
>> exceptions?
>> http://cr.openjdk.java.net/~serb/tmp/Test.java
> Yes, for the single screen configuration.
> This test has no use for multimonitor config because display mode change
> is not supported in case of Xinerama.

The test also should pass in case of Xinerama, because it contains the 
necessary checks inside "isDisplayChangeSupported()" to skip changing 
the display modes if it is unsupported.

>> I am worried since we updated the enumDisplayModes(), but did not
>> update the getCurrentDisplayMode() which still uses the old code.

I think this case should fail.

>>
>>>>>>>>>> the list of supported modes changed and my question was: what
>>>>>>>>>> happens
>>>>>>>>>> when these modes will be passed to setDisplayMode() (of course
>>>>>>>>>> modes
>>>>>>>>>> and setDisplayMode should be from one GraphicsDevice object).
>>>>>>>>> the same as before the fix.
>>
>> Actually it seems that setDisplayMode() should not work since
>> JDK-8131752. probably someday we should change the code in
>> X11GraphicsDevice.isDisplayChangeSupported(), which skip the xinerama
>> case.
>>
>


-- 
Best regards, Sergey.

From philip.race at oracle.com  Mon Jun 20 20:18:00 2016
From: philip.race at oracle.com (Phil Race)
Date: Mon, 20 Jun 2016 13:18:00 -0700
Subject: <AWT Dev> [OpenJDK 2D-Dev] <Swing Dev> RFR(L): 8159690:
 [TESTBUG] Mark headful tests with @key headful.
In-Reply-To: <9cefe7d5e8c947a997d8dd4ac2286382@DEWDFE13DE09.global.corp.sap>
References: <906afad52c284df2bc8a509e00007912@DEWDFE13DE09.global.corp.sap>
	<791258f1-0e1a-9b09-7021-816137e1146b@oracle.com>
	<CA+3eh13uvD2dpc0dk5kN-WgpdiLmjS=LtzA3=ZTJ3xcYV+=b0g@mail.gmail.com>
	<67f94b06-23fb-a280-f706-20808cab000e@oracle.com>
	<503e07b1c4c5469d8a0ed516cb5bb01c@DEWDFE13DE09.global.corp.sap>
	<32a8ced1-f5f5-d3e1-4834-254bcb106165@oracle.com>
	<CA+3eh12qQtoto-rqSGdcDvXvM07z0AwjGVuNFmSo0-ajGZs-sQ@mail.gmail.com>
	<726f6bd0-6463-0515-9a81-328785694b5d@oracle.com>
	<0682a62cf09045b5a394dbcf70cd2ebc@DEWDFE13DE09.global.corp.sap>
	<4e4dca16-76e4-d9fc-12f2-fad347f9e13a@oracle.com>
	<9cefe7d5e8c947a997d8dd4ac2286382@DEWDFE13DE09.global.corp.sap>
Message-ID: <57684F78.3070302@oracle.com>

It should have been reviewed on 2d as well - I only just saw this.
But how I noticed is that as I am syncing jdk9/dev into jdk9/client
I saw hundreds (!) of client tests had been updated in the wrong forest.
Client test changes and other client changes go into 9/client unless
there is a very good reason otherwise - and it is approved by a client 
group lead.

-phil.

On 06/17/2016 07:23 AM, Lindenmaier, Goetz wrote:
> Hi Sergey,
>
> Sorry, I pushed it just now!  If you (or anybody else) has any objections
> I can revert this or do a follow-up to correct it.  Please let me know.
>
> Best regards,
>    Goetz.
>
>
>
>> -----Original Message-----
>> From: Sergey Bylokhov [mailto:Sergey.Bylokhov at oracle.com]
>> Sent: Freitag, 17. Juni 2016 16:21
>> To: Lindenmaier, Goetz <goetz.lindenmaier at sap.com>; Alexandr Scherbatiy
>> <alexandr.scherbatiy at oracle.com>; Volker Simonis
>> <volker.simonis at gmail.com>
>> Cc: awt-dev at openjdk.java.net; swing-dev at openjdk.java.net; 2d-dev <2d-
>> dev at openjdk.java.net>
>> Subject: Re: <Swing Dev> <AWT Dev> RFR(L): 8159690: [TESTBUG] Mark
>> headful tests with @key headful.
>>
>> I guess that 2d team should review it as well (cc)
>>
>> On 17.06.16 17:17, Lindenmaier, Goetz wrote:
>>> Hi Alexandr,
>>>
>>> Thanks for reviewing!
>>>
>>> Best regards,
>>>    Goetz.
>>>
>>>> -----Original Message-----
>>>> From: Alexandr Scherbatiy [mailto:alexandr.scherbatiy at oracle.com]
>>>> Sent: Freitag, 17. Juni 2016 16:04
>>>> To: Volker Simonis <volker.simonis at gmail.com>
>>>> Cc: Lindenmaier, Goetz <goetz.lindenmaier at sap.com>; swing-
>>>> dev at openjdk.java.net; awt-dev at openjdk.java.net
>>>> Subject: Re: <Swing Dev> <AWT Dev> RFR(L): 8159690: [TESTBUG] Mark
>>>> headful tests with @key headful.
>>>>
>>>>
>>>> The change looks good to me.
>>>>
>>>> Thanks,
>>>> Alexandr.
>>>>
>>>> On 6/17/2016 4:54 PM, Volker Simonis wrote:
>>>>> On Fri, Jun 17, 2016 at 3:40 PM, Alexandr Scherbatiy
>>>>> <alexandr.scherbatiy at oracle.com> wrote:
>>>>>> On 6/17/2016 4:17 PM, Lindenmaier, Goetz wrote:
>>>>>>> Hi Alexandr,
>>>>>>>
>>>>>>> yes, you are right, the test you mention is missing in this change.
>>>>>>> There are others, too, and we still have lots of failures for other
>>>>>>> reasons.
>>>>>>>
>>>>>>> We are currently working on getting all the tests green in
>>>>>>> our test environment where we test linuxppc64, linuxppc64le
>>>>>>> and aixppc64 (and, for reference, the Oracle platforms).
>>>>>>> So I will address all the remaining issues at some point.
>>>>>>>
>>>>>>> If you basically agree on this change, I would appreciate if we
>>>>>>> could push this one and I make a follow up change.  Handling
>>>>>>> changes with this many files is a pain point.  But I can also
>>>>>>> extend this change so that we get all of them at once.
>>>>>>      As I see there are areas like jdk_beans or jdk_imageio which usually
>>>> does
>>>>>> not require headful environment and jdk_awt or jdk_swing which
>> usually
>>>>>> requires it. It seems that ordinary AWT/Swing tests require the
>> "headful"
>>>>>> keyword.
>>>>>>
>>>>>>     May be it is more appropriate to have "headful" keyword for areas
>> like
>>>>>> jdk_beans and "headless" keyword for areas like jdk_awt and
>> jdk_swing?
>>>> This
>>>>>> will allow to mark only small part of tests with necessary keyword for
>> each
>>>>>> area.
>>>>>>
>>>>> While this approach sounds desirable, I'm not aware of functionality
>>>>> in jtreg which allows marking all the tests in a test group (e.g.
>>>>> jdk_awt) with a special default keyword which can be override in the
>>>>> test itself.
>>>>>
>>>>> After all, the author of a test should know best if his test requires
>>>>> a headful environment or not. I think after we've gone trough the
>>>>> initial pain of marking all headful test, the future development
>>>>> should then be straightforward and simple.
>>>>>
>>>>>>     In other way almost all AWT/Swing tests should be marked by
>> "headful"
>>>>>> keyword.
>>>>>>
>>>>>>     Thanks,
>>>>>>     Alexandr.
>>>>>>
>>>>>>
>>>>>>> Best regards,
>>>>>>>     Goetz.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>> -----Original Message-----
>>>>>>>> From: Alexandr Scherbatiy [mailto:alexandr.scherbatiy at oracle.com]
>>>>>>>> Sent: Freitag, 17. Juni 2016 14:53
>>>>>>>> To: Volker Simonis <volker.simonis at gmail.com>
>>>>>>>> Cc: Lindenmaier, Goetz <goetz.lindenmaier at sap.com>; swing-
>>>>>>>> dev at openjdk.java.net; awt-dev at openjdk.java.net
>>>>>>>> Subject: Re: <Swing Dev> <AWT Dev> RFR(L): 8159690: [TESTBUG]
>>>> Mark
>>>>>>>> headful tests with @key headful.
>>>>>>>>
>>>>>>>> On 6/17/2016 11:36 AM, Volker Simonis wrote:
>>>>>>>>> On Thu, Jun 16, 2016 at 5:55 PM, Alexandr Scherbatiy
>>>>>>>>> <alexandr.scherbatiy at oracle.com> wrote:
>>>>>>>>>> On 6/16/2016 5:40 PM, Lindenmaier, Goetz wrote:
>>>>>>>>>>
>>>>>>>>>> Hi,
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> we have test machines without X server. On these many of the
>> jdk
>>>>>>>>>> jtreg tests fail with a headless exception.
>>>>>>>>>>
>>>>>>>>>> We grepped for this exception in the test output and identified
>>>>>>>>>>
>>>>>>>>>> about 450 tests.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> In these tests, we added with another script "@key headful".
>>>>>>>>>>
>>>>>>>>>>        What is a number of tests which passe in headless mode?
>>>>>>>>>>
>>>>>>>>>>       I would expect that an ordinary client test which use Frame and
>>>>>>>>>> fails in
>>>>>>>>>> headless mode does not require a special key by default.
>>>>>>>>>>
>>>>>>>>> Hi Alexandr,
>>>>>>>>>
>>>>>>>>> I don't quite understand your concerns, but the purpose of this
>>>> change
>>>>>>>>> is to make it possible to simply exclude all tests which require a
>>>>>>>>> "headful" environment from a jtreg run.
>>>>>>>>>
>>>>>>>>> There are AWT/Swing tests which can be run even without X
>> server.
>>>> For
>>>>>>>> example:
>>>>>>>>> java/awt/image/DrawImage/DrawImageCoordsTest.java
>>>>>>>>>
>>>>>>>>> Others, like for example:
>>>>>>>>>
>>>>>>>>> java/awt/image/DrawImage/EABlitTest.jtr
>>>>>>>>>
>>>>>>>>> will throw a Headless exception and fail:
>>>>>>>>>
>>>>>>>>> java.awt.HeadlessException:
>>>>>>>>> No X11 DISPLAY variable was set, but this program performed an
>>>>>>>>> operation which requires it.
>>>>>>>>>
>>>>>>>>> With Goetz's change we can simply exclude all the test which
>> require
>>>> a
>>>>>>>>> headful environment by specifying "-keywords:\!headful" to jtreg.
>>>>>>>>> After all, I think that's the purpose why the "headful" keyword has
>>>>>>>>> been introduced.
>>>>>>>>>
>>>>>>>>> If there's any other simple way of excluding all tests which require a
>>>>>>>>> headful environment, please let us now.
>>>>>>>>        For example, the test
>>>>>>>> jdk/test/javax/swing/AbstractButton/6711682/bug6711682.java
>> when
>>>> it is
>>>>>>>> run with -Djava.awt.headless=true option fails with exception
>>>>>>>> "java.awt.AWTException: headless environment".
>>>>>>>>
>>>>>>>>       The test is not listed in the proposed patch. Is it correct that this
>>>>>>>> test requires the "headful" environment and should be marked with
>>>> the
>>>>>>>> "headful" keyword?
>>>>>>>>
>>>>>>>>       Thanks,
>>>>>>>>       Alexandr.
>>>>>>>>
>>>>>>>>> Regards,
>>>>>>>>> Volker
>>>>>>>>>
>>>>>>>>>>       Thanks,
>>>>>>>>>>       Alexandr.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> So that the script generates better output, I adapted the
>>>>>>>>>>
>>>>>>>>>> formatting of some of the test descriptions.
>>>>>>>>>>
>>>>>>>>>> see also the text in the webrev, where I posted some incremental
>>>> diffs
>>>>>>>>>> of the changes I more or less edited by hand.  I hope this eases
>>>>>>>>>>
>>>>>>>>>> reviewing :)
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Last, I updated the Copyrights with the script by Coleen.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Please review this change.
>>>>>>>>>>
>>>>>>>>>> http://cr.openjdk.java.net/~goetz/wr16/8159690-
>>>> headful/webrev.01/
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Best regards,
>>>>>>>>>>
>>>>>>>>>>       Goetz.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>
>> --
>> Best regards, Sergey.


From avik.niyogi at oracle.com  Tue Jun 21 06:40:02 2016
From: avik.niyogi at oracle.com (Avik Niyogi)
Date: Tue, 21 Jun 2016 12:10:02 +0530
Subject: <AWT Dev> <AWT dev>[9] Review request for JDK-8156460 [macosx]
	Test case javax/swing/JPopupMenu/6827786/bug6827786.java fails
In-Reply-To: <df3ee77f-7d04-4b26-b15a-554d7288c96f@default>
References: <df3ee77f-7d04-4b26-b15a-554d7288c96f@default>
Message-ID: <03432BF4-9B58-466A-984B-9B81297411CC@oracle.com>

Hi,
The fix looks good to me. 
A small query though, line 281 - 290 is required at that position, looks like it was moved.

With Regards,
Avik Niyogi
> From: Manajit Halder 
> Sent: Monday, June 20, 2016 1:56 AM
> To: Sergey Bylokhov; Semyon Sadetsky
> Cc: awt-dev at openjdk.java.net <mailto:awt-dev at openjdk.java.net>
> Subject: <AWT Dev> <AWT dev>[9] Review request for JDK-8156460 [macosx] Test case javax/swing/JPopupMenu/6827786/bug6827786.java fails
>  
> Hi All,
>  
> Please review the regression fix for issue JDK-8156460 <https://bugs.openjdk.java.net/browse/JDK-8156460> which fixes below mentioned test cases.
> http://cr.openjdk.java.net/~mhalder/8156460/webrev.00/ <http://cr.openjdk.java.net/~mhalder/8156460/webrev.00/>
>  
> This fix resolves the following 3 JCK failures and 7 test failures:
>  
> JCK tests:
> https://bugs.openjdk.java.net/browse/JDK-8158621 <https://bugs.openjdk.java.net/browse/JDK-8158621>
> https://bugs.openjdk.java.net/browse/JDK-8158485 <https://bugs.openjdk.java.net/browse/JDK-8158485>
> https://bugs.openjdk.java.net/browse/JDK-8158501 <https://bugs.openjdk.java.net/browse/JDK-8158501>
>  
> Jtreg tests:
> https://bugs.openjdk.java.net/browse/JDK-8158389 <https://bugs.openjdk.java.net/browse/JDK-8158389>
> https://bugs.openjdk.java.net/browse/JDK-8158526 <https://bugs.openjdk.java.net/browse/JDK-8158526>
> https://bugs.openjdk.java.net/browse/JDK-8158496 <https://bugs.openjdk.java.net/browse/JDK-8158496>
> https://bugs.openjdk.java.net/browse/JDK-8158362 <https://bugs.openjdk.java.net/browse/JDK-8158362>
> https://bugs.openjdk.java.net/browse/JDK-8158512 <https://bugs.openjdk.java.net/browse/JDK-8158512>
> https://bugs.openjdk.java.net/browse/JDK-8156460 <https://bugs.openjdk.java.net/browse/JDK-8156460>
> https://bugs.openjdk.java.net/browse/JDK-8158377 <https://bugs.openjdk.java.net/browse/JDK-8158377>
>  
> Reason of failure:
>             The modifier value calculation was wrong.
>  
> Note that with this fix the test /java/awt/keyboard/AllKeyCode/AllKeyCode.java will fail due to the reason that pressing number (0 to 9) after pressing arrow keys( up, down, left and right) will generate corresponding Numpad keys code for number keys (0 to 9). Whereas if the arrow key are pressed after number keys are pressed then there is no problem. An issue will be created for this issue once this fix is accepted.
>  
> Thanks,
> Manajit

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

From goetz.lindenmaier at sap.com  Tue Jun 21 06:57:52 2016
From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz)
Date: Tue, 21 Jun 2016 06:57:52 +0000
Subject: <AWT Dev> [OpenJDK 2D-Dev] <Swing Dev> RFR(L): 8159690:
 [TESTBUG] Mark headful tests with @key headful.
In-Reply-To: <57684F78.3070302@oracle.com>
References: <906afad52c284df2bc8a509e00007912@DEWDFE13DE09.global.corp.sap>
	<791258f1-0e1a-9b09-7021-816137e1146b@oracle.com>
	<CA+3eh13uvD2dpc0dk5kN-WgpdiLmjS=LtzA3=ZTJ3xcYV+=b0g@mail.gmail.com>
	<67f94b06-23fb-a280-f706-20808cab000e@oracle.com>
	<503e07b1c4c5469d8a0ed516cb5bb01c@DEWDFE13DE09.global.corp.sap>
	<32a8ced1-f5f5-d3e1-4834-254bcb106165@oracle.com>
	<CA+3eh12qQtoto-rqSGdcDvXvM07z0AwjGVuNFmSo0-ajGZs-sQ@mail.gmail.com>
	<726f6bd0-6463-0515-9a81-328785694b5d@oracle.com>
	<0682a62cf09045b5a394dbcf70cd2ebc@DEWDFE13DE09.global.corp.sap>
	<4e4dca16-76e4-d9fc-12f2-fad347f9e13a@oracle.com>
	<9cefe7d5e8c947a997d8dd4ac2286382@DEWDFE13DE09.global.corp.sap>
	<57684F78.3070302@oracle.com>
Message-ID: <eaeffe139c2d4e5a8fd2c605419a6a27@DEWDFE13DE09.global.corp.sap>

Hi Phil, 

I'm sorry I got this wrong. I'm not that familiar with the list/repo organization
on the jdk side.  I'll try to do better next time.  
Besides the wrong processing of the change, do you have any objections
to its content?  I'll do a follow-up if so to get it straightened out.

Best regards,
 Goetz.

> -----Original Message-----
> From: Phil Race [mailto:philip.race at oracle.com]
> Sent: Montag, 20. Juni 2016 22:18
> To: Lindenmaier, Goetz <goetz.lindenmaier at sap.com>
> Cc: Sergey Bylokhov <Sergey.Bylokhov at oracle.com>; Alexandr Scherbatiy
> <alexandr.scherbatiy at oracle.com>; Volker Simonis
> <volker.simonis at gmail.com>; awt-dev at openjdk.java.net; 2d-dev <2d-
> dev at openjdk.java.net>; swing-dev at openjdk.java.net
> Subject: Re: [OpenJDK 2D-Dev] <Swing Dev> <AWT Dev> RFR(L): 8159690:
> [TESTBUG] Mark headful tests with @key headful.
> 
> It should have been reviewed on 2d as well - I only just saw this.
> But how I noticed is that as I am syncing jdk9/dev into jdk9/client
> I saw hundreds (!) of client tests had been updated in the wrong forest.
> Client test changes and other client changes go into 9/client unless
> there is a very good reason otherwise - and it is approved by a client
> group lead.
> 
> -phil.
> 
> On 06/17/2016 07:23 AM, Lindenmaier, Goetz wrote:
> > Hi Sergey,
> >
> > Sorry, I pushed it just now!  If you (or anybody else) has any objections
> > I can revert this or do a follow-up to correct it.  Please let me know.
> >
> > Best regards,
> >    Goetz.
> >
> >
> >
> >> -----Original Message-----
> >> From: Sergey Bylokhov [mailto:Sergey.Bylokhov at oracle.com]
> >> Sent: Freitag, 17. Juni 2016 16:21
> >> To: Lindenmaier, Goetz <goetz.lindenmaier at sap.com>; Alexandr
> Scherbatiy
> >> <alexandr.scherbatiy at oracle.com>; Volker Simonis
> >> <volker.simonis at gmail.com>
> >> Cc: awt-dev at openjdk.java.net; swing-dev at openjdk.java.net; 2d-dev
> <2d-
> >> dev at openjdk.java.net>
> >> Subject: Re: <Swing Dev> <AWT Dev> RFR(L): 8159690: [TESTBUG] Mark
> >> headful tests with @key headful.
> >>
> >> I guess that 2d team should review it as well (cc)
> >>
> >> On 17.06.16 17:17, Lindenmaier, Goetz wrote:
> >>> Hi Alexandr,
> >>>
> >>> Thanks for reviewing!
> >>>
> >>> Best regards,
> >>>    Goetz.
> >>>
> >>>> -----Original Message-----
> >>>> From: Alexandr Scherbatiy [mailto:alexandr.scherbatiy at oracle.com]
> >>>> Sent: Freitag, 17. Juni 2016 16:04
> >>>> To: Volker Simonis <volker.simonis at gmail.com>
> >>>> Cc: Lindenmaier, Goetz <goetz.lindenmaier at sap.com>; swing-
> >>>> dev at openjdk.java.net; awt-dev at openjdk.java.net
> >>>> Subject: Re: <Swing Dev> <AWT Dev> RFR(L): 8159690: [TESTBUG]
> Mark
> >>>> headful tests with @key headful.
> >>>>
> >>>>
> >>>> The change looks good to me.
> >>>>
> >>>> Thanks,
> >>>> Alexandr.
> >>>>
> >>>> On 6/17/2016 4:54 PM, Volker Simonis wrote:
> >>>>> On Fri, Jun 17, 2016 at 3:40 PM, Alexandr Scherbatiy
> >>>>> <alexandr.scherbatiy at oracle.com> wrote:
> >>>>>> On 6/17/2016 4:17 PM, Lindenmaier, Goetz wrote:
> >>>>>>> Hi Alexandr,
> >>>>>>>
> >>>>>>> yes, you are right, the test you mention is missing in this change.
> >>>>>>> There are others, too, and we still have lots of failures for other
> >>>>>>> reasons.
> >>>>>>>
> >>>>>>> We are currently working on getting all the tests green in
> >>>>>>> our test environment where we test linuxppc64, linuxppc64le
> >>>>>>> and aixppc64 (and, for reference, the Oracle platforms).
> >>>>>>> So I will address all the remaining issues at some point.
> >>>>>>>
> >>>>>>> If you basically agree on this change, I would appreciate if we
> >>>>>>> could push this one and I make a follow up change.  Handling
> >>>>>>> changes with this many files is a pain point.  But I can also
> >>>>>>> extend this change so that we get all of them at once.
> >>>>>>      As I see there are areas like jdk_beans or jdk_imageio which
> usually
> >>>> does
> >>>>>> not require headful environment and jdk_awt or jdk_swing which
> >> usually
> >>>>>> requires it. It seems that ordinary AWT/Swing tests require the
> >> "headful"
> >>>>>> keyword.
> >>>>>>
> >>>>>>     May be it is more appropriate to have "headful" keyword for areas
> >> like
> >>>>>> jdk_beans and "headless" keyword for areas like jdk_awt and
> >> jdk_swing?
> >>>> This
> >>>>>> will allow to mark only small part of tests with necessary keyword for
> >> each
> >>>>>> area.
> >>>>>>
> >>>>> While this approach sounds desirable, I'm not aware of functionality
> >>>>> in jtreg which allows marking all the tests in a test group (e.g.
> >>>>> jdk_awt) with a special default keyword which can be override in the
> >>>>> test itself.
> >>>>>
> >>>>> After all, the author of a test should know best if his test requires
> >>>>> a headful environment or not. I think after we've gone trough the
> >>>>> initial pain of marking all headful test, the future development
> >>>>> should then be straightforward and simple.
> >>>>>
> >>>>>>     In other way almost all AWT/Swing tests should be marked by
> >> "headful"
> >>>>>> keyword.
> >>>>>>
> >>>>>>     Thanks,
> >>>>>>     Alexandr.
> >>>>>>
> >>>>>>
> >>>>>>> Best regards,
> >>>>>>>     Goetz.
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>> -----Original Message-----
> >>>>>>>> From: Alexandr Scherbatiy
> [mailto:alexandr.scherbatiy at oracle.com]
> >>>>>>>> Sent: Freitag, 17. Juni 2016 14:53
> >>>>>>>> To: Volker Simonis <volker.simonis at gmail.com>
> >>>>>>>> Cc: Lindenmaier, Goetz <goetz.lindenmaier at sap.com>; swing-
> >>>>>>>> dev at openjdk.java.net; awt-dev at openjdk.java.net
> >>>>>>>> Subject: Re: <Swing Dev> <AWT Dev> RFR(L): 8159690: [TESTBUG]
> >>>> Mark
> >>>>>>>> headful tests with @key headful.
> >>>>>>>>
> >>>>>>>> On 6/17/2016 11:36 AM, Volker Simonis wrote:
> >>>>>>>>> On Thu, Jun 16, 2016 at 5:55 PM, Alexandr Scherbatiy
> >>>>>>>>> <alexandr.scherbatiy at oracle.com> wrote:
> >>>>>>>>>> On 6/16/2016 5:40 PM, Lindenmaier, Goetz wrote:
> >>>>>>>>>>
> >>>>>>>>>> Hi,
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> we have test machines without X server. On these many of the
> >> jdk
> >>>>>>>>>> jtreg tests fail with a headless exception.
> >>>>>>>>>>
> >>>>>>>>>> We grepped for this exception in the test output and identified
> >>>>>>>>>>
> >>>>>>>>>> about 450 tests.
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> In these tests, we added with another script "@key headful".
> >>>>>>>>>>
> >>>>>>>>>>        What is a number of tests which passe in headless mode?
> >>>>>>>>>>
> >>>>>>>>>>       I would expect that an ordinary client test which use Frame
> and
> >>>>>>>>>> fails in
> >>>>>>>>>> headless mode does not require a special key by default.
> >>>>>>>>>>
> >>>>>>>>> Hi Alexandr,
> >>>>>>>>>
> >>>>>>>>> I don't quite understand your concerns, but the purpose of this
> >>>> change
> >>>>>>>>> is to make it possible to simply exclude all tests which require a
> >>>>>>>>> "headful" environment from a jtreg run.
> >>>>>>>>>
> >>>>>>>>> There are AWT/Swing tests which can be run even without X
> >> server.
> >>>> For
> >>>>>>>> example:
> >>>>>>>>> java/awt/image/DrawImage/DrawImageCoordsTest.java
> >>>>>>>>>
> >>>>>>>>> Others, like for example:
> >>>>>>>>>
> >>>>>>>>> java/awt/image/DrawImage/EABlitTest.jtr
> >>>>>>>>>
> >>>>>>>>> will throw a Headless exception and fail:
> >>>>>>>>>
> >>>>>>>>> java.awt.HeadlessException:
> >>>>>>>>> No X11 DISPLAY variable was set, but this program performed an
> >>>>>>>>> operation which requires it.
> >>>>>>>>>
> >>>>>>>>> With Goetz's change we can simply exclude all the test which
> >> require
> >>>> a
> >>>>>>>>> headful environment by specifying "-keywords:\!headful" to
> jtreg.
> >>>>>>>>> After all, I think that's the purpose why the "headful" keyword
> has
> >>>>>>>>> been introduced.
> >>>>>>>>>
> >>>>>>>>> If there's any other simple way of excluding all tests which
> require a
> >>>>>>>>> headful environment, please let us now.
> >>>>>>>>        For example, the test
> >>>>>>>> jdk/test/javax/swing/AbstractButton/6711682/bug6711682.java
> >> when
> >>>> it is
> >>>>>>>> run with -Djava.awt.headless=true option fails with exception
> >>>>>>>> "java.awt.AWTException: headless environment".
> >>>>>>>>
> >>>>>>>>       The test is not listed in the proposed patch. Is it correct that
> this
> >>>>>>>> test requires the "headful" environment and should be marked
> with
> >>>> the
> >>>>>>>> "headful" keyword?
> >>>>>>>>
> >>>>>>>>       Thanks,
> >>>>>>>>       Alexandr.
> >>>>>>>>
> >>>>>>>>> Regards,
> >>>>>>>>> Volker
> >>>>>>>>>
> >>>>>>>>>>       Thanks,
> >>>>>>>>>>       Alexandr.
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> So that the script generates better output, I adapted the
> >>>>>>>>>>
> >>>>>>>>>> formatting of some of the test descriptions.
> >>>>>>>>>>
> >>>>>>>>>> see also the text in the webrev, where I posted some
> incremental
> >>>> diffs
> >>>>>>>>>> of the changes I more or less edited by hand.  I hope this eases
> >>>>>>>>>>
> >>>>>>>>>> reviewing :)
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> Last, I updated the Copyrights with the script by Coleen.
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> Please review this change.
> >>>>>>>>>>
> >>>>>>>>>> http://cr.openjdk.java.net/~goetz/wr16/8159690-
> >>>> headful/webrev.01/
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> Best regards,
> >>>>>>>>>>
> >>>>>>>>>>       Goetz.
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>
> >> --
> >> Best regards, Sergey.


From semyon.sadetsky at oracle.com  Tue Jun 21 09:09:35 2016
From: semyon.sadetsky at oracle.com (Semyon Sadetsky)
Date: Tue, 21 Jun 2016 12:09:35 +0300
Subject: <AWT Dev> <AWT dev>[9] Review request for 8022810: Cannot list
 all the available display modes on Ubuntu linux in case of two screen
 devices
In-Reply-To: <bfd8241b-dd21-7ccd-d1a7-1540895086db@oracle.com>
References: <573579EC.6000105@oracle.com>
	<ad449d68-fd9a-0078-626c-d515cc344775@oracle.com>
	<f8acf699-0296-4013-7c17-841c1ff45325@oracle.com>
	<acf4ee13-8d76-f4a3-76b3-ee8bbae8f652@oracle.com>
	<1e8b8362-9813-4ef9-d46d-9d87f5c2ac0f@oracle.com>
	<a6db7025-e6c4-01c1-8f5f-04207edb15aa@oracle.com>
	<7d72df28-6063-871c-2b76-dc040a1011c9@oracle.com>
	<210dbdfe-a115-61e7-2e8e-8c388913812b@oracle.com>
	<ed10bf97-e37c-76d2-7542-e1013de1e871@oracle.com>
	<5d40566d-70e2-0d46-0d2a-b375e80eedd6@oracle.com>
	<74670508-fc12-7423-812c-313161ee3e59@oracle.com>
	<9cd3e850-51fb-40a0-be98-47e9d2841491@oracle.com>
	<4f58051d-a76b-4d4f-c8c4-2aa71a3c1295@oracle.com>
	<74a58110-73d6-8ffa-2b98-8a196f655d57@oracle.com>
	<0b9b2d18-61ea-c6f9-8a21-63947d477cc8@oracle.com>
	<9a546bb9-dd3f-260b-5234-955c882ec436@oracle.com>
	<bfd8241b-dd21-7ccd-d1a7-1540895086db@oracle.com>
Message-ID: <405f6223-e44f-11b0-bfa1-0f9c9a122f20@oracle.com>

On 6/20/2016 3:48 PM, Sergey Bylokhov wrote:

> On 20.06.16 13:29, Semyon Sadetsky wrote:
>>> So can you confirm that after the fix the next code will work w/o
>>> exceptions?
>>> http://cr.openjdk.java.net/~serb/tmp/Test.java
>> Yes, for the single screen configuration.
>> This test has no use for multimonitor config because display mode change
>> is not supported in case of Xinerama.
>
> The test also should pass in case of Xinerama, because it contains the 
> necessary checks inside "isDisplayChangeSupported()" to skip changing 
> the display modes if it is unsupported.
This test has no sense for Xinerama until java supports mode changes for 
it.
I have created a bug to migrate getDisplayMode() to the new xrandr api: 
https://bugs.openjdk.java.net/browse/JDK-8159953
>
>>> I am worried since we updated the enumDisplayModes(), but did not
>>> update the getCurrentDisplayMode() which still uses the old code.
>
> I think this case should fail.
>
>>>
>>>>>>>>>>> the list of supported modes changed and my question was: what
>>>>>>>>>>> happens
>>>>>>>>>>> when these modes will be passed to setDisplayMode() (of course
>>>>>>>>>>> modes
>>>>>>>>>>> and setDisplayMode should be from one GraphicsDevice object).
>>>>>>>>>> the same as before the fix.
>>>
>>> Actually it seems that setDisplayMode() should not work since
>>> JDK-8131752. probably someday we should change the code in
>>> X11GraphicsDevice.isDisplayChangeSupported(), which skip the xinerama
>>> case.
>>>
>>
>
>


From dmitry.markov at oracle.com  Tue Jun 21 09:28:15 2016
From: dmitry.markov at oracle.com (dmitry markov)
Date: Tue, 21 Jun 2016 12:28:15 +0300
Subject: <AWT Dev> [9] Review request for 8154816: Caps Lock doesn't
 work as expected when using Pinyin Simplified input method
In-Reply-To: <5ae1b2a4-dc24-9f2e-c3c7-cd4dc61646c4@oracle.com>
References: <5763D4B0.4030209@oracle.com>
	<5ae1b2a4-dc24-9f2e-c3c7-cd4dc61646c4@oracle.com>
Message-ID: <576908AF.2020401@oracle.com>

Hi Semyon,

Thank you for review.

I guess, the applet based tests are still suitable. As far as I know 
there are many regression tests for AWT/Swing which use such approach. 
And I am not aware of any plans/activities to remove/re-write them.

Thanks,
Dmitry
On 20/06/2016 11:29, Semyon Sadetsky wrote:
> Hi Dmitry,
>
> The fix looks good.
>
> I am only not sure that an applet based test is suitable since applets 
> are deprecated.
>
> --Semyon
>
>
> On 6/17/2016 1:45 PM, dmitry markov wrote:
>> Hello,
>>
>> Could you review a fix for jdk9, please?
>>
>>     bug: https://bugs.openjdk.java.net/browse/JDK-8154816
>>     webrev: http://cr.openjdk.java.net/~dmarkov/8154816/webrev.00/
>>
>> Problem description:
>> When Pinyin Simplified input method is selected and 'Caps Lock' is 
>> on, input is switched to latin letters, but letters are entered in 
>> uppercase.
>>
>> Fix:
>> It is necessary to ignore 'Caps Lock' modifier in 
>> CPlatformResponder.handleKeyEvent() method, if Pinyin Simplified 
>> input method is selected and 'Caps Lock' is on.
>>
>> Thanks,
>> Dmitry
>


From Sergey.Bylokhov at oracle.com  Tue Jun 21 11:30:27 2016
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Tue, 21 Jun 2016 14:30:27 +0300
Subject: <AWT Dev> <AWT dev>[9] Review request for 8022810: Cannot list
 all the available display modes on Ubuntu linux in case of two screen
 devices
In-Reply-To: <405f6223-e44f-11b0-bfa1-0f9c9a122f20@oracle.com>
References: <573579EC.6000105@oracle.com>
	<ad449d68-fd9a-0078-626c-d515cc344775@oracle.com>
	<f8acf699-0296-4013-7c17-841c1ff45325@oracle.com>
	<acf4ee13-8d76-f4a3-76b3-ee8bbae8f652@oracle.com>
	<1e8b8362-9813-4ef9-d46d-9d87f5c2ac0f@oracle.com>
	<a6db7025-e6c4-01c1-8f5f-04207edb15aa@oracle.com>
	<7d72df28-6063-871c-2b76-dc040a1011c9@oracle.com>
	<210dbdfe-a115-61e7-2e8e-8c388913812b@oracle.com>
	<ed10bf97-e37c-76d2-7542-e1013de1e871@oracle.com>
	<5d40566d-70e2-0d46-0d2a-b375e80eedd6@oracle.com>
	<74670508-fc12-7423-812c-313161ee3e59@oracle.com>
	<9cd3e850-51fb-40a0-be98-47e9d2841491@oracle.com>
	<4f58051d-a76b-4d4f-c8c4-2aa71a3c1295@oracle.com>
	<74a58110-73d6-8ffa-2b98-8a196f655d57@oracle.com>
	<0b9b2d18-61ea-c6f9-8a21-63947d477cc8@oracle.com>
	<9a546bb9-dd3f-260b-5234-955c882ec436@oracle.com>
	<bfd8241b-dd21-7ccd-d1a7-1540895086db@oracle.com>
	<405f6223-e44f-11b0-bfa1-0f9c9a122f20@oracle.com>
Message-ID: <115d6bfc-006a-9f36-41e4-1dff60d87bf9@oracle.com>

On 21.06.16 12:09, Semyon Sadetsky wrote:
> This test has no sense for Xinerama until java supports mode changes for
> it.
> I have created a bug to migrate getDisplayMode() to the new xrandr api:
> https://bugs.openjdk.java.net/browse/JDK-8159953
>>>> I am worried since we updated the enumDisplayModes(), but did not
>>>> update the getCurrentDisplayMode() which still uses the old code.

I am not sure why it is related to supporting of mode changes, this is 
related to what I wrote above about 
enumDisplayModes/getCurrentDisplayMode, but if you would like to fix it 
separately ok.

To Alexander: It seems that we should update this API for HiDPI? How 
DisplayMode is supposed to work in HiDPI?

>>>>>>>>>>>> the list of supported modes changed and my question was: what
>>>>>>>>>>>> happens
>>>>>>>>>>>> when these modes will be passed to setDisplayMode() (of course
>>>>>>>>>>>> modes
>>>>>>>>>>>> and setDisplayMode should be from one GraphicsDevice object).
>>>>>>>>>>> the same as before the fix.
>>>>
>>>> Actually it seems that setDisplayMode() should not work since
>>>> JDK-8131752. probably someday we should change the code in
>>>> X11GraphicsDevice.isDisplayChangeSupported(), which skip the xinerama
>>>> case.
>>>>
>>>
>>
>>
>


-- 
Best regards, Sergey.

From java at obendig.de  Tue Jun 21 14:39:41 2016
From: java at obendig.de (Oliver Bendig)
Date: Tue, 21 Jun 2016 16:39:41 +0200 (CEST)
Subject: <AWT Dev> Review request for 4908075: Press shift and another key
 using robot does not trigger events properly
Message-ID: <2040975450.33317.1466519981519.JavaMail.open-xchange@app06.ox.hosteurope.de>

Hi,

can you please review the following fix:

Webrev: http://cr.openjdk.java.net/~simonis/webrevs/2016/4908075/
BugID: https://bugs.openjdk.java.net/browse/JDK-4908075

Following some mre details: we are facing issues when trying to send keyboard
events via awt robot. When trying to send a keyboard event from the extended
keys with the SHIFT-key pressed, this doesn't send a correct key combination.
Instead, the Shift-Key is released before the second keycode is sent. This makes
it impossible to send combinations like e.g. shift+delete.

The bug id 4908075 for this issue is rather old. The suggested idea to switch to
SendInput() instead of keybd_event() was delayed at that time because of missing
support in Win98. For testing purposes, I implemented SendInput instead of
keybd_event, but the issue stays the same. The problem seems to be caused by the
missing KEYEVENTF_EXTENDEDKEY flag when calling keybd_event or SendInput. Bug id
8155742 introduces this flag for other reason for VK_ALT_GRAPH. If this is
enhanced to cover the extended keys that were introduced as enhancement of the
old 84 key AT keyboard, the correct key events are sent.

The bug 4908075 was closed as "Won't fix" but I think the fix would be rather
simple. Should I reopen 4908075 or is it better to create a new bug for this
issue.

Thank you and best regards,
Oliver
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20160621/c2c0d512/attachment.html>

From david.dehaven at oracle.com  Tue Jun 21 18:41:18 2016
From: david.dehaven at oracle.com (David DeHaven)
Date: Tue, 21 Jun 2016 11:41:18 -0700
Subject: <AWT Dev> [9] RFR: 8022291: Mac OS: Unexpected JavaLaunchHelper
	message displaying
Message-ID: <72F99549-04C8-4096-915C-A4F917A6E52E@oracle.com>


JBS:
https://bugs.openjdk.java.net/browse/JDK-8022291

Webrev:
http://cr.openjdk.java.net/~ddehaven/8022291/jdk.0/index.html

This actually turned out to be pretty easy to fix, I eliminated the JavaLaunchHelper class and in place of it stuffed the block it replaced into a NSBlockOperation then changed the performSelectorOnMainThread call to invoke the NSBlockOperation's start message.

I tested against the SWT snippet (Snippet297) that was attached to the original Eclipse bug that triggered the original fix. The SWT tests I could dig up all seemed to work ok.

Original Eclipse bug, used to verify the fix:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=389486


This should be backported to 8u after it bakes in 9 for a bit.

-DrD-


From Sergey.Bylokhov at oracle.com  Tue Jun 21 19:53:33 2016
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Tue, 21 Jun 2016 22:53:33 +0300
Subject: <AWT Dev> Review request for 4908075: Press shift and another
 key using robot does not trigger events properly
In-Reply-To: <2040975450.33317.1466519981519.JavaMail.open-xchange@app06.ox.hosteurope.de>
References: <2040975450.33317.1466519981519.JavaMail.open-xchange@app06.ox.hosteurope.de>
Message-ID: <4cc52daf-b82a-30d2-fc84-e9518e0d3452@oracle.com>

Hi, Oliver.
Is it possible to write a test for this fix?

On 21.06.16 17:39, Oliver Bendig wrote:
> Hi,
>
> can you please review the following fix:
>
> Webrev: http://cr.openjdk.java.net/~simonis/webrevs/2016/4908075/
> BugID: https://bugs.openjdk.java.net/browse/JDK-4908075
>
> Following some mre details: we are facing issues when trying to send
> keyboard events via awt robot. When trying to send a keyboard event from
> the extended keys with the SHIFT-key pressed, this doesn't send a
> correct key combination. Instead, the Shift-Key is released before the
> second keycode is sent. This makes it impossible to send combinations
> like e.g. shift+delete.
>
> The bug id 4908075 for this issue is rather old. The suggested idea to
> switch to SendInput() instead of keybd_event() was delayed at that time
> because of missing support in Win98. For testing purposes, I implemented
> SendInput instead of keybd_event, but the issue stays the same. The
> problem seems to be caused by the missing KEYEVENTF_EXTENDEDKEY flag
> when calling keybd_event or SendInput. Bug id 8155742 introduces this
> flag for other reason for VK_ALT_GRAPH. If this is enhanced to cover the
> extended keys that were introduced as enhancement of the old 84 key AT
> keyboard, the correct key events are sent.
>
> The bug 4908075 was closed as "Won't fix" but I think the fix would be
> rather simple. Should I reopen 4908075 or is it better to create a new
> bug for this issue.
>
> Thank you and best regards,
> Oliver
>


-- 
Best regards, Sergey.

From Sergey.Bylokhov at oracle.com  Tue Jun 21 20:24:43 2016
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Tue, 21 Jun 2016 23:24:43 +0300
Subject: <AWT Dev> <AWT dev>[9] Review request for JDK-8155740: [macosx]
 robot.keyPress and robot.keyRelease do not generate key event for Alt-Graph
 key VK_ALT_GRAPH.
In-Reply-To: <44da048f-32d0-db9d-c44b-9420141ef2f9@oracle.com>
References: <538F0C0F-2C53-49CD-96B5-F78A794E3177@oracle.com>
	<5734A835.80908@oracle.com>
	<75CD4BD9-983C-4315-A5FC-3518C37BECF7@oracle.com>
	<573E06C5.5040807@oracle.com>
	<4CFAD53C-0E2F-43B4-854C-BFF1CEB944A5@oracle.com>
	<082a4f05-f5f2-01d0-5951-dc36b3dafbe5@oracle.com>
	<F3869358-BE09-42E0-8F39-ED1E40210B18@oracle.com>
	<8655c6e1-0cfb-01b1-9081-f656970eeafc@oracle.com>
	<6C54D895-737D-4731-BE16-06F4658ADE49@oracle.com>
	<d1da8509-523c-a4ad-4282-aacf0f7f4bcd@oracle.com>
	<D132FC13-E80E-43AF-A62A-E92BE6028C8B@oracle.com>
	<44da048f-32d0-db9d-c44b-9420141ef2f9@oracle.com>
Message-ID: <da6053cc-ac1d-80ab-efd6-0c1cac8eb682@oracle.com>

+1

On 15.06.16 9:41, Semyon Sadetsky wrote:
> OK, Thanks.
>
> Looks good to me.
>
> --Semyon
>
>
> On 6/14/2016 9:48 PM, Manajit Halder wrote:
>> Hi Semyon,
>>
>> Alignement is improved and it looks correct on Xcode and Netbeans.
>> Please review the latest webrev:
>>
>> http://cr.openjdk.java.net/~mhalder/8155740/webrev.05/
>> <http://cr.openjdk.java.net/%7Emhalder/8155740/webrev.05/>
>>
>> Thanks,
>> Manajit
>>
>>> On 14-Jun-2016, at 3:17 pm, Semyon Sadetsky
>>> <semyon.sadetsky at oracle.com <mailto:semyon.sadetsky at oracle.com>> wrote:
>>>
>>> Hi Manajit,
>>>
>>> Could you improve the alignment of lines 272-286?
>>>
>>> --Semyon
>>>
>>>
>>> On 6/13/2016 2:29 PM, Manajit Halder wrote:
>>>> Hi Semyon and Sergey,
>>>>
>>>> Code is modified as per the comment. Please review the modified webrev.
>>>>
>>>> http://cr.openjdk.java.net/~mhalder/8155740/webrev.04/
>>>> <http://cr.openjdk.java.net/%7Emhalder/8155740/webrev.04/>
>>>>
>>>> webrev.02 did not work because -
>>>> The input nsFlag (modifier value) passed to the
>>>> function NsKeyModifiersToJavaModifiers was not correct. The
>>>> calculation of modifier was not wrong and hence wrong modifier
>>>> values was returned from the method.
>>>>
>>>> Test cases run:
>>>> Remaining two tests present
>>>> in https://java.net/jira/browse/MACOSX_PORT passed with the fix.
>>>> java/awt/Dialog/NestedDialogs/Modal/NestedModalDialogTest.java
>>>> java/awt/Dialog/NestedDialogs/Modeless/NestedModelessDialogTest.java
>>>>
>>>> Thanks,
>>>> Manajit
>>>>
>>>>> On 01-Jun-2016, at 11:24 pm, Semyon Sadetsky
>>>>> <semyon.sadetsky at oracle.com <mailto:semyon.sadetsky at oracle.com>> wrote:
>>>>>
>>>>> Hi Manaji,
>>>>>
>>>>> Okay, back to werev.01.
>>>>>
>>>>> Could you remove the comment in lines 262-268 since you assume that
>>>>> it is not true anymore and so
>>>>> CGEventCreateKeyboardEvent/CGEventPost will not cause any troubles.
>>>>>
>>>>> Did you analyze why werev.02 fix did not pass those tests?
>>>>>
>>>>> --Semyon
>>>>>
>>>>>
>>>>> On 6/1/2016 4:46 PM, Manajit Halder wrote:
>>>>>> Hi  Semyon and Sergey,
>>>>>>
>>>>>> After running the tests shared by Sergey I found that the second
>>>>>> webrev (webrev.01) shared by me solves the problem.
>>>>>>
>>>>>> http://cr.openjdk.java.net/~mhalder/8155740/webrev.01/
>>>>>> <http://cr.openjdk.java.net/%7Emhalder/8155740/webrev.01/>
>>>>>>
>>>>>> Following tests were present
>>>>>> in https://java.net/jira/browse/MACOSX_PORT-621:
>>>>>> closed/java/awt/KeyboardFocusmanager/ConsumeNextMnemonicKeyTypedTest/ConsumeNextMnemonicKeyTypedTest
>>>>>> java/awt/Dialog/NestedDialogs/Modal/NestedModalDialogTest.java
>>>>>> java/awt/Dialog/NestedDialogs/Modeless/NestedModelessDialogTest.java
>>>>>>
>>>>>> But only first test (which is now present as part of open code)
>>>>>> could be performed and the remaining tests were not found in the
>>>>>> present code.
>>>>>> The first test fails due to another issue (JDK-8156460), whose fix
>>>>>> is in progress and will be send for after this issue. This fix
>>>>>> (JDK-8155740) is not related to the failure of the first test case.
>>>>>>
>>>>>> The new location of the first test:
>>>>>> java/awt/KeyboardFocusmanager/ConsumeNextMnemonicKeyTypedTest/ConsumeNextMnemonicKeyTypedTest
>>>>>>
>>>>>>  Please review the webrev.01.
>>>>>>
>>>>>> Thanks,
>>>>>> Manajit
>>>>>>
>>>>>>> On 26-May-2016, at 1:05 pm, Semyon Sadetsky
>>>>>>> <<mailto:semyon.sadetsky at oracle.com>semyon.sadetsky at oracle.com>
>>>>>>> wrote:
>>>>>>>
>>>>>>> On 5/24/2016 2:09 PM, Manajit Halder wrote:
>>>>>>>
>>>>>>>> Hi Semyon,
>>>>>>>>
>>>>>>>> It is not clear in the comment what was the problem, but it
>>>>>>>> looks like the problem was observed just by
>>>>>>>> using CGEventCreateKeyboardEvent/CGEventPost. In my case I don?t
>>>>>>>> see any issues just by using the fix. It posts all the key
>>>>>>>> events and all the key events are tested in the test file
>>>>>>>> modified along with the fix.
>>>>>>> If you found the comment is not actual anymore, why did you
>>>>>>> preserve it?
>>>>>>>
>>>>>>> --Semyon
>>>>>>>>
>>>>>>>> Apart from the unknown problem mentioned in the existing comment
>>>>>>>> this fix has following advantages:
>>>>>>>>
>>>>>>>>   * Key codes for modifier key are required to distinguish
>>>>>>>>     between Alt and Alt-Gr key, which is not possible by using
>>>>>>>>     existing solution as it doesn?t post key codes for modifier
>>>>>>>>     keys. And also keys can?t be distinguished base on modifier
>>>>>>>>     value, which is same for both keys (Alt and Alt-Gr).
>>>>>>>>   * As mentioned in the existing
>>>>>>>>     comment CGEventCreateKeyboardEvent/CGEventPost is a better
>>>>>>>>     solution.
>>>>>>>>   * Online search about keyboard simulation showed
>>>>>>>>     that CGEventCreateKeyboardEvent/CGEventPost is used to
>>>>>>>>     simulate key stores in most of the cases.
>>>>>>>>   * Tested the key codes, didn?t observe any problem.
>>>>>>>>
>>>>>>>>
>>>>>>>> Regarding number keys not working
>>>>>>>> with CGEventCreateKeyboardEvent/CGEventPost:
>>>>>>>> Solved the problem by providing event source
>>>>>>>> to CGEventCreateKeyboardEvent. Code is modified.
>>>>>>>>
>>>>>>>> Please review the modified code:
>>>>>>>> http://cr.openjdk.java.net/~mhalder/8155740/webrev.02/
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>> Manajit
>>>>>>>>
>>>>>>>>> On 20-May-2016, at 12:02 am, Semyon Sadetsky
>>>>>>>>> <semyon.sadetsky at oracle.com> wrote:
>>>>>>>>>
>>>>>>>>> Hi Manajit,
>>>>>>>>>
>>>>>>>>> Before your fix all key codes wa sent using
>>>>>>>>>
>>>>>>>>> AXUIElementCreateSystemWide();
>>>>>>>>>
>>>>>>>>> and CGEventCreateKeyboardEvent was commented or excluded from
>>>>>>>>> compilation:
>>>>>>>>>
>>>>>>>>> 274 #if 0
>>>>>>>>>  275     CGEventRef event = CGEventCreateKeyboardEvent(NULL,
>>>>>>>>> keyCode, keyPressed);
>>>>>>>>>  276     if (event != NULL) {
>>>>>>>>>  277         CGEventPost(kCGSessionEventTap, event);
>>>>>>>>>  278         CFRelease(event);
>>>>>>>>>  279     }
>>>>>>>>>  280 #endif
>>>>>>>>>
>>>>>>>>> I just wonder why it was done. Maybe that was some other issue
>>>>>>>>> fix. The comment above states:
>>>>>>>>>
>>>>>>>>>  262      * Well, using CGEventCreateKeyboardEvent/CGEventPost
>>>>>>>>> would have been
>>>>>>>>>  263      * a better solution, however, it gives me all kinds
>>>>>>>>> of trouble and I have
>>>>>>>>>  264      * no idea how to solve them without inserting delays
>>>>>>>>> between simulated
>>>>>>>>>  265      * events. So, I've ended up disabling it and opted
>>>>>>>>> for another approach
>>>>>>>>>  266      * that uses Accessibility API instead.
>>>>>>>>>
>>>>>>>>> I don't understand what trouble is mentioned in the comment
>>>>>>>>> above. But in your fix you've put the
>>>>>>>>> CGEventCreateKeyboardEvent back, may it return this trouble back?
>>>>>>>>>
>>>>>>>>> Also as I understand Numpad number keys did not work as well.
>>>>>>>>> Could you add the corresponding test case since you provide a
>>>>>>>>> fix this extra issue?
>>>>>>>>>
>>>>>>>>> --Semyon
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On 5/13/2016 11:50 PM, Manajit Halder wrote:
>>>>>>>>>> Hi Semyon,
>>>>>>>>>>
>>>>>>>>>> The fix is changed a bit because it was observed that the
>>>>>>>>>> modifier keys plus alphabet keys were not working together. In
>>>>>>>>>> the modified fix only Num keys are posted by
>>>>>>>>>> AXUIElementPostKeyboardEvent and remaining keys are posted by
>>>>>>>>>> CGPostKeyboardEvent/CGEventPost. The fix is explained in the
>>>>>>>>>> comment in file CRobot.m.
>>>>>>>>>>
>>>>>>>>>> Please review the new changes:
>>>>>>>>>> _http://cr.openjdk.java.net/~mhalder/8155740/webrev.01/_
>>>>>>>>>> _
>>>>>>>>>> _
>>>>>>>>>>
>>>>>>>>>> Answers to your questions:
>>>>>>>>>>
>>>>>>>>>> What is difference between AXUIElementPostKeyboardEvent and
>>>>>>>>>> CGEventCreateKeyboardEvent?
>>>>>>>>>>
>>>>>>>>>> Difference as per the documentation:
>>>>>>>>>> AXUIElementPostKeyboardEvent is similar to CGPostKeyboardEvent
>>>>>>>>>> (which synthesizes a low-level keyboard event on the local
>>>>>>>>>> machine), but it allows you to specify the target application
>>>>>>>>>> as opposed to always sending the events to the active
>>>>>>>>>> application. If the system-wide accessibility object is passed
>>>>>>>>>> in the application parameter, the event is sent to the active
>>>>>>>>>> application.
>>>>>>>>>>
>>>>>>>>>> Difference behaviour as per the implementation observed while
>>>>>>>>>> debugging the code:
>>>>>>>>>> AXUIElementPostKeyboardEvent:
>>>>>>>>>> AXUIElementPostKeyboardEvent posts 0 key code for all the
>>>>>>>>>> modifier keys with key codes 16, 17,18, 20, 157 and also for
>>>>>>>>>> newly added modifier key VK_ALT_GRAPH. But it posts correct
>>>>>>>>>> key code for all the remaining keys.
>>>>>>>>>> While debugging it was that for modifier keys keyDown and
>>>>>>>>>> keyUp events are not generated, but flagsChanged event
>>>>>>>>>> (flagsChanged: (NSEvent *)event) is generated. But for all
>>>>>>>>>> other keys keyDown followed by keyUp events are generated.
>>>>>>>>>>
>>>>>>>>>> CGEventCreateKeyboardEvent:
>>>>>>>>>> CGEventCreateKeyboardEvent posts correct key code for all the
>>>>>>>>>> keys except for numeric keys (numbers 0 to 9 on normal
>>>>>>>>>> keyboard). CGEventCreateKeyboardEvent posts wrong key codes
>>>>>>>>>> for the number keys 0 to 9. Instead of posting number key
>>>>>>>>>> codes it posts Numpad key codes for the corresponding number
>>>>>>>>>> key. For example Numpad0 key code is posted for number 0,
>>>>>>>>>> Numpad1 key code is posted for number 1 and simillarly for
>>>>>>>>>> remaining num keys.
>>>>>>>>>> Why the latter was commented? Does it mean that valid modifier
>>>>>>>>>> keys have not been sent by AWT robot?
>>>>>>>>>>
>>>>>>>>>> I didn?t get your question clearly. If you meant why in the
>>>>>>>>>> current implementation the later part (fix using
>>>>>>>>>> CGPostKeyboardEvent) of fix was commented.
>>>>>>>>>> I am not very sure about it. As per the comment it is only
>>>>>>>>>> clear that CGPostKeyboardEvent/CGEventPost would have been a
>>>>>>>>>> better solution and I agree with that, perhaps reason could be
>>>>>>>>>> related to the difference in behaviour observed while
>>>>>>>>>> debugging the code as mentioned above.
>>>>>>>>>>
>>>>>>>>>> Thanks,
>>>>>>>>>> Manajit
>>>>>>>>>>
>>>>>>>>>>> Hi Manajit,
>>>>>>>>>>>
>>>>>>>>>>> Just a few questions to clarify on the fix.
>>>>>>>>>>> What is difference between AXUIElementPostKeyboardEvent and
>>>>>>>>>>> CGEventCreateKeyboardEvent?
>>>>>>>>>>
>>>>>>>>>>> Why the latter was commented? Does it mean that valid
>>>>>>>>>>> modifier keys have not been sent by AWT robot?
>>>>>>>>>>>
>>>>>>>>>>> --Semyon
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> On 5/12/2016 10:45 AM, Manajit Halder wrote:
>>>>>>>>>>>> Hi All,
>>>>>>>>>>>>
>>>>>>>>>>>> Kindly review the fix for JDK9.
>>>>>>>>>>>>
>>>>>>>>>>>> *Bug*:
>>>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8155740
>>>>>>>>>>>> _
>>>>>>>>>>>> _
>>>>>>>>>>>> *Webrev*:
>>>>>>>>>>>> http://cr.openjdk.java.net/~mhalder/8155740/webrev.00/
>>>>>>>>>>>>
>>>>>>>>>>>> *Issue: *
>>>>>>>>>>>> [macosx] robot.keyPress and robot.keyRelease do not generate
>>>>>>>>>>>> key event for Alt-Graph key VK_ALT_GRAPH.
>>>>>>>>>>>>
>>>>>>>>>>>> *Cause: *
>>>>>>>>>>>> VK_ALT_GRAPH is a new key added to the Mac OS X platform and
>>>>>>>>>>>> it is not mapped to any key on the OS X platform.
>>>>>>>>>>>>
>>>>>>>>>>>> *Fix: *
>>>>>>>>>>>> VK_ALT_GRAPH is mapped to right option (OSX_RightOption) key
>>>>>>>>>>>> on Mac OS X.
>>>>>>>>>>>>
>>>>>>>>>>>> Method Java_sun_lwawt_macosx_CRobot_keyEvent is modified for
>>>>>>>>>>>> the following reason:
>>>>>>>>>>>> AXUIElementPostKeyboardEvent posts 0 key code for all  the
>>>>>>>>>>>> modifier keys with key codes (16, 17,18, 20, 157) and also
>>>>>>>>>>>> for newly added modifier key VK_ALT_GRAPH.
>>>>>>>>>>>> But it posts correct key code for all the other keys. On the
>>>>>>>>>>>> other hand CGEventCreateKeyboardEvent posts correct key code
>>>>>>>>>>>> for all the modifier keys and
>>>>>>>>>>>> hence it is used to post modifier key events and
>>>>>>>>>>>> AXUIElementPostKeyboardEvent is used to post all the
>>>>>>>>>>>> remaining key events.
>>>>>>>>>>>>
>>>>>>>>>>>> Regards,
>>>>>>>>>>>> Manajit
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>


-- 
Best regards, Sergey.

From david.dehaven at oracle.com  Tue Jun 21 22:58:04 2016
From: david.dehaven at oracle.com (David DeHaven)
Date: Tue, 21 Jun 2016 15:58:04 -0700
Subject: <AWT Dev> [9] RFR: 8022291: Mac OS: Unexpected JavaLaunchHelper
	message displaying
In-Reply-To: <72F99549-04C8-4096-915C-A4F917A6E52E@oracle.com>
References: <72F99549-04C8-4096-915C-A4F917A6E52E@oracle.com>
Message-ID: <F737C8BE-E9AC-49EF-B465-33717CB354DA@oracle.com>


> JBS:
> https://bugs.openjdk.java.net/browse/JDK-8022291
> 
> Webrev:
> http://cr.openjdk.java.net/~ddehaven/8022291/jdk.0/index.html
> 
> This actually turned out to be pretty easy to fix, I eliminated the JavaLaunchHelper class and in place of it stuffed the block it replaced into a NSBlockOperation then changed the performSelectorOnMainThread call to invoke the NSBlockOperation's start message.
> 
> I tested against the SWT snippet (Snippet297) that was attached to the original Eclipse bug that triggered the original fix. The SWT tests I could dig up all seemed to work ok.
> 
> Original Eclipse bug, used to verify the fix:
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=389486
> 
> 
> This should be backported to 8u after it bakes in 9 for a bit.


Minor update:
http://cr.openjdk.java.net/~ddehaven/8022291/jdk.1/

I put the NSAutoreleasePool back, so it's directly portable to jdk8u.

-DrD-


From semyon.sadetsky at oracle.com  Wed Jun 22 09:40:48 2016
From: semyon.sadetsky at oracle.com (Semyon Sadetsky)
Date: Wed, 22 Jun 2016 12:40:48 +0300
Subject: <AWT Dev> <AWT dev>[9] Review request for 8157827:
 AWT_Desktop/Automated/Exceptions/BasicTest loads incorrect GTK version when
 jdk.gtk.version=3
In-Reply-To: <5748AA6B.90303@oracle.com>
References: <e1e5e9c8-758b-696e-84ec-2ae046e9f22e@oracle.com>
	<57460663.20506@oracle.com>
	<c3a262c7-d66a-80a3-e955-153a06092e09@oracle.com>
	<5748AA6B.90303@oracle.com>
Message-ID: <df46c369-b695-82a6-e9b5-375b4825f35b@oracle.com>

Actually no missing file. Only the missed place to replace ordinal() 
with getNumber().

--Semyon


On 5/27/2016 11:13 PM, Phil Race wrote:
> So is there a missing file here or not ?
>
> -phil.
>
> On 05/26/2016 12:12 AM, Semyon Sadetsky wrote:
>> I am sorry for any misunderstanding I may have caused.
>>
>> That was your request in 
>> http://mail.openjdk.java.net/pipermail/swing-dev/2016-April/005773.html 
>> :
>>
>> >I think we can/should quickly fix the new ordinal() usage and file a
>> >separate bug for the GTKEngine usage.
>>
>> I just fulfilled it. But, my fault, I missed one place to convert 
>> ordinal() to getNumber().
>>
>> Yes, the 8154992 is about the remaining ordinal() refactoring that we 
>> postponed because there are plenty of them in the code and it may 
>> take a noticeable time to fix them all.
>>
>> --Semyon
>>
>> On 5/25/2016 11:09 PM, Phil Race wrote:
>>> Where did getNumber() come from ? Did you miss a file in the review ?
>>>
>>> Under what circumstances does this fail as I did not notice such a 
>>> failure.
>>>
>>> And yet this sounds like what was pointed out by Sergey during the 
>>> GTK 3 review here :
>>> http://mail.openjdk.java.net/pipermail/swing-dev/2016-March/005495.html
>>> and I thought was going to be fixed before it was pushed as 
>>> requested here :-
>>> http://mail.openjdk.java.net/pipermail/swing-dev/2016-April/005773.html
>>>
>>> The request for a separate bug which you filed here :-
>>> https://bugs.openjdk.java.net/browse/JDK-8154992
>>> was for the pre-existing usages.
>>>
>>> -phil.
>>>
>>> On 05/25/2016 10:54 AM, Semyon Sadetsky wrote:
>>>> Hello,
>>>>
>>>> Please review fix for JDK9:
>>>>
>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8157827
>>>>
>>>> webrev: http://cr.openjdk.java.net/~ssadetsky/8157827/webrev.00/
>>>>
>>>> In the Desktop initialization procedure GtkVersions#ordinal() was 
>>>> used instead of GtkVersions#getNumber().
>>>>
>>>> --Semyon
>>>>
>>>
>>
>


From Sergey.Bylokhov at oracle.com  Wed Jun 22 19:12:50 2016
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Wed, 22 Jun 2016 22:12:50 +0300
Subject: <AWT Dev> [9] RFR: 8022291: Mac OS: Unexpected JavaLaunchHelper
 message displaying
In-Reply-To: <F737C8BE-E9AC-49EF-B465-33717CB354DA@oracle.com>
References: <72F99549-04C8-4096-915C-A4F917A6E52E@oracle.com>
	<F737C8BE-E9AC-49EF-B465-33717CB354DA@oracle.com>
Message-ID: <2e17e072-a124-3bd4-e54e-e47230320fe3@oracle.com>

Looks fine.

On 22.06.16 1:58, David DeHaven wrote:
>
>> JBS:
>> https://bugs.openjdk.java.net/browse/JDK-8022291
>>
>> Webrev:
>> http://cr.openjdk.java.net/~ddehaven/8022291/jdk.0/index.html
>>
>> This actually turned out to be pretty easy to fix, I eliminated the JavaLaunchHelper class and in place of it stuffed the block it replaced into a NSBlockOperation then changed the performSelectorOnMainThread call to invoke the NSBlockOperation's start message.
>>
>> I tested against the SWT snippet (Snippet297) that was attached to the original Eclipse bug that triggered the original fix. The SWT tests I could dig up all seemed to work ok.
>>
>> Original Eclipse bug, used to verify the fix:
>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=389486
>>
>>
>> This should be backported to 8u after it bakes in 9 for a bit.
>
>
> Minor update:
> http://cr.openjdk.java.net/~ddehaven/8022291/jdk.1/
>
> I put the NSAutoreleasePool back, so it's directly portable to jdk8u.
>
> -DrD-
>


-- 
Best regards, Sergey.

From ambarish.rapte at oracle.com  Thu Jun 23 05:44:28 2016
From: ambarish.rapte at oracle.com (Ambarish Rapte)
Date: Wed, 22 Jun 2016 22:44:28 -0700 (PDT)
Subject: <AWT Dev> Review request for 8151588: Press the button first
 two times, the 'First' and 'Next' didn't show
In-Reply-To: <1473e148-0210-45e2-88dc-d77cd4106170@default>
References: <1473e148-0210-45e2-88dc-d77cd4106170@default>
Message-ID: <0509e7a6-4c5e-4c4e-b45c-27a9e11cb3d7@default>

Hi,

Gentle reminder. Please review.

 

Regards,

Ambaris

 

 

From: Ambarish Rapte 
Sent: Wednesday, June 15, 2016 8:40 PM
To: Prasanta Sadhukhan; Semyon Sadetsky; Sergey Bylokhov; Alexander Scherbatiy; awt-dev at openjdk.java.net
Subject: <AWT Dev> Review request for 8151588: Press the button first two times, the 'First' and 'Next' didn't show

 

Hi,

Please review this fix for JDK9,

Webrev: http://cr.openjdk.java.net/~arapte/8151588/webrev.00/

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

 

 

Issue:

When Text Area is not in focus, If select or append is called on Text Area and if the desired text is not in visible area

then the Text Area should auto scroll to make the desired text visible.

But this behavior was broken due to fix of,

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

Patch(1): http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/b9f91de8ae43

 

 

Fix:

Issue JDK-6180449 is also fixed by fix of,

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

http://hg.openjdk.java.net/jdk9/client/jdk/rev/4a1e160a12c3

 

Hence reverting the fix Patch(1) for JDK-6180449 to fix this regression.

 

 

Verification:

All JCK tests for Text Area pass, no other test fails due to this change.

The newly added test with this fix, fails without the patch and passes after merging the patch.

 

 

Regards,

Ambarish

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

From semyon.sadetsky at oracle.com  Thu Jun 23 06:37:19 2016
From: semyon.sadetsky at oracle.com (Semyon Sadetsky)
Date: Thu, 23 Jun 2016 09:37:19 +0300
Subject: <AWT Dev> Review request for 8151588: Press the button first
 two times, the 'First' and 'Next' didn't show
In-Reply-To: <0509e7a6-4c5e-4c4e-b45c-27a9e11cb3d7@default>
References: <1473e148-0210-45e2-88dc-d77cd4106170@default>
	<0509e7a6-4c5e-4c4e-b45c-27a9e11cb3d7@default>
Message-ID: <fb0ad96a-e10e-51cb-eb4a-4bbb91403443@oracle.com>

Looks good to me.

--Semyon


On 6/23/2016 8:44 AM, Ambarish Rapte wrote:
>
> Hi,
>
> Gentle reminder. Please review.
>
> Regards,
>
> Ambaris
>
> *From:*Ambarish Rapte
> *Sent:* Wednesday, June 15, 2016 8:40 PM
> *To:* Prasanta Sadhukhan; Semyon Sadetsky; Sergey Bylokhov; Alexander 
> Scherbatiy; awt-dev at openjdk.java.net
> *Subject:* <AWT Dev> Review request for 8151588: Press the button 
> first two times, the 'First' and 'Next' didn't show
>
> Hi,
>
> Please review this fix for JDK9,
>
> Webrev: http://cr.openjdk.java.net/~arapte/8151588/webrev.00/ 
> <http://cr.openjdk.java.net/%7Earapte/8151588/webrev.00/>
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8151588
>
> *Issue:*
>
> When Text Area is not in focus, If select or append is called on Text 
> Area and if the desired text is not in visible area
>
> then the Text Area should auto scroll to make the desired text visible.
>
> But this behavior was broken due to fix of,
>
> bug: https://bugs.openjdk.java.net/browse/JDK-6180449
>
> Patch(1): http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/b9f91de8ae43
>
> *Fix:*
>
> Issue JDK-6180449 is also fixed by fix of,
>
> https://bugs.openjdk.java.net/browse/JDK-8149636
>
> http://hg.openjdk.java.net/jdk9/client/jdk/rev/4a1e160a12c3
>
> Hence reverting the fix /Patch(1)/ for JDK-6180449 to fix this regression.
>
> *Verification:*
>
> All JCK tests for Text Area pass, no other test fails due to this change.
>
> The newly added test with this fix, fails without the patch and passes 
> after merging the patch.
>
> Regards,
>
> Ambarish
>

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

From ajit.ghaisas at oracle.com  Thu Jun 23 07:09:43 2016
From: ajit.ghaisas at oracle.com (Ajit Ghaisas)
Date: Thu, 23 Jun 2016 00:09:43 -0700 (PDT)
Subject: <AWT Dev> [9] Fix for JDK-8074824: Resolve disabled warnings for
	libawt_xawt
In-Reply-To: <53656bf6-bce8-4444-8c4f-67d7cc93a522@default>
References: <53656bf6-bce8-4444-8c4f-67d7cc93a522@default>
Message-ID: <58fd8ac4-4520-4776-8229-a7c510eba6d6@default>

Hi,

Bug :
    https://bugs.openjdk.java.net/browse/JDK-8074824
    (Resolve disabled warnings for libawt_xawt)

As part of fixing this bug, I have -

    1. Fixed warnings in source code after removing blanket warning suppressions from makefile.

    2. In case the warning fix is not possible, converted blanket warning suppression for this library to suppression of warnings for individual files. 

    3. Added comments in makefile for the warning suppression that cannot be fixed. 

   One type of gcc warning 'deprecated-declarations' will be fixed separately (as part of JDK-8160146)


I have built the changes successfully on all supported platforms.


Webrev : 
    http://cr.openjdk.java.net/~aghaisas/8074824/webrev.00/

Request you to review.

Regards,
Ajit

From alexander.potochkin at oracle.com  Thu Jun 23 13:51:32 2016
From: alexander.potochkin at oracle.com (Alexander Potochkin)
Date: Thu, 23 Jun 2016 16:51:32 +0300
Subject: <AWT Dev> [9] Review request for 8154816: Caps Lock doesn't
 work as expected when using Pinyin Simplified input method
In-Reply-To: <5ae1b2a4-dc24-9f2e-c3c7-cd4dc61646c4@oracle.com>
References: <5763D4B0.4030209@oracle.com>
	<5ae1b2a4-dc24-9f2e-c3c7-cd4dc61646c4@oracle.com>
Message-ID: <0ebcdda1-ea22-85a3-266c-df1073769bce@oracle.com>

Hello Semyon

> Hi Dmitry,
>
> The fix looks good.

The fix is good for me as well.
>
> I am only not sure that an applet based test is suitable since applets 
> are deprecated.

The Jtreg manual tests are supposed to be applets.

I consulted with the SQE team,
they have no objections for the applet based tests.

So I think this test is fine.

Thanks
alexp

>
> --Semyon
>
>
> On 6/17/2016 1:45 PM, dmitry markov wrote:
>> Hello,
>>
>> Could you review a fix for jdk9, please?
>>
>>     bug: https://bugs.openjdk.java.net/browse/JDK-8154816
>>     webrev: http://cr.openjdk.java.net/~dmarkov/8154816/webrev.00/
>>
>> Problem description:
>> When Pinyin Simplified input method is selected and 'Caps Lock' is 
>> on, input is switched to latin letters, but letters are entered in 
>> uppercase.
>>
>> Fix:
>> It is necessary to ignore 'Caps Lock' modifier in 
>> CPlatformResponder.handleKeyEvent() method, if Pinyin Simplified 
>> input method is selected and 'Caps Lock' is on.
>>
>> Thanks,
>> Dmitry
>


From alexander.potochkin at oracle.com  Thu Jun 23 13:55:01 2016
From: alexander.potochkin at oracle.com (Alexander Potochkin)
Date: Thu, 23 Jun 2016 16:55:01 +0300
Subject: <AWT Dev> [9] Review request for 8148984: [macosx] Chinese
 Comma cannot be entered using Pinyin Input Method on OS X
In-Reply-To: <5763EF8D.5010309@oracle.com>
References: <5763EF8D.5010309@oracle.com>
Message-ID: <d9cadfcc-1470-32d3-aae0-d1ce133a7b43@oracle.com>

Hello Dmitry

The fix looks good!

Thanks
alexp

On 6/17/2016 15:39, dmitry markov wrote:
> Hello,
>
> Could you review a fix for jdk9, please?
>
>     bug: https://bugs.openjdk.java.net/browse/JDK-8148984
>     webrev: http://cr.openjdk.java.net/~dmarkov/8148984/webrev.00/
>
> Problem description:
> 'Latin comma' character is entered in text component instead of the 
> required 'fullwidth comma' character, when ',' character is pressed on 
> the keyboard and Pinyin ? Traditional or Simplified IM is enabled, 
> because KeyEvent is generated instead of InputMethodEvent.
>
> Fix:
> It is necessary to generate InputMethodEvent for the characters from 
> 'Halfwidth and Fullwidth Forms' Unicode block (U+FF00 - U+FFEF). So 
> the method isCodePointInUnicodeBlockNeedingIMEvent() in AWTView.m 
> should be updated.
>
> Thanks,
> Dmitry


From david.dehaven at oracle.com  Thu Jun 23 18:30:49 2016
From: david.dehaven at oracle.com (David DeHaven)
Date: Thu, 23 Jun 2016 11:30:49 -0700
Subject: <AWT Dev> [9] RFR: 8022291: Mac OS: Unexpected JavaLaunchHelper
	message displaying
In-Reply-To: <2e17e072-a124-3bd4-e54e-e47230320fe3@oracle.com>
References: <72F99549-04C8-4096-915C-A4F917A6E52E@oracle.com>
	<F737C8BE-E9AC-49EF-B465-33717CB354DA@oracle.com>
	<2e17e072-a124-3bd4-e54e-e47230320fe3@oracle.com>
Message-ID: <131A833E-A56D-455A-847B-6A2510F2BD5C@oracle.com>


Thanks, Sergey.

Can someone from the core-libs launcher group please approve? (looks at Kumar)

-DrD-

> Looks fine.
> 
> On 22.06.16 1:58, David DeHaven wrote:
>> 
>>> JBS:
>>> https://bugs.openjdk.java.net/browse/JDK-8022291
>>> 
>>> Webrev:
>>> http://cr.openjdk.java.net/~ddehaven/8022291/jdk.0/index.html
>>> 
>>> This actually turned out to be pretty easy to fix, I eliminated the JavaLaunchHelper class and in place of it stuffed the block it replaced into a NSBlockOperation then changed the performSelectorOnMainThread call to invoke the NSBlockOperation's start message.
>>> 
>>> I tested against the SWT snippet (Snippet297) that was attached to the original Eclipse bug that triggered the original fix. The SWT tests I could dig up all seemed to work ok.
>>> 
>>> Original Eclipse bug, used to verify the fix:
>>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=389486
>>> 
>>> 
>>> This should be backported to 8u after it bakes in 9 for a bit.
>> 
>> 
>> Minor update:
>> http://cr.openjdk.java.net/~ddehaven/8022291/jdk.1/
>> 
>> I put the NSAutoreleasePool back, so it's directly portable to jdk8u.
>> 
>> -DrD-
>> 
> 
> 
> -- 
> Best regards, Sergey.


From ambarish.rapte at oracle.com  Fri Jun 24 08:37:29 2016
From: ambarish.rapte at oracle.com (Ambarish Rapte)
Date: Fri, 24 Jun 2016 01:37:29 -0700 (PDT)
Subject: <AWT Dev> Review request for 8158616: [TEST_BUG] There is only
 "Fail" button on the description dialog
In-Reply-To: <5332c203-1809-0300-29c8-57daed73b241@oracle.com>
References: <0208ff0e-d357-41b3-b8ec-dceaefca3e8a@default>
	<20eed0d6-b5b6-6d94-f5ec-a68916c03bea@oracle.com>
	<c6efe01e-2dbb-44b8-9a6d-efffafa9206a@default>
	<5332c203-1809-0300-29c8-57daed73b241@oracle.com>
Message-ID: <405ba84e-05c3-410e-8fe7-29fa5a3a3218@default>

Hi Semyon,

                JDK-8155740, is pushed now, http://hg.openjdk.java.net/jdk9/client/jdk/rev/16a8f15abd96

                On mac Robot supports Alt-Gr key press now, hence excluding mac also.

 

                Please review the updated webrev: http://cr.openjdk.java.net/~arapte/8158616/webrev.01/

                Changes:

1.       Exclude the test for windows and mac.

2.       Using jtreg tags for exclusion instead of testlibrary.

 

Regards,

Ambarish

                

 

From: Semyon Sadetsky 
Sent: Wednesday, June 15, 2016 8:53 PM
To: Ambarish Rapte; Prasanta Sadhukhan; Sergey Bylokhov; awt-dev at openjdk.java.net
Subject: Re: Review request for 8158616: [TEST_BUG] There is only "Fail" button on the description dialog

 

 

 

On 6/15/2016 2:05 PM, Ambarish Rapte wrote:

Hi Semyon,

 

Yes, the test is automatic for windows and it is tested with the test: test/java/awt/Robot/ModifierRobotKey/ModifierRobotKeyTest.java

Windows robot supports Alt-Gr key press: http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/80766aba7d32

Hence the test could be automated.

 

But on Linux and mac robot does not support Alt-Gr key press yet, hence the test is manual.

It seems for mac this also will fixed as JDK-8155740 is pushed, right?

--Semyon



 

Regards,

Ambarish

 

From: Semyon Sadetsky 
Sent: Wednesday, June 15, 2016 3:08 PM
To: Ambarish Rapte; Prasanta Sadhukhan; Sergey Bylokhov; HYPERLINK "mailto:awt-dev at openjdk.java.net"awt-dev at openjdk.java.net
Subject: Re: Review request for 8158616: [TEST_BUG] There is only "Fail" button on the description dialog

 

Hi Ambarish,

Does it mean that the test was automatic on Windows and manual on other OSes?

--Semyon

 

On 6/15/2016 12:13 PM, Ambarish Rapte wrote:

Hi ,

Please review the test bug fix for JDK9,

Webrev: http://cr.openjdk.java.net/~arapte/8158616/webrev.00/

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

 

 

Issue: 

Misleading description to click pass button in test steps for Windows.

But there is no pass button.

As the pass criteria is verified programmatically, there is no need of Pass button.

 

Fix:

Corrected the description &

Skipping the test execution for Windows platform, as the test is automated under Robot class.

 

Verification:

Test executes successfully on Windows, Ubunu & Mac

 

 

Regards,

Ambarish

 

 

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

From semyon.sadetsky at oracle.com  Fri Jun 24 11:31:26 2016
From: semyon.sadetsky at oracle.com (Semyon Sadetsky)
Date: Fri, 24 Jun 2016 14:31:26 +0300
Subject: <AWT Dev> Review request for 8158616: [TEST_BUG] There is only
 "Fail" button on the description dialog
In-Reply-To: <405ba84e-05c3-410e-8fe7-29fa5a3a3218@default>
References: <0208ff0e-d357-41b3-b8ec-dceaefca3e8a@default>
	<20eed0d6-b5b6-6d94-f5ec-a68916c03bea@oracle.com>
	<c6efe01e-2dbb-44b8-9a6d-efffafa9206a@default>
	<5332c203-1809-0300-29c8-57daed73b241@oracle.com>
	<405ba84e-05c3-410e-8fe7-29fa5a3a3218@default>
Message-ID: <93a1b856-bd75-c8b6-3d1b-16e9539a425d@oracle.com>

Looks good to me.

--Semyon


On 6/24/2016 11:37 AM, Ambarish Rapte wrote:
>
> Hi Semyon,
>
> JDK-8155740, is pushed now, 
> http://hg.openjdk.java.net/jdk9/client/jdk/rev/16a8f15abd96
>
> On mac Robot supports Alt-Gr key press now, hence excluding mac also.
>
> Please review the updated webrev: 
> http://cr.openjdk.java.net/~arapte/8158616/webrev.01/ 
> <http://cr.openjdk.java.net/%7Earapte/8158616/webrev.01/>
>
> Changes:
>
> 1.Exclude the test for windows and mac.
>
> 2.Using jtreg tags for exclusion instead of testlibrary.
>
> Regards,
>
> Ambarish
>
> *From:*Semyon Sadetsky
> *Sent:* Wednesday, June 15, 2016 8:53 PM
> *To:* Ambarish Rapte; Prasanta Sadhukhan; Sergey Bylokhov; 
> awt-dev at openjdk.java.net
> *Subject:* Re: Review request for 8158616: [TEST_BUG] There is only 
> "Fail" button on the description dialog
>
> On 6/15/2016 2:05 PM, Ambarish Rapte wrote:
>
>     Hi Semyon,
>
>     Yes, the test is automatic for windows and it is tested with the
>     test: test/java/awt/Robot/ModifierRobotKey/ModifierRobotKeyTest.java
>
>     Windows robot supports Alt-Gr key press:
>     http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/80766aba7d32
>
>     Hence the test could be automated.
>
>     But on Linux and mac robot does not support Alt-Gr key press yet,
>     hence the test is manual.
>
> It seems for mac this also will fixed as JDK-8155740 is pushed, right?
>
> --Semyon
>
> Regards,
>
> Ambarish
>
> *From:*Semyon Sadetsky
> *Sent:* Wednesday, June 15, 2016 3:08 PM
> *To:* Ambarish Rapte; Prasanta Sadhukhan; Sergey Bylokhov; 
> awt-dev at openjdk.java.net <mailto:awt-dev at openjdk.java.net>
> *Subject:* Re: Review request for 8158616: [TEST_BUG] There is only 
> "Fail" button on the description dialog
>
> Hi Ambarish,
>
> Does it mean that the test was automatic on Windows and manual on 
> other OSes?
>
> --Semyon
>
> On 6/15/2016 12:13 PM, Ambarish Rapte wrote:
>
>     Hi ,
>
>     Please review the test bug fix for JDK9,
>
>     Webrev: http://cr.openjdk.java.net/~arapte/8158616/webrev.00/
>     <http://cr.openjdk.java.net/%7Earapte/8158616/webrev.00/>
>
>     Bug: https://bugs.openjdk.java.net/browse/JDK-8158616
>
>     Issue:
>
>     Misleading description to click pass button in test steps for Windows.
>
>     But there is no pass button.
>
>     As the pass criteria is verified programmatically, there is no
>     need of Pass button.
>
>     Fix:
>
>     Corrected the description &
>
>     Skipping the test execution for Windows platform, as the test is
>     automated under Robot class.
>
>     Verification:
>
>     Test executes successfully on Windows, Ubunu & Mac
>
>     Regards,
>
>     Ambarish
>

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

From manajit.halder at oracle.com  Fri Jun 24 15:23:51 2016
From: manajit.halder at oracle.com (Manajit Halder)
Date: Fri, 24 Jun 2016 20:53:51 +0530
Subject: <AWT Dev> <AWT dev>[9] Review request for [macosx]
	NestedModalDialogTest.java and NestedModelessDialogTest.java
	tests does not run with current JDK codebase after taking the
	files from MACOSX_PORT
Message-ID: <353E8B64-2991-4F3B-AAC4-20377A11E924@oracle.com>

Hi Sergey,

Kindly review the fix for JDK9.

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

Webrev: 
http://cr.openjdk.java.net/~mhalder/8160266/webrev.00/ <http://cr.openjdk.java.net/~mhalder/8160266/webrev.00/>

Issue: 
[macosx] NestedModalDialogTest.java and NestedModelessDialogTest.java tests does not run with current JDK codebase after taking the files from MACOSX_PORT

Cause: 
Both the tests were written using unit.framework.

Fix: 
Test files are modified to remove the dependency of junit.framework and related API calls. Test files were moved from MACOSX_PORT to the current JDK 9 codebase and added at the corresponding folder location:
test/java/awt/Dialog/NestedDialogs/Modal/NestedModalDialogTest.java
test/java/awt/Dialog/NestedDialogs/Modeless/NestedModelessDialogTest.java

Along with the test file 3 supporting files are also moved. The files are:
test/java/awt/regtesthelpers/RobotUtilities.java
test/java/awt/regtesthelpers/VisibilityValidator.java
test/java/awt/regtesthelpers/Waypoint.java


Regards,
Manajit
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20160624/f1c2e41c/attachment.html>

From manajit.halder at oracle.com  Sat Jun 25 14:16:34 2016
From: manajit.halder at oracle.com (Manajit Halder)
Date: Sat, 25 Jun 2016 19:46:34 +0530
Subject: <AWT Dev> <AWT dev>[9] Review request for JDK-8156460 [macosx]
	Test case javax/swing/JPopupMenu/6827786/bug6827786.java fails
In-Reply-To: <03432BF4-9B58-466A-984B-9B81297411CC@oracle.com>
References: <df3ee77f-7d04-4b26-b15a-554d7288c96f@default>
	<03432BF4-9B58-466A-984B-9B81297411CC@oracle.com>
Message-ID: <3F293A13-C767-451D-A07E-87A84A3C0D6D@oracle.com>

Hi All,

The code was changed on the same lines in one file after the first review was generated. A new review is generated after taking an update of the code.
Fix wise the webrev.00 and webrev.01 are same.

Please review webrev.01
http://cr.openjdk.java.net/~mhalder/8156460/webrev.01/ <http://cr.openjdk.java.net/~mhalder/8156460/webrev.01/>

Also note that along with the previous 10 issues as mentioned in the first review mail below another two new issues created 2 days ago also gets resolved by this fix.
The 2 new issues are:

https://bugs.openjdk.java.net/browse/JDK-8160144 <https://bugs.openjdk.java.net/browse/JDK-8160144>
https://bugs.openjdk.java.net/browse/JDK-8160145 <https://bugs.openjdk.java.net/browse/JDK-8160145>

Thank you Avik for your comment. The lines were moved up to maintain the order of modifier values in increasing order.

Thanks,
Manajit


> On 21-Jun-2016, at 12:10 pm, Avik Niyogi <avik.niyogi at oracle.com> wrote:
> 
> Hi,
> The fix looks good to me. 
> A small query though, line 281 - 290 is required at that position, looks like it was moved.
> 
> With Regards,
> Avik Niyogi
>> From: Manajit Halder 
>> Sent: Monday, June 20, 2016 1:56 AM
>> To: Sergey Bylokhov; Semyon Sadetsky
>> Cc: awt-dev at openjdk.java.net <mailto:awt-dev at openjdk.java.net>
>> Subject: <AWT Dev> <AWT dev>[9] Review request for JDK-8156460 [macosx] Test case javax/swing/JPopupMenu/6827786/bug6827786.java fails
>>  
>> Hi All,
>>  
>> Please review the regression fix for issue JDK-8156460 <https://bugs.openjdk.java.net/browse/JDK-8156460> which fixes below mentioned test cases.
>> http://cr.openjdk.java.net/~mhalder/8156460/webrev.00/ <http://cr.openjdk.java.net/~mhalder/8156460/webrev.00/>
>>  
>> This fix resolves the following 3 JCK failures and 7 test failures:
>>  
>> JCK tests:
>> https://bugs.openjdk.java.net/browse/JDK-8158621 <https://bugs.openjdk.java.net/browse/JDK-8158621>
>> https://bugs.openjdk.java.net/browse/JDK-8158485 <https://bugs.openjdk.java.net/browse/JDK-8158485>
>> https://bugs.openjdk.java.net/browse/JDK-8158501 <https://bugs.openjdk.java.net/browse/JDK-8158501>
>>  
>> Jtreg tests:
>> https://bugs.openjdk.java.net/browse/JDK-8158389 <https://bugs.openjdk.java.net/browse/JDK-8158389>
>> https://bugs.openjdk.java.net/browse/JDK-8158526 <https://bugs.openjdk.java.net/browse/JDK-8158526>
>> https://bugs.openjdk.java.net/browse/JDK-8158496 <https://bugs.openjdk.java.net/browse/JDK-8158496>
>> https://bugs.openjdk.java.net/browse/JDK-8158362 <https://bugs.openjdk.java.net/browse/JDK-8158362>
>> https://bugs.openjdk.java.net/browse/JDK-8158512 <https://bugs.openjdk.java.net/browse/JDK-8158512>
>> https://bugs.openjdk.java.net/browse/JDK-8156460 <https://bugs.openjdk.java.net/browse/JDK-8156460>
>> https://bugs.openjdk.java.net/browse/JDK-8158377 <https://bugs.openjdk.java.net/browse/JDK-8158377>
>>  
>> Reason of failure:
>>             The modifier value calculation was wrong.
>>  
>> Note that with this fix the test /java/awt/keyboard/AllKeyCode/AllKeyCode.java will fail due to the reason that pressing number (0 to 9) after pressing arrow keys( up, down, left and right) will generate corresponding Numpad keys code for number keys (0 to 9). Whereas if the arrow key are pressed after number keys are pressed then there is no problem. An issue will be created for this issue once this fix is accepted.
>>  
>> Thanks,
>> Manajit
> 

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

From erik.joelsson at oracle.com  Mon Jun 27 08:15:01 2016
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Mon, 27 Jun 2016 10:15:01 +0200
Subject: <AWT Dev> [9] Fix for JDK-8074824: Resolve disabled warnings
 for libawt_xawt
In-Reply-To: <58fd8ac4-4520-4776-8229-a7c510eba6d6@default>
References: <53656bf6-bce8-4444-8c4f-67d7cc93a522@default>
	<58fd8ac4-4520-4776-8229-a7c510eba6d6@default>
Message-ID: <5770E085.3040109@oracle.com>

Hello,

I'm happy with the makefile changes, unless anyone else could come up 
with a solution for any of the remaining warnings.

/Erik

On 2016-06-23 09:09, Ajit Ghaisas wrote:
> Hi,
>
> Bug :
>      https://bugs.openjdk.java.net/browse/JDK-8074824
>      (Resolve disabled warnings for libawt_xawt)
>
> As part of fixing this bug, I have -
>
>      1. Fixed warnings in source code after removing blanket warning suppressions from makefile.
>
>      2. In case the warning fix is not possible, converted blanket warning suppression for this library to suppression of warnings for individual files.
>
>      3. Added comments in makefile for the warning suppression that cannot be fixed.
>
>     One type of gcc warning 'deprecated-declarations' will be fixed separately (as part of JDK-8160146)
>
>
> I have built the changes successfully on all supported platforms.
>
>
> Webrev :
>      http://cr.openjdk.java.net/~aghaisas/8074824/webrev.00/
>
> Request you to review.
>
> Regards,
> Ajit


From dmitry.markov at oracle.com  Mon Jun 27 13:05:26 2016
From: dmitry.markov at oracle.com (dmitry markov)
Date: Mon, 27 Jun 2016 16:05:26 +0300
Subject: <AWT Dev> [9] Review request for 8148984: [macosx] Chinese
 Comma cannot be entered using Pinyin Input Method on OS X
In-Reply-To: <d9cadfcc-1470-32d3-aae0-d1ce133a7b43@oracle.com>
References: <5763EF8D.5010309@oracle.com>
	<d9cadfcc-1470-32d3-aae0-d1ce133a7b43@oracle.com>
Message-ID: <57712496.5010501@oracle.com>

Hello Alex,
Thank you for review.

Can anyone else review the fix, please?

Thanks,
Dmitry
On 23/06/2016 16:55, Alexander Potochkin wrote:
> Hello Dmitry
>
> The fix looks good!
>
> Thanks
> alexp
>
> On 6/17/2016 15:39, dmitry markov wrote:
>> Hello,
>>
>> Could you review a fix for jdk9, please?
>>
>>     bug: https://bugs.openjdk.java.net/browse/JDK-8148984
>>     webrev: http://cr.openjdk.java.net/~dmarkov/8148984/webrev.00/
>>
>> Problem description:
>> 'Latin comma' character is entered in text component instead of the 
>> required 'fullwidth comma' character, when ',' character is pressed 
>> on the keyboard and Pinyin ? Traditional or Simplified IM is enabled, 
>> because KeyEvent is generated instead of InputMethodEvent.
>>
>> Fix:
>> It is necessary to generate InputMethodEvent for the characters from 
>> 'Halfwidth and Fullwidth Forms' Unicode block (U+FF00 - U+FFEF). So 
>> the method isCodePointInUnicodeBlockNeedingIMEvent() in AWTView.m 
>> should be updated.
>>
>> Thanks,
>> Dmitry
>


From artem.ananiev at oracle.com  Mon Jun 27 17:35:45 2016
From: artem.ananiev at oracle.com (Artem Ananiev)
Date: Mon, 27 Jun 2016 20:35:45 +0300
Subject: <AWT Dev> Result: New AWT Group Lead: Sergey Bylokhov
In-Reply-To: <bf5be81e-870c-5288-8ca2-e511d5d236e0@oracle.com>
References: <bf5be81e-870c-5288-8ca2-e511d5d236e0@oracle.com>
Message-ID: <2966f435-5ef4-5f32-4f82-89dc9c37b9b0@oracle.com>


The voting [4] for Sergey Bylokhov (OpenJDK user name: serb) is now 
closed. Results:

Yes: 5
Veto: 0
Abstain: 0

In the original email, a mistake was made: Group Lead nomination must be 
approved by a Simple Majority [5], not a Two-Thirds Majority [3]. 
According to the Bylaws definition of Simple Majority, results above are 
enough to approve the nomination.

[4] http://mail.openjdk.java.net/pipermail/awt-dev/2016-June/011465.html
[5] http://openjdk.java.net/bylaws#simple-majority

Thanks,

Artem

On 6/10/16 6:39 PM, Artem Ananiev wrote:
> Hi, AWT team,
>
> I hereby nominate Sergey Bylokhov (OpenJDK user name: serb) to AWT Group
> Lead [1].
>
> Sergey is a member of Java Client group at Oracle. He has been one of
> the most active contributors to AWT (and other Java client libs: Swing,
> Java2D, JavaFX, Java Sound, Java Beans) last few years and demonstrated
> very deep knowledge of the library, its architecture and implementation
> on various platforms.
>
> Votes are due by June 24, 2016.
>
> Only current AWT group members [2] are eligible to vote on this
> nomination. Votes must be cast in the open by replying to this mailing
> list.
>
> For Two-Thirds Majority voting instructions, see [3]
>
> [1] http://openjdk.java.net/bylaws#group-lead
> [2] http://openjdk.java.net/census#awt
> [3] http://openjdk.java.net/bylaws#two-thirds-majority
>
> Thanks,
>
> Artem

From manajit.halder at oracle.com  Mon Jun 27 17:57:44 2016
From: manajit.halder at oracle.com (Manajit Halder)
Date: Mon, 27 Jun 2016 23:27:44 +0530
Subject: <AWT Dev> <AWT dev>[9] Review request for JDK-7156316: [macosx]
	Ctrl+Space does generate Unknown keychar
Message-ID: <78D4DBD1-9A17-4A95-A148-3DD0D1E4EC88@oracle.com>

Hi All,

Kindly review the fix for JDK9.

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

Webrev: 
http://cr.openjdk.java.net/~mhalder/7156316/webrev.00/ <http://cr.openjdk.java.net/~mhalder/7156316/webrev.00/>

Issue: 
[macosx] Ctrl+Space does generate Unknown keychar

Cause: 
SPACK key value was received as ? ? in function handleKeyEvent and that was correct value, but while sending the value as a character to function nsToJavaChar it was getting passed as 0. The function nsToJavaChar was returning 0 as unichar character for SPACE key as there was no code to handle the situation.
 
Fix: 
An extra parameter was added in handleKeyEvent function indicating SPACE key and was passed to nsToJavaChar method to handle it.

Regards,
Manajit
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20160627/8ef4facc/attachment.html>

From kumar.x.srinivasan at oracle.com  Mon Jun 27 20:19:03 2016
From: kumar.x.srinivasan at oracle.com (Kumar Srinivasan)
Date: Mon, 27 Jun 2016 13:19:03 -0700
Subject: <AWT Dev> [9] RFR: 8022291: Mac OS: Unexpected JavaLaunchHelper
 message displaying
In-Reply-To: <131A833E-A56D-455A-847B-6A2510F2BD5C@oracle.com>
References: <72F99549-04C8-4096-915C-A4F917A6E52E@oracle.com>
	<F737C8BE-E9AC-49EF-B465-33717CB354DA@oracle.com>
	<2e17e072-a124-3bd4-e54e-e47230320fe3@oracle.com>
	<131A833E-A56D-455A-847B-6A2510F2BD5C@oracle.com>
Message-ID: <57718A37.7000700@oracle.com>


I am not an expert in this area, if Sergey is ok with it.
I am fine with it.

Brent ?

Kumar

> Thanks, Sergey.
>
> Can someone from the core-libs launcher group please approve? (looks at Kumar)
>
> -DrD-
>
>> Looks fine.
>>
>> On 22.06.16 1:58, David DeHaven wrote:
>>>> JBS:
>>>> https://bugs.openjdk.java.net/browse/JDK-8022291
>>>>
>>>> Webrev:
>>>> http://cr.openjdk.java.net/~ddehaven/8022291/jdk.0/index.html
>>>>
>>>> This actually turned out to be pretty easy to fix, I eliminated the JavaLaunchHelper class and in place of it stuffed the block it replaced into a NSBlockOperation then changed the performSelectorOnMainThread call to invoke the NSBlockOperation's start message.
>>>>
>>>> I tested against the SWT snippet (Snippet297) that was attached to the original Eclipse bug that triggered the original fix. The SWT tests I could dig up all seemed to work ok.
>>>>
>>>> Original Eclipse bug, used to verify the fix:
>>>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=389486
>>>>
>>>>
>>>> This should be backported to 8u after it bakes in 9 for a bit.
>>>
>>> Minor update:
>>> http://cr.openjdk.java.net/~ddehaven/8022291/jdk.1/
>>>
>>> I put the NSAutoreleasePool back, so it's directly portable to jdk8u.
>>>
>>> -DrD-
>>>
>>
>> -- 
>> Best regards, Sergey.


From brent.christian at oracle.com  Mon Jun 27 21:57:03 2016
From: brent.christian at oracle.com (Brent Christian)
Date: Mon, 27 Jun 2016 14:57:03 -0700
Subject: <AWT Dev> [9] RFR: 8022291: Mac OS: Unexpected JavaLaunchHelper
 message displaying
In-Reply-To: <57718A37.7000700@oracle.com>
References: <72F99549-04C8-4096-915C-A4F917A6E52E@oracle.com>
	<F737C8BE-E9AC-49EF-B465-33717CB354DA@oracle.com>
	<2e17e072-a124-3bd4-e54e-e47230320fe3@oracle.com>
	<131A833E-A56D-455A-847B-6A2510F2BD5C@oracle.com>
	<57718A37.7000700@oracle.com>
Message-ID: <5771A12F.9060205@oracle.com>

I'm not familiar with this area.  The changes looks reasonable enough to me.

-Brent
On 06/27/2016 01:19 PM, Kumar Srinivasan wrote:
>
> I am not an expert in this area, if Sergey is ok with it.
> I am fine with it.
>
> Brent ?
>
> Kumar
>
>> Thanks, Sergey.
>>
>> Can someone from the core-libs launcher group please approve? (looks
>> at Kumar)
>>
>> -DrD-
>>
>>> Looks fine.
>>>
>>> On 22.06.16 1:58, David DeHaven wrote:
>>>>> JBS:
>>>>> https://bugs.openjdk.java.net/browse/JDK-8022291
>>>>>
>>>>> Webrev:
>>>>> http://cr.openjdk.java.net/~ddehaven/8022291/jdk.0/index.html
>>>>>
>>>>> This actually turned out to be pretty easy to fix, I eliminated the
>>>>> JavaLaunchHelper class and in place of it stuffed the block it
>>>>> replaced into a NSBlockOperation then changed the
>>>>> performSelectorOnMainThread call to invoke the NSBlockOperation's
>>>>> start message.
>>>>>
>>>>> I tested against the SWT snippet (Snippet297) that was attached to
>>>>> the original Eclipse bug that triggered the original fix. The SWT
>>>>> tests I could dig up all seemed to work ok.
>>>>>
>>>>> Original Eclipse bug, used to verify the fix:
>>>>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=389486
>>>>>
>>>>>
>>>>> This should be backported to 8u after it bakes in 9 for a bit.
>>>>
>>>> Minor update:
>>>> http://cr.openjdk.java.net/~ddehaven/8022291/jdk.1/
>>>>
>>>> I put the NSAutoreleasePool back, so it's directly portable to jdk8u.
>>>>
>>>> -DrD-
>>>>
>>>
>>> --
>>> Best regards, Sergey.
>


From kumar.eng84 at gmail.com  Mon Jun 27 23:49:16 2016
From: kumar.eng84 at gmail.com (kumar rohit)
Date: Mon, 27 Jun 2016 16:49:16 -0700
Subject: <AWT Dev> Card layout in Java swing
Message-ID: <CANrveP8U2SD=TCpiPxXhOE4JabVKamH5RL0B5pY4QXLqDq0-fA@mail.gmail.com>

Hello I have java quiz based project, so how can I design it? I press Next
button and the next question with options and answers will be displayed?

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

From rajeev.chamyal at oracle.com  Tue Jun 28 07:30:10 2016
From: rajeev.chamyal at oracle.com (Rajeev Chamyal)
Date: Tue, 28 Jun 2016 00:30:10 -0700 (PDT)
Subject: <AWT Dev> Review request for 8151588: Press the button first
 two times, the 'First' and 'Next' didn't show
In-Reply-To: <fb0ad96a-e10e-51cb-eb4a-4bbb91403443@oracle.com>
References: <1473e148-0210-45e2-88dc-d77cd4106170@default>
	<0509e7a6-4c5e-4c4e-b45c-27a9e11cb3d7@default>
	<fb0ad96a-e10e-51cb-eb4a-4bbb91403443@oracle.com>
Message-ID: <d3be032f-302d-47af-aae8-9ed9aa9637d0@default>

Looks good to me.

 

Regards,

Rajeev Chamyal

 

From: Semyon Sadetsky 
Sent: 23 June 2016 12:07
To: Ambarish Rapte; Prasanta Sadhukhan; Sergey Bylokhov; Alexander Scherbatiy; awt-dev at openjdk.java.net
Subject: Re: <AWT Dev> Review request for 8151588: Press the button first two times, the 'First' and 'Next' didn't show

 

Looks good to me.

--Semyon

 

On 6/23/2016 8:44 AM, Ambarish Rapte wrote:

Hi,

Gentle reminder. Please review.

 

Regards,

Ambaris

 

 

From: Ambarish Rapte 
Sent: Wednesday, June 15, 2016 8:40 PM
To: Prasanta Sadhukhan; Semyon Sadetsky; Sergey Bylokhov; Alexander Scherbatiy; HYPERLINK "mailto:awt-dev at openjdk.java.net"awt-dev at openjdk.java.net
Subject: <AWT Dev> Review request for 8151588: Press the button first two times, the 'First' and 'Next' didn't show

 

Hi,

Please review this fix for JDK9,

Webrev: http://cr.openjdk.java.net/~arapte/8151588/webrev.00/

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

 

 

Issue:

When Text Area is not in focus, If select or append is called on Text Area and if the desired text is not in visible area

then the Text Area should auto scroll to make the desired text visible.

But this behavior was broken due to fix of,

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

Patch(1): http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/b9f91de8ae43

 

 

Fix:

Issue JDK-6180449 is also fixed by fix of,

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

http://hg.openjdk.java.net/jdk9/client/jdk/rev/4a1e160a12c3

 

Hence reverting the fix Patch(1) for JDK-6180449 to fix this regression.

 

 

Verification:

All JCK tests for Text Area pass, no other test fails due to this change.

The newly added test with this fix, fails without the patch and passes after merging the patch.

 

 

Regards,

Ambarish

 

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

From manajit.halder at oracle.com  Tue Jun 28 08:14:00 2016
From: manajit.halder at oracle.com (Manajit Halder)
Date: Tue, 28 Jun 2016 13:44:00 +0530
Subject: <AWT Dev> <AWT dev>[9] Review request for JDK-8156460 [macosx]
	Test case javax/swing/JPopupMenu/6827786/bug6827786.java fails
In-Reply-To: <3F293A13-C767-451D-A07E-87A84A3C0D6D@oracle.com>
References: <df3ee77f-7d04-4b26-b15a-554d7288c96f@default>
	<03432BF4-9B58-466A-984B-9B81297411CC@oracle.com>
	<3F293A13-C767-451D-A07E-87A84A3C0D6D@oracle.com>
Message-ID: <6A67C60C-A2C0-4EDA-860C-A9790804376B@oracle.com>

Hi All,

Gentle remainder. Please review the changes.

Thanks,
Manajit

> On 25-Jun-2016, at 7:46 pm, Manajit Halder <manajit.halder at oracle.com> wrote:
> 
> Hi All,
> 
> The code was changed on the same lines in one file after the first review was generated. A new review is generated after taking an update of the code.
> Fix wise the webrev.00 and webrev.01 are same.
> 
> Please review webrev.01
> http://cr.openjdk.java.net/~mhalder/8156460/webrev.01/ <http://cr.openjdk.java.net/~mhalder/8156460/webrev.01/>
> 
> Also note that along with the previous 10 issues as mentioned in the first review mail below another two new issues created 2 days ago also gets resolved by this fix.
> The 2 new issues are:
> 
> https://bugs.openjdk.java.net/browse/JDK-8160144 <https://bugs.openjdk.java.net/browse/JDK-8160144>
> https://bugs.openjdk.java.net/browse/JDK-8160145 <https://bugs.openjdk.java.net/browse/JDK-8160145>
> 
> Thank you Avik for your comment. The lines were moved up to maintain the order of modifier values in increasing order.
> 
> Thanks,
> Manajit
> 
> 
>> On 21-Jun-2016, at 12:10 pm, Avik Niyogi <avik.niyogi at oracle.com <mailto:avik.niyogi at oracle.com>> wrote:
>> 
>> Hi,
>> The fix looks good to me. 
>> A small query though, line 281 - 290 is required at that position, looks like it was moved.
>> 
>> With Regards,
>> Avik Niyogi
>>> From: Manajit Halder 
>>> Sent: Monday, June 20, 2016 1:56 AM
>>> To: Sergey Bylokhov; Semyon Sadetsky
>>> Cc: awt-dev at openjdk.java.net <mailto:awt-dev at openjdk.java.net>
>>> Subject: <AWT Dev> <AWT dev>[9] Review request for JDK-8156460 [macosx] Test case javax/swing/JPopupMenu/6827786/bug6827786.java fails
>>>  
>>> Hi All,
>>>  
>>> Please review the regression fix for issue JDK-8156460 <https://bugs.openjdk.java.net/browse/JDK-8156460> which fixes below mentioned test cases.
>>> http://cr.openjdk.java.net/~mhalder/8156460/webrev.00/ <http://cr.openjdk.java.net/~mhalder/8156460/webrev.00/>
>>>  
>>> This fix resolves the following 3 JCK failures and 7 test failures:
>>>  
>>> JCK tests:
>>> https://bugs.openjdk.java.net/browse/JDK-8158621 <https://bugs.openjdk.java.net/browse/JDK-8158621>
>>> https://bugs.openjdk.java.net/browse/JDK-8158485 <https://bugs.openjdk.java.net/browse/JDK-8158485>
>>> https://bugs.openjdk.java.net/browse/JDK-8158501 <https://bugs.openjdk.java.net/browse/JDK-8158501>
>>>  
>>> Jtreg tests:
>>> https://bugs.openjdk.java.net/browse/JDK-8158389 <https://bugs.openjdk.java.net/browse/JDK-8158389>
>>> https://bugs.openjdk.java.net/browse/JDK-8158526 <https://bugs.openjdk.java.net/browse/JDK-8158526>
>>> https://bugs.openjdk.java.net/browse/JDK-8158496 <https://bugs.openjdk.java.net/browse/JDK-8158496>
>>> https://bugs.openjdk.java.net/browse/JDK-8158362 <https://bugs.openjdk.java.net/browse/JDK-8158362>
>>> https://bugs.openjdk.java.net/browse/JDK-8158512 <https://bugs.openjdk.java.net/browse/JDK-8158512>
>>> https://bugs.openjdk.java.net/browse/JDK-8156460 <https://bugs.openjdk.java.net/browse/JDK-8156460>
>>> https://bugs.openjdk.java.net/browse/JDK-8158377 <https://bugs.openjdk.java.net/browse/JDK-8158377>
>>>  
>>> Reason of failure:
>>>             The modifier value calculation was wrong.
>>>  
>>> Note that with this fix the test /java/awt/keyboard/AllKeyCode/AllKeyCode.java will fail due to the reason that pressing number (0 to 9) after pressing arrow keys( up, down, left and right) will generate corresponding Numpad keys code for number keys (0 to 9). Whereas if the arrow key are pressed after number keys are pressed then there is no problem. An issue will be created for this issue once this fix is accepted.
>>>  
>>> Thanks,
>>> Manajit
>> 
> 

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

From neugens at redhat.com  Wed Jun 29 10:40:57 2016
From: neugens at redhat.com (Mario Torre)
Date: Wed, 29 Jun 2016 12:40:57 +0200
Subject: <AWT Dev> Taking screenshots on x11 composite desktop produce
 wrong result
In-Reply-To: <CAJwKKmYXarJo_CCSOQKoK4ofY7XRAkGq+fzfP33Vk05STWYffg@mail.gmail.com>
References: <CAJwKKmZ__GVT6aVRA+gNJ=gYnwNAmkG18BLmju2A05Vrkr+QrQ@mail.gmail.com>
	<56D713BB.5030305@oracle.com>
	<CAJwKKmaTc2Oe9E3y57y5iG1keqA9jU_NJCy1yQEe0GTG3QXokg@mail.gmail.com>
	<CAJwKKmb9USyRxSmEw_U2ur6cAAkmPJDBmhQN=4EV0u9wkqw5hA@mail.gmail.com>
	<CAJwKKmYDYGcgdtZLTaimE=8Y_PDdB22dB1C+58CfXDnA-t6n+w@mail.gmail.com>
	<5704EA02.1090500@oracle.com>
	<CAJwKKmaxvNMTfSrz1Tk0ChMC8ZcRWkRXbo9ZU1dKbwerKb_ymw@mail.gmail.com>
	<5704FAD9.50805@oracle.com>
	<CAGUMyaSERCsb2KrumOGxLALHqgWM=uT=FrrKSBxPFM-3WAR3VA@mail.gmail.com>
	<a33b671c-f478-f430-431e-8fc5e589c5d9@oracle.com>
	<CAGUMyaROjZ33O2yRtvdRWf9UBG7r7823A9me6rh-5zEmt7bGWQ@mail.gmail.com>
	<5594e799-8935-f079-2fe3-60b5079eab4a@oracle.com>
	<131c0e73-8fc9-2db2-b4bf-b110d4fcdbeb@oracle.com>
	<b7d3a594-9fca-ad39-71c8-eed46acbc138@oracle.com>
	<CAJwKKmb7CpgcOQdLviOm3SxtV37K7YaotZZpDpG6w3Ryc1Lzug@mail.gmail.com>
	<d9e526c0-b7ad-45af-df67-23407490b96c@oracle.com>
	<CAJwKKmYXarJo_CCSOQKoK4ofY7XRAkGq+fzfP33Vk05STWYffg@mail.gmail.com>
Message-ID: <CAJwKKmZqJEjaW9X79YjXURyaNbb2pMP-br6BwWGjOMnk91r0iQ@mail.gmail.com>

Ping?

Cheers,
Mario

On Thu, Jun 16, 2016 at 6:47 PM, Mario Torre <neugens at redhat.com> wrote:
> On Wed, Jun 1, 2016 at 1:52 PM, Semyon Sadetsky
> <semyon.sadetsky at oracle.com> wrote:
>>
>>
>> On 6/1/2016 2:39 PM, Mario Torre wrote:
>>>
>>> On Wed, Jun 1, 2016 at 1:23 PM, Semyon Sadetsky
>>> <semyon.sadetsky at oracle.com> wrote:
>>>>
>>>> I ran JPRT build. It seems that the build server does not have the
>>>> requested
>>>> header:
>>>>
>>>>
>>>> /opt/jprt/T/P1/102200.ssadetsk/s/jdk/src/java.desktop/unix/native/libawt_xawt/awt/awt_Robot.c:40:39:
>>>> fatal error: X11/extensions/Xcomposite.h: No such file or directory
>>>>   #include <X11/extensions/Xcomposite.h>
>>>>
>>>> someone need to install Xcomposite library there
>>>>
>>> Should this be made optional?
>>>
>>> I can do some dlsym hack if necessary (I would prefer to avoid that
>>> though).
>>
>> Apparently dlsym is the shortest way to fix that issue and you don't need to
>> modify the makefile in that case.
>
> Well, to be honest, I think Xcomposite should just be a requirement, I
> believe all the systems that OpenJDK 9 targets as "supported" have
> that library, it just needs to be installed.
>
> Anyway, this is the patch with the dl-stuff hacks:
>
> http://cr.openjdk.java.net/~neugens/8150954/webrev.06/
>
> The only question I have is where to unload the library, I gave a look
> at what the XToolkit code does with GTK, and it seems that it's just
> never unloaded (there's a method to unload the library, but looks like
> it's never used anywhere, except, of course, if some functions fail to
> load in the first place, which is what I also do here). I think this
> is not a real problem though, so rather than making the whole code a
> lot more complex I would keep it that way, YMMV.
>
> I believe I need again two approvals now.
>
> Cheers,
> Mario

From alexandr.scherbatiy at oracle.com  Wed Jun 29 11:27:12 2016
From: alexandr.scherbatiy at oracle.com (Alexandr Scherbatiy)
Date: Wed, 29 Jun 2016 14:27:12 +0300
Subject: <AWT Dev> <AWT dev>[9] Review request for 8117886: There is no
 tooltip while moving the mouse on the tray icon.
In-Reply-To: <293d6978-fb6c-9307-a53e-17e0bb9b8a37@oracle.com>
References: <293d6978-fb6c-9307-a53e-17e0bb9b8a37@oracle.com>
Message-ID: <ba3f1434-79a6-e0a9-34a2-65ce503fdc5c@oracle.com>

On 6/14/2016 5:23 PM, Semyon Sadetsky wrote:
> Hello,
>
> Please review fix for JDK9:
>
> bug: https://bugs.openjdk.java.net/browse/JDK-8117886
>
> webrev: http://cr.openjdk.java.net/~ssadetsky/8117886/webrev.00/
>
> gnome3 DE got a new DE notifications bar, so the tooltips for tray 
> icons have gone.
>
> Just note about that in the TrayIcon's javadoc.
    - "this is platform dependent" - may be  "this behavior is 
platform-dependent" would be slightly better
    - I am not a native speaker. For me the the "Tooltip may not be 
visible" sounds better than "Tooltip may be not visible"
    - line:204 "not" is repeated twice

   Thanks,
   Alexandr.
>
> --Semyon
>


From java at obendig.de  Wed Jun 29 13:54:17 2016
From: java at obendig.de (Oliver Bendig)
Date: Wed, 29 Jun 2016 15:54:17 +0200 (CEST)
Subject: <AWT Dev> Review request for 4908075: Press shift and another
 key using robot does not trigger events properly
In-Reply-To: <4cc52daf-b82a-30d2-fc84-e9518e0d3452@oracle.com>
References: <2040975450.33317.1466519981519.JavaMail.open-xchange@app06.ox.hosteurope.de>
	<4cc52daf-b82a-30d2-fc84-e9518e0d3452@oracle.com>
Message-ID: <858355732.51186.1467208457259.JavaMail.open-xchange@app07.ox.hosteurope.de>

Hi,

here is a test for this. I updated the webrev.
Webrev: http://cr.openjdk.java.net/~simonis/webrevs/2016/4908075.v2/

This test is for windows only as other OS might catch some of the tested
keyboard events before the are passed to the canvas.
I hope this is ok as the problem itself occurs on windows only.

Regards, Oliver


> Sergey Bylokhov <Sergey.Bylokhov at oracle.com> hat am 21. Juni 2016 um 21:53
> geschrieben:
> 
> Hi, Oliver.
> Is it possible to write a test for this fix?
> 
> On 21.06.16 17:39, Oliver Bendig wrote:
> > Hi,
> >
> > can you please review the following fix:
> >
> > Webrev: http://cr.openjdk.java.net/~simonis/webrevs/2016/4908075/
> > BugID: https://bugs.openjdk.java.net/browse/JDK-4908075
> >
> > Following some mre details: we are facing issues when trying to send
> > keyboard events via awt robot. When trying to send a keyboard event from
> > the extended keys with the SHIFT-key pressed, this doesn't send a
> > correct key combination. Instead, the Shift-Key is released before the
> > second keycode is sent. This makes it impossible to send combinations
> > like e.g. shift+delete.
> >
> > The bug id 4908075 for this issue is rather old. The suggested idea to
> > switch to SendInput() instead of keybd_event() was delayed at that time
> > because of missing support in Win98. For testing purposes, I implemented
> > SendInput instead of keybd_event, but the issue stays the same. The
> > problem seems to be caused by the missing KEYEVENTF_EXTENDEDKEY flag
> > when calling keybd_event or SendInput. Bug id 8155742 introduces this
> > flag for other reason for VK_ALT_GRAPH. If this is enhanced to cover the
> > extended keys that were introduced as enhancement of the old 84 key AT
> > keyboard, the correct key events are sent.
> >
> > The bug 4908075 was closed as "Won't fix" but I think the fix would be
> > rather simple. Should I reopen 4908075 or is it better to create a new
> > bug for this issue.
> >
> > Thank you and best regards,
> > Oliver
> >
> 
> -- 
> Best regards, Sergey.

>

From alexandr.scherbatiy at oracle.com  Wed Jun 29 15:50:07 2016
From: alexandr.scherbatiy at oracle.com (Alexandr Scherbatiy)
Date: Wed, 29 Jun 2016 18:50:07 +0300
Subject: <AWT Dev> Review request for 8143064 Icons are not properly
 rendered with Windows L&F on HiDPI display
In-Reply-To: <5649FF2B.2080607@oracle.com>
References: <5649EBAF.2040308@oracle.com> <5649FF2B.2080607@oracle.com>
Message-ID: <0d0e61e6-6f80-5caf-5330-10e6ed0be7cf@oracle.com>


Hello,

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

The MultiResolutionImage image is used for the icons painting.

Thanks,
Alexandr.

On 11/16/2015 7:07 PM, Sergey Bylokhov wrote:
> Hi, Alexander.
>  109         AffineTransform tx = ((Graphics2D) g).getTransform();
>  110         int sw = tx.isIdentity() ? w : (int) Math.round(w * 
> tx.getScaleX());
>  111         int sh = tx.isIdentity() ? h : (int) Math.round(h * 
> tx.getScaleY());
>
> I think that it is not necessary that !isIdentity transform return 
> non-zero value from the getScaleX/Y method. I recall that exactly the 
> same bug on OSX was fixed via MultiResolutionCachedImage, why we 
> cannot do the same here?
>
> On 16.11.15 17:43, Alexander Scherbatiy wrote:
>> Could you review the fix:
>>    bug: https://bugs.openjdk.java.net/browse/JDK-8143064
>>    webrev: http://cr.openjdk.java.net/~alexsch/8143064/webrev.00
>>
>>    Icon image sizes are scaled in sun.swing.CachedPainter.
>>
>>    Thanks,
>>    Alexandr.
>>
>
>


From semyon.sadetsky at oracle.com  Wed Jun 29 16:55:28 2016
From: semyon.sadetsky at oracle.com (Semyon Sadetsky)
Date: Wed, 29 Jun 2016 19:55:28 +0300
Subject: <AWT Dev> <AWT dev>[9] Review request for 8117886: There is no
 tooltip while moving the mouse on the tray icon.
In-Reply-To: <ba3f1434-79a6-e0a9-34a2-65ce503fdc5c@oracle.com>
References: <293d6978-fb6c-9307-a53e-17e0bb9b8a37@oracle.com>
	<ba3f1434-79a6-e0a9-34a2-65ce503fdc5c@oracle.com>
Message-ID: <4c215f11-0cdd-ed1c-c4cc-87c1dd4b2b6e@oracle.com>

Hi Alexander,

On 6/29/2016 2:27 PM, Alexandr Scherbatiy wrote:
> On 6/14/2016 5:23 PM, Semyon Sadetsky wrote:
>> Hello,
>>
>> Please review fix for JDK9:
>>
>> bug: https://bugs.openjdk.java.net/browse/JDK-8117886
>>
>> webrev: http://cr.openjdk.java.net/~ssadetsky/8117886/webrev.00/
>>
>> gnome3 DE got a new DE notifications bar, so the tooltips for tray 
>> icons have gone.
>>
>> Just note about that in the TrayIcon's javadoc.
>    - "this is platform dependent" - may be  "this behavior is 
> platform-dependent" would be slightly better
ok
>    - I am not a native speaker. For me the the "Tooltip may not be 
> visible" sounds better than "Tooltip may be not visible"
"Tooltip may not be visible" sounds to me as "Tooltip cannot not be 
visible", while "Tooltip may be not visible" sounds like "Tooltip may be 
invisible".
So, for this context the original version seems more correct to me (also 
not 100% sure).
>    - line:204 "not" is repeated twice
ok.

Please look at the updated version: 
http://cr.openjdk.java.net/~ssadetsky/8117886/webrev.01/

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


From anton.tarasov at jetbrains.com  Wed Jun 29 18:04:16 2016
From: anton.tarasov at jetbrains.com (Anton Tarasov)
Date: Wed, 29 Jun 2016 21:04:16 +0300
Subject: <AWT Dev> Review request for 8160570: [mac] modal dialog can skip
	the activation/focus events
Message-ID: <94F97299-9503-4D82-93AA-0E8C40AE7524@jetbrains.com>

Hello,

Please review the fix:

bug: https://bugs.openjdk.java.net/browse/JDK-8160570
webrev: http://cr.openjdk.java.net/~ant/JDK-8160570/webrev.0 <http://cr.openjdk.java.net/~ant/JDK-8160570/webrev.0>

The problem is that a modal dialog can skip the activation/focus events on OSX.
The fix is to cache the focusability state of the Window peer earlier, in its ctor.
Please find more details in JIRA.

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

From alexandr.scherbatiy at oracle.com  Wed Jun 29 18:47:57 2016
From: alexandr.scherbatiy at oracle.com (Alexandr Scherbatiy)
Date: Wed, 29 Jun 2016 21:47:57 +0300
Subject: <AWT Dev> <AWT dev>[9] Review request for 8117886: There is no
 tooltip while moving the mouse on the tray icon.
In-Reply-To: <4c215f11-0cdd-ed1c-c4cc-87c1dd4b2b6e@oracle.com>
References: <293d6978-fb6c-9307-a53e-17e0bb9b8a37@oracle.com>
	<ba3f1434-79a6-e0a9-34a2-65ce503fdc5c@oracle.com>
	<4c215f11-0cdd-ed1c-c4cc-87c1dd4b2b6e@oracle.com>
Message-ID: <47fb8c41-4cd0-7299-3ec2-146d70c42351@oracle.com>

On 6/29/2016 7:55 PM, Semyon Sadetsky wrote:
> Hi Alexander,
>
> On 6/29/2016 2:27 PM, Alexandr Scherbatiy wrote:
>> On 6/14/2016 5:23 PM, Semyon Sadetsky wrote:
>>> Hello,
>>>
>>> Please review fix for JDK9:
>>>
>>> bug: https://bugs.openjdk.java.net/browse/JDK-8117886
>>>
>>> webrev: http://cr.openjdk.java.net/~ssadetsky/8117886/webrev.00/
>>>
>>> gnome3 DE got a new DE notifications bar, so the tooltips for tray 
>>> icons have gone.
>>>
>>> Just note about that in the TrayIcon's javadoc.
>>    - "this is platform dependent" - may be  "this behavior is 
>> platform-dependent" would be slightly better
> ok
>>    - I am not a native speaker. For me the the "Tooltip may not be 
>> visible" sounds better than "Tooltip may be not visible"
> "Tooltip may not be visible" sounds to me as "Tooltip cannot not be 
> visible", while "Tooltip may be not visible" sounds like "Tooltip may 
> be invisible".
> So, for this context the original version seems more correct to me 
> (also not 100% sure).
>>    - line:204 "not" is repeated twice
> ok.
>
> Please look at the updated version: 
> http://cr.openjdk.java.net/~ssadetsky/8117886/webrev.01/

    The fix looks good to me.

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


From alexandr.scherbatiy at oracle.com  Wed Jun 29 18:55:15 2016
From: alexandr.scherbatiy at oracle.com (Alexandr Scherbatiy)
Date: Wed, 29 Jun 2016 21:55:15 +0300
Subject: <AWT Dev> <AWT dev>[9] Review request for JDK-8156460 [macosx]
 Test case javax/swing/JPopupMenu/6827786/bug6827786.java fails
In-Reply-To: <6A67C60C-A2C0-4EDA-860C-A9790804376B@oracle.com>
References: <df3ee77f-7d04-4b26-b15a-554d7288c96f@default>
	<03432BF4-9B58-466A-984B-9B81297411CC@oracle.com>
	<3F293A13-C767-451D-A07E-87A84A3C0D6D@oracle.com>
	<6A67C60C-A2C0-4EDA-860C-A9790804376B@oracle.com>
Message-ID: <671903c6-4f3d-b9a3-f168-347dede495fa@oracle.com>

On 6/28/2016 11:14 AM, Manajit Halder wrote:
> Hi All,
>
> Gentle remainder. Please review the changes.
    It is better to use "if (leftAltKeyPressed)" instead of "if 
(leftAltKeyPressed == YES)" and "if (!altGRPressed)" instead of "if 
(altGRPressed == NO)".

   Thanks,
   Alexandr.
>
> Thanks,
> Manajit
>
>> On 25-Jun-2016, at 7:46 pm, Manajit Halder <manajit.halder at oracle.com 
>> <mailto:manajit.halder at oracle.com>> wrote:
>>
>> Hi All,
>>
>> The code was changed on the same lines in one file after the first 
>> review was generated. A new review is generated after taking an 
>> update of the code.
>> Fix wise the webrev.00 and webrev.01 are same.
>>
>> Please review webrev.01
>> http://cr.openjdk.java.net/~mhalder/8156460/webrev.01/ 
>> <http://cr.openjdk.java.net/%7Emhalder/8156460/webrev.01/>
>>
>> Also note that along with the previous 10 issues as mentioned in the 
>> first review mail below another two new issues created 2 days ago 
>> also gets resolved by this fix.
>> The 2 new issues are:
>>
>> https://bugs.openjdk.java.net/browse/JDK-8160144
>> https://bugs.openjdk.java.net/browse/JDK-8160145
>>
>> Thank you Avik for your comment. The lines were moved up to maintain 
>> the order of modifier values in increasing order.
>>
>> Thanks,
>> Manajit
>>
>>
>>> On 21-Jun-2016, at 12:10 pm, Avik Niyogi <avik.niyogi at oracle.com 
>>> <mailto:avik.niyogi at oracle.com>> wrote:
>>>
>>> Hi,
>>> The fix looks good to me.
>>> A small query though, line 281 - 290 is required at that position, 
>>> looks like it was moved.
>>>
>>> With Regards,
>>> Avik Niyogi
>>>> *From:*Manajit Halder
>>>> *Sent:*Monday, June 20, 2016 1:56 AM
>>>> *To:*Sergey Bylokhov; Semyon Sadetsky
>>>> *Cc:*awt-dev at openjdk.java.net <mailto:awt-dev at openjdk.java.net>
>>>> *Subject:*<AWT Dev> <AWT dev>[9] Review request for JDK-8156460 
>>>> [macosx] Test case javax/swing/JPopupMenu/6827786/bug6827786.java fails
>>>> Hi All,
>>>> Please review the regression fix for issue JDK-8156460 
>>>> <https://bugs.openjdk.java.net/browse/JDK-8156460> which fixes 
>>>> below mentioned test cases.
>>>> http://cr.openjdk.java.net/~mhalder/8156460/webrev.00/ 
>>>> <http://cr.openjdk.java.net/%7Emhalder/8156460/webrev.00/>
>>>> This fix resolves the following 3 JCK failures and 7 test failures:
>>>> JCK tests:
>>>> https://bugs.openjdk.java.net/browse/JDK-8158621
>>>> https://bugs.openjdk.java.net/browse/JDK-8158485
>>>> https://bugs.openjdk.java.net/browse/JDK-8158501
>>>> Jtreg tests:
>>>> https://bugs.openjdk.java.net/browse/JDK-8158389
>>>> https://bugs.openjdk.java.net/browse/JDK-8158526
>>>> https://bugs.openjdk.java.net/browse/JDK-8158496
>>>> https://bugs.openjdk.java.net/browse/JDK-8158362
>>>> https://bugs.openjdk.java.net/browse/JDK-8158512
>>>> https://bugs.openjdk.java.net/browse/JDK-8156460
>>>> https://bugs.openjdk.java.net/browse/JDK-8158377
>>>> Reason of failure:
>>>> The modifier value calculation was wrong.
>>>> Note that with this fix the 
>>>> test /java/awt/keyboard/AllKeyCode/AllKeyCode.java will fail due to 
>>>> the reason that pressing number (0 to 9) after pressing arrow keys( 
>>>> up, down, left and right) will generate corresponding Numpad keys 
>>>> code for number keys (0 to 9). Whereas if the arrow key are pressed 
>>>> after number keys are pressed then there is no problem. An issue 
>>>> will be created for this issue once this fix is accepted.
>>>> Thanks,
>>>> Manajit
>>>
>>
>

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

From semyon.sadetsky at oracle.com  Thu Jun 30 08:38:53 2016
From: semyon.sadetsky at oracle.com (Semyon Sadetsky)
Date: Thu, 30 Jun 2016 11:38:53 +0300
Subject: <AWT Dev> Review request for 8143064 Icons are not properly
 rendered with Windows L&F on HiDPI display
In-Reply-To: <0d0e61e6-6f80-5caf-5330-10e6ed0be7cf@oracle.com>
References: <5649EBAF.2040308@oracle.com> <5649FF2B.2080607@oracle.com>
	<0d0e61e6-6f80-5caf-5330-10e6ed0be7cf@oracle.com>
Message-ID: <7e2fec3e-28c7-03c0-0771-7539df02c38a@oracle.com>

Hi Alexander,

I have added printout after the line 679 of the XPStyle.java:

676 ThemeReader.paintBackground(SunWritableRaster.stealData(dbi, 0),
677                                        part.getControlName(c), 
part.getValue(),
678                                        State.getValue(part, state),
679                                        0, 0, w, h, w);

-->> System.out.println(w + " " + h + " " + part.getControlName(c) + " " 
+ part.getValue() + " " + State.getValue(part, state));

And it prints the same lines constantly when I repeatedly focus the test 
window without resizing it.

It seems to me that the image caching doesn't work and the image is 
reconstructed each time from the native theme.

Yet another question: why not use the actual scaling factor for the 
resolution variant instead of fixed 2X?

--Semyon


On 6/29/2016 6:50 PM, Alexandr Scherbatiy wrote:
>
> Hello,
>
> Could you review the updated fix:
>   http://cr.openjdk.java.net/~alexsch/8143064/webrev.01
>
> The MultiResolutionImage image is used for the icons painting.
>
> Thanks,
> Alexandr.
>
> On 11/16/2015 7:07 PM, Sergey Bylokhov wrote:
>> Hi, Alexander.
>>  109         AffineTransform tx = ((Graphics2D) g).getTransform();
>>  110         int sw = tx.isIdentity() ? w : (int) Math.round(w * 
>> tx.getScaleX());
>>  111         int sh = tx.isIdentity() ? h : (int) Math.round(h * 
>> tx.getScaleY());
>>
>> I think that it is not necessary that !isIdentity transform return 
>> non-zero value from the getScaleX/Y method. I recall that exactly the 
>> same bug on OSX was fixed via MultiResolutionCachedImage, why we 
>> cannot do the same here?
>>
>> On 16.11.15 17:43, Alexander Scherbatiy wrote:
>>> Could you review the fix:
>>>    bug: https://bugs.openjdk.java.net/browse/JDK-8143064
>>>    webrev: http://cr.openjdk.java.net/~alexsch/8143064/webrev.00
>>>
>>>    Icon image sizes are scaled in sun.swing.CachedPainter.
>>>
>>>    Thanks,
>>>    Alexandr.
>>>
>>
>>
>


From Sergey.Bylokhov at oracle.com  Thu Jun 30 11:26:05 2016
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Thu, 30 Jun 2016 14:26:05 +0300
Subject: <AWT Dev> Review Request: JDK-8158478 : X11 keysym XK_topt maps
 to the wrong Unicode character
In-Reply-To: <2b335df9-711a-44c9-96e6-dc21cbaa02ab@default>
References: <01958dab-24a1-457d-9e44-07d8b1d9f71a@default>
	<2b335df9-711a-44c9-96e6-dc21cbaa02ab@default>
Message-ID: <90e3bac3-3c3a-97e4-7573-977cc48aadd9@oracle.com>

looks fine

On 16.06.16 8:58, Prem Balakrishnan wrote:
> Reminder
>
>
>
> *From:*Prem Balakrishnan
> *Sent:* Monday, June 06, 2016 3:50 PM
> *To:* Sergey Bylokhov; Semyon Sadetsky; Ambarish Rapte;
> awt-dev at openjdk.java.net
> *Subject:* Review Request: JDK-8158478 : X11 keysym XK_topt maps to the
> wrong Unicode character
>
>
>
> Hi,
>
> Please review fix for JDK9,
>
>
>
> *Bug:* https://bugs.openjdk.java.net/browse/JDK-8158478
>
>
>
> *Webrev:* http://cr.openjdk.java.net/~pkbalakr/8158478/webrev.00/
>
>
>
>
>
> *Issue:*
>
> X11 keysym XK_topt maps to the wrong Unicode character.
>
>
>
>
>
> *Cause:*
>
> XK_topt  is set to Display the Symbol  ? ( U+242C un defined)
>
>
>
> *Fix:*
>
> XK_topt  is set to Displays the Symbol ? (U+252C: BOX DRAWINGS LIGHT
> DOWN AND HORIZONTAL)
>
>
>
> Thanks,
>
> Prem
>
>
>


-- 
Best regards, Sergey.

From mikhail.cherkasov at oracle.com  Thu Jun 30 13:01:13 2016
From: mikhail.cherkasov at oracle.com (mikhail cherkasov)
Date: Thu, 30 Jun 2016 16:01:13 +0300
Subject: <AWT Dev> [9] Review request for JDK-8160650: Couple awt and swing
 tests have wrong require jtreg arguments
Message-ID: <57751819.50404@oracle.com>

Hi all,

jbs: https://bugs.openjdk.java.net/browse/JDK-8160650
webrev:http://cr.openjdk.java.net/~mcherkas/8160650/9/webrev/

Couple awt and swing tests have wrong require jtreg arguments,
the following tests should use "os.family" instead of "os.name":

javax/swing/LookAndFeel/8145547/DemandGTK.java: @requires (os.name == 
"linux" | os.name == "solaris")
java/awt/TextArea/TextAreaCaretVisibilityTest/bug7129742.java: * 
@requires (os.family == "linux" | os.name == "solaris")
java/awt/WMSpecificTests/Mutter/MutterMaximizeTest.java: @requires 
(os.name == "linux" | os.name == "solaris")
java/awt/WMSpecificTests/Metacity/FullscreenDialogModality.java: * 
@requires (os.name == "linux" | os.name == "solaris")

see jtreg doc: http://openjdk.java.net/jtreg/tag-spec.html#requires_names

Thanks,
Mikhail.

From semyon.sadetsky at oracle.com  Thu Jun 30 14:38:57 2016
From: semyon.sadetsky at oracle.com (Semyon Sadetsky)
Date: Thu, 30 Jun 2016 17:38:57 +0300
Subject: <AWT Dev> [9] Review request for 8160623: [PIT] Exception running
 java/awt/event/KeyEvent/KeyChar/KeyCharTest.java
Message-ID: <2b60aa5c-8f85-618a-7aa0-cbdacca840c7@oracle.com>

Hello,

Please review fix for JDK9:

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

webrev: http://cr.openjdk.java.net/~ssadetsky/8160623/webrev.00/

This a regression from JDK-8139189. The wchar array may contain all 
zeroes for some known keys (likely for Delete key only) and it should 
not be interpreted as  CHAR_UNDEFINED.

--Semyon



From yuri.nesterenko at oracle.com  Thu Jun 30 14:59:54 2016
From: yuri.nesterenko at oracle.com (Yuri Nesterenko)
Date: Thu, 30 Jun 2016 17:59:54 +0300
Subject: <AWT Dev> [9] Review request for 8160623: [PIT] Exception
 running java/awt/event/KeyEvent/KeyChar/KeyCharTest.java
In-Reply-To: <2b60aa5c-8f85-618a-7aa0-cbdacca840c7@oracle.com>
References: <2b60aa5c-8f85-618a-7aa0-cbdacca840c7@oracle.com>
Message-ID: <577533EA.30108@oracle.com>

Have it built and tested on a couple of locales: all seems working OK.
Fine with me!

-yan

On 06/30/2016 05:38 PM, Semyon Sadetsky wrote:
> Hello,
>
> Please review fix for JDK9:
>
> bug: https://bugs.openjdk.java.net/browse/JDK-8160623
>
> webrev: http://cr.openjdk.java.net/~ssadetsky/8160623/webrev.00/
>
> This a regression from JDK-8139189. The wchar array may contain all
> zeroes for some known keys (likely for Delete key only) and it should
> not be interpreted as  CHAR_UNDEFINED.
>
> --Semyon
>
>


From philip.race at oracle.com  Thu Jun 30 15:26:36 2016
From: philip.race at oracle.com (Philip Race)
Date: Thu, 30 Jun 2016 08:26:36 -0700
Subject: <AWT Dev> [9] Review request for 8160623: [PIT] Exception
 running java/awt/event/KeyEvent/KeyChar/KeyCharTest.java
In-Reply-To: <2b60aa5c-8f85-618a-7aa0-cbdacca840c7@oracle.com>
References: <2b60aa5c-8f85-618a-7aa0-cbdacca840c7@oracle.com>
Message-ID: <57753A2C.5010808@oracle.com>

Whilst I am not an expert on this code it looks OK
but it seems like the failing regression test should be updated
with this bug id as part of the change ..

-phil.

On 6/30/16, 7:38 AM, Semyon Sadetsky wrote:
> Hello,
>
> Please review fix for JDK9:
>
> bug: https://bugs.openjdk.java.net/browse/JDK-8160623
>
> webrev: http://cr.openjdk.java.net/~ssadetsky/8160623/webrev.00/
>
> This a regression from JDK-8139189. The wchar array may contain all 
> zeroes for some known keys (likely for Delete key only) and it should 
> not be interpreted as  CHAR_UNDEFINED.
>
> --Semyon
>
>

From alexandr.scherbatiy at oracle.com  Thu Jun 30 17:03:20 2016
From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy)
Date: Thu, 30 Jun 2016 21:03:20 +0400
Subject: <AWT Dev> <AWT dev>[9] Review request for JDK-7156316: [macosx]
 Ctrl+Space does generate Unknown keychar
In-Reply-To: <78D4DBD1-9A17-4A95-A148-3DD0D1E4EC88@oracle.com>
References: <78D4DBD1-9A17-4A95-A148-3DD0D1E4EC88@oracle.com>
Message-ID: <83cf55a6-e317-dd2b-2f72-d32b284ab572@oracle.com>

On 27/06/16 21:57, Manajit Halder wrote:
> Hi All,
>
> Kindly review the fix for JDK9.
>
> *Bug*:
> https://bugs.openjdk.java.net/browse/JDK-7156316
> _
> _
> *Webrev*:
> http://cr.openjdk.java.net/~mhalder/7156316/webrev.00/ 
> <http://cr.openjdk.java.net/%7Emhalder/7156316/webrev.00/>
>
> *Issue: *
> [macosx] Ctrl+Space does generate Unknown keychar
>
> *Cause: *
> SPACK key value was received as ? ? in function handleKeyEvent and 
> that was correct value, but while sending the value as a character 
> to function nsToJavaChar it was getting passed as 0. The 
> function nsToJavaChar was returning 0 as unichar character for SPACE 
> key as there was no code to handle the situation.
> *Fix: *
> An extra parameter was added in handleKeyEvent function indicating 
> SPACE key and was passed to nsToJavaChar method to handle it.
156                 if ("".equals(chars.trim())) {
   It is better to use: chars.trim().isEmpty() or may be spaceKeyTyped =
chars.trim().isEmpty().

   Thanks,
   Alexandr.

>
> Regards,
> Manajit

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

From semyon.sadetsky at oracle.com  Thu Jun 30 17:21:34 2016
From: semyon.sadetsky at oracle.com (Semyon Sadetsky)
Date: Thu, 30 Jun 2016 20:21:34 +0300
Subject: <AWT Dev> <AWT dev>[9] Review request for 8061637:
 GraphicsEnvironment API does not detect dynamically attached graphics
 device
In-Reply-To: <574DE204.8010904@oracle.com>
References: <57230580.1070805@oracle.com>
	<af304deb-bea7-1fd8-36bb-b77088c94ff8@oracle.com>
	<5742DB9E.4080607@oracle.com>
	<90b4d485-b14a-d3c3-ebb3-dcf467f995de@oracle.com>
	<5743155D.2030408@oracle.com> <574DE204.8010904@oracle.com>
Message-ID: <63a303b0-b796-2f9e-5f0a-76c1f69d2730@oracle.com>

On 5/31/2016 10:12 PM, Phil Race wrote:
> I am not very familiar with this code, but why is this discussion 
> centred around D3D?
> The GDI pipeline is just as "popular" on Windows due to Intel chipsets.
Because we always use D3DGraphicsDevice if d3d is available.
new D3DGraphicsDevice()-> getDeviceCaps()-> 
D3DRenderQueue.flushAndInvokeNow()->
flushBuffer()-> 
D3DRenderQueue.cpp->AwtToolkit::GetInstance().InvokeFunction()->::SendMessage()

It may cause a deadlock if the displayChange event is handled on the 
Toolkit thread.

--Semyon
>
> -phil.
>
> On 05/23/2016 07:36 AM, Semyon Sadetsky wrote:
>>
>>
>> On 5/23/2016 5:00 PM, Sergey Bylokhov wrote:
>>> On 23.05.16 13:29, Semyon Sadetsky wrote:
>>>> This will not be possible because of deadlock: the SGE update calls 
>>>> D3D,
>>>> which synchronously send messages to the toolkit thread.
>>>
>>> Why it is a problem to call this on the toolkit thread directly?
>> This is how D3D calls are run : sun.java2d.d3d. 
>> D3DRenderQueue#flashBuffer uses 
>> AwtToolkit::GetInstance().InvokeFunction().
>>
>> --Semyon
>>>
>>>>> I think that XToolkit and LWToolkit should uses this logic already.
>>>> On Windows communication with the graphics pipeline is designed 
>>>> differently.
>>>
>>> They are quite similar if not identical. I suggest to check two 
>>> solutions:
>>>  - displayChanged is on toolkit thread, only listeners which can 
>>> call users code executed on EDT.
>>>  - The main logic on the toolkit thread all listeners are on related 
>>> EDT(in this case we will need to save the appcontext of the listener 
>>> on addDisplayChangedListener()).
>>>
>>>>
>>>> --Semyon
>>>>>
>>>>> On 29.04.16 9:56, Semyon Sadetsky wrote:
>>>>>> Hello,
>>>>>>
>>>>>> Please review fix for JDK9:
>>>>>>
>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8061637
>>>>>> webrev: http://cr.openjdk.java.net/~ssadetsky/8061637/webrev.00/
>>>>>>
>>>>>> Display reconfiguration notification is skipped by JavaWS and the 
>>>>>> plugin
>>>>>> under Windows.
>>>>>> This happens because native display change event is scheduled to the
>>>>>> main app context EDT but the last was disabled by 8004584. As 
>>>>>> result NPE
>>>>>> is thrown on the Toolkit thread and event handling is not scheduled.
>>>>>> The fix solution runs display event handling in a new thread if the
>>>>>> system EDT is not available.
>>>>>> Test would require to write native code so the bug is labeled
>>>>>> noreg-hard.
>>>>>>
>>>>>> --Semyon
>>>>>
>>>>>
>>>>
>>>
>>>
>>
>

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

From Sergey.Bylokhov at oracle.com  Thu Jun 30 18:11:45 2016
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Thu, 30 Jun 2016 21:11:45 +0300
Subject: <AWT Dev> <Swing Dev> [9] Review request for JDK-8160650:
 Couple awt and swing tests have wrong require jtreg arguments
In-Reply-To: <57751819.50404@oracle.com>
References: <57751819.50404@oracle.com>
Message-ID: <81eae917-2b22-1288-cd65-a3d33d46625a@oracle.com>

Looks fine.

On 30.06.16 16:01, mikhail cherkasov wrote:
> Hi all,
>
> jbs: https://bugs.openjdk.java.net/browse/JDK-8160650
> webrev:http://cr.openjdk.java.net/~mcherkas/8160650/9/webrev/
>
> Couple awt and swing tests have wrong require jtreg arguments,
> the following tests should use "os.family" instead of "os.name":
>
> javax/swing/LookAndFeel/8145547/DemandGTK.java: @requires (os.name ==
> "linux" | os.name == "solaris")
> java/awt/TextArea/TextAreaCaretVisibilityTest/bug7129742.java: *
> @requires (os.family == "linux" | os.name == "solaris")
> java/awt/WMSpecificTests/Mutter/MutterMaximizeTest.java: @requires
> (os.name == "linux" | os.name == "solaris")
> java/awt/WMSpecificTests/Metacity/FullscreenDialogModality.java: *
> @requires (os.name == "linux" | os.name == "solaris")
>
> see jtreg doc: http://openjdk.java.net/jtreg/tag-spec.html#requires_names
>
> Thanks,
> Mikhail.


-- 
Best regards, Sergey.

From alexandr.scherbatiy at oracle.com  Thu Jun 30 20:04:34 2016
From: alexandr.scherbatiy at oracle.com (Alexandr Scherbatiy)
Date: Thu, 30 Jun 2016 23:04:34 +0300
Subject: <AWT Dev> [9] Review request for JDK-8160650: Couple awt and
 swing tests have wrong require jtreg arguments
In-Reply-To: <57751819.50404@oracle.com>
References: <57751819.50404@oracle.com>
Message-ID: <bd61b532-2ce5-8895-a3c3-48470c9f1447@oracle.com>

The fix looks good to me.

Thanks,
Alexandr.

On 6/30/2016 4:01 PM, mikhail cherkasov wrote:
> Hi all,
>
> jbs: https://bugs.openjdk.java.net/browse/JDK-8160650
> webrev:http://cr.openjdk.java.net/~mcherkas/8160650/9/webrev/
>
> Couple awt and swing tests have wrong require jtreg arguments,
> the following tests should use "os.family" instead of "os.name":
>
> javax/swing/LookAndFeel/8145547/DemandGTK.java: @requires (os.name == 
> "linux" | os.name == "solaris")
> java/awt/TextArea/TextAreaCaretVisibilityTest/bug7129742.java: * 
> @requires (os.family == "linux" | os.name == "solaris")
> java/awt/WMSpecificTests/Mutter/MutterMaximizeTest.java: @requires 
> (os.name == "linux" | os.name == "solaris")
> java/awt/WMSpecificTests/Metacity/FullscreenDialogModality.java: * 
> @requires (os.name == "linux" | os.name == "solaris")
>
> see jtreg doc: http://openjdk.java.net/jtreg/tag-spec.html#requires_names
>
> Thanks,
> Mikhail.