June 2021 - core-libs-dev

[jdk17] RFR: JDK-8266313 (JEP-356) - RandomGenerator spec implementation requirements tightly coupled to JDK internal classes
by Jim Laskey 14 Jul '21

14 Jul '21

The wording of the @implSpec referred to internal methods in the description. The patch rewords the @implSpec to be more descriptive of the algorithm than the methods used. ------------- Commit messages: - non-infinite to finite - Use limiting - Remove use of clamping - Merge branch 'master' of https://github.com/openjdk/jdk17 into 8266313 - Javadoc changes Changes: https://git.openjdk.java.net/jdk17/pull/151/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk17&pr=151&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8266313 Stats: 51 lines in 2 files changed: 22 ins; 4 del; 25 mod Patch: https://git.openjdk.java.net/jdk17/pull/151.diff Fetch: git fetch https://git.openjdk.java.net/jdk17 pull/151/head:pull/151 PR: https://git.openjdk.java.net/jdk17/pull/151

2 9

RFR: 8268698: Use Objects.check{Index, FromToIndex, FromIndexSize} where possible
by Yi Yang 13 Jul '21

13 Jul '21

After JDK-8265518, it's possible to replace all variants of checkIndex by Objects.checkIndex/Objects.checkFromToIndex/Objects.checkFromIndexSize in the whole JDK codebase. ------------- Commit messages: - use checkIndex globally Changes: https://git.openjdk.java.net/jdk/pull/4507/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4507&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8268698 Stats: 206 lines in 34 files changed: 31 ins; 111 del; 64 mod Patch: https://git.openjdk.java.net/jdk/pull/4507.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4507/head:pull/4507 PR: https://git.openjdk.java.net/jdk/pull/4507

8 42

RFR: 8266578: Disambiguate BigDecimal description of scale
by Ignasi Marimon-Clos 12 Jul '21

12 Jul '21

The API Docs for `BigDecimal` introduce the meaning of `scale`. The current writeup can be missleading when presenting the meaning of a `scale` value that's negative. Hopefully, with this PR, the sentence is more clear. The ambiguity is on this sentence: > If negative, the unscaled value of the number is ... Instead, I suggest the more verbose: > If the scale is negative, the unscaled value of the number is ... To keep symmetry, I've also reviewed the positive case from: > If zero or positive, the scale is the number of digits ... to: > If the scale is zero or positive, the scale is the number of digits ... ------------- Commit messages: - Merge branch 'master' into minor-disambiguation - Disambiguate the BigDecimal docs Changes: https://git.openjdk.java.net/jdk/pull/582/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=582&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8266578 Stats: 6 lines in 1 file changed: 1 ins; 0 del; 5 mod Patch: https://git.openjdk.java.net/jdk/pull/582.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/582/head:pull/582 PR: https://git.openjdk.java.net/jdk/pull/582

4 14

[jdk17] RFR: JDK-8268826: Cleanup Override in Context-Specific Deserialization Filters
by Roger Riggs 09 Jul '21

09 Jul '21

Remove the unnecessary special case "OVERRIDE" in jdk.serialFilterFactory property. Fix description in the example of a filter allowing platform classes. Suppress some warnings about use of SecurityManager in tests. ------------- Commit messages: - JDK-8268827: Cleanup Implement Context-Specific Deserialization Filters Changes: https://git.openjdk.java.net/jdk17/pull/85/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk17&pr=85&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8268826 Stats: 29 lines in 4 files changed: 10 ins; 13 del; 6 mod Patch: https://git.openjdk.java.net/jdk17/pull/85.diff Fetch: git fetch https://git.openjdk.java.net/jdk17 pull/85/head:pull/85 PR: https://git.openjdk.java.net/jdk17/pull/85

3 18

[jdk17] RFR: 6766844: ByteArrayInputStream#read with a byte array of length 0 not consistent with InputStream when at EOF
by Brian Burkhalter 08 Jul '21

08 Jul '21

Modify the specification of `java.io.ByteArrayInputStream#read(byte[],int,int)` to indicate that `-1` is returned instead of `0` when the stream is at its end and the third parameter, `len`, 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/jdk17/pull/189/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk17&pr=189&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-6766844 Stats: 18 lines in 2 files changed: 12 ins; 1 del; 5 mod Patch: https://git.openjdk.java.net/jdk17/pull/189.diff Fetch: git fetch https://git.openjdk.java.net/jdk17 pull/189/head:pull/189 PR: https://git.openjdk.java.net/jdk17/pull/189

4 14

[jdk17] RFR: 8268766: Desugaring of pattern matching enum switch should be improved
by Jan Lahoda 08 Jul '21

08 Jul '21

Currently, an enum switch with patterns is desugared in a very non-standard, and potentially slow, way. It would be better to use the standard `typeSwitch` bootstrap to classify the enum constants. The bootstrap needs to accept enum constants as labels in order to allow this. A complication is that if an enum constant is missing, that is not an incompatible change for the switch, and the switch should simply work as if the case for the missing constant didn't exist. So, the proposed solution is to have a new bootstrap `enumConstant` that converts the enum constant name to the enum constant, returning `null`, if the constant does not exist. It delegates to `ConstantBootstraps.enumConstant` to do the actual conversion. And `typeSwitch` accepts `null`s as padding. How does this look? ------------- Commit messages: - Adding and fixing test. - Merging master. - 8268766: Desugaring of pattern matching enum switch should be improved Changes: https://git.openjdk.java.net/jdk17/pull/81/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk17&pr=81&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8268766 Stats: 313 lines in 6 files changed: 165 ins; 76 del; 72 mod Patch: https://git.openjdk.java.net/jdk17/pull/81.diff Fetch: git fetch https://git.openjdk.java.net/jdk17 pull/81/head:pull/81 PR: https://git.openjdk.java.net/jdk17/pull/81

5 29

RFR: 8266407: remove jdk.internal.javac.PreviewFeature.Feature.SEALED_CLASSES
by Vicente Romero 06 Jul '21

06 Jul '21

Enum constant: jdk.internal.javac.PreviewFeature.Feature.SEALED_CLASSES was not removed when Sealed Classes were made final because the build was failing without it. Now that the feature is final we should be able to safely removed it. This is the intention of this patch. TIA, Vicente ------------- Commit messages: - 8266407: remove jdk.internal.javac.PreviewFeature.Feature.SEALED_CLASSES Changes: https://git.openjdk.java.net/jdk/pull/4578/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4578&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8266407 Stats: 4 lines in 1 file changed: 0 ins; 4 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/4578.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4578/head:pull/4578 PR: https://git.openjdk.java.net/jdk/pull/4578

2 2

[jdk17] RFR: JDK-8225667: Clarify the behavior of System::gc w.r.t. reference processing
by Mandy Chung 06 Jul '21

06 Jul '21

This spec clarification is a follow-up to [JDK-8224760](https://bugs.openjdk.java.net/browse/JDK-8224760?focusedCommen… w.r.t. reference processing. Since there is no guarantee for any memory reclamation by the invocation of `System::gc`, the spec should also clarify that there is no guarantee in determining the change of reachability of any objects or any particular number of `Reference` objects be enqueued and cleared. CSR: https://bugs.openjdk.java.net/browse/JDK-8269690 ------------- Commit messages: - JDK-8225667: Clarify the behavior of System::gc w.r.t. reference processing Changes: https://git.openjdk.java.net/jdk17/pull/183/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk17&pr=183&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8225667 Stats: 9 lines in 2 files changed: 9 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk17/pull/183.diff Fetch: git fetch https://git.openjdk.java.net/jdk17 pull/183/head:pull/183 PR: https://git.openjdk.java.net/jdk17/pull/183

5 12

RFR: 8266310: deadlock while loading the JNI code
by Aleksei Voitylov 06 Jul '21

06 Jul '21

Please review this PR which fixes the deadlock in ClassLoader between the two lock objects - a lock object associated with the class being loaded, and the ClassLoader.loadedLibraryNames hash map, locked during the native library load operation. Problem being fixed: The initial reproducer demonstrated a deadlock between the JarFile/ZipFile and the hash map. That deadlock exists even when the ZipFile/JarFile lock is removed because there's another lock object in the class loader, associated with the name of the class being loaded. Such objects are stored in ClassLoader.parallelLockMap. The deadlock occurs when JNI_OnLoad() loads exactly the same class, whose signature is being verified in another thread. Proposed fix: The proposed patch suggests to get rid of locking loadedLibraryNames hash map and synchronize on each entry name, as it's done with class names in see ClassLoader.getClassLoadingLock(name) method. The patch introduces nativeLibraryLockMap which holds the lock objects for each library name, and the getNativeLibraryLock() private method is used to lazily initialize the corresponding lock object. nativeLibraryContext was changed to ThreadLocal, so that in any concurrent thread it would have a NativeLibrary object on top of the stack, that's being currently loaded/unloaded in that thread. nativeLibraryLockMap accumulates the names of all native libraries loaded - in line with class loading code, it is not explicitly cleared. Testing: jtreg and jck testing with no regressions. A new regression test was developed. ------------- Commit messages: - JDK-8266310: deadlock while loading the JNI code - JDK-8266310: deadlock while loading the JNI code Changes: https://git.openjdk.java.net/jdk/pull/3976/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3976&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8266310 Stats: 475 lines in 6 files changed: 456 ins; 0 del; 19 mod Patch: https://git.openjdk.java.net/jdk/pull/3976.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3976/head:pull/3976 PR: https://git.openjdk.java.net/jdk/pull/3976

11 60

RFR: 8269124: Update java.time to use switch expressions (part II)
by Patrick Concannon 05 Jul '21

05 Jul '21

Hi, Could someone please review the second half of my update for the `java.time` package to make use of switch expressions? This PR was split into two parts due to the large number of files affected. Kind regards,  Patrick ------------- Commit messages: - 8269124: Update java.time to use switch expressions (part II) Changes: https://git.openjdk.java.net/jdk/pull/4552/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4552&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8269124 Stats: 359 lines in 16 files changed: 0 ins; 48 del; 311 mod Patch: https://git.openjdk.java.net/jdk/pull/4552.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4552/head:pull/4552 PR: https://git.openjdk.java.net/jdk/pull/4552

7 26