Re: RFR 8234147 : Avoid looking up standard charsets in core libraries

On 27/11/2019 04:39, Ivan Gerasimov wrote: Hello! It is a cleanup fix with mostly two kinds of changes: - when a standard charset is specified by its name, use a preinitialized Charset constant instead, - replace the usage of StandardCharset.* constants with their sun.nio.cs.* equivalents to a

RFR(S) : 8234309:LFGarbageCollectedTest.java fails with parse Exception

Hi All, Kindly review the small patch. Moved @library /lib/testlibrary /java/lang/invoke/common to the top to avoid the parse exception and report as Test ignored. JBS: https://bugs.openjdk.java.net/browse/JDK-8234309 Webrev: http://cr.openjdk.java.net/~vagarwal/8234309/webrev.

RFR 8234147 : Avoid looking up standard charsets in core libraries

Hello! It is a cleanup fix with mostly two kinds of changes: - when a standard charset is specified by its name, use a preinitialized Charset constant instead, - replace the usage of StandardCharset.* constants with their sun.nio.cs.* equivalents to avoid accidental early initialization of rar

Re: RFR: JDK-8212780: JEP 343: Packaging Tool Implementation

> I believe otherwise it is an accurate incremental webrev of the jpackage changes since EA-5. It is also not very incremental. * *src/jdk.incubator.jpackage/share/classes/jdk/incubator/jpackage/main/Main.java is definitely not "new" ... -phil. On 11/26/19, 2:17 PM, Andy Herrick wrote: yes,

Re: RFR of JDK-8232446: logging enhancement for rmi when socket closed

Hi Roger, Thanks for reviewing, I have updated as you suggested: http://cr.openjdk.java.net/~mli/8232446/webrev.01/ Thank you -Hamlin On 2019/11/27 2:47 AM, Roger Riggs wrote: Hi Hamlin, ok, but it looses the logging of the connection close when the socket is null. I intended to suggest

Re: jpackage ROOTDIR variable in a Windows bat file

> On Nov 26, 2019, at 2:41 PM, Alexey Semenyuk > wrote: > > > > On 11/26/2019 9:48 AM, Michael Hall wrote: >> >> >>> On Nov 25, 2019, at 11:47 AM, Alexey Semenyuk >> > wrote: >>> > > --name HalfPipe > --runtime-image "c:/Program Files/Java/

Re: [PATCH] Simplification proposal regarding TYPE-field initialization in primitive wrappers

Hi, I saw Remi's reply after I sent my reply. The questions I asked were just to confirm that my suspicion (int.class gets compiled into Integer.TYPE) were true - I am currently on mobile, so I couldn't test it myself. In short, my mail doesn't provide any additional value, and if I had seen R

Re: RFR: JDK-8212780: JEP 343: Packaging Tool Implementation

yes,  this incremental webrev contains the JNLPConverter code, which it should not. I believe otherwise it is an accurate incremental webrev of the jpackage changes since EA-5. /Andy On 11/26/2019 4:53 PM, Phil Race wrote: Andy, I am puzzled by what I see here > The webrev at [3] shows the

Re: RFR: JDK-8212780: JEP 343: Packaging Tool Implementation

Andy, I am puzzled by what I see here > The webrev at [3] shows the changes since EA-06 (Build 13-jpackage+1-49 ) up to the current point. > [3] http://cr.openjdk.java.net/~herrick/8212780/webrev.06-10/ This includes the JNLPConverter which isn't what I expected to see and (correctly) isn't i

Re: RFR: JDK-8212780: JEP 343: Packaging Tool Implementation

This all looks good. +1 -- Kevin On 11/26/2019 12:56 PM, Erik Joelsson wrote: (adding build-dev) Build changes look good. /Erik On 2019-11-20 09:37, Andy Herrick wrote: I posted new composite webrev [7], and git patch [8] after pushing fix for JDK-8234402 [6]. [7] http://cr.openjdk.java

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

I modified CompactNumberFormat.java to simplify the syntax parsing: https://cr.openjdk.java.net/~naoto/8222756/webrev.01/ Please review this webrev instead. Naoto On 11/25/19 1:16 PM, naoto.s...@oracle.com wrote: Hello, CompactNumberFormat has been added since JDK 12 to support compact numb

Re: [PATCH] Simplification proposal regarding TYPE-field initialization in primitive wrappers

Hello, > I suspect that it will print null, because to my knowledge, int.class will be > compiled to a getstatic Integer.TYPE, so your test basically tests if > Integer.TYPE == Integer.TYPE. right, Remi pointed this out in his response. > Also, do the tier1 tests succeed with your patch? I'm

Re: New candidate JEP: 370: Foreign-Memory Access API

Very good suggestion - thanks; I will fix it. Cheers Maurizio On 26/11/2019 20:32, Johannes Kuhn wrote: Hi, Just had the chance to look at the proposal, and I have a small suggestion: MemorySegmenent::mapFromPath should state that it can throw a SecurityException if a SecurityManager is insta

Re: RFR: JDK-8212780: JEP 343: Packaging Tool Implementation

(adding build-dev) Build changes look good. /Erik On 2019-11-20 09:37, Andy Herrick wrote: I posted new composite webrev [7], and git patch [8] after pushing fix for JDK-8234402 [6]. [7] http://cr.openjdk.java.net/~herrick/8212780/webrev.EA-11/ [8] http://cr.openjdk.java.net/~herrick/821278

Re: jpackage ROOTDIR variable in a Windows bat file

On 11/26/2019 9:48 AM, Michael Hall wrote: On Nov 25, 2019, at 11:47 AM, Alexey Semenyuk mailto:alexey.semen...@oracle.com>> wrote: --name HalfPipe --runtime-image "c:/Program Files/Java/jdk-14" --runtime-image and --add-modules parameters should not be used together. If Java run-time

Re: New candidate JEP: 370: Foreign-Memory Access API

Hi, Just had the chance to look at the proposal, and I have a small suggestion: MemorySegmenent::mapFromPath should state that it can throw a SecurityException if a SecurityManager is installed in the javadoc. The description can be copied from FileChannel::open. With best regards, Johannes

Re: [PATCH] Simplification proposal regarding TYPE-field initialization in primitive wrappers

On November 26, 2019 8:29:06 PM GMT+01:00, "Сергей Цыпанов" wrote: >Hello, > >while using java.lang.Integer.TYPE I've found out that currently >wrapper classes for primitives initialize their own TYPE-fields by >calling native method java.lang.Class.getPrimitiveClass(). > >This can be simplifi

Re: [PATCH] Simplification proposal regarding TYPE-field initialization in primitive wrappers

Hello Remi, > int.class is compiled by javac as Integer.TYPE so this is the reason why assertion works in the test. > the opcode ldc only works with an object/interface class, not with a > primitive type [1]. Thanks for pointing this out, I think I should read that whole chapter again. Regard

Re: [PATCH] Simplification proposal regarding TYPE-field initialization in primitive wrappers

Hi Sergey, hum, it doesn't work :) int.class is compiled by javac as Integer.TYPE, the opcode ldc only works with an object/interface class, not with a primitive type [1]. regards, Rémi [1] https://docs.oracle.com/javase/specs/jvms/se13/html/jvms-6.html#jvms-6.5.ldc - Mail original - >

[PATCH] Simplification proposal regarding TYPE-field initialization in primitive wrappers

Hello, while using java.lang.Integer.TYPE I've found out that currently wrapper classes for primitives initialize their own TYPE-fields by calling native method java.lang.Class.getPrimitiveClass(). This can be simplified by changing existing declaration (here for java.lang.Integer) @SuppressW

Re: RFR of JDK-8232446: logging enhancement for rmi when socket closed

Hi Hamlin, ok, but it looses the logging of the connection close when the socket is null. I intended to suggest that the logging happened before/outside the test for socket != null. if (TCPTransport.tcpLog.isLoggable(Log.BRIEF)) { TCPTransport.tcpLog.log(Log.BRIEF,"close connection, socket: "

Re: RFR: 8234799: Word missing in javadoc of java.util.Arrays

+1 > On Nov 26, 2019, at 11:45 AM, Daniel Fuchs wrote: > > Looks good! > > best regards, > > -- daniel > > On 26/11/2019 15:57, Julia Boes wrote: >> Hi, >> The statement is indeed asserted in >> test/jdk/java/util/Arrays/ArraysEqCmpTest.testNullElementsInObjectArray(). >> Also, Lance pointed

RFR: 8234821: remove unused functions from libjli

Hello, please review this small change . It removed unneeded functions from libjli (shown by link-time-gc) . libjli contains a few functions that are shown as unused when applying link-time-gc . Those functions fall into 2 categories : - totally unused/uncalled functions (can be deleted ) -

Re: RFR: 8234799: Word missing in javadoc of java.util.Arrays

Looks good! best regards, -- daniel On 26/11/2019 15:57, Julia Boes wrote: Hi, The statement is indeed asserted in test/jdk/java/util/Arrays/ArraysEqCmpTest.testNullElementsInObjectArray(). Also, Lance pointed out that a CSR is required for this fix. CSR: https://bugs.openjdk.java.net/bro

Re: RFR: 8234525: enable link-time section-gc for linux s390x to remove unused code

On 2019-11-26 04:53, Baesken, Matthias wrote: Erik, may I add you as a reviewer too ? Yes. /Erik

Re: RFR: 8234799: Word missing in javadoc of java.util.Arrays

Hi, The statement is indeed asserted in test/jdk/java/util/Arrays/ArraysEqCmpTest.testNullElementsInObjectArray(). Also, Lance pointed out that a CSR is required for this fix. CSR: https://bugs.openjdk.java.net/browse/JDK-8234810 Regards, Julia On 26/11/2019 10:50, Daniel Fuchs wrote: Hi

Re: jpackage ROOTDIR variable in a Windows bat file

> On Nov 25, 2019, at 11:47 AM, Alexey Semenyuk > wrote: > >>> >>> --name HalfPipe >>> --runtime-image "c:/Program Files/Java/jdk-14" > --runtime-image and --add-modules parameters should not be used together. > If Java run-time image is specified with --runtime-image parameter, jpackage >

RE: RFR: 8234525: enable link-time section-gc for linux s390x to remove unused code

Hi Martin , > Hi Matthias and Erik, > > I also think this is an interesting option. > > I like the idea to generate smaller libraries. In addition to that, I could > also > imagine building with -Os (size optimized) by default and only select -O3 for > performance critical files (e.g. C2's reg

Re: RFR: 8234799: Word missing in javadoc of java.util.Arrays

Hi Julia, Looks good to me. But can you find out if there exists a test where this statement is verified? best regards, -- daniel On 26/11/2019 10:46, Julia Boes wrote: Hi, This is a minor fix, a word was missing in the javadoc of Arrays.compare(compare(T[] a, T[] b). Bug: https://bugs.o

Re: JDK 14 RFR of JDK-8234781: Update description of InvalidClassException to include more conditions

The change looks good to me Joe. Thanks for adding the catch-all clause. This will cover the “bad” record class file, where the canonical constructor is not present. -Chris. > On 26 Nov 2019, at 01:46, Joe Darcy wrote: > > Hello, > > Noticed in the context of doing some other reviews, the s

RFR: 8234799: Word missing in javadoc of java.util.Arrays

Hi, This is a minor fix, a word was missing in the javadoc of Arrays.compare(compare(T[] a, T[] b). Bug: https://bugs.openjdk.java.net/browse/JDK-8234799 Webrev: http://cr.openjdk.java.net/~jboes/webrevs/8234799/webrev.00/ Regards, Julia

RE: RFR: 8234525: enable link-time section-gc for linux s390x to remove unused code

Hi Matthias and Erik, I also think this is an interesting option. I like the idea to generate smaller libraries. In addition to that, I could also imagine building with -Os (size optimized) by default and only select -O3 for performance critical files (e.g. C2's register allocation, some gc cod

Re: JDK 14 RFR of JDK-8234781: Update description of InvalidClassException to include more conditions

On 26/11/2019 01:46, Joe Darcy wrote: : Please review the patch below to include the missing condition and add a catch-all clause to implicitly cover any future changes to the serialization spec (correct by default, event if not as precise as possible). This would not preclude making more