Re: RFR: JEP 367: Remove the Pack200 Tools and API

Hi, Updated webrev[1] reflect comments since last webrev. Vicente had done all the heavy-lifting and hand over to me to finish up. Changes to symbols is reverted, as we expect that only need to be updated in next release by running make/scripts/generate-symbol-data.sh. The jar files are

Re: RFR: 8234185: Cleanup usage of canonicalize function between libjava, hotspot and libinstrument

Hi Christoph, On 5/12/2019 9:55 pm, Langer, Christoph wrote: Hi David, thanks again for your efforts. Here is a version that ran successfully through jdk-submit (mach5-one-clanger-JDK-8234185-3-20191205-1051-7247172): http://cr.openjdk.java.net/~clanger/webrevs/8234185.2/ I avoid

RFR 8235359: Simplify method Class.getRecordComponents()

Hi, Please review this small change to simplify Class.getRecordComponents() by changing the return type of getRecordComponents0() to RecordComponent[]. Open Webrev: http://cr.openjdk.java.net/~hseigel/bug_8235359/webrev/index.html JBS Bug: https://bugs.openjdk.java.net/browse/JDK-8235359

Re: RFR 8235359: Simplify method Class.getRecordComponents()

Thanks Fred! Harold On 12/5/2019 9:50 AM, Frederic Parain wrote: Looks good to me. Fred On Dec 5, 2019, at 09:36, Harold Seigel wrote: Hi, Please review this small change to simplify Class.getRecordComponents() by changing the return type of getRecordComponents0() to RecordComponent[].

Re: RFR 8235359: Simplify method Class.getRecordComponents()

Looks good to me. Fred > On Dec 5, 2019, at 09:36, Harold Seigel wrote: > > Hi, > > Please review this small change to simplify Class.getRecordComponents() by > changing the return type of getRecordComponents0() to RecordComponent[]. > > Open Webrev:

Re: RFR 8235359: Simplify method Class.getRecordComponents()

Looks good. Lois On 12/5/2019 9:36 AM, Harold Seigel wrote: Hi, Please review this small change to simplify Class.getRecordComponents() by changing the return type of getRecordComponents0() to RecordComponent[]. Open Webrev:

Re: RFR 8235359: Simplify method Class.getRecordComponents()

> On 5 Dec 2019, at 14:36, Harold Seigel wrote: > > Hi, > > Please review this small change to simplify Class.getRecordComponents() by > changing the return type of getRecordComponents0() to RecordComponent[]. > > Open Webrev: >

Re: RFR 8235359: Simplify method Class.getRecordComponents()

Thanks Lois and Chris! Harold On 12/5/2019 9:56 AM, Chris Hegarty wrote: On 5 Dec 2019, at 14:36, Harold Seigel > wrote: Hi, Please review this small change to simplify Class.getRecordComponents() by changing the return type of getRecordComponents0() to

Re: RFR: 8234185: Cleanup usage of canonicalize function between libjava, hotspot and libinstrument

On 12/5/19 8:00 AM, David Holmes wrote: Hi Christoph, On 5/12/2019 9:55 pm, Langer, Christoph wrote: Hi David, thanks again for your efforts. Here is a version that ran successfully through jdk-submit (mach5-one-clanger-JDK-8234185-3-20191205-1051-7247172): http://cr.openjdk.java.net

RE: RFR: 8234185: Cleanup usage of canonicalize function between libjava, hotspot and libinstrument

Hi David, I prepared an updated webrev: http://cr.openjdk.java.net/~clanger/webrevs/8234185.3/ > src/java.base/windows/native/libjava/canonicalize_md.c > > +// We can't include jdk_util.h here because the file is used in Oracle > in another context > +// #include "jdk_util.h" > > Seems to me

Re: RFR 8235359: Simplify method Class.getRecordComponents()

looks good, Vicente On 12/5/19 9:36 AM, Harold Seigel wrote: Hi, Please review this small change to simplify Class.getRecordComponents() by changing the return type of getRecordComponents0() to RecordComponent[]. Open Webrev:

JDK 14 RFR of JDK-8235369: "Class.toGenericString need to be updated for records"

Hello, Please review this small cleanup to records support in java.lang.Class:     JDK-8235369: "Class.toGenericString need to be updated for records"     CSR: https://bugs.openjdk.java.net/browse/JDK-8235428     webrev: http://cr.openjdk.java.net/~darcy/8235369.0/ Patch below; thanks, -Joe

Re: RFR 8235359: Simplify method Class.getRecordComponents()

Thanks Vicente! Harold On 12/5/2019 11:44 AM, Vicente Romero wrote: looks good, Vicente On 12/5/19 9:36 AM, Harold Seigel wrote: Hi, Please review this small change to simplify Class.getRecordComponents() by changing the return type of getRecordComponents0() to RecordComponent[]. Open

Re: [14] RFR: 8222756: Plural support in CompactNumberFormat

Thanks, Joe and Roger, for the reviews. Here is the updated webrev: http://cr.openjdk.java.net/~naoto/8222756/webrev.02/ These are the changes since v.01: CompactNumberFormat.java: - Reflected the CSR changes (thank you, JoeD, for the quick turnaround!), and misc typos in the spec. - Added

Re: RFR 8235359: Simplify method Class.getRecordComponents()

Looks good. Mandy On 12/5/19 6:36 AM, Harold Seigel wrote: Hi, Please review this small change to simplify Class.getRecordComponents() by changing the return type of getRecordComponents0() to RecordComponent[]. Open Webrev:

Re: RFR 8235359: Simplify method Class.getRecordComponents()

Thanks Mandy! Harold On 12/5/2019 1:59 PM, Mandy Chung wrote: Looks good. Mandy On 12/5/19 6:36 AM, Harold Seigel wrote: Hi, Please review this small change to simplify Class.getRecordComponents() by changing the return type of getRecordComponents0() to RecordComponent[]. Open Webrev:

Re: [14] RFR: 8222756: Plural support in CompactNumberFormat

Hi Naoto, Thanks for the updates. Looks fine. Roger On 12/5/19 1:49 PM, naoto.s...@oracle.com wrote: Thanks, Joe and Roger, for the reviews. Here is the updated webrev: http://cr.openjdk.java.net/~naoto/8222756/webrev.02/ These are the changes since v.01: CompactNumberFormat.java: -

Re: RFR: JEP 367: Remove the Pack200 Tools and API

On 12/5/19 12:41 AM, Alan Bateman wrote: On 05/12/2019 08:16, Henry Jen wrote: Hi, Updated webrev[1] reflect comments since last webrev. Vicente had done all the heavy-lifting and hand over to me to finish up. Changes to symbols is reverted, as we expect that only need to be updated in

Re: JDK 14 RFR of JDK-8235369: "Class.toGenericString need to be updated for records"

looks good, Vicente On 12/5/19 1:08 PM, Joe Darcy wrote: Hello, Please review this small cleanup to records support in java.lang.Class:     JDK-8235369: "Class.toGenericString need to be updated for records"     CSR: https://bugs.openjdk.java.net/browse/JDK-8235428     webrev:

Re: JDK 14 RFR of JDK-8235369: "Class.toGenericString need to be updated for records"

+1 Mandy On 12/5/19 10:08 AM, Joe Darcy wrote: Hello, Please review this small cleanup to records support in java.lang.Class:     JDK-8235369: "Class.toGenericString need to be updated for records"     CSR: https://bugs.openjdk.java.net/browse/JDK-8235428     webrev:

Re: [14] RFR: 8222756: Plural support in CompactNumberFormat

+1, looks good! Best regards, Joe On 12/5/19 12:13 PM, Roger Riggs wrote: Hi Naoto, Thanks for the updates. Looks fine. Roger On 12/5/19 1:49 PM, naoto.s...@oracle.com wrote: Thanks, Joe and Roger, for the reviews. Here is the updated webrev:

RFR JDK-8234049: Implementation of Memory Access API (Incubator)

Hi, as part of the effort to upstream the changes related to JEP 370 (foreign memory access API) [1], I'd like to ask for a code review for the corresponding core-libs and hotspot changes: http://cr.openjdk.java.net/~mcimadamore/panama/8234049/ A javadoc for the memory access API is also

Re: JDK 14 RFR of JDK-8235369: "Class.toGenericString need to be updated for records"

LGTM. -Chris > On 5 Dec 2019, at 18:08, Joe Darcy wrote: > > Hello, > > Please review this small cleanup to records support in java.lang.Class: > > JDK-8235369: "Class.toGenericString need to be updated for records" > CSR: https://bugs.openjdk.java.net/browse/JDK-8235428 >

Re: RFR JDK-8234049: Implementation of Memory Access API (Incubator)

Awesome work, Maurizio! Regarding hotspot changes: * ciField.cpp - this one is to trust final fields in the foreign memory access implementation (otherwise VM doesn't trust memory segment bounds) New packages aren't part of java.base. Considering the implementation resides in an incubator

RFR: JDK-8233270: Add support to jtreg helpers to unpack packages

Please review  fixes for [1] and [2]. Both target jpackage tool. The webrev is at [3]. [1] https://bugs.openjdk.java.net/browse/JDK-8233270 [2] https://bugs.openjdk.java.net/browse/JDK-8230933 [3] http://cr.openjdk.java.net/~asemenyuk/8233270/webrev.00/

Re: RFR: 8234185: Cleanup usage of canonicalize function between libjava, hotspot and libinstrument

-20191205-1051-7247172): http://cr.openjdk.java.net/~clanger/webrevs/8234185.2/ I avoid the inclusion of jdk_util.h in src/java.base/windows/native/libjava/canonicalize_md.c. Do you think this is good to go? Avoiding the include does seem to be the way to go. That seems so obvious now. src

Re: RFR JDK-8234049: Implementation of Memory Access API (Incubator)

On 05/12/2019 22:39, Vladimir Ivanov wrote: Awesome work, Maurizio! Regarding hotspot changes: * ciField.cpp - this one is to trust final fields in the foreign memory access implementation (otherwise VM doesn't trust memory segment bounds) New packages aren't part of java.base.

Re: RFR JDK-8234049: Implementation of Memory Access API (Incubator)

Hi Maurizio, that's a huge work :) So as a guy discovering the API, i've not taken a deep look to the implementation because i've noob questions. The first sentence of the overview of GroupLayout should say that there are two types of GroupLayout struct and union instead of talking about

Re: RFR JDK-8234049: Implementation of Memory Access API (Incubator)

On 06/12/2019 00:13, Remi Forax wrote: Hi Maurizio, that's a huge work :) So as a guy discovering the API, i've not taken a deep look to the implementation because i've noob questions. The first sentence of the overview of GroupLayout should say that there are two types of GroupLayout

Re: RFR: JDK-8233270: Add support to jtreg helpers to unpack packages

I don't understand the relationship between these two bugs. -phil On 12/5/19, 2:47 PM, Alexey Semenyuk wrote: Please review fixes for [1] and [2]. Both target jpackage tool. The webrev is at [3]. [1] https://bugs.openjdk.java.net/browse/JDK-8233270 [2]

Re: RFR: JDK-8233270: Add support to jtreg helpers to unpack packages

Hi Alexey, 1) Remove this file: test/jdk/tools/jpackage/helpers/jdk/jpackage/test/JavaTool.java.rej 2) Agree with Phil, they probably should be pushed as two separate bugs. 3) Do you know how to run installer tests with new changes? It is not clear from code. Changes itself looks fine.

RE: [EXTERNAL] JDK-8234076 bug fix candidate

Hello all again! Based on the suggestion by Kumar I made the following small patch to checkArg src/java.base/share/native/libjli/args.c: --- a/src/java.base/share/native/libjli/args.c +++ b/src/java.base/share/native/libjli/args.c @@ -130,6 +130,8 @@ static void checkArg(const char *arg) {

RFR JDK-8235351: Lookup::unreflect should bind with the original caller independent of Method's accessible flag

When unreflecting on a Method for caller-sensitive method, the produced MethodHandle should bind with the original caller lookup independent of the accessible flag. Webrev:   http://cr.openjdk.java.net/~mchung/jdk14/8235351/webrev.00/ thanks Mandy

Re: RFR: JEP 367: Remove the Pack200 Tools and API

OK, so I created an issue[1] for follow up for Windows build and reverted the change in flags-cflags.m4, if nothing else, I’ll push without another webrev pinging that I get an +1 from someone in build-de, Erik? [1] https://bugs.openjdk.java.net/browse/JDK-8235461 Cheers, Henry > On Dec 5,

Re: [EXTERNAL] JDK-8234076 bug fix candidate

> On Dec 5, 2019, at 5:57 PM, Nikola Grcevski > wrote: > > Hello all again! > > Based on the suggestion by Kumar I made the following small patch to checkArg > src/java.base/share/native/libjli/args.c: > > --- a/src/java.base/share/native/libjli/args.c > +++

Re: RFR: 8234185: Cleanup usage of canonicalize function between libjava, hotspot and libinstrument

Hi Christoph, On 6/12/2019 2:12 am, Langer, Christoph wrote: Hi David, I prepared an updated webrev: http://cr.openjdk.java.net/~clanger/webrevs/8234185.3/ src/java.base/windows/native/libjava/canonicalize_md.c +// We can't include jdk_util.h here because the file is used in Oracle in

Re: RFR: JEP 367: Remove the Pack200 Tools and API

On 05/12/2019 08:16, Henry Jen wrote: Hi, Updated webrev[1] reflect comments since last webrev. Vicente had done all the heavy-lifting and hand over to me to finish up. Changes to symbols is reverted, as we expect that only need to be updated in next release by running

RE: RFR: 8234185: Cleanup usage of canonicalize function between libjava, hotspot and libinstrument

Hi David, thanks again for your efforts. Here is a version that ran successfully through jdk-submit (mach5-one-clanger-JDK-8234185-3-20191205-1051-7247172): http://cr.openjdk.java.net/~clanger/webrevs/8234185.2/ I avoid the inclusion of jdk_util.h in src/java.base/windows/native/libjava

RE: RFR(S): 8220348: [ntintel] asserts about copying unalinged array

Hi Martin, I can see that both places already include headers from src/java.base/share/native/libjava/. I suggest adding the define in jni_util.h. WindowsPreferences.c already includes it. Best regards Christoph From: Doerr, Martin Sent: Donnerstag, 5. Dezember 2019 12:00 To: Thomas Stüfe ;

RE: RFR(S): 8220348: [ntintel] asserts about copying unalinged array

Hi Thomas and Christoph, thanks for the reviews. Other code in java.security.jgss also uses these #defined checks: src/java.security.jgss/share/native/libj2gss/gssapi.h:#if defined (_WIN32) && defined (_MSC_VER) I’d like to have it consistent with that. @Christoph: I think having