From krishna.addepalli at oracle.com  Fri Mar  1 06:45:38 2019
From: krishna.addepalli at oracle.com (Krishna Addepalli)
Date: Fri, 1 Mar 2019 12:15:38 +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: <cf24cc5e-b918-d460-96c2-37805152c708@oracle.com>
References: <3412A11C-7C9B-4661-8E24-410F31403C86@oracle.com>
 <CANTFZ2iVoK0rQYMeaPLcZVPsUDucDWwxW=_PPCuxMSvq0+0WJA@mail.gmail.com>
 <CANTFZ2hGFehNZdg5fwdo+PQfPEVNVd6QA9p7O37CAL27mKzKWg@mail.gmail.com>
 <cf24cc5e-b918-d460-96c2-37805152c708@oracle.com>
Message-ID: <C24C3098-9BE5-4CE1-877F-F5A7EBDDA310@oracle.com>

Hi Sergey Malenkov,

Thank you for pointing this out. This issue is also reported in JDK-8218917. I?m looking into the issue.

Thanks,
Krishna

> On 01-Mar-2019, at 2:45 AM, Sergey Bylokhov <Sergey.Bylokhov at oracle.com> wrote:
> 
> Hi, Sergey.
> 
> Do you have bugid for this issue?
> 
> On 28/02/2019 09:35, Sergey Malenkov wrote:
>> The following change fixes the critical problem for us, but I do not
>> like this solution.
>> I think that  leftAltKeyPressed  and  altGRPressed  should be more consistent.
>> Index: src/java.desktop/macosx/native/libawt_lwawt/awt/AWTEvent.m
>> IDEA additional info:
>> Subsystem: com.intellij.openapi.diff.impl.patch.CharsetEP
>> <+>UTF-8
>> ===================================================================
>> --- src/java.desktop/macosx/native/libawt_lwawt/awt/AWTEvent.m
>> (revision 07bf36928d2435d60c4cf38ece9773e54a9f6cde)
>> +++ src/java.desktop/macosx/native/libawt_lwawt/awt/AWTEvent.m (date
>> 1551368901289)
>> @@ -746,6 +746,7 @@
>>                  *javaKeyLocation = java_awt_event_KeyEvent_KEY_LOCATION_RIGHT;
>>              } else if (cur->nsMask == NSAlternateKeyMask) {
>>                  leftAltKeyPressed = NO;
>> +                altGRPressed = NO;
>>                  continue;
>>              }
>>              *javaKeyType = (cur->nsMask & nsFlags) ?
>> On Thu, Feb 28, 2019 at 8:12 PM Sergey Malenkov <malenkov at gmail.com> wrote:
>>> 
>>> ATTENTION!
>>> 
>>> This old fix breaks Java UI 11 on macOS Mojave.
>>> If you press RightAlt once, you never receive event with LeftAlt.
>>> Note that static altGRPressed = NO is switched to YES, but never to NO.
>>> 
>>> Could you please improve your fix and add a test
>>> that Alt-events are not changed after pressing/releasing right Alt?
>>> 
>>> Thanks,
>>> SAM
>>> 
>>> 
>>> --
>>> Best regards,
>>> Sergey A. Malenkov
> 
> 
> -- 
> Best regards, Sergey.


From malenkov at gmail.com  Fri Mar  1 10:43:48 2019
From: malenkov at gmail.com (Sergey Malenkov)
Date: Fri, 1 Mar 2019 13:43:48 +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: <cf24cc5e-b918-d460-96c2-37805152c708@oracle.com>
References: <3412A11C-7C9B-4661-8E24-410F31403C86@oracle.com>
 <CANTFZ2iVoK0rQYMeaPLcZVPsUDucDWwxW=_PPCuxMSvq0+0WJA@mail.gmail.com>
 <CANTFZ2hGFehNZdg5fwdo+PQfPEVNVd6QA9p7O37CAL27mKzKWg@mail.gmail.com>
 <cf24cc5e-b918-d460-96c2-37805152c708@oracle.com>
Message-ID: <CANTFZ2h5f=1SyvMUP5k2+DpMah5EjvdGchtOqX0Kxiq8EkwuyQ@mail.gmail.com>

Hello, Sergey!

> Do you have bugid for this issue?
Not yet. I'll file an issue soon.

Regards,
SAM

On Fri, Mar 1, 2019 at 12:15 AM Sergey Bylokhov
<Sergey.Bylokhov at oracle.com> wrote:
>
> Hi, Sergey.
>
> Do you have bugid for this issue?
>
> On 28/02/2019 09:35, Sergey Malenkov wrote:
> > The following change fixes the critical problem for us, but I do not
> > like this solution.
> > I think that  leftAltKeyPressed  and  altGRPressed  should be more consistent.
> >
> >
> > Index: src/java.desktop/macosx/native/libawt_lwawt/awt/AWTEvent.m
> > IDEA additional info:
> > Subsystem: com.intellij.openapi.diff.impl.patch.CharsetEP
> > <+>UTF-8
> > ===================================================================
> > --- src/java.desktop/macosx/native/libawt_lwawt/awt/AWTEvent.m
> > (revision 07bf36928d2435d60c4cf38ece9773e54a9f6cde)
> > +++ src/java.desktop/macosx/native/libawt_lwawt/awt/AWTEvent.m (date
> > 1551368901289)
> > @@ -746,6 +746,7 @@
> >                   *javaKeyLocation = java_awt_event_KeyEvent_KEY_LOCATION_RIGHT;
> >               } else if (cur->nsMask == NSAlternateKeyMask) {
> >                   leftAltKeyPressed = NO;
> > +                altGRPressed = NO;
> >                   continue;
> >               }
> >               *javaKeyType = (cur->nsMask & nsFlags) ?
> >
> >
> >
> > On Thu, Feb 28, 2019 at 8:12 PM Sergey Malenkov <malenkov at gmail.com> wrote:
> >>
> >> ATTENTION!
> >>
> >> This old fix breaks Java UI 11 on macOS Mojave.
> >> If you press RightAlt once, you never receive event with LeftAlt.
> >> Note that static altGRPressed = NO is switched to YES, but never to NO.
> >>
> >> Could you please improve your fix and add a test
> >> that Alt-events are not changed after pressing/releasing right Alt?
> >>
> >> Thanks,
> >> SAM
> >>
> >>
> >> --
> >> Best regards,
> >> Sergey A. Malenkov
> >
> >
> >
>
>
> --
> Best regards, Sergey.



-- 
Best regards,
Sergey A. Malenkov

From takiguc at linux.vnet.ibm.com  Fri Mar  1 13:16:24 2019
From: takiguc at linux.vnet.ibm.com (Ichiroh Takiguchi)
Date: Fri, 01 Mar 2019 22:16:24 +0900
Subject: <AWT Dev> RFR: 8212676 AIX's CDE/MWM support
In-Reply-To: <ad8f6c895b66c65a0b7bc344c5a759e0@linux.vnet.ibm.com>
References: <5f309d9c612f2c16aef75846e0ff14fa@linux.vnet.ibm.com>
 <d2b3bc94-0ba3-712f-c46b-f83048491cb0@oracle.com>
 <f942c133e212bace34e72e79bfb64ab4@linux.vnet.ibm.com>
 <0ede447e30ed05ce7a52f6d133b2c15b@linux.vnet.ibm.com>
 <180114e58e98f339332e3a781a34126b@linux.vnet.ibm.com>
 <d9e8c69e64ff87bb84a9468b4364fb06@linux.vnet.ibm.com>
 <5a4f9f5c7a80a5abda9edd150e19a11f@linux.vnet.ibm.com>
 <4addeebf-9ed8-bb63-5920-49ae6fb429b1@oracle.com>
 <c314e88dcc25495f6fba698f8ad5ae63@linux.vnet.ibm.com>
 <5C0725B5.3080907@oracle.com> <5C0773E7.8030108@oracle.com>
 <ad8f6c895b66c65a0b7bc344c5a759e0@linux.vnet.ibm.com>
Message-ID: <13a9685a38984c56ec2f0aaa084a3f80@linux.vnet.ibm.com>

Hello.

Could you review the fix again ?

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

I applied following changes:
* I added AIX detection code into sun.awt.OSInfo class.
   It seems CDE's default should be middle color.
   But AIX's default is high color, so AIX detection code is required.
* MWM detection code can be used on Linux and AIX platform
   AIX only code was removed
* I could not recreate XMapRaised/XMapWindow related issue.
   The fix was ignored
* Non-focusable window handling on DTWM/MWM
   I checked Linux's MWM working behavior on RHEL6.
   I applied AIX's code into Linux side, but it was bad.
   Working behavior became worse.
   So AIX detection feature is still required.

(JDK-8212676 was also updated)

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

Thanks,
Ichiroh Takiguchi
IBM Japan, Ltd.

On 2018-12-05 18:22, Ichiroh Takiguchi wrote:
> Hello Phil.
> 
> I heard some of AIX users used RealVNC VNC Enterprise Edition for AIX
> maintenance. [1]
> I assume they still use CDE.
> 
> [1] https://www.realvnc.com/en/connect/download/vnc/aix/#older-versions
> 
> Thanks,
> Ichiroh Takiguchi
> 
> On 2018-12-05 15:44, Philip Race wrote:
>> . and I think I need to be convinced about whether "aix" is the right
>> thing to check here.
>> "I know AIX works like this today" isn't a very robust, or very
>> portable approach.
>> The fix is more about the CDE/Motif environment than AIX, isn't it ?
>> 
>> -phil.
>> 
>> 
>> On 12/4/18, 5:11 PM, Philip Race wrote:
>>> 
>>> 
>>> On 12/4/18, 5:10 PM, Ichiroh Takiguchi wrote:
>>>> Hello Phil.
>>>> 
>>>>> I haven't evaluated the merits of this proposal but this
>>>>> https://cr.openjdk.java.net/~itakiguchi/8212676/webrev.00/src/java.desktop/share/classes/sun/font/FontUtilities.java.udiff.html 
>>>>> is not the right place to support a flag used in all these X11 
>>>>> files.
>>>> Could you give me your recommendation ?
>>> 
>>> Somewhere closer to the code that needs it.
>>>> 
>>>>> And why is i18n-dev on the review ? I can't see any I18N related 
>>>>> changes.
>>>> I thought focus issue was related input method.
>>> 
>>> No. I mean input focus is necessary for input methods but focus does 
>>> not
>>> automatically mean input methods are in play.
>>> 
>>> -phil
>>> 
>>>> AIX IM was activated even if focus was moved to non focusable window 
>>>> (middle window). [1]
>>>> So I posted this issue into I18N, but it was not good.
>>>> Actually, all key events were forwarded to middle window if user 
>>>> clicked inside of right window.
>>>> 
>>>> [1] 
>>>> https://bugs.openjdk.java.net/secure/attachment/79986/aix-focusable.png
>>>> 
>>>> Thanks,
>>>> Ichiroh Takiguchi
>>>> 
>>>> On 2018-12-05 03:06, Phil Race wrote:
>>>>> I haven't evaluated the merits of this proposal but this
>>>>> https://cr.openjdk.java.net/~itakiguchi/8212676/webrev.00/src/java.desktop/share/classes/sun/font/FontUtilities.java.udiff.html 
>>>>> is not the right place to support a flag used in all these X11 
>>>>> files.
>>>>> 
>>>>> And why is i18n-dev on the review ? I can't see any I18N related 
>>>>> changes.
>>>>> 
>>>>> -phil.
>>>>> 
>>>>> On 12/4/18 8:53 AM, Ichiroh Takiguchi wrote:
>>>>>> Hello again.
>>>>>> 
>>>>>> Could you give me review comment and/or suggestion ?
>>>>>> 
>>>>>> Bug:    https://bugs.openjdk.java.net/browse/JDK-8212676
>>>>>> Change: https://cr.openjdk.java.net/~itakiguchi/8212676/webrev.00/
>>>>>> 
>>>>>> Thanks,
>>>>>> Ichiroh Takiguchi
>>>>>> 
>>>>>> On 2018-11-26 21:27, Ichiroh Takiguchi wrote:
>>>>>>> Hello.
>>>>>>> 
>>>>>>> Could you review the fix ?
>>>>>>> 
>>>>>>> Bug:    https://bugs.openjdk.java.net/browse/JDK-8212676
>>>>>>> Change: 
>>>>>>> https://cr.openjdk.java.net/~itakiguchi/8212676/webrev.00/
>>>>>>> 
>>>>>>> Test instructions and screen shots are in JDK-8212676.
>>>>>>> 
>>>>>>> GUI environment for AIX platform still needs CDE support.
>>>>>>> This fix is required to avoid unexpected working behavior on AIX 
>>>>>>> platform.
>>>>>>> 
>>>>>>> I'd like to obtain a sponsor for this issue.
>>>>>>> 
>>>>>>> Thanks,
>>>>>>> Ichiroh Takiguchi
>>>>>>> IBM Japan, Ltd.
>>>>>>> 
>>>>>>> On 2018-06-18 18:57, Ichiroh Takiguchi wrote:
>>>>>>>> Hello.
>>>>>>>> 
>>>>>>>> This fix is really required for AIX's GUI.
>>>>>>>> System color setting and window manager's working behavior are 
>>>>>>>> very important.
>>>>>>>> 
>>>>>>>> I appreciate any feedback, and how I would go about obtaining a
>>>>>>>> sponsor and contributor ?
>>>>>>>> 
>>>>>>>> On 2018-05-25 11:02, Ichiroh Takiguchi wrote:
>>>>>>>>> Hello Phil.
>>>>>>>>> 
>>>>>>>>> webrev file was extracted.
>>>>>>>>> Please see
>>>>>>>>>   http://cr.openjdk.java.net/~aleonard/AIX_GUI/webrev.00/
>>>>>>>>> 
>>>>>>>>> On 2018-05-19 02:48, Ichiroh Takiguchi wrote:
>>>>>>>>>> Hello Phil.
>>>>>>>>>> 
>>>>>>>>>> Webrev.zip file is stored into
>>>>>>>>>> http://cr.openjdk.java.net/~aleonard/AIX_GUI/webrev-aixgui.zip
>>>>>>>>>> 
>>>>>>>>>> Test programs are also stored:
>>>>>>>>>> No testcase is available for FontUtilities.java and 
>>>>>>>>>> XDecoratedPeer.java.
>>>>>>>>>> 
>>>>>>>>>> MotifColorUtilities.java
>>>>>>>>>> http://cr.openjdk.java.net/~aleonard/AIX_GUI/SystemColorTest2.java
>>>>>>>>>> Run SystemColorTest2, system colors should be displayed
>>>>>>>>>> AIX sample is
>>>>>>>>>> http://cr.openjdk.java.net/~aleonard/AIX_GUI/aix_systemcolor.txt
>>>>>>>>>> 
>>>>>>>>>> XWM.java
>>>>>>>>>> http://cr.openjdk.java.net/~aleonard/AIX_GUI/XWMTest1.java
>>>>>>>>>> On AIX CDE, isMotif and isCDE were true.
>>>>>>>>>> On AIX MWM, every entry is false.
>>>>>>>>>> 
>>>>>>>>>> XWindowPeer.java
>>>>>>>>>> http://cr.openjdk.java.net/~aleonard/AIX_GUI/JFrameTest.java
>>>>>>>>>> On AIX CDE, click inside of "Non-Focusable" window (not window 
>>>>>>>>>> frame).
>>>>>>>>>> Window focus should not be changed because of "click on focus" 
>>>>>>>>>> feature.
>>>>>>>>>> But input focus is moved to "Non-Focusable" window.
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> On 2018-05-18 01:00, Phil Race wrote:
>>>>>>>>>>> I think we'd need to see the actual proposed changes and 
>>>>>>>>>>> understand
>>>>>>>>>>> the implications
>>>>>>>>>>> for ongoing support as we no longer support any platform 
>>>>>>>>>>> which has a
>>>>>>>>>>> CDE desktop.
>>>>>>>>>>> Solaris 11.3 uses Gnome, so we'd be more inclined to be 
>>>>>>>>>>> ripping out
>>>>>>>>>>> such support rather
>>>>>>>>>>> than adding to it.
>>>>>>>>>>> 
>>>>>>>>>>> -phil.
>>>>>>>>>>> 
>>>>>>>>>>> On 05/17/2018 04:18 AM, Ichiroh Takiguchi wrote:
>>>>>>>>>>>> Hello,
>>>>>>>>>>>> IBM would like to contribute AIX's CDE (Common Desktop 
>>>>>>>>>>>> Environment) DTWM (Desktop Window Manager) /MWM (Motif 
>>>>>>>>>>>> Window Manager) support to OpenJDK project.
>>>>>>>>>>>> 
>>>>>>>>>>>> I'd like contribute following 5 files:
>>>>>>>>>>>> 
>>>>>>>>>>>> M src/java.desktop/share/classes/sun/font/FontUtilities.java
>>>>>>>>>>>> (Add isAIX flag to determine AIX platform for GUI 
>>>>>>>>>>>> environment)
>>>>>>>>>>>> M 
>>>>>>>>>>>> src/java.desktop/unix/classes/sun/awt/X11/MotifColorUtilities.java 
>>>>>>>>>>>> (Add High Color support on CDE, OpenJDK just supports Medium 
>>>>>>>>>>>> Color) [1]
>>>>>>>>>>>> M 
>>>>>>>>>>>> src/java.desktop/unix/classes/sun/awt/X11/XDecoratedPeer.java
>>>>>>>>>>>> (Avoid miss calculation for window position under DTWM/MWM 
>>>>>>>>>>>> by XMapRaised/XMapWindow)
>>>>>>>>>>>> M src/java.desktop/unix/classes/sun/awt/X11/XWM.java
>>>>>>>>>>>> (Detect MWM on AIX platform)
>>>>>>>>>>>> M src/java.desktop/unix/classes/sun/awt/X11/XWindowPeer.java
>>>>>>>>>>>> (Add non-focusable window support on DTWM/MWM for AIX, 
>>>>>>>>>>>> because DTWM/MWM does not have enough features for ICCCM)
>>>>>>>>>>>> 
>>>>>>>>>>>> I appreciate any feedback please, and how I would go about 
>>>>>>>>>>>> obtaining a sponsor and contributor ?
>>>>>>>>>>>> 
>>>>>>>>>>>> Thanks,
>>>>>>>>>>>> Ichiroh Takiguchi
>>>>>>>>>>>> IBM Japan, Ltd.
>>>>>>>>>>>> 
>>>>>>>>>>>> [1] 
>>>>>>>>>>>> https://docs.oracle.com/cd/E19253-01/806-7492/fontsandcolors-15233/index.html
>>>>>>>>>>>> 
>>>>>> 
>>>> 


From alexey.ivanov at oracle.com  Fri Mar  1 20:25:59 2019
From: alexey.ivanov at oracle.com (Alexey Ivanov)
Date: Fri, 1 Mar 2019 20:25:59 +0000
Subject: <AWT Dev> <Swing Dev> [12] JDK-8182043: Access to Windows Large
 Icons
In-Reply-To: <5a617257-eaba-4e30-a1e5-60e1f7a01b10@default>
References: <261fe40d-a8ed-4b12-9017-81fd8e9efef2@default>
 <4cc06fa7-7406-ece0-0527-46d566d701a1@oracle.com>
 <934606c2-3a79-4ae5-b041-3fa1b6a9fd99@default>
 <378efc00-ae1a-4e9c-861e-e563657486ce@default>
 <d0b98261-9ae3-19dc-7b6a-76de2e99c3c8@oracle.com>
 <b9b6bb78-3e3c-4924-92a6-026943e5b79c@default>
 <02c13573-f2ef-4275-7468-c53b54310ef0@oracle.com>
 <a706ab54-6054-4954-a369-d35986f1a19f@default>
 <23897cf4-5068-641b-3b38-4de185796341@oracle.com>
 <5a617257-eaba-4e30-a1e5-60e1f7a01b10@default>
Message-ID: <797327a1-86c9-6726-3f08-83ed3900af11@oracle.com>

Hi Shashi,

Sorry for my belated review.

On 22/01/2019 18:03, Shashidhara Veerabhadraiah wrote:
>
> Hi All, Please review the below new fix compared to earlier webrevs. 
> Now the new api to get the icons of different sizes is being made part 
> of a new class SystemIcon. Please consider this as a different 
> solution than the one that was under review for a long time till now.
>
> http://cr.openjdk.java.net/~sveerabhadra/8182043/webrev.05/
>

This version looks cleaner.

The new SystemIcon class contains only one method, getSystemIcon. Does 
it justify creating a new class for this? Can't we add this extended 
version into FileSystemView class?

FileSystemView has method:
public Icon getSystemIcon(File f)

We're extending it with
public Icon getSystemIcon(File f, int size)

Are there any objections to this approach?


The class name, if we're going this route, could be more specific: 
FileSystemIcon seems a better alternative.


Javadoc for SystemIcon says, ?SystemIcon is JFileChooser's gateway to 
the file system icons.? Yet JFileChooser uses 
FileSystemView.getSystemIcon(File). So Javadoc is not accurate at the 
very least.

There should also be @since tag for the class.

As this is a new API, I think it makes sense to throw 
IllegalArgumentException for invalid parameters: file == null or size is 
out of supported range.

You don't usually want to print exception stack trace or messages from a 
public API:
74???????????? System.err.println("FileSystemView.getShellFolder: f="+f);
75???????????? e.printStackTrace();

As Phil mentioned, you should clearly state when a null value can be 
returned.


static public Icon getSystemIcon(File f, int size)
should be
public static Icon getSystemIcon(File f, int size)

At this time, SystemIcon is an utility class which provides only static 
methods. Yet it can be instantiated which does not look good.
The code indents by three spaces instead of four.

Win32ShellFolder2.java
1111???? public Image getIcon(int size) {
The method should have @Override annotation.

It can also be added to
1040???? public Image getIcon(final boolean getLargeIcon) {


Win32ShellFolderManager2.java
383????????????????????????? key.startsWith("shell32LargeIcon 
")?LARGE_ICON_SIZE : SMALL_ICON_SIZE);

There should be spaces around ???.


> Part of the fix is being borrowed from Semyon?s fix and would like to 
> thank Semyon for that.
>

You can give Semyon attribution by including "Contributed-by" tag in 
your commit message and referencing Semyon and yourself there.


Regards,
Alexey

> Thanks and regards,
>
> Shashi
>
> <SNIP>


From philip.race at oracle.com  Fri Mar  1 20:40:20 2019
From: philip.race at oracle.com (Phil Race)
Date: Fri, 1 Mar 2019 12:40:20 -0800
Subject: <AWT Dev> <Swing Dev> [12] JDK-8182043: Access to Windows Large
 Icons
In-Reply-To: <797327a1-86c9-6726-3f08-83ed3900af11@oracle.com>
References: <261fe40d-a8ed-4b12-9017-81fd8e9efef2@default>
 <4cc06fa7-7406-ece0-0527-46d566d701a1@oracle.com>
 <934606c2-3a79-4ae5-b041-3fa1b6a9fd99@default>
 <378efc00-ae1a-4e9c-861e-e563657486ce@default>
 <d0b98261-9ae3-19dc-7b6a-76de2e99c3c8@oracle.com>
 <b9b6bb78-3e3c-4924-92a6-026943e5b79c@default>
 <02c13573-f2ef-4275-7468-c53b54310ef0@oracle.com>
 <a706ab54-6054-4954-a369-d35986f1a19f@default>
 <23897cf4-5068-641b-3b38-4de185796341@oracle.com>
 <5a617257-eaba-4e30-a1e5-60e1f7a01b10@default>
 <797327a1-86c9-6726-3f08-83ed3900af11@oracle.com>
Message-ID: <72fea0a5-51de-5670-1a86-831bf2f8a362@oracle.com>

Alexey,

We already nixed this approach
See https://mail.openjdk.java.net/pipermail/awt-dev/2019-January/014972.html

Shashi is re-thinking it to use MultiResolutionImage.

-phil.

On 3/1/19 12:25 PM, Alexey Ivanov wrote:
> Hi Shashi,
>
> Sorry for my belated review.
>
> On 22/01/2019 18:03, Shashidhara Veerabhadraiah wrote:
>>
>> Hi All, Please review the below new fix compared to earlier webrevs. 
>> Now the new api to get the icons of different sizes is being made 
>> part of a new class SystemIcon. Please consider this as a different 
>> solution than the one that was under review for a long time till now.
>>
>> http://cr.openjdk.java.net/~sveerabhadra/8182043/webrev.05/
>>
>
> This version looks cleaner.
>
> The new SystemIcon class contains only one method, getSystemIcon. Does 
> it justify creating a new class for this? Can't we add this extended 
> version into FileSystemView class?
>
> FileSystemView has method:
> public Icon getSystemIcon(File f)
>
> We're extending it with
> public Icon getSystemIcon(File f, int size)
>
> Are there any objections to this approach?
>
>
> The class name, if we're going this route, could be more specific: 
> FileSystemIcon seems a better alternative.
>
>
> Javadoc for SystemIcon says, ?SystemIcon is JFileChooser's gateway to 
> the file system icons.? Yet JFileChooser uses 
> FileSystemView.getSystemIcon(File). So Javadoc is not accurate at the 
> very least.
>
> There should also be @since tag for the class.
>
> As this is a new API, I think it makes sense to throw 
> IllegalArgumentException for invalid parameters: file == null or size 
> is out of supported range.
>
> You don't usually want to print exception stack trace or messages from 
> a public API:
> 74???????????? System.err.println("FileSystemView.getShellFolder: f="+f);
> 75???????????? e.printStackTrace();
>
> As Phil mentioned, you should clearly state when a null value can be 
> returned.
>
>
> static public Icon getSystemIcon(File f, int size)
> should be
> public static Icon getSystemIcon(File f, int size)
>
> At this time, SystemIcon is an utility class which provides only 
> static methods. Yet it can be instantiated which does not look good.
> The code indents by three spaces instead of four.
>
> Win32ShellFolder2.java
> 1111???? public Image getIcon(int size) {
> The method should have @Override annotation.
>
> It can also be added to
> 1040???? public Image getIcon(final boolean getLargeIcon) {
>
>
> Win32ShellFolderManager2.java
> 383????????????????????????? key.startsWith("shell32LargeIcon 
> ")?LARGE_ICON_SIZE : SMALL_ICON_SIZE);
>
> There should be spaces around ???.
>
>
>> Part of the fix is being borrowed from Semyon?s fix and would like to 
>> thank Semyon for that.
>>
>
> You can give Semyon attribution by including "Contributed-by" tag in 
> your commit message and referencing Semyon and yourself there.
>
>
> Regards,
> Alexey
>
>> Thanks and regards,
>>
>> Shashi
>>
>> <SNIP>
>


From shashidhara.veerabhadraiah at oracle.com  Mon Mar  4 10:05:32 2019
From: shashidhara.veerabhadraiah at oracle.com (Shashidhara Veerabhadraiah)
Date: Mon, 4 Mar 2019 02:05:32 -0800 (PST)
Subject: <AWT Dev> <Swing Dev> [13] JDK-8216008:
 -Djavax.accessibility.assistive_technologies empty list leads to crash
In-Reply-To: <fdffa07a-7513-4a66-bbb9-5774b521b5d5@default>
References: <86dc6276-6a1c-4d09-8155-705fea8fd95e@default>
 <d1b5e58f-bfbd-3996-684d-2e74336cdc87@oracle.com>
 <465ad181-9c9c-4752-a3bc-595e82f08744@default>
 <a218d1b1-f003-f6b7-acfb-e50b9c27a56c@oracle.com>
 <c548de66-3c14-4488-b719-6a0cfde1dc9b@default>
 <9149f70d-5265-efb1-e496-48e159e61e92@oracle.com>
 <554176f6-b538-46b5-97bb-14e488f50656@default>
 <b99d879b-c2ce-358f-be3a-339d5faeff63@oracle.com>
 <daf49f44-1a41-8aa3-3c82-2fbd57ee7634@oracle.com>
 <a48ea2a7-ebdd-410d-b6f9-88288d6ee6d4@default> <5C5DEB0E.5010405@oracle.com>
 <23625b97-76d0-4956-8d4b-bf1add82ceb1@default>
 <1d4ad24a-e6bf-8e71-c88c-020e1106f089@oracle.com>
 <de99f10e-04da-4109-9980-4a8daf6a973c@default>
 <8634f5a6-a0a6-5739-9fd6-9a304a4a97f3@oracle.com>
 <70c695de-a54e-4aad-ae7b-0e11a6b9054e@default>
 <fdffa07a-7513-4a66-bbb9-5774b521b5d5@default>
Message-ID: <f586ecc6-a795-4564-a825-0b66323a8326@default>

Hi Joe, Please find the updated Webrev fixing the typo:

?

http://cr.openjdk.java.net/~sveerabhadra/8216008/webrev.07/

?

Thanks and regards,

Shashi

?

From: Shashidhara Veerabhadraiah 
Sent: Thursday, February 21, 2019 2:08 PM
To: Philip Race <philip.race at oracle.com>; Joe Darcy <joe.darcy at oracle.com>
Cc: awt-dev at openjdk.java.net; swing-dev at openjdk.java.net
Subject: Re: <AWT Dev> <Swing Dev> [13] JDK-8216008: -Djavax.accessibility.assistive_technologies empty list leads to crash

?

Hi Joe, Please find the new Webrev fixing the specification as asked in the CSR bug: https://bugs.openjdk.java.net/browse/JDK-8218737

?

Webrev: http://cr.openjdk.java.net/~sveerabhadra/8216008/webrev.06/

?

Thanks and regards,

Shashi

?

From: Shashidhara Veerabhadraiah 
Sent: Monday, February 18, 2019 10:19 AM
To: Philip Race <HYPERLINK "mailto:philip.race at oracle.com"philip.race at oracle.com>
Cc: HYPERLINK "mailto:awt-dev at openjdk.java.net"awt-dev at openjdk.java.net; HYPERLINK "mailto:swing-dev at openjdk.java.net"swing-dev at openjdk.java.net
Subject: Re: <AWT Dev> <Swing Dev> [13] JDK-8216008: -Djavax.accessibility.assistive_technologies empty list leads to crash

?

Thank you Phil for that help on CSR.

?

From: Phil Race 
Sent: Friday, February 15, 2019 9:41 PM
To: Shashidhara Veerabhadraiah <HYPERLINK "mailto:shashidhara.veerabhadraiah at oracle.com"shashidhara.veerabhadraiah at oracle.com>
Cc: Sergey Bylokhov <HYPERLINK "mailto:sergey.bylokhov at oracle.com"sergey.bylokhov at oracle.com>; HYPERLINK "mailto:awt-dev at openjdk.java.net"awt-dev at openjdk.java.net; HYPERLINK "mailto:swing-dev at openjdk.java.net"swing-dev at openjdk.java.net
Subject: Re: <Swing Dev> [13] JDK-8216008: -Djavax.accessibility.assistive_technologies empty list leads to crash

?

That text may actually be worse.
Although I maybe didn't get your distinction of null vs the empty string here ?

Oh, wait. Why is this doc clarification on the PRIVATE implementation method ?
It needs to go on the public getDefaultToolkit() method to have any point whatsoever
especially from a CSR perspective.
Try this :
-???? * toolkit is created. All errors are handled via an AWTError exception.
+???? * toolkit is created.
+???? * If the list of assistive technology providers is the empty string, or
+???? * contains only white space characters then the method returns immediately.
+???? * All other errors are handled via an AWTError exception.


I think the CSR needs some work too. I've made some updates there.

-phil.

On 2/15/19 2:10 AM, Shashidhara Veerabhadraiah wrote:

Hi Phil, I have updated the CSR and updated the information for the function and here is the new Webrev:

?

http://cr.openjdk.java.net/~sveerabhadra/8216008/webrev.05/

Thanks and regards,

Shashi

?

From: Phil Race 
Sent: Friday, February 15, 2019 2:58 AM
To: Shashidhara Veerabhadraiah HYPERLINK "mailto:shashidhara.veerabhadraiah at oracle.com"<shashidhara.veerabhadraiah at oracle.com>
Cc: Sergey Bylokhov HYPERLINK "mailto:sergey.bylokhov at oracle.com"<sergey.bylokhov at oracle.com>; HYPERLINK "mailto:awt-dev at openjdk.java.net"awt-dev at openjdk.java.net; HYPERLINK "mailto:swing-dev at openjdk.java.net"swing-dev at openjdk.java.net
Subject: Re: <Swing Dev> [13] JDK-8216008: -Djavax.accessibility.assistive_technologies empty list leads to crash

?

+???? * activate method.? If the list of assistive technology providers is empty string,
?
is "the" empty string.
?
?
The CSR needs to be updated to include this spec. 
What is there now in the specification section needs to be fixed
It should not point to the webrev or review and right now
doesn't contain the change to the javadoc in the body of the CSR
?
I think I even have to question most of the rest of it.
Any one reading it would think that we always used to throw an exception in such
case and now want to stop doing so. Isn't the bug that we did NOT throw an exception
and now we do ? You only hint at that when you say at the end of "Solution", "as was the case earlier"
?
If I am right the only thing you need in the CSR is to say that you
are reverting the implementation to previous behaviour and updating the
specification to make it clear that this behaviour is allowed by the spec
since this case was unclear.
?
-phil.

?

On 2/12/19 1:08 AM, Shashidhara Veerabhadraiah wrote:

Hi Phil, Here is the new Webrev and CSR for the same:

http://cr.openjdk.java.net/~sveerabhadra/8216008/webrev.04/

?

CSR: https://bugs.openjdk.java.net/browse/JDK-8218737

?

Thanks and regards,

Shashi

?

From: Philip Race 
Sent: Saturday, February 9, 2019 2:18 AM
To: Shashidhara Veerabhadraiah HYPERLINK "mailto:shashidhara.veerabhadraiah at oracle.com"<shashidhara.veerabhadraiah at oracle.com>
Cc: Sergey Bylokhov HYPERLINK "mailto:sergey.bylokhov at oracle.com"<sergey.bylokhov at oracle.com>; HYPERLINK "mailto:awt-dev at openjdk.java.net"awt-dev at openjdk.java.net; HYPERLINK "mailto:swing-dev at openjdk.java.net"swing-dev at openjdk.java.net
Subject: Re: <Swing Dev> [13] JDK-8216008: -Djavax.accessibility.assistive_technologies empty list leads to crash

?

FWIW I think this could be closed out as "not a bug".
An empty value string is an error and the spec. says AWTError is
how errors are reported. In fact I'll argue that 8 was wrong not
to have thrown an exception in such a case.
It was an accident of the implementation that it did not.
But if we want to be behaviourally compatible then ... 
Note that since you now document this you need an approved CSR BEFORE pushing it.

And if you go the CSR route you may need to be more precise about what
you mean by "empty".

I think it needs to say

"If the list of assistive technology providers is null, or contains only white
space characters then the method returns immediately.
All other errors are handled by throwing {@code AWTError}"

@throws AWTError if there is any error in parsing or loading the ATs.

-phil.

On 1/21/19, 9:12 AM, Shashidhara Veerabhadraiah wrote: 

Hi Sergey, Here is the new Webrev for your comments:
?
http://cr.openjdk.java.net/~sveerabhadra/8216008/webrev.02/
?
Thanks and regards,
Shashi
?
-----Original Message-----
From: Sergey Bylokhov 
Sent: Saturday, January 19, 2019 3:47 AM
To: Shashidhara Veerabhadraiah HYPERLINK "mailto:shashidhara.veerabhadraiah at oracle.com"<shashidhara.veerabhadraiah at oracle.com>; HYPERLINK "mailto:awt-dev at openjdk.java.net"awt-dev at openjdk.java.net; HYPERLINK "mailto:swing-dev at openjdk.java.net"swing-dev at openjdk.java.net
Subject: Re: <Swing Dev> [13] JDK-8216008: -Djavax.accessibility.assistive_technologies empty list leads to crash
?
On 16/01/2019 23:03, HYPERLINK "mailto:shashidhara.veerabhadraiah at oracle.com"shashidhara.veerabhadraiah at oracle.com wrote:

Another point is that the whitespace trimming should not trigger additional input processing? for the custom class that will be used for assistive technology. For eg., if custom class "FooProvider" is implemented and if we pass "? FooProvider? " by mistake, a bug may be created to trim the whitespace in this case as well!!

?
Yes, my previous email suggested to always trim the content of the "input", it will cover all cases, the "atNames" is empty, the "atNames" contains only the whitespace, or the name of the class has some spaces at the start/end.
?

?
Thanks and regards,
?
Shashi
?
?
On 17/01/19 10:28 AM, Shashidhara Veerabhadraiah wrote:

We need one way to tell the system not to load any assistive technologies and which is being provided.
If we add trailing white spaces removal then we may need to add another functionality to see if that class exists or not and based on that not to load anything(without throwing the error because we are parsing the input content). I think that would take a different direction. I feel it is fair enough to provide one way to tell not to load any assistive technologies and additional parsing would only lead to other ways/expectations.
?
Thanks and regards,
Shashi
?
-----Original Message-----
From: Sergey Bylokhov
Sent: Thursday, January 17, 2019 1:33 AM
To: Shashidhara Veerabhadraiah HYPERLINK "mailto:shashidhara.veerabhadraiah at oracle.com"<shashidhara.veerabhadraiah at oracle.com>; HYPERLINK "mailto:awt-dev at openjdk.java.net"awt-dev at openjdk.java.net; HYPERLINK "mailto:swing-dev at openjdk.java.net"swing-dev at openjdk.java.net
Subject: Re: <Swing Dev> [13] JDK-8216008: -Djavax.accessibility.assistive_technologies empty list leads to crash
?
I guess you meant whitespaces, then it is unclear why we should not consider "empty" parameter as a "mistake"?
?
On 15/01/2019 20:37, Shashidhara Veerabhadraiah wrote:

Hi Sergey, I felt that a string with an empty space is intentional and should be considering it as a 'mistake' if done by the developers. Hence I feel it is not required(as there is a way to tell nothing to load). Please let me know if you think otherwise.

?
?

Thanks and regards,
Shashi
?
-----Original Message-----
From: Sergey Bylokhov
Sent: Tuesday, January 15, 2019 7:32 AM
To: Shashidhara Veerabhadraiah HYPERLINK "mailto:shashidhara.veerabhadraiah at oracle.com"<shashidhara.veerabhadraiah at oracle.com>; HYPERLINK "mailto:awt-dev at openjdk.java.net"awt-dev at openjdk.java.net; HYPERLINK "mailto:swing-dev at openjdk.java.net"swing-dev at openjdk.java.net
Subject: Re: <Swing Dev> [13] JDK-8216008: -Djavax.accessibility.assistive_technologies empty list leads to crash
?
Hi, Shashi.
?
Should we trim all whitespaces from the "atNames"?
Otherwise the "atNames", which contains only one whitespace, will trigger the same error.
?
On 09/01/2019 00:20, Shashidhara Veerabhadraiah wrote:

Hi Sergey, Thanks for pointing that out. Here is the new Webrev:
?
http://cr.openjdk.java.net/~sveerabhadra/8216008/webrev.01/
?
Thanks and regards,
Shashi
?
-----Original Message-----
From: Sergey Bylokhov
Sent: Friday, January 4, 2019 3:48 AM
To: Shashidhara Veerabhadraiah HYPERLINK "mailto:shashidhara.veerabhadraiah at oracle.com"<shashidhara.veerabhadraiah at oracle.com>; HYPERLINK "mailto:awt-dev at openjdk.java.net"awt-dev at openjdk.java.net; HYPERLINK "mailto:swing-dev at openjdk.java.net"swing-dev at openjdk.java.net
Subject: Re: <Swing Dev> [13] JDK-8216008: -Djavax.accessibility.assistive_technologies empty list leads to crash
?
Hi, Shashi.
I think you can update an existing test:
open/test/jdk/javax/accessibility/AccessibilityProvider/basic.sh
?
On 03/01/2019 01:36, Shashidhara Veerabhadraiah wrote:

Hi All, Please review a fix for the below bug.
?
Bug: https://bugs.openjdk.java.net/browse/JDK-8216008
?
Webrev: http://cr.openjdk.java.net/~sveerabhadra/8216008/webrev.00/
?
Since the mentioned list of assistive technologies for the system property(javax.accessibility.assistive_technologies) is loaded by jvm am unable to write a test case for this bug. The test file attached with the bug can be used for testing this fix.
?
This fix removes the error(class not found error) by passing an empty list to system variable javax.accessibility.assistive_technologies and does not load any assistive technologies(as the list is empty). Currently empty list produce a crash which is not required as there was no class name mentioned in the list. Please read the bug comments for more information.
?
Thanks and regards,
?
Shashi
?

?

?

?

?

?
?

?

?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/awt-dev/attachments/20190304/cc3d84e6/attachment-0001.html>

From andrew_m_leonard at uk.ibm.com  Mon Mar  4 13:32:34 2019
From: andrew_m_leonard at uk.ibm.com (Andrew Leonard)
Date: Mon, 4 Mar 2019 13:32:34 +0000
Subject: <AWT Dev> JDK-8217735: Q: Should jint be jboolean ?
Message-ID: <OF07BFFAC9.476BD7EF-ON002583B3.004A4AEB-802583B3.004A6473@notes.na.collabserv.com>

Hi,

This bug raised a missmatch between the Java and JNI definition for a 
native method, where Java specifies "boolean" and the JNI jint. Which is 
right, should they match?
https://bugs.openjdk.java.net/browse/JDK-8217735
One part of the JVM spec that confuses me a bit is:
2.3.4 The boolean Type
Although the Java Virtual Machine defines a boolean type, 
it only provides very limited support for it. 
There are no Java Virtual Machine instructions solely dedicated
to operations on boolean values. Instead, expressions in the Java 
programming language that operate on boolean values are 
compiled to use values of the Java Virtual Machine int data type.

javah would generate a jboolean..

Thanks
Andrew

Andrew Leonard
Java Runtimes Development
IBM Hursley
IBM United Kingdom Ltd
Phone internal: 245913, external: 01962 815913
internet email: andrew_m_leonard at uk.ibm.com 

Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 
741598. 
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/awt-dev/attachments/20190304/d86d0ecf/attachment.html>

From shashidhara.veerabhadraiah at oracle.com  Wed Mar  6 06:15:36 2019
From: shashidhara.veerabhadraiah at oracle.com (Shashidhara Veerabhadraiah)
Date: Tue, 5 Mar 2019 22:15:36 -0800 (PST)
Subject: <AWT Dev> <Swing Dev> [13] JDK-8216008:
 -Djavax.accessibility.assistive_technologies empty list leads to crash
In-Reply-To: <f586ecc6-a795-4564-a825-0b66323a8326@default>
References: <86dc6276-6a1c-4d09-8155-705fea8fd95e@default>
 <d1b5e58f-bfbd-3996-684d-2e74336cdc87@oracle.com>
 <465ad181-9c9c-4752-a3bc-595e82f08744@default>
 <a218d1b1-f003-f6b7-acfb-e50b9c27a56c@oracle.com>
 <c548de66-3c14-4488-b719-6a0cfde1dc9b@default>
 <9149f70d-5265-efb1-e496-48e159e61e92@oracle.com>
 <554176f6-b538-46b5-97bb-14e488f50656@default>
 <b99d879b-c2ce-358f-be3a-339d5faeff63@oracle.com>
 <daf49f44-1a41-8aa3-3c82-2fbd57ee7634@oracle.com>
 <a48ea2a7-ebdd-410d-b6f9-88288d6ee6d4@default> <5C5DEB0E.5010405@oracle.com>
 <23625b97-76d0-4956-8d4b-bf1add82ceb1@default>
 <1d4ad24a-e6bf-8e71-c88c-020e1106f089@oracle.com>
 <de99f10e-04da-4109-9980-4a8daf6a973c@default>
 <8634f5a6-a0a6-5739-9fd6-9a304a4a97f3@oracle.com>
 <70c695de-a54e-4aad-ae7b-0e11a6b9054e@default>
 <fdffa07a-7513-4a66-bbb9-5774b521b5d5@default>
 <f586ecc6-a795-4564-a825-0b66323a8326@default>
Message-ID: <a2e461b3-c4e9-4955-8bec-44c8eb45b269@default>

Hi Phil\Sergey, Please review the CSR along with the bug fix.

?

Webrev: http://cr.openjdk.java.net/~sveerabhadra/8216008/webrev.07/

?

CSR: https://bugs.openjdk.java.net/browse/JDK-8218737

?

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

?

Thanks and regards,

Shashi

?

From: Shashidhara Veerabhadraiah 
Sent: Monday, March 4, 2019 3:36 PM
To: Philip Race <philip.race at oracle.com>; Joe Darcy <joe.darcy at oracle.com>
Cc: awt-dev at openjdk.java.net; swing-dev at openjdk.java.net
Subject: Re: <AWT Dev> <Swing Dev> [13] JDK-8216008: -Djavax.accessibility.assistive_technologies empty list leads to crash

?

Hi Joe, Please find the updated Webrev fixing the typo:

?

http://cr.openjdk.java.net/~sveerabhadra/8216008/webrev.07/

?

Thanks and regards,

Shashi

?

From: Shashidhara Veerabhadraiah 
Sent: Thursday, February 21, 2019 2:08 PM
To: Philip Race <HYPERLINK "mailto:philip.race at oracle.com"philip.race at oracle.com>; Joe Darcy <HYPERLINK "mailto:joe.darcy at oracle.com"joe.darcy at oracle.com>
Cc: HYPERLINK "mailto:awt-dev at openjdk.java.net"awt-dev at openjdk.java.net; HYPERLINK "mailto:swing-dev at openjdk.java.net"swing-dev at openjdk.java.net
Subject: Re: <AWT Dev> <Swing Dev> [13] JDK-8216008: -Djavax.accessibility.assistive_technologies empty list leads to crash

?

Hi Joe, Please find the new Webrev fixing the specification as asked in the CSR bug: https://bugs.openjdk.java.net/browse/JDK-8218737

?

Webrev: http://cr.openjdk.java.net/~sveerabhadra/8216008/webrev.06/

?

Thanks and regards,

Shashi

?

From: Shashidhara Veerabhadraiah 
Sent: Monday, February 18, 2019 10:19 AM
To: Philip Race <HYPERLINK "mailto:philip.race at oracle.com"philip.race at oracle.com>
Cc: HYPERLINK "mailto:awt-dev at openjdk.java.net"awt-dev at openjdk.java.net; HYPERLINK "mailto:swing-dev at openjdk.java.net"swing-dev at openjdk.java.net
Subject: Re: <AWT Dev> <Swing Dev> [13] JDK-8216008: -Djavax.accessibility.assistive_technologies empty list leads to crash

?

Thank you Phil for that help on CSR.

?

From: Phil Race 
Sent: Friday, February 15, 2019 9:41 PM
To: Shashidhara Veerabhadraiah <HYPERLINK "mailto:shashidhara.veerabhadraiah at oracle.com"shashidhara.veerabhadraiah at oracle.com>
Cc: Sergey Bylokhov <HYPERLINK "mailto:sergey.bylokhov at oracle.com"sergey.bylokhov at oracle.com>; HYPERLINK "mailto:awt-dev at openjdk.java.net"awt-dev at openjdk.java.net; HYPERLINK "mailto:swing-dev at openjdk.java.net"swing-dev at openjdk.java.net
Subject: Re: <Swing Dev> [13] JDK-8216008: -Djavax.accessibility.assistive_technologies empty list leads to crash

?

That text may actually be worse.
Although I maybe didn't get your distinction of null vs the empty string here ?

Oh, wait. Why is this doc clarification on the PRIVATE implementation method ?
It needs to go on the public getDefaultToolkit() method to have any point whatsoever
especially from a CSR perspective.
Try this :
-???? * toolkit is created. All errors are handled via an AWTError exception.
+???? * toolkit is created.
+???? * If the list of assistive technology providers is the empty string, or
+???? * contains only white space characters then the method returns immediately.
+???? * All other errors are handled via an AWTError exception.


I think the CSR needs some work too. I've made some updates there.

-phil.

On 2/15/19 2:10 AM, Shashidhara Veerabhadraiah wrote:

Hi Phil, I have updated the CSR and updated the information for the function and here is the new Webrev:

?

http://cr.openjdk.java.net/~sveerabhadra/8216008/webrev.05/

Thanks and regards,

Shashi

?

From: Phil Race 
Sent: Friday, February 15, 2019 2:58 AM
To: Shashidhara Veerabhadraiah HYPERLINK "mailto:shashidhara.veerabhadraiah at oracle.com"<shashidhara.veerabhadraiah at oracle.com>
Cc: Sergey Bylokhov HYPERLINK "mailto:sergey.bylokhov at oracle.com"<sergey.bylokhov at oracle.com>; HYPERLINK "mailto:awt-dev at openjdk.java.net"awt-dev at openjdk.java.net; HYPERLINK "mailto:swing-dev at openjdk.java.net"swing-dev at openjdk.java.net
Subject: Re: <Swing Dev> [13] JDK-8216008: -Djavax.accessibility.assistive_technologies empty list leads to crash

?

+???? * activate method.? If the list of assistive technology providers is empty string,
?
is "the" empty string.
?
?
The CSR needs to be updated to include this spec. 
What is there now in the specification section needs to be fixed
It should not point to the webrev or review and right now
doesn't contain the change to the javadoc in the body of the CSR
?
I think I even have to question most of the rest of it.
Any one reading it would think that we always used to throw an exception in such
case and now want to stop doing so. Isn't the bug that we did NOT throw an exception
and now we do ? You only hint at that when you say at the end of "Solution", "as was the case earlier"
?
If I am right the only thing you need in the CSR is to say that you
are reverting the implementation to previous behaviour and updating the
specification to make it clear that this behaviour is allowed by the spec
since this case was unclear.
?
-phil.

?

On 2/12/19 1:08 AM, Shashidhara Veerabhadraiah wrote:

Hi Phil, Here is the new Webrev and CSR for the same:

http://cr.openjdk.java.net/~sveerabhadra/8216008/webrev.04/

?

CSR: https://bugs.openjdk.java.net/browse/JDK-8218737

?

Thanks and regards,

Shashi

?

From: Philip Race 
Sent: Saturday, February 9, 2019 2:18 AM
To: Shashidhara Veerabhadraiah HYPERLINK "mailto:shashidhara.veerabhadraiah at oracle.com"<shashidhara.veerabhadraiah at oracle.com>
Cc: Sergey Bylokhov HYPERLINK "mailto:sergey.bylokhov at oracle.com"<sergey.bylokhov at oracle.com>; HYPERLINK "mailto:awt-dev at openjdk.java.net"awt-dev at openjdk.java.net; HYPERLINK "mailto:swing-dev at openjdk.java.net"swing-dev at openjdk.java.net
Subject: Re: <Swing Dev> [13] JDK-8216008: -Djavax.accessibility.assistive_technologies empty list leads to crash

?

FWIW I think this could be closed out as "not a bug".
An empty value string is an error and the spec. says AWTError is
how errors are reported. In fact I'll argue that 8 was wrong not
to have thrown an exception in such a case.
It was an accident of the implementation that it did not.
But if we want to be behaviourally compatible then ... 
Note that since you now document this you need an approved CSR BEFORE pushing it.

And if you go the CSR route you may need to be more precise about what
you mean by "empty".

I think it needs to say

"If the list of assistive technology providers is null, or contains only white
space characters then the method returns immediately.
All other errors are handled by throwing {@code AWTError}"

@throws AWTError if there is any error in parsing or loading the ATs.

-phil.

On 1/21/19, 9:12 AM, Shashidhara Veerabhadraiah wrote: 

Hi Sergey, Here is the new Webrev for your comments:
?
http://cr.openjdk.java.net/~sveerabhadra/8216008/webrev.02/
?
Thanks and regards,
Shashi
?
-----Original Message-----
From: Sergey Bylokhov 
Sent: Saturday, January 19, 2019 3:47 AM
To: Shashidhara Veerabhadraiah HYPERLINK "mailto:shashidhara.veerabhadraiah at oracle.com"<shashidhara.veerabhadraiah at oracle.com>; HYPERLINK "mailto:awt-dev at openjdk.java.net"awt-dev at openjdk.java.net; HYPERLINK "mailto:swing-dev at openjdk.java.net"swing-dev at openjdk.java.net
Subject: Re: <Swing Dev> [13] JDK-8216008: -Djavax.accessibility.assistive_technologies empty list leads to crash
?
On 16/01/2019 23:03, HYPERLINK "mailto:shashidhara.veerabhadraiah at oracle.com"shashidhara.veerabhadraiah at oracle.com wrote:

Another point is that the whitespace trimming should not trigger additional input processing? for the custom class that will be used for assistive technology. For eg., if custom class "FooProvider" is implemented and if we pass "? FooProvider? " by mistake, a bug may be created to trim the whitespace in this case as well!!

?
Yes, my previous email suggested to always trim the content of the "input", it will cover all cases, the "atNames" is empty, the "atNames" contains only the whitespace, or the name of the class has some spaces at the start/end.
?

?
Thanks and regards,
?
Shashi
?
?
On 17/01/19 10:28 AM, Shashidhara Veerabhadraiah wrote:

We need one way to tell the system not to load any assistive technologies and which is being provided.
If we add trailing white spaces removal then we may need to add another functionality to see if that class exists or not and based on that not to load anything(without throwing the error because we are parsing the input content). I think that would take a different direction. I feel it is fair enough to provide one way to tell not to load any assistive technologies and additional parsing would only lead to other ways/expectations.
?
Thanks and regards,
Shashi
?
-----Original Message-----
From: Sergey Bylokhov
Sent: Thursday, January 17, 2019 1:33 AM
To: Shashidhara Veerabhadraiah HYPERLINK "mailto:shashidhara.veerabhadraiah at oracle.com"<shashidhara.veerabhadraiah at oracle.com>; HYPERLINK "mailto:awt-dev at openjdk.java.net"awt-dev at openjdk.java.net; HYPERLINK "mailto:swing-dev at openjdk.java.net"swing-dev at openjdk.java.net
Subject: Re: <Swing Dev> [13] JDK-8216008: -Djavax.accessibility.assistive_technologies empty list leads to crash
?
I guess you meant whitespaces, then it is unclear why we should not consider "empty" parameter as a "mistake"?
?
On 15/01/2019 20:37, Shashidhara Veerabhadraiah wrote:

Hi Sergey, I felt that a string with an empty space is intentional and should be considering it as a 'mistake' if done by the developers. Hence I feel it is not required(as there is a way to tell nothing to load). Please let me know if you think otherwise.

?
?

Thanks and regards,
Shashi
?
-----Original Message-----
From: Sergey Bylokhov
Sent: Tuesday, January 15, 2019 7:32 AM
To: Shashidhara Veerabhadraiah HYPERLINK "mailto:shashidhara.veerabhadraiah at oracle.com"<shashidhara.veerabhadraiah at oracle.com>; HYPERLINK "mailto:awt-dev at openjdk.java.net"awt-dev at openjdk.java.net; HYPERLINK "mailto:swing-dev at openjdk.java.net"swing-dev at openjdk.java.net
Subject: Re: <Swing Dev> [13] JDK-8216008: -Djavax.accessibility.assistive_technologies empty list leads to crash
?
Hi, Shashi.
?
Should we trim all whitespaces from the "atNames"?
Otherwise the "atNames", which contains only one whitespace, will trigger the same error.
?
On 09/01/2019 00:20, Shashidhara Veerabhadraiah wrote:

Hi Sergey, Thanks for pointing that out. Here is the new Webrev:
?
http://cr.openjdk.java.net/~sveerabhadra/8216008/webrev.01/
?
Thanks and regards,
Shashi
?
-----Original Message-----
From: Sergey Bylokhov
Sent: Friday, January 4, 2019 3:48 AM
To: Shashidhara Veerabhadraiah HYPERLINK "mailto:shashidhara.veerabhadraiah at oracle.com"<shashidhara.veerabhadraiah at oracle.com>; HYPERLINK "mailto:awt-dev at openjdk.java.net"awt-dev at openjdk.java.net; HYPERLINK "mailto:swing-dev at openjdk.java.net"swing-dev at openjdk.java.net
Subject: Re: <Swing Dev> [13] JDK-8216008: -Djavax.accessibility.assistive_technologies empty list leads to crash
?
Hi, Shashi.
I think you can update an existing test:
open/test/jdk/javax/accessibility/AccessibilityProvider/basic.sh
?
On 03/01/2019 01:36, Shashidhara Veerabhadraiah wrote:

Hi All, Please review a fix for the below bug.
?
Bug: https://bugs.openjdk.java.net/browse/JDK-8216008
?
Webrev: http://cr.openjdk.java.net/~sveerabhadra/8216008/webrev.00/
?
Since the mentioned list of assistive technologies for the system property(javax.accessibility.assistive_technologies) is loaded by jvm am unable to write a test case for this bug. The test file attached with the bug can be used for testing this fix.
?
This fix removes the error(class not found error) by passing an empty list to system variable javax.accessibility.assistive_technologies and does not load any assistive technologies(as the list is empty). Currently empty list produce a crash which is not required as there was no class name mentioned in the list. Please read the bug comments for more information.
?
Thanks and regards,
?
Shashi
?

?

?

?

?

?
?

?

?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/awt-dev/attachments/20190305/a14177eb/attachment-0001.html>

From krishna.addepalli at oracle.com  Wed Mar  6 06:44:11 2019
From: krishna.addepalli at oracle.com (Krishna Addepalli)
Date: Wed, 6 Mar 2019 12:14:11 +0530
Subject: <AWT Dev> [13] JDK-8218917: KeyEvent.getModifiers() returns
 inconsistent values for ALT keys
Message-ID: <990B3CDA-E3A0-4051-8771-1AD486094974@oracle.com>

Hi All,

Please review a fix for https://bugs.openjdk.java.net/browse/JDK-8218917 <https://bugs.openjdk.java.net/browse/JDK-8218917>
With webrev: http://cr.openjdk.java.net/~kaddepalli/8218917/webrev00/ <http://cr.openjdk.java.net/~kaddepalli/8218917/webrev00/>

The problem is that once right alt key is pressed, pressing the left alt key always returns the key code for right alt key. The problem was in AWTEvent.m, there is a static variable ?altGRPressed? which is being set once right alt is pressed, but is not being cleared when left alt key is pressed. The fix is to completely remove the ?altGRPressed? variable as ?leftAtlPressed? is sufficient to determine which alt key was pressed.
I have tested all the regressions associated with JDK-8156460, and found no new failures.

Thanks,
Krishna
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/awt-dev/attachments/20190306/0a8b43ed/attachment.html>

From philip.race at oracle.com  Wed Mar  6 17:12:17 2019
From: philip.race at oracle.com (Philip Race)
Date: Wed, 06 Mar 2019 22:42:17 +0530
Subject: <AWT Dev> <Swing Dev> [13] JDK-8216008:
 -Djavax.accessibility.assistive_technologies empty list leads to crash
In-Reply-To: <a2e461b3-c4e9-4955-8bec-44c8eb45b269@default>
References: <86dc6276-6a1c-4d09-8155-705fea8fd95e@default>
 <d1b5e58f-bfbd-3996-684d-2e74336cdc87@oracle.com>
 <465ad181-9c9c-4752-a3bc-595e82f08744@default>
 <a218d1b1-f003-f6b7-acfb-e50b9c27a56c@oracle.com>
 <c548de66-3c14-4488-b719-6a0cfde1dc9b@default>
 <9149f70d-5265-efb1-e496-48e159e61e92@oracle.com>
 <554176f6-b538-46b5-97bb-14e488f50656@default>
 <b99d879b-c2ce-358f-be3a-339d5faeff63@oracle.com>
 <daf49f44-1a41-8aa3-3c82-2fbd57ee7634@oracle.com>
 <a48ea2a7-ebdd-410d-b6f9-88288d6ee6d4@default> <5C5DEB0E.5010405@oracle.com>
 <23625b97-76d0-4956-8d4b-bf1add82ceb1@default>
 <1d4ad24a-e6bf-8e71-c88c-020e1106f089@oracle.com>
 <de99f10e-04da-4109-9980-4a8daf6a973c@default>
 <8634f5a6-a0a6-5739-9fd6-9a304a4a97f3@oracle.com>
 <70c695de-a54e-4aad-ae7b-0e11a6b9054e@default>
 <fdffa07a-7513-4a66-bbb9-5774b521b5d5@default>
 <f586ecc6-a795-4564-a825-0b66323a8326@default>
 <a2e461b3-c4e9-4955-8bec-44c8eb45b269@default>
Message-ID: <5C7FFF71.1020809@oracle.com>

the webrev needs a couple of minor tweaks :

contains  empty string  ->  is the empty string

and

immeadiately ->  immediately


Go ahead and finalize the CSR which looks OK.

-phil.

On 3/6/19, 11:45 AM, Shashidhara Veerabhadraiah wrote:
>
> Hi Phil\Sergey, Please review the CSR along with the bug fix.
>
> Webrev: http://cr.openjdk.java.net/~sveerabhadra/8216008/webrev.07/ 
> <http://cr.openjdk.java.net/%7Esveerabhadra/8216008/webrev.07/>
>
> CSR: https://bugs.openjdk.java.net/browse/JDK-8218737
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8216008
>
> Thanks and regards,
>
> Shashi
>
> *From:*Shashidhara Veerabhadraiah
> *Sent:* Monday, March 4, 2019 3:36 PM
> *To:* Philip Race <philip.race at oracle.com>; Joe Darcy 
> <joe.darcy at oracle.com>
> *Cc:* awt-dev at openjdk.java.net; swing-dev at openjdk.java.net
> *Subject:* Re: <AWT Dev> <Swing Dev> [13] JDK-8216008: 
> -Djavax.accessibility.assistive_technologies empty list leads to crash
>
> Hi Joe, Please find the updated Webrev fixing the typo:
>
> http://cr.openjdk.java.net/~sveerabhadra/8216008/webrev.07/ 
> <http://cr.openjdk.java.net/%7Esveerabhadra/8216008/webrev.07/>
>
> Thanks and regards,
>
> Shashi
>
> *From:*Shashidhara Veerabhadraiah
> *Sent:* Thursday, February 21, 2019 2:08 PM
> *To:* Philip Race <philip.race at oracle.com 
> <mailto:philip.race at oracle.com>>; Joe Darcy <joe.darcy at oracle.com 
> <mailto:joe.darcy at oracle.com>>
> *Cc:* awt-dev at openjdk.java.net <mailto:awt-dev at openjdk.java.net>; 
> swing-dev at openjdk.java.net <mailto:swing-dev at openjdk.java.net>
> *Subject:* Re: <AWT Dev> <Swing Dev> [13] JDK-8216008: 
> -Djavax.accessibility.assistive_technologies empty list leads to crash
>
> Hi Joe, Please find the new Webrev fixing the specification as asked 
> in the CSR bug: https://bugs.openjdk.java.net/browse/JDK-8218737
>
> Webrev: http://cr.openjdk.java.net/~sveerabhadra/8216008/webrev.06/ 
> <http://cr.openjdk.java.net/%7Esveerabhadra/8216008/webrev.06/>
>
> Thanks and regards,
>
> Shashi
>
> *From:*Shashidhara Veerabhadraiah
> *Sent:* Monday, February 18, 2019 10:19 AM
> *To:* Philip Race <philip.race at oracle.com <mailto:philip.race at oracle.com>>
> *Cc:* awt-dev at openjdk.java.net <mailto:awt-dev at openjdk.java.net>; 
> swing-dev at openjdk.java.net <mailto:swing-dev at openjdk.java.net>
> *Subject:* Re: <AWT Dev> <Swing Dev> [13] JDK-8216008: 
> -Djavax.accessibility.assistive_technologies empty list leads to crash
>
> Thank you Phil for that help on CSR.
>
> *From:*Phil Race
> *Sent:* Friday, February 15, 2019 9:41 PM
> *To:* Shashidhara Veerabhadraiah 
> <shashidhara.veerabhadraiah at oracle.com 
> <mailto:shashidhara.veerabhadraiah at oracle.com>>
> *Cc:* Sergey Bylokhov <sergey.bylokhov at oracle.com 
> <mailto:sergey.bylokhov at oracle.com>>; awt-dev at openjdk.java.net 
> <mailto:awt-dev at openjdk.java.net>; swing-dev at openjdk.java.net 
> <mailto:swing-dev at openjdk.java.net>
> *Subject:* Re: <Swing Dev> [13] JDK-8216008: 
> -Djavax.accessibility.assistive_technologies empty list leads to crash
>
> That text may actually be worse.
> Although I maybe didn't get your distinction of null vs the empty 
> string here ?
>
> Oh, wait. Why is this doc clarification on the PRIVATE implementation 
> method ?
> It needs to go on the public getDefaultToolkit() method to have any 
> point whatsoever
> especially from a CSR perspective.
> Try this :
> -     * toolkit is created. All errors are handled via an AWTError 
> exception.
> +     * toolkit is created.
> +     * If the list of assistive technology providers is the empty 
> string, or
> +     * contains only white space characters then the method returns 
> immediately.
> +     * All other errors are handled via an AWTError exception.
>
>
> I think the CSR needs some work too. I've made some updates there.
>
> -phil.
>
> On 2/15/19 2:10 AM, Shashidhara Veerabhadraiah wrote:
>
>     Hi Phil, I have updated the CSR and updated the information for
>     the function and here is the new Webrev:
>
>     http://cr.openjdk.java.net/~sveerabhadra/8216008/webrev.05/
>     <http://cr.openjdk.java.net/%7Esveerabhadra/8216008/webrev.05/>
>
>     Thanks and regards,
>
>     Shashi
>
>     *From:*Phil Race
>     *Sent:* Friday, February 15, 2019 2:58 AM
>     *To:* Shashidhara Veerabhadraiah
>     <shashidhara.veerabhadraiah at oracle.com>
>     <mailto:shashidhara.veerabhadraiah at oracle.com>
>     *Cc:* Sergey Bylokhov <sergey.bylokhov at oracle.com>
>     <mailto:sergey.bylokhov at oracle.com>; awt-dev at openjdk.java.net
>     <mailto:awt-dev at openjdk.java.net>; swing-dev at openjdk.java.net
>     <mailto:swing-dev at openjdk.java.net>
>     *Subject:* Re: <Swing Dev> [13] JDK-8216008:
>     -Djavax.accessibility.assistive_technologies empty list leads to crash
>
>     +     * activate method.  If the list of assistive technology providers is empty string,
>
>       
>
>     is "the" empty string.
>
>       
>
>       
>
>     The CSR needs to be updated to include this spec.
>
>     What is there now in the specification section needs to be fixed
>
>     It should not point to the webrev or review and right now
>
>     doesn't contain the change to the javadoc in the body of the CSR
>
>       
>
>     I think I even have to question most of the rest of it.
>
>     Any one reading it would think that we always used to throw an exception in such
>
>     case and now want to stop doing so. Isn't the bug that we did NOT throw an exception
>
>     and now we do ? You only hint at that when you say at the end of "Solution", "as was the case earlier"
>
>       
>
>     If I am right the only thing you need in the CSR is to say that you
>
>     are reverting the implementation to previous behaviour and updating the
>
>     specification to make it clear that this behaviour is allowed by the spec
>
>     since this case was unclear.
>
>       
>
>     -phil.
>
>     On 2/12/19 1:08 AM, Shashidhara Veerabhadraiah wrote:
>
>         Hi Phil, Here is the new Webrev and CSR for the same:
>
>         http://cr.openjdk.java.net/~sveerabhadra/8216008/webrev.04/
>         <http://cr.openjdk.java.net/%7Esveerabhadra/8216008/webrev.04/>
>
>         CSR: https://bugs.openjdk.java.net/browse/JDK-8218737
>
>         Thanks and regards,
>
>         Shashi
>
>         *From:*Philip Race
>         *Sent:* Saturday, February 9, 2019 2:18 AM
>         *To:* Shashidhara Veerabhadraiah
>         <shashidhara.veerabhadraiah at oracle.com>
>         <mailto:shashidhara.veerabhadraiah at oracle.com>
>         *Cc:* Sergey Bylokhov <sergey.bylokhov at oracle.com>
>         <mailto:sergey.bylokhov at oracle.com>; awt-dev at openjdk.java.net
>         <mailto:awt-dev at openjdk.java.net>; swing-dev at openjdk.java.net
>         <mailto:swing-dev at openjdk.java.net>
>         *Subject:* Re: <Swing Dev> [13] JDK-8216008:
>         -Djavax.accessibility.assistive_technologies empty list leads
>         to crash
>
>         FWIW I think this could be closed out as "not a bug".
>         An empty value string is an error and the spec. says AWTError is
>         how errors are reported. In fact I'll argue that 8 was wrong not
>         to have thrown an exception in such a case.
>         It was an accident of the implementation that it did not.
>         But if we want to be behaviourally compatible then ...
>         Note that since you now document this you need an approved CSR
>         BEFORE pushing it.
>
>         And if you go the CSR route you may need to be more precise
>         about what
>         you mean by "empty".
>
>         I think it needs to say
>
>         "If the list of assistive technology providers is null, or
>         contains only white
>         space characters then the method returns immediately.
>         All other errors are handled by throwing {@code AWTError}"
>
>         @throws AWTError if there is any error in parsing or loading
>         the ATs.
>
>         -phil.
>
>         On 1/21/19, 9:12 AM, Shashidhara Veerabhadraiah wrote:
>
>             Hi Sergey, Here is the new Webrev for your comments:
>
>               
>
>             http://cr.openjdk.java.net/~sveerabhadra/8216008/webrev.02/  <http://cr.openjdk.java.net/%7Esveerabhadra/8216008/webrev.02/>
>
>               
>
>             Thanks and regards,
>
>             Shashi
>
>               
>
>             -----Original Message-----
>
>             From: Sergey Bylokhov
>
>             Sent: Saturday, January 19, 2019 3:47 AM
>
>             To: Shashidhara Veerabhadraiah<shashidhara.veerabhadraiah at oracle.com>  <mailto:shashidhara.veerabhadraiah at oracle.com>;awt-dev at openjdk.java.net  <mailto:awt-dev at openjdk.java.net>;swing-dev at openjdk.java.net  <mailto:swing-dev at openjdk.java.net>
>
>             Subject: Re:<Swing Dev>  [13] JDK-8216008: -Djavax.accessibility.assistive_technologies empty list leads to crash
>
>               
>
>             On 16/01/2019 23:03,shashidhara.veerabhadraiah at oracle.com  <mailto:shashidhara.veerabhadraiah at oracle.com>  wrote:
>
>                 Another point is that the whitespace trimming should not trigger additional input processing  for the custom class that will be used for assistive technology. For eg., if custom class "FooProvider" is implemented and if we pass "  FooProvider  " by mistake, a bug may be created to trim the whitespace in this case as well!!
>
>               
>
>             Yes, my previous email suggested to always trim the content of the "input", it will cover all cases, the "atNames" is empty, the "atNames" contains only the whitespace, or the name of the class has some spaces at the start/end.
>
>               
>
>                   
>
>                 Thanks and regards,
>
>                   
>
>                 Shashi
>
>                   
>
>                   
>
>                 On 17/01/19 10:28 AM, Shashidhara Veerabhadraiah wrote:
>
>                     We need one way to tell the system not to load any assistive technologies and which is being provided.
>
>                     If we add trailing white spaces removal then we may need to add another functionality to see if that class exists or not and based on that not to load anything(without throwing the error because we are parsing the input content). I think that would take a different direction. I feel it is fair enough to provide one way to tell not to load any assistive technologies and additional parsing would only lead to other ways/expectations.
>
>                       
>
>                     Thanks and regards,
>
>                     Shashi
>
>                       
>
>                     -----Original Message-----
>
>                     From: Sergey Bylokhov
>
>                     Sent: Thursday, January 17, 2019 1:33 AM
>
>                     To: Shashidhara Veerabhadraiah<shashidhara.veerabhadraiah at oracle.com>  <mailto:shashidhara.veerabhadraiah at oracle.com>;awt-dev at openjdk.java.net  <mailto:awt-dev at openjdk.java.net>;swing-dev at openjdk.java.net  <mailto:swing-dev at openjdk.java.net>
>
>                     Subject: Re:<Swing Dev>  [13] JDK-8216008: -Djavax.accessibility.assistive_technologies empty list leads to crash
>
>                       
>
>                     I guess you meant whitespaces, then it is unclear why we should not consider "empty" parameter as a "mistake"?
>
>                       
>
>                     On 15/01/2019 20:37, Shashidhara Veerabhadraiah wrote:
>
>                         Hi Sergey, I felt that a string with an empty space is intentional and should be considering it as a 'mistake' if done by the developers. Hence I feel it is not required(as there is a way to tell nothing to load). Please let me know if you think otherwise.
>
>                       
>
>                       
>
>                         Thanks and regards,
>
>                         Shashi
>
>                           
>
>                         -----Original Message-----
>
>                         From: Sergey Bylokhov
>
>                         Sent: Tuesday, January 15, 2019 7:32 AM
>
>                         To: Shashidhara Veerabhadraiah<shashidhara.veerabhadraiah at oracle.com>  <mailto:shashidhara.veerabhadraiah at oracle.com>;awt-dev at openjdk.java.net  <mailto:awt-dev at openjdk.java.net>;swing-dev at openjdk.java.net  <mailto:swing-dev at openjdk.java.net>
>
>                         Subject: Re:<Swing Dev>  [13] JDK-8216008: -Djavax.accessibility.assistive_technologies empty list leads to crash
>
>                           
>
>                         Hi, Shashi.
>
>                           
>
>                         Should we trim all whitespaces from the "atNames"?
>
>                         Otherwise the "atNames", which contains only one whitespace, will trigger the same error.
>
>                           
>
>                         On 09/01/2019 00:20, Shashidhara Veerabhadraiah wrote:
>
>                             Hi Sergey, Thanks for pointing that out. Here is the new Webrev:
>
>                               
>
>                             http://cr.openjdk.java.net/~sveerabhadra/8216008/webrev.01/  <http://cr.openjdk.java.net/%7Esveerabhadra/8216008/webrev.01/>
>
>                               
>
>                             Thanks and regards,
>
>                             Shashi
>
>                               
>
>                             -----Original Message-----
>
>                             From: Sergey Bylokhov
>
>                             Sent: Friday, January 4, 2019 3:48 AM
>
>                             To: Shashidhara Veerabhadraiah<shashidhara.veerabhadraiah at oracle.com>  <mailto:shashidhara.veerabhadraiah at oracle.com>;awt-dev at openjdk.java.net  <mailto:awt-dev at openjdk.java.net>;swing-dev at openjdk.java.net  <mailto:swing-dev at openjdk.java.net>
>
>                             Subject: Re:<Swing Dev>  [13] JDK-8216008: -Djavax.accessibility.assistive_technologies empty list leads to crash
>
>                               
>
>                             Hi, Shashi.
>
>                             I think you can update an existing test:
>
>                             open/test/jdk/javax/accessibility/AccessibilityProvider/basic.sh
>
>                               
>
>                             On 03/01/2019 01:36, Shashidhara Veerabhadraiah wrote:
>
>                                 Hi All, Please review a fix for the below bug.
>
>                                   
>
>                                 Bug:https://bugs.openjdk.java.net/browse/JDK-8216008
>
>                                   
>
>                                 Webrev:http://cr.openjdk.java.net/~sveerabhadra/8216008/webrev.00/  <http://cr.openjdk.java.net/%7Esveerabhadra/8216008/webrev.00/>
>
>                                   
>
>                                 Since the mentioned list of assistive technologies for the system property(javax.accessibility.assistive_technologies) is loaded by jvm am unable to write a test case for this bug. The test file attached with the bug can be used for testing this fix.
>
>                                   
>
>                                 This fix removes the error(class not found error) by passing an empty list to system variable javax.accessibility.assistive_technologies and does not load any assistive technologies(as the list is empty). Currently empty list produce a crash which is not required as there was no class name mentioned in the list. Please read the bug comments for more information.
>
>                                   
>
>                                 Thanks and regards,
>
>                                   
>
>                                 Shashi
>
>                                   
>
>                               
>
>                           
>
>                       
>
>                   
>
>               
>
>               
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/awt-dev/attachments/20190306/3b5dddf3/attachment-0001.html>

From malenkov at gmail.com  Wed Mar  6 17:32:14 2019
From: malenkov at gmail.com (Sergey Malenkov)
Date: Wed, 6 Mar 2019 20:32:14 +0300
Subject: <AWT Dev> [13] JDK-8218917: KeyEvent.getModifiers() returns
 inconsistent values for ALT keys
In-Reply-To: <990B3CDA-E3A0-4051-8771-1AD486094974@oracle.com>
References: <990B3CDA-E3A0-4051-8771-1AD486094974@oracle.com>
Message-ID: <CANTFZ2i30ao6fVuVxQseEzF38vBnLUfw3PPadYyKrUCrgfKo9g@mail.gmail.com>

Hi Krishna,

Your fix solves the issue that the right Alt key breaks further
processing of the left Alt key.

But there is a problem with modifiers mask:
304         java_awt_event_InputEvent_ALT_DOWN_MASK |
java_awt_event_InputEvent_ALT_GRAPH_DOWN_MASK,
305         java_awt_event_InputEvent_ALT_MASK |
java_awt_event_InputEvent_ALT_GRAPH_MASK,
306         java_awt_event_KeyEvent_VK_ALT |
java_awt_event_KeyEvent_VK_ALT_GRAPH

Why did you merge VK_ALT and VK_ALT_GRAPH? This is key codes, not a mask.
Why did you set ALT_DOWN_MASK and ALT_GRAPH_DOWN_MASK both if only the
VK_ALT_GRAPH is pressed?

Could you please provide a more complex test? For example,
  robot.keyPress(KeyEvent.VK_ALT); // check that key code is VK_ALT
and modifiers = ALT_DOWN_MASK
  robot.keyPress(KeyEvent.VK_ALT_GRAPH); // check that key code is
VK_ALT_GRAPH and modifiers = ALT_DOWN_MASK | ALT_GRAPH_DOWN_MASK
  robot.keyRelease(KeyEvent.VK_ALT); // check that key code is VK_ALT
and modifiers = ALT_GRAPH_DOWN_MASK
  robot.keyRelease(KeyEvent.VK_ALT_GRAPH); // check that key code is
VK_ALT_GRAPH and modifiers = 0

Note, if you replace ALT_GRAPH with SHIFT in the code above, all
required events will be sent correctly.

In the following article I provide a manual test and a simple patch to
solve issues with pressing the left Shift key together with the right
one.
http://sites.google.com/site/malenkov/java/190306

Unfortunately I cannot create an automated test, because the Robot
have no ability to press a key in the required location (left or
right).



On Wed, Mar 6, 2019 at 9:45 AM Krishna Addepalli
<krishna.addepalli at oracle.com> wrote:
>
> Hi All,
>
> Please review a fix for https://bugs.openjdk.java.net/browse/JDK-8218917
> With webrev: http://cr.openjdk.java.net/~kaddepalli/8218917/webrev00/
>
> The problem is that once right alt key is pressed, pressing the left alt key always returns the key code for right alt key. The problem was in AWTEvent.m, there is a static variable ?altGRPressed? which is being set once right alt is pressed, but is not being cleared when left alt key is pressed. The fix is to completely remove the ?altGRPressed? variable as ?leftAtlPressed? is sufficient to determine which alt key was pressed.
> I have tested all the regressions associated with JDK-8156460, and found no new failures.
>
> Thanks,
> Krishna



-- 
Best regards,
Sergey A. Malenkov

From Sergey.Bylokhov at oracle.com  Thu Mar  7 06:08:30 2019
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Wed, 6 Mar 2019 22:08:30 -0800
Subject: <AWT Dev> [13] Review Request: 8215105
 java/awt/Robot/HiDPIScreenCapture/ScreenCaptureTest.java: Wrong Pixel Color
Message-ID: <dbae87f1-e1d0-5bc9-c4de-a75abe89bb6f@oracle.com>

Hello.
Please review the fix for JDK 13.

Bug: https://bugs.openjdk.java.net/browse/JDK-8215105
Fix: http://cr.openjdk.java.net/~serb/8215105/webrev.00

Notes about the current implementation.
  1. The native system reads the pixels using the current "Display Profile".
  2. The robot API saves pixels into BufferedImage, which uses the sRGB color profile.
  3. To convert pixels from native representation to sRGB we used "kCGColorSpaceGenericRGB" mode.

Note that during conversion we may lost a color precision, this is why we always configured our test systems to use "Generic RGB Profiles"
But the logic above does not work on macOS 10.13.6.


I have tested macOS 10.12/13/14 and the only constant which works on all systems is a kCGColorSpaceSRGB + Display Profile "sRGB IEC 61966-2.1".
So we can:
  - Change nothing and skip "support" of 10.13.6 where "kCGColorSpaceGenericRGB" + "Generic RGB Profiles" does not work.
  - Apply the current fix, but then we need to change the requirement to the test systems(macos 10.12->10.14) to use "sRGB IEC 61966-2.1"

But since "kCGColorSpaceGenericRGB is available only for legacy reasons." it make sense to use kCGColorSpaceSRGB anyway.
https://developer.apple.com/documentation/coregraphics/kcgcolorspacegenericrgb

-- 
Best regards, Sergey.

From Sergey.Bylokhov at oracle.com  Thu Mar  7 06:59:11 2019
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Wed, 6 Mar 2019 22:59:11 -0800
Subject: <AWT Dev> [13] Review Request: 8219504 Test for JDK-8211435 can
 be run on all platforms
In-Reply-To: <4df8575d-9dbb-4f39-bc98-128f4a8730f3@default>
References: <7c09c115-3f90-1c0f-3711-c874ece6f53b@oracle.com>
 <4df8575d-9dbb-4f39-bc98-128f4a8730f3@default>
Message-ID: <d1ded32d-e149-4e9e-2d32-1369f5d962fc@oracle.com>

Thank you for review!
Looking for the second +1 from someone else.

On 20/02/2019 22:20, Krishna Addepalli wrote:
> +1
> 
> Krishna
> 
> -----Original Message-----
> From: Sergey Bylokhov
> Sent: Thursday, February 21, 2019 8:01 AM
> To: awt-dev at openjdk.java.net
> Subject: <AWT Dev> [13] Review Request: 8219504 Test for JDK-8211435 can be run on all platforms
> 
> Hello.
> Please review the fix for jdk 13.
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8219504
> Fix: http://cr.openjdk.java.net/~serb/8219504/webrev.00
> 
> Currently the test for JDK-8211435 is executed on macOS only, because of JDK-8204142[1][2]:
> But since JDK-8204142 was fixed we can run it on all platforms.
> 
> [1] https://bugs.openjdk.java.net/browse/JDK-8204142
> [2] http://mail.openjdk.java.net/pipermail/awt-dev/2018-October/014492.html
> 


-- 
Best regards, Sergey.

From dmitry.markov at oracle.com  Thu Mar  7 09:29:07 2019
From: dmitry.markov at oracle.com (Dmitry Markov)
Date: Thu, 7 Mar 2019 09:29:07 +0000
Subject: <AWT Dev> [13] Review Request: 8219504 Test for JDK-8211435 can
 be run on all platforms
In-Reply-To: <d1ded32d-e149-4e9e-2d32-1369f5d962fc@oracle.com>
References: <7c09c115-3f90-1c0f-3711-c874ece6f53b@oracle.com>
 <4df8575d-9dbb-4f39-bc98-128f4a8730f3@default>
 <d1ded32d-e149-4e9e-2d32-1369f5d962fc@oracle.com>
Message-ID: <D1288038-5C87-40E9-80E5-1350781BE215@oracle.com>

Hi Sergey,

The fix looks good to me.

Thanks,
Dmitry

> On 7 Mar 2019, at 06:59, Sergey Bylokhov <sergey.bylokhov at oracle.com> wrote:
> 
> Thank you for review!
> Looking for the second +1 from someone else.
> 
> On 20/02/2019 22:20, Krishna Addepalli wrote:
>> +1
>> Krishna
>> -----Original Message-----
>> From: Sergey Bylokhov
>> Sent: Thursday, February 21, 2019 8:01 AM
>> To: awt-dev at openjdk.java.net
>> Subject: <AWT Dev> [13] Review Request: 8219504 Test for JDK-8211435 can be run on all platforms
>> Hello.
>> Please review the fix for jdk 13.
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8219504
>> Fix: http://cr.openjdk.java.net/~serb/8219504/webrev.00
>> Currently the test for JDK-8211435 is executed on macOS only, because of JDK-8204142[1][2]:
>> But since JDK-8204142 was fixed we can run it on all platforms.
>> [1] https://bugs.openjdk.java.net/browse/JDK-8204142
>> [2] http://mail.openjdk.java.net/pipermail/awt-dev/2018-October/014492.html
> 
> 
> -- 
> Best regards, Sergey.


From shashidhara.veerabhadraiah at oracle.com  Thu Mar  7 15:45:49 2019
From: shashidhara.veerabhadraiah at oracle.com (Shashidhara Veerabhadraiah)
Date: Thu, 7 Mar 2019 07:45:49 -0800 (PST)
Subject: <AWT Dev> [13] Review Request: 8219504 Test for JDK-8211435 can
 be run on all platforms
In-Reply-To: <D1288038-5C87-40E9-80E5-1350781BE215@oracle.com>
References: <7c09c115-3f90-1c0f-3711-c874ece6f53b@oracle.com>
 <4df8575d-9dbb-4f39-bc98-128f4a8730f3@default>
 <d1ded32d-e149-4e9e-2d32-1369f5d962fc@oracle.com>
 <D1288038-5C87-40E9-80E5-1350781BE215@oracle.com>
Message-ID: <32fe5766-d4d3-4806-9322-039925ea1ad7@default>

Hi Sergey, I think you need to add "@run main" command and this bug id to the "@bug" list of bugs. Also you can update the copyright year to this year as well.

Thanks and regards,
Shashi

-----Original Message-----
From: Dmitry Markov 
Sent: Thursday, March 7, 2019 2:59 PM
To: Sergey Bylokhov <sergey.bylokhov at oracle.com>
Cc: awt-dev at openjdk.java.net
Subject: Re: <AWT Dev> [13] Review Request: 8219504 Test for JDK-8211435 can be run on all platforms

Hi Sergey,

The fix looks good to me.

Thanks,
Dmitry

> On 7 Mar 2019, at 06:59, Sergey Bylokhov <sergey.bylokhov at oracle.com> wrote:
> 
> Thank you for review!
> Looking for the second +1 from someone else.
> 
> On 20/02/2019 22:20, Krishna Addepalli wrote:
>> +1
>> Krishna
>> -----Original Message-----
>> From: Sergey Bylokhov
>> Sent: Thursday, February 21, 2019 8:01 AM
>> To: awt-dev at openjdk.java.net
>> Subject: <AWT Dev> [13] Review Request: 8219504 Test for JDK-8211435 
>> can be run on all platforms Hello.
>> Please review the fix for jdk 13.
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8219504
>> Fix: http://cr.openjdk.java.net/~serb/8219504/webrev.00
>> Currently the test for JDK-8211435 is executed on macOS only, because of JDK-8204142[1][2]:
>> But since JDK-8204142 was fixed we can run it on all platforms.
>> [1] https://bugs.openjdk.java.net/browse/JDK-8204142
>> [2] 
>> http://mail.openjdk.java.net/pipermail/awt-dev/2018-October/014492.ht
>> ml
> 
> 
> --
> Best regards, Sergey.


From Sergey.Bylokhov at oracle.com  Thu Mar  7 21:49:42 2019
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Thu, 7 Mar 2019 13:49:42 -0800
Subject: <AWT Dev> [13] Review Request: 8219504 Test for JDK-8211435 can
 be run on all platforms
In-Reply-To: <32fe5766-d4d3-4806-9322-039925ea1ad7@default>
References: <7c09c115-3f90-1c0f-3711-c874ece6f53b@oracle.com>
 <4df8575d-9dbb-4f39-bc98-128f4a8730f3@default>
 <d1ded32d-e149-4e9e-2d32-1369f5d962fc@oracle.com>
 <D1288038-5C87-40E9-80E5-1350781BE215@oracle.com>
 <32fe5766-d4d3-4806-9322-039925ea1ad7@default>
Message-ID: <7954212c-2fa3-3b51-6b2f-5806951b2e80@oracle.com>

Hi, Shashi.
On 07/03/2019 07:45, Shashidhara Veerabhadraiah wrote:
> Hi Sergey, I think you need to add "@run main" command and this bug id to the "@bug" list of bugs. Also you can update the copyright year to this year as well.

  - The "@run main" tag is optional, this is default action for the test.
  - The @bug tag contains a bugid for which the test was written or the bugid which was found by this test later. It can also contain the bugid of bugfix in the test if the fix rewrote the test.
  - I'll update the year before the push.

> 
> Thanks and regards,
> Shashi
> 
> -----Original Message-----
> From: Dmitry Markov
> Sent: Thursday, March 7, 2019 2:59 PM
> To: Sergey Bylokhov <sergey.bylokhov at oracle.com>
> Cc: awt-dev at openjdk.java.net
> Subject: Re: <AWT Dev> [13] Review Request: 8219504 Test for JDK-8211435 can be run on all platforms
> 
> Hi Sergey,
> 
> The fix looks good to me.
> 
> Thanks,
> Dmitry
> 
>> On 7 Mar 2019, at 06:59, Sergey Bylokhov <sergey.bylokhov at oracle.com> wrote:
>>
>> Thank you for review!
>> Looking for the second +1 from someone else.
>>
>> On 20/02/2019 22:20, Krishna Addepalli wrote:
>>> +1
>>> Krishna
>>> -----Original Message-----
>>> From: Sergey Bylokhov
>>> Sent: Thursday, February 21, 2019 8:01 AM
>>> To: awt-dev at openjdk.java.net
>>> Subject: <AWT Dev> [13] Review Request: 8219504 Test for JDK-8211435
>>> can be run on all platforms Hello.
>>> Please review the fix for jdk 13.
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8219504
>>> Fix: http://cr.openjdk.java.net/~serb/8219504/webrev.00
>>> Currently the test for JDK-8211435 is executed on macOS only, because of JDK-8204142[1][2]:
>>> But since JDK-8204142 was fixed we can run it on all platforms.
>>> [1] https://bugs.openjdk.java.net/browse/JDK-8204142
>>> [2]
>>> http://mail.openjdk.java.net/pipermail/awt-dev/2018-October/014492.ht
>>> ml
>>
>>
>> --
>> Best regards, Sergey.
> 


-- 
Best regards, Sergey.

From alexandre.iline at oracle.com  Thu Mar  7 22:28:25 2019
From: alexandre.iline at oracle.com (Alexandre (Shura) Iline)
Date: Thu, 7 Mar 2019 14:28:25 -0800
Subject: <AWT Dev> [13] Review Request: 8215105
 java/awt/Robot/HiDPIScreenCapture/ScreenCaptureTest.java: Wrong Pixel Color
In-Reply-To: <dbae87f1-e1d0-5bc9-c4de-a75abe89bb6f@oracle.com>
References: <dbae87f1-e1d0-5bc9-c4de-a75abe89bb6f@oracle.com>
Message-ID: <0D9A7534-2ABD-485A-B566-BC3FE138AD48@oracle.com>

Bug description says:
"The test java/awt/Robot/HiDPIScreenCapture/ScreenCaptureTest.java fails on MacOSX, Windows. This failure was also observed on Kubuntu (KDE) ?

Should there be sub-bugs created for Mac OS and also other platforms?

Shura

> On Mar 6, 2019, at 10:08 PM, Sergey Bylokhov <Sergey.Bylokhov at oracle.com> wrote:
> 
> Hello.
> Please review the fix for JDK 13.
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8215105
> Fix: http://cr.openjdk.java.net/~serb/8215105/webrev.00
> 
> Notes about the current implementation.
> 1. The native system reads the pixels using the current "Display Profile".
> 2. The robot API saves pixels into BufferedImage, which uses the sRGB color profile.
> 3. To convert pixels from native representation to sRGB we used "kCGColorSpaceGenericRGB" mode.
> 
> Note that during conversion we may lost a color precision, this is why we always configured our test systems to use "Generic RGB Profiles"
> But the logic above does not work on macOS 10.13.6.
> 
> 
> I have tested macOS 10.12/13/14 and the only constant which works on all systems is a kCGColorSpaceSRGB + Display Profile "sRGB IEC 61966-2.1".
> So we can:
> - Change nothing and skip "support" of 10.13.6 where "kCGColorSpaceGenericRGB" + "Generic RGB Profiles" does not work.
> - Apply the current fix, but then we need to change the requirement to the test systems(macos 10.12->10.14) to use "sRGB IEC 61966-2.1"
> 
> But since "kCGColorSpaceGenericRGB is available only for legacy reasons." it make sense to use kCGColorSpaceSRGB anyway.
> https://developer.apple.com/documentation/coregraphics/kcgcolorspacegenericrgb
> 
> -- 
> Best regards, Sergey.


From Sergey.Bylokhov at oracle.com  Thu Mar  7 23:07:54 2019
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Thu, 7 Mar 2019 15:07:54 -0800
Subject: <AWT Dev> [13] Review Request: 8215105
 java/awt/Robot/HiDPIScreenCapture/ScreenCaptureTest.java: Wrong Pixel Color
In-Reply-To: <0D9A7534-2ABD-485A-B566-BC3FE138AD48@oracle.com>
References: <dbae87f1-e1d0-5bc9-c4de-a75abe89bb6f@oracle.com>
 <0D9A7534-2ABD-485A-B566-BC3FE138AD48@oracle.com>
Message-ID: <94650ad6-4ea3-8e21-699a-be30092125e0@oracle.com>

Hi, Shura.
On 07/03/2019 14:28, Alexandre (Shura) Iline wrote:
> Bug description says:
> "The test java/awt/Robot/HiDPIScreenCapture/ScreenCaptureTest.java fails on MacOSX, Windows. This failure was also observed on Kubuntu (KDE) ?

The bug contains "how to reproduce" information only for macOS (where it is fixed in the current webrev).
I cannot reproduce it on Windows/Linux(on Gnome, since KDE is unsupported)

> 
> Should there be sub-bugs created for Mac OS and also other platforms?
> 
> Shura
> 
>> On Mar 6, 2019, at 10:08 PM, Sergey Bylokhov <Sergey.Bylokhov at oracle.com> wrote:
>>
>> Hello.
>> Please review the fix for JDK 13.
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8215105
>> Fix: http://cr.openjdk.java.net/~serb/8215105/webrev.00
>>
>> Notes about the current implementation.
>> 1. The native system reads the pixels using the current "Display Profile".
>> 2. The robot API saves pixels into BufferedImage, which uses the sRGB color profile.
>> 3. To convert pixels from native representation to sRGB we used "kCGColorSpaceGenericRGB" mode.
>>
>> Note that during conversion we may lost a color precision, this is why we always configured our test systems to use "Generic RGB Profiles"
>> But the logic above does not work on macOS 10.13.6.
>>
>>
>> I have tested macOS 10.12/13/14 and the only constant which works on all systems is a kCGColorSpaceSRGB + Display Profile "sRGB IEC 61966-2.1".
>> So we can:
>> - Change nothing and skip "support" of 10.13.6 where "kCGColorSpaceGenericRGB" + "Generic RGB Profiles" does not work.
>> - Apply the current fix, but then we need to change the requirement to the test systems(macos 10.12->10.14) to use "sRGB IEC 61966-2.1"
>>
>> But since "kCGColorSpaceGenericRGB is available only for legacy reasons." it make sense to use kCGColorSpaceSRGB anyway.
>> https://developer.apple.com/documentation/coregraphics/kcgcolorspacegenericrgb
>>
>> -- 
>> Best regards, Sergey.
> 


-- 
Best regards, Sergey.

From shashidhara.veerabhadraiah at oracle.com  Fri Mar  8 04:18:35 2019
From: shashidhara.veerabhadraiah at oracle.com (Shashidhara Veerabhadraiah)
Date: Thu, 7 Mar 2019 20:18:35 -0800 (PST)
Subject: <AWT Dev> [13] Review Request: 8219504 Test for JDK-8211435 can
 be run on all platforms
In-Reply-To: <7954212c-2fa3-3b51-6b2f-5806951b2e80@oracle.com>
References: <7c09c115-3f90-1c0f-3711-c874ece6f53b@oracle.com>
 <4df8575d-9dbb-4f39-bc98-128f4a8730f3@default>
 <d1ded32d-e149-4e9e-2d32-1369f5d962fc@oracle.com>
 <D1288038-5C87-40E9-80E5-1350781BE215@oracle.com>
 <32fe5766-d4d3-4806-9322-039925ea1ad7@default>
 <7954212c-2fa3-3b51-6b2f-5806951b2e80@oracle.com>
Message-ID: <4f236c67-efdd-4512-971c-edb16e961898@default>

Hi Sergey, Then the fix looks good to me.

Thanks and regards,
Shashi

-----Original Message-----
From: Sergey Bylokhov 
Sent: Friday, March 8, 2019 3:20 AM
To: Shashidhara Veerabhadraiah <shashidhara.veerabhadraiah at oracle.com>; Dmitry Markov <dmitry.markov at oracle.com>
Cc: awt-dev at openjdk.java.net
Subject: Re: <AWT Dev> [13] Review Request: 8219504 Test for JDK-8211435 can be run on all platforms

Hi, Shashi.
On 07/03/2019 07:45, Shashidhara Veerabhadraiah wrote:
> Hi Sergey, I think you need to add "@run main" command and this bug id to the "@bug" list of bugs. Also you can update the copyright year to this year as well.

  - The "@run main" tag is optional, this is default action for the test.
  - The @bug tag contains a bugid for which the test was written or the bugid which was found by this test later. It can also contain the bugid of bugfix in the test if the fix rewrote the test.
  - I'll update the year before the push.

> 
> Thanks and regards,
> Shashi
> 
> -----Original Message-----
> From: Dmitry Markov
> Sent: Thursday, March 7, 2019 2:59 PM
> To: Sergey Bylokhov <sergey.bylokhov at oracle.com>
> Cc: awt-dev at openjdk.java.net
> Subject: Re: <AWT Dev> [13] Review Request: 8219504 Test for 
> JDK-8211435 can be run on all platforms
> 
> Hi Sergey,
> 
> The fix looks good to me.
> 
> Thanks,
> Dmitry
> 
>> On 7 Mar 2019, at 06:59, Sergey Bylokhov <sergey.bylokhov at oracle.com> wrote:
>>
>> Thank you for review!
>> Looking for the second +1 from someone else.
>>
>> On 20/02/2019 22:20, Krishna Addepalli wrote:
>>> +1
>>> Krishna
>>> -----Original Message-----
>>> From: Sergey Bylokhov
>>> Sent: Thursday, February 21, 2019 8:01 AM
>>> To: awt-dev at openjdk.java.net
>>> Subject: <AWT Dev> [13] Review Request: 8219504 Test for JDK-8211435 
>>> can be run on all platforms Hello.
>>> Please review the fix for jdk 13.
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8219504
>>> Fix: http://cr.openjdk.java.net/~serb/8219504/webrev.00
>>> Currently the test for JDK-8211435 is executed on macOS only, because of JDK-8204142[1][2]:
>>> But since JDK-8204142 was fixed we can run it on all platforms.
>>> [1] https://bugs.openjdk.java.net/browse/JDK-8204142
>>> [2]
>>> http://mail.openjdk.java.net/pipermail/awt-dev/2018-October/014492.h
>>> t
>>> ml
>>
>>
>> --
>> Best regards, Sergey.
> 


--
Best regards, Sergey.

From shashidhara.veerabhadraiah at oracle.com  Fri Mar  8 05:03:13 2019
From: shashidhara.veerabhadraiah at oracle.com (Shashidhara Veerabhadraiah)
Date: Thu, 7 Mar 2019 21:03:13 -0800 (PST)
Subject: <AWT Dev> <Swing Dev> [13] JDK-8216008:
 -Djavax.accessibility.assistive_technologies empty list leads to crash
In-Reply-To: <5C7FFF71.1020809@oracle.com>
References: <86dc6276-6a1c-4d09-8155-705fea8fd95e@default>
 <d1b5e58f-bfbd-3996-684d-2e74336cdc87@oracle.com>
 <465ad181-9c9c-4752-a3bc-595e82f08744@default>
 <a218d1b1-f003-f6b7-acfb-e50b9c27a56c@oracle.com>
 <c548de66-3c14-4488-b719-6a0cfde1dc9b@default>
 <9149f70d-5265-efb1-e496-48e159e61e92@oracle.com>
 <554176f6-b538-46b5-97bb-14e488f50656@default>
 <b99d879b-c2ce-358f-be3a-339d5faeff63@oracle.com>
 <daf49f44-1a41-8aa3-3c82-2fbd57ee7634@oracle.com>
 <a48ea2a7-ebdd-410d-b6f9-88288d6ee6d4@default> <5C5DEB0E.5010405@oracle.com>
 <23625b97-76d0-4956-8d4b-bf1add82ceb1@default>
 <1d4ad24a-e6bf-8e71-c88c-020e1106f089@oracle.com>
 <de99f10e-04da-4109-9980-4a8daf6a973c@default>
 <8634f5a6-a0a6-5739-9fd6-9a304a4a97f3@oracle.com>
 <70c695de-a54e-4aad-ae7b-0e11a6b9054e@default>
 <fdffa07a-7513-4a66-bbb9-5774b521b5d5@default>
 <f586ecc6-a795-4564-a825-0b66323a8326@default>
 <a2e461b3-c4e9-4955-8bec-44c8eb45b269@default> <5C7FFF71.1020809@oracle.com>
Message-ID: <88e0e602-7b4e-443d-95fe-a7fe288fa161@default>

Thank you Phil for the review and here are the updates done:

?

HYPERLINK "http://cr.openjdk.java.net/~sveerabhadra/8216008/webrev.08/"http://cr.openjdk.java.net/~sveerabhadra/8216008//webrev.08/

?

Thanks and regards,

Shashi

?

From: Philip Race 
Sent: Wednesday, March 6, 2019 10:42 PM
To: Shashidhara Veerabhadraiah <shashidhara.veerabhadraiah at oracle.com>
Cc: awt-dev at openjdk.java.net; swing-dev at openjdk.java.net; Joe Darcy <joe.darcy at oracle.com>
Subject: Re: <AWT Dev> <Swing Dev> [13] JDK-8216008: -Djavax.accessibility.assistive_technologies empty list leads to crash

?

the webrev needs a couple of minor tweaks :
?
contains empty string -> is the empty string
?
and
?
immeadiately -> immediately


Go ahead and finalize the CSR which looks OK.

-phil.

On 3/6/19, 11:45 AM, Shashidhara Veerabhadraiah wrote: 

Hi Phil\Sergey, Please review the CSR along with the bug fix.

?

Webrev: HYPERLINK "http://cr.openjdk.java.net/%7Esveerabhadra/8216008/webrev.07/"http://cr.openjdk.java.net/~sveerabhadra/8216008/webrev.07/

?

CSR: https://bugs.openjdk.java.net/browse/JDK-8218737

?

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

?

Thanks and regards,

Shashi

?

From: Shashidhara Veerabhadraiah 
Sent: Monday, March 4, 2019 3:36 PM
To: Philip Race HYPERLINK "mailto:philip.race at oracle.com"<philip.race at oracle.com>; Joe Darcy HYPERLINK "mailto:joe.darcy at oracle.com"<joe.darcy at oracle.com>
Cc: HYPERLINK "mailto:awt-dev at openjdk.java.net"awt-dev at openjdk.java.net; HYPERLINK "mailto:swing-dev at openjdk.java.net"swing-dev at openjdk.java.net
Subject: Re: <AWT Dev> <Swing Dev> [13] JDK-8216008: -Djavax.accessibility.assistive_technologies empty list leads to crash

?

Hi Joe, Please find the updated Webrev fixing the typo:

?

HYPERLINK "http://cr.openjdk.java.net/%7Esveerabhadra/8216008/webrev.07/"http://cr.openjdk.java.net/~sveerabhadra/8216008/webrev.07/

?

Thanks and regards,

Shashi

?

From: Shashidhara Veerabhadraiah 
Sent: Thursday, February 21, 2019 2:08 PM
To: Philip Race <HYPERLINK "mailto:philip.race at oracle.com"philip.race at oracle.com>; Joe Darcy <HYPERLINK "mailto:joe.darcy at oracle.com"joe.darcy at oracle.com>
Cc: HYPERLINK "mailto:awt-dev at openjdk.java.net"awt-dev at openjdk.java.net; HYPERLINK "mailto:swing-dev at openjdk.java.net"swing-dev at openjdk.java.net
Subject: Re: <AWT Dev> <Swing Dev> [13] JDK-8216008: -Djavax.accessibility.assistive_technologies empty list leads to crash

?

Hi Joe, Please find the new Webrev fixing the specification as asked in the CSR bug: https://bugs.openjdk.java.net/browse/JDK-8218737

?

Webrev: HYPERLINK "http://cr.openjdk.java.net/%7Esveerabhadra/8216008/webrev.06/"http://cr.openjdk.java.net/~sveerabhadra/8216008/webrev.06/

?

Thanks and regards,

Shashi

?

From: Shashidhara Veerabhadraiah 
Sent: Monday, February 18, 2019 10:19 AM
To: Philip Race <HYPERLINK "mailto:philip.race at oracle.com"philip.race at oracle.com>
Cc: HYPERLINK "mailto:awt-dev at openjdk.java.net"awt-dev at openjdk.java.net; HYPERLINK "mailto:swing-dev at openjdk.java.net"swing-dev at openjdk.java.net
Subject: Re: <AWT Dev> <Swing Dev> [13] JDK-8216008: -Djavax.accessibility.assistive_technologies empty list leads to crash

?

Thank you Phil for that help on CSR.

?

From: Phil Race 
Sent: Friday, February 15, 2019 9:41 PM
To: Shashidhara Veerabhadraiah <HYPERLINK "mailto:shashidhara.veerabhadraiah at oracle.com"shashidhara.veerabhadraiah at oracle.com>
Cc: Sergey Bylokhov <HYPERLINK "mailto:sergey.bylokhov at oracle.com"sergey.bylokhov at oracle.com>; HYPERLINK "mailto:awt-dev at openjdk.java.net"awt-dev at openjdk.java.net; HYPERLINK "mailto:swing-dev at openjdk.java.net"swing-dev at openjdk.java.net
Subject: Re: <Swing Dev> [13] JDK-8216008: -Djavax.accessibility.assistive_technologies empty list leads to crash

?

That text may actually be worse.
Although I maybe didn't get your distinction of null vs the empty string here ?

Oh, wait. Why is this doc clarification on the PRIVATE implementation method ?
It needs to go on the public getDefaultToolkit() method to have any point whatsoever
especially from a CSR perspective.
Try this :
-???? * toolkit is created. All errors are handled via an AWTError exception.
+???? * toolkit is created.
+???? * If the list of assistive technology providers is the empty string, or
+???? * contains only white space characters then the method returns immediately.
+???? * All other errors are handled via an AWTError exception.


I think the CSR needs some work too. I've made some updates there.

-phil.

On 2/15/19 2:10 AM, Shashidhara Veerabhadraiah wrote:

Hi Phil, I have updated the CSR and updated the information for the function and here is the new Webrev:

?

HYPERLINK "http://cr.openjdk.java.net/%7Esveerabhadra/8216008/webrev.05/"http://cr.openjdk.java.net/~sveerabhadra/8216008/webrev.05/

Thanks and regards,

Shashi

?

From: Phil Race 
Sent: Friday, February 15, 2019 2:58 AM
To: Shashidhara Veerabhadraiah HYPERLINK "mailto:shashidhara.veerabhadraiah at oracle.com"<shashidhara.veerabhadraiah at oracle.com>
Cc: Sergey Bylokhov HYPERLINK "mailto:sergey.bylokhov at oracle.com"<sergey.bylokhov at oracle.com>; HYPERLINK "mailto:awt-dev at openjdk.java.net"awt-dev at openjdk.java.net; HYPERLINK "mailto:swing-dev at openjdk.java.net"swing-dev at openjdk.java.net
Subject: Re: <Swing Dev> [13] JDK-8216008: -Djavax.accessibility.assistive_technologies empty list leads to crash

?

+???? * activate method.? If the list of assistive technology providers is empty string,
?
is "the" empty string.
?
?
The CSR needs to be updated to include this spec. 
What is there now in the specification section needs to be fixed
It should not point to the webrev or review and right now
doesn't contain the change to the javadoc in the body of the CSR
?
I think I even have to question most of the rest of it.
Any one reading it would think that we always used to throw an exception in such
case and now want to stop doing so. Isn't the bug that we did NOT throw an exception
and now we do ? You only hint at that when you say at the end of "Solution", "as was the case earlier"
?
If I am right the only thing you need in the CSR is to say that you
are reverting the implementation to previous behaviour and updating the
specification to make it clear that this behaviour is allowed by the spec
since this case was unclear.
?
-phil.

?

On 2/12/19 1:08 AM, Shashidhara Veerabhadraiah wrote:

Hi Phil, Here is the new Webrev and CSR for the same:

HYPERLINK "http://cr.openjdk.java.net/%7Esveerabhadra/8216008/webrev.04/"http://cr.openjdk.java.net/~sveerabhadra/8216008/webrev.04/

?

CSR: https://bugs.openjdk.java.net/browse/JDK-8218737

?

Thanks and regards,

Shashi

?

From: Philip Race 
Sent: Saturday, February 9, 2019 2:18 AM
To: Shashidhara Veerabhadraiah HYPERLINK "mailto:shashidhara.veerabhadraiah at oracle.com"<shashidhara.veerabhadraiah at oracle.com>
Cc: Sergey Bylokhov HYPERLINK "mailto:sergey.bylokhov at oracle.com"<sergey.bylokhov at oracle.com>; HYPERLINK "mailto:awt-dev at openjdk.java.net"awt-dev at openjdk.java.net; HYPERLINK "mailto:swing-dev at openjdk.java.net"swing-dev at openjdk.java.net
Subject: Re: <Swing Dev> [13] JDK-8216008: -Djavax.accessibility.assistive_technologies empty list leads to crash

?

FWIW I think this could be closed out as "not a bug".
An empty value string is an error and the spec. says AWTError is
how errors are reported. In fact I'll argue that 8 was wrong not
to have thrown an exception in such a case.
It was an accident of the implementation that it did not.
But if we want to be behaviourally compatible then ... 
Note that since you now document this you need an approved CSR BEFORE pushing it.

And if you go the CSR route you may need to be more precise about what
you mean by "empty".

I think it needs to say

"If the list of assistive technology providers is null, or contains only white
space characters then the method returns immediately.
All other errors are handled by throwing {@code AWTError}"

@throws AWTError if there is any error in parsing or loading the ATs.

-phil.

On 1/21/19, 9:12 AM, Shashidhara Veerabhadraiah wrote: 

Hi Sergey, Here is the new Webrev for your comments:
?
HYPERLINK "http://cr.openjdk.java.net/%7Esveerabhadra/8216008/webrev.02/"http://cr.openjdk.java.net/~sveerabhadra/8216008/webrev.02/
?
Thanks and regards,
Shashi
?
-----Original Message-----
From: Sergey Bylokhov 
Sent: Saturday, January 19, 2019 3:47 AM
To: Shashidhara Veerabhadraiah HYPERLINK "mailto:shashidhara.veerabhadraiah at oracle.com"<shashidhara.veerabhadraiah at oracle.com>; HYPERLINK "mailto:awt-dev at openjdk.java.net"awt-dev at openjdk.java.net; HYPERLINK "mailto:swing-dev at openjdk.java.net"swing-dev at openjdk.java.net
Subject: Re: <Swing Dev> [13] JDK-8216008: -Djavax.accessibility.assistive_technologies empty list leads to crash
?
On 16/01/2019 23:03, HYPERLINK "mailto:shashidhara.veerabhadraiah at oracle.com"shashidhara.veerabhadraiah at oracle.com wrote:

Another point is that the whitespace trimming should not trigger additional input processing? for the custom class that will be used for assistive technology. For eg., if custom class "FooProvider" is implemented and if we pass "? FooProvider? " by mistake, a bug may be created to trim the whitespace in this case as well!!

?
Yes, my previous email suggested to always trim the content of the "input", it will cover all cases, the "atNames" is empty, the "atNames" contains only the whitespace, or the name of the class has some spaces at the start/end.
?

?
Thanks and regards,
?
Shashi
?
?
On 17/01/19 10:28 AM, Shashidhara Veerabhadraiah wrote:

We need one way to tell the system not to load any assistive technologies and which is being provided.
If we add trailing white spaces removal then we may need to add another functionality to see if that class exists or not and based on that not to load anything(without throwing the error because we are parsing the input content). I think that would take a different direction. I feel it is fair enough to provide one way to tell not to load any assistive technologies and additional parsing would only lead to other ways/expectations.
?
Thanks and regards,
Shashi
?
-----Original Message-----
From: Sergey Bylokhov
Sent: Thursday, January 17, 2019 1:33 AM
To: Shashidhara Veerabhadraiah HYPERLINK "mailto:shashidhara.veerabhadraiah at oracle.com"<shashidhara.veerabhadraiah at oracle.com>; HYPERLINK "mailto:awt-dev at openjdk.java.net"awt-dev at openjdk.java.net; HYPERLINK "mailto:swing-dev at openjdk.java.net"swing-dev at openjdk.java.net
Subject: Re: <Swing Dev> [13] JDK-8216008: -Djavax.accessibility.assistive_technologies empty list leads to crash
?
I guess you meant whitespaces, then it is unclear why we should not consider "empty" parameter as a "mistake"?
?
On 15/01/2019 20:37, Shashidhara Veerabhadraiah wrote:

Hi Sergey, I felt that a string with an empty space is intentional and should be considering it as a 'mistake' if done by the developers. Hence I feel it is not required(as there is a way to tell nothing to load). Please let me know if you think otherwise.

?
?

Thanks and regards,
Shashi
?
-----Original Message-----
From: Sergey Bylokhov
Sent: Tuesday, January 15, 2019 7:32 AM
To: Shashidhara Veerabhadraiah HYPERLINK "mailto:shashidhara.veerabhadraiah at oracle.com"<shashidhara.veerabhadraiah at oracle.com>; HYPERLINK "mailto:awt-dev at openjdk.java.net"awt-dev at openjdk.java.net; HYPERLINK "mailto:swing-dev at openjdk.java.net"swing-dev at openjdk.java.net
Subject: Re: <Swing Dev> [13] JDK-8216008: -Djavax.accessibility.assistive_technologies empty list leads to crash
?
Hi, Shashi.
?
Should we trim all whitespaces from the "atNames"?
Otherwise the "atNames", which contains only one whitespace, will trigger the same error.
?
On 09/01/2019 00:20, Shashidhara Veerabhadraiah wrote:

Hi Sergey, Thanks for pointing that out. Here is the new Webrev:
?
HYPERLINK "http://cr.openjdk.java.net/%7Esveerabhadra/8216008/webrev.01/"http://cr.openjdk.java.net/~sveerabhadra/8216008/webrev.01/
?
Thanks and regards,
Shashi
?
-----Original Message-----
From: Sergey Bylokhov
Sent: Friday, January 4, 2019 3:48 AM
To: Shashidhara Veerabhadraiah HYPERLINK "mailto:shashidhara.veerabhadraiah at oracle.com"<shashidhara.veerabhadraiah at oracle.com>; HYPERLINK "mailto:awt-dev at openjdk.java.net"awt-dev at openjdk.java.net; HYPERLINK "mailto:swing-dev at openjdk.java.net"swing-dev at openjdk.java.net
Subject: Re: <Swing Dev> [13] JDK-8216008: -Djavax.accessibility.assistive_technologies empty list leads to crash
?
Hi, Shashi.
I think you can update an existing test:
open/test/jdk/javax/accessibility/AccessibilityProvider/basic.sh
?
On 03/01/2019 01:36, Shashidhara Veerabhadraiah wrote:

Hi All, Please review a fix for the below bug.
?
Bug: https://bugs.openjdk.java.net/browse/JDK-8216008
?
Webrev: HYPERLINK "http://cr.openjdk.java.net/%7Esveerabhadra/8216008/webrev.00/"http://cr.openjdk.java.net/~sveerabhadra/8216008/webrev.00/
?
Since the mentioned list of assistive technologies for the system property(javax.accessibility.assistive_technologies) is loaded by jvm am unable to write a test case for this bug. The test file attached with the bug can be used for testing this fix.
?
This fix removes the error(class not found error) by passing an empty list to system variable javax.accessibility.assistive_technologies and does not load any assistive technologies(as the list is empty). Currently empty list produce a crash which is not required as there was no class name mentioned in the list. Please read the bug comments for more information.
?
Thanks and regards,
?
Shashi
?

?

?

?

?

?
?

?

?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/awt-dev/attachments/20190307/8793c887/attachment-0001.html>

From shashidhara.veerabhadraiah at oracle.com  Fri Mar  8 06:11:45 2019
From: shashidhara.veerabhadraiah at oracle.com (Shashidhara Veerabhadraiah)
Date: Thu, 7 Mar 2019 22:11:45 -0800 (PST)
Subject: <AWT Dev> <Swing Dev> [13] JDK-8216008:
 -Djavax.accessibility.assistive_technologies empty list leads to crash
In-Reply-To: <88e0e602-7b4e-443d-95fe-a7fe288fa161@default>
References: <86dc6276-6a1c-4d09-8155-705fea8fd95e@default>
 <d1b5e58f-bfbd-3996-684d-2e74336cdc87@oracle.com>
 <465ad181-9c9c-4752-a3bc-595e82f08744@default>
 <a218d1b1-f003-f6b7-acfb-e50b9c27a56c@oracle.com>
 <c548de66-3c14-4488-b719-6a0cfde1dc9b@default>
 <9149f70d-5265-efb1-e496-48e159e61e92@oracle.com>
 <554176f6-b538-46b5-97bb-14e488f50656@default>
 <b99d879b-c2ce-358f-be3a-339d5faeff63@oracle.com>
 <daf49f44-1a41-8aa3-3c82-2fbd57ee7634@oracle.com>
 <a48ea2a7-ebdd-410d-b6f9-88288d6ee6d4@default> <5C5DEB0E.5010405@oracle.com>
 <23625b97-76d0-4956-8d4b-bf1add82ceb1@default>
 <1d4ad24a-e6bf-8e71-c88c-020e1106f089@oracle.com>
 <de99f10e-04da-4109-9980-4a8daf6a973c@default>
 <8634f5a6-a0a6-5739-9fd6-9a304a4a97f3@oracle.com>
 <70c695de-a54e-4aad-ae7b-0e11a6b9054e@default>
 <fdffa07a-7513-4a66-bbb9-5774b521b5d5@default>
 <f586ecc6-a795-4564-a825-0b66323a8326@default>
 <a2e461b3-c4e9-4955-8bec-44c8eb45b269@default> <5C7FFF71.1020809@oracle.com>
 <88e0e602-7b4e-443d-95fe-a7fe288fa161@default>
Message-ID: <fcce40df-1b75-41ea-9381-f8fd5086d4ee@default>

Hi Phil, As discussed here are the updates for the Webrev. Hopefully this is correct.

?

http://cr.openjdk.java.net/~sveerabhadra/8216008/webrev.09/

?

Thanks and regards,

Shashi

?

From: Shashidhara Veerabhadraiah 
Sent: Friday, March 8, 2019 10:33 AM
To: Philip Race <philip.race at oracle.com>
Cc: awt-dev at openjdk.java.net; Joe Darcy <joe.darcy at oracle.com>; swing-dev at openjdk.java.net
Subject: Re: <AWT Dev> <Swing Dev> [13] JDK-8216008: -Djavax.accessibility.assistive_technologies empty list leads to crash

?

Thank you Phil for the review and here are the updates done:

?

HYPERLINK "http://cr.openjdk.java.net/~sveerabhadra/8216008/webrev.08/"http://cr.openjdk.java.net/~sveerabhadra/8216008//webrev.08/

?

Thanks and regards,

Shashi

?

From: Philip Race 
Sent: Wednesday, March 6, 2019 10:42 PM
To: Shashidhara Veerabhadraiah <HYPERLINK "mailto:shashidhara.veerabhadraiah at oracle.com"shashidhara.veerabhadraiah at oracle.com>
Cc: HYPERLINK "mailto:awt-dev at openjdk.java.net"awt-dev at openjdk.java.net; HYPERLINK "mailto:swing-dev at openjdk.java.net"swing-dev at openjdk.java.net; Joe Darcy <HYPERLINK "mailto:joe.darcy at oracle.com"joe.darcy at oracle.com>
Subject: Re: <AWT Dev> <Swing Dev> [13] JDK-8216008: -Djavax.accessibility.assistive_technologies empty list leads to crash

?

the webrev needs a couple of minor tweaks :
?
contains empty string -> is the empty string
?
and
?
immeadiately -> immediately


Go ahead and finalize the CSR which looks OK.

-phil.

On 3/6/19, 11:45 AM, Shashidhara Veerabhadraiah wrote: 

Hi Phil\Sergey, Please review the CSR along with the bug fix.

?

Webrev: HYPERLINK "http://cr.openjdk.java.net/%7Esveerabhadra/8216008/webrev.07/"http://cr.openjdk.java.net/~sveerabhadra/8216008/webrev.07/

?

CSR: https://bugs.openjdk.java.net/browse/JDK-8218737

?

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

?

Thanks and regards,

Shashi

?

From: Shashidhara Veerabhadraiah 
Sent: Monday, March 4, 2019 3:36 PM
To: Philip Race HYPERLINK "mailto:philip.race at oracle.com"<philip.race at oracle.com>; Joe Darcy HYPERLINK "mailto:joe.darcy at oracle.com"<joe.darcy at oracle.com>
Cc: HYPERLINK "mailto:awt-dev at openjdk.java.net"awt-dev at openjdk.java.net; HYPERLINK "mailto:swing-dev at openjdk.java.net"swing-dev at openjdk.java.net
Subject: Re: <AWT Dev> <Swing Dev> [13] JDK-8216008: -Djavax.accessibility.assistive_technologies empty list leads to crash

?

Hi Joe, Please find the updated Webrev fixing the typo:

?

HYPERLINK "http://cr.openjdk.java.net/%7Esveerabhadra/8216008/webrev.07/"http://cr.openjdk.java.net/~sveerabhadra/8216008/webrev.07/

?

Thanks and regards,

Shashi

?

From: Shashidhara Veerabhadraiah 
Sent: Thursday, February 21, 2019 2:08 PM
To: Philip Race <HYPERLINK "mailto:philip.race at oracle.com"philip.race at oracle.com>; Joe Darcy <HYPERLINK "mailto:joe.darcy at oracle.com"joe.darcy at oracle.com>
Cc: HYPERLINK "mailto:awt-dev at openjdk.java.net"awt-dev at openjdk.java.net; HYPERLINK "mailto:swing-dev at openjdk.java.net"swing-dev at openjdk.java.net
Subject: Re: <AWT Dev> <Swing Dev> [13] JDK-8216008: -Djavax.accessibility.assistive_technologies empty list leads to crash

?

Hi Joe, Please find the new Webrev fixing the specification as asked in the CSR bug: https://bugs.openjdk.java.net/browse/JDK-8218737

?

Webrev: HYPERLINK "http://cr.openjdk.java.net/%7Esveerabhadra/8216008/webrev.06/"http://cr.openjdk.java.net/~sveerabhadra/8216008/webrev.06/

?

Thanks and regards,

Shashi

?

From: Shashidhara Veerabhadraiah 
Sent: Monday, February 18, 2019 10:19 AM
To: Philip Race <HYPERLINK "mailto:philip.race at oracle.com"philip.race at oracle.com>
Cc: HYPERLINK "mailto:awt-dev at openjdk.java.net"awt-dev at openjdk.java.net; HYPERLINK "mailto:swing-dev at openjdk.java.net"swing-dev at openjdk.java.net
Subject: Re: <AWT Dev> <Swing Dev> [13] JDK-8216008: -Djavax.accessibility.assistive_technologies empty list leads to crash

?

Thank you Phil for that help on CSR.

?

From: Phil Race 
Sent: Friday, February 15, 2019 9:41 PM
To: Shashidhara Veerabhadraiah <HYPERLINK "mailto:shashidhara.veerabhadraiah at oracle.com"shashidhara.veerabhadraiah at oracle.com>
Cc: Sergey Bylokhov <HYPERLINK "mailto:sergey.bylokhov at oracle.com"sergey.bylokhov at oracle.com>; HYPERLINK "mailto:awt-dev at openjdk.java.net"awt-dev at openjdk.java.net; HYPERLINK "mailto:swing-dev at openjdk.java.net"swing-dev at openjdk.java.net
Subject: Re: <Swing Dev> [13] JDK-8216008: -Djavax.accessibility.assistive_technologies empty list leads to crash

?

That text may actually be worse.
Although I maybe didn't get your distinction of null vs the empty string here ?

Oh, wait. Why is this doc clarification on the PRIVATE implementation method ?
It needs to go on the public getDefaultToolkit() method to have any point whatsoever
especially from a CSR perspective.
Try this :
-???? * toolkit is created. All errors are handled via an AWTError exception.
+???? * toolkit is created.
+???? * If the list of assistive technology providers is the empty string, or
+???? * contains only white space characters then the method returns immediately.
+???? * All other errors are handled via an AWTError exception.


I think the CSR needs some work too. I've made some updates there.

-phil.

On 2/15/19 2:10 AM, Shashidhara Veerabhadraiah wrote:

Hi Phil, I have updated the CSR and updated the information for the function and here is the new Webrev:

?

HYPERLINK "http://cr.openjdk.java.net/%7Esveerabhadra/8216008/webrev.05/"http://cr.openjdk.java.net/~sveerabhadra/8216008/webrev.05/

Thanks and regards,

Shashi

?

From: Phil Race 
Sent: Friday, February 15, 2019 2:58 AM
To: Shashidhara Veerabhadraiah HYPERLINK "mailto:shashidhara.veerabhadraiah at oracle.com"<shashidhara.veerabhadraiah at oracle.com>
Cc: Sergey Bylokhov HYPERLINK "mailto:sergey.bylokhov at oracle.com"<sergey.bylokhov at oracle.com>; HYPERLINK "mailto:awt-dev at openjdk.java.net"awt-dev at openjdk.java.net; HYPERLINK "mailto:swing-dev at openjdk.java.net"swing-dev at openjdk.java.net
Subject: Re: <Swing Dev> [13] JDK-8216008: -Djavax.accessibility.assistive_technologies empty list leads to crash

?

+???? * activate method.? If the list of assistive technology providers is empty string,
?
is "the" empty string.
?
?
The CSR needs to be updated to include this spec. 
What is there now in the specification section needs to be fixed
It should not point to the webrev or review and right now
doesn't contain the change to the javadoc in the body of the CSR
?
I think I even have to question most of the rest of it.
Any one reading it would think that we always used to throw an exception in such
case and now want to stop doing so. Isn't the bug that we did NOT throw an exception
and now we do ? You only hint at that when you say at the end of "Solution", "as was the case earlier"
?
If I am right the only thing you need in the CSR is to say that you
are reverting the implementation to previous behaviour and updating the
specification to make it clear that this behaviour is allowed by the spec
since this case was unclear.
?
-phil.

?

On 2/12/19 1:08 AM, Shashidhara Veerabhadraiah wrote:

Hi Phil, Here is the new Webrev and CSR for the same:

HYPERLINK "http://cr.openjdk.java.net/%7Esveerabhadra/8216008/webrev.04/"http://cr.openjdk.java.net/~sveerabhadra/8216008/webrev.04/

?

CSR: https://bugs.openjdk.java.net/browse/JDK-8218737

?

Thanks and regards,

Shashi

?

From: Philip Race 
Sent: Saturday, February 9, 2019 2:18 AM
To: Shashidhara Veerabhadraiah HYPERLINK "mailto:shashidhara.veerabhadraiah at oracle.com"<shashidhara.veerabhadraiah at oracle.com>
Cc: Sergey Bylokhov HYPERLINK "mailto:sergey.bylokhov at oracle.com"<sergey.bylokhov at oracle.com>; HYPERLINK "mailto:awt-dev at openjdk.java.net"awt-dev at openjdk.java.net; HYPERLINK "mailto:swing-dev at openjdk.java.net"swing-dev at openjdk.java.net
Subject: Re: <Swing Dev> [13] JDK-8216008: -Djavax.accessibility.assistive_technologies empty list leads to crash

?

FWIW I think this could be closed out as "not a bug".
An empty value string is an error and the spec. says AWTError is
how errors are reported. In fact I'll argue that 8 was wrong not
to have thrown an exception in such a case.
It was an accident of the implementation that it did not.
But if we want to be behaviourally compatible then ... 
Note that since you now document this you need an approved CSR BEFORE pushing it.

And if you go the CSR route you may need to be more precise about what
you mean by "empty".

I think it needs to say

"If the list of assistive technology providers is null, or contains only white
space characters then the method returns immediately.
All other errors are handled by throwing {@code AWTError}"

@throws AWTError if there is any error in parsing or loading the ATs.

-phil.

On 1/21/19, 9:12 AM, Shashidhara Veerabhadraiah wrote: 

Hi Sergey, Here is the new Webrev for your comments:
?
HYPERLINK "http://cr.openjdk.java.net/%7Esveerabhadra/8216008/webrev.02/"http://cr.openjdk.java.net/~sveerabhadra/8216008/webrev.02/
?
Thanks and regards,
Shashi
?
-----Original Message-----
From: Sergey Bylokhov 
Sent: Saturday, January 19, 2019 3:47 AM
To: Shashidhara Veerabhadraiah HYPERLINK "mailto:shashidhara.veerabhadraiah at oracle.com"<shashidhara.veerabhadraiah at oracle.com>; HYPERLINK "mailto:awt-dev at openjdk.java.net"awt-dev at openjdk.java.net; HYPERLINK "mailto:swing-dev at openjdk.java.net"swing-dev at openjdk.java.net
Subject: Re: <Swing Dev> [13] JDK-8216008: -Djavax.accessibility.assistive_technologies empty list leads to crash
?
On 16/01/2019 23:03, HYPERLINK "mailto:shashidhara.veerabhadraiah at oracle.com"shashidhara.veerabhadraiah at oracle.com wrote:

Another point is that the whitespace trimming should not trigger additional input processing? for the custom class that will be used for assistive technology. For eg., if custom class "FooProvider" is implemented and if we pass "? FooProvider? " by mistake, a bug may be created to trim the whitespace in this case as well!!

?
Yes, my previous email suggested to always trim the content of the "input", it will cover all cases, the "atNames" is empty, the "atNames" contains only the whitespace, or the name of the class has some spaces at the start/end.
?

?
Thanks and regards,
?
Shashi
?
?
On 17/01/19 10:28 AM, Shashidhara Veerabhadraiah wrote:

We need one way to tell the system not to load any assistive technologies and which is being provided.
If we add trailing white spaces removal then we may need to add another functionality to see if that class exists or not and based on that not to load anything(without throwing the error because we are parsing the input content). I think that would take a different direction. I feel it is fair enough to provide one way to tell not to load any assistive technologies and additional parsing would only lead to other ways/expectations.
?
Thanks and regards,
Shashi
?
-----Original Message-----
From: Sergey Bylokhov
Sent: Thursday, January 17, 2019 1:33 AM
To: Shashidhara Veerabhadraiah HYPERLINK "mailto:shashidhara.veerabhadraiah at oracle.com"<shashidhara.veerabhadraiah at oracle.com>; HYPERLINK "mailto:awt-dev at openjdk.java.net"awt-dev at openjdk.java.net; HYPERLINK "mailto:swing-dev at openjdk.java.net"swing-dev at openjdk.java.net
Subject: Re: <Swing Dev> [13] JDK-8216008: -Djavax.accessibility.assistive_technologies empty list leads to crash
?
I guess you meant whitespaces, then it is unclear why we should not consider "empty" parameter as a "mistake"?
?
On 15/01/2019 20:37, Shashidhara Veerabhadraiah wrote:

Hi Sergey, I felt that a string with an empty space is intentional and should be considering it as a 'mistake' if done by the developers. Hence I feel it is not required(as there is a way to tell nothing to load). Please let me know if you think otherwise.

?
?

Thanks and regards,
Shashi
?
-----Original Message-----
From: Sergey Bylokhov
Sent: Tuesday, January 15, 2019 7:32 AM
To: Shashidhara Veerabhadraiah HYPERLINK "mailto:shashidhara.veerabhadraiah at oracle.com"<shashidhara.veerabhadraiah at oracle.com>; HYPERLINK "mailto:awt-dev at openjdk.java.net"awt-dev at openjdk.java.net; HYPERLINK "mailto:swing-dev at openjdk.java.net"swing-dev at openjdk.java.net
Subject: Re: <Swing Dev> [13] JDK-8216008: -Djavax.accessibility.assistive_technologies empty list leads to crash
?
Hi, Shashi.
?
Should we trim all whitespaces from the "atNames"?
Otherwise the "atNames", which contains only one whitespace, will trigger the same error.
?
On 09/01/2019 00:20, Shashidhara Veerabhadraiah wrote:

Hi Sergey, Thanks for pointing that out. Here is the new Webrev:
?
HYPERLINK "http://cr.openjdk.java.net/%7Esveerabhadra/8216008/webrev.01/"http://cr.openjdk.java.net/~sveerabhadra/8216008/webrev.01/
?
Thanks and regards,
Shashi
?
-----Original Message-----
From: Sergey Bylokhov
Sent: Friday, January 4, 2019 3:48 AM
To: Shashidhara Veerabhadraiah HYPERLINK "mailto:shashidhara.veerabhadraiah at oracle.com"<shashidhara.veerabhadraiah at oracle.com>; HYPERLINK "mailto:awt-dev at openjdk.java.net"awt-dev at openjdk.java.net; HYPERLINK "mailto:swing-dev at openjdk.java.net"swing-dev at openjdk.java.net
Subject: Re: <Swing Dev> [13] JDK-8216008: -Djavax.accessibility.assistive_technologies empty list leads to crash
?
Hi, Shashi.
I think you can update an existing test:
open/test/jdk/javax/accessibility/AccessibilityProvider/basic.sh
?
On 03/01/2019 01:36, Shashidhara Veerabhadraiah wrote:

Hi All, Please review a fix for the below bug.
?
Bug: https://bugs.openjdk.java.net/browse/JDK-8216008
?
Webrev: HYPERLINK "http://cr.openjdk.java.net/%7Esveerabhadra/8216008/webrev.00/"http://cr.openjdk.java.net/~sveerabhadra/8216008/webrev.00/
?
Since the mentioned list of assistive technologies for the system property(javax.accessibility.assistive_technologies) is loaded by jvm am unable to write a test case for this bug. The test file attached with the bug can be used for testing this fix.
?
This fix removes the error(class not found error) by passing an empty list to system variable javax.accessibility.assistive_technologies and does not load any assistive technologies(as the list is empty). Currently empty list produce a crash which is not required as there was no class name mentioned in the list. Please read the bug comments for more information.
?
Thanks and regards,
?
Shashi
?

?

?

?

?

?
?

?

?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/awt-dev/attachments/20190307/08bb943b/attachment-0001.html>

From philip.race at oracle.com  Fri Mar  8 06:47:41 2019
From: philip.race at oracle.com (Philip Race)
Date: Fri, 08 Mar 2019 12:17:41 +0530
Subject: <AWT Dev> <Swing Dev> [13] JDK-8216008:
 -Djavax.accessibility.assistive_technologies empty list leads to crash
In-Reply-To: <fcce40df-1b75-41ea-9381-f8fd5086d4ee@default>
References: <86dc6276-6a1c-4d09-8155-705fea8fd95e@default>
 <465ad181-9c9c-4752-a3bc-595e82f08744@default>
 <a218d1b1-f003-f6b7-acfb-e50b9c27a56c@oracle.com>
 <c548de66-3c14-4488-b719-6a0cfde1dc9b@default>
 <9149f70d-5265-efb1-e496-48e159e61e92@oracle.com>
 <554176f6-b538-46b5-97bb-14e488f50656@default>
 <b99d879b-c2ce-358f-be3a-339d5faeff63@oracle.com>
 <daf49f44-1a41-8aa3-3c82-2fbd57ee7634@oracle.com>
 <a48ea2a7-ebdd-410d-b6f9-88288d6ee6d4@default> <5C5DEB0E.5010405@oracle.com>
 <23625b97-76d0-4956-8d4b-bf1add82ceb1@default>
 <1d4ad24a-e6bf-8e71-c88c-020e1106f089@oracle.com>
 <de99f10e-04da-4109-9980-4a8daf6a973c@default>
 <8634f5a6-a0a6-5739-9fd6-9a304a4a97f3@oracle.com>
 <70c695de-a54e-4aad-ae7b-0e11a6b9054e@default>
 <fdffa07a-7513-4a66-bbb9-5774b521b5d5@default>
 <f586ecc6-a795-4564-a825-0b66323a8326@default>
 <a2e461b3-c4e9-4955-8bec-44c8eb45b269@default> <5C7FFF71.1020809@oracle.com>
 <88e0e602-7b4e-443d-95fe-a7fe288fa161@default>
 <fcce40df-1b75-41ea-9381-f8fd5086d4ee@default>
Message-ID: <5C82100D.8030106@oracle.com>

Ok but you need to wait for the CSR to be approved before you can push.

-phil.

On 3/8/19, 11:41 AM, Shashidhara Veerabhadraiah wrote:
>
> Hi Phil, As discussed here are the updates for the Webrev. Hopefully 
> this is correct.
>
> http://cr.openjdk.java.net/~sveerabhadra/8216008/webrev.09/ 
> <http://cr.openjdk.java.net/%7Esveerabhadra/8216008/webrev.09/>
>
> Thanks and regards,
>
> Shashi
>
> *From:*Shashidhara Veerabhadraiah
> *Sent:* Friday, March 8, 2019 10:33 AM
> *To:* Philip Race <philip.race at oracle.com>
> *Cc:* awt-dev at openjdk.java.net; Joe Darcy <joe.darcy at oracle.com>; 
> swing-dev at openjdk.java.net
> *Subject:* Re: <AWT Dev> <Swing Dev> [13] JDK-8216008: 
> -Djavax.accessibility.assistive_technologies empty list leads to crash
>
> Thank you Phil for the review and here are the updates done:
>
> http://cr.openjdk.java.net/~sveerabhadra/8216008//webrev.08/ 
> <http://cr.openjdk.java.net/%7Esveerabhadra/8216008/webrev.08/>
>
> Thanks and regards,
>
> Shashi
>
> *From:*Philip Race
> *Sent:* Wednesday, March 6, 2019 10:42 PM
> *To:* Shashidhara Veerabhadraiah 
> <shashidhara.veerabhadraiah at oracle.com 
> <mailto:shashidhara.veerabhadraiah at oracle.com>>
> *Cc:* awt-dev at openjdk.java.net <mailto:awt-dev at openjdk.java.net>; 
> swing-dev at openjdk.java.net <mailto:swing-dev at openjdk.java.net>; Joe 
> Darcy <joe.darcy at oracle.com <mailto:joe.darcy at oracle.com>>
> *Subject:* Re: <AWT Dev> <Swing Dev> [13] JDK-8216008: 
> -Djavax.accessibility.assistive_technologies empty list leads to crash
>
> the webrev needs a couple of minor tweaks :
>   
> contains empty string  ->  is the empty string
>   
> and
>   
> immeadiately ->  immediately
>
>
> Go ahead and finalize the CSR which looks OK.
>
> -phil.
>
> On 3/6/19, 11:45 AM, Shashidhara Veerabhadraiah wrote:
>
>     Hi Phil\Sergey, Please review the CSR along with the bug fix.
>
>     Webrev:
>     http://cr.openjdk.java.net/~sveerabhadra/8216008/webrev.07/
>     <http://cr.openjdk.java.net/%7Esveerabhadra/8216008/webrev.07/>
>
>     CSR: https://bugs.openjdk.java.net/browse/JDK-8218737
>
>     Bug: https://bugs.openjdk.java.net/browse/JDK-8216008
>
>     Thanks and regards,
>
>     Shashi
>
>     *From:*Shashidhara Veerabhadraiah
>     *Sent:* Monday, March 4, 2019 3:36 PM
>     *To:* Philip Race <philip.race at oracle.com>
>     <mailto:philip.race at oracle.com>; Joe Darcy <joe.darcy at oracle.com>
>     <mailto:joe.darcy at oracle.com>
>     *Cc:* awt-dev at openjdk.java.net <mailto:awt-dev at openjdk.java.net>;
>     swing-dev at openjdk.java.net <mailto:swing-dev at openjdk.java.net>
>     *Subject:* Re: <AWT Dev> <Swing Dev> [13] JDK-8216008:
>     -Djavax.accessibility.assistive_technologies empty list leads to crash
>
>     Hi Joe, Please find the updated Webrev fixing the typo:
>
>     http://cr.openjdk.java.net/~sveerabhadra/8216008/webrev.07/
>     <http://cr.openjdk.java.net/%7Esveerabhadra/8216008/webrev.07/>
>
>     Thanks and regards,
>
>     Shashi
>
>     *From:*Shashidhara Veerabhadraiah
>     *Sent:* Thursday, February 21, 2019 2:08 PM
>     *To:* Philip Race <philip.race at oracle.com
>     <mailto:philip.race at oracle.com>>; Joe Darcy <joe.darcy at oracle.com
>     <mailto:joe.darcy at oracle.com>>
>     *Cc:* awt-dev at openjdk.java.net <mailto:awt-dev at openjdk.java.net>;
>     swing-dev at openjdk.java.net <mailto:swing-dev at openjdk.java.net>
>     *Subject:* Re: <AWT Dev> <Swing Dev> [13] JDK-8216008:
>     -Djavax.accessibility.assistive_technologies empty list leads to crash
>
>     Hi Joe, Please find the new Webrev fixing the specification as
>     asked in the CSR bug: https://bugs.openjdk.java.net/browse/JDK-8218737
>
>     Webrev:
>     http://cr.openjdk.java.net/~sveerabhadra/8216008/webrev.06/
>     <http://cr.openjdk.java.net/%7Esveerabhadra/8216008/webrev.06/>
>
>     Thanks and regards,
>
>     Shashi
>
>     *From:*Shashidhara Veerabhadraiah
>     *Sent:* Monday, February 18, 2019 10:19 AM
>     *To:* Philip Race <philip.race at oracle.com
>     <mailto:philip.race at oracle.com>>
>     *Cc:* awt-dev at openjdk.java.net <mailto:awt-dev at openjdk.java.net>;
>     swing-dev at openjdk.java.net <mailto:swing-dev at openjdk.java.net>
>     *Subject:* Re: <AWT Dev> <Swing Dev> [13] JDK-8216008:
>     -Djavax.accessibility.assistive_technologies empty list leads to crash
>
>     Thank you Phil for that help on CSR.
>
>     *From:*Phil Race
>     *Sent:* Friday, February 15, 2019 9:41 PM
>     *To:* Shashidhara Veerabhadraiah
>     <shashidhara.veerabhadraiah at oracle.com
>     <mailto:shashidhara.veerabhadraiah at oracle.com>>
>     *Cc:* Sergey Bylokhov <sergey.bylokhov at oracle.com
>     <mailto:sergey.bylokhov at oracle.com>>; awt-dev at openjdk.java.net
>     <mailto:awt-dev at openjdk.java.net>; swing-dev at openjdk.java.net
>     <mailto:swing-dev at openjdk.java.net>
>     *Subject:* Re: <Swing Dev> [13] JDK-8216008:
>     -Djavax.accessibility.assistive_technologies empty list leads to crash
>
>     That text may actually be worse.
>     Although I maybe didn't get your distinction of null vs the empty
>     string here ?
>
>     Oh, wait. Why is this doc clarification on the PRIVATE
>     implementation method ?
>     It needs to go on the public getDefaultToolkit() method to have
>     any point whatsoever
>     especially from a CSR perspective.
>     Try this :
>     -     * toolkit is created. All errors are handled via an AWTError
>     exception.
>     +     * toolkit is created.
>     +     * If the list of assistive technology providers is the empty
>     string, or
>     +     * contains only white space characters then the method
>     returns immediately.
>     +     * All other errors are handled via an AWTError exception.
>
>
>     I think the CSR needs some work too. I've made some updates there.
>
>     -phil.
>
>     On 2/15/19 2:10 AM, Shashidhara Veerabhadraiah wrote:
>
>         Hi Phil, I have updated the CSR and updated the information
>         for the function and here is the new Webrev:
>
>         http://cr.openjdk.java.net/~sveerabhadra/8216008/webrev.05/
>         <http://cr.openjdk.java.net/%7Esveerabhadra/8216008/webrev.05/>
>
>         Thanks and regards,
>
>         Shashi
>
>         *From:*Phil Race
>         *Sent:* Friday, February 15, 2019 2:58 AM
>         *To:* Shashidhara Veerabhadraiah
>         <shashidhara.veerabhadraiah at oracle.com>
>         <mailto:shashidhara.veerabhadraiah at oracle.com>
>         *Cc:* Sergey Bylokhov <sergey.bylokhov at oracle.com>
>         <mailto:sergey.bylokhov at oracle.com>; awt-dev at openjdk.java.net
>         <mailto:awt-dev at openjdk.java.net>; swing-dev at openjdk.java.net
>         <mailto:swing-dev at openjdk.java.net>
>         *Subject:* Re: <Swing Dev> [13] JDK-8216008:
>         -Djavax.accessibility.assistive_technologies empty list leads
>         to crash
>
>         +     * activate method.  If the list of assistive technology providers is empty string,
>
>           
>
>         is "the" empty string.
>
>           
>
>           
>
>         The CSR needs to be updated to include this spec.
>
>         What is there now in the specification section needs to be fixed
>
>         It should not point to the webrev or review and right now
>
>         doesn't contain the change to the javadoc in the body of the CSR
>
>           
>
>         I think I even have to question most of the rest of it.
>
>         Any one reading it would think that we always used to throw an exception in such
>
>         case and now want to stop doing so. Isn't the bug that we did NOT throw an exception
>
>         and now we do ? You only hint at that when you say at the end of "Solution", "as was the case earlier"
>
>           
>
>         If I am right the only thing you need in the CSR is to say that you
>
>         are reverting the implementation to previous behaviour and updating the
>
>         specification to make it clear that this behaviour is allowed by the spec
>
>         since this case was unclear.
>
>           
>
>         -phil.
>
>         On 2/12/19 1:08 AM, Shashidhara Veerabhadraiah wrote:
>
>             Hi Phil, Here is the new Webrev and CSR for the same:
>
>             http://cr.openjdk.java.net/~sveerabhadra/8216008/webrev.04/ <http://cr.openjdk.java.net/%7Esveerabhadra/8216008/webrev.04/>
>
>             CSR: https://bugs.openjdk.java.net/browse/JDK-8218737
>
>             Thanks and regards,
>
>             Shashi
>
>             *From:*Philip Race
>             *Sent:* Saturday, February 9, 2019 2:18 AM
>             *To:* Shashidhara Veerabhadraiah
>             <shashidhara.veerabhadraiah at oracle.com>
>             <mailto:shashidhara.veerabhadraiah at oracle.com>
>             *Cc:* Sergey Bylokhov <sergey.bylokhov at oracle.com>
>             <mailto:sergey.bylokhov at oracle.com>;
>             awt-dev at openjdk.java.net
>             <mailto:awt-dev at openjdk.java.net>;
>             swing-dev at openjdk.java.net <mailto:swing-dev at openjdk.java.net>
>             *Subject:* Re: <Swing Dev> [13] JDK-8216008:
>             -Djavax.accessibility.assistive_technologies empty list
>             leads to crash
>
>             FWIW I think this could be closed out as "not a bug".
>             An empty value string is an error and the spec. says
>             AWTError is
>             how errors are reported. In fact I'll argue that 8 was
>             wrong not
>             to have thrown an exception in such a case.
>             It was an accident of the implementation that it did not.
>             But if we want to be behaviourally compatible then ...
>             Note that since you now document this you need an approved
>             CSR BEFORE pushing it.
>
>             And if you go the CSR route you may need to be more
>             precise about what
>             you mean by "empty".
>
>             I think it needs to say
>
>             "If the list of assistive technology providers is null, or
>             contains only white
>             space characters then the method returns immediately.
>             All other errors are handled by throwing {@code AWTError}"
>
>             @throws AWTError if there is any error in parsing or
>             loading the ATs.
>
>             -phil.
>
>             On 1/21/19, 9:12 AM, Shashidhara Veerabhadraiah wrote:
>
>                 Hi Sergey, Here is the new Webrev for your comments:
>
>                   
>
>                 http://cr.openjdk.java.net/~sveerabhadra/8216008/webrev.02/  <http://cr.openjdk.java.net/%7Esveerabhadra/8216008/webrev.02/>
>
>                   
>
>                 Thanks and regards,
>
>                 Shashi
>
>                   
>
>                 -----Original Message-----
>
>                 From: Sergey Bylokhov
>
>                 Sent: Saturday, January 19, 2019 3:47 AM
>
>                 To: Shashidhara Veerabhadraiah<shashidhara.veerabhadraiah at oracle.com>  <mailto:shashidhara.veerabhadraiah at oracle.com>;awt-dev at openjdk.java.net  <mailto:awt-dev at openjdk.java.net>;swing-dev at openjdk.java.net  <mailto:swing-dev at openjdk.java.net>
>
>                 Subject: Re:<Swing Dev>  [13] JDK-8216008: -Djavax.accessibility.assistive_technologies empty list leads to crash
>
>                   
>
>                 On 16/01/2019 23:03,shashidhara.veerabhadraiah at oracle.com  <mailto:shashidhara.veerabhadraiah at oracle.com>  wrote:
>
>                     Another point is that the whitespace trimming should not trigger additional input processing  for the custom class that will be used for assistive technology. For eg., if custom class "FooProvider" is implemented and if we pass "  FooProvider  " by mistake, a bug may be created to trim the whitespace in this case as well!!
>
>                   
>
>                 Yes, my previous email suggested to always trim the content of the "input", it will cover all cases, the "atNames" is empty, the "atNames" contains only the whitespace, or the name of the class has some spaces at the start/end.
>
>                   
>
>                       
>
>                     Thanks and regards,
>
>                       
>
>                     Shashi
>
>                       
>
>                       
>
>                     On 17/01/19 10:28 AM, Shashidhara Veerabhadraiah wrote:
>
>                         We need one way to tell the system not to load any assistive technologies and which is being provided.
>
>                         If we add trailing white spaces removal then we may need to add another functionality to see if that class exists or not and based on that not to load anything(without throwing the error because we are parsing the input content). I think that would take a different direction. I feel it is fair enough to provide one way to tell not to load any assistive technologies and additional parsing would only lead to other ways/expectations.
>
>                           
>
>                         Thanks and regards,
>
>                         Shashi
>
>                           
>
>                         -----Original Message-----
>
>                         From: Sergey Bylokhov
>
>                         Sent: Thursday, January 17, 2019 1:33 AM
>
>                         To: Shashidhara Veerabhadraiah<shashidhara.veerabhadraiah at oracle.com>  <mailto:shashidhara.veerabhadraiah at oracle.com>;awt-dev at openjdk.java.net  <mailto:awt-dev at openjdk.java.net>;swing-dev at openjdk.java.net  <mailto:swing-dev at openjdk.java.net>
>
>                         Subject: Re:<Swing Dev>  [13] JDK-8216008: -Djavax.accessibility.assistive_technologies empty list leads to crash
>
>                           
>
>                         I guess you meant whitespaces, then it is unclear why we should not consider "empty" parameter as a "mistake"?
>
>                           
>
>                         On 15/01/2019 20:37, Shashidhara Veerabhadraiah wrote:
>
>                             Hi Sergey, I felt that a string with an empty space is intentional and should be considering it as a 'mistake' if done by the developers. Hence I feel it is not required(as there is a way to tell nothing to load). Please let me know if you think otherwise.
>
>                           
>
>                           
>
>                             Thanks and regards,
>
>                             Shashi
>
>                               
>
>                             -----Original Message-----
>
>                             From: Sergey Bylokhov
>
>                             Sent: Tuesday, January 15, 2019 7:32 AM
>
>                             To: Shashidhara Veerabhadraiah<shashidhara.veerabhadraiah at oracle.com>  <mailto:shashidhara.veerabhadraiah at oracle.com>;awt-dev at openjdk.java.net  <mailto:awt-dev at openjdk.java.net>;swing-dev at openjdk.java.net  <mailto:swing-dev at openjdk.java.net>
>
>                             Subject: Re:<Swing Dev>  [13] JDK-8216008: -Djavax.accessibility.assistive_technologies empty list leads to crash
>
>                               
>
>                             Hi, Shashi.
>
>                               
>
>                             Should we trim all whitespaces from the "atNames"?
>
>                             Otherwise the "atNames", which contains only one whitespace, will trigger the same error.
>
>                               
>
>                             On 09/01/2019 00:20, Shashidhara Veerabhadraiah wrote:
>
>                                 Hi Sergey, Thanks for pointing that out. Here is the new Webrev:
>
>                                   
>
>                                 http://cr.openjdk.java.net/~sveerabhadra/8216008/webrev.01/  <http://cr.openjdk.java.net/%7Esveerabhadra/8216008/webrev.01/>
>
>                                   
>
>                                 Thanks and regards,
>
>                                 Shashi
>
>                                   
>
>                                 -----Original Message-----
>
>                                 From: Sergey Bylokhov
>
>                                 Sent: Friday, January 4, 2019 3:48 AM
>
>                                 To: Shashidhara Veerabhadraiah<shashidhara.veerabhadraiah at oracle.com>  <mailto:shashidhara.veerabhadraiah at oracle.com>;awt-dev at openjdk.java.net  <mailto:awt-dev at openjdk.java.net>;swing-dev at openjdk.java.net  <mailto:swing-dev at openjdk.java.net>
>
>                                 Subject: Re:<Swing Dev>  [13] JDK-8216008: -Djavax.accessibility.assistive_technologies empty list leads to crash
>
>                                   
>
>                                 Hi, Shashi.
>
>                                 I think you can update an existing test:
>
>                                 open/test/jdk/javax/accessibility/AccessibilityProvider/basic.sh
>
>                                   
>
>                                 On 03/01/2019 01:36, Shashidhara Veerabhadraiah wrote:
>
>                                     Hi All, Please review a fix for the below bug.
>
>                                       
>
>                                     Bug:https://bugs.openjdk.java.net/browse/JDK-8216008
>
>                                       
>
>                                     Webrev:http://cr.openjdk.java.net/~sveerabhadra/8216008/webrev.00/  <http://cr.openjdk.java.net/%7Esveerabhadra/8216008/webrev.00/>
>
>                                       
>
>                                     Since the mentioned list of assistive technologies for the system property(javax.accessibility.assistive_technologies) is loaded by jvm am unable to write a test case for this bug. The test file attached with the bug can be used for testing this fix.
>
>                                       
>
>                                     This fix removes the error(class not found error) by passing an empty list to system variable javax.accessibility.assistive_technologies and does not load any assistive technologies(as the list is empty). Currently empty list produce a crash which is not required as there was no class name mentioned in the list. Please read the bug comments for more information.
>
>                                       
>
>                                     Thanks and regards,
>
>                                       
>
>                                     Shashi
>
>                                       
>
>                                   
>
>                               
>
>                           
>
>                       
>
>                   
>
>                   
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/awt-dev/attachments/20190308/e81ecf47/attachment-0001.html>

From shashidhara.veerabhadraiah at oracle.com  Fri Mar  8 06:56:33 2019
From: shashidhara.veerabhadraiah at oracle.com (Shashidhara Veerabhadraiah)
Date: Thu, 7 Mar 2019 22:56:33 -0800 (PST)
Subject: <AWT Dev> <Swing Dev> [13] JDK-8216008:
 -Djavax.accessibility.assistive_technologies empty list leads to crash
In-Reply-To: <5C82100D.8030106@oracle.com>
References: <86dc6276-6a1c-4d09-8155-705fea8fd95e@default>
 <465ad181-9c9c-4752-a3bc-595e82f08744@default>
 <a218d1b1-f003-f6b7-acfb-e50b9c27a56c@oracle.com>
 <c548de66-3c14-4488-b719-6a0cfde1dc9b@default>
 <9149f70d-5265-efb1-e496-48e159e61e92@oracle.com>
 <554176f6-b538-46b5-97bb-14e488f50656@default>
 <b99d879b-c2ce-358f-be3a-339d5faeff63@oracle.com>
 <daf49f44-1a41-8aa3-3c82-2fbd57ee7634@oracle.com>
 <a48ea2a7-ebdd-410d-b6f9-88288d6ee6d4@default> <5C5DEB0E.5010405@oracle.com>
 <23625b97-76d0-4956-8d4b-bf1add82ceb1@default>
 <1d4ad24a-e6bf-8e71-c88c-020e1106f089@oracle.com>
 <de99f10e-04da-4109-9980-4a8daf6a973c@default>
 <8634f5a6-a0a6-5739-9fd6-9a304a4a97f3@oracle.com>
 <70c695de-a54e-4aad-ae7b-0e11a6b9054e@default>
 <fdffa07a-7513-4a66-bbb9-5774b521b5d5@default>
 <f586ecc6-a795-4564-a825-0b66323a8326@default>
 <a2e461b3-c4e9-4955-8bec-44c8eb45b269@default> <5C7FFF71.1020809@oracle.com>
 <88e0e602-7b4e-443d-95fe-a7fe288fa161@default>
 <fcce40df-1b75-41ea-9381-f8fd5086d4ee@default> <5C82100D.8030106@oracle.com>
Message-ID: <c7154c53-b67c-469f-8ca2-a4f886cbf635@default>

Thank you Phil. Sure will wait till CSR is approved.

?

Thanks and regards,

shashi

?

From: Philip Race 
Sent: Friday, March 8, 2019 12:18 PM
To: Shashidhara Veerabhadraiah <shashidhara.veerabhadraiah at oracle.com>
Cc: awt-dev at openjdk.java.net; Joe Darcy <joe.darcy at oracle.com>; swing-dev at openjdk.java.net
Subject: Re: <AWT Dev> <Swing Dev> [13] JDK-8216008: -Djavax.accessibility.assistive_technologies empty list leads to crash

?

Ok but you need to wait for the CSR to be approved before you can push.

-phil.

On 3/8/19, 11:41 AM, Shashidhara Veerabhadraiah wrote: 

Hi Phil, As discussed here are the updates for the Webrev. Hopefully this is correct.

?

HYPERLINK "http://cr.openjdk.java.net/%7Esveerabhadra/8216008/webrev.09/"http://cr.openjdk.java.net/~sveerabhadra/8216008/webrev.09/

?

Thanks and regards,

Shashi

?

From: Shashidhara Veerabhadraiah 
Sent: Friday, March 8, 2019 10:33 AM
To: Philip Race HYPERLINK "mailto:philip.race at oracle.com"<philip.race at oracle.com>
Cc: HYPERLINK "mailto:awt-dev at openjdk.java.net"awt-dev at openjdk.java.net; Joe Darcy HYPERLINK "mailto:joe.darcy at oracle.com"<joe.darcy at oracle.com>; HYPERLINK "mailto:swing-dev at openjdk.java.net"swing-dev at openjdk.java.net
Subject: Re: <AWT Dev> <Swing Dev> [13] JDK-8216008: -Djavax.accessibility.assistive_technologies empty list leads to crash

?

Thank you Phil for the review and here are the updates done:

?

HYPERLINK "http://cr.openjdk.java.net/%7Esveerabhadra/8216008/webrev.08/"http://cr.openjdk.java.net/~sveerabhadra/8216008//webrev.08/

?

Thanks and regards,

Shashi

?

From: Philip Race 
Sent: Wednesday, March 6, 2019 10:42 PM
To: Shashidhara Veerabhadraiah <HYPERLINK "mailto:shashidhara.veerabhadraiah at oracle.com"shashidhara.veerabhadraiah at oracle.com>
Cc: HYPERLINK "mailto:awt-dev at openjdk.java.net"awt-dev at openjdk.java.net; HYPERLINK "mailto:swing-dev at openjdk.java.net"swing-dev at openjdk.java.net; Joe Darcy <HYPERLINK "mailto:joe.darcy at oracle.com"joe.darcy at oracle.com>
Subject: Re: <AWT Dev> <Swing Dev> [13] JDK-8216008: -Djavax.accessibility.assistive_technologies empty list leads to crash

?

the webrev needs a couple of minor tweaks :
?
contains empty string -> is the empty string
?
and
?
immeadiately -> immediately


Go ahead and finalize the CSR which looks OK.

-phil.

On 3/6/19, 11:45 AM, Shashidhara Veerabhadraiah wrote: 

Hi Phil\Sergey, Please review the CSR along with the bug fix.

?

Webrev: HYPERLINK "http://cr.openjdk.java.net/%7Esveerabhadra/8216008/webrev.07/"http://cr.openjdk.java.net/~sveerabhadra/8216008/webrev.07/

?

CSR: https://bugs.openjdk.java.net/browse/JDK-8218737

?

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

?

Thanks and regards,

Shashi

?

From: Shashidhara Veerabhadraiah 
Sent: Monday, March 4, 2019 3:36 PM
To: Philip Race HYPERLINK "mailto:philip.race at oracle.com"<philip.race at oracle.com>; Joe Darcy HYPERLINK "mailto:joe.darcy at oracle.com"<joe.darcy at oracle.com>
Cc: HYPERLINK "mailto:awt-dev at openjdk.java.net"awt-dev at openjdk.java.net; HYPERLINK "mailto:swing-dev at openjdk.java.net"swing-dev at openjdk.java.net
Subject: Re: <AWT Dev> <Swing Dev> [13] JDK-8216008: -Djavax.accessibility.assistive_technologies empty list leads to crash

?

Hi Joe, Please find the updated Webrev fixing the typo:

?

HYPERLINK "http://cr.openjdk.java.net/%7Esveerabhadra/8216008/webrev.07/"http://cr.openjdk.java.net/~sveerabhadra/8216008/webrev.07/

?

Thanks and regards,

Shashi

?

From: Shashidhara Veerabhadraiah 
Sent: Thursday, February 21, 2019 2:08 PM
To: Philip Race <HYPERLINK "mailto:philip.race at oracle.com"philip.race at oracle.com>; Joe Darcy <HYPERLINK "mailto:joe.darcy at oracle.com"joe.darcy at oracle.com>
Cc: HYPERLINK "mailto:awt-dev at openjdk.java.net"awt-dev at openjdk.java.net; HYPERLINK "mailto:swing-dev at openjdk.java.net"swing-dev at openjdk.java.net
Subject: Re: <AWT Dev> <Swing Dev> [13] JDK-8216008: -Djavax.accessibility.assistive_technologies empty list leads to crash

?

Hi Joe, Please find the new Webrev fixing the specification as asked in the CSR bug: https://bugs.openjdk.java.net/browse/JDK-8218737

?

Webrev: HYPERLINK "http://cr.openjdk.java.net/%7Esveerabhadra/8216008/webrev.06/"http://cr.openjdk.java.net/~sveerabhadra/8216008/webrev.06/

?

Thanks and regards,

Shashi

?

From: Shashidhara Veerabhadraiah 
Sent: Monday, February 18, 2019 10:19 AM
To: Philip Race <HYPERLINK "mailto:philip.race at oracle.com"philip.race at oracle.com>
Cc: HYPERLINK "mailto:awt-dev at openjdk.java.net"awt-dev at openjdk.java.net; HYPERLINK "mailto:swing-dev at openjdk.java.net"swing-dev at openjdk.java.net
Subject: Re: <AWT Dev> <Swing Dev> [13] JDK-8216008: -Djavax.accessibility.assistive_technologies empty list leads to crash

?

Thank you Phil for that help on CSR.

?

From: Phil Race 
Sent: Friday, February 15, 2019 9:41 PM
To: Shashidhara Veerabhadraiah <HYPERLINK "mailto:shashidhara.veerabhadraiah at oracle.com"shashidhara.veerabhadraiah at oracle.com>
Cc: Sergey Bylokhov <HYPERLINK "mailto:sergey.bylokhov at oracle.com"sergey.bylokhov at oracle.com>; HYPERLINK "mailto:awt-dev at openjdk.java.net"awt-dev at openjdk.java.net; HYPERLINK "mailto:swing-dev at openjdk.java.net"swing-dev at openjdk.java.net
Subject: Re: <Swing Dev> [13] JDK-8216008: -Djavax.accessibility.assistive_technologies empty list leads to crash

?

That text may actually be worse.
Although I maybe didn't get your distinction of null vs the empty string here ?

Oh, wait. Why is this doc clarification on the PRIVATE implementation method ?
It needs to go on the public getDefaultToolkit() method to have any point whatsoever
especially from a CSR perspective.
Try this :
-???? * toolkit is created. All errors are handled via an AWTError exception.
+???? * toolkit is created.
+???? * If the list of assistive technology providers is the empty string, or
+???? * contains only white space characters then the method returns immediately.
+???? * All other errors are handled via an AWTError exception.


I think the CSR needs some work too. I've made some updates there.

-phil.

On 2/15/19 2:10 AM, Shashidhara Veerabhadraiah wrote:

Hi Phil, I have updated the CSR and updated the information for the function and here is the new Webrev:

?

HYPERLINK "http://cr.openjdk.java.net/%7Esveerabhadra/8216008/webrev.05/"http://cr.openjdk.java.net/~sveerabhadra/8216008/webrev.05/

Thanks and regards,

Shashi

?

From: Phil Race 
Sent: Friday, February 15, 2019 2:58 AM
To: Shashidhara Veerabhadraiah HYPERLINK "mailto:shashidhara.veerabhadraiah at oracle.com"<shashidhara.veerabhadraiah at oracle.com>
Cc: Sergey Bylokhov HYPERLINK "mailto:sergey.bylokhov at oracle.com"<sergey.bylokhov at oracle.com>; HYPERLINK "mailto:awt-dev at openjdk.java.net"awt-dev at openjdk.java.net; HYPERLINK "mailto:swing-dev at openjdk.java.net"swing-dev at openjdk.java.net
Subject: Re: <Swing Dev> [13] JDK-8216008: -Djavax.accessibility.assistive_technologies empty list leads to crash

?

+???? * activate method.? If the list of assistive technology providers is empty string,
?
is "the" empty string.
?
?
The CSR needs to be updated to include this spec. 
What is there now in the specification section needs to be fixed
It should not point to the webrev or review and right now
doesn't contain the change to the javadoc in the body of the CSR
?
I think I even have to question most of the rest of it.
Any one reading it would think that we always used to throw an exception in such
case and now want to stop doing so. Isn't the bug that we did NOT throw an exception
and now we do ? You only hint at that when you say at the end of "Solution", "as was the case earlier"
?
If I am right the only thing you need in the CSR is to say that you
are reverting the implementation to previous behaviour and updating the
specification to make it clear that this behaviour is allowed by the spec
since this case was unclear.
?
-phil.

?

On 2/12/19 1:08 AM, Shashidhara Veerabhadraiah wrote:

Hi Phil, Here is the new Webrev and CSR for the same:

HYPERLINK "http://cr.openjdk.java.net/%7Esveerabhadra/8216008/webrev.04/"http://cr.openjdk.java.net/~sveerabhadra/8216008/webrev.04/

?

CSR: https://bugs.openjdk.java.net/browse/JDK-8218737

?

Thanks and regards,

Shashi

?

From: Philip Race 
Sent: Saturday, February 9, 2019 2:18 AM
To: Shashidhara Veerabhadraiah HYPERLINK "mailto:shashidhara.veerabhadraiah at oracle.com"<shashidhara.veerabhadraiah at oracle.com>
Cc: Sergey Bylokhov HYPERLINK "mailto:sergey.bylokhov at oracle.com"<sergey.bylokhov at oracle.com>; HYPERLINK "mailto:awt-dev at openjdk.java.net"awt-dev at openjdk.java.net; HYPERLINK "mailto:swing-dev at openjdk.java.net"swing-dev at openjdk.java.net
Subject: Re: <Swing Dev> [13] JDK-8216008: -Djavax.accessibility.assistive_technologies empty list leads to crash

?

FWIW I think this could be closed out as "not a bug".
An empty value string is an error and the spec. says AWTError is
how errors are reported. In fact I'll argue that 8 was wrong not
to have thrown an exception in such a case.
It was an accident of the implementation that it did not.
But if we want to be behaviourally compatible then ... 
Note that since you now document this you need an approved CSR BEFORE pushing it.

And if you go the CSR route you may need to be more precise about what
you mean by "empty".

I think it needs to say

"If the list of assistive technology providers is null, or contains only white
space characters then the method returns immediately.
All other errors are handled by throwing {@code AWTError}"

@throws AWTError if there is any error in parsing or loading the ATs.

-phil.

On 1/21/19, 9:12 AM, Shashidhara Veerabhadraiah wrote: 

Hi Sergey, Here is the new Webrev for your comments:
?
HYPERLINK "http://cr.openjdk.java.net/%7Esveerabhadra/8216008/webrev.02/"http://cr.openjdk.java.net/~sveerabhadra/8216008/webrev.02/
?
Thanks and regards,
Shashi
?
-----Original Message-----
From: Sergey Bylokhov 
Sent: Saturday, January 19, 2019 3:47 AM
To: Shashidhara Veerabhadraiah HYPERLINK "mailto:shashidhara.veerabhadraiah at oracle.com"<shashidhara.veerabhadraiah at oracle.com>; HYPERLINK "mailto:awt-dev at openjdk.java.net"awt-dev at openjdk.java.net; HYPERLINK "mailto:swing-dev at openjdk.java.net"swing-dev at openjdk.java.net
Subject: Re: <Swing Dev> [13] JDK-8216008: -Djavax.accessibility.assistive_technologies empty list leads to crash
?
On 16/01/2019 23:03, HYPERLINK "mailto:shashidhara.veerabhadraiah at oracle.com"shashidhara.veerabhadraiah at oracle.com wrote:

Another point is that the whitespace trimming should not trigger additional input processing? for the custom class that will be used for assistive technology. For eg., if custom class "FooProvider" is implemented and if we pass "? FooProvider? " by mistake, a bug may be created to trim the whitespace in this case as well!!

?
Yes, my previous email suggested to always trim the content of the "input", it will cover all cases, the "atNames" is empty, the "atNames" contains only the whitespace, or the name of the class has some spaces at the start/end.
?

?
Thanks and regards,
?
Shashi
?
?
On 17/01/19 10:28 AM, Shashidhara Veerabhadraiah wrote:

We need one way to tell the system not to load any assistive technologies and which is being provided.
If we add trailing white spaces removal then we may need to add another functionality to see if that class exists or not and based on that not to load anything(without throwing the error because we are parsing the input content). I think that would take a different direction. I feel it is fair enough to provide one way to tell not to load any assistive technologies and additional parsing would only lead to other ways/expectations.
?
Thanks and regards,
Shashi
?
-----Original Message-----
From: Sergey Bylokhov
Sent: Thursday, January 17, 2019 1:33 AM
To: Shashidhara Veerabhadraiah HYPERLINK "mailto:shashidhara.veerabhadraiah at oracle.com"<shashidhara.veerabhadraiah at oracle.com>; HYPERLINK "mailto:awt-dev at openjdk.java.net"awt-dev at openjdk.java.net; HYPERLINK "mailto:swing-dev at openjdk.java.net"swing-dev at openjdk.java.net
Subject: Re: <Swing Dev> [13] JDK-8216008: -Djavax.accessibility.assistive_technologies empty list leads to crash
?
I guess you meant whitespaces, then it is unclear why we should not consider "empty" parameter as a "mistake"?
?
On 15/01/2019 20:37, Shashidhara Veerabhadraiah wrote:

Hi Sergey, I felt that a string with an empty space is intentional and should be considering it as a 'mistake' if done by the developers. Hence I feel it is not required(as there is a way to tell nothing to load). Please let me know if you think otherwise.

?
?

Thanks and regards,
Shashi
?
-----Original Message-----
From: Sergey Bylokhov
Sent: Tuesday, January 15, 2019 7:32 AM
To: Shashidhara Veerabhadraiah HYPERLINK "mailto:shashidhara.veerabhadraiah at oracle.com"<shashidhara.veerabhadraiah at oracle.com>; HYPERLINK "mailto:awt-dev at openjdk.java.net"awt-dev at openjdk.java.net; HYPERLINK "mailto:swing-dev at openjdk.java.net"swing-dev at openjdk.java.net
Subject: Re: <Swing Dev> [13] JDK-8216008: -Djavax.accessibility.assistive_technologies empty list leads to crash
?
Hi, Shashi.
?
Should we trim all whitespaces from the "atNames"?
Otherwise the "atNames", which contains only one whitespace, will trigger the same error.
?
On 09/01/2019 00:20, Shashidhara Veerabhadraiah wrote:

Hi Sergey, Thanks for pointing that out. Here is the new Webrev:
?
HYPERLINK "http://cr.openjdk.java.net/%7Esveerabhadra/8216008/webrev.01/"http://cr.openjdk.java.net/~sveerabhadra/8216008/webrev.01/
?
Thanks and regards,
Shashi
?
-----Original Message-----
From: Sergey Bylokhov
Sent: Friday, January 4, 2019 3:48 AM
To: Shashidhara Veerabhadraiah HYPERLINK "mailto:shashidhara.veerabhadraiah at oracle.com"<shashidhara.veerabhadraiah at oracle.com>; HYPERLINK "mailto:awt-dev at openjdk.java.net"awt-dev at openjdk.java.net; HYPERLINK "mailto:swing-dev at openjdk.java.net"swing-dev at openjdk.java.net
Subject: Re: <Swing Dev> [13] JDK-8216008: -Djavax.accessibility.assistive_technologies empty list leads to crash
?
Hi, Shashi.
I think you can update an existing test:
open/test/jdk/javax/accessibility/AccessibilityProvider/basic.sh
?
On 03/01/2019 01:36, Shashidhara Veerabhadraiah wrote:

Hi All, Please review a fix for the below bug.
?
Bug: https://bugs.openjdk.java.net/browse/JDK-8216008
?
Webrev: HYPERLINK "http://cr.openjdk.java.net/%7Esveerabhadra/8216008/webrev.00/"http://cr.openjdk.java.net/~sveerabhadra/8216008/webrev.00/
?
Since the mentioned list of assistive technologies for the system property(javax.accessibility.assistive_technologies) is loaded by jvm am unable to write a test case for this bug. The test file attached with the bug can be used for testing this fix.
?
This fix removes the error(class not found error) by passing an empty list to system variable javax.accessibility.assistive_technologies and does not load any assistive technologies(as the list is empty). Currently empty list produce a crash which is not required as there was no class name mentioned in the list. Please read the bug comments for more information.
?
Thanks and regards,
?
Shashi
?

?

?

?

?

?
?

?

?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/awt-dev/attachments/20190307/9cf22644/attachment-0001.html>

From joe.darcy at oracle.com  Fri Mar  8 09:12:26 2019
From: joe.darcy at oracle.com (Joe Darcy)
Date: Fri, 8 Mar 2019 01:12:26 -0800
Subject: <AWT Dev> <Swing Dev> [13] JDK-8216008:
 -Djavax.accessibility.assistive_technologies empty list leads to crash
In-Reply-To: <c7154c53-b67c-469f-8ca2-a4f886cbf635@default>
References: <86dc6276-6a1c-4d09-8155-705fea8fd95e@default>
 <c548de66-3c14-4488-b719-6a0cfde1dc9b@default>
 <9149f70d-5265-efb1-e496-48e159e61e92@oracle.com>
 <554176f6-b538-46b5-97bb-14e488f50656@default>
 <b99d879b-c2ce-358f-be3a-339d5faeff63@oracle.com>
 <daf49f44-1a41-8aa3-3c82-2fbd57ee7634@oracle.com>
 <a48ea2a7-ebdd-410d-b6f9-88288d6ee6d4@default> <5C5DEB0E.5010405@oracle.com>
 <23625b97-76d0-4956-8d4b-bf1add82ceb1@default>
 <1d4ad24a-e6bf-8e71-c88c-020e1106f089@oracle.com>
 <de99f10e-04da-4109-9980-4a8daf6a973c@default>
 <8634f5a6-a0a6-5739-9fd6-9a304a4a97f3@oracle.com>
 <70c695de-a54e-4aad-ae7b-0e11a6b9054e@default>
 <fdffa07a-7513-4a66-bbb9-5774b521b5d5@default>
 <f586ecc6-a795-4564-a825-0b66323a8326@default>
 <a2e461b3-c4e9-4955-8bec-44c8eb45b269@default> <5C7FFF71.1020809@oracle.com>
 <88e0e602-7b4e-443d-95fe-a7fe288fa161@default>
 <fcce40df-1b75-41ea-9381-f8fd5086d4ee@default> <5C82100D.8030106@oracle.com>
 <c7154c53-b67c-469f-8ca2-a4f886cbf635@default>
Message-ID: <606ce427-71da-8bdb-7726-5334ab3d3399@oracle.com>

Hello,

I strongly recommend using

 ??? String.strip

rather than

 ??? String.trim

as Strim.trim uses a idosyncratic definition of whitespace whereas the 
new-in-11 String.strip uses a conventional definition of white space. 
Likewise, I recommend linking "white space" to the definition of white 
space used by Character.isWhitespace.

Thanks,

-Joe

On 3/7/2019 10:56 PM, Shashidhara Veerabhadraiah wrote:
>
> Thank you Phil. Sure will wait till CSR is approved.
>
> Thanks and regards,
>
> shashi
>
> *From:*Philip Race
> *Sent:* Friday, March 8, 2019 12:18 PM
> *To:* Shashidhara Veerabhadraiah <shashidhara.veerabhadraiah at oracle.com>
> *Cc:* awt-dev at openjdk.java.net; Joe Darcy <joe.darcy at oracle.com>; 
> swing-dev at openjdk.java.net
> *Subject:* Re: <AWT Dev> <Swing Dev> [13] JDK-8216008: 
> -Djavax.accessibility.assistive_technologies empty list leads to crash
>
> Ok but you need to wait for the CSR to be approved before you can push.
>
> -phil.
>
> On 3/8/19, 11:41 AM, Shashidhara Veerabhadraiah wrote:
>
>     Hi Phil, As discussed here are the updates for the Webrev.
>     Hopefully this is correct.
>
>     http://cr.openjdk.java.net/~sveerabhadra/8216008/webrev.09/
>     <http://cr.openjdk.java.net/%7Esveerabhadra/8216008/webrev.09/>
>
>     Thanks and regards,
>
>     Shashi
>
>     *From:*Shashidhara Veerabhadraiah
>     *Sent:* Friday, March 8, 2019 10:33 AM
>     *To:* Philip Race <philip.race at oracle.com>
>     <mailto:philip.race at oracle.com>
>     *Cc:* awt-dev at openjdk.java.net <mailto:awt-dev at openjdk.java.net>;
>     Joe Darcy <joe.darcy at oracle.com> <mailto:joe.darcy at oracle.com>;
>     swing-dev at openjdk.java.net <mailto:swing-dev at openjdk.java.net>
>     *Subject:* Re: <AWT Dev> <Swing Dev> [13] JDK-8216008:
>     -Djavax.accessibility.assistive_technologies empty list leads to crash
>
>     Thank you Phil for the review and here are the updates done:
>
>     http://cr.openjdk.java.net/~sveerabhadra/8216008//webrev.08/
>     <http://cr.openjdk.java.net/%7Esveerabhadra/8216008/webrev.08/>
>
>     Thanks and regards,
>
>     Shashi
>
>     *From:*Philip Race
>     *Sent:* Wednesday, March 6, 2019 10:42 PM
>     *To:* Shashidhara Veerabhadraiah
>     <shashidhara.veerabhadraiah at oracle.com
>     <mailto:shashidhara.veerabhadraiah at oracle.com>>
>     *Cc:* awt-dev at openjdk.java.net <mailto:awt-dev at openjdk.java.net>;
>     swing-dev at openjdk.java.net <mailto:swing-dev at openjdk.java.net>;
>     Joe Darcy <joe.darcy at oracle.com <mailto:joe.darcy at oracle.com>>
>     *Subject:* Re: <AWT Dev> <Swing Dev> [13] JDK-8216008:
>     -Djavax.accessibility.assistive_technologies empty list leads to crash
>
>     the webrev needs a couple of minor tweaks :
>
>     contains empty string  -> is the empty string
>
>       
>
>     and
>
>       
>
>     immeadiately -> immediately
>
>
>     Go ahead and finalize the CSR which looks OK.
>
>     -phil.
>
>     On 3/6/19, 11:45 AM, Shashidhara Veerabhadraiah wrote:
>
>         Hi Phil\Sergey, Please review the CSR along with the bug fix.
>
>         Webrev:
>         http://cr.openjdk.java.net/~sveerabhadra/8216008/webrev.07/
>         <http://cr.openjdk.java.net/%7Esveerabhadra/8216008/webrev.07/>
>
>         CSR: https://bugs.openjdk.java.net/browse/JDK-8218737
>
>         Bug: https://bugs.openjdk.java.net/browse/JDK-8216008
>
>         Thanks and regards,
>
>         Shashi
>
>         *From:*Shashidhara Veerabhadraiah
>         *Sent:* Monday, March 4, 2019 3:36 PM
>         *To:* Philip Race <philip.race at oracle.com>
>         <mailto:philip.race at oracle.com>; Joe Darcy
>         <joe.darcy at oracle.com> <mailto:joe.darcy at oracle.com>
>         *Cc:* awt-dev at openjdk.java.net
>         <mailto:awt-dev at openjdk.java.net>; swing-dev at openjdk.java.net
>         <mailto:swing-dev at openjdk.java.net>
>         *Subject:* Re: <AWT Dev> <Swing Dev> [13] JDK-8216008:
>         -Djavax.accessibility.assistive_technologies empty list leads
>         to crash
>
>         Hi Joe, Please find the updated Webrev fixing the typo:
>
>         http://cr.openjdk.java.net/~sveerabhadra/8216008/webrev.07/
>         <http://cr.openjdk.java.net/%7Esveerabhadra/8216008/webrev.07/>
>
>         Thanks and regards,
>
>         Shashi
>
>         *From:*Shashidhara Veerabhadraiah
>         *Sent:* Thursday, February 21, 2019 2:08 PM
>         *To:* Philip Race <philip.race at oracle.com
>         <mailto:philip.race at oracle.com>>; Joe Darcy
>         <joe.darcy at oracle.com <mailto:joe.darcy at oracle.com>>
>         *Cc:* awt-dev at openjdk.java.net
>         <mailto:awt-dev at openjdk.java.net>; swing-dev at openjdk.java.net
>         <mailto:swing-dev at openjdk.java.net>
>         *Subject:* Re: <AWT Dev> <Swing Dev> [13] JDK-8216008:
>         -Djavax.accessibility.assistive_technologies empty list leads
>         to crash
>
>         Hi Joe, Please find the new Webrev fixing the specification as
>         asked in the CSR bug:
>         https://bugs.openjdk.java.net/browse/JDK-8218737
>
>         Webrev:
>         http://cr.openjdk.java.net/~sveerabhadra/8216008/webrev.06/
>         <http://cr.openjdk.java.net/%7Esveerabhadra/8216008/webrev.06/>
>
>         Thanks and regards,
>
>         Shashi
>
>         *From:*Shashidhara Veerabhadraiah
>         *Sent:* Monday, February 18, 2019 10:19 AM
>         *To:* Philip Race <philip.race at oracle.com
>         <mailto:philip.race at oracle.com>>
>         *Cc:* awt-dev at openjdk.java.net
>         <mailto:awt-dev at openjdk.java.net>; swing-dev at openjdk.java.net
>         <mailto:swing-dev at openjdk.java.net>
>         *Subject:* Re: <AWT Dev> <Swing Dev> [13] JDK-8216008:
>         -Djavax.accessibility.assistive_technologies empty list leads
>         to crash
>
>         Thank you Phil for that help on CSR.
>
>         *From:*Phil Race
>         *Sent:* Friday, February 15, 2019 9:41 PM
>         *To:* Shashidhara Veerabhadraiah
>         <shashidhara.veerabhadraiah at oracle.com
>         <mailto:shashidhara.veerabhadraiah at oracle.com>>
>         *Cc:* Sergey Bylokhov <sergey.bylokhov at oracle.com
>         <mailto:sergey.bylokhov at oracle.com>>; awt-dev at openjdk.java.net
>         <mailto:awt-dev at openjdk.java.net>; swing-dev at openjdk.java.net
>         <mailto:swing-dev at openjdk.java.net>
>         *Subject:* Re: <Swing Dev> [13] JDK-8216008:
>         -Djavax.accessibility.assistive_technologies empty list leads
>         to crash
>
>         That text may actually be worse.
>         Although I maybe didn't get your distinction of null vs the
>         empty string here ?
>
>         Oh, wait. Why is this doc clarification on the PRIVATE
>         implementation method ?
>         It needs to go on the public getDefaultToolkit() method to
>         have any point whatsoever
>         especially from a CSR perspective.
>         Try this :
>         -???? * toolkit is created. All errors are handled via an
>         AWTError exception.
>         +???? * toolkit is created.
>         +???? * If the list of assistive technology providers is the
>         empty string, or
>         +???? * contains only white space characters then the method
>         returns immediately.
>         +???? * All other errors are handled via an AWTError exception.
>
>
>         I think the CSR needs some work too. I've made some updates there.
>
>         -phil.
>
>         On 2/15/19 2:10 AM, Shashidhara Veerabhadraiah wrote:
>
>             Hi Phil, I have updated the CSR and updated the
>             information for the function and here is the new Webrev:
>
>             http://cr.openjdk.java.net/~sveerabhadra/8216008/webrev.05/
>             <http://cr.openjdk.java.net/%7Esveerabhadra/8216008/webrev.05/>
>
>             Thanks and regards,
>
>             Shashi
>
>             *From:*Phil Race
>             *Sent:* Friday, February 15, 2019 2:58 AM
>             *To:* Shashidhara Veerabhadraiah
>             <shashidhara.veerabhadraiah at oracle.com>
>             <mailto:shashidhara.veerabhadraiah at oracle.com>
>             *Cc:* Sergey Bylokhov <sergey.bylokhov at oracle.com>
>             <mailto:sergey.bylokhov at oracle.com>;
>             awt-dev at openjdk.java.net
>             <mailto:awt-dev at openjdk.java.net>;
>             swing-dev at openjdk.java.net <mailto:swing-dev at openjdk.java.net>
>             *Subject:* Re: <Swing Dev> [13] JDK-8216008:
>             -Djavax.accessibility.assistive_technologies empty list
>             leads to crash
>
>             +???? * activate method.? If the list of assistive
>             technology providers is empty string,
>
>             is "the" empty string.
>
>             The CSR needs to be updated to include this spec.
>
>             What is there now in the specification section needs to be
>             fixed
>
>             It should not point to the webrev or review and right now
>
>             doesn't contain the change to the javadoc in the body of
>             the CSR
>
>             I think I even have to question most of the rest of it.
>
>             Any one reading it would think that we always used to
>             throw an exception in such
>
>             case and now want to stop doing so. Isn't the bug that we
>             did NOT throw an exception
>
>             and now we do ? You only hint at that when you say at the
>             end of "Solution", "as was the case earlier"
>
>             If I am right the only thing you need in the CSR is to say
>             that you
>
>             are reverting the implementation to previous behaviour and
>             updating the
>
>             specification to make it clear that this behaviour is
>             allowed by the spec
>
>             since this case was unclear.
>
>             -phil.
>
>             On 2/12/19 1:08 AM, Shashidhara Veerabhadraiah wrote:
>
>                 Hi Phil, Here is the new Webrev and CSR for the same:
>
>                 http://cr.openjdk.java.net/~sveerabhadra/8216008/webrev.04/
>                 <http://cr.openjdk.java.net/%7Esveerabhadra/8216008/webrev.04/>
>
>                 CSR: https://bugs.openjdk.java.net/browse/JDK-8218737
>
>                 Thanks and regards,
>
>                 Shashi
>
>                 *From:*Philip Race
>                 *Sent:* Saturday, February 9, 2019 2:18 AM
>                 *To:* Shashidhara Veerabhadraiah
>                 <shashidhara.veerabhadraiah at oracle.com>
>                 <mailto:shashidhara.veerabhadraiah at oracle.com>
>                 *Cc:* Sergey Bylokhov <sergey.bylokhov at oracle.com>
>                 <mailto:sergey.bylokhov at oracle.com>;
>                 awt-dev at openjdk.java.net
>                 <mailto:awt-dev at openjdk.java.net>;
>                 swing-dev at openjdk.java.net
>                 <mailto:swing-dev at openjdk.java.net>
>                 *Subject:* Re: <Swing Dev> [13] JDK-8216008:
>                 -Djavax.accessibility.assistive_technologies empty
>                 list leads to crash
>
>                 FWIW I think this could be closed out as "not a bug".
>                 An empty value string is an error and the spec. says
>                 AWTError is
>                 how errors are reported. In fact I'll argue that 8 was
>                 wrong not
>                 to have thrown an exception in such a case.
>                 It was an accident of the implementation that it did not.
>                 But if we want to be behaviourally compatible then ...
>                 Note that since you now document this you need an
>                 approved CSR BEFORE pushing it.
>
>                 And if you go the CSR route you may need to be more
>                 precise about what
>                 you mean by "empty".
>
>                 I think it needs to say
>
>                 "If the list of assistive technology providers is
>                 null, or contains only white
>                 space characters then the method returns immediately.
>                 All other errors are handled by throwing {@code AWTError}"
>
>                 @throws AWTError if there is any error in parsing or
>                 loading the ATs.
>
>                 -phil.
>
>                 On 1/21/19, 9:12 AM, Shashidhara Veerabhadraiah wrote:
>
>                     Hi Sergey, Here is the new Webrev for your comments:
>
>                       
>
>                     http://cr.openjdk.java.net/~sveerabhadra/8216008/webrev.02/  <http://cr.openjdk.java.net/%7Esveerabhadra/8216008/webrev.02/>
>
>                       
>
>                     Thanks and regards,
>
>                     Shashi
>
>                       
>
>                     -----Original Message-----
>
>                     From: Sergey Bylokhov
>
>                     Sent: Saturday, January 19, 2019 3:47 AM
>
>                     To: Shashidhara Veerabhadraiah<shashidhara.veerabhadraiah at oracle.com>  <mailto:shashidhara.veerabhadraiah at oracle.com>;awt-dev at openjdk.java.net  <mailto:awt-dev at openjdk.java.net>;swing-dev at openjdk.java.net  <mailto:swing-dev at openjdk.java.net>
>
>                     Subject: Re: <Swing Dev> [13] JDK-8216008: -Djavax.accessibility.assistive_technologies empty list leads to crash
>
>                       
>
>                     On 16/01/2019 23:03,shashidhara.veerabhadraiah at oracle.com  <mailto:shashidhara.veerabhadraiah at oracle.com>  wrote:
>
>                         Another point is that the whitespace trimming should not trigger additional input processing? for the custom class that will be used for assistive technology. For eg., if custom class "FooProvider" is implemented and if we pass "? FooProvider? " by mistake, a bug may be created to trim the whitespace in this case as well!!
>
>                       
>
>                     Yes, my previous email suggested to always trim the content of the "input", it will cover all cases, the "atNames" is empty, the "atNames" contains only the whitespace, or the name of the class has some spaces at the start/end.
>
>                       
>
>                           
>
>                         Thanks and regards,
>
>                           
>
>                         Shashi
>
>                           
>
>                           
>
>                         On 17/01/19 10:28 AM, Shashidhara Veerabhadraiah wrote:
>
>                             We need one way to tell the system not to load any assistive technologies and which is being provided.
>
>                             If we add trailing white spaces removal then we may need to add another functionality to see if that class exists or not and based on that not to load anything(without throwing the error because we are parsing the input content). I think that would take a different direction. I feel it is fair enough to provide one way to tell not to load any assistive technologies and additional parsing would only lead to other ways/expectations.
>
>                               
>
>                             Thanks and regards,
>
>                             Shashi
>
>                               
>
>                             -----Original Message-----
>
>                             From: Sergey Bylokhov
>
>                             Sent: Thursday, January 17, 2019 1:33 AM
>
>                             To: Shashidhara Veerabhadraiah<shashidhara.veerabhadraiah at oracle.com>  <mailto:shashidhara.veerabhadraiah at oracle.com>;awt-dev at openjdk.java.net  <mailto:awt-dev at openjdk.java.net>;swing-dev at openjdk.java.net  <mailto:swing-dev at openjdk.java.net>
>
>                             Subject: Re: <Swing Dev> [13] JDK-8216008: -Djavax.accessibility.assistive_technologies empty list leads to crash
>
>                               
>
>                             I guess you meant whitespaces, then it is unclear why we should not consider "empty" parameter as a "mistake"?
>
>                               
>
>                             On 15/01/2019 20:37, Shashidhara Veerabhadraiah wrote:
>
>                                 Hi Sergey, I felt that a string with an empty space is intentional and should be considering it as a 'mistake' if done by the developers. Hence I feel it is not required(as there is a way to tell nothing to load). Please let me know if you think otherwise.
>
>                               
>
>                               
>
>                                 Thanks and regards,
>
>                                 Shashi
>
>                                   
>
>                                 -----Original Message-----
>
>                                 From: Sergey Bylokhov
>
>                                 Sent: Tuesday, January 15, 2019 7:32 AM
>
>                                 To: Shashidhara Veerabhadraiah<shashidhara.veerabhadraiah at oracle.com>  <mailto:shashidhara.veerabhadraiah at oracle.com>;awt-dev at openjdk.java.net  <mailto:awt-dev at openjdk.java.net>;swing-dev at openjdk.java.net  <mailto:swing-dev at openjdk.java.net>
>
>                                 Subject: Re: <Swing Dev> [13] JDK-8216008: -Djavax.accessibility.assistive_technologies empty list leads to crash
>
>                                   
>
>                                 Hi, Shashi.
>
>                                   
>
>                                 Should we trim all whitespaces from the "atNames"?
>
>                                 Otherwise the "atNames", which contains only one whitespace, will trigger the same error.
>
>                                   
>
>                                 On 09/01/2019 00:20, Shashidhara Veerabhadraiah wrote:
>
>                                     Hi Sergey, Thanks for pointing that out. Here is the new Webrev:
>
>                                       
>
>                                     http://cr.openjdk.java.net/~sveerabhadra/8216008/webrev.01/  <http://cr.openjdk.java.net/%7Esveerabhadra/8216008/webrev.01/>
>
>                                       
>
>                                     Thanks and regards,
>
>                                     Shashi
>
>                                       
>
>                                     -----Original Message-----
>
>                                     From: Sergey Bylokhov
>
>                                     Sent: Friday, January 4, 2019 3:48 AM
>
>                                     To: Shashidhara Veerabhadraiah<shashidhara.veerabhadraiah at oracle.com>  <mailto:shashidhara.veerabhadraiah at oracle.com>;awt-dev at openjdk.java.net  <mailto:awt-dev at openjdk.java.net>;swing-dev at openjdk.java.net  <mailto:swing-dev at openjdk.java.net>
>
>                                     Subject: Re: <Swing Dev> [13] JDK-8216008: -Djavax.accessibility.assistive_technologies empty list leads to crash
>
>                                       
>
>                                     Hi, Shashi.
>
>                                     I think you can update an existing test:
>
>                                     open/test/jdk/javax/accessibility/AccessibilityProvider/basic.sh
>
>                                       
>
>                                     On 03/01/2019 01:36, Shashidhara Veerabhadraiah wrote:
>
>                                         Hi All, Please review a fix for the below bug.
>
>                                           
>
>                                         Bug:https://bugs.openjdk.java.net/browse/JDK-8216008
>
>                                           
>
>                                         Webrev:http://cr.openjdk.java.net/~sveerabhadra/8216008/webrev.00/  <http://cr.openjdk.java.net/%7Esveerabhadra/8216008/webrev.00/>
>
>                                           
>
>                                         Since the mentioned list of assistive technologies for the system property(javax.accessibility.assistive_technologies) is loaded by jvm am unable to write a test case for this bug. The test file attached with the bug can be used for testing this fix.
>
>                                           
>
>                                         This fix removes the error(class not found error) by passing an empty list to system variable javax.accessibility.assistive_technologies and does not load any assistive technologies(as the list is empty). Currently empty list produce a crash which is not required as there was no class name mentioned in the list. Please read the bug comments for more information.
>
>                                           
>
>                                         Thanks and regards,
>
>                                           
>
>                                         Shashi
>
>                                           
>
>                                       
>
>                                   
>
>                               
>
>                           
>
>                       
>
>                       
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/awt-dev/attachments/20190308/b8e66cff/attachment-0001.html>

From Sergey.Bylokhov at oracle.com  Sat Mar  9 00:48:27 2019
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Fri, 8 Mar 2019 16:48:27 -0800
Subject: <AWT Dev> [13] Review Request: 8220320 Remove unused old code in
 GraphicsEnvironment on unix
Message-ID: <42097c78-3e3d-1b97-b02f-ac1d79dc6127@oracle.com>

Hello.
Please review small fix for JDK 13.

Bug: https://bugs.openjdk.java.net/browse/JDK-8220320
Fix: http://cr.openjdk.java.net/~serb/8220320/webrev.00

  - The X11GraphicsDevice.initID() can be removed, because it is unused and its native implementation was dropped already.
  - The code related to #ifdef NETSCAPE can be dropped
  - the null checks in Java_sun_awt_X11GraphicsConfig_initIDs() after "CHECK_NULL()" are redundant

-- 
Best regards, Sergey.

From krishna.addepalli at oracle.com  Mon Mar 11 10:53:10 2019
From: krishna.addepalli at oracle.com (Krishna Addepalli)
Date: Mon, 11 Mar 2019 16:23:10 +0530
Subject: <AWT Dev> [13] JDK-8218917: KeyEvent.getModifiers() returns
 inconsistent values for ALT keys
In-Reply-To: <CANTFZ2i30ao6fVuVxQseEzF38vBnLUfw3PPadYyKrUCrgfKo9g@mail.gmail.com>
References: <990B3CDA-E3A0-4051-8771-1AD486094974@oracle.com>
 <CANTFZ2i30ao6fVuVxQseEzF38vBnLUfw3PPadYyKrUCrgfKo9g@mail.gmail.com>
Message-ID: <6B001F8A-858F-4279-8F42-366F22D49B52@oracle.com>

Hi Sergey,

Thanks for proposing a patch.
The feature of ALT_GR support on Mac was not done by me, however looking at the bug, and the fact that Mac doesn?t have ?AltGR? key, I?m wondering if it makes sense to have code that emits ALT_GR code?

Also, even if we wanted to support it, I wouldn?t want to do it as a compile time flag. Ideally, it should be a flag that can be turned on/off at run time via a system property.

@Manajit, could you throw some light on why it was decided to implement this behaviour on Mac vis a vis disabling all those tests that rely on this behaviour for Mac?

Thanks,
Krishna

> On 06-Mar-2019, at 11:02 PM, Sergey Malenkov <malenkov at gmail.com> wrote:
> 
> Hi Krishna,
> 
> Your fix solves the issue that the right Alt key breaks further
> processing of the left Alt key.
> 
> But there is a problem with modifiers mask:
> 304         java_awt_event_InputEvent_ALT_DOWN_MASK |
> java_awt_event_InputEvent_ALT_GRAPH_DOWN_MASK,
> 305         java_awt_event_InputEvent_ALT_MASK |
> java_awt_event_InputEvent_ALT_GRAPH_MASK,
> 306         java_awt_event_KeyEvent_VK_ALT |
> java_awt_event_KeyEvent_VK_ALT_GRAPH
> 
> Why did you merge VK_ALT and VK_ALT_GRAPH? This is key codes, not a mask.
> Why did you set ALT_DOWN_MASK and ALT_GRAPH_DOWN_MASK both if only the
> VK_ALT_GRAPH is pressed?
> 
> Could you please provide a more complex test? For example,
>  robot.keyPress(KeyEvent.VK_ALT); // check that key code is VK_ALT
> and modifiers = ALT_DOWN_MASK
>  robot.keyPress(KeyEvent.VK_ALT_GRAPH); // check that key code is
> VK_ALT_GRAPH and modifiers = ALT_DOWN_MASK | ALT_GRAPH_DOWN_MASK
>  robot.keyRelease(KeyEvent.VK_ALT); // check that key code is VK_ALT
> and modifiers = ALT_GRAPH_DOWN_MASK
>  robot.keyRelease(KeyEvent.VK_ALT_GRAPH); // check that key code is
> VK_ALT_GRAPH and modifiers = 0
> 
> Note, if you replace ALT_GRAPH with SHIFT in the code above, all
> required events will be sent correctly.
> 
> In the following article I provide a manual test and a simple patch to
> solve issues with pressing the left Shift key together with the right
> one.
> https://urldefense.proofpoint.com/v2/url?u=http-3A__sites.google.com_site_malenkov_java_190306&d=DwIFaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=QF7AertWDY_M4hfHg_4S-iyX-aP0wtLYwZFgs0zfX_k&m=vpGiD5G2K4wQZbNL-H0ffHAEDEWj-433rJ1a-9zAeyE&s=P2SNOGSmKVcDyQuWHUuP9hs5wxjrqkdwtrOMGqv-tZg&e=
> 
> Unfortunately I cannot create an automated test, because the Robot
> have no ability to press a key in the required location (left or
> right).
> 
> 
> 
> On Wed, Mar 6, 2019 at 9:45 AM Krishna Addepalli
> <krishna.addepalli at oracle.com> wrote:
>> 
>> Hi All,
>> 
>> Please review a fix for https://bugs.openjdk.java.net/browse/JDK-8218917
>> With webrev: http://cr.openjdk.java.net/~kaddepalli/8218917/webrev00/
>> 
>> The problem is that once right alt key is pressed, pressing the left alt key always returns the key code for right alt key. The problem was in AWTEvent.m, there is a static variable ?altGRPressed? which is being set once right alt is pressed, but is not being cleared when left alt key is pressed. The fix is to completely remove the ?altGRPressed? variable as ?leftAtlPressed? is sufficient to determine which alt key was pressed.
>> I have tested all the regressions associated with JDK-8156460, and found no new failures.
>> 
>> Thanks,
>> Krishna
> 
> 
> 
> -- 
> Best regards,
> Sergey A. Malenkov


From malenkov at gmail.com  Mon Mar 11 12:23:14 2019
From: malenkov at gmail.com (Sergey Malenkov)
Date: Mon, 11 Mar 2019 15:23:14 +0300
Subject: <AWT Dev> [13] JDK-8218917: KeyEvent.getModifiers() returns
 inconsistent values for ALT keys
In-Reply-To: <6B001F8A-858F-4279-8F42-366F22D49B52@oracle.com>
References: <990B3CDA-E3A0-4051-8771-1AD486094974@oracle.com>
 <CANTFZ2i30ao6fVuVxQseEzF38vBnLUfw3PPadYyKrUCrgfKo9g@mail.gmail.com>
 <6B001F8A-858F-4279-8F42-366F22D49B52@oracle.com>
Message-ID: <CANTFZ2iUHFNSm9st3d3BLYvERa5OmpOzU+T5e1aoLq5C7YkMfQ@mail.gmail.com>

Hi Krishna,

> The feature of ALT_GR support on Mac was not done by me, however looking at the bug, and the fact that Mac doesn?t have ?AltGR? key, I?m wondering if it makes sense to have code that emits ALT_GR code?

Sometimes it can be useful. For example, we can increase amount of
shortcuts in our IDE, i.e. Alt+F -> Alt+F & AltGr+F. But, we should
have an ability to turn this functionality off, because some Mac users
want to use Alt+arrows with the right Alt key.

> Also, even if we wanted to support it, I wouldn?t want to do it as a compile time flag. Ideally, it should be a flag that can be turned on/off at run time via a system property.

This is a good idea. I've added a flag without a system property only
to keep my patch as small as possible.

-- 
Best regards,
Sergey A. Malenkov


> > On 06-Mar-2019, at 11:02 PM, Sergey Malenkov <malenkov at gmail.com> wrote:
> >
> > Hi Krishna,
> >
> > Your fix solves the issue that the right Alt key breaks further
> > processing of the left Alt key.
> >
> > But there is a problem with modifiers mask:
> > 304         java_awt_event_InputEvent_ALT_DOWN_MASK |
> > java_awt_event_InputEvent_ALT_GRAPH_DOWN_MASK,
> > 305         java_awt_event_InputEvent_ALT_MASK |
> > java_awt_event_InputEvent_ALT_GRAPH_MASK,
> > 306         java_awt_event_KeyEvent_VK_ALT |
> > java_awt_event_KeyEvent_VK_ALT_GRAPH
> >
> > Why did you merge VK_ALT and VK_ALT_GRAPH? This is key codes, not a mask.
> > Why did you set ALT_DOWN_MASK and ALT_GRAPH_DOWN_MASK both if only the
> > VK_ALT_GRAPH is pressed?
> >
> > Could you please provide a more complex test? For example,
> >  robot.keyPress(KeyEvent.VK_ALT); // check that key code is VK_ALT
> > and modifiers = ALT_DOWN_MASK
> >  robot.keyPress(KeyEvent.VK_ALT_GRAPH); // check that key code is
> > VK_ALT_GRAPH and modifiers = ALT_DOWN_MASK | ALT_GRAPH_DOWN_MASK
> >  robot.keyRelease(KeyEvent.VK_ALT); // check that key code is VK_ALT
> > and modifiers = ALT_GRAPH_DOWN_MASK
> >  robot.keyRelease(KeyEvent.VK_ALT_GRAPH); // check that key code is
> > VK_ALT_GRAPH and modifiers = 0
> >
> > Note, if you replace ALT_GRAPH with SHIFT in the code above, all
> > required events will be sent correctly.
> >
> > In the following article I provide a manual test and a simple patch to
> > solve issues with pressing the left Shift key together with the right
> > one.
> > https://urldefense.proofpoint.com/v2/url?u=http-3A__sites.google.com_site_malenkov_java_190306&d=DwIFaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=QF7AertWDY_M4hfHg_4S-iyX-aP0wtLYwZFgs0zfX_k&m=vpGiD5G2K4wQZbNL-H0ffHAEDEWj-433rJ1a-9zAeyE&s=P2SNOGSmKVcDyQuWHUuP9hs5wxjrqkdwtrOMGqv-tZg&e=
> >
> > Unfortunately I cannot create an automated test, because the Robot
> > have no ability to press a key in the required location (left or
> > right).
> >
> >
> >
> > On Wed, Mar 6, 2019 at 9:45 AM Krishna Addepalli
> > <krishna.addepalli at oracle.com> wrote:
> >>
> >> Hi All,
> >>
> >> Please review a fix for https://bugs.openjdk.java.net/browse/JDK-8218917
> >> With webrev: http://cr.openjdk.java.net/~kaddepalli/8218917/webrev00/
> >>
> >> The problem is that once right alt key is pressed, pressing the left alt key always returns the key code for right alt key. The problem was in AWTEvent.m, there is a static variable ?altGRPressed? which is being set once right alt is pressed, but is not being cleared when left alt key is pressed. The fix is to completely remove the ?altGRPressed? variable as ?leftAtlPressed? is sufficient to determine which alt key was pressed.
> >> I have tested all the regressions associated with JDK-8156460, and found no new failures.
> >>
> >> Thanks,
> >> Krishna
> >
> >
> >
> > --
> > Best regards,
> > Sergey A. Malenkov

From takiguc at linux.vnet.ibm.com  Mon Mar 11 13:00:14 2019
From: takiguc at linux.vnet.ibm.com (Ichiroh Takiguchi)
Date: Mon, 11 Mar 2019 22:00:14 +0900
Subject: <AWT Dev> RFR: 8213232 Unix/X11 setCompositionEnableNative issue
In-Reply-To: <50e98ca5cbdc56a5a13b0754968521c2@linux.vnet.ibm.com>
References: <9ad6f2166ea8eabcf7391feccf9d8915@linux.vnet.ibm.com>
 <0a651f1099a96e314573b6b8c9f60e6c@linux.vnet.ibm.com>
 <50e98ca5cbdc56a5a13b0754968521c2@linux.vnet.ibm.com>
Message-ID: <a2c8c52f2075c49ae256564208f2d0d0@linux.vnet.ibm.com>

Hello.

Could you review the fix and give me your suggestion, please ?

Thanks,
Ichiroh Takiguchi

On 2019-02-26 22:08, Ichiroh Takiguchi wrote:
> Hello.
> 
> Could you review the fix ?
> 
> Bug:    https://bugs.openjdk.java.net/browse/JDK-8213232
> Change: https://cr.openjdk.java.net/~itakiguchi/8213232/webrev.01/
> 
> JDK-8213232 [1] has movies.
> Please check it.
> 
> I applied following changes on webrev.01:
> 1. According to "Xlib - C Language X Interface" [2]
>    See "Preedit State Callbacks" section:
>    PreeditStartCallback() should return int.
> 2. Add 64bit Big Endian CPU support, like s390x
> 3. Change copyright year
> 
> [1] https://bugs.openjdk.java.net/browse/JDK-8213232
> [2] 
> https://www.x.org/releases/X11R7.6/doc/libX11/specs/libX11/libX11.html
> 
> Thanks,
> Ichiroh Takiguchi
> IBM Japan, Ltd.
> 
> On 2018-12-04 11:22, Ichiroh Takiguchi wrote:
>> Hello.
>> 
>> Could you review the fix ?
>> 
>> Bug:    https://bugs.openjdk.java.net/browse/JDK-8213232
>> Change: https://cr.openjdk.java.net/~itakiguchi/8213232/webrev.00/
>> 
>> This issue is related by wrong usage of XNPreeditState on 
>> XSetICValues().
>> Because of wrong usage, UnsupportedOperationException exception
>> happened with Xlib bundled input method.
>> Test instructions is in JDK-8213232.
>> 
>> I'd like to obtain a sponsor for this issue.
>> 
>> Thanks,
>> Ichiroh Takiguchi
>> IBM Japan, Ltd.
>> 
>> On 2018-06-19 02:15, Ichiroh Takiguchi wrote:
>>> Hello,
>>> IBM would like to contribute Unix/X11 setCompositionEnableNative 
>>> issue
>>> patch to OpenJDK project.
>>> 
>>> Issue:
>>> To  turn on or turn off IME via Java, XNPreeditState should be used
>>> with XSetValues().
>>> But it should be nested via XVaCreateNestedList() since 
>>> XNPreeditState
>>> is a part of XNPreeditAttributes.
>>> Current code is, like:
>>> -    ret = XSetICValues(pX11IMData->current_ic, XNPreeditState,
>>> -                       (enable ? XIMPreeditEnable : 
>>> XIMPreeditDisable), NULL);
>>> But it should be, like:
>>> +    pr_atrb = XVaCreateNestedList(0,
>>> +                  XNPreeditState, (enable ? XIMPreeditEnable :
>>> XIMPreeditDisable),
>>> +                  NULL);
>>> +    ret = XSetICValues(pX11IMData->current_ic, XNPreeditAttributes,
>>> pr_atrb, NULL);
>>> 
>>> On Linux platform, the issue can check with following test program 
>>> and
>>> kinput2 XIM server and
>>> Wnn8 for Linux/BSD (htt).
>>> ==================
>>> import java.awt.*;
>>> import java.awt.event.*;
>>> import javax.swing.*;
>>> 
>>> public class CompositionEnabledTest extends JFrame {
>>>   CompositionEnabledTest() {
>>>     Container c = getContentPane();
>>>     c.setLayout(new GridLayout(0,2));
>>>     JButton btn;
>>>     JTextField tf;
>>>     btn = new JButton("Undefined");
>>>     c.add(btn);
>>>     tf = new JTextField("Undefined");
>>>     c.add(tf);
>>>     btn = new JButton("Disabled");
>>>     btn.addFocusListener(new MyFocusListener(false));
>>>     c.add(btn);
>>>     tf = new JTextField("Disabled");
>>>     tf.addFocusListener(new MyFocusListener(false));
>>>     c.add(tf);
>>>     btn = new JButton("Enabled");
>>>     btn.addFocusListener(new MyFocusListener(true));
>>>     c.add(btn);
>>>     tf = new JTextField("Enabled");
>>>     tf.addFocusListener(new MyFocusListener(true));
>>>     c.add(tf);
>>>     setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);
>>>     pack();
>>>     setVisible(true);
>>>   }
>>>   class MyFocusListener implements FocusListener {
>>>     boolean state;
>>>     MyFocusListener(boolean state) {
>>>       this.state = state;
>>>     }
>>>     public void focusGained(FocusEvent fe) {
>>>       
>>> fe.getComponent().getInputContext().setCompositionEnabled(state);
>>>     }
>>>     public void focusLost(FocusEvent fe) { }
>>>   }
>>>   public static void main(String[] args) {
>>>     new CompositionEnabledTest();
>>>   }
>>> }
>>> ==================
>>> 
>>> Click JTextField and JButton, then XIM server status may be changed.
>>> If XIM server does not support XNPreeditState, it does not work.
>>> 
>>> I'd like contribute following 3 files:
>>> M src/java.desktop/share/classes/sun/awt/im/InputContext.java
>>> M src/java.desktop/unix/classes/sun/awt/X11InputMethod.java
>>> M src/java.desktop/unix/native/libawt_xawt/awt/awt_InputMethod.c
>>> 
>>> http://cr.openjdk.java.net/~aleonard/set_composition_enabled/webrev.00/
>>> 
>>> I appreciate any feedback please, and how I would go about obtaining 
>>> a
>>> sponsor and contributor?
>>> 
>>> Thanks,
>>> Ichiroh Takiguchi
>>> IBM Japan, Ltd.


From philip.race at oracle.com  Mon Mar 11 14:43:02 2019
From: philip.race at oracle.com (Philip Race)
Date: Mon, 11 Mar 2019 20:13:02 +0530
Subject: <AWT Dev> [13] JDK-8218917: KeyEvent.getModifiers() returns
 inconsistent values for ALT keys
In-Reply-To: <CANTFZ2iUHFNSm9st3d3BLYvERa5OmpOzU+T5e1aoLq5C7YkMfQ@mail.gmail.com>
References: <990B3CDA-E3A0-4051-8771-1AD486094974@oracle.com>
 <CANTFZ2i30ao6fVuVxQseEzF38vBnLUfw3PPadYyKrUCrgfKo9g@mail.gmail.com>
 <6B001F8A-858F-4279-8F42-366F22D49B52@oracle.com>
 <CANTFZ2iUHFNSm9st3d3BLYvERa5OmpOzU+T5e1aoLq5C7YkMfQ@mail.gmail.com>
Message-ID: <5C8673F6.8060306@oracle.com>

Having looked at this a little bit today it all makes no sense to me.
The work was done to prevent failure of a test which assumes AltGraph
is available, but it is not on Mac. So a Mac key was usurped to provide it.
When all we needed to do was disable the test on Mac

Since then for reasons that baffle me after adding the support, the test
has now been updated to not run on MacOS.

The reasoning that AltGraph might be useful to someone is a bit weak
and I don't think I'd want to support it via system property or build 
options.

If its not a platform keyboard key, why do we need it ?

Back the fixes out all the way to before this started and keep the test 
disabled
on Mac - with appropriate tweaks - is what looks best to me.

-phil.

On 3/11/19, 5:53 PM, Sergey Malenkov wrote:
> Hi Krishna,
>
>> The feature of ALT_GR support on Mac was not done by me, however looking at the bug, and the fact that Mac doesn?t have ?AltGR? key, I?m wondering if it makes sense to have code that emits ALT_GR code?
> Sometimes it can be useful. For example, we can increase amount of
> shortcuts in our IDE, i.e. Alt+F ->  Alt+F&  AltGr+F. But, we should
> have an ability to turn this functionality off, because some Mac users
> want to use Alt+arrows with the right Alt key.
>
>> Also, even if we wanted to support it, I wouldn?t want to do it as a compile time flag. Ideally, it should be a flag that can be turned on/off at run time via a system property.
> This is a good idea. I've added a flag without a system property only
> to keep my patch as small as possible.
>

From Sergey.Bylokhov at oracle.com  Tue Mar 12 00:04:45 2019
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Mon, 11 Mar 2019 17:04:45 -0700
Subject: <AWT Dev> [13] JDK-8218917: KeyEvent.getModifiers() returns
 inconsistent values for ALT keys
In-Reply-To: <5C8673F6.8060306@oracle.com>
References: <990B3CDA-E3A0-4051-8771-1AD486094974@oracle.com>
 <CANTFZ2i30ao6fVuVxQseEzF38vBnLUfw3PPadYyKrUCrgfKo9g@mail.gmail.com>
 <6B001F8A-858F-4279-8F42-366F22D49B52@oracle.com>
 <CANTFZ2iUHFNSm9st3d3BLYvERa5OmpOzU+T5e1aoLq5C7YkMfQ@mail.gmail.com>
 <5C8673F6.8060306@oracle.com>
Message-ID: <6d97202a-ad60-c768-4a31-66ca02f16f70@oracle.com>

Hi, Phil.
On 11/03/2019 07:43, Philip Race wrote:
> The reasoning that AltGraph might be useful to someone is a bit weak
> and I don't think I'd want to support it via system property or build options.
> 
> If its not a platform keyboard key, why do we need it ?

The "AltGraph" key is also commonly referred to as "Right Alt", and
it has been implemented on all platforms as a "Right Alt", it is convenient to
distinguish the left/right alts.

-- 
Best regards, Sergey.

From philip.race at oracle.com  Tue Mar 12 00:37:16 2019
From: philip.race at oracle.com (Philip Race)
Date: Tue, 12 Mar 2019 06:07:16 +0530
Subject: <AWT Dev> [13] JDK-8218917: KeyEvent.getModifiers() returns
 inconsistent values for ALT keys
In-Reply-To: <6d97202a-ad60-c768-4a31-66ca02f16f70@oracle.com>
References: <990B3CDA-E3A0-4051-8771-1AD486094974@oracle.com>
 <CANTFZ2i30ao6fVuVxQseEzF38vBnLUfw3PPadYyKrUCrgfKo9g@mail.gmail.com>
 <6B001F8A-858F-4279-8F42-366F22D49B52@oracle.com>
 <CANTFZ2iUHFNSm9st3d3BLYvERa5OmpOzU+T5e1aoLq5C7YkMfQ@mail.gmail.com>
 <5C8673F6.8060306@oracle.com>
 <6d97202a-ad60-c768-4a31-66ca02f16f70@oracle.com>
Message-ID: <5C86FF3C.7030700@oracle.com>

The debate is about AltGraph which an ancient MS-DOSism for
asking for an ALTernate GRAPHics bitmap font - all pre-dates windows
and I am sure has never been applicable to any MacOS.

So someone needs to properly explain why we would claim a Mac keyboard
is OK to generate a keycode it doesn't have and cause a slew of regressions
in the process ...

If Mac doesn't distinguish these two, we should generate the same 
keycode for both.
One could suppose there is a difference else why two keys, but what is 
the right
thing to do here  that fixes all the problems. What exactly WAS the problem
with what was there in the first place ? And if changing it is correct 
why is it
causing regressions ?

-phil.



On 3/12/19, 5:34 AM, Sergey Bylokhov wrote:
> Hi, Phil.
> On 11/03/2019 07:43, Philip Race wrote:
>> The reasoning that AltGraph might be useful to someone is a bit weak
>> and I don't think I'd want to support it via system property or build 
>> options.
>>
>> If its not a platform keyboard key, why do we need it ?
>
> The "AltGraph" key is also commonly referred to as "Right Alt", and
> it has been implemented on all platforms as a "Right Alt", it is 
> convenient to
> distinguish the left/right alts.
>

From Sergey.Bylokhov at oracle.com  Tue Mar 12 01:17:18 2019
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Mon, 11 Mar 2019 18:17:18 -0700
Subject: <AWT Dev> [13] JDK-8218917: KeyEvent.getModifiers() returns
 inconsistent values for ALT keys
In-Reply-To: <5C86FF3C.7030700@oracle.com>
References: <990B3CDA-E3A0-4051-8771-1AD486094974@oracle.com>
 <CANTFZ2i30ao6fVuVxQseEzF38vBnLUfw3PPadYyKrUCrgfKo9g@mail.gmail.com>
 <6B001F8A-858F-4279-8F42-366F22D49B52@oracle.com>
 <CANTFZ2iUHFNSm9st3d3BLYvERa5OmpOzU+T5e1aoLq5C7YkMfQ@mail.gmail.com>
 <5C8673F6.8060306@oracle.com>
 <6d97202a-ad60-c768-4a31-66ca02f16f70@oracle.com>
 <5C86FF3C.7030700@oracle.com>
Message-ID: <b842a817-1c61-7d23-a144-41bfc87013a3@oracle.com>

On 11/03/2019 17:37, Philip Race wrote:
> The debate is about AltGraph which an ancient MS-DOSism for
> asking for an ALTernate GRAPHics bitmap font - all pre-dates windows
> and I am sure has never been applicable to any MacOS.

It also about the "right alt" which is also know as "AltGraph". I guess currently
it is implemented as "right alt" on Linux/macOS/windows.

BTW on linux it is also named as "Alternative Characters Key":
https://help.ubuntu.com/community/ComposeKey

> So someone needs to properly explain why we would claim a Mac keyboard
> is OK to generate a keycode it doesn't have and cause a slew of regressions
> in the process ...> 
> If Mac doesn't distinguish these two, we should generate the same keycode for both.

The macOS supports "right alt", otherwise it would not be possible to implement it in java:
https://developer.apple.com/library/archive/technotes/tn2450/_index.html


> One could suppose there is a difference else why two keys, but what is the right
> thing to do here? that fixes all the problems. What exactly WAS the problem
> with what was there in the first place ? And if changing it is correct why is it
> causing regressions ?

Regressions were caused by the bugs in the fix implementation, or am I missed something?


> 
> -phil.
> 
> 
> 
> On 3/12/19, 5:34 AM, Sergey Bylokhov wrote:
>> Hi, Phil.
>> On 11/03/2019 07:43, Philip Race wrote:
>>> The reasoning that AltGraph might be useful to someone is a bit weak
>>> and I don't think I'd want to support it via system property or build options.
>>>
>>> If its not a platform keyboard key, why do we need it ?
>>
>> The "AltGraph" key is also commonly referred to as "Right Alt", and
>> it has been implemented on all platforms as a "Right Alt", it is convenient to
>> distinguish the left/right alts.
>>


-- 
Best regards, Sergey.

From takiguc at linux.vnet.ibm.com  Tue Mar 12 02:04:55 2019
From: takiguc at linux.vnet.ibm.com (Ichiroh Takiguchi)
Date: Tue, 12 Mar 2019 11:04:55 +0900
Subject: <AWT Dev> RFR: 8212676 AIX's CDE/MWM support
In-Reply-To: <13a9685a38984c56ec2f0aaa084a3f80@linux.vnet.ibm.com>
References: <5f309d9c612f2c16aef75846e0ff14fa@linux.vnet.ibm.com>
 <d2b3bc94-0ba3-712f-c46b-f83048491cb0@oracle.com>
 <f942c133e212bace34e72e79bfb64ab4@linux.vnet.ibm.com>
 <0ede447e30ed05ce7a52f6d133b2c15b@linux.vnet.ibm.com>
 <180114e58e98f339332e3a781a34126b@linux.vnet.ibm.com>
 <d9e8c69e64ff87bb84a9468b4364fb06@linux.vnet.ibm.com>
 <5a4f9f5c7a80a5abda9edd150e19a11f@linux.vnet.ibm.com>
 <4addeebf-9ed8-bb63-5920-49ae6fb429b1@oracle.com>
 <c314e88dcc25495f6fba698f8ad5ae63@linux.vnet.ibm.com>
 <5C0725B5.3080907@oracle.com> <5C0773E7.8030108@oracle.com>
 <ad8f6c895b66c65a0b7bc344c5a759e0@linux.vnet.ibm.com>
 <13a9685a38984c56ec2f0aaa084a3f80@linux.vnet.ibm.com>
Message-ID: <368b32e110b608570c4929e216ee37c6@linux.vnet.ibm.com>

Hello.

Could you review the fix and give me your suggestion, please ?

Thanks,
Ichiroh Takiguchi

On 2019-03-01 22:16, Ichiroh Takiguchi wrote:
> Hello.
> 
> Could you review the fix again ?
> 
> Bug:    https://bugs.openjdk.java.net/browse/JDK-8212676
> Change: https://cr.openjdk.java.net/~itakiguchi/8212676/webrev.01/
> 
> I applied following changes:
> * I added AIX detection code into sun.awt.OSInfo class.
>   It seems CDE's default should be middle color.
>   But AIX's default is high color, so AIX detection code is required.
> * MWM detection code can be used on Linux and AIX platform
>   AIX only code was removed
> * I could not recreate XMapRaised/XMapWindow related issue.
>   The fix was ignored
> * Non-focusable window handling on DTWM/MWM
>   I checked Linux's MWM working behavior on RHEL6.
>   I applied AIX's code into Linux side, but it was bad.
>   Working behavior became worse.
>   So AIX detection feature is still required.
> 
> (JDK-8212676 was also updated)
> 
> I'd like to obtain a sponsor for this issue.
> 
> Thanks,
> Ichiroh Takiguchi
> IBM Japan, Ltd.
> 
> On 2018-12-05 18:22, Ichiroh Takiguchi wrote:
>> Hello Phil.
>> 
>> I heard some of AIX users used RealVNC VNC Enterprise Edition for AIX
>> maintenance. [1]
>> I assume they still use CDE.
>> 
>> [1] 
>> https://www.realvnc.com/en/connect/download/vnc/aix/#older-versions
>> 
>> Thanks,
>> Ichiroh Takiguchi
>> 
>> On 2018-12-05 15:44, Philip Race wrote:
>>> . and I think I need to be convinced about whether "aix" is the right
>>> thing to check here.
>>> "I know AIX works like this today" isn't a very robust, or very
>>> portable approach.
>>> The fix is more about the CDE/Motif environment than AIX, isn't it ?
>>> 
>>> -phil.
>>> 
>>> 
>>> On 12/4/18, 5:11 PM, Philip Race wrote:
>>>> 
>>>> 
>>>> On 12/4/18, 5:10 PM, Ichiroh Takiguchi wrote:
>>>>> Hello Phil.
>>>>> 
>>>>>> I haven't evaluated the merits of this proposal but this
>>>>>> https://cr.openjdk.java.net/~itakiguchi/8212676/webrev.00/src/java.desktop/share/classes/sun/font/FontUtilities.java.udiff.html 
>>>>>> is not the right place to support a flag used in all these X11 
>>>>>> files.
>>>>> Could you give me your recommendation ?
>>>> 
>>>> Somewhere closer to the code that needs it.
>>>>> 
>>>>>> And why is i18n-dev on the review ? I can't see any I18N related 
>>>>>> changes.
>>>>> I thought focus issue was related input method.
>>>> 
>>>> No. I mean input focus is necessary for input methods but focus does 
>>>> not
>>>> automatically mean input methods are in play.
>>>> 
>>>> -phil
>>>> 
>>>>> AIX IM was activated even if focus was moved to non focusable 
>>>>> window (middle window). [1]
>>>>> So I posted this issue into I18N, but it was not good.
>>>>> Actually, all key events were forwarded to middle window if user 
>>>>> clicked inside of right window.
>>>>> 
>>>>> [1] 
>>>>> https://bugs.openjdk.java.net/secure/attachment/79986/aix-focusable.png
>>>>> 
>>>>> Thanks,
>>>>> Ichiroh Takiguchi
>>>>> 
>>>>> On 2018-12-05 03:06, Phil Race wrote:
>>>>>> I haven't evaluated the merits of this proposal but this
>>>>>> https://cr.openjdk.java.net/~itakiguchi/8212676/webrev.00/src/java.desktop/share/classes/sun/font/FontUtilities.java.udiff.html 
>>>>>> is not the right place to support a flag used in all these X11 
>>>>>> files.
>>>>>> 
>>>>>> And why is i18n-dev on the review ? I can't see any I18N related 
>>>>>> changes.
>>>>>> 
>>>>>> -phil.
>>>>>> 
>>>>>> On 12/4/18 8:53 AM, Ichiroh Takiguchi wrote:
>>>>>>> Hello again.
>>>>>>> 
>>>>>>> Could you give me review comment and/or suggestion ?
>>>>>>> 
>>>>>>> Bug:    https://bugs.openjdk.java.net/browse/JDK-8212676
>>>>>>> Change: 
>>>>>>> https://cr.openjdk.java.net/~itakiguchi/8212676/webrev.00/
>>>>>>> 
>>>>>>> Thanks,
>>>>>>> Ichiroh Takiguchi
>>>>>>> 
>>>>>>> On 2018-11-26 21:27, Ichiroh Takiguchi wrote:
>>>>>>>> Hello.
>>>>>>>> 
>>>>>>>> Could you review the fix ?
>>>>>>>> 
>>>>>>>> Bug:    https://bugs.openjdk.java.net/browse/JDK-8212676
>>>>>>>> Change: 
>>>>>>>> https://cr.openjdk.java.net/~itakiguchi/8212676/webrev.00/
>>>>>>>> 
>>>>>>>> Test instructions and screen shots are in JDK-8212676.
>>>>>>>> 
>>>>>>>> GUI environment for AIX platform still needs CDE support.
>>>>>>>> This fix is required to avoid unexpected working behavior on AIX 
>>>>>>>> platform.
>>>>>>>> 
>>>>>>>> I'd like to obtain a sponsor for this issue.
>>>>>>>> 
>>>>>>>> Thanks,
>>>>>>>> Ichiroh Takiguchi
>>>>>>>> IBM Japan, Ltd.
>>>>>>>> 
>>>>>>>> On 2018-06-18 18:57, Ichiroh Takiguchi wrote:
>>>>>>>>> Hello.
>>>>>>>>> 
>>>>>>>>> This fix is really required for AIX's GUI.
>>>>>>>>> System color setting and window manager's working behavior are 
>>>>>>>>> very important.
>>>>>>>>> 
>>>>>>>>> I appreciate any feedback, and how I would go about obtaining a
>>>>>>>>> sponsor and contributor ?
>>>>>>>>> 
>>>>>>>>> On 2018-05-25 11:02, Ichiroh Takiguchi wrote:
>>>>>>>>>> Hello Phil.
>>>>>>>>>> 
>>>>>>>>>> webrev file was extracted.
>>>>>>>>>> Please see
>>>>>>>>>>   http://cr.openjdk.java.net/~aleonard/AIX_GUI/webrev.00/
>>>>>>>>>> 
>>>>>>>>>> On 2018-05-19 02:48, Ichiroh Takiguchi wrote:
>>>>>>>>>>> Hello Phil.
>>>>>>>>>>> 
>>>>>>>>>>> Webrev.zip file is stored into
>>>>>>>>>>> http://cr.openjdk.java.net/~aleonard/AIX_GUI/webrev-aixgui.zip
>>>>>>>>>>> 
>>>>>>>>>>> Test programs are also stored:
>>>>>>>>>>> No testcase is available for FontUtilities.java and 
>>>>>>>>>>> XDecoratedPeer.java.
>>>>>>>>>>> 
>>>>>>>>>>> MotifColorUtilities.java
>>>>>>>>>>> http://cr.openjdk.java.net/~aleonard/AIX_GUI/SystemColorTest2.java
>>>>>>>>>>> Run SystemColorTest2, system colors should be displayed
>>>>>>>>>>> AIX sample is
>>>>>>>>>>> http://cr.openjdk.java.net/~aleonard/AIX_GUI/aix_systemcolor.txt
>>>>>>>>>>> 
>>>>>>>>>>> XWM.java
>>>>>>>>>>> http://cr.openjdk.java.net/~aleonard/AIX_GUI/XWMTest1.java
>>>>>>>>>>> On AIX CDE, isMotif and isCDE were true.
>>>>>>>>>>> On AIX MWM, every entry is false.
>>>>>>>>>>> 
>>>>>>>>>>> XWindowPeer.java
>>>>>>>>>>> http://cr.openjdk.java.net/~aleonard/AIX_GUI/JFrameTest.java
>>>>>>>>>>> On AIX CDE, click inside of "Non-Focusable" window (not 
>>>>>>>>>>> window frame).
>>>>>>>>>>> Window focus should not be changed because of "click on 
>>>>>>>>>>> focus" feature.
>>>>>>>>>>> But input focus is moved to "Non-Focusable" window.
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> On 2018-05-18 01:00, Phil Race wrote:
>>>>>>>>>>>> I think we'd need to see the actual proposed changes and 
>>>>>>>>>>>> understand
>>>>>>>>>>>> the implications
>>>>>>>>>>>> for ongoing support as we no longer support any platform 
>>>>>>>>>>>> which has a
>>>>>>>>>>>> CDE desktop.
>>>>>>>>>>>> Solaris 11.3 uses Gnome, so we'd be more inclined to be 
>>>>>>>>>>>> ripping out
>>>>>>>>>>>> such support rather
>>>>>>>>>>>> than adding to it.
>>>>>>>>>>>> 
>>>>>>>>>>>> -phil.
>>>>>>>>>>>> 
>>>>>>>>>>>> On 05/17/2018 04:18 AM, Ichiroh Takiguchi wrote:
>>>>>>>>>>>>> Hello,
>>>>>>>>>>>>> IBM would like to contribute AIX's CDE (Common Desktop 
>>>>>>>>>>>>> Environment) DTWM (Desktop Window Manager) /MWM (Motif 
>>>>>>>>>>>>> Window Manager) support to OpenJDK project.
>>>>>>>>>>>>> 
>>>>>>>>>>>>> I'd like contribute following 5 files:
>>>>>>>>>>>>> 
>>>>>>>>>>>>> M 
>>>>>>>>>>>>> src/java.desktop/share/classes/sun/font/FontUtilities.java
>>>>>>>>>>>>> (Add isAIX flag to determine AIX platform for GUI 
>>>>>>>>>>>>> environment)
>>>>>>>>>>>>> M 
>>>>>>>>>>>>> src/java.desktop/unix/classes/sun/awt/X11/MotifColorUtilities.java 
>>>>>>>>>>>>> (Add High Color support on CDE, OpenJDK just supports 
>>>>>>>>>>>>> Medium Color) [1]
>>>>>>>>>>>>> M 
>>>>>>>>>>>>> src/java.desktop/unix/classes/sun/awt/X11/XDecoratedPeer.java
>>>>>>>>>>>>> (Avoid miss calculation for window position under DTWM/MWM 
>>>>>>>>>>>>> by XMapRaised/XMapWindow)
>>>>>>>>>>>>> M src/java.desktop/unix/classes/sun/awt/X11/XWM.java
>>>>>>>>>>>>> (Detect MWM on AIX platform)
>>>>>>>>>>>>> M 
>>>>>>>>>>>>> src/java.desktop/unix/classes/sun/awt/X11/XWindowPeer.java
>>>>>>>>>>>>> (Add non-focusable window support on DTWM/MWM for AIX, 
>>>>>>>>>>>>> because DTWM/MWM does not have enough features for ICCCM)
>>>>>>>>>>>>> 
>>>>>>>>>>>>> I appreciate any feedback please, and how I would go about 
>>>>>>>>>>>>> obtaining a sponsor and contributor ?
>>>>>>>>>>>>> 
>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>> Ichiroh Takiguchi
>>>>>>>>>>>>> IBM Japan, Ltd.
>>>>>>>>>>>>> 
>>>>>>>>>>>>> [1] 
>>>>>>>>>>>>> https://docs.oracle.com/cd/E19253-01/806-7492/fontsandcolors-15233/index.html
>>>>>>>>>>>>> 
>>>>>>> 
>>>>> 


From shashidhara.veerabhadraiah at oracle.com  Tue Mar 12 08:36:55 2019
From: shashidhara.veerabhadraiah at oracle.com (Shashidhara Veerabhadraiah)
Date: Tue, 12 Mar 2019 01:36:55 -0700 (PDT)
Subject: <AWT Dev> <Swing Dev> [13] JDK-8216008:
 -Djavax.accessibility.assistive_technologies empty list leads to crash
In-Reply-To: <606ce427-71da-8bdb-7726-5334ab3d3399@oracle.com>
References: <86dc6276-6a1c-4d09-8155-705fea8fd95e@default>
 <c548de66-3c14-4488-b719-6a0cfde1dc9b@default>
 <9149f70d-5265-efb1-e496-48e159e61e92@oracle.com>
 <554176f6-b538-46b5-97bb-14e488f50656@default>
 <b99d879b-c2ce-358f-be3a-339d5faeff63@oracle.com>
 <daf49f44-1a41-8aa3-3c82-2fbd57ee7634@oracle.com>
 <a48ea2a7-ebdd-410d-b6f9-88288d6ee6d4@default> <5C5DEB0E.5010405@oracle.com>
 <23625b97-76d0-4956-8d4b-bf1add82ceb1@default>
 <1d4ad24a-e6bf-8e71-c88c-020e1106f089@oracle.com>
 <de99f10e-04da-4109-9980-4a8daf6a973c@default>
 <8634f5a6-a0a6-5739-9fd6-9a304a4a97f3@oracle.com>
 <70c695de-a54e-4aad-ae7b-0e11a6b9054e@default>
 <fdffa07a-7513-4a66-bbb9-5774b521b5d5@default>
 <f586ecc6-a795-4564-a825-0b66323a8326@default>
 <a2e461b3-c4e9-4955-8bec-44c8eb45b269@default> <5C7FFF71.1020809@oracle.com>
 <88e0e602-7b4e-443d-95fe-a7fe288fa161@default>
 <fcce40df-1b75-41ea-9381-f8fd5086d4ee@default> <5C82100D.8030106@oracle.com>
 <c7154c53-b67c-469f-8ca2-a4f886cbf635@default>
 <606ce427-71da-8bdb-7726-5334ab3d3399@oracle.com>
Message-ID: <36db56a3-b0c1-4509-a65d-f6d198e34e73@default>

Hi Joe, Thank you for that good suggestion. I have incorporated the same and here is the new Webrev:

?

http://cr.openjdk.java.net/~sveerabhadra/8216008/webrev.10/

?

Thanks and regards,

Shashi

?

From: Joe Darcy 
Sent: Friday, March 8, 2019 2:42 PM
To: Shashidhara Veerabhadraiah <shashidhara.veerabhadraiah at oracle.com>; Philip Race <philip.race at oracle.com>
Cc: awt-dev at openjdk.java.net; swing-dev at openjdk.java.net
Subject: Re: <AWT Dev> <Swing Dev> [13] JDK-8216008: -Djavax.accessibility.assistive_technologies empty list leads to crash

?

Hello,

I strongly recommend using 

??? String.strip

rather than

??? String.trim

as Strim.trim uses a idosyncratic definition of whitespace whereas the new-in-11 String.strip uses a conventional definition of white space. Likewise, I recommend linking "white space" to the definition of white space used by Character.isWhitespace.

Thanks,

-Joe

On 3/7/2019 10:56 PM, Shashidhara Veerabhadraiah wrote:

Thank you Phil. Sure will wait till CSR is approved.

?

Thanks and regards,

shashi

?

From: Philip Race 
Sent: Friday, March 8, 2019 12:18 PM
To: Shashidhara Veerabhadraiah HYPERLINK "mailto:shashidhara.veerabhadraiah at oracle.com"<shashidhara.veerabhadraiah at oracle.com>
Cc: HYPERLINK "mailto:awt-dev at openjdk.java.net"awt-dev at openjdk.java.net; Joe Darcy HYPERLINK "mailto:joe.darcy at oracle.com"<joe.darcy at oracle.com>; HYPERLINK "mailto:swing-dev at openjdk.java.net"swing-dev at openjdk.java.net
Subject: Re: <AWT Dev> <Swing Dev> [13] JDK-8216008: -Djavax.accessibility.assistive_technologies empty list leads to crash

?

Ok but you need to wait for the CSR to be approved before you can push.

-phil.

On 3/8/19, 11:41 AM, Shashidhara Veerabhadraiah wrote: 

Hi Phil, As discussed here are the updates for the Webrev. Hopefully this is correct.

?

HYPERLINK "http://cr.openjdk.java.net/%7Esveerabhadra/8216008/webrev.09/"http://cr.openjdk.java.net/~sveerabhadra/8216008/webrev.09/

?

Thanks and regards,

Shashi

?

From: Shashidhara Veerabhadraiah 
Sent: Friday, March 8, 2019 10:33 AM
To: Philip Race HYPERLINK "mailto:philip.race at oracle.com"<philip.race at oracle.com>
Cc: HYPERLINK "mailto:awt-dev at openjdk.java.net"awt-dev at openjdk.java.net; Joe Darcy HYPERLINK "mailto:joe.darcy at oracle.com"<joe.darcy at oracle.com>; HYPERLINK "mailto:swing-dev at openjdk.java.net"swing-dev at openjdk.java.net
Subject: Re: <AWT Dev> <Swing Dev> [13] JDK-8216008: -Djavax.accessibility.assistive_technologies empty list leads to crash

?

Thank you Phil for the review and here are the updates done:

?

HYPERLINK "http://cr.openjdk.java.net/%7Esveerabhadra/8216008/webrev.08/"http://cr.openjdk.java.net/~sveerabhadra/8216008//webrev.08/

?

Thanks and regards,

Shashi

?

From: Philip Race 
Sent: Wednesday, March 6, 2019 10:42 PM
To: Shashidhara Veerabhadraiah <HYPERLINK "mailto:shashidhara.veerabhadraiah at oracle.com"shashidhara.veerabhadraiah at oracle.com>
Cc: HYPERLINK "mailto:awt-dev at openjdk.java.net"awt-dev at openjdk.java.net; HYPERLINK "mailto:swing-dev at openjdk.java.net"swing-dev at openjdk.java.net; Joe Darcy <HYPERLINK "mailto:joe.darcy at oracle.com"joe.darcy at oracle.com>
Subject: Re: <AWT Dev> <Swing Dev> [13] JDK-8216008: -Djavax.accessibility.assistive_technologies empty list leads to crash

?

the webrev needs a couple of minor tweaks :
?
contains empty string -> is the empty string
?
and
?
immeadiately -> immediately


Go ahead and finalize the CSR which looks OK.

-phil.

On 3/6/19, 11:45 AM, Shashidhara Veerabhadraiah wrote: 

Hi Phil\Sergey, Please review the CSR along with the bug fix.

?

Webrev: HYPERLINK "http://cr.openjdk.java.net/%7Esveerabhadra/8216008/webrev.07/"http://cr.openjdk.java.net/~sveerabhadra/8216008/webrev.07/

?

CSR: https://bugs.openjdk.java.net/browse/JDK-8218737

?

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

?

Thanks and regards,

Shashi

?

From: Shashidhara Veerabhadraiah 
Sent: Monday, March 4, 2019 3:36 PM
To: Philip Race HYPERLINK "mailto:philip.race at oracle.com"<philip.race at oracle.com>; Joe Darcy HYPERLINK "mailto:joe.darcy at oracle.com"<joe.darcy at oracle.com>
Cc: HYPERLINK "mailto:awt-dev at openjdk.java.net"awt-dev at openjdk.java.net; HYPERLINK "mailto:swing-dev at openjdk.java.net"swing-dev at openjdk.java.net
Subject: Re: <AWT Dev> <Swing Dev> [13] JDK-8216008: -Djavax.accessibility.assistive_technologies empty list leads to crash

?

Hi Joe, Please find the updated Webrev fixing the typo:

?

HYPERLINK "http://cr.openjdk.java.net/%7Esveerabhadra/8216008/webrev.07/"http://cr.openjdk.java.net/~sveerabhadra/8216008/webrev.07/

?

Thanks and regards,

Shashi

?

From: Shashidhara Veerabhadraiah 
Sent: Thursday, February 21, 2019 2:08 PM
To: Philip Race <HYPERLINK "mailto:philip.race at oracle.com"philip.race at oracle.com>; Joe Darcy <HYPERLINK "mailto:joe.darcy at oracle.com"joe.darcy at oracle.com>
Cc: HYPERLINK "mailto:awt-dev at openjdk.java.net"awt-dev at openjdk.java.net; HYPERLINK "mailto:swing-dev at openjdk.java.net"swing-dev at openjdk.java.net
Subject: Re: <AWT Dev> <Swing Dev> [13] JDK-8216008: -Djavax.accessibility.assistive_technologies empty list leads to crash

?

Hi Joe, Please find the new Webrev fixing the specification as asked in the CSR bug: https://bugs.openjdk.java.net/browse/JDK-8218737

?

Webrev: HYPERLINK "http://cr.openjdk.java.net/%7Esveerabhadra/8216008/webrev.06/"http://cr.openjdk.java.net/~sveerabhadra/8216008/webrev.06/

?

Thanks and regards,

Shashi

?

From: Shashidhara Veerabhadraiah 
Sent: Monday, February 18, 2019 10:19 AM
To: Philip Race <HYPERLINK "mailto:philip.race at oracle.com"philip.race at oracle.com>
Cc: HYPERLINK "mailto:awt-dev at openjdk.java.net"awt-dev at openjdk.java.net; HYPERLINK "mailto:swing-dev at openjdk.java.net"swing-dev at openjdk.java.net
Subject: Re: <AWT Dev> <Swing Dev> [13] JDK-8216008: -Djavax.accessibility.assistive_technologies empty list leads to crash

?

Thank you Phil for that help on CSR.

?

From: Phil Race 
Sent: Friday, February 15, 2019 9:41 PM
To: Shashidhara Veerabhadraiah <HYPERLINK "mailto:shashidhara.veerabhadraiah at oracle.com"shashidhara.veerabhadraiah at oracle.com>
Cc: Sergey Bylokhov <HYPERLINK "mailto:sergey.bylokhov at oracle.com"sergey.bylokhov at oracle.com>; HYPERLINK "mailto:awt-dev at openjdk.java.net"awt-dev at openjdk.java.net; HYPERLINK "mailto:swing-dev at openjdk.java.net"swing-dev at openjdk.java.net
Subject: Re: <Swing Dev> [13] JDK-8216008: -Djavax.accessibility.assistive_technologies empty list leads to crash

?

That text may actually be worse.
Although I maybe didn't get your distinction of null vs the empty string here ?

Oh, wait. Why is this doc clarification on the PRIVATE implementation method ?
It needs to go on the public getDefaultToolkit() method to have any point whatsoever
especially from a CSR perspective.
Try this :
-???? * toolkit is created. All errors are handled via an AWTError exception.
+???? * toolkit is created.
+???? * If the list of assistive technology providers is the empty string, or
+???? * contains only white space characters then the method returns immediately.
+???? * All other errors are handled via an AWTError exception.


I think the CSR needs some work too. I've made some updates there.

-phil.

On 2/15/19 2:10 AM, Shashidhara Veerabhadraiah wrote:

Hi Phil, I have updated the CSR and updated the information for the function and here is the new Webrev:

?

HYPERLINK "http://cr.openjdk.java.net/%7Esveerabhadra/8216008/webrev.05/"http://cr.openjdk.java.net/~sveerabhadra/8216008/webrev.05/

Thanks and regards,

Shashi

?

From: Phil Race 
Sent: Friday, February 15, 2019 2:58 AM
To: Shashidhara Veerabhadraiah HYPERLINK "mailto:shashidhara.veerabhadraiah at oracle.com"<shashidhara.veerabhadraiah at oracle.com>
Cc: Sergey Bylokhov HYPERLINK "mailto:sergey.bylokhov at oracle.com"<sergey.bylokhov at oracle.com>; HYPERLINK "mailto:awt-dev at openjdk.java.net"awt-dev at openjdk.java.net; HYPERLINK "mailto:swing-dev at openjdk.java.net"swing-dev at openjdk.java.net
Subject: Re: <Swing Dev> [13] JDK-8216008: -Djavax.accessibility.assistive_technologies empty list leads to crash

?

+???? * activate method.? If the list of assistive technology providers is empty string,
?
is "the" empty string.
?
?
The CSR needs to be updated to include this spec. 
What is there now in the specification section needs to be fixed
It should not point to the webrev or review and right now
doesn't contain the change to the javadoc in the body of the CSR
?
I think I even have to question most of the rest of it.
Any one reading it would think that we always used to throw an exception in such
case and now want to stop doing so. Isn't the bug that we did NOT throw an exception
and now we do ? You only hint at that when you say at the end of "Solution", "as was the case earlier"
?
If I am right the only thing you need in the CSR is to say that you
are reverting the implementation to previous behaviour and updating the
specification to make it clear that this behaviour is allowed by the spec
since this case was unclear.
?
-phil.

?

On 2/12/19 1:08 AM, Shashidhara Veerabhadraiah wrote:

Hi Phil, Here is the new Webrev and CSR for the same:

HYPERLINK "http://cr.openjdk.java.net/%7Esveerabhadra/8216008/webrev.04/"http://cr.openjdk.java.net/~sveerabhadra/8216008/webrev.04/

?

CSR: https://bugs.openjdk.java.net/browse/JDK-8218737

?

Thanks and regards,

Shashi

?

From: Philip Race 
Sent: Saturday, February 9, 2019 2:18 AM
To: Shashidhara Veerabhadraiah HYPERLINK "mailto:shashidhara.veerabhadraiah at oracle.com"<shashidhara.veerabhadraiah at oracle.com>
Cc: Sergey Bylokhov HYPERLINK "mailto:sergey.bylokhov at oracle.com"<sergey.bylokhov at oracle.com>; HYPERLINK "mailto:awt-dev at openjdk.java.net"awt-dev at openjdk.java.net; HYPERLINK "mailto:swing-dev at openjdk.java.net"swing-dev at openjdk.java.net
Subject: Re: <Swing Dev> [13] JDK-8216008: -Djavax.accessibility.assistive_technologies empty list leads to crash

?

FWIW I think this could be closed out as "not a bug".
An empty value string is an error and the spec. says AWTError is
how errors are reported. In fact I'll argue that 8 was wrong not
to have thrown an exception in such a case.
It was an accident of the implementation that it did not.
But if we want to be behaviourally compatible then ... 
Note that since you now document this you need an approved CSR BEFORE pushing it.

And if you go the CSR route you may need to be more precise about what
you mean by "empty".

I think it needs to say

"If the list of assistive technology providers is null, or contains only white
space characters then the method returns immediately.
All other errors are handled by throwing {@code AWTError}"

@throws AWTError if there is any error in parsing or loading the ATs.

-phil.

On 1/21/19, 9:12 AM, Shashidhara Veerabhadraiah wrote: 

Hi Sergey, Here is the new Webrev for your comments:
?
HYPERLINK "http://cr.openjdk.java.net/%7Esveerabhadra/8216008/webrev.02/"http://cr.openjdk.java.net/~sveerabhadra/8216008/webrev.02/
?
Thanks and regards,
Shashi
?
-----Original Message-----
From: Sergey Bylokhov 
Sent: Saturday, January 19, 2019 3:47 AM
To: Shashidhara Veerabhadraiah HYPERLINK "mailto:shashidhara.veerabhadraiah at oracle.com"<shashidhara.veerabhadraiah at oracle.com>; HYPERLINK "mailto:awt-dev at openjdk.java.net"awt-dev at openjdk.java.net; HYPERLINK "mailto:swing-dev at openjdk.java.net"swing-dev at openjdk.java.net
Subject: Re: <Swing Dev> [13] JDK-8216008: -Djavax.accessibility.assistive_technologies empty list leads to crash
?
On 16/01/2019 23:03, HYPERLINK "mailto:shashidhara.veerabhadraiah at oracle.com"shashidhara.veerabhadraiah at oracle.com wrote:

Another point is that the whitespace trimming should not trigger additional input processing? for the custom class that will be used for assistive technology. For eg., if custom class "FooProvider" is implemented and if we pass "? FooProvider? " by mistake, a bug may be created to trim the whitespace in this case as well!!

?
Yes, my previous email suggested to always trim the content of the "input", it will cover all cases, the "atNames" is empty, the "atNames" contains only the whitespace, or the name of the class has some spaces at the start/end.
?

?
Thanks and regards,
?
Shashi
?
?
On 17/01/19 10:28 AM, Shashidhara Veerabhadraiah wrote:

We need one way to tell the system not to load any assistive technologies and which is being provided.
If we add trailing white spaces removal then we may need to add another functionality to see if that class exists or not and based on that not to load anything(without throwing the error because we are parsing the input content). I think that would take a different direction. I feel it is fair enough to provide one way to tell not to load any assistive technologies and additional parsing would only lead to other ways/expectations.
?
Thanks and regards,
Shashi
?
-----Original Message-----
From: Sergey Bylokhov
Sent: Thursday, January 17, 2019 1:33 AM
To: Shashidhara Veerabhadraiah HYPERLINK "mailto:shashidhara.veerabhadraiah at oracle.com"<shashidhara.veerabhadraiah at oracle.com>; HYPERLINK "mailto:awt-dev at openjdk.java.net"awt-dev at openjdk.java.net; HYPERLINK "mailto:swing-dev at openjdk.java.net"swing-dev at openjdk.java.net
Subject: Re: <Swing Dev> [13] JDK-8216008: -Djavax.accessibility.assistive_technologies empty list leads to crash
?
I guess you meant whitespaces, then it is unclear why we should not consider "empty" parameter as a "mistake"?
?
On 15/01/2019 20:37, Shashidhara Veerabhadraiah wrote:

Hi Sergey, I felt that a string with an empty space is intentional and should be considering it as a 'mistake' if done by the developers. Hence I feel it is not required(as there is a way to tell nothing to load). Please let me know if you think otherwise.

?
?

Thanks and regards,
Shashi
?
-----Original Message-----
From: Sergey Bylokhov
Sent: Tuesday, January 15, 2019 7:32 AM
To: Shashidhara Veerabhadraiah HYPERLINK "mailto:shashidhara.veerabhadraiah at oracle.com"<shashidhara.veerabhadraiah at oracle.com>; HYPERLINK "mailto:awt-dev at openjdk.java.net"awt-dev at openjdk.java.net; HYPERLINK "mailto:swing-dev at openjdk.java.net"swing-dev at openjdk.java.net
Subject: Re: <Swing Dev> [13] JDK-8216008: -Djavax.accessibility.assistive_technologies empty list leads to crash
?
Hi, Shashi.
?
Should we trim all whitespaces from the "atNames"?
Otherwise the "atNames", which contains only one whitespace, will trigger the same error.
?
On 09/01/2019 00:20, Shashidhara Veerabhadraiah wrote:

Hi Sergey, Thanks for pointing that out. Here is the new Webrev:
?
HYPERLINK "http://cr.openjdk.java.net/%7Esveerabhadra/8216008/webrev.01/"http://cr.openjdk.java.net/~sveerabhadra/8216008/webrev.01/
?
Thanks and regards,
Shashi
?
-----Original Message-----
From: Sergey Bylokhov
Sent: Friday, January 4, 2019 3:48 AM
To: Shashidhara Veerabhadraiah HYPERLINK "mailto:shashidhara.veerabhadraiah at oracle.com"<shashidhara.veerabhadraiah at oracle.com>; HYPERLINK "mailto:awt-dev at openjdk.java.net"awt-dev at openjdk.java.net; HYPERLINK "mailto:swing-dev at openjdk.java.net"swing-dev at openjdk.java.net
Subject: Re: <Swing Dev> [13] JDK-8216008: -Djavax.accessibility.assistive_technologies empty list leads to crash
?
Hi, Shashi.
I think you can update an existing test:
open/test/jdk/javax/accessibility/AccessibilityProvider/basic.sh
?
On 03/01/2019 01:36, Shashidhara Veerabhadraiah wrote:

Hi All, Please review a fix for the below bug.
?
Bug: https://bugs.openjdk.java.net/browse/JDK-8216008
?
Webrev: HYPERLINK "http://cr.openjdk.java.net/%7Esveerabhadra/8216008/webrev.00/"http://cr.openjdk.java.net/~sveerabhadra/8216008/webrev.00/
?
Since the mentioned list of assistive technologies for the system property(javax.accessibility.assistive_technologies) is loaded by jvm am unable to write a test case for this bug. The test file attached with the bug can be used for testing this fix.
?
This fix removes the error(class not found error) by passing an empty list to system variable javax.accessibility.assistive_technologies and does not load any assistive technologies(as the list is empty). Currently empty list produce a crash which is not required as there was no class name mentioned in the list. Please read the bug comments for more information.
?
Thanks and regards,
?
Shashi
?

?

?

?

?

?
?

?

?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/awt-dev/attachments/20190312/b726c224/attachment-0001.html>

From malenkov at gmail.com  Tue Mar 12 19:28:14 2019
From: malenkov at gmail.com (Sergey Malenkov)
Date: Tue, 12 Mar 2019 22:28:14 +0300
Subject: <AWT Dev> [13] JDK-8218917: KeyEvent.getModifiers() returns
 inconsistent values for ALT keys
In-Reply-To: <b842a817-1c61-7d23-a144-41bfc87013a3@oracle.com>
References: <990B3CDA-E3A0-4051-8771-1AD486094974@oracle.com>
 <CANTFZ2i30ao6fVuVxQseEzF38vBnLUfw3PPadYyKrUCrgfKo9g@mail.gmail.com>
 <6B001F8A-858F-4279-8F42-366F22D49B52@oracle.com>
 <CANTFZ2iUHFNSm9st3d3BLYvERa5OmpOzU+T5e1aoLq5C7YkMfQ@mail.gmail.com>
 <5C8673F6.8060306@oracle.com>
 <6d97202a-ad60-c768-4a31-66ca02f16f70@oracle.com>
 <5C86FF3C.7030700@oracle.com>
 <b842a817-1c61-7d23-a144-41bfc87013a3@oracle.com>
Message-ID: <CANTFZ2ikTVEP1OcrE415KhRbKr7Bv1XND-UW5tVPOW5+Ube7Jw@mail.gmail.com>

Hi Sergey,

1. macOS uses a regular Alt key as "Alternate Character Key". This is
the reason why JDK Toolkit defines Ctrl+Alt to select a mnemonic,
instead of simple Alt. See
https://sites.google.com/site/malenkov/java/141229

2. JDK also supports KEY LOCATION for such keys. Mentioned "Key Table
Usages" says nothing about AltGr.

3. Regression was caused by adding AltGr to key processing on Mac. But
I found more issues with inconsistent key processing on different
platforms. See http://sites.google.com/site/malenkov/java/190312


On Tue, Mar 12, 2019 at 4:17 AM Sergey Bylokhov
<Sergey.Bylokhov at oracle.com> wrote:
>
> On 11/03/2019 17:37, Philip Race wrote:
> > The debate is about AltGraph which an ancient MS-DOSism for
> > asking for an ALTernate GRAPHics bitmap font - all pre-dates windows
> > and I am sure has never been applicable to any MacOS.
>
> It also about the "right alt" which is also know as "AltGraph". I guess currently
> it is implemented as "right alt" on Linux/macOS/windows.
>
> BTW on linux it is also named as "Alternative Characters Key":
> https://help.ubuntu.com/community/ComposeKey
>
> > So someone needs to properly explain why we would claim a Mac keyboard
> > is OK to generate a keycode it doesn't have and cause a slew of regressions
> > in the process ...>
> > If Mac doesn't distinguish these two, we should generate the same keycode for both.
>
> The macOS supports "right alt", otherwise it would not be possible to implement it in java:
> https://developer.apple.com/library/archive/technotes/tn2450/_index.html
>
>
> > One could suppose there is a difference else why two keys, but what is the right
> > thing to do here  that fixes all the problems. What exactly WAS the problem
> > with what was there in the first place ? And if changing it is correct why is it
> > causing regressions ?
>
> Regressions were caused by the bugs in the fix implementation, or am I missed something?
>
>
> >
> > -phil.
> >
> >
> >
> > On 3/12/19, 5:34 AM, Sergey Bylokhov wrote:
> >> Hi, Phil.
> >> On 11/03/2019 07:43, Philip Race wrote:
> >>> The reasoning that AltGraph might be useful to someone is a bit weak
> >>> and I don't think I'd want to support it via system property or build options.
> >>>
> >>> If its not a platform keyboard key, why do we need it ?
> >>
> >> The "AltGraph" key is also commonly referred to as "Right Alt", and
> >> it has been implemented on all platforms as a "Right Alt", it is convenient to
> >> distinguish the left/right alts.
> >>
>
>
> --
> Best regards, Sergey.



-- 
Best regards,
Sergey A. Malenkov

From malenkov at gmail.com  Tue Mar 12 19:50:43 2019
From: malenkov at gmail.com (Sergey Malenkov)
Date: Tue, 12 Mar 2019 22:50:43 +0300
Subject: <AWT Dev> [13] JDK-8218917: KeyEvent.getModifiers() returns
 inconsistent values for ALT keys
In-Reply-To: <5C86FF3C.7030700@oracle.com>
References: <990B3CDA-E3A0-4051-8771-1AD486094974@oracle.com>
 <CANTFZ2i30ao6fVuVxQseEzF38vBnLUfw3PPadYyKrUCrgfKo9g@mail.gmail.com>
 <6B001F8A-858F-4279-8F42-366F22D49B52@oracle.com>
 <CANTFZ2iUHFNSm9st3d3BLYvERa5OmpOzU+T5e1aoLq5C7YkMfQ@mail.gmail.com>
 <5C8673F6.8060306@oracle.com>
 <6d97202a-ad60-c768-4a31-66ca02f16f70@oracle.com>
 <5C86FF3C.7030700@oracle.com>
Message-ID: <CANTFZ2i4jCjeQ_pWXQhVfXBjFkyV41Q9eugTNM77d7BPvGXEZQ@mail.gmail.com>

Hi Phil,

The AltGr is actively used with some locales to enter national
characters on Windows and Linux. Also it is used to enter some special
symbols. See http://en.wikipedia.org/wiki/AltGr_key

Someone may want to connect a classic keyboard to MacMini and
configure the right Alt key to behave like AltGr. But this key should
work as usual by default.

My change fixes other issues like processing both modifier keys with
the same key code and with different location at the same time. But it
is easy to modify it and remove AltGr supporting. For example,
http://cr.openjdk.java.net/~ant/JDK-8218917/webrev.0/

On Tue, Mar 12, 2019 at 3:37 AM Philip Race <philip.race at oracle.com> wrote:
>
> The debate is about AltGraph which an ancient MS-DOSism for
> asking for an ALTernate GRAPHics bitmap font - all pre-dates windows
> and I am sure has never been applicable to any MacOS.
>
> So someone needs to properly explain why we would claim a Mac keyboard
> is OK to generate a keycode it doesn't have and cause a slew of regressions
> in the process ...
>
> If Mac doesn't distinguish these two, we should generate the same
> keycode for both.
> One could suppose there is a difference else why two keys, but what is
> the right
> thing to do here  that fixes all the problems. What exactly WAS the problem
> with what was there in the first place ? And if changing it is correct
> why is it
> causing regressions ?
>
> -phil.
>
>
>
> On 3/12/19, 5:34 AM, Sergey Bylokhov wrote:
> > Hi, Phil.
> > On 11/03/2019 07:43, Philip Race wrote:
> >> The reasoning that AltGraph might be useful to someone is a bit weak
> >> and I don't think I'd want to support it via system property or build
> >> options.
> >>
> >> If its not a platform keyboard key, why do we need it ?
> >
> > The "AltGraph" key is also commonly referred to as "Right Alt", and
> > it has been implemented on all platforms as a "Right Alt", it is
> > convenient to
> > distinguish the left/right alts.
> >



-- 
Best regards,
Sergey A. Malenkov

From Sergey.Bylokhov at oracle.com  Wed Mar 13 03:57:49 2019
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Tue, 12 Mar 2019 20:57:49 -0700
Subject: <AWT Dev> [13] JDK-8218917: KeyEvent.getModifiers() returns
 inconsistent values for ALT keys
In-Reply-To: <CANTFZ2ikTVEP1OcrE415KhRbKr7Bv1XND-UW5tVPOW5+Ube7Jw@mail.gmail.com>
References: <990B3CDA-E3A0-4051-8771-1AD486094974@oracle.com>
 <CANTFZ2i30ao6fVuVxQseEzF38vBnLUfw3PPadYyKrUCrgfKo9g@mail.gmail.com>
 <6B001F8A-858F-4279-8F42-366F22D49B52@oracle.com>
 <CANTFZ2iUHFNSm9st3d3BLYvERa5OmpOzU+T5e1aoLq5C7YkMfQ@mail.gmail.com>
 <5C8673F6.8060306@oracle.com>
 <6d97202a-ad60-c768-4a31-66ca02f16f70@oracle.com>
 <5C86FF3C.7030700@oracle.com>
 <b842a817-1c61-7d23-a144-41bfc87013a3@oracle.com>
 <CANTFZ2ikTVEP1OcrE415KhRbKr7Bv1XND-UW5tVPOW5+Ube7Jw@mail.gmail.com>
Message-ID: <7dcf0e9b-cfc8-b985-f60c-10f7fe307825@oracle.com>

On 12/03/2019 12:28, Sergey Malenkov wrote:
> Hi Sergey,
> 
> 1. macOS uses a regular Alt key as "Alternate Character Key". This is
> the reason why JDK Toolkit defines Ctrl+Alt to select a mnemonic,
> instead of simple Alt. See
> https://sites.google.com/site/malenkov/java/141229

Right, but introducing this flag for the "left alt" could cause even more
issues, so this flag is set only for the right.

> 3. Regression was caused by adding AltGr to key processing on Mac. But
> I found more issues with inconsistent key processing on different
> platforms. See http://sites.google.com/site/malenkov/java/190312

Not sure that CAPS_LOCK is related.

> 
> 
> On Tue, Mar 12, 2019 at 4:17 AM Sergey Bylokhov
> <Sergey.Bylokhov at oracle.com> wrote:
>>
>> On 11/03/2019 17:37, Philip Race wrote:
>>> The debate is about AltGraph which an ancient MS-DOSism for
>>> asking for an ALTernate GRAPHics bitmap font - all pre-dates windows
>>> and I am sure has never been applicable to any MacOS.
>>
>> It also about the "right alt" which is also know as "AltGraph". I guess currently
>> it is implemented as "right alt" on Linux/macOS/windows.
>>
>> BTW on linux it is also named as "Alternative Characters Key":
>> https://help.ubuntu.com/community/ComposeKey
>>
>>> So someone needs to properly explain why we would claim a Mac keyboard
>>> is OK to generate a keycode it doesn't have and cause a slew of regressions
>>> in the process ...>
>>> If Mac doesn't distinguish these two, we should generate the same keycode for both.
>>
>> The macOS supports "right alt", otherwise it would not be possible to implement it in java:
>> https://developer.apple.com/library/archive/technotes/tn2450/_index.html
>>
>>
>>> One could suppose there is a difference else why two keys, but what is the right
>>> thing to do here  that fixes all the problems. What exactly WAS the problem
>>> with what was there in the first place ? And if changing it is correct why is it
>>> causing regressions ?
>>
>> Regressions were caused by the bugs in the fix implementation, or am I missed something?
>>
>>
>>>
>>> -phil.
>>>
>>>
>>>
>>> On 3/12/19, 5:34 AM, Sergey Bylokhov wrote:
>>>> Hi, Phil.
>>>> On 11/03/2019 07:43, Philip Race wrote:
>>>>> The reasoning that AltGraph might be useful to someone is a bit weak
>>>>> and I don't think I'd want to support it via system property or build options.
>>>>>
>>>>> If its not a platform keyboard key, why do we need it ?
>>>>
>>>> The "AltGraph" key is also commonly referred to as "Right Alt", and
>>>> it has been implemented on all platforms as a "Right Alt", it is convenient to
>>>> distinguish the left/right alts.
>>>>
>>
>>
>> --
>> Best regards, Sergey.
> 
> 
> 


-- 
Best regards, Sergey.

From malenkov at gmail.com  Wed Mar 13 10:59:01 2019
From: malenkov at gmail.com (Sergey Malenkov)
Date: Wed, 13 Mar 2019 13:59:01 +0300
Subject: <AWT Dev> [13] JDK-8218917: KeyEvent.getModifiers() returns
 inconsistent values for ALT keys
In-Reply-To: <7dcf0e9b-cfc8-b985-f60c-10f7fe307825@oracle.com>
References: <990B3CDA-E3A0-4051-8771-1AD486094974@oracle.com>
 <CANTFZ2i30ao6fVuVxQseEzF38vBnLUfw3PPadYyKrUCrgfKo9g@mail.gmail.com>
 <6B001F8A-858F-4279-8F42-366F22D49B52@oracle.com>
 <CANTFZ2iUHFNSm9st3d3BLYvERa5OmpOzU+T5e1aoLq5C7YkMfQ@mail.gmail.com>
 <5C8673F6.8060306@oracle.com>
 <6d97202a-ad60-c768-4a31-66ca02f16f70@oracle.com>
 <5C86FF3C.7030700@oracle.com>
 <b842a817-1c61-7d23-a144-41bfc87013a3@oracle.com>
 <CANTFZ2ikTVEP1OcrE415KhRbKr7Bv1XND-UW5tVPOW5+Ube7Jw@mail.gmail.com>
 <7dcf0e9b-cfc8-b985-f60c-10f7fe307825@oracle.com>
Message-ID: <CANTFZ2h2gc8abosQBJrSNA2tF6cwDQacjpfKp_y1znwkkAU+8w@mail.gmail.com>

Hi Sergey,

I do not want to use the left Alt key as AltGr. Actually, I think it
will be unexpected for Mac users that the right Alt key does not work
as Alt. Mac users don't need AltGr to enter extra characters, because
they use Alt for this purpose.

I missed the "for ALT keys" in the bug title and thought that
"KeyEvent.getModifiers() returns inconsistent values" was about
incompatible behaviour on different platforms. In fact, JDK-8218917
should be renamed to something like ?The right Alt key on Mac should
behave as Alt and must not break the left Alt key processing?.


On Wed, Mar 13, 2019 at 6:57 AM Sergey Bylokhov
<Sergey.Bylokhov at oracle.com> wrote:
>
> On 12/03/2019 12:28, Sergey Malenkov wrote:
> > Hi Sergey,
> >
> > 1. macOS uses a regular Alt key as "Alternate Character Key". This is
> > the reason why JDK Toolkit defines Ctrl+Alt to select a mnemonic,
> > instead of simple Alt. See
> > https://sites.google.com/site/malenkov/java/141229
>
> Right, but introducing this flag for the "left alt" could cause even more
> issues, so this flag is set only for the right.
>
> > 3. Regression was caused by adding AltGr to key processing on Mac. But
> > I found more issues with inconsistent key processing on different
> > platforms. See http://sites.google.com/site/malenkov/java/190312
>
> Not sure that CAPS_LOCK is related.
>
> >
> >
> > On Tue, Mar 12, 2019 at 4:17 AM Sergey Bylokhov
> > <Sergey.Bylokhov at oracle.com> wrote:
> >>
> >> On 11/03/2019 17:37, Philip Race wrote:
> >>> The debate is about AltGraph which an ancient MS-DOSism for
> >>> asking for an ALTernate GRAPHics bitmap font - all pre-dates windows
> >>> and I am sure has never been applicable to any MacOS.
> >>
> >> It also about the "right alt" which is also know as "AltGraph". I guess currently
> >> it is implemented as "right alt" on Linux/macOS/windows.
> >>
> >> BTW on linux it is also named as "Alternative Characters Key":
> >> https://help.ubuntu.com/community/ComposeKey
> >>
> >>> So someone needs to properly explain why we would claim a Mac keyboard
> >>> is OK to generate a keycode it doesn't have and cause a slew of regressions
> >>> in the process ...>
> >>> If Mac doesn't distinguish these two, we should generate the same keycode for both.
> >>
> >> The macOS supports "right alt", otherwise it would not be possible to implement it in java:
> >> https://developer.apple.com/library/archive/technotes/tn2450/_index.html
> >>
> >>
> >>> One could suppose there is a difference else why two keys, but what is the right
> >>> thing to do here  that fixes all the problems. What exactly WAS the problem
> >>> with what was there in the first place ? And if changing it is correct why is it
> >>> causing regressions ?
> >>
> >> Regressions were caused by the bugs in the fix implementation, or am I missed something?
> >>
> >>
> >>>
> >>> -phil.
> >>>
> >>>
> >>>
> >>> On 3/12/19, 5:34 AM, Sergey Bylokhov wrote:
> >>>> Hi, Phil.
> >>>> On 11/03/2019 07:43, Philip Race wrote:
> >>>>> The reasoning that AltGraph might be useful to someone is a bit weak
> >>>>> and I don't think I'd want to support it via system property or build options.
> >>>>>
> >>>>> If its not a platform keyboard key, why do we need it ?
> >>>>
> >>>> The "AltGraph" key is also commonly referred to as "Right Alt", and
> >>>> it has been implemented on all platforms as a "Right Alt", it is convenient to
> >>>> distinguish the left/right alts.
> >>>>
> >>
> >>
> >> --
> >> Best regards, Sergey.
> >
> >
> >
>
>
> --
> Best regards, Sergey.



-- 
Best regards,
Sergey A. Malenkov

From Sergey.Bylokhov at oracle.com  Wed Mar 13 21:09:42 2019
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Wed, 13 Mar 2019 14:09:42 -0700
Subject: <AWT Dev> [13] JDK-8218917: KeyEvent.getModifiers() returns
 inconsistent values for ALT keys
In-Reply-To: <CANTFZ2h2gc8abosQBJrSNA2tF6cwDQacjpfKp_y1znwkkAU+8w@mail.gmail.com>
References: <990B3CDA-E3A0-4051-8771-1AD486094974@oracle.com>
 <CANTFZ2i30ao6fVuVxQseEzF38vBnLUfw3PPadYyKrUCrgfKo9g@mail.gmail.com>
 <6B001F8A-858F-4279-8F42-366F22D49B52@oracle.com>
 <CANTFZ2iUHFNSm9st3d3BLYvERa5OmpOzU+T5e1aoLq5C7YkMfQ@mail.gmail.com>
 <5C8673F6.8060306@oracle.com>
 <6d97202a-ad60-c768-4a31-66ca02f16f70@oracle.com>
 <5C86FF3C.7030700@oracle.com>
 <b842a817-1c61-7d23-a144-41bfc87013a3@oracle.com>
 <CANTFZ2ikTVEP1OcrE415KhRbKr7Bv1XND-UW5tVPOW5+Ube7Jw@mail.gmail.com>
 <7dcf0e9b-cfc8-b985-f60c-10f7fe307825@oracle.com>
 <CANTFZ2h2gc8abosQBJrSNA2tF6cwDQacjpfKp_y1znwkkAU+8w@mail.gmail.com>
Message-ID: <0c65a2e9-d5b3-eaf0-44eb-2b969de64dac@oracle.com>

On 13/03/2019 03:59, Sergey Malenkov wrote:
> I missed the "for ALT keys" in the bug title and thought that
> "KeyEvent.getModifiers() returns inconsistent values" was about
> incompatible behaviour on different platforms. In fact, JDK-8218917
> should be renamed to something like ?The right Alt key on Mac should
> behave as Alt and must not break the left Alt key processing?.

But the "right Alt" should behave like a "left alt" already, it should use both flags:
the common alt(ALT_DOWN_MASK) and the altGr(ALT_GRAPH_DOWN_MASK).

So if the client will follow the spec below it should work as before, isn't it?:
https://docs.oracle.com/en/java/javase/11/docs/api/java.desktop/java/awt/event/InputEvent.html#getModifiersEx()

> On Wed, Mar 13, 2019 at 6:57 AM Sergey Bylokhov
> <Sergey.Bylokhov at oracle.com> wrote:
>>
>> On 12/03/2019 12:28, Sergey Malenkov wrote:
>>> Hi Sergey,
>>>
>>> 1. macOS uses a regular Alt key as "Alternate Character Key". This is
>>> the reason why JDK Toolkit defines Ctrl+Alt to select a mnemonic,
>>> instead of simple Alt. See
>>> https://sites.google.com/site/malenkov/java/141229
>>
>> Right, but introducing this flag for the "left alt" could cause even more
>> issues, so this flag is set only for the right.
>>
>>> 3. Regression was caused by adding AltGr to key processing on Mac. But
>>> I found more issues with inconsistent key processing on different
>>> platforms. See http://sites.google.com/site/malenkov/java/190312
>>
>> Not sure that CAPS_LOCK is related.
>>
>>>
>>>
>>> On Tue, Mar 12, 2019 at 4:17 AM Sergey Bylokhov
>>> <Sergey.Bylokhov at oracle.com> wrote:
>>>>
>>>> On 11/03/2019 17:37, Philip Race wrote:
>>>>> The debate is about AltGraph which an ancient MS-DOSism for
>>>>> asking for an ALTernate GRAPHics bitmap font - all pre-dates windows
>>>>> and I am sure has never been applicable to any MacOS.
>>>>
>>>> It also about the "right alt" which is also know as "AltGraph". I guess currently
>>>> it is implemented as "right alt" on Linux/macOS/windows.
>>>>
>>>> BTW on linux it is also named as "Alternative Characters Key":
>>>> https://help.ubuntu.com/community/ComposeKey
>>>>
>>>>> So someone needs to properly explain why we would claim a Mac keyboard
>>>>> is OK to generate a keycode it doesn't have and cause a slew of regressions
>>>>> in the process ...>
>>>>> If Mac doesn't distinguish these two, we should generate the same keycode for both.
>>>>
>>>> The macOS supports "right alt", otherwise it would not be possible to implement it in java:
>>>> https://developer.apple.com/library/archive/technotes/tn2450/_index.html
>>>>
>>>>
>>>>> One could suppose there is a difference else why two keys, but what is the right
>>>>> thing to do here  that fixes all the problems. What exactly WAS the problem
>>>>> with what was there in the first place ? And if changing it is correct why is it
>>>>> causing regressions ?
>>>>
>>>> Regressions were caused by the bugs in the fix implementation, or am I missed something?
>>>>
>>>>
>>>>>
>>>>> -phil.
>>>>>
>>>>>
>>>>>
>>>>> On 3/12/19, 5:34 AM, Sergey Bylokhov wrote:
>>>>>> Hi, Phil.
>>>>>> On 11/03/2019 07:43, Philip Race wrote:
>>>>>>> The reasoning that AltGraph might be useful to someone is a bit weak
>>>>>>> and I don't think I'd want to support it via system property or build options.
>>>>>>>
>>>>>>> If its not a platform keyboard key, why do we need it ?
>>>>>>
>>>>>> The "AltGraph" key is also commonly referred to as "Right Alt", and
>>>>>> it has been implemented on all platforms as a "Right Alt", it is convenient to
>>>>>> distinguish the left/right alts.
>>>>>>
>>>>
>>>>
>>>> --
>>>> Best regards, Sergey.
>>>
>>>
>>>
>>
>>
>> --
>> Best regards, Sergey.
> 
> 
> 


-- 
Best regards, Sergey.

From malenkov at gmail.com  Thu Mar 14 10:33:22 2019
From: malenkov at gmail.com (Sergey Malenkov)
Date: Thu, 14 Mar 2019 13:33:22 +0300
Subject: <AWT Dev> [13] JDK-8218917: KeyEvent.getModifiers() returns
 inconsistent values for ALT keys
In-Reply-To: <0c65a2e9-d5b3-eaf0-44eb-2b969de64dac@oracle.com>
References: <990B3CDA-E3A0-4051-8771-1AD486094974@oracle.com>
 <CANTFZ2i30ao6fVuVxQseEzF38vBnLUfw3PPadYyKrUCrgfKo9g@mail.gmail.com>
 <6B001F8A-858F-4279-8F42-366F22D49B52@oracle.com>
 <CANTFZ2iUHFNSm9st3d3BLYvERa5OmpOzU+T5e1aoLq5C7YkMfQ@mail.gmail.com>
 <5C8673F6.8060306@oracle.com>
 <6d97202a-ad60-c768-4a31-66ca02f16f70@oracle.com>
 <5C86FF3C.7030700@oracle.com>
 <b842a817-1c61-7d23-a144-41bfc87013a3@oracle.com>
 <CANTFZ2ikTVEP1OcrE415KhRbKr7Bv1XND-UW5tVPOW5+Ube7Jw@mail.gmail.com>
 <7dcf0e9b-cfc8-b985-f60c-10f7fe307825@oracle.com>
 <CANTFZ2h2gc8abosQBJrSNA2tF6cwDQacjpfKp_y1znwkkAU+8w@mail.gmail.com>
 <0c65a2e9-d5b3-eaf0-44eb-2b969de64dac@oracle.com>
Message-ID: <CANTFZ2gY=h5AyLTu8KPkwyL1_4TvY6jLf9_aqTGBwa0kf5mRdQ@mail.gmail.com>

I strongly don't like two masks for one key. If you press VK_ALT,
ALT_DOWN_MASK should be set. If you press VK_SHIFT then,
SHIFT_DOWN_MASK should be added to indicate that both keys are
pressed. And if you press VK_ALT_GRAPH, only ALT_GRAPH_DOWN_MASK
should be added. Otherwise, you can't distinguish the following key
strokes: 'AltGr+Right' and 'Alt+AltGr+Right'. But these keystrokes are
different and should invoke different actions. For example,
'Alt+Right' moves cursor to the next word
'Alt+Shift+Right' moves cursor to the next word AND adds all skipped
characters to selection
'Alt+AltGr+Right' does nothing, because we do not assign this shortcut yet

On Thu, Mar 14, 2019 at 12:09 AM Sergey Bylokhov
<Sergey.Bylokhov at oracle.com> wrote:
>
> On 13/03/2019 03:59, Sergey Malenkov wrote:
> > I missed the "for ALT keys" in the bug title and thought that
> > "KeyEvent.getModifiers() returns inconsistent values" was about
> > incompatible behaviour on different platforms. In fact, JDK-8218917
> > should be renamed to something like ?The right Alt key on Mac should
> > behave as Alt and must not break the left Alt key processing?.
>
> But the "right Alt" should behave like a "left alt" already, it should use both flags:
> the common alt(ALT_DOWN_MASK) and the altGr(ALT_GRAPH_DOWN_MASK).
>
> So if the client will follow the spec below it should work as before, isn't it?:
> https://docs.oracle.com/en/java/javase/11/docs/api/java.desktop/java/awt/event/InputEvent.html#getModifiersEx()
>
> > On Wed, Mar 13, 2019 at 6:57 AM Sergey Bylokhov
> > <Sergey.Bylokhov at oracle.com> wrote:
> >>
> >> On 12/03/2019 12:28, Sergey Malenkov wrote:
> >>> Hi Sergey,
> >>>
> >>> 1. macOS uses a regular Alt key as "Alternate Character Key". This is
> >>> the reason why JDK Toolkit defines Ctrl+Alt to select a mnemonic,
> >>> instead of simple Alt. See
> >>> https://sites.google.com/site/malenkov/java/141229
> >>
> >> Right, but introducing this flag for the "left alt" could cause even more
> >> issues, so this flag is set only for the right.
> >>
> >>> 3. Regression was caused by adding AltGr to key processing on Mac. But
> >>> I found more issues with inconsistent key processing on different
> >>> platforms. See http://sites.google.com/site/malenkov/java/190312
> >>
> >> Not sure that CAPS_LOCK is related.
> >>
> >>>
> >>>
> >>> On Tue, Mar 12, 2019 at 4:17 AM Sergey Bylokhov
> >>> <Sergey.Bylokhov at oracle.com> wrote:
> >>>>
> >>>> On 11/03/2019 17:37, Philip Race wrote:
> >>>>> The debate is about AltGraph which an ancient MS-DOSism for
> >>>>> asking for an ALTernate GRAPHics bitmap font - all pre-dates windows
> >>>>> and I am sure has never been applicable to any MacOS.
> >>>>
> >>>> It also about the "right alt" which is also know as "AltGraph". I guess currently
> >>>> it is implemented as "right alt" on Linux/macOS/windows.
> >>>>
> >>>> BTW on linux it is also named as "Alternative Characters Key":
> >>>> https://help.ubuntu.com/community/ComposeKey
> >>>>
> >>>>> So someone needs to properly explain why we would claim a Mac keyboard
> >>>>> is OK to generate a keycode it doesn't have and cause a slew of regressions
> >>>>> in the process ...>
> >>>>> If Mac doesn't distinguish these two, we should generate the same keycode for both.
> >>>>
> >>>> The macOS supports "right alt", otherwise it would not be possible to implement it in java:
> >>>> https://developer.apple.com/library/archive/technotes/tn2450/_index.html
> >>>>
> >>>>
> >>>>> One could suppose there is a difference else why two keys, but what is the right
> >>>>> thing to do here  that fixes all the problems. What exactly WAS the problem
> >>>>> with what was there in the first place ? And if changing it is correct why is it
> >>>>> causing regressions ?
> >>>>
> >>>> Regressions were caused by the bugs in the fix implementation, or am I missed something?
> >>>>
> >>>>
> >>>>>
> >>>>> -phil.
> >>>>>
> >>>>>
> >>>>>
> >>>>> On 3/12/19, 5:34 AM, Sergey Bylokhov wrote:
> >>>>>> Hi, Phil.
> >>>>>> On 11/03/2019 07:43, Philip Race wrote:
> >>>>>>> The reasoning that AltGraph might be useful to someone is a bit weak
> >>>>>>> and I don't think I'd want to support it via system property or build options.
> >>>>>>>
> >>>>>>> If its not a platform keyboard key, why do we need it ?
> >>>>>>
> >>>>>> The "AltGraph" key is also commonly referred to as "Right Alt", and
> >>>>>> it has been implemented on all platforms as a "Right Alt", it is convenient to
> >>>>>> distinguish the left/right alts.
> >>>>>>
> >>>>
> >>>>
> >>>> --
> >>>> Best regards, Sergey.
> >>>
> >>>
> >>>
> >>
> >>
> >> --
> >> Best regards, Sergey.
> >
> >
> >
>
>
> --
> Best regards, Sergey.



-- 
Best regards,
Sergey A. Malenkov

From Sergey.Bylokhov at oracle.com  Thu Mar 14 23:07:38 2019
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Thu, 14 Mar 2019 16:07:38 -0700
Subject: <AWT Dev> [13] JDK-8218917: KeyEvent.getModifiers() returns
 inconsistent values for ALT keys
In-Reply-To: <CANTFZ2gY=h5AyLTu8KPkwyL1_4TvY6jLf9_aqTGBwa0kf5mRdQ@mail.gmail.com>
References: <990B3CDA-E3A0-4051-8771-1AD486094974@oracle.com>
 <CANTFZ2i30ao6fVuVxQseEzF38vBnLUfw3PPadYyKrUCrgfKo9g@mail.gmail.com>
 <6B001F8A-858F-4279-8F42-366F22D49B52@oracle.com>
 <CANTFZ2iUHFNSm9st3d3BLYvERa5OmpOzU+T5e1aoLq5C7YkMfQ@mail.gmail.com>
 <5C8673F6.8060306@oracle.com>
 <6d97202a-ad60-c768-4a31-66ca02f16f70@oracle.com>
 <5C86FF3C.7030700@oracle.com>
 <b842a817-1c61-7d23-a144-41bfc87013a3@oracle.com>
 <CANTFZ2ikTVEP1OcrE415KhRbKr7Bv1XND-UW5tVPOW5+Ube7Jw@mail.gmail.com>
 <7dcf0e9b-cfc8-b985-f60c-10f7fe307825@oracle.com>
 <CANTFZ2h2gc8abosQBJrSNA2tF6cwDQacjpfKp_y1znwkkAU+8w@mail.gmail.com>
 <0c65a2e9-d5b3-eaf0-44eb-2b969de64dac@oracle.com>
 <CANTFZ2gY=h5AyLTu8KPkwyL1_4TvY6jLf9_aqTGBwa0kf5mRdQ@mail.gmail.com>
Message-ID: <b59673ed-5564-58a8-c110-978ddf3d63c4@oracle.com>

On 14/03/2019 03:33, Sergey Malenkov wrote:
> I strongly don't like two masks for one key. If you press VK_ALT,
> ALT_DOWN_MASK should be set. If you press VK_SHIFT then,
> SHIFT_DOWN_MASK should be added to indicate that both keys are
> pressed. And if you press VK_ALT_GRAPH, only ALT_GRAPH_DOWN_MASK
> should be added. Otherwise, you can't distinguish the following key
> strokes: 'AltGr+Right' and 'Alt+AltGr+Right'. But these keystrokes are
> different and should invoke different actions. For example,
> 'Alt+Right' moves cursor to the next word
> 'Alt+Shift+Right' moves cursor to the next word AND adds all skipped
> characters to selection
> 'Alt+AltGr+Right' does nothing, because we do not assign this shortcut yet

Unfortunately it is not possible to drop ALT_DOWN_MASK(to support 'Alt+AltGr+Right')
from the "right alt", it should work as alt for compatibility reasons, it is known that some
applications depends on it. The current implementation is the only way
that we could do to distinguish the alt and altGr, that preserves
compatibility and confirms the specification.


-- 
Best regards, Sergey.

From krishna.addepalli at oracle.com  Fri Mar 15 06:27:13 2019
From: krishna.addepalli at oracle.com (Krishna Addepalli)
Date: Fri, 15 Mar 2019 11:57:13 +0530
Subject: <AWT Dev> [13] JDK-8218917: KeyEvent.getModifiers() returns
 inconsistent values for ALT keys
In-Reply-To: <CANTFZ2gY=h5AyLTu8KPkwyL1_4TvY6jLf9_aqTGBwa0kf5mRdQ@mail.gmail.com>
References: <990B3CDA-E3A0-4051-8771-1AD486094974@oracle.com>
 <CANTFZ2i30ao6fVuVxQseEzF38vBnLUfw3PPadYyKrUCrgfKo9g@mail.gmail.com>
 <6B001F8A-858F-4279-8F42-366F22D49B52@oracle.com>
 <CANTFZ2iUHFNSm9st3d3BLYvERa5OmpOzU+T5e1aoLq5C7YkMfQ@mail.gmail.com>
 <5C8673F6.8060306@oracle.com>
 <6d97202a-ad60-c768-4a31-66ca02f16f70@oracle.com>
 <5C86FF3C.7030700@oracle.com>
 <b842a817-1c61-7d23-a144-41bfc87013a3@oracle.com>
 <CANTFZ2ikTVEP1OcrE415KhRbKr7Bv1XND-UW5tVPOW5+Ube7Jw@mail.gmail.com>
 <7dcf0e9b-cfc8-b985-f60c-10f7fe307825@oracle.com>
 <CANTFZ2h2gc8abosQBJrSNA2tF6cwDQacjpfKp_y1znwkkAU+8w@mail.gmail.com>
 <0c65a2e9-d5b3-eaf0-44eb-2b969de64dac@oracle.com>
 <CANTFZ2gY=h5AyLTu8KPkwyL1_4TvY6jLf9_aqTGBwa0kf5mRdQ@mail.gmail.com>
Message-ID: <5956470F-019E-40E7-AE6D-9BB9F4E95F19@oracle.com>

Hi Sergey Malenkov,

> 'Alt+AltGr+Right' does nothing, because we do not assign this shortcut yet
In my personal experience, I did not find any instance, wherein a shortcut had left and right alt in it.
Although it is not impossible, it seems weird to define such shortcuts.
It would be helpful if you could point to some resources, wherein defining such shortcuts is acceptable.

Thanks,
Krishna

> On 14-Mar-2019, at 4:03 PM, Sergey Malenkov <malenkov at gmail.com> wrote:
> 
> I strongly don't like two masks for one key. If you press VK_ALT,
> ALT_DOWN_MASK should be set. If you press VK_SHIFT then,
> SHIFT_DOWN_MASK should be added to indicate that both keys are
> pressed. And if you press VK_ALT_GRAPH, only ALT_GRAPH_DOWN_MASK
> should be added. Otherwise, you can't distinguish the following key
> strokes: 'AltGr+Right' and 'Alt+AltGr+Right'. But these keystrokes are
> different and should invoke different actions. For example,
> 'Alt+Right' moves cursor to the next word
> 'Alt+Shift+Right' moves cursor to the next word AND adds all skipped
> characters to selection
> 'Alt+AltGr+Right' does nothing, because we do not assign this shortcut yet
> 
> On Thu, Mar 14, 2019 at 12:09 AM Sergey Bylokhov
> <Sergey.Bylokhov at oracle.com> wrote:
>> 
>> On 13/03/2019 03:59, Sergey Malenkov wrote:
>>> I missed the "for ALT keys" in the bug title and thought that
>>> "KeyEvent.getModifiers() returns inconsistent values" was about
>>> incompatible behaviour on different platforms. In fact, JDK-8218917
>>> should be renamed to something like ?The right Alt key on Mac should
>>> behave as Alt and must not break the left Alt key processing?.
>> 
>> But the "right Alt" should behave like a "left alt" already, it should use both flags:
>> the common alt(ALT_DOWN_MASK) and the altGr(ALT_GRAPH_DOWN_MASK).
>> 
>> So if the client will follow the spec below it should work as before, isn't it?:
>> https://docs.oracle.com/en/java/javase/11/docs/api/java.desktop/java/awt/event/InputEvent.html#getModifiersEx()
>> 
>>> On Wed, Mar 13, 2019 at 6:57 AM Sergey Bylokhov
>>> <Sergey.Bylokhov at oracle.com> wrote:
>>>> 
>>>> On 12/03/2019 12:28, Sergey Malenkov wrote:
>>>>> Hi Sergey,
>>>>> 
>>>>> 1. macOS uses a regular Alt key as "Alternate Character Key". This is
>>>>> the reason why JDK Toolkit defines Ctrl+Alt to select a mnemonic,
>>>>> instead of simple Alt. See
>>>>> https://sites.google.com/site/malenkov/java/141229
>>>> 
>>>> Right, but introducing this flag for the "left alt" could cause even more
>>>> issues, so this flag is set only for the right.
>>>> 
>>>>> 3. Regression was caused by adding AltGr to key processing on Mac. But
>>>>> I found more issues with inconsistent key processing on different
>>>>> platforms. See http://sites.google.com/site/malenkov/java/190312
>>>> 
>>>> Not sure that CAPS_LOCK is related.
>>>> 
>>>>> 
>>>>> 
>>>>> On Tue, Mar 12, 2019 at 4:17 AM Sergey Bylokhov
>>>>> <Sergey.Bylokhov at oracle.com> wrote:
>>>>>> 
>>>>>> On 11/03/2019 17:37, Philip Race wrote:
>>>>>>> The debate is about AltGraph which an ancient MS-DOSism for
>>>>>>> asking for an ALTernate GRAPHics bitmap font - all pre-dates windows
>>>>>>> and I am sure has never been applicable to any MacOS.
>>>>>> 
>>>>>> It also about the "right alt" which is also know as "AltGraph". I guess currently
>>>>>> it is implemented as "right alt" on Linux/macOS/windows.
>>>>>> 
>>>>>> BTW on linux it is also named as "Alternative Characters Key":
>>>>>> https://help.ubuntu.com/community/ComposeKey
>>>>>> 
>>>>>>> So someone needs to properly explain why we would claim a Mac keyboard
>>>>>>> is OK to generate a keycode it doesn't have and cause a slew of regressions
>>>>>>> in the process ...>
>>>>>>> If Mac doesn't distinguish these two, we should generate the same keycode for both.
>>>>>> 
>>>>>> The macOS supports "right alt", otherwise it would not be possible to implement it in java:
>>>>>> https://developer.apple.com/library/archive/technotes/tn2450/_index.html
>>>>>> 
>>>>>> 
>>>>>>> One could suppose there is a difference else why two keys, but what is the right
>>>>>>> thing to do here  that fixes all the problems. What exactly WAS the problem
>>>>>>> with what was there in the first place ? And if changing it is correct why is it
>>>>>>> causing regressions ?
>>>>>> 
>>>>>> Regressions were caused by the bugs in the fix implementation, or am I missed something?
>>>>>> 
>>>>>> 
>>>>>>> 
>>>>>>> -phil.
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> On 3/12/19, 5:34 AM, Sergey Bylokhov wrote:
>>>>>>>> Hi, Phil.
>>>>>>>> On 11/03/2019 07:43, Philip Race wrote:
>>>>>>>>> The reasoning that AltGraph might be useful to someone is a bit weak
>>>>>>>>> and I don't think I'd want to support it via system property or build options.
>>>>>>>>> 
>>>>>>>>> If its not a platform keyboard key, why do we need it ?
>>>>>>>> 
>>>>>>>> The "AltGraph" key is also commonly referred to as "Right Alt", and
>>>>>>>> it has been implemented on all platforms as a "Right Alt", it is convenient to
>>>>>>>> distinguish the left/right alts.
>>>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> --
>>>>>> Best regards, Sergey.
>>>>> 
>>>>> 
>>>>> 
>>>> 
>>>> 
>>>> --
>>>> Best regards, Sergey.
>>> 
>>> 
>>> 
>> 
>> 
>> --
>> Best regards, Sergey.
> 
> 
> 
> -- 
> Best regards,
> Sergey A. Malenkov


From malenkov at gmail.com  Fri Mar 15 12:54:47 2019
From: malenkov at gmail.com (Sergey Malenkov)
Date: Fri, 15 Mar 2019 15:54:47 +0300
Subject: <AWT Dev> [13] JDK-8218917: KeyEvent.getModifiers() returns
 inconsistent values for ALT keys
In-Reply-To: <5956470F-019E-40E7-AE6D-9BB9F4E95F19@oracle.com>
References: <990B3CDA-E3A0-4051-8771-1AD486094974@oracle.com>
 <CANTFZ2i30ao6fVuVxQseEzF38vBnLUfw3PPadYyKrUCrgfKo9g@mail.gmail.com>
 <6B001F8A-858F-4279-8F42-366F22D49B52@oracle.com>
 <CANTFZ2iUHFNSm9st3d3BLYvERa5OmpOzU+T5e1aoLq5C7YkMfQ@mail.gmail.com>
 <5C8673F6.8060306@oracle.com>
 <6d97202a-ad60-c768-4a31-66ca02f16f70@oracle.com>
 <5C86FF3C.7030700@oracle.com>
 <b842a817-1c61-7d23-a144-41bfc87013a3@oracle.com>
 <CANTFZ2ikTVEP1OcrE415KhRbKr7Bv1XND-UW5tVPOW5+Ube7Jw@mail.gmail.com>
 <7dcf0e9b-cfc8-b985-f60c-10f7fe307825@oracle.com>
 <CANTFZ2h2gc8abosQBJrSNA2tF6cwDQacjpfKp_y1znwkkAU+8w@mail.gmail.com>
 <0c65a2e9-d5b3-eaf0-44eb-2b969de64dac@oracle.com>
 <CANTFZ2gY=h5AyLTu8KPkwyL1_4TvY6jLf9_aqTGBwa0kf5mRdQ@mail.gmail.com>
 <5956470F-019E-40E7-AE6D-9BB9F4E95F19@oracle.com>
Message-ID: <CANTFZ2jUNuwSfEaRVMSCjVhJ50i9aWYi5V_fZE5aRvVConz3Sw@mail.gmail.com>

Hi guys,

We have a major issue about unexpected AltGr in the keyboard layout
that should not have AltGr at all:
http://youtrack.jetbrains.com/issue/IDEA-206348
Why you decided to support AltGr for every keyboard layout? It really
breaks backward compatibility!

> Unfortunately it is not possible to drop ALT_DOWN_MASK(to support 'Alt+AltGr+Right')
from the "right alt", it should work as alt for compatibility reasons,
it is known that some
applications depends on it."

I think the main client is Swing and pressed AltGr that looks like
'Alt+AltGr+' breaks all Alt-based shortcuts defined in
javax.swing.plaf.basic.BasicLookAndFeel#initComponentDefaults and
other places. Now, if you press "alt LEFT", the "moveColumnLeft"
action is performed only for the left Alt. And this also breaks a
backward compatibility.

It is not backward compatible to use AltGr instead of right Alt in
both cases. Instead of 'Alt+key' you will get 'AltGr+key' or
'Alt+AltGr+key', which are not bound to any action.

On Fri, Mar 15, 2019 at 9:27 AM Krishna Addepalli
<krishna.addepalli at oracle.com> wrote:
>
> Hi Sergey Malenkov,
>
> > 'Alt+AltGr+Right' does nothing, because we do not assign this shortcut yet
> In my personal experience, I did not find any instance, wherein a shortcut had left and right alt in it.
> Although it is not impossible, it seems weird to define such shortcuts.
> It would be helpful if you could point to some resources, wherein defining such shortcuts is acceptable.
>
> Thanks,
> Krishna
>
> > On 14-Mar-2019, at 4:03 PM, Sergey Malenkov <malenkov at gmail.com> wrote:
> >
> > I strongly don't like two masks for one key. If you press VK_ALT,
> > ALT_DOWN_MASK should be set. If you press VK_SHIFT then,
> > SHIFT_DOWN_MASK should be added to indicate that both keys are
> > pressed. And if you press VK_ALT_GRAPH, only ALT_GRAPH_DOWN_MASK
> > should be added. Otherwise, you can't distinguish the following key
> > strokes: 'AltGr+Right' and 'Alt+AltGr+Right'. But these keystrokes are
> > different and should invoke different actions. For example,
> > 'Alt+Right' moves cursor to the next word
> > 'Alt+Shift+Right' moves cursor to the next word AND adds all skipped
> > characters to selection
> > 'Alt+AltGr+Right' does nothing, because we do not assign this shortcut yet
> >
> > On Thu, Mar 14, 2019 at 12:09 AM Sergey Bylokhov
> > <Sergey.Bylokhov at oracle.com> wrote:
> >>
> >> On 13/03/2019 03:59, Sergey Malenkov wrote:
> >>> I missed the "for ALT keys" in the bug title and thought that
> >>> "KeyEvent.getModifiers() returns inconsistent values" was about
> >>> incompatible behaviour on different platforms. In fact, JDK-8218917
> >>> should be renamed to something like ?The right Alt key on Mac should
> >>> behave as Alt and must not break the left Alt key processing?.
> >>
> >> But the "right Alt" should behave like a "left alt" already, it should use both flags:
> >> the common alt(ALT_DOWN_MASK) and the altGr(ALT_GRAPH_DOWN_MASK).
> >>
> >> So if the client will follow the spec below it should work as before, isn't it?:
> >> https://docs.oracle.com/en/java/javase/11/docs/api/java.desktop/java/awt/event/InputEvent.html#getModifiersEx()
> >>
> >>> On Wed, Mar 13, 2019 at 6:57 AM Sergey Bylokhov
> >>> <Sergey.Bylokhov at oracle.com> wrote:
> >>>>
> >>>> On 12/03/2019 12:28, Sergey Malenkov wrote:
> >>>>> Hi Sergey,
> >>>>>
> >>>>> 1. macOS uses a regular Alt key as "Alternate Character Key". This is
> >>>>> the reason why JDK Toolkit defines Ctrl+Alt to select a mnemonic,
> >>>>> instead of simple Alt. See
> >>>>> https://sites.google.com/site/malenkov/java/141229
> >>>>
> >>>> Right, but introducing this flag for the "left alt" could cause even more
> >>>> issues, so this flag is set only for the right.
> >>>>
> >>>>> 3. Regression was caused by adding AltGr to key processing on Mac. But
> >>>>> I found more issues with inconsistent key processing on different
> >>>>> platforms. See http://sites.google.com/site/malenkov/java/190312
> >>>>
> >>>> Not sure that CAPS_LOCK is related.
> >>>>
> >>>>>
> >>>>>
> >>>>> On Tue, Mar 12, 2019 at 4:17 AM Sergey Bylokhov
> >>>>> <Sergey.Bylokhov at oracle.com> wrote:
> >>>>>>
> >>>>>> On 11/03/2019 17:37, Philip Race wrote:
> >>>>>>> The debate is about AltGraph which an ancient MS-DOSism for
> >>>>>>> asking for an ALTernate GRAPHics bitmap font - all pre-dates windows
> >>>>>>> and I am sure has never been applicable to any MacOS.
> >>>>>>
> >>>>>> It also about the "right alt" which is also know as "AltGraph". I guess currently
> >>>>>> it is implemented as "right alt" on Linux/macOS/windows.
> >>>>>>
> >>>>>> BTW on linux it is also named as "Alternative Characters Key":
> >>>>>> https://help.ubuntu.com/community/ComposeKey
> >>>>>>
> >>>>>>> So someone needs to properly explain why we would claim a Mac keyboard
> >>>>>>> is OK to generate a keycode it doesn't have and cause a slew of regressions
> >>>>>>> in the process ...>
> >>>>>>> If Mac doesn't distinguish these two, we should generate the same keycode for both.
> >>>>>>
> >>>>>> The macOS supports "right alt", otherwise it would not be possible to implement it in java:
> >>>>>> https://developer.apple.com/library/archive/technotes/tn2450/_index.html
> >>>>>>
> >>>>>>
> >>>>>>> One could suppose there is a difference else why two keys, but what is the right
> >>>>>>> thing to do here  that fixes all the problems. What exactly WAS the problem
> >>>>>>> with what was there in the first place ? And if changing it is correct why is it
> >>>>>>> causing regressions ?
> >>>>>>
> >>>>>> Regressions were caused by the bugs in the fix implementation, or am I missed something?
> >>>>>>
> >>>>>>
> >>>>>>>
> >>>>>>> -phil.
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>> On 3/12/19, 5:34 AM, Sergey Bylokhov wrote:
> >>>>>>>> Hi, Phil.
> >>>>>>>> On 11/03/2019 07:43, Philip Race wrote:
> >>>>>>>>> The reasoning that AltGraph might be useful to someone is a bit weak
> >>>>>>>>> and I don't think I'd want to support it via system property or build options.
> >>>>>>>>>
> >>>>>>>>> If its not a platform keyboard key, why do we need it ?
> >>>>>>>>
> >>>>>>>> The "AltGraph" key is also commonly referred to as "Right Alt", and
> >>>>>>>> it has been implemented on all platforms as a "Right Alt", it is convenient to
> >>>>>>>> distinguish the left/right alts.
> >>>>>>>>
> >>>>>>
> >>>>>>
> >>>>>> --
> >>>>>> Best regards, Sergey.
> >>>>>
> >>>>>
> >>>>>
> >>>>
> >>>>
> >>>> --
> >>>> Best regards, Sergey.
> >>>
> >>>
> >>>
> >>
> >>
> >> --
> >> Best regards, Sergey.
> >
> >
> >
> > --
> > Best regards,
> > Sergey A. Malenkov
>


-- 
Best regards,
Sergey A. Malenkov

From Sergey.Bylokhov at oracle.com  Fri Mar 15 22:30:32 2019
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Fri, 15 Mar 2019 15:30:32 -0700
Subject: <AWT Dev> [13] JDK-8218917: KeyEvent.getModifiers() returns
 inconsistent values for ALT keys
In-Reply-To: <CANTFZ2jUNuwSfEaRVMSCjVhJ50i9aWYi5V_fZE5aRvVConz3Sw@mail.gmail.com>
References: <990B3CDA-E3A0-4051-8771-1AD486094974@oracle.com>
 <CANTFZ2i30ao6fVuVxQseEzF38vBnLUfw3PPadYyKrUCrgfKo9g@mail.gmail.com>
 <6B001F8A-858F-4279-8F42-366F22D49B52@oracle.com>
 <CANTFZ2iUHFNSm9st3d3BLYvERa5OmpOzU+T5e1aoLq5C7YkMfQ@mail.gmail.com>
 <5C8673F6.8060306@oracle.com>
 <6d97202a-ad60-c768-4a31-66ca02f16f70@oracle.com>
 <5C86FF3C.7030700@oracle.com>
 <b842a817-1c61-7d23-a144-41bfc87013a3@oracle.com>
 <CANTFZ2ikTVEP1OcrE415KhRbKr7Bv1XND-UW5tVPOW5+Ube7Jw@mail.gmail.com>
 <7dcf0e9b-cfc8-b985-f60c-10f7fe307825@oracle.com>
 <CANTFZ2h2gc8abosQBJrSNA2tF6cwDQacjpfKp_y1znwkkAU+8w@mail.gmail.com>
 <0c65a2e9-d5b3-eaf0-44eb-2b969de64dac@oracle.com>
 <CANTFZ2gY=h5AyLTu8KPkwyL1_4TvY6jLf9_aqTGBwa0kf5mRdQ@mail.gmail.com>
 <5956470F-019E-40E7-AE6D-9BB9F4E95F19@oracle.com>
 <CANTFZ2jUNuwSfEaRVMSCjVhJ50i9aWYi5V_fZE5aRvVConz3Sw@mail.gmail.com>
Message-ID: <b8901169-5a6e-cd3d-56d7-d3d2578ff29a@oracle.com>

On 15/03/2019 05:54, Sergey Malenkov wrote:
> We have a major issue about unexpected AltGr in the keyboard layout
> that should not have AltGr at all:
> http://youtrack.jetbrains.com/issue/IDEA-206348
> Why you decided to support AltGr for every keyboard layout? It really
> breaks backward compatibility!

Even in your bug report the people complain that altGr key does not work, and
the only problem here is that it does not assigned by default.
But on the other side it is possible to set separate shortcuts
to the "Alt + Alt Graph + Enter"and "Alt + Enter":

> I think the main client is Swing and pressed AltGr that looks like
> 'Alt+AltGr+' breaks all Alt-based shortcuts defined in
> javax.swing.plaf.basic.BasicLookAndFeel#initComponentDefaults and
> other places. Now, if you press "alt LEFT", the "moveColumnLeft"
> action is performed only for the left Alt. And this also breaks a
> backward compatibility.

The term "all" is not so critical, there are only few such shortcuts, and it is
a good thing that potentially we can set different shortcuts for each.
This is a bug that these places were not updated, it is easy to fix since this
is not exposed via public API.
But we will get the same result if we will use the AltGr mask only.

> It is not backward compatible to use AltGr instead of right Alt in
> both cases. Instead of 'Alt+key' you will get 'AltGr+key' or
> 'Alt+AltGr+key', which are not bound to any action.

It is compatible to the specification of InputEvent.getModifiersEx():
KeyEvent event = new KeyEvent(new Button(), 0, 0,
                               ALT_DOWN_MASK | ALT_GRAPH_DOWN_MASK, 0);
   int onmask =  ALT_DOWN_MASK;
   int offmask = CTRL_DOWN_MASK|SHIFT_DOWN_MASK;
   if ((event.getModifiersEx() & (onmask | offmask)) == onmask) {
     ...
   }

The code above works before and after the change for altGr.
But it will stop working if we will use altGr only, and it will be hard to argue
why the ALT flag is not set while alt key is pressed(since on some keyboards this key is
marked as alt and on some other altGr).

And as specially noted in the method above the code should not assume which
flags(and how many) were set by the actions, if such assumptions exists in
Swing itself they should be fixed as well.

> 
> On Fri, Mar 15, 2019 at 9:27 AM Krishna Addepalli
> <krishna.addepalli at oracle.com> wrote:
>>
>> Hi Sergey Malenkov,
>>
>>> 'Alt+AltGr+Right' does nothing, because we do not assign this shortcut yet
>> In my personal experience, I did not find any instance, wherein a shortcut had left and right alt in it.
>> Although it is not impossible, it seems weird to define such shortcuts.
>> It would be helpful if you could point to some resources, wherein defining such shortcuts is acceptable.
>>
>> Thanks,
>> Krishna
>>
>>> On 14-Mar-2019, at 4:03 PM, Sergey Malenkov <malenkov at gmail.com> wrote:
>>>
>>> I strongly don't like two masks for one key. If you press VK_ALT,
>>> ALT_DOWN_MASK should be set. If you press VK_SHIFT then,
>>> SHIFT_DOWN_MASK should be added to indicate that both keys are
>>> pressed. And if you press VK_ALT_GRAPH, only ALT_GRAPH_DOWN_MASK
>>> should be added. Otherwise, you can't distinguish the following key
>>> strokes: 'AltGr+Right' and 'Alt+AltGr+Right'. But these keystrokes are
>>> different and should invoke different actions. For example,
>>> 'Alt+Right' moves cursor to the next word
>>> 'Alt+Shift+Right' moves cursor to the next word AND adds all skipped
>>> characters to selection
>>> 'Alt+AltGr+Right' does nothing, because we do not assign this shortcut yet
>>>
>>> On Thu, Mar 14, 2019 at 12:09 AM Sergey Bylokhov
>>> <Sergey.Bylokhov at oracle.com> wrote:
>>>>
>>>> On 13/03/2019 03:59, Sergey Malenkov wrote:
>>>>> I missed the "for ALT keys" in the bug title and thought that
>>>>> "KeyEvent.getModifiers() returns inconsistent values" was about
>>>>> incompatible behaviour on different platforms. In fact, JDK-8218917
>>>>> should be renamed to something like ?The right Alt key on Mac should
>>>>> behave as Alt and must not break the left Alt key processing?.
>>>>
>>>> But the "right Alt" should behave like a "left alt" already, it should use both flags:
>>>> the common alt(ALT_DOWN_MASK) and the altGr(ALT_GRAPH_DOWN_MASK).
>>>>
>>>> So if the client will follow the spec below it should work as before, isn't it?:
>>>> https://docs.oracle.com/en/java/javase/11/docs/api/java.desktop/java/awt/event/InputEvent.html#getModifiersEx()
>>>>
>>>>> On Wed, Mar 13, 2019 at 6:57 AM Sergey Bylokhov
>>>>> <Sergey.Bylokhov at oracle.com> wrote:
>>>>>>
>>>>>> On 12/03/2019 12:28, Sergey Malenkov wrote:
>>>>>>> Hi Sergey,
>>>>>>>
>>>>>>> 1. macOS uses a regular Alt key as "Alternate Character Key". This is
>>>>>>> the reason why JDK Toolkit defines Ctrl+Alt to select a mnemonic,
>>>>>>> instead of simple Alt. See
>>>>>>> https://sites.google.com/site/malenkov/java/141229
>>>>>>
>>>>>> Right, but introducing this flag for the "left alt" could cause even more
>>>>>> issues, so this flag is set only for the right.
>>>>>>
>>>>>>> 3. Regression was caused by adding AltGr to key processing on Mac. But
>>>>>>> I found more issues with inconsistent key processing on different
>>>>>>> platforms. See http://sites.google.com/site/malenkov/java/190312
>>>>>>
>>>>>> Not sure that CAPS_LOCK is related.
>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On Tue, Mar 12, 2019 at 4:17 AM Sergey Bylokhov
>>>>>>> <Sergey.Bylokhov at oracle.com> wrote:
>>>>>>>>
>>>>>>>> On 11/03/2019 17:37, Philip Race wrote:
>>>>>>>>> The debate is about AltGraph which an ancient MS-DOSism for
>>>>>>>>> asking for an ALTernate GRAPHics bitmap font - all pre-dates windows
>>>>>>>>> and I am sure has never been applicable to any MacOS.
>>>>>>>>
>>>>>>>> It also about the "right alt" which is also know as "AltGraph". I guess currently
>>>>>>>> it is implemented as "right alt" on Linux/macOS/windows.
>>>>>>>>
>>>>>>>> BTW on linux it is also named as "Alternative Characters Key":
>>>>>>>> https://help.ubuntu.com/community/ComposeKey
>>>>>>>>
>>>>>>>>> So someone needs to properly explain why we would claim a Mac keyboard
>>>>>>>>> is OK to generate a keycode it doesn't have and cause a slew of regressions
>>>>>>>>> in the process ...>
>>>>>>>>> If Mac doesn't distinguish these two, we should generate the same keycode for both.
>>>>>>>>
>>>>>>>> The macOS supports "right alt", otherwise it would not be possible to implement it in java:
>>>>>>>> https://developer.apple.com/library/archive/technotes/tn2450/_index.html
>>>>>>>>
>>>>>>>>
>>>>>>>>> One could suppose there is a difference else why two keys, but what is the right
>>>>>>>>> thing to do here  that fixes all the problems. What exactly WAS the problem
>>>>>>>>> with what was there in the first place ? And if changing it is correct why is it
>>>>>>>>> causing regressions ?
>>>>>>>>
>>>>>>>> Regressions were caused by the bugs in the fix implementation, or am I missed something?
>>>>>>>>
>>>>>>>>
>>>>>>>>>
>>>>>>>>> -phil.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On 3/12/19, 5:34 AM, Sergey Bylokhov wrote:
>>>>>>>>>> Hi, Phil.
>>>>>>>>>> On 11/03/2019 07:43, Philip Race wrote:
>>>>>>>>>>> The reasoning that AltGraph might be useful to someone is a bit weak
>>>>>>>>>>> and I don't think I'd want to support it via system property or build options.
>>>>>>>>>>>
>>>>>>>>>>> If its not a platform keyboard key, why do we need it ?
>>>>>>>>>>
>>>>>>>>>> The "AltGraph" key is also commonly referred to as "Right Alt", and
>>>>>>>>>> it has been implemented on all platforms as a "Right Alt", it is convenient to
>>>>>>>>>> distinguish the left/right alts.
>>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>> Best regards, Sergey.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Best regards, Sergey.
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>> Best regards, Sergey.
>>>
>>>
>>>
>>> --
>>> Best regards,
>>> Sergey A. Malenkov
>>
> 
> 


-- 
Best regards, Sergey.

From malenkov at gmail.com  Sat Mar 16 10:58:09 2019
From: malenkov at gmail.com (Sergey Malenkov)
Date: Sat, 16 Mar 2019 13:58:09 +0300
Subject: <AWT Dev> [13] JDK-8218917: KeyEvent.getModifiers() returns
 inconsistent values for ALT keys
In-Reply-To: <b8901169-5a6e-cd3d-56d7-d3d2578ff29a@oracle.com>
References: <990B3CDA-E3A0-4051-8771-1AD486094974@oracle.com>
 <CANTFZ2i30ao6fVuVxQseEzF38vBnLUfw3PPadYyKrUCrgfKo9g@mail.gmail.com>
 <6B001F8A-858F-4279-8F42-366F22D49B52@oracle.com>
 <CANTFZ2iUHFNSm9st3d3BLYvERa5OmpOzU+T5e1aoLq5C7YkMfQ@mail.gmail.com>
 <5C8673F6.8060306@oracle.com>
 <6d97202a-ad60-c768-4a31-66ca02f16f70@oracle.com>
 <5C86FF3C.7030700@oracle.com>
 <b842a817-1c61-7d23-a144-41bfc87013a3@oracle.com>
 <CANTFZ2ikTVEP1OcrE415KhRbKr7Bv1XND-UW5tVPOW5+Ube7Jw@mail.gmail.com>
 <7dcf0e9b-cfc8-b985-f60c-10f7fe307825@oracle.com>
 <CANTFZ2h2gc8abosQBJrSNA2tF6cwDQacjpfKp_y1znwkkAU+8w@mail.gmail.com>
 <0c65a2e9-d5b3-eaf0-44eb-2b969de64dac@oracle.com>
 <CANTFZ2gY=h5AyLTu8KPkwyL1_4TvY6jLf9_aqTGBwa0kf5mRdQ@mail.gmail.com>
 <5956470F-019E-40E7-AE6D-9BB9F4E95F19@oracle.com>
 <CANTFZ2jUNuwSfEaRVMSCjVhJ50i9aWYi5V_fZE5aRvVConz3Sw@mail.gmail.com>
 <b8901169-5a6e-cd3d-56d7-d3d2578ff29a@oracle.com>
Message-ID: <CANTFZ2hUFGyAVuYPxH8ubvpbWypHD4Q2G+oRZKS+Gw=j-H3sdw@mail.gmail.com>

Hi Sergey,

Your example is synthetic and shows a problem in the one specific
case. I think if you introduce new mask, you have to use it in your
example too. If you add ALT_GRAPH_DOWN_MASK to 'offmask' your example
will not work (that's how processed all shortcuts in Swing and IDEA).
If you add it to 'onmask' the KeyEvent(new Button(), 0, 0,
ALT_GRAPH_DOWN_MASK, 0) will not work.

Am I right that to support your specific case you have to find and fix
all Alt-based shortcuts in Swing, we should fix all Alt-based
shortcuts in all keymaps in our IDEs and we should notify all our
users that they have to fix all Alt-based shortcuts in their custom
keymaps? The brilliant example of backward compatibility!

> So if the client will follow the spec below it should work as before, isn't it?:
> https://docs.oracle.com/en/java/javase/11/docs/api/java.desktop/java/awt/event/InputEvent.html#getModifiersEx()

If a developer use this method as described his code will be broken
too, because good and attentive developer definitely added
ALT_GRAPH_DOWN_MASK to 'offmask'.

On Sat, Mar 16, 2019 at 1:27 AM Sergey Bylokhov
<Sergey.Bylokhov at oracle.com> wrote:
>
> On 15/03/2019 05:54, Sergey Malenkov wrote:
> > We have a major issue about unexpected AltGr in the keyboard layout
> > that should not have AltGr at all:
> > http://youtrack.jetbrains.com/issue/IDEA-206348
> > Why you decided to support AltGr for every keyboard layout? It really
> > breaks backward compatibility!
>
> Even in your bug report the people complain that altGr key does not work, and
> the only problem here is that it does not assigned by default.
> But on the other side it is possible to set separate shortcuts
> to the "Alt + Alt Graph + Enter"and "Alt + Enter":
>
> > I think the main client is Swing and pressed AltGr that looks like
> > 'Alt+AltGr+' breaks all Alt-based shortcuts defined in
> > javax.swing.plaf.basic.BasicLookAndFeel#initComponentDefaults and
> > other places. Now, if you press "alt LEFT", the "moveColumnLeft"
> > action is performed only for the left Alt. And this also breaks a
> > backward compatibility.
>
> The term "all" is not so critical, there are only few such shortcuts, and it is
> a good thing that potentially we can set different shortcuts for each.
> This is a bug that these places were not updated, it is easy to fix since this
> is not exposed via public API.
> But we will get the same result if we will use the AltGr mask only.
>
> > It is not backward compatible to use AltGr instead of right Alt in
> > both cases. Instead of 'Alt+key' you will get 'AltGr+key' or
> > 'Alt+AltGr+key', which are not bound to any action.
>
> It is compatible to the specification of InputEvent.getModifiersEx():
> KeyEvent event = new KeyEvent(new Button(), 0, 0,
>                                ALT_DOWN_MASK | ALT_GRAPH_DOWN_MASK, 0);
>    int onmask =  ALT_DOWN_MASK;
>    int offmask = CTRL_DOWN_MASK|SHIFT_DOWN_MASK;
>    if ((event.getModifiersEx() & (onmask | offmask)) == onmask) {
>      ...
>    }
>
> The code above works before and after the change for altGr.
> But it will stop working if we will use altGr only, and it will be hard to argue
> why the ALT flag is not set while alt key is pressed(since on some keyboards this key is
> marked as alt and on some other altGr).
>
> And as specially noted in the method above the code should not assume which
> flags(and how many) were set by the actions, if such assumptions exists in
> Swing itself they should be fixed as well.
>
> >
> > On Fri, Mar 15, 2019 at 9:27 AM Krishna Addepalli
> > <krishna.addepalli at oracle.com> wrote:
> >>
> >> Hi Sergey Malenkov,
> >>
> >>> 'Alt+AltGr+Right' does nothing, because we do not assign this shortcut yet
> >> In my personal experience, I did not find any instance, wherein a shortcut had left and right alt in it.
> >> Although it is not impossible, it seems weird to define such shortcuts.
> >> It would be helpful if you could point to some resources, wherein defining such shortcuts is acceptable.
> >>
> >> Thanks,
> >> Krishna
> >>
> >>> On 14-Mar-2019, at 4:03 PM, Sergey Malenkov <malenkov at gmail.com> wrote:
> >>>
> >>> I strongly don't like two masks for one key. If you press VK_ALT,
> >>> ALT_DOWN_MASK should be set. If you press VK_SHIFT then,
> >>> SHIFT_DOWN_MASK should be added to indicate that both keys are
> >>> pressed. And if you press VK_ALT_GRAPH, only ALT_GRAPH_DOWN_MASK
> >>> should be added. Otherwise, you can't distinguish the following key
> >>> strokes: 'AltGr+Right' and 'Alt+AltGr+Right'. But these keystrokes are
> >>> different and should invoke different actions. For example,
> >>> 'Alt+Right' moves cursor to the next word
> >>> 'Alt+Shift+Right' moves cursor to the next word AND adds all skipped
> >>> characters to selection
> >>> 'Alt+AltGr+Right' does nothing, because we do not assign this shortcut yet
> >>>
> >>> On Thu, Mar 14, 2019 at 12:09 AM Sergey Bylokhov
> >>> <Sergey.Bylokhov at oracle.com> wrote:
> >>>>
> >>>> On 13/03/2019 03:59, Sergey Malenkov wrote:
> >>>>> I missed the "for ALT keys" in the bug title and thought that
> >>>>> "KeyEvent.getModifiers() returns inconsistent values" was about
> >>>>> incompatible behaviour on different platforms. In fact, JDK-8218917
> >>>>> should be renamed to something like ?The right Alt key on Mac should
> >>>>> behave as Alt and must not break the left Alt key processing?.
> >>>>
> >>>> But the "right Alt" should behave like a "left alt" already, it should use both flags:
> >>>> the common alt(ALT_DOWN_MASK) and the altGr(ALT_GRAPH_DOWN_MASK).
> >>>>
> >>>> So if the client will follow the spec below it should work as before, isn't it?:
> >>>> https://docs.oracle.com/en/java/javase/11/docs/api/java.desktop/java/awt/event/InputEvent.html#getModifiersEx()
> >>>>
> >>>>> On Wed, Mar 13, 2019 at 6:57 AM Sergey Bylokhov
> >>>>> <Sergey.Bylokhov at oracle.com> wrote:
> >>>>>>
> >>>>>> On 12/03/2019 12:28, Sergey Malenkov wrote:
> >>>>>>> Hi Sergey,
> >>>>>>>
> >>>>>>> 1. macOS uses a regular Alt key as "Alternate Character Key". This is
> >>>>>>> the reason why JDK Toolkit defines Ctrl+Alt to select a mnemonic,
> >>>>>>> instead of simple Alt. See
> >>>>>>> https://sites.google.com/site/malenkov/java/141229
> >>>>>>
> >>>>>> Right, but introducing this flag for the "left alt" could cause even more
> >>>>>> issues, so this flag is set only for the right.
> >>>>>>
> >>>>>>> 3. Regression was caused by adding AltGr to key processing on Mac. But
> >>>>>>> I found more issues with inconsistent key processing on different
> >>>>>>> platforms. See http://sites.google.com/site/malenkov/java/190312
> >>>>>>
> >>>>>> Not sure that CAPS_LOCK is related.
> >>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>> On Tue, Mar 12, 2019 at 4:17 AM Sergey Bylokhov
> >>>>>>> <Sergey.Bylokhov at oracle.com> wrote:
> >>>>>>>>
> >>>>>>>> On 11/03/2019 17:37, Philip Race wrote:
> >>>>>>>>> The debate is about AltGraph which an ancient MS-DOSism for
> >>>>>>>>> asking for an ALTernate GRAPHics bitmap font - all pre-dates windows
> >>>>>>>>> and I am sure has never been applicable to any MacOS.
> >>>>>>>>
> >>>>>>>> It also about the "right alt" which is also know as "AltGraph". I guess currently
> >>>>>>>> it is implemented as "right alt" on Linux/macOS/windows.
> >>>>>>>>
> >>>>>>>> BTW on linux it is also named as "Alternative Characters Key":
> >>>>>>>> https://help.ubuntu.com/community/ComposeKey
> >>>>>>>>
> >>>>>>>>> So someone needs to properly explain why we would claim a Mac keyboard
> >>>>>>>>> is OK to generate a keycode it doesn't have and cause a slew of regressions
> >>>>>>>>> in the process ...>
> >>>>>>>>> If Mac doesn't distinguish these two, we should generate the same keycode for both.
> >>>>>>>>
> >>>>>>>> The macOS supports "right alt", otherwise it would not be possible to implement it in java:
> >>>>>>>> https://developer.apple.com/library/archive/technotes/tn2450/_index.html
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>> One could suppose there is a difference else why two keys, but what is the right
> >>>>>>>>> thing to do here  that fixes all the problems. What exactly WAS the problem
> >>>>>>>>> with what was there in the first place ? And if changing it is correct why is it
> >>>>>>>>> causing regressions ?
> >>>>>>>>
> >>>>>>>> Regressions were caused by the bugs in the fix implementation, or am I missed something?
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>>
> >>>>>>>>> -phil.
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> On 3/12/19, 5:34 AM, Sergey Bylokhov wrote:
> >>>>>>>>>> Hi, Phil.
> >>>>>>>>>> On 11/03/2019 07:43, Philip Race wrote:
> >>>>>>>>>>> The reasoning that AltGraph might be useful to someone is a bit weak
> >>>>>>>>>>> and I don't think I'd want to support it via system property or build options.
> >>>>>>>>>>>
> >>>>>>>>>>> If its not a platform keyboard key, why do we need it ?
> >>>>>>>>>>
> >>>>>>>>>> The "AltGraph" key is also commonly referred to as "Right Alt", and
> >>>>>>>>>> it has been implemented on all platforms as a "Right Alt", it is convenient to
> >>>>>>>>>> distinguish the left/right alts.
> >>>>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> --
> >>>>>>>> Best regards, Sergey.
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>
> >>>>>>
> >>>>>> --
> >>>>>> Best regards, Sergey.
> >>>>>
> >>>>>
> >>>>>
> >>>>
> >>>>
> >>>> --
> >>>> Best regards, Sergey.
> >>>
> >>>
> >>>
> >>> --
> >>> Best regards,
> >>> Sergey A. Malenkov
> >>
> >
> >
>
>
> --
> Best regards, Sergey.



-- 
Best regards,
Sergey A. Malenkov

From Sergey.Bylokhov at oracle.com  Sat Mar 16 22:26:50 2019
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Sat, 16 Mar 2019 15:26:50 -0700
Subject: <AWT Dev> [13] JDK-8218917: KeyEvent.getModifiers() returns
 inconsistent values for ALT keys
In-Reply-To: <CANTFZ2hUFGyAVuYPxH8ubvpbWypHD4Q2G+oRZKS+Gw=j-H3sdw@mail.gmail.com>
References: <990B3CDA-E3A0-4051-8771-1AD486094974@oracle.com>
 <CANTFZ2i30ao6fVuVxQseEzF38vBnLUfw3PPadYyKrUCrgfKo9g@mail.gmail.com>
 <6B001F8A-858F-4279-8F42-366F22D49B52@oracle.com>
 <CANTFZ2iUHFNSm9st3d3BLYvERa5OmpOzU+T5e1aoLq5C7YkMfQ@mail.gmail.com>
 <5C8673F6.8060306@oracle.com>
 <6d97202a-ad60-c768-4a31-66ca02f16f70@oracle.com>
 <5C86FF3C.7030700@oracle.com>
 <b842a817-1c61-7d23-a144-41bfc87013a3@oracle.com>
 <CANTFZ2ikTVEP1OcrE415KhRbKr7Bv1XND-UW5tVPOW5+Ube7Jw@mail.gmail.com>
 <7dcf0e9b-cfc8-b985-f60c-10f7fe307825@oracle.com>
 <CANTFZ2h2gc8abosQBJrSNA2tF6cwDQacjpfKp_y1znwkkAU+8w@mail.gmail.com>
 <0c65a2e9-d5b3-eaf0-44eb-2b969de64dac@oracle.com>
 <CANTFZ2gY=h5AyLTu8KPkwyL1_4TvY6jLf9_aqTGBwa0kf5mRdQ@mail.gmail.com>
 <5956470F-019E-40E7-AE6D-9BB9F4E95F19@oracle.com>
 <CANTFZ2jUNuwSfEaRVMSCjVhJ50i9aWYi5V_fZE5aRvVConz3Sw@mail.gmail.com>
 <b8901169-5a6e-cd3d-56d7-d3d2578ff29a@oracle.com>
 <CANTFZ2hUFGyAVuYPxH8ubvpbWypHD4Q2G+oRZKS+Gw=j-H3sdw@mail.gmail.com>
Message-ID: <6d9a95d4-4ceb-c596-ce8f-6dccbd21dd6e@oracle.com>

On 16/03/2019 03:58, Sergey Malenkov wrote:
> Your example is synthetic and shows a problem in the one specific
> case. I think if you introduce new mask, you have to use it in your
> example too. If you add ALT_GRAPH_DOWN_MASK to 'offmask' your example
> will not work (that's how processed all shortcuts in Swing and IDEA).
> If you add it to 'onmask' the KeyEvent(new Button(), 0, 0,
> ALT_GRAPH_DOWN_MASK, 0) will not work.

Your example is good as well, but it shows the opposite, if
ALT_GRAPH_DOWN_MASK was used as "onmask" or as "offmask" then it means
that this example tries to take care about altGr and it only
properly works after the fix. And if the code is unaware about the altGr
flag as in previous example it will be ignored.

> Am I right that to support your specific case you have to find and fix
> all Alt-based shortcuts in Swing, we should fix all Alt-based
> shortcuts in all keymaps in our IDEs and we should notify all our
> users that they have to fix all Alt-based shortcuts in their custom
> keymaps? The brilliant example of backward compatibility!

I do not remember all changes which were integrated since initially it was done
~4 years ago. But Swing was updated by some changes after that, for example:
https://bugs.openjdk.java.net/browse/JDK-8194873

> 
>> So if the client will follow the spec below it should work as before, isn't it?:
>> https://docs.oracle.com/en/java/javase/11/docs/api/java.desktop/java/awt/event/InputEvent.html#getModifiersEx()
> 
> If a developer use this method as described his code will be broken
> too, because good and attentive developer definitely added
> ALT_GRAPH_DOWN_MASK to 'offmask'.

If the user wants to ignore all combinations with "Alternate Character Key"
then, as you pointed in the start of this thread, he should ignore both
"alt" since on macOS both alt keys are "Alternate Character Key".

> 
> On Sat, Mar 16, 2019 at 1:27 AM Sergey Bylokhov
> <Sergey.Bylokhov at oracle.com> wrote:
>>
>> On 15/03/2019 05:54, Sergey Malenkov wrote:
>>> We have a major issue about unexpected AltGr in the keyboard layout
>>> that should not have AltGr at all:
>>> http://youtrack.jetbrains.com/issue/IDEA-206348
>>> Why you decided to support AltGr for every keyboard layout? It really
>>> breaks backward compatibility!
>>
>> Even in your bug report the people complain that altGr key does not work, and
>> the only problem here is that it does not assigned by default.
>> But on the other side it is possible to set separate shortcuts
>> to the "Alt + Alt Graph + Enter"and "Alt + Enter":
>>
>>> I think the main client is Swing and pressed AltGr that looks like
>>> 'Alt+AltGr+' breaks all Alt-based shortcuts defined in
>>> javax.swing.plaf.basic.BasicLookAndFeel#initComponentDefaults and
>>> other places. Now, if you press "alt LEFT", the "moveColumnLeft"
>>> action is performed only for the left Alt. And this also breaks a
>>> backward compatibility.
>>
>> The term "all" is not so critical, there are only few such shortcuts, and it is
>> a good thing that potentially we can set different shortcuts for each.
>> This is a bug that these places were not updated, it is easy to fix since this
>> is not exposed via public API.
>> But we will get the same result if we will use the AltGr mask only.
>>
>>> It is not backward compatible to use AltGr instead of right Alt in
>>> both cases. Instead of 'Alt+key' you will get 'AltGr+key' or
>>> 'Alt+AltGr+key', which are not bound to any action.
>>
>> It is compatible to the specification of InputEvent.getModifiersEx():
>> KeyEvent event = new KeyEvent(new Button(), 0, 0,
>>                                 ALT_DOWN_MASK | ALT_GRAPH_DOWN_MASK, 0);
>>     int onmask =  ALT_DOWN_MASK;
>>     int offmask = CTRL_DOWN_MASK|SHIFT_DOWN_MASK;
>>     if ((event.getModifiersEx() & (onmask | offmask)) == onmask) {
>>       ...
>>     }
>>
>> The code above works before and after the change for altGr.
>> But it will stop working if we will use altGr only, and it will be hard to argue
>> why the ALT flag is not set while alt key is pressed(since on some keyboards this key is
>> marked as alt and on some other altGr).
>>
>> And as specially noted in the method above the code should not assume which
>> flags(and how many) were set by the actions, if such assumptions exists in
>> Swing itself they should be fixed as well.
>>
>>>
>>> On Fri, Mar 15, 2019 at 9:27 AM Krishna Addepalli
>>> <krishna.addepalli at oracle.com> wrote:
>>>>
>>>> Hi Sergey Malenkov,
>>>>
>>>>> 'Alt+AltGr+Right' does nothing, because we do not assign this shortcut yet
>>>> In my personal experience, I did not find any instance, wherein a shortcut had left and right alt in it.
>>>> Although it is not impossible, it seems weird to define such shortcuts.
>>>> It would be helpful if you could point to some resources, wherein defining such shortcuts is acceptable.
>>>>
>>>> Thanks,
>>>> Krishna
>>>>
>>>>> On 14-Mar-2019, at 4:03 PM, Sergey Malenkov <malenkov at gmail.com> wrote:
>>>>>
>>>>> I strongly don't like two masks for one key. If you press VK_ALT,
>>>>> ALT_DOWN_MASK should be set. If you press VK_SHIFT then,
>>>>> SHIFT_DOWN_MASK should be added to indicate that both keys are
>>>>> pressed. And if you press VK_ALT_GRAPH, only ALT_GRAPH_DOWN_MASK
>>>>> should be added. Otherwise, you can't distinguish the following key
>>>>> strokes: 'AltGr+Right' and 'Alt+AltGr+Right'. But these keystrokes are
>>>>> different and should invoke different actions. For example,
>>>>> 'Alt+Right' moves cursor to the next word
>>>>> 'Alt+Shift+Right' moves cursor to the next word AND adds all skipped
>>>>> characters to selection
>>>>> 'Alt+AltGr+Right' does nothing, because we do not assign this shortcut yet
>>>>>
>>>>> On Thu, Mar 14, 2019 at 12:09 AM Sergey Bylokhov
>>>>> <Sergey.Bylokhov at oracle.com> wrote:
>>>>>>
>>>>>> On 13/03/2019 03:59, Sergey Malenkov wrote:
>>>>>>> I missed the "for ALT keys" in the bug title and thought that
>>>>>>> "KeyEvent.getModifiers() returns inconsistent values" was about
>>>>>>> incompatible behaviour on different platforms. In fact, JDK-8218917
>>>>>>> should be renamed to something like ?The right Alt key on Mac should
>>>>>>> behave as Alt and must not break the left Alt key processing?.
>>>>>>
>>>>>> But the "right Alt" should behave like a "left alt" already, it should use both flags:
>>>>>> the common alt(ALT_DOWN_MASK) and the altGr(ALT_GRAPH_DOWN_MASK).
>>>>>>
>>>>>> So if the client will follow the spec below it should work as before, isn't it?:
>>>>>> https://docs.oracle.com/en/java/javase/11/docs/api/java.desktop/java/awt/event/InputEvent.html#getModifiersEx()
>>>>>>
>>>>>>> On Wed, Mar 13, 2019 at 6:57 AM Sergey Bylokhov
>>>>>>> <Sergey.Bylokhov at oracle.com> wrote:
>>>>>>>>
>>>>>>>> On 12/03/2019 12:28, Sergey Malenkov wrote:
>>>>>>>>> Hi Sergey,
>>>>>>>>>
>>>>>>>>> 1. macOS uses a regular Alt key as "Alternate Character Key". This is
>>>>>>>>> the reason why JDK Toolkit defines Ctrl+Alt to select a mnemonic,
>>>>>>>>> instead of simple Alt. See
>>>>>>>>> https://sites.google.com/site/malenkov/java/141229
>>>>>>>>
>>>>>>>> Right, but introducing this flag for the "left alt" could cause even more
>>>>>>>> issues, so this flag is set only for the right.
>>>>>>>>
>>>>>>>>> 3. Regression was caused by adding AltGr to key processing on Mac. But
>>>>>>>>> I found more issues with inconsistent key processing on different
>>>>>>>>> platforms. See http://sites.google.com/site/malenkov/java/190312
>>>>>>>>
>>>>>>>> Not sure that CAPS_LOCK is related.
>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On Tue, Mar 12, 2019 at 4:17 AM Sergey Bylokhov
>>>>>>>>> <Sergey.Bylokhov at oracle.com> wrote:
>>>>>>>>>>
>>>>>>>>>> On 11/03/2019 17:37, Philip Race wrote:
>>>>>>>>>>> The debate is about AltGraph which an ancient MS-DOSism for
>>>>>>>>>>> asking for an ALTernate GRAPHics bitmap font - all pre-dates windows
>>>>>>>>>>> and I am sure has never been applicable to any MacOS.
>>>>>>>>>>
>>>>>>>>>> It also about the "right alt" which is also know as "AltGraph". I guess currently
>>>>>>>>>> it is implemented as "right alt" on Linux/macOS/windows.
>>>>>>>>>>
>>>>>>>>>> BTW on linux it is also named as "Alternative Characters Key":
>>>>>>>>>> https://help.ubuntu.com/community/ComposeKey
>>>>>>>>>>
>>>>>>>>>>> So someone needs to properly explain why we would claim a Mac keyboard
>>>>>>>>>>> is OK to generate a keycode it doesn't have and cause a slew of regressions
>>>>>>>>>>> in the process ...>
>>>>>>>>>>> If Mac doesn't distinguish these two, we should generate the same keycode for both.
>>>>>>>>>>
>>>>>>>>>> The macOS supports "right alt", otherwise it would not be possible to implement it in java:
>>>>>>>>>> https://developer.apple.com/library/archive/technotes/tn2450/_index.html
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>> One could suppose there is a difference else why two keys, but what is the right
>>>>>>>>>>> thing to do here  that fixes all the problems. What exactly WAS the problem
>>>>>>>>>>> with what was there in the first place ? And if changing it is correct why is it
>>>>>>>>>>> causing regressions ?
>>>>>>>>>>
>>>>>>>>>> Regressions were caused by the bugs in the fix implementation, or am I missed something?
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> -phil.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> On 3/12/19, 5:34 AM, Sergey Bylokhov wrote:
>>>>>>>>>>>> Hi, Phil.
>>>>>>>>>>>> On 11/03/2019 07:43, Philip Race wrote:
>>>>>>>>>>>>> The reasoning that AltGraph might be useful to someone is a bit weak
>>>>>>>>>>>>> and I don't think I'd want to support it via system property or build options.
>>>>>>>>>>>>>
>>>>>>>>>>>>> If its not a platform keyboard key, why do we need it ?
>>>>>>>>>>>>
>>>>>>>>>>>> The "AltGraph" key is also commonly referred to as "Right Alt", and
>>>>>>>>>>>> it has been implemented on all platforms as a "Right Alt", it is convenient to
>>>>>>>>>>>> distinguish the left/right alts.
>>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> --
>>>>>>>>>> Best regards, Sergey.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>> Best regards, Sergey.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Best regards, Sergey.
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Best regards,
>>>>> Sergey A. Malenkov
>>>>
>>>
>>>
>>
>>
>> --
>> Best regards, Sergey.
> 
> 
> 


-- 
Best regards, Sergey.

From volker.simonis at gmail.com  Mon Mar 18 14:15:51 2019
From: volker.simonis at gmail.com (Volker Simonis)
Date: Mon, 18 Mar 2019 15:15:51 +0100
Subject: <AWT Dev> RFR: 8220528: [AIX] Fix basic Xinerama and Xrender
	functionality
In-Reply-To: <CA+3eh130xEVyDdr=r+kjY9A1c8pqKkCSw4gb+3OpNFBLMts0UQ@mail.gmail.com>
References: <CA+3eh130xEVyDdr=r+kjY9A1c8pqKkCSw4gb+3OpNFBLMts0UQ@mail.gmail.com>
Message-ID: <CA+3eh1000n2+dtBf_+A7OFvTPceL86ASMBHfUn_NdDswPRbmYQ@mail.gmail.com>

Ping...

Can I please also get a review from the awt/2d group?

Thanks,
Volker

On Wed, Mar 13, 2019 at 11:09 AM Volker Simonis
<volker.simonis at gmail.com> wrote:
>
> Hi,
>
> can I please have a review for the following change which fixes
> Xinerama and Xrender support on AIX:
>
> http://cr.openjdk.java.net/~simonis/webrevs/2019/8220528/
> https://bugs.openjdk.java.net/browse/JDK-8220528
>
> The change basically fixes the way how the corresponding libraries
> (libXext and libXrender) get loaded on AIX and does some cleanups with
> regards to the various platform macros. I've also added some debug
> tracing to the Xrender initialization code similar to the Xinerama
> initialization.
>
> Thank you and best regards,
> Volker

From malenkov at gmail.com  Mon Mar 18 14:32:48 2019
From: malenkov at gmail.com (Sergey Malenkov)
Date: Mon, 18 Mar 2019 17:32:48 +0300
Subject: <AWT Dev> [13] JDK-8218917: KeyEvent.getModifiers() returns
 inconsistent values for ALT keys
In-Reply-To: <6d9a95d4-4ceb-c596-ce8f-6dccbd21dd6e@oracle.com>
References: <990B3CDA-E3A0-4051-8771-1AD486094974@oracle.com>
 <CANTFZ2i30ao6fVuVxQseEzF38vBnLUfw3PPadYyKrUCrgfKo9g@mail.gmail.com>
 <6B001F8A-858F-4279-8F42-366F22D49B52@oracle.com>
 <CANTFZ2iUHFNSm9st3d3BLYvERa5OmpOzU+T5e1aoLq5C7YkMfQ@mail.gmail.com>
 <5C8673F6.8060306@oracle.com>
 <6d97202a-ad60-c768-4a31-66ca02f16f70@oracle.com>
 <5C86FF3C.7030700@oracle.com>
 <b842a817-1c61-7d23-a144-41bfc87013a3@oracle.com>
 <CANTFZ2ikTVEP1OcrE415KhRbKr7Bv1XND-UW5tVPOW5+Ube7Jw@mail.gmail.com>
 <7dcf0e9b-cfc8-b985-f60c-10f7fe307825@oracle.com>
 <CANTFZ2h2gc8abosQBJrSNA2tF6cwDQacjpfKp_y1znwkkAU+8w@mail.gmail.com>
 <0c65a2e9-d5b3-eaf0-44eb-2b969de64dac@oracle.com>
 <CANTFZ2gY=h5AyLTu8KPkwyL1_4TvY6jLf9_aqTGBwa0kf5mRdQ@mail.gmail.com>
 <5956470F-019E-40E7-AE6D-9BB9F4E95F19@oracle.com>
 <CANTFZ2jUNuwSfEaRVMSCjVhJ50i9aWYi5V_fZE5aRvVConz3Sw@mail.gmail.com>
 <b8901169-5a6e-cd3d-56d7-d3d2578ff29a@oracle.com>
 <CANTFZ2hUFGyAVuYPxH8ubvpbWypHD4Q2G+oRZKS+Gw=j-H3sdw@mail.gmail.com>
 <6d9a95d4-4ceb-c596-ce8f-6dccbd21dd6e@oracle.com>
Message-ID: <CANTFZ2h7UkaBVqXje7XQ3f-Jrk2Yc30X-T0zXjFNadZ6BCyVbQ@mail.gmail.com>

Hi Sergey,

ALT_GRAPH_DOWN_MASK is not the only mask missing in JavaDoc. What is
about META_DOWN_MASK? What if the developer, who does not care about
ALT_GRAPH, forget about META too? Guess how your example will work on
Mac. What is about the WORA slogan?

I believe that the example in the javadoc is not entirely correct.
This is just a very simple example, related to the English locale on
Windows (and possibly on Linux). It should not be used in
multi-platform code.



On Sun, Mar 17, 2019 at 1:26 AM Sergey Bylokhov
<Sergey.Bylokhov at oracle.com> wrote:
>
> On 16/03/2019 03:58, Sergey Malenkov wrote:
> > Your example is synthetic and shows a problem in the one specific
> > case. I think if you introduce new mask, you have to use it in your
> > example too. If you add ALT_GRAPH_DOWN_MASK to 'offmask' your example
> > will not work (that's how processed all shortcuts in Swing and IDEA).
> > If you add it to 'onmask' the KeyEvent(new Button(), 0, 0,
> > ALT_GRAPH_DOWN_MASK, 0) will not work.
>
> Your example is good as well, but it shows the opposite, if
> ALT_GRAPH_DOWN_MASK was used as "onmask" or as "offmask" then it means
> that this example tries to take care about altGr and it only
> properly works after the fix. And if the code is unaware about the altGr
> flag as in previous example it will be ignored.
>
> > Am I right that to support your specific case you have to find and fix
> > all Alt-based shortcuts in Swing, we should fix all Alt-based
> > shortcuts in all keymaps in our IDEs and we should notify all our
> > users that they have to fix all Alt-based shortcuts in their custom
> > keymaps? The brilliant example of backward compatibility!
>
> I do not remember all changes which were integrated since initially it was done
> ~4 years ago. But Swing was updated by some changes after that, for example:
> https://bugs.openjdk.java.net/browse/JDK-8194873
>
> >
> >> So if the client will follow the spec below it should work as before, isn't it?:
> >> https://docs.oracle.com/en/java/javase/11/docs/api/java.desktop/java/awt/event/InputEvent.html#getModifiersEx()
> >
> > If a developer use this method as described his code will be broken
> > too, because good and attentive developer definitely added
> > ALT_GRAPH_DOWN_MASK to 'offmask'.
>
> If the user wants to ignore all combinations with "Alternate Character Key"
> then, as you pointed in the start of this thread, he should ignore both
> "alt" since on macOS both alt keys are "Alternate Character Key".
>
> >
> > On Sat, Mar 16, 2019 at 1:27 AM Sergey Bylokhov
> > <Sergey.Bylokhov at oracle.com> wrote:
> >>
> >> On 15/03/2019 05:54, Sergey Malenkov wrote:
> >>> We have a major issue about unexpected AltGr in the keyboard layout
> >>> that should not have AltGr at all:
> >>> http://youtrack.jetbrains.com/issue/IDEA-206348
> >>> Why you decided to support AltGr for every keyboard layout? It really
> >>> breaks backward compatibility!
> >>
> >> Even in your bug report the people complain that altGr key does not work, and
> >> the only problem here is that it does not assigned by default.
> >> But on the other side it is possible to set separate shortcuts
> >> to the "Alt + Alt Graph + Enter"and "Alt + Enter":
> >>
> >>> I think the main client is Swing and pressed AltGr that looks like
> >>> 'Alt+AltGr+' breaks all Alt-based shortcuts defined in
> >>> javax.swing.plaf.basic.BasicLookAndFeel#initComponentDefaults and
> >>> other places. Now, if you press "alt LEFT", the "moveColumnLeft"
> >>> action is performed only for the left Alt. And this also breaks a
> >>> backward compatibility.
> >>
> >> The term "all" is not so critical, there are only few such shortcuts, and it is
> >> a good thing that potentially we can set different shortcuts for each.
> >> This is a bug that these places were not updated, it is easy to fix since this
> >> is not exposed via public API.
> >> But we will get the same result if we will use the AltGr mask only.
> >>
> >>> It is not backward compatible to use AltGr instead of right Alt in
> >>> both cases. Instead of 'Alt+key' you will get 'AltGr+key' or
> >>> 'Alt+AltGr+key', which are not bound to any action.
> >>
> >> It is compatible to the specification of InputEvent.getModifiersEx():
> >> KeyEvent event = new KeyEvent(new Button(), 0, 0,
> >>                                 ALT_DOWN_MASK | ALT_GRAPH_DOWN_MASK, 0);
> >>     int onmask =  ALT_DOWN_MASK;
> >>     int offmask = CTRL_DOWN_MASK|SHIFT_DOWN_MASK;
> >>     if ((event.getModifiersEx() & (onmask | offmask)) == onmask) {
> >>       ...
> >>     }
> >>
> >> The code above works before and after the change for altGr.
> >> But it will stop working if we will use altGr only, and it will be hard to argue
> >> why the ALT flag is not set while alt key is pressed(since on some keyboards this key is
> >> marked as alt and on some other altGr).
> >>
> >> And as specially noted in the method above the code should not assume which
> >> flags(and how many) were set by the actions, if such assumptions exists in
> >> Swing itself they should be fixed as well.
> >>
> >>>
> >>> On Fri, Mar 15, 2019 at 9:27 AM Krishna Addepalli
> >>> <krishna.addepalli at oracle.com> wrote:
> >>>>
> >>>> Hi Sergey Malenkov,
> >>>>
> >>>>> 'Alt+AltGr+Right' does nothing, because we do not assign this shortcut yet
> >>>> In my personal experience, I did not find any instance, wherein a shortcut had left and right alt in it.
> >>>> Although it is not impossible, it seems weird to define such shortcuts.
> >>>> It would be helpful if you could point to some resources, wherein defining such shortcuts is acceptable.
> >>>>
> >>>> Thanks,
> >>>> Krishna
> >>>>
> >>>>> On 14-Mar-2019, at 4:03 PM, Sergey Malenkov <malenkov at gmail.com> wrote:
> >>>>>
> >>>>> I strongly don't like two masks for one key. If you press VK_ALT,
> >>>>> ALT_DOWN_MASK should be set. If you press VK_SHIFT then,
> >>>>> SHIFT_DOWN_MASK should be added to indicate that both keys are
> >>>>> pressed. And if you press VK_ALT_GRAPH, only ALT_GRAPH_DOWN_MASK
> >>>>> should be added. Otherwise, you can't distinguish the following key
> >>>>> strokes: 'AltGr+Right' and 'Alt+AltGr+Right'. But these keystrokes are
> >>>>> different and should invoke different actions. For example,
> >>>>> 'Alt+Right' moves cursor to the next word
> >>>>> 'Alt+Shift+Right' moves cursor to the next word AND adds all skipped
> >>>>> characters to selection
> >>>>> 'Alt+AltGr+Right' does nothing, because we do not assign this shortcut yet
> >>>>>
> >>>>> On Thu, Mar 14, 2019 at 12:09 AM Sergey Bylokhov
> >>>>> <Sergey.Bylokhov at oracle.com> wrote:
> >>>>>>
> >>>>>> On 13/03/2019 03:59, Sergey Malenkov wrote:
> >>>>>>> I missed the "for ALT keys" in the bug title and thought that
> >>>>>>> "KeyEvent.getModifiers() returns inconsistent values" was about
> >>>>>>> incompatible behaviour on different platforms. In fact, JDK-8218917
> >>>>>>> should be renamed to something like ?The right Alt key on Mac should
> >>>>>>> behave as Alt and must not break the left Alt key processing?.
> >>>>>>
> >>>>>> But the "right Alt" should behave like a "left alt" already, it should use both flags:
> >>>>>> the common alt(ALT_DOWN_MASK) and the altGr(ALT_GRAPH_DOWN_MASK).
> >>>>>>
> >>>>>> So if the client will follow the spec below it should work as before, isn't it?:
> >>>>>> https://docs.oracle.com/en/java/javase/11/docs/api/java.desktop/java/awt/event/InputEvent.html#getModifiersEx()
> >>>>>>
> >>>>>>> On Wed, Mar 13, 2019 at 6:57 AM Sergey Bylokhov
> >>>>>>> <Sergey.Bylokhov at oracle.com> wrote:
> >>>>>>>>
> >>>>>>>> On 12/03/2019 12:28, Sergey Malenkov wrote:
> >>>>>>>>> Hi Sergey,
> >>>>>>>>>
> >>>>>>>>> 1. macOS uses a regular Alt key as "Alternate Character Key". This is
> >>>>>>>>> the reason why JDK Toolkit defines Ctrl+Alt to select a mnemonic,
> >>>>>>>>> instead of simple Alt. See
> >>>>>>>>> https://sites.google.com/site/malenkov/java/141229
> >>>>>>>>
> >>>>>>>> Right, but introducing this flag for the "left alt" could cause even more
> >>>>>>>> issues, so this flag is set only for the right.
> >>>>>>>>
> >>>>>>>>> 3. Regression was caused by adding AltGr to key processing on Mac. But
> >>>>>>>>> I found more issues with inconsistent key processing on different
> >>>>>>>>> platforms. See http://sites.google.com/site/malenkov/java/190312
> >>>>>>>>
> >>>>>>>> Not sure that CAPS_LOCK is related.
> >>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> On Tue, Mar 12, 2019 at 4:17 AM Sergey Bylokhov
> >>>>>>>>> <Sergey.Bylokhov at oracle.com> wrote:
> >>>>>>>>>>
> >>>>>>>>>> On 11/03/2019 17:37, Philip Race wrote:
> >>>>>>>>>>> The debate is about AltGraph which an ancient MS-DOSism for
> >>>>>>>>>>> asking for an ALTernate GRAPHics bitmap font - all pre-dates windows
> >>>>>>>>>>> and I am sure has never been applicable to any MacOS.
> >>>>>>>>>>
> >>>>>>>>>> It also about the "right alt" which is also know as "AltGraph". I guess currently
> >>>>>>>>>> it is implemented as "right alt" on Linux/macOS/windows.
> >>>>>>>>>>
> >>>>>>>>>> BTW on linux it is also named as "Alternative Characters Key":
> >>>>>>>>>> https://help.ubuntu.com/community/ComposeKey
> >>>>>>>>>>
> >>>>>>>>>>> So someone needs to properly explain why we would claim a Mac keyboard
> >>>>>>>>>>> is OK to generate a keycode it doesn't have and cause a slew of regressions
> >>>>>>>>>>> in the process ...>
> >>>>>>>>>>> If Mac doesn't distinguish these two, we should generate the same keycode for both.
> >>>>>>>>>>
> >>>>>>>>>> The macOS supports "right alt", otherwise it would not be possible to implement it in java:
> >>>>>>>>>> https://developer.apple.com/library/archive/technotes/tn2450/_index.html
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>> One could suppose there is a difference else why two keys, but what is the right
> >>>>>>>>>>> thing to do here  that fixes all the problems. What exactly WAS the problem
> >>>>>>>>>>> with what was there in the first place ? And if changing it is correct why is it
> >>>>>>>>>>> causing regressions ?
> >>>>>>>>>>
> >>>>>>>>>> Regressions were caused by the bugs in the fix implementation, or am I missed something?
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>> -phil.
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>> On 3/12/19, 5:34 AM, Sergey Bylokhov wrote:
> >>>>>>>>>>>> Hi, Phil.
> >>>>>>>>>>>> On 11/03/2019 07:43, Philip Race wrote:
> >>>>>>>>>>>>> The reasoning that AltGraph might be useful to someone is a bit weak
> >>>>>>>>>>>>> and I don't think I'd want to support it via system property or build options.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> If its not a platform keyboard key, why do we need it ?
> >>>>>>>>>>>>
> >>>>>>>>>>>> The "AltGraph" key is also commonly referred to as "Right Alt", and
> >>>>>>>>>>>> it has been implemented on all platforms as a "Right Alt", it is convenient to
> >>>>>>>>>>>> distinguish the left/right alts.
> >>>>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> --
> >>>>>>>>>> Best regards, Sergey.
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> --
> >>>>>>>> Best regards, Sergey.
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>
> >>>>>>
> >>>>>> --
> >>>>>> Best regards, Sergey.
> >>>>>
> >>>>>
> >>>>>
> >>>>> --
> >>>>> Best regards,
> >>>>> Sergey A. Malenkov
> >>>>
> >>>
> >>>
> >>
> >>
> >> --
> >> Best regards, Sergey.
> >
> >
> >
>
>
> --
> Best regards, Sergey.



-- 
Best regards,
Sergey A. Malenkov

From thomas.stuefe at gmail.com  Mon Mar 18 19:59:15 2019
From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=)
Date: Mon, 18 Mar 2019 20:59:15 +0100
Subject: <AWT Dev> [OpenJDK 2D-Dev] RFR: 8220528: [AIX] Fix basic
 Xinerama and Xrender functionality
In-Reply-To: <CA+3eh1000n2+dtBf_+A7OFvTPceL86ASMBHfUn_NdDswPRbmYQ@mail.gmail.com>
References: <CA+3eh130xEVyDdr=r+kjY9A1c8pqKkCSw4gb+3OpNFBLMts0UQ@mail.gmail.com>
 <CA+3eh1000n2+dtBf_+A7OFvTPceL86ASMBHfUn_NdDswPRbmYQ@mail.gmail.com>
Message-ID: <CAA-vtUwXF7QaEMm+i=8U5zH0y6MkOFPvKRtnQsm+x2+Z_uyPPA@mail.gmail.com>

Sorry, not awt/2d group, but to me it looks fine too. Only nit: the error
printout at 495 I would put right after the associated dlsym at 456. You
want to make sure dlerror() is not stale at the point where you call it,
since it would return NULL.

Cheers, Thomas



On Mon, Mar 18, 2019 at 3:17 PM Volker Simonis <volker.simonis at gmail.com>
wrote:

> Ping...
>
> Can I please also get a review from the awt/2d group?
>
> Thanks,
> Volker
>
> On Wed, Mar 13, 2019 at 11:09 AM Volker Simonis
> <volker.simonis at gmail.com> wrote:
> >
> > Hi,
> >
> > can I please have a review for the following change which fixes
> > Xinerama and Xrender support on AIX:
> >
> > http://cr.openjdk.java.net/~simonis/webrevs/2019/8220528/
> > https://bugs.openjdk.java.net/browse/JDK-8220528
> >
> > The change basically fixes the way how the corresponding libraries
> > (libXext and libXrender) get loaded on AIX and does some cleanups with
> > regards to the various platform macros. I've also added some debug
> > tracing to the Xrender initialization code similar to the Xinerama
> > initialization.
> >
> > Thank you and best regards,
> > Volker
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/awt-dev/attachments/20190318/589372ff/attachment.html>

From Sergey.Bylokhov at oracle.com  Mon Mar 18 23:42:34 2019
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Mon, 18 Mar 2019 16:42:34 -0700
Subject: <AWT Dev> RFR: 8212676 AIX's CDE/MWM support
In-Reply-To: <368b32e110b608570c4929e216ee37c6@linux.vnet.ibm.com>
References: <5f309d9c612f2c16aef75846e0ff14fa@linux.vnet.ibm.com>
 <d2b3bc94-0ba3-712f-c46b-f83048491cb0@oracle.com>
 <f942c133e212bace34e72e79bfb64ab4@linux.vnet.ibm.com>
 <0ede447e30ed05ce7a52f6d133b2c15b@linux.vnet.ibm.com>
 <180114e58e98f339332e3a781a34126b@linux.vnet.ibm.com>
 <d9e8c69e64ff87bb84a9468b4364fb06@linux.vnet.ibm.com>
 <5a4f9f5c7a80a5abda9edd150e19a11f@linux.vnet.ibm.com>
 <4addeebf-9ed8-bb63-5920-49ae6fb429b1@oracle.com>
 <c314e88dcc25495f6fba698f8ad5ae63@linux.vnet.ibm.com>
 <5C0725B5.3080907@oracle.com> <5C0773E7.8030108@oracle.com>
 <ad8f6c895b66c65a0b7bc344c5a759e0@linux.vnet.ibm.com>
 <13a9685a38984c56ec2f0aaa084a3f80@linux.vnet.ibm.com>
 <368b32e110b608570c4929e216ee37c6@linux.vnet.ibm.com>
Message-ID: <10ad0a1a-b4ad-3978-fab0-87c28005a879@oracle.com>

Hi, Ichiroh.

It looks fine, but I have one general comment: this fix is not about some general support of "AIX's CDE/MWM", but it is mostly about initialization of "java.awt.SystemColor", which is already used by the awt/swing.

On 11/03/2019 19:04, Ichiroh Takiguchi wrote:
> Hello.
> 
> Could you review the fix and give me your suggestion, please ?
> 
> Thanks,
> Ichiroh Takiguchi
> 
> On 2019-03-01 22:16, Ichiroh Takiguchi wrote:
>> Hello.
>>
>> Could you review the fix again ?
>>
>> Bug:??? https://bugs.openjdk.java.net/browse/JDK-8212676
>> Change: https://cr.openjdk.java.net/~itakiguchi/8212676/webrev.01/
>>
>> I applied following changes:
>> * I added AIX detection code into sun.awt.OSInfo class.
>> ? It seems CDE's default should be middle color.
>> ? But AIX's default is high color, so AIX detection code is required.
>> * MWM detection code can be used on Linux and AIX platform
>> ? AIX only code was removed
>> * I could not recreate XMapRaised/XMapWindow related issue.
>> ? The fix was ignored
>> * Non-focusable window handling on DTWM/MWM
>> ? I checked Linux's MWM working behavior on RHEL6.
>> ? I applied AIX's code into Linux side, but it was bad.
>> ? Working behavior became worse.
>> ? So AIX detection feature is still required.
>>
>> (JDK-8212676 was also updated)
>>
>> I'd like to obtain a sponsor for this issue.
>>
>> Thanks,
>> Ichiroh Takiguchi
>> IBM Japan, Ltd.
>>
>> On 2018-12-05 18:22, Ichiroh Takiguchi wrote:
>>> Hello Phil.
>>>
>>> I heard some of AIX users used RealVNC VNC Enterprise Edition for AIX
>>> maintenance. [1]
>>> I assume they still use CDE.
>>>
>>> [1] https://www.realvnc.com/en/connect/download/vnc/aix/#older-versions
>>>
>>> Thanks,
>>> Ichiroh Takiguchi
>>>
>>> On 2018-12-05 15:44, Philip Race wrote:
>>>> . and I think I need to be convinced about whether "aix" is the right
>>>> thing to check here.
>>>> "I know AIX works like this today" isn't a very robust, or very
>>>> portable approach.
>>>> The fix is more about the CDE/Motif environment than AIX, isn't it ?
>>>>
>>>> -phil.
>>>>
>>>>
>>>> On 12/4/18, 5:11 PM, Philip Race wrote:
>>>>>
>>>>>
>>>>> On 12/4/18, 5:10 PM, Ichiroh Takiguchi wrote:
>>>>>> Hello Phil.
>>>>>>
>>>>>>> I haven't evaluated the merits of this proposal but this
>>>>>>> https://cr.openjdk.java.net/~itakiguchi/8212676/webrev.00/src/java.desktop/share/classes/sun/font/FontUtilities.java.udiff.html is not the right place to support a flag used in all these X11 files.
>>>>>> Could you give me your recommendation ?
>>>>>
>>>>> Somewhere closer to the code that needs it.
>>>>>>
>>>>>>> And why is i18n-dev on the review ? I can't see any I18N related changes.
>>>>>> I thought focus issue was related input method.
>>>>>
>>>>> No. I mean input focus is necessary for input methods but focus does not
>>>>> automatically mean input methods are in play.
>>>>>
>>>>> -phil
>>>>>
>>>>>> AIX IM was activated even if focus was moved to non focusable window (middle window). [1]
>>>>>> So I posted this issue into I18N, but it was not good.
>>>>>> Actually, all key events were forwarded to middle window if user clicked inside of right window.
>>>>>>
>>>>>> [1] https://bugs.openjdk.java.net/secure/attachment/79986/aix-focusable.png
>>>>>>
>>>>>> Thanks,
>>>>>> Ichiroh Takiguchi
>>>>>>
>>>>>> On 2018-12-05 03:06, Phil Race wrote:
>>>>>>> I haven't evaluated the merits of this proposal but this
>>>>>>> https://cr.openjdk.java.net/~itakiguchi/8212676/webrev.00/src/java.desktop/share/classes/sun/font/FontUtilities.java.udiff.html is not the right place to support a flag used in all these X11 files.
>>>>>>>
>>>>>>> And why is i18n-dev on the review ? I can't see any I18N related changes.
>>>>>>>
>>>>>>> -phil.
>>>>>>>
>>>>>>> On 12/4/18 8:53 AM, Ichiroh Takiguchi wrote:
>>>>>>>> Hello again.
>>>>>>>>
>>>>>>>> Could you give me review comment and/or suggestion ?
>>>>>>>>
>>>>>>>> Bug:??? https://bugs.openjdk.java.net/browse/JDK-8212676
>>>>>>>> Change: https://cr.openjdk.java.net/~itakiguchi/8212676/webrev.00/
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>> Ichiroh Takiguchi
>>>>>>>>
>>>>>>>> On 2018-11-26 21:27, Ichiroh Takiguchi wrote:
>>>>>>>>> Hello.
>>>>>>>>>
>>>>>>>>> Could you review the fix ?
>>>>>>>>>
>>>>>>>>> Bug:??? https://bugs.openjdk.java.net/browse/JDK-8212676
>>>>>>>>> Change: https://cr.openjdk.java.net/~itakiguchi/8212676/webrev.00/
>>>>>>>>>
>>>>>>>>> Test instructions and screen shots are in JDK-8212676.
>>>>>>>>>
>>>>>>>>> GUI environment for AIX platform still needs CDE support.
>>>>>>>>> This fix is required to avoid unexpected working behavior on AIX platform.
>>>>>>>>>
>>>>>>>>> I'd like to obtain a sponsor for this issue.
>>>>>>>>>
>>>>>>>>> Thanks,
>>>>>>>>> Ichiroh Takiguchi
>>>>>>>>> IBM Japan, Ltd.
>>>>>>>>>
>>>>>>>>> On 2018-06-18 18:57, Ichiroh Takiguchi wrote:
>>>>>>>>>> Hello.
>>>>>>>>>>
>>>>>>>>>> This fix is really required for AIX's GUI.
>>>>>>>>>> System color setting and window manager's working behavior are very important.
>>>>>>>>>>
>>>>>>>>>> I appreciate any feedback, and how I would go about obtaining a
>>>>>>>>>> sponsor and contributor ?
>>>>>>>>>>
>>>>>>>>>> On 2018-05-25 11:02, Ichiroh Takiguchi wrote:
>>>>>>>>>>> Hello Phil.
>>>>>>>>>>>
>>>>>>>>>>> webrev file was extracted.
>>>>>>>>>>> Please see
>>>>>>>>>>> ? http://cr.openjdk.java.net/~aleonard/AIX_GUI/webrev.00/
>>>>>>>>>>>
>>>>>>>>>>> On 2018-05-19 02:48, Ichiroh Takiguchi wrote:
>>>>>>>>>>>> Hello Phil.
>>>>>>>>>>>>
>>>>>>>>>>>> Webrev.zip file is stored into
>>>>>>>>>>>> http://cr.openjdk.java.net/~aleonard/AIX_GUI/webrev-aixgui.zip
>>>>>>>>>>>>
>>>>>>>>>>>> Test programs are also stored:
>>>>>>>>>>>> No testcase is available for FontUtilities.java and XDecoratedPeer.java.
>>>>>>>>>>>>
>>>>>>>>>>>> MotifColorUtilities.java
>>>>>>>>>>>> http://cr.openjdk.java.net/~aleonard/AIX_GUI/SystemColorTest2.java
>>>>>>>>>>>> Run SystemColorTest2, system colors should be displayed
>>>>>>>>>>>> AIX sample is
>>>>>>>>>>>> http://cr.openjdk.java.net/~aleonard/AIX_GUI/aix_systemcolor.txt
>>>>>>>>>>>>
>>>>>>>>>>>> XWM.java
>>>>>>>>>>>> http://cr.openjdk.java.net/~aleonard/AIX_GUI/XWMTest1.java
>>>>>>>>>>>> On AIX CDE, isMotif and isCDE were true.
>>>>>>>>>>>> On AIX MWM, every entry is false.
>>>>>>>>>>>>
>>>>>>>>>>>> XWindowPeer.java
>>>>>>>>>>>> http://cr.openjdk.java.net/~aleonard/AIX_GUI/JFrameTest.java
>>>>>>>>>>>> On AIX CDE, click inside of "Non-Focusable" window (not window frame).
>>>>>>>>>>>> Window focus should not be changed because of "click on focus" feature.
>>>>>>>>>>>> But input focus is moved to "Non-Focusable" window.
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> On 2018-05-18 01:00, Phil Race wrote:
>>>>>>>>>>>>> I think we'd need to see the actual proposed changes and understand
>>>>>>>>>>>>> the implications
>>>>>>>>>>>>> for ongoing support as we no longer support any platform which has a
>>>>>>>>>>>>> CDE desktop.
>>>>>>>>>>>>> Solaris 11.3 uses Gnome, so we'd be more inclined to be ripping out
>>>>>>>>>>>>> such support rather
>>>>>>>>>>>>> than adding to it.
>>>>>>>>>>>>>
>>>>>>>>>>>>> -phil.
>>>>>>>>>>>>>
>>>>>>>>>>>>> On 05/17/2018 04:18 AM, Ichiroh Takiguchi wrote:
>>>>>>>>>>>>>> Hello,
>>>>>>>>>>>>>> IBM would like to contribute AIX's CDE (Common Desktop Environment) DTWM (Desktop Window Manager) /MWM (Motif Window Manager) support to OpenJDK project.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> I'd like contribute following 5 files:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> M src/java.desktop/share/classes/sun/font/FontUtilities.java
>>>>>>>>>>>>>> (Add isAIX flag to determine AIX platform for GUI environment)
>>>>>>>>>>>>>> M src/java.desktop/unix/classes/sun/awt/X11/MotifColorUtilities.java (Add High Color support on CDE, OpenJDK just supports Medium Color) [1]
>>>>>>>>>>>>>> M src/java.desktop/unix/classes/sun/awt/X11/XDecoratedPeer.java
>>>>>>>>>>>>>> (Avoid miss calculation for window position under DTWM/MWM by XMapRaised/XMapWindow)
>>>>>>>>>>>>>> M src/java.desktop/unix/classes/sun/awt/X11/XWM.java
>>>>>>>>>>>>>> (Detect MWM on AIX platform)
>>>>>>>>>>>>>> M src/java.desktop/unix/classes/sun/awt/X11/XWindowPeer.java
>>>>>>>>>>>>>> (Add non-focusable window support on DTWM/MWM for AIX, because DTWM/MWM does not have enough features for ICCCM)
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> I appreciate any feedback please, and how I would go about obtaining a sponsor and contributor ?
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>>> Ichiroh Takiguchi
>>>>>>>>>>>>>> IBM Japan, Ltd.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> [1] https://docs.oracle.com/cd/E19253-01/806-7492/fontsandcolors-15233/index.html
>>>>>>>>>>>>>>
>>>>>>>>
>>>>>>
> 


-- 
Best regards, Sergey.

From takiguc at linux.vnet.ibm.com  Tue Mar 19 17:22:43 2019
From: takiguc at linux.vnet.ibm.com (Ichiroh Takiguchi)
Date: Wed, 20 Mar 2019 02:22:43 +0900
Subject: <AWT Dev> RFR: 8212676 java.awt.SystemColor setting on CDE
In-Reply-To: <10ad0a1a-b4ad-3978-fab0-87c28005a879@oracle.com>
References: <5f309d9c612f2c16aef75846e0ff14fa@linux.vnet.ibm.com>
 <d2b3bc94-0ba3-712f-c46b-f83048491cb0@oracle.com>
 <f942c133e212bace34e72e79bfb64ab4@linux.vnet.ibm.com>
 <0ede447e30ed05ce7a52f6d133b2c15b@linux.vnet.ibm.com>
 <180114e58e98f339332e3a781a34126b@linux.vnet.ibm.com>
 <d9e8c69e64ff87bb84a9468b4364fb06@linux.vnet.ibm.com>
 <5a4f9f5c7a80a5abda9edd150e19a11f@linux.vnet.ibm.com>
 <4addeebf-9ed8-bb63-5920-49ae6fb429b1@oracle.com>
 <c314e88dcc25495f6fba698f8ad5ae63@linux.vnet.ibm.com>
 <5C0725B5.3080907@oracle.com> <5C0773E7.8030108@oracle.com>
 <ad8f6c895b66c65a0b7bc344c5a759e0@linux.vnet.ibm.com>
 <13a9685a38984c56ec2f0aaa084a3f80@linux.vnet.ibm.com>
 <368b32e110b608570c4929e216ee37c6@linux.vnet.ibm.com>
 <10ad0a1a-b4ad-3978-fab0-87c28005a879@oracle.com>
Message-ID: <5c62bbea9c6a2550b4f960708c38c856@linux.vnet.ibm.com>

Hello Sergey.

Thank you for your suggestion.
I changed Subject.
 From: AIX's CDE/MWM support
To: AWT SystemColor setting on CDE

Could you review the fix and give me your suggestion again ?

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

For AIX dtwm/mwm issue, I opened JDK-8221082 [1].

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

Thanks,
Ichiroh Takiguchi

On 2019-03-19 08:42, Sergey Bylokhov wrote:
> Hi, Ichiroh.
> 
> It looks fine, but I have one general comment: this fix is not about
> some general support of "AIX's CDE/MWM", but it is mostly about
> initialization of "java.awt.SystemColor", which is already used by the
> awt/swing.
> 
> On 11/03/2019 19:04, Ichiroh Takiguchi wrote:
>> Hello.
>> 
>> Could you review the fix and give me your suggestion, please ?
>> 
>> Thanks,
>> Ichiroh Takiguchi
>> 
>> On 2019-03-01 22:16, Ichiroh Takiguchi wrote:
>>> Hello.
>>> 
>>> Could you review the fix again ?
>>> 
>>> Bug:??? https://bugs.openjdk.java.net/browse/JDK-8212676
>>> Change: https://cr.openjdk.java.net/~itakiguchi/8212676/webrev.01/
>>> 
>>> I applied following changes:
>>> * I added AIX detection code into sun.awt.OSInfo class.
>>> ? It seems CDE's default should be middle color.
>>> ? But AIX's default is high color, so AIX detection code is 
>>> required.
>>> * MWM detection code can be used on Linux and AIX platform
>>> ? AIX only code was removed
>>> * I could not recreate XMapRaised/XMapWindow related issue.
>>> ? The fix was ignored
>>> * Non-focusable window handling on DTWM/MWM
>>> ? I checked Linux's MWM working behavior on RHEL6.
>>> ? I applied AIX's code into Linux side, but it was bad.
>>> ? Working behavior became worse.
>>> ? So AIX detection feature is still required.
>>> 
>>> (JDK-8212676 was also updated)
>>> 
>>> I'd like to obtain a sponsor for this issue.
>>> 
>>> Thanks,
>>> Ichiroh Takiguchi
>>> IBM Japan, Ltd.
>>> 
>>> On 2018-12-05 18:22, Ichiroh Takiguchi wrote:
>>>> Hello Phil.
>>>> 
>>>> I heard some of AIX users used RealVNC VNC Enterprise Edition for 
>>>> AIX
>>>> maintenance. [1]
>>>> I assume they still use CDE.
>>>> 
>>>> [1] 
>>>> https://www.realvnc.com/en/connect/download/vnc/aix/#older-versions
>>>> 
>>>> Thanks,
>>>> Ichiroh Takiguchi
>>>> 
>>>> On 2018-12-05 15:44, Philip Race wrote:
>>>>> . and I think I need to be convinced about whether "aix" is the 
>>>>> right
>>>>> thing to check here.
>>>>> "I know AIX works like this today" isn't a very robust, or very
>>>>> portable approach.
>>>>> The fix is more about the CDE/Motif environment than AIX, isn't it 
>>>>> ?
>>>>> 
>>>>> -phil.
>>>>> 
>>>>> 
>>>>> On 12/4/18, 5:11 PM, Philip Race wrote:
>>>>>> 
>>>>>> 
>>>>>> On 12/4/18, 5:10 PM, Ichiroh Takiguchi wrote:
>>>>>>> Hello Phil.
>>>>>>> 
>>>>>>>> I haven't evaluated the merits of this proposal but this
>>>>>>>> https://cr.openjdk.java.net/~itakiguchi/8212676/webrev.00/src/java.desktop/share/classes/sun/font/FontUtilities.java.udiff.html 
>>>>>>>> is not the right place to support a flag used in all these X11 
>>>>>>>> files.
>>>>>>> Could you give me your recommendation ?
>>>>>> 
>>>>>> Somewhere closer to the code that needs it.
>>>>>>> 
>>>>>>>> And why is i18n-dev on the review ? I can't see any I18N related 
>>>>>>>> changes.
>>>>>>> I thought focus issue was related input method.
>>>>>> 
>>>>>> No. I mean input focus is necessary for input methods but focus 
>>>>>> does not
>>>>>> automatically mean input methods are in play.
>>>>>> 
>>>>>> -phil
>>>>>> 
>>>>>>> AIX IM was activated even if focus was moved to non focusable 
>>>>>>> window (middle window). [1]
>>>>>>> So I posted this issue into I18N, but it was not good.
>>>>>>> Actually, all key events were forwarded to middle window if user 
>>>>>>> clicked inside of right window.
>>>>>>> 
>>>>>>> [1] 
>>>>>>> https://bugs.openjdk.java.net/secure/attachment/79986/aix-focusable.png
>>>>>>> 
>>>>>>> Thanks,
>>>>>>> Ichiroh Takiguchi
>>>>>>> 
>>>>>>> On 2018-12-05 03:06, Phil Race wrote:
>>>>>>>> I haven't evaluated the merits of this proposal but this
>>>>>>>> https://cr.openjdk.java.net/~itakiguchi/8212676/webrev.00/src/java.desktop/share/classes/sun/font/FontUtilities.java.udiff.html 
>>>>>>>> is not the right place to support a flag used in all these X11 
>>>>>>>> files.
>>>>>>>> 
>>>>>>>> And why is i18n-dev on the review ? I can't see any I18N related 
>>>>>>>> changes.
>>>>>>>> 
>>>>>>>> -phil.
>>>>>>>> 
>>>>>>>> On 12/4/18 8:53 AM, Ichiroh Takiguchi wrote:
>>>>>>>>> Hello again.
>>>>>>>>> 
>>>>>>>>> Could you give me review comment and/or suggestion ?
>>>>>>>>> 
>>>>>>>>> Bug:??? https://bugs.openjdk.java.net/browse/JDK-8212676
>>>>>>>>> Change: 
>>>>>>>>> https://cr.openjdk.java.net/~itakiguchi/8212676/webrev.00/
>>>>>>>>> 
>>>>>>>>> Thanks,
>>>>>>>>> Ichiroh Takiguchi
>>>>>>>>> 
>>>>>>>>> On 2018-11-26 21:27, Ichiroh Takiguchi wrote:
>>>>>>>>>> Hello.
>>>>>>>>>> 
>>>>>>>>>> Could you review the fix ?
>>>>>>>>>> 
>>>>>>>>>> Bug:??? https://bugs.openjdk.java.net/browse/JDK-8212676
>>>>>>>>>> Change: 
>>>>>>>>>> https://cr.openjdk.java.net/~itakiguchi/8212676/webrev.00/
>>>>>>>>>> 
>>>>>>>>>> Test instructions and screen shots are in JDK-8212676.
>>>>>>>>>> 
>>>>>>>>>> GUI environment for AIX platform still needs CDE support.
>>>>>>>>>> This fix is required to avoid unexpected working behavior on 
>>>>>>>>>> AIX platform.
>>>>>>>>>> 
>>>>>>>>>> I'd like to obtain a sponsor for this issue.
>>>>>>>>>> 
>>>>>>>>>> Thanks,
>>>>>>>>>> Ichiroh Takiguchi
>>>>>>>>>> IBM Japan, Ltd.
>>>>>>>>>> 
>>>>>>>>>> On 2018-06-18 18:57, Ichiroh Takiguchi wrote:
>>>>>>>>>>> Hello.
>>>>>>>>>>> 
>>>>>>>>>>> This fix is really required for AIX's GUI.
>>>>>>>>>>> System color setting and window manager's working behavior 
>>>>>>>>>>> are very important.
>>>>>>>>>>> 
>>>>>>>>>>> I appreciate any feedback, and how I would go about obtaining 
>>>>>>>>>>> a
>>>>>>>>>>> sponsor and contributor ?
>>>>>>>>>>> 
>>>>>>>>>>> On 2018-05-25 11:02, Ichiroh Takiguchi wrote:
>>>>>>>>>>>> Hello Phil.
>>>>>>>>>>>> 
>>>>>>>>>>>> webrev file was extracted.
>>>>>>>>>>>> Please see
>>>>>>>>>>>> ? http://cr.openjdk.java.net/~aleonard/AIX_GUI/webrev.00/
>>>>>>>>>>>> 
>>>>>>>>>>>> On 2018-05-19 02:48, Ichiroh Takiguchi wrote:
>>>>>>>>>>>>> Hello Phil.
>>>>>>>>>>>>> 
>>>>>>>>>>>>> Webrev.zip file is stored into
>>>>>>>>>>>>> http://cr.openjdk.java.net/~aleonard/AIX_GUI/webrev-aixgui.zip
>>>>>>>>>>>>> 
>>>>>>>>>>>>> Test programs are also stored:
>>>>>>>>>>>>> No testcase is available for FontUtilities.java and 
>>>>>>>>>>>>> XDecoratedPeer.java.
>>>>>>>>>>>>> 
>>>>>>>>>>>>> MotifColorUtilities.java
>>>>>>>>>>>>> http://cr.openjdk.java.net/~aleonard/AIX_GUI/SystemColorTest2.java
>>>>>>>>>>>>> Run SystemColorTest2, system colors should be displayed
>>>>>>>>>>>>> AIX sample is
>>>>>>>>>>>>> http://cr.openjdk.java.net/~aleonard/AIX_GUI/aix_systemcolor.txt
>>>>>>>>>>>>> 
>>>>>>>>>>>>> XWM.java
>>>>>>>>>>>>> http://cr.openjdk.java.net/~aleonard/AIX_GUI/XWMTest1.java
>>>>>>>>>>>>> On AIX CDE, isMotif and isCDE were true.
>>>>>>>>>>>>> On AIX MWM, every entry is false.
>>>>>>>>>>>>> 
>>>>>>>>>>>>> XWindowPeer.java
>>>>>>>>>>>>> http://cr.openjdk.java.net/~aleonard/AIX_GUI/JFrameTest.java
>>>>>>>>>>>>> On AIX CDE, click inside of "Non-Focusable" window (not 
>>>>>>>>>>>>> window frame).
>>>>>>>>>>>>> Window focus should not be changed because of "click on 
>>>>>>>>>>>>> focus" feature.
>>>>>>>>>>>>> But input focus is moved to "Non-Focusable" window.
>>>>>>>>>>>>> 
>>>>>>>>>>>>> 
>>>>>>>>>>>>> On 2018-05-18 01:00, Phil Race wrote:
>>>>>>>>>>>>>> I think we'd need to see the actual proposed changes and 
>>>>>>>>>>>>>> understand
>>>>>>>>>>>>>> the implications
>>>>>>>>>>>>>> for ongoing support as we no longer support any platform 
>>>>>>>>>>>>>> which has a
>>>>>>>>>>>>>> CDE desktop.
>>>>>>>>>>>>>> Solaris 11.3 uses Gnome, so we'd be more inclined to be 
>>>>>>>>>>>>>> ripping out
>>>>>>>>>>>>>> such support rather
>>>>>>>>>>>>>> than adding to it.
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> -phil.
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> On 05/17/2018 04:18 AM, Ichiroh Takiguchi wrote:
>>>>>>>>>>>>>>> Hello,
>>>>>>>>>>>>>>> IBM would like to contribute AIX's CDE (Common Desktop 
>>>>>>>>>>>>>>> Environment) DTWM (Desktop Window Manager) /MWM (Motif 
>>>>>>>>>>>>>>> Window Manager) support to OpenJDK project.
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> I'd like contribute following 5 files:
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> M 
>>>>>>>>>>>>>>> src/java.desktop/share/classes/sun/font/FontUtilities.java
>>>>>>>>>>>>>>> (Add isAIX flag to determine AIX platform for GUI 
>>>>>>>>>>>>>>> environment)
>>>>>>>>>>>>>>> M 
>>>>>>>>>>>>>>> src/java.desktop/unix/classes/sun/awt/X11/MotifColorUtilities.java 
>>>>>>>>>>>>>>> (Add High Color support on CDE, OpenJDK just supports 
>>>>>>>>>>>>>>> Medium Color) [1]
>>>>>>>>>>>>>>> M 
>>>>>>>>>>>>>>> src/java.desktop/unix/classes/sun/awt/X11/XDecoratedPeer.java
>>>>>>>>>>>>>>> (Avoid miss calculation for window position under 
>>>>>>>>>>>>>>> DTWM/MWM by XMapRaised/XMapWindow)
>>>>>>>>>>>>>>> M src/java.desktop/unix/classes/sun/awt/X11/XWM.java
>>>>>>>>>>>>>>> (Detect MWM on AIX platform)
>>>>>>>>>>>>>>> M 
>>>>>>>>>>>>>>> src/java.desktop/unix/classes/sun/awt/X11/XWindowPeer.java
>>>>>>>>>>>>>>> (Add non-focusable window support on DTWM/MWM for AIX, 
>>>>>>>>>>>>>>> because DTWM/MWM does not have enough features for ICCCM)
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> I appreciate any feedback please, and how I would go 
>>>>>>>>>>>>>>> about obtaining a sponsor and contributor ?
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>>>> Ichiroh Takiguchi
>>>>>>>>>>>>>>> IBM Japan, Ltd.
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> [1] 
>>>>>>>>>>>>>>> https://docs.oracle.com/cd/E19253-01/806-7492/fontsandcolors-15233/index.html
>>>>>>>>>>>>>>> 
>>>>>>>>> 
>>>>>>> 
>> 


From krishna.addepalli at oracle.com  Wed Mar 20 11:18:22 2019
From: krishna.addepalli at oracle.com (Krishna Addepalli)
Date: Wed, 20 Mar 2019 16:48:22 +0530
Subject: <AWT Dev> [13] JDK-8218917: KeyEvent.getModifiers() returns
 inconsistent values for ALT keys
In-Reply-To: <CANTFZ2h7UkaBVqXje7XQ3f-Jrk2Yc30X-T0zXjFNadZ6BCyVbQ@mail.gmail.com>
References: <990B3CDA-E3A0-4051-8771-1AD486094974@oracle.com>
 <CANTFZ2i30ao6fVuVxQseEzF38vBnLUfw3PPadYyKrUCrgfKo9g@mail.gmail.com>
 <6B001F8A-858F-4279-8F42-366F22D49B52@oracle.com>
 <CANTFZ2iUHFNSm9st3d3BLYvERa5OmpOzU+T5e1aoLq5C7YkMfQ@mail.gmail.com>
 <5C8673F6.8060306@oracle.com>
 <6d97202a-ad60-c768-4a31-66ca02f16f70@oracle.com>
 <5C86FF3C.7030700@oracle.com>
 <b842a817-1c61-7d23-a144-41bfc87013a3@oracle.com>
 <CANTFZ2ikTVEP1OcrE415KhRbKr7Bv1XND-UW5tVPOW5+Ube7Jw@mail.gmail.com>
 <7dcf0e9b-cfc8-b985-f60c-10f7fe307825@oracle.com>
 <CANTFZ2h2gc8abosQBJrSNA2tF6cwDQacjpfKp_y1znwkkAU+8w@mail.gmail.com>
 <0c65a2e9-d5b3-eaf0-44eb-2b969de64dac@oracle.com>
 <CANTFZ2gY=h5AyLTu8KPkwyL1_4TvY6jLf9_aqTGBwa0kf5mRdQ@mail.gmail.com>
 <5956470F-019E-40E7-AE6D-9BB9F4E95F19@oracle.com>
 <CANTFZ2jUNuwSfEaRVMSCjVhJ50i9aWYi5V_fZE5aRvVConz3Sw@mail.gmail.com>
 <b8901169-5a6e-cd3d-56d7-d3d2578ff29a@oracle.com>
 <CANTFZ2hUFGyAVuYPxH8ubvpbWypHD4Q2G+oRZKS+Gw=j-H3sdw@mail.gmail.com>
 <6d9a95d4-4ceb-c596-ce8f-6dccbd21dd6e@oracle.com>
 <CANTFZ2h7UkaBVqXje7XQ3f-Jrk2Yc30X-T0zXjFNadZ6BCyVbQ@mail.gmail.com>
Message-ID: <3DDEC8F7-44EE-4C5F-8B69-C411BDD9FA60@oracle.com>

Hi Sergey Malenkov,

We can debate on how to treat the ALTGR_KEY, and can choose to include the behaviour as a system flag.
But, currently, with my fix, the code will behave exactly as in Java 1.8. Even there, when I pressed ALTGR key, after holding ALT key, I observed a KeyEvent 0 being sent.

I would suggest to re-look at my fix which fixes the current problem at hand, and perhaps we can move this discussion under a new bug.

Thanks,
Krishna

> On 18-Mar-2019, at 8:02 PM, Sergey Malenkov <malenkov at gmail.com> wrote:
> 
> Hi Sergey,
> 
> ALT_GRAPH_DOWN_MASK is not the only mask missing in JavaDoc. What is
> about META_DOWN_MASK? What if the developer, who does not care about
> ALT_GRAPH, forget about META too? Guess how your example will work on
> Mac. What is about the WORA slogan?
> 
> I believe that the example in the javadoc is not entirely correct.
> This is just a very simple example, related to the English locale on
> Windows (and possibly on Linux). It should not be used in
> multi-platform code.
> 
> 
> 
> On Sun, Mar 17, 2019 at 1:26 AM Sergey Bylokhov
> <Sergey.Bylokhov at oracle.com <mailto:Sergey.Bylokhov at oracle.com>> wrote:
>> 
>> On 16/03/2019 03:58, Sergey Malenkov wrote:
>>> Your example is synthetic and shows a problem in the one specific
>>> case. I think if you introduce new mask, you have to use it in your
>>> example too. If you add ALT_GRAPH_DOWN_MASK to 'offmask' your example
>>> will not work (that's how processed all shortcuts in Swing and IDEA).
>>> If you add it to 'onmask' the KeyEvent(new Button(), 0, 0,
>>> ALT_GRAPH_DOWN_MASK, 0) will not work.
>> 
>> Your example is good as well, but it shows the opposite, if
>> ALT_GRAPH_DOWN_MASK was used as "onmask" or as "offmask" then it means
>> that this example tries to take care about altGr and it only
>> properly works after the fix. And if the code is unaware about the altGr
>> flag as in previous example it will be ignored.
>> 
>>> Am I right that to support your specific case you have to find and fix
>>> all Alt-based shortcuts in Swing, we should fix all Alt-based
>>> shortcuts in all keymaps in our IDEs and we should notify all our
>>> users that they have to fix all Alt-based shortcuts in their custom
>>> keymaps? The brilliant example of backward compatibility!
>> 
>> I do not remember all changes which were integrated since initially it was done
>> ~4 years ago. But Swing was updated by some changes after that, for example:
>> https://bugs.openjdk.java.net/browse/JDK-8194873
>> 
>>> 
>>>> So if the client will follow the spec below it should work as before, isn't it?:
>>>> https://docs.oracle.com/en/java/javase/11/docs/api/java.desktop/java/awt/event/InputEvent.html#getModifiersEx()
>>> 
>>> If a developer use this method as described his code will be broken
>>> too, because good and attentive developer definitely added
>>> ALT_GRAPH_DOWN_MASK to 'offmask'.
>> 
>> If the user wants to ignore all combinations with "Alternate Character Key"
>> then, as you pointed in the start of this thread, he should ignore both
>> "alt" since on macOS both alt keys are "Alternate Character Key".
>> 
>>> 
>>> On Sat, Mar 16, 2019 at 1:27 AM Sergey Bylokhov
>>> <Sergey.Bylokhov at oracle.com> wrote:
>>>> 
>>>> On 15/03/2019 05:54, Sergey Malenkov wrote:
>>>>> We have a major issue about unexpected AltGr in the keyboard layout
>>>>> that should not have AltGr at all:
>>>>> https://urldefense.proofpoint.com/v2/url?u=http-3A__youtrack.jetbrains.com_issue_IDEA-2D206348&d=DwIFaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=QF7AertWDY_M4hfHg_4S-iyX-aP0wtLYwZFgs0zfX_k&m=j-gQEy4UDmzd3Sa5zjEYskUw4CoYUZ9gDurLkGu1YOo&s=HcCKCq8FPyOoJEvT4qk59DJqCAiRB-BvECy_VCAdpqI&e= <https://urldefense.proofpoint.com/v2/url?u=http-3A__youtrack.jetbrains.com_issue_IDEA-2D206348&d=DwIFaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=QF7AertWDY_M4hfHg_4S-iyX-aP0wtLYwZFgs0zfX_k&m=j-gQEy4UDmzd3Sa5zjEYskUw4CoYUZ9gDurLkGu1YOo&s=HcCKCq8FPyOoJEvT4qk59DJqCAiRB-BvECy_VCAdpqI&e=>
>>>>> Why you decided to support AltGr for every keyboard layout? It really
>>>>> breaks backward compatibility!
>>>> 
>>>> Even in your bug report the people complain that altGr key does not work, and
>>>> the only problem here is that it does not assigned by default.
>>>> But on the other side it is possible to set separate shortcuts
>>>> to the "Alt + Alt Graph + Enter"and "Alt + Enter":
>>>> 
>>>>> I think the main client is Swing and pressed AltGr that looks like
>>>>> 'Alt+AltGr+' breaks all Alt-based shortcuts defined in
>>>>> javax.swing.plaf.basic.BasicLookAndFeel#initComponentDefaults and
>>>>> other places. Now, if you press "alt LEFT", the "moveColumnLeft"
>>>>> action is performed only for the left Alt. And this also breaks a
>>>>> backward compatibility.
>>>> 
>>>> The term "all" is not so critical, there are only few such shortcuts, and it is
>>>> a good thing that potentially we can set different shortcuts for each.
>>>> This is a bug that these places were not updated, it is easy to fix since this
>>>> is not exposed via public API.
>>>> But we will get the same result if we will use the AltGr mask only.
>>>> 
>>>>> It is not backward compatible to use AltGr instead of right Alt in
>>>>> both cases. Instead of 'Alt+key' you will get 'AltGr+key' or
>>>>> 'Alt+AltGr+key', which are not bound to any action.
>>>> 
>>>> It is compatible to the specification of InputEvent.getModifiersEx():
>>>> KeyEvent event = new KeyEvent(new Button(), 0, 0,
>>>>                                ALT_DOWN_MASK | ALT_GRAPH_DOWN_MASK, 0);
>>>>    int onmask =  ALT_DOWN_MASK;
>>>>    int offmask = CTRL_DOWN_MASK|SHIFT_DOWN_MASK;
>>>>    if ((event.getModifiersEx() & (onmask | offmask)) == onmask) {
>>>>      ...
>>>>    }
>>>> 
>>>> The code above works before and after the change for altGr.
>>>> But it will stop working if we will use altGr only, and it will be hard to argue
>>>> why the ALT flag is not set while alt key is pressed(since on some keyboards this key is
>>>> marked as alt and on some other altGr).
>>>> 
>>>> And as specially noted in the method above the code should not assume which
>>>> flags(and how many) were set by the actions, if such assumptions exists in
>>>> Swing itself they should be fixed as well.
>>>> 
>>>>> 
>>>>> On Fri, Mar 15, 2019 at 9:27 AM Krishna Addepalli
>>>>> <krishna.addepalli at oracle.com <mailto:krishna.addepalli at oracle.com>> wrote:
>>>>>> 
>>>>>> Hi Sergey Malenkov,
>>>>>> 
>>>>>>> 'Alt+AltGr+Right' does nothing, because we do not assign this shortcut yet
>>>>>> In my personal experience, I did not find any instance, wherein a shortcut had left and right alt in it.
>>>>>> Although it is not impossible, it seems weird to define such shortcuts.
>>>>>> It would be helpful if you could point to some resources, wherein defining such shortcuts is acceptable.
>>>>>> 
>>>>>> Thanks,
>>>>>> Krishna
>>>>>> 
>>>>>>> On 14-Mar-2019, at 4:03 PM, Sergey Malenkov <malenkov at gmail.com <mailto:malenkov at gmail.com>> wrote:
>>>>>>> 
>>>>>>> I strongly don't like two masks for one key. If you press VK_ALT,
>>>>>>> ALT_DOWN_MASK should be set. If you press VK_SHIFT then,
>>>>>>> SHIFT_DOWN_MASK should be added to indicate that both keys are
>>>>>>> pressed. And if you press VK_ALT_GRAPH, only ALT_GRAPH_DOWN_MASK
>>>>>>> should be added. Otherwise, you can't distinguish the following key
>>>>>>> strokes: 'AltGr+Right' and 'Alt+AltGr+Right'. But these keystrokes are
>>>>>>> different and should invoke different actions. For example,
>>>>>>> 'Alt+Right' moves cursor to the next word
>>>>>>> 'Alt+Shift+Right' moves cursor to the next word AND adds all skipped
>>>>>>> characters to selection
>>>>>>> 'Alt+AltGr+Right' does nothing, because we do not assign this shortcut yet
>>>>>>> 
>>>>>>> On Thu, Mar 14, 2019 at 12:09 AM Sergey Bylokhov
>>>>>>> <Sergey.Bylokhov at oracle.com <mailto:Sergey.Bylokhov at oracle.com>> wrote:
>>>>>>>> 
>>>>>>>> On 13/03/2019 03:59, Sergey Malenkov wrote:
>>>>>>>>> I missed the "for ALT keys" in the bug title and thought that
>>>>>>>>> "KeyEvent.getModifiers() returns inconsistent values" was about
>>>>>>>>> incompatible behaviour on different platforms. In fact, JDK-8218917
>>>>>>>>> should be renamed to something like ?The right Alt key on Mac should
>>>>>>>>> behave as Alt and must not break the left Alt key processing?.
>>>>>>>> 
>>>>>>>> But the "right Alt" should behave like a "left alt" already, it should use both flags:
>>>>>>>> the common alt(ALT_DOWN_MASK) and the altGr(ALT_GRAPH_DOWN_MASK).
>>>>>>>> 
>>>>>>>> So if the client will follow the spec below it should work as before, isn't it?:
>>>>>>>> https://docs.oracle.com/en/java/javase/11/docs/api/java.desktop/java/awt/event/InputEvent.html#getModifiersEx() <https://docs.oracle.com/en/java/javase/11/docs/api/java.desktop/java/awt/event/InputEvent.html#getModifiersEx()>
>>>>>>>> 
>>>>>>>>> On Wed, Mar 13, 2019 at 6:57 AM Sergey Bylokhov
>>>>>>>>> <Sergey.Bylokhov at oracle.com <mailto:Sergey.Bylokhov at oracle.com>> wrote:
>>>>>>>>>> 
>>>>>>>>>> On 12/03/2019 12:28, Sergey Malenkov wrote:
>>>>>>>>>>> Hi Sergey,
>>>>>>>>>>> 
>>>>>>>>>>> 1. macOS uses a regular Alt key as "Alternate Character Key". This is
>>>>>>>>>>> the reason why JDK Toolkit defines Ctrl+Alt to select a mnemonic,
>>>>>>>>>>> instead of simple Alt. See
>>>>>>>>>>> https://urldefense.proofpoint.com/v2/url?u=https-3A__sites.google.com_site_malenkov_java_141229&d=DwIFaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=QF7AertWDY_M4hfHg_4S-iyX-aP0wtLYwZFgs0zfX_k&m=j-gQEy4UDmzd3Sa5zjEYskUw4CoYUZ9gDurLkGu1YOo&s=Y6PcJ4DGp2cSnTLEvtsIdt55_u0F8VqL5LSA7vBPbkw&e= <https://urldefense.proofpoint.com/v2/url?u=https-3A__sites.google.com_site_malenkov_java_141229&d=DwIFaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=QF7AertWDY_M4hfHg_4S-iyX-aP0wtLYwZFgs0zfX_k&m=j-gQEy4UDmzd3Sa5zjEYskUw4CoYUZ9gDurLkGu1YOo&s=Y6PcJ4DGp2cSnTLEvtsIdt55_u0F8VqL5LSA7vBPbkw&e=>
>>>>>>>>>> 
>>>>>>>>>> Right, but introducing this flag for the "left alt" could cause even more
>>>>>>>>>> issues, so this flag is set only for the right.
>>>>>>>>>> 
>>>>>>>>>>> 3. Regression was caused by adding AltGr to key processing on Mac. But
>>>>>>>>>>> I found more issues with inconsistent key processing on different
>>>>>>>>>>> platforms. See https://urldefense.proofpoint.com/v2/url?u=http-3A__sites.google.com_site_malenkov_java_190312&d=DwIFaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=QF7AertWDY_M4hfHg_4S-iyX-aP0wtLYwZFgs0zfX_k&m=j-gQEy4UDmzd3Sa5zjEYskUw4CoYUZ9gDurLkGu1YOo&s=Y7GZdeTQvRyIBxAsCDtaB8PZo9_GRVYIZZvn2VfCzJc&e= <https://urldefense.proofpoint.com/v2/url?u=http-3A__sites.google.com_site_malenkov_java_190312&d=DwIFaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=QF7AertWDY_M4hfHg_4S-iyX-aP0wtLYwZFgs0zfX_k&m=j-gQEy4UDmzd3Sa5zjEYskUw4CoYUZ9gDurLkGu1YOo&s=Y7GZdeTQvRyIBxAsCDtaB8PZo9_GRVYIZZvn2VfCzJc&e=>
>>>>>>>>>> 
>>>>>>>>>> Not sure that CAPS_LOCK is related.
>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> On Tue, Mar 12, 2019 at 4:17 AM Sergey Bylokhov
>>>>>>>>>>> <Sergey.Bylokhov at oracle.com <mailto:Sergey.Bylokhov at oracle.com>> wrote:
>>>>>>>>>>>> 
>>>>>>>>>>>> On 11/03/2019 17:37, Philip Race wrote:
>>>>>>>>>>>>> The debate is about AltGraph which an ancient MS-DOSism for
>>>>>>>>>>>>> asking for an ALTernate GRAPHics bitmap font - all pre-dates windows
>>>>>>>>>>>>> and I am sure has never been applicable to any MacOS.
>>>>>>>>>>>> 
>>>>>>>>>>>> It also about the "right alt" which is also know as "AltGraph". I guess currently
>>>>>>>>>>>> it is implemented as "right alt" on Linux/macOS/windows.
>>>>>>>>>>>> 
>>>>>>>>>>>> BTW on linux it is also named as "Alternative Characters Key":
>>>>>>>>>>>> https://urldefense.proofpoint.com/v2/url?u=https-3A__help.ubuntu.com_community_ComposeKey&d=DwIFaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=QF7AertWDY_M4hfHg_4S-iyX-aP0wtLYwZFgs0zfX_k&m=j-gQEy4UDmzd3Sa5zjEYskUw4CoYUZ9gDurLkGu1YOo&s=DvJtvBcerkulT3S417Vu6hQyXy7e0bI1bX9fInefV-A&e= <https://urldefense.proofpoint.com/v2/url?u=https-3A__help.ubuntu.com_community_ComposeKey&d=DwIFaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=QF7AertWDY_M4hfHg_4S-iyX-aP0wtLYwZFgs0zfX_k&m=j-gQEy4UDmzd3Sa5zjEYskUw4CoYUZ9gDurLkGu1YOo&s=DvJtvBcerkulT3S417Vu6hQyXy7e0bI1bX9fInefV-A&e=>
>>>>>>>>>>>> 
>>>>>>>>>>>>> So someone needs to properly explain why we would claim a Mac keyboard
>>>>>>>>>>>>> is OK to generate a keycode it doesn't have and cause a slew of regressions
>>>>>>>>>>>>> in the process ...>
>>>>>>>>>>>>> If Mac doesn't distinguish these two, we should generate the same keycode for both.
>>>>>>>>>>>> 
>>>>>>>>>>>> The macOS supports "right alt", otherwise it would not be possible to implement it in java:
>>>>>>>>>>>> https://urldefense.proofpoint.com/v2/url?u=https-3A__developer.apple.com_library_archive_technotes_tn2450_-5Findex.html&d=DwIFaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=QF7AertWDY_M4hfHg_4S-iyX-aP0wtLYwZFgs0zfX_k&m=j-gQEy4UDmzd3Sa5zjEYskUw4CoYUZ9gDurLkGu1YOo&s=hD5wMxSuL3iN_tqTn0Cd5ULhp_bGzQl3fFnQQdNXNuU&e= <https://urldefense.proofpoint.com/v2/url?u=https-3A__developer.apple.com_library_archive_technotes_tn2450_-5Findex.html&d=DwIFaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=QF7AertWDY_M4hfHg_4S-iyX-aP0wtLYwZFgs0zfX_k&m=j-gQEy4UDmzd3Sa5zjEYskUw4CoYUZ9gDurLkGu1YOo&s=hD5wMxSuL3iN_tqTn0Cd5ULhp_bGzQl3fFnQQdNXNuU&e=>
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>>> One could suppose there is a difference else why two keys, but what is the right
>>>>>>>>>>>>> thing to do here  that fixes all the problems. What exactly WAS the problem
>>>>>>>>>>>>> with what was there in the first place ? And if changing it is correct why is it
>>>>>>>>>>>>> causing regressions ?
>>>>>>>>>>>> 
>>>>>>>>>>>> Regressions were caused by the bugs in the fix implementation, or am I missed something?
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>>> 
>>>>>>>>>>>>> -phil.
>>>>>>>>>>>>> 
>>>>>>>>>>>>> 
>>>>>>>>>>>>> 
>>>>>>>>>>>>> On 3/12/19, 5:34 AM, Sergey Bylokhov wrote:
>>>>>>>>>>>>>> Hi, Phil.
>>>>>>>>>>>>>> On 11/03/2019 07:43, Philip Race wrote:
>>>>>>>>>>>>>>> The reasoning that AltGraph might be useful to someone is a bit weak
>>>>>>>>>>>>>>> and I don't think I'd want to support it via system property or build options.
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> If its not a platform keyboard key, why do we need it ?
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> The "AltGraph" key is also commonly referred to as "Right Alt", and
>>>>>>>>>>>>>> it has been implemented on all platforms as a "Right Alt", it is convenient to
>>>>>>>>>>>>>> distinguish the left/right alts.
>>>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>> --
>>>>>>>>>>>> Best regards, Sergey.
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> --
>>>>>>>>>> Best regards, Sergey.
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>>> --
>>>>>>>> Best regards, Sergey.
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> --
>>>>>>> Best regards,
>>>>>>> Sergey A. Malenkov
>>>>>> 
>>>>> 
>>>>> 
>>>> 
>>>> 
>>>> --
>>>> Best regards, Sergey.
>>> 
>>> 
>>> 
>> 
>> 
>> --
>> Best regards, Sergey.
> 
> 
> 
> -- 
> Best regards,
> Sergey A. Malenkov

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/awt-dev/attachments/20190320/049da2de/attachment-0001.html>

From Sergey.Bylokhov at oracle.com  Wed Mar 20 22:28:03 2019
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Wed, 20 Mar 2019 15:28:03 -0700
Subject: <AWT Dev> [13] Review Request: 8220495 Update GIFlib library to the
 latest 5.1.8
Message-ID: <037b3455-b3ad-7aab-51d2-5e0b882190c7@oracle.com>

Hello.
Please review the fix for JDK 13.

Bug: https://bugs.openjdk.java.net/browse/JDK-8220495
Fix: http://cr.openjdk.java.net/~serb/8220495/webrev.02

The giflib was updated from 5.1.4 to 5.1.8.

The is mostly a replacement of old files(5.1.4) by the new files(5.1.8) except two additional steps.
  - The library uses "<unistd.h>" which breaks the build on windows, and "<stdbool.h>" wihch does not work properly on old Solaris.
    It was fixed by this patch(same as in 5.1.4 during previous upgrade):
    http://cr.openjdk.java.net/~serb/8220495/giflib

  - I have drop the usage of "tabs" and manually reformat the code to make the diff smaller.

Mach5 on all platforms is green.

-- 
Best regards, Sergey.

From philip.race at oracle.com  Wed Mar 20 22:45:15 2019
From: philip.race at oracle.com (Philip Race)
Date: Wed, 20 Mar 2019 15:45:15 -0700
Subject: <AWT Dev> [13] Review Request: 8220495 Update GIFlib library to
 the latest 5.1.8
In-Reply-To: <037b3455-b3ad-7aab-51d2-5e0b882190c7@oracle.com>
References: <037b3455-b3ad-7aab-51d2-5e0b882190c7@oracle.com>
Message-ID: <5C92C27B.7090209@oracle.com>

I am surprised that giflib does not build on windows, we can't
be the only people using it on windows ?

Except for the legal header, I think your "patches" should be
inside a platform ifdef to show exactly where they are needed
and also be bracketed by comments

So something like this :
/** Begin JDK modifications to support building on Solaris **/
#ifdef SOLARIS
..
#endif /* SOLARIS */
/** End JDK modifications to support building on Solaris **/

-phil.


On 3/20/19, 3:28 PM, Sergey Bylokhov wrote:
> Hello.
> Please review the fix for JDK 13.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8220495
> Fix: http://cr.openjdk.java.net/~serb/8220495/webrev.02
>
> The giflib was updated from 5.1.4 to 5.1.8.
>
> The is mostly a replacement of old files(5.1.4) by the new 
> files(5.1.8) except two additional steps.
>  - The library uses "<unistd.h>" which breaks the build on windows, 
> and "<stdbool.h>" wihch does not work properly on old Solaris.
>    It was fixed by this patch(same as in 5.1.4 during previous upgrade):
>    http://cr.openjdk.java.net/~serb/8220495/giflib
>
>  - I have drop the usage of "tabs" and manually reformat the code to 
> make the diff smaller.
>
> Mach5 on all platforms is green.
>

From Sergey.Bylokhov at oracle.com  Wed Mar 20 22:51:28 2019
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Wed, 20 Mar 2019 15:51:28 -0700
Subject: <AWT Dev> [13] Review Request: 8220495 Update GIFlib library to
 the latest 5.1.8
In-Reply-To: <5C92C27B.7090209@oracle.com>
References: <037b3455-b3ad-7aab-51d2-5e0b882190c7@oracle.com>
 <5C92C27B.7090209@oracle.com>
Message-ID: <0d419571-30b4-3da0-36ba-7319bc5bb021@oracle.com>

On 20/03/2019 15:45, Philip Race wrote:
> Except for the legal header, I think your "patches" should be
> inside a platform ifdef to show exactly where they are needed
> and also be bracketed by comments

Note that this patch is not visible in the main webrev, because it is not
"my patch", it is already in our repo. I just highlighted it.
It could be build using custom unistd.h or unistd.h from the cygwin/mingw.

> So something like this :
> /** Begin JDK modifications to support building on Solaris **/
> #ifdef SOLARIS
> ..
> #endif /* SOLARIS */
> /** End JDK modifications to support building on Solaris **/

Will update the patch.

> 
> -phil.
> 
> 
> On 3/20/19, 3:28 PM, Sergey Bylokhov wrote:
>> Hello.
>> Please review the fix for JDK 13.
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8220495
>> Fix: http://cr.openjdk.java.net/~serb/8220495/webrev.02
>>
>> The giflib was updated from 5.1.4 to 5.1.8.
>>
>> The is mostly a replacement of old files(5.1.4) by the new files(5.1.8) except two additional steps.
>> ?- The library uses "<unistd.h>" which breaks the build on windows, and "<stdbool.h>" wihch does not work properly on old Solaris.
>> ?? It was fixed by this patch(same as in 5.1.4 during previous upgrade):
>> ?? http://cr.openjdk.java.net/~serb/8220495/giflib
>>
>> ?- I have drop the usage of "tabs" and manually reformat the code to make the diff smaller.
>>
>> Mach5 on all platforms is green.
>>


-- 
Best regards, Sergey.

From Sergey.Bylokhov at oracle.com  Wed Mar 20 22:56:55 2019
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Wed, 20 Mar 2019 15:56:55 -0700
Subject: <AWT Dev> RFR: 8212676 java.awt.SystemColor setting on CDE
In-Reply-To: <5c62bbea9c6a2550b4f960708c38c856@linux.vnet.ibm.com>
References: <5f309d9c612f2c16aef75846e0ff14fa@linux.vnet.ibm.com>
 <d2b3bc94-0ba3-712f-c46b-f83048491cb0@oracle.com>
 <f942c133e212bace34e72e79bfb64ab4@linux.vnet.ibm.com>
 <0ede447e30ed05ce7a52f6d133b2c15b@linux.vnet.ibm.com>
 <180114e58e98f339332e3a781a34126b@linux.vnet.ibm.com>
 <d9e8c69e64ff87bb84a9468b4364fb06@linux.vnet.ibm.com>
 <5a4f9f5c7a80a5abda9edd150e19a11f@linux.vnet.ibm.com>
 <4addeebf-9ed8-bb63-5920-49ae6fb429b1@oracle.com>
 <c314e88dcc25495f6fba698f8ad5ae63@linux.vnet.ibm.com>
 <5C0725B5.3080907@oracle.com> <5C0773E7.8030108@oracle.com>
 <ad8f6c895b66c65a0b7bc344c5a759e0@linux.vnet.ibm.com>
 <13a9685a38984c56ec2f0aaa084a3f80@linux.vnet.ibm.com>
 <368b32e110b608570c4929e216ee37c6@linux.vnet.ibm.com>
 <10ad0a1a-b4ad-3978-fab0-87c28005a879@oracle.com>
 <5c62bbea9c6a2550b4f960708c38c856@linux.vnet.ibm.com>
Message-ID: <38f580c8-8945-618e-baef-3d2447ac0662@oracle.com>

Looks fine.
Thank you for contribution!

On 19/03/2019 10:22, Ichiroh Takiguchi wrote:
> Hello Sergey.
> 
> Thank you for your suggestion.
> I changed Subject.
> From: AIX's CDE/MWM support
> To: AWT SystemColor setting on CDE
> 
> Could you review the fix and give me your suggestion again ?
> 
> Bug:??? https://bugs.openjdk.java.net/browse/JDK-8212676
> Change: https://cr.openjdk.java.net/~itakiguchi/8212676/webrev.02/
> 
> For AIX dtwm/mwm issue, I opened JDK-8221082 [1].
> 
> [1]? https://bugs.openjdk.java.net/browse/JDK-8221082
> 
> Thanks,
> Ichiroh Takiguchi
> 
> On 2019-03-19 08:42, Sergey Bylokhov wrote:
>> Hi, Ichiroh.
>>
>> It looks fine, but I have one general comment: this fix is not about
>> some general support of "AIX's CDE/MWM", but it is mostly about
>> initialization of "java.awt.SystemColor", which is already used by the
>> awt/swing.
>>
>> On 11/03/2019 19:04, Ichiroh Takiguchi wrote:
>>> Hello.
>>>
>>> Could you review the fix and give me your suggestion, please ?
>>>
>>> Thanks,
>>> Ichiroh Takiguchi
>>>
>>> On 2019-03-01 22:16, Ichiroh Takiguchi wrote:
>>>> Hello.
>>>>
>>>> Could you review the fix again ?
>>>>
>>>> Bug:??? https://bugs.openjdk.java.net/browse/JDK-8212676
>>>> Change: https://cr.openjdk.java.net/~itakiguchi/8212676/webrev.01/
>>>>
>>>> I applied following changes:
>>>> * I added AIX detection code into sun.awt.OSInfo class.
>>>> ? It seems CDE's default should be middle color.
>>>> ? But AIX's default is high color, so AIX detection code is required.
>>>> * MWM detection code can be used on Linux and AIX platform
>>>> ? AIX only code was removed
>>>> * I could not recreate XMapRaised/XMapWindow related issue.
>>>> ? The fix was ignored
>>>> * Non-focusable window handling on DTWM/MWM
>>>> ? I checked Linux's MWM working behavior on RHEL6.
>>>> ? I applied AIX's code into Linux side, but it was bad.
>>>> ? Working behavior became worse.
>>>> ? So AIX detection feature is still required.
>>>>
>>>> (JDK-8212676 was also updated)
>>>>
>>>> I'd like to obtain a sponsor for this issue.
>>>>
>>>> Thanks,
>>>> Ichiroh Takiguchi
>>>> IBM Japan, Ltd.
>>>>
>>>> On 2018-12-05 18:22, Ichiroh Takiguchi wrote:
>>>>> Hello Phil.
>>>>>
>>>>> I heard some of AIX users used RealVNC VNC Enterprise Edition for AIX
>>>>> maintenance. [1]
>>>>> I assume they still use CDE.
>>>>>
>>>>> [1] https://www.realvnc.com/en/connect/download/vnc/aix/#older-versions
>>>>>
>>>>> Thanks,
>>>>> Ichiroh Takiguchi
>>>>>
>>>>> On 2018-12-05 15:44, Philip Race wrote:
>>>>>> . and I think I need to be convinced about whether "aix" is the right
>>>>>> thing to check here.
>>>>>> "I know AIX works like this today" isn't a very robust, or very
>>>>>> portable approach.
>>>>>> The fix is more about the CDE/Motif environment than AIX, isn't it ?
>>>>>>
>>>>>> -phil.
>>>>>>
>>>>>>
>>>>>> On 12/4/18, 5:11 PM, Philip Race wrote:
>>>>>>>
>>>>>>>
>>>>>>> On 12/4/18, 5:10 PM, Ichiroh Takiguchi wrote:
>>>>>>>> Hello Phil.
>>>>>>>>
>>>>>>>>> I haven't evaluated the merits of this proposal but this
>>>>>>>>> https://cr.openjdk.java.net/~itakiguchi/8212676/webrev.00/src/java.desktop/share/classes/sun/font/FontUtilities.java.udiff.html is not the right place to support a flag used in all these X11 files.
>>>>>>>> Could you give me your recommendation ?
>>>>>>>
>>>>>>> Somewhere closer to the code that needs it.
>>>>>>>>
>>>>>>>>> And why is i18n-dev on the review ? I can't see any I18N related changes.
>>>>>>>> I thought focus issue was related input method.
>>>>>>>
>>>>>>> No. I mean input focus is necessary for input methods but focus does not
>>>>>>> automatically mean input methods are in play.
>>>>>>>
>>>>>>> -phil
>>>>>>>
>>>>>>>> AIX IM was activated even if focus was moved to non focusable window (middle window). [1]
>>>>>>>> So I posted this issue into I18N, but it was not good.
>>>>>>>> Actually, all key events were forwarded to middle window if user clicked inside of right window.
>>>>>>>>
>>>>>>>> [1] https://bugs.openjdk.java.net/secure/attachment/79986/aix-focusable.png
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>> Ichiroh Takiguchi
>>>>>>>>
>>>>>>>> On 2018-12-05 03:06, Phil Race wrote:
>>>>>>>>> I haven't evaluated the merits of this proposal but this
>>>>>>>>> https://cr.openjdk.java.net/~itakiguchi/8212676/webrev.00/src/java.desktop/share/classes/sun/font/FontUtilities.java.udiff.html is not the right place to support a flag used in all these X11 files.
>>>>>>>>>
>>>>>>>>> And why is i18n-dev on the review ? I can't see any I18N related changes.
>>>>>>>>>
>>>>>>>>> -phil.
>>>>>>>>>
>>>>>>>>> On 12/4/18 8:53 AM, Ichiroh Takiguchi wrote:
>>>>>>>>>> Hello again.
>>>>>>>>>>
>>>>>>>>>> Could you give me review comment and/or suggestion ?
>>>>>>>>>>
>>>>>>>>>> Bug:??? https://bugs.openjdk.java.net/browse/JDK-8212676
>>>>>>>>>> Change: https://cr.openjdk.java.net/~itakiguchi/8212676/webrev.00/
>>>>>>>>>>
>>>>>>>>>> Thanks,
>>>>>>>>>> Ichiroh Takiguchi
>>>>>>>>>>
>>>>>>>>>> On 2018-11-26 21:27, Ichiroh Takiguchi wrote:
>>>>>>>>>>> Hello.
>>>>>>>>>>>
>>>>>>>>>>> Could you review the fix ?
>>>>>>>>>>>
>>>>>>>>>>> Bug:??? https://bugs.openjdk.java.net/browse/JDK-8212676
>>>>>>>>>>> Change: https://cr.openjdk.java.net/~itakiguchi/8212676/webrev.00/
>>>>>>>>>>>
>>>>>>>>>>> Test instructions and screen shots are in JDK-8212676.
>>>>>>>>>>>
>>>>>>>>>>> GUI environment for AIX platform still needs CDE support.
>>>>>>>>>>> This fix is required to avoid unexpected working behavior on AIX platform.
>>>>>>>>>>>
>>>>>>>>>>> I'd like to obtain a sponsor for this issue.
>>>>>>>>>>>
>>>>>>>>>>> Thanks,
>>>>>>>>>>> Ichiroh Takiguchi
>>>>>>>>>>> IBM Japan, Ltd.
>>>>>>>>>>>
>>>>>>>>>>> On 2018-06-18 18:57, Ichiroh Takiguchi wrote:
>>>>>>>>>>>> Hello.
>>>>>>>>>>>>
>>>>>>>>>>>> This fix is really required for AIX's GUI.
>>>>>>>>>>>> System color setting and window manager's working behavior are very important.
>>>>>>>>>>>>
>>>>>>>>>>>> I appreciate any feedback, and how I would go about obtaining a
>>>>>>>>>>>> sponsor and contributor ?
>>>>>>>>>>>>
>>>>>>>>>>>> On 2018-05-25 11:02, Ichiroh Takiguchi wrote:
>>>>>>>>>>>>> Hello Phil.
>>>>>>>>>>>>>
>>>>>>>>>>>>> webrev file was extracted.
>>>>>>>>>>>>> Please see
>>>>>>>>>>>>> ? http://cr.openjdk.java.net/~aleonard/AIX_GUI/webrev.00/
>>>>>>>>>>>>>
>>>>>>>>>>>>> On 2018-05-19 02:48, Ichiroh Takiguchi wrote:
>>>>>>>>>>>>>> Hello Phil.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Webrev.zip file is stored into
>>>>>>>>>>>>>> http://cr.openjdk.java.net/~aleonard/AIX_GUI/webrev-aixgui.zip
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Test programs are also stored:
>>>>>>>>>>>>>> No testcase is available for FontUtilities.java and XDecoratedPeer.java.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> MotifColorUtilities.java
>>>>>>>>>>>>>> http://cr.openjdk.java.net/~aleonard/AIX_GUI/SystemColorTest2.java
>>>>>>>>>>>>>> Run SystemColorTest2, system colors should be displayed
>>>>>>>>>>>>>> AIX sample is
>>>>>>>>>>>>>> http://cr.openjdk.java.net/~aleonard/AIX_GUI/aix_systemcolor.txt
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> XWM.java
>>>>>>>>>>>>>> http://cr.openjdk.java.net/~aleonard/AIX_GUI/XWMTest1.java
>>>>>>>>>>>>>> On AIX CDE, isMotif and isCDE were true.
>>>>>>>>>>>>>> On AIX MWM, every entry is false.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> XWindowPeer.java
>>>>>>>>>>>>>> http://cr.openjdk.java.net/~aleonard/AIX_GUI/JFrameTest.java
>>>>>>>>>>>>>> On AIX CDE, click inside of "Non-Focusable" window (not window frame).
>>>>>>>>>>>>>> Window focus should not be changed because of "click on focus" feature.
>>>>>>>>>>>>>> But input focus is moved to "Non-Focusable" window.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On 2018-05-18 01:00, Phil Race wrote:
>>>>>>>>>>>>>>> I think we'd need to see the actual proposed changes and understand
>>>>>>>>>>>>>>> the implications
>>>>>>>>>>>>>>> for ongoing support as we no longer support any platform which has a
>>>>>>>>>>>>>>> CDE desktop.
>>>>>>>>>>>>>>> Solaris 11.3 uses Gnome, so we'd be more inclined to be ripping out
>>>>>>>>>>>>>>> such support rather
>>>>>>>>>>>>>>> than adding to it.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> -phil.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> On 05/17/2018 04:18 AM, Ichiroh Takiguchi wrote:
>>>>>>>>>>>>>>>> Hello,
>>>>>>>>>>>>>>>> IBM would like to contribute AIX's CDE (Common Desktop Environment) DTWM (Desktop Window Manager) /MWM (Motif Window Manager) support to OpenJDK project.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> I'd like contribute following 5 files:
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> M src/java.desktop/share/classes/sun/font/FontUtilities.java
>>>>>>>>>>>>>>>> (Add isAIX flag to determine AIX platform for GUI environment)
>>>>>>>>>>>>>>>> M src/java.desktop/unix/classes/sun/awt/X11/MotifColorUtilities.java (Add High Color support on CDE, OpenJDK just supports Medium Color) [1]
>>>>>>>>>>>>>>>> M src/java.desktop/unix/classes/sun/awt/X11/XDecoratedPeer.java
>>>>>>>>>>>>>>>> (Avoid miss calculation for window position under DTWM/MWM by XMapRaised/XMapWindow)
>>>>>>>>>>>>>>>> M src/java.desktop/unix/classes/sun/awt/X11/XWM.java
>>>>>>>>>>>>>>>> (Detect MWM on AIX platform)
>>>>>>>>>>>>>>>> M src/java.desktop/unix/classes/sun/awt/X11/XWindowPeer.java
>>>>>>>>>>>>>>>> (Add non-focusable window support on DTWM/MWM for AIX, because DTWM/MWM does not have enough features for ICCCM)
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> I appreciate any feedback please, and how I would go about obtaining a sponsor and contributor ?
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>>>>> Ichiroh Takiguchi
>>>>>>>>>>>>>>>> IBM Japan, Ltd.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> [1] https://docs.oracle.com/cd/E19253-01/806-7492/fontsandcolors-15233/index.html
>>>>>>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>
>>>
> 


-- 
Best regards, Sergey.

From philip.race at oracle.com  Wed Mar 20 23:03:24 2019
From: philip.race at oracle.com (Philip Race)
Date: Wed, 20 Mar 2019 16:03:24 -0700
Subject: <AWT Dev> [13] Review Request: 8220495 Update GIFlib library to
 the latest 5.1.8
In-Reply-To: <0d419571-30b4-3da0-36ba-7319bc5bb021@oracle.com>
References: <037b3455-b3ad-7aab-51d2-5e0b882190c7@oracle.com>
 <5C92C27B.7090209@oracle.com>
 <0d419571-30b4-3da0-36ba-7319bc5bb021@oracle.com>
Message-ID: <5C92C6BC.2030207@oracle.com>



On 3/20/19, 3:51 PM, Sergey Bylokhov wrote:
> On 20/03/2019 15:45, Philip Race wrote:
>> Except for the legal header, I think your "patches" should be
>> inside a platform ifdef to show exactly where they are needed
>> and also be bracketed by comments
>
> Note that this patch is not visible in the main webrev, because it is not
> "my patch", it is already in our repo. I just highlighted it.

I understood that.

> It could be build using custom unistd.h or unistd.h from the 
> cygwin/mingw.

That could be it.

-phil.

>
>> So something like this :
>> /** Begin JDK modifications to support building on Solaris **/
>> #ifdef SOLARIS
>> ..
>> #endif /* SOLARIS */
>> /** End JDK modifications to support building on Solaris **/
>
> Will update the patch.
>
>>
>> -phil.
>>
>>
>> On 3/20/19, 3:28 PM, Sergey Bylokhov wrote:
>>> Hello.
>>> Please review the fix for JDK 13.
>>>
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8220495
>>> Fix: http://cr.openjdk.java.net/~serb/8220495/webrev.02
>>>
>>> The giflib was updated from 5.1.4 to 5.1.8.
>>>
>>> The is mostly a replacement of old files(5.1.4) by the new 
>>> files(5.1.8) except two additional steps.
>>>  - The library uses "<unistd.h>" which breaks the build on windows, 
>>> and "<stdbool.h>" wihch does not work properly on old Solaris.
>>>    It was fixed by this patch(same as in 5.1.4 during previous 
>>> upgrade):
>>>    http://cr.openjdk.java.net/~serb/8220495/giflib
>>>
>>>  - I have drop the usage of "tabs" and manually reformat the code to 
>>> make the diff smaller.
>>>
>>> Mach5 on all platforms is green.
>>>
>
>

From Sergey.Bylokhov at oracle.com  Thu Mar 21 00:52:30 2019
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Wed, 20 Mar 2019 17:52:30 -0700
Subject: <AWT Dev> [13] JDK-8218917: KeyEvent.getModifiers() returns
 inconsistent values for ALT keys
In-Reply-To: <CANTFZ2h7UkaBVqXje7XQ3f-Jrk2Yc30X-T0zXjFNadZ6BCyVbQ@mail.gmail.com>
References: <990B3CDA-E3A0-4051-8771-1AD486094974@oracle.com>
 <CANTFZ2iUHFNSm9st3d3BLYvERa5OmpOzU+T5e1aoLq5C7YkMfQ@mail.gmail.com>
 <5C8673F6.8060306@oracle.com>
 <6d97202a-ad60-c768-4a31-66ca02f16f70@oracle.com>
 <5C86FF3C.7030700@oracle.com>
 <b842a817-1c61-7d23-a144-41bfc87013a3@oracle.com>
 <CANTFZ2ikTVEP1OcrE415KhRbKr7Bv1XND-UW5tVPOW5+Ube7Jw@mail.gmail.com>
 <7dcf0e9b-cfc8-b985-f60c-10f7fe307825@oracle.com>
 <CANTFZ2h2gc8abosQBJrSNA2tF6cwDQacjpfKp_y1znwkkAU+8w@mail.gmail.com>
 <0c65a2e9-d5b3-eaf0-44eb-2b969de64dac@oracle.com>
 <CANTFZ2gY=h5AyLTu8KPkwyL1_4TvY6jLf9_aqTGBwa0kf5mRdQ@mail.gmail.com>
 <5956470F-019E-40E7-AE6D-9BB9F4E95F19@oracle.com>
 <CANTFZ2jUNuwSfEaRVMSCjVhJ50i9aWYi5V_fZE5aRvVConz3Sw@mail.gmail.com>
 <b8901169-5a6e-cd3d-56d7-d3d2578ff29a@oracle.com>
 <CANTFZ2hUFGyAVuYPxH8ubvpbWypHD4Q2G+oRZKS+Gw=j-H3sdw@mail.gmail.com>
 <6d9a95d4-4ceb-c596-ce8f-6dccbd21dd6e@oracle.com>
 <CANTFZ2h7UkaBVqXje7XQ3f-Jrk2Yc30X-T0zXjFNadZ6BCyVbQ@mail.gmail.com>
Message-ID: <cb957518-228d-3187-4cd5-35c1d07c3119@oracle.com>

On 18/03/2019 07:32, Sergey Malenkov wrote:
> Hi Sergey,
> 
> ALT_GRAPH_DOWN_MASK is not the only mask missing in JavaDoc. What is
> about META_DOWN_MASK? What if the developer, who does not care about
> ALT_GRAPH, forget about META too? Guess how your example will work on
> Mac. What is about the WORA slogan?

I am not sure what does it meant "forget about Meta", if the code does not care
about "altGr"/"meta/mouse_buttons" it should not use it as off/onnmask and as a result it should ignore it.
BTW it is not missed in the JavaDoc:
https://docs.oracle.com/en/java/javase/11/docs/api/java.desktop/java/awt/event/InputEvent.html#field.summary

> I believe that the example in the javadoc is not entirely correct.

Why it is incorrect?

> This is just a very simple example, related to the English locale on
> Windows (and possibly on Linux). It should not be used in
> multi-platform code.
> 
> 
> 
> On Sun, Mar 17, 2019 at 1:26 AM Sergey Bylokhov
> <Sergey.Bylokhov at oracle.com> wrote:
>>
>> On 16/03/2019 03:58, Sergey Malenkov wrote:
>>> Your example is synthetic and shows a problem in the one specific
>>> case. I think if you introduce new mask, you have to use it in your
>>> example too. If you add ALT_GRAPH_DOWN_MASK to 'offmask' your example
>>> will not work (that's how processed all shortcuts in Swing and IDEA).
>>> If you add it to 'onmask' the KeyEvent(new Button(), 0, 0,
>>> ALT_GRAPH_DOWN_MASK, 0) will not work.
>>
>> Your example is good as well, but it shows the opposite, if
>> ALT_GRAPH_DOWN_MASK was used as "onmask" or as "offmask" then it means
>> that this example tries to take care about altGr and it only
>> properly works after the fix. And if the code is unaware about the altGr
>> flag as in previous example it will be ignored.
>>
>>> Am I right that to support your specific case you have to find and fix
>>> all Alt-based shortcuts in Swing, we should fix all Alt-based
>>> shortcuts in all keymaps in our IDEs and we should notify all our
>>> users that they have to fix all Alt-based shortcuts in their custom
>>> keymaps? The brilliant example of backward compatibility!
>>
>> I do not remember all changes which were integrated since initially it was done
>> ~4 years ago. But Swing was updated by some changes after that, for example:
>> https://bugs.openjdk.java.net/browse/JDK-8194873
>>
>>>
>>>> So if the client will follow the spec below it should work as before, isn't it?:
>>>> https://docs.oracle.com/en/java/javase/11/docs/api/java.desktop/java/awt/event/InputEvent.html#getModifiersEx()
>>>
>>> If a developer use this method as described his code will be broken
>>> too, because good and attentive developer definitely added
>>> ALT_GRAPH_DOWN_MASK to 'offmask'.
>>
>> If the user wants to ignore all combinations with "Alternate Character Key"
>> then, as you pointed in the start of this thread, he should ignore both
>> "alt" since on macOS both alt keys are "Alternate Character Key".
>>
>>>
>>> On Sat, Mar 16, 2019 at 1:27 AM Sergey Bylokhov
>>> <Sergey.Bylokhov at oracle.com> wrote:
>>>>
>>>> On 15/03/2019 05:54, Sergey Malenkov wrote:
>>>>> We have a major issue about unexpected AltGr in the keyboard layout
>>>>> that should not have AltGr at all:
>>>>> http://youtrack.jetbrains.com/issue/IDEA-206348
>>>>> Why you decided to support AltGr for every keyboard layout? It really
>>>>> breaks backward compatibility!
>>>>
>>>> Even in your bug report the people complain that altGr key does not work, and
>>>> the only problem here is that it does not assigned by default.
>>>> But on the other side it is possible to set separate shortcuts
>>>> to the "Alt + Alt Graph + Enter"and "Alt + Enter":
>>>>
>>>>> I think the main client is Swing and pressed AltGr that looks like
>>>>> 'Alt+AltGr+' breaks all Alt-based shortcuts defined in
>>>>> javax.swing.plaf.basic.BasicLookAndFeel#initComponentDefaults and
>>>>> other places. Now, if you press "alt LEFT", the "moveColumnLeft"
>>>>> action is performed only for the left Alt. And this also breaks a
>>>>> backward compatibility.
>>>>
>>>> The term "all" is not so critical, there are only few such shortcuts, and it is
>>>> a good thing that potentially we can set different shortcuts for each.
>>>> This is a bug that these places were not updated, it is easy to fix since this
>>>> is not exposed via public API.
>>>> But we will get the same result if we will use the AltGr mask only.
>>>>
>>>>> It is not backward compatible to use AltGr instead of right Alt in
>>>>> both cases. Instead of 'Alt+key' you will get 'AltGr+key' or
>>>>> 'Alt+AltGr+key', which are not bound to any action.
>>>>
>>>> It is compatible to the specification of InputEvent.getModifiersEx():
>>>> KeyEvent event = new KeyEvent(new Button(), 0, 0,
>>>>                                  ALT_DOWN_MASK | ALT_GRAPH_DOWN_MASK, 0);
>>>>      int onmask =  ALT_DOWN_MASK;
>>>>      int offmask = CTRL_DOWN_MASK|SHIFT_DOWN_MASK;
>>>>      if ((event.getModifiersEx() & (onmask | offmask)) == onmask) {
>>>>        ...
>>>>      }
>>>>
>>>> The code above works before and after the change for altGr.
>>>> But it will stop working if we will use altGr only, and it will be hard to argue
>>>> why the ALT flag is not set while alt key is pressed(since on some keyboards this key is
>>>> marked as alt and on some other altGr).
>>>>
>>>> And as specially noted in the method above the code should not assume which
>>>> flags(and how many) were set by the actions, if such assumptions exists in
>>>> Swing itself they should be fixed as well.
>>>>
>>>>>
>>>>> On Fri, Mar 15, 2019 at 9:27 AM Krishna Addepalli
>>>>> <krishna.addepalli at oracle.com> wrote:
>>>>>>
>>>>>> Hi Sergey Malenkov,
>>>>>>
>>>>>>> 'Alt+AltGr+Right' does nothing, because we do not assign this shortcut yet
>>>>>> In my personal experience, I did not find any instance, wherein a shortcut had left and right alt in it.
>>>>>> Although it is not impossible, it seems weird to define such shortcuts.
>>>>>> It would be helpful if you could point to some resources, wherein defining such shortcuts is acceptable.
>>>>>>
>>>>>> Thanks,
>>>>>> Krishna
>>>>>>
>>>>>>> On 14-Mar-2019, at 4:03 PM, Sergey Malenkov <malenkov at gmail.com> wrote:
>>>>>>>
>>>>>>> I strongly don't like two masks for one key. If you press VK_ALT,
>>>>>>> ALT_DOWN_MASK should be set. If you press VK_SHIFT then,
>>>>>>> SHIFT_DOWN_MASK should be added to indicate that both keys are
>>>>>>> pressed. And if you press VK_ALT_GRAPH, only ALT_GRAPH_DOWN_MASK
>>>>>>> should be added. Otherwise, you can't distinguish the following key
>>>>>>> strokes: 'AltGr+Right' and 'Alt+AltGr+Right'. But these keystrokes are
>>>>>>> different and should invoke different actions. For example,
>>>>>>> 'Alt+Right' moves cursor to the next word
>>>>>>> 'Alt+Shift+Right' moves cursor to the next word AND adds all skipped
>>>>>>> characters to selection
>>>>>>> 'Alt+AltGr+Right' does nothing, because we do not assign this shortcut yet
>>>>>>>
>>>>>>> On Thu, Mar 14, 2019 at 12:09 AM Sergey Bylokhov
>>>>>>> <Sergey.Bylokhov at oracle.com> wrote:
>>>>>>>>
>>>>>>>> On 13/03/2019 03:59, Sergey Malenkov wrote:
>>>>>>>>> I missed the "for ALT keys" in the bug title and thought that
>>>>>>>>> "KeyEvent.getModifiers() returns inconsistent values" was about
>>>>>>>>> incompatible behaviour on different platforms. In fact, JDK-8218917
>>>>>>>>> should be renamed to something like ?The right Alt key on Mac should
>>>>>>>>> behave as Alt and must not break the left Alt key processing?.
>>>>>>>>
>>>>>>>> But the "right Alt" should behave like a "left alt" already, it should use both flags:
>>>>>>>> the common alt(ALT_DOWN_MASK) and the altGr(ALT_GRAPH_DOWN_MASK).
>>>>>>>>
>>>>>>>> So if the client will follow the spec below it should work as before, isn't it?:
>>>>>>>> https://docs.oracle.com/en/java/javase/11/docs/api/java.desktop/java/awt/event/InputEvent.html#getModifiersEx()
>>>>>>>>
>>>>>>>>> On Wed, Mar 13, 2019 at 6:57 AM Sergey Bylokhov
>>>>>>>>> <Sergey.Bylokhov at oracle.com> wrote:
>>>>>>>>>>
>>>>>>>>>> On 12/03/2019 12:28, Sergey Malenkov wrote:
>>>>>>>>>>> Hi Sergey,
>>>>>>>>>>>
>>>>>>>>>>> 1. macOS uses a regular Alt key as "Alternate Character Key". This is
>>>>>>>>>>> the reason why JDK Toolkit defines Ctrl+Alt to select a mnemonic,
>>>>>>>>>>> instead of simple Alt. See
>>>>>>>>>>> https://sites.google.com/site/malenkov/java/141229
>>>>>>>>>>
>>>>>>>>>> Right, but introducing this flag for the "left alt" could cause even more
>>>>>>>>>> issues, so this flag is set only for the right.
>>>>>>>>>>
>>>>>>>>>>> 3. Regression was caused by adding AltGr to key processing on Mac. But
>>>>>>>>>>> I found more issues with inconsistent key processing on different
>>>>>>>>>>> platforms. See http://sites.google.com/site/malenkov/java/190312
>>>>>>>>>>
>>>>>>>>>> Not sure that CAPS_LOCK is related.
>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> On Tue, Mar 12, 2019 at 4:17 AM Sergey Bylokhov
>>>>>>>>>>> <Sergey.Bylokhov at oracle.com> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>> On 11/03/2019 17:37, Philip Race wrote:
>>>>>>>>>>>>> The debate is about AltGraph which an ancient MS-DOSism for
>>>>>>>>>>>>> asking for an ALTernate GRAPHics bitmap font - all pre-dates windows
>>>>>>>>>>>>> and I am sure has never been applicable to any MacOS.
>>>>>>>>>>>>
>>>>>>>>>>>> It also about the "right alt" which is also know as "AltGraph". I guess currently
>>>>>>>>>>>> it is implemented as "right alt" on Linux/macOS/windows.
>>>>>>>>>>>>
>>>>>>>>>>>> BTW on linux it is also named as "Alternative Characters Key":
>>>>>>>>>>>> https://help.ubuntu.com/community/ComposeKey
>>>>>>>>>>>>
>>>>>>>>>>>>> So someone needs to properly explain why we would claim a Mac keyboard
>>>>>>>>>>>>> is OK to generate a keycode it doesn't have and cause a slew of regressions
>>>>>>>>>>>>> in the process ...>
>>>>>>>>>>>>> If Mac doesn't distinguish these two, we should generate the same keycode for both.
>>>>>>>>>>>>
>>>>>>>>>>>> The macOS supports "right alt", otherwise it would not be possible to implement it in java:
>>>>>>>>>>>> https://developer.apple.com/library/archive/technotes/tn2450/_index.html
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>> One could suppose there is a difference else why two keys, but what is the right
>>>>>>>>>>>>> thing to do here  that fixes all the problems. What exactly WAS the problem
>>>>>>>>>>>>> with what was there in the first place ? And if changing it is correct why is it
>>>>>>>>>>>>> causing regressions ?
>>>>>>>>>>>>
>>>>>>>>>>>> Regressions were caused by the bugs in the fix implementation, or am I missed something?
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> -phil.
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> On 3/12/19, 5:34 AM, Sergey Bylokhov wrote:
>>>>>>>>>>>>>> Hi, Phil.
>>>>>>>>>>>>>> On 11/03/2019 07:43, Philip Race wrote:
>>>>>>>>>>>>>>> The reasoning that AltGraph might be useful to someone is a bit weak
>>>>>>>>>>>>>>> and I don't think I'd want to support it via system property or build options.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> If its not a platform keyboard key, why do we need it ?
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> The "AltGraph" key is also commonly referred to as "Right Alt", and
>>>>>>>>>>>>>> it has been implemented on all platforms as a "Right Alt", it is convenient to
>>>>>>>>>>>>>> distinguish the left/right alts.
>>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> --
>>>>>>>>>>>> Best regards, Sergey.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> --
>>>>>>>>>> Best regards, Sergey.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>> Best regards, Sergey.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> Best regards,
>>>>>>> Sergey A. Malenkov
>>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>> Best regards, Sergey.
>>>
>>>
>>>
>>
>>
>> --
>> Best regards, Sergey.
> 
> 
> 


-- 
Best regards, Sergey.

From Sergey.Bylokhov at oracle.com  Thu Mar 21 09:33:29 2019
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Thu, 21 Mar 2019 02:33:29 -0700
Subject: <AWT Dev> [13] Review Request: 8220495 Update GIFlib library to
 the latest 5.1.8
In-Reply-To: <5C92C27B.7090209@oracle.com>
References: <037b3455-b3ad-7aab-51d2-5e0b882190c7@oracle.com>
 <5C92C27B.7090209@oracle.com>
Message-ID: <07d93382-4267-0ef9-d77d-b7138e68d8a8@oracle.com>

On 20/03/2019 15:45, Philip Race wrote:
> So something like this :
> /** Begin JDK modifications to support building on Solaris **/
> #ifdef SOLARIS
> ..
> #endif /* SOLARIS */
> /** End JDK modifications to support building on Solaris **/

An updated version:
http://cr.openjdk.java.net/~serb/8220495/webrev.04

I have updated this version to support platforms which are used for all trains since jdk7+.
Summary:
  - #include <unistd.h> will be used on non-windows only
  - #include <stdbool.h> is commented out(it is supported since c99, and unsupported in SunStudio and VS2010)
  - "inline" keyword is commented out(it is supported since c99, and unsupported in SunStudio and VS2010)

-- 
Best regards, Sergey.

From malenkov at gmail.com  Thu Mar 21 10:18:28 2019
From: malenkov at gmail.com (Sergey Malenkov)
Date: Thu, 21 Mar 2019 13:18:28 +0300
Subject: <AWT Dev> [13] JDK-8218917: KeyEvent.getModifiers() returns
 inconsistent values for ALT keys
In-Reply-To: <cb957518-228d-3187-4cd5-35c1d07c3119@oracle.com>
References: <990B3CDA-E3A0-4051-8771-1AD486094974@oracle.com>
 <CANTFZ2iUHFNSm9st3d3BLYvERa5OmpOzU+T5e1aoLq5C7YkMfQ@mail.gmail.com>
 <5C8673F6.8060306@oracle.com>
 <6d97202a-ad60-c768-4a31-66ca02f16f70@oracle.com>
 <5C86FF3C.7030700@oracle.com>
 <b842a817-1c61-7d23-a144-41bfc87013a3@oracle.com>
 <CANTFZ2ikTVEP1OcrE415KhRbKr7Bv1XND-UW5tVPOW5+Ube7Jw@mail.gmail.com>
 <7dcf0e9b-cfc8-b985-f60c-10f7fe307825@oracle.com>
 <CANTFZ2h2gc8abosQBJrSNA2tF6cwDQacjpfKp_y1znwkkAU+8w@mail.gmail.com>
 <0c65a2e9-d5b3-eaf0-44eb-2b969de64dac@oracle.com>
 <CANTFZ2gY=h5AyLTu8KPkwyL1_4TvY6jLf9_aqTGBwa0kf5mRdQ@mail.gmail.com>
 <5956470F-019E-40E7-AE6D-9BB9F4E95F19@oracle.com>
 <CANTFZ2jUNuwSfEaRVMSCjVhJ50i9aWYi5V_fZE5aRvVConz3Sw@mail.gmail.com>
 <b8901169-5a6e-cd3d-56d7-d3d2578ff29a@oracle.com>
 <CANTFZ2hUFGyAVuYPxH8ubvpbWypHD4Q2G+oRZKS+Gw=j-H3sdw@mail.gmail.com>
 <6d9a95d4-4ceb-c596-ce8f-6dccbd21dd6e@oracle.com>
 <CANTFZ2h7UkaBVqXje7XQ3f-Jrk2Yc30X-T0zXjFNadZ6BCyVbQ@mail.gmail.com>
 <cb957518-228d-3187-4cd5-35c1d07c3119@oracle.com>
Message-ID: <CANTFZ2js+fk=++y7zxqDW0NB+kmhH9EUD54quD6tb31dD_rkHQ@mail.gmail.com>

Hi Sergey,

> I am not sure what does it meant "forget about Meta", if the code does not care
> about "altGr"/"meta/mouse_buttons" it should not use it as off/onnmask and as a result it should ignore it.
> BTW it is not missed in the JavaDoc:
> https://docs.oracle.com/en/java/javase/11/docs/api/java.desktop/java/awt/event/InputEvent.html#field.summary

That is I am talking about!
Consider opposite point of view. If the code care about these buttons,
your fix breaks the code, because Alt became AltGr unexpectedly.

> > I believe that the example in the javadoc is not entirely correct.
>
> Why it is incorrect?

Because on Mac it considers that Alt+F and Alt+Meta+F are equal.
And junior developer will be surprised.

> >
> > On Sun, Mar 17, 2019 at 1:26 AM Sergey Bylokhov
> > <Sergey.Bylokhov at oracle.com> wrote:
> >>
> >> On 16/03/2019 03:58, Sergey Malenkov wrote:
> >>> Your example is synthetic and shows a problem in the one specific
> >>> case. I think if you introduce new mask, you have to use it in your
> >>> example too. If you add ALT_GRAPH_DOWN_MASK to 'offmask' your example
> >>> will not work (that's how processed all shortcuts in Swing and IDEA).
> >>> If you add it to 'onmask' the KeyEvent(new Button(), 0, 0,
> >>> ALT_GRAPH_DOWN_MASK, 0) will not work.
> >>
> >> Your example is good as well, but it shows the opposite, if
> >> ALT_GRAPH_DOWN_MASK was used as "onmask" or as "offmask" then it means
> >> that this example tries to take care about altGr and it only
> >> properly works after the fix. And if the code is unaware about the altGr
> >> flag as in previous example it will be ignored.
> >>
> >>> Am I right that to support your specific case you have to find and fix
> >>> all Alt-based shortcuts in Swing, we should fix all Alt-based
> >>> shortcuts in all keymaps in our IDEs and we should notify all our
> >>> users that they have to fix all Alt-based shortcuts in their custom
> >>> keymaps? The brilliant example of backward compatibility!
> >>
> >> I do not remember all changes which were integrated since initially it was done
> >> ~4 years ago. But Swing was updated by some changes after that, for example:
> >> https://bugs.openjdk.java.net/browse/JDK-8194873
> >>
> >>>
> >>>> So if the client will follow the spec below it should work as before, isn't it?:
> >>>> https://docs.oracle.com/en/java/javase/11/docs/api/java.desktop/java/awt/event/InputEvent.html#getModifiersEx()
> >>>
> >>> If a developer use this method as described his code will be broken
> >>> too, because good and attentive developer definitely added
> >>> ALT_GRAPH_DOWN_MASK to 'offmask'.
> >>
> >> If the user wants to ignore all combinations with "Alternate Character Key"
> >> then, as you pointed in the start of this thread, he should ignore both
> >> "alt" since on macOS both alt keys are "Alternate Character Key".
> >>
> >>>
> >>> On Sat, Mar 16, 2019 at 1:27 AM Sergey Bylokhov
> >>> <Sergey.Bylokhov at oracle.com> wrote:
> >>>>
> >>>> On 15/03/2019 05:54, Sergey Malenkov wrote:
> >>>>> We have a major issue about unexpected AltGr in the keyboard layout
> >>>>> that should not have AltGr at all:
> >>>>> http://youtrack.jetbrains.com/issue/IDEA-206348
> >>>>> Why you decided to support AltGr for every keyboard layout? It really
> >>>>> breaks backward compatibility!
> >>>>
> >>>> Even in your bug report the people complain that altGr key does not work, and
> >>>> the only problem here is that it does not assigned by default.
> >>>> But on the other side it is possible to set separate shortcuts
> >>>> to the "Alt + Alt Graph + Enter"and "Alt + Enter":
> >>>>
> >>>>> I think the main client is Swing and pressed AltGr that looks like
> >>>>> 'Alt+AltGr+' breaks all Alt-based shortcuts defined in
> >>>>> javax.swing.plaf.basic.BasicLookAndFeel#initComponentDefaults and
> >>>>> other places. Now, if you press "alt LEFT", the "moveColumnLeft"
> >>>>> action is performed only for the left Alt. And this also breaks a
> >>>>> backward compatibility.
> >>>>
> >>>> The term "all" is not so critical, there are only few such shortcuts, and it is
> >>>> a good thing that potentially we can set different shortcuts for each.
> >>>> This is a bug that these places were not updated, it is easy to fix since this
> >>>> is not exposed via public API.
> >>>> But we will get the same result if we will use the AltGr mask only.
> >>>>
> >>>>> It is not backward compatible to use AltGr instead of right Alt in
> >>>>> both cases. Instead of 'Alt+key' you will get 'AltGr+key' or
> >>>>> 'Alt+AltGr+key', which are not bound to any action.
> >>>>
> >>>> It is compatible to the specification of InputEvent.getModifiersEx():
> >>>> KeyEvent event = new KeyEvent(new Button(), 0, 0,
> >>>>                                  ALT_DOWN_MASK | ALT_GRAPH_DOWN_MASK, 0);
> >>>>      int onmask =  ALT_DOWN_MASK;
> >>>>      int offmask = CTRL_DOWN_MASK|SHIFT_DOWN_MASK;
> >>>>      if ((event.getModifiersEx() & (onmask | offmask)) == onmask) {
> >>>>        ...
> >>>>      }
> >>>>
> >>>> The code above works before and after the change for altGr.
> >>>> But it will stop working if we will use altGr only, and it will be hard to argue
> >>>> why the ALT flag is not set while alt key is pressed(since on some keyboards this key is
> >>>> marked as alt and on some other altGr).
> >>>>
> >>>> And as specially noted in the method above the code should not assume which
> >>>> flags(and how many) were set by the actions, if such assumptions exists in
> >>>> Swing itself they should be fixed as well.
> >>>>
> >>>>>
> >>>>> On Fri, Mar 15, 2019 at 9:27 AM Krishna Addepalli
> >>>>> <krishna.addepalli at oracle.com> wrote:
> >>>>>>
> >>>>>> Hi Sergey Malenkov,
> >>>>>>
> >>>>>>> 'Alt+AltGr+Right' does nothing, because we do not assign this shortcut yet
> >>>>>> In my personal experience, I did not find any instance, wherein a shortcut had left and right alt in it.
> >>>>>> Although it is not impossible, it seems weird to define such shortcuts.
> >>>>>> It would be helpful if you could point to some resources, wherein defining such shortcuts is acceptable.
> >>>>>>
> >>>>>> Thanks,
> >>>>>> Krishna
> >>>>>>
> >>>>>>> On 14-Mar-2019, at 4:03 PM, Sergey Malenkov <malenkov at gmail.com> wrote:
> >>>>>>>
> >>>>>>> I strongly don't like two masks for one key. If you press VK_ALT,
> >>>>>>> ALT_DOWN_MASK should be set. If you press VK_SHIFT then,
> >>>>>>> SHIFT_DOWN_MASK should be added to indicate that both keys are
> >>>>>>> pressed. And if you press VK_ALT_GRAPH, only ALT_GRAPH_DOWN_MASK
> >>>>>>> should be added. Otherwise, you can't distinguish the following key
> >>>>>>> strokes: 'AltGr+Right' and 'Alt+AltGr+Right'. But these keystrokes are
> >>>>>>> different and should invoke different actions. For example,
> >>>>>>> 'Alt+Right' moves cursor to the next word
> >>>>>>> 'Alt+Shift+Right' moves cursor to the next word AND adds all skipped
> >>>>>>> characters to selection
> >>>>>>> 'Alt+AltGr+Right' does nothing, because we do not assign this shortcut yet
> >>>>>>>
> >>>>>>> On Thu, Mar 14, 2019 at 12:09 AM Sergey Bylokhov
> >>>>>>> <Sergey.Bylokhov at oracle.com> wrote:
> >>>>>>>>
> >>>>>>>> On 13/03/2019 03:59, Sergey Malenkov wrote:
> >>>>>>>>> I missed the "for ALT keys" in the bug title and thought that
> >>>>>>>>> "KeyEvent.getModifiers() returns inconsistent values" was about
> >>>>>>>>> incompatible behaviour on different platforms. In fact, JDK-8218917
> >>>>>>>>> should be renamed to something like ?The right Alt key on Mac should
> >>>>>>>>> behave as Alt and must not break the left Alt key processing?.
> >>>>>>>>
> >>>>>>>> But the "right Alt" should behave like a "left alt" already, it should use both flags:
> >>>>>>>> the common alt(ALT_DOWN_MASK) and the altGr(ALT_GRAPH_DOWN_MASK).
> >>>>>>>>
> >>>>>>>> So if the client will follow the spec below it should work as before, isn't it?:
> >>>>>>>> https://docs.oracle.com/en/java/javase/11/docs/api/java.desktop/java/awt/event/InputEvent.html#getModifiersEx()
> >>>>>>>>
> >>>>>>>>> On Wed, Mar 13, 2019 at 6:57 AM Sergey Bylokhov
> >>>>>>>>> <Sergey.Bylokhov at oracle.com> wrote:
> >>>>>>>>>>
> >>>>>>>>>> On 12/03/2019 12:28, Sergey Malenkov wrote:
> >>>>>>>>>>> Hi Sergey,
> >>>>>>>>>>>
> >>>>>>>>>>> 1. macOS uses a regular Alt key as "Alternate Character Key". This is
> >>>>>>>>>>> the reason why JDK Toolkit defines Ctrl+Alt to select a mnemonic,
> >>>>>>>>>>> instead of simple Alt. See
> >>>>>>>>>>> https://sites.google.com/site/malenkov/java/141229
> >>>>>>>>>>
> >>>>>>>>>> Right, but introducing this flag for the "left alt" could cause even more
> >>>>>>>>>> issues, so this flag is set only for the right.
> >>>>>>>>>>
> >>>>>>>>>>> 3. Regression was caused by adding AltGr to key processing on Mac. But
> >>>>>>>>>>> I found more issues with inconsistent key processing on different
> >>>>>>>>>>> platforms. See http://sites.google.com/site/malenkov/java/190312
> >>>>>>>>>>
> >>>>>>>>>> Not sure that CAPS_LOCK is related.
> >>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>> On Tue, Mar 12, 2019 at 4:17 AM Sergey Bylokhov
> >>>>>>>>>>> <Sergey.Bylokhov at oracle.com> wrote:
> >>>>>>>>>>>>
> >>>>>>>>>>>> On 11/03/2019 17:37, Philip Race wrote:
> >>>>>>>>>>>>> The debate is about AltGraph which an ancient MS-DOSism for
> >>>>>>>>>>>>> asking for an ALTernate GRAPHics bitmap font - all pre-dates windows
> >>>>>>>>>>>>> and I am sure has never been applicable to any MacOS.
> >>>>>>>>>>>>
> >>>>>>>>>>>> It also about the "right alt" which is also know as "AltGraph". I guess currently
> >>>>>>>>>>>> it is implemented as "right alt" on Linux/macOS/windows.
> >>>>>>>>>>>>
> >>>>>>>>>>>> BTW on linux it is also named as "Alternative Characters Key":
> >>>>>>>>>>>> https://help.ubuntu.com/community/ComposeKey
> >>>>>>>>>>>>
> >>>>>>>>>>>>> So someone needs to properly explain why we would claim a Mac keyboard
> >>>>>>>>>>>>> is OK to generate a keycode it doesn't have and cause a slew of regressions
> >>>>>>>>>>>>> in the process ...>
> >>>>>>>>>>>>> If Mac doesn't distinguish these two, we should generate the same keycode for both.
> >>>>>>>>>>>>
> >>>>>>>>>>>> The macOS supports "right alt", otherwise it would not be possible to implement it in java:
> >>>>>>>>>>>> https://developer.apple.com/library/archive/technotes/tn2450/_index.html
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>>> One could suppose there is a difference else why two keys, but what is the right
> >>>>>>>>>>>>> thing to do here  that fixes all the problems. What exactly WAS the problem
> >>>>>>>>>>>>> with what was there in the first place ? And if changing it is correct why is it
> >>>>>>>>>>>>> causing regressions ?
> >>>>>>>>>>>>
> >>>>>>>>>>>> Regressions were caused by the bugs in the fix implementation, or am I missed something?
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> -phil.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> On 3/12/19, 5:34 AM, Sergey Bylokhov wrote:
> >>>>>>>>>>>>>> Hi, Phil.
> >>>>>>>>>>>>>> On 11/03/2019 07:43, Philip Race wrote:
> >>>>>>>>>>>>>>> The reasoning that AltGraph might be useful to someone is a bit weak
> >>>>>>>>>>>>>>> and I don't think I'd want to support it via system property or build options.
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> If its not a platform keyboard key, why do we need it ?
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> The "AltGraph" key is also commonly referred to as "Right Alt", and
> >>>>>>>>>>>>>> it has been implemented on all platforms as a "Right Alt", it is convenient to
> >>>>>>>>>>>>>> distinguish the left/right alts.
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>> --
> >>>>>>>>>>>> Best regards, Sergey.
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> --
> >>>>>>>>>> Best regards, Sergey.
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> --
> >>>>>>>> Best regards, Sergey.
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>> --
> >>>>>>> Best regards,
> >>>>>>> Sergey A. Malenkov
> >>>>>>
> >>>>>
> >>>>>
> >>>>
> >>>>
> >>>> --
> >>>> Best regards, Sergey.
> >>>
> >>>
> >>>
> >>
> >>
> >> --
> >> Best regards, Sergey.
> >
> >
> >
>
>
> --
> Best regards, Sergey.



-- 
Best regards,
Sergey A. Malenkov

From malenkov at gmail.com  Thu Mar 21 10:34:14 2019
From: malenkov at gmail.com (Sergey Malenkov)
Date: Thu, 21 Mar 2019 13:34:14 +0300
Subject: <AWT Dev> [13] JDK-8218917: KeyEvent.getModifiers() returns
 inconsistent values for ALT keys
In-Reply-To: <3DDEC8F7-44EE-4C5F-8B69-C411BDD9FA60@oracle.com>
References: <990B3CDA-E3A0-4051-8771-1AD486094974@oracle.com>
 <CANTFZ2i30ao6fVuVxQseEzF38vBnLUfw3PPadYyKrUCrgfKo9g@mail.gmail.com>
 <6B001F8A-858F-4279-8F42-366F22D49B52@oracle.com>
 <CANTFZ2iUHFNSm9st3d3BLYvERa5OmpOzU+T5e1aoLq5C7YkMfQ@mail.gmail.com>
 <5C8673F6.8060306@oracle.com>
 <6d97202a-ad60-c768-4a31-66ca02f16f70@oracle.com>
 <5C86FF3C.7030700@oracle.com>
 <b842a817-1c61-7d23-a144-41bfc87013a3@oracle.com>
 <CANTFZ2ikTVEP1OcrE415KhRbKr7Bv1XND-UW5tVPOW5+Ube7Jw@mail.gmail.com>
 <7dcf0e9b-cfc8-b985-f60c-10f7fe307825@oracle.com>
 <CANTFZ2h2gc8abosQBJrSNA2tF6cwDQacjpfKp_y1znwkkAU+8w@mail.gmail.com>
 <0c65a2e9-d5b3-eaf0-44eb-2b969de64dac@oracle.com>
 <CANTFZ2gY=h5AyLTu8KPkwyL1_4TvY6jLf9_aqTGBwa0kf5mRdQ@mail.gmail.com>
 <5956470F-019E-40E7-AE6D-9BB9F4E95F19@oracle.com>
 <CANTFZ2jUNuwSfEaRVMSCjVhJ50i9aWYi5V_fZE5aRvVConz3Sw@mail.gmail.com>
 <b8901169-5a6e-cd3d-56d7-d3d2578ff29a@oracle.com>
 <CANTFZ2hUFGyAVuYPxH8ubvpbWypHD4Q2G+oRZKS+Gw=j-H3sdw@mail.gmail.com>
 <6d9a95d4-4ceb-c596-ce8f-6dccbd21dd6e@oracle.com>
 <CANTFZ2h7UkaBVqXje7XQ3f-Jrk2Yc30X-T0zXjFNadZ6BCyVbQ@mail.gmail.com>
 <3DDEC8F7-44EE-4C5F-8B69-C411BDD9FA60@oracle.com>
Message-ID: <CANTFZ2hEqJYOcyFQVsfsuv=i=yM+tTwJtVmn3ekkVQ+NDr7=_w@mail.gmail.com>

Hi Krishna,

> But, currently, with my fix, the code will behave exactly as in Java 1.8.

Nope, it still sends VK_ALT_GRAPH pressed event for the right Alt.

http://bugs.openjdk.java.net/browse/JDK-8151136
According to the issue above AltGr support was backported to 9.


On Wed, Mar 20, 2019 at 2:18 PM Krishna Addepalli
<krishna.addepalli at oracle.com> wrote:
>
> Hi Sergey Malenkov,
>
> We can debate on how to treat the ALTGR_KEY, and can choose to include the behaviour as a system flag.
> But, currently, with my fix, the code will behave exactly as in Java 1.8. Even there, when I pressed ALTGR key, after holding ALT key, I observed a KeyEvent 0 being sent.
>
> I would suggest to re-look at my fix which fixes the current problem at hand, and perhaps we can move this discussion under a new bug.
>
> Thanks,
> Krishna
>
> On 18-Mar-2019, at 8:02 PM, Sergey Malenkov <malenkov at gmail.com> wrote:
>
> Hi Sergey,
>
> ALT_GRAPH_DOWN_MASK is not the only mask missing in JavaDoc. What is
> about META_DOWN_MASK? What if the developer, who does not care about
> ALT_GRAPH, forget about META too? Guess how your example will work on
> Mac. What is about the WORA slogan?
>
> I believe that the example in the javadoc is not entirely correct.
> This is just a very simple example, related to the English locale on
> Windows (and possibly on Linux). It should not be used in
> multi-platform code.
>
>
>
> On Sun, Mar 17, 2019 at 1:26 AM Sergey Bylokhov
> <Sergey.Bylokhov at oracle.com> wrote:
>
>
> On 16/03/2019 03:58, Sergey Malenkov wrote:
>
> Your example is synthetic and shows a problem in the one specific
> case. I think if you introduce new mask, you have to use it in your
> example too. If you add ALT_GRAPH_DOWN_MASK to 'offmask' your example
> will not work (that's how processed all shortcuts in Swing and IDEA).
> If you add it to 'onmask' the KeyEvent(new Button(), 0, 0,
> ALT_GRAPH_DOWN_MASK, 0) will not work.
>
>
> Your example is good as well, but it shows the opposite, if
> ALT_GRAPH_DOWN_MASK was used as "onmask" or as "offmask" then it means
> that this example tries to take care about altGr and it only
> properly works after the fix. And if the code is unaware about the altGr
> flag as in previous example it will be ignored.
>
> Am I right that to support your specific case you have to find and fix
> all Alt-based shortcuts in Swing, we should fix all Alt-based
> shortcuts in all keymaps in our IDEs and we should notify all our
> users that they have to fix all Alt-based shortcuts in their custom
> keymaps? The brilliant example of backward compatibility!
>
>
> I do not remember all changes which were integrated since initially it was done
> ~4 years ago. But Swing was updated by some changes after that, for example:
> https://bugs.openjdk.java.net/browse/JDK-8194873
>
>
> So if the client will follow the spec below it should work as before, isn't it?:
> https://docs.oracle.com/en/java/javase/11/docs/api/java.desktop/java/awt/event/InputEvent.html#getModifiersEx()
>
>
> If a developer use this method as described his code will be broken
> too, because good and attentive developer definitely added
> ALT_GRAPH_DOWN_MASK to 'offmask'.
>
>
> If the user wants to ignore all combinations with "Alternate Character Key"
> then, as you pointed in the start of this thread, he should ignore both
> "alt" since on macOS both alt keys are "Alternate Character Key".
>
>
> On Sat, Mar 16, 2019 at 1:27 AM Sergey Bylokhov
> <Sergey.Bylokhov at oracle.com> wrote:
>
>
> On 15/03/2019 05:54, Sergey Malenkov wrote:
>
> We have a major issue about unexpected AltGr in the keyboard layout
> that should not have AltGr at all:
> https://urldefense.proofpoint.com/v2/url?u=http-3A__youtrack.jetbrains.com_issue_IDEA-2D206348&d=DwIFaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=QF7AertWDY_M4hfHg_4S-iyX-aP0wtLYwZFgs0zfX_k&m=j-gQEy4UDmzd3Sa5zjEYskUw4CoYUZ9gDurLkGu1YOo&s=HcCKCq8FPyOoJEvT4qk59DJqCAiRB-BvECy_VCAdpqI&e=
> Why you decided to support AltGr for every keyboard layout? It really
> breaks backward compatibility!
>
>
> Even in your bug report the people complain that altGr key does not work, and
> the only problem here is that it does not assigned by default.
> But on the other side it is possible to set separate shortcuts
> to the "Alt + Alt Graph + Enter"and "Alt + Enter":
>
> I think the main client is Swing and pressed AltGr that looks like
> 'Alt+AltGr+' breaks all Alt-based shortcuts defined in
> javax.swing.plaf.basic.BasicLookAndFeel#initComponentDefaults and
> other places. Now, if you press "alt LEFT", the "moveColumnLeft"
> action is performed only for the left Alt. And this also breaks a
> backward compatibility.
>
>
> The term "all" is not so critical, there are only few such shortcuts, and it is
> a good thing that potentially we can set different shortcuts for each.
> This is a bug that these places were not updated, it is easy to fix since this
> is not exposed via public API.
> But we will get the same result if we will use the AltGr mask only.
>
> It is not backward compatible to use AltGr instead of right Alt in
> both cases. Instead of 'Alt+key' you will get 'AltGr+key' or
> 'Alt+AltGr+key', which are not bound to any action.
>
>
> It is compatible to the specification of InputEvent.getModifiersEx():
> KeyEvent event = new KeyEvent(new Button(), 0, 0,
>                                ALT_DOWN_MASK | ALT_GRAPH_DOWN_MASK, 0);
>    int onmask =  ALT_DOWN_MASK;
>    int offmask = CTRL_DOWN_MASK|SHIFT_DOWN_MASK;
>    if ((event.getModifiersEx() & (onmask | offmask)) == onmask) {
>      ...
>    }
>
> The code above works before and after the change for altGr.
> But it will stop working if we will use altGr only, and it will be hard to argue
> why the ALT flag is not set while alt key is pressed(since on some keyboards this key is
> marked as alt and on some other altGr).
>
> And as specially noted in the method above the code should not assume which
> flags(and how many) were set by the actions, if such assumptions exists in
> Swing itself they should be fixed as well.
>
>
> On Fri, Mar 15, 2019 at 9:27 AM Krishna Addepalli
> <krishna.addepalli at oracle.com> wrote:
>
>
> Hi Sergey Malenkov,
>
> 'Alt+AltGr+Right' does nothing, because we do not assign this shortcut yet
>
> In my personal experience, I did not find any instance, wherein a shortcut had left and right alt in it.
> Although it is not impossible, it seems weird to define such shortcuts.
> It would be helpful if you could point to some resources, wherein defining such shortcuts is acceptable.
>
> Thanks,
> Krishna
>
> On 14-Mar-2019, at 4:03 PM, Sergey Malenkov <malenkov at gmail.com> wrote:
>
> I strongly don't like two masks for one key. If you press VK_ALT,
> ALT_DOWN_MASK should be set. If you press VK_SHIFT then,
> SHIFT_DOWN_MASK should be added to indicate that both keys are
> pressed. And if you press VK_ALT_GRAPH, only ALT_GRAPH_DOWN_MASK
> should be added. Otherwise, you can't distinguish the following key
> strokes: 'AltGr+Right' and 'Alt+AltGr+Right'. But these keystrokes are
> different and should invoke different actions. For example,
> 'Alt+Right' moves cursor to the next word
> 'Alt+Shift+Right' moves cursor to the next word AND adds all skipped
> characters to selection
> 'Alt+AltGr+Right' does nothing, because we do not assign this shortcut yet
>
> On Thu, Mar 14, 2019 at 12:09 AM Sergey Bylokhov
> <Sergey.Bylokhov at oracle.com> wrote:
>
>
> On 13/03/2019 03:59, Sergey Malenkov wrote:
>
> I missed the "for ALT keys" in the bug title and thought that
> "KeyEvent.getModifiers() returns inconsistent values" was about
> incompatible behaviour on different platforms. In fact, JDK-8218917
> should be renamed to something like ?The right Alt key on Mac should
> behave as Alt and must not break the left Alt key processing?.
>
>
> But the "right Alt" should behave like a "left alt" already, it should use both flags:
> the common alt(ALT_DOWN_MASK) and the altGr(ALT_GRAPH_DOWN_MASK).
>
> So if the client will follow the spec below it should work as before, isn't it?:
> https://docs.oracle.com/en/java/javase/11/docs/api/java.desktop/java/awt/event/InputEvent.html#getModifiersEx()
>
> On Wed, Mar 13, 2019 at 6:57 AM Sergey Bylokhov
> <Sergey.Bylokhov at oracle.com> wrote:
>
>
> On 12/03/2019 12:28, Sergey Malenkov wrote:
>
> Hi Sergey,
>
> 1. macOS uses a regular Alt key as "Alternate Character Key". This is
> the reason why JDK Toolkit defines Ctrl+Alt to select a mnemonic,
> instead of simple Alt. See
> https://urldefense.proofpoint.com/v2/url?u=https-3A__sites.google.com_site_malenkov_java_141229&d=DwIFaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=QF7AertWDY_M4hfHg_4S-iyX-aP0wtLYwZFgs0zfX_k&m=j-gQEy4UDmzd3Sa5zjEYskUw4CoYUZ9gDurLkGu1YOo&s=Y6PcJ4DGp2cSnTLEvtsIdt55_u0F8VqL5LSA7vBPbkw&e=
>
>
> Right, but introducing this flag for the "left alt" could cause even more
> issues, so this flag is set only for the right.
>
> 3. Regression was caused by adding AltGr to key processing on Mac. But
> I found more issues with inconsistent key processing on different
> platforms. See https://urldefense.proofpoint.com/v2/url?u=http-3A__sites.google.com_site_malenkov_java_190312&d=DwIFaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=QF7AertWDY_M4hfHg_4S-iyX-aP0wtLYwZFgs0zfX_k&m=j-gQEy4UDmzd3Sa5zjEYskUw4CoYUZ9gDurLkGu1YOo&s=Y7GZdeTQvRyIBxAsCDtaB8PZo9_GRVYIZZvn2VfCzJc&e=
>
>
> Not sure that CAPS_LOCK is related.
>
>
>
> On Tue, Mar 12, 2019 at 4:17 AM Sergey Bylokhov
> <Sergey.Bylokhov at oracle.com> wrote:
>
>
> On 11/03/2019 17:37, Philip Race wrote:
>
> The debate is about AltGraph which an ancient MS-DOSism for
> asking for an ALTernate GRAPHics bitmap font - all pre-dates windows
> and I am sure has never been applicable to any MacOS.
>
>
> It also about the "right alt" which is also know as "AltGraph". I guess currently
> it is implemented as "right alt" on Linux/macOS/windows.
>
> BTW on linux it is also named as "Alternative Characters Key":
> https://urldefense.proofpoint.com/v2/url?u=https-3A__help.ubuntu.com_community_ComposeKey&d=DwIFaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=QF7AertWDY_M4hfHg_4S-iyX-aP0wtLYwZFgs0zfX_k&m=j-gQEy4UDmzd3Sa5zjEYskUw4CoYUZ9gDurLkGu1YOo&s=DvJtvBcerkulT3S417Vu6hQyXy7e0bI1bX9fInefV-A&e=
>
> So someone needs to properly explain why we would claim a Mac keyboard
> is OK to generate a keycode it doesn't have and cause a slew of regressions
> in the process ...>
> If Mac doesn't distinguish these two, we should generate the same keycode for both.
>
>
> The macOS supports "right alt", otherwise it would not be possible to implement it in java:
> https://urldefense.proofpoint.com/v2/url?u=https-3A__developer.apple.com_library_archive_technotes_tn2450_-5Findex.html&d=DwIFaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=QF7AertWDY_M4hfHg_4S-iyX-aP0wtLYwZFgs0zfX_k&m=j-gQEy4UDmzd3Sa5zjEYskUw4CoYUZ9gDurLkGu1YOo&s=hD5wMxSuL3iN_tqTn0Cd5ULhp_bGzQl3fFnQQdNXNuU&e=
>
>
> One could suppose there is a difference else why two keys, but what is the right
> thing to do here  that fixes all the problems. What exactly WAS the problem
> with what was there in the first place ? And if changing it is correct why is it
> causing regressions ?
>
>
> Regressions were caused by the bugs in the fix implementation, or am I missed something?
>
>
>
> -phil.
>
>
>
> On 3/12/19, 5:34 AM, Sergey Bylokhov wrote:
>
> Hi, Phil.
> On 11/03/2019 07:43, Philip Race wrote:
>
> The reasoning that AltGraph might be useful to someone is a bit weak
> and I don't think I'd want to support it via system property or build options.
>
> If its not a platform keyboard key, why do we need it ?
>
>
> The "AltGraph" key is also commonly referred to as "Right Alt", and
> it has been implemented on all platforms as a "Right Alt", it is convenient to
> distinguish the left/right alts.
>
>
>
> --
> Best regards, Sergey.
>
>
>
>
>
>
> --
> Best regards, Sergey.
>
>
>
>
>
>
> --
> Best regards, Sergey.
>
>
>
>
> --
> Best regards,
> Sergey A. Malenkov
>
>
>
>
>
>
> --
> Best regards, Sergey.
>
>
>
>
>
>
> --
> Best regards, Sergey.
>
>
>
>
> --
> Best regards,
> Sergey A. Malenkov
>
>


-- 
Best regards,
Sergey A. Malenkov

From Sergey.Bylokhov at oracle.com  Thu Mar 21 16:27:47 2019
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Thu, 21 Mar 2019 09:27:47 -0700
Subject: <AWT Dev> [13] JDK-8218917: KeyEvent.getModifiers() returns
 inconsistent values for ALT keys
In-Reply-To: <CANTFZ2js+fk=++y7zxqDW0NB+kmhH9EUD54quD6tb31dD_rkHQ@mail.gmail.com>
References: <990B3CDA-E3A0-4051-8771-1AD486094974@oracle.com>
 <6d97202a-ad60-c768-4a31-66ca02f16f70@oracle.com>
 <5C86FF3C.7030700@oracle.com>
 <b842a817-1c61-7d23-a144-41bfc87013a3@oracle.com>
 <CANTFZ2ikTVEP1OcrE415KhRbKr7Bv1XND-UW5tVPOW5+Ube7Jw@mail.gmail.com>
 <7dcf0e9b-cfc8-b985-f60c-10f7fe307825@oracle.com>
 <CANTFZ2h2gc8abosQBJrSNA2tF6cwDQacjpfKp_y1znwkkAU+8w@mail.gmail.com>
 <0c65a2e9-d5b3-eaf0-44eb-2b969de64dac@oracle.com>
 <CANTFZ2gY=h5AyLTu8KPkwyL1_4TvY6jLf9_aqTGBwa0kf5mRdQ@mail.gmail.com>
 <5956470F-019E-40E7-AE6D-9BB9F4E95F19@oracle.com>
 <CANTFZ2jUNuwSfEaRVMSCjVhJ50i9aWYi5V_fZE5aRvVConz3Sw@mail.gmail.com>
 <b8901169-5a6e-cd3d-56d7-d3d2578ff29a@oracle.com>
 <CANTFZ2hUFGyAVuYPxH8ubvpbWypHD4Q2G+oRZKS+Gw=j-H3sdw@mail.gmail.com>
 <6d9a95d4-4ceb-c596-ce8f-6dccbd21dd6e@oracle.com>
 <CANTFZ2h7UkaBVqXje7XQ3f-Jrk2Yc30X-T0zXjFNadZ6BCyVbQ@mail.gmail.com>
 <cb957518-228d-3187-4cd5-35c1d07c3119@oracle.com>
 <CANTFZ2js+fk=++y7zxqDW0NB+kmhH9EUD54quD6tb31dD_rkHQ@mail.gmail.com>
Message-ID: <d9faebb3-e7e0-9a86-eab8-a5e24f867459@oracle.com>

On 21/03/2019 03:18, Sergey Malenkov wrote:
> Hi Sergey,
> 
>> I am not sure what does it meant "forget about Meta", if the code does not care
>> about "altGr"/"meta/mouse_buttons" it should not use it as off/onnmask and as a result it should ignore it.
>> BTW it is not missed in the JavaDoc:
>> https://docs.oracle.com/en/java/javase/11/docs/api/java.desktop/java/awt/event/InputEvent.html#field.summary
> 
> That is I am talking about!
> Consider opposite point of view. If the code care about these buttons,
> your fix breaks the code, because Alt became AltGr unexpectedly.

Why it is became unexpectedly if the user want filter out alternate graphics key
and this button is really used for alternate graphics?

> 
>>> I believe that the example in the javadoc is not entirely correct.
>>
>> Why it is incorrect?
> 
> Because on Mac it considers that Alt+F and Alt+Meta+F are equal.
> And junior developer will be surprised.

On mac the meta key is used for "command key", if you mean the altGr then
the problem which we have here is that we should use altGr for both keys.

> 
>>>
>>> On Sun, Mar 17, 2019 at 1:26 AM Sergey Bylokhov
>>> <Sergey.Bylokhov at oracle.com> wrote:
>>>>
>>>> On 16/03/2019 03:58, Sergey Malenkov wrote:
>>>>> Your example is synthetic and shows a problem in the one specific
>>>>> case. I think if you introduce new mask, you have to use it in your
>>>>> example too. If you add ALT_GRAPH_DOWN_MASK to 'offmask' your example
>>>>> will not work (that's how processed all shortcuts in Swing and IDEA).
>>>>> If you add it to 'onmask' the KeyEvent(new Button(), 0, 0,
>>>>> ALT_GRAPH_DOWN_MASK, 0) will not work.
>>>>
>>>> Your example is good as well, but it shows the opposite, if
>>>> ALT_GRAPH_DOWN_MASK was used as "onmask" or as "offmask" then it means
>>>> that this example tries to take care about altGr and it only
>>>> properly works after the fix. And if the code is unaware about the altGr
>>>> flag as in previous example it will be ignored.
>>>>
>>>>> Am I right that to support your specific case you have to find and fix
>>>>> all Alt-based shortcuts in Swing, we should fix all Alt-based
>>>>> shortcuts in all keymaps in our IDEs and we should notify all our
>>>>> users that they have to fix all Alt-based shortcuts in their custom
>>>>> keymaps? The brilliant example of backward compatibility!
>>>>
>>>> I do not remember all changes which were integrated since initially it was done
>>>> ~4 years ago. But Swing was updated by some changes after that, for example:
>>>> https://bugs.openjdk.java.net/browse/JDK-8194873
>>>>
>>>>>
>>>>>> So if the client will follow the spec below it should work as before, isn't it?:
>>>>>> https://docs.oracle.com/en/java/javase/11/docs/api/java.desktop/java/awt/event/InputEvent.html#getModifiersEx()
>>>>>
>>>>> If a developer use this method as described his code will be broken
>>>>> too, because good and attentive developer definitely added
>>>>> ALT_GRAPH_DOWN_MASK to 'offmask'.
>>>>
>>>> If the user wants to ignore all combinations with "Alternate Character Key"
>>>> then, as you pointed in the start of this thread, he should ignore both
>>>> "alt" since on macOS both alt keys are "Alternate Character Key".
>>>>
>>>>>
>>>>> On Sat, Mar 16, 2019 at 1:27 AM Sergey Bylokhov
>>>>> <Sergey.Bylokhov at oracle.com> wrote:
>>>>>>
>>>>>> On 15/03/2019 05:54, Sergey Malenkov wrote:
>>>>>>> We have a major issue about unexpected AltGr in the keyboard layout
>>>>>>> that should not have AltGr at all:
>>>>>>> http://youtrack.jetbrains.com/issue/IDEA-206348
>>>>>>> Why you decided to support AltGr for every keyboard layout? It really
>>>>>>> breaks backward compatibility!
>>>>>>
>>>>>> Even in your bug report the people complain that altGr key does not work, and
>>>>>> the only problem here is that it does not assigned by default.
>>>>>> But on the other side it is possible to set separate shortcuts
>>>>>> to the "Alt + Alt Graph + Enter"and "Alt + Enter":
>>>>>>
>>>>>>> I think the main client is Swing and pressed AltGr that looks like
>>>>>>> 'Alt+AltGr+' breaks all Alt-based shortcuts defined in
>>>>>>> javax.swing.plaf.basic.BasicLookAndFeel#initComponentDefaults and
>>>>>>> other places. Now, if you press "alt LEFT", the "moveColumnLeft"
>>>>>>> action is performed only for the left Alt. And this also breaks a
>>>>>>> backward compatibility.
>>>>>>
>>>>>> The term "all" is not so critical, there are only few such shortcuts, and it is
>>>>>> a good thing that potentially we can set different shortcuts for each.
>>>>>> This is a bug that these places were not updated, it is easy to fix since this
>>>>>> is not exposed via public API.
>>>>>> But we will get the same result if we will use the AltGr mask only.
>>>>>>
>>>>>>> It is not backward compatible to use AltGr instead of right Alt in
>>>>>>> both cases. Instead of 'Alt+key' you will get 'AltGr+key' or
>>>>>>> 'Alt+AltGr+key', which are not bound to any action.
>>>>>>
>>>>>> It is compatible to the specification of InputEvent.getModifiersEx():
>>>>>> KeyEvent event = new KeyEvent(new Button(), 0, 0,
>>>>>>                                   ALT_DOWN_MASK | ALT_GRAPH_DOWN_MASK, 0);
>>>>>>       int onmask =  ALT_DOWN_MASK;
>>>>>>       int offmask = CTRL_DOWN_MASK|SHIFT_DOWN_MASK;
>>>>>>       if ((event.getModifiersEx() & (onmask | offmask)) == onmask) {
>>>>>>         ...
>>>>>>       }
>>>>>>
>>>>>> The code above works before and after the change for altGr.
>>>>>> But it will stop working if we will use altGr only, and it will be hard to argue
>>>>>> why the ALT flag is not set while alt key is pressed(since on some keyboards this key is
>>>>>> marked as alt and on some other altGr).
>>>>>>
>>>>>> And as specially noted in the method above the code should not assume which
>>>>>> flags(and how many) were set by the actions, if such assumptions exists in
>>>>>> Swing itself they should be fixed as well.
>>>>>>
>>>>>>>
>>>>>>> On Fri, Mar 15, 2019 at 9:27 AM Krishna Addepalli
>>>>>>> <krishna.addepalli at oracle.com> wrote:
>>>>>>>>
>>>>>>>> Hi Sergey Malenkov,
>>>>>>>>
>>>>>>>>> 'Alt+AltGr+Right' does nothing, because we do not assign this shortcut yet
>>>>>>>> In my personal experience, I did not find any instance, wherein a shortcut had left and right alt in it.
>>>>>>>> Although it is not impossible, it seems weird to define such shortcuts.
>>>>>>>> It would be helpful if you could point to some resources, wherein defining such shortcuts is acceptable.
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>> Krishna
>>>>>>>>
>>>>>>>>> On 14-Mar-2019, at 4:03 PM, Sergey Malenkov <malenkov at gmail.com> wrote:
>>>>>>>>>
>>>>>>>>> I strongly don't like two masks for one key. If you press VK_ALT,
>>>>>>>>> ALT_DOWN_MASK should be set. If you press VK_SHIFT then,
>>>>>>>>> SHIFT_DOWN_MASK should be added to indicate that both keys are
>>>>>>>>> pressed. And if you press VK_ALT_GRAPH, only ALT_GRAPH_DOWN_MASK
>>>>>>>>> should be added. Otherwise, you can't distinguish the following key
>>>>>>>>> strokes: 'AltGr+Right' and 'Alt+AltGr+Right'. But these keystrokes are
>>>>>>>>> different and should invoke different actions. For example,
>>>>>>>>> 'Alt+Right' moves cursor to the next word
>>>>>>>>> 'Alt+Shift+Right' moves cursor to the next word AND adds all skipped
>>>>>>>>> characters to selection
>>>>>>>>> 'Alt+AltGr+Right' does nothing, because we do not assign this shortcut yet
>>>>>>>>>
>>>>>>>>> On Thu, Mar 14, 2019 at 12:09 AM Sergey Bylokhov
>>>>>>>>> <Sergey.Bylokhov at oracle.com> wrote:
>>>>>>>>>>
>>>>>>>>>> On 13/03/2019 03:59, Sergey Malenkov wrote:
>>>>>>>>>>> I missed the "for ALT keys" in the bug title and thought that
>>>>>>>>>>> "KeyEvent.getModifiers() returns inconsistent values" was about
>>>>>>>>>>> incompatible behaviour on different platforms. In fact, JDK-8218917
>>>>>>>>>>> should be renamed to something like ?The right Alt key on Mac should
>>>>>>>>>>> behave as Alt and must not break the left Alt key processing?.
>>>>>>>>>>
>>>>>>>>>> But the "right Alt" should behave like a "left alt" already, it should use both flags:
>>>>>>>>>> the common alt(ALT_DOWN_MASK) and the altGr(ALT_GRAPH_DOWN_MASK).
>>>>>>>>>>
>>>>>>>>>> So if the client will follow the spec below it should work as before, isn't it?:
>>>>>>>>>> https://docs.oracle.com/en/java/javase/11/docs/api/java.desktop/java/awt/event/InputEvent.html#getModifiersEx()
>>>>>>>>>>
>>>>>>>>>>> On Wed, Mar 13, 2019 at 6:57 AM Sergey Bylokhov
>>>>>>>>>>> <Sergey.Bylokhov at oracle.com> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>> On 12/03/2019 12:28, Sergey Malenkov wrote:
>>>>>>>>>>>>> Hi Sergey,
>>>>>>>>>>>>>
>>>>>>>>>>>>> 1. macOS uses a regular Alt key as "Alternate Character Key". This is
>>>>>>>>>>>>> the reason why JDK Toolkit defines Ctrl+Alt to select a mnemonic,
>>>>>>>>>>>>> instead of simple Alt. See
>>>>>>>>>>>>> https://sites.google.com/site/malenkov/java/141229
>>>>>>>>>>>>
>>>>>>>>>>>> Right, but introducing this flag for the "left alt" could cause even more
>>>>>>>>>>>> issues, so this flag is set only for the right.
>>>>>>>>>>>>
>>>>>>>>>>>>> 3. Regression was caused by adding AltGr to key processing on Mac. But
>>>>>>>>>>>>> I found more issues with inconsistent key processing on different
>>>>>>>>>>>>> platforms. See http://sites.google.com/site/malenkov/java/190312
>>>>>>>>>>>>
>>>>>>>>>>>> Not sure that CAPS_LOCK is related.
>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> On Tue, Mar 12, 2019 at 4:17 AM Sergey Bylokhov
>>>>>>>>>>>>> <Sergey.Bylokhov at oracle.com> wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On 11/03/2019 17:37, Philip Race wrote:
>>>>>>>>>>>>>>> The debate is about AltGraph which an ancient MS-DOSism for
>>>>>>>>>>>>>>> asking for an ALTernate GRAPHics bitmap font - all pre-dates windows
>>>>>>>>>>>>>>> and I am sure has never been applicable to any MacOS.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> It also about the "right alt" which is also know as "AltGraph". I guess currently
>>>>>>>>>>>>>> it is implemented as "right alt" on Linux/macOS/windows.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> BTW on linux it is also named as "Alternative Characters Key":
>>>>>>>>>>>>>> https://help.ubuntu.com/community/ComposeKey
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> So someone needs to properly explain why we would claim a Mac keyboard
>>>>>>>>>>>>>>> is OK to generate a keycode it doesn't have and cause a slew of regressions
>>>>>>>>>>>>>>> in the process ...>
>>>>>>>>>>>>>>> If Mac doesn't distinguish these two, we should generate the same keycode for both.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> The macOS supports "right alt", otherwise it would not be possible to implement it in java:
>>>>>>>>>>>>>> https://developer.apple.com/library/archive/technotes/tn2450/_index.html
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> One could suppose there is a difference else why two keys, but what is the right
>>>>>>>>>>>>>>> thing to do here  that fixes all the problems. What exactly WAS the problem
>>>>>>>>>>>>>>> with what was there in the first place ? And if changing it is correct why is it
>>>>>>>>>>>>>>> causing regressions ?
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Regressions were caused by the bugs in the fix implementation, or am I missed something?
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> -phil.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> On 3/12/19, 5:34 AM, Sergey Bylokhov wrote:
>>>>>>>>>>>>>>>> Hi, Phil.
>>>>>>>>>>>>>>>> On 11/03/2019 07:43, Philip Race wrote:
>>>>>>>>>>>>>>>>> The reasoning that AltGraph might be useful to someone is a bit weak
>>>>>>>>>>>>>>>>> and I don't think I'd want to support it via system property or build options.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> If its not a platform keyboard key, why do we need it ?
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> The "AltGraph" key is also commonly referred to as "Right Alt", and
>>>>>>>>>>>>>>>> it has been implemented on all platforms as a "Right Alt", it is convenient to
>>>>>>>>>>>>>>>> distinguish the left/right alts.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> --
>>>>>>>>>>>>>> Best regards, Sergey.
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> --
>>>>>>>>>>>> Best regards, Sergey.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> --
>>>>>>>>>> Best regards, Sergey.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> Best regards,
>>>>>>>>> Sergey A. Malenkov
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Best regards, Sergey.
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>> Best regards, Sergey.
>>>
>>>
>>>
>>
>>
>> --
>> Best regards, Sergey.
> 
> 
> 


-- 
Best regards, Sergey.

From thomas.stuefe at gmail.com  Mon Mar 25 07:01:08 2019
From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=)
Date: Mon, 25 Mar 2019 08:01:08 +0100
Subject: <AWT Dev> RFR(xs): 8221375: Windows 32bit build (VS2017) broken
In-Reply-To: <44c67029-57fc-155c-39e1-bd810e70fe32@oracle.com>
References: <CAA-vtUwuJ0MFWbgeT+Ch2qSZeZTFq-uYB-Fd3r3b3Ht+67S1wQ@mail.gmail.com>
 <44c67029-57fc-155c-39e1-bd810e70fe32@oracle.com>
Message-ID: <CAA-vtUyhVLJm-TjJk-Rt4ibk7cYdM2k5ONUszt3ms39SjcoTHA@mail.gmail.com>

Hi David,

(added net-dev, awt-dev, security-dev since part of these fixes are in
their territory)

On Mon, Mar 25, 2019 at 1:34 AM David Holmes <david.holmes at oracle.com>
wrote:

> Hi Thomas,
>
> A few queries, comments and concerns ...
>
> On 25/03/2019 6:58 am, Thomas St?fe wrote:
> > Hi all,
> >
> > After a long time I tried to build a Windows 32bit VM (VS2017) and
> failed;
>
> I'm somewhat surprised as I thought someone was actively doing Windows
> 32-bit builds out there, plus there are shared code changes that should
> also have been caught by non-Windows 32-bit builds. :(
>
>
Not sure what others do. I did a 32bit windows build, slowdebug, warning
enabled, and it failed with those 5+ issues.


> > multiple errors and warnings. Lets reverse the bitrot:
> >
> > cr:
> >
> http://cr.openjdk.java.net/~stuefe/webrevs/8221375--windows-32bit-build-(vs2017)-broken-in-many-places/webrev.00/webrev/
> >
> > Issue: https://bugs.openjdk.java.net/browse/JDK-8221375
> >
> > Most of the fixes are trivial: Calling convention mismatches (awt DTRACE
> > callbacks), printf specifiers etc.
> >
> > Had to supress a warning in os_windows_x86.cpp - I was surprised by this
> > since this did not look 32bit specifc, do we disable warnings on Windows
> > 64bit builds?
>
> What version of VS2017? We use VS2017 15.9.6 and we don't disable warnings.
>
>
I use VS2017 CE. Not sure which version spcifically, but my compiler is at

Microsoft (R) C/C++ Optimizing Compiler Version 19.14.26431 for x86


> > The error I had in vmStructs.cpp was a bit weird: compiler complained
> about
> > an assignment of an enum value defined like this:
> >
> > hash_mask_in_place       = (address_word)hash_mask << hash_shift
> >
> > to an uint64_t variable, complaining about narrowing. I did not find out
> > what his problem was. In the end, I decided to add an explicit cast to
> > GENERATE_VM_LONG_CONSTANT_ENTRY(name) (see vmStructs.hpp).
>
> Not at all sure that's the right fix. In markOop.hpp we see that value
> gets special treatment on Windows-x64:
>

> #ifndef _WIN64
>           ,hash_mask               = right_n_bits(hash_bits),
>           hash_mask_in_place       = (address_word)hash_mask << hash_shift
> #endif
>    };
>
>    // Alignment of JavaThread pointers encoded in object header required
> by biased locking
>    enum { biased_lock_alignment    = 2 << (epoch_shift + epoch_bits)
>    };
>
> #ifdef _WIN64
>      // These values are too big for Win64
>      const static uintptr_t hash_mask = right_n_bits(hash_bits);
>      const static uintptr_t hash_mask_in_place  =
>                              (address_word)hash_mask << hash_shift;
> #endif
>
> perhaps something special is needed for Windows-x86. I'm unclear how the
> values can be "too big" ??
>
>
I banged my head against this for an hour or so and I think this is a
compiler bug.

What I get is:

warning C4838: conversion from '' to 'uint64_t' requires a narrowing
conversion

(Note the empty "from" string.)

Here are my tries to provoke the error:

VMLongConstantEntry iii[] = {  { "hallo", markOopDesc::hash_mask_in_place
}, {0,0}};  <<< this fails
VMLongConstantEntry iii = { "hallo", markOopDesc::hash_mask_in_place };
 << but this succeeds
uint64_t iii = markOopDesc::hash_mask_in_place;   << this succeeds  too

I have no clue what this means. It is difficult to fix since the expression
is hidden in such a macro pile. But I think either we go with my change or
we disable the warning for win32 for the whole section.


> >
> > With this patch we can build with warnings enabled on 32bit and 64bit
> > windows.
> >
> > Since patch fixes both hotspot and JDK parts, I'm sending it to hs-dev
> and
> > core-libs-dev.
>
> Don't see anything that actually comes under core-libs-dev. Looks like
> one net-dev, one awt-dev and one security-dev. Sorry.
>
>
Okay, I will add them.


> Cheers,
> David
> -----
>
>
Thanks for reviewing,

Thomas


> > Thanks, Thomas
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/awt-dev/attachments/20190325/19c5a7c1/attachment.html>

From david.holmes at oracle.com  Mon Mar 25 07:17:05 2019
From: david.holmes at oracle.com (David Holmes)
Date: Mon, 25 Mar 2019 17:17:05 +1000
Subject: <AWT Dev> RFR(xs): 8221375: Windows 32bit build (VS2017) broken
In-Reply-To: <CAA-vtUyhVLJm-TjJk-Rt4ibk7cYdM2k5ONUszt3ms39SjcoTHA@mail.gmail.com>
References: <CAA-vtUwuJ0MFWbgeT+Ch2qSZeZTFq-uYB-Fd3r3b3Ht+67S1wQ@mail.gmail.com>
 <44c67029-57fc-155c-39e1-bd810e70fe32@oracle.com>
 <CAA-vtUyhVLJm-TjJk-Rt4ibk7cYdM2k5ONUszt3ms39SjcoTHA@mail.gmail.com>
Message-ID: <46ea4603-9a4c-6330-ad47-30fe4137fc0b@oracle.com>

Hi Thomas,

On 25/03/2019 5:01 pm, Thomas St?fe wrote:
> Hi David,
> 
> (added net-dev, awt-dev, security-dev since part of these fixes are in 
> their territory)

May be better to split up the reviews, cross-posting that many groups 
gets very messy given most people won't be subscribed to them all - 
myself included.

> On Mon, Mar 25, 2019 at 1:34 AM David Holmes <david.holmes at oracle.com 
> <mailto:david.holmes at oracle.com>> wrote:
> 
>     Hi Thomas,
> 
>     A few queries, comments and concerns ...
> 
>     On 25/03/2019 6:58 am, Thomas St?fe wrote:
>      > Hi all,
>      >
>      > After a long time I tried to build a Windows 32bit VM (VS2017)
>     and failed;
> 
>     I'm somewhat surprised as I thought someone was actively doing Windows
>     32-bit builds out there, plus there are shared code changes that should
>     also have been caught by non-Windows 32-bit builds. :(
> 
> 
> Not sure what others?do. I did a 32bit windows build, slowdebug, warning 
> enabled, and it failed with those 5+ issues.
> 
>      > multiple errors and warnings. Lets reverse the bitrot:
>      >
>      > cr:
>      >
>     http://cr.openjdk.java.net/~stuefe/webrevs/8221375--windows-32bit-build-(vs2017)-broken-in-many-places/webrev.00/webrev/
>      >
>      > Issue: https://bugs.openjdk.java.net/browse/JDK-8221375
>      >
>      > Most of the fixes are trivial: Calling convention mismatches (awt
>     DTRACE
>      > callbacks), printf specifiers etc.
>      >
>      > Had to supress a warning in os_windows_x86.cpp - I was surprised
>     by this
>      > since this did not look 32bit specifc, do we disable warnings on
>     Windows
>      > 64bit builds?
> 
>     What version of VS2017? We use VS2017 15.9.6 and we don't disable
>     warnings.
> 
> 
> I use VS2017 CE. Not sure which version spcifically, but my compiler is at
> 
> Microsoft (R) C/C++ Optimizing Compiler Version 19.14.26431 for x86

I think that would equate to an older version - 15.7

MSVC++ 14.14 _MSC_VER == 1914 (Visual Studio 2017 version 15.7)

Any chance you can upgrade to latest version? (Especially in light of 
the apparent compiler bug you cite below.)

Thanks,
David
-----

>      > The error I had in vmStructs.cpp was a bit weird: compiler
>     complained about
>      > an assignment of an enum value defined like this:
>      >
>      > hash_mask_in_place? ? ? ?= (address_word)hash_mask << hash_shift
>      >
>      > to an uint64_t variable, complaining about narrowing. I did not
>     find out
>      > what his problem was. In the end, I decided to add an explicit
>     cast to
>      > GENERATE_VM_LONG_CONSTANT_ENTRY(name) (see vmStructs.hpp).
> 
>     Not at all sure that's the right fix. In markOop.hpp we see that value
>     gets special treatment on Windows-x64:
> 
> 
>     #ifndef _WIN64
>      ? ? ? ? ? ,hash_mask? ? ? ? ? ? ? ?= right_n_bits(hash_bits),
>      ? ? ? ? ? hash_mask_in_place? ? ? ?= (address_word)hash_mask <<
>     hash_shift
>     #endif
>      ? ?};
> 
>      ? ?// Alignment of JavaThread pointers encoded in object header
>     required
>     by biased locking
>      ? ?enum { biased_lock_alignment? ? = 2 << (epoch_shift + epoch_bits)
>      ? ?};
> 
>     #ifdef _WIN64
>      ? ? ?// These values are too big for Win64
>      ? ? ?const static uintptr_t hash_mask = right_n_bits(hash_bits);
>      ? ? ?const static uintptr_t hash_mask_in_place? =
>      ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?(address_word)hash_mask << hash_shift;
>     #endif
> 
>     perhaps something special is needed for Windows-x86. I'm unclear how
>     the
>     values can be "too big" ??
> 
> 
> I banged my head against this for an hour or so and I think this is a 
> compiler bug.
> 
> What I get is:
> 
> warning C4838: conversion from '' to 'uint64_t' requires a narrowing 
> conversion
> 
> (Note the empty "from" string.)
> 
> Here are my tries to provoke the error:
> 
> VMLongConstantEntry iii[] = {? { "hallo", 
> markOopDesc::hash_mask_in_place }, {0,0}};? <<< this fails
> VMLongConstantEntry iii = { "hallo", markOopDesc::hash_mask_in_place };  
>  ?<< but this succeeds
> uint64_t iii = markOopDesc::hash_mask_in_place;? ?<< this succeeds? too
> 
> I have no clue what this means. It is difficult to fix since the 
> expression is hidden in such a macro pile. But I think either we go with 
> my change or we disable the warning for win32 for the whole section.
> 
>      >
>      > With this patch we can build with warnings enabled on 32bit and 64bit
>      > windows.
>      >
>      > Since patch fixes both hotspot and JDK parts, I'm sending it to
>     hs-dev and
>      > core-libs-dev.
> 
>     Don't see anything that actually comes under core-libs-dev. Looks like
>     one net-dev, one awt-dev and one security-dev. Sorry.
> 
> 
> Okay, I will add them.
> 
>     Cheers,
>     David
>     -----
> 
> 
> Thanks for reviewing,
> 
> Thomas
> 
>      > Thanks, Thomas
>      >
> 

From thomas.stuefe at gmail.com  Mon Mar 25 12:44:21 2019
From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=)
Date: Mon, 25 Mar 2019 13:44:21 +0100
Subject: <AWT Dev> RFR(xs): 8221375: Windows 32bit build (VS2017) broken
In-Reply-To: <46ea4603-9a4c-6330-ad47-30fe4137fc0b@oracle.com>
References: <CAA-vtUwuJ0MFWbgeT+Ch2qSZeZTFq-uYB-Fd3r3b3Ht+67S1wQ@mail.gmail.com>
 <44c67029-57fc-155c-39e1-bd810e70fe32@oracle.com>
 <CAA-vtUyhVLJm-TjJk-Rt4ibk7cYdM2k5ONUszt3ms39SjcoTHA@mail.gmail.com>
 <46ea4603-9a4c-6330-ad47-30fe4137fc0b@oracle.com>
Message-ID: <CAA-vtUwA+cUxS3XHvNkwXP3hMPiW=WWhn5RFWsTK9qQA_NUHug@mail.gmail.com>

Hi David,

Updating vs2017 did not help :/

Cheers, Thomas

On Mon, Mar 25, 2019 at 8:17 AM David Holmes <david.holmes at oracle.com>
wrote:

> Hi Thomas,
>
> On 25/03/2019 5:01 pm, Thomas St?fe wrote:
> > Hi David,
> >
> > (added net-dev, awt-dev, security-dev since part of these fixes are in
> > their territory)
>
> May be better to split up the reviews, cross-posting that many groups
> gets very messy given most people won't be subscribed to them all -
> myself included.
>


>
> > On Mon, Mar 25, 2019 at 1:34 AM David Holmes <david.holmes at oracle.com
> > <mailto:david.holmes at oracle.com>> wrote:
> >
> >     Hi Thomas,
> >
> >     A few queries, comments and concerns ...
> >
> >     On 25/03/2019 6:58 am, Thomas St?fe wrote:
> >      > Hi all,
> >      >
> >      > After a long time I tried to build a Windows 32bit VM (VS2017)
> >     and failed;
> >
> >     I'm somewhat surprised as I thought someone was actively doing
> Windows
> >     32-bit builds out there, plus there are shared code changes that
> should
> >     also have been caught by non-Windows 32-bit builds. :(
> >
> >
> > Not sure what others do. I did a 32bit windows build, slowdebug, warning
> > enabled, and it failed with those 5+ issues.
> >
> >      > multiple errors and warnings. Lets reverse the bitrot:
> >      >
> >      > cr:
> >      >
> >
> http://cr.openjdk.java.net/~stuefe/webrevs/8221375--windows-32bit-build-(vs2017)-broken-in-many-places/webrev.00/webrev/
> >      >
> >      > Issue: https://bugs.openjdk.java.net/browse/JDK-8221375
> >      >
> >      > Most of the fixes are trivial: Calling convention mismatches (awt
> >     DTRACE
> >      > callbacks), printf specifiers etc.
> >      >
> >      > Had to supress a warning in os_windows_x86.cpp - I was surprised
> >     by this
> >      > since this did not look 32bit specifc, do we disable warnings on
> >     Windows
> >      > 64bit builds?
> >
> >     What version of VS2017? We use VS2017 15.9.6 and we don't disable
> >     warnings.
> >
> >
> > I use VS2017 CE. Not sure which version spcifically, but my compiler is
> at
> >
> > Microsoft (R) C/C++ Optimizing Compiler Version 19.14.26431 for x86
>
> I think that would equate to an older version - 15.7
>
> MSVC++ 14.14 _MSC_VER == 1914 (Visual Studio 2017 version 15.7)
>
> Any chance you can upgrade to latest version? (Especially in light of
> the apparent compiler bug you cite below.)
>
> Thanks,
> David
> -----
>
> >      > The error I had in vmStructs.cpp was a bit weird: compiler
> >     complained about
> >      > an assignment of an enum value defined like this:
> >      >
> >      > hash_mask_in_place       = (address_word)hash_mask << hash_shift
> >      >
> >      > to an uint64_t variable, complaining about narrowing. I did not
> >     find out
> >      > what his problem was. In the end, I decided to add an explicit
> >     cast to
> >      > GENERATE_VM_LONG_CONSTANT_ENTRY(name) (see vmStructs.hpp).
> >
> >     Not at all sure that's the right fix. In markOop.hpp we see that
> value
> >     gets special treatment on Windows-x64:
> >
> >
> >     #ifndef _WIN64
> >                ,hash_mask               = right_n_bits(hash_bits),
> >                hash_mask_in_place       = (address_word)hash_mask <<
> >     hash_shift
> >     #endif
> >         };
> >
> >         // Alignment of JavaThread pointers encoded in object header
> >     required
> >     by biased locking
> >         enum { biased_lock_alignment    = 2 << (epoch_shift + epoch_bits)
> >         };
> >
> >     #ifdef _WIN64
> >           // These values are too big for Win64
> >           const static uintptr_t hash_mask = right_n_bits(hash_bits);
> >           const static uintptr_t hash_mask_in_place  =
> >                                   (address_word)hash_mask << hash_shift;
> >     #endif
> >
> >     perhaps something special is needed for Windows-x86. I'm unclear how
> >     the
> >     values can be "too big" ??
> >
> >
> > I banged my head against this for an hour or so and I think this is a
> > compiler bug.
> >
> > What I get is:
> >
> > warning C4838: conversion from '' to 'uint64_t' requires a narrowing
> > conversion
> >
> > (Note the empty "from" string.)
> >
> > Here are my tries to provoke the error:
> >
> > VMLongConstantEntry iii[] = {  { "hallo",
> > markOopDesc::hash_mask_in_place }, {0,0}};  <<< this fails
> > VMLongConstantEntry iii = { "hallo", markOopDesc::hash_mask_in_place };
> >   << but this succeeds
> > uint64_t iii = markOopDesc::hash_mask_in_place;   << this succeeds  too
> >
> > I have no clue what this means. It is difficult to fix since the
> > expression is hidden in such a macro pile. But I think either we go with
> > my change or we disable the warning for win32 for the whole section.
> >
> >      >
> >      > With this patch we can build with warnings enabled on 32bit and
> 64bit
> >      > windows.
> >      >
> >      > Since patch fixes both hotspot and JDK parts, I'm sending it to
> >     hs-dev and
> >      > core-libs-dev.
> >
> >     Don't see anything that actually comes under core-libs-dev. Looks
> like
> >     one net-dev, one awt-dev and one security-dev. Sorry.
> >
> >
> > Okay, I will add them.
> >
> >     Cheers,
> >     David
> >     -----
> >
> >
> > Thanks for reviewing,
> >
> > Thomas
> >
> >      > Thanks, Thomas
> >      >
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/awt-dev/attachments/20190325/b23f0f6d/attachment.html>

From thomas.stuefe at gmail.com  Mon Mar 25 12:45:21 2019
From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=)
Date: Mon, 25 Mar 2019 13:45:21 +0100
Subject: <AWT Dev> RFR(xs): 8221375: Windows 32bit build (VS2017) broken
In-Reply-To: <CAA-vtUwA+cUxS3XHvNkwXP3hMPiW=WWhn5RFWsTK9qQA_NUHug@mail.gmail.com>
References: <CAA-vtUwuJ0MFWbgeT+Ch2qSZeZTFq-uYB-Fd3r3b3Ht+67S1wQ@mail.gmail.com>
 <44c67029-57fc-155c-39e1-bd810e70fe32@oracle.com>
 <CAA-vtUyhVLJm-TjJk-Rt4ibk7cYdM2k5ONUszt3ms39SjcoTHA@mail.gmail.com>
 <46ea4603-9a4c-6330-ad47-30fe4137fc0b@oracle.com>
 <CAA-vtUwA+cUxS3XHvNkwXP3hMPiW=WWhn5RFWsTK9qQA_NUHug@mail.gmail.com>
Message-ID: <CAA-vtUzbk8aCq8XV7pyDj3z5+dh9bjt7HtAm1MJWsm3o2bv0Yg@mail.gmail.com>

Hi all,

Following David's suggestion, I withdraw this bug and will open issues for
each area separately.

Cheers, Thomas



On Mon, Mar 25, 2019 at 1:44 PM Thomas St?fe <thomas.stuefe at gmail.com>
wrote:

> Hi David,
>
> Updating vs2017 did not help :/
>
> Cheers, Thomas
>
> On Mon, Mar 25, 2019 at 8:17 AM David Holmes <david.holmes at oracle.com>
> wrote:
>
>> Hi Thomas,
>>
>> On 25/03/2019 5:01 pm, Thomas St?fe wrote:
>> > Hi David,
>> >
>> > (added net-dev, awt-dev, security-dev since part of these fixes are in
>> > their territory)
>>
>> May be better to split up the reviews, cross-posting that many groups
>> gets very messy given most people won't be subscribed to them all -
>> myself included.
>>
>
>
>>
>> > On Mon, Mar 25, 2019 at 1:34 AM David Holmes <david.holmes at oracle.com
>> > <mailto:david.holmes at oracle.com>> wrote:
>> >
>> >     Hi Thomas,
>> >
>> >     A few queries, comments and concerns ...
>> >
>> >     On 25/03/2019 6:58 am, Thomas St?fe wrote:
>> >      > Hi all,
>> >      >
>> >      > After a long time I tried to build a Windows 32bit VM (VS2017)
>> >     and failed;
>> >
>> >     I'm somewhat surprised as I thought someone was actively doing
>> Windows
>> >     32-bit builds out there, plus there are shared code changes that
>> should
>> >     also have been caught by non-Windows 32-bit builds. :(
>> >
>> >
>> > Not sure what others do. I did a 32bit windows build, slowdebug,
>> warning
>> > enabled, and it failed with those 5+ issues.
>> >
>> >      > multiple errors and warnings. Lets reverse the bitrot:
>> >      >
>> >      > cr:
>> >      >
>> >
>> http://cr.openjdk.java.net/~stuefe/webrevs/8221375--windows-32bit-build-(vs2017)-broken-in-many-places/webrev.00/webrev/
>> >      >
>> >      > Issue: https://bugs.openjdk.java.net/browse/JDK-8221375
>> >      >
>> >      > Most of the fixes are trivial: Calling convention mismatches (awt
>> >     DTRACE
>> >      > callbacks), printf specifiers etc.
>> >      >
>> >      > Had to supress a warning in os_windows_x86.cpp - I was surprised
>> >     by this
>> >      > since this did not look 32bit specifc, do we disable warnings on
>> >     Windows
>> >      > 64bit builds?
>> >
>> >     What version of VS2017? We use VS2017 15.9.6 and we don't disable
>> >     warnings.
>> >
>> >
>> > I use VS2017 CE. Not sure which version spcifically, but my compiler is
>> at
>> >
>> > Microsoft (R) C/C++ Optimizing Compiler Version 19.14.26431 for x86
>>
>> I think that would equate to an older version - 15.7
>>
>> MSVC++ 14.14 _MSC_VER == 1914 (Visual Studio 2017 version 15.7)
>>
>> Any chance you can upgrade to latest version? (Especially in light of
>> the apparent compiler bug you cite below.)
>>
>> Thanks,
>> David
>> -----
>>
>> >      > The error I had in vmStructs.cpp was a bit weird: compiler
>> >     complained about
>> >      > an assignment of an enum value defined like this:
>> >      >
>> >      > hash_mask_in_place       = (address_word)hash_mask << hash_shift
>> >      >
>> >      > to an uint64_t variable, complaining about narrowing. I did not
>> >     find out
>> >      > what his problem was. In the end, I decided to add an explicit
>> >     cast to
>> >      > GENERATE_VM_LONG_CONSTANT_ENTRY(name) (see vmStructs.hpp).
>> >
>> >     Not at all sure that's the right fix. In markOop.hpp we see that
>> value
>> >     gets special treatment on Windows-x64:
>> >
>> >
>> >     #ifndef _WIN64
>> >                ,hash_mask               = right_n_bits(hash_bits),
>> >                hash_mask_in_place       = (address_word)hash_mask <<
>> >     hash_shift
>> >     #endif
>> >         };
>> >
>> >         // Alignment of JavaThread pointers encoded in object header
>> >     required
>> >     by biased locking
>> >         enum { biased_lock_alignment    = 2 << (epoch_shift +
>> epoch_bits)
>> >         };
>> >
>> >     #ifdef _WIN64
>> >           // These values are too big for Win64
>> >           const static uintptr_t hash_mask = right_n_bits(hash_bits);
>> >           const static uintptr_t hash_mask_in_place  =
>> >                                   (address_word)hash_mask << hash_shift;
>> >     #endif
>> >
>> >     perhaps something special is needed for Windows-x86. I'm unclear how
>> >     the
>> >     values can be "too big" ??
>> >
>> >
>> > I banged my head against this for an hour or so and I think this is a
>> > compiler bug.
>> >
>> > What I get is:
>> >
>> > warning C4838: conversion from '' to 'uint64_t' requires a narrowing
>> > conversion
>> >
>> > (Note the empty "from" string.)
>> >
>> > Here are my tries to provoke the error:
>> >
>> > VMLongConstantEntry iii[] = {  { "hallo",
>> > markOopDesc::hash_mask_in_place }, {0,0}};  <<< this fails
>> > VMLongConstantEntry iii = { "hallo", markOopDesc::hash_mask_in_place
>> };
>> >   << but this succeeds
>> > uint64_t iii = markOopDesc::hash_mask_in_place;   << this succeeds  too
>> >
>> > I have no clue what this means. It is difficult to fix since the
>> > expression is hidden in such a macro pile. But I think either we go
>> with
>> > my change or we disable the warning for win32 for the whole section.
>> >
>> >      >
>> >      > With this patch we can build with warnings enabled on 32bit and
>> 64bit
>> >      > windows.
>> >      >
>> >      > Since patch fixes both hotspot and JDK parts, I'm sending it to
>> >     hs-dev and
>> >      > core-libs-dev.
>> >
>> >     Don't see anything that actually comes under core-libs-dev. Looks
>> like
>> >     one net-dev, one awt-dev and one security-dev. Sorry.
>> >
>> >
>> > Okay, I will add them.
>> >
>> >     Cheers,
>> >     David
>> >     -----
>> >
>> >
>> > Thanks for reviewing,
>> >
>> > Thomas
>> >
>> >      > Thanks, Thomas
>> >      >
>> >
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/awt-dev/attachments/20190325/c6690e25/attachment-0001.html>

From thomas.stuefe at gmail.com  Mon Mar 25 13:09:27 2019
From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=)
Date: Mon, 25 Mar 2019 14:09:27 +0100
Subject: <AWT Dev> 8221405: Fix Windows 32bit awt build
Message-ID: <CAA-vtUwHAHf4fVE0LvW=_qnQgR5bG2Wc=twsafCRptL3L4zGdg@mail.gmail.com>

Hi all,

Issue: https://bugs.openjdk.java.net/browse/JDK-8221405
cr:
http://cr.openjdk.java.net/~stuefe/webrevs/8221405-windows32-awt-buildfixes/webrev.00/webrev/

On 32bit windows, awt build did bitrot. Dtrace print callbacks need to be
declared with __stdcall. No other platform cares.

Thanks, Thomas
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/awt-dev/attachments/20190325/6b226ea2/attachment.html>

From alexey.ivanov at oracle.com  Mon Mar 25 14:46:25 2019
From: alexey.ivanov at oracle.com (Alexey Ivanov)
Date: Mon, 25 Mar 2019 14:46:25 +0000
Subject: <AWT Dev> RFR(xs): 8221375: Windows 32bit build (VS2017) broken
In-Reply-To: <CAA-vtUzbk8aCq8XV7pyDj3z5+dh9bjt7HtAm1MJWsm3o2bv0Yg@mail.gmail.com>
References: <CAA-vtUwuJ0MFWbgeT+Ch2qSZeZTFq-uYB-Fd3r3b3Ht+67S1wQ@mail.gmail.com>
 <44c67029-57fc-155c-39e1-bd810e70fe32@oracle.com>
 <CAA-vtUyhVLJm-TjJk-Rt4ibk7cYdM2k5ONUszt3ms39SjcoTHA@mail.gmail.com>
 <46ea4603-9a4c-6330-ad47-30fe4137fc0b@oracle.com>
 <CAA-vtUwA+cUxS3XHvNkwXP3hMPiW=WWhn5RFWsTK9qQA_NUHug@mail.gmail.com>
 <CAA-vtUzbk8aCq8XV7pyDj3z5+dh9bjt7HtAm1MJWsm3o2bv0Yg@mail.gmail.com>
Message-ID: <8200636c-f2d8-b9b8-824b-a6e25445539b@oracle.com>

Hi Thomas,

There was a thread about failing build on 32 bit Windows:
http://mail.openjdk.java.net/pipermail/build-dev/2018-November/023767.html

It continued in February 2019:
http://mail.openjdk.java.net/pipermail/build-dev/2019-February/024925.html

Fast debug builds were affected. Likely there was mismatch between 
CALLBACK / JNICALL macro:
http://mail.openjdk.java.net/pipermail/build-dev/2019-February/024972.html
http://mail.openjdk.java.net/pipermail/build-dev/2019-February/024973.html

Magnus suggested a fix:
http://mail.openjdk.java.net/pipermail/build-dev/2019-February/024996.html

Yet there was no reply as whether it fixed the debug build or not.


Hope these pointers help.

Regards,
Alexey

On 25/03/2019 12:45, Thomas St?fe wrote:
> Hi all,
>
> Following David's suggestion, I withdraw this bug and will open issues 
> for each area separately.
>
> Cheers, Thomas
>
>
>
> On Mon, Mar 25, 2019 at 1:44 PM Thomas St?fe <thomas.stuefe at gmail.com 
> <mailto:thomas.stuefe at gmail.com>> wrote:
>
>     Hi David,
>
>     Updating vs2017 did not help :/
>
>     Cheers, Thomas
>
>     On Mon, Mar 25, 2019 at 8:17 AM David Holmes
>     <david.holmes at oracle.com <mailto:david.holmes at oracle.com>> wrote:
>
>         Hi Thomas,
>
>         On 25/03/2019 5:01 pm, Thomas St?fe wrote:
>         > Hi David,
>         >
>         > (added net-dev, awt-dev, security-dev since part of these
>         fixes are in
>         > their territory)
>
>         May be better to split up the reviews, cross-posting that many
>         groups
>         gets very messy given most people won't be subscribed to them
>         all -
>         myself included.
>
>
>
>         > On Mon, Mar 25, 2019 at 1:34 AM David Holmes
>         <david.holmes at oracle.com <mailto:david.holmes at oracle.com>
>         > <mailto:david.holmes at oracle.com
>         <mailto:david.holmes at oracle.com>>> wrote:
>         >
>         >? ? ?Hi Thomas,
>         >
>         >? ? ?A few queries, comments and concerns ...
>         >
>         >? ? ?On 25/03/2019 6:58 am, Thomas St?fe wrote:
>         >? ? ? > Hi all,
>         >? ? ? >
>         >? ? ? > After a long time I tried to build a Windows 32bit VM
>         (VS2017)
>         >? ? ?and failed;
>         >
>         >? ? ?I'm somewhat surprised as I thought someone was actively
>         doing Windows
>         >? ? ?32-bit builds out there, plus there are shared code
>         changes that should
>         >? ? ?also have been caught by non-Windows 32-bit builds. :(
>         >
>         >
>         > Not sure what others?do. I did a 32bit windows build,
>         slowdebug, warning
>         > enabled, and it failed with those 5+ issues.
>         >
>         >? ? ? > multiple errors and warnings. Lets reverse the bitrot:
>         >? ? ? >
>         >? ? ? > cr:
>         >? ? ? >
>         >
>         http://cr.openjdk.java.net/~stuefe/webrevs/8221375--windows-32bit-build-(vs2017)-broken-in-many-places/webrev.00/webrev/
>         >? ? ? >
>         >? ? ? > Issue: https://bugs.openjdk.java.net/browse/JDK-8221375
>         >? ? ? >
>         >? ? ? > Most of the fixes are trivial: Calling convention
>         mismatches (awt
>         >? ? ?DTRACE
>         >? ? ? > callbacks), printf specifiers etc.
>         >? ? ? >
>         >? ? ? > Had to supress a warning in os_windows_x86.cpp - I
>         was surprised
>         >? ? ?by this
>         >? ? ? > since this did not look 32bit specifc, do we disable
>         warnings on
>         >? ? ?Windows
>         >? ? ? > 64bit builds?
>         >
>         >? ? ?What version of VS2017? We use VS2017 15.9.6 and we
>         don't disable
>         >? ? ?warnings.
>         >
>         >
>         > I use VS2017 CE. Not sure which version spcifically, but my
>         compiler is at
>         >
>         > Microsoft (R) C/C++ Optimizing Compiler Version 19.14.26431
>         for x86
>
>         I think that would equate to an older version - 15.7
>
>         MSVC++ 14.14 _MSC_VER == 1914 (Visual Studio 2017 version 15.7)
>
>         Any chance you can upgrade to latest version? (Especially in
>         light of
>         the apparent compiler bug you cite below.)
>
>         Thanks,
>         David
>         -----
>
>         >? ? ? > The error I had in vmStructs.cpp was a bit weird:
>         compiler
>         >? ? ?complained about
>         >? ? ? > an assignment of an enum value defined like this:
>         >? ? ? >
>         >? ? ? > hash_mask_in_place? ? ? ?= (address_word)hash_mask <<
>         hash_shift
>         >? ? ? >
>         >? ? ? > to an uint64_t variable, complaining about narrowing.
>         I did not
>         >? ? ?find out
>         >? ? ? > what his problem was. In the end, I decided to add an
>         explicit
>         >? ? ?cast to
>         >? ? ? > GENERATE_VM_LONG_CONSTANT_ENTRY(name) (see
>         vmStructs.hpp).
>         >
>         >? ? ?Not at all sure that's the right fix. In markOop.hpp we
>         see that value
>         >? ? ?gets special treatment on Windows-x64:
>         >
>         >
>         >? ? ?#ifndef _WIN64
>         >? ? ? ? ? ? ? ? ,hash_mask? ? ? ? ? ? ? ?=
>         right_n_bits(hash_bits),
>         >? ? ? ? ? ? ? ? hash_mask_in_place? ? ? ?=
>         (address_word)hash_mask <<
>         >? ? ?hash_shift
>         >? ? ?#endif
>         >? ? ? ? ?};
>         >
>         >? ? ? ? ?// Alignment of JavaThread pointers encoded in
>         object header
>         >? ? ?required
>         >? ? ?by biased locking
>         >? ? ? ? ?enum { biased_lock_alignment? ? = 2 << (epoch_shift
>         + epoch_bits)
>         >? ? ? ? ?};
>         >
>         >? ? ?#ifdef _WIN64
>         >? ? ? ? ? ?// These values are too big for Win64
>         >? ? ? ? ? ?const static uintptr_t hash_mask =
>         right_n_bits(hash_bits);
>         >? ? ? ? ? ?const static uintptr_t hash_mask_in_place? =
>         > ?(address_word)hash_mask << hash_shift;
>         >? ? ?#endif
>         >
>         >? ? ?perhaps something special is needed for Windows-x86. I'm
>         unclear how
>         >? ? ?the
>         >? ? ?values can be "too big" ??
>         >
>         >
>         > I banged my head against this for an hour or so and I think
>         this is a
>         > compiler bug.
>         >
>         > What I get is:
>         >
>         > warning C4838: conversion from '' to 'uint64_t' requires a
>         narrowing
>         > conversion
>         >
>         > (Note the empty "from" string.)
>         >
>         > Here are my tries to provoke the error:
>         >
>         > VMLongConstantEntry iii[] = {? { "hallo",
>         > markOopDesc::hash_mask_in_place }, {0,0}}; <<< this fails
>         > VMLongConstantEntry iii = { "hallo",
>         markOopDesc::hash_mask_in_place };
>         >? ?<< but this succeeds
>         > uint64_t iii = markOopDesc::hash_mask_in_place; ?<< this
>         succeeds? too
>         >
>         > I have no clue what this means. It is difficult to fix since
>         the
>         > expression is hidden in such a macro pile. But I think
>         either we go with
>         > my change or we disable the warning for win32 for the whole
>         section.
>         >
>         >? ? ? >
>         >? ? ? > With this patch we can build with warnings enabled on
>         32bit and 64bit
>         >? ? ? > windows.
>         >? ? ? >
>         >? ? ? > Since patch fixes both hotspot and JDK parts, I'm
>         sending it to
>         >? ? ?hs-dev and
>         >? ? ? > core-libs-dev.
>         >
>         >? ? ?Don't see anything that actually comes under
>         core-libs-dev. Looks like
>         >? ? ?one net-dev, one awt-dev and one security-dev. Sorry.
>         >
>         >
>         > Okay, I will add them.
>         >
>         >? ? ?Cheers,
>         >? ? ?David
>         >? ? ?-----
>         >
>         >
>         > Thanks for reviewing,
>         >
>         > Thomas
>         >
>         >? ? ? > Thanks, Thomas
>         >? ? ? >
>         >
>

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

From thomas.stuefe at gmail.com  Mon Mar 25 14:58:41 2019
From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=)
Date: Mon, 25 Mar 2019 15:58:41 +0100
Subject: <AWT Dev> RFR(xs): 8221375: Windows 32bit build (VS2017) broken
In-Reply-To: <8200636c-f2d8-b9b8-824b-a6e25445539b@oracle.com>
References: <CAA-vtUwuJ0MFWbgeT+Ch2qSZeZTFq-uYB-Fd3r3b3Ht+67S1wQ@mail.gmail.com>
 <44c67029-57fc-155c-39e1-bd810e70fe32@oracle.com>
 <CAA-vtUyhVLJm-TjJk-Rt4ibk7cYdM2k5ONUszt3ms39SjcoTHA@mail.gmail.com>
 <46ea4603-9a4c-6330-ad47-30fe4137fc0b@oracle.com>
 <CAA-vtUwA+cUxS3XHvNkwXP3hMPiW=WWhn5RFWsTK9qQA_NUHug@mail.gmail.com>
 <CAA-vtUzbk8aCq8XV7pyDj3z5+dh9bjt7HtAm1MJWsm3o2bv0Yg@mail.gmail.com>
 <8200636c-f2d8-b9b8-824b-a6e25445539b@oracle.com>
Message-ID: <CAA-vtUzzXRkRiEsdhWUPWjFAstmoGLYzbPkkau-LLM5JiO7dTA@mail.gmail.com>

Hi Alexey,

thanks. I posted an updated fix for this on awt-net (8221405) since David
asked me to split the patch up. Could you please review it?

Thanks! ..Thomas


On Mon, Mar 25, 2019 at 3:46 PM Alexey Ivanov <alexey.ivanov at oracle.com>
wrote:

> Hi Thomas,
>
> There was a thread about failing build on 32 bit Windows:
> http://mail.openjdk.java.net/pipermail/build-dev/2018-November/023767.html
>
> It continued in February 2019:
> http://mail.openjdk.java.net/pipermail/build-dev/2019-February/024925.html
>
> Fast debug builds were affected. Likely there was mismatch between
> CALLBACK / JNICALL macro:
> http://mail.openjdk.java.net/pipermail/build-dev/2019-February/024972.html
> http://mail.openjdk.java.net/pipermail/build-dev/2019-February/024973.html
>
> Magnus suggested a fix:
> http://mail.openjdk.java.net/pipermail/build-dev/2019-February/024996.html
>
> Yet there was no reply as whether it fixed the debug build or not.
>
>
> Hope these pointers help.
>
> Regards,
> Alexey
>
> On 25/03/2019 12:45, Thomas St?fe wrote:
>
> Hi all,
>
> Following David's suggestion, I withdraw this bug and will open issues for
> each area separately.
>
> Cheers, Thomas
>
>
>
> On Mon, Mar 25, 2019 at 1:44 PM Thomas St?fe <thomas.stuefe at gmail.com>
> wrote:
>
>> Hi David,
>>
>> Updating vs2017 did not help :/
>>
>> Cheers, Thomas
>>
>> On Mon, Mar 25, 2019 at 8:17 AM David Holmes <david.holmes at oracle.com>
>> wrote:
>>
>>> Hi Thomas,
>>>
>>> On 25/03/2019 5:01 pm, Thomas St?fe wrote:
>>> > Hi David,
>>> >
>>> > (added net-dev, awt-dev, security-dev since part of these fixes are in
>>> > their territory)
>>>
>>> May be better to split up the reviews, cross-posting that many groups
>>> gets very messy given most people won't be subscribed to them all -
>>> myself included.
>>>
>>
>>
>>>
>>> > On Mon, Mar 25, 2019 at 1:34 AM David Holmes <david.holmes at oracle.com
>>> > <mailto:david.holmes at oracle.com>> wrote:
>>> >
>>> >     Hi Thomas,
>>> >
>>> >     A few queries, comments and concerns ...
>>> >
>>> >     On 25/03/2019 6:58 am, Thomas St?fe wrote:
>>> >      > Hi all,
>>> >      >
>>> >      > After a long time I tried to build a Windows 32bit VM (VS2017)
>>> >     and failed;
>>> >
>>> >     I'm somewhat surprised as I thought someone was actively doing
>>> Windows
>>> >     32-bit builds out there, plus there are shared code changes that
>>> should
>>> >     also have been caught by non-Windows 32-bit builds. :(
>>> >
>>> >
>>> > Not sure what others do. I did a 32bit windows build, slowdebug,
>>> warning
>>> > enabled, and it failed with those 5+ issues.
>>> >
>>> >      > multiple errors and warnings. Lets reverse the bitrot:
>>> >      >
>>> >      > cr:
>>> >      >
>>> >
>>> http://cr.openjdk.java.net/~stuefe/webrevs/8221375--windows-32bit-build-(vs2017)-broken-in-many-places/webrev.00/webrev/
>>> >      >
>>> >      > Issue: https://bugs.openjdk.java.net/browse/JDK-8221375
>>> >      >
>>> >      > Most of the fixes are trivial: Calling convention mismatches
>>> (awt
>>> >     DTRACE
>>> >      > callbacks), printf specifiers etc.
>>> >      >
>>> >      > Had to supress a warning in os_windows_x86.cpp - I was surprised
>>> >     by this
>>> >      > since this did not look 32bit specifc, do we disable warnings on
>>> >     Windows
>>> >      > 64bit builds?
>>> >
>>> >     What version of VS2017? We use VS2017 15.9.6 and we don't disable
>>> >     warnings.
>>> >
>>> >
>>> > I use VS2017 CE. Not sure which version spcifically, but my compiler
>>> is at
>>> >
>>> > Microsoft (R) C/C++ Optimizing Compiler Version 19.14.26431 for x86
>>>
>>> I think that would equate to an older version - 15.7
>>>
>>> MSVC++ 14.14 _MSC_VER == 1914 (Visual Studio 2017 version 15.7)
>>>
>>> Any chance you can upgrade to latest version? (Especially in light of
>>> the apparent compiler bug you cite below.)
>>>
>>> Thanks,
>>> David
>>> -----
>>>
>>> >      > The error I had in vmStructs.cpp was a bit weird: compiler
>>> >     complained about
>>> >      > an assignment of an enum value defined like this:
>>> >      >
>>> >      > hash_mask_in_place       = (address_word)hash_mask << hash_shift
>>> >      >
>>> >      > to an uint64_t variable, complaining about narrowing. I did not
>>> >     find out
>>> >      > what his problem was. In the end, I decided to add an explicit
>>> >     cast to
>>> >      > GENERATE_VM_LONG_CONSTANT_ENTRY(name) (see vmStructs.hpp).
>>> >
>>> >     Not at all sure that's the right fix. In markOop.hpp we see that
>>> value
>>> >     gets special treatment on Windows-x64:
>>> >
>>> >
>>> >     #ifndef _WIN64
>>> >                ,hash_mask               = right_n_bits(hash_bits),
>>> >                hash_mask_in_place       = (address_word)hash_mask <<
>>> >     hash_shift
>>> >     #endif
>>> >         };
>>> >
>>> >         // Alignment of JavaThread pointers encoded in object header
>>> >     required
>>> >     by biased locking
>>> >         enum { biased_lock_alignment    = 2 << (epoch_shift +
>>> epoch_bits)
>>> >         };
>>> >
>>> >     #ifdef _WIN64
>>> >           // These values are too big for Win64
>>> >           const static uintptr_t hash_mask = right_n_bits(hash_bits);
>>> >           const static uintptr_t hash_mask_in_place  =
>>> >                                   (address_word)hash_mask <<
>>> hash_shift;
>>> >     #endif
>>> >
>>> >     perhaps something special is needed for Windows-x86. I'm unclear
>>> how
>>> >     the
>>> >     values can be "too big" ??
>>> >
>>> >
>>> > I banged my head against this for an hour or so and I think this is a
>>> > compiler bug.
>>> >
>>> > What I get is:
>>> >
>>> > warning C4838: conversion from '' to 'uint64_t' requires a narrowing
>>> > conversion
>>> >
>>> > (Note the empty "from" string.)
>>> >
>>> > Here are my tries to provoke the error:
>>> >
>>> > VMLongConstantEntry iii[] = {  { "hallo",
>>> > markOopDesc::hash_mask_in_place }, {0,0}};  <<< this fails
>>> > VMLongConstantEntry iii = { "hallo", markOopDesc::hash_mask_in_place
>>> };
>>> >   << but this succeeds
>>> > uint64_t iii = markOopDesc::hash_mask_in_place;   << this succeeds  too
>>> >
>>> > I have no clue what this means. It is difficult to fix since the
>>> > expression is hidden in such a macro pile. But I think either we go
>>> with
>>> > my change or we disable the warning for win32 for the whole section.
>>> >
>>> >      >
>>> >      > With this patch we can build with warnings enabled on 32bit and
>>> 64bit
>>> >      > windows.
>>> >      >
>>> >      > Since patch fixes both hotspot and JDK parts, I'm sending it to
>>> >     hs-dev and
>>> >      > core-libs-dev.
>>> >
>>> >     Don't see anything that actually comes under core-libs-dev. Looks
>>> like
>>> >     one net-dev, one awt-dev and one security-dev. Sorry.
>>> >
>>> >
>>> > Okay, I will add them.
>>> >
>>> >     Cheers,
>>> >     David
>>> >     -----
>>> >
>>> >
>>> > Thanks for reviewing,
>>> >
>>> > Thomas
>>> >
>>> >      > Thanks, Thomas
>>> >      >
>>> >
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/awt-dev/attachments/20190325/85e1bf00/attachment.html>

From takiguc at linux.vnet.ibm.com  Mon Mar 25 16:28:02 2019
From: takiguc at linux.vnet.ibm.com (Ichiroh Takiguchi)
Date: Tue, 26 Mar 2019 01:28:02 +0900
Subject: <AWT Dev> RFR: 8213232 Unix/X11 setCompositionEnableNative issue
In-Reply-To: <a2c8c52f2075c49ae256564208f2d0d0@linux.vnet.ibm.com>
References: <9ad6f2166ea8eabcf7391feccf9d8915@linux.vnet.ibm.com>
 <0a651f1099a96e314573b6b8c9f60e6c@linux.vnet.ibm.com>
 <50e98ca5cbdc56a5a13b0754968521c2@linux.vnet.ibm.com>
 <a2c8c52f2075c49ae256564208f2d0d0@linux.vnet.ibm.com>
Message-ID: <2a317b57477504d617ef46a0cbfc28a9@linux.vnet.ibm.com>

Hello.

Could you review the fix and give me your suggestion, please ?
I really appreciate your feedback.

Currently, UnsupportedOperationException happens because of invalid 
usage
by input method operation.

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

Thanks,
Ichiroh Takiguchi

On 2019-03-11 22:00, Ichiroh Takiguchi wrote:
> Hello.
> 
> Could you review the fix and give me your suggestion, please ?
> 
> Thanks,
> Ichiroh Takiguchi
> 
> On 2019-02-26 22:08, Ichiroh Takiguchi wrote:
>> Hello.
>> 
>> Could you review the fix ?
>> 
>> Bug:    https://bugs.openjdk.java.net/browse/JDK-8213232
>> Change: https://cr.openjdk.java.net/~itakiguchi/8213232/webrev.01/
>> 
>> JDK-8213232 [1] has movies.
>> Please check it.
>> 
>> I applied following changes on webrev.01:
>> 1. According to "Xlib - C Language X Interface" [2]
>>    See "Preedit State Callbacks" section:
>>    PreeditStartCallback() should return int.
>> 2. Add 64bit Big Endian CPU support, like s390x
>> 3. Change copyright year
>> 
>> [1] https://bugs.openjdk.java.net/browse/JDK-8213232
>> [2] 
>> https://www.x.org/releases/X11R7.6/doc/libX11/specs/libX11/libX11.html
>> 
>> Thanks,
>> Ichiroh Takiguchi
>> IBM Japan, Ltd.
>> 
>> On 2018-12-04 11:22, Ichiroh Takiguchi wrote:
>>> Hello.
>>> 
>>> Could you review the fix ?
>>> 
>>> Bug:    https://bugs.openjdk.java.net/browse/JDK-8213232
>>> Change: https://cr.openjdk.java.net/~itakiguchi/8213232/webrev.00/
>>> 
>>> This issue is related by wrong usage of XNPreeditState on 
>>> XSetICValues().
>>> Because of wrong usage, UnsupportedOperationException exception
>>> happened with Xlib bundled input method.
>>> Test instructions is in JDK-8213232.
>>> 
>>> I'd like to obtain a sponsor for this issue.
>>> 
>>> Thanks,
>>> Ichiroh Takiguchi
>>> IBM Japan, Ltd.
>>> 
>>> On 2018-06-19 02:15, Ichiroh Takiguchi wrote:
>>>> Hello,
>>>> IBM would like to contribute Unix/X11 setCompositionEnableNative 
>>>> issue
>>>> patch to OpenJDK project.
>>>> 
>>>> Issue:
>>>> To  turn on or turn off IME via Java, XNPreeditState should be used
>>>> with XSetValues().
>>>> But it should be nested via XVaCreateNestedList() since 
>>>> XNPreeditState
>>>> is a part of XNPreeditAttributes.
>>>> Current code is, like:
>>>> -    ret = XSetICValues(pX11IMData->current_ic, XNPreeditState,
>>>> -                       (enable ? XIMPreeditEnable : 
>>>> XIMPreeditDisable), NULL);
>>>> But it should be, like:
>>>> +    pr_atrb = XVaCreateNestedList(0,
>>>> +                  XNPreeditState, (enable ? XIMPreeditEnable :
>>>> XIMPreeditDisable),
>>>> +                  NULL);
>>>> +    ret = XSetICValues(pX11IMData->current_ic, XNPreeditAttributes,
>>>> pr_atrb, NULL);
>>>> 
>>>> On Linux platform, the issue can check with following test program 
>>>> and
>>>> kinput2 XIM server and
>>>> Wnn8 for Linux/BSD (htt).
>>>> ==================
>>>> import java.awt.*;
>>>> import java.awt.event.*;
>>>> import javax.swing.*;
>>>> 
>>>> public class CompositionEnabledTest extends JFrame {
>>>>   CompositionEnabledTest() {
>>>>     Container c = getContentPane();
>>>>     c.setLayout(new GridLayout(0,2));
>>>>     JButton btn;
>>>>     JTextField tf;
>>>>     btn = new JButton("Undefined");
>>>>     c.add(btn);
>>>>     tf = new JTextField("Undefined");
>>>>     c.add(tf);
>>>>     btn = new JButton("Disabled");
>>>>     btn.addFocusListener(new MyFocusListener(false));
>>>>     c.add(btn);
>>>>     tf = new JTextField("Disabled");
>>>>     tf.addFocusListener(new MyFocusListener(false));
>>>>     c.add(tf);
>>>>     btn = new JButton("Enabled");
>>>>     btn.addFocusListener(new MyFocusListener(true));
>>>>     c.add(btn);
>>>>     tf = new JTextField("Enabled");
>>>>     tf.addFocusListener(new MyFocusListener(true));
>>>>     c.add(tf);
>>>>     setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);
>>>>     pack();
>>>>     setVisible(true);
>>>>   }
>>>>   class MyFocusListener implements FocusListener {
>>>>     boolean state;
>>>>     MyFocusListener(boolean state) {
>>>>       this.state = state;
>>>>     }
>>>>     public void focusGained(FocusEvent fe) {
>>>>       
>>>> fe.getComponent().getInputContext().setCompositionEnabled(state);
>>>>     }
>>>>     public void focusLost(FocusEvent fe) { }
>>>>   }
>>>>   public static void main(String[] args) {
>>>>     new CompositionEnabledTest();
>>>>   }
>>>> }
>>>> ==================
>>>> 
>>>> Click JTextField and JButton, then XIM server status may be changed.
>>>> If XIM server does not support XNPreeditState, it does not work.
>>>> 
>>>> I'd like contribute following 3 files:
>>>> M src/java.desktop/share/classes/sun/awt/im/InputContext.java
>>>> M src/java.desktop/unix/classes/sun/awt/X11InputMethod.java
>>>> M src/java.desktop/unix/native/libawt_xawt/awt/awt_InputMethod.c
>>>> 
>>>> http://cr.openjdk.java.net/~aleonard/set_composition_enabled/webrev.00/
>>>> 
>>>> I appreciate any feedback please, and how I would go about obtaining 
>>>> a
>>>> sponsor and contributor?
>>>> 
>>>> Thanks,
>>>> Ichiroh Takiguchi
>>>> IBM Japan, Ltd.


From takiguc at linux.vnet.ibm.com  Mon Mar 25 16:39:11 2019
From: takiguc at linux.vnet.ibm.com (Ichiroh Takiguchi)
Date: Tue, 26 Mar 2019 01:39:11 +0900
Subject: <AWT Dev> RFR: 8212676 java.awt.SystemColor setting on CDE
In-Reply-To: <38f580c8-8945-618e-baef-3d2447ac0662@oracle.com>
References: <5f309d9c612f2c16aef75846e0ff14fa@linux.vnet.ibm.com>
 <d2b3bc94-0ba3-712f-c46b-f83048491cb0@oracle.com>
 <f942c133e212bace34e72e79bfb64ab4@linux.vnet.ibm.com>
 <0ede447e30ed05ce7a52f6d133b2c15b@linux.vnet.ibm.com>
 <180114e58e98f339332e3a781a34126b@linux.vnet.ibm.com>
 <d9e8c69e64ff87bb84a9468b4364fb06@linux.vnet.ibm.com>
 <5a4f9f5c7a80a5abda9edd150e19a11f@linux.vnet.ibm.com>
 <4addeebf-9ed8-bb63-5920-49ae6fb429b1@oracle.com>
 <c314e88dcc25495f6fba698f8ad5ae63@linux.vnet.ibm.com>
 <5C0725B5.3080907@oracle.com> <5C0773E7.8030108@oracle.com>
 <ad8f6c895b66c65a0b7bc344c5a759e0@linux.vnet.ibm.com>
 <13a9685a38984c56ec2f0aaa084a3f80@linux.vnet.ibm.com>
 <368b32e110b608570c4929e216ee37c6@linux.vnet.ibm.com>
 <10ad0a1a-b4ad-3978-fab0-87c28005a879@oracle.com>
 <5c62bbea9c6a2550b4f960708c38c856@linux.vnet.ibm.com>
 <38f580c8-8945-618e-baef-3d2447ac0662@oracle.com>
Message-ID: <c59fc2bcfa918698f0512ca18cbf17e8@linux.vnet.ibm.com>

Hello.

Another reviewer is required for this fix.
Bug:    https://bugs.openjdk.java.net/browse/JDK-8212676
Change: https://cr.openjdk.java.net/~itakiguchi/8212676/webrev.02/

Could you review the fix and give me your suggestion or feedback, please 
?
And I'd like to obtain a sponsor for this issue.

Thanks,
Ichiroh Takiguchi

On 2019-03-21 07:56, Sergey Bylokhov wrote:
> Looks fine.
> Thank you for contribution!
> 
> On 19/03/2019 10:22, Ichiroh Takiguchi wrote:
>> Hello Sergey.
>> 
>> Thank you for your suggestion.
>> I changed Subject.
>> From: AIX's CDE/MWM support
>> To: AWT SystemColor setting on CDE
>> 
>> Could you review the fix and give me your suggestion again ?
>> 
>> Bug:??? https://bugs.openjdk.java.net/browse/JDK-8212676
>> Change: https://cr.openjdk.java.net/~itakiguchi/8212676/webrev.02/
>> 
>> For AIX dtwm/mwm issue, I opened JDK-8221082 [1].
>> 
>> [1]? https://bugs.openjdk.java.net/browse/JDK-8221082
>> 
>> Thanks,
>> Ichiroh Takiguchi
>> 
>> On 2019-03-19 08:42, Sergey Bylokhov wrote:
>>> Hi, Ichiroh.
>>> 
>>> It looks fine, but I have one general comment: this fix is not about
>>> some general support of "AIX's CDE/MWM", but it is mostly about
>>> initialization of "java.awt.SystemColor", which is already used by 
>>> the
>>> awt/swing.
>>> 
>>> On 11/03/2019 19:04, Ichiroh Takiguchi wrote:
>>>> Hello.
>>>> 
>>>> Could you review the fix and give me your suggestion, please ?
>>>> 
>>>> Thanks,
>>>> Ichiroh Takiguchi
>>>> 
>>>> On 2019-03-01 22:16, Ichiroh Takiguchi wrote:
>>>>> Hello.
>>>>> 
>>>>> Could you review the fix again ?
>>>>> 
>>>>> Bug:??? https://bugs.openjdk.java.net/browse/JDK-8212676
>>>>> Change: https://cr.openjdk.java.net/~itakiguchi/8212676/webrev.01/
>>>>> 
>>>>> I applied following changes:
>>>>> * I added AIX detection code into sun.awt.OSInfo class.
>>>>> ? It seems CDE's default should be middle color.
>>>>> ? But AIX's default is high color, so AIX detection code is 
>>>>> required.
>>>>> * MWM detection code can be used on Linux and AIX platform
>>>>> ? AIX only code was removed
>>>>> * I could not recreate XMapRaised/XMapWindow related issue.
>>>>> ? The fix was ignored
>>>>> * Non-focusable window handling on DTWM/MWM
>>>>> ? I checked Linux's MWM working behavior on RHEL6.
>>>>> ? I applied AIX's code into Linux side, but it was bad.
>>>>> ? Working behavior became worse.
>>>>> ? So AIX detection feature is still required.
>>>>> 
>>>>> (JDK-8212676 was also updated)
>>>>> 
>>>>> I'd like to obtain a sponsor for this issue.
>>>>> 
>>>>> Thanks,
>>>>> Ichiroh Takiguchi
>>>>> IBM Japan, Ltd.
>>>>> 
>>>>> On 2018-12-05 18:22, Ichiroh Takiguchi wrote:
>>>>>> Hello Phil.
>>>>>> 
>>>>>> I heard some of AIX users used RealVNC VNC Enterprise Edition for 
>>>>>> AIX
>>>>>> maintenance. [1]
>>>>>> I assume they still use CDE.
>>>>>> 
>>>>>> [1] 
>>>>>> https://www.realvnc.com/en/connect/download/vnc/aix/#older-versions
>>>>>> 
>>>>>> Thanks,
>>>>>> Ichiroh Takiguchi
>>>>>> 
>>>>>> On 2018-12-05 15:44, Philip Race wrote:
>>>>>>> . and I think I need to be convinced about whether "aix" is the 
>>>>>>> right
>>>>>>> thing to check here.
>>>>>>> "I know AIX works like this today" isn't a very robust, or very
>>>>>>> portable approach.
>>>>>>> The fix is more about the CDE/Motif environment than AIX, isn't 
>>>>>>> it ?
>>>>>>> 
>>>>>>> -phil.
>>>>>>> 
>>>>>>> 
>>>>>>> On 12/4/18, 5:11 PM, Philip Race wrote:
>>>>>>>> 
>>>>>>>> 
>>>>>>>> On 12/4/18, 5:10 PM, Ichiroh Takiguchi wrote:
>>>>>>>>> Hello Phil.
>>>>>>>>> 
>>>>>>>>>> I haven't evaluated the merits of this proposal but this
>>>>>>>>>> https://cr.openjdk.java.net/~itakiguchi/8212676/webrev.00/src/java.desktop/share/classes/sun/font/FontUtilities.java.udiff.html 
>>>>>>>>>> is not the right place to support a flag used in all these X11 
>>>>>>>>>> files.
>>>>>>>>> Could you give me your recommendation ?
>>>>>>>> 
>>>>>>>> Somewhere closer to the code that needs it.
>>>>>>>>> 
>>>>>>>>>> And why is i18n-dev on the review ? I can't see any I18N 
>>>>>>>>>> related changes.
>>>>>>>>> I thought focus issue was related input method.
>>>>>>>> 
>>>>>>>> No. I mean input focus is necessary for input methods but focus 
>>>>>>>> does not
>>>>>>>> automatically mean input methods are in play.
>>>>>>>> 
>>>>>>>> -phil
>>>>>>>> 
>>>>>>>>> AIX IM was activated even if focus was moved to non focusable 
>>>>>>>>> window (middle window). [1]
>>>>>>>>> So I posted this issue into I18N, but it was not good.
>>>>>>>>> Actually, all key events were forwarded to middle window if 
>>>>>>>>> user clicked inside of right window.
>>>>>>>>> 
>>>>>>>>> [1] 
>>>>>>>>> https://bugs.openjdk.java.net/secure/attachment/79986/aix-focusable.png
>>>>>>>>> 
>>>>>>>>> Thanks,
>>>>>>>>> Ichiroh Takiguchi
>>>>>>>>> 
>>>>>>>>> On 2018-12-05 03:06, Phil Race wrote:
>>>>>>>>>> I haven't evaluated the merits of this proposal but this
>>>>>>>>>> https://cr.openjdk.java.net/~itakiguchi/8212676/webrev.00/src/java.desktop/share/classes/sun/font/FontUtilities.java.udiff.html 
>>>>>>>>>> is not the right place to support a flag used in all these X11 
>>>>>>>>>> files.
>>>>>>>>>> 
>>>>>>>>>> And why is i18n-dev on the review ? I can't see any I18N 
>>>>>>>>>> related changes.
>>>>>>>>>> 
>>>>>>>>>> -phil.
>>>>>>>>>> 
>>>>>>>>>> On 12/4/18 8:53 AM, Ichiroh Takiguchi wrote:
>>>>>>>>>>> Hello again.
>>>>>>>>>>> 
>>>>>>>>>>> Could you give me review comment and/or suggestion ?
>>>>>>>>>>> 
>>>>>>>>>>> Bug:??? https://bugs.openjdk.java.net/browse/JDK-8212676
>>>>>>>>>>> Change: 
>>>>>>>>>>> https://cr.openjdk.java.net/~itakiguchi/8212676/webrev.00/
>>>>>>>>>>> 
>>>>>>>>>>> Thanks,
>>>>>>>>>>> Ichiroh Takiguchi
>>>>>>>>>>> 
>>>>>>>>>>> On 2018-11-26 21:27, Ichiroh Takiguchi wrote:
>>>>>>>>>>>> Hello.
>>>>>>>>>>>> 
>>>>>>>>>>>> Could you review the fix ?
>>>>>>>>>>>> 
>>>>>>>>>>>> Bug:??? https://bugs.openjdk.java.net/browse/JDK-8212676
>>>>>>>>>>>> Change: 
>>>>>>>>>>>> https://cr.openjdk.java.net/~itakiguchi/8212676/webrev.00/
>>>>>>>>>>>> 
>>>>>>>>>>>> Test instructions and screen shots are in JDK-8212676.
>>>>>>>>>>>> 
>>>>>>>>>>>> GUI environment for AIX platform still needs CDE support.
>>>>>>>>>>>> This fix is required to avoid unexpected working behavior on 
>>>>>>>>>>>> AIX platform.
>>>>>>>>>>>> 
>>>>>>>>>>>> I'd like to obtain a sponsor for this issue.
>>>>>>>>>>>> 
>>>>>>>>>>>> Thanks,
>>>>>>>>>>>> Ichiroh Takiguchi
>>>>>>>>>>>> IBM Japan, Ltd.
>>>>>>>>>>>> 
>>>>>>>>>>>> On 2018-06-18 18:57, Ichiroh Takiguchi wrote:
>>>>>>>>>>>>> Hello.
>>>>>>>>>>>>> 
>>>>>>>>>>>>> This fix is really required for AIX's GUI.
>>>>>>>>>>>>> System color setting and window manager's working behavior 
>>>>>>>>>>>>> are very important.
>>>>>>>>>>>>> 
>>>>>>>>>>>>> I appreciate any feedback, and how I would go about 
>>>>>>>>>>>>> obtaining a
>>>>>>>>>>>>> sponsor and contributor ?
>>>>>>>>>>>>> 
>>>>>>>>>>>>> On 2018-05-25 11:02, Ichiroh Takiguchi wrote:
>>>>>>>>>>>>>> Hello Phil.
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> webrev file was extracted.
>>>>>>>>>>>>>> Please see
>>>>>>>>>>>>>> ? http://cr.openjdk.java.net/~aleonard/AIX_GUI/webrev.00/
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> On 2018-05-19 02:48, Ichiroh Takiguchi wrote:
>>>>>>>>>>>>>>> Hello Phil.
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> Webrev.zip file is stored into
>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~aleonard/AIX_GUI/webrev-aixgui.zip
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> Test programs are also stored:
>>>>>>>>>>>>>>> No testcase is available for FontUtilities.java and 
>>>>>>>>>>>>>>> XDecoratedPeer.java.
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> MotifColorUtilities.java
>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~aleonard/AIX_GUI/SystemColorTest2.java
>>>>>>>>>>>>>>> Run SystemColorTest2, system colors should be displayed
>>>>>>>>>>>>>>> AIX sample is
>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~aleonard/AIX_GUI/aix_systemcolor.txt
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> XWM.java
>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~aleonard/AIX_GUI/XWMTest1.java
>>>>>>>>>>>>>>> On AIX CDE, isMotif and isCDE were true.
>>>>>>>>>>>>>>> On AIX MWM, every entry is false.
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> XWindowPeer.java
>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~aleonard/AIX_GUI/JFrameTest.java
>>>>>>>>>>>>>>> On AIX CDE, click inside of "Non-Focusable" window (not 
>>>>>>>>>>>>>>> window frame).
>>>>>>>>>>>>>>> Window focus should not be changed because of "click on 
>>>>>>>>>>>>>>> focus" feature.
>>>>>>>>>>>>>>> But input focus is moved to "Non-Focusable" window.
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> On 2018-05-18 01:00, Phil Race wrote:
>>>>>>>>>>>>>>>> I think we'd need to see the actual proposed changes and 
>>>>>>>>>>>>>>>> understand
>>>>>>>>>>>>>>>> the implications
>>>>>>>>>>>>>>>> for ongoing support as we no longer support any platform 
>>>>>>>>>>>>>>>> which has a
>>>>>>>>>>>>>>>> CDE desktop.
>>>>>>>>>>>>>>>> Solaris 11.3 uses Gnome, so we'd be more inclined to be 
>>>>>>>>>>>>>>>> ripping out
>>>>>>>>>>>>>>>> such support rather
>>>>>>>>>>>>>>>> than adding to it.
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> -phil.
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> On 05/17/2018 04:18 AM, Ichiroh Takiguchi wrote:
>>>>>>>>>>>>>>>>> Hello,
>>>>>>>>>>>>>>>>> IBM would like to contribute AIX's CDE (Common Desktop 
>>>>>>>>>>>>>>>>> Environment) DTWM (Desktop Window Manager) /MWM (Motif 
>>>>>>>>>>>>>>>>> Window Manager) support to OpenJDK project.
>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>> I'd like contribute following 5 files:
>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>> M 
>>>>>>>>>>>>>>>>> src/java.desktop/share/classes/sun/font/FontUtilities.java
>>>>>>>>>>>>>>>>> (Add isAIX flag to determine AIX platform for GUI 
>>>>>>>>>>>>>>>>> environment)
>>>>>>>>>>>>>>>>> M 
>>>>>>>>>>>>>>>>> src/java.desktop/unix/classes/sun/awt/X11/MotifColorUtilities.java 
>>>>>>>>>>>>>>>>> (Add High Color support on CDE, OpenJDK just supports 
>>>>>>>>>>>>>>>>> Medium Color) [1]
>>>>>>>>>>>>>>>>> M 
>>>>>>>>>>>>>>>>> src/java.desktop/unix/classes/sun/awt/X11/XDecoratedPeer.java
>>>>>>>>>>>>>>>>> (Avoid miss calculation for window position under 
>>>>>>>>>>>>>>>>> DTWM/MWM by XMapRaised/XMapWindow)
>>>>>>>>>>>>>>>>> M src/java.desktop/unix/classes/sun/awt/X11/XWM.java
>>>>>>>>>>>>>>>>> (Detect MWM on AIX platform)
>>>>>>>>>>>>>>>>> M 
>>>>>>>>>>>>>>>>> src/java.desktop/unix/classes/sun/awt/X11/XWindowPeer.java
>>>>>>>>>>>>>>>>> (Add non-focusable window support on DTWM/MWM for AIX, 
>>>>>>>>>>>>>>>>> because DTWM/MWM does not have enough features for 
>>>>>>>>>>>>>>>>> ICCCM)
>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>> I appreciate any feedback please, and how I would go 
>>>>>>>>>>>>>>>>> about obtaining a sponsor and contributor ?
>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>>>>>> Ichiroh Takiguchi
>>>>>>>>>>>>>>>>> IBM Japan, Ltd.
>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>> [1] 
>>>>>>>>>>>>>>>>> https://docs.oracle.com/cd/E19253-01/806-7492/fontsandcolors-15233/index.html
>>>>>>>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>> 
>>>> 
>> 


From volker.simonis at gmail.com  Mon Mar 25 18:42:02 2019
From: volker.simonis at gmail.com (Volker Simonis)
Date: Mon, 25 Mar 2019 19:42:02 +0100
Subject: <AWT Dev> [OpenJDK 2D-Dev] RFR: 8220528: [AIX] Fix basic
 Xinerama and Xrender functionality
In-Reply-To: <CAA-vtUwXF7QaEMm+i=8U5zH0y6MkOFPvKRtnQsm+x2+Z_uyPPA@mail.gmail.com>
References: <CA+3eh130xEVyDdr=r+kjY9A1c8pqKkCSw4gb+3OpNFBLMts0UQ@mail.gmail.com>
 <CA+3eh1000n2+dtBf_+A7OFvTPceL86ASMBHfUn_NdDswPRbmYQ@mail.gmail.com>
 <CAA-vtUwXF7QaEMm+i=8U5zH0y6MkOFPvKRtnQsm+x2+Z_uyPPA@mail.gmail.com>
Message-ID: <CA+3eh12-jEJywLruafE6bn79bT4CkyXJz7iHTWqiwaaywybHXQ@mail.gmail.com>

Hi Thomas, Christoph,

thanks for looking into my fix. I hope I've addressed all your
concerns with my new webrev:

http://cr.openjdk.java.net/~simonis/webrevs/2019/8220528.v4

By the way, I've tested the new implementation by simulating a
multi-screen environment on my Linux box with Xephyr:

$ Xephyr +xinerama -screen 1024x768 -screen 1024x768+1024+0 -ac -listen tcp :1

And started a Swing application from AIX where I've redirected the
DISPLAY to myhost:1:

$ DISPLAY=myhost:1 ./images/jdk/bin/java -showversion
-Dsun.awt.nativedebug=true -Dawtdebug.trace=true -Dawtdebug.on=true
-Dawtdebug.ctrace=true -cp ~/Java HelloSwing

The various debug properties will lead to the following output:

openjdk version "13-internal" 2019-09-17
OpenJDK Runtime Environment (slowdebug build 13-internal+0-adhoc.xxx.jdk-jdk)
OpenJDK 64-Bit Server VM (slowdebug build
13-internal+0-adhoc.xxx.jdk-jdk, mixed mode)
Xinerama extension is available
calling XineramaQueryScreens func
Enabling Xinerama support
 num screens = 2
allocating 2 screens

The Swing frame will appear on one of the Xinerama screens and can be
move with the mouse between the two available screens.

If I hear no further objections, I plan to push this by the end of the week.

Thank you and best regards,
Volker



On Mon, Mar 18, 2019 at 8:59 PM Thomas St?fe <thomas.stuefe at gmail.com> wrote:
>
> Sorry, not awt/2d group, but to me it looks fine too. Only nit: the error printout at 495 I would put right after the associated dlsym at 456. You want to make sure dlerror() is not stale at the point where you call it, since it would return NULL.
>
> Cheers, Thomas
>
>
>
> On Mon, Mar 18, 2019 at 3:17 PM Volker Simonis <volker.simonis at gmail.com> wrote:
>>
>> Ping...
>>
>> Can I please also get a review from the awt/2d group?
>>
>> Thanks,
>> Volker
>>
>> On Wed, Mar 13, 2019 at 11:09 AM Volker Simonis
>> <volker.simonis at gmail.com> wrote:
>> >
>> > Hi,
>> >
>> > can I please have a review for the following change which fixes
>> > Xinerama and Xrender support on AIX:
>> >
>> > http://cr.openjdk.java.net/~simonis/webrevs/2019/8220528/
>> > https://bugs.openjdk.java.net/browse/JDK-8220528
>> >
>> > The change basically fixes the way how the corresponding libraries
>> > (libXext and libXrender) get loaded on AIX and does some cleanups with
>> > regards to the various platform macros. I've also added some debug
>> > tracing to the Xrender initialization code similar to the Xinerama
>> > initialization.
>> >
>> > Thank you and best regards,
>> > Volker

From thomas.stuefe at gmail.com  Mon Mar 25 18:50:04 2019
From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=)
Date: Mon, 25 Mar 2019 19:50:04 +0100
Subject: <AWT Dev> [OpenJDK 2D-Dev] RFR: 8220528: [AIX] Fix basic
 Xinerama and Xrender functionality
In-Reply-To: <CA+3eh12-jEJywLruafE6bn79bT4CkyXJz7iHTWqiwaaywybHXQ@mail.gmail.com>
References: <CA+3eh130xEVyDdr=r+kjY9A1c8pqKkCSw4gb+3OpNFBLMts0UQ@mail.gmail.com>
 <CA+3eh1000n2+dtBf_+A7OFvTPceL86ASMBHfUn_NdDswPRbmYQ@mail.gmail.com>
 <CAA-vtUwXF7QaEMm+i=8U5zH0y6MkOFPvKRtnQsm+x2+Z_uyPPA@mail.gmail.com>
 <CA+3eh12-jEJywLruafE6bn79bT4CkyXJz7iHTWqiwaaywybHXQ@mail.gmail.com>
Message-ID: <CAA-vtUx8aEocjwzG8qTcqpRn6OAx3aJ0jS6TL_QRtL40nbErow@mail.gmail.com>

On Mon 25. Mar 2019 at 19:42, Volker Simonis <volker.simonis at gmail.com>
wrote:

> Hi Thomas, Christoph,
>
> thanks for looking into my fix. I hope I've addressed all your
> concerns with my new webrev:
>
> http://cr.openjdk.java.net/~simonis/webrevs/2019/8220528.v4
>
> By the way, I've tested the new implementation by simulating a
> multi-screen environment on my Linux box with Xephyr:
>
> $ Xephyr +xinerama -screen 1024x768 -screen 1024x768+1024+0 -ac -listen
> tcp :1
>
> And started a Swing application from AIX where I've redirected the
> DISPLAY to myhost:1:
>
> $ DISPLAY=myhost:1 ./images/jdk/bin/java -showversion
> -Dsun.awt.nativedebug=true -Dawtdebug.trace=true -Dawtdebug.on=true
> -Dawtdebug.ctrace=true -cp ~/Java HelloSwing
>
> The various debug properties will lead to the following output:
>
> openjdk version "13-internal" 2019-09-17
> OpenJDK Runtime Environment (slowdebug build
> 13-internal+0-adhoc.xxx.jdk-jdk)
> OpenJDK 64-Bit Server VM (slowdebug build
> 13-internal+0-adhoc.xxx.jdk-jdk, mixed mode)
> Xinerama extension is available
> calling XineramaQueryScreens func
> Enabling Xinerama support
>  num screens = 2
> allocating 2 screens
>
> The Swing frame will appear on one of the Xinerama screens and can be
> move with the mouse between the two available screens.
>
> If I hear no further objections, I plan to push this by the end of the
> week.
>

All good now. Thank you.

Strange that this error was not detected before, what with the masses of
people running swing apps on AIX.

Cheers, thomas



> Thank you and best regards,
> Volker
>
>
>
> On Mon, Mar 18, 2019 at 8:59 PM Thomas St?fe <thomas.stuefe at gmail.com>
> wrote:
> >
> > Sorry, not awt/2d group, but to me it looks fine too. Only nit: the
> error printout at 495 I would put right after the associated dlsym at 456.
> You want to make sure dlerror() is not stale at the point where you call
> it, since it would return NULL.
> >
> > Cheers, Thomas
> >
> >
> >
> > On Mon, Mar 18, 2019 at 3:17 PM Volker Simonis <volker.simonis at gmail.com>
> wrote:
> >>
> >> Ping...
> >>
> >> Can I please also get a review from the awt/2d group?
> >>
> >> Thanks,
> >> Volker
> >>
> >> On Wed, Mar 13, 2019 at 11:09 AM Volker Simonis
> >> <volker.simonis at gmail.com> wrote:
> >> >
> >> > Hi,
> >> >
> >> > can I please have a review for the following change which fixes
> >> > Xinerama and Xrender support on AIX:
> >> >
> >> > http://cr.openjdk.java.net/~simonis/webrevs/2019/8220528/
> >> > https://bugs.openjdk.java.net/browse/JDK-8220528
> >> >
> >> > The change basically fixes the way how the corresponding libraries
> >> > (libXext and libXrender) get loaded on AIX and does some cleanups with
> >> > regards to the various platform macros. I've also added some debug
> >> > tracing to the Xrender initialization code similar to the Xinerama
> >> > initialization.
> >> >
> >> > Thank you and best regards,
> >> > Volker
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/awt-dev/attachments/20190325/ab4174d2/attachment-0001.html>

From volker.simonis at gmail.com  Tue Mar 26 08:56:45 2019
From: volker.simonis at gmail.com (Volker Simonis)
Date: Tue, 26 Mar 2019 09:56:45 +0100
Subject: <AWT Dev> [OpenJDK 2D-Dev] RFR: 8220528: [AIX] Fix basic
 Xinerama and Xrender functionality
In-Reply-To: <CAA-vtUx8aEocjwzG8qTcqpRn6OAx3aJ0jS6TL_QRtL40nbErow@mail.gmail.com>
References: <CA+3eh130xEVyDdr=r+kjY9A1c8pqKkCSw4gb+3OpNFBLMts0UQ@mail.gmail.com>
 <CA+3eh1000n2+dtBf_+A7OFvTPceL86ASMBHfUn_NdDswPRbmYQ@mail.gmail.com>
 <CAA-vtUwXF7QaEMm+i=8U5zH0y6MkOFPvKRtnQsm+x2+Z_uyPPA@mail.gmail.com>
 <CA+3eh12-jEJywLruafE6bn79bT4CkyXJz7iHTWqiwaaywybHXQ@mail.gmail.com>
 <CAA-vtUx8aEocjwzG8qTcqpRn6OAx3aJ0jS6TL_QRtL40nbErow@mail.gmail.com>
Message-ID: <CA+3eh103zZZ13P4NijNK=N-32eZS7G6peq8XAuim6V50k0evLQ@mail.gmail.com>

On Mon, Mar 25, 2019 at 7:50 PM Thomas St?fe <thomas.stuefe at gmail.com> wrote:
>
>
>
> On Mon 25. Mar 2019 at 19:42, Volker Simonis <volker.simonis at gmail.com> wrote:
>>
>> Hi Thomas, Christoph,
>>
>> thanks for looking into my fix. I hope I've addressed all your
>> concerns with my new webrev:
>>
>> http://cr.openjdk.java.net/~simonis/webrevs/2019/8220528.v4
>>
>> By the way, I've tested the new implementation by simulating a
>> multi-screen environment on my Linux box with Xephyr:
>>
>> $ Xephyr +xinerama -screen 1024x768 -screen 1024x768+1024+0 -ac -listen tcp :1
>>
>> And started a Swing application from AIX where I've redirected the
>> DISPLAY to myhost:1:
>>
>> $ DISPLAY=myhost:1 ./images/jdk/bin/java -showversion
>> -Dsun.awt.nativedebug=true -Dawtdebug.trace=true -Dawtdebug.on=true
>> -Dawtdebug.ctrace=true -cp ~/Java HelloSwing
>>
>> The various debug properties will lead to the following output:
>>
>> openjdk version "13-internal" 2019-09-17
>> OpenJDK Runtime Environment (slowdebug build 13-internal+0-adhoc.xxx.jdk-jdk)
>> OpenJDK 64-Bit Server VM (slowdebug build
>> 13-internal+0-adhoc.xxx.jdk-jdk, mixed mode)
>> Xinerama extension is available
>> calling XineramaQueryScreens func
>> Enabling Xinerama support
>>  num screens = 2
>> allocating 2 screens
>>
>> The Swing frame will appear on one of the Xinerama screens and can be
>> move with the mouse between the two available screens.
>>
>> If I hear no further objections, I plan to push this by the end of the week.
>
>
> All good now. Thank you.
>

Thanks.

> Strange that this error was not detected before, what with the masses of people running swing apps on AIX.
>

It was not really an error. Basic Swing/AWT worked (we actually passed
the TCK). What did not work was some advanced
transparency/translucency support (due to failing Xrender) and
multiscreen support (due to failing Xinerama).

> Cheers, thomas
>
>
>>
>> Thank you and best regards,
>> Volker
>>
>>
>>
>> On Mon, Mar 18, 2019 at 8:59 PM Thomas St?fe <thomas.stuefe at gmail.com> wrote:
>> >
>> > Sorry, not awt/2d group, but to me it looks fine too. Only nit: the error printout at 495 I would put right after the associated dlsym at 456. You want to make sure dlerror() is not stale at the point where you call it, since it would return NULL.
>> >
>> > Cheers, Thomas
>> >
>> >
>> >
>> > On Mon, Mar 18, 2019 at 3:17 PM Volker Simonis <volker.simonis at gmail.com> wrote:
>> >>
>> >> Ping...
>> >>
>> >> Can I please also get a review from the awt/2d group?
>> >>
>> >> Thanks,
>> >> Volker
>> >>
>> >> On Wed, Mar 13, 2019 at 11:09 AM Volker Simonis
>> >> <volker.simonis at gmail.com> wrote:
>> >> >
>> >> > Hi,
>> >> >
>> >> > can I please have a review for the following change which fixes
>> >> > Xinerama and Xrender support on AIX:
>> >> >
>> >> > http://cr.openjdk.java.net/~simonis/webrevs/2019/8220528/
>> >> > https://bugs.openjdk.java.net/browse/JDK-8220528
>> >> >
>> >> > The change basically fixes the way how the corresponding libraries
>> >> > (libXext and libXrender) get loaded on AIX and does some cleanups with
>> >> > regards to the various platform macros. I've also added some debug
>> >> > tracing to the Xrender initialization code similar to the Xinerama
>> >> > initialization.
>> >> >
>> >> > Thank you and best regards,
>> >> > Volker

From christoph.langer at sap.com  Tue Mar 26 09:17:19 2019
From: christoph.langer at sap.com (Langer, Christoph)
Date: Tue, 26 Mar 2019 09:17:19 +0000
Subject: <AWT Dev> 8221405: Fix Windows 32bit awt build
In-Reply-To: <CAA-vtUwHAHf4fVE0LvW=_qnQgR5bG2Wc=twsafCRptL3L4zGdg@mail.gmail.com>
References: <CAA-vtUwHAHf4fVE0LvW=_qnQgR5bG2Wc=twsafCRptL3L4zGdg@mail.gmail.com>
Message-ID: <HE1PR0201MB22662B1B871D88CF5722A5498A5F0@HE1PR0201MB2266.eurprd02.prod.outlook.com>

Hi Thomas,

this looks good to me, too.

Best regards
Christoph

From: awt-dev <awt-dev-bounces at openjdk.java.net> On Behalf Of Thomas St?fe
Sent: Montag, 25. M?rz 2019 14:09
To: AWT-DEV Mailing List <awt-dev at openjdk.java.net>
Subject: <AWT Dev> 8221405: Fix Windows 32bit awt build

Hi all,

Issue: https://bugs.openjdk.java.net/browse/JDK-8221405
cr: http://cr.openjdk.java.net/~stuefe/webrevs/8221405-windows32-awt-buildfixes/webrev.00/webrev/

On 32bit windows, awt build did bitrot. Dtrace print callbacks need to be declared with __stdcall. No other platform cares.

Thanks, Thomas
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/awt-dev/attachments/20190326/1524174c/attachment.html>

From thomas.stuefe at gmail.com  Tue Mar 26 10:21:24 2019
From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=)
Date: Tue, 26 Mar 2019 11:21:24 +0100
Subject: <AWT Dev> 8221405: Fix Windows 32bit awt build
In-Reply-To: <HE1PR0201MB22662B1B871D88CF5722A5498A5F0@HE1PR0201MB2266.eurprd02.prod.outlook.com>
References: <CAA-vtUwHAHf4fVE0LvW=_qnQgR5bG2Wc=twsafCRptL3L4zGdg@mail.gmail.com>
 <HE1PR0201MB22662B1B871D88CF5722A5498A5F0@HE1PR0201MB2266.eurprd02.prod.outlook.com>
Message-ID: <CAA-vtUxsG+QvRQ0xE6m7oTSJEqwifTA-cbY6B8uL21dw1P58Xw@mail.gmail.com>

thanks!

On Tue, Mar 26, 2019 at 10:17 AM Langer, Christoph <christoph.langer at sap.com>
wrote:

> Hi Thomas,
>
>
>
> this looks good to me, too.
>
>
>
> Best regards
>
> Christoph
>
>
>
> *From:* awt-dev <awt-dev-bounces at openjdk.java.net> *On Behalf Of *Thomas
> St?fe
> *Sent:* Montag, 25. M?rz 2019 14:09
> *To:* AWT-DEV Mailing List <awt-dev at openjdk.java.net>
> *Subject:* <AWT Dev> 8221405: Fix Windows 32bit awt build
>
>
>
> Hi all,
>
>
>
> Issue: https://bugs.openjdk.java.net/browse/JDK-8221405
>
> cr:
> http://cr.openjdk.java.net/~stuefe/webrevs/8221405-windows32-awt-buildfixes/webrev.00/webrev/
>
>
>
> On 32bit windows, awt build did bitrot. Dtrace print callbacks need to be
> declared with __stdcall. No other platform cares.
>
>
>
> Thanks, Thomas
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/awt-dev/attachments/20190326/19f276fe/attachment.html>

From krishna.addepalli at oracle.com  Tue Mar 26 10:56:46 2019
From: krishna.addepalli at oracle.com (Krishna Addepalli)
Date: Tue, 26 Mar 2019 16:26:46 +0530
Subject: <AWT Dev> [13] JDK-8218917: KeyEvent.getModifiers() returns
 inconsistent values for ALT keys
In-Reply-To: <CANTFZ2hEqJYOcyFQVsfsuv=i=yM+tTwJtVmn3ekkVQ+NDr7=_w@mail.gmail.com>
References: <990B3CDA-E3A0-4051-8771-1AD486094974@oracle.com>
 <CANTFZ2i30ao6fVuVxQseEzF38vBnLUfw3PPadYyKrUCrgfKo9g@mail.gmail.com>
 <6B001F8A-858F-4279-8F42-366F22D49B52@oracle.com>
 <CANTFZ2iUHFNSm9st3d3BLYvERa5OmpOzU+T5e1aoLq5C7YkMfQ@mail.gmail.com>
 <5C8673F6.8060306@oracle.com>
 <6d97202a-ad60-c768-4a31-66ca02f16f70@oracle.com>
 <5C86FF3C.7030700@oracle.com>
 <b842a817-1c61-7d23-a144-41bfc87013a3@oracle.com>
 <CANTFZ2ikTVEP1OcrE415KhRbKr7Bv1XND-UW5tVPOW5+Ube7Jw@mail.gmail.com>
 <7dcf0e9b-cfc8-b985-f60c-10f7fe307825@oracle.com>
 <CANTFZ2h2gc8abosQBJrSNA2tF6cwDQacjpfKp_y1znwkkAU+8w@mail.gmail.com>
 <0c65a2e9-d5b3-eaf0-44eb-2b969de64dac@oracle.com>
 <CANTFZ2gY=h5AyLTu8KPkwyL1_4TvY6jLf9_aqTGBwa0kf5mRdQ@mail.gmail.com>
 <5956470F-019E-40E7-AE6D-9BB9F4E95F19@oracle.com>
 <CANTFZ2jUNuwSfEaRVMSCjVhJ50i9aWYi5V_fZE5aRvVConz3Sw@mail.gmail.com>
 <b8901169-5a6e-cd3d-56d7-d3d2578ff29a@oracle.com>
 <CANTFZ2hUFGyAVuYPxH8ubvpbWypHD4Q2G+oRZKS+Gw=j-H3sdw@mail.gmail.com>
 <6d9a95d4-4ceb-c596-ce8f-6dccbd21dd6e@oracle.com>
 <CANTFZ2h7UkaBVqXje7XQ3f-Jrk2Yc30X-T0zXjFNadZ6BCyVbQ@mail.gmail.com>
 <3DDEC8F7-44EE-4C5F-8B69-C411BDD9FA60@oracle.com>
 <CANTFZ2hEqJYOcyFQVsfsuv=i=yM+tTwJtVmn3ekkVQ+NDr7=_w@mail.gmail.com>
Message-ID: <2791772D-6F0E-45B1-8D8F-3C01F87728F8@oracle.com>

Hi Sergey Malenkov,

My fix exactly solves the problem of right alt hijacking the state and always sending a ALTGR key even if left ALT only was pressed.

What I meant by same behaviour is that pressing the left ALT and then pressing the ALTGR key(or vice versa) will deliver the event with KeyPressed 0.
Even my proposed fix restores this behaviour. Whether this is a correct behaviour is a different matter.
I still maintain that, we should fix the immediate problem at hand (since that is minimal code changes), and then continue the discussion of how to support the ALTGR behaviour under a different bug(it could as well become an enhancement).

Thanks,
Krishna

> On 21-Mar-2019, at 4:04 PM, Sergey Malenkov <malenkov at gmail.com> wrote:
> 
> Hi Krishna,
> 
>> But, currently, with my fix, the code will behave exactly as in Java 1.8.
> 
> Nope, it still sends VK_ALT_GRAPH pressed event for the right Alt.
> 
> http://bugs.openjdk.java.net/browse/JDK-8151136
> According to the issue above AltGr support was backported to 9.
> 
> 
> On Wed, Mar 20, 2019 at 2:18 PM Krishna Addepalli
> <krishna.addepalli at oracle.com> wrote:
>> 
>> Hi Sergey Malenkov,
>> 
>> We can debate on how to treat the ALTGR_KEY, and can choose to include the behaviour as a system flag.
>> But, currently, with my fix, the code will behave exactly as in Java 1.8. Even there, when I pressed ALTGR key, after holding ALT key, I observed a KeyEvent 0 being sent.
>> 
>> I would suggest to re-look at my fix which fixes the current problem at hand, and perhaps we can move this discussion under a new bug.
>> 
>> Thanks,
>> Krishna
>> 
>> On 18-Mar-2019, at 8:02 PM, Sergey Malenkov <malenkov at gmail.com> wrote:
>> 
>> Hi Sergey,
>> 
>> ALT_GRAPH_DOWN_MASK is not the only mask missing in JavaDoc. What is
>> about META_DOWN_MASK? What if the developer, who does not care about
>> ALT_GRAPH, forget about META too? Guess how your example will work on
>> Mac. What is about the WORA slogan?
>> 
>> I believe that the example in the javadoc is not entirely correct.
>> This is just a very simple example, related to the English locale on
>> Windows (and possibly on Linux). It should not be used in
>> multi-platform code.
>> 
>> 
>> 
>> On Sun, Mar 17, 2019 at 1:26 AM Sergey Bylokhov
>> <Sergey.Bylokhov at oracle.com> wrote:
>> 
>> 
>> On 16/03/2019 03:58, Sergey Malenkov wrote:
>> 
>> Your example is synthetic and shows a problem in the one specific
>> case. I think if you introduce new mask, you have to use it in your
>> example too. If you add ALT_GRAPH_DOWN_MASK to 'offmask' your example
>> will not work (that's how processed all shortcuts in Swing and IDEA).
>> If you add it to 'onmask' the KeyEvent(new Button(), 0, 0,
>> ALT_GRAPH_DOWN_MASK, 0) will not work.
>> 
>> 
>> Your example is good as well, but it shows the opposite, if
>> ALT_GRAPH_DOWN_MASK was used as "onmask" or as "offmask" then it means
>> that this example tries to take care about altGr and it only
>> properly works after the fix. And if the code is unaware about the altGr
>> flag as in previous example it will be ignored.
>> 
>> Am I right that to support your specific case you have to find and fix
>> all Alt-based shortcuts in Swing, we should fix all Alt-based
>> shortcuts in all keymaps in our IDEs and we should notify all our
>> users that they have to fix all Alt-based shortcuts in their custom
>> keymaps? The brilliant example of backward compatibility!
>> 
>> 
>> I do not remember all changes which were integrated since initially it was done
>> ~4 years ago. But Swing was updated by some changes after that, for example:
>> https://bugs.openjdk.java.net/browse/JDK-8194873
>> 
>> 
>> So if the client will follow the spec below it should work as before, isn't it?:
>> https://docs.oracle.com/en/java/javase/11/docs/api/java.desktop/java/awt/event/InputEvent.html#getModifiersEx()
>> 
>> 
>> If a developer use this method as described his code will be broken
>> too, because good and attentive developer definitely added
>> ALT_GRAPH_DOWN_MASK to 'offmask'.
>> 
>> 
>> If the user wants to ignore all combinations with "Alternate Character Key"
>> then, as you pointed in the start of this thread, he should ignore both
>> "alt" since on macOS both alt keys are "Alternate Character Key".
>> 
>> 
>> On Sat, Mar 16, 2019 at 1:27 AM Sergey Bylokhov
>> <Sergey.Bylokhov at oracle.com> wrote:
>> 
>> 
>> On 15/03/2019 05:54, Sergey Malenkov wrote:
>> 
>> We have a major issue about unexpected AltGr in the keyboard layout
>> that should not have AltGr at all:
>> https://urldefense.proofpoint.com/v2/url?u=http-3A__youtrack.jetbrains.com_issue_IDEA-2D206348&d=DwIFaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=QF7AertWDY_M4hfHg_4S-iyX-aP0wtLYwZFgs0zfX_k&m=j-gQEy4UDmzd3Sa5zjEYskUw4CoYUZ9gDurLkGu1YOo&s=HcCKCq8FPyOoJEvT4qk59DJqCAiRB-BvECy_VCAdpqI&e=
>> Why you decided to support AltGr for every keyboard layout? It really
>> breaks backward compatibility!
>> 
>> 
>> Even in your bug report the people complain that altGr key does not work, and
>> the only problem here is that it does not assigned by default.
>> But on the other side it is possible to set separate shortcuts
>> to the "Alt + Alt Graph + Enter"and "Alt + Enter":
>> 
>> I think the main client is Swing and pressed AltGr that looks like
>> 'Alt+AltGr+' breaks all Alt-based shortcuts defined in
>> javax.swing.plaf.basic.BasicLookAndFeel#initComponentDefaults and
>> other places. Now, if you press "alt LEFT", the "moveColumnLeft"
>> action is performed only for the left Alt. And this also breaks a
>> backward compatibility.
>> 
>> 
>> The term "all" is not so critical, there are only few such shortcuts, and it is
>> a good thing that potentially we can set different shortcuts for each.
>> This is a bug that these places were not updated, it is easy to fix since this
>> is not exposed via public API.
>> But we will get the same result if we will use the AltGr mask only.
>> 
>> It is not backward compatible to use AltGr instead of right Alt in
>> both cases. Instead of 'Alt+key' you will get 'AltGr+key' or
>> 'Alt+AltGr+key', which are not bound to any action.
>> 
>> 
>> It is compatible to the specification of InputEvent.getModifiersEx():
>> KeyEvent event = new KeyEvent(new Button(), 0, 0,
>>                               ALT_DOWN_MASK | ALT_GRAPH_DOWN_MASK, 0);
>>   int onmask =  ALT_DOWN_MASK;
>>   int offmask = CTRL_DOWN_MASK|SHIFT_DOWN_MASK;
>>   if ((event.getModifiersEx() & (onmask | offmask)) == onmask) {
>>     ...
>>   }
>> 
>> The code above works before and after the change for altGr.
>> But it will stop working if we will use altGr only, and it will be hard to argue
>> why the ALT flag is not set while alt key is pressed(since on some keyboards this key is
>> marked as alt and on some other altGr).
>> 
>> And as specially noted in the method above the code should not assume which
>> flags(and how many) were set by the actions, if such assumptions exists in
>> Swing itself they should be fixed as well.
>> 
>> 
>> On Fri, Mar 15, 2019 at 9:27 AM Krishna Addepalli
>> <krishna.addepalli at oracle.com> wrote:
>> 
>> 
>> Hi Sergey Malenkov,
>> 
>> 'Alt+AltGr+Right' does nothing, because we do not assign this shortcut yet
>> 
>> In my personal experience, I did not find any instance, wherein a shortcut had left and right alt in it.
>> Although it is not impossible, it seems weird to define such shortcuts.
>> It would be helpful if you could point to some resources, wherein defining such shortcuts is acceptable.
>> 
>> Thanks,
>> Krishna
>> 
>> On 14-Mar-2019, at 4:03 PM, Sergey Malenkov <malenkov at gmail.com> wrote:
>> 
>> I strongly don't like two masks for one key. If you press VK_ALT,
>> ALT_DOWN_MASK should be set. If you press VK_SHIFT then,
>> SHIFT_DOWN_MASK should be added to indicate that both keys are
>> pressed. And if you press VK_ALT_GRAPH, only ALT_GRAPH_DOWN_MASK
>> should be added. Otherwise, you can't distinguish the following key
>> strokes: 'AltGr+Right' and 'Alt+AltGr+Right'. But these keystrokes are
>> different and should invoke different actions. For example,
>> 'Alt+Right' moves cursor to the next word
>> 'Alt+Shift+Right' moves cursor to the next word AND adds all skipped
>> characters to selection
>> 'Alt+AltGr+Right' does nothing, because we do not assign this shortcut yet
>> 
>> On Thu, Mar 14, 2019 at 12:09 AM Sergey Bylokhov
>> <Sergey.Bylokhov at oracle.com> wrote:
>> 
>> 
>> On 13/03/2019 03:59, Sergey Malenkov wrote:
>> 
>> I missed the "for ALT keys" in the bug title and thought that
>> "KeyEvent.getModifiers() returns inconsistent values" was about
>> incompatible behaviour on different platforms. In fact, JDK-8218917
>> should be renamed to something like ?The right Alt key on Mac should
>> behave as Alt and must not break the left Alt key processing?.
>> 
>> 
>> But the "right Alt" should behave like a "left alt" already, it should use both flags:
>> the common alt(ALT_DOWN_MASK) and the altGr(ALT_GRAPH_DOWN_MASK).
>> 
>> So if the client will follow the spec below it should work as before, isn't it?:
>> https://docs.oracle.com/en/java/javase/11/docs/api/java.desktop/java/awt/event/InputEvent.html#getModifiersEx()
>> 
>> On Wed, Mar 13, 2019 at 6:57 AM Sergey Bylokhov
>> <Sergey.Bylokhov at oracle.com> wrote:
>> 
>> 
>> On 12/03/2019 12:28, Sergey Malenkov wrote:
>> 
>> Hi Sergey,
>> 
>> 1. macOS uses a regular Alt key as "Alternate Character Key". This is
>> the reason why JDK Toolkit defines Ctrl+Alt to select a mnemonic,
>> instead of simple Alt. See
>> https://urldefense.proofpoint.com/v2/url?u=https-3A__sites.google.com_site_malenkov_java_141229&d=DwIFaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=QF7AertWDY_M4hfHg_4S-iyX-aP0wtLYwZFgs0zfX_k&m=j-gQEy4UDmzd3Sa5zjEYskUw4CoYUZ9gDurLkGu1YOo&s=Y6PcJ4DGp2cSnTLEvtsIdt55_u0F8VqL5LSA7vBPbkw&e=
>> 
>> 
>> Right, but introducing this flag for the "left alt" could cause even more
>> issues, so this flag is set only for the right.
>> 
>> 3. Regression was caused by adding AltGr to key processing on Mac. But
>> I found more issues with inconsistent key processing on different
>> platforms. See https://urldefense.proofpoint.com/v2/url?u=http-3A__sites.google.com_site_malenkov_java_190312&d=DwIFaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=QF7AertWDY_M4hfHg_4S-iyX-aP0wtLYwZFgs0zfX_k&m=j-gQEy4UDmzd3Sa5zjEYskUw4CoYUZ9gDurLkGu1YOo&s=Y7GZdeTQvRyIBxAsCDtaB8PZo9_GRVYIZZvn2VfCzJc&e=
>> 
>> 
>> Not sure that CAPS_LOCK is related.
>> 
>> 
>> 
>> On Tue, Mar 12, 2019 at 4:17 AM Sergey Bylokhov
>> <Sergey.Bylokhov at oracle.com> wrote:
>> 
>> 
>> On 11/03/2019 17:37, Philip Race wrote:
>> 
>> The debate is about AltGraph which an ancient MS-DOSism for
>> asking for an ALTernate GRAPHics bitmap font - all pre-dates windows
>> and I am sure has never been applicable to any MacOS.
>> 
>> 
>> It also about the "right alt" which is also know as "AltGraph". I guess currently
>> it is implemented as "right alt" on Linux/macOS/windows.
>> 
>> BTW on linux it is also named as "Alternative Characters Key":
>> https://urldefense.proofpoint.com/v2/url?u=https-3A__help.ubuntu.com_community_ComposeKey&d=DwIFaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=QF7AertWDY_M4hfHg_4S-iyX-aP0wtLYwZFgs0zfX_k&m=j-gQEy4UDmzd3Sa5zjEYskUw4CoYUZ9gDurLkGu1YOo&s=DvJtvBcerkulT3S417Vu6hQyXy7e0bI1bX9fInefV-A&e=
>> 
>> So someone needs to properly explain why we would claim a Mac keyboard
>> is OK to generate a keycode it doesn't have and cause a slew of regressions
>> in the process ...>
>> If Mac doesn't distinguish these two, we should generate the same keycode for both.
>> 
>> 
>> The macOS supports "right alt", otherwise it would not be possible to implement it in java:
>> https://urldefense.proofpoint.com/v2/url?u=https-3A__developer.apple.com_library_archive_technotes_tn2450_-5Findex.html&d=DwIFaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=QF7AertWDY_M4hfHg_4S-iyX-aP0wtLYwZFgs0zfX_k&m=j-gQEy4UDmzd3Sa5zjEYskUw4CoYUZ9gDurLkGu1YOo&s=hD5wMxSuL3iN_tqTn0Cd5ULhp_bGzQl3fFnQQdNXNuU&e=
>> 
>> 
>> One could suppose there is a difference else why two keys, but what is the right
>> thing to do here  that fixes all the problems. What exactly WAS the problem
>> with what was there in the first place ? And if changing it is correct why is it
>> causing regressions ?
>> 
>> 
>> Regressions were caused by the bugs in the fix implementation, or am I missed something?
>> 
>> 
>> 
>> -phil.
>> 
>> 
>> 
>> On 3/12/19, 5:34 AM, Sergey Bylokhov wrote:
>> 
>> Hi, Phil.
>> On 11/03/2019 07:43, Philip Race wrote:
>> 
>> The reasoning that AltGraph might be useful to someone is a bit weak
>> and I don't think I'd want to support it via system property or build options.
>> 
>> If its not a platform keyboard key, why do we need it ?
>> 
>> 
>> The "AltGraph" key is also commonly referred to as "Right Alt", and
>> it has been implemented on all platforms as a "Right Alt", it is convenient to
>> distinguish the left/right alts.
>> 
>> 
>> 
>> --
>> Best regards, Sergey.
>> 
>> 
>> 
>> 
>> 
>> 
>> --
>> Best regards, Sergey.
>> 
>> 
>> 
>> 
>> 
>> 
>> --
>> Best regards, Sergey.
>> 
>> 
>> 
>> 
>> --
>> Best regards,
>> Sergey A. Malenkov
>> 
>> 
>> 
>> 
>> 
>> 
>> --
>> Best regards, Sergey.
>> 
>> 
>> 
>> 
>> 
>> 
>> --
>> Best regards, Sergey.
>> 
>> 
>> 
>> 
>> --
>> Best regards,
>> Sergey A. Malenkov
>> 
>> 
> 
> 
> -- 
> Best regards,
> Sergey A. Malenkov


From alexey.ivanov at oracle.com  Tue Mar 26 13:36:36 2019
From: alexey.ivanov at oracle.com (Alexey Ivanov)
Date: Tue, 26 Mar 2019 13:36:36 +0000
Subject: <AWT Dev> 8221405: Fix Windows 32bit awt build
In-Reply-To: <CAA-vtUwHAHf4fVE0LvW=_qnQgR5bG2Wc=twsafCRptL3L4zGdg@mail.gmail.com>
References: <CAA-vtUwHAHf4fVE0LvW=_qnQgR5bG2Wc=twsafCRptL3L4zGdg@mail.gmail.com>
Message-ID: <336e01bb-1e0d-4583-2a78-cd2d980aed05@oracle.com>

Hi Thomas,

Looks good, I'm not a reviewer though.
Could I also ask you to push this changeset to jdk/client [1] instead of 
jdk/jdk?

A small question: two prototypes are changed in debug_trace.h but only 
one is updated in debug_trace.c. Is it because the functions matching 
the second prototype have already been updated with JNICALL?

Regards,
Alexey

[1] http://hg.openjdk.java.net/jdk/client/

On 25/03/2019 13:09, Thomas St?fe wrote:
> Hi all,
>
> Issue: https://bugs.openjdk.java.net/browse/JDK-8221405
> cr: 
> http://cr.openjdk.java.net/~stuefe/webrevs/8221405-windows32-awt-buildfixes/webrev.00/webrev/
>
> On 32bit windows, awt build did bitrot. Dtrace print callbacks need to 
> be declared with __stdcall. No other platform cares.
>
> Thanks, Thomas


From alexey.ivanov at oracle.com  Tue Mar 26 14:00:14 2019
From: alexey.ivanov at oracle.com (Alexey Ivanov)
Date: Tue, 26 Mar 2019 14:00:14 +0000
Subject: <AWT Dev> RFR(xs): 8221375: Windows 32bit build (VS2017) broken
In-Reply-To: <CAA-vtUzzXRkRiEsdhWUPWjFAstmoGLYzbPkkau-LLM5JiO7dTA@mail.gmail.com>
References: <CAA-vtUwuJ0MFWbgeT+Ch2qSZeZTFq-uYB-Fd3r3b3Ht+67S1wQ@mail.gmail.com>
 <44c67029-57fc-155c-39e1-bd810e70fe32@oracle.com>
 <CAA-vtUyhVLJm-TjJk-Rt4ibk7cYdM2k5ONUszt3ms39SjcoTHA@mail.gmail.com>
 <46ea4603-9a4c-6330-ad47-30fe4137fc0b@oracle.com>
 <CAA-vtUwA+cUxS3XHvNkwXP3hMPiW=WWhn5RFWsTK9qQA_NUHug@mail.gmail.com>
 <CAA-vtUzbk8aCq8XV7pyDj3z5+dh9bjt7HtAm1MJWsm3o2bv0Yg@mail.gmail.com>
 <8200636c-f2d8-b9b8-824b-a6e25445539b@oracle.com>
 <CAA-vtUzzXRkRiEsdhWUPWjFAstmoGLYzbPkkau-LLM5JiO7dTA@mail.gmail.com>
Message-ID: <c5fa1232-6c96-a486-69d9-6272bf317adf@oracle.com>

Sure!

That way the changes are easier to review, and each group focuses on 
their area.

On 25/03/2019 14:58, Thomas St?fe wrote:
> Hi Alexey,
>
> thanks. I posted an updated fix for this on awt-net (8221405) since 
> David asked me to split the patch up. Could you please review it?
>
> Thanks! ..Thomas
-- 
Regards,
Alexey

From thomas.stuefe at gmail.com  Tue Mar 26 14:41:06 2019
From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=)
Date: Tue, 26 Mar 2019 15:41:06 +0100
Subject: <AWT Dev> 8221405: Fix Windows 32bit awt build
In-Reply-To: <336e01bb-1e0d-4583-2a78-cd2d980aed05@oracle.com>
References: <CAA-vtUwHAHf4fVE0LvW=_qnQgR5bG2Wc=twsafCRptL3L4zGdg@mail.gmail.com>
 <336e01bb-1e0d-4583-2a78-cd2d980aed05@oracle.com>
Message-ID: <CAA-vtUywsC3rM3nc5c45B+DCey0_ajvf+TjN8ZMpYj925kxuSw@mail.gmail.com>

Hi Alexey,



On Tue, Mar 26, 2019 at 2:36 PM Alexey Ivanov <alexey.ivanov at oracle.com>
wrote:

> Hi Thomas,
>
> Looks good, I'm not a reviewer though.
> Could I also ask you to push this changeset to jdk/client [1] instead of
> jdk/jdk?
>
> A small question: two prototypes are changed in debug_trace.h but only
> one is updated in debug_trace.c. Is it because the functions matching
> the second prototype have already been updated with JNICALL?
>
>
Not really sure I understand the question. There is no real 1:1
relationship between my change in .h and .c:

DTRACE_PRINTxx macros call _DTrace_Template() which expands to
DTrace_PrintFunction(). First argument is pointer to DTrace_VPrint(), which
is a function decorated with JNICALL. Hence the build error - the type of
the first argument of DTrace_PrintFunction is DTRACE_PRINT_CALLBACK, which
is a fkt pointer *without* JNICALL.

So one way to fix this was to correct the DTRACE_PRINT_CALLBACK type to be
a fkt pointer pointing to a JNICALL decorated function.

That means that I also needed to fix all functions whose pointers are being
passed around as DTRACE_PRINT_CALLBACK. But there only was one I saw,
DTrace_PrintStdErr().

I'll push to jdk/client. Will that be transported to jdk/jdk automatically?

Cheers, Thomas





> Regards,
> Alexey
>
> [1] http://hg.openjdk.java.net/jdk/client/
>
> On 25/03/2019 13:09, Thomas St?fe wrote:
> > Hi all,
> >
> > Issue: https://bugs.openjdk.java.net/browse/JDK-8221405
> > cr:
> >
> http://cr.openjdk.java.net/~stuefe/webrevs/8221405-windows32-awt-buildfixes/webrev.00/webrev/
> >
> > On 32bit windows, awt build did bitrot. Dtrace print callbacks need to
> > be declared with __stdcall. No other platform cares.
> >
> > Thanks, Thomas
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/awt-dev/attachments/20190326/ba9cdf76/attachment.html>

From alexey.ivanov at oracle.com  Tue Mar 26 15:26:50 2019
From: alexey.ivanov at oracle.com (Alexey Ivanov)
Date: Tue, 26 Mar 2019 15:26:50 +0000
Subject: <AWT Dev> 8221405: Fix Windows 32bit awt build
In-Reply-To: <CAA-vtUywsC3rM3nc5c45B+DCey0_ajvf+TjN8ZMpYj925kxuSw@mail.gmail.com>
References: <CAA-vtUwHAHf4fVE0LvW=_qnQgR5bG2Wc=twsafCRptL3L4zGdg@mail.gmail.com>
 <336e01bb-1e0d-4583-2a78-cd2d980aed05@oracle.com>
 <CAA-vtUywsC3rM3nc5c45B+DCey0_ajvf+TjN8ZMpYj925kxuSw@mail.gmail.com>
Message-ID: <3c5b1485-b5c2-9484-1873-c0a04b62e0b3@oracle.com>

Hi Thomas,

On 26/03/2019 14:41, Thomas St?fe wrote:
> Hi Alexey,
>
>
>
> On Tue, Mar 26, 2019 at 2:36 PM Alexey Ivanov 
> <alexey.ivanov at oracle.com <mailto:alexey.ivanov at oracle.com>> wrote:
>
>     Hi Thomas,
>
>     Looks good, I'm not a reviewer though.
>     Could I also ask you to push this changeset to jdk/client [1]
>     instead of
>     jdk/jdk?
>
>     A small question: two prototypes are changed in debug_trace.h but
>     only
>     one is updated in debug_trace.c. Is it because the functions matching
>     the second prototype have already been updated with JNICALL?
>
>
> Not really sure I understand the question. There is no real 1:1 
> relationship between my change in .h and .c:

I mean there are two prototypes in the header:
1. typedef void (JNICALL *DTRACE_OUTPUT_CALLBACK)(const char * msg);
2. typedef void (JNICALL *DTRACE_PRINT_CALLBACK)(const char * file, int 
line, int argc, const char * fmt, va_list arglist);

1. In C, only the first one is updated:
static void JNICALL DTrace_PrintStdErr(const char *msg);
which corresponds to the first case. This shouldn't have caused build 
failure because the declarations in .h and .c matched.

2. I believe DTrace_VPrintln and DTrace_VPrint are the callbacks for the 
2nd prototype of DTRACE_PRINT_CALLBACK. They're received JNICALL under 
JDK-8214120 but the header hasn't been updated. This caused the build 
failure.

The prevent the build failure, it would be enough to update the 2nd 
declaration in the header. (Or alternatively, drop JNICALL from 
DTrace_VPrintln and DTrace_VPrint in .c file.)
For consistency, you're updating the 1st declaration as well.

>
> DTRACE_PRINTxx macros call _DTrace_Template() which expands to 
> DTrace_PrintFunction(). First argument is pointer to DTrace_VPrint(), 
> which is a function decorated with JNICALL. Hence the build error - 
> the type of the first argument of DTrace_PrintFunction is 
> DTRACE_PRINT_CALLBACK, which is a fkt pointer *without* JNICALL.
>
> So one way to fix this was to correct the DTRACE_PRINT_CALLBACK type 
> to be a fkt pointer pointing to a JNICALL decorated function.
>
> That means that I also needed to fix all functions whose pointers are 
> being passed around as DTRACE_PRINT_CALLBACK. But there only was one I 
> saw, DTrace_PrintStdErr().

 From the above, it looks this isn't necessary as DTrace_PrintStdErr() 
is of type DTRACE_OUTPUT_CALLBACK.

However, I think it's better to have both DTRACE_OUTPUT_CALLBACK and 
DTRACE_PRINT_CALLBACK consistent: either with JNICALL or without.


Looks fine to me!

> I'll push to jdk/client. Will that be transported to jdk/jdk 
> automatically?

Yes, it will.
Although I'm not sure how often they're synced.

Regards,
Alexey

>
> Cheers, Thomas
>
>
>     Regards,
>     Alexey
>
>     [1] http://hg.openjdk.java.net/jdk/client/
>
>     On 25/03/2019 13:09, Thomas St?fe wrote:
>     > Hi all,
>     >
>     > Issue: https://bugs.openjdk.java.net/browse/JDK-8221405
>     > cr:
>     >
>     http://cr.openjdk.java.net/~stuefe/webrevs/8221405-windows32-awt-buildfixes/webrev.00/webrev/
>     >
>     > On 32bit windows, awt build did bitrot. Dtrace print callbacks
>     need to
>     > be declared with __stdcall. No other platform cares.
>     >
>     > Thanks, Thomas
>

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

From thomas.stuefe at gmail.com  Tue Mar 26 16:01:55 2019
From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=)
Date: Tue, 26 Mar 2019 17:01:55 +0100
Subject: <AWT Dev> 8221405: Fix Windows 32bit awt build
In-Reply-To: <3c5b1485-b5c2-9484-1873-c0a04b62e0b3@oracle.com>
References: <CAA-vtUwHAHf4fVE0LvW=_qnQgR5bG2Wc=twsafCRptL3L4zGdg@mail.gmail.com>
 <336e01bb-1e0d-4583-2a78-cd2d980aed05@oracle.com>
 <CAA-vtUywsC3rM3nc5c45B+DCey0_ajvf+TjN8ZMpYj925kxuSw@mail.gmail.com>
 <3c5b1485-b5c2-9484-1873-c0a04b62e0b3@oracle.com>
Message-ID: <CAA-vtUyH1nqFZfrJJecW_TLYqDOrJtabOWqogwdXMtOphKvRvQ@mail.gmail.com>

Hi Alexey,

On Tue, Mar 26, 2019 at 4:26 PM Alexey Ivanov <alexey.ivanov at oracle.com>
wrote:

> Hi Thomas,
>
> On 26/03/2019 14:41, Thomas St?fe wrote:
>
> Hi Alexey,
>
>
>
> On Tue, Mar 26, 2019 at 2:36 PM Alexey Ivanov <alexey.ivanov at oracle.com>
> wrote:
>
>> Hi Thomas,
>>
>> Looks good, I'm not a reviewer though.
>> Could I also ask you to push this changeset to jdk/client [1] instead of
>> jdk/jdk?
>>
>> A small question: two prototypes are changed in debug_trace.h but only
>> one is updated in debug_trace.c. Is it because the functions matching
>> the second prototype have already been updated with JNICALL?
>>
>>
> Not really sure I understand the question. There is no real 1:1
> relationship between my change in .h and .c:
>
>
> I mean there are two prototypes in the header:
> 1. typedef void (JNICALL *DTRACE_OUTPUT_CALLBACK)(const char * msg);
> 2. typedef void (JNICALL *DTRACE_PRINT_CALLBACK)(const char * file, int
> line, int argc, const char * fmt, va_list arglist);
>
> 1. In C, only the first one is updated:
> static void JNICALL DTrace_PrintStdErr(const char *msg);
> which corresponds to the first case. This shouldn't have caused build
> failure because the declarations in .h and .c matched.
>
> 2. I believe DTrace_VPrintln and DTrace_VPrint are the callbacks for the
> 2nd prototype of DTRACE_PRINT_CALLBACK. They're received JNICALL under
> JDK-8214120 but the header hasn't been updated. This caused the build
> failure.
>
>
I cannot find any place where function pointers to DTrace_VPrintln or
DTrace_VPrint are used. They only ever are called directly.


> The prevent the build failure, it would be enough to update the 2nd
> declaration in the header. (Or alternatively, drop JNICALL from
> DTrace_VPrintln and DTrace_VPrint in .c file.)
> For consistency, you're updating the 1st declaration as well.
>
>
> DTRACE_PRINTxx macros call _DTrace_Template() which expands to
> DTrace_PrintFunction(). First argument is pointer to DTrace_VPrint(), which
> is a function decorated with JNICALL. Hence the build error - the type of
> the first argument of DTrace_PrintFunction is DTRACE_PRINT_CALLBACK, which
> is a fkt pointer *without* JNICALL.
>
> So one way to fix this was to correct the DTRACE_PRINT_CALLBACK type to be
> a fkt pointer pointing to a JNICALL decorated function.
>
> That means that I also needed to fix all functions whose pointers are
> being passed around as DTRACE_PRINT_CALLBACK. But there only was one I saw,
> DTrace_PrintStdErr().
>
>
> From the above, it looks this isn't necessary as DTrace_PrintStdErr() is
> of type DTRACE_OUTPUT_CALLBACK.
>
> However, I think it's better to have both DTRACE_OUTPUT_CALLBACK and
> DTRACE_PRINT_CALLBACK consistent: either with JNICALL or without.
>
>
> Looks fine to me!
>
>
Great, I pushed. Thanks for reviewing!

--Thomas

> I'll push to jdk/client. Will that be transported to jdk/jdk automatically?
>
>
> Yes, it will.
> Although I'm not sure how often they're synced.
>
> Regards,
> Alexey
>
>
> Cheers, Thomas
>
>
>
>
>
>> Regards,
>> Alexey
>>
>> [1] http://hg.openjdk.java.net/jdk/client/
>>
>> On 25/03/2019 13:09, Thomas St?fe wrote:
>> > Hi all,
>> >
>> > Issue: https://bugs.openjdk.java.net/browse/JDK-8221405
>> > cr:
>> >
>> http://cr.openjdk.java.net/~stuefe/webrevs/8221405-windows32-awt-buildfixes/webrev.00/webrev/
>> >
>> > On 32bit windows, awt build did bitrot. Dtrace print callbacks need to
>> > be declared with __stdcall. No other platform cares.
>> >
>> > Thanks, Thomas
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/awt-dev/attachments/20190326/f588d8a7/attachment.html>

From andrew_m_leonard at uk.ibm.com  Tue Mar 26 19:42:04 2019
From: andrew_m_leonard at uk.ibm.com (Andrew Leonard)
Date: Tue, 26 Mar 2019 19:42:04 +0000
Subject: <AWT Dev> Request for Sponsor: 8217735:
 awt_image_GifImageDecoder_parseImage() "interlace" param has the wrong type
Message-ID: <OF91EBFB2B.E1E7E71B-ON002583C9.006BD0DA-802583C9.006C38B6@notes.na.collabserv.com>

Hi,
Please can I obtain a sponsor for this simple fix to correct the 
parseImage() jni parameter type?
https://bugs.openjdk.java.net/browse/JDK-8217735
http://cr.openjdk.java.net/~aleonard/8217735/webrev.00/

The problem manifests itself most notably with OpenJ9 when running the 
SwingSet2 demo, depending on how the stack byte alignment resolves 
iteself.
I've not seen an issue yet running SwingSet2 with Hotspot, possibly by 
luck of stack alignment.

Many thanks
Andrew

Andrew Leonard
Java Runtimes Development
IBM Hursley
IBM United Kingdom Ltd
Phone internal: 245913, external: 01962 815913
internet email: andrew_m_leonard at uk.ibm.com 

Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 
741598. 
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/awt-dev/attachments/20190326/d7f619b3/attachment.html>

From Sergey.Bylokhov at oracle.com  Tue Mar 26 21:04:34 2019
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Tue, 26 Mar 2019 14:04:34 -0700
Subject: <AWT Dev> [OpenJDK 2D-Dev] RFR: 8220528: [AIX] Fix basic
 Xinerama and Xrender functionality
In-Reply-To: <CA+3eh12-jEJywLruafE6bn79bT4CkyXJz7iHTWqiwaaywybHXQ@mail.gmail.com>
References: <CA+3eh130xEVyDdr=r+kjY9A1c8pqKkCSw4gb+3OpNFBLMts0UQ@mail.gmail.com>
 <CA+3eh1000n2+dtBf_+A7OFvTPceL86ASMBHfUn_NdDswPRbmYQ@mail.gmail.com>
 <CAA-vtUwXF7QaEMm+i=8U5zH0y6MkOFPvKRtnQsm+x2+Z_uyPPA@mail.gmail.com>
 <CA+3eh12-jEJywLruafE6bn79bT4CkyXJz7iHTWqiwaaywybHXQ@mail.gmail.com>
Message-ID: <ba8808ee-e8ec-05bc-cd83-f1bfd295a5e7@oracle.com>

v4 looks fine.

On 25/03/2019 11:42, Volker Simonis wrote:
> Hi Thomas, Christoph,
> 
> thanks for looking into my fix. I hope I've addressed all your
> concerns with my new webrev:
> 
> http://cr.openjdk.java.net/~simonis/webrevs/2019/8220528.v4
> 
> By the way, I've tested the new implementation by simulating a
> multi-screen environment on my Linux box with Xephyr:
> 
> $ Xephyr +xinerama -screen 1024x768 -screen 1024x768+1024+0 -ac -listen tcp :1
> 
> And started a Swing application from AIX where I've redirected the
> DISPLAY to myhost:1:
> 
> $ DISPLAY=myhost:1 ./images/jdk/bin/java -showversion
> -Dsun.awt.nativedebug=true -Dawtdebug.trace=true -Dawtdebug.on=true
> -Dawtdebug.ctrace=true -cp ~/Java HelloSwing
> 
> The various debug properties will lead to the following output:
> 
> openjdk version "13-internal" 2019-09-17
> OpenJDK Runtime Environment (slowdebug build 13-internal+0-adhoc.xxx.jdk-jdk)
> OpenJDK 64-Bit Server VM (slowdebug build
> 13-internal+0-adhoc.xxx.jdk-jdk, mixed mode)
> Xinerama extension is available
> calling XineramaQueryScreens func
> Enabling Xinerama support
>   num screens = 2
> allocating 2 screens
> 
> The Swing frame will appear on one of the Xinerama screens and can be
> move with the mouse between the two available screens.
> 
> If I hear no further objections, I plan to push this by the end of the week.
> 
> Thank you and best regards,
> Volker
> 
> 
> 
> On Mon, Mar 18, 2019 at 8:59 PM Thomas St?fe <thomas.stuefe at gmail.com> wrote:
>>
>> Sorry, not awt/2d group, but to me it looks fine too. Only nit: the error printout at 495 I would put right after the associated dlsym at 456. You want to make sure dlerror() is not stale at the point where you call it, since it would return NULL.
>>
>> Cheers, Thomas
>>
>>
>>
>> On Mon, Mar 18, 2019 at 3:17 PM Volker Simonis <volker.simonis at gmail.com> wrote:
>>>
>>> Ping...
>>>
>>> Can I please also get a review from the awt/2d group?
>>>
>>> Thanks,
>>> Volker
>>>
>>> On Wed, Mar 13, 2019 at 11:09 AM Volker Simonis
>>> <volker.simonis at gmail.com> wrote:
>>>>
>>>> Hi,
>>>>
>>>> can I please have a review for the following change which fixes
>>>> Xinerama and Xrender support on AIX:
>>>>
>>>> http://cr.openjdk.java.net/~simonis/webrevs/2019/8220528/
>>>> https://bugs.openjdk.java.net/browse/JDK-8220528
>>>>
>>>> The change basically fixes the way how the corresponding libraries
>>>> (libXext and libXrender) get loaded on AIX and does some cleanups with
>>>> regards to the various platform macros. I've also added some debug
>>>> tracing to the Xrender initialization code similar to the Xinerama
>>>> initialization.
>>>>
>>>> Thank you and best regards,
>>>> Volker


-- 
Best regards, Sergey.

From prasanta.sadhukhan at oracle.com  Wed Mar 27 09:54:58 2019
From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan)
Date: Wed, 27 Mar 2019 15:24:58 +0530
Subject: <AWT Dev> Request for Sponsor: 8217735:
 awt_image_GifImageDecoder_parseImage() "interlace" param has the wrong type
In-Reply-To: <OF91EBFB2B.E1E7E71B-ON002583C9.006BD0DA-802583C9.006C38B6@notes.na.collabserv.com>
References: <OF91EBFB2B.E1E7E71B-ON002583C9.006BD0DA-802583C9.006C38B6@notes.na.collabserv.com>
Message-ID: <18244b29-3950-9d71-0ad9-3cd908323ba3@oracle.com>

I can sponsor this...But I guess this review should be going to 2d-dev 
instead of awt-dev.

Regards
Prasanta
On 27-Mar-19 1:12 AM, Andrew Leonard wrote:
> Hi,
> Please can I obtain a sponsor for this simple fix to correct the 
> parseImage() jni parameter type?
> https://bugs.openjdk.java.net/browse/JDK-8217735
> http://cr.openjdk.java.net/~aleonard/8217735/webrev.00/ 
> <http://cr.openjdk.java.net/%7Ealeonard/8217735/webrev.00/>
>
> The problem manifests itself most notably with OpenJ9 when running the 
> SwingSet2 demo, depending on how the stack byte alignment resolves 
> iteself.
> I've not seen an issue yet running SwingSet2 with Hotspot, possibly by 
> luck of stack alignment.
>
> Many thanks
> Andrew
>
> Andrew Leonard
> Java Runtimes Development
> IBM Hursley
> IBM United Kingdom Ltd
> Phone internal: 245913, external: 01962 815913
> internet email: andrew_m_leonard at uk.ibm.com
>
> Unless stated otherwise above:
> IBM United Kingdom Limited - Registered in England and Wales with 
> number 741598.
> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/awt-dev/attachments/20190327/6d236b91/attachment-0001.html>

From philip.race at oracle.com  Wed Mar 27 16:06:50 2019
From: philip.race at oracle.com (Phil Race)
Date: Wed, 27 Mar 2019 09:06:50 -0700
Subject: <AWT Dev> [13] Review Request: 8215105
 java/awt/Robot/HiDPIScreenCapture/ScreenCaptureTest.java: Wrong Pixel Color
In-Reply-To: <dbae87f1-e1d0-5bc9-c4de-a75abe89bb6f@oracle.com>
References: <dbae87f1-e1d0-5bc9-c4de-a75abe89bb6f@oracle.com>
Message-ID: <d5ec01e7-dfb5-f336-aa99-670fbd61b465@oracle.com>

+1 (somehow this fix got lost).

-phil.


On 3/6/19 10:08 PM, Sergey Bylokhov wrote:
> Hello.
> Please review the fix for JDK 13.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8215105
> Fix: http://cr.openjdk.java.net/~serb/8215105/webrev.00
>
> Notes about the current implementation.
> ?1. The native system reads the pixels using the current "Display 
> Profile".
> ?2. The robot API saves pixels into BufferedImage, which uses the sRGB 
> color profile.
> ?3. To convert pixels from native representation to sRGB we used 
> "kCGColorSpaceGenericRGB" mode.
>
> Note that during conversion we may lost a color precision, this is why 
> we always configured our test systems to use "Generic RGB Profiles"
> But the logic above does not work on macOS 10.13.6.
>
>
> I have tested macOS 10.12/13/14 and the only constant which works on 
> all systems is a kCGColorSpaceSRGB + Display Profile "sRGB IEC 
> 61966-2.1".
> So we can:
> ?- Change nothing and skip "support" of 10.13.6 where 
> "kCGColorSpaceGenericRGB" + "Generic RGB Profiles" does not work.
> ?- Apply the current fix, but then we need to change the requirement 
> to the test systems(macos 10.12->10.14) to use "sRGB IEC 61966-2.1"
>
> But since "kCGColorSpaceGenericRGB is available only for legacy 
> reasons." it make sense to use kCGColorSpaceSRGB anyway.
> https://developer.apple.com/documentation/coregraphics/kcgcolorspacegenericrgb 
>
>


From philip.race at oracle.com  Wed Mar 27 23:39:38 2019
From: philip.race at oracle.com (Philip Race)
Date: Wed, 27 Mar 2019 16:39:38 -0700
Subject: <AWT Dev> [13] Review Request: 8220495 Update GIFlib library to
 the latest 5.1.8
In-Reply-To: <07d93382-4267-0ef9-d77d-b7138e68d8a8@oracle.com>
References: <037b3455-b3ad-7aab-51d2-5e0b882190c7@oracle.com>
 <5C92C27B.7090209@oracle.com>
 <07d93382-4267-0ef9-d77d-b7138e68d8a8@oracle.com>
Message-ID: <5C9C09BA.7000401@oracle.com>

+1

-phil.

On 3/21/19, 2:33 AM, Sergey Bylokhov wrote:
> On 20/03/2019 15:45, Philip Race wrote:
>> So something like this :
>> /** Begin JDK modifications to support building on Solaris **/
>> #ifdef SOLARIS
>> ..
>> #endif /* SOLARIS */
>> /** End JDK modifications to support building on Solaris **/
>
> An updated version:
> http://cr.openjdk.java.net/~serb/8220495/webrev.04
>
> I have updated this version to support platforms which are used for 
> all trains since jdk7+.
> Summary:
>  - #include <unistd.h> will be used on non-windows only
>  - #include <stdbool.h> is commented out(it is supported since c99, 
> and unsupported in SunStudio and VS2010)
>  - "inline" keyword is commented out(it is supported since c99, and 
> unsupported in SunStudio and VS2010)
>

From takiguc at linux.vnet.ibm.com  Thu Mar 28 13:27:20 2019
From: takiguc at linux.vnet.ibm.com (Ichiroh Takiguchi)
Date: Thu, 28 Mar 2019 22:27:20 +0900
Subject: <AWT Dev> RFR: 8211826: StringIndexOutOfBoundsException happens
 via GetStringUTFRegion()
In-Reply-To: <3b84398c-8376-d3af-5ee5-138d07ba8fe9@oracle.com>
References: <9ef1395b22bf1ec5106f532730f1bd42@linux.vnet.ibm.com>
 <3b84398c-8376-d3af-5ee5-138d07ba8fe9@oracle.com>
Message-ID: <8b86a17d1681f3d64b025bf7fd2f2df3@linux.vnet.ibm.com>

Hello.

Sorry for bad response.

Could you review the fix ?

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

Following changes are applied:
* Issue title was changed on JBS.
* Attached testcase was changed and add a fix for swing_GTKEngine.c.
* On swing_GTKEngine.c, maximum length size for String data is arranged.
     -static char conversionBuffer[CONV_BUFFER_SIZE];
     +static char conversionBuffer[(CONV_BUFFER_SIZE - 1) * 3 + 1];

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

Thanks,
Ichiroh Takiguchi

On 2018-11-10 11:02, Sergey Bylokhov wrote:
> Hi, Ichiroh.
> The changes looks good, i think that the test from
> the bug description can be integrated as well.
> 
>> Note that, 
>> src/java.desktop/unix/native/libawt_xawt/awt/swing_GTKEngine.c has 
>> same kind of code.
>> But buffer handling is not same, so I could not determine, I need to 
>> change swing_GTKEngine.c or not.
> 
> I think that in swing_GTKEngine.c we have an opposite
> problem when we use the java length as the size of the array,
> so GetStringUTFRegion may overrun the conversionBuffer.
> BTW I think we need to clean conversionBuffer before each usage.


From philip.race at oracle.com  Thu Mar 28 20:55:34 2019
From: philip.race at oracle.com (Philip Race)
Date: Thu, 28 Mar 2019 13:55:34 -0700
Subject: <AWT Dev> [13] Review Request: 8220320 Remove unused old code
 in GraphicsEnvironment on unix
In-Reply-To: <42097c78-3e3d-1b97-b02f-ac1d79dc6127@oracle.com>
References: <42097c78-3e3d-1b97-b02f-ac1d79dc6127@oracle.com>
Message-ID: <5C9D34C6.6000507@oracle.com>

+1

add the noreg-cleanup label to the bug

-phil.

On 3/8/19, 4:48 PM, Sergey Bylokhov wrote:
> Hello.
> Please review small fix for JDK 13.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8220320
> Fix: http://cr.openjdk.java.net/~serb/8220320/webrev.00
>
>  - The X11GraphicsDevice.initID() can be removed, because it is unused 
> and its native implementation was dropped already.
>  - The code related to #ifdef NETSCAPE can be dropped
>  - the null checks in Java_sun_awt_X11GraphicsConfig_initIDs() after 
> "CHECK_NULL()" are redundant
>