Re: [10] Review request for 8185634, 8185634: Java Fx-Swing dialogs appearing behind main stage

[Alexander Zvegintsev]

Hi Phil,

Please review the updated fix with reflection incorporated
http://cr.openjdk.java.net/~azvegint/jdk/10/8185634/01/

New issue created JDK-8187803 
 as JDK counterpart of 
this issue.


Thanks,
Alexander.

On 21/09/2017 22:25, Phil Race wrote:

Some procedural comments :
Since 90% of this is in AWT code, I'd have thought awt-dev should be 
included here.

I've added that list.

And apart from needing separate bug ids, I don't see why the bug below 
is confidential.



I agree with what Kevin pointed out off-line that as in the dialog 
case, the FX side
of the code can use reflection and simply be a harmless non-functional 
no-op

if the SwingAccessor does not provide the new method.

BTW
264 inline HWND GetOverridenHWnd() { return m_overridenHwnd; }
should be "dd" not "d".

-phil.

On 09/21/2017 03:38 AM, Alexander Zvegintsev wrote:

Hello,

please review the fix

http://cr.openjdk.java.net/~azvegint/jdk/10/8185634/00/

for the issue

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

Re: [10] Review request for 8182043: Access to Windows Large Icons

[Sergey Bylokhov]

On 9/21/17 14:12, Semyon Sadetsky wrote:

On 09/21/2017 01:52 PM, Sergey Bylokhov wrote:


On 9/21/17 08:54, Semyon Sadetsky wrote:

On 09/20/2017 02:41 PM, Sergey Bylokhov wrote:


Hi, Semyon
I have some initial comments which are based on the two bugs: 
JDK-8182043 and JDK-8156183.


getSystemIcon(File file, int size):
    - How the user will know what values/sizes should be passed, 
what values are supported? It is unlikely that he will pass all 
values in between 8-256?

Supported sizes are described in the method spec, aren't they?
This API doesn't imply any size limitation like the 8-256 you mentioned.


Does it mean that all sizes will be supported(1-Integer.MAX_INT)? I 
guess it is unlikely that the the explorer.exe will contains the icons 
bigger than 1024.

This is a a cross-platform API, not a windows specific implementation.


This was an example, and the question was how the user will know what 
icons are supported by some specific file.







"For any positive size value the exact file icon size is queried":
    - This should be double checked because our implementation can 
return MultiResolutionIconImage if the system returns the icon which 
size is different from requested.


FILE_ICON_SMALL(FILE_ICON_LARGE);
    - What these parameters mean? Is it the smallest(biggest) 
supported size or is it a default size? Can it be different if 
different dpi are used on the screen? For example 16(32) by default 
and 32(64) on HiDPI?
They means what they have been meaning FileChooserUI implementation 
for the Windows L which operates by two fixed icon sizes, large and 
small.


But it is not necessary will be used by our implementation of 
FileChooserUI when this API became public. For example in the 
description of JDK-8156183 the user said that large icons are used in 
"a media file browser" and "32x32 isn't large by the standards of 
current-millennium operating systems".
But even in our FileChooserUI implementation shouldn't we use x2 icons 
in case of HiDPI?

FILE_ICON_SMALL - is it a smallest supported size?
User may use the new method to get icons at any resolution. Small/large 
sizes are preserved for backward compatibility, because before this 
change only those two sizes were available.


Backward compatibility to what? There was know public API for this.
It is still unclear what is a "the small or large file icon variant" means.





FILE_ICON_SMALL:
   - It seems that this value duplicate functionality of the old 
getSystemIcon(File) method?
How this can be got from the spec? It may return the same size but 
not necessarily.


Then how the old method and the new one are related? Will the old 
method returns the size in between FILE_ICON_SMALL and FILE_ICON_LARGE?

I didn't get how it would be possible?


Possible what? It is unclear how the two methods are related to each other.






Probably it will be better to provide to the user the 
set(list/mri/array/etc) of supported images, or if it is really slow 
the set(list/mri/array/etc) of supported sizes, and the user will be 
able to pass some meaningful sizes.
This is not a good idea. Extracting all available icon resolutions 
might take significant time and since icons are cached it would be 
waste of RAM.


It should be measured, we can try to load them lazy, or provide the 
list of sizes which are supported.
Sorry, I didn't get what are you proposing to measure? And how do you 
propose to get the icon size without reading the image?





On 9/13/17 11:01, Semyon Sadetsky wrote:

Hello,

Please review fix for JDK10 (the changes involve AWT and Swing):

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

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

The fix  opens the part of the ShellFolder API for getting system 
icons which was decided to be left closed during the 8081722 
enhancement review in 9.


Also the fix extends the API by adding possibility to query file 
icons of arbitrary size and implements this extension for Windows 
platform.


--Semyon














--
Best regards, Sergey.

Re: [10] Review request for 8186495: Some closed SQE tests fail after frame dispose() on Linux

[Sergey Bylokhov]

On 9/21/17 08:57, Semyon Sadetsky wrote:

On 09/13/2017 03:42 PM, Sergey Bylokhov wrote:


On 9/13/17 15:36, Semyon Sadetsky wrote:
The problem in the fix is that the new checks do not try to be 
thread safe.
So, what do you propose? Add a volatile field "disposing" and do noop 
if it is true?


I have added a links to the bug which contain an examples, of how it 
was implemented in other cases.
I did not get which links do you mean. Can you be more specific about 
the solution you are proposing?


I added a links to two bugs in the comment, my proposal is to do 
something similar to a fixes for those bugs.










--Semyon




--Semyon


On 09/13/2017 11:55 AM, Sergey Bylokhov wrote:

On 9/13/17 11:49, Semyon Sadetsky wrote:
The tests passes after the fix for me. Which situations do you 
mean? Can you provide examples?


For example in XFramePeer.setVisible() it is possible that the 
peer became disposed after the new check.




--Semyon


On 09/11/2017 03:20 PM, Sergey Bylokhov wrote:

Hi, Semyon.
Did you check why the bug is not reproduced on jdk8?
I guess that it is still possible to get a situations below 
because of absent synchronization on all paths of usage 
"window",isDispose() and dispose() method:

 - check isDispose().
 - dispose the peer
 - use the long value which was disposed step above


On 9/8/17 20:00, Semyon Sadetsky wrote:

Hello,

Please review fix for JDK10:

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

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

After toolkit window is destroyed methods invocations on the 
window component may cause exceptions because of wrong native 
xwindow ID. The fix introduces checks in the X* peers to 
ensure that window ID is actual otherwise do nothing.


--Semyon





























--
Best regards, Sergey.

Re: [10] Review request for 8166772: Touch keyboard is not shown for text components on a screen touch

[Anton Litvinov]

Hello Sergey,

Thank you very much for review of this fix. The second version of the 
fix with minor changes in 3 places which address your remarks is 
created. The new fix version applied to the today's version of the 
consolidated repository "jdk10/client" was verified in my local 
environment successfully. Could you please look at the new version of 
the fix.


Webrev (the 2nd version): 
http://cr.openjdk.java.net/~alitvinov/8166772/jdk10/webrev.01


The 2nd version of the fix contains the next changes:
1.  "SunToolkit.java" file - Now "true" is used as the default value for 
the system property "awt.touchKeyboardAutoShowIsEnable".
2.  The 1st version of the fix was not thread-safe, only in case, when 
more than 1 EDT could exist in the process, in 2 places: "WToolkit.java" 
file (access to the fields "compOnTouchDownEvent", 
"compOnMousePressedEvent"), "awt_Toolkit.cpp" file (deletion and 
assignment of "NULL" to the field "m_touchKbrdExeFilePath" in the method 
"ShowTouchKeyboard()").
- "WToolkit.java" - The modifier "volatile" was added to the fields 
"compOnTouchDownEvent", "compOnMousePressedEvent".
- "awt_Toolkit.cpp" - Code deleting and assigning NULL to 
"m_touchKbrdExeFilePath" in the method "ShowTouchKeyboard()" was 
substituted for the code which outputs into the trace message in case, 
if launching the touch keyboard system application fails.


Could you please answer my question.
- Should CCC request be filed for the new system property 
"awt.touchKeyboardAutoShowIsEnable", whose value is considered as "true" 
by default, if it is not specified by the user explicitly while 
launching a Java application?


Thank you,
Anton

On 05/09/2017 18:15, Sergey Bylokhov wrote:

Hi, Anton.
The fix looks good.
 - But can you please recheck that is is not necessary to use 
additional synchronization in showOrHideTouchKeyboard() if a few EDT 
will be used.
 - I suggest to invert the awt.touchKeyboardAutoShowIsEnabled and use 
true as default value, we will have more coverage and feedback in this 
case. This property will be used as a workaround if some bugs will be 
found.


On 8/30/17 11:51, Anton Litvinov wrote:

Hello dear reviewers,

Could anybody please look at this review request?

Thank you,
Anton

On 17/08/2017 13:20, Anton Litvinov wrote:

Hello,

Could you please review the following fix for the bug.

Bug: https://bugs.openjdk.java.net/browse/JDK-8166772
Webrev: http://cr.openjdk.java.net/~alitvinov/8166772/jdk10/webrev.00

The bug is the fact that, when a user touches any Swing or AWT text 
component, for example "JTextField", "JTextArea", "TextField", 
"TextArea", by means of a touch screen on a host with MS Windows 
10/8.1/8 OS, the system touch keyboard is not shown automatically. 
Please find a detailed description of the bug, screenshots depicting 
the touch keyboard and a compilable test case with Swing/AWT text 
components in JBS bug record. Also a summary of the done research of 
the issue with a description of identified approaches for its 
resolution are reported in my last comment in the bug record.


THE FIX:
On a very abstract level the fix functioning can be presented by the 
next 3 stages:


Stage 1.
The fix adds support of "WM_TOUCH" system window messages to AWT 
native peer windows through C++ class "AwtComponent". It "processes" 
"WM_TOUCH" message and marks "java.awt.event.MouseEvent", which is 
created as a result of handling of the further coming 
"WM_LBUTTONDOWN", "WM_LBUTTONUP" messages sent by the system in 
substitution for this "WM_TOUCH" message, by the new private field 
flag "MouseEvent.causedByTouchEvent".


Stage 2.
Then on Java level the fix handles "MouseEvent", "FocusEvent" 
received only by the instances of "java.awt.TextComponent", 
"javax.swing.text.TextComponent" in 
"WToolkit.showOrHideTouchKeyboard()" called from 
"Component.dispatchEventImpl()" and shows or hides the touch 
keyboard on "MouseEvent.MOUSE_RELEASED" and "FocusEvent.FOCUS_LOST" 
events by calling corresponding native methods of "WToolkit" class.


Stage 3.
Showing of the touch keyboard is implemented in C++ class 
"AwtToolkit" and is done by launching the system application 
"TabTip.exe" which implements the system touch keyboard. This 
approach is described in the bug record.


FEATURES OF THE FIX:
1. By default all native and Java parts of the fix do not function 
at all - the fix is disabled. To enable the fix the application 
should be run with "-Dawt.touchKeyboardAutoShowIsEnabled=true" 
option. Handling of this new property is implemented in 
"sun.awt.SunToolkit" class.


2. Native parts of the fix functions only on MS Window 8 or later.

3. The fix implements automatic showing of the touch keyboard for 
the following 2 use cases:

a.  The user touches the text components using the touch screen.
b.  The user does mouse clicks on the text components, while no 
any keyboard is attached to the host.


FIX LOGICAL STRUCTURE BY SOURCE CODE:
1. Core of the fix:
Native 

Re: [10] Review Request: JDK-8081311 : [TEST_BUG] java/awt/ComponentOrientation/WindowTest.java

[Semyon Sadetsky]

+1


On 09/21/2017 02:02 PM, Sergey Bylokhov wrote:

+1

On 9/21/17 01:29, Pankaj Bansal wrote:

Hi Sergey/Semyon,

I have updated the webrev according to your comments. Please review.
Webrev:   http://cr.openjdk.java.net/~psadhukhan/pankaj/webrev/

Regards,
Pankaj Bansal

-Original Message-
From: Semyon Sadetsky
Sent: Tuesday, September 19, 2017 8:40 PM
To: Sergey Bylokhov; Pankaj Bansal; awt-dev@openjdk.java.net
Subject: Re:  [10] Review Request: JDK-8081311 : [TEST_BUG] 
java/awt/ComponentOrientation/WindowTest.java


On 09/18/2017 11:04 AM, Sergey Bylokhov wrote:


On 9/18/17 10:14, Semyon Sadetsky wrote:

It is fine because it tests the ComponentOrientation class which is
loaded from the resource bundle and applied to the window.

I would agree with you if the resource bundle at least contained a
value for the component orientation but it sets some specific locale
codes. And java's locale functionality is not a subject of the
client-libs, it is an another module. Also, as it was already pointed
out, the method was deprecated long time ago.


Where did you check these bundles? Because resource bundles for this
test contains the all variations of orientation
property(UNKNOWN/LEFT_TO_RIGHT/RIGHT_TO_LEFT/none).
OK. I missed those bundle classes with the orientation properties. I 
think the test may either be left as it is, or moved to the i18n 
suite with adding a test to ComponentOrientation suite that tests

applyComponentOrientation() directly.







On 9/15/17 4:53 PM, Sergey Bylokhov wrote:

I guess you missed something, the possibility to configure the
components via ResourceBudnle or locale is something different
that the hardcore the orientation in the application. And the fact
that this test found the bug in jdk9 just show that the test is
valid.

On 9/15/17 16:29, Semyon Sadetsky wrote:

The component orientation test suite should use the right API,
not the deprecated one. This was missed when the new API is 
created.

So the change is valid from this point with the corresponding
comment in JIRA.

--Semyon

On 9/15/2017 3:09 PM, Sergey Bylokhov wrote:


On 9/14/17 23:15, Pankaj Bansal wrote:

This test is not failing with JDK 9_181 and JDK10 as methods
are deprecated not removed. It is giving lot of warning for
using deprecated things, so I made these changes. I think the
bug description should be changed to notify that.


I am not sure that it is correct to replace one API to another
one. This test was written as part of i18n support and it checks
that our API can be configured by the ResourceBundles. The
updated test doing the different things - it checks that
getComponentOrientation will return the value which were set by
applyComponentOrientation().

Since it was reported that the test failed because of some bug,
but looks like now it work as expected, this CR can be closed as
not reproducible. Or you can clean the test but without changing
its logic.



Regards,
Pankaj Bansal

-Original Message-
From: Sergey Bylokhov
Sent: Thursday, September 14, 2017 11:30 PM
To: Pankaj Bansal; awt-dev@openjdk.java.net
Subject: Re:  [10] Review Request: JDK-8081311 :
[TEST_BUG] java/awt/ComponentOrientation/WindowTest.java

Hi, Pankaj.
Can you please clarify why this test fails on jdk9? This method
is deprecated but it was not removed, so it should work.
Probably at some point of jdk9 development it was broken?

On 9/14/17 03:25, Pankaj Bansal wrote:

Hi All,

Please review the fix for test program
test/java/awt/ComponentOrientation/WindowTest.java for JDK 10.

Bug:

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

Webrev:

http://cr.openjdk.java.net/~aghaisas/pankaj/8081311/webrev.0/

Issue:

The test java/awt/ComponentOrientation/WindowTest.java uses
depreciated function  applyResourceBundle. So the test should
be updated to use applyComponentOrientation function.

Fix:

Made changes in java/awt/ComponentOrientation/WindowTest.java
to use
applyComponentOrientation function and did corresponding 
changes.

Along with that, the test is also using java.applet.Applet
which is also deprecated, so changed the test to use Frame
instead.

Regards,

Pankaj Bansal




--
Best regards, Sergey.

Re: [10] Review request for 8182043: Access to Windows Large Icons

[Semyon Sadetsky]

On 09/21/2017 01:52 PM, Sergey Bylokhov wrote:


On 9/21/17 08:54, Semyon Sadetsky wrote:

On 09/20/2017 02:41 PM, Sergey Bylokhov wrote:


Hi, Semyon
I have some initial comments which are based on the two bugs: 
JDK-8182043 and JDK-8156183.


getSystemIcon(File file, int size):
- How the user will know what values/sizes should be passed, 
what values are supported? It is unlikely that he will pass all 
values in between 8-256?

Supported sizes are described in the method spec, aren't they?
This API doesn't imply any size limitation like the 8-256 you mentioned.


Does it mean that all sizes will be supported(1-Integer.MAX_INT)? I 
guess it is unlikely that the the explorer.exe will contains the icons 
bigger than 1024.

This is a a cross-platform API, not a windows specific implementation.





"For any positive size value the exact file icon size is queried":
- This should be double checked because our implementation can 
return MultiResolutionIconImage if the system returns the icon which 
size is different from requested.


FILE_ICON_SMALL(FILE_ICON_LARGE);
- What these parameters mean? Is it the smallest(biggest) 
supported size or is it a default size? Can it be different if 
different dpi are used on the screen? For example 16(32) by default 
and 32(64) on HiDPI?
They means what they have been meaning FileChooserUI implementation 
for the Windows L which operates by two fixed icon sizes, large and 
small.


But it is not necessary will be used by our implementation of 
FileChooserUI when this API became public. For example in the 
description of JDK-8156183 the user said that large icons are used in 
"a media file browser" and "32x32 isn't large by the standards of 
current-millennium operating systems".
But even in our FileChooserUI implementation shouldn't we use x2 icons 
in case of HiDPI?

FILE_ICON_SMALL - is it a smallest supported size?
User may use the new method to get icons at any resolution. Small/large 
sizes are preserved for backward compatibility, because before this 
change only those two sizes were available.




FILE_ICON_SMALL:
   - It seems that this value duplicate functionality of the old 
getSystemIcon(File) method?
How this can be got from the spec? It may return the same size but 
not necessarily.


Then how the old method and the new one are related? Will the old 
method returns the size in between FILE_ICON_SMALL and FILE_ICON_LARGE?

I didn't get how it would be possible?





Probably it will be better to provide to the user the 
set(list/mri/array/etc) of supported images, or if it is really slow 
the set(list/mri/array/etc) of supported sizes, and the user will be 
able to pass some meaningful sizes.
This is not a good idea. Extracting all available icon resolutions 
might take significant time and since icons are cached it would be 
waste of RAM.


It should be measured, we can try to load them lazy, or provide the 
list of sizes which are supported.
Sorry, I didn't get what are you proposing to measure? And how do you 
propose to get the icon size without reading the image?





On 9/13/17 11:01, Semyon Sadetsky wrote:

Hello,

Please review fix for JDK10 (the changes involve AWT and Swing):

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

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

The fix  opens the part of the ShellFolder API for getting system 
icons which was decided to be left closed during the 8081722 
enhancement review in 9.


Also the fix extends the API by adding possibility to query file 
icons of arbitrary size and implements this extension for Windows 
platform.


--Semyon

Re: [10] Review Request: JDK-8081311 : [TEST_BUG] java/awt/ComponentOrientation/WindowTest.java

[Sergey Bylokhov]

+1

On 9/21/17 01:29, Pankaj Bansal wrote:

Hi Sergey/Semyon,

I have updated the webrev according to your comments. Please review.
Webrev:   http://cr.openjdk.java.net/~psadhukhan/pankaj/webrev/

Regards,
Pankaj Bansal

-Original Message-
From: Semyon Sadetsky
Sent: Tuesday, September 19, 2017 8:40 PM
To: Sergey Bylokhov; Pankaj Bansal; awt-dev@openjdk.java.net
Subject: Re:  [10] Review Request: JDK-8081311 : [TEST_BUG] 
java/awt/ComponentOrientation/WindowTest.java

On 09/18/2017 11:04 AM, Sergey Bylokhov wrote:


On 9/18/17 10:14, Semyon Sadetsky wrote:

It is fine because it tests the ComponentOrientation class which is
loaded from the resource bundle and applied to the window.

I would agree with you if the resource bundle at least contained a
value for the component orientation but it sets some specific locale
codes. And java's locale functionality is not a subject of the
client-libs, it is an another module. Also, as it was already pointed
out, the method was deprecated long time ago.


Where did you check these bundles? Because resource bundles for this
test contains the all variations of orientation
property(UNKNOWN/LEFT_TO_RIGHT/RIGHT_TO_LEFT/none).

OK. I missed those bundle classes with the orientation properties. I think the 
test may either be left as it is, or moved to the i18n suite with adding a test 
to ComponentOrientation suite that tests
applyComponentOrientation() directly.







On 9/15/17 4:53 PM, Sergey Bylokhov wrote:

I guess you missed something, the possibility to configure the
components via ResourceBudnle or locale is something different
that the hardcore the orientation in the application. And the fact
that this test found the bug in jdk9 just show that the test is
valid.

On 9/15/17 16:29, Semyon Sadetsky wrote:

The component orientation test suite should use the right API,
not the deprecated one. This was missed when the new API is created.
So the change is valid from this point with the corresponding
comment in JIRA.

--Semyon

On 9/15/2017 3:09 PM, Sergey Bylokhov wrote:


On 9/14/17 23:15, Pankaj Bansal wrote:

This test is not failing with JDK 9_181 and JDK10 as methods
are deprecated not removed. It is giving lot of warning for
using deprecated things, so I made these changes. I think the
bug description should be changed to notify that.


I am not sure that it is correct to replace one API to another
one. This test was written as part of i18n support and it checks
that our API can be configured by the ResourceBundles. The
updated test doing the different things - it checks that
getComponentOrientation will return the value which were set by
applyComponentOrientation().

Since it was reported that the test failed because of some bug,
but looks like now it work as expected, this CR can be closed as
not reproducible. Or you can clean the test but without changing
its logic.



Regards,
Pankaj Bansal

-Original Message-
From: Sergey Bylokhov
Sent: Thursday, September 14, 2017 11:30 PM
To: Pankaj Bansal; awt-dev@openjdk.java.net
Subject: Re:  [10] Review Request: JDK-8081311 :
[TEST_BUG] java/awt/ComponentOrientation/WindowTest.java

Hi, Pankaj.
Can you please clarify why this test fails on jdk9? This method
is deprecated but it was not removed, so it should work.
Probably at some point of jdk9 development it was broken?

On 9/14/17 03:25, Pankaj Bansal wrote:

Hi All,

Please review the fix for test program
test/java/awt/ComponentOrientation/WindowTest.java for JDK 10.

Bug:

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

Webrev:

http://cr.openjdk.java.net/~aghaisas/pankaj/8081311/webrev.0/

Issue:

The test java/awt/ComponentOrientation/WindowTest.java uses
depreciated function  applyResourceBundle. So the test should
be updated to use applyComponentOrientation function.

Fix:

Made changes in java/awt/ComponentOrientation/WindowTest.java
to use
applyComponentOrientation function and did corresponding changes.
Along with that, the test is also using java.applet.Applet
which is also deprecated, so changed the test to use Frame
instead.

Regards,

Pankaj Bansal




--
Best regards, Sergey.
























--
Best regards, Sergey.

Re: [10] Review Request: JDK-6857809 : [TEST_BUG] java/awt/Component/PrintAllXcheckJNI/PrintAllXcheckJNI.java

[Sergey Bylokhov]

+1

On 9/21/17 07:54, Semyon Sadetsky wrote:

Looks good to me.

--Semyon


On 09/21/2017 01:44 AM, Pankaj Bansal wrote:


Hi Sergey/Seymon,

I have incorporated the webrev for review comments.

Yes Sergey, the test passes on Ubuntu with GTK L

Webrev: 
http://cr.openjdk.java.net/~psadhukhan/pankaj/JDK-6857809-webrev.01/ 



Regards,

Pankaj Bansal

*From:*Semyon Sadetsky
*Sent:* Wednesday, September 20, 2017 10:43 PM
*To:* Pankaj Bansal; awt-dev@openjdk.java.net
*Subject:* Re:  [10] Review Request: JDK-6857809 : [TEST_BUG] 
java/awt/Component/PrintAllXcheckJNI/PrintAllXcheckJNI.java


On 09/20/2017 09:21 AM, Pankaj Bansal wrote:

Hi Seymon,

I think the issue is because no size is set on frame. This is also
the proposed fix in the bug description.

This is good, but setting a fixed frame size forces the java Frame 
object to return that size only at the very beginning the real and 
final frame dimensions will be established  asynchronously by the 
native window subsystem.


Regards,

Pankaj

*From:*Semyon Sadetsky
*Sent:* Wednesday, September 20, 2017 9:02 PM
*To:* Pankaj Bansal; awt-dev@openjdk.java.net

*Subject:* Re:  [10] Review Request: JDK-6857809 :
[TEST_BUG] java/awt/Component/PrintAllXcheckJNI/PrintAllXcheckJNI.java

Hi Pankaj,

The root cause of the issue is that the underling native window is
not yet created when its with and height are requested. This is
because windows are created asynchronously. The test should be
fixed by adding Robot.waitForIdle() after frame.setVisible(true).

--Semyon

On 09/20/2017 05:49 AM, Pankaj Bansal wrote:

Hi All,

Please review the fix for test program test
java/awt/Component/PrintAllXcheckJNI/PrintAllXcheckJNI.java
for JDK 10.

Bug:

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

Webrev:

http://cr.openjdk.java.net/~aghaisas/pankaj/6857809/webrev.0/


Issue:

The test
 java/awt/Component/PrintAllXcheckJNI/PrintAllXcheckJNI.java
fails on Linux intermittently due to
“java.lang.IllegalArgumentException: Width (0) and height (0)
cannot be <= 0” exception.

Fix:

Made changes in
java/awt/Component/PrintAllXcheckJNI/PrintAllXcheckJNI.java to
set the size of frame to make the test more stable.

Regards,

Pankaj Bansal






--
Best regards, Sergey.

Re: [10] Review request for 8182043: Access to Windows Large Icons

[Sergey Bylokhov]

On 9/21/17 08:54, Semyon Sadetsky wrote:

On 09/20/2017 02:41 PM, Sergey Bylokhov wrote:


Hi, Semyon
I have some initial comments which are based on the two bugs: 
JDK-8182043 and JDK-8156183.


getSystemIcon(File file, int size):
    - How the user will know what values/sizes should be passed, what 
values are supported? It is unlikely that he will pass all values in 
between 8-256?

Supported sizes are described in the method spec, aren't they?
This API doesn't imply any size limitation like the 8-256 you mentioned.


Does it mean that all sizes will be supported(1-Integer.MAX_INT)? I 
guess it is unlikely that the the explorer.exe will contains the icons 
bigger than 1024.





"For any positive size value the exact file icon size is queried":
    - This should be double checked because our implementation can 
return MultiResolutionIconImage if the system returns the icon which 
size is different from requested.


FILE_ICON_SMALL(FILE_ICON_LARGE);
    - What these parameters mean? Is it the smallest(biggest) 
supported size or is it a default size? Can it be different if 
different dpi are used on the screen? For example 16(32) by default 
and 32(64) on HiDPI?
They means what they have been meaning FileChooserUI implementation for 
the Windows L which operates by two fixed icon sizes, large and small.


But it is not necessary will be used by our implementation of 
FileChooserUI when this API became public. For example in the 
description of JDK-8156183 the user said that large icons are used in "a 
media file browser" and "32x32 isn't large by the standards of 
current-millennium operating systems".
But even in our FileChooserUI implementation shouldn't we use x2 icons 
in case of HiDPI?

FILE_ICON_SMALL - is it a smallest supported size?


FILE_ICON_SMALL:
   - It seems that this value duplicate functionality of the old 
getSystemIcon(File) method?
How this can be got from the spec? It may return the same size but not 
necessarily.


Then how the old method and the new one are related? Will the old method 
returns the size in between FILE_ICON_SMALL and FILE_ICON_LARGE?





Probably it will be better to provide to the user the 
set(list/mri/array/etc) of supported images, or if it is really slow 
the set(list/mri/array/etc) of supported sizes, and the user will be 
able to pass some meaningful sizes.
This is not a good idea. Extracting all available icon resolutions might 
take significant time and since icons are cached it would be waste of RAM.


It should be measured, we can try to load them lazy, or provide the list 
of sizes which are supported.





On 9/13/17 11:01, Semyon Sadetsky wrote:

Hello,

Please review fix for JDK10 (the changes involve AWT and Swing):

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

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

The fix  opens the part of the ShellFolder API for getting system 
icons which was decided to be left closed during the 8081722 
enhancement review in 9.


Also the fix extends the API by adding possibility to query file 
icons of arbitrary size and implements this extension for Windows 
platform.


--Semyon









--
Best regards, Sergey.

Re: [10] Review request for 185634: Java Fx-Swing dialogs appearing behind main stage

[Phil Race]

Some procedural comments :
Since 90% of this is in AWT code, I'd have thought awt-dev should be 
included here.

I've added that list.

And apart from needing separate bug ids, I don't see why the bug below 
is confidential.



I agree with what Kevin pointed out off-line that as in the dialog case, 
the FX side

of the code can use reflection and simply be a harmless non-functional no-op
if the SwingAccessor does not provide the new method.

BTW

264 inline HWND GetOverridenHWnd() { return m_overridenHwnd; }

should be "dd" not "d".

-phil.

On 09/21/2017 03:38 AM, Alexander Zvegintsev wrote:

Hello,

please review the fix

http://cr.openjdk.java.net/~azvegint/jdk/10/8185634/00/

for the issue

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

Re: [10] Review request for 8186495: Some closed SQE tests fail after frame dispose() on Linux

[Semyon Sadetsky]

On 09/13/2017 03:42 PM, Sergey Bylokhov wrote:


On 9/13/17 15:36, Semyon Sadetsky wrote:
The problem in the fix is that the new checks do not try to be 
thread safe.
So, what do you propose? Add a volatile field "disposing" and do noop 
if it is true?


I have added a links to the bug which contain an examples, of how it 
was implemented in other cases.
I did not get which links do you mean. Can you be more specific about 
the solution you are proposing?








--Semyon




--Semyon


On 09/13/2017 11:55 AM, Sergey Bylokhov wrote:

On 9/13/17 11:49, Semyon Sadetsky wrote:
The tests passes after the fix for me. Which situations do you 
mean? Can you provide examples?


For example in XFramePeer.setVisible() it is possible that the 
peer became disposed after the new check.




--Semyon


On 09/11/2017 03:20 PM, Sergey Bylokhov wrote:

Hi, Semyon.
Did you check why the bug is not reproduced on jdk8?
I guess that it is still possible to get a situations below 
because of absent synchronization on all paths of usage 
"window",isDispose() and dispose() method:

 - check isDispose().
 - dispose the peer
 - use the long value which was disposed step above


On 9/8/17 20:00, Semyon Sadetsky wrote:

Hello,

Please review fix for JDK10:

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

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

After toolkit window is destroyed methods invocations on the 
window component may cause exceptions because of wrong native 
xwindow ID. The fix introduces checks in the X* peers to 
ensure that window ID is actual otherwise do nothing.


--Semyon

Re: [10] Review request for 8182043: Access to Windows Large Icons

[Semyon Sadetsky]

On 09/20/2017 02:41 PM, Sergey Bylokhov wrote:


Hi, Semyon
I have some initial comments which are based on the two bugs: 
JDK-8182043 and JDK-8156183.


getSystemIcon(File file, int size):
- How the user will know what values/sizes should be passed, what 
values are supported? It is unlikely that he will pass all values in 
between 8-256?

Supported sizes are described in the method spec, aren't they?
This API doesn't imply any size limitation like the 8-256 you mentioned.


"For any positive size value the exact file icon size is queried":
- This should be double checked because our implementation can 
return MultiResolutionIconImage if the system returns the icon which 
size is different from requested.


FILE_ICON_SMALL(FILE_ICON_LARGE);
- What these parameters mean? Is it the smallest(biggest) 
supported size or is it a default size? Can it be different if 
different dpi are used on the screen? For example 16(32) by default 
and 32(64) on HiDPI?
They means what they have been meaning FileChooserUI implementation for 
the Windows L which operates by two fixed icon sizes, large and small.

FILE_ICON_SMALL:
   - It seems that this value duplicate functionality of the old 
getSystemIcon(File) method?
How this can be got from the spec? It may return the same size but not 
necessarily.



Probably it will be better to provide to the user the 
set(list/mri/array/etc) of supported images, or if it is really slow 
the set(list/mri/array/etc) of supported sizes, and the user will be 
able to pass some meaningful sizes.
This is not a good idea. Extracting all available icon resolutions might 
take significant time and since icons are cached it would be waste of RAM.



On 9/13/17 11:01, Semyon Sadetsky wrote:

Hello,

Please review fix for JDK10 (the changes involve AWT and Swing):

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

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

The fix  opens the part of the ShellFolder API for getting system 
icons which was decided to be left closed during the 8081722 
enhancement review in 9.


Also the fix extends the API by adding possibility to query file 
icons of arbitrary size and implements this extension for Windows 
platform.


--Semyon

Re: [10] Review Request: JDK-6857809 : [TEST_BUG] java/awt/Component/PrintAllXcheckJNI/PrintAllXcheckJNI.java

[Semyon Sadetsky]

Looks good to me.

--Semyon


On 09/21/2017 01:44 AM, Pankaj Bansal wrote:


Hi Sergey/Seymon,

I have incorporated the webrev for review comments.

Yes Sergey, the test passes on Ubuntu with GTK L

Webrev: 
http://cr.openjdk.java.net/~psadhukhan/pankaj/JDK-6857809-webrev.01/ 



Regards,

Pankaj Bansal

*From:*Semyon Sadetsky
*Sent:* Wednesday, September 20, 2017 10:43 PM
*To:* Pankaj Bansal; awt-dev@openjdk.java.net
*Subject:* Re:  [10] Review Request: JDK-6857809 : [TEST_BUG] 
java/awt/Component/PrintAllXcheckJNI/PrintAllXcheckJNI.java


On 09/20/2017 09:21 AM, Pankaj Bansal wrote:

Hi Seymon,

I think the issue is because no size is set on frame. This is also
the proposed fix in the bug description.

This is good, but setting a fixed frame size forces the java Frame 
object to return that size only at the very beginning the real and 
final frame dimensions will be established  asynchronously by the 
native window subsystem.


Regards,

Pankaj

*From:*Semyon Sadetsky
*Sent:* Wednesday, September 20, 2017 9:02 PM
*To:* Pankaj Bansal; awt-dev@openjdk.java.net

*Subject:* Re:  [10] Review Request: JDK-6857809 :
[TEST_BUG] java/awt/Component/PrintAllXcheckJNI/PrintAllXcheckJNI.java

Hi Pankaj,

The root cause of the issue is that the underling native window is
not yet created when its with and height are requested. This is
because windows are created asynchronously. The test should be
fixed by adding Robot.waitForIdle() after frame.setVisible(true).

--Semyon

On 09/20/2017 05:49 AM, Pankaj Bansal wrote:

Hi All,

Please review the fix for test program test
java/awt/Component/PrintAllXcheckJNI/PrintAllXcheckJNI.java
for JDK 10.

Bug:

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

Webrev:

http://cr.openjdk.java.net/~aghaisas/pankaj/6857809/webrev.0/


Issue:

The test
 java/awt/Component/PrintAllXcheckJNI/PrintAllXcheckJNI.java
fails on Linux intermittently due to
“java.lang.IllegalArgumentException: Width (0) and height (0)
cannot be <= 0” exception.

Fix:

Made changes in
java/awt/Component/PrintAllXcheckJNI/PrintAllXcheckJNI.java to
set the size of frame to make the test more stable.

Regards,

Pankaj Bansal

Re: [10] JDK-8148344: Java robot keypress should be able to use extended key code characters as ? ? ?.

[Shashidhara Veerabhadraiah]

Hi All, Please find the updated webrev containing a new test that is added to 
test out the software changes that were made under this enhancement.

 

http://cr.openjdk.java.net/~sveerabhadra/8148344/webrev.02/

 

Thanks and regards,

Shashi

 

From: Shashidhara Veerabhadraiah 
Sent: Thursday, September 21, 2017 11:37 AM
To: Sergey Bylokhov ; Semyon Sadetsky 
; awt-dev@openjdk.java.net
Subject: Re:  [10] JDK-8148344: Java robot keypress should be able to 
use extended key code characters as ? ? ?.

 

Hi Sergey, I was able to input the surrogate pairs and got the required output 
as shown below:

 



 

 

Below is the output after we input the surrogate pairs:

 



 

Thanks and regards,

Shashi

 

 

-Original Message-
From: Sergey Bylokhov 
Sent: Thursday, September 14, 2017 11:33 PM
To: Shashidhara Veerabhadraiah mailto:shashidhara.veerabhadra...@oracle.com"shashidhara.veerabhadra...@oracle.com>;
 Semyon Sadetsky mailto:semyon.sadet...@oracle.com"semyon.sadet...@oracle.com>; HYPERLINK 
"mailto:awt-dev@openjdk.java.net"awt-dev@openjdk.java.net
Subject: Re:  [10] JDK-8148344: Java robot keypress should be able to 
use extended key code characters as ? ? ?.

 

The java uses UTF16, I guess this new api should use it also, and we should 
check that the surrogate pairs will be supported.

 

On 9/14/17 03:56, Shashidhara Veerabhadraiah wrote:

> Hi Sergey, Yes it represents the Unicode code point. The encoding is same as 
> the window characteristic which is UTF 8 as implemented in Java.

> 

> Thanks and regards,

> Shashi

> 

> -Original Message-

> From: Sergey Bylokhov

> Sent: Wednesday, September 13, 2017 5:22 AM

> To: Shashidhara Veerabhadraiah 

>  "mailto:shashidhara.veerabhadra...@oracle.com"shashidhara.veerabhadra...@oracle.com>;
>  Semyon Sadetsky 

> mailto:semyon.sadet...@oracle.com"semyon.sadet...@oracle.com>; 
> HYPERLINK "mailto:awt-dev@openjdk.java.net"awt-dev@openjdk.java.net

> Subject: Re:  [10] JDK-8148344: Java robot keypress should be able 
> to use extended key code characters as ? ? ?.

> 

> Hi, Shashi.

> One initial question:

> What is an int parameter of these methods means, is it a "Unicode code 
> point"? What encoding utf8/utf16 should be used?

> 

> On 9/8/17 02:50, Shashidhara Veerabhadraiah wrote:

>> Hi, I have updated the Webrev to accommodate the comments and here is 

>> the new Webrev:

>> 

>> http://cr.openjdk.java.net/~sveerabhadra/8148344/webrev.01/

>> 

>> I have separated the /_Unicode_/ keys input via java robot as a new 

>> set of /_public_/ api’s (this is in similar fashion as how the 

>> platform offers the Unicode keys input into the system) and this has 

>> been tested on all the platforms using the test file similar to the 

>> attached file in the bug. A more proper test file would be put for 

>> review in the subsequent reviews.

>> 

>> Thanks and regards,

>> 

>> Shashi

>> 

>> *From:* Sergey Bylokhov

>> *Sent:* Wednesday, August 30, 2017 2:33 AM

>> *To:* Shashidhara Veerabhadraiah

>> > "mailto:shashidhara.veerabhadra...@oracle.com"shashidhara.veerabhadra...@oracle.com>

>> *Cc:* HYPERLINK "mailto:awt-dev@openjdk.java.net"awt-dev@openjdk.java.net

>> *Subject:* Re:  [10] JDK-8148344: Java robot keypress should 

>> be able to use extended key code characters as ? ? ?.

>> 

>> Hi, Shashi.

>> 

>> This is part of this fix, to figure out how it will work for external 

>> applications. As you said this functionally can be useful for an 

>> onscreen keyboards, which virtually can have any possible keys, but 

>> we should check how the applications will react on such keys:

>>    - Will the application get some kind of keyPress/Release?

>>    - Will the application get some keyCode for such event?

>>    - Is it possible to get autorepeat for such keys?(between

>> press/release)

>> 

>> Depending from the answers above we can enhance existed robot API or 

>> provide a new one:

>> like Robot.keyType(char)/etc

>> 

>> - HYPERLINK 
>> "mailto:shashidhara.veerabhadra...@oracle.com"shashidhara.veerabhadra...@oracle.com

>>  wrote:

>>> 

>> 

>>> 

>> 

>>> 

>> 

>> Hi Sergey, I was only able to add short cut keys in the Microsoft 

>> word but not as a system wide short cut key. There was no mechanism 

>> that I could find to add a short cut key for a Unicode char!! Can you 

>> please tell me the steps to do the same if you are aware of?

>> 

>> Thanks and regards,

>> 

>> shashi

>> 

>>> 

>> 

>> *From:*Sergey Bylokhov

>>> *Sent:* Tuesday, August 22, 2017 8:34 PM

>>> *To:* Shashidhara Veerabhadraiah

>>> > >

>>> *Cc:* HYPERLINK "mailto:awt-dev@openjdk.java.net"awt-dev@openjdk.java.net 
>>> 

>>> *Subject:* Re:  [10] JDK-8148344: Java robot keypress 

>>> should be

>> able to use 

Re: [10] Review Request: JDK-6857809 : [TEST_BUG] java/awt/Component/PrintAllXcheckJNI/PrintAllXcheckJNI.java

[Pankaj Bansal]

Hi Sergey/Seymon,

 

I have incorporated the webrev for review comments.

Yes Sergey, the test passes on Ubuntu with GTK L

Webrev:  http://cr.openjdk.java.net/~psadhukhan/pankaj/JDK-6857809-webrev.01/

Regards,

Pankaj Bansal

 

 

From: Semyon Sadetsky 
Sent: Wednesday, September 20, 2017 10:43 PM
To: Pankaj Bansal; awt-dev@openjdk.java.net
Subject: Re:  [10] Review Request: JDK-6857809 : [TEST_BUG] 
java/awt/Component/PrintAllXcheckJNI/PrintAllXcheckJNI.java

 

On 09/20/2017 09:21 AM, Pankaj Bansal wrote:

Hi Seymon,

 

I think the issue is because no size is set on frame. This is also the proposed 
fix in the bug description.

This is good, but setting a fixed frame size forces the java Frame object to 
return that size only at the very beginning the real and final frame dimensions 
will be established  asynchronously by the native window subsystem.



Regards,

Pankaj

 

From: Semyon Sadetsky 
Sent: Wednesday, September 20, 2017 9:02 PM
To: Pankaj Bansal; HYPERLINK 
"mailto:awt-dev@openjdk.java.net"awt-dev@openjdk.java.net
Subject: Re:  [10] Review Request: JDK-6857809 : [TEST_BUG] 
java/awt/Component/PrintAllXcheckJNI/PrintAllXcheckJNI.java

 

Hi Pankaj,

The root cause of the issue is that the underling native window is not yet 
created when its with and height are requested. This is because windows are 
created asynchronously. The test should be fixed by adding Robot.waitForIdle() 
after frame.setVisible(true).

--Semyon

 

On 09/20/2017 05:49 AM, Pankaj Bansal wrote:

Hi All,

 

Please review the fix for test program test 
java/awt/Component/PrintAllXcheckJNI/PrintAllXcheckJNI.java for JDK 10.

 

Bug:

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

 

Webrev:

HYPERLINK 
"http://cr.openjdk.java.net/%7Eaghaisas/pankaj/6857809/webrev.0/"http://cr.openjdk.java.net/~aghaisas/pankaj/6857809/webrev.0/

 

Issue:

The test  java/awt/Component/PrintAllXcheckJNI/PrintAllXcheckJNI.java fails on 
Linux intermittently due to "java.lang.IllegalArgumentException: Width (0) and 
height (0) cannot be <= 0" exception.

 

Fix:

Made changes in java/awt/Component/PrintAllXcheckJNI/PrintAllXcheckJNI.java to 
set the size of frame to make the test more stable.

 

Regards,

Pankaj Bansal

 

 

Re: [10] Review Request: JDK-8081311 : [TEST_BUG] java/awt/ComponentOrientation/WindowTest.java

[Pankaj Bansal]

Hi Sergey/Semyon,

I have updated the webrev according to your comments. Please review.
Webrev:   http://cr.openjdk.java.net/~psadhukhan/pankaj/webrev/

Regards,
Pankaj Bansal

-Original Message-
From: Semyon Sadetsky 
Sent: Tuesday, September 19, 2017 8:40 PM
To: Sergey Bylokhov; Pankaj Bansal; awt-dev@openjdk.java.net
Subject: Re:  [10] Review Request: JDK-8081311 : [TEST_BUG] 
java/awt/ComponentOrientation/WindowTest.java

On 09/18/2017 11:04 AM, Sergey Bylokhov wrote:

> On 9/18/17 10:14, Semyon Sadetsky wrote:
>>> It is fine because it tests the ComponentOrientation class which is 
>>> loaded from the resource bundle and applied to the window.
>> I would agree with you if the resource bundle at least contained a 
>> value for the component orientation but it sets some specific locale 
>> codes. And java's locale functionality is not a subject of the 
>> client-libs, it is an another module. Also, as it was already pointed 
>> out, the method was deprecated long time ago.
>
> Where did you check these bundles? Because resource bundles for this 
> test contains the all variations of orientation 
> property(UNKNOWN/LEFT_TO_RIGHT/RIGHT_TO_LEFT/none).
OK. I missed those bundle classes with the orientation properties. I think the 
test may either be left as it is, or moved to the i18n suite with adding a test 
to ComponentOrientation suite that tests
applyComponentOrientation() directly.
>
>>>


 On 9/15/17 4:53 PM, Sergey Bylokhov wrote:
> I guess you missed something, the possibility to configure the 
> components via ResourceBudnle or locale is something different 
> that the hardcore the orientation in the application. And the fact 
> that this test found the bug in jdk9 just show that the test is 
> valid.
>
> On 9/15/17 16:29, Semyon Sadetsky wrote:
>> The component orientation test suite should use the right API, 
>> not the deprecated one. This was missed when the new API is created.
>> So the change is valid from this point with the corresponding 
>> comment in JIRA.
>>
>> --Semyon
>>
>> On 9/15/2017 3:09 PM, Sergey Bylokhov wrote:
>>>
>>> On 9/14/17 23:15, Pankaj Bansal wrote:
 This test is not failing with JDK 9_181 and JDK10 as methods 
 are deprecated not removed. It is giving lot of warning for 
 using deprecated things, so I made these changes. I think the 
 bug description should be changed to notify that.
>>>
>>> I am not sure that it is correct to replace one API to another 
>>> one. This test was written as part of i18n support and it checks 
>>> that our API can be configured by the ResourceBundles. The 
>>> updated test doing the different things - it checks that 
>>> getComponentOrientation will return the value which were set by 
>>> applyComponentOrientation().
>>>
>>> Since it was reported that the test failed because of some bug, 
>>> but looks like now it work as expected, this CR can be closed as 
>>> not reproducible. Or you can clean the test but without changing 
>>> its logic.
>>>

 Regards,
 Pankaj Bansal

 -Original Message-
 From: Sergey Bylokhov
 Sent: Thursday, September 14, 2017 11:30 PM
 To: Pankaj Bansal; awt-dev@openjdk.java.net
 Subject: Re:  [10] Review Request: JDK-8081311 : 
 [TEST_BUG] java/awt/ComponentOrientation/WindowTest.java

 Hi, Pankaj.
 Can you please clarify why this test fails on jdk9? This method 
 is deprecated but it was not removed, so it should work.
 Probably at some point of jdk9 development it was broken?

 On 9/14/17 03:25, Pankaj Bansal wrote:
> Hi All,
>
> Please review the fix for test program 
> test/java/awt/ComponentOrientation/WindowTest.java for JDK 10.
>
> Bug:
>
> https://bugs.openjdk.java.net/browse/JDK-8081311
>
> Webrev:
>
> http://cr.openjdk.java.net/~aghaisas/pankaj/8081311/webrev.0/
>
> Issue:
>
> The test java/awt/ComponentOrientation/WindowTest.java uses 
> depreciated function  applyResourceBundle. So the test should 
> be updated to use applyComponentOrientation function.
>
> Fix:
>
> Made changes in java/awt/ComponentOrientation/WindowTest.java
> to use
> applyComponentOrientation function and did corresponding changes.
> Along with that, the test is also using java.applet.Applet 
> which is also deprecated, so changed the test to use Frame 
> instead.
>
> Regards,
>
> Pankaj Bansal
>


 --
 Best regards, Sergey.

>>>
>>>
>>
>
>

>>>
>>>
>>
>
>

Re: [10] JDK-8148344: Java robot keypress should be able to use extended key code characters as ? ? ?.

[Shashidhara Veerabhadraiah]

Hi Sergey, I was able to input the surrogate pairs and got the required output 
as shown below:

 



 

 

Below is the output after we input the surrogate pairs:

 



 

Thanks and regards,

Shashi

 

 

-Original Message-
From: Sergey Bylokhov 
Sent: Thursday, September 14, 2017 11:33 PM
To: Shashidhara Veerabhadraiah ; Semyon 
Sadetsky ; awt-dev@openjdk.java.net
Subject: Re:  [10] JDK-8148344: Java robot keypress should be able to 
use extended key code characters as ? ? ?.

 

The java uses UTF16, I guess this new api should use it also, and we should 
check that the surrogate pairs will be supported.

 

On 9/14/17 03:56, Shashidhara Veerabhadraiah wrote:

> Hi Sergey, Yes it represents the Unicode code point. The encoding is same as 
> the window characteristic which is UTF 8 as implemented in Java.

> 

> Thanks and regards,

> Shashi

> 

> -Original Message-

> From: Sergey Bylokhov

> Sent: Wednesday, September 13, 2017 5:22 AM

> To: Shashidhara Veerabhadraiah 

>  "mailto:shashidhara.veerabhadra...@oracle.com"shashidhara.veerabhadra...@oracle.com>;
>  Semyon Sadetsky 

> mailto:semyon.sadet...@oracle.com"semyon.sadet...@oracle.com>; 
> HYPERLINK "mailto:awt-dev@openjdk.java.net"awt-dev@openjdk.java.net

> Subject: Re:  [10] JDK-8148344: Java robot keypress should be able 
> to use extended key code characters as ? ? ?.

> 

> Hi, Shashi.

> One initial question:

> What is an int parameter of these methods means, is it a "Unicode code 
> point"? What encoding utf8/utf16 should be used?

> 

> On 9/8/17 02:50, Shashidhara Veerabhadraiah wrote:

>> Hi, I have updated the Webrev to accommodate the comments and here is 

>> the new Webrev:

>> 

>> http://cr.openjdk.java.net/~sveerabhadra/8148344/webrev.01/

>> 

>> I have separated the /_Unicode_/ keys input via java robot as a new 

>> set of /_public_/ api’s (this is in similar fashion as how the 

>> platform offers the Unicode keys input into the system) and this has 

>> been tested on all the platforms using the test file similar to the 

>> attached file in the bug. A more proper test file would be put for 

>> review in the subsequent reviews.

>> 

>> Thanks and regards,

>> 

>> Shashi

>> 

>> *From:* Sergey Bylokhov

>> *Sent:* Wednesday, August 30, 2017 2:33 AM

>> *To:* Shashidhara Veerabhadraiah

>> > "mailto:shashidhara.veerabhadra...@oracle.com"shashidhara.veerabhadra...@oracle.com>

>> *Cc:* HYPERLINK "mailto:awt-dev@openjdk.java.net"awt-dev@openjdk.java.net

>> *Subject:* Re:  [10] JDK-8148344: Java robot keypress should 

>> be able to use extended key code characters as ? ? ?.

>> 

>> Hi, Shashi.

>> 

>> This is part of this fix, to figure out how it will work for external 

>> applications. As you said this functionally can be useful for an 

>> onscreen keyboards, which virtually can have any possible keys, but 

>> we should check how the applications will react on such keys:

>>    - Will the application get some kind of keyPress/Release?

>>    - Will the application get some keyCode for such event?

>>    - Is it possible to get autorepeat for such keys?(between

>> press/release)

>> 

>> Depending from the answers above we can enhance existed robot API or 

>> provide a new one:

>> like Robot.keyType(char)/etc

>> 

>> - HYPERLINK 
>> "mailto:shashidhara.veerabhadra...@oracle.com"shashidhara.veerabhadra...@oracle.com

>>  wrote:

>>> 

>> 

>>> 

>> 

>>> 

>> 

>> Hi Sergey, I was only able to add short cut keys in the Microsoft 

>> word but not as a system wide short cut key. There was no mechanism 

>> that I could find to add a short cut key for a Unicode char!! Can you 

>> please tell me the steps to do the same if you are aware of?

>> 

>> Thanks and regards,

>> 

>> shashi

>> 

>>> 

>> 

>> *From:*Sergey Bylokhov

>>> *Sent:* Tuesday, August 22, 2017 8:34 PM

>>> *To:* Shashidhara Veerabhadraiah

>>> > >

>>> *Cc:* HYPERLINK "mailto:awt-dev@openjdk.java.net"awt-dev@openjdk.java.net 
>>> 

>>> *Subject:* Re:  [10] JDK-8148344: Java robot keypress 

>>> should be

>> able to use extended key code characters as ? ? ?.

>> 

>> Hi, Shashi.

>>> Can you check how this Robot API will work when the application will have a 
>>> shortcut for such key? Will such shortcuts will work after this fix?

>>> 

>>> - HYPERLINK 
>>> "mailto:shashidhara.veerabhadra...@oracle.com"shashidhara.veerabhadra...@oracle.com

>>  wrote:

 

>> 

>>> 

>> 

>>> 

>> 

>> Hi All, Please review fix for the /_enhancement_/ wherein the robot 

>> key press of non-ascii were interpreted as question marks.

>> 

>> Issue: The robot key press events was handling only the ascii inputs 

>> and ignored the other Unicode inputs. Either