October 2021 - core-libs-dev

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: 8274949: Use String.contains() instead of String.indexOf() in java.base
by Andrey Turbanov 19 Nov '21

19 Nov '21

String.contains was introduced in Java 5. Some code in java.base still uses old approach with `String.indexOf` to check if String contains specified substring. I propose to migrate such usages. Makes code shorter and easier to read. ------------- Commit messages: - [PATCH] Use String.contains() instead of String.indexOf() in java.base - [PATCH] Use String.contains() instead of String.indexOf() in java.base Changes: https://git.openjdk.java.net/jdk/pull/5559/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5559&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8274949 Stats: 40 lines in 17 files changed: 0 ins; 3 del; 37 mod Patch: https://git.openjdk.java.net/jdk/pull/5559.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5559/head:pull/5559 PR: https://git.openjdk.java.net/jdk/pull/5559

6 6

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: 8271515: Integration of JEP 417: Vector API (Third Incubator)
by Paul Sandoz 15 Nov '21

15 Nov '21

This PR improves the performance of vector operations that accept masks on architectures that support masking in hardware, specifically Intel AVX512 and ARM SVE. On architectures that do not support masking in hardware the same technique as before is applied to most operations, specifically composition using blend. Masked loads/stores are a special form of masked operation that require additional care to ensure out-of-bounds access throw exceptions. The range checking has not been fully optimized and will require further work. No API enhancements were required and only a few additional tests were needed. ------------- Commit messages: - Apply patch from https://github.com/openjdk/panama-vector/pull/142 - Apply patch from https://github.com/openjdk/panama-vector/pull/139 - Apply patch from https://github.com/openjdk/panama-vector/pull/151 - Add new files. - 8271515: Integration of JEP 417: Vector API (Third Incubator) Changes: https://git.openjdk.java.net/jdk/pull/5873/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5873&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8271515 Stats: 21999 lines in 106 files changed: 16228 ins; 2077 del; 3694 mod Patch: https://git.openjdk.java.net/jdk/pull/5873.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5873/head:pull/5873 PR: https://git.openjdk.java.net/jdk/pull/5873

5 28

RFR: 8273660: Propagate CNF exception in FieldValues.get via an IOException
by Roger Riggs 15 Nov '21

15 Nov '21

The ObjectInputStream.GetField method `get(String name, Object val)` should have been throwing a ClassNotFoundException if the class was not found. Instead the implementation was returning null. A design error does not allow the `get(String name, Object val)` method to throw CNFE as it should. However, an exception must be thrown to prevent invalid data from being returned. Wrapping the CNFE in IOException allows it to be thrown and the exception handled. The call to `get(String name, Object val)` is always from within a `readObject` method so the deserialization logic can catch the IOException and unwrap it to handle the CNFE. ------------- Commit messages: - 8273660: Propagate CNF exception in FieldValues.get via an IOException Changes: https://git.openjdk.java.net/jdk/pull/6053/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6053&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8273660 Stats: 112 lines in 2 files changed: 109 ins; 0 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/6053.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/6053/head:pull/6053 PR: https://git.openjdk.java.net/jdk/pull/6053

7 12

RFR (CSR): 8202555: Double.toString(double) sometimes produces incorrect results
by Raffaello Giulietti 15 Nov '21

15 Nov '21

Hello, PR [1] and the accompanying article [2] have been subject to some positive reactions in the last couple of weeks. A fresh set of about 20 thousand additional hard test cases kindly provided by Paul Zimmermann of INRIA and other tests proposed by Guy Steele have been added to the code. The corresponding CSR [3] is in Finalized state for review. The proposed spec has been carefully written to uniquely define the outcomes and the code in the PR has been extensively tested to match the proposed spec. Behavioral backward compatibility has been a major goal for the CSR. In fact, in the vast majority of cases, the CSR and the current implementation agree on the outcomes. As the CSR is a prerequisite for the advancement of the PR, I beg everybody entitled (and interested) to review and approve it and/or discuss it further. Greetings Raffaello ---- [1] https://github.com/openjdk/jdk/pull/3402 [2] https://drive.google.com/file/d/1luHhyQF9zKlM8yJ1nebU0OgVYhfC6CBN/view [3] https://bugs.openjdk.java.net/browse/JDK-8202555

1 1

RFR: 8274835: Remove unnecessary castings in java.base
by Andrey Turbanov 12 Nov '21

12 Nov '21

Redundant castings make code harder to read. Found them by IntelliJ IDEA. I tried to select only casts which are definitely safe to remove. Also didn't touch primitive types casts. ------------- Commit messages: - [PATCH] Remove unnecessary castings in java.base - [PATCH] Remove unnecessary castings in java.base Changes: https://git.openjdk.java.net/jdk/pull/5454/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5454&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8274835 Stats: 38 lines in 15 files changed: 1 ins; 4 del; 33 mod Patch: https://git.openjdk.java.net/jdk/pull/5454.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5454/head:pull/5454 PR: https://git.openjdk.java.net/jdk/pull/5454

8 7

RFR: 8275197: Remove unused fields in ThaiBuddhistChronology
by Andrey Turbanov 11 Nov '21

11 Nov '21

Remove 3 unused HashMap's. Reported here https://mail.openjdk.java.net/pipermail/core-libs-dev/2021-September/081866… I did the similar PR to treetenbp and it was merged https://github.com/ThreeTen/threetenbp/pull/155 ------------- Commit messages: - [PATCH] Remove unused fields in ThaiBuddhistChronology Changes: https://git.openjdk.java.net/jdk/pull/5917/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5917&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8275197 Stats: 37 lines in 1 file changed: 0 ins; 36 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/5917.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5917/head:pull/5917 PR: https://git.openjdk.java.net/jdk/pull/5917

4 4

RFR: 8244202: Implementation of JEP 418: Internet-Address Resolution SPI
by Aleksei Efimov 11 Nov '21

11 Nov '21

This change implements a new service provider interface for host name and address resolution, so that java.net.InetAddress API can make use of resolvers other than the platform's built-in resolver. The following API classes are added to `java.net.spi` package to facilitate this: - `InetAddressResolverProvider` - abstract class defining a service, and is, essentially, a factory for `InetAddressResolver` resolvers. - `InetAddressResolverProvider.Configuration ` - an interface describing the platform's built-in configuration for resolution operations that could be used to bootstrap a resolver construction, or to implement partial delegation of lookup operations. - `InetAddressResolver` - an interface that defines methods for the fundamental forward and reverse lookup operations. - `InetAddressResolver.LookupPolicy` - a class whose instances describe the characteristics of one forward lookup operation. More details in [JEP-418](https://openjdk.java.net/jeps/418). Testing: new and existing `tier1:tier3` tests ------------- Commit messages: - 8244202: Implementation of JEP 418: Internet-Address Resolution SPI Changes: https://git.openjdk.java.net/jdk/pull/5822/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5822&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8244202 Stats: 2779 lines in 50 files changed: 2524 ins; 134 del; 121 mod Patch: https://git.openjdk.java.net/jdk/pull/5822.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5822/head:pull/5822 PR: https://git.openjdk.java.net/jdk/pull/5822

6 48

Fix AbstractLdapNamingEnumeration next to throw NoSuchElementException instead of NullPointerException
by Andrew Luo 10 Nov '21

10 Nov '21

I have a small PR to fix a bug in AbstractLdapNamingEnumeration - details are in the PR: https://github.com/openjdk/jdk/pull/6095 (Note: I'm already an OpenJDK contributor and have signed an OCA but don't have an author account to be able to create bugs) Thanks, -Andrew

2 1