September 2018 - core-libs-dev

RFR JDK-8209553: ExceptionInInitializerError can have a default detail message if the cause is given
by mandy chung 13 Sep '18

13 Sep '18

ExceptionInInitializerError(Throwable cause) sets the detail message to null. It'd be helpful to include a detail message rather than null as in Throwable(Throwable cause) that constructs a new throwable with a default message cause==null ? null : cause.toString(). This would help troubleshooting of writing new bootstrap methods where VM currently asserts non-null linkage error message [1] where there are other solutions such as constructing the message in the VM or removing the assert. This patch proposes to change ExceptionInInitializerError(Throwable cause) to default the detail message to cause.toString() if cause is not null. It's an incompatibility change; for example existing code that expects a null message will now see a detail message. But the compatibility risk should be low as EIIE should be fatal. This also proposes to add new LinkageError(Throwable cause) constructor to retrofit the exception chaining mechanism and that allows to clean up the current ExceptionInInitializerError implementation. Webrev: http://cr.openjdk.java.net/~mchung/jdk12/webrevs/8209553/webrev.00 I will create a CSR. Mandy [1] https://bugs.openjdk.java.net/browse/JDK-8208172

6 19

[12]: RFR: Use CLDR's time zone mappings for Windows
by Naoto Sato 13 Sep '18

13 Sep '18

Hello, Please review the fix to the following issue: https://bugs.openjdk.java.net/browse/JDK-8209167 The proposed changeset is located at: http://cr.openjdk.java.net/~naoto/8209167/webrev.01/ This fix is to remove the hand crafted map file (lib/tzmappings) on Windows, which maps Windows time zones to Java's tzid. It is now dynamically generated at the build time, using CLDR's data file (windowsZones.xml) Naoto

5 8

RFR 8098798: Thread.join(ms) on Linux still affected by changes to the time-of-day clock
by Roger Riggs 13 Sep '18

13 Sep '18

Please review changes for: 8098798: Thread.join(ms) on Linux still affected by changes to the time-of-day clock Use System.nanoTime to compute any remaining delay 8210004: Thread.sleep(millis, nanos) timeout returns early Avoid an early return by rounding the milliseconds up if there are any nanoseconds as was done in Object.wait(ms, ns). (If its not appropriate to do the two reviews together, I can split them). Webrev: http://cr.openjdk.java.net/~rriggs/webrev-thread-early-8098798/ Thanks, Roger

3 7

[12] RFR of JDK-8209772: Refactor shell test java/util/ServiceLoader/basic/basic.sh to java
by Amy Lu 13 Sep '18

13 Sep '18

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

2 2

RFR 8210670 (S): Accept double-dash VM-name options at launch time
by mark.reinhold＠oracle.com 13 Sep '18

13 Sep '18

To make this trivial enhancement I first had to fix some broken tests, so there are two issues and two webrevs here. 8210669: Some launcher tests assume a pre-JDK 9 run-time image layout Two launcher tests, ExecutionEnvironment.java and Test7029048.java (in test/jdk/tools/launcher), still assume the old image layout in which a HotSpot shared library (libjava.so) is found in $JDK/lib/$ARCH/$VMTYPE on Linux and Solaris. The intermediate $ARCH directory was removed in JDK 9, as part of JEP 220 (Modular Run-Time Images) [1]. Since that time these tests have been succeeding anyway, because they don’t fail when the requested VM is not found. The tests should be fixed to fail when the requested VM is not found, and to look for VM shared libraries in the proper location. JBS: https://bugs.openjdk.java.net/browse/JDK-8210669 Webrev: http://cr.openjdk.java.net/~mr/rev/8210669/ 8210670: Accept double-dash VM-name options at launch time Per JEP 293 (Guidelines for JDK Command-Line Tool Options) [2], enhance the Java launcher so that `--server` is accepted to select the server VM, in addition to `-server`, and likewise for any other VMs listed in the $JDK/lib/jvm.cfg file. JBS: https://bugs.openjdk.java.net/browse/JDK-8210670 Webrev: http://cr.openjdk.java.net/~mr/rev/8210670/ Passes tier1 tests; tier2-3 in progress. Thanks, - Mark [1] http://openjdk.java.net/jeps/220 [2] http://openjdk.java.net/jeps/293

2 2

ByteArrayOutputStream should not have a new writeBytes method in Java 11
by Christian Ullenboom 12 Sep '18

12 Sep '18

1. There is write(byte[]) already 2. even if, it should not be byte b[] but byte[] b

5 6

Re-iterate JDK-6194856: Zip Files lose ALL ownership and permissions of the files
by Langer, Christoph 12 Sep '18

12 Sep '18

Hi all, I'm currently revisiting a long standing shortcoming of the java.util.zip (and java.util.jar) implementation. The lack is that in the current implementation, Unix mode bits (e.g. rwx) are not stored/read from zip or jar files and the jar tool has no capabilities to store/preserve the mode information. There have been several bugs opened but they were closed with "Won't Fix". One of them is JDK-6194856, mentioned in this mail's subject [1]. Unfortunately there is no detailed reasoning given why that can't be done. Maybe these are compatibility or security issues? Maybe someone can enlighten me about previous discussions concerning this matter... I personally can imagine contributing the following: First step: Enrich java.util.zip.ZipEntry with some method(s) like getUnixPermissions() and setUnixPermissions(). For writing zip files it would mean depending on the availability of Unix permission information in a ZipEntry object, the entry version would be set to "3 - Unix" according to section "D. Explanation of fields", "version made by (2 bytes)" of the zip specification that is referenced in the current Javadoc for the java.util.zip package [2]. Reading Zip files would take into account the file attribute mapping of the version field and in case of "3 - Unix", it would read the permissions settings from the external file attributes section of the entry header. This seems to be the de-facto standard of the GNU zip/unzip implementation. With that addition the the java.util.zip API, developers using it would get the ability to cope with Unix permissions. As a second step, I can imagine spending a flag for the jar utility to have it handle Unix permissions when packing/extracting. Isn't that something that should be done? Or, if not, why? Thanks and best regards in advance Christoph [1] https://bugs.openjdk.java.net/browse/JDK-6194856 [2] http://www.info-zip.org/doc/appnote-19970311-iz.zip

3 2

[RFR] 8205525 : Improve exception messages during manifest parsing of jar archives
by Baesken, Matthias 12 Sep '18

12 Sep '18

Hello, please review this small change that improve exception messages during manifest parsing of jar archives . Thanks, Matthias Bug : https://bugs.openjdk.java.net/browse/JDK-8205525 Webrev : http://cr.openjdk.java.net/~mbaesken/webrevs/8205525/

9 73

RFR (XS) 8210347 : Combine subsequent calls to Set.contains() and Set.add()
by Ivan Gerasimov 12 Sep '18

12 Sep '18

Hello! It's a pico-optimization. In a few places a call to Set.contains() can be merged with the following Set.add(). BUGURL: https://bugs.openjdk.java.net/browse/JDK-8210347 WEBREV: http://cr.openjdk.java.net/~igerasim/8210347/00/webrev/ Would you please help review the trivial fix? -- With kind regards, Ivan Gerasimov

3 2

Question about libjava/childproc.c
by Thomas Stüfe 11 Sep '18

11 Sep '18

Hi all, I just saw that in childproc.c, between fork and exec, in the child process, we attempt to close all file descriptors. Which is fine and good practice. See function "closeDecriptors()" in libjava/childproc.c. That function attempts to read /proc/fd to get all open file descriptors and then closes them. For that, it uses readdir(). However, it has to make some weird magic workarounds since readdir() itself may be internally implemented using a file descriptor: 86 /* We're trying to close all file descriptors, but opendir() might 87 * itself be implemented using a file descriptor, and we certainly 88 * don't want to close that while it's in use. We assume that if 89 * opendir() is implemented using a file descriptor, then it uses 90 * the lowest numbered file descriptor, just like open(). So we 91 * close a couple explicitly. */ 92 93 close(from_fd); /* for possible use by opendir() */ 94 close(from_fd + 1); /* another one for good luck */ My question would be, could we not - instead of straight away closing the file descriptor - set them all to FD_CLOEXEC instead? for (every fd in /proc/fd) fcntl(fd, F_SETFD, FD_CLOEXEC) ? That way we will close them once we do exec(), which is what we actually want, no? Thanks & Regards, Thomas

3 10