From aghaisas at openjdk.java.net  Thu Jul  1 01:34:13 2021
From: aghaisas at openjdk.java.net (Ajit Ghaisas)
Date: Thu, 1 Jul 2021 01:34:13 GMT
Subject: [OpenJDK 2D-Dev] [jdk17] RFR: 8267602: [macos] [lanai]
 java/awt/PrintJob/Text/stringwidth.sh doesn't exit on cancelling print
 dialog [v2]
In-Reply-To: <-FZZ43SrkU-jrTHs8r2-nsFcNGqtIPMuYlSjO0SaeM4=.cca9ac80-7cd8-4dbc-8648-1b8dd1e865ca@github.com>
References: <igtGmLC3ndGDpnZ1qniB9T7XjTBQpmymeNIOw9PaPE4=.78711824-fead-4586-97bb-bd4c3c1fe781@github.com>
 <-FZZ43SrkU-jrTHs8r2-nsFcNGqtIPMuYlSjO0SaeM4=.cca9ac80-7cd8-4dbc-8648-1b8dd1e865ca@github.com>
Message-ID: <Obc3uowRDALRw_7bJNvdXTLKy-H7hwvAIpoOwYkUgsk=.c4074c1d-04e9-42d6-80b1-1fc9bfbfb78d@github.com>

On Wed, 30 Jun 2021 14:37:31 GMT, Jayathirth D V <jdv at openjdk.org> wrote:

>> Final blit operation in MTLLayer.blitTexture() is driven by CVDisplayLink in Metal.
>> In this test case we are hitting an invalid condition because of which we exit from MTLLayer.blitTexture(), but we are not stopping the CVDisplayLink. This is causing the CVDisplayLink callback to run in loop. Fix is to stop CVDisplayLink when we return without completing final blit operation in MTLLayer.blitTexture().
>> 
>> Sanity and performance analysis is green. More details in JBS.
>
> Jayathirth D V has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove stopDisplayLink call when nextDrawableCount is not zero

Marked as reviewed by aghaisas (Committer).

-------------

PR: https://git.openjdk.java.net/jdk17/pull/175

From jdv at openjdk.java.net  Thu Jul  1 03:02:02 2021
From: jdv at openjdk.java.net (Jayathirth D V)
Date: Thu, 1 Jul 2021 03:02:02 GMT
Subject: [OpenJDK 2D-Dev] [jdk17] RFR: 8267602: [macos] [lanai]
 java/awt/PrintJob/Text/stringwidth.sh doesn't exit on cancelling print
 dialog [v2]
In-Reply-To: <-FZZ43SrkU-jrTHs8r2-nsFcNGqtIPMuYlSjO0SaeM4=.cca9ac80-7cd8-4dbc-8648-1b8dd1e865ca@github.com>
References: <igtGmLC3ndGDpnZ1qniB9T7XjTBQpmymeNIOw9PaPE4=.78711824-fead-4586-97bb-bd4c3c1fe781@github.com>
 <-FZZ43SrkU-jrTHs8r2-nsFcNGqtIPMuYlSjO0SaeM4=.cca9ac80-7cd8-4dbc-8648-1b8dd1e865ca@github.com>
Message-ID: <5tpyTVL5JRy63EZ9rtkjnI3ogtSgYs_bkZtG4gVylog=.ef3f641e-b064-4b8c-96e3-87c9957aef55@github.com>

On Wed, 30 Jun 2021 14:37:31 GMT, Jayathirth D V <jdv at openjdk.org> wrote:

>> Final blit operation in MTLLayer.blitTexture() is driven by CVDisplayLink in Metal.
>> In this test case we are hitting an invalid condition because of which we exit from MTLLayer.blitTexture(), but we are not stopping the CVDisplayLink. This is causing the CVDisplayLink callback to run in loop. Fix is to stop CVDisplayLink when we return without completing final blit operation in MTLLayer.blitTexture().
>> 
>> Sanity and performance analysis is green. More details in JBS.
>
> Jayathirth D V has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove stopDisplayLink call when nextDrawableCount is not zero

Verified that all test run is green with latest commit also.

-------------

PR: https://git.openjdk.java.net/jdk17/pull/175

From jdv at openjdk.java.net  Thu Jul  1 03:05:04 2021
From: jdv at openjdk.java.net (Jayathirth D V)
Date: Thu, 1 Jul 2021 03:05:04 GMT
Subject: [OpenJDK 2D-Dev] [jdk17] Integrated: 8267602: [macos] [lanai]
 java/awt/PrintJob/Text/stringwidth.sh doesn't exit on cancelling print
 dialog
In-Reply-To: <igtGmLC3ndGDpnZ1qniB9T7XjTBQpmymeNIOw9PaPE4=.78711824-fead-4586-97bb-bd4c3c1fe781@github.com>
References: <igtGmLC3ndGDpnZ1qniB9T7XjTBQpmymeNIOw9PaPE4=.78711824-fead-4586-97bb-bd4c3c1fe781@github.com>
Message-ID: <tFAUMtOa2zLLCWtLIQKfGVZYx69kdc9wAigX__H5cCI=.f0e77d4d-f83c-4f59-9003-60a8f71cf754@github.com>

On Tue, 29 Jun 2021 17:34:00 GMT, Jayathirth D V <jdv at openjdk.org> wrote:

> Final blit operation in MTLLayer.blitTexture() is driven by CVDisplayLink in Metal.
> In this test case we are hitting an invalid condition because of which we exit from MTLLayer.blitTexture(), but we are not stopping the CVDisplayLink. This is causing the CVDisplayLink callback to run in loop. Fix is to stop CVDisplayLink when we return without completing final blit operation in MTLLayer.blitTexture().
> 
> Sanity and performance analysis is green. More details in JBS.

This pull request has now been integrated.

Changeset: f7ffd587
Author:    Jayathirth D V <jdv at openjdk.org>
URL:       https://git.openjdk.java.net/jdk17/commit/f7ffd5872d69633c89505ce3e4fef9df8293e76b
Stats:     6 lines in 1 file changed: 6 ins; 0 del; 0 mod

8267602: [macos] [lanai] java/awt/PrintJob/Text/stringwidth.sh doesn't exit on cancelling print dialog

Reviewed-by: aghaisas, serb

-------------

PR: https://git.openjdk.java.net/jdk17/pull/175

From jdv at openjdk.java.net  Thu Jul  1 10:14:00 2021
From: jdv at openjdk.java.net (Jayathirth D V)
Date: Thu, 1 Jul 2021 10:14:00 GMT
Subject: [OpenJDK 2D-Dev] [jdk17] RFR: 8266079: Lanai: AlphaComposite
 shows differences on Metal compared to OpenGL [v2]
In-Reply-To: <uLTCX_HaIt0PVRv4psEvWUaVD6JevtuQ4puSuQaA8Q8=.df26bb2b-18bb-4952-8465-d7ec21aa8dd2@github.com>
References: <a3xpk6ClZB2__CikIXazTo8cnlVr_ppS03q66O36uu8=.3cf9bb53-ddbf-40cf-8b1c-74a150945d89@github.com>
 <uLTCX_HaIt0PVRv4psEvWUaVD6JevtuQ4puSuQaA8Q8=.df26bb2b-18bb-4952-8465-d7ec21aa8dd2@github.com>
Message-ID: <ZjyWELQOiuuAxIIl3xcCTC2EzCPs_TnxT9yuenql7aQ=.7e88e00e-931c-4fba-aac5-ff710a30e481@github.com>

On Wed, 23 Jun 2021 12:15:03 GMT, Alexey Ushakov <avu at openjdk.org> wrote:

>> Implemented blit via compute kernel
>
> Alexey Ushakov has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision:
> 
>   8266079: Lanai: AlphaComposite shows differences on Metal compared to OpenGL
>   
>   Keep MTLLayer opacity in sync with window content view

All test run is green with latest commit.

-------------

PR: https://git.openjdk.java.net/jdk17/pull/62

From github.com+10835776+stsypanov at openjdk.java.net  Thu Jul  1 10:38:28 2021
From: github.com+10835776+stsypanov at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=)
Date: Thu, 1 Jul 2021 10:38:28 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8268764: Use Long.hashCode() instead of
 int-cast where applicable [v2]
In-Reply-To: <ZVcup6_4t_d6djkaIRuX8kk7qs7iUSBdvfTS2CwJR3Y=.fa4ac0b9-41df-4ade-8c38-7f262e5145f3@github.com>
References: <FWTqr_PuocBt9WX9bDw7_ugW8N818tZqV8O03ziXG20=.098ec08a-cb98-4f3a-8f83-fde4221ba583@github.com>
 <ZVcup6_4t_d6djkaIRuX8kk7qs7iUSBdvfTS2CwJR3Y=.fa4ac0b9-41df-4ade-8c38-7f262e5145f3@github.com>
Message-ID: <HB1z1cJI9L5pqd_WmVvj9vi018gqtImK_DEuX-sUtP8=.9ae2c48b-797f-4cd6-99ae-700daa4d8e55@github.com>

On Wed, 30 Jun 2021 11:49:51 GMT, ?????? ??????? <github.com+10835776+stsypanov at openjdk.org> wrote:

>> In some JDK classes there's still the following hashCode() implementation:
>> 
>> long objNum;
>> 
>> public int hashCode() {
>>     return (int) objNum;
>> }
>> 
>> This outdated expression should be replaced with Long.hashCode(long) as it
>> 
>> - uses all bits of the original value, does not discard any information upfront. For example, depending on how you are generating the IDs, the upper bits could change more frequently (or the opposite).
>> 
>> - does not introduce any bias towards values with more ones (zeros), as it would be the case if the two halves were combined with an OR (AND) operation.
>> 
>> See https://stackoverflow.com/a/4045083
>> 
>> This is related to https://github.com/openjdk/jdk/pull/4309
>
> ?????? ??????? has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision:
> 
>  - Merge branch 'master' into 8268764
>  - 8268764: Use Long.hashCode() instead of int-cast where applicable

Hi Kevin, thanks for review! I've updated copy-right year

-------------

PR: https://git.openjdk.java.net/jdk/pull/4491

From github.com+10835776+stsypanov at openjdk.java.net  Thu Jul  1 10:38:24 2021
From: github.com+10835776+stsypanov at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=)
Date: Thu, 1 Jul 2021 10:38:24 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8268764: Use Long.hashCode() instead of
 int-cast where applicable [v3]
In-Reply-To: <FWTqr_PuocBt9WX9bDw7_ugW8N818tZqV8O03ziXG20=.098ec08a-cb98-4f3a-8f83-fde4221ba583@github.com>
References: <FWTqr_PuocBt9WX9bDw7_ugW8N818tZqV8O03ziXG20=.098ec08a-cb98-4f3a-8f83-fde4221ba583@github.com>
Message-ID: <ebvBjXWBYHat1Sel4UzveO8VLsyKMKdbbJ4BaMjcnJk=.4ed164b0-43d8-4668-b0f5-d90209d79fb7@github.com>

> In some JDK classes there's still the following hashCode() implementation:
> 
> long objNum;
> 
> public int hashCode() {
>     return (int) objNum;
> }
> 
> This outdated expression should be replaced with Long.hashCode(long) as it
> 
> - uses all bits of the original value, does not discard any information upfront. For example, depending on how you are generating the IDs, the upper bits could change more frequently (or the opposite).
> 
> - does not introduce any bias towards values with more ones (zeros), as it would be the case if the two halves were combined with an OR (AND) operation.
> 
> See https://stackoverflow.com/a/4045083
> 
> This is related to https://github.com/openjdk/jdk/pull/4309

?????? ??????? has updated the pull request incrementally with one additional commit since the last revision:

  8268764: Update copy-right year

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4491/files
  - new: https://git.openjdk.java.net/jdk/pull/4491/files/12a1d3ac..932c26ad

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4491&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4491&range=01-02

  Stats: 6 lines in 6 files changed: 0 ins; 0 del; 6 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4491.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4491/head:pull/4491

PR: https://git.openjdk.java.net/jdk/pull/4491

From kevinw at openjdk.java.net  Thu Jul  1 11:39:00 2021
From: kevinw at openjdk.java.net (Kevin Walls)
Date: Thu, 1 Jul 2021 11:39:00 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8268764: Use Long.hashCode() instead of
 int-cast where applicable [v3]
In-Reply-To: <ebvBjXWBYHat1Sel4UzveO8VLsyKMKdbbJ4BaMjcnJk=.4ed164b0-43d8-4668-b0f5-d90209d79fb7@github.com>
References: <FWTqr_PuocBt9WX9bDw7_ugW8N818tZqV8O03ziXG20=.098ec08a-cb98-4f3a-8f83-fde4221ba583@github.com>
 <ebvBjXWBYHat1Sel4UzveO8VLsyKMKdbbJ4BaMjcnJk=.4ed164b0-43d8-4668-b0f5-d90209d79fb7@github.com>
Message-ID: <RNAM2x8XAZGcoB3x5XrGJrXRre7sU01v9IL1OyljLhA=.98fc305e-6ec4-470b-8f8b-3942e87ffced@github.com>

On Thu, 1 Jul 2021 10:38:24 GMT, ?????? ??????? <github.com+10835776+stsypanov at openjdk.org> wrote:

>> In some JDK classes there's still the following hashCode() implementation:
>> 
>> long objNum;
>> 
>> public int hashCode() {
>>     return (int) objNum;
>> }
>> 
>> This outdated expression should be replaced with Long.hashCode(long) as it
>> 
>> - uses all bits of the original value, does not discard any information upfront. For example, depending on how you are generating the IDs, the upper bits could change more frequently (or the opposite).
>> 
>> - does not introduce any bias towards values with more ones (zeros), as it would be the case if the two halves were combined with an OR (AND) operation.
>> 
>> See https://stackoverflow.com/a/4045083
>> 
>> This is related to https://github.com/openjdk/jdk/pull/4309
>
> ?????? ??????? has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8268764: Update copy-right year

Marked as reviewed by kevinw (Committer).

OK, one more (C) in src/jdk.jdi/share/classes/com/sun/tools/jdi/ReferenceTypeImpl.java and done. 8-)
Needs a second Review before integrating, thanks.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4491

From github.com+10835776+stsypanov at openjdk.java.net  Thu Jul  1 12:19:53 2021
From: github.com+10835776+stsypanov at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=)
Date: Thu, 1 Jul 2021 12:19:53 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8268764: Use Long.hashCode() instead of
 int-cast where applicable [v4]
In-Reply-To: <FWTqr_PuocBt9WX9bDw7_ugW8N818tZqV8O03ziXG20=.098ec08a-cb98-4f3a-8f83-fde4221ba583@github.com>
References: <FWTqr_PuocBt9WX9bDw7_ugW8N818tZqV8O03ziXG20=.098ec08a-cb98-4f3a-8f83-fde4221ba583@github.com>
Message-ID: <eciHLB1bKgy02_eV0d-Y-RiECZshzMxHakK2ZaUhFk0=.298fe17f-0913-4f1e-8eba-4587c28b05b1@github.com>

> In some JDK classes there's still the following hashCode() implementation:
> 
> long objNum;
> 
> public int hashCode() {
>     return (int) objNum;
> }
> 
> This outdated expression should be replaced with Long.hashCode(long) as it
> 
> - uses all bits of the original value, does not discard any information upfront. For example, depending on how you are generating the IDs, the upper bits could change more frequently (or the opposite).
> 
> - does not introduce any bias towards values with more ones (zeros), as it would be the case if the two halves were combined with an OR (AND) operation.
> 
> See https://stackoverflow.com/a/4045083
> 
> This is related to https://github.com/openjdk/jdk/pull/4309

?????? ??????? has updated the pull request incrementally with one additional commit since the last revision:

  8268764: Update copy-right year

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4491/files
  - new: https://git.openjdk.java.net/jdk/pull/4491/files/932c26ad..20ad76be

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4491&range=03
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4491&range=02-03

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4491.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4491/head:pull/4491

PR: https://git.openjdk.java.net/jdk/pull/4491

From github.com+10835776+stsypanov at openjdk.java.net  Thu Jul  1 12:19:55 2021
From: github.com+10835776+stsypanov at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=)
Date: Thu, 1 Jul 2021 12:19:55 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8268764: Use Long.hashCode() instead of
 int-cast where applicable [v3]
In-Reply-To: <ebvBjXWBYHat1Sel4UzveO8VLsyKMKdbbJ4BaMjcnJk=.4ed164b0-43d8-4668-b0f5-d90209d79fb7@github.com>
References: <FWTqr_PuocBt9WX9bDw7_ugW8N818tZqV8O03ziXG20=.098ec08a-cb98-4f3a-8f83-fde4221ba583@github.com>
 <ebvBjXWBYHat1Sel4UzveO8VLsyKMKdbbJ4BaMjcnJk=.4ed164b0-43d8-4668-b0f5-d90209d79fb7@github.com>
Message-ID: <KfVPBIhy44IKY4Nq3-UmI69sQPfr0Fb2oz_0jgykjfQ=.2edc1651-5efb-43d7-8ac6-5ca82e87713d@github.com>

On Thu, 1 Jul 2021 10:38:24 GMT, ?????? ??????? <github.com+10835776+stsypanov at openjdk.org> wrote:

>> In some JDK classes there's still the following hashCode() implementation:
>> 
>> long objNum;
>> 
>> public int hashCode() {
>>     return (int) objNum;
>> }
>> 
>> This outdated expression should be replaced with Long.hashCode(long) as it
>> 
>> - uses all bits of the original value, does not discard any information upfront. For example, depending on how you are generating the IDs, the upper bits could change more frequently (or the opposite).
>> 
>> - does not introduce any bias towards values with more ones (zeros), as it would be the case if the two halves were combined with an OR (AND) operation.
>> 
>> See https://stackoverflow.com/a/4045083
>> 
>> This is related to https://github.com/openjdk/jdk/pull/4309
>
> ?????? ??????? has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8268764: Update copy-right year

Right, done!

-------------

PR: https://git.openjdk.java.net/jdk/pull/4491

From jwilhelm at openjdk.java.net  Fri Jul  2 00:25:29 2021
From: jwilhelm at openjdk.java.net (Jesper Wilhelmsson)
Date: Fri, 2 Jul 2021 00:25:29 GMT
Subject: [OpenJDK 2D-Dev] RFR: Merge jdk17
Message-ID: <TUjEwZq1CJKqY5Om5LvjGRrePb-6rZkJDxuLEA3bZB8=.50845890-a4f8-49a6-9f48-bc2897ffc752@github.com>

Forwardport JDK 17 -> JDK 18

-------------

Commit messages:
 - Merge
 - 8269745: [JVMCI] restore original qualified exports to Graal
 - 8268566: java/foreign/TestResourceScope.java timed out
 - 8260684: vmTestbase/gc/gctests/PhantomReference/phantom002/TestDescription.java timed out
 - 8269580: assert(is_valid()) failed: invalid register (-1)
 - 8269704: Typo in j.t.Normalizer.normalize()
 - 8269354: javac crashes when processing parenthesized pattern in instanceof
 - 8269285: Crash/miscompile in CallGenerator::for_method_handle_inline after JDK-8191998
 - 8269088: C2 fails with assert(!n->is_Store() && !n->is_LoadStore()) failed: no node with a side effect
 - 8269230: C2: main loop in micro benchmark never executed
 - ... and 3 more: https://git.openjdk.java.net/jdk/compare/de61328d...5515a992

The webrevs contain the adjustments done while merging with regards to each parent branch:
 - master: https://webrevs.openjdk.java.net/?repo=jdk&pr=4661&range=00.0
 - jdk17: https://webrevs.openjdk.java.net/?repo=jdk&pr=4661&range=00.1

Changes: https://git.openjdk.java.net/jdk/pull/4661/files
  Stats: 996 lines in 26 files changed: 843 ins; 64 del; 89 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4661.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4661/head:pull/4661

PR: https://git.openjdk.java.net/jdk/pull/4661

From jwilhelm at openjdk.java.net  Fri Jul  2 01:12:34 2021
From: jwilhelm at openjdk.java.net (Jesper Wilhelmsson)
Date: Fri, 2 Jul 2021 01:12:34 GMT
Subject: [OpenJDK 2D-Dev] RFR: Merge jdk17 [v2]
In-Reply-To: <TUjEwZq1CJKqY5Om5LvjGRrePb-6rZkJDxuLEA3bZB8=.50845890-a4f8-49a6-9f48-bc2897ffc752@github.com>
References: <TUjEwZq1CJKqY5Om5LvjGRrePb-6rZkJDxuLEA3bZB8=.50845890-a4f8-49a6-9f48-bc2897ffc752@github.com>
Message-ID: <uKN02bBiFcW-sCGWUPDQ48YZM6qeSPLnGp-Rvlg6rCE=.55740632-bafe-4584-a4ec-f54d3cd4dfb4@github.com>

> Forwardport JDK 17 -> JDK 18

Jesper Wilhelmsson has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 133 commits:

 - Merge
 - 8225559: assertion error at TransTypes.visitApply
   
   Reviewed-by: sadayapalam, jlahoda
 - 8268960: com/sun/net/httpserver/Headers.java: Ensure mutators normalize keys and disallow null for keys and values
   
   Reviewed-by: chegar, dfuchs, michaelm
 - 8267307: Introduce new client property for XAWT: xawt.mwm_decor_title
   
   Reviewed-by: azvegint, serb
 - 8133873: Simplify {Register,Unregister}NMethodOopClosure
   
   Reviewed-by: tschatzl, kbarrett
 - 8268298: jdk/jfr/api/consumer/log/TestVerbosity.java fails: unexpected log message
   
   Reviewed-by: egahlin
 - 8266746: C1: Replace UnsafeGetRaw with UnsafeGet when setting up OSR entry block
   
   Replace UnsafeGetRaw with UnsafeGetObject when setting up OSR entry block, and rename Unsafe{Get,Put}Object to Unsafe{Get,Put}
   
   Reviewed-by: thartmann, dlong, mdoerr
 - 8268870: Remove dead code in metaspaceShared
   
   Reviewed-by: tschatzl
 - Merge
 - 8268637: Update --release 17 symbol information for JDK 17 build 28
   
   Reviewed-by: iris
 - ... and 123 more: https://git.openjdk.java.net/jdk/compare/a4d2a9a7...5515a992

-------------

Changes: https://git.openjdk.java.net/jdk/pull/4661/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4661&range=01
  Stats: 32483 lines in 677 files changed: 18918 ins; 11377 del; 2188 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4661.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4661/head:pull/4661

PR: https://git.openjdk.java.net/jdk/pull/4661

From jwilhelm at openjdk.java.net  Fri Jul  2 01:12:36 2021
From: jwilhelm at openjdk.java.net (Jesper Wilhelmsson)
Date: Fri, 2 Jul 2021 01:12:36 GMT
Subject: [OpenJDK 2D-Dev] Integrated: Merge jdk17
In-Reply-To: <TUjEwZq1CJKqY5Om5LvjGRrePb-6rZkJDxuLEA3bZB8=.50845890-a4f8-49a6-9f48-bc2897ffc752@github.com>
References: <TUjEwZq1CJKqY5Om5LvjGRrePb-6rZkJDxuLEA3bZB8=.50845890-a4f8-49a6-9f48-bc2897ffc752@github.com>
Message-ID: <9541FIty7ivYR6t4zu5TZr5R_tIsqCHUaP4Wmo7q1nM=.6563c5be-64bb-40aa-a0e4-4facdfb85b2c@github.com>

On Fri, 2 Jul 2021 00:18:55 GMT, Jesper Wilhelmsson <jwilhelm at openjdk.org> wrote:

> Forwardport JDK 17 -> JDK 18

This pull request has now been integrated.

Changeset: b0e18679
Author:    Jesper Wilhelmsson <jwilhelm at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/b0e186792e816be30347dacfd88b8e55476584e7
Stats:     996 lines in 26 files changed: 843 ins; 64 del; 89 mod

Merge

-------------

PR: https://git.openjdk.java.net/jdk/pull/4661

From serb at openjdk.java.net  Fri Jul  2 04:06:03 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Fri, 2 Jul 2021 04:06:03 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8269223: -Xcheck:jni WARNINGs working
 with fonts on Linux [v2]
In-Reply-To: <8Rk4Vnlp_DCPQ8nocSevcUwS2QOUMfYsThZZAY4tL4Y=.a7cc56ae-b10a-4a79-b419-9e29273d51da@github.com>
References: <9qME86kmJADg8GimR2jWTt831LWYfE3J19jrxKtrNS0=.1a62b00d-fbba-4cb3-aa28-450ab935d239@github.com>
 <8Rk4Vnlp_DCPQ8nocSevcUwS2QOUMfYsThZZAY4tL4Y=.a7cc56ae-b10a-4a79-b419-9e29273d51da@github.com>
Message-ID: <3iuAPD1hs6bPOOJSIwkafCPgJXyg7VR7s6bAQgPDrrg=.457714f3-d28f-4807-a9e3-e5a2f07e87a8@github.com>

On Wed, 30 Jun 2021 10:42:44 GMT, Maxim Kartashev <github.com+28651297+mkartashev at openjdk.org> wrote:

>> Added an `ExceptionCheck()` followed by `ExceptionDescribe()` and `ExceptionClear()` immediately after the Java calls made from the callback function `ReadTTFontFileFunc()` in `freetypeScaler.c`. 
>> 
>> The exception(s) need to be cleared because we're not returning immediately to Java that would've been able to handle them gracefully. And in order not to loose the exception entirely (even though the return value would also indicate an error condition), print out the exception with `ExceptionDescribe()` to aid in debugging.
>
> Maxim Kartashev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Addressed PR comments
>   
>   1. Allowed test to run on any platform.
>   2. Trimmed comments to fit in with 80 columns.
>   3. Removed unnecessayr comments.
>   4. Made the ExceptionDescribe() calls conditional on the value of
>      FontUtilities.debugFonts()

Looks fine to me, I'll run the tests.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4572

From avu at openjdk.java.net  Fri Jul  2 17:49:17 2021
From: avu at openjdk.java.net (Alexey Ushakov)
Date: Fri, 2 Jul 2021 17:49:17 GMT
Subject: [OpenJDK 2D-Dev] [jdk17] RFR: 8266079: Lanai: AlphaComposite
 shows differences on Metal compared to OpenGL [v3]
In-Reply-To: <a3xpk6ClZB2__CikIXazTo8cnlVr_ppS03q66O36uu8=.3cf9bb53-ddbf-40cf-8b1c-74a150945d89@github.com>
References: <a3xpk6ClZB2__CikIXazTo8cnlVr_ppS03q66O36uu8=.3cf9bb53-ddbf-40cf-8b1c-74a150945d89@github.com>
Message-ID: <usmOxzkj1CF0pC-5Ow29otKIN83h0QWLtjJDbuA14x4=.f5f34034-7126-46c4-b73e-988aaa164bd6@github.com>

> Implemented blit via compute kernel

Alexey Ushakov has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision:

  8266079: Lanai: AlphaComposite shows differences on Metal compared to OpenGL
  
  Keep MTLLayer opacity in sync with window content view

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk17/pull/62/files
  - new: https://git.openjdk.java.net/jdk17/pull/62/files/3eef431e..361407b1

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk17&pr=62&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk17&pr=62&range=01-02

  Stats: 34 lines in 6 files changed: 28 ins; 5 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk17/pull/62.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk17 pull/62/head:pull/62

PR: https://git.openjdk.java.net/jdk17/pull/62

From duke at openjdk.java.net  Sat Jul  3 19:21:54 2021
From: duke at openjdk.java.net (duke)
Date: Sat, 3 Jul 2021 19:21:54 GMT
Subject: [OpenJDK 2D-Dev] Withdrawn: JDK-8263467: Incorrect double-checked
 locking in sun.java2d.CRenderer
In-Reply-To: <ZAfgFTYJDWkDgRxjL7ImOf0t73VhZXsnZdamRe76x6o=.adb2a7e2-d92c-4a10-85be-f7a15b287da6@github.com>
References: <ZAfgFTYJDWkDgRxjL7ImOf0t73VhZXsnZdamRe76x6o=.adb2a7e2-d92c-4a10-85be-f7a15b287da6@github.com>
Message-ID: <mE6ND1RPZ2_McPdIw69Qsp53jPRUJcYidFQlk_-rezo=.5c8618ff-fead-4917-b9c6-9a2d87582e68@github.com>

On Thu, 11 Mar 2021 19:13:47 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> SonarCloud reports multiple incorrect double-checked locking cases in `sun.java2d.CRenderer`. For example:
> 
> 
>   Arc2D arcToShape;
> 
>   ...
>             if (arcToShape == null) {
>                 synchronized (this) {
>                     if (arcToShape == null) {
>                         arcToShape = new Arc2D.Float();
>                     }
>                 }
>             }
> 
> 
> `Arc2D` contains fields that are not `final`. `arcToShape` is not `volatile`. This makes it an incorrect DCL.
> This code is used by Mac OS, do it would probably blow up some time later on M1.
> 
> This is the candidate fix that preserves the semantics. I am doing this fix blindly so far, without testing on real Mac OS. But maybe there is no need to do any of this, because the setter methods overwrite the contents of all these objects under their own sync. So, maybe we can just allocate those objects without DCL-backed caching and pass them in?

This pull request has been closed without being integrated.

-------------

PR: https://git.openjdk.java.net/jdk/pull/2948

From aghaisas at openjdk.java.net  Mon Jul  5 05:56:52 2021
From: aghaisas at openjdk.java.net (Ajit Ghaisas)
Date: Mon, 5 Jul 2021 05:56:52 GMT
Subject: [OpenJDK 2D-Dev] [jdk17] RFR: 8266079: Lanai: AlphaComposite
 shows differences on Metal compared to OpenGL [v3]
In-Reply-To: <usmOxzkj1CF0pC-5Ow29otKIN83h0QWLtjJDbuA14x4=.f5f34034-7126-46c4-b73e-988aaa164bd6@github.com>
References: <a3xpk6ClZB2__CikIXazTo8cnlVr_ppS03q66O36uu8=.3cf9bb53-ddbf-40cf-8b1c-74a150945d89@github.com>
 <usmOxzkj1CF0pC-5Ow29otKIN83h0QWLtjJDbuA14x4=.f5f34034-7126-46c4-b73e-988aaa164bd6@github.com>
Message-ID: <2l3cbAuO_7J82qboQR3gs_mK7Q80KT5Cc14iyB864kY=.d1986bad-1d4e-4de7-8589-7c1c4989cf3b@github.com>

On Fri, 2 Jul 2021 17:49:17 GMT, Alexey Ushakov <avu at openjdk.org> wrote:

>> Implemented blit via compute kernel
>
> Alexey Ushakov has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision:
> 
>   8266079: Lanai: AlphaComposite shows differences on Metal compared to OpenGL
>   
>   Keep MTLLayer opacity in sync with window content view

The latest version of this PR re-introduces [JDK-8243547](https://bugs.openjdk.java.net/browse/JDK-8243547)

-------------

PR: https://git.openjdk.java.net/jdk17/pull/62

From avu at openjdk.java.net  Mon Jul  5 08:08:52 2021
From: avu at openjdk.java.net (Alexey Ushakov)
Date: Mon, 5 Jul 2021 08:08:52 GMT
Subject: [OpenJDK 2D-Dev] [jdk17] RFR: 8266079: Lanai: AlphaComposite
 shows differences on Metal compared to OpenGL [v3]
In-Reply-To: <2l3cbAuO_7J82qboQR3gs_mK7Q80KT5Cc14iyB864kY=.d1986bad-1d4e-4de7-8589-7c1c4989cf3b@github.com>
References: <a3xpk6ClZB2__CikIXazTo8cnlVr_ppS03q66O36uu8=.3cf9bb53-ddbf-40cf-8b1c-74a150945d89@github.com>
 <usmOxzkj1CF0pC-5Ow29otKIN83h0QWLtjJDbuA14x4=.f5f34034-7126-46c4-b73e-988aaa164bd6@github.com>
 <2l3cbAuO_7J82qboQR3gs_mK7Q80KT5Cc14iyB864kY=.d1986bad-1d4e-4de7-8589-7c1c4989cf3b@github.com>
Message-ID: <9kKVMXqbcVL_cDr0cVZJEg8Nykpm-criK7deO-goUzo=.8d66ee8c-2a1c-4c20-8e90-277c494f7aa8@github.com>

On Mon, 5 Jul 2021 05:54:07 GMT, Ajit Ghaisas <aghaisas at openjdk.org> wrote:

> The latest version of this PR re-introduces JDK-8243547

 rechecked with the previous version, still reproducible.

-------------

PR: https://git.openjdk.java.net/jdk17/pull/62

From martin.desruisseaux at geomatys.com  Mon Jul  5 13:43:03 2021
From: martin.desruisseaux at geomatys.com (Martin Desruisseaux)
Date: Mon, 5 Jul 2021 15:43:03 +0200
Subject: [OpenJDK 2D-Dev] Relax pixelStride check inside
 PixelInterleavedSampleModel constructor?
Message-ID: <0e6a7f51-14e0-2402-83f4-b5e23790831b@geomatys.com>

Hello

PixelInterleavedSampleModel constructor has the following argument check 
at line 100:

    if (pixelStride*w > scanlineStride) {
         throw new IllegalArgumentException("Pixel stride times width must be less than or equal to the scanline stride");
    }

It seems to me that the following check would be more accurate:

    if (pixelStride*(w-1) + maxBandOff >= scanlineStride) {
         ...
    }

Rational: consider a subsampling operation where a new 
PixelInterleavedSampleModel is created for an image with a subset of the 
pixels of the original image. This is an operation similar to the 
existing PixelInterleavedSampleModel.createSubsetModel(int[] bands) 
method, which allows to create a view without coyping the DataBuffer 
content. Consider the following subsampling factors:

    sourceXSubsampling = 5
    sourceYSubsampling = 1

Consider an image of size 16 ? 3 pixels with a single band. In the 
illustration below, "X" and "-" are pixels from the source images and 
"X" are pixels retained in the subsampled image. Note that the last 
column of the source image is included in the subsampled image; it is 
important for this issue.

    X----X----X----X
    X----X----X----X
    X----X----X----X

A subsampled image view can be created with a 
PixelInterleavedSampleModel having a pixel stride of 5, a width of 4 and 
everything else identical, in particular a scanline stride of 16. It 
works well in the general case. But for the case illustrated above, an 
IllegalArgumentException is thrown. It can be seen from the following 
condition:

    pixelStride*w > scanlineStride
               5*4 > 16
                20 > 16
                true -> IllegalArgumentException

Above condition is equivalent to requiring image to be like that:

    X----X----X----X----

Instead of:

    X----X----X----X

The amended check proposed at the beginning of this email checks if 
there is enough room for storing the last sample value of a row, 
ignoring the remaining of pixel stride that are just skipped. The check 
in this case become:

    pixelStride*(w-1) + maxBandOff >= scanlineStride
    5*(4-1) + 0 >= 16
    15 >= 16
    false -> no exception thrown

I can create a pull request, but before spending time on it I would like 
to know if this is considered worth fixing?

 ??? Regards,

 ??? ??? Martin


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/2d-dev/attachments/20210705/ece6858a/attachment.htm>

From avu at openjdk.java.net  Mon Jul  5 15:41:34 2021
From: avu at openjdk.java.net (Alexey Ushakov)
Date: Mon, 5 Jul 2021 15:41:34 GMT
Subject: [OpenJDK 2D-Dev] [jdk17] RFR: 8266079: Lanai: AlphaComposite
 shows differences on Metal compared to OpenGL [v4]
In-Reply-To: <a3xpk6ClZB2__CikIXazTo8cnlVr_ppS03q66O36uu8=.3cf9bb53-ddbf-40cf-8b1c-74a150945d89@github.com>
References: <a3xpk6ClZB2__CikIXazTo8cnlVr_ppS03q66O36uu8=.3cf9bb53-ddbf-40cf-8b1c-74a150945d89@github.com>
Message-ID: <MqoXmj-zcOvIRpirWTm9m4PkT03unpRNO1zXHIlKG-0=.b4974fd7-0e6a-40e0-aeba-954616e02297@github.com>

> Implemented blit via compute kernel

Alexey Ushakov has updated the pull request incrementally with one additional commit since the last revision:

  8266079: Lanai: AlphaComposite shows differences on Metal compared to OpenGL
  
  Keep layer translucent for translucent windows

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk17/pull/62/files
  - new: https://git.openjdk.java.net/jdk17/pull/62/files/361407b1..e61914d3

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk17&pr=62&range=03
 - incr: https://webrevs.openjdk.java.net/?repo=jdk17&pr=62&range=02-03

  Stats: 5 lines in 2 files changed: 4 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk17/pull/62.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk17 pull/62/head:pull/62

PR: https://git.openjdk.java.net/jdk17/pull/62

From avu at openjdk.java.net  Mon Jul  5 15:55:20 2021
From: avu at openjdk.java.net (Alexey Ushakov)
Date: Mon, 5 Jul 2021 15:55:20 GMT
Subject: [OpenJDK 2D-Dev] [jdk17] RFR: 8266079: Lanai: AlphaComposite
 shows differences on Metal compared to OpenGL [v5]
In-Reply-To: <a3xpk6ClZB2__CikIXazTo8cnlVr_ppS03q66O36uu8=.3cf9bb53-ddbf-40cf-8b1c-74a150945d89@github.com>
References: <a3xpk6ClZB2__CikIXazTo8cnlVr_ppS03q66O36uu8=.3cf9bb53-ddbf-40cf-8b1c-74a150945d89@github.com>
Message-ID: <pppqA2YSjwiNvZPnUOul1cXtmDA_w0kgxkfv6rvV87A=.18e56cea-d453-4e6d-b87b-15fd696c3ea0@github.com>

> Implemented blit via compute kernel

Alexey Ushakov has updated the pull request incrementally with one additional commit since the last revision:

  8266079: Lanai: AlphaComposite shows differences on Metal compared to OpenGL
  
  Minor cleanup

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk17/pull/62/files
  - new: https://git.openjdk.java.net/jdk17/pull/62/files/e61914d3..cb4cf04c

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk17&pr=62&range=04
 - incr: https://webrevs.openjdk.java.net/?repo=jdk17&pr=62&range=03-04

  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk17/pull/62.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk17 pull/62/head:pull/62

PR: https://git.openjdk.java.net/jdk17/pull/62

From avu at openjdk.java.net  Mon Jul  5 15:55:20 2021
From: avu at openjdk.java.net (Alexey Ushakov)
Date: Mon, 5 Jul 2021 15:55:20 GMT
Subject: [OpenJDK 2D-Dev] [jdk17] RFR: 8266079: Lanai: AlphaComposite
 shows differences on Metal compared to OpenGL [v4]
In-Reply-To: <MqoXmj-zcOvIRpirWTm9m4PkT03unpRNO1zXHIlKG-0=.b4974fd7-0e6a-40e0-aeba-954616e02297@github.com>
References: <a3xpk6ClZB2__CikIXazTo8cnlVr_ppS03q66O36uu8=.3cf9bb53-ddbf-40cf-8b1c-74a150945d89@github.com>
 <MqoXmj-zcOvIRpirWTm9m4PkT03unpRNO1zXHIlKG-0=.b4974fd7-0e6a-40e0-aeba-954616e02297@github.com>
Message-ID: <oa7B9Y9uBU8nFB43O2jy_xpL9kBWD9H9VCYp38zOZ8Q=.6dcce6dc-a267-438f-973f-1b93e0e83356@github.com>

On Mon, 5 Jul 2021 15:41:34 GMT, Alexey Ushakov <avu at openjdk.org> wrote:

>> Implemented blit via compute kernel
>
> Alexey Ushakov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8266079: Lanai: AlphaComposite shows differences on Metal compared to OpenGL
>   
>   Keep layer translucent for translucent windows

> don't we need to do something like [mtlLayer setOpaque:(opaque == JNI_TRUE)]?

Done

-------------

PR: https://git.openjdk.java.net/jdk17/pull/62

From avu at openjdk.java.net  Mon Jul  5 15:55:21 2021
From: avu at openjdk.java.net (Alexey Ushakov)
Date: Mon, 5 Jul 2021 15:55:21 GMT
Subject: [OpenJDK 2D-Dev] [jdk17] RFR: 8266079: Lanai: AlphaComposite
 shows differences on Metal compared to OpenGL [v3]
In-Reply-To: <2l3cbAuO_7J82qboQR3gs_mK7Q80KT5Cc14iyB864kY=.d1986bad-1d4e-4de7-8589-7c1c4989cf3b@github.com>
References: <a3xpk6ClZB2__CikIXazTo8cnlVr_ppS03q66O36uu8=.3cf9bb53-ddbf-40cf-8b1c-74a150945d89@github.com>
 <usmOxzkj1CF0pC-5Ow29otKIN83h0QWLtjJDbuA14x4=.f5f34034-7126-46c4-b73e-988aaa164bd6@github.com>
 <2l3cbAuO_7J82qboQR3gs_mK7Q80KT5Cc14iyB864kY=.d1986bad-1d4e-4de7-8589-7c1c4989cf3b@github.com>
Message-ID: <8vWOzbaaoF3324zsU95c3yLDWF_stflCN9wuK3438Fo=.c4cb5afd-b7f1-41bc-b478-bf300ccc5856@github.com>

On Mon, 5 Jul 2021 05:54:07 GMT, Ajit Ghaisas <aghaisas at openjdk.org> wrote:

> The latest version of this PR re-introduces [JDK-8243547](https://bugs.openjdk.java.net/browse/JDK-8243547)

Fixed

-------------

PR: https://git.openjdk.java.net/jdk17/pull/62

From avu at openjdk.java.net  Mon Jul  5 15:55:27 2021
From: avu at openjdk.java.net (Alexey Ushakov)
Date: Mon, 5 Jul 2021 15:55:27 GMT
Subject: [OpenJDK 2D-Dev] [jdk17] RFR: 8266079: Lanai: AlphaComposite
 shows differences on Metal compared to OpenGL [v2]
In-Reply-To: <_ckINhzlkfObwA0ncLZCaoFzWItgZUyR-4Bg3evQYME=.890f1ed7-d977-4f2a-9125-3a0fef580440@github.com>
References: <a3xpk6ClZB2__CikIXazTo8cnlVr_ppS03q66O36uu8=.3cf9bb53-ddbf-40cf-8b1c-74a150945d89@github.com>
 <uLTCX_HaIt0PVRv4psEvWUaVD6JevtuQ4puSuQaA8Q8=.df26bb2b-18bb-4952-8465-d7ec21aa8dd2@github.com>
 <_ckINhzlkfObwA0ncLZCaoFzWItgZUyR-4Bg3evQYME=.890f1ed7-d977-4f2a-9125-3a0fef580440@github.com>
Message-ID: <rB8FFOVtzZUczob8DQVH-HVe3W69QjSYbTj3yUAZBds=.33505856-59c6-421d-bb6f-703556c19ce9@github.com>

On Mon, 28 Jun 2021 22:45:12 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> Alexey Ushakov has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR.
>
> src/java.desktop/macosx/native/libawt_lwawt/awt/CWrapper.m line 349:
> 
>> 347:         if ([window.contentView.layer isKindOfClass:[CAMetalLayer class]]) {
>> 348:             [window.contentView.layer setOpaque:(BOOL)opaque];
>> 349:         }
> 
> This class "CWrapper" is intended to be a simple wrapper on top of cocoa methods, the changed method above is expected to call the "NSWindow#setOpaque" only. So you need to place "window.contentView.layer setOpaque" in some other place(native or java).

Done

-------------

PR: https://git.openjdk.java.net/jdk17/pull/62

From serb at openjdk.java.net  Mon Jul  5 17:57:49 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Mon, 5 Jul 2021 17:57:49 GMT
Subject: [OpenJDK 2D-Dev] [jdk17] RFR: 8266079: Lanai: AlphaComposite
 shows differences on Metal compared to OpenGL [v5]
In-Reply-To: <pppqA2YSjwiNvZPnUOul1cXtmDA_w0kgxkfv6rvV87A=.18e56cea-d453-4e6d-b87b-15fd696c3ea0@github.com>
References: <a3xpk6ClZB2__CikIXazTo8cnlVr_ppS03q66O36uu8=.3cf9bb53-ddbf-40cf-8b1c-74a150945d89@github.com>
 <pppqA2YSjwiNvZPnUOul1cXtmDA_w0kgxkfv6rvV87A=.18e56cea-d453-4e6d-b87b-15fd696c3ea0@github.com>
Message-ID: <7wK3b4pEuQEqbhbfOVbuev54tk0GrPG0x-wbGlFLQeo=.23d33a05-7b43-49f1-947b-463a68d29918@github.com>

On Mon, 5 Jul 2021 15:55:20 GMT, Alexey Ushakov <avu at openjdk.org> wrote:

>> Implemented blit via compute kernel
>
> Alexey Ushakov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8266079: Lanai: AlphaComposite shows differences on Metal compared to OpenGL
>   
>   Minor cleanup

src/java.desktop/macosx/classes/sun/lwawt/macosx/CPlatformWindow.java line 340:

> 338:         if (!isTranslucent) {
> 339:             contentView.setWindowLayerOpaque(true);
> 340:         }

I think windowLayer should be always in sync with NSWindowOpaque state. And both should be changed together via setOpaque() method.

The change above will call the "setWindowLayerOpaque" twice:
 - LWWindowPeer()->platformWindow.initialize()->contentView.setWindowLayerOpaque(true)
 - LWWindowPeer()->initializeImpl()->setOpaque()->contentView.setWindowLayerOpaque()

-------------

PR: https://git.openjdk.java.net/jdk17/pull/62

From serb at openjdk.java.net  Tue Jul  6 02:06:54 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Tue, 6 Jul 2021 02:06:54 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8264666: Reuse
 Math.multiplyExact/addExact in the LCMSImageLayout class
In-Reply-To: <3iYQc9duUeEGRqm3146n4XhLQ_LY6YzXv-f-WgDu9sE=.a0a36297-4ce8-489c-9b50-43aede408e3b@github.com>
References: <3iYQc9duUeEGRqm3146n4XhLQ_LY6YzXv-f-WgDu9sE=.a0a36297-4ce8-489c-9b50-43aede408e3b@github.com>
Message-ID: <7KZnFze5t-CubGjEog8v44FSB3Wd9rw2ObW3D6LV-Xc=.ffb85e40-12fe-40bc-ab1a-4192c6024990@github.com>

On Fri, 2 Apr 2021 23:02:50 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> - The hand-crafted methods for addition and multiplication are replaced by the "Math" versions.
> - Cleanup: the usage of do/while(false) is removed

not now

-------------

PR: https://git.openjdk.java.net/jdk/pull/3333

From github.com+28651297+mkartashev at openjdk.java.net  Wed Jul  7 09:59:51 2021
From: github.com+28651297+mkartashev at openjdk.java.net (Maxim Kartashev)
Date: Wed, 7 Jul 2021 09:59:51 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8269223: -Xcheck:jni WARNINGs working
 with fonts on Linux [v2]
In-Reply-To: <3iuAPD1hs6bPOOJSIwkafCPgJXyg7VR7s6bAQgPDrrg=.457714f3-d28f-4807-a9e3-e5a2f07e87a8@github.com>
References: <9qME86kmJADg8GimR2jWTt831LWYfE3J19jrxKtrNS0=.1a62b00d-fbba-4cb3-aa28-450ab935d239@github.com>
 <8Rk4Vnlp_DCPQ8nocSevcUwS2QOUMfYsThZZAY4tL4Y=.a7cc56ae-b10a-4a79-b419-9e29273d51da@github.com>
 <3iuAPD1hs6bPOOJSIwkafCPgJXyg7VR7s6bAQgPDrrg=.457714f3-d28f-4807-a9e3-e5a2f07e87a8@github.com>
Message-ID: <MSkIknTWHwgtgs0igI9KX-bRUbZI20SpOEiXSF_i3gs=.ebdaa293-28a9-4411-bb98-a8bd3d55b6fb@github.com>

On Fri, 2 Jul 2021 04:02:45 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> Looks fine to me, I'll run the tests.

@mrserb Any news on that front?

-------------

PR: https://git.openjdk.java.net/jdk/pull/4572

From aghaisas at openjdk.java.net  Wed Jul  7 10:49:55 2021
From: aghaisas at openjdk.java.net (Ajit Ghaisas)
Date: Wed, 7 Jul 2021 10:49:55 GMT
Subject: [OpenJDK 2D-Dev] [jdk17] RFR: 8266079: Lanai: AlphaComposite
 shows differences on Metal compared to OpenGL [v5]
In-Reply-To: <pppqA2YSjwiNvZPnUOul1cXtmDA_w0kgxkfv6rvV87A=.18e56cea-d453-4e6d-b87b-15fd696c3ea0@github.com>
References: <a3xpk6ClZB2__CikIXazTo8cnlVr_ppS03q66O36uu8=.3cf9bb53-ddbf-40cf-8b1c-74a150945d89@github.com>
 <pppqA2YSjwiNvZPnUOul1cXtmDA_w0kgxkfv6rvV87A=.18e56cea-d453-4e6d-b87b-15fd696c3ea0@github.com>
Message-ID: <vccLw8XMJDmnAzWHwcOBI98x9BeBY81E0ifPo5nrhtI=.517bdafa-1c7e-40d8-8b61-d80fcf7ad374@github.com>

On Mon, 5 Jul 2021 15:55:20 GMT, Alexey Ushakov <avu at openjdk.org> wrote:

>> Implemented blit via compute kernel
>
> Alexey Ushakov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8266079: Lanai: AlphaComposite shows differences on Metal compared to OpenGL
>   
>   Minor cleanup

I verified that the latest version does not re-introduce JDK-8243547.
All automated test run is also green with this version.

-------------

PR: https://git.openjdk.java.net/jdk17/pull/62

From philip.race at oracle.com  Wed Jul  7 13:58:01 2021
From: philip.race at oracle.com (Philip Race)
Date: Wed, 7 Jul 2021 06:58:01 -0700
Subject: [OpenJDK 2D-Dev] FYI: A CFD for a Wayland project has been posted
 to discuss@openjdk.java.net
Message-ID: <e3beaf45-3034-438c-cf45-6e22d2527a5f@oracle.com>

https://mail.openjdk.java.net/pipermail/discuss/2021-July/005846.html

-phil.

From alexey.ushakov at jetbrains.com  Thu Jul  8 12:36:04 2021
From: alexey.ushakov at jetbrains.com (Alexey Ushakov)
Date: Thu, 8 Jul 2021 15:36:04 +0300
Subject: [OpenJDK 2D-Dev] <AWT Dev> FYI: A CFD for a Wayland project has
 been posted to discuss@openjdk.java.net
In-Reply-To: <e3beaf45-3034-438c-cf45-6e22d2527a5f@oracle.com>
References: <e3beaf45-3034-438c-cf45-6e22d2527a5f@oracle.com>
Message-ID: <49067D2A-A1F4-4D14-8330-7030810DC722@jetbrains.com>

> What other support is missing ? What platform APIs should the 
implementation  use ?
Currently we use XRender extension for many advanced operations in Java2D. Obviously it?s not available for pure Wayland apps. The only alternative for the moment is to use OpenGL pipeline. We can use it as mid term solution but for the long term we need to replace this outdated pipeline with something new. For example, we can use Vulkan api for more advanced rendering. Our recent effort to support Metal on Mac shows that current 2d architecture capable to support pipelines based on such advanced low level apis as Metal. Metal is quite similar to Vulkan.

Best Regards,
Alexey

> On 7 Jul 2021, at 16:58, Philip Race <philip.race at oracle.com> wrote:
> 
> https://mail.openjdk.java.net/pipermail/discuss/2021-July/005846.html
> 
> -phil.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/2d-dev/attachments/20210708/2948c22e/attachment.htm>

From serb at openjdk.java.net  Fri Jul  9 16:45:50 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Fri, 9 Jul 2021 16:45:50 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8269223: -Xcheck:jni WARNINGs working
 with fonts on Linux [v2]
In-Reply-To: <3iuAPD1hs6bPOOJSIwkafCPgJXyg7VR7s6bAQgPDrrg=.457714f3-d28f-4807-a9e3-e5a2f07e87a8@github.com>
References: <9qME86kmJADg8GimR2jWTt831LWYfE3J19jrxKtrNS0=.1a62b00d-fbba-4cb3-aa28-450ab935d239@github.com>
 <8Rk4Vnlp_DCPQ8nocSevcUwS2QOUMfYsThZZAY4tL4Y=.a7cc56ae-b10a-4a79-b419-9e29273d51da@github.com>
 <3iuAPD1hs6bPOOJSIwkafCPgJXyg7VR7s6bAQgPDrrg=.457714f3-d28f-4807-a9e3-e5a2f07e87a8@github.com>
Message-ID: <mVJkrQSpqjLqU0jqunEHspumvENdl9u8cv1Hd8jCwko=.d1b6279a-9be5-4509-9f7e-7d9e046561d9@github.com>

On Fri, 2 Jul 2021 04:02:45 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> Maxim Kartashev has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Addressed PR comments
>>   
>>   1. Allowed test to run on any platform.
>>   2. Trimmed comments to fit in with 80 columns.
>>   3. Removed unnecessayr comments.
>>   4. Made the ExceptionDescribe() calls conditional on the value of
>>      FontUtilities.debugFonts()
>
> Looks fine to me, I'll run the tests.

> @mrserb Any news on that front?

The new test fails on all platforms:
 - Linux/MacOS: The test should be marked as headful, otherwise it may run on headless systems where "No X11 DISPLAY variable was set"
 - WIndows: The jni warnings are generated in the log.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4572

From github.com+28651297+mkartashev at openjdk.java.net  Wed Jul 14 05:48:42 2021
From: github.com+28651297+mkartashev at openjdk.java.net (Maxim Kartashev)
Date: Wed, 14 Jul 2021 05:48:42 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8269223: -Xcheck:jni WARNINGs working
 with fonts on Linux [v3]
In-Reply-To: <9qME86kmJADg8GimR2jWTt831LWYfE3J19jrxKtrNS0=.1a62b00d-fbba-4cb3-aa28-450ab935d239@github.com>
References: <9qME86kmJADg8GimR2jWTt831LWYfE3J19jrxKtrNS0=.1a62b00d-fbba-4cb3-aa28-450ab935d239@github.com>
Message-ID: <9Ztykod0kHfKYCtYGKgLnhles7C4H2aoR0DH4RYYhPo=.0ebb1ee2-2bc2-4399-bdfc-01330722fa79@github.com>

> Added an `ExceptionCheck()` followed by `ExceptionDescribe()` and `ExceptionClear()` immediately after the Java calls made from the callback function `ReadTTFontFileFunc()` in `freetypeScaler.c`. 
> 
> The exception(s) need to be cleared because we're not returning immediately to Java that would've been able to handle them gracefully. And in order not to loose the exception entirely (even though the return value would also indicate an error condition), print out the exception with `ExceptionDescribe()` to aid in debugging.

Maxim Kartashev has updated the pull request incrementally with one additional commit since the last revision:

  1. Marked the test as headful so that it doesn't fail on a headless
  system.
  2. Added exception checks to Windows-specific code.

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4572/files
  - new: https://git.openjdk.java.net/jdk/pull/4572/files/d1bc82e8..9cc7c8ed

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4572&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4572&range=01-02

  Stats: 15 lines in 4 files changed: 9 ins; 0 del; 6 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4572.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4572/head:pull/4572

PR: https://git.openjdk.java.net/jdk/pull/4572

From kizune at openjdk.java.net  Wed Jul 14 11:27:23 2021
From: kizune at openjdk.java.net (Alexander Zuev)
Date: Wed, 14 Jul 2021 11:27:23 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8269637:
 javax/swing/JFileChooser/FileSystemView/SystemIconTest.java fails on
 windows
Message-ID: <YXKDCVQUe3t_-ZYbAN-9O-sfBce27YdPxcT7xKlc4RE=.39c78bec-38bf-440f-a161-cad249ad0682@github.com>

Make fallback code for inaccessible file to return multiresolution icon
Remove test from ProblemList

-------------

Commit messages:
 - 8269637: javax/swing/JFileChooser/FileSystemView/SystemIconTest.java fails on windows

Changes: https://git.openjdk.java.net/jdk/pull/4777/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4777&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8269637
  Stats: 11 lines in 2 files changed: 8 ins; 1 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4777.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4777/head:pull/4777

PR: https://git.openjdk.java.net/jdk/pull/4777

From aivanov at openjdk.java.net  Wed Jul 14 11:59:13 2021
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Wed, 14 Jul 2021 11:59:13 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8269637:
 javax/swing/JFileChooser/FileSystemView/SystemIconTest.java fails on
 windows
In-Reply-To: <YXKDCVQUe3t_-ZYbAN-9O-sfBce27YdPxcT7xKlc4RE=.39c78bec-38bf-440f-a161-cad249ad0682@github.com>
References: <YXKDCVQUe3t_-ZYbAN-9O-sfBce27YdPxcT7xKlc4RE=.39c78bec-38bf-440f-a161-cad249ad0682@github.com>
Message-ID: <jX9IgbWvhrdEX-fl_pGepEGfJzQr-omklGvp6RlvG4g=.887ce319-25d7-43f1-b8cf-9ed0dd7b710d@github.com>

On Wed, 14 Jul 2021 11:19:53 GMT, Alexander Zuev <kizune at openjdk.org> wrote:

> Make fallback code for inaccessible file to return multiresolution icon
> Remove test from ProblemList

So, essentially all the icons returned are MultiResolutionIcon even if there's only one icon, right?

-------------

PR: https://git.openjdk.java.net/jdk/pull/4777

From kizune at openjdk.java.net  Wed Jul 14 17:16:14 2021
From: kizune at openjdk.java.net (Alexander Zuev)
Date: Wed, 14 Jul 2021 17:16:14 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8269637:
 javax/swing/JFileChooser/FileSystemView/SystemIconTest.java fails on
 windows
In-Reply-To: <jX9IgbWvhrdEX-fl_pGepEGfJzQr-omklGvp6RlvG4g=.887ce319-25d7-43f1-b8cf-9ed0dd7b710d@github.com>
References: <YXKDCVQUe3t_-ZYbAN-9O-sfBce27YdPxcT7xKlc4RE=.39c78bec-38bf-440f-a161-cad249ad0682@github.com>
 <jX9IgbWvhrdEX-fl_pGepEGfJzQr-omklGvp6RlvG4g=.887ce319-25d7-43f1-b8cf-9ed0dd7b710d@github.com>
Message-ID: <ttBGdKwpTUy07-2TtVEXZJlge3LnaVoA172ZQ2-EDi0=.6b80da92-ae14-47cc-9837-71884ea4885a@github.com>

On Wed, 14 Jul 2021 11:56:15 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> So, essentially all the icons returned are MultiResolutionIcon even if there's only one icon, right?

It was a multiresolution icon even with one icon inside but only when the native and requested icon resolutions do not match. Now it will always be MRI even if file is inaccessible and there is a default icon in System32.dll that matches the requested resolution.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4777

From aivanov at openjdk.java.net  Wed Jul 14 17:20:13 2021
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Wed, 14 Jul 2021 17:20:13 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8269637:
 javax/swing/JFileChooser/FileSystemView/SystemIconTest.java fails on
 windows
In-Reply-To: <YXKDCVQUe3t_-ZYbAN-9O-sfBce27YdPxcT7xKlc4RE=.39c78bec-38bf-440f-a161-cad249ad0682@github.com>
References: <YXKDCVQUe3t_-ZYbAN-9O-sfBce27YdPxcT7xKlc4RE=.39c78bec-38bf-440f-a161-cad249ad0682@github.com>
Message-ID: <KbJbqSnvbATyMOJjlU_uw20E1L2yi808jhZysA8aEJg=.10b3dd34-814e-44e5-a93a-fb2b651926df@github.com>

On Wed, 14 Jul 2021 11:19:53 GMT, Alexander Zuev <kizune at openjdk.org> wrote:

> Make fallback code for inaccessible file to return multiresolution icon
> Remove test from ProblemList

Marked as reviewed by aivanov (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/4777

From kizune at openjdk.java.net  Wed Jul 14 18:29:16 2021
From: kizune at openjdk.java.net (Alexander Zuev)
Date: Wed, 14 Jul 2021 18:29:16 GMT
Subject: [OpenJDK 2D-Dev] Integrated: 8269637:
 javax/swing/JFileChooser/FileSystemView/SystemIconTest.java fails on
 windows
In-Reply-To: <YXKDCVQUe3t_-ZYbAN-9O-sfBce27YdPxcT7xKlc4RE=.39c78bec-38bf-440f-a161-cad249ad0682@github.com>
References: <YXKDCVQUe3t_-ZYbAN-9O-sfBce27YdPxcT7xKlc4RE=.39c78bec-38bf-440f-a161-cad249ad0682@github.com>
Message-ID: <Lz3gNA2f0aS4oeHMdysK3XN-wRp8dOQkgFe4LRot3uQ=.8210c08b-83ee-4c3f-be8c-87038d179a6c@github.com>

On Wed, 14 Jul 2021 11:19:53 GMT, Alexander Zuev <kizune at openjdk.org> wrote:

> Make fallback code for inaccessible file to return multiresolution icon
> Remove test from ProblemList

This pull request has now been integrated.

Changeset: a033866d
Author:    Alexander Zuev <kizune at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/a033866d786507db69ab75643684e617fd1f4ba2
Stats:     11 lines in 2 files changed: 8 ins; 1 del; 2 mod

8269637: javax/swing/JFileChooser/FileSystemView/SystemIconTest.java fails on windows

Reviewed-by: aivanov

-------------

PR: https://git.openjdk.java.net/jdk/pull/4777

From jdv at openjdk.java.net  Thu Jul 15 15:54:27 2021
From: jdv at openjdk.java.net (Jayathirth D V)
Date: Thu, 15 Jul 2021 15:54:27 GMT
Subject: [OpenJDK 2D-Dev] [jdk17] RFR: 8266079: Lanai: AlphaComposite
 shows differences on Metal compared to OpenGL [v3]
In-Reply-To: <8vWOzbaaoF3324zsU95c3yLDWF_stflCN9wuK3438Fo=.c4cb5afd-b7f1-41bc-b478-bf300ccc5856@github.com>
References: <a3xpk6ClZB2__CikIXazTo8cnlVr_ppS03q66O36uu8=.3cf9bb53-ddbf-40cf-8b1c-74a150945d89@github.com>
 <usmOxzkj1CF0pC-5Ow29otKIN83h0QWLtjJDbuA14x4=.f5f34034-7126-46c4-b73e-988aaa164bd6@github.com>
 <2l3cbAuO_7J82qboQR3gs_mK7Q80KT5Cc14iyB864kY=.d1986bad-1d4e-4de7-8589-7c1c4989cf3b@github.com>
 <8vWOzbaaoF3324zsU95c3yLDWF_stflCN9wuK3438Fo=.c4cb5afd-b7f1-41bc-b478-bf300ccc5856@github.com>
Message-ID: <Z3NQT2rDU9DM63w1rAG8_9_LNryldUwf-bGgN-duuC0=.cb741aec-6b54-49e8-b65a-183b34bc835c@github.com>

On Mon, 5 Jul 2021 15:51:46 GMT, Alexey Ushakov <avu at openjdk.org> wrote:

>> The latest version of this PR re-introduces [JDK-8243547](https://bugs.openjdk.java.net/browse/JDK-8243547)
>
>> The latest version of this PR re-introduces [JDK-8243547](https://bugs.openjdk.java.net/browse/JDK-8243547)
> 
> Fixed

@avu Since we are past RDP2, lets close this JDK17 PR and open new jdk-dev(18) PR to continue the review.

-------------

PR: https://git.openjdk.java.net/jdk17/pull/62

From maxim.kartashev at jetbrains.com  Thu Jul 15 16:53:15 2021
From: maxim.kartashev at jetbrains.com (Maxim Kartashev)
Date: Thu, 15 Jul 2021 19:53:15 +0300
Subject: [OpenJDK 2D-Dev] <AWT Dev> FYI: A CFD for a Wayland project has
 been posted to discuss@openjdk.java.net
In-Reply-To: <e3beaf45-3034-438c-cf45-6e22d2527a5f@oracle.com>
References: <e3beaf45-3034-438c-cf45-6e22d2527a5f@oracle.com>
Message-ID: <CAG0Tb0hryfRq3Ze2=XnVCuX5=q4SPy=4Cnt2NPVupAd3557pkg@mail.gmail.com>

> At that time Java for Linux will "mostly" run via the X11 compatibility layer

There's a quality-of-service problem with running via the compatibility layer as
under certain circumstances native X windows look blurry.

Users with small(ish) HiDPI displays tend to enable fractional scaling and with
that enabled (regardless of the actual scale), XWayland pretends that the screen
size is smaller and then pixel-stretches the resulting window according
to the global scale. This works as a temporary solution, but people get quickly
tired of looking at text that is blurry.

See https://gitlab.gnome.org/GNOME/mutter/-/issues/402 and
https://github.com/swaywm/sway/issues/5917 for some more details.



On Wed, Jul 7, 2021 at 4:59 PM Philip Race <philip.race at oracle.com> wrote:
>
> https://mail.openjdk.java.net/pipermail/discuss/2021-July/005846.html
>
> -phil.

From github.com+9004656+yaaz at openjdk.java.net  Thu Jul 15 17:38:42 2021
From: github.com+9004656+yaaz at openjdk.java.net (Nikita Gubarkov)
Date: Thu, 15 Jul 2021 17:38:42 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8269806: Emoji rendering on Linux
Message-ID: <TvYUntHbfOLa-Wdbsh5lpQo2jKzPIotPlUuwsqIcERc=.75104ec2-b82b-4d41-b96b-2f7378c7a97c@github.com>

It was implemented in JetBrains Runtime a year ago and was ported & refactored for this PR
It includes:
- Bitmap glyph loading via Freetype
- Manual scaling & transformation of bitmap glyphs with nearest-neighbor or bilinear-mipmap style algorithms depending on the text antialiasing hint
- Storing BGRA glyphs in glyph cache & rendering them as plain images, as currently used XRender text drawing functions doesn't support colored glyphs
- Small fixes in related code like null-checks which could cause NPE & comment typos

-------------

Commit messages:
 - 8269806: Emoji rendering on Linux

Changes: https://git.openjdk.java.net/jdk/pull/4798/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4798&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8269806
  Stats: 749 lines in 9 files changed: 555 ins; 51 del; 143 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4798.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4798/head:pull/4798

PR: https://git.openjdk.java.net/jdk/pull/4798

From weijun at openjdk.java.net  Fri Jul 16 20:58:08 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Fri, 16 Jul 2021 20:58:08 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8270859: Post JEP 411 refactoring: client
 libs with maximum covering > 10K
Message-ID: <9Wxw1cSmYDW0PLzPggKDLvoF8h_OPNd29x69FT89IOk=.06df777f-06a2-4fe1-b044-b319b78d8cb2@github.com>

This is the last part of Post JEP 411 refactoring that makes `@SuppressWarnings("removal")` more fine grained. This fix deals with all client libs annotations that covers more than 10K bytes of code.

-------------

Commit messages:
 - 8270859: Post JEP 411 refactoring: client libs with maximum covering > 10K

Changes: https://git.openjdk.java.net/jdk/pull/4815/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4815&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8270859
  Stats: 279 lines in 22 files changed: 146 ins; 96 del; 37 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4815.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4815/head:pull/4815

PR: https://git.openjdk.java.net/jdk/pull/4815

From github.com+1671049+vest at openjdk.java.net  Fri Jul 16 21:44:51 2021
From: github.com+1671049+vest at openjdk.java.net (Vest)
Date: Fri, 16 Jul 2021 21:44:51 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8270859: Post JEP 411 refactoring: client
 libs with maximum covering > 10K
In-Reply-To: <9Wxw1cSmYDW0PLzPggKDLvoF8h_OPNd29x69FT89IOk=.06df777f-06a2-4fe1-b044-b319b78d8cb2@github.com>
References: <9Wxw1cSmYDW0PLzPggKDLvoF8h_OPNd29x69FT89IOk=.06df777f-06a2-4fe1-b044-b319b78d8cb2@github.com>
Message-ID: <LkO4xq8qMYUeluQhjkLNhKBXlcjyGqVw4H2Cb2V_DTU=.1588f3ab-cbd0-4194-b23c-d461f1221983@github.com>

On Fri, 16 Jul 2021 20:52:08 GMT, Weijun Wang <weijun at openjdk.org> wrote:

> This is the last part of Post JEP 411 refactoring that makes `@SuppressWarnings("removal")` more fine grained. This fix deals with all client libs annotations that cover more than 10K bytes of code.

src/java.desktop/share/classes/javax/swing/ImageIcon.java line 124:

> 122:                 // We don't care about component.
> 123:                 // So don't prevent class initialisation.
> 124:                 e.printStackTrace();

I am not the reviewer, but I am curious. If we do not care about the exception, is it a right way to just print it to the console as it is? If people use loggers, they won?t be able to capture this stack trace.
thank you for your answer in advance.
p.s. I know it is not your code, but isn?t it a suitable time to improve this part?

-------------

PR: https://git.openjdk.java.net/jdk/pull/4815

From kcr at openjdk.java.net  Fri Jul 16 22:05:50 2021
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Fri, 16 Jul 2021 22:05:50 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8270859: Post JEP 411 refactoring: client
 libs with maximum covering > 10K
In-Reply-To: <LkO4xq8qMYUeluQhjkLNhKBXlcjyGqVw4H2Cb2V_DTU=.1588f3ab-cbd0-4194-b23c-d461f1221983@github.com>
References: <9Wxw1cSmYDW0PLzPggKDLvoF8h_OPNd29x69FT89IOk=.06df777f-06a2-4fe1-b044-b319b78d8cb2@github.com>
 <LkO4xq8qMYUeluQhjkLNhKBXlcjyGqVw4H2Cb2V_DTU=.1588f3ab-cbd0-4194-b23c-d461f1221983@github.com>
Message-ID: <6CzDn79NU1Z2-mXGthin5FZ0RoHxtPFhe1zSnDoQVxg=.20b080dd-cf22-47fa-b3b5-93fb7524c381@github.com>

On Fri, 16 Jul 2021 21:39:56 GMT, Vest <github.com+1671049+Vest at openjdk.org> wrote:

>> This is the last part of Post JEP 411 refactoring that makes `@SuppressWarnings("removal")` more fine grained. This fix deals with all client libs annotations that cover more than 10K bytes of code.
>
> src/java.desktop/share/classes/javax/swing/ImageIcon.java line 124:
> 
>> 122:                 // We don't care about component.
>> 123:                 // So don't prevent class initialisation.
>> 124:                 e.printStackTrace();
> 
> I am not the reviewer, but I am curious. If we do not care about the exception, is it a right way to just print it to the console as it is? If people use loggers, they won?t be able to capture this stack trace.
> thank you for your answer in advance.
> p.s. I know it is not your code, but isn?t it a suitable time to improve this part?

No. A refactoring change like this is the wrong time to make any unrelated changes. If such changes are a good idea, they should be done in a different bug with a separate pull request.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4815

From prr at openjdk.java.net  Sat Jul 17 02:00:51 2021
From: prr at openjdk.java.net (Phil Race)
Date: Sat, 17 Jul 2021 02:00:51 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8270859: Post JEP 411 refactoring: client
 libs with maximum covering > 10K
In-Reply-To: <9Wxw1cSmYDW0PLzPggKDLvoF8h_OPNd29x69FT89IOk=.06df777f-06a2-4fe1-b044-b319b78d8cb2@github.com>
References: <9Wxw1cSmYDW0PLzPggKDLvoF8h_OPNd29x69FT89IOk=.06df777f-06a2-4fe1-b044-b319b78d8cb2@github.com>
Message-ID: <eWkWQligjktwkzkX35fM9qt6nxyHA2l5iz2TUh9Fohs=.c7300b4b-1ff5-4785-9fe5-d4e75e77b6d2@github.com>

On Fri, 16 Jul 2021 20:52:08 GMT, Weijun Wang <weijun at openjdk.org> wrote:

> This is the last part of Post JEP 411 refactoring that makes `@SuppressWarnings("removal")` more fine grained. This fix deals with all client libs annotations that cover more than 10K bytes of code.

src/java.desktop/unix/classes/sun/print/PrintServiceLookupProvider.java line 130:

> 128:         }
> 129: 
> 130:         osname = System.getProperty("os.name");

I suppose that you are relying on the default security settings which allow access to this property ?
Do you have reason to believe that it is common to make this assumption in code in the JDK ?
Why take the chance ?

-------------

PR: https://git.openjdk.java.net/jdk/pull/4815

From prr at openjdk.java.net  Sat Jul 17 02:00:50 2021
From: prr at openjdk.java.net (Phil Race)
Date: Sat, 17 Jul 2021 02:00:50 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8270859: Post JEP 411 refactoring: client
 libs with maximum covering > 10K
In-Reply-To: <LkO4xq8qMYUeluQhjkLNhKBXlcjyGqVw4H2Cb2V_DTU=.1588f3ab-cbd0-4194-b23c-d461f1221983@github.com>
References: <9Wxw1cSmYDW0PLzPggKDLvoF8h_OPNd29x69FT89IOk=.06df777f-06a2-4fe1-b044-b319b78d8cb2@github.com>
 <LkO4xq8qMYUeluQhjkLNhKBXlcjyGqVw4H2Cb2V_DTU=.1588f3ab-cbd0-4194-b23c-d461f1221983@github.com>
Message-ID: <x5eAAfp6ZJoyOQD8tei4jPLoqeRkNDMQLLTHGgHugUU=.f8840854-4522-422c-a6a6-d42b193e8844@github.com>

On Fri, 16 Jul 2021 21:39:56 GMT, Vest <github.com+1671049+Vest at openjdk.org> wrote:

>> This is the last part of Post JEP 411 refactoring that makes `@SuppressWarnings("removal")` more fine grained. This fix deals with all client libs annotations that cover more than 10K bytes of code.
>
> src/java.desktop/share/classes/javax/swing/ImageIcon.java line 124:
> 
>> 122:                 // We don't care about component.
>> 123:                 // So don't prevent class initialisation.
>> 124:                 e.printStackTrace();
> 
> I am not the reviewer, but I am curious. If we do not care about the exception, is it a right way to just print it to the console as it is? If people use loggers, they won?t be able to capture this stack trace.
> thank you for your answer in advance.
> p.s. I know it is not your code, but isn?t it a suitable time to improve this part?

No, that has nothing to do with what is being done here so it is a terrible time to do it.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4815

From serb at openjdk.java.net  Sat Jul 17 02:55:48 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Sat, 17 Jul 2021 02:55:48 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8270859: Post JEP 411 refactoring: client
 libs with maximum covering > 10K
In-Reply-To: <9Wxw1cSmYDW0PLzPggKDLvoF8h_OPNd29x69FT89IOk=.06df777f-06a2-4fe1-b044-b319b78d8cb2@github.com>
References: <9Wxw1cSmYDW0PLzPggKDLvoF8h_OPNd29x69FT89IOk=.06df777f-06a2-4fe1-b044-b319b78d8cb2@github.com>
Message-ID: <UpNTNUwTtRI0A6-pFNitqhgawXSHTY5McYsgLfM8KyY=.36c4e94a-89f8-456b-b99f-4280d812b788@github.com>

On Fri, 16 Jul 2021 20:52:08 GMT, Weijun Wang <weijun at openjdk.org> wrote:

> This is the last part of Post JEP 411 refactoring that makes `@SuppressWarnings("removal")` more fine grained. This fix deals with all client libs annotations that cover more than 10K bytes of code.

After the requested change to the PrintServiceLookupProvider.java. Please confirm that the client tests are green.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4815

From serb at openjdk.java.net  Sat Jul 17 03:11:48 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Sat, 17 Jul 2021 03:11:48 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8269223: -Xcheck:jni WARNINGs working
 with fonts on Linux [v3]
In-Reply-To: <9Ztykod0kHfKYCtYGKgLnhles7C4H2aoR0DH4RYYhPo=.0ebb1ee2-2bc2-4399-bdfc-01330722fa79@github.com>
References: <9qME86kmJADg8GimR2jWTt831LWYfE3J19jrxKtrNS0=.1a62b00d-fbba-4cb3-aa28-450ab935d239@github.com>
 <9Ztykod0kHfKYCtYGKgLnhles7C4H2aoR0DH4RYYhPo=.0ebb1ee2-2bc2-4399-bdfc-01330722fa79@github.com>
Message-ID: <dTk8TYfCC62cCLcOKSo_i_dSSvOdIVVUkfJ2DgOlY0w=.1ffb2f10-464e-4cc5-b6c5-620d57bbffa3@github.com>

On Wed, 14 Jul 2021 05:48:42 GMT, Maxim Kartashev <github.com+28651297+mkartashev at openjdk.org> wrote:

>> Added an `ExceptionCheck()` followed by `ExceptionDescribe()` and `ExceptionClear()` immediately after the Java calls made from the callback function `ReadTTFontFileFunc()` in `freetypeScaler.c`. 
>> 
>> The exception(s) need to be cleared because we're not returning immediately to Java that would've been able to handle them gracefully. And in order not to loose the exception entirely (even though the return value would also indicate an error condition), print out the exception with `ExceptionDescribe()` to aid in debugging.
>
> Maxim Kartashev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   1. Marked the test as headful so that it doesn't fail on a headless
>   system.
>   2. Added exception checks to Windows-specific code.

src/java.desktop/windows/native/libawt/java2d/d3d/D3DRenderQueue.cpp line 870:

> 868:         J2dTraceLn(J2D_TRACE_VERBOSE, "  executing runnable");
> 869:         jboolean ignoreException;
> 870:         JNU_CallMethodByName(env, &ignoreException, pFlush->runnable, "run", "()V");

What is the purpose of this change? the only difference is that in the second case the ExceptionCheck will be called, does it affect something?

src/java.desktop/windows/native/libawt/windows/awt_Component.cpp line 6575:

> 6573:     jintArray obj = (jintArray)JNU_CallStaticMethodByName(env, &ignoreException,
> 6574:                                                           "java/awt/event/InputEvent",
> 6575:                                                           "getButtonDownMasks", "()[I").l;

obj might be null? Can not we just add CHECK_NULL(obj) here?

-------------

PR: https://git.openjdk.java.net/jdk/pull/4572

From psadhukhan at openjdk.java.net  Mon Jul 19 05:04:08 2021
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Mon, 19 Jul 2021 05:04:08 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8267940: [macos]
 java/awt/print/Dialog/DialogOwnerTest.java fails
Message-ID: <ZdTkAejkHKcPNnfyMXqYJsQEDTPaWXyK-HSrQOAOsyU=.469d52ab-a83a-4d0f-beab-67897c94fd02@github.com>

This test fails to follow the test instruction which says ""On Top" print dialogs should stay behind the "Owner Window" 
but it seems to be the behaviour right from jdk11b18 where DialogOwner class and this test was inducted via JDK-8203796 not only in mac but in windows too ie,
"On Top" print dialogs should stay behind the "Owner Window" as per instruction but is not.
On Top print dialogs actually stay above the "owner window"

I guess there is some ambiguity in test instruction or clarity in understanding test instructions is not there
because Test instructions says "For On Top tests all windows should stay *behind* the owner window."
but "Owner Window" instruction says "For tests that are 'Owned' or 'On Top' the dialog must always stay *above* this window. " 

Rectified the test instruction to be same as owner window instruction

-------------

Commit messages:
 - [macos] java/awt/print/Dialog/DialogOwnerTest.java fails

Changes: https://git.openjdk.java.net/jdk/pull/4823/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4823&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8267940
  Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4823.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4823/head:pull/4823

PR: https://git.openjdk.java.net/jdk/pull/4823

From github.com+28651297+mkartashev at openjdk.java.net  Mon Jul 19 08:33:58 2021
From: github.com+28651297+mkartashev at openjdk.java.net (Maxim Kartashev)
Date: Mon, 19 Jul 2021 08:33:58 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8269223: -Xcheck:jni WARNINGs working
 with fonts on Linux [v3]
In-Reply-To: <dTk8TYfCC62cCLcOKSo_i_dSSvOdIVVUkfJ2DgOlY0w=.1ffb2f10-464e-4cc5-b6c5-620d57bbffa3@github.com>
References: <9qME86kmJADg8GimR2jWTt831LWYfE3J19jrxKtrNS0=.1a62b00d-fbba-4cb3-aa28-450ab935d239@github.com>
 <9Ztykod0kHfKYCtYGKgLnhles7C4H2aoR0DH4RYYhPo=.0ebb1ee2-2bc2-4399-bdfc-01330722fa79@github.com>
 <dTk8TYfCC62cCLcOKSo_i_dSSvOdIVVUkfJ2DgOlY0w=.1ffb2f10-464e-4cc5-b6c5-620d57bbffa3@github.com>
Message-ID: <OmTheQjsiL-YHPvJMrCBt2HN4DigIbqgakEclL_8yW8=.88f92fb8-5b85-44fe-95b5-82d5afba93ca@github.com>

On Sat, 17 Jul 2021 03:03:41 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> Maxim Kartashev has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   1. Marked the test as headful so that it doesn't fail on a headless
>>   system.
>>   2. Added exception checks to Windows-specific code.
>
> src/java.desktop/windows/native/libawt/java2d/d3d/D3DRenderQueue.cpp line 870:
> 
>> 868:         J2dTraceLn(J2D_TRACE_VERBOSE, "  executing runnable");
>> 869:         jboolean ignoreException;
>> 870:         JNU_CallMethodByName(env, &ignoreException, pFlush->runnable, "run", "()V");
> 
> What is the purpose of this change? the only difference is that in the second case the ExceptionCheck will be called, does it affect something?

Yes, the `ExceptionCheck()` call will silence the warnings from `-Xcheck:jni`.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4572

From prr at openjdk.java.net  Wed Jul 21 22:18:44 2021
From: prr at openjdk.java.net (Phil Race)
Date: Wed, 21 Jul 2021 22:18:44 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8270893: IndexOutOfBoundsException while
 reading large TIFF file
In-Reply-To: <qLvPyanN3ikx_eRrNuct6gtZyN8vmKyUVa35mMME0Jw=.f9204066-6c19-42ea-9118-106214f994c6@github.com>
References: <laZrFZgYl4ceeN-BL-ZFP5sU_Tz7U4d0av4Auww5EDc=.d6efa3b3-32b6-4144-8b97-6ed9e06e729f@github.com>
 <qLvPyanN3ikx_eRrNuct6gtZyN8vmKyUVa35mMME0Jw=.f9204066-6c19-42ea-9118-106214f994c6@github.com>
Message-ID: <YI7g0Ccxi_tD1wqiGKYi5jbcQ9FPlx2v7x7EYhdWadg=.500d5452-aab2-4eb9-9ed0-0e85a8a8e907@github.com>

On Wed, 21 Jul 2021 04:22:05 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> Is it possible to create a testcase for this fix? Probably this regression should be fixed in jdk17?

FWIW the fixer had already written :
"Also to hit this code we need stream/file with at-least 1MB of IFD data, that's why there is no regression test"

Maybe 1Mb isn't actually a blocker, and it would be good to learn if we can create a TIFF image of that size and have github accept it.

But we definitely should run all the relevant existing regression tests.

As for JDk 17, we are in RDP 2 and this has been out there for exactly (?) 12 months until the first report and will need backporting anyway to other release trains.
So it is safer to put in 18 and backport later to a 17 update

-------------

PR: https://git.openjdk.java.net/jdk/pull/4836

From prr at openjdk.java.net  Wed Jul 21 22:25:52 2021
From: prr at openjdk.java.net (Phil Race)
Date: Wed, 21 Jul 2021 22:25:52 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8267940: [macos]
 java/awt/print/Dialog/DialogOwnerTest.java fails [v2]
In-Reply-To: <dn4XI0IJlr-GdMyQeuns0SzaFlR31j3oubKq_avMOYo=.0a87554e-e59d-49ad-8236-b175602dff44@github.com>
References: <ZdTkAejkHKcPNnfyMXqYJsQEDTPaWXyK-HSrQOAOsyU=.469d52ab-a83a-4d0f-beab-67897c94fd02@github.com>
 <dn4XI0IJlr-GdMyQeuns0SzaFlR31j3oubKq_avMOYo=.0a87554e-e59d-49ad-8236-b175602dff44@github.com>
Message-ID: <jUCMpUIXZLOKcbGN4Jid-Hs0J9SnbUX2MQTj4cSUaDc=.27bed0fc-033b-40e1-a5bd-188f4be88c47@github.com>

On Wed, 21 Jul 2021 04:19:03 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> This test fails to follow the test instruction which says ""On Top" print dialogs should stay behind the "Owner Window" 
>> but it seems to be the behaviour right from jdk11b18 where DialogOwner class and this test was inducted via JDK-8203796 not only in mac but in windows too ie,
>> "On Top" print dialogs should stay behind the "Owner Window" as per instruction but is not.
>> On Top print dialogs actually stay above the "owner window"
>> 
>> I guess there is some ambiguity in test instruction or clarity in understanding test instructions is not there
>> because Test instructions says "For On Top tests all windows should stay *behind* the owner window."
>> but "Owner Window" instruction says "For tests that are 'Owned' or 'On Top' the dialog must always stay *above* this window. " 
>> 
>> Rectified the test instruction to be same as owner window instruction
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix instruction

Marked as reviewed by prr (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/4823

From prr at openjdk.java.net  Wed Jul 21 22:37:43 2021
From: prr at openjdk.java.net (Phil Race)
Date: Wed, 21 Jul 2021 22:37:43 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8270893: IndexOutOfBoundsException while
 reading large TIFF file
In-Reply-To: <laZrFZgYl4ceeN-BL-ZFP5sU_Tz7U4d0av4Auww5EDc=.d6efa3b3-32b6-4144-8b97-6ed9e06e729f@github.com>
References: <laZrFZgYl4ceeN-BL-ZFP5sU_Tz7U4d0av4Auww5EDc=.d6efa3b3-32b6-4144-8b97-6ed9e06e729f@github.com>
Message-ID: <kFZ6p0xWEVZ804OpFj5xOWJzcnZK-qIL5L8JiZaRF8s=.d2224e6a-16ee-463e-83e0-8ef8c3fb5f5e@github.com>

On Tue, 20 Jul 2021 06:25:22 GMT, Jayathirth D V <jdv at openjdk.org> wrote:

> We are incorrectly passing source offset to ImageInputStream.readFully() which is getting used on destination buffer. streamPos maintained in each implementation of stream maintain's appropriate source offset while reading the data. Since we are completely utilizing destination buffer any offset greater than 0 would cause IOOBE. In our case we should use 0 as offset value.
> 
> Also to hit this code we need stream/file with at-least 1MB of IFD data, that's why there is no regression test. This change can be verified using image attached in JBS. All test run is green.

Approving but I would like some more evidence that a test is not practical.

-------------

Marked as reviewed by prr (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/4836

From jwilhelm at openjdk.java.net  Thu Jul 22 00:02:23 2021
From: jwilhelm at openjdk.java.net (Jesper Wilhelmsson)
Date: Thu, 22 Jul 2021 00:02:23 GMT
Subject: [OpenJDK 2D-Dev] RFR: Merge jdk17
Message-ID: <EyjzhDedbKuTrHsbgwBAv7Q3cDRnmZ9pv_zR_rRzdZg=.779ee90b-0a77-413a-95b2-6f85d77296c4@github.com>

Forwardport JDK 17 -> JDK 18

-------------

Commit messages:
 - Merge
 - 8266347: assert(Dependencies::is_concrete_root_method(fm, ctxk) == Dependencies::is_concrete_method(m, ctxk)) failed: mismatch
 - 8264066: Enhance compiler validation
 - 8265201: JarFile.getInputStream not validating invalid signed jars
 - 8258432: Improve File Transfers
 - 8264079: Improve abstractions
 - 8262380: Enhance XML processing passes
 - 8262967: Improve Zip file support
 - 8264460: Improve NTLM support
 - 8256491: Better HTTP transport
 - ... and 10 more: https://git.openjdk.java.net/jdk/compare/0790f04d...025eaefb

The webrevs contain the adjustments done while merging with regards to each parent branch:
 - master: https://webrevs.openjdk.java.net/?repo=jdk&pr=4863&range=00.0
 - jdk17: https://webrevs.openjdk.java.net/?repo=jdk&pr=4863&range=00.1

Changes: https://git.openjdk.java.net/jdk/pull/4863/files
  Stats: 517 lines in 33 files changed: 403 ins; 34 del; 80 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4863.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4863/head:pull/4863

PR: https://git.openjdk.java.net/jdk/pull/4863

From jwilhelm at openjdk.java.net  Thu Jul 22 00:51:37 2021
From: jwilhelm at openjdk.java.net (Jesper Wilhelmsson)
Date: Thu, 22 Jul 2021 00:51:37 GMT
Subject: [OpenJDK 2D-Dev] RFR: Merge jdk17 [v2]
In-Reply-To: <EyjzhDedbKuTrHsbgwBAv7Q3cDRnmZ9pv_zR_rRzdZg=.779ee90b-0a77-413a-95b2-6f85d77296c4@github.com>
References: <EyjzhDedbKuTrHsbgwBAv7Q3cDRnmZ9pv_zR_rRzdZg=.779ee90b-0a77-413a-95b2-6f85d77296c4@github.com>
Message-ID: <pAbckiZhttmfKUoxQWEPkJpNvzyNGo9c0VKlKeN929A=.b6e0fb04-aa73-4174-aa51-0b7eecf86564@github.com>

> Forwardport JDK 17 -> JDK 18

Jesper Wilhelmsson has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 282 commits:

 - Merge
 - 8271015: Split cds/SharedBaseAddress.java test into smaller parts
   
   Reviewed-by: ccheung, minqi
 - 8271014: Refactor HeapShared::is_archived_object()
   
   Reviewed-by: ccheung, minqi
 - 8270949: Make dynamically generated classes with the class file version of the current release
   
   Reviewed-by: alanb
 - 8269849: vmTestbase/gc/gctests/PhantomReference/phantom002/TestDescription.java failed with "OutOfMemoryError: Java heap space: failed reallocation of scalar replaced objects"
   
   Reviewed-by: kbarrett
 - 8270991: G1 Full GC always performs heap verification after JDK-8269295
   
   Reviewed-by: iwalulya, kbarrett
 - 8270820: remove unused stiFileTableIndex from SDE.c
   
   Reviewed-by: cjplummer, sspitsyn
 - 8270147: Increase stride size allowing unrolling more loops
   
   Reviewed-by: kvn, iveresov
 - 8270803: Reduce CDS API verbosity
   
   Reviewed-by: minqi, ccheung
 - 8269933: test/jdk/javax/net/ssl/compatibility/JdkInfo incorrect verification of protocol and cipher support
   
   Reviewed-by: xuelei, rhalade
 - ... and 272 more: https://git.openjdk.java.net/jdk/compare/89f7998a...025eaefb

-------------

Changes: https://git.openjdk.java.net/jdk/pull/4863/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4863&range=01
  Stats: 55988 lines in 1158 files changed: 26162 ins; 25130 del; 4696 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4863.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4863/head:pull/4863

PR: https://git.openjdk.java.net/jdk/pull/4863

From jwilhelm at openjdk.java.net  Thu Jul 22 00:51:38 2021
From: jwilhelm at openjdk.java.net (Jesper Wilhelmsson)
Date: Thu, 22 Jul 2021 00:51:38 GMT
Subject: [OpenJDK 2D-Dev] Integrated: Merge jdk17
In-Reply-To: <EyjzhDedbKuTrHsbgwBAv7Q3cDRnmZ9pv_zR_rRzdZg=.779ee90b-0a77-413a-95b2-6f85d77296c4@github.com>
References: <EyjzhDedbKuTrHsbgwBAv7Q3cDRnmZ9pv_zR_rRzdZg=.779ee90b-0a77-413a-95b2-6f85d77296c4@github.com>
Message-ID: <uLKilEHqK1ophFqLcb19742sf7ShTcYaXP-yo8A0U-M=.04e4edb1-ff3b-406e-8a45-9bc01771a05b@github.com>

On Wed, 21 Jul 2021 23:52:53 GMT, Jesper Wilhelmsson <jwilhelm at openjdk.org> wrote:

> Forwardport JDK 17 -> JDK 18

This pull request has now been integrated.

Changeset: c36755de
Author:    Jesper Wilhelmsson <jwilhelm at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/c36755dedf1a0d7ce0aeadd401e0c70ff84185e7
Stats:     517 lines in 33 files changed: 403 ins; 34 del; 80 mod

Merge

-------------

PR: https://git.openjdk.java.net/jdk/pull/4863

From jdv at openjdk.java.net  Thu Jul 22 02:39:49 2021
From: jdv at openjdk.java.net (Jayathirth D V)
Date: Thu, 22 Jul 2021 02:39:49 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8270893: IndexOutOfBoundsException while
 reading large TIFF file
In-Reply-To: <YI7g0Ccxi_tD1wqiGKYi5jbcQ9FPlx2v7x7EYhdWadg=.500d5452-aab2-4eb9-9ed0-0e85a8a8e907@github.com>
References: <laZrFZgYl4ceeN-BL-ZFP5sU_Tz7U4d0av4Auww5EDc=.d6efa3b3-32b6-4144-8b97-6ed9e06e729f@github.com>
 <qLvPyanN3ikx_eRrNuct6gtZyN8vmKyUVa35mMME0Jw=.f9204066-6c19-42ea-9118-106214f994c6@github.com>
 <YI7g0Ccxi_tD1wqiGKYi5jbcQ9FPlx2v7x7EYhdWadg=.500d5452-aab2-4eb9-9ed0-0e85a8a8e907@github.com>
Message-ID: <cRO23eYQ4uMzQTFR7dJyn7aZlZgWUV25GjaKFt9PSDM=.f750191a-8629-456b-800a-810c4412983d@github.com>

On Wed, 21 Jul 2021 22:15:35 GMT, Phil Race <prr at openjdk.org> wrote:

> > Is it possible to create a testcase for this fix? Probably this regression should be fixed in jdk17?
> 
> FWIW the fixer had already written :
> "Also to hit this code we need stream/file with at-least 1MB of IFD data, that's why there is no regression test"
> 
> Maybe 1Mb isn't actually a blocker, and it would be good to learn if we can create a TIFF image of that size and have github accept it.
> 
> But we definitely should run all the relevant existing regression tests.
> 
> As for JDk 17, we are in RDP 2 and this has been out there for exactly (?) 12 months until the first report and will need backporting anyway to other release trains.
> So it is safer to put in 18 and backport later to a 17 update

Sure i will take a look at creating regression test case for this issue and see whether we can hit this particular path.
All client tier test cases were run and CI job link is present in the JBS and it is green with fix.
Yes i am planning to backport it to the trains where the original issue was fixed.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4836

From psadhukhan at openjdk.java.net  Thu Jul 22 04:32:50 2021
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Thu, 22 Jul 2021 04:32:50 GMT
Subject: [OpenJDK 2D-Dev] Integrated: 8267940: [macos]
 java/awt/print/Dialog/DialogOwnerTest.java fails
In-Reply-To: <ZdTkAejkHKcPNnfyMXqYJsQEDTPaWXyK-HSrQOAOsyU=.469d52ab-a83a-4d0f-beab-67897c94fd02@github.com>
References: <ZdTkAejkHKcPNnfyMXqYJsQEDTPaWXyK-HSrQOAOsyU=.469d52ab-a83a-4d0f-beab-67897c94fd02@github.com>
Message-ID: <WEpk8uzmB-XsujWGhdNbty0zRONxf6y0OJ_OIp1pf6E=.02d61f56-f482-4a3a-b2e3-24f46bace391@github.com>

On Mon, 19 Jul 2021 04:46:59 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> This test fails to follow the test instruction which says ""On Top" print dialogs should stay behind the "Owner Window" 
> but it seems to be the behaviour right from jdk11b18 where DialogOwner class and this test was inducted via JDK-8203796 not only in mac but in windows too ie,
> "On Top" print dialogs should stay behind the "Owner Window" as per instruction but is not.
> On Top print dialogs actually stay above the "owner window"
> 
> I guess there is some ambiguity in test instruction or clarity in understanding test instructions is not there
> because Test instructions says "For On Top tests all windows should stay *behind* the owner window."
> but "Owner Window" instruction says "For tests that are 'Owned' or 'On Top' the dialog must always stay *above* this window. " 
> 
> Rectified the test instruction to be same as owner window instruction

This pull request has now been integrated.

Changeset: 9131a8f5
Author:    Prasanta Sadhukhan <psadhukhan at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/9131a8f5f241b04c28a875fddb7a060cc9a3c252
Stats:     1 line in 1 file changed: 0 ins; 0 del; 1 mod

8267940: [macos] java/awt/print/Dialog/DialogOwnerTest.java fails

Reviewed-by: azvegint, prr

-------------

PR: https://git.openjdk.java.net/jdk/pull/4823

From psadhukhan at openjdk.java.net  Thu Jul 22 05:09:51 2021
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Thu, 22 Jul 2021 05:09:51 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8205138: Remove Applet references from
 Font2DTest
In-Reply-To: <kZPptQFv0tFD31kgppLjHFbxYTbUt5c6HPsV7xLl-rk=.07113ed7-cd9c-4b45-98e4-d57e16610836@github.com>
References: <kZPptQFv0tFD31kgppLjHFbxYTbUt5c6HPsV7xLl-rk=.07113ed7-cd9c-4b45-98e4-d57e16610836@github.com>
Message-ID: <vPxzFMvaLuMAcRMEVVfnSqgNze8WVcU0aKbQEaz5ars=.6cfd750f-2a36-4bb5-bcf1-431949c06c7e@github.com>

On Mon, 19 Jul 2021 20:50:14 GMT, Phil Race <prr at openjdk.org> wrote:

> Applet support was removed already but the .html file was left as well as docs on applet issues
> and a parameter only relevant to applets.

src/demo/share/jfc/Font2DTest/Font2DTest.java line 272:

> 270:         fileMenu.addSeparator();
> 271:         if ( !isApplet )
> 272:           fileMenu.add( new MenuItemV2( "Exit", this ));

If it is not Applet, should we not retain this line?

src/demo/share/jfc/Font2DTest/README.txt line 142:

> 140: - There are still some bugs around the error handling.
> 141: Most of these problems will usually get fixed when some parameters
> 142: are changed, or the screen is refreshed.

Are the 1st 2 known problems are not there now?

-------------

PR: https://git.openjdk.java.net/jdk/pull/4831

From serb at openjdk.java.net  Thu Jul 22 05:38:44 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Thu, 22 Jul 2021 05:38:44 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8270893: IndexOutOfBoundsException while
 reading large TIFF file
In-Reply-To: <laZrFZgYl4ceeN-BL-ZFP5sU_Tz7U4d0av4Auww5EDc=.d6efa3b3-32b6-4144-8b97-6ed9e06e729f@github.com>
References: <laZrFZgYl4ceeN-BL-ZFP5sU_Tz7U4d0av4Auww5EDc=.d6efa3b3-32b6-4144-8b97-6ed9e06e729f@github.com>
Message-ID: <ftAHacF-Tv7ABZDU2dF9bKfgiXg1moPwvgSt-NjzqJA=.25a7902e-78bf-4566-a477-e18a61cbec4d@github.com>

On Tue, 20 Jul 2021 06:25:22 GMT, Jayathirth D V <jdv at openjdk.org> wrote:

> We are incorrectly passing source offset to ImageInputStream.readFully() which is getting used on destination buffer. streamPos maintained in each implementation of stream maintain's appropriate source offset while reading the data. Since we are completely utilizing destination buffer any offset greater than 0 would cause IOOBE. In our case we should use 0 as offset value.
> 
> Also to hit this code we need stream/file with at-least 1MB of IFD data, that's why there is no regression test. This change can be verified using image attached in JBS. All test run is green.

We can save the header of the image as a binary array and then generate the image on the fly by filling the content with zeros. So it is not necessary to store such file in the repo.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4836

From github.com+28651297+mkartashev at openjdk.java.net  Fri Jul 23 09:07:10 2021
From: github.com+28651297+mkartashev at openjdk.java.net (Maxim Kartashev)
Date: Fri, 23 Jul 2021 09:07:10 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8269223: -Xcheck:jni WARNINGs working
 with fonts on Linux [v3]
In-Reply-To: <dTk8TYfCC62cCLcOKSo_i_dSSvOdIVVUkfJ2DgOlY0w=.1ffb2f10-464e-4cc5-b6c5-620d57bbffa3@github.com>
References: <9qME86kmJADg8GimR2jWTt831LWYfE3J19jrxKtrNS0=.1a62b00d-fbba-4cb3-aa28-450ab935d239@github.com>
 <9Ztykod0kHfKYCtYGKgLnhles7C4H2aoR0DH4RYYhPo=.0ebb1ee2-2bc2-4399-bdfc-01330722fa79@github.com>
 <dTk8TYfCC62cCLcOKSo_i_dSSvOdIVVUkfJ2DgOlY0w=.1ffb2f10-464e-4cc5-b6c5-620d57bbffa3@github.com>
Message-ID: <RWLMVvUVuAJSukQR5jaN0ioyFcWmuSFX9mk3i8rw70I=.91f8fb67-5eb9-4982-9de7-dc25514f6ff9@github.com>

On Sat, 17 Jul 2021 03:05:35 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> Maxim Kartashev has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   1. Marked the test as headful so that it doesn't fail on a headless
>>   system.
>>   2. Added exception checks to Windows-specific code.
>
> src/java.desktop/windows/native/libawt/windows/awt_Component.cpp line 6575:
> 
>> 6573:     jintArray obj = (jintArray)JNU_CallStaticMethodByName(env, &ignoreException,
>> 6574:                                                           "java/awt/event/InputEvent",
>> 6575:                                                           "getButtonDownMasks", "()[I").l;
> 
> obj might be null? Can not we just add CHECK_NULL(obj) here?

obj indeed might be null, especially since all kinds of things could go wrong during class/method resolution. Added `CHECK_NULL(obj)` here.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4572

From jdv at openjdk.java.net  Fri Jul 23 09:16:10 2021
From: jdv at openjdk.java.net (Jayathirth D V)
Date: Fri, 23 Jul 2021 09:16:10 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8270893: IndexOutOfBoundsException while
 reading large TIFF file
In-Reply-To: <laZrFZgYl4ceeN-BL-ZFP5sU_Tz7U4d0av4Auww5EDc=.d6efa3b3-32b6-4144-8b97-6ed9e06e729f@github.com>
References: <laZrFZgYl4ceeN-BL-ZFP5sU_Tz7U4d0av4Auww5EDc=.d6efa3b3-32b6-4144-8b97-6ed9e06e729f@github.com>
Message-ID: <oMjnKs-SroDUSkbr8tK47FDwF-p7ieBkxHSCs9lTlR8=.eab85d02-0e4d-479f-863f-36186777b82c@github.com>

On Tue, 20 Jul 2021 06:25:22 GMT, Jayathirth D V <jdv at openjdk.org> wrote:

> We are incorrectly passing source offset to ImageInputStream.readFully() which is getting used on destination buffer. streamPos maintained in each implementation of stream maintain's appropriate source offset while reading the data. Since we are completely utilizing destination buffer any offset greater than 0 would cause IOOBE. In our case we should use 0 as offset value.
> 
> Also to hit this code we need stream/file with at-least 1MB of IFD data, that's why there is no regression test. This change can be verified using image attached in JBS. All test run is green.

I went through TIFF spec and image provided in the bug to understand whether we can find a way to pass similar data to reproduce the issue.

The image attached in JBS has ICCProfile as one of the TIFFTag(This is considered as UNDEFINED tag by our standard reader) and its count is more than 1024000. And for this ICCProfile tag corresponding data is also present in the stream, it is not some corrupt header scenario where we can just write bad data in header and hit the issue. We divide the tag data in chunks on 1024000 bytes, when we are done reading first chunk of ICCProfile data and start reading the second chunk we hit this issue.

So to add regression test for this scenario we need more than 1024000 bytes of data in one of the TIFFTag type where the present change is done. We will not be able to pass that amount of data in byteArray stream. Also if we want to pass raw data as part of a TIFFTag i need relevant TIFFtag data like ICCProfile in the image attached in JBS.

 So i am leaving discussion open so that others can give inputs on ways we can put relevant data into our TIFFImageWriter to hit this issue.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4836

From serb at openjdk.java.net  Sat Jul 24 03:20:04 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Sat, 24 Jul 2021 03:20:04 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8270893: IndexOutOfBoundsException while
 reading large TIFF file
In-Reply-To: <laZrFZgYl4ceeN-BL-ZFP5sU_Tz7U4d0av4Auww5EDc=.d6efa3b3-32b6-4144-8b97-6ed9e06e729f@github.com>
References: <laZrFZgYl4ceeN-BL-ZFP5sU_Tz7U4d0av4Auww5EDc=.d6efa3b3-32b6-4144-8b97-6ed9e06e729f@github.com>
Message-ID: <HvHCK2qH-Vah2-TcTIGYOCxH1TwsSWsZds37WKA37m4=.b42d21e8-6fb9-4ff4-8e2f-f75e2eae4419@github.com>

On Tue, 20 Jul 2021 06:25:22 GMT, Jayathirth D V <jdv at openjdk.org> wrote:

> We are incorrectly passing source offset to ImageInputStream.readFully() which is getting used on destination buffer. streamPos maintained in each implementation of stream maintain's appropriate source offset while reading the data. Since we are completely utilizing destination buffer any offset greater than 0 would cause IOOBE. In our case we should use 0 as offset value.
> 
> Also to hit this code we need stream/file with at-least 1MB of IFD data, that's why there is no regression test. This change can be verified using image attached in JBS. All test run is green.

1024000 bytes does not look like a big problem especially if it is generated on the fly during the test execution?
You can try to load the data for our PYCC color profile and set one of its tag data to a big chunk like icSigCopyrightTag, or you can try to just fill it by zeros at the end.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4836

From github.com+741251+turbanoff at openjdk.java.net  Mon Jul 26 11:30:21 2021
From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov)
Date: Mon, 26 Jul 2021 11:30:21 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8269130: Replace usages of
 Collection.toArray() with Collection.toArray(T[]) to avoid redundant array
 copying
Message-ID: <T7SCIIPHljpkI__o6KGtVXO1I9jMWWcXkQv-GaUE6pE=.b3de93a2-9057-4bf5-9680-2397a4d10e62@github.com>

I found few places, where code initially perform `Object[] Colleciton.toArray()` call and then manually copy array into another array with required type.
This PR cleanups such places to more shorter call `T[] Collection.toArray(T[])`.

-------------

Commit messages:
 - Replace usages of Collection.toArray() with Collection.toArray(T[]) to avoid redundant array copying
 - Replace usages of Collection.toArray() with Collection.toArray(T[]) to avoid redundant array copying
 - Replace usages of Collection.toArray() with Collection.toArray(T[]) to avoid redundant array copying

Changes: https://git.openjdk.java.net/jdk/pull/4487/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4487&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8269130
  Stats: 70 lines in 8 files changed: 0 ins; 54 del; 16 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4487.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4487/head:pull/4487

PR: https://git.openjdk.java.net/jdk/pull/4487

From github.com+10835776+stsypanov at openjdk.java.net  Mon Jul 26 11:30:21 2021
From: github.com+10835776+stsypanov at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=)
Date: Mon, 26 Jul 2021 11:30:21 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8269130: Replace usages of
 Collection.toArray() with Collection.toArray(T[]) to avoid redundant array
 copying
In-Reply-To: <T7SCIIPHljpkI__o6KGtVXO1I9jMWWcXkQv-GaUE6pE=.b3de93a2-9057-4bf5-9680-2397a4d10e62@github.com>
References: <T7SCIIPHljpkI__o6KGtVXO1I9jMWWcXkQv-GaUE6pE=.b3de93a2-9057-4bf5-9680-2397a4d10e62@github.com>
Message-ID: <RGdfH15SqrmAJ_F_lJsXWPgDXASBawZa6STmTw79O0M=.9a0479b0-2555-4541-95ba-665960ab4fbe@github.com>

On Mon, 14 Jun 2021 17:00:29 GMT, Andrey Turbanov <github.com+741251+turbanoff at openjdk.org> wrote:

> I found few places, where code initially perform `Object[] Colleciton.toArray()` call and then manually copy array into another array with required type.
> This PR cleanups such places to more shorter call `T[] Collection.toArray(T[])`.

I think the same simlification can be done for some classes affected by your previous PR https://github.com/openjdk/jdk/pull/4482, e.g. `HttpsClient`, lines 154-157 and 177-180 and `PKCS7`, so I'd wait for https://github.com/openjdk/jdk/pull/4482 and then add one more commit here.

@turbanoff I've filed a ticket for this: https://bugs.openjdk.java.net/browse/JDK-8269130. Also I think you can integrate https://github.com/openjdk/jdk/pull/4482

-------------

PR: https://git.openjdk.java.net/jdk/pull/4487

From github.com+114367+mbien at openjdk.java.net  Mon Jul 26 11:30:21 2021
From: github.com+114367+mbien at openjdk.java.net (Michael Bien)
Date: Mon, 26 Jul 2021 11:30:21 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8269130: Replace usages of
 Collection.toArray() with Collection.toArray(T[]) to avoid redundant array
 copying
In-Reply-To: <T7SCIIPHljpkI__o6KGtVXO1I9jMWWcXkQv-GaUE6pE=.b3de93a2-9057-4bf5-9680-2397a4d10e62@github.com>
References: <T7SCIIPHljpkI__o6KGtVXO1I9jMWWcXkQv-GaUE6pE=.b3de93a2-9057-4bf5-9680-2397a4d10e62@github.com>
Message-ID: <1z_ElyUFTtNdV6Wt5HV0lEdQZbTvf7F5MRdV6pB36zM=.d92f53e6-53dc-436e-acf3-619f784d7814@github.com>

On Mon, 14 Jun 2021 17:00:29 GMT, Andrey Turbanov <github.com+741251+turbanoff at openjdk.org> wrote:

> I found few places, where code initially perform `Object[] Colleciton.toArray()` call and then manually copy array into another array with required type.
> This PR cleanups such places to more shorter call `T[] Collection.toArray(T[])`.

src/java.base/share/classes/java/security/Security.java line 656:

> 654:             return null;
> 655: 
> 656:         return candidates.toArray(new Provider[0]);

`candidates.toArray(new Provider[candidates.size()]);`

would use the fast path of the toArray() implementation. Performance probably doesn't matter much in a lot of this cases, but since its only a few characters more, its still worth considering IMO.

The only places I would leave this out are on the HashTable and on the Vector collections in this PR, since calling one synchronized method is not the same as calling two - concurrency wise.

(i am no reviewer)

-------------

PR: https://git.openjdk.java.net/jdk/pull/4487

From github.com+741251+turbanoff at openjdk.java.net  Mon Jul 26 11:30:22 2021
From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov)
Date: Mon, 26 Jul 2021 11:30:22 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8269130: Replace usages of
 Collection.toArray() with Collection.toArray(T[]) to avoid redundant array
 copying
In-Reply-To: <1z_ElyUFTtNdV6Wt5HV0lEdQZbTvf7F5MRdV6pB36zM=.d92f53e6-53dc-436e-acf3-619f784d7814@github.com>
References: <T7SCIIPHljpkI__o6KGtVXO1I9jMWWcXkQv-GaUE6pE=.b3de93a2-9057-4bf5-9680-2397a4d10e62@github.com>
 <1z_ElyUFTtNdV6Wt5HV0lEdQZbTvf7F5MRdV6pB36zM=.d92f53e6-53dc-436e-acf3-619f784d7814@github.com>
Message-ID: <HbAuDh-MFnpUrGAxHJTKJX9_0ybK5EbYuHoTI3s2MPE=.6104a076-442a-4c67-9805-5c4008905d10@github.com>

On Tue, 15 Jun 2021 12:06:43 GMT, Michael Bien <github.com+114367+mbien at openjdk.org> wrote:

>> I found few places, where code initially perform `Object[] Colleciton.toArray()` call and then manually copy array into another array with required type.
>> This PR cleanups such places to more shorter call `T[] Collection.toArray(T[])`.
>
> src/java.base/share/classes/java/security/Security.java line 656:
> 
>> 654:             return null;
>> 655: 
>> 656:         return candidates.toArray(new Provider[0]);
> 
> `candidates.toArray(new Provider[candidates.size()]);`
> 
> would use the fast path of the toArray() implementation. Performance probably doesn't matter much in a lot of this cases, but since its only a few characters more, its still worth considering IMO.
> 
> The only places I would leave this out are on the HashTable and on the Vector collections in this PR, since calling one synchronized method is not the same as calling two - concurrency wise.
> 
> (i am no reviewer)

Actually it's not _the fast path_ - see https://shipilev.net/blog/2016/arrays-wisdom-ancients/

-------------

PR: https://git.openjdk.java.net/jdk/pull/4487

From github.com+114367+mbien at openjdk.java.net  Mon Jul 26 11:30:22 2021
From: github.com+114367+mbien at openjdk.java.net (Michael Bien)
Date: Mon, 26 Jul 2021 11:30:22 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8269130: Replace usages of
 Collection.toArray() with Collection.toArray(T[]) to avoid redundant array
 copying
In-Reply-To: <HbAuDh-MFnpUrGAxHJTKJX9_0ybK5EbYuHoTI3s2MPE=.6104a076-442a-4c67-9805-5c4008905d10@github.com>
References: <T7SCIIPHljpkI__o6KGtVXO1I9jMWWcXkQv-GaUE6pE=.b3de93a2-9057-4bf5-9680-2397a4d10e62@github.com>
 <1z_ElyUFTtNdV6Wt5HV0lEdQZbTvf7F5MRdV6pB36zM=.d92f53e6-53dc-436e-acf3-619f784d7814@github.com>
 <HbAuDh-MFnpUrGAxHJTKJX9_0ybK5EbYuHoTI3s2MPE=.6104a076-442a-4c67-9805-5c4008905d10@github.com>
Message-ID: <XMK9iClcp3uF-aORRgwlw0r7X9TGNvP12JYZSFESnwc=.4ee3292e-f9f0-4fb2-b039-8f4f2b97df34@github.com>

On Tue, 15 Jun 2021 12:34:50 GMT, Andrey Turbanov <github.com+741251+turbanoff at openjdk.org> wrote:

>> src/java.base/share/classes/java/security/Security.java line 656:
>> 
>>> 654:             return null;
>>> 655: 
>>> 656:         return candidates.toArray(new Provider[0]);
>> 
>> `candidates.toArray(new Provider[candidates.size()]);`
>> 
>> would use the fast path of the toArray() implementation. Performance probably doesn't matter much in a lot of this cases, but since its only a few characters more, its still worth considering IMO.
>> 
>> The only places I would leave this out are on the HashTable and on the Vector collections in this PR, since calling one synchronized method is not the same as calling two - concurrency wise.
>> 
>> (i am no reviewer)
>
> Actually it's not _the fast path_ - see https://shipilev.net/blog/2016/arrays-wisdom-ancients/

oh I am sorry my mistake - I actually now remember reading the article. (It would be interesting to rerun the benchmark on modern JDKs since I would expect the gap to be smaller now)
Please disregard my suggestion.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4487

From serb at openjdk.java.net  Mon Jul 26 11:30:23 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Mon, 26 Jul 2021 11:30:23 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8269130: Replace usages of
 Collection.toArray() with Collection.toArray(T[]) to avoid redundant array
 copying
In-Reply-To: <T7SCIIPHljpkI__o6KGtVXO1I9jMWWcXkQv-GaUE6pE=.b3de93a2-9057-4bf5-9680-2397a4d10e62@github.com>
References: <T7SCIIPHljpkI__o6KGtVXO1I9jMWWcXkQv-GaUE6pE=.b3de93a2-9057-4bf5-9680-2397a4d10e62@github.com>
Message-ID: <522sj45K-E26GUke0gp6dDoq_4dpwfLMytNVmg5V2k8=.2d5a1a6c-4191-4f63-a83e-af35c69cb6e4@github.com>

On Mon, 14 Jun 2021 17:00:29 GMT, Andrey Turbanov <github.com+741251+turbanoff at openjdk.org> wrote:

> I found few places, where code initially perform `Object[] Colleciton.toArray()` call and then manually copy array into another array with required type.
> This PR cleanups such places to more shorter call `T[] Collection.toArray(T[])`.

src/java.desktop/share/classes/sun/java2d/SunGraphicsEnvironment.java line 191:

> 189:                         installed[i]);
> 190:             }
> 191:             String[] retval = map.keySet().toArray(new String[0]);

Looks like previously the code returns values, and now it will return keys, please recheck.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4487

From mullan at openjdk.java.net  Mon Jul 26 19:10:35 2021
From: mullan at openjdk.java.net (Sean Mullan)
Date: Mon, 26 Jul 2021 19:10:35 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8269130: Replace usages of
 Collection.toArray() with Collection.toArray(T[]) to avoid redundant array
 copying
In-Reply-To: <T7SCIIPHljpkI__o6KGtVXO1I9jMWWcXkQv-GaUE6pE=.b3de93a2-9057-4bf5-9680-2397a4d10e62@github.com>
References: <T7SCIIPHljpkI__o6KGtVXO1I9jMWWcXkQv-GaUE6pE=.b3de93a2-9057-4bf5-9680-2397a4d10e62@github.com>
Message-ID: <w-b3bQRsyksOmZlapJ8a175cxPbajxOHPK5bP2mmfJ0=.dbc900f7-9a03-4233-90dd-8853e410adb2@github.com>

On Mon, 14 Jun 2021 17:00:29 GMT, Andrey Turbanov <github.com+741251+turbanoff at openjdk.org> wrote:

> I found few places, where code initially perform `Object[] Colleciton.toArray()` call and then manually copy array into another array with required type.
> This PR cleanups such places to more shorter call `T[] Collection.toArray(T[])`.

The changes to the security classes look good.

-------------

Marked as reviewed by mullan (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/4487

From github.com+2996845+bokken at openjdk.java.net  Mon Jul 26 19:18:33 2021
From: github.com+2996845+bokken at openjdk.java.net (Brett Okken)
Date: Mon, 26 Jul 2021 19:18:33 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8269130: Replace usages of
 Collection.toArray() with Collection.toArray(T[]) to avoid redundant array
 copying
In-Reply-To: <T7SCIIPHljpkI__o6KGtVXO1I9jMWWcXkQv-GaUE6pE=.b3de93a2-9057-4bf5-9680-2397a4d10e62@github.com>
References: <T7SCIIPHljpkI__o6KGtVXO1I9jMWWcXkQv-GaUE6pE=.b3de93a2-9057-4bf5-9680-2397a4d10e62@github.com>
Message-ID: <amB5jIt1-LyF6A8_OxgTfO6tDKhujRwvnM1QYqPbzkU=.17cd1c88-0ff5-42f6-ad9b-53d5cbdd74e5@github.com>

On Mon, 14 Jun 2021 17:00:29 GMT, Andrey Turbanov <github.com+741251+turbanoff at openjdk.org> wrote:

> I found few places, where code initially perform `Object[] Colleciton.toArray()` call and then manually copy array into another array with required type.
> This PR cleanups such places to more shorter call `T[] Collection.toArray(T[])`.

src/java.base/share/classes/java/security/Security.java line 656:

> 654:             return null;
> 655: 
> 656:         return candidates.toArray(new Provider[0]);

Is this called often enough to warrant creating a constant of `new Provider[0]` (benefits of this covered in the _Wisdom of the Ancients_ blog linked)?

-------------

PR: https://git.openjdk.java.net/jdk/pull/4487

From github.com+2996845+bokken at openjdk.java.net  Mon Jul 26 19:58:30 2021
From: github.com+2996845+bokken at openjdk.java.net (Brett Okken)
Date: Mon, 26 Jul 2021 19:58:30 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8269130: Replace usages of
 Collection.toArray() with Collection.toArray(T[]) to avoid redundant array
 copying
In-Reply-To: <T7SCIIPHljpkI__o6KGtVXO1I9jMWWcXkQv-GaUE6pE=.b3de93a2-9057-4bf5-9680-2397a4d10e62@github.com>
References: <T7SCIIPHljpkI__o6KGtVXO1I9jMWWcXkQv-GaUE6pE=.b3de93a2-9057-4bf5-9680-2397a4d10e62@github.com>
Message-ID: <FRn0jQHYWMJL5GTfhu4TWGlg8OaBHVpEoIQ_pCka3rs=.151177ce-ac88-4932-b8c9-c6e59a148b5c@github.com>

On Mon, 14 Jun 2021 17:00:29 GMT, Andrey Turbanov <github.com+741251+turbanoff at openjdk.org> wrote:

> I found few places, where code initially perform `Object[] Colleciton.toArray()` call and then manually copy array into another array with required type.
> This PR cleanups such places to more shorter call `T[] Collection.toArray(T[])`.

src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/utilities/SystemDictionaryHelper.java line 92:

> 90:       }
> 91: 
> 92:       InstanceKlass[] searchResult = tmp.toArray(new InstanceKlass[0]);

Is it too far outside the scope of these changes to make `tmp` an `ArrayList` rather than a `Vector`?

-------------

PR: https://git.openjdk.java.net/jdk/pull/4487

From weijun at openjdk.java.net  Tue Jul 27 17:37:34 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Tue, 27 Jul 2021 17:37:34 GMT
Subject: [OpenJDK 2D-Dev] Integrated: 8270859: Post JEP 411 refactoring:
 client libs with maximum covering > 10K
In-Reply-To: <9Wxw1cSmYDW0PLzPggKDLvoF8h_OPNd29x69FT89IOk=.06df777f-06a2-4fe1-b044-b319b78d8cb2@github.com>
References: <9Wxw1cSmYDW0PLzPggKDLvoF8h_OPNd29x69FT89IOk=.06df777f-06a2-4fe1-b044-b319b78d8cb2@github.com>
Message-ID: <262eSH5uEXtLA0bGhGMYjyvPH95AjMNDmIW0DIYp2Ao=.5cc95f00-e0b4-44fb-bf39-5077c10c96bc@github.com>

On Fri, 16 Jul 2021 20:52:08 GMT, Weijun Wang <weijun at openjdk.org> wrote:

> This is the last part of Post JEP 411 refactoring that makes `@SuppressWarnings("removal")` more fine grained. This fix deals with all client libs annotations that cover more than 10K bytes of code.

This pull request has now been integrated.

Changeset: 90cd2fa1
Author:    Weijun Wang <weijun at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/90cd2fa16458dcc3e36171fa4bf21f26bc92b168
Stats:     283 lines in 22 files changed: 147 ins; 98 del; 38 mod

8270859: Post JEP 411 refactoring: client libs with maximum covering > 10K

Reviewed-by: serb

-------------

PR: https://git.openjdk.java.net/jdk/pull/4815

From github.com+42199859+nikolaytach at openjdk.java.net  Wed Jul 28 17:21:30 2021
From: github.com+42199859+nikolaytach at openjdk.java.net (NikolayTach)
Date: Wed, 28 Jul 2021 17:21:30 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8181571: printing to CUPS fails on mac
 sandbox app
In-Reply-To: <2Mgxu1zmn4d0AJ1JsWHH4oO5PtUDtNfCQE8UYu7hkmc=.a080d861-8fec-4677-aa7b-dabdf431b5b4@github.com>
References: <2Mgxu1zmn4d0AJ1JsWHH4oO5PtUDtNfCQE8UYu7hkmc=.a080d861-8fec-4677-aa7b-dabdf431b5b4@github.com>
Message-ID: <63JwCGX6p50e5FOnMIuUEOUKrfIm4HkJXEO55VBeHWg=.ea74605e-ff56-4526-b2f8-a5d5f1fd8995@github.com>

On Wed, 21 Jul 2021 15:45:55 GMT, Alexander Scherbatiy <alexsch at openjdk.org> wrote:

> The issue is reproduced on macOS Big Sur 11.0.1 with jdk 16.0.1+9.
> 
> Create a native macOS app from the Hello.java file, sign and run it in sandbox:
> 
> import javax.print.*;
> import javax.swing.*;
> 
> public class Hello {
> 
>     public static void main(String[] args) throws Exception {
>         SwingUtilities.invokeAndWait(() -> {
>             boolean isSandboxed = System.getenv("APP_SANDBOX_CONTAINER_ID") != null;
>             PrintService defaultPrinter = PrintServiceLookup.lookupDefaultPrintService();
>             PrintService[] services = PrintServiceLookup.lookupPrintServices(null, null);
> 
>             StringBuilder builder = new StringBuilder();
>             builder.append("is sandboxed: ").append(isSandboxed).append("\n");
>             builder.append("default printer: ").append(defaultPrinter).append("\n");
>             int size = services.length;
>             for (int i = 0; i < size; i++) {
>                 builder.append("printer[").append(i).append("]=").append(services[i]).append("\n");
>             }
>             JOptionPane.showMessageDialog(null, builder.toString());
>         });
>     }
> }
> 
> The signed app in sandbox shows null default printer and PrintServiceLookup.lookupPrintServices(null, null) returns "Unix Printer: lp".
> ![PrintSandboxedApp](https://bugs.openjdk.java.net/secure/attachment/95629/PrintSandboxedApp.png)
> 
> The problem has been discussed on  2d-dev mail list:
>   https://mail.openjdk.java.net/pipermail/2d-dev/2017-June/008375.html
>   https://mail.openjdk.java.net/pipermail/2d-dev/2017-July/008418.html
> 
> According to the discussion:
> 
>> I've submitted a DTS incident to Apple and a friend there has followed-up.
>> Their unofficial position is that java should be connecting to the cups interface returned
>> by the cupsServer() function and not changing the interface string to "localhost".
>> Security changes in 10.12.4 reject the TCP connection which they say confuses
>> network-client access with print access.  They don't seem interested in loosening that change.
> 
> 
> The proposed solution is to use the domain socket pathname in httpConnect(...) cups function and cupsGetDests(...) to get list of printers from cups  when the app is signed and is run in sandbox on MacOs.

[JDK-8247768 ](https://bugs.openjdk.java.net/browse/JDK-8247768)
Same here played 6 times yet moved, 8 issues missed.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4861

From avu at openjdk.java.net  Wed Jul 28 17:39:32 2021
From: avu at openjdk.java.net (Alexey Ushakov)
Date: Wed, 28 Jul 2021 17:39:32 GMT
Subject: [OpenJDK 2D-Dev] [jdk17] Withdrawn: 8266079: Lanai: AlphaComposite
 shows differences on Metal compared to OpenGL
In-Reply-To: <a3xpk6ClZB2__CikIXazTo8cnlVr_ppS03q66O36uu8=.3cf9bb53-ddbf-40cf-8b1c-74a150945d89@github.com>
References: <a3xpk6ClZB2__CikIXazTo8cnlVr_ppS03q66O36uu8=.3cf9bb53-ddbf-40cf-8b1c-74a150945d89@github.com>
Message-ID: <-RHSKRSUc959ZIAuVN8HO1tafeIJasE93vWBC5q631E=.38c3347e-61c5-4f77-a2fa-3e08a40164df@github.com>

On Tue, 15 Jun 2021 16:57:00 GMT, Alexey Ushakov <avu at openjdk.org> wrote:

> Implemented blit via compute kernel

This pull request has been closed without being integrated.

-------------

PR: https://git.openjdk.java.net/jdk17/pull/62

From avu at openjdk.java.net  Wed Jul 28 17:39:32 2021
From: avu at openjdk.java.net (Alexey Ushakov)
Date: Wed, 28 Jul 2021 17:39:32 GMT
Subject: [OpenJDK 2D-Dev] [jdk17] RFR: 8266079: Lanai: AlphaComposite
 shows differences on Metal compared to OpenGL [v5]
In-Reply-To: <pppqA2YSjwiNvZPnUOul1cXtmDA_w0kgxkfv6rvV87A=.18e56cea-d453-4e6d-b87b-15fd696c3ea0@github.com>
References: <a3xpk6ClZB2__CikIXazTo8cnlVr_ppS03q66O36uu8=.3cf9bb53-ddbf-40cf-8b1c-74a150945d89@github.com>
 <pppqA2YSjwiNvZPnUOul1cXtmDA_w0kgxkfv6rvV87A=.18e56cea-d453-4e6d-b87b-15fd696c3ea0@github.com>
Message-ID: <raRHKGVqYa7QUwKy_5ooFVkTQ4EiXr_FTMLrF3Ku_OQ=.ea6fccd4-fc3a-4022-8da6-8fb775bed634@github.com>

On Mon, 5 Jul 2021 15:55:20 GMT, Alexey Ushakov <avu at openjdk.org> wrote:

>> Implemented blit via compute kernel
>
> Alexey Ushakov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8266079: Lanai: AlphaComposite shows differences on Metal compared to OpenGL
>   
>   Minor cleanup

Moving this request to jdk18

-------------

PR: https://git.openjdk.java.net/jdk17/pull/62

From kustaa.nyholm at sparetimelabs.com  Wed Jul 28 19:11:36 2021
From: kustaa.nyholm at sparetimelabs.com (Kustaa Nyholm)
Date: Wed, 28 Jul 2021 22:11:36 +0300
Subject: [OpenJDK 2D-Dev] Black screen on Raspberry Pi / Manjaro
Message-ID: <F44CE7C7-C63C-482B-BB9F-7C03BE8CDC8B@sparetimelabs.com>

Hi,

I'm afraid this is the wrong mailing list or venue but have to start from somewhere.

I just tested my Swing app using OpenJDK 11.0.1 on Raspberry Pi 4 / Manjaro and it worked great.

I then enabled the OpenGL pipeline with

-Dsun.java2d.opengl=True

and console confirmed that the pipeline was enabled.

The rending now  fails as follows:

During the initial rendering of Swing components (it is a bit slow so I can see what happens)
a lot of extra black follows or preceeds rendering  of every Swing component. When the
rendering is complete the whole window goes black except a white border around an
OpenGL canvas component. 

As I move the cursor around the component under the cursor flashes correctly rendered but
remains black.

If I resize the window, the whole window flashes briefly (much much faster that what
normal rendering takes place) with the correct rendering but then goes black again.

I tried this with X11 and Wayland enabled KDE (if it makes a difference, perhaps Java2D
rendring is not affected by the Desktop rendering....


Is this a driver issue?

If so where should I turn next to ask questions like what driver I'm using and whom 
to report the problem?


I'm rather new to Linux / Raspberry so the driver / open source bug reporting
is kind of unclear to me...

wbr Kusti


From rriggs at openjdk.java.net  Thu Jul 29 16:44:55 2021
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Thu, 29 Jul 2021 16:44:55 GMT
Subject: [OpenJDK 2D-Dev] [jdk17] RFR: 8271489: (doc) Clarify Filter Factory
 example
Message-ID: <0p6tjDXve1NzwIv5CqU2RjJgL9R0t0Je8scHatsVlTU=.a49cd354-ca52-4a8c-8481-dde3431a4a27@github.com>

Improve the clarity of comments in the ObjectInputFilter FilterInThread example.

-------------

Commit messages:
 - 8271489: (doc) Clarify Filter Factory example
 - 8270398: Enhance canonicalization
 - 8270404: Better canonicalization
 - Merge
 - Merge
 - 8263531: Remove unused buffer int
 - 8262731: [macOS] Exception from "Printable.print" is swallowed during "PrinterJob.print"
 - 8269763: The JEditorPane is blank after JDK-8265167
 - 8265580: Enhanced style for RTF kit
 - 8265574: Improve handling of sheets
 - ... and 15 more: https://git.openjdk.java.net/jdk17/compare/c1304519...650e1561

Changes: https://git.openjdk.java.net/jdk17/pull/292/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk17&pr=292&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8271489
  Stats: 1001 lines in 42 files changed: 625 ins; 181 del; 195 mod
  Patch: https://git.openjdk.java.net/jdk17/pull/292.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk17 pull/292/head:pull/292

PR: https://git.openjdk.java.net/jdk17/pull/292

From rriggs at openjdk.java.net  Thu Jul 29 17:46:36 2021
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Thu, 29 Jul 2021 17:46:36 GMT
Subject: [OpenJDK 2D-Dev] [jdk17] Withdrawn: 8271489: (doc) Clarify Filter
 Factory example
In-Reply-To: <0p6tjDXve1NzwIv5CqU2RjJgL9R0t0Je8scHatsVlTU=.a49cd354-ca52-4a8c-8481-dde3431a4a27@github.com>
References: <0p6tjDXve1NzwIv5CqU2RjJgL9R0t0Je8scHatsVlTU=.a49cd354-ca52-4a8c-8481-dde3431a4a27@github.com>
Message-ID: <4o8A0bH9cVUSjB1lO6rW6Z3QT1KTxpu9Z0IaWK3c_-g=.25c55618-f4b9-46d6-9e4e-39674df24ca9@github.com>

On Thu, 29 Jul 2021 16:36:21 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> Improve the clarity of comments in the ObjectInputFilter FilterInThread example.

This pull request has been closed without being integrated.

-------------

PR: https://git.openjdk.java.net/jdk17/pull/292

From avu at openjdk.java.net  Fri Jul 30 15:48:50 2021
From: avu at openjdk.java.net (Alexey Ushakov)
Date: Fri, 30 Jul 2021 15:48:50 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8266079: Lanai: AlphaComposite shows
 differences on Metal compared to OpenGL
Message-ID: <7FfjAXZJPIzx2OfaLY8dlET6NVnF-XAiaAI7mJwNGeo=.2381d679-8860-4c79-a7bd-4749f10bb90e@github.com>

Keep MTLLayer opacity in sync with window content view
Keep layer translucent for translucent windows

-------------

Commit messages:
 - 8266079: Lanai: AlphaComposite shows differences on Metal compared to OpenGL

Changes: https://git.openjdk.java.net/jdk/pull/4946/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4946&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8266079
  Stats: 270 lines in 7 files changed: 266 ins; 1 del; 3 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4946.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4946/head:pull/4946

PR: https://git.openjdk.java.net/jdk/pull/4946