Re: RFR of JDK-8214431: tests failed because can not find removed library folder at test/jdk/lib/testlibrary/jdk/testlibrary

Thanks, I'll do that. Cheers, Thomas On Thu, Nov 29, 2018, 06:00 David Holmes Hi Thomas, > > On 29/11/2018 2:37 pm, Thomas Stüfe wrote: > > Hi all, > > > > Will the failed test jobs be automatically re-submitted or should we do > > that manually? > > Do you mean for the submit-repo? > > I'd

Re: RFR of JDK-8214431: tests failed because can not find removed library folder at test/jdk/lib/testlibrary/jdk/testlibrary

Hi Thomas, On 29/11/2018 2:37 pm, Thomas Stüfe wrote: Hi all, Will the failed test jobs be automatically re-submitted or should we do that manually? Do you mean for the submit-repo? I'd pull/rebase to get all recent fixes as there was a Mac build fix that just went in too - then resubmit.

Re: RFR of JDK-8214431: tests failed because can not find removed library folder at test/jdk/lib/testlibrary/jdk/testlibrary

Hi all, Will the failed test jobs be automatically re-submitted or should we do that manually? Thanks, Thomas On Thu, Nov 29, 2018, 00:43 Hamlin Li Hi, > > Thank you for reviewing this, it's just pushed, I'm sorry for the > inconvenience. > > Thank you > > -Hamlin > > On 2018/11/29 5:12 AM,

Re: RFR(xs): JDK-8214460 fix broken macOS build

On 11/28/18 18:18, Stuart Marks wrote: https://bugs.openjdk.java.net/browse/JDK-8214460 Please review this small fix to correct broken macOS build caused by the fix for JDK-8214014. Patch appended below. -cf_socksHost = NULL, +cf_socksHost = NULL; int httpPort = 80, //

Re: RFR(xs): JDK-8214460 fix broken macOS build

Looks good! Thanks for jumping on this. David On 29/11/2018 12:18 pm, Stuart Marks wrote: Hi all, https://bugs.openjdk.java.net/browse/JDK-8214460 Please review this small fix to correct broken macOS build caused by the fix for JDK-8214014. Patch appended below. Thanks, s'marks # HG

Re: RFR: 8213754: PPC64: Add Intrinsics for isDigit/isLowerCase/isUpperCase/isWhitespace

Hi, I'll look at it on Thursday. In spite of it looking like the email was sent to core-lib-dev, I have not seen it before and its not in the core-libs-dev archive. $.02, Roger On 11/28/18 7:15 PM, Vladimir Kozlov wrote: You still need review from core-libs. About your hotspot changes.

RFR(xs): JDK-8214460 fix broken macOS build

Hi all, https://bugs.openjdk.java.net/browse/JDK-8214460 Please review this small fix to correct broken macOS build caused by the fix for JDK-8214014. Patch appended below. Thanks, s'marks # HG changeset patch # User smarks # Date 1543457799 28800 # Wed Nov 28 18:16:39 2018 -0800 #

Re: Extending Java Arrays/Collection Sort API

As you noticed, I jumped into the discussion mid-stream. I've been itching to get index-based sorting into JDK ever since I tried to code Burrows-Wheeler on the JDK and saw a huge footprint overhead due to the need for a proxy object for each byte position in the file to be compressed. Here are

Re: RFR: 8213754: PPC64: Add Intrinsics for isDigit/isLowerCase/isUpperCase/isWhitespace

You still need review from core-libs. About your hotspot changes. You need to add intrinsics to is_disabled_by_flags() to be able switch them off. Note, match_rule_supported() calls in C2Compiler::is_intrinsic_supported() executed before intrinsics in C2 are registered. So they will not be

Re: RFR of JDK-8214431: tests failed because can not find removed library folder at test/jdk/lib/testlibrary/jdk/testlibrary

Hi, Thank you for reviewing this, it's just pushed, I'm sorry for the inconvenience. Thank you -Hamlin On 2018/11/29 5:12 AM, Chris Hegarty wrote: I think this good. Thanks. -Chris. On 28 Nov 2018, at 20:32, David Holmes wrote: Hi Hamlin, On 28/11/2018 10:52 pm, Hamlin Li wrote: Hi

Re: [test] 8214445 : java/net/URL/HandlerLoop has illegal reflective access

+1 Brian > On Nov 28, 2018, at 1:48 PM, Roger Riggs wrote: > > Please review a test cleanup to remove a latent Illegal Reflective Access. > > Adding the @modules was necessary and the code was updated to remove > compilation warnings. > > Webrev: >

Re: RFR: JDK-8213362 : Could not find libjava.dylib error when initializing JVM via JNI_CreateJavaVM

Since there is no header file in JDK provides the function prototypes, I don’t think this is considered public(supported) APIs. Anyway, in case a tools is build with launcher code, and shipped separately from JDK, that would be impacted by this bug. So I added a test call JLI_Launch as well.

Re: [test] 8214445 : java/net/URL/HandlerLoop has illegal reflective access

Hi Chris, On 11/28/2018 05:21 PM, Chris Hegarty wrote: Will the @modules tag implicitly result in this test running in othervm? Apparently so, the test log shows Mode: othervm Its logical since only by launching a new java process can the --add-exports and --add-modules command line args

Re: [test] 8214445 : java/net/URL/HandlerLoop has illegal reflective access

> On 28 Nov 2018, at 21:48, Roger Riggs wrote: > > Please review a test cleanup to remove a latent Illegal Reflective Access. > > Adding the @modules was necessary and the code was updated to remove > compilation warnings. > > Webrev: >

Re: [test] 8214445 : java/net/URL/HandlerLoop has illegal reflective access

Thanks Lance On 11/28/2018 05:05 PM, Lance Andersen wrote: Looks OK Roger On Nov 28, 2018, at 4:48 PM, Roger Riggs > wrote: Please review a test cleanup to remove a latent Illegal Reflective Access. Adding the @modules was necessary and the code was updated

Re: [test] 8214445 : java/net/URL/HandlerLoop has illegal reflective access

Looks OK Roger > On Nov 28, 2018, at 4:48 PM, Roger Riggs wrote: > > Please review a test cleanup to remove a latent Illegal Reflective Access. > > Adding the @modules was necessary and the code was updated to remove > compilation warnings. > > Webrev: >

[test] 8214445 : java/net/URL/HandlerLoop has illegal reflective access

Please review a test cleanup to remove a latent Illegal Reflective Access. Adding the @modules was necessary and the code was updated to remove compilation warnings. Webrev:   http://cr.openjdk.java.net/~rriggs/webrev-handlerloop-8214445/ Jira:  

Re: Extending Java Arrays/Collection Sort API

The way we like to approach this is: first explore whether the problem is one we should solve (that's this discussion, it's going well), then design discussions (you probably have one in your back pocket already), then implementation/testing/review, and then we can think about which version to

Re: RFR of JDK-8214431: tests failed because can not find removed library folder at test/jdk/lib/testlibrary/jdk/testlibrary

I think this good. Thanks. -Chris. > On 28 Nov 2018, at 20:32, David Holmes wrote: > > Hi Hamlin, > > On 28/11/2018 10:52 pm, Hamlin Li wrote: >> Hi David, >> Yes, they'd better be removed too, so I create another bug >> https://bugs.openjdk.java.net/browse/JDK-8214435 to track it. > > Ok.

Re: RFR of JDK-8214431: tests failed because can not find removed library folder at test/jdk/lib/testlibrary/jdk/testlibrary

Hi Hamlin, Change looks good, thanks for fixing this. Thanks, Christian > On Nov 28, 2018, at 4:52 AM, Hamlin Li wrote: > > Hi David, > > Yes, they'd better be removed too, so I create another bug > https://bugs.openjdk.java.net/browse/JDK-8214435 to track it. > > With only

Re: RFR of JDK-8214431: tests failed because can not find removed library folder at test/jdk/lib/testlibrary/jdk/testlibrary

Hi Hamlin, On 28/11/2018 10:52 pm, Hamlin Li wrote: Hi David, Yes, they'd better be removed too, so I create another bug https://bugs.openjdk.java.net/browse/JDK-8214435 to track it. Ok. With only /lib/testlibrary/, tests will not fail, tests only fail when there is something like "run

Re: Extending Java Arrays/Collection Sort API

Hi John & Brian, Thank you for your feedback finally, we almost agree Java Sort API could be improved, in jdk13 possibly. > > Doug is right that there is an enormous potential list of sort methods, > and we can't include them all. But I do miss the ability to extract > indexes instead of

Re: RFR(JDK 12/java.xml) 8213117: adoptNode corrupts attribute values

Thanks Lance! On 11/28/18, 9:41 AM, Lance Andersen wrote: Hi Joe Looks good, Best Lance On Nov 27, 2018, at 2:58 PM, Joe Wang > wrote: Hi, Please review a fix for the adoptNode impl. Before a node from a deferred DOM can be adopted, it needs to be fully

Re: 6516099: InputStream.skipFully(int k) to skip exactly k bytes

Looks good to me Brian. I never knew whether positive meant >= 0 or > 0 anyway ;-) best regards, -- daniel On 28/11/2018 17:38, Brian Burkhalter wrote: Hello again, One, hopefully final, one sentence change was requested in a comment on the CSR: ---

Re: RFR(JDK 12/java.xml) 8213117: adoptNode corrupts attribute values

Hi Joe Looks good, Best Lance > On Nov 27, 2018, at 2:58 PM, Joe Wang wrote: > > Hi, > > Please review a fix for the adoptNode impl. Before a node from a deferred DOM > can be adopted, it needs to be fully expanded. > > JBS: https://bugs.openjdk.java.net/browse/JDK-8213117 > webrev:

Re: 6516099: InputStream.skipFully(int k) to skip exactly k bytes

Hello again, One, hopefully final, one sentence change was requested in a comment on the CSR: --- a/src/java.base/share/classes/java/io/InputStream.java +++ b/src/java.base/share/classes/java/io/InputStream.java @@ -567,6 +567,7 @@ * of this method. * * @implSpec + * If

Re: RFR 8214014 : Remove vestiges of gopher: protocol proxy support

> Please check in javax.print that the inclusion of the gopher protocol is no longer needed. In that case, 2d-dev is the list you want. Swing doesn't do printing. It must have been a decade since I heard anyone mention gopher, but did you really mean to remove a Java SE public API variable ?

Re: Downport JDK-8212828 (posix_spawn on Linux as non-default) to 11u

On Wed, Nov 28, 2018 at 5:39 PM Alan Bateman wrote: > > On 28/11/2018 15:36, Thomas Stüfe wrote: > > Hi all, > > > > I would like to have this patch in 11u too, so I just did a 11u > > downport request. > > > > Our agreement was that launchMechanism=POSIX_SPAWN would stay as > > optional

Re: RFR 8214014 : Remove vestiges of gopher: protocol proxy support

On 28/11/2018 16:34, Roger Riggs wrote: Please review the removal of some left over references to the gopher protocol related to proxies. Most are related to properties or setting up proxies (for gopher). Please check in javax.print that the inclusion of the gopher protocol is no longer

Re: RFR 8214014 : Remove vestiges of gopher: protocol proxy support

Looks good Roger WRT to the removal > On Nov 28, 2018, at 11:34 AM, Roger Riggs wrote: > > Please review the removal of some left over references to the gopher protocol > related to proxies. > Most are related to properties or setting up proxies (for gopher). > > Please check in javax.print

Re: Downport JDK-8212828 (posix_spawn on Linux as non-default) to 11u

On 28/11/2018 15:36, Thomas Stüfe wrote: Hi all, I would like to have this patch in 11u too, so I just did a 11u downport request. Our agreement was that launchMechanism=POSIX_SPAWN would stay as optional non-default value for jdk12, and at the start of JDK13 development we would switch the

RFR 8214014 : Remove vestiges of gopher: protocol proxy support

Please review the removal of some left over references to the gopher protocol related to proxies. Most are related to properties or setting up proxies (for gopher). Please check in javax.print that the inclusion of the gopher protocol is no longer needed. Webrev:  

Re: RFR: JDK-8213362 : Could not find libjava.dylib error when initializing JVM via JNI_CreateJavaVM

> On Nov 28, 2018, at 12:46 AM, Alan Bateman wrote: > > On 27/11/2018 23:05, Henry Jen wrote: >> Hi, >> >> Please review a follow up webrev[1] based on Priyanka’s patch, it simply >> added a test case for Mac only that will link with libjli. >> Note that, to use invoke API, one should

Re: Downport JDK-8212828 (posix_spawn on Linux as non-default) to 11u

I'm in favor FWIW. On Wed, Nov 28, 2018 at 9:36 AM Thomas Stüfe wrote: > > Hi all, > > I would like to have this patch in 11u too, so I just did a 11u > downport request. > > Our agreement was that launchMechanism=POSIX_SPAWN would stay as > optional non-default value for jdk12, and at the start

Downport JDK-8212828 (posix_spawn on Linux as non-default) to 11u

Hi all, I would like to have this patch in 11u too, so I just did a 11u downport request. Our agreement was that launchMechanism=POSIX_SPAWN would stay as optional non-default value for jdk12, and at the start of JDK13 development we would switch the default to posix_spawn. I would like to see

Re: RFR 8177552: Compact Number Formatting support

Looks good to me. Naoto On 11/28/18 3:46 AM, Nishit Jain wrote: Thanks Naoto, Updated. http://cr.openjdk.java.net/~nishjain/8177552/webrevs/webrev.04/ Regards, Nishit Jain On 27-11-2018 20:55, naoto.s...@oracle.com wrote: Hi Nishit, On 11/26/18 11:11 PM, Nishit Jain wrote: Hi Naoto, On

Re: [12] RFR: 8214170: ResourceBundle.Control.newBundle should throw IllegalAccessException when constructor of the resource bundle is not public.

Thank you, Mandy, for pointing out. I was wrong on JDK8 result. With a modified test case, I got the following result for jdk8 and jdk12: jdk8u: slc06brs:/projects/jdk/jdk/jdk/open/test/jdk/java/util/ResourceBundle/Control 479 %

Re: RFR: JDK-8213362 : Could not find libjava.dylib error when initializing JVM via JNI_CreateJavaVM

On 11/28/2018 5:19 AM, Alan Bateman wrote: On 28/11/2018 13:13, Kevin Rushforth wrote: The jpackage tool calls JLI_Launch. I remember that from Andy's webrev but it's not integrated yet. Does the JavaFX packager tool do the same? Yes, the javapackager tool (delivered via JavaFX) in JDK

Re: RFR: JDK-8213362 : Could not find libjava.dylib error when initializing JVM via JNI_CreateJavaVM

On 28/11/2018 13:13, Kevin Rushforth wrote: The jpackage tool calls JLI_Launch. I remember that from Andy's webrev but it's not integrated yet. Does the JavaFX packager tool do the same? -Alan

Re: RFR of JDK-8214431: tests failed because can not find removed library folder at test/jdk/lib/testlibrary/jdk/testlibrary

Just read the webrev, already covered :) -Leo On 11/28/18 9:09 PM, li.ji...@oracle.com wrote: Hi Hamlin, You can find some tests under sun/management/jmxremote/ failed on this issue too. Thanks, Leo On 11/28/18 7:15 PM, Hamlin Li wrote: Hi David, Thank a lot for double checking the

Re: RFR of JDK-8214431: tests failed because can not find removed library folder at test/jdk/lib/testlibrary/jdk/testlibrary

I think you mean bootstrap/PasswordFilePermissionTest.java bootstrap/SSLConfigFilePermissionTest.java startstop/JMXStatusPerfCountersTest.java startstop/JMXStatusTest.java. They have already been included in http://cr.openjdk.java.net/~mli/8214431/webrev.00/ Thank you -Hamlin On

Re: RFR: JDK-8213362 : Could not find libjava.dylib error when initializing JVM via JNI_CreateJavaVM

The jpackage tool calls JLI_Launch. -- Kevin On 11/28/2018 5:05 AM, Alan Bateman wrote: On 28/11/2018 13:03, Kevin Rushforth wrote: This is related to a bug I filed back in October, JDK-8211959 [1], in which JLI_Launch is failing for the same reason. The fix to java_md_macosx.m is the same

Re: RFR of JDK-8214431: tests failed because can not find removed library folder at test/jdk/lib/testlibrary/jdk/testlibrary

Hi Hamlin, You can find some tests under sun/management/jmxremote/ failed on this issue too. Thanks, Leo On 11/28/18 7:15 PM, Hamlin Li wrote: Hi David, Thank a lot for double checking the usage of testlibrary. I have updated the patch, http://cr.openjdk.java.net/~mli/8214431/webrev.00/

Re: RFR: JDK-8213362 : Could not find libjava.dylib error when initializing JVM via JNI_CreateJavaVM

On 28/11/2018 13:03, Kevin Rushforth wrote: This is related to a bug I filed back in October, JDK-8211959 [1], in which JLI_Launch is failing for the same reason. The fix to java_md_macosx.m is the same one I identified in that bug. You might consider adding a test that calls JLI_Launch, but

Re: RFR: JDK-8213362 : Could not find libjava.dylib error when initializing JVM via JNI_CreateJavaVM

This is related to a bug I filed back in October, JDK-8211959 [1], in which JLI_Launch is failing for the same reason. The fix to java_md_macosx.m is the same one I identified in that bug. You might consider adding a test that calls JLI_Launch, but either way, JDK-8211959 can be closed as a

Re: RFR of JDK-8214431: tests failed because can not find removed library folder at test/jdk/lib/testlibrary/jdk/testlibrary

Hi David, Yes, they'd better be removed too, so I create another bug https://bugs.openjdk.java.net/browse/JDK-8214435 to track it. With only /lib/testlibrary/, tests will not fail, tests only fail when there is something like "run build jdk.testlibrary.*" So, I think in this bug it's OK to

Re: RFR of JDK-8214431: tests failed because can not find removed library folder at test/jdk/lib/testlibrary/jdk/testlibrary

Hi Hamlin, On 28/11/2018 9:15 pm, Hamlin Li wrote: Hi David, Thank a lot for double checking the usage of testlibrary. I have updated the patch, http://cr.openjdk.java.net/~mli/8214431/webrev.00/ I'm not sure about the removal of /lib/testlibrary/ from @library /lib/testlibrary/

Re: RFR: 8210454 jar tool does not allow setting the module version without also setting the main class

> On 26 Nov 2018, at 18:41, Lance Andersen wrote: > > The webrev can be found at: > http://cr.openjdk.java.net/~lancea/8210454/webrev.00/ Looks good to me Lance, thanks. -Chris.

Re: RFR 8177552: Compact Number Formatting support

Thanks Naoto, Updated. http://cr.openjdk.java.net/~nishjain/8177552/webrevs/webrev.04/ Regards, Nishit Jain On 27-11-2018 20:55, naoto.s...@oracle.com wrote: Hi Nishit, On 11/26/18 11:11 PM, Nishit Jain wrote: Hi Naoto, On 26-11-2018 21:01, naoto.s...@oracle.com wrote: Hi Nishit, On

Re: RFR of JDK-8214431: tests failed because can not find removed library folder at test/jdk/lib/testlibrary/jdk/testlibrary

Hi David, Thank a lot for double checking the usage of testlibrary. I have updated the patch, http://cr.openjdk.java.net/~mli/8214431/webrev.00/ Thank you -Hamlin On 2018/11/28 6:24 PM, David Holmes wrote: Hi Hamlin, I see a lot more tests that look like they may be affected:

Re: RFR of JDK-8214431: tests failed because can not find removed library folder at test/jdk/lib/testlibrary/jdk/testlibrary

Hi Hamlin, I see a lot more tests that look like they may be affected: ./jdk/com/sun/tools/attach/TempDirTest.java: * @run build jdk.testlibrary.* Application RunnerUtil ./jdk/com/sun/tools/attach/PermissionTest.java: * @run build jdk.testlibrary.* Application

RFR of JDK-8214431: tests failed because can not find removed library folder at test/jdk/lib/testlibrary/jdk/testlibrary

Would you please review the following patch? This is a regression by JDK-8211975. bug: https://bugs.openjdk.java.net/browse/JDK-8214431 patch at the bottom. Thank you -Hamlin diff -r 70adb0f573a7

Re: RFR: 8212794 IBM-964 and IBM-29626C are required for AIX default charset

On 2018-11-28 10:36, Alan Bateman wrote: On 28/11/2018 09:28, Magnus Ihse Bursie wrote: I'm quite unsatisfied with the current handling of character sets in the build in general. :-( I'd really like to modernize it. I have a, slightly fuzzy, laundry list of things I want to fix from a build

Re: RFR: 8212794 IBM-964 and IBM-29626C are required for AIX default charset

On 28/11/2018 09:28, Magnus Ihse Bursie wrote: I'm quite unsatisfied with the current handling of character sets in the build in general. :-( I'd really like to modernize it. I have a, slightly fuzzy, laundry list of things I want to fix from a build perspective, but I'm not sure of what

Re: RFR: 8210454 jar tool does not allow setting the module version without also setting the main class

On 26/11/2018 18:41, Lance Andersen wrote: Hi, Please review this change which allows the jar tool to set the module version without specifying the setting a main class The relevant jck tests have run clean in mach 5 as do the tier1, tier2 and tier3 tests run clean The webrev can be

Re: RFR: JDK-8214063: OpenJDK will not build on AIX while using the xlc 13.1 compiler

On 2018-11-27 13:26, Ichiroh Takiguchi wrote: Hello Volker. Sorry for your confusion. I want to keep visibility feature on AIX platform for future OpenJDK. If I can apply workaround for AIX platform... XLC++ 13.1 is confused destructor order for ~SimpleCriticalSectionLock() on

Re: RFR: 8212794 IBM-964 and IBM-29626C are required for AIX default charset

On 15/11/2018 00:29, Ichiroh Takiguchi wrote: Hello Martin. I know your point, but it's default encoding issue. User cannot start OpenJDK JDK9/10/11/12 on ja_JP(IBM29626C) and zh_TW(IBM964) locale on AIX. But IBM964 cannot be used for default encoding in current setting. This fix is really

Re: RFR: JDK-8213362 : Could not find libjava.dylib error when initializing JVM via JNI_CreateJavaVM

On 27/11/2018 23:05, Henry Jen wrote: Hi, Please review a follow up webrev[1] based on Priyanka’s patch, it simply added a test case for Mac only that will link with libjli. Note that, to use invoke API, one should probably link with libjvm, which works for all supported platforms, not just