June 2021 - core-libs-dev

RFR: 8268664: The documentation of the Scanner.hasNextLine is incorrect
by Ian Graves 02 Jul '21

02 Jul '21

8268664: The documentation of the Scanner.hasNextLine is incorrect ------------- Commit messages: - Clarifying docs on Scanner.hasNextLine() regarding line separators Changes: https://git.openjdk.java.net/jdk/pull/4547/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4547&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8268664 Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/4547.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4547/head:pull/4547 PR: https://git.openjdk.java.net/jdk/pull/4547

4 4

RFR: 8188044: We need Math.unsignedMultiplyHigh
by Brian Burkhalter 02 Jul '21

02 Jul '21

Please consider this proposal to add a method `unsignedMultiplyHigh(long,long)` to each of `java.lang.Math` and `java.lang.StrictMath`. ------------- Commit messages: - 8188044: We need Math.unsignedMultiplyHigh Changes: https://git.openjdk.java.net/jdk/pull/4644/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4644&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8188044 Stats: 72 lines in 3 files changed: 62 ins; 0 del; 10 mod Patch: https://git.openjdk.java.net/jdk/pull/4644.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4644/head:pull/4644 PR: https://git.openjdk.java.net/jdk/pull/4644

9 21

[jdk17] RFR: 8269543: The warning for System::setSecurityManager should only appear once for each caller
by Weijun Wang 02 Jul '21

02 Jul '21

Add a cache to record which source has called `System::setSecurityManager` and only print out warning lines once for each. ------------- Commit messages: - renaming variables, two callers in test - one warning for each caller Changes: https://git.openjdk.java.net/jdk17/pull/166/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk17&pr=166&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8269543 Stats: 47 lines in 2 files changed: 34 ins; 0 del; 13 mod Patch: https://git.openjdk.java.net/jdk17/pull/166.diff Fetch: git fetch https://git.openjdk.java.net/jdk17 pull/166/head:pull/166 PR: https://git.openjdk.java.net/jdk17/pull/166

8 15

[jdk17] RFR: 8268566: java/foreign/TestResourceScope.java timed out
by Maurizio Cimadamore 01 Jul '21

01 Jul '21

This patch contains another minor tweak to TestResourceScope as we have seen this test timing out at least once (on arm64). I realized that some of the logic recently introduced in the test could lead to the test waiting forever: for instance, if all threads are executed right away before the main thread gets a chance to do anything, we'd be in a state where the lock count is zero, and no other thread will update it. I've removed the while loop - as that's not essential to make sure that the test works (what we want is to trigger a close operation that is concurrent with respect some acquire/release). I've also lowered the number of threads - which was using 10K - that was good for stress testing, but it's not a good number in more realistic conditions. ------------- Commit messages: - * Remove wait from test Changes: https://git.openjdk.java.net/jdk17/pull/45/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk17&pr=45&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8268566 Stats: 5 lines in 1 file changed: 0 ins; 4 del; 1 mod Patch: https://git.openjdk.java.net/jdk17/pull/45.diff Fetch: git fetch https://git.openjdk.java.net/jdk17 pull/45/head:pull/45 PR: https://git.openjdk.java.net/jdk17/pull/45

2 2

[jdk17] RFR: 8269704: Typo in j.t.Normalizer.normalize()
by Naoto Sato 01 Jul '21

01 Jul '21

A trivial typo fix. ------------- Commit messages: - 8269704: Typo in j.t.Normalizer.normalize() Changes: https://git.openjdk.java.net/jdk17/pull/187/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk17&pr=187&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8269704 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk17/pull/187.diff Fetch: git fetch https://git.openjdk.java.net/jdk17 pull/187/head:pull/187 PR: https://git.openjdk.java.net/jdk17/pull/187

4 4

RFR: 6766844: ByteArrayInputStream#read with a byte array of length 0 not consistent with InputStream when at EOF
by Brian Burkhalter 30 Jun '21

30 Jun '21

Modify `java.io.ByteArrayInputStream` methods `read(byte[])` and `read(byte[],int,int)` to return zero per the `InputStream` specification when the byte array actual or specified length is zero. ------------- Commit messages: - 6766844: ByteArrayInputStream#read with a byte array of length 0 not consistent with InputStream when at EOF Changes: https://git.openjdk.java.net/jdk/pull/4591/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4591&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-6766844 Stats: 16 lines in 2 files changed: 11 ins; 1 del; 4 mod Patch: https://git.openjdk.java.net/jdk/pull/4591.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4591/head:pull/4591 PR: https://git.openjdk.java.net/jdk/pull/4591

5 20

[jdk17] RFR: JDK-8262841: Clarify the behavior of PhantomReference::refersTo
by Mandy Chung 30 Jun '21

30 Jun '21

`Reference::refersTo` behaves the same for soft, weak, and phantom references whereas `PhantomReference::get` always returns `null` which is different than soft and weak references. This patch clarifies the specification of `PhantomReference` to make it clear that `refersTo` can be used for phantom references. With `refersTo`, phantom references if not registered in a reference queue are not completely useless. Update the javadoc of the constructor to reflect that. I created a CSR to document this spec clarification: https://bugs.openjdk.java.net/browse/JDK-8269688 ------------- Commit messages: - JDK-8262841: Behavior of PhantomReference.refersTo is not well documented Changes: https://git.openjdk.java.net/jdk17/pull/181/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk17&pr=181&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8262841 Stats: 5 lines in 1 file changed: 2 ins; 2 del; 1 mod Patch: https://git.openjdk.java.net/jdk17/pull/181.diff Fetch: git fetch https://git.openjdk.java.net/jdk17 pull/181/head:pull/181 PR: https://git.openjdk.java.net/jdk17/pull/181

3 3

[jdk17] RFR: 8269513: Clarify the spec wrt `useOldISOCodes` system property
by Naoto Sato 30 Jun '21

30 Jun '21

Please review this small doc change to the system property. Accompanying CSR has also been created. ------------- Commit messages: - 8269513: Clarify the spec wrt `useOldISOCodes` system property Changes: https://git.openjdk.java.net/jdk17/pull/163/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk17&pr=163&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8269513 Stats: 3 lines in 1 file changed: 2 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk17/pull/163.diff Fetch: git fetch https://git.openjdk.java.net/jdk17 pull/163/head:pull/163 PR: https://git.openjdk.java.net/jdk17/pull/163

5 14

[jdk17] RFR: 8269486: CallerAccessTest fails for non server variant
by Christoph Göttschkes 30 Jun '21

30 Jun '21

Hi, please review this small fix. The test case uses a custom launcher and before launching the JVM, it adds the "lib" and "lib/server" directories to the environment variable which controls the native library search path. For non server variants, the second directory is not called "lib/server", but "lib/client", for instance. I changed the test case to use the utility methods in `Platform` to get the correct paths, dependent on the VM variant. ------------- Commit messages: - 8269486: CallerAccessTest fails for non server variant Changes: https://git.openjdk.java.net/jdk17/pull/159/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk17&pr=159&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8269486 Stats: 6 lines in 1 file changed: 0 ins; 3 del; 3 mod Patch: https://git.openjdk.java.net/jdk17/pull/159.diff Fetch: git fetch https://git.openjdk.java.net/jdk17 pull/159/head:pull/159 PR: https://git.openjdk.java.net/jdk17/pull/159

6 10

RFR: 8268457: XML Transformer outputs Unicode supplementary character incorrectly to HTML
by Masanori Yano 30 Jun '21

30 Jun '21

Hi all, Could you please review the 8268457 bug fixes? The problem is that ToHTMLStream applies processing for non-surrogate pairs to the surrogate pair. This fix changes the processing for non-surrogate pairs to the else condition. ------------- Commit messages: - clean up whitespace - 8268457: XML Transformer outputs Unicode supplementary character incorrectly to HTML Changes: https://git.openjdk.java.net/jdk/pull/4474/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4474&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8268457 Stats: 235 lines in 7 files changed: 223 ins; 9 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/4474.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4474/head:pull/4474 PR: https://git.openjdk.java.net/jdk/pull/4474

5 15