September 2021 - core-libs-dev

RFR: 8274544: Langtools command's usage were grabled on Japanese Windows
by Ichiroh Takiguchi 22 Nov '21

22 Nov '21

JEP-400 (UTF-8 by Default) was eabled on JDK18-b13. After JDK18-b13, javac and some other langtool command's usage were garbled on Japanese Windows. These commands use PrintWriter instead of standard out/err with PrintStream. ------------- Commit messages: - Langtools command's usage were grabled on Japanese Windows Changes: https://git.openjdk.java.net/jdk/pull/5771/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5771&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8274544 Stats: 35 lines in 2 files changed: 34 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/5771.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5771/head:pull/5771 PR: https://git.openjdk.java.net/jdk/pull/5771

6 48

RFR: 8274333: Redundant null comparison after Pattern.split
by Andrey Turbanov 19 Nov '21

19 Nov '21

In couple of classes, result part of arrays of Pattern.split is compared with `null`. Pattern.split (and hence String.split) never returns `null` in array elements. Such comparisons are redundant. ------------- Commit messages: - [PATCH] Remove redundant 'null' comparison after Pattern.split Changes: https://git.openjdk.java.net/jdk/pull/5708/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5708&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8274333 Stats: 15 lines in 2 files changed: 4 ins; 5 del; 6 mod Patch: https://git.openjdk.java.net/jdk/pull/5708.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5708/head:pull/5708 PR: https://git.openjdk.java.net/jdk/pull/5708

6 5

RFR: 8271820: Implementation of JEP 416: Reimplement Core Reflection with Method Handle
by Mandy Chung 16 Nov '21

16 Nov '21

This reimplements core reflection with method handles. For `Constructor::newInstance` and `Method::invoke`, the new implementation uses `MethodHandle`. For `Field` accessor, the new implementation uses `VarHandle`. For the first few invocations of one of these reflective methods on a specific reflective object we invoke the corresponding method handle directly. After that we spin a dynamic bytecode stub defined in a hidden class which loads the target `MethodHandle` or `VarHandle` from its class data as a dynamically computed constant. Loading the method handle from a constant allows JIT to inline the method-handle invocation in order to achieve good performance. The VM's native reflection methods are needed during early startup, before the method-handle mechanism is initialized. That happens soon after System::initPhase1 and before System::initPhase2, after which we switch to using method handles exclusively. The core reflection and method handle implementation are updated to handle chained caller-sensitive method calls [1] properly. A caller-sensitive method can define with a caller-sensitive adapter method that will take an additional caller class parameter and the adapter method will be annotated with `@CallerSensitiveAdapter` for better auditing. See the detailed description from [2]. Ran tier1-tier8 tests. [1] https://bugs.openjdk.java.net/browse/JDK-8013527 [2] https://bugs.openjdk.java.net/browse/JDK-8271820?focusedCommentId=14439430&… ------------- Commit messages: - fix whitespace - Merge branch 'master' of https://github.com/openjdk/jdk into reimplement-method-invoke - Merge branch 'master' of https://github.com/openjdk/jdk into reimplement-method-invoke - Merge - clean up test - Merge branch 'master' of https://github.com/openjdk/jdk into reimplement-method-invoke - cleanup - Merge branch 'master' of https://github.com/openjdk/jdk into reimplement-method-invoke - fix ClassByteBuilder to handle short field type properly. Support volatile fields - minor cleanup - ... and 5 more: https://git.openjdk.java.net/jdk/compare/cb368802...c575c3db Changes: https://git.openjdk.java.net/jdk/pull/5027/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5027&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8271820 Stats: 7572 lines in 75 files changed: 7103 ins; 288 del; 181 mod Patch: https://git.openjdk.java.net/jdk/pull/5027.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5027/head:pull/5027 PR: https://git.openjdk.java.net/jdk/pull/5027

15 92

RFR: 8250678: ModuleDescriptor.Version parsing treats empty segments inconsistently
by Masanori Yano 09 Nov '21

09 Nov '21

Could you please review the 8250678 bug fixes? The `parse` method of ModuleDescriptor.Version class behaves incorrectly when the input string contains consecutive delimiters. The `parse` method treats strings as three sections, but the parsing method differs between the method for the version sections and the ones for others. In version sections, the `parse` method takes a single character in a loop and determines whether it is a delimiter. In pre and build sections, the parse method takes two characters in a loop and determines whether the second character is the delimiter. Therefore, if the string contains a sequence of delimiters in pre or build section, the `parse` method treats character at the odd-numbered position as a token and the one at even-numbered as a delimiter. A string containing consecutive delimiters is an incorrect version string, but this behavior does not follow the API specification. https://download.java.net/java/early_access/jdk18/docs/api/java.base/java/l… Therefore, I propose to fix the parsing method of pre and build section in the same way as the version. ------------- Commit messages: - 8250678: ModuleDescriptor.Version parsing treats empty segments inconsistently Changes: https://git.openjdk.java.net/jdk/pull/5679/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5679&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8250678 Stats: 26 lines in 2 files changed: 11 ins; 14 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/5679.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5679/head:pull/5679 PR: https://git.openjdk.java.net/jdk/pull/5679

4 17

RFR: JDK-8272192 Shortcut String equality checks by checking equality of the value array
by q2q-2q2 02 Nov '21

02 Nov '21

Shortcut String equality checks by checking equality of the value array ------------- Commit messages: - JDK-8272192 Changes: https://git.openjdk.java.net/jdk/pull/5370/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5370&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8272192 Stats: 62 lines in 3 files changed: 60 ins; 1 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/5370.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5370/head:pull/5370 PR: https://git.openjdk.java.net/jdk/pull/5370

5 5

RFR: 8153490: Cannot setBytes() if incoming buffer's length is bigger than number of elements we want to insert.
by Mitsuru Kariya 28 Oct '21

28 Oct '21

Fix `SerialBlob.setBytes(long pos, byte[] bytes, int offset, int length)` in the following cases: 1. `pos - 1 + bytes.length - offset > this.length() && pos - 1 + length <= this.length()` The original implementation throws `ArrayIndexOutOfBoundsException` but this case should end successfully. (test31) 2. `pos - 1 + length > this.length()` The original implementation throws `ArrayIndexOutOfBoundsException` but this case should end successfully. *1 (test32) 3. `pos == this.length() + 1` The original implementation throws `SerialException` but this case should end successfully. *2 (test33) Additionally, fix `SerialClob.setString(long pos, String str, int offset, int length)` in the following cases: 1. `offset > str.length()` The original implementaion throws `StringIndexOutOfBoundsException` but this case should throw `SerialException`. (test39) 2. `pos - 1 + str.length() - offset > this.length() && pos - 1 + length <= this.length()` The original implementation throws `ArrayIndexOutOfBoundsException` but this case should end successfully. (test32) 3. `pos - 1 + length > this.length()` The original implementaion throws `SerialException` but this case should end successfully. *3 (test40) 4. `pos == this.length() + 1` The original implementaion throws `SerialException` but this case should end successfully. *4 (test41) The javadoc has also been modified according to the above. *1 The documentation of `Blob.setBytes()` says, "If the end of the Blob value is reached while writing the array of bytes, then the length of the Blob value will be increased to accommodate the extra bytes." *2 The documentation of `Blob.setBytes()` says, "If the value specified for pos is greater than the length+1 of the BLOB value then the behavior is undefined." So, it should work correctly when pos == length+1 of the BLOB value. *3 The documentation of `Clob.setString()` says, "If the end of the Clob value is eached while writing the given string, then the length of the Clob value will be increased to accommodate the extra characters." *4 The documentation of `Clob.setString()` says, "If the value specified for pos is greater than the length+1 of the CLOB value then the behavior is undefined." So, it should work correctly when pos == length+1 of the CLOB value. ------------- Commit messages: - 8153490:Cannot setBytes() if incoming buffer's length is bigger than number of elements we want to insert. Changes: https://git.openjdk.java.net/jdk/pull/4001/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4001&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8153490 Stats: 179 lines in 4 files changed: 122 ins; 17 del; 40 mod Patch: https://git.openjdk.java.net/jdk/pull/4001.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4001/head:pull/4001 PR: https://git.openjdk.java.net/jdk/pull/4001

5 24

RFR: 8233674: JarURLConnection.getJarFile throws Exception if some process is holding the file
by Masanori Yano 28 Oct '21

28 Oct '21

Could you please review the 8233674 bug fixes? This problem is caused by the antivirus software opening the file for a short time, so CreateFile() should be retried. ------------- Commit messages: - 8233674: JarURLConnection.getJarFile throws Exception if some process is holding the file Changes: https://git.openjdk.java.net/jdk/pull/5460/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5460&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8233674 Stats: 299 lines in 3 files changed: 261 ins; 12 del; 26 mod Patch: https://git.openjdk.java.net/jdk/pull/5460.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5460/head:pull/5460 PR: https://git.openjdk.java.net/jdk/pull/5460

2 10

RFR: 8268788: Annotations with lambda expressions can still cause AnnotationFormatError
by Sergei Ustimenko 22 Oct '21

22 Oct '21

Change #3294 helps to avoid `AnnotaionFormatException` in `sun.reflect.annotation.AnnotationInvocationHandler.validateAnnotationMethods`. While it fixes the case with e.g. `Runnable` that generates the synthetic method without parameters, validation still fails on synthetic methods that have parameters e.g. `Function`, `BiFunction`, etc. This change removes the restriction on parameters count to be zero i.e. lambdas with parameters would be skipped from validation. ------------- Commit messages: - 8268788: Annotations with lambda expressions can still cause AnnotationFormatError Changes: https://git.openjdk.java.net/jdk/pull/4642/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4642&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8268788 Stats: 8 lines in 2 files changed: 5 ins; 1 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/4642.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4642/head:pull/4642 PR: https://git.openjdk.java.net/jdk/pull/4642

5 9

RFR: 8273111: Default timezone should return zone ID if /etc/localtime is valid but not canonicalization on linux
by Wu Yan 22 Oct '21

22 Oct '21

Hi, Please help me review the change to enhance getting time zone ID from /etc/localtime on linux. We use `realpath` instead of `readlink` to obtain the link name of /etc/localtime, because `readlink` can only read the value of a symbolic of link, not the canonicalized absolute pathname. For example, the value of /etc/localtime is "../usr/share/zoneinfo//Asia/Shanghai", then the linkbuf obtained by `readlink` is "../usr/share/zoneinfo//Asia/Shanghai", and then the call of `getZoneName(linkbuf)` will get "/Asia/Shanghai", not "Asia/Shanghai", which consider as invalid in `ZoneInfoFile.getZoneInfo()`. Using `realpath`, you can get “/usr/share/zoneinfo/Asia/Shanghai“ directly from “/etc/localtime“. Thanks, wuyan ------------- Commit messages: - 8273111: Default timezone should return zone ID if /etc/localtime is valid but not canonicalization on linux Changes: https://git.openjdk.java.net/jdk/pull/5327/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5327&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8273111 Stats: 10 lines in 1 file changed: 2 ins; 1 del; 7 mod Patch: https://git.openjdk.java.net/jdk/pull/5327.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5327/head:pull/5327 PR: https://git.openjdk.java.net/jdk/pull/5327

5 21

RFR: 8270380: Change the default value of the java.security.manager system property to disallow
by Weijun Wang 21 Oct '21

21 Oct '21

This change modifies the default value of the `java.security.manager` system property from "allow" to "disallow". This means unless it's explicitly set to "allow", any call to `System.setSecurityManager()` would throw an UOE. The `AllowSecurityManager.java` and `SecurityManagerWarnings.java` tests are updated to confirm this behavior change. Two other tests are updated because they were added after JDK-8267184 and do not have `-Djava.security.manager=allow` on its `@run` line even it they need to install one at runtime. ------------- Commit messages: - 8270380: Change the default value of the java.security.manager system property to disallow Changes: https://git.openjdk.java.net/jdk/pull/5204/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5204&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8270380 Stats: 24 lines in 6 files changed: 3 ins; 8 del; 13 mod Patch: https://git.openjdk.java.net/jdk/pull/5204.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5204/head:pull/5204 PR: https://git.openjdk.java.net/jdk/pull/5204

8 20