Re: JDK 16 RFR of JDK-8250240: Address use of default constructors in the java.util.concurrent

Hi Martin, Okay; I'll push with "public", but would be fine if the 166-alpha crew want to revisit for "protected". Thanks for the review, -Joe On 7/23/2020 7:49 PM, Martin Buchholz wrote: I'm happy with this change whether or not the slightly more evocative "protected" is used. On Thu, Jul

Re: RFR: 8188055: (ref) Add Reference.refersTo predicate

Hi Kim, On 22/07/2020 6:04 pm, Kim Barrett wrote: On Apr 8, 2020, at 5:27 AM, David Holmes wrote: Hi Kim, Apparently I lost track of these comments and forgot to respond. Thanks for the follow up - I figured it was all "on hold". Cheers, David I still won't be sending out a new webrev u

Re: RFR(s): Support graceful application termination on Windows shutdown/logoff

Hi Nikola, I'm redirecting this to the core-libs team initially because this is an issue that has been raised and discussed considerably in the past (possibly with some misunderstanding relating to the WM_ENDSESSION event). The core-libs team need to confirm the intended semantics here and we

Re: JDK 16 RFR of JDK-8250240: Address use of default constructors in the java.util.concurrent

I'm happy with this change whether or not the slightly more evocative "protected" is used. On Thu, Jul 23, 2020 at 5:43 PM Joe Darcy wrote: > > Hi Martin, > > On 7/23/2020 5:24 PM, Martin Buchholz wrote: > > So these are all abstract classes where the constructor can only be > > called via super(

Re: JDK 16 RFR of JDK-8250237: Address use of default constructors in the javax.script package

Looks good -Sundar On 24/07/20 2:54 am, Joe Darcy wrote: Hello, One class in the javax.script package uses a default constructor; please review the patch below and CSR (https://bugs.openjdk.java.net/browse/JDK-8250239) to replace it with an explicit constructor. Thanks, -Joe diff -r d62

Re: JDK 16 RFR of JDK-8250240: Address use of default constructors in the java.util.concurrent

Hi Martin, On 7/23/2020 5:24 PM, Martin Buchholz wrote: So these are all abstract classes where the constructor can only be called via super() ? Yep. In which case one would expect the constructors to be protected, not public. But I'm probably missing some reason why "protected" would not be

Re: JDK 16 RFR of JDK-8250240: Address use of default constructors in the java.util.concurrent

So these are all abstract classes where the constructor can only be called via super() ? In which case one would expect the constructors to be protected, not public. But I'm probably missing some reason why "protected" would not be 100% compatible. Historically, we've preferred to put changes in v

Re: 8248248: [macos] EmptyFolderPackageTest.java fails EmptyFolderPackageTest-dmg-setup.scpt exited with 134 code

Looks good. - Alexey On 7/23/2020 7:17 PM, alexander.matv...@oracle.com wrote: http://cr.openjdk.java.net/~almatvee/8248248/webrev.01/ - Added INFINITE_TIMEOUT instead of -1. - Fix actually did not work correctly and process never timeout, since we were reading process output and wait with ti

Re: 8248248: [macos] EmptyFolderPackageTest.java fails EmptyFolderPackageTest-dmg-setup.scpt exited with 134 code

http://cr.openjdk.java.net/~almatvee/8248248/webrev.01/ - Added INFINITE_TIMEOUT instead of -1. - Fix actually did not work correctly and process never timeout, since we were reading process output and wait with timeout never executed, since reading output was continue until process terminated.

Re: RFR 8249217: Unexpected StackOverflowError in "process reaper" thread still happens

+1 On Thu, Jul 23, 2020 at 3:50 PM David Holmes wrote: > > Still good. > > Thanks, > David > > On 24/07/2020 12:11 am, Roger Riggs wrote: > > Webrev updated with Martin's suggestion: > > > > http://cr.openjdk.java.net/~rriggs/webrev-stackoverflow-8249217-2/ > > > > Thanks, Roger > > > > > > On 7/

Re: RFR 8249217: Unexpected StackOverflowError in "process reaper" thread still happens

Still good. Thanks, David On 24/07/2020 12:11 am, Roger Riggs wrote: Webrev updated with Martin's suggestion: http://cr.openjdk.java.net/~rriggs/webrev-stackoverflow-8249217-2/ Thanks, Roger On 7/22/20 8:35 PM, Martin Buchholz wrote: Roger: You're absolutely right!  I should have looked.

Re: JDK 16 RFR of JDK-8250240: Address use of default constructors in the java.util.concurrent

+1 -- Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 lance.ander...@oracle.com Sent from my iPhone > On Jul 23, 2020, at 6:04 PM, Joe Darcy wrote: > > Hello, > > Martin, how would you prefer these changes,

JDK 16 RFR of JDK-8250240: Address use of default constructors in the java.util.concurrent

Hello, Martin, how would you prefer these changes, or equivalent ones, to get into the java.util.concurrent upstream sources? Several classes in java.util.concurrent rely on default constructors, which is not recommended.  Please review the patch below which removes them along with the corre

Re: JDK 16 RFR of JDK-8250237: Address use of default constructors in the javax.script package

+1 Best, Lance Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 lance.ander...@oracle.com Sent from my iPad > On Jul 23, 2020, at 5:24 PM, Joe Darcy wrote: > > Hello, > > One class in the javax.script packa

Re: JDK 16 RFR of JDK-8250237: Address use of default constructors in the javax.script package

+1 Paul. > On Jul 23, 2020, at 2:24 PM, Joe Darcy wrote: > > Hello, > > One class in the javax.script package uses a default constructor; please > review the patch below and CSR > (https://bugs.openjdk.java.net/browse/JDK-8250239) to replace it with an > explicit constructor. > > Thanks, >

JDK 16 RFR of JDK-8250237: Address use of default constructors in the javax.script package

Hello, One class in the javax.script package uses a default constructor; please review the patch below and CSR (https://bugs.openjdk.java.net/browse/JDK-8250239) to replace it with an explicit constructor. Thanks, -Joe diff -r d62da6fc4074 src/java.scripting/share/classes/javax/script/Com

Re: RFR(M): 8249963: Make the zlib implementation selectively configurable at startup

nis/webrevs/2020/8249963/ > > https://bugs.openjdk.java.net/browse/JDK-8249963 > > > > I've tested these changes locally on Linux/Windows/Mac without any > > problems but got a Mach5 build error for Windows after sending them to > > the submit repo (Job: > >

Re: RFR(T): 8250236: ProblemList java/lang/invoke/lambda/LambdaFileEncodingSerialization.java on linux-x64

Thanks for the fast review. Dan On 7/23/20 4:34 PM, Roger Riggs wrote: Looks good, thanks On 7/23/20 4:30 PM, Daniel D. Daugherty wrote: Accidentally pushed send before I was done. Please ignore the previous email... Greetings, I'm making another pass at reducing the noise in the JDK16 C

Re: RFR 8250235: java/lang/invoke/lambda/LambdaFileEncodingSerialization.java should be on the problem list

Thanks, but never mind, Dan and I had a race to get this on the Problem List;  I lost. (Or Won, I'm not sure which). On 7/23/20 4:30 PM, Lance @ Oracle wrote: +1 Best, Lance [null] _ _ Lance Andersen| Principal Member of Technical Sta

Re: RFR(T): 8250236: ProblemList java/lang/invoke/lambda/LambdaFileEncodingSerialization.java on linux-x64

Looks good, thanks On 7/23/20 4:30 PM, Daniel D. Daugherty wrote: Accidentally pushed send before I was done. Please ignore the previous email... Greetings, I'm making another pass at reducing the noise in the JDK16 CI. There are currently 34 sightings of this test failure since I filed the

Re: RFR 8250235: java/lang/invoke/lambda/LambdaFileEncodingSerialization.java should be on the problem list

+1 Best, Lance Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 lance.ander...@oracle.com Sent from my iPad > On Jul 23, 2020, at 4:28 PM, Roger Riggs wrote: > > Please review adding an intermittent test to

RFR(T): 8250236: ProblemList java/lang/invoke/lambda/LambdaFileEncodingSerialization.java on linux-x64

Accidentally pushed send before I was done. Please ignore the previous email... Greetings, I'm making another pass at reducing the noise in the JDK16 CI. There are currently 34 sightings of this test failure since I filed the bug on 2020.07.08. I think it is time to ProblemList this test. For

RFR(T): 8250236: ProblemList java/lang/invoke/lambda/LambdaFileEncodingSerialization.java on linux-x64

Greetings, I'm making another pass at reducing the noise in the JDK16 CI. There are currently 34 sightings of this test failure since I filed the bug on 2020.07.08. I think it is time to ProblemList this test. For whatever reason, this failures only seems to be happening on Linux-X64 machines.

RFR 8250235: java/lang/invoke/lambda/LambdaFileEncodingSerialization.java should be on the problem list

Please review adding an intermittent test to the ProblemList. The test java/lang/invoke/lambda/LambdaFileEncodingSerialization.java has been failing intermittently and fairly frequently. [1] diff a/test/jdk/ProblemList.txt b/test/jdk/ProblemList.txt --- a/test/jdk/ProblemList.txt +++ b/test/jd

Re: RFR(M): 8249963: Make the zlib implementation selectively configurable at startup

enjdk.java.net/~simonis/webrevs/2020/8249963/ > https://bugs.openjdk.java.net/browse/JDK-8249963 > > I've tested these changes locally on Linux/Windows/Mac without any > problems but got a Mach5 build error for Windows after sending them to > the submit repo (Job: > mach5-o

Re: JDK 16 RFR of JDK-8250221: Address use of default constructors in java.logging

Hi Joe, LGTM. best regards, -- daniel On 23/07/2020 18:37, Joe Darcy wrote: Hello, Please review the changes for     JDK-8250221: Address use of default constructors in java.logging     webrev: http://cr.openjdk.java.net/~darcy/8250221.0/     CSR: https://bugs.openjdk.java.net/browse/JDK

Re: RFR JDK-8250219: Proxy::newProxyInstance spec should specify the behavior if a given proxy interface is hidden

On 23/07/2020 19:40, Mandy Chung wrote: CSR: https://bugs.openjdk.java.net/browse/JDK-8250224 Webrev: http://cr.openjdk.java.net/~mchung/jdk16/webrevs/8250219/webrev.00/ This patch updates the `|Proxy::newProxyInstance` |spec to explicitly list that the given interfaces must be non-hidden in

Re: RFR(M): 8249963: Make the zlib implementation selectively configurable at startup

On 23/07/2020 18:18, Volker Simonis wrote: Hi, can I please get some reviews for the following small enhancement which will allow you to configure different zlib implementations at VM start-up and get up to 100% better throughput for compression and about 50% better throughput for decompression

RFR JDK-8250219: Proxy::newProxyInstance spec should specify the behavior if a given proxy interface is hidden

CSR: https://bugs.openjdk.java.net/browse/JDK-8250224 Webrev: http://cr.openjdk.java.net/~mchung/jdk16/webrevs/8250219/webrev.00/ This patch updates the `|Proxy::newProxyInstance` |spec to explicitly list that the given interfaces must be non-hidden interfaces.|  Proxy::newProxyInstance| curre

Re: JDK 16 RFR of JDK-8250221: Address use of default constructors in java.logging

+1 > On Jul 23, 2020, at 1:37 PM, Joe Darcy wrote: > > ErrorManager.jav

JDK 16 RFR of JDK-8250221: Address use of default constructors in java.logging

Hello, Please review the changes for     JDK-8250221: Address use of default constructors in java.logging     webrev: http://cr.openjdk.java.net/~darcy/8250221.0/     CSR: https://bugs.openjdk.java.net/browse/JDK-8250223 This is part of a larger effort to remove reliance of default constructor

RFR(M): 8249963: Make the zlib implementation selectively configurable at startup

https://bugs.openjdk.java.net/browse/JDK-8249963 I've tested these changes locally on Linux/Windows/Mac without any problems but got a Mach5 build error for Windows after sending them to the submit repo (Job: mach5-one-simonis-JDK-8249963-20200723-1236-12890347, BuildId: 2020-07-23-1235507.volker.simo

Re: [aarch64-port-dev ] RFR (XXL): 8223347: Integration of Vector API (Incubator): AArch64 backend changes

Hello Ningsheng, Build change looks good. /Erik On 2020-07-23 01:02, Ningsheng Jian wrote: Hi Vladimir, Thanks for pointing out this. Yes, I missed that change in shared code. I've regenerated the webrev, with GensrcAdlc.gmk file change included: http://cr.openjdk.java.net/~njian/vectorap

Re: [aarch64-port-dev ] RFR (XXL): 8223347: Integration of Vector API (Incubator): AArch64 backend changes

Hi Vladimir, Thanks for pointing out this. Yes, I missed that change in shared code. I've regenerated the webrev, with GensrcAdlc.gmk file change included: http://cr.openjdk.java.net/~njian/vectorapi/8223347-integration/aarch64-webrev.01/ Also add build-dev. Thanks, Ningsheng On 7/23/20 5:3

Re: RFR: JDK-8222187: java.util.Base64.Decoder stream adds unexpected null bytes at the end

Thanks for pushing changeset 865b5ca81009. Raffaello On 2020-07-21 19:18, Lance Andersen wrote: Hi Roger, I will plan to push tomorrow morning pending any last minute reviews Best Lance On Jul 21, 2020, at 9:57 AM, Roger Riggs > wrote: Hi Rafaello, Lance, T

Re: RFR 8249217: Unexpected StackOverflowError in "process reaper" thread still happens

Webrev updated with Martin's suggestion: http://cr.openjdk.java.net/~rriggs/webrev-stackoverflow-8249217-2/ Thanks, Roger On 7/22/20 8:35 PM, Martin Buchholz wrote: Roger: You're absolutely right! I should have looked. On Wed, Jul 22, 2020 at 5:25 PM Roger Riggs wrote: Hi Martin, That's

Re: RFR: JDK-8247592: refactor test/jdk/tools/launcher/Test7029048.java

Thanks Mandy, that would be much appreciated! On 23/07/2020 07:24, Mandy Chung wrote: > Hi Aleksei, > > Looks good.  I can sponsor this. > > Mandy > > On 7/22/20 1:32 AM, Aleksei Voitylov wrote: >> Hi Mandy, >> >> here is the webrev which addresses your comments: >> >> http://cr.openjdk.java.net/~