September 2018 - core-libs-dev

RFR:8205330 InitialDirContext ctor sometimes throws NPE if the server has sent a disconnection
by vyom tewari 11 Sep '18

11 Sep '18

Hi All, Please review this simple fix below webrev: http://cr.openjdk.java.net/~vtewari/8205330/webrev0.0/index.html bugid: https://bugs.openjdk.java.net/browse/JDK-8205330 This fix will resolve the race in LdapClient where we are explicitly making "null" to LdapClient.conn. Thanks, Vyom

3 13

RFR: JDK-8205461 Create Collector which merges results of two other collectors
by Tomasz Linkowski 11 Sep '18

11 Sep '18

Hello, I'm responding to the thread at [1] (I'm not sure whether my message will get appended to it) and the CSR at [2]. I stumbled here from StackOverflow where - indepedently of all the others - I also came up with this type of "dual" *Collector* [3]. I named it "collectingBoth" there but I'd like to suggest a slightly different name here. I believe that Zheka Kozlov made a great observation about similiarity to "collectingAndThen" [4]. And it seems Brian Goetz favors the "AndThen" suffix [5]. On the other hand, this new Collector differs from "collectingAndThen" in that: 1) it hides the accumulation type parameters (A1, A2), and 2) it needs a few lower bounds on some of its type parameters. All in all, I'd like to propose to name the method "collectingBothAndThen" (or alternatively: "biCollectingAndThen". As an aside, I'd like to suggest changing the name of the parameter from "merger" to "biFinisher": 1) Peter Levart pointed out in [6] that "finisher" is already taken by the Collector API (and it's true), but it didn't prevent "collectingAndThen" from taking a "finisher" and then calling: downstream.finisher().andThen(finisher) 2) note that in all other contexts "merger" represents a BinaryOperator because it merges two values of the *same* type, and here the types of merged values are different. Complete signatures for comparison below: *<T,A,R,RR> Collector<T,A,RR> collectingAndThen(* * Collector<T, A, R> downstream,* * Function<R, RR> finisher)* *<T,R1,R2,R> Collector<T,?,R> collectingBothAndThen(* * Collector<? super T, ?, R1> downstream1,* * Collector<? super T, ?, R2> downstream2,* * BiFunction<? super R1, ? super R2, R> biFinisher)* As to the other potential names, I must say: - I'm not in favor of "teeingAndThen" nor all the duplex-related names (I find them unintuitive, especially the "teeing" one), - I really like "composite" and "compound" proposed by Stuart Marks [7]; it seems that "compouding" could be both intuitive and adhering to the -ing suffix convention [1] http://mail.openjdk.java.net/pipermail/core-libs-dev/2018-August/054718.html [2] https://bugs.openjdk.java.net/browse/JDK-8209685 [3] https://stackoverflow.com/a/52211175/2032415 [4] http://mail.openjdk.java.net/pipermail/core-libs-dev/2018-June/053922.html [5] http://mail.openjdk.java.net/pipermail/core-libs-dev/2018-August/054736.html [6] http://mail.openjdk.java.net/pipermail/core-libs-dev/2018-August/054724.html [7] http://mail.openjdk.java.net/pipermail/core-libs-dev/2018-August/054949.html -- Regards, Tomasz Linkowski

2 1

[12] RFR 8209773: Refactor shell test javax/naming/module/basic.sh to java
by Chris Yin 11 Sep '18

11 Sep '18

Please have a review for below change to refactor shell test javax/naming/module/basic.sh to plain java, no test logic change, old shell script is removed at same time, thanks bug: https://bugs.openjdk.java.net/browse/JDK-8209773 webrev: http://cr.openjdk.java.net/~xyin/8209773/webrev.00/ Regards, Chris

3 6

Review Request: JDK-8210502: jdeps does not handle properly on analyzing a mixture of MR JARs and non-MR JARs
by mandy chung 10 Sep '18

10 Sep '18

To analyze class dependencies of a multi-release JAR file, jdeps --multi-release option must be specified so that only entries of the specified version will be analyzed. This is to fix a bug in jdeps that fails when it is given both MR JARs and non-MR JARs. --multi-release option should be accepted for non-MR JAR files and all unversioned entries will be analyzed. The fix is trivial; just remove the check. Webrev: http://cr.openjdk.java.net/~mchung/jdk12/webrevs/8210502/webrev.00 Mandy

2 1

RFR: JDK-8059019 sdp.conf.template should move from unix to solaris
by Magnus Ihse Bursie 10 Sep '18

10 Sep '18

The file sdp.conf.template is copied only when building for solaris, but it resides in the unix source directory. Bug: https://bugs.openjdk.java.net/browse/JDK-8059019 Patch inline: diff --git a/make/copy/Copy-java.base.gmk b/make/copy/Copy-java.base.gmk --- a/make/copy/Copy-java.base.gmk +++ b/make/copy/Copy-java.base.gmk @@ -185,7 +185,7 @@ ifeq ($(OPENJDK_TARGET_OS), solaris) $(eval $(call SetupCopyFiles, COPY_SDP_CONF, \ - FILES := $(TOPDIR)/src/java.base/$(OPENJDK_TARGET_OS_TYPE)/conf/sdp/sdp.conf.template, \ + FILES := $(TOPDIR)/src/java.base/$(OPENJDK_TARGET_OS)/conf/sdp/sdp.conf.template, \ DEST := $(CONF_DST_DIR)/sdp, \ )) diff --git a/src/java.base/unix/conf/sdp/sdp.conf.template b/src/java.base/solaris/conf/sdp/sdp.conf.template rename from src/java.base/unix/conf/sdp/sdp.conf.template rename to src/java.base/solaris/conf/sdp/sdp.conf.template /Magnus

3 4

[12] RFR of JDK-8209930: Refactor java/util/zip/ZipFile/deletetempjar.sh to plain java test
by Amy Lu 10 Sep '18

10 Sep '18

test/jdk/java/util/zip/ZipFile/deletetempjar.sh Please review this patch to refactor above shell script test to java. bug: https://bugs.openjdk.java.net/browse/JDK-8209930 webrev: http://cr.openjdk.java.net/~amlu/8209930/webrev.00/ Thanks, Amy

2 4

RFR(M) : 8182404 : remove jdk.testlibrary.JDKToolFinder and JDKToolLauncher
by Igor Ignatyev 08 Sep '18

08 Sep '18

http://cr.openjdk.java.net/~iignatyev//8182404/webrev.00/index.html > 327 lines changed: 13 ins; 270 del; 44 mod; Hi all, could you please review the patch which removes jdk.testlibrary.JDKToolFinder and JDKToolLauncher and replaces their usages w/ jdk.test.lib.JDKToolFinder and JDKToolLauncher respectively? JBS: https://bugs.openjdk.java.net/browse/JDK-8182404 webrev: http://cr.openjdk.java.net/~iignatyev//8182404/webrev.00/index.html testing: tier1-3 + :jdk_svc Thanks, -- Igor

4 3

RFR(L/M) : 8210112 : remove jdk.testlibrary.ProcessTools
by Igor Ignatyev 07 Sep '18

07 Sep '18

http://cr.openjdk.java.net/~iignatyev//8210112/webrev.00/index.html > 2375 lines changed: 322 ins; 1662 del; 391 mod Hi all, could you please review the patch which removes jdk.testlibrary.ProcessTools and its friends and replaces all theirs usages w/ corresponding classes from jdk.test.lib.process? there were a few differences b/w implementations which are addressed by the patch: - j.t.l.p.ProcessTools missed executeProcess(ProcessBuilder, String) method - j.t.l.p.OutputAnalyzer didn't have shouldMatchByLine methods family - j.t.l.p.OutputBuffer was a very rudimentary and didn't serve any purposes, while j.t.OutputBuffer provided lazy access to a process's cout, cerr and exitcode. I have changed j.t.l.p.OutputBuffer to be an interface w/ two implementations LazyOutputBuffer and EagerOutputBuffer, and updated j.t.l.p.OutputAnalyzer to get values from an OutputBuffer instead of storing them. - j.t.l.p.ProcessTools::createJavaProcessBuilder always adds '-cp', but j.t.ProcessTools::createJavaProcessBuilder did not. I have identified tests which really depend on absence of '-cp' and updated them to create ProcessBuilder directly, namely JavaClassPathTest and AppendToClassPathModuleTest. the rest of the patch is straightforward change of used classes w/ adding @library /test/lib if necessary and removing @library /lib/testlibrary if possible. webrev: http://cr.openjdk.java.net/~iignatyev//8210112/webrev.00/index.html testing: tier1-tier3 + :jdk_svc JBS: https://bugs.openjdk.java.net/browse/JDK-8210112 Thanks, -- Igor

4 8

RFR JDK-8210345: The Japanese message of FileNotFoundException garbled
by Xueming Shen 07 Sep '18

07 Sep '18

Hi Please help review the changeset for JDK-8210345. issue: https://bugs.openjdk.java.net/browse/JDK-8210345 webrev: http://cr.openjdk.java.net/~sherman/8210345/webrev This is a "regression" from the change we made for JDK-8200243 [1], in which the getLastErrorString() for windows platform was updated back to use the platform encoding, instead of the incorrect utf8. However the corresponding change (to use JNU_NewStringPlatform to encode the err msg) in io_util.c was missed out. We currently don't have a auto-regression test with corresponding machine_locale setup/configuration for this one, Pallavi.Sonal kindly helped to verified it manually on his local setup (see attached). It would be desired to have a specific testing configuration to catch such error going forward, but it would be better done separately. Thanks, Sherman [1] http://mail.openjdk.java.net/pipermail/core-libs-dev/2018-June/054140.html ----------------- I could run the test case with you mach5 download and it is giving expected output : C:\Test>C:\Test\jdk-12\bin\java -showversion JI9057040 java version "12-internal" 2019-03-19 Java(TM) SE Runtime Environment 19.3 (build 12-internal+0-2018-09-05-0009528.xueming.shen.jdk12) Java HotSpot(TM) 64-Bit Server VM 19.3 (build 12-internal+0-2018-09-05-0009528.xueming.shen.jdk12, mixed mode) ja_JP java.io.FileNotFoundException: testabc.txt (指定されたファイルが見つかりません。) at java.base/java.io.FileInputStream.open0(Native Method) at java.base/java.io.FileInputStream.open(FileInputStream.java:219) at java.base/java.io.FileInputStream.<init>(FileInputStream.java:157) at java.base/java.io.FileInputStream.<init>(FileInputStream.java:112) at java.base/java.io.FileReader.<init>(FileReader.java:60) at JI9057040.main(JI9057040.java:10) testabc.txt (指定されたファイルが見つかりません。) testabc.txt (指定されたファイルが見つかりません。)

2 1

[12] RFR: 8210142: java.util.Calendar.clone() doesn't respect sharedZone flag
by Naoto Sato 06 Sep '18

06 Sep '18

Hello, Please review the fix to the following issue: https://bugs.openjdk.java.net/browse/JDK-8210142 The proposed fix is located at: http://cr.openjdk.java.net/~naoto/8210142/webrev.00/ The fix is a simple one line change, which is to make the sharedZone field consistent with the cloned TimeZone instance in Calendar.clone(). Naoto

3 7