RE: RFR [XXS] : 8244183: linker error jpackageapplauncher on Windows 32bit

Sorry , there was still an issue with rev. 0 , I had to adjust the signature of wmain As well to get around the link errors . http://cr.openjdk.java.net/~mbaesken/webrevs/8244183.1/ This builds on both windows 64 bit and 32 bit . Best regards, Matthias From: Thomas Stüfe Sent: Freitag, 1.

Re: RFR: 8244224: Implementation of JEP 381: Remove the Solaris and SPARC Ports - (core libraries)

New webrev addressing the feedback/comments I have received: webrev: http://cr.openjdk.java.net/~mikael/webrevs/8244224/webrev.01/corelibs/open/webrev/ incremental: http://cr.openjdk.java.net/~mikael/webrevs/8244224/webrev.01/corelibs.incr/open/webrev/ I hope I caught everything. Some

Re: RFR: 8244224: Implementation of JEP 381: Remove the Solaris and SPARC Ports - (core libraries)

I have always wondered what “solinux” is supposed to mean - though not enough to actually ask anybody :) I’ll file a follow-up enhancement to cover renaming the files. Thank you for the review! Cheers, Mikael > On May 4, 2020, at 7:59 AM, Roger Riggs wrote: > > Hi Michael, > > Looks

Re: RFR: 8244224: Implementation of JEP 381: Remove the Solaris and SPARC Ports - (core libraries)

> On May 5, 2020, at 5:42 AM, Daniel Fuchs wrote: > > Hi Mikael, > > I spotted another place where a residual reference to Solaris > remains in a comment: > src/java.base/unix/native/libnet/PlainSocketImpl.c > > 857 #if defined(_AIX) > 858 if (errno == EINVAL) { > 859 //

Re: RFR: 8244224: Implementation of JEP 381: Remove the Solaris and SPARC Ports - (core libraries)

> On May 4, 2020, at 9:27 AM, naoto.s...@oracle.com wrote: > > Hi Mikael, > > I took a look at i18n related files. It looks good overall. > > One nit in java/nio/charset/Charset/DefaultCharsetTest.java: If the test is > only applicable to linux (@requires os.family == "linux" in jtreg tag

Re: RFR: 8244224: Implementation of JEP 381: Remove the Solaris and SPARC Ports - (core libraries)

> On May 4, 2020, at 2:33 PM, Brent Christian > wrote: > > Hi, > > Looks fine to me. I have just one minor observation: > > src/java.base/share/native/libjli/emessages.h > > *** 92,102 > #define JRE_ERROR5 "Error: Failed to start a %d-bit JVM process from a > %d-bit JVM." > !

Re: RFR: 8244224: Implementation of JEP 381: Remove the Solaris and SPARC Ports - (core libraries)

Alan, thank you for the review! New webrev coming. Meanwhile comments inline.. > On May 4, 2020, at 1:49 AM, Alan Bateman wrote: > > On 04/05/2020 06:12, Mikael Vidstedt wrote: >> Please review this change which implements part of JEP 381: >> >> JBS:

Re: RFR: 8244224: Implementation of JEP 381: Remove the Solaris and SPARC Ports - (core libraries)

Thank you for reviewing, Max! Cheers, Mikael > On May 4, 2020, at 7:22 AM, Weijun Wang wrote: > > There are several security-related files (name.contains("security")) and they > all look fine. > > --Max > > >> On May 4, 2020, at 1:12 PM, Mikael Vidstedt >> wrote: >> >> >> Please

Re: os::javaTimeSystemUTC to call nanosecond precision OS API, so Clock.systemUTC() can give nanosecond precision UTC

Hi Mark, On 6/05/2020 1:50 am, Mark Kralj-Taylor wrote: Hi David, So the issue is that while glibc 2.12 (in OEL6.4) supports clock_gettime(CLOCK_REALTIME) it requires a runtime dependency on librt.so, which is an optional runtime dependency, hence the dynamic lookup you mention. The complexity

Re: RFR(XS): 8244495: Some jlink tests crash on Windows after JDK-8237750

Thanks Mandy for review! Yumin On 5/6/20 6:50 PM, Mandy Chung wrote: This looks okay to me. Mandy On 5/6/20 6:01 PM, Yumin Qi wrote: Hi,   Please review the fix for   bug: https://bugs.openjdk.java.net/browse/JDK-8244495   webrev: http://cr.openjdk.java.net/~minqi/8244495/webrev/ Tests

Re: RFR(XS): 8244495: Some jlink tests crash on Windows after JDK-8237750

Thanks for review, yes, enough for a push! Yumin On 5/6/20 7:15 PM, David Holmes wrote: On 7/05/2020 12:04 pm, Daniel D. Daugherty wrote: On 5/6/20 9:01 PM, Yumin Qi wrote: Hi,   Please review the fix for   bug: https://bugs.openjdk.java.net/browse/JDK-8244495   webrev:

Re: RFR(XS): 8244495: Some jlink tests crash on Windows after JDK-8237750

Thanks for review! Yumin On 5/6/20 6:26 PM, Kim Barrett wrote: On May 6, 2020, at 9:01 PM, Yumin Qi wrote: Hi, Please review the fix for bug: https://bugs.openjdk.java.net/browse/JDK-8244495 webrev: http://cr.openjdk.java.net/~minqi/8244495/webrev/ Tests

Re: RFR(XS): 8244495: Some jlink tests crash on Windows after JDK-8237750

On 7/05/2020 12:04 pm, Daniel D. Daugherty wrote: On 5/6/20 9:01 PM, Yumin Qi wrote: Hi,   Please review the fix for   bug: https://bugs.openjdk.java.net/browse/JDK-8244495   webrev: http://cr.openjdk.java.net/~minqi/8244495/webrev/ src/java.base/share/native/libjimage/imageDecompressor.cpp  

Re: RFR(XS): 8244495: Some jlink tests crash on Windows after JDK-8237750

On 5/6/20 9:01 PM, Yumin Qi wrote: Hi,   Please review the fix for   bug: https://bugs.openjdk.java.net/browse/JDK-8244495   webrev: http://cr.openjdk.java.net/~minqi/8244495/webrev/ src/java.base/share/native/libjimage/imageDecompressor.cpp     No comments. Thumbs up. I think this qualifies

Re: RFR(XS): 8244495: Some jlink tests crash on Windows after JDK-8237750

Hi Yumin, On 7/05/2020 11:01 am, Yumin Qi wrote: Hi,   Please review the fix for   bug: https://bugs.openjdk.java.net/browse/JDK-8244495   webrev: http://cr.openjdk.java.net/~minqi/8244495/webrev/ Tests tools/jlink/JLinkTest.javaand tools/jlink/basic/BasicTest.java failed after 8237750

Re: RFR(XS): 8244495: Some jlink tests crash on Windows after JDK-8237750

This looks okay to me. Mandy On 5/6/20 6:01 PM, Yumin Qi wrote: Hi,   Please review the fix for   bug: https://bugs.openjdk.java.net/browse/JDK-8244495   webrev: http://cr.openjdk.java.net/~minqi/8244495/webrev/ Tests tools/jlink/JLinkTest.javaand tools/jlink/basic/BasicTest.java failed

Re: RFR(XS): 8244495: Some jlink tests crash on Windows after JDK-8237750

> On May 6, 2020, at 9:01 PM, Yumin Qi wrote: > > Hi, > Please review the fix for > bug: https://bugs.openjdk.java.net/browse/JDK-8244495 > webrev: http://cr.openjdk.java.net/~minqi/8244495/webrev/ > > Tests tools/jlink/JLinkTest.javaand tools/jlink/basic/BasicTest.java failed > after

RFR(XS): 8244495: Some jlink tests crash on Windows after JDK-8237750

Hi,   Please review the fix for   bug: https://bugs.openjdk.java.net/browse/JDK-8244495   webrev: http://cr.openjdk.java.net/~minqi/8244495/webrev/ Tests tools/jlink/JLinkTest.javaand tools/jlink/basic/BasicTest.java failed after 8237750 pushed. The fix of 8237750 changed default behavior of

Re: RFR [15] 6394757: rev2: AbstractSet.removeAll semantics are surprisingly dependent on relative sizes

> On May 6, 2020, at 2:08 PM, Stuart Marks wrote: > > > > On 5/4/20 6:44 PM, Alan Snyder wrote: >> What problem are you trying to solve? >> The Collections framework explicitly does not support custom membership >> semantics. If you think it should, file an RFE and create a JEP. It’s not a

RFR: 8237834: com/sun/jndi/ldap/LdapDnsProviderTest.java failing with LDAP response read timeout

Hi, LdapDnsProviderTest test expects to have no services running on port on test machine. That could cause it to fail intermittently due to unexpected exception message thrown by LDAP client, i.e. timeout or disconnect instead of expected connection refusal. The proposed fix tries to

Re: RFR: JDK-8236518: There is no Native Packages WinUpgradeUUIDTest-2.0.exe after creating Native packages on win

Looks good. - Alexey On 5/6/2020 3:13 PM, Andy Herrick wrote: Please review jpackage test fix to issue [1] at [2] [1] - https://bugs.openjdk.java.net/browse/JDK-8236518 [2] - http://cr.openjdk.java.net/~herrick/8236518/webrev.01 /Andy

Re: [15]: RFR: 8244245: localizedBy() should override localized values with default values

+1 Stephen On Wed, 6 May 2020 at 21:50, wrote: > > Hello, > > Please review the fix to the following issue: > > https://bugs.openjdk.java.net/browse/JDK-8244245 > > The CSR and proposed changeset are located at: > > https://bugs.openjdk.java.net/browse/JDK-8244246 >

Re: RFR: JDK-8236518: There is no Native Packages WinUpgradeUUIDTest-2.0.exe after creating Native packages on win

Hi Andy, Looks good. Thanks, Alexander On 5/6/20 12:13 PM, Andy Herrick wrote: Please review jpackage test fix to issue [1] at [2] [1] - https://bugs.openjdk.java.net/browse/JDK-8236518 [2] - http://cr.openjdk.java.net/~herrick/8236518/webrev.01 /Andy

Re: RFR [15] 6394757: rev2: AbstractSet.removeAll semantics are surprisingly dependent on relative sizes

On 5/4/20 6:44 PM, Alan Snyder wrote: What problem are you trying to solve? The Collections framework explicitly does not support custom membership semantics. If you think it should, file an RFE and create a JEP. It’s not a small change and tinkering is not the way to get there. There

[15]: RFR: 8244245: localizedBy() should override localized values with default values

Hello, Please review the fix to the following issue: https://bugs.openjdk.java.net/browse/JDK-8244245 The CSR and proposed changeset are located at: https://bugs.openjdk.java.net/browse/JDK-8244246 https://cr.openjdk.java.net/~naoto/8244245/webrev.00/ This stems from the closed issue

Re: RFR: 8244413: Avoid rebinds in MethodHandle.viewAsType

On 5/6/20 12:50 PM, Claes Redestad wrote: On 2020-05-06 16:59, Claes Redestad wrote: -XX:TieredStopAtLevel=1: Benchmark   Mode  Cnt    Score   Error  Units 15-b19  Capture0.lambda_01  avgt    5    6.312 ± 0.919  ns/op 15-b20  Capture0.lambda_01  avgt    5  105.761 ± 7.575 

Re: RFR: 6415694 Clarification in Javadoc for java.rmi.AlreadyBoundException

OK, pushed: http://hg.openjdk.java.net/jdk/jdk/rev/6b4e4ffe01ab Thanks for your contribution! s'marks On 5/4/20 1:50 AM, Jayashree Sk1 wrote: Hi Stuart, Yup Contributed-by as picked from my email : jayashreesk . Will keep in mind about the complicated change-sets. Thanks Jay

Re: RFR: 8244413: Avoid rebinds in MethodHandle.viewAsType

On 2020-05-06 16:59, Claes Redestad wrote: -XX:TieredStopAtLevel=1:     Benchmark   Mode  Cnt    Score   Error  Units 15-b19  Capture0.lambda_01  avgt    5    6.312 ± 0.919  ns/op 15-b20  Capture0.lambda_01  avgt    5  105.761 ± 7.575  ns/op jdk Capture0.lambda_01  avgt    5 

RFR: JDK-8236518: There is no Native Packages WinUpgradeUUIDTest-2.0.exe after creating Native packages on win

Please review jpackage test fix to issue [1] at [2] [1] - https://bugs.openjdk.java.net/browse/JDK-8236518 [2] - http://cr.openjdk.java.net/~herrick/8236518/webrev.01 /Andy

Re: RFR JDK-8223347 Integration of Vector API (Incubator): Java API, implementation, and tests

Thanks, Paul! Talking with you about it helped me formulate my thoughts better. > On May 6, 2020, at 9:02 AM, Paul Sandoz wrote: > > Hi John, > > Thanks. For the benefit of others, John and I had a long chat about this and > Joe’s CSR comments. > > I have a better appreciation of your

Re: RFR JDK-8223347 Integration of Vector API (Incubator): Java API, implementation, and tests

Hi John, Thanks. For the benefit of others, John and I had a long chat about this and Joe’s CSR comments. I have a better appreciation of your approach to the design and some of the more subjective aspects to guide developers to API points, and to make code more readable (that’s creative API

Re: CfD: compile-time checked immutable collections

Thank you for your reply. I am not truly satisfied with this explanation (especially Josh Blochs "i am unwilling to create a few more interfaces" - sounds a bit silly if you look at all those unmodifiable-workarounds that are in place by now, even those incorporated into IDEs to warn the

Re: RFR: JDK-8241602 jlink does not produce reproducible jimage filesJ

On 06/05/2020 15:45, Jim Laskey wrote: http://cr.openjdk.java.net/~jlaskey/8241602/webrev-02 This version looks okay to me. -Alan.

Re: RFR: 8244413: Avoid rebinds in MethodHandle.viewAsType

On 2020-05-06 00:34, Claes Redestad wrote: Hi Mandy, On 2020-05-06 00:23, Mandy Chung wrote: This looks good. thanks! Pushed. FTR, I took inventory of existing micros, and found a few where the effect of this change on capturing lambdas can be studied. For example: $ make

Re: RFR [LDAP]: 8062947: Fix exception message to correctly represent LDAP connection failure

Hi Daniel, Thanks for the review ! Best, Aleksei On 06/05/2020 11:35, Daniel Fuchs wrote: Hi Aleksei, Looks good to me. best regards, -- daniel On 05/05/2020 18:23, Aleks Efimov wrote: "LDAP response read timed out, timeout used:-1ms.": https://bugs.openjdk.java.net/browse/JDK-8062947

Re: RFR: JDK-8241602 jlink does not produce reproducible jimage filesJ

http://cr.openjdk.java.net/~jlaskey/8241602/webrev-02 > On May 6, 2020, at 11:05 AM, Alan Bateman wrote: > > On 06/05/2020 14:42, Jim Laskey wrote: >> : >> >> Aside: The order in the file is still somewhat scattered, based on archive

Re: RFR: JDK-8241602 jlink does not produce reproducible jimage filesJ

On 06/05/2020 14:42, Jim Laskey wrote: : Aside: The order in the file is still somewhat scattered, based on archive and archive content.  We have the a pattern based sorting plugin which we don't use and we never did any locality vs performance testing. Not in the test but the JDK does use

Re: RFR: JDK-8241602 jlink does not produce reproducible jimage files

Thank you. Notes below. updated webrev: http://cr.openjdk.java.net/~jlaskey/8241602/webrev-00 > On May 6, 2020, at 4:14 AM, Alan Bateman wrote: > > On 05/05/2020 20:56, Jim Laskey wrote: >> This fix addresses the inconsistent ordering

Re: RFR [LDAP]: 8062947: Fix exception message to correctly represent LDAP connection failure

Hi Aleksei, Looks good to me. best regards, -- daniel On 05/05/2020 18:23, Aleks Efimov wrote: "LDAP response read timed out, timeout used:-1ms.": https://bugs.openjdk.java.net/browse/JDK-8062947 The following fix tries to tackle this issue: http://cr.openjdk.java.net/~aefimov/8062947/00

Re: RFR: JDK-8241602 jlink does not produce reproducible jimage files

On 05/05/2020 20:56, Jim Laskey wrote: This fix addresses the inconsistent ordering by jimage content by jlink from run to run. Bottom line, the implementer was using HashSet without defining hashcode/equals for the Set entry classes. webrev:

Re: RFR: JDK-8241602 jlink does not produce reproducible jimage files

On 2020-05-05 21:56, Jim Laskey wrote: This fix addresses the inconsistent ordering by jimage content by jlink from run to run. Bottom line, the implementer was using HashSet without defining hashcode/equals for the Set entry classes. webrev:

[PATCH] 8244199: [TestBug]: Update sun/management/jmxremote/bootstrap tests

Hello, A quick follow-up on this request.. -Original Message- From: Thejasvi Voniadka Sent: Monday, May 4, 2020 12:56 PM To: core-libs-dev@openjdk.java.net Subject: [PATCH] 8244199: [TestBug]: Update sun/management/jmxremote/bootstrap tests Hi, May I please find a sponsor for this