February 2017 - core-libs-dev

JDK 9 RFR of 8175042: Add success message to java/io/FileInputStream/LargeFileAvailable.java
by Brian Burkhalter 15 Feb '17

15 Feb '17

Please review this trivial fix [1] for [2]. The intent is to add to the test log evidence that the test in fact completed. Also cf. [3]. Thanks, Brian [1] diff --- a/test/java/io/FileInputStream/LargeFileAvailable.java +++ b/test/java/io/FileInputStream/LargeFileAvailable.java @@ -71,6 +71,9 @@ } finally { file.delete(); } + + System.out.println("Test succeeded."); + System.out.flush(); } [2] https://bugs.openjdk.java.net/browse/JDK-8175042 [3] http://mail.openjdk.java.net/pipermail/nio-dev/2017-February/004130.html

3 3

RE: jdk10 : simplify jexec build settings
by Baesken, Matthias 15 Feb '17

15 Feb '17

I compared the jexec.c versions for macosx and unix ( jdk/src/java.base/macosx/native/launcher/jexec.c and jdk/src/java.base/unix/native/launcher/jexec.c ) And to me it looks like the unix version could be used for macosx too (just in case there is a need to reenable the build of jexec.c for macosx one day again). Comments / suggestions ? Best regards, Matthias From: Baesken, Matthias Sent: Donnerstag, 9. Februar 2017 14:10 To: 'Erik Joelsson' <erik.joelsson(a)oracle.com>; build-dev(a)openjdk.java.net; 'core-libs-dev(a)openjdk.java.net' <core-libs-dev(a)openjdk.java.net> Cc: Langer, Christoph <christoph.langer(a)sap.com> Subject: RE: jdk10 : simplify jexec build settings Hello Erik, thanks for the comments . >>Then there is handling for macosx left , but the build is not enabled for macosx, does it still make sense to include the macosx handling (there is even a separate jexec.c for macosx) : > >This is indeed weird. I don't think we ever built jexec for macosx so the source file should likely be removed. That is however a question for core-libs I think. I include core-libs-dev , can someone comment on jexec on macosx ? Currently jexec.c is not compiled for macosx (jdk9/10), see jdk/make/launcher/Launcher-java.base.gmk . It is just compiled on linux . So I wonder - is it ok to remove the macosx handling in the mentioned makefile jdk/make/launcher/Launcher-java.base.gmk for jexec ? >This will automatically look in all the directories where source files are supposed to be and pick the most specific one if there are any with the same name. >Since the share launcher dir contains more src files, you will need to leave the INCLUDE_FILES := jexec.c this time. >From what I observe in the linux build log, just jexec.c is compiled into jexec.o and then this single object is used to create the executable ("program") jexec. Other src files are not used in the compilation of jexec, so just using $(JDK_TOPDIR)/src/$(MODULE)/unix/native/launcher would be fine (as long as macosx can be dropped). Best regards, Matthias From: Erik Joelsson [mailto:erik.joelsson@oracle.com] Sent: Donnerstag, 9. Februar 2017 13:42 To: Baesken, Matthias <matthias.baesken(a)sap.com<mailto:matthias.baesken@sap.com>>; build-dev(a)openjdk.java.net<mailto:build-dev@openjdk.java.net> Cc: Langer, Christoph <christoph.langer(a)sap.com<mailto:christoph.langer@sap.com>> Subject: Re: jdk10 : simplify jexec build settings Hello, On 2017-02-09 12:36, Baesken, Matthias wrote: Hello , while adjusting the jspawnhelper build settings with 8174086, it has been noticed that the jexec build settings need some simplification as well. The bug https://bugs.openjdk.java.net/browse/JDK-8174242 has been created for this. When looking into it, I had some questions : http://hg.openjdk.java.net/jdk10/jdk10/jdk/file/ae7afa9abe67/make/launcher/… The makefile (make/launcher/Launcher-java.base.gmk ) handles Solaris 32bit, but is this really supported in jdk 9 or 10 ( I think it was removed in 9 and only 64bit Solaris support remains ) ? We do not support 32bit Solaris. The issue with jexec for Solaris was raised a while back and the conclusion was to scrap support, so no need to build it for Solaris at all. ifeq ($(OPENJDK_TARGET_OS), solaris) ifeq ($(OPENJDK_TARGET_CPU_BITS), 32) BUILD_JEXEC := 1 endif endif ifeq ($(OPENJDK_TARGET_OS), linux) BUILD_JEXEC := 1 endif # OPENJDK_TARGET_OS # # jdk/make/java/jexec/Makefile # ifeq ($(BUILD_JEXEC), 1) Then there is handling for macosx left , but the build is not enabled for macosx, does it still make sense to include the macosx handling (there is even a separate jexec.c for macosx) : This is indeed weird. I don't think we ever built jexec for macosx so the source file should likely be removed. That is however a question for core-libs I think. The makefile logic shouldn't need to be that specific though. Our modern pattern for this is something like this: SRC := $(call uniq, $(wildcard \ $(JDK_TOPDIR)/src/$(MODULE)/$(OPENJDK_TARGET_OS)/native/launcher \ $(JDK_TOPDIR)/src/$(MODULE)/$(OPENJDK_TARGET_OS_TYPE)/native/launcher \ $(JDK_TOPDIR)/src/$(MODULE)/share/native/launcher)) This will automatically look in all the directories where source files are supposed to be and pick the most specific one if there are any with the same name. Since the share launcher dir contains more src files, you will need to leave the INCLUDE_FILES := jexec.c this time. For libraries, we have abstracted this construct in the macro FindSrcDirForLib (LibCommon.gmk) but we haven't done the same for launchers yet. /Erik ifeq ($(OPENJDK_TARGET_OS), windows) else ifeq ($(OPENJDK_TARGET_OS), macosx) BUILD_JEXEC_SRC := $(JDK_TOPDIR)/src/java.base/macosx/native/launcher else BUILD_JEXEC_SRC := $(JDK_TOPDIR)/src/java.base/unix/native/launcher endif Should I remove the solaris 32bit / macosx handling for jexec from make/launcher/Launcher-java.base.gmk ? Regards, Matthias

2 5

RFR(XS): 8174950: Gracefully handle null Supplier in Objects.requireNonNull
by Volker Simonis 15 Feb '17

15 Feb '17

Hi, can I please have another review for the following trivial fix: http://cr.openjdk.java.net/~simonis/webrevs/2017/8174950/ https://bugs.openjdk.java.net/browse/JDK-8174950 This change has already been discussed in length on the mailing list: http://mail.openjdk.java.net/pipermail/core-libs-dev/2017-February/thread.h… http://mail.openjdk.java.net/pipermail/core-libs-dev/2014-February/thread.h… and in the bug comments at: https://bugs.openjdk.java.net/browse/JDK-8033909 So I'll give just (yet another) short summary here: - Objects.requireNonNull(T, Supplier) does not check for the Supplier argument being null. Instead it relies on the fact, that the VM will implicitly throw a NullPointerException when it calls .get on the Supplier argument during the creation of the explicit NullPointerException which it is supposed to throw. - this behavior slightly differs from Objects.requireNonNull(T, String) which simply creates a NullPointerException with a null message in the case where the String argument is null. - the difference is not evident in the OpenJDK, because the HotSpot VM creates a NPE with a null message by default if we call a method on a null object. - however creating such a NPE with a null message when invoking a method on a null object is not enforced by the standard, and other implementations can do better :) For the following trivial program: public class NonNull { public static void main(String[] args) { Supplier<String> ss = null; Object o = Objects.requireNonNull(null, ss); } } the current OpenJDK implementation returns: Exception in thread "main" java.lang.NullPointerException at java.util.Objects.requireNonNull(Objects.java:290) at NonNull.main(NonNull.java:8) but the SAP JVM will print: Exception in thread "main" java.lang.NullPointerException: while trying to invoke the method java.util.function.Supplier.get() of a null object loaded from local variable 'messageSupplier' at java.util.Objects.requireNonNull(Objects.java:290) at NonNull.main(NonNull.java:8) which is at least confusing for a call to Objects.requireNonNul() with a null Supplier. We think the exception should be the same like the one we get when invoking Objects.requireNonNul() with a null String. - because of this difference (and because we like our extended Exception messages :) the JCK test for Objects.requireNonNul(T, Supplier) (i.e. api/java_util/Objects/index.html#RequireNonNullMessageSupplier) was removed from TCK 8 and is still commented out in TCK 9 (npe_checkingNullSupplier() in RequireNonNullMessageSupplier.java). I really think that the simplest and most natural fix for this problem is to simply check for a null Supplier argument and create the NPE with an explicit null message in that case (as outlined in the webrev). This: - makes the two requireNonNul() overloads for String and Supplier behave the same (which I think was the initial intention). - doesn't require documentation changes - makes it possible to write a simple and conforming TCK test Regards, Volker

5 5

RFR 8165035 jar --help-extra should provide information on the -n/--normalize option
by Paul Sandoz 15 Feb '17

15 Feb '17

Hi, Please review this minor fix to the --help-extra option to to report the -n/--normalize option: http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8165035-jar-tool-n/webrev/ It will report the following (and will be formatted correctly for a fixed width font): " Operation modifiers valid only in create mode: -n, --normalize Normalize information in the new jar archive after creation “ Paul.

5 4

RE: RFR [JAXP] JDK-8174025 Regression in XML Transform caused by JDK-8087303
by Frank Yuan 15 Feb '17

15 Feb '17

Hi Joe and Daniel I tested more and checked the code, both of you are right. CRLF, CR, LF in the xml file are all normalized to LF, and finally output to the platform-related line.separator if it's serialized. The serializer only handle LF as newline. User can create CR text node programmatically or there may be some case that CR is sent to the serializer intentionally, but anyway in these cases, CR is not regarded as a newline. So the change as Joe's comment and I stated in previous mail is made: http://cr.openjdk.java.net/~fyuan/8174025/webrev.02/ Thanks Frank > -----Original Message----- > From: Frank Yuan [mailto:frank.yuan@oracle.com] > Subject: RE: RFR [JAXP] JDK-8174025 Regression in XML Transform caused by JDK-8087303 > > > > -----Original Message----- > > From: huizhe wang [mailto:huizhe.wang@oracle.com] > > Subject: Re: RFR [JAXP] JDK-8174025 Regression in XML Transform caused > by JDK-8087303 > > > > Looks good to me as well. > > > > For the CR and LF question, XML processors are required by the > > specification to normalize and translate both CRLF sequence and any CR > > not followed by LF to a single LF. For that reason, you don't have > > check CR since the content the serializer gets is parsed. > > > Thank you very much for explanation, since that, I will remove the check > for CR as below: > 3439c3439 > < while (skipBeginningNewlines && (text[start] == '\n' > || text[start] == '\r')) { > --- > > while (skipBeginningNewlines && text[start] == '\n') > { > 3498c3498 > < while (skipBeginningNewlines && (text[start] == > '\n' || text[start] == '\r')) { > --- > > while (skipBeginningNewlines && text[start] == > '\n') { > > Once it is passed by all tests, I will push the change. > > Thanks > Frank > > > Best, > > Joe > > > > On 2/14/2017 6:58 AM, Frank Yuan wrote: > > >> -----Original Message----- > > >> From: Daniel Fuchs [mailto:daniel.fuchs@oracle.com] > > >> Subject: Re: RFR [JAXP] JDK-8174025 Regression in XML Transform > caused by JDK-8087303 > > >> > > >> Hi Frank, > > >> > > >> On 14/02/17 13:43, Frank Yuan wrote: > > >>>> -----Original Message----- > > >>>> From: Daniel Fuchs [mailto:daniel.fuchs@oracle.com] > > >>>> Subject: Re: RFR [JAXP] JDK-8174025 Regression in XML Transform > caused by JDK-8087303 > > >>>> > > >>>> Hi Frank, > > >>>> > > >>>> Should you skip '\r' if it's not followed by '\n'? > > >> Well - I'll let Joe answer that. ;-) > > > Hmm, wait for Joe to confirm. > > > > > >> It was just a question, I was wondering whether that could > > >> potentially cause problems down the road - since new lines > > >> are usually only either '\n' or '\r'+'\n'. > > >> > > > Agree. > > > > > >> Your patch looks fine otherwise, maybe the code that skips > > >> the '\n' could be factorized somewhere to avoid duplication, > > >> but that's not really important. > > >> > > >> Both issues reported in the bug are still fix - so I think we > > >> should try to get this patch in as soon as we can. > > >> > > > Yes, understand! > > > > > > Thanks > > > Frank > > > > > >> best regards, > > >> > > >> -- daniel > > >> > > >>> Does it matter? Since XML processor should normalize the newline. > > >>> > > >>> Thanks > > >>> Frank > > >>>> best regards, > > >>>> > > >>>> -- daniel > > >>>> > > >>>> On 14/02/17 10:33, Frank Yuan wrote: > > >>>>> Hi Joe > > >>>>> > > >>>>> As you suggested, I made pretty-print a little better based on the > fix. That is when adding indentation, just check the > > >>> beginning > > >>>>> character(s), in case of '\n' or '\r' then, ignore it/them. > > >>>>> > > >>>>> Please check the new webrev: > http://cr.openjdk.java.net/~fyuan/8174025/webrev.01/ > > >>>>> > > >>>>> > > >>>>> Thanks > > >>>>> Frank > > >>>>> > > >>>>> -----Original Message----- > > >>>>> From: huizhe wang [mailto:huizhe.wang@oracle.com] > > >>>>> Subject: should have been 8174025 -> Re: RFR [JAXP] JDK-8170192 > Regression in XML Transform caused by JDK-8087303 > > >>>>> > > >>>>> Note that the bug id was incorrect, it should have been 8174025. > 8170192 > > >>>>> was a test bug fix. > > >>>>> > > >>>>> -Joe > > >>>>> > > >>>>> On 2/13/2017 1:35 AM, Frank Yuan wrote: > > >>>>>> Hi Joe and Daniel > > >>>>>> > > >>>>>> Thank you very much for your review! > > >>>>>> > > >>>>>> Frank > > >>>>>> > > >>>>>> > > >>>>>> -----Original Message----- > > >>>>>> From: huizhe wang [mailto:huizhe.wang@oracle.com] > > >>>>>> Subject: Re: RFR [JAXP] JDK-8170192 Regression in XML Transform > caused by JDK-8087303 > > >>>>>> > > >>>>>> +1 from me too. > > >>>>>> > > >>>>>> Thanks, > > >>>>>> Joe > > >>>>>> > > >>>>>> On 2/10/2017 5:25 AM, Daniel Fuchs wrote: > > >>>>>>> Hi Frank, > > >>>>>>> > > >>>>>>> Thanks for fixing this! > > >>>>>>> > > >>>>>>> I imported your patch and played with it a bit. > > >>>>>>> Also ran the jaxp test. > > >>>>>>> > > >>>>>>> Both issues reported have indeed disappeared. > > >>>>>>> > > >>>>>>> So that's a +1 from me. > > >>>>>>> > > >>>>>>> best regards, > > >>>>>>> > > >>>>>>> -- daniel > > >>>>>>> > > >>>>>>> On 10/02/17 11:03, Frank Yuan wrote: > > >>>>>>>> Hi All > > >>>>>>>> > > >>>>>>>> > > >>>>>>>> > > >>>>>>>> Would you like to review > > >>>>>>>> http://cr.openjdk.java.net/~fyuan/8174025/webrev.00/? > > >>>>>>>> > > >>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8174025 > > >>>>>>>> > > >>>>>>>> > > >>>>>>>> > > >>>>>>>> JDK-8087303 introduced 2 issues: > > >>>>>>>> > > >>>>>>>> 1. Flaw when xlst uses disable-output-escaping attribute > > >>>>>>>> > > >>>>>>>> 2. Eat the whitespace between html inline elements > > >>>>>>>> > > >>>>>>>> > > >>>>>>>> > > >>>>>>>> This patch fixed the issues. > > >>>>>>>> > > >>>>>>>> To fix the second issue, we decide to keep the compatibility > with JDK 8 > > >>>>>>>> on the whitespace handling, that is only LSSerializer cleans > the extra > > >>>>>>>> whitespaces in if pretty-print is on, but XSLT doesn't. > > >>>>>>>> > > >>>>>>>> I modified the behavior of getIndent() method in class > ToStream, to make > > >>>>>>>> LSSerializer be sensitive of current state from ToStream. This > should be > > >>>>>>>> safe because ToStream is an internal class and getIndent() > method is > > >>>>>>>> never used before. > > >>>>>>>> > > >>>>>>>> > > >>>>>>>> > > >>>>>>>> Thanks > > >>>>>>>> > > >>>>>>>> Frank > > >>>>>>>> > > >>>>>>>> > > >>>>>>>> > > >>>>> > > >>> > > >

2 2

Re: RFR [JAXP] JDK-8174025 Regression in XML Transform caused by JDK-8087303
by Frank Yuan 15 Feb '17

15 Feb '17

Hi Joe As you suggested, I made pretty-print a little better based on the fix. That is when adding indentation, just check the beginning character(s), in case of '\n' or '\r' then, ignore it/them. Please check the new webrev: http://cr.openjdk.java.net/~fyuan/8174025/webrev.01/ Thanks Frank -----Original Message----- From: huizhe wang [mailto:huizhe.wang@oracle.com] Subject: should have been 8174025 -> Re: RFR [JAXP] JDK-8170192 Regression in XML Transform caused by JDK-8087303 Note that the bug id was incorrect, it should have been 8174025. 8170192 was a test bug fix. -Joe On 2/13/2017 1:35 AM, Frank Yuan wrote: > Hi Joe and Daniel > > Thank you very much for your review! > > Frank > > > -----Original Message----- > From: huizhe wang [mailto:huizhe.wang@oracle.com] > Subject: Re: RFR [JAXP] JDK-8170192 Regression in XML Transform caused by JDK-8087303 > > +1 from me too. > > Thanks, > Joe > > On 2/10/2017 5:25 AM, Daniel Fuchs wrote: >> Hi Frank, >> >> Thanks for fixing this! >> >> I imported your patch and played with it a bit. >> Also ran the jaxp test. >> >> Both issues reported have indeed disappeared. >> >> So that's a +1 from me. >> >> best regards, >> >> -- daniel >> >> On 10/02/17 11:03, Frank Yuan wrote: >>> Hi All >>> >>> >>> >>> Would you like to review >>> http://cr.openjdk.java.net/~fyuan/8174025/webrev.00/? >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8174025 >>> >>> >>> >>> JDK-8087303 introduced 2 issues: >>> >>> 1. Flaw when xlst uses disable-output-escaping attribute >>> >>> 2. Eat the whitespace between html inline elements >>> >>> >>> >>> This patch fixed the issues. >>> >>> To fix the second issue, we decide to keep the compatibility with JDK 8 >>> on the whitespace handling, that is only LSSerializer cleans the extra >>> whitespaces in if pretty-print is on, but XSLT doesn't. >>> >>> I modified the behavior of getIndent() method in class ToStream, to make >>> LSSerializer be sensitive of current state from ToStream. This should be >>> safe because ToStream is an internal class and getIndent() method is >>> never used before. >>> >>> >>> >>> Thanks >>> >>> Frank >>> >>> >>> >

3 6

[9] RFR: 8174779: Locale issues with Mac 10.12
by Naoto Sato 14 Feb '17

14 Feb '17

Hello, Please review the fix to the following issue: https://bugs.openjdk.java.net/browse/JDK-8174779 The proposed fix is located at: http://cr.openjdk.java.net/~naoto/8174779/webrev.01/ The root cause of the problem was that starting from macOS 10.12, it returns the preferred user language including both script and region, which cannot be dealt with the existing parsing code. Naoto

2 1

JDK 9 RFR of JDK-8174960: Mark WakeupAfterClose.java as failing intermittentl
by joe darcy 14 Feb '17

14 Feb '17

Hello, The test java/nio/channels/Selector/WakeupAfterClose.java has been seen to fail intermittently at a low frequency (JDK-8143614). The test should be marked accordingly; patch below. Thanks, -Joe --- a/test/java/nio/channels/Selector/WakeupAfterClose.java Mon Feb 13 11:35:00 2017 -0500 +++ b/test/java/nio/channels/Selector/WakeupAfterClose.java Tue Feb 14 12:01:03 2017 -0800 @@ -1,5 +1,5 @@ /* - * Copyright (c) 2007, Oracle and/or its affiliates. All rights reserved. + * Copyright (c) 2007, 2017, Oracle and/or its affiliates. All rights reserved. * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. * * This code is free software; you can redistribute it and/or modify it @@ -24,6 +24,7 @@ /* @test * @bug 6524172 * @summary Invoking wakeup on closed Selector can throw NPE if close resets interrupt status + * @key intermittent */ import java.nio.channels.Selector;

3 2

RFR JDK-8174248: partialUpdateFooMainClass test in tools/jar/modularJar/Basic.java needs to be re-examined
by Xueming Shen 14 Feb '17

14 Feb '17

Hi, Please review the test change for JDK-8174248 issue: https://bugs.openjdk.java.net/browse/JDK-8174248 webrev: http://cr.openjdk.java.net/~sherman/8174248/webrev The change is to simply rename the entry name from "IAmNotTheEntryPoint" to a "packaged" one as " jdk.test.foo.IAmNotTheEntryPoint" to satisfy the newly added sanity check in j.l.m.ModuleDescriptor.Builder.mainClass(), in which the "main-class in unnamed package" is no longer allowed (and the named package must exist in module "packages") . Arguably it might be desired for "jar" tool to also verify whether or not the "main-class" really exists in the module jar file (the implementation does not verify the existence of the main-class for the manifest for now, the newly added module related code follows the "convention"), but this probably should be handled/discussed in a separate rfe. Thanks, Sherman

3 2

RFR (JAXP) 8169450: StAX parse error if there is a newline in xml declaration
by huizhe wang 14 Feb '17

14 Feb '17

A quick fix for the error parsing xml declaration. This is one of the three outstanding issues in the xml area that must be addressed for the coming development deadline. JBS: https://bugs.openjdk.java.net/browse/JDK-8169450 webrev: http://cr.openjdk.java.net/~joehw/jdk9/8169450/webrev/ Checking whether a space follows "<?xml" was sufficient for DOM/SAX for which the base parser was originally created since the xml declaration was normalized during version detection. StAX, sharing the base parser after it was added to the JDK, however, does not use the same version detection/normalization process and would incorrectly parse the declaration if there are other whitespaces. Thanks, Joe

4 9