Re: [12] JDK-6849922: java/awt/Choice/ChoiceKeyEventReaction/ChoiceKeyEventReaction.html fails

[Shashidhara Veerabhadraiah]

Thank you Krishna and Sergey for the review.

-Original Message-
From: Sergey Bylokhov 
Sent: Thursday, November 15, 2018 3:13 AM
To: Shashidhara Veerabhadraiah ; Krishna 
Addepalli ; swing-...@openjdk.java.net; 
awt-dev@openjdk.java.net
Subject: Re:  [12] JDK-6849922: 
java/awt/Choice/ChoiceKeyEventReaction/ChoiceKeyEventReaction.html fails

Looks fine.


-- 
Best regards, Sergey.

Re: OpenJdk11-28-EA JDialog hanging

[Krishna Addepalli]

Hi Martin & Laurent,

Thank you for all your efforts in root causing and fixing this important issue.

Regards,
Krishna

> On 14-Nov-2018, at 11:16 PM, Martin Balao  wrote:
> 
> Hi,
> 
> Submit-repo tests passed.
> 
> Changeset has been committed:
> http://hg.openjdk.java.net/jdk/jdk/rev/08a0bf1592bd
> 
> Thanks to all of you for your time reviewing this.
> 
> I'll now propose a JDK-11 backport.
> 
> Kind regards,
> Martin.-

Re: FYI: new javadoc tag to document system properties

[Joseph D. Darcy]

Hello,

For future CSR requests involving system properties, please document the 
properties using these javadoc facilities.


Thanks,

-Joe

On 11/14/2018 2:27 PM, Jonathan Gibbons wrote:
This is an FYI to announce some initial, long-overdue support in 
javadoc for documenting system properties (JDK-5076751).


Currently, system properties are just documented using ad-hoc 
narrative text, which is fine if you know where to look for any given 
property.


JDK 12 introduces a new inline javadoc tag, {@systemProperty 
/property-name/} which can be used to "declare" the name of a system 
property. You can use this tag as a drop-in replacement for the 
plain-text property name; it will have no overt effect on the 
narrative text, but it will cause the property name to be put into the 
search index and the A-Z index. Thus, property names will become 
searchable, to allow users to easily find the definition of any such 
system property.


Adding support into javadoc is only part of the story. Now that the 
support is in javadoc, we want to update the API documentation, so 
that the documentation is updated for all Java SE and JDK system 
properties.


Where should the tag be used?  The tag should be used in the text of 
the defining instance of the property.  This is where the 
characteristics of the system property are described, which may 
include information like: "what is the property for", "how and when is 
it set", "can it be modified", and so on. For example, it could be 
used in the docs for System.getProperties [1] or Networking Properties 
[2] In general, it should -not- be used in situations that merely 
refer to the system property by name.  For example, the docs for 
Path.toAbsolutePath [3] make a reference to the system property 
user.dir, but that is not a definition of the property.


Going forward, in future releases, we expect to explore some 
enhancements to this feature. Here are some of the ideas that have 
been suggested:


 * Create a "summary page" that lists all the system properties. This
   would be somewhat similar to the current top-level "Constant Values"
   page.
 * Add information regarding the "scope" of the definition: is it
   defined by the Java SE specification, or JDK, or JavaFX, etc. This
   information could be used to organize the content on the summary page.
 * Update @see and {@link} to be able to refer to system properties.
 * Allow a short description to be included in the {@systemProperty}
   tag. This text could be included in the search index, the A-Z index,
   and the summary page.

-- Jon


[1]: 
https://docs.oracle.com/en/java/javase/11/docs/api/java.base/java/lang/System.html#getProperties()
[2]: 
https://docs.oracle.com/en/java/javase/11/docs/api/java.base/java/net/doc-files/net-properties.html
[3]: 
https://docs.oracle.com/en/java/javase/11/docs/api/java.base/java/nio/file/Path.html#toAbsolutePath()

FYI: new javadoc tag to document system properties

[Jonathan Gibbons]

This is an FYI to announce some initial, long-overdue support in javadoc 
for documenting system properties (JDK-5076751).


Currently, system properties are just documented using ad-hoc narrative 
text, which is fine if you know where to look for any given property.


JDK 12 introduces a new inline javadoc tag, {@systemProperty 
/property-name/} which can be used to "declare" the name of a system 
property. You can use this tag as a drop-in replacement for the 
plain-text property name; it will have no overt effect on the narrative 
text, but it will cause the property name to be put into the search 
index and the A-Z index. Thus, property names will become searchable, to 
allow users to easily find the definition of any such system property.


Adding support into javadoc is only part of the story. Now that the 
support is in javadoc, we want to update the API documentation, so that 
the documentation is updated for all Java SE and JDK system properties.


Where should the tag be used?  The tag should be used in the text of the 
defining instance of the property.  This is where the characteristics of 
the system property are described, which may include information like: 
"what is the property for", "how and when is it set", "can it be 
modified", and so on. For example, it could be used in the docs for 
System.getProperties [1] or Networking Properties [2] In general, it 
should -not- be used in situations that merely refer to the system 
property by name.  For example, the docs for Path.toAbsolutePath [3] 
make a reference to the system property user.dir, but that is not a 
definition of the property.


Going forward, in future releases, we expect to explore some 
enhancements to this feature. Here are some of the ideas that have been 
suggested:


 * Create a "summary page" that lists all the system properties. This
   would be somewhat similar to the current top-level "Constant Values"
   page.
 * Add information regarding the "scope" of the definition: is it
   defined by the Java SE specification, or JDK, or JavaFX, etc. This
   information could be used to organize the content on the summary page.
 * Update @see and {@link} to be able to refer to system properties.
 * Allow a short description to be included in the {@systemProperty}
   tag. This text could be included in the search index, the A-Z index,
   and the summary page.

-- Jon


[1]: 
https://docs.oracle.com/en/java/javase/11/docs/api/java.base/java/lang/System.html#getProperties()
[2]: 
https://docs.oracle.com/en/java/javase/11/docs/api/java.base/java/net/doc-files/net-properties.html
[3]: 
https://docs.oracle.com/en/java/javase/11/docs/api/java.base/java/nio/file/Path.html#toAbsolutePath()

Re: [12] JDK-6849922: java/awt/Choice/ChoiceKeyEventReaction/ChoiceKeyEventReaction.html fails

[Sergey Bylokhov]

Looks fine.


--
Best regards, Sergey.

Re: [12] JDK-7124285: Nothing heard from VoiceOver regarding the status of the progress bar

[Alexey Ivanov]

Hi Shashi,

First of all, I must emphasize that Swing has always been and is 
accessible by design. Phil replied to that part already. I just wanted 
to reiterate the same statement.


Please see my other comments inline:

On 08/11/2018 17:10, shashidhara.veerabhadra...@oracle.com wrote:
Hi Alexey, I totally understand your perspective and even I ran into 
some of those questions. Below are my responses!!


Thank you Alexey for bringing out unique issues pertaining to 
accessibility.


Thanks and regards,
shashi

On 08/11/18 10:00 PM, Alexey Ivanov wrote:

Hi Shashi,

On 08/11/2018 04:18, Shashidhara Veerabhadraiah wrote:
Hi Alexey, Thanks for running the test on Windows. With 
accessibility in question we should reach the component using the 
keyboard only. Touch and mouse is not permitted.


In this case each component must be focusable.
Can you reach each JLabel when using Tab? You can't (usually).
Typically the idea is to be reachable for disabled person and a 
component is must be accessible if a value needs to be entered. For 
ex., JLabel is next to a edit box and when the control goes to edit 
box, VO tells its an edit box and needs to enter something. One can 
set the accessible name for this edit box and the same will be told 
over VO. So in this case reaching Jlabel is not required.


Okay.

What if a JLabel at the top of the window contains instructions for the 
purpose of the dialog window. Without this information, it could be 
impossible to fill the form displayed in the dialog box.


So the question is can it be reached via a keyboard stroke? If not 
then that component is not accessible and that's the assessment.


I haven't searched for special keyboard shortcuts for Narrator.
What Sergey found is not general purpose but rather accessibility 
tool shortcuts. In that case, progress bar is still not accessible 
when using Tab, is it?

Yes, it is not accessible with TAB key strokes.


I have found the keyboard shorts for Narrator:
https://support.microsoft.com/en-gb/help/22806/windows-10-narrator-keyboard-commands-touch-gestures

Using it's shortcuts — Caps Lock + Left / Right array — I can select 
either progress bar in my test: both focusable and non-focusable. (Caps 
Lock is the default Narrator key referenced in the table.)


Caps Lock + W reads the entire window, highlighting each control and 
reading its current value. All non-focusable controls are included.



I have not tested it with JAWS though.

I could not reach to the progress bar(thro' keyboard) without 
explicitly setting the focusability 'on' it for both Windows and 
Mac. Sergey found a way to do it on Mac but I was not able to do the 
same. But with this fix, I see it working on both Windows and Mac.


But your fix also changes the behaviour for the case where no 
accessibility is used: progress bar receives keyboard focus even 
though it never needs it because it does not support any input.


It's just the other side of the coin.
Very true. The problem is that our software never designed from the 
accessibility stand point of view and we are trying to use the 
existing framework for a different purpose(focusability). Hence it 
leads to such confusions.


I meant this as a counterargument to making progress bar focusable.

Swing was designed with accessibility in mind. That's why each 
JComponent has AccessibleContext.


As far as I understand from another branch of this review, it works as 
expected. One has to use shortcut keys of the accessibility tool to 
"select" the progress bar so that its status is read.


I believe it's the way it's supposed to work.

To be clear: I don't object to making progress bar focusable in 
SwingSet2 if it's the only way to mitigate the problem. However, it 
does not feel right. That's why I'm trying to understand how other 
applications deal with this problem.
Yeah true. Adding an additional meaning to Focusability brings in such 
confusions. Ideal solution is to add certain framework for the 
accessibility point of view. But that's a long shot I believe.


I can't see any additional meaning added to focusability.
If a component is focusable, it can become the current focus owner and 
thus receive keyboard input.


It's exactly what happens in this case.
As a side effect, the current focus owner is read by VoiceOver, or 
another accessibility tool for that matter. It's pretty much expected: 
the user is supposed to interact with the current focus owner. If it 
wasn't announced by the accessibility tool, how would the user know the 
current focus owner has changed?



To sum up, it looks everything works as expected: VoiceOver reads the 
status of the progress bar once it's selected using shortcut keys of 
VoiceOver. So the test instructions should be updated to include these 
shortcut keys.


Progress bar should not be focusable. It should remain non-focusable as 
it has always been.



For Windows, we just need to find the right shortcuts.


Does it sound reasonable?

Regards,
Alexey

Re: Fwd: Re: RFR: 8212794 IBM-964 and IBM-29626C are required for AIX default charset

[Ichiroh Takiguchi]

I'm very sorry for your confusion, please ignore previous mail.
I posted it on wrong mailing list.

Ichiroh Takiguchi

On 2018-11-15 03:11, Ichiroh Takiguchi wrote:

Hello.

Martin Buchholz suggested me via bugs.openjdk.java.net,
I should not touch non AIX side.
So I rewrote another code.
Could you review the fix again ?

Bug:https://bugs.openjdk.java.net/browse/JDK-8212794
Change: https://cr.openjdk.java.net/~itakiguchi/8212794/webrev.01/

I don't want to touch non AIX side code, but I need to rename 3 files
to avoid compilation issue.
IBM33722.java -> IBM33722.java.template
IBM964.java -> IBM964.java.template
SimpleEUCEncoder.java -> SimpleEUCEncoder.java.template

Thanks,
Ichiroh Takiguchi
IBM Japan, Ltd.

 Original Message 
Subject: Re: RFR: 8212794 IBM-964 and IBM-29626C are required for AIX
default charset
Date: 2018-11-08 20:13
From: Volker Simonis 
To: Ichiroh Takiguchi 
Cc: Java Core Libs ,
ppc-aix-port-...@openjdk.java.net, "SHEN, XUEMING"
,Alan Bateman


Hi Ichiroh,

sorry, but unfortunately, this change is way beyond my level of 
expertise :)


You should try to get a review from Sherman or Alan.

Regards,
Volker
On Fri, Oct 26, 2018 at 3:33 PM Ichiroh Takiguchi
 wrote:


Hello.

Could you review the fix ?

Bug:https://bugs.openjdk.java.net/browse/JDK-8212794
Change: https://cr.openjdk.java.net/~itakiguchi/8212794/webrev.00/

I'd like to obtain a sponsor for this issue.


IBM964 charset and IBM29626C charset are required for default charset
on AIX zh_TW and ja_JP locale.
OpenJDK already has IBM964, but it could not be configured for default
charset.
IBM29626C is new one.
(IBM33722 extends IBM29626C class)

I knew IBM charsets would need to move to somewhere.
The discussion was started by "Adding new IBM extended charsets". [1]
But it's related default charset issue.
Please put them inside of OpenJDK.

About IBM964,
Bhaktavatsal started the discussion [2].
Sherman said that [3]
   the new model (open/make/data/charetmapping), instead of 
hard-coding

the map
   into the source code.

This fix only has small sized hard-coded mapping,
IBM964/IBM29626C/IBM33722 refer other charsets conversion table
which are using the new model.
And class file is smaller then before.
Still I used SimpleEUCEncoder class because it's stable.
I think we may re-write it by IBM charsets renewal.

Thanks,
Ichiroh Takiguchi
IBM Japan, Ltd.

[1]
http://mail.openjdk.java.net/pipermail/core-libs-dev/2018-July/054248.html
[2]
http://mail.openjdk.java.net/pipermail/core-libs-dev/2018-May/053050.html
[3]
http://mail.openjdk.java.net/pipermail/core-libs-dev/2018-May/053096.html

Fwd: Re: RFR: 8212794 IBM-964 and IBM-29626C are required for AIX default charset

[Ichiroh Takiguchi]

Hello.

Martin Buchholz suggested me via bugs.openjdk.java.net,
I should not touch non AIX side.
So I rewrote another code.
Could you review the fix again ?

Bug:https://bugs.openjdk.java.net/browse/JDK-8212794
Change: https://cr.openjdk.java.net/~itakiguchi/8212794/webrev.01/

I don't want to touch non AIX side code, but I need to rename 3 files
to avoid compilation issue.
IBM33722.java -> IBM33722.java.template
IBM964.java -> IBM964.java.template
SimpleEUCEncoder.java -> SimpleEUCEncoder.java.template

Thanks,
Ichiroh Takiguchi
IBM Japan, Ltd.

 Original Message 
Subject: Re: RFR: 8212794 IBM-964 and IBM-29626C are required for AIX 
default charset

Date: 2018-11-08 20:13
From: Volker Simonis 
To: Ichiroh Takiguchi 
Cc: Java Core Libs , 
ppc-aix-port-...@openjdk.java.net, "SHEN, XUEMING" 
,Alan Bateman 


Hi Ichiroh,

sorry, but unfortunately, this change is way beyond my level of 
expertise :)


You should try to get a review from Sherman or Alan.

Regards,
Volker
On Fri, Oct 26, 2018 at 3:33 PM Ichiroh Takiguchi
 wrote:


Hello.

Could you review the fix ?

Bug:https://bugs.openjdk.java.net/browse/JDK-8212794
Change: https://cr.openjdk.java.net/~itakiguchi/8212794/webrev.00/

I'd like to obtain a sponsor for this issue.


IBM964 charset and IBM29626C charset are required for default charset
on AIX zh_TW and ja_JP locale.
OpenJDK already has IBM964, but it could not be configured for default
charset.
IBM29626C is new one.
(IBM33722 extends IBM29626C class)

I knew IBM charsets would need to move to somewhere.
The discussion was started by "Adding new IBM extended charsets". [1]
But it's related default charset issue.
Please put them inside of OpenJDK.

About IBM964,
Bhaktavatsal started the discussion [2].
Sherman said that [3]
   the new model (open/make/data/charetmapping), instead of hard-coding
the map
   into the source code.

This fix only has small sized hard-coded mapping,
IBM964/IBM29626C/IBM33722 refer other charsets conversion table
which are using the new model.
And class file is smaller then before.
Still I used SimpleEUCEncoder class because it's stable.
I think we may re-write it by IBM charsets renewal.

Thanks,
Ichiroh Takiguchi
IBM Japan, Ltd.

[1]
http://mail.openjdk.java.net/pipermail/core-libs-dev/2018-July/054248.html
[2]
http://mail.openjdk.java.net/pipermail/core-libs-dev/2018-May/053050.html
[3]
http://mail.openjdk.java.net/pipermail/core-libs-dev/2018-May/053096.html

Re: RFR: 8213614 DnD operation change feature does not work with 64bit big endian CPU

[Ichiroh Takiguchi]

Hello Sergey.
Thank you for your review.

As you told me, I could find out some "(int)Native.getLong()".
I'm not sure, I checked them before or not.
I'll get back to you.

Thanks,

On 2018-11-14 05:43, Sergey Bylokhov wrote:

This change looks fine, I'll push it if there are no any objections.

BTW we have some other places where we use the similar approach:
"(int)Native.getLong()", I assume we need to update it also?

On 09/11/2018 04:01, Ichiroh Takiguchi wrote:

Hello,
IBM would like to contribute this patch to OpenJDK project.

Bug:    https://bugs.openjdk.java.net/browse/JDK-8213614
Change: https://cr.openjdk.java.net/~itakiguchi/8213614/webrev.00/

Issue:
This issue only happens on 64bit big endian CPU.
Keyboard's key data is 32bit, but current code picks up it for 64bit 
data

and casted for 32bit data.
This operation works on little endian CPU, but it does not work on BIG 
endian CPU.


Test instruction is in JDK-8213614.

I'd like to obtain a sponsor for this issue.

Thanks,
Ichiroh Takiguchi
IBM Japan, Ltd.

Re: OpenJdk11-28-EA JDialog hanging

[Martin Balao]

Hi,

Submit-repo tests passed.

Changeset has been committed:
http://hg.openjdk.java.net/jdk/jdk/rev/08a0bf1592bd

Thanks to all of you for your time reviewing this.

I'll now propose a JDK-11 backport.

Kind regards,
Martin.-

Re: [12] JDK-7124285: Nothing heard from VoiceOver regarding the status of the progress bar

[Alexey Ivanov]

Hi Shashi,

I absolutely agree with Sergey: the component must be accessible even if 
it's not focusable.

And I don't quite understand what you're talking about.

The person who uses an accessibility tool will use the shortcuts of the 
tool to navigate controls in the window.


Tab key, on the other hand, serves different purpose: it moves input 
focus between interactive components which accept user's input. As 
expected, the accessibility tool announces the change of the focused 
component.


Thus, when you make the progress bar focusable, you can set input focus 
to it. It's just a side effect.
At the same time, progress bar accepts no input. It should stay 
non-focusable. Otherwise, it's confusing for both users: those who 
prefer to use keyboard to navigate between components and those who use 
accessibility tools.



Can you get the status of the progress bar using VoiceOver shortcuts on 
macOS?
If yes, we're done. If not, we have to understand why the progress bar 
cannot be selected with VoiceOver.



For Windows, Sergey provided the link to JAWS shortcuts:
https://www.freedomscientific.com/Content/Documents/Manuals/JAWS/Keystrokes.txt
Search for "For Dialog Boxes" section.

Insert+B or CapsLock+B (the latter is for laptops) should read the 
entire window from top to bottom. It should also read the state of the 
progress bar.


Insert+Tab or CapsLock+Tab is Announce Progress Bar Status

There should be a key shortcut to navigate between all controls.
Do Shift+Period and Shift+Comma work?


Regards,
Alexey

On 14/11/2018 07:00, Shashidhara Veerabhadraiah wrote:

All swing components has accessibility info associated with it. But how those 
information is received thro' AT matters.

For ex., one can use the control+option(system accessibility shortcuts) on the 
progress bar demo but you can't use it in the option pane demo. You can't reach 
'show input dialog' and other buttons in that pane. You are forced to use the 
TAB keys(java options) there.
It looks like TAB keys are delivered to the window(consumed for focus traversal 
purpose) and I don't think the control+option keys are delivered to the window 
but instead platform accessibility sub system consumes it and reads the backend 
swift component's accessibility info there. Whenever  a accessibility info of a 
component is reached using the system short cut we would see a black rectangle 
covering that component whereas it is not the same for TAB key based traversal 
within the option pane demo(as it is consumed by java window).
So to conclude within some of our custom components, TAB key is the only way of 
traversal and am not sure why the system short cut fails to navigate such 
components though.

Thanks and regards,
Shashi

-Original Message-
From: Sergey Bylokhov
Sent: Tuesday, November 13, 2018 6:09 AM
To: Shashidhara Veerabhadraiah ; 
awt-dev@openjdk.java.net; swing-...@openjdk.java.net
Subject: Re:  [12] JDK-7124285: Nothing heard from VoiceOver 
regarding the status of the progress bar

On 11/11/2018 05:30, shashidhara.veerabhadra...@oracle.com wrote:

This fix works for both windows and mac. Mac may have a short cut to ignore 
such things but we still need to solve the problem for windows and for mac(for 
TAB key traversal case). TAB key is consumed by java swing for traversal 
purpose and hence TAB key traversal is assumed to work for accessibility case 
as well and it does work for with this fix. So why deny that?

Hope this answers your question. Accessibility is a new area to explore here 
for everyone I think and am also learning along with these fixes. So please let 
me know if you have any more questions.

This assumption is wrong, the components should be accessible even they are 
have a focus or not, can be focused or not, editable or not, enabled or not, in 
all these cases the accessibility tool should be able to provide this 
information to the user.


--
Best regards, Sergey.

Re: RFR 8213532: add missing LocalFree calls after using FormatMessage(A) [windows]

[Baesken, Matthias]

Thanks for  the review,   pushed to  the client repo .

Best regards, Matthias


> Hi Matthias,
> 
> The fix looks good.
> 
> Thanks,
> Dmitry
> 
> > On 14 Nov 2018, at 07:48, Baesken, Matthias
>  wrote:
> >
> > Hi  Sergey,  thanks for  the review !
> >
> > Could I have a second review please,  before I push the change ?
> >
> > Best regards, Matthias
> >
> >

Re: Review request for: JDK-8213292 Input freezes after MacOS key-selector (press) usage on macOS Mojave

[Alexey Ushakov]

Thanks, Sergey!

One more thing, looks like I need a sponsor. I don’t have commit rights for the 
latest releases.

Best Regards,
Alexey

> On 13 Nov 2018, at 21:38, Sergey Bylokhov  wrote:
> 
> Looks fine.
> 
> On 08/11/2018 01:40, Alexey Ushakov wrote:
>> I’ve checked the fix on 10.13. Looks like it works as well. So, here is 
>> updated webrev:
>> http://cr.openjdk.java.net/~avu/JDK-8213292/webrev.01
>> Best Regards,
>> Alexey
>>> On 8 Nov 2018, at 01:12, Sergey Bylokhov >> > wrote:
>>> 
 I’ll check the fix on macOS 10.13 or lower but I prefer not to touch 
 working code :), so decided to limit the fix impact to only 10.14
>>> The problem with such changes is that nobody will drop the OS-check, 
>>> because of the same reason, and it will be there forever.
>>> I suggest to recheck it on 10.13 and drop the OS-check if it works properly.
>>> 
>>> 
>>> -- 
>>> Best regards, Sergey.
> 
> 
> -- 
> Best regards, Sergey.

Re: RFR 8213532: add missing LocalFree calls after using FormatMessage(A) [windows]

[Dmitry Markov]

Hi Matthias,

The fix looks good.

Thanks,
Dmitry

> On 14 Nov 2018, at 07:48, Baesken, Matthias  wrote:
> 
> Hi  Sergey,  thanks for  the review !
> 
> Could I have a second review please,  before I push the change ?
> 
> Best regards, Matthias
> 
> 
>> -Original Message-
>> From: Sergey Bylokhov 
>> Sent: Freitag, 9. November 2018 21:50
>> To: Baesken, Matthias ; awt-
>> d...@openjdk.java.net
>> Subject: Re: RFR 8213532: add missing LocalFree calls after using
>> FormatMessage(A) [windows] - was RE:  FW: RFR [XS] : 8213366:
>> (fs) avoid handle leak in
>> Java_sun_nio_fs_WindowsNativeDispatcher_FindFirstFile0
>> 
>> Looks fine.
>> 
>> On 08/11/2018 08:20, Baesken, Matthias wrote:
>>> Hello, looks like I used the wrong DTRACE_PRINTLN* call  at one place in
>> src/java.desktop/windows/native/libawt/windows/ThemeReader.cpp .
>>> New webrev :
>>> 
>>> http://cr.openjdk.java.net/~mbaesken/webrevs/8213532.1/
>>> 
>>> Regards, Matthias
>>> 
>>> 
>