Re: RFR (S): JDK-8222778: Packaging Tool (JEP 343) on Linux/AArch64

On 7/18/19 12:19 AM, Dmitry Chuyko wrote: .. 2. LinuxDebBundler.getArch() now maps only x86_64 to amd64, x86 is still mapped to i386, and other archs map to themselves. 3. In tests, new method getRpmArch() was added to linux/base/Base.java, it maps JVMs os.arch to default rpmbu

Re: RFR: JDK-8227831: Avoid using volatile for write-once, read-many class field

Hi Claes, On 18/07/2019 1:04 am, Claes Redestad wrote: Hi, removing volatile aligns LangReflectAccess initialization with the pattern used for other access objects: it's only initialized in the static initializer of some class which we ensure is initialized, which means any initialization race

Re: RFR: 8227642: [TESTBUG] Make docker tests podman compatible

Sounds good, Thank you, Misha On 7/17/19 6:45 PM, Igor Ignatev wrote: We definitely should do it as a separate RFE, I meant to write it in my email, but was interrupted by a fire drill, and forgot about it when returned. — Igor On Jul 17, 2019, at 6:38 PM, mikhailo.seledt...@oracle.com

Re: RFR: 8227642: [TESTBUG] Make docker tests podman compatible

We definitely should do it as a separate RFE, I meant to write it in my email, but was interrupted by a fire drill, and forgot about it when returned. — Igor > On Jul 17, 2019, at 6:38 PM, mikhailo.seledt...@oracle.com wrote: > > However, I would recommend to do this work as part of a new RFE.

Re: RFR: 8227642: [TESTBUG] Make docker tests podman compatible

On 7/17/19 11:37 AM, Igor Ignatyev wrote: Hi Severin, the updated webrev looks good to me, please see a couple comments below. Cheers, -- Igor On Jul 17, 2019, at 10:34 AM, Severin Gehwolf > wrote: Hi Misha, On Wed, 2019-07-17 at 10:22 -0700,mikhailo.seledt...

Re: 8228338: tools/pack200/TimeStamp.java fails with NullPointerException

A test job I launched before the CI tests just finished now and it looks like this catches all the failures but let’s wait until the CI is done to be certain. Thanks, Brian > On Jul 17, 2019, at 5:09 PM, Lance Andersen wrote: > > All good Brian, I agree and the latest update also looks OK >

Re: 8228338: tools/pack200/TimeStamp.java fails with NullPointerException

All good Brian, I agree and the latest update also looks OK > On Jul 17, 2019, at 8:04 PM, Brian Burkhalter > wrote: > > Sorry Lance but there was another failure which I’ve lumped into the same > issue and updated the webrev in place. I think it would be better to wait > until tiers 1-3 are

Re: 8228338: tools/pack200/TimeStamp.java fails with NullPointerException

Sorry Lance but there was another failure which I’ve lumped into the same issue and updated the webrev in place. I think it would be better to wait until tiers 1-3 are done before looking at it to avoid more spinning. Thanks, Brian > On Jul 17, 2019, at 4:17 PM, Lance Andersen wrote: > > Loo

Re: 8228338: tools/pack200/TimeStamp.java fails with NullPointerException

Looks OK Brian > On Jul 17, 2019, at 7:14 PM, Brian Burkhalter > wrote: > > https://bugs.openjdk.java.net/browse/JDK-8228338 > http://cr.openjdk.java.net/~bpb/8228338/webrev.00/ > > Another slip up due to not having tested the JDK-8067801 patch sufficiently. > > Thanks, > > Brian

8228338: tools/pack200/TimeStamp.java fails with NullPointerException

https://bugs.openjdk.java.net/browse/JDK-8228338 http://cr.openjdk.java.net/~bpb/8228338/webrev.00/ Another slip up due to not having tested the JDK-8067801 patch sufficiently. Thanks, Brian

Re: 8228204: Fix for JDK-8067801 breaks java/io/NegativeInitSize.java

Hi Lance, > On Jul 17, 2019, at 3:10 PM, Lance Andersen wrote: > > Looks OK, please add noreg-self label or equivalent to the issue Done and removed bug number from @bug tag. Pushed. Sorry for the noise. Thanks, Brian

Re: 8228204: Fix for JDK-8067801 breaks java/io/NegativeInitSize.java

Hi Brian, Looks OK, please add noreg-self label or equivalent to the issue > On Jul 17, 2019, at 5:43 PM, Brian Burkhalter > wrote: > > https://bugs.openjdk.java.net/browse/JDK-8228204 > > I lamely did not catch this before the push of the patch for [1]. The diff is > below. > > Thanks, >

Re: RFR: 8227587: Add internal privileged System.loadLibrary

On 7/17/19 3:25 AM, Claes Redestad wrote: Hi Peter, On 2019-07-17 10:29, Peter Levart wrote: Hi Claes, Am I reading correct that package-private ClassLoader.loadLibrary(Class fromClass, String name, boolean isAbsolute) wouldn't need to consult SecurityManager wasn't it for accessing syst

8228204: Fix for JDK-8067801 breaks java/io/NegativeInitSize.java

https://bugs.openjdk.java.net/browse/JDK-8228204 I lamely did not catch this before the push of the patch for [1]. The diff is below. Thanks, Brian [1] https://bugs.openjdk.java.net/browse/JDK-8067801 [2] diff @@ -22,7 +22,7 @@ */ /* @test - @bug 4015701 4127654 + @bug 4015701 412765

Re: 8067801: Enforce null check for underlying I/O streams

Thanks, Lance! > On Jul 17, 2019, at 2:19 PM, Lance Andersen wrote: > > Looks good. Maybe consider expanding to some of the other classes when you > have cycles. But in the meantime, ship it!

Re: RFR (S): JDK-8222778: Packaging Tool (JEP 343) on Linux/AArch64

Hi Andrew, On 7/17/19 11:52 AM, Andrew Haley wrote: On 7/16/19 8:55 PM, Dmitry Chuyko wrote: Hello, Please review a small patch that mostly fixes jpackage test for Linux aarch64 and also arm,x86,power. It is prepared for 'JDK-8200758-branch' branch of open 'sandbox' repo. There are few parts:

Re: 8067801: Enforce null check for underlying I/O streams

Hi Brian > On Jul 17, 2019, at 5:08 PM, Brian Burkhalter > wrote: > > Hi Lance, > >> On Jul 17, 2019, at 1:55 PM, Lance Andersen > > wrote: >> >> I guess the next question(here he goes again ;-) is do you want to test all >> of the constructors such as Buffe

Re: 8067801: Enforce null check for underlying I/O streams

Hi Lance, > On Jul 17, 2019, at 1:55 PM, Lance Andersen wrote: > > I guess the next question(here he goes again ;-) is do you want to test all > of the constructors such as BufferedInputStream(InputStream, int) or just one > per class? I realize the BufferedInputStream(InputStream) just call

Re: RFR (S): JDK-8222778: Packaging Tool (JEP 343) on Linux/AArch64

Hi Dmitry, Updated webrev looks fine. Thanks, Alexander On 7/17/2019 1:44 PM, Dmitry Chuyko wrote: Ok, here is the updated webrev: http://cr.openjdk.java.net/~dchuyko/8222778/webrev.01/ -Dmitry On 7/17/19 11:03 PM, Alexander Matveev wrote: Hi Dmitry, I also do not see point of keeping thi

Re: 8067801: Enforce null check for underlying I/O streams

Hi Brian > On Jul 17, 2019, at 4:39 PM, Brian Burkhalter > wrote: > > Hi Lance, > >> On Jul 17, 2019, at 1:02 PM, Lance Andersen > > wrote: >> >> I think what you have is fine, a unique test in each subdirectory as it is >> organized by class. What you might

Re: RFR (S): JDK-8222778: Packaging Tool (JEP 343) on Linux/AArch64

Ok, here is the updated webrev: http://cr.openjdk.java.net/~dchuyko/8222778/webrev.01/ -Dmitry On 7/17/19 11:03 PM, Alexander Matveev wrote: Hi Dmitry, I also do not see point of keeping this block, so lets remove it instead of keeping it commented. Thanks, Alexander On 7/16/2019 3:50 PM,

Re: 8067801: Enforce null check for underlying I/O streams

Hi Lance, > On Jul 17, 2019, at 1:02 PM, Lance Andersen wrote: > > I think what you have is fine, a unique test in each subdirectory as it is > organized by class. What you might consider is having a generic NPE Test > class, which validates the error for Constructors and methods as described

Re: RFR (S): JDK-8222778: Packaging Tool (JEP 343) on Linux/AArch64

Hi Dmitry, I also do not see point of keeping this block, so lets remove it instead of keeping it commented. Thanks, Alexander On 7/16/2019 3:50 PM, Dmitry Chuyko wrote: Alexander, thanks for having a look, On 7/17/19 12:30 AM, Alexander Matveev wrote: Hi Dmitry, http://cr.openjdk.java.ne

Re: 8067801: Enforce null check for underlying I/O streams

Hi Brian, > On Jul 17, 2019, at 3:46 PM, Brian Burkhalter > wrote: > > Hi Lance, > >> On Jul 17, 2019, at 12:35 PM, Brian Burkhalter > > wrote: >> >>> I might consider adding the NPE message to the individual classes as it is >>> easy to miss in the java.io

Re: 8067801: Enforce null check for underlying I/O streams

Hi Lance, > On Jul 17, 2019, at 12:35 PM, Brian Burkhalter > wrote: > >> I might consider adding the NPE message to the individual classes as it is >> easy to miss in the java.io > > package but that is just a suggestion. Especially with

Re: 8067801: Enforce null check for underlying I/O streams

Hi Lance, > On Jul 17, 2019, at 12:28 PM, Lance Andersen > wrote: > > I think this looks good. Thanks. > I might consider adding the NPE message to the individual classes as it is > easy to miss in the java.io package but that is just a > suggestion. Especially with the

Re: 8067801: Enforce null check for underlying I/O streams

Hi Brian, I think this looks good. I might consider adding the NPE message to the individual classes as it is easy to miss in the java.io package but that is just a suggestion. Especially with the new search feature of javadoc, I usually go straight to the method so would never see the info

Re: RFR: 8227642: [TESTBUG] Make docker tests podman compatible

Hi Severin, the updated webrev looks good to me, please see a couple comments below. Cheers, -- Igor > On Jul 17, 2019, at 10:34 AM, Severin Gehwolf wrote: > > Hi Misha, > > On Wed, 2019-07-17 at 10:22 -0700, mikhailo.seledt...@oracle.com > wrote: >>

Re: RFR: 8227642: [TESTBUG] Make docker tests podman compatible

On 7/17/19 10:34 AM, Severin Gehwolf wrote: Hi Misha, On Wed, 2019-07-17 at 10:22 -0700, mikhailo.seledt...@oracle.com wrote: Hi Severin, On 7/17/19 5:44 AM, Severin Gehwolf wrote: Hi Igor, Misha, On Tue, 2019-07-16 at 11:49 -0700, Igor Ignatyev wrote: Hi Severin, I don't think that test

Re: RFR: 8227642: [TESTBUG] Make docker tests podman compatible

Hi Misha, On Wed, 2019-07-17 at 10:22 -0700, mikhailo.seledt...@oracle.com wrote: > Hi Severin, > > On 7/17/19 5:44 AM, Severin Gehwolf wrote: > > Hi Igor, Misha, > > > > On Tue, 2019-07-16 at 11:49 -0700, Igor Ignatyev wrote: > > > Hi Severin, > > > > > > I don't think that tests (or test libr

Re: RFR: 8227642: [TESTBUG] Make docker tests podman compatible

Hi Severin, On 7/17/19 5:44 AM, Severin Gehwolf wrote: Hi Igor, Misha, On Tue, 2019-07-16 at 11:49 -0700, Igor Ignatyev wrote: Hi Severin, I don't think that tests (or test libraries for that matter) should be responsible for setting correct PATH value, it should be a part of host configurati

8067801: Enforce null check for underlying I/O streams

https://bugs.openjdk.java.net/browse/JDK-8067801 http://cr.openjdk.java.net/~bpb/8067801/webrev.00/ Add null check to Filter{In,Out}putStream constructors. This covers all the cases listed in the issue as those are all subclasses of these two classes. No javadoc update is need due to this statem

Re: The final optimized version of Dual-Pivot Quicksort (ver.19.1)

Hi, I integrated locally the complete DPQS 19.2 patch from Vladimir Yaroslavskiy with up-to-date jdk14 (client) repository: build OK and jtreg passed OK (java/util/Arrays). Here is the corresponding webrev for review: http://cr.openjdk.java.net/~lbourges/dpqs/dpqs-8226297/webrev/ Cheers, Laurent

Re: RFR: JDK-8227831: Avoid using volatile for write-once, read-many class field

Hi, removing volatile aligns LangReflectAccess initialization with the pattern used for other access objects: it's only initialized in the static initializer of some class which we ensure is initialized, which means any initialization race is guarded by the initialization of said class - in this

Re: RFR: 8227642: [TESTBUG] Make docker tests podman compatible

Hi Igor, Misha, On Tue, 2019-07-16 at 11:49 -0700, Igor Ignatyev wrote: > Hi Severin, > > I don't think that tests (or test libraries for that matter) should > be responsible for setting correct PATH value, it should be a part of > host configuration procedure (tests can/should check that all > r

Re: RFR: 8227587: Add internal privileged System.loadLibrary

Hi Peter, On 2019-07-17 10:29, Peter Levart wrote: Hi Claes, Am I reading correct that package-private ClassLoader.loadLibrary(Class fromClass, String name, boolean isAbsolute) wouldn't need to consult SecurityManager wasn't it for accessing system properties in private ClassLoader.initializ

Re: RFR (S): JDK-8222778: Packaging Tool (JEP 343) on Linux/AArch64

On 7/16/19 8:55 PM, Dmitry Chuyko wrote: > Hello, > > Please review a small patch that mostly fixes jpackage test for Linux > aarch64 and also arm,x86,power. It is prepared for 'JDK-8200758-branch' > branch of open 'sandbox' repo. > > There are few parts: > > 1. LinuxPlatform.cpp and IniFile.c

Re: RFR: 8227587: Add internal privileged System.loadLibrary

Hi Claes, Am I reading correct that package-private ClassLoader.loadLibrary(Class fromClass, String name, boolean isAbsolute) wouldn't need to consult SecurityManager wasn't it for accessing system properties in private ClassLoader.initializePath(String propName). So perhaps if the two calls

Re: RFR: JDK-8227831: Avoid using volatile for write-once, read-many class field

Hi Aleskey, Thank you for your comment. I forgot to mention one thing. I verified that all accesses to langReflectioAccess calls the accessor "langReflectAccess()". Since this variable is modified once from null to non-null, I think the write in the setter is guaranteed to be visible in the

RE: RFR : 8227737: avoid implicit-function-declaration on AIX

Thanks ! * How far are we then from enabling "warnings as errors" on AIX? :P * I count in the opt/product jdk/jdk AIX build currently 60 remaining matches of compiler warnings . Plus additionally a number of those (probably linker warnings ?) : 1500-029: (W) WARNING: subprogra

Re: RFR: JDK-8227831: Avoid using volatile for write-once, read-many class field

On 7/17/19 8:48 AM, Kazunori Ogata wrote: > Webrev: http://cr.openjdk.java.net/~ogatak/8227831/webrev/ Note this is generally not safe: it introduces data race on langReflectAccess field access. It has to be proved that everything that implements LangReflectAccess interface makes this data race

RE: RFR : 8227737: avoid implicit-function-declaration on AIX

Hi Matthias, looks good, thanks for doing this. How far are we then from enabling "warnings as errors" on AIX? :P Best regards Christoph From: awt-dev On Behalf Of Baesken, Matthias Sent: Dienstag, 16. Juli 2019 17:04 To: Java Core Libs ; nio-...@openjdk.java.net; net-...@openjdk.jav

RE: RFR: JDK-8227831: Avoid using volatile for write-once, read-many class field

Hi Ogata, this seems to make sense. So, +1 from my end. Can you please add a space after "if" in line "734 if(langReflectAccess == null) {"? Thanks Christoph > -Original Message- > From: core-libs-dev On Behalf > Of Kazunori Ogata > Sent: Mittwoch, 17. Juli 2019 08:49