November 2021 - core-libs-dev

RFR: 8153133: Thread.dumpStack() can use StackWalker
by Jaikiran Pai 09 Nov '21

09 Nov '21

Can I please get a review of this change which seeks to implement the enhancement noted in https://bugs.openjdk.java.net/browse/JDK-8153133? The commit in this PR uses the `StackWalker` API to dump the stacktrace of the thread. A few things to note about this change: - Previously, the dumped stacktrace would be preceded by a line (from the `Exception` instance) which would state `java.lang.Exception: Stack trace` and the rest of the lines would be the stacktrace. The change in this PR does a small (unrelated) enhacement which now includes the thread name in the message. So something like `MainThread Stack trace` where `MainThread` is the name of the thread whose stacktrace is being dumped. The linked JBS doesn't mention this change as a necessity but I decided to include it in this PR since I've always missed the thread name in that dumped stacktrace and since we are now using the StackWalker API, the mention of `java.lang.Exception: ...` line in the thread dump will no longer make sense (unless we wanted backward compatibility) - The change doesn't use lambda to allow `Thread.dumpStack()` to be called (for debugging purposes) from places where lambda usage might be too early. - The change also includes a fallback to use the `Exception.printStackTrace()` to allow for calls to `Thread.dumpStack()` when `StackWalker` class itself is being initialized. The PR also includes a new jtreg test which verifies this change. The test has 3 test actions - one without security manager, one with security manager and one with `java.security.debug=access,stack` to exercise the case where Thread.dumpStack() gets called during StackWalker class initialization. The linked JBS issue notes that it would be good to use the StackWalker API even in the `Thread.getStackTrace` implementation. This PR however doesn't include that change because I wanted to tackle that separately since I think that would need to run some performance benchmarks to evaluate any performance changes. The current `Thread.dumpStack` method clearly states that it is meant for debugging purposes so I haven't run any kind of performance benchmarks on this change. ------------- Commit messages: - 8153133: Thread.dumpStack() can use StackWalker Changes: https://git.openjdk.java.net/jdk/pull/6292/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6292&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8153133 Stats: 171 lines in 3 files changed: 170 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/6292.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/6292/head:pull/6292 PR: https://git.openjdk.java.net/jdk/pull/6292

3 11

RFR: 8231490: Ugly racy writes to ZipUtils.defaultBuf
by Eamonn McManus 08 Nov '21

08 Nov '21

This change applies the minimal fix suggested in https://bugs.openjdk.java.net/browse/JDK-8231490. The bug text suggests possibilities for reworking, but notes that this change is enough to fix the data race. Adding a regression test is probaby not feasible but we do observe that Java TSAN no longer reports a race after the change. ------------- Commit messages: - 8231490: Fix a data race in java.util.zip.Inflater Changes: https://git.openjdk.java.net/jdk/pull/6242/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6242&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8231490 Stats: 3 lines in 1 file changed: 2 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/6242.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/6242/head:pull/6242 PR: https://git.openjdk.java.net/jdk/pull/6242

2 3

RFR: 8276408: Deprecate Runtime.exec methods with a single string command line argument
by Roger Riggs 08 Nov '21

08 Nov '21

The three `java.lang.Runtime.exec` methods that tokenize a command line to produce an array of string arguments are easily misused, sometimes with erroneous results. For example, on some operating systems, spaces are supported in filenames and are in common use. The tokenization uses only whitespace characters, ignoring quote characters. It is error prone because quotes may appear in the string but are ignored. The implementation (on Windows) includes a heuristic for the executable argument that tries to re-parse the command line respecting quotes but it is undocumented. ------------- Commit messages: - 8276408: Deprecate Runtime.exec methods with a single string command line argument Changes: https://git.openjdk.java.net/jdk/pull/6233/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6233&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8276408 Stats: 21 lines in 1 file changed: 21 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/6233.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/6233/head:pull/6233 PR: https://git.openjdk.java.net/jdk/pull/6233

2 3

RFR: 8276400: openjdk image Jars, Zips and Jmods built from the same source are not reproducible
by Andrew Leonard 08 Nov '21

08 Nov '21

This PR enables reproducible Jars, Jmods and openjdk image zip files (eg.src.zip). It provides support for SOURCE_DATE_EPOCH for Jar, Jmod and underlying ZipOutputStream's. It fixes the following keys issues relating to reproducibility: - Jar and ZipOutputStream are not SOURCE_DATE_EPOCH aware - Jar and ZipOutputStream now detect SOURCE_DATE_EPOCH environment setting - Jar and Jmod file content ordering was non-determinsitic - Fixes to Jar and Jmod main's to ensure sorted classes content ordering - openjdk image zip file generation used "zip" which is non-determinsitic - New openjdk build tool "GenerateZip" which produces the final determinsitic zip files as part of the build and also detects SOURCE_DATE_EPOCH Signed-off-by: Andrew Leonard <anleonar(a)redhat.com> ------------- Commit messages: - 8276400: openjdk image Jars, Zips and Jmods built from the same source are not reproducible Changes: https://git.openjdk.java.net/jdk/pull/6268/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6268&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8276400 Stats: 818 lines in 11 files changed: 797 ins; 3 del; 18 mod Patch: https://git.openjdk.java.net/jdk/pull/6268.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/6268/head:pull/6268 PR: https://git.openjdk.java.net/jdk/pull/6268

7 22

RFR: JDK-8276562: Fix to JDK-8263155 left out the help text changes
by Andy Herrick 08 Nov '21

08 Nov '21

JDK-8276562: Fix to JDK-8263155 left out the help text changes ------------- Commit messages: - JDK-8276562: Fix to JDK-8263155 left out the help text changes Changes: https://git.openjdk.java.net/jdk/pull/6281/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6281&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8276562 Stats: 20 lines in 4 files changed: 18 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/6281.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/6281/head:pull/6281 PR: https://git.openjdk.java.net/jdk/pull/6281

3 3

RFR: JDK-8274686 : java.util.UUID#hashCode() should use Long.hashCode()
by PROgrm_JARvis 08 Nov '21

08 Nov '21

This is trivial fix of [JDK-8274686](https://bugs.java.com/bugdatabase/view_bug.do?bug_id=JDK-82746… which replaces manually-computed `int`-based `long` hash-code. Because `Long#hashCode(long)` uses other hashing function than the one currently used here: https://github.com/openjdk/jdk/blob/75d6688df9845ecb8f370b4cd2d5a36f13d3cdc… the value of `hashCode()` will produce different result, however this does not seem to be a breaking change as `UUID#hashCode()` is not specified. --- Note: the comment to the bug states: > Moved to JDK for further discussions of the proposed enhancement. But as I there seemed to be no corresponding discussion in core-libs-dev and the change looks trivial, I considered that it is appropriate to open a PR which (if needed) may be used for discussion (especially, considering the fact that its comments get mirrored to the ML). ------------- Commit messages: - fix: use `Long#hashCode(long)` for `UUID#hashCode()` Changes: https://git.openjdk.java.net/jdk/pull/5811/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5811&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8274686 Stats: 2 lines in 1 file changed: 0 ins; 1 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/5811.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5811/head:pull/5811 PR: https://git.openjdk.java.net/jdk/pull/5811

6 10

RFR: JDK-8276239: Better tables in java.util.random package summary
by Ludvig Janiuk 08 Nov '21

08 Nov '21

The tables are now striped, and they use row headers (which is a nice-to-have for accessibility). ------------- Commit messages: - Striped tables and table row headers Changes: https://git.openjdk.java.net/jdk/pull/6196/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6196&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8276239 Stats: 32 lines in 1 file changed: 0 ins; 0 del; 32 mod Patch: https://git.openjdk.java.net/jdk/pull/6196.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/6196/head:pull/6196 PR: https://git.openjdk.java.net/jdk/pull/6196

2 3

RFR: 8273235: tools/launcher/HelpFlagsTest.java Fails on Windows 32bit
by Christian Stein 08 Nov '21

08 Nov '21

This PR implements the fix as suggested by Adam Farley, which reads: > Note: Looks to be as simple as adding `jaccessinspector-32` and `jaccesswalker-32` to `TOOLS_NOT_TO_TEST` at the top of `HelpFlagsTest.java`, as the non-32bit versions are already there. ------------- Commit messages: - Ignore `jaccessinspector-32` and `jaccesswalker-32` Changes: https://git.openjdk.java.net/jdk/pull/6256/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6256&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8273235 Stats: 2 lines in 1 file changed: 2 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/6256.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/6256/head:pull/6256 PR: https://git.openjdk.java.net/jdk/pull/6256

2 3

RFR: 8274412: Add a method to Stream API to consume and close the stream without using try-with-resources
by Tagir F.Valeev 06 Nov '21

06 Nov '21

Currently, when the stream holds a resource, it's necessary to wrap it with try-with-resources. This undermines the compact and fluent style of stream API calls. For example, if we want to get the `List` of files inside the directory and timely close the underlying filehandle, we should use something like this: List<Path> paths; try (Stream<Path> stream = Files.list(Path.of("/etc"))) { paths = stream.toList(); } // use paths I suggest to add a new default method to Stream interface named `consumeAndClose`, which allows performing terminal stream operation and closing the stream at the same time. It may look like this: default <R> R consumeAndClose(Function<? super Stream<T>, ? extends R> function) { Objects.requireNonNull(function); try(this) { return function.apply(this); } } Now, it will be possible to get the list of the files in the fluent manner: List<Path> list = Files.list(Path.of("/etc")).consumeAndClose(Stream::toList); ------------- Commit messages: - Fix tests - 8274412: Add a method to Stream API to consume and close the stream without using try-with-resources Changes: https://git.openjdk.java.net/jdk/pull/5796/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5796&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8274412 Stats: 140 lines in 5 files changed: 135 ins; 0 del; 5 mod Patch: https://git.openjdk.java.net/jdk/pull/5796.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5796/head:pull/5796 PR: https://git.openjdk.java.net/jdk/pull/5796

9 13

RFR: 8276688: Remove JLinkReproducibleXXXTest from ProblemList.txt
by Jaikiran Pai 06 Nov '21

06 Nov '21

Can I please get a review for this change which removes the `JLinkReproducibleTest` and `JLinkReproducible3Test` tests from the `ProblemList.txt`? With the fix for https://bugs.openjdk.java.net/browse/JDK-8275509 now merged, I expect these tests to stop failing intermittently. I have run these tests on my Linux setup before and after the fix for JDK-8275509. Before the fix, these tests used to fail at least a few times in 50 runs each. After the fix for JDK-8275509, I've run these tests at least a 100 times each and haven't seen any failures. Having said that, I think it would be good to have someone run these a few times on a linux-aarch64 system and windows too. I don't have access to such setups. ------------- Commit messages: - 8276688: Remove JLinkReproducibleXXXTest from ProblemList.txt Changes: https://git.openjdk.java.net/jdk/pull/6272/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6272&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8276688 Stats: 2 lines in 1 file changed: 0 ins; 2 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/6272.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/6272/head:pull/6272 PR: https://git.openjdk.java.net/jdk/pull/6272

3 4