From dmitry.markov at oracle.com  Mon Sep  2 11:52:05 2019
From: dmitry.markov at oracle.com (Dmitry Markov)
Date: Mon, 2 Sep 2019 12:52:05 +0100
Subject: <AWT Dev> [14] Review Request: 8229515 [macos] access to window
 property of NSView on wrong thread
In-Reply-To: <daba0af9-2f44-f71a-90b1-4600f7d17b74@oracle.com>
References: <daba0af9-2f44-f71a-90b1-4600f7d17b74@oracle.com>
Message-ID: <6D70EC82-09F0-4360-84FB-9EF3A4BD26DC@oracle.com>

Hi Sergey,

The fix looks good to me.

Thanks,
Dmitry

> On 30 Aug 2019, at 21:59, Sergey Bylokhov <Sergey.Bylokhov at oracle.com> wrote:
> 
> Hello.
> Please review the fix for JDK 14.
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8229515
> Fix: http://cr.openjdk.java.net/~serb/8229515/webrev.00
> 
> The access to the "window" property of the NSView was moved to the appkit thread,
> since the Cocoa components should be used on this thread only.
> 
> -- 
> Best regards, Sergey.


From philip.race at oracle.com  Mon Sep  2 14:55:09 2019
From: philip.race at oracle.com (Philip Race)
Date: Mon, 02 Sep 2019 07:55:09 -0700
Subject: <AWT Dev> [14] Review Request: 8229515 [macos] access to window
 property of NSView on wrong thread
In-Reply-To: <daba0af9-2f44-f71a-90b1-4600f7d17b74@oracle.com>
References: <daba0af9-2f44-f71a-90b1-4600f7d17b74@oracle.com>
Message-ID: <5D6D2D4D.2030805@oracle.com>

+1

-phil

On 8/30/19, 1:59 PM, Sergey Bylokhov wrote:
> Hello.
> Please review the fix for JDK 14.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8229515
> Fix: http://cr.openjdk.java.net/~serb/8229515/webrev.00
>
> The access to the "window" property of the NSView was moved to the 
> appkit thread,
> since the Cocoa components should be used on this thread only.
>

From gnu.andrew at redhat.com  Tue Sep  3 04:50:49 2019
From: gnu.andrew at redhat.com (Andrew John Hughes)
Date: Tue, 3 Sep 2019 05:50:49 +0100
Subject: <AWT Dev> [8u] 8217676: Upgrade libpng to 1.6.37
In-Reply-To: <ed79b415-4d25-0ff7-265c-6a1441b3a8fd@redhat.com>
References: <bc7785da-e5b2-416c-9e80-4eadcd3a7d59@redhat.com>
 <42cc1803-6f71-ba9d-d262-f79522071f10@redhat.com>
 <ed79b415-4d25-0ff7-265c-6a1441b3a8fd@redhat.com>
Message-ID: <a88824fb-959a-5c35-b370-2fd3732e47f8@redhat.com>

On 22/08/2019 21:00, Zhengyu Gu wrote:
> 

snip...

> Updated webrev:
> 
> root: http://cr.openjdk.java.net/~zgu/JDK-8217676-8u/root/webrev.00/
> corba: http://cr.openjdk.java.net/~zgu/JDK-8217676-8u/corba/webrev.00
> hotspot: http://cr.openjdk.java.net/~zgu/JDK-8217676-8u/hotspot/webrev.00
> jaxp: http://cr.openjdk.java.net/~zgu/JDK-8217676-8u/jaxp/webrev.00
> jaxws: http://cr.openjdk.java.net/~zgu/JDK-8217676-8u/jaxws/webrev.00/
> jdk: http://cr.openjdk.java.net/~zgu/JDK-8217676-8u/jdk/webrev.00/
> langtools:
> http://cr.openjdk.java.net/~zgu/JDK-8217676-8u/langtools/webrev.00/
> nashorn: http://cr.openjdk.java.net/~zgu/JDK-8217676-8u/nashorn/webrev.00/
> 
> Thanks,
> 
> -Zhengyu
> 
> 

The license patch seems to miss some header lines when compared with
11u, and also removes a section about trademarks and export control that
isn't altered in the 11u version. How was it applied?

I've attached what I get from manually applying the 11u patch to
THIRD_PARTY_README. This diffs cleanly against libpng.md in 11u.

Thanks,
-- 
Andrew :)

Senior Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)

PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net)
Fingerprint = 5132 579D D154 0ED2 3E04  C5A0 CFDA 0F9B 3596 4222
https://keybase.io/gnu_andrew
-------------- next part --------------
A non-text attachment was scrubbed...
Name: libpng_license.patch
Type: text/x-patch
Size: 8529 bytes
Desc: not available
URL: <https://mail.openjdk.java.net/pipermail/awt-dev/attachments/20190903/61964092/libpng_license.patch>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: OpenPGP digital signature
URL: <https://mail.openjdk.java.net/pipermail/awt-dev/attachments/20190903/61964092/signature.asc>

From zgu at redhat.com  Tue Sep  3 14:18:47 2019
From: zgu at redhat.com (Zhengyu Gu)
Date: Tue, 3 Sep 2019 10:18:47 -0400
Subject: <AWT Dev> [8u] 8217676: Upgrade libpng to 1.6.37
In-Reply-To: <a88824fb-959a-5c35-b370-2fd3732e47f8@redhat.com>
References: <bc7785da-e5b2-416c-9e80-4eadcd3a7d59@redhat.com>
 <42cc1803-6f71-ba9d-d262-f79522071f10@redhat.com>
 <ed79b415-4d25-0ff7-265c-6a1441b3a8fd@redhat.com>
 <a88824fb-959a-5c35-b370-2fd3732e47f8@redhat.com>
Message-ID: <4a2daffd-c776-25fa-8f08-ac61949f4caa@redhat.com>

Hi Andrew,

> The license patch seems to miss some header lines when compared with
> 11u, and also removes a section about trademarks and export control that
> isn't altered in the 11u version. How was it applied?
> 
> I've attached what I get from manually applying the 11u patch to
> THIRD_PARTY_README. This diffs cleanly against libpng.md in 11u.
> 

Updated all THIRD_PARTY_README files with your patch.

http://cr.openjdk.java.net/~zgu/JDK-8217676-8u/v2/

Retested with jdk_imageio.

Thanks,

-Zhengyu

> Thanks,
> 

From matthias.baesken at sap.com  Tue Sep  3 15:40:24 2019
From: matthias.baesken at sap.com (Baesken, Matthias)
Date: Tue, 3 Sep 2019 15:40:24 +0000
Subject: <AWT Dev> RFR: 8230480: check malloc/calloc results in java.desktop
Message-ID: <AM6PR02MB5078D872F6EDF48FD20E482693B90@AM6PR02MB5078.eurprd02.prod.outlook.com>

Hello,  please review this small change .

I noticed that  at a few places  in java.desktop  checking  malloc/calloc   return  values  is not done.
This should be changed .

Additionally  I  think we miss here a free in an early return, changed it too :

http://cr.openjdk.java.net/~mbaesken/webrevs/8230480.0/src/java.desktop/unix/native/common/awt/X11Color.c.frames.html

567     if (depth > 12) {
568         free (awt_data->awtImage);
569         return 1;
570     }



Build/webrev :

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

http://cr.openjdk.java.net/~mbaesken/webrevs/8230480.0/


Thanks, Matthias
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/awt-dev/attachments/20190903/ce849040/attachment.html>

From philip.race at oracle.com  Tue Sep  3 16:57:32 2019
From: philip.race at oracle.com (Phil Race)
Date: Tue, 3 Sep 2019 09:57:32 -0700
Subject: <AWT Dev> [OpenJDK 2D-Dev] RFR: 8230480: check malloc/calloc
 results in java.desktop
In-Reply-To: <AM6PR02MB5078D872F6EDF48FD20E482693B90@AM6PR02MB5078.eurprd02.prod.outlook.com>
References: <AM6PR02MB5078D872F6EDF48FD20E482693B90@AM6PR02MB5078.eurprd02.prod.outlook.com>
Message-ID: <55d19f86-29f6-aa3f-21ef-8c1e2cf371ef@oracle.com>

I am not sure about that free you added.
A return of "1" means success. And a caller is then expecting the 
awtImage to be valid.

How did you determine that this was the correct thing to do here ?

-phil.

On 9/3/19 8:40 AM, Baesken, Matthias wrote:
>
> Hello, ?please review this small change .
>
> I noticed that? at a few places? in java.desktop? checking 
> ?malloc/calloc ??return values? is not done.
>
> This should be changed .
>
> Additionally? I ?think we miss here a free in an early return, changed 
> it too :
>
> http://cr.openjdk.java.net/~mbaesken/webrevs/8230480.0/src/java.desktop/unix/native/common/awt/X11Color.c.frames.html
>
> 567???? if (depth > 12) {
>
> 568???????? free (awt_data->awtImage);
>
> 569???????? return 1;
>
> 570???? }
>
> Build/webrev :
>
> https://bugs.openjdk.java.net/browse/JDK-8230480
>
> http://cr.openjdk.java.net/~mbaesken/webrevs/8230480.0/
>
> Thanks, Matthias
>

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

From alexey.ivanov at oracle.com  Tue Sep  3 17:55:04 2019
From: alexey.ivanov at oracle.com (Alexey Ivanov)
Date: Tue, 3 Sep 2019 18:55:04 +0100
Subject: <AWT Dev> <Swing Dev> [13] Review Request: 8225372
 accessibility errors in tables in java.desktop files
In-Reply-To: <ebc1fdff-d319-4a43-b1bd-b801136b6227@default>
References: <ebc1fdff-d319-4a43-b1bd-b801136b6227@default>
Message-ID: <fbd5f3e1-0f13-2a83-d852-d00ca8ccdf08@oracle.com>

Hi Sergey,

Sorry for my belated reply.

Please see my comments inline:

On 03/08/2019 00:56, Sergey Bylokhov wrote:
> Hello.
>
> The accessibility checker found similar issues in the private methods in java.awt.geom.Path2D class. The spec for these methods is exposed via serialization form.

Path2D.java looks fine to me.

>
> So we need to fix it as well:
> http://cr.openjdk.java.net/~serb/8225372/webrev.02
>
> ----- Sergey.Bylokhov at oracle.com wrote:
>
>> Hi, Alexey.
>>
>> Thank you for review, the new version is here:
>> Fix: http://cr.openjdk.java.net/~serb/8225372/webrev.01
>> Doc:
>> http://cr.openjdk.java.net/~serb/8225372/docs.01/api/java.desktop/module-summary.html
>>
>> See comments inline:
>>
>> On 14/06/2019 09:19, Alexey Ivanov wrote:
>>> *GridBagLayout.java*
>>> Does it make sense to use nested lists for valid values> It could
>> make the presentation clearer rather than a paragraph followed by a
>> list.
>>
>> We can:
>> http://cr.openjdk.java.net/~serb/8225372/docs.01/api/java.desktop/java/awt/GridBagLayout.html
>> But I am not sure that it looks better due to the current default
>> styles for nested <li>

It looks fine to me. And it has more semantic markup.
For more visual distinction, we can add style="list-style-type: circle" 
to all the nested <ul> elements, or use ?square? type. Alternatively, 
it's possible to modify the style of the outer <ul> element, the nested 
<ul>'s are still rendered with ?disc? type.


There are several text passages that aren't part of paragraph. I'm not 
sure if ?orphaned? text should be put into a <p>.

The markup for Figure 2 and 3 can be simplified, especially if the image 
headers are dropped.

There's *an error* in ?alt? attribute for Figure 2 and 3: the images are 
referred to as Figures 1 and 2 correspondingly.

>>
>>> The value ?center? is invalid for ?float? property in CSS, so it
>> must be removed, including style attribute of <img> element.
>>
>> I dropped all incorrect "float" attributes whenever possible.

These changes look good. Thanks for cleaning this up across the entire 
module.

>>
>>> *DesktopProperties.html*
>>> I'm still unsure we should suppress rendering <th> in bold, should
>> we not?
>>
>> I changed the code to use default style as-is.
>>
>>> *Modality.html*
>>> The table in examples could be replaced by a series of
>>> <ol style="float: left"> element with , followed by
>>> <p style="float: left"><img ...></p>
>>> Then goes <div style="clear: left"></div>.
>>> I would probably add titles to the examples to make
>>> the distinction between the examples clearer. If each
>>> example is preceded by <h3>Example #</h3>, then
>>> style="clear: left" can be applied to it.
>>> If this sounds reasonable, I can file a new bug to
>>> handle this. This way we'll get rid of presentation table.
>> I think that the final result will be quite similar to the existing
>> table?
>> We can change the order of columns, so the a11y tool will read the
>> text of the image(Example 1/Example 2/etc) and then the current
>> description of the example.
>> http://cr.openjdk.java.net/~serb/8225372/docs.01/api/java.desktop/java/awt/doc-files/Modality.html

Yes, it will look similar to how it looks at the moment. Yet the markup 
will be more semantic without presentation table. In fact, I went ahead 
and re-done the markup of examples:
http://cr.openjdk.java.net/~aivanov/8225372/webrev.00/
http://cr.openjdk.java.net/~aivanov/8225372/webrev.00/raw_files/new/src/java.desktop/share/classes/java/awt/doc-files/Modality.html#Examples

I find it clearer even when viewing visually. Each example is separated 
from others. If anchors are added, it will be possible to link to an 
individual example.

I used Narrator in Windows 10 to read the examples. I admit it's hard 
for me to judge objectively, however, the headers make the page easier 
to navigate and to understand where the next example starts.


There's a little inconsistency in the examples: at times quotes are 
used, at other times they aren't. Shall the quotes be dropped?

Another issue is that Modality.html extensively uses <u> element [3]. 
This element was deprecated in HTML 4; it was restored with HTML 5 with 
new semantic. I strongly believe the usage of <u> in this document does 
not correspond to the element semantics [4][5]. I think it should be 
replaced with <mark> ?to mark key words or phrases? or <i> ?to denote 
technical terms?? which better correspond to the usage on this page.

Definitely, this issue should be addressed separately from this one. The 
entire desktop module should be analysed and cleaned of <u> where it's 
used for presentational purposes only. (The same is true for <b> and <i> 
too.)

[3] https://developer.mozilla.org/en-US/docs/Web/HTML/Element/u
[4] https://developer.mozilla.org/en-US/docs/Web/HTML/Element/u#Usage_notes
[5] 
https://developer.mozilla.org/en-US/docs/Web/HTML/Element/u#Avoiding_%3Cu%3E


>>> *NumericShaper.html*
>>> The table has only one row group, so you have to add row groups:
>>> <tbody> elements create the row group that will be associated with
>> ?Arabic? row group header.
>>
>> fixed.
>>> *gif_metadata.html*
>>> As you mention, some tables don't have meaningful row header. And
>> it's not required in this case.
>>> Adding the additional index column which does not make the table
>> clearer does not make any sense to me. We already have column headers
>> (yes, scope="col" should be added), and that resolves the missing
>> header problem, doesn't it?
>>> See ?Tables with one header? article in Web Accessibility Tutorial:
>>>
>> https://www.w3.org/WAI/tutorials/tables/one-header/#table-with-ambiguous-data
>>
>> The current document checker requires both row and columns headers. We
>> can fix the checker, but I do not see an issue with "index", these
>> tables look like a grid which contains enumerated data.

Well, I think the additional column adds noise when it's read by 
Narrator. I cannot see any scenario where the index column could be useful.

At the same time, I don't mind adding the Index column if everyone 
agrees it's the way to go. However, fixing the checker still seems like 
a better option. As another option, the first column could be the header 
of the row.

>>> *tiff_metadata.html*
>>> Compression type headers should be in <thead> (lines 516?518) and other table content in <tbody>
>>> In case of Mapping the Standard Metadata Format to TIFF Native Image Metadata, the first column could probably be the row header. I'm not sure.
>> I added index to all these tables, otherwise, the tables looks
>> non-unified.
>>
>>> The extra row in this table, lines 869?872 could be removed completely.
>> Fixed.
>>
>>> *BoxLayout.java*
>>> It would suggest more semantic mark-up for "Example" (lines 39?44):
>>> <p><b>Example:</b>
>>> <p><img ...>
>>> instead of changing only text presentation by ?font-weight: bold?
>> property on <div> element.
>>> This is applicable to other similar cases.
>>> <b> [1] has new semantics since HTML5; <strong> [2] can also be
>> used, however, in this case this snipped does not represent anything
>> of certain importance.>
>>> style attribute on <img> element has invalid value of ?bottom? for
>> property ?float?, so it must be removed.
>>
>> Fixed.
>>
>>> [1] https://developer.mozilla.org/en-US/docs/Web/HTML/Element/b
>>> [2] https://developer.mozilla.org/en-US/docs/Web/HTML/Element/strong

>>> *componentProperties.html*
>>> The same as DesktopProperties.html: should we suppress
>>> rendering <th> in bold?
>>>
>>> JFileChooser, JInternalFrame, JInternalFrameTitlePane,
>>> JProgressBar, JSlider, JTabbedPane, Text Properties
>>> tables lack <thead> element around the header row.
>>> Because of the style applied, the header row is not
>>> rendered in bold. So suppressing bold rendering proved
>>> to be useful.

The tables of properties have no <thead> element. Their header row 
should be inside <thead> element; the start of <tbody> should be moved 
below the closing of </thead>.

>>> On 12/06/2019 06:29, Sergey Bylokhov wrote:
>>>> Hello.
>>>> Please review the fix for JDK 13.
>>>>
>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8225372
>>>> Fix: http://cr.openjdk.java.net/~serb/8225372/webrev.00
>>>> Doc: http://cr.openjdk.java.net/~serb/8225372/docs/api/java.desktop/module-summary.html
>>>>
>>>> <SNIP>
-- 
Regards,
Alexey

From matthias.baesken at sap.com  Wed Sep  4 08:56:52 2019
From: matthias.baesken at sap.com (Baesken, Matthias)
Date: Wed, 4 Sep 2019 08:56:52 +0000
Subject: <AWT Dev> [OpenJDK 2D-Dev] RFR: 8230480: check malloc/calloc
 results in java.desktop
In-Reply-To: <55d19f86-29f6-aa3f-21ef-8c1e2cf371ef@oracle.com>
References: <AM6PR02MB5078D872F6EDF48FD20E482693B90@AM6PR02MB5078.eurprd02.prod.outlook.com>
 <55d19f86-29f6-aa3f-21ef-8c1e2cf371ef@oracle.com>
Message-ID: <VI1PR02MB508661B3FC96E4966AFCA00A93B80@VI1PR02MB5086.eurprd02.prod.outlook.com>

Hi Phil ,   I think you are  right,  the "depth > 12"  is a legitimate  case  so no freeing should be done there .

New webrev :

  *   Removed the free for "depth > 12"
  *   ZALLOC-ed    "awt_data->color_data = ZALLOC (_ColorData);"   in X11Color.c  needs return value handling too



http://cr.openjdk.java.net/~mbaesken/webrevs/8230480.1/


Best regards, Matthias



From: Phil Race <philip.race at oracle.com>
Sent: Dienstag, 3. September 2019 18:58
To: Baesken, Matthias <matthias.baesken at sap.com>; awt-dev at openjdk.java.net; 2d-dev at openjdk.java.net
Subject: Re: [OpenJDK 2D-Dev] RFR: 8230480: check malloc/calloc results in java.desktop

I am not sure about that free you added.
A return of "1" means success. And a caller is then expecting the awtImage to be valid.

How did you determine that this was the correct thing to do here ?

-phil.
On 9/3/19 8:40 AM, Baesken, Matthias wrote:
Hello,  please review this small change .

I noticed that  at a few places  in java.desktop  checking  malloc/calloc   return  values  is not done.
This should be changed .

Additionally  I  think we miss here a free in an early return, changed it too :

http://cr.openjdk.java.net/~mbaesken/webrevs/8230480.0/src/java.desktop/unix/native/common/awt/X11Color.c.frames.html

567     if (depth > 12) {
568         free (awt_data->awtImage);
569         return 1;
570     }



Build/webrev :

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

http://cr.openjdk.java.net/~mbaesken/webrevs/8230480.0/


Thanks, Matthias

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

From philip.race at oracle.com  Wed Sep  4 16:23:05 2019
From: philip.race at oracle.com (Phil Race)
Date: Wed, 4 Sep 2019 09:23:05 -0700
Subject: <AWT Dev> [OpenJDK 2D-Dev] RFR: 8230480: check malloc/calloc
 results in java.desktop
In-Reply-To: <VI1PR02MB508661B3FC96E4966AFCA00A93B80@VI1PR02MB5086.eurprd02.prod.outlook.com>
References: <AM6PR02MB5078D872F6EDF48FD20E482693B90@AM6PR02MB5078.eurprd02.prod.outlook.com>
 <55d19f86-29f6-aa3f-21ef-8c1e2cf371ef@oracle.com>
 <VI1PR02MB508661B3FC96E4966AFCA00A93B80@VI1PR02MB5086.eurprd02.prod.outlook.com>
Message-ID: <38161194-7a5a-389f-06f2-f52d1b18f9da@oracle.com>

OK. Approved. Please push to jdk/client, not jdk/jdk, unless at least 
you've run
the *headful* jtreg tests on Linux, and sound tests on Mac ..

-phil.

On 9/4/19 1:56 AM, Baesken, Matthias wrote:
>
> Hi Phil ,?? I think you are? right,? the ?depth > 12?? is a 
> legitimate? case? so no freeing should be done there .
>
> New webrev :
>
>   * Removed the free for ?depth > 12?
>   * ZALLOC-ed??? ?awt_data->color_data = ZALLOC (_ColorData);??? in
>     X11Color.c? needs return value handling too
>
> http://cr.openjdk.java.net/~mbaesken/webrevs/8230480.1/
>
> Best regards, Matthias
>
> *From:*Phil Race <philip.race at oracle.com>
> *Sent:* Dienstag, 3. September 2019 18:58
> *To:* Baesken, Matthias <matthias.baesken at sap.com>; 
> awt-dev at openjdk.java.net; 2d-dev at openjdk.java.net
> *Subject:* Re: [OpenJDK 2D-Dev] RFR: 8230480: check malloc/calloc 
> results in java.desktop
>
> I am not sure about that free you added.
> A return of "1" means success. And a caller is then expecting the 
> awtImage to be valid.
>
> How did you determine that this was the correct thing to do here ?
>
> -phil.
>
> On 9/3/19 8:40 AM, Baesken, Matthias wrote:
>
>     Hello, ?please review this small change .
>
>     I noticed that? at a few places? in java.desktop? checking
>     ?malloc/calloc ??return? values? is not done.
>
>     This should be changed .
>
>     Additionally? I ?think we miss here a free in an early return,
>     changed it too :
>
>     http://cr.openjdk.java.net/~mbaesken/webrevs/8230480.0/src/java.desktop/unix/native/common/awt/X11Color.c.frames.html
>
>     567???? if (depth > 12) {
>
>     568???????? free (awt_data->awtImage);
>
>     569???????? return 1;
>
>     570???? }
>
>     Build/webrev :
>
>     https://bugs.openjdk.java.net/browse/JDK-8230480
>
>     http://cr.openjdk.java.net/~mbaesken/webrevs/8230480.0/
>
>     Thanks, Matthias
>

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

From Sergey.Bylokhov at oracle.com  Sat Sep  7 03:05:57 2019
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Fri, 6 Sep 2019 20:05:57 -0700
Subject: <AWT Dev> [14] Review Request: 8225101 Crash at
 sun.awt.X11.XlibWrapper.XkbGetUpdatedMap when change keybord map
Message-ID: <d9b1eb02-e2a3-d521-3c84-01181ee5a3b3@oracle.com>

Hello.
Please review the fix for JDK 14.

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

This is the fix of the bug caused by dereferencing 0 in XkbMapNotify notification.

The sun.awt.X11.XToolkit class contains a native pointer "awt_XKBDescPtr" which
is initialized at the start of the application or by the "XkbNewKeyboardNotify"
notification. And deallocated by the same "XkbNewKeyboardNotify" or via "ShutdownHook"

The "awt_XKBDescPtr" in the changed code in the webrev might be NULL in two situations:
  - Sometime before the "XlibWrapper.XkbGetMap" returned NULL for some reason.
  - The shutdown hook start to execute in parallel and dispose of the current keyboard info and
    sets "awt_XKBDescPtr" to 0

I was able to reproduce the bug by some script which floods the XServer with millions of
keyboard requests, which makes the system unresponsive but allow to get the timings to
reproduce the bug.

As a fix, I suggest using "awt_XKBDescPtr" in "XkbMapNotify" only if it is not 0, as we
already do in all other places.


-- 
Best regards, Sergey.

From akashche at redhat.com  Mon Sep  9 16:29:56 2019
From: akashche at redhat.com (Alex Kashchenko)
Date: Mon, 9 Sep 2019 17:29:56 +0100
Subject: <AWT Dev> [8u] RFR: 8196681: Java Access Bridge logging and debug
 flags dynamically controlled
Message-ID: <be9f2206-fea1-de32-71d1-6ffc954d3160@redhat.com>

Hi,

Please review the code change required to backport JDK-8196681 to 8u.

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

Original review thread: 
http://mail.openjdk.java.net/pipermail/awt-dev/2018-September/014302.html

11u changeset: 
https://hg.openjdk.java.net/jdk-updates/jdk11u-dev/rev/af9ad0ae9039

Patch does not apply cleanly, because std::chrono is used for 
timestamps. And this part of C++11 standard is not supported by VS2010 
toolchain that is used for 8u windows builds. The following change 
reimplements the same timestamps without std::chrono:


  auto getTimeStamp() -> long long {
-    using namespace std::chrono;
-    auto timeNow = 
duration_cast<milliseconds>(steady_clock::now().time_since_epoch());
-
-    return timeNow.count();
+    LARGE_INTEGER freqLarge;
+    ::QueryPerformanceFrequency(&freqLarge);
+    long long freq = freqLarge.QuadPart;
+    LARGE_INTEGER counterLarge;
+    ::QueryPerformanceCounter(&counterLarge);
+    long long counter = counterLarge.QuadPart;
+    long long milliDen = 1000;
+    long long whole = (counter / freq) * milliDen;
+    long long part = (counter % freq) * milliDen / freq;
+    return whole + part;
  }


Backport also depends on JDK-8077707 and JDK-8132249 (both apply 
cleanly), "jdk8u-fix-request" label was added for them.

Backport requires CSR that was filed in JDK-8230699.

Thanks!

-- 
-Alex

From philip.race at oracle.com  Mon Sep  9 20:06:59 2019
From: philip.race at oracle.com (Phil Race)
Date: Mon, 9 Sep 2019 13:06:59 -0700
Subject: <AWT Dev> [14] Review Request: 8225101 Crash at
 sun.awt.X11.XlibWrapper.XkbGetUpdatedMap when change keybord map
In-Reply-To: <d9b1eb02-e2a3-d521-3c84-01181ee5a3b3@oracle.com>
References: <d9b1eb02-e2a3-d521-3c84-01181ee5a3b3@oracle.com>
Message-ID: <9f500d89-9207-1a40-2885-fd706a7ff9bc@oracle.com>

Approved

-phil.

On 9/6/19 8:05 PM, Sergey Bylokhov wrote:
> Hello.
> Please review the fix for JDK 14.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8225101
> Fix: http://cr.openjdk.java.net/~serb/8225101/webrev.00
>
> This is the fix of the bug caused by dereferencing 0 in XkbMapNotify 
> notification.
>
> The sun.awt.X11.XToolkit class contains a native pointer 
> "awt_XKBDescPtr" which
> is initialized at the start of the application or by the 
> "XkbNewKeyboardNotify"
> notification. And deallocated by the same "XkbNewKeyboardNotify" or 
> via "ShutdownHook"
>
> The "awt_XKBDescPtr" in the changed code in the webrev might be NULL 
> in two situations:
> ?- Sometime before the "XlibWrapper.XkbGetMap" returned NULL for some 
> reason.
> ?- The shutdown hook start to execute in parallel and dispose of the 
> current keyboard info and
> ?? sets "awt_XKBDescPtr" to 0
>
> I was able to reproduce the bug by some script which floods the 
> XServer with millions of
> keyboard requests, which makes the system unresponsive but allow to 
> get the timings to
> reproduce the bug.
>
> As a fix, I suggest using "awt_XKBDescPtr" in "XkbMapNotify" only if 
> it is not 0, as we
> already do in all other places.
>
>


From Sergey.Bylokhov at oracle.com  Mon Sep  9 22:14:14 2019
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Mon, 9 Sep 2019 15:14:14 -0700
Subject: <AWT Dev> <Swing Dev> [13] Review Request: 8225372
 accessibility errors in tables in java.desktop files
In-Reply-To: <fbd5f3e1-0f13-2a83-d852-d00ca8ccdf08@oracle.com>
References: <ebc1fdff-d319-4a43-b1bd-b801136b6227@default>
 <fbd5f3e1-0f13-2a83-d852-d00ca8ccdf08@oracle.com>
Message-ID: <a13a0654-ccf4-790b-d99b-95bbe0f19139@oracle.com>

Hi, Alexey.

Thank you for the review, here is an updated version:
http://cr.openjdk.java.net/~serb/8225372/webrev.03

  - GridBagLayout.html: The text about "Figures 1 and 2" was changed
  - componentProperties.html: The <thead> is added to some of the tables
  - Modality.html: The <u> was dropped from everywhere, it does not seems to be useful
  - Modality.html: An example block was reworked as suggested:
    http://cr.openjdk.java.net/~serb/8225372/docs.03/api/java.desktop/java/awt/doc-files/Modality.html

On 9/3/19 10:55 am, Alexey Ivanov wrote:
> It looks fine to me. And it has more semantic markup.
> For more visual distinction, we can add style="list-style-type: circle" to all the nested <ul> elements, or use ?square? type. Alternatively, it's possible to modify the style of the outer <ul> element, the nested <ul>'s are still rendered with ?disc? type.

They are the same because of CSS style used by the JavaDoc tool(by default nested ul elements are different from the outer elements), I guess we need to file a bug to restore this appearance(if this change was not intentional).


-- 
Best regards, Sergey.

From drc at virtualgl.org  Tue Sep 10 02:55:31 2019
From: drc at virtualgl.org (DRC)
Date: Mon, 9 Sep 2019 21:55:31 -0500
Subject: <AWT Dev> Status of JDK-8016255
Message-ID: <e0912682-358a-d59c-dd23-44ff5ab8433d@virtualgl.org>

This bug:
https://bugs.openjdk.java.net/browse/JDK-8016255
was opened over six years ago and is still listed as "unresolved."  It
unfortunately affects my product.  Any chance of getting a resolution or
an update on its status?

In a nutshell, "dead keys" (accent modifier keys) on certain
international keyboards are not properly handled in Swing on Un*x
systems.  Only the key release event from those keys is delivered to
applications, without a prior key press event.

DRC

From pankaj.b.bansal at oracle.com  Tue Sep 10 06:07:13 2019
From: pankaj.b.bansal at oracle.com (Pankaj Bansal)
Date: Mon, 9 Sep 2019 23:07:13 -0700 (PDT)
Subject: <AWT Dev> [14] Review Request: 8225101 Crash at
 sun.awt.X11.XlibWrapper.XkbGetUpdatedMap when change keybord map
In-Reply-To: <9f500d89-9207-1a40-2885-fd706a7ff9bc@oracle.com>
References: <d9b1eb02-e2a3-d521-3c84-01181ee5a3b3@oracle.com>
 <9f500d89-9207-1a40-2885-fd706a7ff9bc@oracle.com>
Message-ID: <4fa43159-f71a-4b16-99b6-b3735923b70d@default>

Looks good to me

-Pankaj

-----Original Message-----
From: Phil Race 
Sent: Tuesday, September 10, 2019 1:37 AM
To: Sergey Bylokhov; awt-dev at openjdk.java.net
Subject: Re: <AWT Dev> [14] Review Request: 8225101 Crash at sun.awt.X11.XlibWrapper.XkbGetUpdatedMap when change keybord map

Approved

-phil.

On 9/6/19 8:05 PM, Sergey Bylokhov wrote:
> Hello.
> Please review the fix for JDK 14.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8225101
> Fix: http://cr.openjdk.java.net/~serb/8225101/webrev.00
>
> This is the fix of the bug caused by dereferencing 0 in XkbMapNotify 
> notification.
>
> The sun.awt.X11.XToolkit class contains a native pointer 
> "awt_XKBDescPtr" which is initialized at the start of the application 
> or by the "XkbNewKeyboardNotify"
> notification. And deallocated by the same "XkbNewKeyboardNotify" or 
> via "ShutdownHook"
>
> The "awt_XKBDescPtr" in the changed code in the webrev might be NULL 
> in two situations:
> ?- Sometime before the "XlibWrapper.XkbGetMap" returned NULL for some 
> reason.
> ?- The shutdown hook start to execute in parallel and dispose of the 
> current keyboard info and
> ?? sets "awt_XKBDescPtr" to 0
>
> I was able to reproduce the bug by some script which floods the 
> XServer with millions of keyboard requests, which makes the system 
> unresponsive but allow to get the timings to reproduce the bug.
>
> As a fix, I suggest using "awt_XKBDescPtr" in "XkbMapNotify" only if 
> it is not 0, as we already do in all other places.
>
>


From pankaj.b.bansal at oracle.com  Tue Sep 10 10:06:22 2019
From: pankaj.b.bansal at oracle.com (Pankaj Bansal)
Date: Tue, 10 Sep 2019 03:06:22 -0700 (PDT)
Subject: <AWT Dev> [14] RFR JDK-8225805 - Java Access Bridge does not close
	the logger
Message-ID: <4dc446d8-b8ea-437e-97c8-e4110206b9f0@default>

Hi All,

Please review the following fix for jdk14.


Bug: 

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

 

webrev

http://cr.openjdk.java.net/~pbansal/8225805/webrev01/

 

 

Issue:

The Windows WindowsAccessBridge Log file is not being closed anywhere. We should always close opened resources.

It is not causing any issue as all files opened by the program are closed when program exits normally (JAWS in this case). But case be an issue in case the program terminates abnormally. We should explicitly close the log file.

 

Fix:

Closed the WindowsAccessBridge log file in destructor.

 


Regards,
Pankaj Bansal

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

From dmitry.markov at oracle.com  Tue Sep 10 11:24:22 2019
From: dmitry.markov at oracle.com (Dmitry Markov)
Date: Tue, 10 Sep 2019 12:24:22 +0100
Subject: <AWT Dev> [14] RFR JDK-8225805 - Java Access Bridge does not
 close the logger
In-Reply-To: <4dc446d8-b8ea-437e-97c8-e4110206b9f0@default>
References: <4dc446d8-b8ea-437e-97c8-e4110206b9f0@default>
Message-ID: <89478841-357A-4A11-B5A3-48EA33E56D11@oracle.com>

Hi Pankaj,

The fix looks good to me.

Thanks,
Dmitry

> On 10 Sep 2019, at 11:06, Pankaj Bansal <pankaj.b.bansal at oracle.com> wrote:
> 
> Hi All,
> 
> Please review the following fix for jdk14.
> 
> Bug: 
> https://bugs.openjdk.java.net/browse/JDK-8225805 <https://bugs.openjdk.java.net/browse/JDK-8225805>
>  
> webrev
> http://cr.openjdk.java.net/~pbansal/8225805/webrev01/ <http://cr.openjdk.java.net/~pbansal/8225805/webrev01/>
>  
>  
> Issue:
> The Windows WindowsAccessBridge Log file is not being closed anywhere. We should always close opened resources.
> It is not causing any issue as all files opened by the program are closed when program exits normally (JAWS in this case). But case be an issue in case the program terminates abnormally. We should explicitly close the log file.
>  
> Fix:
> Closed the WindowsAccessBridge log file in destructor.
>  
> 
> Regards,
> Pankaj Bansal

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

From ambarish.rapte at oracle.com  Tue Sep 10 18:00:11 2019
From: ambarish.rapte at oracle.com (Ambarish Rapte)
Date: Tue, 10 Sep 2019 11:00:11 -0700 (PDT)
Subject: <AWT Dev> [14] RFR : 8226253 : JAWS reports wrong number of radio
 buttons when buttons are hidden.
Message-ID: <7aa0747c-8440-4807-a48d-d68ee326e02c@default>

Hi,

Please review this fix,

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

Webrev: http://cr.openjdk.java.net/~arapte/a11y/8226253/webrev.01/ 

 

Issue:

AccessibleContext.getAccessibleChildrenCount() returns number of all Accessible children, but does not take visibility of a child component in consideration.

 

Fix:

Do not consider children that are not showing when providing accessible children count and when providing an accessible child of the component to screen reader.

This change is needed for both AccessibleContext and AccessibleRelationSet.

The newly added methods do not result in creating the AccessibleContext of children components earlier than before the fix.

The AccessibleContext gets created in AccessibilityEventMonitor.AccessibilityEventListener.installListeners(AccessibleContext) method, which occurs before the newly added methods get executed.

 

Verification:

Tested the fix with JList with a custom AccessibleContext(custom ListModel) to hide non visible components, JRadioButton, JCheckBox, JToggleButton, JRadioButtonMenuItem, JCheckBoxMenuItem, JComboBox and SwingSet2.

Did not find any misbehavior with the fix.

 

 

Some pointers provided by Sergey in offline discussion:

1. Fix the issue on Java Access Bridge side. => http://cr.openjdk.java.net/~arapte/a11y/8226253/webrev.01/

2. Confirm that the fix does not create the AccessibleContext of children earlier than before the fix. => Does not happen

3. Test JList with a custom AccessibleContext. => Tested by adding a custom ListModel to JList. JList.AccessibleJList uses the ListModel for getAccessibleChildrenCount() and getAccessibleChild()

 

 

Regards,

Ambarish
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/awt-dev/attachments/20190910/3476aa1a/attachment.html>

From jayathirth.d.v at oracle.com  Wed Sep 11 06:31:51 2019
From: jayathirth.d.v at oracle.com (Jayathirth Rao)
Date: Wed, 11 Sep 2019 12:01:51 +0530
Subject: <AWT Dev> [14] RFR JDK-8225805 - Java Access Bridge does not
 close the logger
In-Reply-To: <4dc446d8-b8ea-437e-97c8-e4110206b9f0@default>
References: <4dc446d8-b8ea-437e-97c8-e4110206b9f0@default>
Message-ID: <016D246E-3123-4998-ADB2-F46AE38E0785@oracle.com>

Looks like in case of JavaAccessBridge we were closing log file but it was missed for WindowsAccessBridge.
Changes are fine.

Thanks,
Jay 

> On 10-Sep-2019, at 3:36 PM, Pankaj Bansal <pankaj.b.bansal at oracle.com> wrote:
> 
> Hi All,
> 
> Please review the following fix for jdk14.
> 
> Bug: 
> https://bugs.openjdk.java.net/browse/JDK-8225805 <https://bugs.openjdk.java.net/browse/JDK-8225805>
>  
> webrev
> http://cr.openjdk.java.net/~pbansal/8225805/webrev01/ <http://cr.openjdk.java.net/~pbansal/8225805/webrev01/>
>  
>  
> Issue:
> The Windows WindowsAccessBridge Log file is not being closed anywhere. We should always close opened resources.
> It is not causing any issue as all files opened by the program are closed when program exits normally (JAWS in this case). But case be an issue in case the program terminates abnormally. We should explicitly close the log file.
>  
> Fix:
> Closed the WindowsAccessBridge log file in destructor.
>  
> 
> Regards,
> Pankaj Bansal

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

From gnu.andrew at redhat.com  Thu Sep 12 02:11:05 2019
From: gnu.andrew at redhat.com (Andrew John Hughes)
Date: Thu, 12 Sep 2019 03:11:05 +0100
Subject: <AWT Dev> [8u] 8217676: Upgrade libpng to 1.6.37
In-Reply-To: <4a2daffd-c776-25fa-8f08-ac61949f4caa@redhat.com>
References: <bc7785da-e5b2-416c-9e80-4eadcd3a7d59@redhat.com>
 <42cc1803-6f71-ba9d-d262-f79522071f10@redhat.com>
 <ed79b415-4d25-0ff7-265c-6a1441b3a8fd@redhat.com>
 <a88824fb-959a-5c35-b370-2fd3732e47f8@redhat.com>
 <4a2daffd-c776-25fa-8f08-ac61949f4caa@redhat.com>
Message-ID: <d35e2231-6565-d4cf-0b35-2c89a0642265@redhat.com>



On 03/09/2019 15:18, Zhengyu Gu wrote:
> Hi Andrew,
> 
>> The license patch seems to miss some header lines when compared with
>> 11u, and also removes a section about trademarks and export control that
>> isn't altered in the 11u version. How was it applied?
>>
>> I've attached what I get from manually applying the 11u patch to
>> THIRD_PARTY_README. This diffs cleanly against libpng.md in 11u.
>>
> 
> Updated all THIRD_PARTY_README files with your patch.
> 
> http://cr.openjdk.java.net/~zgu/JDK-8217676-8u/v2/
> 
> Retested with jdk_imageio.
> 
> Thanks,
> 
> -Zhengyu
> 
>> Thanks,
>>

Looks good.

As this is one of the fixes we still intend to get into 8u232, please
flag the bug with jdk8u-critical-request and then push to the
https://hg.openjdk.java.net/jdk8u/jdk8u/ family of repos when approved.

Thanks,
-- 
Andrew :)

Senior Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)

PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net)
Fingerprint = 5132 579D D154 0ED2 3E04  C5A0 CFDA 0F9B 3596 4222
https://keybase.io/gnu_andrew

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: OpenPGP digital signature
URL: <https://mail.openjdk.java.net/pipermail/awt-dev/attachments/20190912/de7af72d/signature.asc>

From matthias.baesken at sap.com  Thu Sep 12 09:08:17 2019
From: matthias.baesken at sap.com (Baesken, Matthias)
Date: Thu, 12 Sep 2019 09:08:17 +0000
Subject: <AWT Dev> RFR [XS] : 8230900: missing ReleaseStringUTFChars in
 java.desktop native code
Message-ID: <AM6PR02MB5078CF022D79D59EB3B413AD93B00@AM6PR02MB5078.eurprd02.prod.outlook.com>

Hello, please reviews this small fix .

It adds  a couple of missing ReleaseStringUTFChars  calls  in   java.desktop  module native  coding (mostly in cases of early returns).


Bug/webrev :

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

http://cr.openjdk.java.net/~mbaesken/webrevs/8230900.0/

Thanks, Matthias
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/awt-dev/attachments/20190912/a5f53a10/attachment.html>

From christoph.langer at sap.com  Thu Sep 12 19:28:49 2019
From: christoph.langer at sap.com (Langer, Christoph)
Date: Thu, 12 Sep 2019 19:28:49 +0000
Subject: <AWT Dev> RFR [XS] : 8230900: missing ReleaseStringUTFChars in
 java.desktop native code
In-Reply-To: <AM6PR02MB5078CF022D79D59EB3B413AD93B00@AM6PR02MB5078.eurprd02.prod.outlook.com>
References: <AM6PR02MB5078CF022D79D59EB3B413AD93B00@AM6PR02MB5078.eurprd02.prod.outlook.com>
Message-ID: <AM6PR02MB519251C68BCD7ABC849B74708AB00@AM6PR02MB5192.eurprd02.prod.outlook.com>

Hi Matthias,

the changes seem to make sense.

I've got 2 findings:

In fontpath.c, there is a space between ReleaseStringUTFChars and ( which should be removed in lines 1282 and 1339.

In ShellFolder2.c, line 1134, the function call takes only 2 parameters. You need to remove the first param env. Otherwise it breaks the Windows build.

Thanks
Christoph

From: 2d-dev <2d-dev-bounces at openjdk.java.net> On Behalf Of Baesken, Matthias
Sent: Donnerstag, 12. September 2019 11:08
To: 2d-dev at openjdk.java.net; awt-dev at openjdk.java.net
Subject: [CAUTION] [OpenJDK 2D-Dev] RFR [XS] : 8230900: missing ReleaseStringUTFChars in java.desktop native code

Hello, please reviews this small fix .

It adds  a couple of missing ReleaseStringUTFChars  calls  in   java.desktop  module native  coding (mostly in cases of early returns).


Bug/webrev :

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

http://cr.openjdk.java.net/~mbaesken/webrevs/8230900.0/

Thanks, Matthias
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/awt-dev/attachments/20190912/9b6a7280/attachment.html>

From matthias.baesken at sap.com  Fri Sep 13 06:37:18 2019
From: matthias.baesken at sap.com (Baesken, Matthias)
Date: Fri, 13 Sep 2019 06:37:18 +0000
Subject: <AWT Dev> RFR [XS] : 8230900: missing ReleaseStringUTFChars in
 java.desktop native code
In-Reply-To: <AM6PR02MB519251C68BCD7ABC849B74708AB00@AM6PR02MB5192.eurprd02.prod.outlook.com>
References: <AM6PR02MB5078CF022D79D59EB3B413AD93B00@AM6PR02MB5078.eurprd02.prod.outlook.com>
 <AM6PR02MB519251C68BCD7ABC849B74708AB00@AM6PR02MB5192.eurprd02.prod.outlook.com>
Message-ID: <AM6PR02MB5078A199F7419E7E769ED19C93B30@AM6PR02MB5078.eurprd02.prod.outlook.com>

Hi Christoph,

I removed the  blanks after  ReleaseStringUTFChars  in fontpath.c,   and adjusted the  ReleaseStringUTFChars call to  C++ syntax in ShellFolder2.c.
New webrev :

http://cr.openjdk.java.net/~mbaesken/webrevs/8230900.1/

Best Regards ,
   Matthias


From: Langer, Christoph <christoph.langer at sap.com>
Sent: Donnerstag, 12. September 2019 21:29
To: Baesken, Matthias <matthias.baesken at sap.com>; 2d-dev at openjdk.java.net; awt-dev at openjdk.java.net
Subject: RE: RFR [XS] : 8230900: missing ReleaseStringUTFChars in java.desktop native code

Hi Matthias,

the changes seem to make sense.

I've got 2 findings:

In fontpath.c, there is a space between ReleaseStringUTFChars and ( which should be removed in lines 1282 and 1339.

In ShellFolder2.c, line 1134, the function call takes only 2 parameters. You need to remove the first param env. Otherwise it breaks the Windows build.

Thanks
Christoph

From: 2d-dev <2d-dev-bounces at openjdk.java.net<mailto:2d-dev-bounces at openjdk.java.net>> On Behalf Of Baesken, Matthias
Sent: Donnerstag, 12. September 2019 11:08
To: 2d-dev at openjdk.java.net<mailto:2d-dev at openjdk.java.net>; awt-dev at openjdk.java.net<mailto:awt-dev at openjdk.java.net>
Subject: [CAUTION] [OpenJDK 2D-Dev] RFR [XS] : 8230900: missing ReleaseStringUTFChars in java.desktop native code

Hello, please reviews this small fix .

It adds  a couple of missing ReleaseStringUTFChars  calls  in   java.desktop  module native  coding (mostly in cases of early returns).


Bug/webrev :

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

http://cr.openjdk.java.net/~mbaesken/webrevs/8230900.0/

Thanks, Matthias
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/awt-dev/attachments/20190913/7fc89bde/attachment-0001.html>

From jagjot.singh at oracle.com  Fri Sep 13 10:21:00 2019
From: jagjot.singh at oracle.com (Jagjot Singh)
Date: Fri, 13 Sep 2019 03:21:00 -0700 (PDT)
Subject: <AWT Dev> <Awt Dev> [13] RFR [JDK-8080185][TESTBUG] Test
 instructions need to be updated for test
 java/awt/dnd/DnDFileGroupDescriptor/DnDFileGroupDescriptor
Message-ID: <622ce742-bab8-4f38-bd97-be55227f5ebc@default>

Hi All,

 

Please review a small fix for JDK- 8080185

 

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

 

Webrev:  http://cr.openjdk.java.net/~vagarwal/8080185/webrev.0/

 

Summary: The regression test  java/awt/dnd/DnDFileGroupDescriptor/DnDFileGroupDescriptor needs further addition to the instruction set. The instructions suggests that we need to select an attachment from MS Outlook and drag and drop into the red field of applet . It is not mandatory. We can even drag and drop any file from any location into the red field of applet. File path appears in both cases. Updating the test instructions accordingly.

 

Best Regards,

Jagjot Singh

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

From philip.race at oracle.com  Fri Sep 13 17:44:55 2019
From: philip.race at oracle.com (Philip Race)
Date: Fri, 13 Sep 2019 10:44:55 -0700
Subject: <AWT Dev> [OpenJDK 2D-Dev] RFR [XS] : 8230900: missing
 ReleaseStringUTFChars in java.desktop native code
In-Reply-To: <AM6PR02MB5078A199F7419E7E769ED19C93B30@AM6PR02MB5078.eurprd02.prod.outlook.com>
References: <AM6PR02MB5078CF022D79D59EB3B413AD93B00@AM6PR02MB5078.eurprd02.prod.outlook.com>
 <AM6PR02MB519251C68BCD7ABC849B74708AB00@AM6PR02MB5192.eurprd02.prod.outlook.com>
 <AM6PR02MB5078A199F7419E7E769ED19C93B30@AM6PR02MB5078.eurprd02.prod.outlook.com>
Message-ID: <5D7BD597.5020101@oracle.com>

Looks good.

-phil.

On 9/12/19, 11:37 PM, Baesken, Matthias wrote:
>
> Hi Christoph,
>
> I removed the  blanks after ReleaseStringUTFChars  in fontpath.c,   
> and adjusted the ReleaseStringUTFChars call to  C++ syntax in 
> ShellFolder2.c.
>
> New webrev :
>
> http://cr.openjdk.java.net/~mbaesken/webrevs/8230900.1/ 
> <http://cr.openjdk.java.net/%7Embaesken/webrevs/8230900.1/>
>
> Best Regards ,
>
>    Matthias
>
> *From:*Langer, Christoph <christoph.langer at sap.com>
> *Sent:* Donnerstag, 12. September 2019 21:29
> *To:* Baesken, Matthias <matthias.baesken at sap.com>; 
> 2d-dev at openjdk.java.net; awt-dev at openjdk.java.net
> *Subject:* RE: RFR [XS] : 8230900: missing ReleaseStringUTFChars in 
> java.desktop native code
>
> Hi Matthias,
>
> the changes seem to make sense.
>
> I've got 2 findings:
>
> In fontpath.c, there is a space between ReleaseStringUTFChars and ( 
> which should be removed in lines 1282 and 1339.
>
> In ShellFolder2.c, line 1134, the function call takes only 2 
> parameters. You need to remove the first param env. Otherwise it 
> breaks the Windows build.
>
> Thanks
>
> Christoph
>
> *From:*2d-dev <2d-dev-bounces at openjdk.java.net 
> <mailto:2d-dev-bounces at openjdk.java.net>> *On Behalf Of *Baesken, Matthias
> *Sent:* Donnerstag, 12. September 2019 11:08
> *To:* 2d-dev at openjdk.java.net <mailto:2d-dev at openjdk.java.net>; 
> awt-dev at openjdk.java.net <mailto:awt-dev at openjdk.java.net>
> *Subject:* [CAUTION] [OpenJDK 2D-Dev] RFR [XS] : 8230900: missing 
> ReleaseStringUTFChars in java.desktop native code
>
> Hello, please reviews this small fix .
>
> It adds  a couple of missing ReleaseStringUTFChars  calls  in   
> java.desktop  module native  coding (mostly in cases of early returns).
>
> Bug/webrev :
>
> https://bugs.openjdk.java.net/browse/JDK-8230900
>
> http://cr.openjdk.java.net/~mbaesken/webrevs/8230900.0/ 
> <http://cr.openjdk.java.net/%7Embaesken/webrevs/8230900.0/>
>
> Thanks, Matthias
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/awt-dev/attachments/20190913/8a420c70/attachment.html>

From zgu at redhat.com  Mon Sep 16 18:04:43 2019
From: zgu at redhat.com (Zhengyu Gu)
Date: Mon, 16 Sep 2019 14:04:43 -0400
Subject: <AWT Dev> [8u] RFR: 8196681: Java Access Bridge logging and
 debug flags dynamically controlled
In-Reply-To: <be9f2206-fea1-de32-71d1-6ffc954d3160@redhat.com>
References: <be9f2206-fea1-de32-71d1-6ffc954d3160@redhat.com>
Message-ID: <257397da-ae0c-a0e0-f20f-c3f2094d6c48@redhat.com>

Hi Alex,

On 9/9/19 12:29 PM, Alex Kashchenko wrote:
> Hi,
> 
> Please review the code change required to backport JDK-8196681 to 8u.
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8196681
> 
> Original review thread: 
> http://mail.openjdk.java.net/pipermail/awt-dev/2018-September/014302.html
> 
> 11u changeset: 
> https://hg.openjdk.java.net/jdk-updates/jdk11u-dev/rev/af9ad0ae9039
> 
> Patch does not apply cleanly, because std::chrono is used for 
> timestamps. And this part of C++11 standard is not supported by VS2010 
> toolchain that is used for 8u windows builds. The following change 
> reimplements the same timestamps without std::chrono:
> 
> 
>  ?auto getTimeStamp() -> long long {
> -??? using namespace std::chrono;
> -??? auto timeNow = 
> duration_cast<milliseconds>(steady_clock::now().time_since_epoch());
> -
> -??? return timeNow.count();
> +??? LARGE_INTEGER freqLarge;
> +??? ::QueryPerformanceFrequency(&freqLarge);
> +??? long long freq = freqLarge.QuadPart;
> +??? LARGE_INTEGER counterLarge;
> +??? ::QueryPerformanceCounter(&counterLarge);
> +??? long long counter = counterLarge.QuadPart;
> +??? long long milliDen = 1000;
> +??? long long whole = (counter / freq) * milliDen;
> +??? long long part = (counter % freq) * milliDen / freq;
> +??? return whole + part;
>  ?}
> 
Would this whole + part calculation just (counter * milliDen) / freq? or 
you are worry about overflow?

Otherwise, looks good to me.

Thanks,

-Zhengyu


> 
> Backport also depends on JDK-8077707 and JDK-8132249 (both apply 
> cleanly), "jdk8u-fix-request" label was added for them.
> 
> Backport requires CSR that was filed in JDK-8230699.
> 
> Thanks!
> 

From Sergey.Bylokhov at oracle.com  Mon Sep 16 18:14:03 2019
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Mon, 16 Sep 2019 11:14:03 -0700
Subject: <AWT Dev> <Awt Dev> [13] RFR [JDK-8080185][TESTBUG] Test
 instructions need to be updated for test
 java/awt/dnd/DnDFileGroupDescriptor/DnDFileGroupDescriptor
In-Reply-To: <622ce742-bab8-4f38-bd97-be55227f5ebc@default>
References: <622ce742-bab8-4f38-bd97-be55227f5ebc@default>
Message-ID: <a35eef96-59b2-9eac-808c-12b64ab47e70@oracle.com>

Hi, Jagjot.

Did you check that an initial bug JDK-6242241 can be reproduced by the new instructions?
I assume the fix is for jdk14 not jdk13.

On 9/13/19 3:21 am, Jagjot Singh wrote:
> Hi All,
> 
> Please review a small fix for?JDK-8080185
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8080185
> 
> Webrev:http://cr.openjdk.java.net/~vagarwal/8080185/webrev.0/
> 
> Summary: The regression test ?java/awt/dnd/DnDFileGroupDescriptor/DnDFileGroupDescriptor needs further addition to the instruction set. The instructions suggests that we need to select an attachment from MS Outlook and drag and drop into the red field of applet?. It is not mandatory. We can even drag and drop any file from any location into the red field of applet. File path appears in both cases. Updating the test instructions accordingly.
> 
> Best Regards,
> 
> Jagjot Singh
> 


-- 
Best regards, Sergey.

From Sergey.Bylokhov at oracle.com  Mon Sep 16 18:18:16 2019
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Mon, 16 Sep 2019 11:18:16 -0700
Subject: <AWT Dev> Status of JDK-8016255
In-Reply-To: <e0912682-358a-d59c-dd23-44ff5ab8433d@virtualgl.org>
References: <e0912682-358a-d59c-dd23-44ff5ab8433d@virtualgl.org>
Message-ID: <59dad5da-8b6b-257a-2d09-a1941137a4e7@oracle.com>

Hello, DRC.

It looks like this particular bug is not on the table and nobody working on it right now =(
I encourage the community to participate.

On 9/9/19 7:55 pm, DRC wrote:
> This bug:
> https://bugs.openjdk.java.net/browse/JDK-8016255
> was opened over six years ago and is still listed as "unresolved."  It
> unfortunately affects my product.  Any chance of getting a resolution or
> an update on its status?
> 
> In a nutshell, "dead keys" (accent modifier keys) on certain
> international keyboards are not properly handled in Swing on Un*x
> systems.  Only the key release event from those keys is delivered to
> applications, without a prior key press event.
> 
> DRC
> 


-- 
Best regards, Sergey.

From drc at virtualgl.org  Mon Sep 16 18:36:47 2019
From: drc at virtualgl.org (DRC)
Date: Mon, 16 Sep 2019 13:36:47 -0500
Subject: <AWT Dev> Status of JDK-8016255
In-Reply-To: <59dad5da-8b6b-257a-2d09-a1941137a4e7@oracle.com>
References: <e0912682-358a-d59c-dd23-44ff5ab8433d@virtualgl.org>
 <59dad5da-8b6b-257a-2d09-a1941137a4e7@oracle.com>
Message-ID: <3303e201-9c54-4154-1c5e-f4ac0159c0ff@virtualgl.org>

OK, thanks for the update.  I submitted two related issues for macOS and
Windows.  Java does not correctly handle dead keys on those platforms,
either, but the symptoms are different.  On Windows, Java produces the
incorrect key symbol for dead keys that are activated via a modifier
(Shift, AltGr.)  On macOS, Java produces the incorrect key symbol for
the key release of a dead key (but the key press is usually correct.)

Is it your assertion that these issues will have to be fixed by the
community as well?

On 9/16/19 1:18 PM, Sergey Bylokhov wrote:
> Hello, DRC.
> 
> It looks like this particular bug is not on the table and nobody working
> on it right now =(
> I encourage the community to participate.
> 
> On 9/9/19 7:55 pm, DRC wrote:
>> This bug:
>> https://bugs.openjdk.java.net/browse/JDK-8016255
>> was opened over six years ago and is still listed as "unresolved."? It
>> unfortunately affects my product.? Any chance of getting a resolution or
>> an update on its status?
>>
>> In a nutshell, "dead keys" (accent modifier keys) on certain
>> international keyboards are not properly handled in Swing on Un*x
>> systems.? Only the key release event from those keys is delivered to
>> applications, without a prior key press event.
>>
>> DRC


From alexey.ivanov at oracle.com  Mon Sep 16 19:09:56 2019
From: alexey.ivanov at oracle.com (Alexey Ivanov)
Date: Mon, 16 Sep 2019 20:09:56 +0100
Subject: <AWT Dev> <Swing Dev> [13] Review Request: 8225372
 accessibility errors in tables in java.desktop files
In-Reply-To: <a13a0654-ccf4-790b-d99b-95bbe0f19139@oracle.com>
References: <ebc1fdff-d319-4a43-b1bd-b801136b6227@default>
 <fbd5f3e1-0f13-2a83-d852-d00ca8ccdf08@oracle.com>
 <a13a0654-ccf4-790b-d99b-95bbe0f19139@oracle.com>
Message-ID: <f166df79-63ae-f943-88cd-9c01674bc311@oracle.com>

Hi Sergey,

This version looks good to me.

On 09/09/2019 23:14, Sergey Bylokhov wrote:
> Hi, Alexey.
>
> Thank you for the review, here is an updated version:
> http://cr.openjdk.java.net/~serb/8225372/webrev.03
>
> ?- GridBagLayout.html: The text about "Figures 1 and 2" was changed
> ?- componentProperties.html: The <thead> is added to some of the tables
> ?- Modality.html: The <u> was dropped from everywhere, it does not 
> seems to be useful

I think <u> was used to make a term / concept stand out from its 
definition / description.
Anyway, this can be addressed in a separate issue as I mentioned before.
Let's leave it that way for now.

>
> ?- Modality.html: An example block was reworked as suggested:
> http://cr.openjdk.java.net/~serb/8225372/docs.03/api/java.desktop/java/awt/doc-files/Modality.html
>
> On 9/3/19 10:55 am, Alexey Ivanov wrote:
>> It looks fine to me. And it has more semantic markup.
>> For more visual distinction, we can add style="list-style-type: 
>> circle" to all the nested <ul> elements, or use ?square? type. 
>> Alternatively, it's possible to modify the style of the outer <ul> 
>> element, the nested <ul>'s are still rendered with ?disc? type.
>
> They are the same because of CSS style used by the JavaDoc tool(by 
> default nested ul elements are different from the outer elements), I 
> guess we need to file a bug to restore this appearance(if this change 
> was not intentional).

Yeah, I know.
Javadoc tool likely redefines presentation rules to not depend on 
browser defaults and, therefore, to look consistently across different 
browsers. There could be not many nested lists in Java documentation 
comments, so this style could be accidental.

-- 
Regards,
Alexey

From jagjot.singh at oracle.com  Tue Sep 17 08:13:58 2019
From: jagjot.singh at oracle.com (Jagjot Singh)
Date: Tue, 17 Sep 2019 01:13:58 -0700 (PDT)
Subject: <AWT Dev> <Awt Dev> [13] RFR [JDK-8080185][TESTBUG] Test
 instructions need to be updated for test
 java/awt/dnd/DnDFileGroupDescriptor/DnDFileGroupDescriptor
In-Reply-To: <a35eef96-59b2-9eac-808c-12b64ab47e70@oracle.com>
References: <622ce742-bab8-4f38-bd97-be55227f5ebc@default>
 <a35eef96-59b2-9eac-808c-12b64ab47e70@oracle.com>
Message-ID: <1e7e876f-959f-498e-9b4f-ba3af849a27f@default>

Hi Sergey,

I went through JDK-6242241. The regression test java/awt/dnd/DnDFileGroupDescriptor/DnDFileGroupDescriptor was written to cover the issue encountered in JDK-6242241. Previous version of MS Outlook does not provide DataFlavor.javaFileListFlavor. Starting from MS Outlook Express 6, MS Outlook provides DataFlavor.javaFileListFlavor. Hence, the test was passing and the issue was not reproducible.

Dragging and Dropping a file from any location (e.g. Windows Explorer) apart from MS Outlook was never a problem. Adding them to the instruction set will not lead to the failure of the test.  According to the issue with which the test was written, the current changes proposed to be done in the instruction set may seem inappropriate. But, this issue is no more reproducible with version of Outlook starting from Express 6 and current changes will increase the coverage of the test.  Sergey, what are your thoughts on it?

My bad with the JDK version. The fix is for jdk14 not jdk13.

Best Regards,
Jagjot Singh

-----Original Message-----
From: Sergey Bylokhov 
Sent: Monday, September 16, 2019 11:44 PM
To: Jagjot Singh <jagjot.singh at oracle.com>; awt-dev at openjdk.java.net
Cc: Praveen Mohan <praveen.mohan at oracle.com>; Gauri Patil <gauri.patil at oracle.com>; Praveen Gupta <praveen.p.gupta at oracle.com>
Subject: Re: <AWT Dev> <Awt Dev> [13] RFR [JDK-8080185][TESTBUG] Test instructions need to be updated for test java/awt/dnd/DnDFileGroupDescriptor/DnDFileGroupDescriptor

Hi, Jagjot.

Did you check that an initial bug JDK-6242241 can be reproduced by the new instructions?
I assume the fix is for jdk14 not jdk13.

On 9/13/19 3:21 am, Jagjot Singh wrote:
> Hi All,
> 
> Please review a small fix for?JDK-8080185
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8080185
> 
> Webrev:http://cr.openjdk.java.net/~vagarwal/8080185/webrev.0/
> 
> Summary: The regression test ?java/awt/dnd/DnDFileGroupDescriptor/DnDFileGroupDescriptor needs further addition to the instruction set. The instructions suggests that we need to select an attachment from MS Outlook and drag and drop into the red field of applet?. It is not mandatory. We can even drag and drop any file from any location into the red field of applet. File path appears in both cases. Updating the test instructions accordingly.
> 
> Best Regards,
> 
> Jagjot Singh
> 


-- 
Best regards, Sergey.

From akashche at redhat.com  Tue Sep 17 09:41:13 2019
From: akashche at redhat.com (Alex Kashchenko)
Date: Tue, 17 Sep 2019 10:41:13 +0100
Subject: <AWT Dev> [8u] RFR: 8196681: Java Access Bridge logging and
 debug flags dynamically controlled
In-Reply-To: <257397da-ae0c-a0e0-f20f-c3f2094d6c48@redhat.com>
References: <be9f2206-fea1-de32-71d1-6ffc954d3160@redhat.com>
 <257397da-ae0c-a0e0-f20f-c3f2094d6c48@redhat.com>
Message-ID: <e9066d6c-b665-1976-9a28-a6dacc3b9edb@redhat.com>

Hi Zhengyu,

On 09/16/2019 07:04 PM, Zhengyu Gu wrote:
> Hi Alex,
> 
> On 9/9/19 12:29 PM, Alex Kashchenko wrote:
>> Hi,
>>
>> Please review the code change required to backport JDK-8196681 to 8u.
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8196681
>>
>> Original review thread: 
>> http://mail.openjdk.java.net/pipermail/awt-dev/2018-September/014302.html
>>
>> 11u changeset: 
>> https://hg.openjdk.java.net/jdk-updates/jdk11u-dev/rev/af9ad0ae9039
>>
>> Patch does not apply cleanly, because std::chrono is used for 
>> timestamps. And this part of C++11 standard is not supported by VS2010 
>> toolchain that is used for 8u windows builds. The following change 
>> reimplements the same timestamps without std::chrono:
>>
>>
>> ??auto getTimeStamp() -> long long {
>> -??? using namespace std::chrono;
>> -??? auto timeNow = 
>> duration_cast<milliseconds>(steady_clock::now().time_since_epoch());
>> -
>> -??? return timeNow.count();
>> +??? LARGE_INTEGER freqLarge;
>> +??? ::QueryPerformanceFrequency(&freqLarge);
>> +??? long long freq = freqLarge.QuadPart;
>> +??? LARGE_INTEGER counterLarge;
>> +??? ::QueryPerformanceCounter(&counterLarge);
>> +??? long long counter = counterLarge.QuadPart;
>> +??? long long milliDen = 1000;
>> +??? long long whole = (counter / freq) * milliDen;
>> +??? long long part = (counter % freq) * milliDen / freq;
>> +??? return whole + part;
>> ??}
>>
> Would this whole + part calculation just (counter * milliDen) / freq? or 
> you are worry about overflow?
> 
> Otherwise, looks good to me.

Thanks for the review!

Yes, overflow here doesn't matter for milliseconds, but will happen if 
nanoseconds are used.

> 
> [...]
> 


-- 
-Alex

From zgu at redhat.com  Tue Sep 17 13:40:00 2019
From: zgu at redhat.com (Zhengyu Gu)
Date: Tue, 17 Sep 2019 09:40:00 -0400
Subject: <AWT Dev> [8u] RFR: 8196681: Java Access Bridge logging and
 debug flags dynamically controlled
In-Reply-To: <e9066d6c-b665-1976-9a28-a6dacc3b9edb@redhat.com>
References: <be9f2206-fea1-de32-71d1-6ffc954d3160@redhat.com>
 <257397da-ae0c-a0e0-f20f-c3f2094d6c48@redhat.com>
 <e9066d6c-b665-1976-9a28-a6dacc3b9edb@redhat.com>
Message-ID: <6364845a-a48e-c96a-7a9b-5a9edc9413d8@redhat.com>



On 9/17/19 5:41 AM, Alex Kashchenko wrote:
> Hi Zhengyu,
> 
> On 09/16/2019 07:04 PM, Zhengyu Gu wrote:
>> Hi Alex,
>>
>> On 9/9/19 12:29 PM, Alex Kashchenko wrote:
>>> Hi,
>>>
>>> Please review the code change required to backport JDK-8196681 to 8u.
>>>
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8196681
>>>
>>> Original review thread: 
>>> http://mail.openjdk.java.net/pipermail/awt-dev/2018-September/014302.html 
>>>
>>>
>>> 11u changeset: 
>>> https://hg.openjdk.java.net/jdk-updates/jdk11u-dev/rev/af9ad0ae9039
>>>
>>> Patch does not apply cleanly, because std::chrono is used for 
>>> timestamps. And this part of C++11 standard is not supported by 
>>> VS2010 toolchain that is used for 8u windows builds. The following 
>>> change reimplements the same timestamps without std::chrono:
>>>
>>>
>>> ??auto getTimeStamp() -> long long {
>>> -??? using namespace std::chrono;
>>> -??? auto timeNow = 
>>> duration_cast<milliseconds>(steady_clock::now().time_since_epoch());
>>> -
>>> -??? return timeNow.count();
>>> +??? LARGE_INTEGER freqLarge;
>>> +??? ::QueryPerformanceFrequency(&freqLarge);
>>> +??? long long freq = freqLarge.QuadPart;
>>> +??? LARGE_INTEGER counterLarge;
>>> +??? ::QueryPerformanceCounter(&counterLarge);
>>> +??? long long counter = counterLarge.QuadPart;
>>> +??? long long milliDen = 1000;
>>> +??? long long whole = (counter / freq) * milliDen;
>>> +??? long long part = (counter % freq) * milliDen / freq;
>>> +??? return whole + part;
>>> ??}
>>>
>> Would this whole + part calculation just (counter * milliDen) / freq? 
>> or you are worry about overflow?
>>
>> Otherwise, looks good to me.
> 
> Thanks for the review!
> 
> Yes, overflow here doesn't matter for milliseconds, but will happen if 
> nanoseconds are used.
Okay, a comment will be good.

Thanks,

-Zhengyu

> 
>>
>> [...]
>>
> 
> 

From akashche at redhat.com  Tue Sep 17 15:14:19 2019
From: akashche at redhat.com (Alex Kashchenko)
Date: Tue, 17 Sep 2019 16:14:19 +0100
Subject: <AWT Dev> [8u] RFR: 8196681: Java Access Bridge logging and
 debug flags dynamically controlled
In-Reply-To: <6364845a-a48e-c96a-7a9b-5a9edc9413d8@redhat.com>
References: <be9f2206-fea1-de32-71d1-6ffc954d3160@redhat.com>
 <257397da-ae0c-a0e0-f20f-c3f2094d6c48@redhat.com>
 <e9066d6c-b665-1976-9a28-a6dacc3b9edb@redhat.com>
 <6364845a-a48e-c96a-7a9b-5a9edc9413d8@redhat.com>
Message-ID: <f02ab2ab-7286-361b-0772-9425fa9b4ce7@redhat.com>

On 9/17/19 2:40 PM, Zhengyu Gu wrote:
> 
> 
> On 9/17/19 5:41 AM, Alex Kashchenko wrote:
>> Hi Zhengyu,
>>
>> On 09/16/2019 07:04 PM, Zhengyu Gu wrote:
>>> Hi Alex,
>>>
>>> On 9/9/19 12:29 PM, Alex Kashchenko wrote:
>>>> Hi,
>>>>
>>>> Please review the code change required to backport JDK-8196681 to 8u.
>>>>
>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8196681
>>>>
>>>> Original review thread: 
>>>> http://mail.openjdk.java.net/pipermail/awt-dev/2018-September/014302.html 
>>>>
>>>>
>>>> 11u changeset: 
>>>> https://hg.openjdk.java.net/jdk-updates/jdk11u-dev/rev/af9ad0ae9039
>>>>
>>>> Patch does not apply cleanly, because std::chrono is used for 
>>>> timestamps. And this part of C++11 standard is not supported by 
>>>> VS2010 toolchain that is used for 8u windows builds. The following 
>>>> change reimplements the same timestamps without std::chrono:
>>>>
>>>>
>>>> ??auto getTimeStamp() -> long long {
>>>> -??? using namespace std::chrono;
>>>> -??? auto timeNow = 
>>>> duration_cast<milliseconds>(steady_clock::now().time_since_epoch());
>>>> -
>>>> -??? return timeNow.count();
>>>> +??? LARGE_INTEGER freqLarge;
>>>> +??? ::QueryPerformanceFrequency(&freqLarge);
>>>> +??? long long freq = freqLarge.QuadPart;
>>>> +??? LARGE_INTEGER counterLarge;
>>>> +??? ::QueryPerformanceCounter(&counterLarge);
>>>> +??? long long counter = counterLarge.QuadPart;
>>>> +??? long long milliDen = 1000;
>>>> +??? long long whole = (counter / freq) * milliDen;
>>>> +??? long long part = (counter % freq) * milliDen / freq;
>>>> +??? return whole + part;
>>>> ??}
>>>>
>>> Would this whole + part calculation just (counter * milliDen) / freq? 
>>> or you are worry about overflow?
>>>
>>> Otherwise, looks good to me.
>>
>> Thanks for the review!
>>
>> Yes, overflow here doesn't matter for milliseconds, but will happen if 
>> nanoseconds are used.
> Okay, a comment will be good.

Added a comment:

+    // prevent possible overflow
+    long long whole = (counter / freq) * milliDen;
+    long long part = (counter % freq) * milliDen / freq;
+    return whole + part;

Full webrev just for the record: 
http://cr.openjdk.java.net/~akasko/jdk8u/8196681/webrev.01/

All other changes to original patch, besides 
AccessBridgeDebug#getTimeStamp() above, are either path changes or 
string literal changes in debug messages.

> 
> [...]
> 


-- 
-Alex

From zgu at redhat.com  Tue Sep 17 16:05:06 2019
From: zgu at redhat.com (Zhengyu Gu)
Date: Tue, 17 Sep 2019 12:05:06 -0400
Subject: <AWT Dev> [8u] RFR: 8196681: Java Access Bridge logging and
 debug flags dynamically controlled
In-Reply-To: <f02ab2ab-7286-361b-0772-9425fa9b4ce7@redhat.com>
References: <be9f2206-fea1-de32-71d1-6ffc954d3160@redhat.com>
 <257397da-ae0c-a0e0-f20f-c3f2094d6c48@redhat.com>
 <e9066d6c-b665-1976-9a28-a6dacc3b9edb@redhat.com>
 <6364845a-a48e-c96a-7a9b-5a9edc9413d8@redhat.com>
 <f02ab2ab-7286-361b-0772-9425fa9b4ce7@redhat.com>
Message-ID: <18257e04-a41c-a551-f2a4-51863eaa2427@redhat.com>

>>>>>
>>>> Would this whole + part calculation just (counter * milliDen) / 
>>>> freq? or you are worry about overflow?
>>>>
>>>> Otherwise, looks good to me.
>>>
>>> Thanks for the review!
>>>
>>> Yes, overflow here doesn't matter for milliseconds, but will happen 
>>> if nanoseconds are used.
>> Okay, a comment will be good.
> 
> Added a comment:
> 
> +??? // prevent possible overflow
> +??? long long whole = (counter / freq) * milliDen;
> +??? long long part = (counter % freq) * milliDen / freq;
> +??? return whole + part;
> 
> Full webrev just for the record: 
> http://cr.openjdk.java.net/~akasko/jdk8u/8196681/webrev.01/
> 
> All other changes to original patch, besides 
> AccessBridgeDebug#getTimeStamp() above, are either path changes or 
> string literal changes in debug messages.

Looks good.

Thanks,

-Zhengyu

> 
>>
>> [...]
>>
> 
> 

From alexey.ivanov at oracle.com  Wed Sep 18 17:52:45 2019
From: alexey.ivanov at oracle.com (Alexey Ivanov)
Date: Wed, 18 Sep 2019 18:52:45 +0100
Subject: <AWT Dev> <Swing Dev> [13] Review Request: 8225372
 accessibility errors in tables in java.desktop files
In-Reply-To: <f166df79-63ae-f943-88cd-9c01674bc311@oracle.com>
References: <ebc1fdff-d319-4a43-b1bd-b801136b6227@default>
 <fbd5f3e1-0f13-2a83-d852-d00ca8ccdf08@oracle.com>
 <a13a0654-ccf4-790b-d99b-95bbe0f19139@oracle.com>
 <f166df79-63ae-f943-88cd-9c01674bc311@oracle.com>
Message-ID: <b31f810f-adec-2339-c9bd-6aff831ac2dc@oracle.com>

On 16/09/2019 20:09, Alexey Ivanov wrote:
> Hi Sergey,
>
> This version looks good to me.
>
> On 09/09/2019 23:14, Sergey Bylokhov wrote:
>> Hi, Alexey.
>>
>> <SNIP>
>> ?- Modality.html: The <u> was dropped from everywhere, it does not 
>> seems to be useful
>
> I think <u> was used to make a term / concept stand out from its 
> definition / description.
> Anyway, this can be addressed in a separate issue as I mentioned before.
> Let's leave it that way for now.
I've submitted
https://bugs.openjdk.java.net/browse/JDK-8231128
Cleanup usage of <u> in java.desktop files
-- 
Regards,
Alexey

From dmitry.markov at oracle.com  Thu Sep 19 16:12:24 2019
From: dmitry.markov at oracle.com (Dmitry Markov)
Date: Thu, 19 Sep 2019 17:12:24 +0100
Subject: <AWT Dev> =?utf-8?q?_=5B14=5D_RFR_8230782=3A_Robot=2EcreateScreen?=
 =?utf-8?b?Q2FwdHVyZSgpIGZhaWxzIGlmIOKAnGF3dC5yb2JvdC5ndGvigJ0gaXMgc2V0?=
 =?utf-8?q?_to_false?=
Message-ID: <57F73381-FB1A-4347-9D10-DAB692DB40C9@oracle.com>

Hello,

Could you review a fix for jdk14, please?

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

Problem description:
After integration of JDK-8210776 [1] we started to use malloc() function for allocation of XColor array in QueryColorMap() (see multiVis.c). However malloc() does not initialise allocated memory. So if the memory contains some ?garbage? we may get incorrect data inside the array. As a result Robot.createsScreenCapture() retrieves incorrect colours.

Fix:
It is necessary to invoke calloc() for allocation of the array as it used to be before XWD upgrade

Thanks,
Dmitry

[1] - https://bugs.openjdk.java.net/browse/JDK-8210776
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/awt-dev/attachments/20190919/d5e0c7b5/attachment.html>

From philip.race at oracle.com  Thu Sep 19 16:58:39 2019
From: philip.race at oracle.com (Phil Race)
Date: Thu, 19 Sep 2019 09:58:39 -0700
Subject: <AWT Dev>
 =?utf-8?q?=5B14=5D_RFR_8230782=3A_Robot=2EcreateScreenC?=
 =?utf-8?b?YXB0dXJlKCkgZmFpbHMgaWYg4oCcYXd0LnJvYm90Lmd0a+KAnSBpcyBzZXQg?=
 =?utf-8?q?to_false?=
In-Reply-To: <57F73381-FB1A-4347-9D10-DAB692DB40C9@oracle.com>
References: <57F73381-FB1A-4347-9D10-DAB692DB40C9@oracle.com>
Message-ID: <97b893fe-4a8f-17e3-b602-59c189cb0645@oracle.com>


+1 to the fix but any ideas for a regression test.
There are no related keywords on the bug ..

-phil.


On 9/19/19 9:12 AM, Dmitry Markov wrote:
> Hello,
>
> Could you review a fix for jdk14, please?
>
> ?bug: https://bugs.openjdk.java.net/browse/JDK-8230782
> ?webrev: http://cr.openjdk.java.net/~dmarkov/8230782/webrev.00/
>
> Problem description:
> After integration of JDK-8210776 [1] we started to use malloc() 
> function for allocation of XColor array in QueryColorMap() (see 
> multiVis.c). However malloc() does not initialise allocated memory. So 
> if the memory contains some ?garbage? we may get incorrect data inside 
> the array. As a result Robot.createsScreenCapture() retrieves 
> incorrect colours.
>
> Fix:
> It is necessary to invoke calloc() for allocation of the array as it 
> used to be before XWD upgrade
>
> Thanks,
> Dmitry
>
> [1] - https://bugs.openjdk.java.net/browse/JDK-8210776

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

From dmitry.markov at oracle.com  Thu Sep 19 18:25:16 2019
From: dmitry.markov at oracle.com (Dmitry Markov)
Date: Thu, 19 Sep 2019 19:25:16 +0100
Subject: <AWT Dev>
 =?utf-8?q?=5B14=5D_RFR_8230782=3A_Robot=2EcreateScreenC?=
 =?utf-8?b?YXB0dXJlKCkgZmFpbHMgaWYg4oCcYXd0LnJvYm90Lmd0a+KAnSBpcyBzZXQg?=
 =?utf-8?q?to_false?=
In-Reply-To: <97b893fe-4a8f-17e3-b602-59c189cb0645@oracle.com>
References: <57F73381-FB1A-4347-9D10-DAB692DB40C9@oracle.com>
 <97b893fe-4a8f-17e3-b602-59c189cb0645@oracle.com>
Message-ID: <551D91A8-DE2F-41E1-A094-69DEB721733D@oracle.com>

Thank you for the review, Phil!
I am afraid we cannot create a regression test for this since the issue takes place only in VNC environment. I have added ?noreg-hard? to the bug.

Thanks,
Dmitry

> On 19 Sep 2019, at 17:58, Phil Race <philip.race at oracle.com> wrote:
> 
> 
> +1 to the fix but any ideas for a regression test.
> There are no related keywords on the bug ..
> 
> -phil.
> 
> 
> On 9/19/19 9:12 AM, Dmitry Markov wrote:
>> Hello,
>> 
>> Could you review a fix for jdk14, please?
>> 
>>  bug: https://bugs.openjdk.java.net/browse/JDK-8230782 <https://bugs.openjdk.java.net/browse/JDK-8230782>
>>  webrev: http://cr.openjdk.java.net/~dmarkov/8230782/webrev.00/ <http://cr.openjdk.java.net/~dmarkov/8230782/webrev.00/>
>> 
>> Problem description:
>> After integration of JDK-8210776 [1] we started to use malloc() function for allocation of XColor array in QueryColorMap() (see multiVis.c). However malloc() does not initialise allocated memory. So if the memory contains some ?garbage? we may get incorrect data inside the array. As a result Robot.createsScreenCapture() retrieves incorrect colours.
>> 
>> Fix:
>> It is necessary to invoke calloc() for allocation of the array as it used to be before XWD upgrade
>> 
>> Thanks,
>> Dmitry
>> 
>> [1] - https://bugs.openjdk.java.net/browse/JDK-8210776 <https://bugs.openjdk.java.net/browse/JDK-8210776>

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

From Sergey.Bylokhov at oracle.com  Thu Sep 19 19:26:20 2019
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Thu, 19 Sep 2019 12:26:20 -0700
Subject: <AWT Dev>
 =?utf-8?q?=5B14=5D_RFR_8230782=3A_Robot=2EcreateScreenC?=
 =?utf-8?b?YXB0dXJlKCkgZmFpbHMgaWYg4oCcYXd0LnJvYm90Lmd0a+KAnSBpcyBzZXQg?=
 =?utf-8?q?to_false?=
In-Reply-To: <551D91A8-DE2F-41E1-A094-69DEB721733D@oracle.com>
References: <57F73381-FB1A-4347-9D10-DAB692DB40C9@oracle.com>
 <97b893fe-4a8f-17e3-b602-59c189cb0645@oracle.com>
 <551D91A8-DE2F-41E1-A094-69DEB721733D@oracle.com>
Message-ID: <9000242d-699e-ef30-f259-983b34ebb206@oracle.com>

Hi, Dmitry.

It is interesting that previously this bug was fixed loooong time ago:
https://bugs.openjdk.java.net/browse/JDK-4392080

Looks like the evaluation of that bug is the same as the current one, right?

Can we report this bug upstream, and provide the patch with a proper description of the bug?


On 9/19/19 11:25 am, Dmitry Markov wrote:
> Thank you for the review, Phil!
> I am afraid we cannot create a regression test for this since the issue takes place only in VNC environment. I have added ?noreg-hard? to the bug.
> 
> Thanks,
> Dmitry
> 
>> On 19 Sep 2019, at 17:58, Phil Race <philip.race at oracle.com <mailto:philip.race at oracle.com>> wrote:
>>
>>
>> +1 to the fix but any ideas for a regression test.
>> There are no related keywords on the bug ..
>>
>> -phil.
>>
>>
>> On 9/19/19 9:12 AM, Dmitry Markov wrote:
>>> Hello,
>>>
>>> Could you review a fix for jdk14, please?
>>>
>>> ?bug: https://bugs.openjdk.java.net/browse/JDK-8230782
>>> ?webrev: http://cr.openjdk.java.net/~dmarkov/8230782/webrev.00/
>>>
>>> Problem description:
>>> After integration of JDK-8210776 [1] we started to use malloc() function for allocation of XColor array in QueryColorMap() (see multiVis.c). However malloc() does not initialise allocated memory. So if the memory contains some ?garbage? we may get incorrect data inside the array. As a result Robot.createsScreenCapture() retrieves incorrect colours.
>>>
>>> Fix:
>>> It is necessary to invoke calloc() for allocation of the array as it used to be before XWD upgrade
>>>
>>> Thanks,
>>> Dmitry
>>>
>>> [1] - https://bugs.openjdk.java.net/browse/JDK-8210776
>>
> 


-- 
Best regards, Sergey.

From dmitry.markov at oracle.com  Fri Sep 20 10:54:13 2019
From: dmitry.markov at oracle.com (Dmitry Markov)
Date: Fri, 20 Sep 2019 11:54:13 +0100
Subject: <AWT Dev>
 =?utf-8?q?=5B14=5D_RFR_8230782=3A_Robot=2EcreateScreenC?=
 =?utf-8?b?YXB0dXJlKCkgZmFpbHMgaWYg4oCcYXd0LnJvYm90Lmd0a+KAnSBpcyBzZXQg?=
 =?utf-8?q?to_false?=
In-Reply-To: <9000242d-699e-ef30-f259-983b34ebb206@oracle.com>
References: <57F73381-FB1A-4347-9D10-DAB692DB40C9@oracle.com>
 <97b893fe-4a8f-17e3-b602-59c189cb0645@oracle.com>
 <551D91A8-DE2F-41E1-A094-69DEB721733D@oracle.com>
 <9000242d-699e-ef30-f259-983b34ebb206@oracle.com>
Message-ID: <84FE05FC-5491-4CE0-B6F5-5A93A6C44E17@oracle.com>

Hi Sergey,

That?s right, this one and JDK-4392080 are devoted to the same problem. I have opened the bug against ?xorg.app.xwd? - https://gitlab.freedesktop.org/xorg/app/xwd/issues/3 <https://gitlab.freedesktop.org/xorg/app/xwd/issues/3>

Thanks,
Dmitry

> On 19 Sep 2019, at 20:26, Sergey Bylokhov <Sergey.Bylokhov at oracle.com> wrote:
> 
> Hi, Dmitry.
> 
> It is interesting that previously this bug was fixed loooong time ago:
> https://bugs.openjdk.java.net/browse/JDK-4392080 <https://bugs.openjdk.java.net/browse/JDK-4392080>
> 
> Looks like the evaluation of that bug is the same as the current one, right?
> 
> Can we report this bug upstream, and provide the patch with a proper description of the bug?
> 
> 
> On 9/19/19 11:25 am, Dmitry Markov wrote:
>> Thank you for the review, Phil!
>> I am afraid we cannot create a regression test for this since the issue takes place only in VNC environment. I have added ?noreg-hard? to the bug.
>> Thanks,
>> Dmitry
>>> On 19 Sep 2019, at 17:58, Phil Race <philip.race at oracle.com <mailto:philip.race at oracle.com> <mailto:philip.race at oracle.com <mailto:philip.race at oracle.com>>> wrote:
>>> 
>>> 
>>> +1 to the fix but any ideas for a regression test.
>>> There are no related keywords on the bug ..
>>> 
>>> -phil.
>>> 
>>> 
>>> On 9/19/19 9:12 AM, Dmitry Markov wrote:
>>>> Hello,
>>>> 
>>>> Could you review a fix for jdk14, please?
>>>> 
>>>>  bug: https://bugs.openjdk.java.net/browse/JDK-8230782
>>>>  webrev: http://cr.openjdk.java.net/~dmarkov/8230782/webrev.00/
>>>> 
>>>> Problem description:
>>>> After integration of JDK-8210776 [1] we started to use malloc() function for allocation of XColor array in QueryColorMap() (see multiVis.c). However malloc() does not initialise allocated memory. So if the memory contains some ?garbage? we may get incorrect data inside the array. As a result Robot.createsScreenCapture() retrieves incorrect colours.
>>>> 
>>>> Fix:
>>>> It is necessary to invoke calloc() for allocation of the array as it used to be before XWD upgrade
>>>> 
>>>> Thanks,
>>>> Dmitry
>>>> 
>>>> [1] - https://bugs.openjdk.java.net/browse/JDK-8210776
>>> 
> 
> 
> -- 
> Best regards, Sergey.

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

From Sergey.Bylokhov at oracle.com  Sat Sep 21 18:38:16 2019
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Sat, 21 Sep 2019 11:38:16 -0700
Subject: <AWT Dev>
 =?utf-8?q?=5B14=5D_RFR_8230782=3A_Robot=2EcreateScreenC?=
 =?utf-8?b?YXB0dXJlKCkgZmFpbHMgaWYg4oCcYXd0LnJvYm90Lmd0a+KAnSBpcyBzZXQg?=
 =?utf-8?q?to_false?=
In-Reply-To: <84FE05FC-5491-4CE0-B6F5-5A93A6C44E17@oracle.com>
References: <57F73381-FB1A-4347-9D10-DAB692DB40C9@oracle.com>
 <97b893fe-4a8f-17e3-b602-59c189cb0645@oracle.com>
 <551D91A8-DE2F-41E1-A094-69DEB721733D@oracle.com>
 <9000242d-699e-ef30-f259-983b34ebb206@oracle.com>
 <84FE05FC-5491-4CE0-B6F5-5A93A6C44E17@oracle.com>
Message-ID: <1d618263-fcaa-04a0-2fad-c399e668ccd7@oracle.com>

On 9/20/19 3:54 am, Dmitry Markov wrote:
> Hi Sergey,
> 
> That?s right, this one and JDK-4392080 are devoted to the same problem. I have opened the bug against ?xorg.app.xwd? - https://gitlab.freedesktop.org/xorg/app/xwd/issues/3

Thank you, looks fine.

> 
> Thanks,
> Dmitry
> 
>> On 19 Sep 2019, at 20:26, Sergey Bylokhov <Sergey.Bylokhov at oracle.com <mailto:Sergey.Bylokhov at oracle.com>> wrote:
>>
>> Hi, Dmitry.
>>
>> It is interesting that previously this bug was fixed loooong time ago:
>> https://bugs.openjdk.java.net/browse/JDK-4392080
>>
>> Looks like the evaluation of that bug is the same as the current one, right?
>>
>> Can we report this bug upstream, and provide the patch with a proper description of the bug?
>>
>>
>> On 9/19/19 11:25 am, Dmitry Markov wrote:
>>> Thank you for the review, Phil!
>>> I am afraid we cannot create a regression test for this since the issue takes place only in VNC environment. I have added ?noreg-hard? to the bug.
>>> Thanks,
>>> Dmitry
>>>> On 19 Sep 2019, at 17:58, Phil Race <philip.race at oracle.com <mailto:philip.race at oracle.com><mailto:philip.race at oracle.com>> wrote:
>>>>
>>>>
>>>> +1 to the fix but any ideas for a regression test.
>>>> There are no related keywords on the bug ..
>>>>
>>>> -phil.
>>>>
>>>>
>>>> On 9/19/19 9:12 AM, Dmitry Markov wrote:
>>>>> Hello,
>>>>>
>>>>> Could you review a fix for jdk14, please?
>>>>>
>>>>> ?bug: https://bugs.openjdk.java.net/browse/JDK-8230782
>>>>> ?webrev: http://cr.openjdk.java.net/~dmarkov/8230782/webrev.00/
>>>>>
>>>>> Problem description:
>>>>> After integration of JDK-8210776 [1] we started to use malloc() function for allocation of XColor array in QueryColorMap() (see multiVis.c). However malloc() does not initialise allocated memory. So if the memory contains some ?garbage? we may get incorrect data inside the array. As a result Robot.createsScreenCapture() retrieves incorrect colours.
>>>>>
>>>>> Fix:
>>>>> It is necessary to invoke calloc() for allocation of the array as it used to be before XWD upgrade
>>>>>
>>>>> Thanks,
>>>>> Dmitry
>>>>>
>>>>> [1] - https://bugs.openjdk.java.net/browse/JDK-8210776
>>>>
>>
>>
>> --
>> Best regards, Sergey.
> 


-- 
Best regards, Sergey.

From Sergey.Bylokhov at oracle.com  Sat Sep 21 18:42:23 2019
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Sat, 21 Sep 2019 11:42:23 -0700
Subject: <AWT Dev> Status of JDK-8016255
In-Reply-To: <3303e201-9c54-4154-1c5e-f4ac0159c0ff@virtualgl.org>
References: <e0912682-358a-d59c-dd23-44ff5ab8433d@virtualgl.org>
 <59dad5da-8b6b-257a-2d09-a1941137a4e7@oracle.com>
 <3303e201-9c54-4154-1c5e-f4ac0159c0ff@virtualgl.org>
Message-ID: <6be868f2-74b8-f0ca-6b7f-e53a7b703d02@oracle.com>

On 9/16/19 11:36 am, DRC wrote:
> OK, thanks for the update.  I submitted two related issues for macOS and
> Windows.  Java does not correctly handle dead keys on those platforms,
> either, but the symptoms are different.  On Windows, Java produces the
> incorrect key symbol for dead keys that are activated via a modifier
> (Shift, AltGr.)  On macOS, Java produces the incorrect key symbol for
> the key release of a dead key (but the key press is usually correct.)

Thank you, for these reports.

> Is it your assertion that these issues will have to be fixed by the
> community as well?

Not "have to", but since currently, nobody works on these issues, someone
can step in and propose a patch.

> 
> On 9/16/19 1:18 PM, Sergey Bylokhov wrote:
>> Hello, DRC.
>>
>> It looks like this particular bug is not on the table and nobody working
>> on it right now =(
>> I encourage the community to participate.
>>
>> On 9/9/19 7:55 pm, DRC wrote:
>>> This bug:
>>> https://bugs.openjdk.java.net/browse/JDK-8016255
>>> was opened over six years ago and is still listed as "unresolved."? It
>>> unfortunately affects my product.? Any chance of getting a resolution or
>>> an update on its status?
>>>
>>> In a nutshell, "dead keys" (accent modifier keys) on certain
>>> international keyboards are not properly handled in Swing on Un*x
>>> systems.? Only the key release event from those keys is delivered to
>>> applications, without a prior key press event.
>>>
>>> DRC
> 


-- 
Best regards, Sergey.

From joe.darcy at oracle.com  Sat Sep 21 19:48:18 2019
From: joe.darcy at oracle.com (Joe Darcy)
Date: Sat, 21 Sep 2019 12:48:18 -0700
Subject: <AWT Dev> JDK 14 RFR of JDK-8231334: Suppress warnings on
 non-serializable instance fields in client libs serializable classes
Message-ID: <ed084e59-bebd-714e-d8af-893115f0e6b3@oracle.com>

Hello,

Quick background, I'm working on expanding the compile-time 
serialization checks of javac's -Xlint:serial option. Ahead of that work 
going back, I'm analyzing the JDK sources and plan to pre-suppress the 
coming-soon new warnings, fixing or at least filing follow-up bugs for 
any problems that are found. Corresponding suppression bugs are already 
out for review against core libs (JDK-8231202) and security libs 
(JDK-8231262).

The new check in development is if a serializable class has an instance 
field that is not declared to be a serializable type. This might 
actually be fine in practice, such as if the field in question always 
points to a serializable object at runtime, but it is arguably worth 
noting as an item of potential concern. This check is skipped if the 
class using the serialPersistentFields mechanism.

For the client libs, the webrev with the new @SuppressedWarnings 
annotations is:

 ??? JDK-8231334: Suppress warnings on non-serializable instance fields 
in client libs serializable classes
 ??? http://cr.openjdk.java.net/~darcy/8231334.0/

The changes are mostly in awt, but also some in beans, a few in 
printing, and one in sound.

As discussed with Phil off-line, the new checks also found an existing 
known issue, the auxiliary class java.awt.ImageMediaEntry declared in 
MediaTracker.java is not serializable/deserializable in practice 
(JDK-4397681).

Thanks,

-Joe

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

From philip.race at oracle.com  Sun Sep 22 20:25:21 2019
From: philip.race at oracle.com (Philip Race)
Date: Sun, 22 Sep 2019 13:25:21 -0700
Subject: <AWT Dev> <Beans Dev> JDK 14 RFR of JDK-8231334: Suppress
 warnings on non-serializable instance fields in client libs serializable
 classes
In-Reply-To: <ed084e59-bebd-714e-d8af-893115f0e6b3@oracle.com>
References: <ed084e59-bebd-714e-d8af-893115f0e6b3@oracle.com>
Message-ID: <5D87D8B1.2070708@oracle.com>


+        @SuppressWarnings("serial") // Not statically typed as Serializable

So is the comment being used to distinguish this overloading of what "serial" means ?
Why not introduce a new warning category ?

Randomly looking at
====
src/java.desktop/share/classes/java/awt/Container.java

@@ -3849,10 +3849,11 @@

          /**
           * The handler to fire {@code PropertyChange}
           * when children are added or removed
           */
+        @SuppressWarnings("serial") // Not statically typed as Serializable
          protected ContainerListener accessibleContainerHandler = null;
===

I see that Container has a writeObject method which doesn't write this 
field, so it is effectively transient.

I recognise that it is difficult for the compiler to figure this out, so 
perhaps there should just be a policy
not to check classes that have writeObject methods ?

Also in such a case, would it be an effectively compatible change to add 
transient to the field, so that
it presumably would no longer need this warning.

I haven't looked but presumably there could be other such cases.

Will you be filing bugs for all the fixable cases ?

-phil

On 9/21/19, 12:48 PM, Joe Darcy wrote:
>
> Hello,
>
> Quick background, I'm working on expanding the compile-time 
> serialization checks of javac's -Xlint:serial option. Ahead of that 
> work going back, I'm analyzing the JDK sources and plan to 
> pre-suppress the coming-soon new warnings, fixing or at least filing 
> follow-up bugs for any problems that are found. Corresponding 
> suppression bugs are already out for review against core libs 
> (JDK-8231202) and security libs (JDK-8231262).
>
> The new check in development is if a serializable class has an 
> instance field that is not declared to be a serializable type. This 
> might actually be fine in practice, such as if the field in question 
> always points to a serializable object at runtime, but it is arguably 
> worth noting as an item of potential concern. This check is skipped if 
> the class using the serialPersistentFields mechanism.
>
> For the client libs, the webrev with the new @SuppressedWarnings 
> annotations is:
>
>     JDK-8231334: Suppress warnings on non-serializable instance fields 
> in client libs serializable classes
> http://cr.openjdk.java.net/~darcy/8231334.0/
>
> The changes are mostly in awt, but also some in beans, a few in 
> printing, and one in sound.
>
> As discussed with Phil off-line, the new checks also found an existing 
> known issue, the auxiliary class java.awt.ImageMediaEntry declared in 
> MediaTracker.java is not serializable/deserializable in practice 
> (JDK-4397681).
>
> Thanks,
>
> -Joe
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/awt-dev/attachments/20190922/59c7823a/attachment.html>

From Sergey.Bylokhov at oracle.com  Mon Sep 23 18:29:35 2019
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Mon, 23 Sep 2019 11:29:35 -0700
Subject: <AWT Dev> <Awt Dev> [13] RFR [JDK-8080185][TESTBUG] Test
 instructions need to be updated for test
 java/awt/dnd/DnDFileGroupDescriptor/DnDFileGroupDescriptor
In-Reply-To: <1e7e876f-959f-498e-9b4f-ba3af849a27f@default>
References: <622ce742-bab8-4f38-bd97-be55227f5ebc@default>
 <a35eef96-59b2-9eac-808c-12b64ab47e70@oracle.com>
 <1e7e876f-959f-498e-9b4f-ba3af849a27f@default>
Message-ID: <f8f34428-f148-1782-12e1-48daca31a7f2@oracle.com>

On 9/17/19 1:13 am, Jagjot Singh wrote:
> Dragging and Dropping a file from any location (e.g. Windows Explorer) apart from MS Outlook was never a problem. Adding them to the instruction set will not lead to the failure of the test.  According to the issue with which the test was written, the current changes proposed to be done in the instruction set may seem inappropriate. But, this issue is no more reproducible with version of Outlook starting from Express 6 and current changes will increase the coverage of the test.  Sergey, what are your thoughts on it?

I suggest updating the test in any possible way which will allow verifying the old bug, at least try.

> 
> My bad with the JDK version. The fix is for jdk14 not jdk13.
> 
> Best Regards,
> Jagjot Singh
> 
> -----Original Message-----
> From: Sergey Bylokhov
> Sent: Monday, September 16, 2019 11:44 PM
> To: Jagjot Singh <jagjot.singh at oracle.com>; awt-dev at openjdk.java.net
> Cc: Praveen Mohan <praveen.mohan at oracle.com>; Gauri Patil <gauri.patil at oracle.com>; Praveen Gupta <praveen.p.gupta at oracle.com>
> Subject: Re: <AWT Dev> <Awt Dev> [13] RFR [JDK-8080185][TESTBUG] Test instructions need to be updated for test java/awt/dnd/DnDFileGroupDescriptor/DnDFileGroupDescriptor
> 
> Hi, Jagjot.
> 
> Did you check that an initial bug JDK-6242241 can be reproduced by the new instructions?
> I assume the fix is for jdk14 not jdk13.
> 
> On 9/13/19 3:21 am, Jagjot Singh wrote:
>> Hi All,
>>
>> Please review a small fix for?JDK-8080185
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8080185
>>
>> Webrev:http://cr.openjdk.java.net/~vagarwal/8080185/webrev.0/
>>
>> Summary: The regression test ?java/awt/dnd/DnDFileGroupDescriptor/DnDFileGroupDescriptor needs further addition to the instruction set. The instructions suggests that we need to select an attachment from MS Outlook and drag and drop into the red field of applet?. It is not mandatory. We can even drag and drop any file from any location into the red field of applet. File path appears in both cases. Updating the test instructions accordingly.
>>
>> Best Regards,
>>
>> Jagjot Singh
>>
> 
> 


-- 
Best regards, Sergey.

From joe.darcy at oracle.com  Mon Sep 23 19:54:23 2019
From: joe.darcy at oracle.com (Joe Darcy)
Date: Mon, 23 Sep 2019 12:54:23 -0700
Subject: <AWT Dev> <Beans Dev> JDK 14 RFR of JDK-8231334: Suppress
 warnings on non-serializable instance fields in client libs serializable
 classes
In-Reply-To: <5D87D8B1.2070708@oracle.com>
References: <ed084e59-bebd-714e-d8af-893115f0e6b3@oracle.com>
 <5D87D8B1.2070708@oracle.com>
Message-ID: <7b7d3cdc-99b1-93be-b5b6-d6ee18aecf6c@oracle.com>

Hi Phil,

On 9/22/2019 1:25 PM, Philip Race wrote:
>
> + @SuppressWarnings("serial") // Not statically typed as Serializable 
> So is the comment being used to distinguish this overloading of what 
> "serial" means ? Why not introduce a new warning category ?


The -Xlint:serial check in javac has had an operational meaning of "does 
a serializable type define a serialVersionUID?" The work-in-progress is 
aiming to expand this to cover other aspect of declaring serializable 
(and externalizable) types.

It would be possible to put the new checks in their own category, but 
that would limit their use and some of new checks find what are most 
likely semantic errors, such as declaring a serialVersionUID in an enum 
type, which gets silently ignored.


> Randomly looking at
> ====
> src/java.desktop/share/classes/java/awt/Container.java
>
> @@ -3849,10 +3849,11 @@
>
> ???????? /**
> ????????? * The handler to fire {@code PropertyChange}
> ????????? * when children are added or removed
> ????????? */
> +??????? @SuppressWarnings("serial") // Not statically typed as 
> Serializable
> ???????? protected ContainerListener accessibleContainerHandler = null;
> ===
>
> I see that Container has a writeObject method which doesn't write this 
> field, so it is effectively transient.
>
> I recognise that it is difficult for the compiler to figure this out, 
> so perhaps there should just be a policy
> not to check classes that have writeObject methods ?


Yes, it is not feasible for this level of analysis to decode the 
semantics of writeObject and related methods. The analysis does skip 
over classes using serialPersistentFields, which is an alternative 
mechanism to indicate which fields are used for serialization.

In terms of possible false positives, I think it is acceptable to keep 
doing the checks in the presence of a writeObject method since a 
writeObject can be used to make alterations to serialization process 
other than changing the set of fields written out.


>
> Also in such a case, would it be an effectively compatible change to 
> add transient to the field, so that
> it presumably would no longer need this warning.

And the class does define a serialVersionUID so adding transient to the 
field should preserve serial compatibility.


>
> I haven't looked but presumably there could be other such cases.
>
> Will you be filing bugs for all the fixable cases ?

Someone should ;-)

To make sure my intentions are clear, nothing in this overall cleanup 
effort should be construed as seeking to assume ownership of all the 
serialization in the JDK. The primary ownership will remain with the 
component team in question. The new checks are meant to the an aid, 
especially to writing new serializable types, while also prompting some 
examination of the existing types in an effort to allow the warning to 
enabled by default? in the build.

Thanks,

-Joe


>
> -phil
>
> On 9/21/19, 12:48 PM, Joe Darcy wrote:
>>
>> Hello,
>>
>> Quick background, I'm working on expanding the compile-time 
>> serialization checks of javac's -Xlint:serial option. Ahead of that 
>> work going back, I'm analyzing the JDK sources and plan to 
>> pre-suppress the coming-soon new warnings, fixing or at least filing 
>> follow-up bugs for any problems that are found. Corresponding 
>> suppression bugs are already out for review against core libs 
>> (JDK-8231202) and security libs (JDK-8231262).
>>
>> The new check in development is if a serializable class has an 
>> instance field that is not declared to be a serializable type. This 
>> might actually be fine in practice, such as if the field in question 
>> always points to a serializable object at runtime, but it is arguably 
>> worth noting as an item of potential concern. This check is skipped 
>> if the class using the serialPersistentFields mechanism.
>>
>> For the client libs, the webrev with the new @SuppressedWarnings 
>> annotations is:
>>
>> ??? JDK-8231334: Suppress warnings on non-serializable instance 
>> fields in client libs serializable classes
>> http://cr.openjdk.java.net/~darcy/8231334.0/
>>
>> The changes are mostly in awt, but also some in beans, a few in 
>> printing, and one in sound.
>>
>> As discussed with Phil off-line, the new checks also found an 
>> existing known issue, the auxiliary class java.awt.ImageMediaEntry 
>> declared in MediaTracker.java is not serializable/deserializable in 
>> practice (JDK-4397681).
>>
>> Thanks,
>>
>> -Joe
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/awt-dev/attachments/20190923/43958d72/attachment.html>

From jagjot.singh at oracle.com  Tue Sep 24 06:12:50 2019
From: jagjot.singh at oracle.com (Jagjot Singh)
Date: Mon, 23 Sep 2019 23:12:50 -0700 (PDT)
Subject: <AWT Dev> <Awt Dev> [13] RFR [JDK-8080185][TESTBUG] Test
 instructions need to be updated for test
 java/awt/dnd/DnDFileGroupDescriptor/DnDFileGroupDescriptor
In-Reply-To: <f8f34428-f148-1782-12e1-48daca31a7f2@oracle.com>
References: <622ce742-bab8-4f38-bd97-be55227f5ebc@default>
 <a35eef96-59b2-9eac-808c-12b64ab47e70@oracle.com>
 <1e7e876f-959f-498e-9b4f-ba3af849a27f@default>
 <f8f34428-f148-1782-12e1-48daca31a7f2@oracle.com>
Message-ID: <69d07229-9c66-4bcf-97a0-35e1363fb889@default>

Hi Sergey,

Since it is a manual test, I can update the test instructions to perform both tasks i.e. dragging and dropping an attachment from MS Outlook and dragging and dropping any file from any location. This will not only verify the old bug but also cover the other case.

Thanks and Regards,
Jagjot Singh

-----Original Message-----
From: Sergey Bylokhov 
Sent: Tuesday, September 24, 2019 12:00 AM
To: Jagjot Singh <jagjot.singh at oracle.com>; awt-dev at openjdk.java.net
Cc: Praveen Mohan <praveen.mohan at oracle.com>; Gauri Patil <gauri.patil at oracle.com>; Praveen Gupta <praveen.p.gupta at oracle.com>
Subject: Re: <AWT Dev> <Awt Dev> [13] RFR [JDK-8080185][TESTBUG] Test instructions need to be updated for test java/awt/dnd/DnDFileGroupDescriptor/DnDFileGroupDescriptor

On 9/17/19 1:13 am, Jagjot Singh wrote:
> Dragging and Dropping a file from any location (e.g. Windows Explorer) apart from MS Outlook was never a problem. Adding them to the instruction set will not lead to the failure of the test.  According to the issue with which the test was written, the current changes proposed to be done in the instruction set may seem inappropriate. But, this issue is no more reproducible with version of Outlook starting from Express 6 and current changes will increase the coverage of the test.  Sergey, what are your thoughts on it?

I suggest updating the test in any possible way which will allow verifying the old bug, at least try.

> 
> My bad with the JDK version. The fix is for jdk14 not jdk13.
> 
> Best Regards,
> Jagjot Singh
> 
> -----Original Message-----
> From: Sergey Bylokhov
> Sent: Monday, September 16, 2019 11:44 PM
> To: Jagjot Singh <jagjot.singh at oracle.com>; awt-dev at openjdk.java.net
> Cc: Praveen Mohan <praveen.mohan at oracle.com>; Gauri Patil <gauri.patil at oracle.com>; Praveen Gupta <praveen.p.gupta at oracle.com>
> Subject: Re: <AWT Dev> <Awt Dev> [13] RFR [JDK-8080185][TESTBUG] Test instructions need to be updated for test java/awt/dnd/DnDFileGroupDescriptor/DnDFileGroupDescriptor
> 
> Hi, Jagjot.
> 
> Did you check that an initial bug JDK-6242241 can be reproduced by the new instructions?
> I assume the fix is for jdk14 not jdk13.
> 
> On 9/13/19 3:21 am, Jagjot Singh wrote:
>> Hi All,
>>
>> Please review a small fix for?JDK-8080185
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8080185
>>
>> Webrev:http://cr.openjdk.java.net/~vagarwal/8080185/webrev.0/
>>
>> Summary: The regression test ?java/awt/dnd/DnDFileGroupDescriptor/DnDFileGroupDescriptor needs further addition to the instruction set. The instructions suggests that we need to select an attachment from MS Outlook and drag and drop into the red field of applet?. It is not mandatory. We can even drag and drop any file from any location into the red field of applet. File path appears in both cases. Updating the test instructions accordingly.
>>
>> Best Regards,
>>
>> Jagjot Singh
>>
> 
> 


-- 
Best regards, Sergey.

From alexey.ivanov at oracle.com  Tue Sep 24 18:37:47 2019
From: alexey.ivanov at oracle.com (Alexey Ivanov)
Date: Tue, 24 Sep 2019 19:37:47 +0100
Subject: <AWT Dev> [14] RFR JDK-8231144: Wrap contents of plain HTML files
 into contentContainer
Message-ID: <fb88f41d-4ff2-f87e-47b4-5327495b9625@oracle.com>

Hello,

Please review the following simple fix for JDK 14:

bug: https://bugs.openjdk.java.net/browse/JDK-8231144
webrev: http://cr.openjdk.java.net/~aivanov/8231144/webrev.00/
docs: 
http://cr.openjdk.java.net/~aivanov/8231144/docs.00/api/java.desktop/module-summary.html

Plain HTML documentation files have no left margin after processing by 
javadoc. It does not look good. For example, see the following files in 
JDK 13 API reference:
https://docs.oracle.com/en/java/javase/13/docs/api/java.desktop/javax/imageio/metadata/doc-files/gif_metadata.html
https://docs.oracle.com/en/java/javase/13/docs/api/java.desktop/java/awt/doc-files/Modality.html

This simple fix wraps the entire content of the file, between <main> and 
</main>, into <div class="contentContainer"> and </div> which provide 
the margins for class descriptions. Thus, these HTML documentation files 
look consistently, they're also easier to read:
http://cr.openjdk.java.net/~aivanov/8231144/docs.00/api/java.desktop/javax/imageio/metadata/doc-files/gif_metadata.html
http://cr.openjdk.java.net/~aivanov/8231144/docs.00/api/java.desktop/java/awt/doc-files/Modality.html


I attached the screenshots of gif_metadata.html displayed in src, api 
reference, and api reference with the fix applied.

-- 
Regards,
Alexey

From philip.race at oracle.com  Tue Sep 24 19:12:18 2019
From: philip.race at oracle.com (Philip Race)
Date: Tue, 24 Sep 2019 12:12:18 -0700
Subject: <AWT Dev> [OpenJDK 2D-Dev] [14] RFR JDK-8231144: Wrap contents
 of plain HTML files into contentContainer
In-Reply-To: <fb88f41d-4ff2-f87e-47b4-5327495b9625@oracle.com>
References: <fb88f41d-4ff2-f87e-47b4-5327495b9625@oracle.com>
Message-ID: <5D8A6A92.7090105@oracle.com>

All looks good to me.

-phil

On 9/24/19, 11:37 AM, Alexey Ivanov wrote:
> Hello,
>
> Please review the following simple fix for JDK 14:
>
> bug: https://bugs.openjdk.java.net/browse/JDK-8231144
> webrev: http://cr.openjdk.java.net/~aivanov/8231144/webrev.00/
> docs: 
> http://cr.openjdk.java.net/~aivanov/8231144/docs.00/api/java.desktop/module-summary.html
>
> Plain HTML documentation files have no left margin after processing by 
> javadoc. It does not look good. For example, see the following files 
> in JDK 13 API reference:
> https://docs.oracle.com/en/java/javase/13/docs/api/java.desktop/javax/imageio/metadata/doc-files/gif_metadata.html 
>
> https://docs.oracle.com/en/java/javase/13/docs/api/java.desktop/java/awt/doc-files/Modality.html 
>
>
> This simple fix wraps the entire content of the file, between <main> 
> and </main>, into <div class="contentContainer"> and </div> which 
> provide the margins for class descriptions. Thus, these HTML 
> documentation files look consistently, they're also easier to read:
> http://cr.openjdk.java.net/~aivanov/8231144/docs.00/api/java.desktop/javax/imageio/metadata/doc-files/gif_metadata.html 
>
> http://cr.openjdk.java.net/~aivanov/8231144/docs.00/api/java.desktop/java/awt/doc-files/Modality.html 
>
>
>
> I attached the screenshots of gif_metadata.html displayed in src, api 
> reference, and api reference with the fix applied.
>

From philip.race at oracle.com  Tue Sep 24 23:07:27 2019
From: philip.race at oracle.com (Philip Race)
Date: Tue, 24 Sep 2019 16:07:27 -0700
Subject: <AWT Dev> <Beans Dev> JDK 14 RFR of JDK-8231334: Suppress
 warnings on non-serializable instance fields in client libs serializable
 classes
In-Reply-To: <7b7d3cdc-99b1-93be-b5b6-d6ee18aecf6c@oracle.com>
References: <ed084e59-bebd-714e-d8af-893115f0e6b3@oracle.com>
 <5D87D8B1.2070708@oracle.com>
 <7b7d3cdc-99b1-93be-b5b6-d6ee18aecf6c@oracle.com>
Message-ID: <5D8AA1AF.6020404@oracle.com>

OK. Approved by me .. but .. it would be good if you can point out any 
other cases
where you think we can compatibly make changes to get rid of the need 
for suppressing this new warning.

-phil

On 9/23/19, 12:54 PM, Joe Darcy wrote:
>
> Hi Phil,
>
> On 9/22/2019 1:25 PM, Philip Race wrote:
>>
>> +        @SuppressWarnings("serial") // Not statically typed as Serializable
>>
>> So is the comment being used to distinguish this overloading of what "serial" means ?
>> Why not introduce a new warning category ?
>
>
> The -Xlint:serial check in javac has had an operational meaning of 
> "does a serializable type define a serialVersionUID?" The 
> work-in-progress is aiming to expand this to cover other aspect of 
> declaring serializable (and externalizable) types.
>
> It would be possible to put the new checks in their own category, but 
> that would limit their use and some of new checks find what are most 
> likely semantic errors, such as declaring a serialVersionUID in an 
> enum type, which gets silently ignored.
>
>
>>
>> Randomly looking at
>> ====
>> src/java.desktop/share/classes/java/awt/Container.java
>>
>> @@ -3849,10 +3849,11 @@
>>
>>          /**
>>           * The handler to fire {@code PropertyChange}
>>           * when children are added or removed
>>           */
>> +        @SuppressWarnings("serial") // Not statically typed as 
>> Serializable
>>          protected ContainerListener accessibleContainerHandler = null;
>> ===
>>
>> I see that Container has a writeObject method which doesn't write 
>> this field, so it is effectively transient.
>>
>> I recognise that it is difficult for the compiler to figure this out, 
>> so perhaps there should just be a policy
>> not to check classes that have writeObject methods ?
>
>
> Yes, it is not feasible for this level of analysis to decode the 
> semantics of writeObject and related methods. The analysis does skip 
> over classes using serialPersistentFields, which is an alternative 
> mechanism to indicate which fields are used for serialization.
>
> In terms of possible false positives, I think it is acceptable to keep 
> doing the checks in the presence of a writeObject method since a 
> writeObject can be used to make alterations to serialization process 
> other than changing the set of fields written out.
>
>
>>
>> Also in such a case, would it be an effectively compatible change to 
>> add transient to the field, so that
>> it presumably would no longer need this warning.
>
> And the class does define a serialVersionUID so adding transient to 
> the field should preserve serial compatibility.
>
>
>>
>> I haven't looked but presumably there could be other such cases.
>>
>> Will you be filing bugs for all the fixable cases ?
>
> Someone should ;-)
>
> To make sure my intentions are clear, nothing in this overall cleanup 
> effort should be construed as seeking to assume ownership of all the 
> serialization in the JDK. The primary ownership will remain with the 
> component team in question. The new checks are meant to the an aid, 
> especially to writing new serializable types, while also prompting 
> some examination of the existing types in an effort to allow the 
> warning to enabled by default  in the build.
>
> Thanks,
>
> -Joe
>
>
>>
>> -phil
>>
>> On 9/21/19, 12:48 PM, Joe Darcy wrote:
>>>
>>> Hello,
>>>
>>> Quick background, I'm working on expanding the compile-time 
>>> serialization checks of javac's -Xlint:serial option. Ahead of that 
>>> work going back, I'm analyzing the JDK sources and plan to 
>>> pre-suppress the coming-soon new warnings, fixing or at least filing 
>>> follow-up bugs for any problems that are found. Corresponding 
>>> suppression bugs are already out for review against core libs 
>>> (JDK-8231202) and security libs (JDK-8231262).
>>>
>>> The new check in development is if a serializable class has an 
>>> instance field that is not declared to be a serializable type. This 
>>> might actually be fine in practice, such as if the field in question 
>>> always points to a serializable object at runtime, but it is 
>>> arguably worth noting as an item of potential concern. This check is 
>>> skipped if the class using the serialPersistentFields mechanism.
>>>
>>> For the client libs, the webrev with the new @SuppressedWarnings 
>>> annotations is:
>>>
>>>     JDK-8231334: Suppress warnings on non-serializable instance 
>>> fields in client libs serializable classes
>>> http://cr.openjdk.java.net/~darcy/8231334.0/
>>>
>>> The changes are mostly in awt, but also some in beans, a few in 
>>> printing, and one in sound.
>>>
>>> As discussed with Phil off-line, the new checks also found an 
>>> existing known issue, the auxiliary class java.awt.ImageMediaEntry 
>>> declared in MediaTracker.java is not serializable/deserializable in 
>>> practice (JDK-4397681).
>>>
>>> Thanks,
>>>
>>> -Joe
>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/awt-dev/attachments/20190924/ac3a4520/attachment.html>

From joe.darcy at oracle.com  Wed Sep 25 01:14:55 2019
From: joe.darcy at oracle.com (Joe Darcy)
Date: Tue, 24 Sep 2019 18:14:55 -0700
Subject: <AWT Dev> <Beans Dev> JDK 14 RFR of JDK-8231334: Suppress
 warnings on non-serializable instance fields in client libs serializable
 classes
In-Reply-To: <5D8AA1AF.6020404@oracle.com>
References: <ed084e59-bebd-714e-d8af-893115f0e6b3@oracle.com>
 <5D87D8B1.2070708@oracle.com>
 <7b7d3cdc-99b1-93be-b5b6-d6ee18aecf6c@oracle.com>
 <5D8AA1AF.6020404@oracle.com>
Message-ID: <4bba076b-ed36-b133-97be-9a216ab8f7e4@oracle.com>

Hi Phil,

I've taken another look over the classes modified in this patch. Most of 
the classes define neither a readObject nor writeObject method and thus 
use the default serialization mechanism of reading/writing all the 
non-transient instance fields (as long as serialPersistentFields is 
absent, etc.). Most of the rest call 
defaultReadObject/defaultWriteObject wrapped in some light supporting 
logic in a readObject/writeObject method. In these cases, all the 
non-transient instance fields and read/written as well.

The only class which doesn't directly or indirectly use the default 
serialization mechanism is java.awt.Container, which uses putFields in 
its writeObject method. I've filed JDK-8231437: "Review serial fields of 
java.awt.Container" to track the follow-up work.

Thanks for the review,

-Joe

On 9/24/2019 4:07 PM, Philip Race wrote:
> OK. Approved by me .. but .. it would be good if you can point out any 
> other cases
> where you think we can compatibly make changes to get rid of the need 
> for suppressing this new warning.
>
> -phil
>
> On 9/23/19, 12:54 PM, Joe Darcy wrote:
>>
>> Hi Phil,
>>
>> On 9/22/2019 1:25 PM, Philip Race wrote:
>>>
>>> + @SuppressWarnings("serial") // Not statically typed as 
>>> Serializable So is the comment being used to distinguish this 
>>> overloading of what "serial" means ? Why not introduce a new warning 
>>> category ?
>>
>>
>> The -Xlint:serial check in javac has had an operational meaning of 
>> "does a serializable type define a serialVersionUID?" The 
>> work-in-progress is aiming to expand this to cover other aspect of 
>> declaring serializable (and externalizable) types.
>>
>> It would be possible to put the new checks in their own category, but 
>> that would limit their use and some of new checks find what are most 
>> likely semantic errors, such as declaring a serialVersionUID in an 
>> enum type, which gets silently ignored.
>>
>>
>>> Randomly looking at
>>> ====
>>> src/java.desktop/share/classes/java/awt/Container.java
>>>
>>> @@ -3849,10 +3849,11 @@
>>>
>>> ???????? /**
>>> ????????? * The handler to fire {@code PropertyChange}
>>> ????????? * when children are added or removed
>>> ????????? */
>>> +??????? @SuppressWarnings("serial") // Not statically typed as 
>>> Serializable
>>> ???????? protected ContainerListener accessibleContainerHandler = null;
>>> ===
>>>
>>> I see that Container has a writeObject method which doesn't write 
>>> this field, so it is effectively transient.
>>>
>>> I recognise that it is difficult for the compiler to figure this 
>>> out, so perhaps there should just be a policy
>>> not to check classes that have writeObject methods ?
>>
>>
>> Yes, it is not feasible for this level of analysis to decode the 
>> semantics of writeObject and related methods. The analysis does skip 
>> over classes using serialPersistentFields, which is an alternative 
>> mechanism to indicate which fields are used for serialization.
>>
>> In terms of possible false positives, I think it is acceptable to 
>> keep doing the checks in the presence of a writeObject method since a 
>> writeObject can be used to make alterations to serialization process 
>> other than changing the set of fields written out.
>>
>>
>>>
>>> Also in such a case, would it be an effectively compatible change to 
>>> add transient to the field, so that
>>> it presumably would no longer need this warning.
>>
>> And the class does define a serialVersionUID so adding transient to 
>> the field should preserve serial compatibility.
>>
>>
>>>
>>> I haven't looked but presumably there could be other such cases.
>>>
>>> Will you be filing bugs for all the fixable cases ?
>>
>> Someone should ;-)
>>
>> To make sure my intentions are clear, nothing in this overall cleanup 
>> effort should be construed as seeking to assume ownership of all the 
>> serialization in the JDK. The primary ownership will remain with the 
>> component team in question. The new checks are meant to the an aid, 
>> especially to writing new serializable types, while also prompting 
>> some examination of the existing types in an effort to allow the 
>> warning to enabled by default? in the build.
>>
>> Thanks,
>>
>> -Joe
>>
>>
>>>
>>> -phil
>>>
>>> On 9/21/19, 12:48 PM, Joe Darcy wrote:
>>>>
>>>> Hello,
>>>>
>>>> Quick background, I'm working on expanding the compile-time 
>>>> serialization checks of javac's -Xlint:serial option. Ahead of that 
>>>> work going back, I'm analyzing the JDK sources and plan to 
>>>> pre-suppress the coming-soon new warnings, fixing or at least 
>>>> filing follow-up bugs for any problems that are found. 
>>>> Corresponding suppression bugs are already out for review against 
>>>> core libs (JDK-8231202) and security libs (JDK-8231262).
>>>>
>>>> The new check in development is if a serializable class has an 
>>>> instance field that is not declared to be a serializable type. This 
>>>> might actually be fine in practice, such as if the field in 
>>>> question always points to a serializable object at runtime, but it 
>>>> is arguably worth noting as an item of potential concern. This 
>>>> check is skipped if the class using the serialPersistentFields 
>>>> mechanism.
>>>>
>>>> For the client libs, the webrev with the new @SuppressedWarnings 
>>>> annotations is:
>>>>
>>>> ??? JDK-8231334: Suppress warnings on non-serializable instance 
>>>> fields in client libs serializable classes
>>>> http://cr.openjdk.java.net/~darcy/8231334.0/
>>>>
>>>> The changes are mostly in awt, but also some in beans, a few in 
>>>> printing, and one in sound.
>>>>
>>>> As discussed with Phil off-line, the new checks also found an 
>>>> existing known issue, the auxiliary class java.awt.ImageMediaEntry 
>>>> declared in MediaTracker.java is not serializable/deserializable in 
>>>> practice (JDK-4397681).
>>>>
>>>> Thanks,
>>>>
>>>> -Joe
>>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/awt-dev/attachments/20190924/8fa25729/attachment-0001.html>

From matthias.baesken at sap.com  Wed Sep 25 07:39:39 2019
From: matthias.baesken at sap.com (Baesken, Matthias)
Date: Wed, 25 Sep 2019 07:39:39 +0000
Subject: <AWT Dev> RFR [XS]: 8231445: check ZALLOC return values in awt
	coding
Message-ID: <AM6PR02MB507826A4BD03DCD71F1CCD2493870@AM6PR02MB5078.eurprd02.prod.outlook.com>

Hello, please review this small fix .  It deals with return value checking of ZALLOC .

ZALLOC is a macro using calloc, please  see :

jdk/src/java.desktop/unix/native/common/awt/awt_p.h
/* allocated and initialize a structure */
#define ZALLOC(T) ((struct T *)calloc(1, sizeof(struct T)))

    ...   so the return value has to be checked which is missing at some places.


Bug/webrev :

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

http://cr.openjdk.java.net/~mbaesken/webrevs/8231445.0/


Thanks, Matthias
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/awt-dev/attachments/20190925/355b557c/attachment.html>

From christoph.langer at sap.com  Wed Sep 25 09:05:09 2019
From: christoph.langer at sap.com (Langer, Christoph)
Date: Wed, 25 Sep 2019 09:05:09 +0000
Subject: <AWT Dev> [CAUTION] [OpenJDK 2D-Dev] RFR [XS]: 8231445: check
 ZALLOC return values in	awt coding
In-Reply-To: <AM6PR02MB507826A4BD03DCD71F1CCD2493870@AM6PR02MB5078.eurprd02.prod.outlook.com>
References: <AM6PR02MB507826A4BD03DCD71F1CCD2493870@AM6PR02MB5078.eurprd02.prod.outlook.com>
Message-ID: <AM6PR02MB5192F372D6888ECB0869B48E8A870@AM6PR02MB5192.eurprd02.prod.outlook.com>

Hi Matthias,

looks good to me.

Maybe you want to create a Macro for the repeating pattern:

graphicsConfigs[ind] = ZALLOC (_AwtGraphicsConfigData);
if (graphicsConfigs[ind] == NULL) {
    JNU_ThrowOutOfMemoryError(env, "allocation in getAllConfigs failed");
    goto cleanup;
}

in getAllConfigs?

Best regards
Christoph

From: 2d-dev <2d-dev-bounces at openjdk.java.net> On Behalf Of Baesken, Matthias
Sent: Mittwoch, 25. September 2019 09:40
To: awt-dev at openjdk.java.net; 2d-dev at openjdk.java.net
Subject: [CAUTION] [OpenJDK 2D-Dev] RFR [XS]: 8231445: check ZALLOC return values in awt coding

Hello, please review this small fix .  It deals with return value checking of ZALLOC .

ZALLOC is a macro using calloc, please  see :

jdk/src/java.desktop/unix/native/common/awt/awt_p.h
/* allocated and initialize a structure */
#define ZALLOC(T) ((struct T *)calloc(1, sizeof(struct T)))

    ...   so the return value has to be checked which is missing at some places.


Bug/webrev :

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

http://cr.openjdk.java.net/~mbaesken/webrevs/8231445.0/


Thanks, Matthias
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/awt-dev/attachments/20190925/8c03c6d0/attachment.html>

From prasanta.sadhukhan at oracle.com  Wed Sep 25 11:18:12 2019
From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan)
Date: Wed, 25 Sep 2019 16:48:12 +0530
Subject: <AWT Dev> [14] RFR JDK-8214578: [macos] Problem with backslashes on
 macOS/JIS keyboard: Java ignores system settings
Message-ID: <651c2a3d-9491-ed19-e5f0-e57ed4071b25@oracle.com>

Hi All,

Please review a fix for an issue where it is seen that Java apps ignore 
system settings regarding handling yen key.

If we use mac keyboard layout to use Japanese input source and "Change 
Settings -> Keyboard -> Input Sources -> Japanese -> "??" key generates 
-> \ (Backslash) "
and Change Input method to Romaji and press "yen" symbol in Japanese 
keyboard or "option+y" key combination in US keyboard
Java app still interprets it as "yen" in JTextField

Issue seems to happen due to fact when NSTextInputClient.insertText() 
method is called, even though? "\" codePoint is passed,

but insertText() has a check for codePoint is complex or not, so in this 
case, it is not complex, InputMethodEvent is not generated and no "\" is 
inserted in JTextField.

Proposed fix is to see if keyboard layout is Japanese (kotoeri) and 
codePoint is "\" then take it as complex codepoint and generate IME,

so that whatever system setting is set for "yen" symbol, it is correctly 
interpreted and inputted in CInputMethod.insertText() method, to be seen 
in JTextField.

The fix has been tested in US keyboard and Japanese keyboard.

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

webrev: http://cr.openjdk.java.net/~psadhukhan/8214578/webrev.0/

Regards
Prasanta


From philip.race at oracle.com  Wed Sep 25 15:39:54 2019
From: philip.race at oracle.com (Philip Race)
Date: Wed, 25 Sep 2019 08:39:54 -0700
Subject: <AWT Dev> [OpenJDK 2D-Dev] RFR [XS]: 8231445: check ZALLOC
 return values in awt coding
In-Reply-To: <AM6PR02MB507826A4BD03DCD71F1CCD2493870@AM6PR02MB5078.eurprd02.prod.outlook.com>
References: <AM6PR02MB507826A4BD03DCD71F1CCD2493870@AM6PR02MB5078.eurprd02.prod.outlook.com>
Message-ID: <5D8B8A4A.2010208@oracle.com>

Looks fine. getAllConfigs() already throws OOME in a couple of places so
in theory a caller should already be ready to handle that. Mainly I mean
that there shouldn't be any further JNI calls with a pending exception ...

-phil.

On 9/25/19, 12:39 AM, Baesken, Matthias wrote:
>
> Hello, please review this small fix .  It deals with return value 
> checking of ZALLOC .
>
> ZALLOC is a macro using calloc, please  see :
>
> jdk/src/java.desktop/unix/native/common/awt/awt_p.h
> /* allocated and initialize a structure */
> #define ZALLOC(T) ((struct T *)calloc(1, sizeof(struct T)))
>
>     ...   so the return value has to be checked which is missing at 
> some places.
>
> Bug/webrev :
>
> https://bugs.openjdk.java.net/browse/JDK-8231445
>
> http://cr.openjdk.java.net/~mbaesken/webrevs/8231445.0/ 
> <http://cr.openjdk.java.net/%7Embaesken/webrevs/8231445.0/>
>
> Thanks, Matthias
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/awt-dev/attachments/20190925/69478621/attachment.html>

From philip.race at oracle.com  Wed Sep 25 15:57:53 2019
From: philip.race at oracle.com (Philip Race)
Date: Wed, 25 Sep 2019 08:57:53 -0700
Subject: <AWT Dev> [14] RFR JDK-8214578: [macos] Problem with
 backslashes on macOS/JIS keyboard: Java ignores system settings
In-Reply-To: <651c2a3d-9491-ed19-e5f0-e57ed4071b25@oracle.com>
References: <651c2a3d-9491-ed19-e5f0-e57ed4071b25@oracle.com>
Message-ID: <5D8B8E81.8090805@oracle.com>

Prasanta,

Can you please add your evaluation to the bug. Last comment from you in 
there is
"it's still not reproducible for me" which seems unlikely if you have a 
proposed fix.

Actually I am having some trouble understanding what you wrote below.
Questions in line.

On 9/25/19, 4:18 AM, Prasanta Sadhukhan wrote:
> Hi All,
>
> Please review a fix for an issue where it is seen that Java apps 
> ignore system settings regarding handling yen key.
>
> If we use mac keyboard layout to use Japanese input source and "Change 
> Settings -> Keyboard -> Input Sources -> Japanese -> "??" key 
> generates -> \ (Backslash) "

"Japanese -> "??" key generates"

What are you trying to say here with that -> ? Is that another level of 
setting or do
you mean after setting to Japanese and typing some key still generates 
backslash ?
Why does it say ??" ? That isn't a key, is it ?


> and Change Input method to Romaji and press "yen" symbol in Japanese 
> keyboard or "option+y" key combination in US keyboard
> Java app still interprets it as "yen" in JTextField

Umm  .. "still interprets it as Yen" ? Isn't that what you wanted to 
happen ?

>
> Issue seems to happen due to fact when NSTextInputClient.insertText() 
> method is called, even though  "\" codePoint is passed,
>
> but insertText() has a check for codePoint is complex or not, so in 
> this case, it is not complex, InputMethodEvent is not generated and no 
> "\" is inserted in JTextField.

I am not sure I can parse this correctly

"fact when" ? is where I start to get lost.
Can you restate it ?

>
> Proposed fix is to see if keyboard layout is Japanese (kotoeri) and 
> codePoint is "\" then take it as complex codepoint and generate IME,

Why ? Is backslash special ?

-phil.
>
> so that whatever system setting is set for "yen" symbol, it is 
> correctly interpreted and inputted in CInputMethod.insertText() 
> method, to be seen in JTextField.
>
> The fix has been tested in US keyboard and Japanese keyboard.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8214578
>
> webrev: http://cr.openjdk.java.net/~psadhukhan/8214578/webrev.0/
>
> Regards
> Prasanta
>

From Sergey.Bylokhov at oracle.com  Wed Sep 25 21:08:20 2019
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Wed, 25 Sep 2019 14:08:20 -0700
Subject: <AWT Dev> [OpenJDK 2D-Dev] [14] RFR JDK-8231144: Wrap contents
 of plain HTML files into contentContainer
In-Reply-To: <5D8A6A92.7090105@oracle.com>
References: <fb88f41d-4ff2-f87e-47b4-5327495b9625@oracle.com>
 <5D8A6A92.7090105@oracle.com>
Message-ID: <e1e5b84d-ed62-6b74-7487-90639f4523e8@oracle.com>

+1

On 9/24/19 12:12 pm, Philip Race wrote:
> All looks good to me.
> 
> -phil
> 
> On 9/24/19, 11:37 AM, Alexey Ivanov wrote:
>> Hello,
>>
>> Please review the following simple fix for JDK 14:
>>
>> bug: https://bugs.openjdk.java.net/browse/JDK-8231144
>> webrev: http://cr.openjdk.java.net/~aivanov/8231144/webrev.00/
>> docs: http://cr.openjdk.java.net/~aivanov/8231144/docs.00/api/java.desktop/module-summary.html
>>
>> Plain HTML documentation files have no left margin after processing by javadoc. It does not look good. For example, see the following files in JDK 13 API reference:
>> https://docs.oracle.com/en/java/javase/13/docs/api/java.desktop/javax/imageio/metadata/doc-files/gif_metadata.html
>> https://docs.oracle.com/en/java/javase/13/docs/api/java.desktop/java/awt/doc-files/Modality.html
>>
>> This simple fix wraps the entire content of the file, between <main> and </main>, into <div class="contentContainer"> and </div> which provide the margins for class descriptions. Thus, these HTML documentation files look consistently, they're also easier to read:
>> http://cr.openjdk.java.net/~aivanov/8231144/docs.00/api/java.desktop/javax/imageio/metadata/doc-files/gif_metadata.html
>> http://cr.openjdk.java.net/~aivanov/8231144/docs.00/api/java.desktop/java/awt/doc-files/Modality.html
>>
>>
>> I attached the screenshots of gif_metadata.html displayed in src, api reference, and api reference with the fix applied.
>>


-- 
Best regards, Sergey.

From Sergey.Bylokhov at oracle.com  Wed Sep 25 21:14:03 2019
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Wed, 25 Sep 2019 14:14:03 -0700
Subject: <AWT Dev> <Awt Dev> [13] RFR [JDK-8080185][TESTBUG] Test
 instructions need to be updated for test
 java/awt/dnd/DnDFileGroupDescriptor/DnDFileGroupDescriptor
In-Reply-To: <69d07229-9c66-4bcf-97a0-35e1363fb889@default>
References: <622ce742-bab8-4f38-bd97-be55227f5ebc@default>
 <a35eef96-59b2-9eac-808c-12b64ab47e70@oracle.com>
 <1e7e876f-959f-498e-9b4f-ba3af849a27f@default>
 <f8f34428-f148-1782-12e1-48daca31a7f2@oracle.com>
 <69d07229-9c66-4bcf-97a0-35e1363fb889@default>
Message-ID: <b94de822-f984-50b8-aa43-3796fadcda35@oracle.com>

On 9/23/19 11:12 pm, Jagjot Singh wrote:
> Hi Sergey,
> 
> Since it is a manual test, I can update the test instructions to perform both tasks i.e. dragging and dropping an attachment from MS Outlook and dragging and dropping any file from any location. This will not only verify the old bug but also cover the other case.

In the previous email, you said that "issue is no more reproducible with the version of Outlook starting from Express 6", so I guess instruction about copying the text from the MS Outlook is not enough to reproduce the problem, isn't it?

> 
> Thanks and Regards,
> Jagjot Singh
> 
> -----Original Message-----
> From: Sergey Bylokhov
> Sent: Tuesday, September 24, 2019 12:00 AM
> To: Jagjot Singh <jagjot.singh at oracle.com>; awt-dev at openjdk.java.net
> Cc: Praveen Mohan <praveen.mohan at oracle.com>; Gauri Patil <gauri.patil at oracle.com>; Praveen Gupta <praveen.p.gupta at oracle.com>
> Subject: Re: <AWT Dev> <Awt Dev> [13] RFR [JDK-8080185][TESTBUG] Test instructions need to be updated for test java/awt/dnd/DnDFileGroupDescriptor/DnDFileGroupDescriptor
> 
> On 9/17/19 1:13 am, Jagjot Singh wrote:
>> Dragging and Dropping a file from any location (e.g. Windows Explorer) apart from MS Outlook was never a problem. Adding them to the instruction set will not lead to the failure of the test.  According to the issue with which the test was written, the current changes proposed to be done in the instruction set may seem inappropriate. But, this issue is no more reproducible with version of Outlook starting from Express 6 and current changes will increase the coverage of the test.  Sergey, what are your thoughts on it?
> 
> I suggest updating the test in any possible way which will allow verifying the old bug, at least try.
> 
>>
>> My bad with the JDK version. The fix is for jdk14 not jdk13.
>>
>> Best Regards,
>> Jagjot Singh
>>
>> -----Original Message-----
>> From: Sergey Bylokhov
>> Sent: Monday, September 16, 2019 11:44 PM
>> To: Jagjot Singh <jagjot.singh at oracle.com>; awt-dev at openjdk.java.net
>> Cc: Praveen Mohan <praveen.mohan at oracle.com>; Gauri Patil <gauri.patil at oracle.com>; Praveen Gupta <praveen.p.gupta at oracle.com>
>> Subject: Re: <AWT Dev> <Awt Dev> [13] RFR [JDK-8080185][TESTBUG] Test instructions need to be updated for test java/awt/dnd/DnDFileGroupDescriptor/DnDFileGroupDescriptor
>>
>> Hi, Jagjot.
>>
>> Did you check that an initial bug JDK-6242241 can be reproduced by the new instructions?
>> I assume the fix is for jdk14 not jdk13.
>>
>> On 9/13/19 3:21 am, Jagjot Singh wrote:
>>> Hi All,
>>>
>>> Please review a small fix for?JDK-8080185
>>>
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8080185
>>>
>>> Webrev:http://cr.openjdk.java.net/~vagarwal/8080185/webrev.0/
>>>
>>> Summary: The regression test ?java/awt/dnd/DnDFileGroupDescriptor/DnDFileGroupDescriptor needs further addition to the instruction set. The instructions suggests that we need to select an attachment from MS Outlook and drag and drop into the red field of applet?. It is not mandatory. We can even drag and drop any file from any location into the red field of applet. File path appears in both cases. Updating the test instructions accordingly.
>>>
>>> Best Regards,
>>>
>>> Jagjot Singh
>>>
>>
>>
> 
> 


-- 
Best regards, Sergey.

From prasanta.sadhukhan at oracle.com  Thu Sep 26 05:30:44 2019
From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan)
Date: Thu, 26 Sep 2019 11:00:44 +0530
Subject: <AWT Dev> [14] RFR JDK-8214578: [macos] Problem with
 backslashes on macOS/JIS keyboard: Java ignores system settings
In-Reply-To: <5D8B8E81.8090805@oracle.com>
References: <651c2a3d-9491-ed19-e5f0-e57ed4071b25@oracle.com>
 <5D8B8E81.8090805@oracle.com>
Message-ID: <5c2e1c9e-e4e9-431e-f30d-df0b42d0aeb2@oracle.com>

Hi Phil,

On 25-Sep-19 9:27 PM, Philip Race wrote:
> Prasanta,
>
> Can you please add your evaluation to the bug. Last comment from you 
> in there is
> "it's still not reproducible for me" which seems unlikely if you have 
> a proposed fix.
>
I have added the evaluation in JBS.
> Actually I am having some trouble understanding what you wrote below.
> Questions in line.
>
> On 9/25/19, 4:18 AM, Prasanta Sadhukhan wrote:
>> Hi All,
>>
>> Please review a fix for an issue where it is seen that Java apps 
>> ignore system settings regarding handling yen key.
>>
>> If we use mac keyboard layout to use Japanese input source and 
>> "Change Settings -> Keyboard -> Input Sources -> Japanese -> "??" key 
>> generates -> \ (Backslash) "
>
> "Japanese -> "??" key generates"
>
> What are you trying to say here with that -> ? Is that another level 
> of setting or do
> you mean after setting to Japanese and typing some key still generates 
> backslash ?
> Why does it say ??" ? That isn't a key, is it ?
>
"Change Settings -> Keyboard -> Input Sources -> Japanese -> "??" key 
generates -> \ (Backslash) " is system setting you can set from "System 
Preferences". I guess David Buck demoed this setting to you.
>
>> and Change Input method to Romaji and press "yen" symbol in Japanese 
>> keyboard or "option+y" key combination in US keyboard
>> Java app still interprets it as "yen" in JTextField
>
> Umm? .. "still interprets it as Yen" ? Isn't that what you wanted to 
> happen ?
>
No, it should honour the system preference setting for "Japanese -> "??" 
key generates". If it is "\", it should be "\", if it is "yen", it 
should be "yen". Without the fix, it was always "yen" irrespective of 
the above setting.
>>
>> Issue seems to happen due to fact when NSTextInputClient.insertText() 
>> method is called, even though "\" codePoint is passed,
>>
>> but insertText() has a check for codePoint is complex or not, so in 
>> this case, it is not complex, InputMethodEvent is not generated and 
>> no "\" is inserted in JTextField.
>
> I am not sure I can parse this correctly
>
> "fact when" ? is where I start to get lost.
> Can you restate it ?
>
When NSTextInputClient.insertText() method is called with "\" codePoint 
with japanese as input source
insertText() checks whether this codePoint is complex or not,
so in this case, it is not complex, InputMethodEvent is not generated 
and no "\" is inserted in JTextField.
>>
>> Proposed fix is to see if keyboard layout is Japanese (kotoeri) and 
>> codePoint is "\" then take it as complex codepoint and generate IME,
>
> Why ? Is backslash special ?

Actually, for japanese input source in US keybord layout, backslash can 
have different connotation. It can be interpreted as backslash or yen 
depending on system setting.

Regards

Prasanta

>
> -phil.
>>
>> so that whatever system setting is set for "yen" symbol, it is 
>> correctly interpreted and inputted in CInputMethod.insertText() 
>> method, to be seen in JTextField.
>>
>> The fix has been tested in US keyboard and Japanese keyboard.
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8214578
>>
>> webrev: http://cr.openjdk.java.net/~psadhukhan/8214578/webrev.0/
>>
>> Regards
>> Prasanta
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/awt-dev/attachments/20190926/bcd9b787/attachment.html>

From Sergey.Bylokhov at oracle.com  Fri Sep 27 00:38:17 2019
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Thu, 26 Sep 2019 17:38:17 -0700
Subject: <AWT Dev> [14] Review Request: 8231438 [macos] The dark mode is not
 supported yet
Message-ID: <a334fc9b-0a27-73f8-b357-c94a4ce2c093@oracle.com>

Hello.
Please review the fix for JDK 14.

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

In jdk13 we started to use SDK 10.14 to build JDK, which automatically opt-in support of dark mode:
--------------
"The system assumes that apps linked against the macOS 10.14 or later SDK support both light and dark appearances"
https://developer.apple.com/documentation/appkit/nsappearancecustomization/choosing_a_specific_appearance_for_your_macos_app?language=objc
--------------

Unfortunately we dark mode still unsupported by the AWT/Swing, because of:
  - JavaRuntimeSupport Framework which is used by the Aqua L&F to draw the "native"
    appearance does not provide "dark mode" appearance, the bug is filed to Apple.
    https://bugs.openjdk.java.net/browse/JDK-8228555
  - In a few places, we mix the "native" colors used by the system and default colors
    used by the Swing. For example, we may use a transparent white selection "native"
    color which is invisible on top of white text fields.

While the bugs above are not fixed we may opt-out the dark mode:
-------------
Supporting Dark Mode is strongly encouraged. Use the NSRequiresAquaSystemAppearance key to opt out temporarily only while you work on improvements to your app's Dark Mode support. If you do not plan to support a dark appearance at all, apply a light appearance to your entire app, as described in Assign a Specific Appearance to Your App.
https://developer.apple.com/documentation/appkit/nsappearancecustomization/choosing_a_specific_appearance_for_your_macos_app?language=objc
-------------

I tried to disable it via plist.info but it does not work for "java -jar" case, so I disabled it in the code
Some constants in one test were updated to work on dark and light mode, but an updated test still reproduce the initial bug.


-- 
Best regards, Sergey.

From javalists at cbfiddle.com  Fri Sep 27 01:17:46 2019
From: javalists at cbfiddle.com (Alan Snyder)
Date: Thu, 26 Sep 2019 18:17:46 -0700
Subject: <AWT Dev> [14] Review Request: 8231438 [macos] The dark mode is
 not supported yet
In-Reply-To: <a334fc9b-0a27-73f8-b357-c94a4ce2c093@oracle.com>
References: <a334fc9b-0a27-73f8-b357-c94a4ce2c093@oracle.com>
Message-ID: <81F4872D-4758-4FC2-8DA4-8907C8A780D4@cbfiddle.com>

I have a LAF that supports dark mode, so I need this new behavior to be configurable. When using my LAF, the (user selected) default appearance should continue to be used.

  Alan



> On Sep 26, 2019, at 5:38 PM, Sergey Bylokhov <Sergey.Bylokhov at oracle.com> wrote:
> 
> Hello.
> Please review the fix for JDK 14.
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8231438
> Fix: http://cr.openjdk.java.net/~serb/8231438/webrev.01
> 
> In jdk13 we started to use SDK 10.14 to build JDK, which automatically opt-in support of dark mode:
> --------------
> "The system assumes that apps linked against the macOS 10.14 or later SDK support both light and dark appearances"
> https://developer.apple.com/documentation/appkit/nsappearancecustomization/choosing_a_specific_appearance_for_your_macos_app?language=objc
> --------------
> 
> Unfortunately we dark mode still unsupported by the AWT/Swing, because of:
> - JavaRuntimeSupport Framework which is used by the Aqua L&F to draw the "native"
>   appearance does not provide "dark mode" appearance, the bug is filed to Apple.
>   https://bugs.openjdk.java.net/browse/JDK-8228555
> - In a few places, we mix the "native" colors used by the system and default colors
>   used by the Swing. For example, we may use a transparent white selection "native"
>   color which is invisible on top of white text fields.
> 
> While the bugs above are not fixed we may opt-out the dark mode:
> -------------
> Supporting Dark Mode is strongly encouraged. Use the NSRequiresAquaSystemAppearance key to opt out temporarily only while you work on improvements to your app's Dark Mode support. If you do not plan to support a dark appearance at all, apply a light appearance to your entire app, as described in Assign a Specific Appearance to Your App.
> https://developer.apple.com/documentation/appkit/nsappearancecustomization/choosing_a_specific_appearance_for_your_macos_app?language=objc
> -------------
> 
> I tried to disable it via plist.info but it does not work for "java -jar" case, so I disabled it in the code
> Some constants in one test were updated to work on dark and light mode, but an updated test still reproduce the initial bug.
> 
> 
> -- 
> Best regards, Sergey.
> 


From Sergey.Bylokhov at oracle.com  Fri Sep 27 05:52:07 2019
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Thu, 26 Sep 2019 22:52:07 -0700
Subject: <AWT Dev> [14] Review Request: 8231438 [macos] The dark mode is
 not supported yet
In-Reply-To: <81F4872D-4758-4FC2-8DA4-8907C8A780D4@cbfiddle.com>
References: <a334fc9b-0a27-73f8-b357-c94a4ce2c093@oracle.com>
 <81F4872D-4758-4FC2-8DA4-8907C8A780D4@cbfiddle.com>
Message-ID: <02293149-74d4-1ca3-b1da-f50f4a951c59@oracle.com>

On 9/26/19 6:17 pm, Alan Snyder wrote:
> I have a LAF that supports dark mode, so I need this new behavior to be configurable. When using my LAF, the (user selected) default appearance should continue to be used.

I guess you L&F is working on jdk12? If yes then nothing will be changed for it.

> 
>    Alan
> 
> 
> 
>> On Sep 26, 2019, at 5:38 PM, Sergey Bylokhov <Sergey.Bylokhov at oracle.com> wrote:
>>
>> Hello.
>> Please review the fix for JDK 14.
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8231438
>> Fix: http://cr.openjdk.java.net/~serb/8231438/webrev.01
>>
>> In jdk13 we started to use SDK 10.14 to build JDK, which automatically opt-in support of dark mode:
>> --------------
>> "The system assumes that apps linked against the macOS 10.14 or later SDK support both light and dark appearances"
>> https://developer.apple.com/documentation/appkit/nsappearancecustomization/choosing_a_specific_appearance_for_your_macos_app?language=objc
>> --------------
>>
>> Unfortunately we dark mode still unsupported by the AWT/Swing, because of:
>> - JavaRuntimeSupport Framework which is used by the Aqua L&F to draw the "native"
>>    appearance does not provide "dark mode" appearance, the bug is filed to Apple.
>>    https://bugs.openjdk.java.net/browse/JDK-8228555
>> - In a few places, we mix the "native" colors used by the system and default colors
>>    used by the Swing. For example, we may use a transparent white selection "native"
>>    color which is invisible on top of white text fields.
>>
>> While the bugs above are not fixed we may opt-out the dark mode:
>> -------------
>> Supporting Dark Mode is strongly encouraged. Use the NSRequiresAquaSystemAppearance key to opt out temporarily only while you work on improvements to your app's Dark Mode support. If you do not plan to support a dark appearance at all, apply a light appearance to your entire app, as described in Assign a Specific Appearance to Your App.
>> https://developer.apple.com/documentation/appkit/nsappearancecustomization/choosing_a_specific_appearance_for_your_macos_app?language=objc
>> -------------
>>
>> I tried to disable it via plist.info but it does not work for "java -jar" case, so I disabled it in the code
>> Some constants in one test were updated to work on dark and light mode, but an updated test still reproduce the initial bug.
>>
>>
>> -- 
>> Best regards, Sergey.
>>
> 


-- 
Best regards, Sergey.

From javalists at cbfiddle.com  Fri Sep 27 06:00:38 2019
From: javalists at cbfiddle.com (Alan Snyder)
Date: Thu, 26 Sep 2019 23:00:38 -0700
Subject: <AWT Dev> [14] Review Request: 8231438 [macos] The dark mode is
 not supported yet
In-Reply-To: <02293149-74d4-1ca3-b1da-f50f4a951c59@oracle.com>
References: <a334fc9b-0a27-73f8-b357-c94a4ce2c093@oracle.com>
 <81F4872D-4758-4FC2-8DA4-8907C8A780D4@cbfiddle.com>
 <02293149-74d4-1ca3-b1da-f50f4a951c59@oracle.com>
Message-ID: <F9F6489E-4330-4307-909E-54B3A21E178E@cbfiddle.com>

No, it works on a modified JDK 12 whose linked SDK version is 10.14 (or as a bundled app with NSRequiresAquaSystemAppearance = NO).

> On Sep 26, 2019, at 10:52 PM, Sergey Bylokhov <Sergey.Bylokhov at oracle.com> wrote:
> 
> On 9/26/19 6:17 pm, Alan Snyder wrote:
>> I have a LAF that supports dark mode, so I need this new behavior to be configurable. When using my LAF, the (user selected) default appearance should continue to be used.
> 
> I guess you L&F is working on jdk12? If yes then nothing will be changed for it.
> 
>>   Alan
>>> On Sep 26, 2019, at 5:38 PM, Sergey Bylokhov <Sergey.Bylokhov at oracle.com> wrote:
>>> 
>>> Hello.
>>> Please review the fix for JDK 14.
>>> 
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8231438
>>> Fix: http://cr.openjdk.java.net/~serb/8231438/webrev.01
>>> 
>>> In jdk13 we started to use SDK 10.14 to build JDK, which automatically opt-in support of dark mode:
>>> --------------
>>> "The system assumes that apps linked against the macOS 10.14 or later SDK support both light and dark appearances"
>>> https://developer.apple.com/documentation/appkit/nsappearancecustomization/choosing_a_specific_appearance_for_your_macos_app?language=objc
>>> --------------
>>> 
>>> Unfortunately we dark mode still unsupported by the AWT/Swing, because of:
>>> - JavaRuntimeSupport Framework which is used by the Aqua L&F to draw the "native"
>>>   appearance does not provide "dark mode" appearance, the bug is filed to Apple.
>>>   https://bugs.openjdk.java.net/browse/JDK-8228555
>>> - In a few places, we mix the "native" colors used by the system and default colors
>>>   used by the Swing. For example, we may use a transparent white selection "native"
>>>   color which is invisible on top of white text fields.
>>> 
>>> While the bugs above are not fixed we may opt-out the dark mode:
>>> -------------
>>> Supporting Dark Mode is strongly encouraged. Use the NSRequiresAquaSystemAppearance key to opt out temporarily only while you work on improvements to your app's Dark Mode support. If you do not plan to support a dark appearance at all, apply a light appearance to your entire app, as described in Assign a Specific Appearance to Your App.
>>> https://developer.apple.com/documentation/appkit/nsappearancecustomization/choosing_a_specific_appearance_for_your_macos_app?language=objc
>>> -------------
>>> 
>>> I tried to disable it via plist.info but it does not work for "java -jar" case, so I disabled it in the code
>>> Some constants in one test were updated to work on dark and light mode, but an updated test still reproduce the initial bug.
>>> 
>>> 
>>> -- 
>>> Best regards, Sergey.
>>> 
> 
> 
> -- 
> Best regards, Sergey.
> 


From Sergey.Bylokhov at oracle.com  Fri Sep 27 06:32:46 2019
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Thu, 26 Sep 2019 23:32:46 -0700
Subject: <AWT Dev> [14] Review Request: 8231438 [macos] The dark mode is
 not supported yet
In-Reply-To: <F9F6489E-4330-4307-909E-54B3A21E178E@cbfiddle.com>
References: <a334fc9b-0a27-73f8-b357-c94a4ce2c093@oracle.com>
 <81F4872D-4758-4FC2-8DA4-8907C8A780D4@cbfiddle.com>
 <02293149-74d4-1ca3-b1da-f50f4a951c59@oracle.com>
 <F9F6489E-4330-4307-909E-54B3A21E178E@cbfiddle.com>
Message-ID: <0edcc750-b244-0f86-190e-b53189dd9fbd@oracle.com>

Not sure that it will be possible to make a "public" switch to disable/enable this feature,
because both options have to be officially supported and pass all related tests.
I need to double-check this.

On 9/26/19 11:00 pm, Alan Snyder wrote:
> No, it works on a modified JDK 12 whose linked SDK version is 10.14 (or as a bundled app with NSRequiresAquaSystemAppearance = NO).
>> On Sep 26, 2019, at 10:52 PM, Sergey Bylokhov <Sergey.Bylokhov at oracle.com> wrote:
>>
>> On 9/26/19 6:17 pm, Alan Snyder wrote:
>>> I have a LAF that supports dark mode, so I need this new behavior to be configurable. When using my LAF, the (user selected) default appearance should continue to be used.
>>
>> I guess you L&F is working on jdk12? If yes then nothing will be changed for it.
>>
>>>    Alan
>>>> On Sep 26, 2019, at 5:38 PM, Sergey Bylokhov <Sergey.Bylokhov at oracle.com> wrote:
>>>>
>>>> Hello.
>>>> Please review the fix for JDK 14.
>>>>
>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8231438
>>>> Fix: http://cr.openjdk.java.net/~serb/8231438/webrev.01
>>>>
>>>> In jdk13 we started to use SDK 10.14 to build JDK, which automatically opt-in support of dark mode:
>>>> --------------
>>>> "The system assumes that apps linked against the macOS 10.14 or later SDK support both light and dark appearances"
>>>> https://developer.apple.com/documentation/appkit/nsappearancecustomization/choosing_a_specific_appearance_for_your_macos_app?language=objc
>>>> --------------
>>>>
>>>> Unfortunately we dark mode still unsupported by the AWT/Swing, because of:
>>>> - JavaRuntimeSupport Framework which is used by the Aqua L&F to draw the "native"
>>>>    appearance does not provide "dark mode" appearance, the bug is filed to Apple.
>>>>    https://bugs.openjdk.java.net/browse/JDK-8228555
>>>> - In a few places, we mix the "native" colors used by the system and default colors
>>>>    used by the Swing. For example, we may use a transparent white selection "native"
>>>>    color which is invisible on top of white text fields.
>>>>
>>>> While the bugs above are not fixed we may opt-out the dark mode:
>>>> -------------
>>>> Supporting Dark Mode is strongly encouraged. Use the NSRequiresAquaSystemAppearance key to opt out temporarily only while you work on improvements to your app's Dark Mode support. If you do not plan to support a dark appearance at all, apply a light appearance to your entire app, as described in Assign a Specific Appearance to Your App.
>>>> https://developer.apple.com/documentation/appkit/nsappearancecustomization/choosing_a_specific_appearance_for_your_macos_app?language=objc
>>>> -------------
>>>>
>>>> I tried to disable it via plist.info but it does not work for "java -jar" case, so I disabled it in the code
>>>> Some constants in one test were updated to work on dark and light mode, but an updated test still reproduce the initial bug.
>>>>
>>>>
>>>> -- 
>>>> Best regards, Sergey.
>>>>
>>
>>
>> -- 
>> Best regards, Sergey.
>>
> 


-- 
Best regards, Sergey.

From javalists at cbfiddle.com  Fri Sep 27 15:29:17 2019
From: javalists at cbfiddle.com (Alan Snyder)
Date: Fri, 27 Sep 2019 08:29:17 -0700
Subject: <AWT Dev> [14] Review Request: 8231438 [macos] The dark mode is
 not supported yet
In-Reply-To: <0edcc750-b244-0f86-190e-b53189dd9fbd@oracle.com>
References: <a334fc9b-0a27-73f8-b357-c94a4ce2c093@oracle.com>
 <81F4872D-4758-4FC2-8DA4-8907C8A780D4@cbfiddle.com>
 <02293149-74d4-1ca3-b1da-f50f4a951c59@oracle.com>
 <F9F6489E-4330-4307-909E-54B3A21E178E@cbfiddle.com>
 <0edcc750-b244-0f86-190e-b53189dd9fbd@oracle.com>
Message-ID: <B59E372A-662A-4235-8084-222F1C224707@cbfiddle.com>

I would say that a public switch is necessary and therefore must be possible.

It would be presumptuous for the JDK to assume that all Java desktop applications on macOS use AWT/Swing, much less a particular Swing LAF, and therefore incorrect to impose the limitations of AWT/Swing/Aqua LAF on all Java programs on macOS.

By the way, I tried to get Apple to make the dark mode opt-in configurable in the command line case, but they were not convinced.

I also filed a bug with Apple to support dark mode in JRS, but nothing happened.

Maybe Oracle has more leverage with Apple than I have? One can hope.

  Alan



> On Sep 26, 2019, at 11:32 PM, Sergey Bylokhov <Sergey.Bylokhov at oracle.com> wrote:
> 
> Not sure that it will be possible to make a "public" switch to disable/enable this feature,
> because both options have to be officially supported and pass all related tests.
> I need to double-check this.
> 
> On 9/26/19 11:00 pm, Alan Snyder wrote:
>> No, it works on a modified JDK 12 whose linked SDK version is 10.14 (or as a bundled app with NSRequiresAquaSystemAppearance = NO).
>>> On Sep 26, 2019, at 10:52 PM, Sergey Bylokhov <Sergey.Bylokhov at oracle.com> wrote:
>>> 
>>> On 9/26/19 6:17 pm, Alan Snyder wrote:
>>>> I have a LAF that supports dark mode, so I need this new behavior to be configurable. When using my LAF, the (user selected) default appearance should continue to be used.
>>> 
>>> I guess you L&F is working on jdk12? If yes then nothing will be changed for it.
>>> 
>>>>   Alan
>>>>> On Sep 26, 2019, at 5:38 PM, Sergey Bylokhov <Sergey.Bylokhov at oracle.com> wrote:
>>>>> 
>>>>> Hello.
>>>>> Please review the fix for JDK 14.
>>>>> 
>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8231438
>>>>> Fix: http://cr.openjdk.java.net/~serb/8231438/webrev.01
>>>>> 
>>>>> In jdk13 we started to use SDK 10.14 to build JDK, which automatically opt-in support of dark mode:
>>>>> --------------
>>>>> "The system assumes that apps linked against the macOS 10.14 or later SDK support both light and dark appearances"
>>>>> https://developer.apple.com/documentation/appkit/nsappearancecustomization/choosing_a_specific_appearance_for_your_macos_app?language=objc
>>>>> --------------
>>>>> 
>>>>> Unfortunately we dark mode still unsupported by the AWT/Swing, because of:
>>>>> - JavaRuntimeSupport Framework which is used by the Aqua L&F to draw the "native"
>>>>>   appearance does not provide "dark mode" appearance, the bug is filed to Apple.
>>>>>   https://bugs.openjdk.java.net/browse/JDK-8228555
>>>>> - In a few places, we mix the "native" colors used by the system and default colors
>>>>>   used by the Swing. For example, we may use a transparent white selection "native"
>>>>>   color which is invisible on top of white text fields.
>>>>> 
>>>>> While the bugs above are not fixed we may opt-out the dark mode:
>>>>> -------------
>>>>> Supporting Dark Mode is strongly encouraged. Use the NSRequiresAquaSystemAppearance key to opt out temporarily only while you work on improvements to your app's Dark Mode support. If you do not plan to support a dark appearance at all, apply a light appearance to your entire app, as described in Assign a Specific Appearance to Your App.
>>>>> https://developer.apple.com/documentation/appkit/nsappearancecustomization/choosing_a_specific_appearance_for_your_macos_app?language=objc
>>>>> -------------
>>>>> 
>>>>> I tried to disable it via plist.info but it does not work for "java -jar" case, so I disabled it in the code
>>>>> Some constants in one test were updated to work on dark and light mode, but an updated test still reproduce the initial bug.
>>>>> 
>>>>> 
>>>>> -- 
>>>>> Best regards, Sergey.
>>>>> 
>>> 
>>> 
>>> -- 
>>> Best regards, Sergey.
>>> 
> 
> 
> -- 
> Best regards, Sergey.
> 


From Sergey.Bylokhov at oracle.com  Sun Sep 29 05:57:58 2019
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Sat, 28 Sep 2019 22:57:58 -0700
Subject: <AWT Dev> [14] Review Request: 7124404 [macosx] no
 awt.multiClickInterval desktop property
Message-ID: <9ec4082e-cf4c-095d-42f4-1274dbd0a5de@oracle.com>

Hello.
Please review the fix for JDK 14.

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

The desktop property "awt.multiClickInterval" is implemented on macOS
via [NSEvent doubleClickInterval]:
https://developer.apple.com/documentation/appkit/nsevent/1528384-doubleclickinterval?language=objc

The test is reimplemented and open.

-- 
Best regards, Sergey.

From philip.race at oracle.com  Mon Sep 30 01:25:24 2019
From: philip.race at oracle.com (Philip Race)
Date: Sun, 29 Sep 2019 18:25:24 -0700
Subject: <AWT Dev> [14] RFR JDK-8214578: [macos] Problem with
 backslashes on macOS/JIS keyboard: Java ignores system settings
In-Reply-To: <5c2e1c9e-e4e9-431e-f30d-df0b42d0aeb2@oracle.com>
References: <651c2a3d-9491-ed19-e5f0-e57ed4071b25@oracle.com>
 <5D8B8E81.8090805@oracle.com>
 <5c2e1c9e-e4e9-431e-f30d-df0b42d0aeb2@oracle.com>
Message-ID: <5D915984.8000900@oracle.com>

Hi,


On 9/25/19, 10:30 PM, Prasanta Sadhukhan wrote:
>
> Hi Phil,
>
> On 25-Sep-19 9:27 PM, Philip Race wrote:
>> Prasanta,
>>
>> Can you please add your evaluation to the bug. Last comment from you 
>> in there is
>> "it's still not reproducible for me" which seems unlikely if you have 
>> a proposed fix.
>>
> I have added the evaluation in JBS.
>> Actually I am having some trouble understanding what you wrote below.
>> Questions in line.
>>
>> On 9/25/19, 4:18 AM, Prasanta Sadhukhan wrote:
>>> Hi All,
>>>
>>> Please review a fix for an issue where it is seen that Java apps 
>>> ignore system settings regarding handling yen key.
>>>
>>> If we use mac keyboard layout to use Japanese input source and 
>>> "Change Settings -> Keyboard -> Input Sources -> Japanese -> "??" 
>>> key generates -> \ (Backslash) "

OK So if you select Japanese and scroll down far enough in the panel to 
the right
there is a combo box menu with two options which control what code point 
is generated
by the key marked with the Yen.
According to David a Japanese keyboard has no \ key but programmers need 
that
and the Romaji single with Yen is actually not that widely used ...
So us not generating the \ by ignoring that setting is a real problem.


 > Proposed fix is to see if keyboard layout is Japanese (kotoeri) and \
 > codePoint is "\" then take it as complex codepoint and generate IME,

I am not sure if that would be considered hacky but it does seem to work.
The system selection is honoured in the test with your build.

Do we really have to query the keyboard type on every character inserted ?

Is there some level we can cache this ? Or is that an unsolvable problem 
if there are 2 keyboards ?

Also since you do this :

+    unichar codePoint = [useString characterAtIndex:0];

why can't we use the retrieved value here :-
+        ((utf8Length>  1)&&  [self isCodePointInUnicodeBlockNeedingIMEvent:[useString characterAtIndex:0]]) ||

?

-phil.
>>
>> "Japanese -> "??" key generates"
>>
>> What are you trying to say here with that -> ? Is that another level 
>> of setting or do
>> you mean after setting to Japanese and typing some key still 
>> generates backslash ?
>> Why does it say ??" ? That isn't a key, is it ?
>>
> "Change Settings -> Keyboard -> Input Sources -> Japanese -> "??" key 
> generates -> \ (Backslash) " is system setting you can set from 
> "System Preferences". I guess David Buck demoed this setting to you.
>>
>>> and Change Input method to Romaji and press "yen" symbol in Japanese 
>>> keyboard or "option+y" key combination in US keyboard
>>> Java app still interprets it as "yen" in JTextField
>>
>> Umm  .. "still interprets it as Yen" ? Isn't that what you wanted to 
>> happen ?
>>
> No, it should honour the system preference setting for "Japanese -> 
> "??" key generates". If it is "\", it should be "\", if it is "yen", 
> it should be "yen". Without the fix, it was always "yen" irrespective 
> of the above setting.
>>>
>>> Issue seems to happen due to fact when 
>>> NSTextInputClient.insertText() method is called, even though  "\" 
>>> codePoint is passed,
>>>
>>> but insertText() has a check for codePoint is complex or not, so in 
>>> this case, it is not complex, InputMethodEvent is not generated and 
>>> no "\" is inserted in JTextField.
>>
>> I am not sure I can parse this correctly
>>
>> "fact when" ? is where I start to get lost.
>> Can you restate it ?
>>
> When NSTextInputClient.insertText() method is called with "\" 
> codePoint with japanese as input source
> insertText() checks whether this codePoint is complex or not,
> so in this case, it is not complex, InputMethodEvent is not generated 
> and no "\" is inserted in JTextField.
>>>
>>> Proposed fix is to see if keyboard layout is Japanese (kotoeri) and 
>>> codePoint is "\" then take it as complex codepoint and generate IME,
>>
>> Why ? Is backslash special ?
>
> Actually, for japanese input source in US keybord layout, backslash 
> can have different connotation. It can be interpreted as backslash or 
> yen depending on system setting.
>
> Regards
>
> Prasanta
>
>>
>> -phil.
>>>
>>> so that whatever system setting is set for "yen" symbol, it is 
>>> correctly interpreted and inputted in CInputMethod.insertText() 
>>> method, to be seen in JTextField.
>>>
>>> The fix has been tested in US keyboard and Japanese keyboard.
>>>
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8214578
>>>
>>> webrev: http://cr.openjdk.java.net/~psadhukhan/8214578/webrev.0/
>>>
>>> Regards
>>> Prasanta
>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/awt-dev/attachments/20190929/15e8f05a/attachment.html>

From prasanta.sadhukhan at oracle.com  Mon Sep 30 06:47:55 2019
From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan)
Date: Mon, 30 Sep 2019 12:17:55 +0530
Subject: <AWT Dev> [14] RFR JDK-8214578: [macos] Problem with
 backslashes on macOS/JIS keyboard: Java ignores system settings
In-Reply-To: <5D915984.8000900@oracle.com>
References: <651c2a3d-9491-ed19-e5f0-e57ed4071b25@oracle.com>
 <5D8B8E81.8090805@oracle.com>
 <5c2e1c9e-e4e9-431e-f30d-df0b42d0aeb2@oracle.com>
 <5D915984.8000900@oracle.com>
Message-ID: <14638bcd-3a49-c2a6-a49e-3e302f7c0c81@oracle.com>

HI Phil,

I have cached the keyboard layout and used that (tested with US and 
Japanese input sources)

http://cr.openjdk.java.net/~psadhukhan/8214578/webrev.1/

Regards
Prasanta
On 30-Sep-19 6:55 AM, Philip Race wrote:
> Hi,
>
>
> On 9/25/19, 10:30 PM, Prasanta Sadhukhan wrote:
>>
>> Hi Phil,
>>
>> On 25-Sep-19 9:27 PM, Philip Race wrote:
>>> Prasanta,
>>>
>>> Can you please add your evaluation to the bug. Last comment from you 
>>> in there is
>>> "it's still not reproducible for me" which seems unlikely if you 
>>> have a proposed fix.
>>>
>> I have added the evaluation in JBS.
>>> Actually I am having some trouble understanding what you wrote below.
>>> Questions in line.
>>>
>>> On 9/25/19, 4:18 AM, Prasanta Sadhukhan wrote:
>>>> Hi All,
>>>>
>>>> Please review a fix for an issue where it is seen that Java apps 
>>>> ignore system settings regarding handling yen key.
>>>>
>>>> If we use mac keyboard layout to use Japanese input source and 
>>>> "Change Settings -> Keyboard -> Input Sources -> Japanese -> "??" 
>>>> key generates -> \ (Backslash) "
>
> OK So if you select Japanese and scroll down far enough in the panel 
> to the right
> there is a combo box menu with two options which control what code 
> point is generated
> by the key marked with the Yen.
> According to David a Japanese keyboard has no \ key but programmers 
> need that
> and the Romaji single with Yen is actually not that widely used ...
> So us not generating the \ by ignoring that setting is a real problem.
>
>
> > Proposed fix is to see if keyboard layout is Japanese (kotoeri) and \
> > codePoint is "\" then take it as complex codepoint and generate IME,
>
> I am not sure if that would be considered hacky but it does seem to work.
> The system selection is honoured in the test with your build.
>
> Do we really have to query the keyboard type on every character inserted ?
>
> Is there some level we can cache this ? Or is that an unsolvable 
> problem if there are 2 keyboards ?
>
> Also since you do this :
> + unichar codePoint = [useString characterAtIndex:0]; why can't we use 
> the retrieved value here :- + ((utf8Length > 1) && [self 
> isCodePointInUnicodeBlockNeedingIMEvent:[useString 
> characterAtIndex:0]]) ||
> ?
>
> -phil.
>>>
>>> "Japanese -> "??" key generates"
>>>
>>> What are you trying to say here with that -> ? Is that another level 
>>> of setting or do
>>> you mean after setting to Japanese and typing some key still 
>>> generates backslash ?
>>> Why does it say ??" ? That isn't a key, is it ?
>>>
>> "Change Settings -> Keyboard -> Input Sources -> Japanese -> "??" key 
>> generates -> \ (Backslash) " is system setting you can set from 
>> "System Preferences". I guess David Buck demoed this setting to you.
>>>
>>>> and Change Input method to Romaji and press "yen" symbol in 
>>>> Japanese keyboard or "option+y" key combination in US keyboard
>>>> Java app still interprets it as "yen" in JTextField
>>>
>>> Umm? .. "still interprets it as Yen" ? Isn't that what you wanted to 
>>> happen ?
>>>
>> No, it should honour the system preference setting for "Japanese -> 
>> "??" key generates". If it is "\", it should be "\", if it is "yen", 
>> it should be "yen". Without the fix, it was always "yen" irrespective 
>> of the above setting.
>>>>
>>>> Issue seems to happen due to fact when 
>>>> NSTextInputClient.insertText() method is called, even though? "\" 
>>>> codePoint is passed,
>>>>
>>>> but insertText() has a check for codePoint is complex or not, so in 
>>>> this case, it is not complex, InputMethodEvent is not generated and 
>>>> no "\" is inserted in JTextField.
>>>
>>> I am not sure I can parse this correctly
>>>
>>> "fact when" ? is where I start to get lost.
>>> Can you restate it ?
>>>
>> When NSTextInputClient.insertText() method is called with "\" 
>> codePoint with japanese as input source
>> insertText() checks whether this codePoint is complex or not,
>> so in this case, it is not complex, InputMethodEvent is not generated 
>> and no "\" is inserted in JTextField.
>>>>
>>>> Proposed fix is to see if keyboard layout is Japanese (kotoeri) and 
>>>> codePoint is "\" then take it as complex codepoint and generate IME,
>>>
>>> Why ? Is backslash special ?
>>
>> Actually, for japanese input source in US keybord layout, backslash 
>> can have different connotation. It can be interpreted as backslash or 
>> yen depending on system setting.
>>
>> Regards
>>
>> Prasanta
>>
>>>
>>> -phil.
>>>>
>>>> so that whatever system setting is set for "yen" symbol, it is 
>>>> correctly interpreted and inputted in CInputMethod.insertText() 
>>>> method, to be seen in JTextField.
>>>>
>>>> The fix has been tested in US keyboard and Japanese keyboard.
>>>>
>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8214578
>>>>
>>>> webrev: http://cr.openjdk.java.net/~psadhukhan/8214578/webrev.0/
>>>>
>>>> Regards
>>>> Prasanta
>>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/awt-dev/attachments/20190930/25e42308/attachment-0001.html>

From dmitry.markov at oracle.com  Mon Sep 30 12:37:38 2019
From: dmitry.markov at oracle.com (Dmitry Markov)
Date: Mon, 30 Sep 2019 13:37:38 +0100
Subject: <AWT Dev> [14] Review Request: 7124404 [macosx] no
 awt.multiClickInterval desktop property
In-Reply-To: <9ec4082e-cf4c-095d-42f4-1274dbd0a5de@oracle.com>
References: <9ec4082e-cf4c-095d-42f4-1274dbd0a5de@oracle.com>
Message-ID: <3B0712CD-E75C-4459-B385-3EFA69501D1E@oracle.com>

Hi Sergey,

The fix looks fine.
Just a minor remark - the function description in LWCToolkit.m says: ?Signature: ()Z ?; but the function returns int and not boolean. I don?t need a new webrev for that correction.

Thanks,
Dmitry

> On 29 Sep 2019, at 06:57, Sergey Bylokhov <Sergey.Bylokhov at oracle.com> wrote:
> 
> Hello.
> Please review the fix for JDK 14.
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-7124404
> Fix: http://cr.openjdk.java.net/~serb/7124404/webrev.01
> 
> The desktop property "awt.multiClickInterval" is implemented on macOS
> via [NSEvent doubleClickInterval]:
> https://developer.apple.com/documentation/appkit/nsevent/1528384-doubleclickinterval?language=objc
> 
> The test is reimplemented and open.
> 
> -- 
> Best regards, Sergey.


From philip.race at oracle.com  Mon Sep 30 15:55:02 2019
From: philip.race at oracle.com (Phil Race)
Date: Mon, 30 Sep 2019 08:55:02 -0700
Subject: <AWT Dev> [14] RFR JDK-8214578: [macos] Problem with
 backslashes on macOS/JIS keyboard: Java ignores system settings
In-Reply-To: <14638bcd-3a49-c2a6-a49e-3e302f7c0c81@oracle.com>
References: <651c2a3d-9491-ed19-e5f0-e57ed4071b25@oracle.com>
 <5D8B8E81.8090805@oracle.com>
 <5c2e1c9e-e4e9-431e-f30d-df0b42d0aeb2@oracle.com>
 <5D915984.8000900@oracle.com>
 <14638bcd-3a49-c2a6-a49e-3e302f7c0c81@oracle.com>
Message-ID: <66d21c4e-991f-45bd-c1bf-b2fc787e5b02@oracle.com>

If you mean you tested toggling between the two, with the same AWT 
window open
and it correctly picked up the changes, then I am fine with this (+1).

-phil.

On 9/29/19 11:47 PM, Prasanta Sadhukhan wrote:
>
> HI Phil,
>
> I have cached the keyboard layout and used that (tested with US and 
> Japanese input sources)
>
> http://cr.openjdk.java.net/~psadhukhan/8214578/webrev.1/
>
> Regards
> Prasanta
> On 30-Sep-19 6:55 AM, Philip Race wrote:
>> Hi,
>>
>>
>> On 9/25/19, 10:30 PM, Prasanta Sadhukhan wrote:
>>>
>>> Hi Phil,
>>>
>>> On 25-Sep-19 9:27 PM, Philip Race wrote:
>>>> Prasanta,
>>>>
>>>> Can you please add your evaluation to the bug. Last comment from 
>>>> you in there is
>>>> "it's still not reproducible for me" which seems unlikely if you 
>>>> have a proposed fix.
>>>>
>>> I have added the evaluation in JBS.
>>>> Actually I am having some trouble understanding what you wrote below.
>>>> Questions in line.
>>>>
>>>> On 9/25/19, 4:18 AM, Prasanta Sadhukhan wrote:
>>>>> Hi All,
>>>>>
>>>>> Please review a fix for an issue where it is seen that Java apps 
>>>>> ignore system settings regarding handling yen key.
>>>>>
>>>>> If we use mac keyboard layout to use Japanese input source and 
>>>>> "Change Settings -> Keyboard -> Input Sources -> Japanese -> "??" 
>>>>> key generates -> \ (Backslash) "
>>
>> OK So if you select Japanese and scroll down far enough in the panel 
>> to the right
>> there is a combo box menu with two options which control what code 
>> point is generated
>> by the key marked with the Yen.
>> According to David a Japanese keyboard has no \ key but programmers 
>> need that
>> and the Romaji single with Yen is actually not that widely used ...
>> So us not generating the \ by ignoring that setting is a real problem.
>>
>>
>> > Proposed fix is to see if keyboard layout is Japanese (kotoeri) and \
>> > codePoint is "\" then take it as complex codepoint and generate IME,
>>
>> I am not sure if that would be considered hacky but it does seem to work.
>> The system selection is honoured in the test with your build.
>>
>> Do we really have to query the keyboard type on every character 
>> inserted ?
>>
>> Is there some level we can cache this ? Or is that an unsolvable 
>> problem if there are 2 keyboards ?
>>
>> Also since you do this :
>> + unichar codePoint = [useString characterAtIndex:0]; why can't we 
>> use the retrieved value here :- + ((utf8Length > 1) && [self 
>> isCodePointInUnicodeBlockNeedingIMEvent:[useString 
>> characterAtIndex:0]]) ||
>> ?
>>
>> -phil.
>>>>
>>>> "Japanese -> "??" key generates"
>>>>
>>>> What are you trying to say here with that -> ? Is that another 
>>>> level of setting or do
>>>> you mean after setting to Japanese and typing some key still 
>>>> generates backslash ?
>>>> Why does it say ??" ? That isn't a key, is it ?
>>>>
>>> "Change Settings -> Keyboard -> Input Sources -> Japanese -> "??" 
>>> key generates -> \ (Backslash) " is system setting you can set from 
>>> "System Preferences". I guess David Buck demoed this setting to you.
>>>>
>>>>> and Change Input method to Romaji and press "yen" symbol in 
>>>>> Japanese keyboard or "option+y" key combination in US keyboard
>>>>> Java app still interprets it as "yen" in JTextField
>>>>
>>>> Umm? .. "still interprets it as Yen" ? Isn't that what you wanted 
>>>> to happen ?
>>>>
>>> No, it should honour the system preference setting for "Japanese -> 
>>> "??" key generates". If it is "\", it should be "\", if it is "yen", 
>>> it should be "yen". Without the fix, it was always "yen" 
>>> irrespective of the above setting.
>>>>>
>>>>> Issue seems to happen due to fact when 
>>>>> NSTextInputClient.insertText() method is called, even though? "\" 
>>>>> codePoint is passed,
>>>>>
>>>>> but insertText() has a check for codePoint is complex or not, so 
>>>>> in this case, it is not complex, InputMethodEvent is not generated 
>>>>> and no "\" is inserted in JTextField.
>>>>
>>>> I am not sure I can parse this correctly
>>>>
>>>> "fact when" ? is where I start to get lost.
>>>> Can you restate it ?
>>>>
>>> When NSTextInputClient.insertText() method is called with "\" 
>>> codePoint with japanese as input source
>>> insertText() checks whether this codePoint is complex or not,
>>> so in this case, it is not complex, InputMethodEvent is not 
>>> generated and no "\" is inserted in JTextField.
>>>>>
>>>>> Proposed fix is to see if keyboard layout is Japanese (kotoeri) 
>>>>> and codePoint is "\" then take it as complex codepoint and 
>>>>> generate IME,
>>>>
>>>> Why ? Is backslash special ?
>>>
>>> Actually, for japanese input source in US keybord layout, backslash 
>>> can have different connotation. It can be interpreted as backslash 
>>> or yen depending on system setting.
>>>
>>> Regards
>>>
>>> Prasanta
>>>
>>>>
>>>> -phil.
>>>>>
>>>>> so that whatever system setting is set for "yen" symbol, it is 
>>>>> correctly interpreted and inputted in CInputMethod.insertText() 
>>>>> method, to be seen in JTextField.
>>>>>
>>>>> The fix has been tested in US keyboard and Japanese keyboard.
>>>>>
>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8214578
>>>>>
>>>>> webrev: http://cr.openjdk.java.net/~psadhukhan/8214578/webrev.0/
>>>>>
>>>>> Regards
>>>>> Prasanta
>>>>>

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