January 2021 - core-libs-dev

RFR: 8259622: TreeMap.computeIfAbsent deviates from spec
by Tagir F.Valeev 15 Jan '21

15 Jan '21

Handle TreeMap::computeIfAbsent when previous mapping with null value existed (in this case spec requires to overwrite the existing mapping) ------------- Commit messages: - 8259622: TreeMap.computeIfAbsent deviates from spec Changes: https://git.openjdk.java.net/jdk/pull/2058/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2058&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8259622 Stats: 24 lines in 2 files changed: 22 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/2058.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2058/head:pull/2058 PR: https://git.openjdk.java.net/jdk/pull/2058

2 4

[jdk16] RFR: 8254350: CompletableFuture.get may swallow InterruptedException
by Martin Buchholz 14 Jan '21

14 Jan '21

8254350: CompletableFuture.get may swallow InterruptedException ------------- Commit messages: - JDK-8254350 Changes: https://git.openjdk.java.net/jdk16/pull/17/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk16&pr=17&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8254350 Stats: 178 lines in 3 files changed: 170 ins; 5 del; 3 mod Patch: https://git.openjdk.java.net/jdk16/pull/17.diff Fetch: git fetch https://git.openjdk.java.net/jdk16 pull/17/head:pull/17 PR: https://git.openjdk.java.net/jdk16/pull/17

4 5

RFR: 8258956: Memory Leak in StringCoding on ThreadLocal resultCached StringCoding.Result
by Naoto Sato 14 Jan '21

14 Jan '21

Please review the fix to this issue. Unused thread local StringCoding.Result is now wrapped with SoftReference, which can be GC'ed as needed. I confirmed it worked as expected with a test case (https://github.com/openjdk/jdk/blob/8b4e1e1cf8f5d753ed901406f73d67b21557fdd…) but decided not to include it in this PR. This is because I purposefully chose the size of the byte array and max heap size which is fragile, and could become noise in a regression test run. ------------- Commit messages: - Removed the test case. - 8258956: Memory Leak in StringCoding on ThreadLocal resultCached StringCoding.Result Changes: https://git.openjdk.java.net/jdk/pull/2064/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2064&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8258956 Stats: 18 lines in 1 file changed: 9 ins; 0 del; 9 mod Patch: https://git.openjdk.java.net/jdk/pull/2064.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2064/head:pull/2064 PR: https://git.openjdk.java.net/jdk/pull/2064

3 3

RFR: 8253866: Security Libs Terminology Refresh
by Jamil Nimeh 14 Jan '21

14 Jan '21

This is the security libs portion of the effort to replace archaic/non-inclusive words with more neutral terms (see JDK-8253315 for details). Here are the changes covering core libraries code and tests. Terms were changed as follows: - blacklisted.certs -> blocked.certs (along with supporting make infrastructure and tests) - master/slave in KRB5 -> primary/replica - blacklist in other files -> deny list - whitelist -> allow list Addressing similar issues in upstream 3rd party code is out of scope of this PR. Such changes will be picked up from their upstream sources. ------------- Commit messages: - Merge main branch - 8253866: Security Libs Terminology Refresh Changes: https://git.openjdk.java.net/jdk/pull/2074/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2074&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8253866 Stats: 351 lines in 17 files changed: 152 ins; 150 del; 49 mod Patch: https://git.openjdk.java.net/jdk/pull/2074.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2074/head:pull/2074 PR: https://git.openjdk.java.net/jdk/pull/2074

4 6

RFR: Merge jdk16
by Jesper Wilhelmsson 14 Jan '21

14 Jan '21

Forwardport JDK 16 -> JDK 17 ------------- Commit messages: - Merge - 8259719: ProblemList runtime/cds/appcds/jigsaw/modulepath/ModulePathAndCP_JFR.java on Windows - 8259720: ProblemList java/awt/Focus/AppletInitialFocusTest/AppletInitialFocusTest1.java on Windows - 8259722: ProblemList two jdk/jfr/startupargs tests on Windows - 8231461: static/instance overload leads to 'unexpected static method found in unbound lookup' when resolving method reference - 8259063: Possible deadlock with vtable/itable creation vs concurrent class unloading - 8259657: typo in generated HELP page prevents localization - 8258272: LoadVectorMaskedNode can't be replaced by zero con - 8259560: Zero m68k: "static assertion failed: align" after JDK-8252049 - 8258985: Parallel WeakProcessor may use too few threads - ... and 11 more: https://git.openjdk.java.net/jdk/compare/c7e2174b...64cae854 The webrevs contain the adjustments done while merging with regards to each parent branch: - master: https://webrevs.openjdk.java.net/?repo=jdk&pr=2072&range=00.0 - jdk16: https://webrevs.openjdk.java.net/?repo=jdk&pr=2072&range=00.1 Changes: https://git.openjdk.java.net/jdk/pull/2072/files Stats: 991 lines in 48 files changed: 764 ins; 123 del; 104 mod Patch: https://git.openjdk.java.net/jdk/pull/2072.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2072/head:pull/2072 PR: https://git.openjdk.java.net/jdk/pull/2072

1 1

TreeMap in JDK15 deviates from spec
by Phil Smith 13 Jan '21

13 Jan '21

Hello, I submitted bug report 9068554 recently, but I consider this a pretty big issue and I'd like for this not to get lost in triage. With JDK-8176894, a specialized implementation for computeIfAbsent was added to TreeMap, however it doesn't handle null values correctly. Spec states a mapping to null is equivalent to no mapping being present, however code will `return t.value;` without checking that value. The interface default, for reference, looks like `if ((v = get(key)) == null)`. A simple repro follows TreeMap treemap = new TreeMap(); treemap.put("a", null); System.out.println(treemap.computeIfAbsent("a", key -> "default")); System.out.println(treemap.get("a")); HashMap hashmap = new HashMap(); hashmap.put("a", null); System.out.println(hashmap.computeIfAbsent("a", key -> "default")); System.out.println(hashmap.get("a")); Phil

3 2

Difference in encoding semantics of URI returned by File.toURI and Path.toUri representing the same file
by Jaikiran Pai 13 Jan '21

13 Jan '21

The java.io.File has a toURI() API which returns a (system dependent) URI as per its javadoc. The java.io.File also has a toPath() API which then exposes a toUri() API from the java.nio.file.Path. The javadoc of the File class doesn't specify any semantics about the toUri() returned by the java.nio.file.Path. More specifically, for the same file instance, is the File.toURI() and Path.toUri() expected to return a URI which has the same semantics when it comes to encoded characters in the URI? Consider the following trivial code for what I mean: import java.net.*; import java.nio.file.*; import java.io.*; public class PathTest { public static void main(final String[] args) throws Exception { final String location = args[0]; final Path a = Paths.get(location).toAbsolutePath(); System.out.println("URI from Paths.get().toUri() API " + a + " ---> " + a.toUri()); final Path b = new File(location).toPath().toAbsolutePath(); System.out.println("URI from File.toPath().toUri() API " + b + " ---> " + b.toUri()); final File c = new File(location).getAbsoluteFile(); System.out.println("URI from File.toURI() API " + c + " ---> " + c.toURI()); } } The above program prints the URI of a file path using 3 different APIs: 1. Paths.get().toUri() 2. File.toPath().toUri() 3. File.toURI() When I run the program and pass it a directory which contains a non-ascii character (which belongs to the "other" category as explained in the URI javadoc[1]) then I see that the URI returned by the Path.toUri() differs from the URI returned from the File.toURI() when it comes to encoding the "other" category character (i.e. the non-ascii character). Here's the command I use and here's the output: mkdir foobãr java PathTest foobãr Output: URI from Paths.get().toUri() API /private/tmp/delme/foobãr ---> file:///private/tmp/delme/fooba%CC%83r/ URI from File.toPath().toUri() API /private/tmp/delme/foobãr ---> file:///private/tmp/delme/fooba%CC%83r/ URI from File.toURI() API /private/tmp/delme/foobãr ---> file:/private/tmp/delme/foobãr/ Notice that the Path.toUri() version encodes the non-ascii characters whereas the File.toURI() doesn't. Is this expected? The javadoc doesn't have much details around this. Now, interestingly, the same program if passed a file path which contains a "illegal" character (for example space character as defined in[1]), then both the Path.toUri() and File.toURI() return a URI which has the character encoded. Here's the output when you run: mkdir "foo bar" java PathTest "foo bar" Output: URI from Paths.get().toUri() API /private/tmp/delme/foo bar ---> file:///private/tmp/delme/foo%20bar URI from File.toPath().toUri() API /private/tmp/delme/foo bar ---> file:///private/tmp/delme/foo%20bar URI from File.toURI() API /private/tmp/delme/foo bar ---> file:/private/tmp/delme/foo%20bar So it's not clear which categories of the characters will be (consistently) encoded by the URI returned by the Path and File instances, for the same target file. [1] https://docs.oracle.com/en/java/javase/14/docs/api/java.base/java/net/URI.h… -Jaikiran

3 3

RFR: JDK-8212035 : merge jdk.test.lib.util.SimpleHttpServer with jaxp.library.SimpleHttpServer
by Mahendra Chhipa 13 Jan '21

13 Jan '21

jaxp.library.SimpleHttpServer https://bugs.openjdk.java.net/browse/JDK-8212035 ------------- Commit messages: - JDK-8212035 merge jdk.test.lib.util.SimpleHttpServer with Changes: https://git.openjdk.java.net/jdk/pull/1632/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1632&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8212035 Stats: 276 lines in 16 files changed: 72 ins; 141 del; 63 mod Patch: https://git.openjdk.java.net/jdk/pull/1632.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1632/head:pull/1632 PR: https://git.openjdk.java.net/jdk/pull/1632

2 17

RFR: 8259319: Illegal package access when SunPKCS11 requires SunJCE's classes
by Martin Balao 12 Jan '21

12 Jan '21

As described in JDK-8259319 [1], this fix proposal is to set proper access permissions so the SunPKCS11 provider can create instances of SunJCE classes when a Security Manager is installed and the fallback scheme is used. No regressions found in jdk/sun/security/pkcs11 tests category. -- [1] - https://bugs.openjdk.java.net/browse/JDK-8259319 ------------- Commit messages: - 8259319: Illegal package access when SunPKCS11 requires SunJCE's classes Changes: https://git.openjdk.java.net/jdk/pull/1961/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1961&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8259319 Stats: 115 lines in 4 files changed: 105 ins; 0 del; 10 mod Patch: https://git.openjdk.java.net/jdk/pull/1961.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1961/head:pull/1961 PR: https://git.openjdk.java.net/jdk/pull/1961

3 11

[jdk16] RFR: 8259636: Check for buffer backed by shared segment kicks in in unexpected places
by Maurizio Cimadamore 12 Jan '21

12 Jan '21

When support for shared segment was added, we decided to disable support for buffers derived from shared segment in certain async operations, as there's currently no way to make sure that the memory won't be reclaimed while the IO operation is still taking place. After looking at the code, it seemed like the best place to put the restriction would be sun.nio.ch.DirectBuffer::address() method, since this method is used in a lot of places just before jumping into some piece of JNI code. While I still stand by that decision, the Netty team has discovered that this decision also affected operations such as creating slices from byte buffers derived from shared segment - this is caused by the fact that one direct buffer constructor (the one for views and slices) is calling the dreaded DirectBuffer::address method. The fix is simple: just avoid the method call - which is very easy to do in the case of the buffer constructor: in fact this method just returns the value of the `address` field inside the `Buffer` class, so we can always cast to `Buffer` and then access `address` field from there. ------------- Commit messages: - Tweak direct buffer slice constructor not to use DirectBuffer::address Changes: https://git.openjdk.java.net/jdk16/pull/110/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk16&pr=110&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8259636 Stats: 19 lines in 2 files changed: 18 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk16/pull/110.diff Fetch: git fetch https://git.openjdk.java.net/jdk16 pull/110/head:pull/110 PR: https://git.openjdk.java.net/jdk16/pull/110

4 5