March 2021 - core-libs-dev

RFR: 8173970: jar tool should have a way to extract to a directory
by Jaikiran Pai 13 Nov '25

13 Nov '25

Can I please get a review for this patch which proposes to implement the enhancement request noted in https://bugs.openjdk.java.net/browse/JDK-8173970? The commit in this PR introduces the `-o` and `--output-dir` option to the `jar` command. The option takes a path to a destination directory as a value and extracts the contents of the jar into that directory. This is an optional option and the changes in the commit continue to maintain backward compatibility where the jar is extracted into current directory, if no `-o` or `--output-dir` option has been specified. As far as I know, there hasn't been any discussion on what the name of this new option should be. I was initially thinking of using `-d` but that is currently used by the `jar` command for a different purpose. So I decided to use `-o` and `--output-dir`. This is of course open for change depending on any suggestions in this PR. The commit in this PR also updates the `jar.properties` file which contains the English version of the jar command's `--help` output. However, no changes have been done to the internationalization files corresponding to this one (for example: `jar_de.properties`), because I don't know what process needs to be followed to have those files updated (if at all they need to be updated). The commit also includes a jtreg testcase which verifies the usage of this new option. ------------- Commit messages: - 8173970: jar tool should have a way to extract to a directory Changes: https://git.openjdk.java.net/jdk/pull/2752/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2752&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8173970 Stats: 268 lines in 4 files changed: 262 ins; 0 del; 6 mod Patch: https://git.openjdk.java.net/jdk/pull/2752.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2752/head:pull/2752 PR: https://git.openjdk.java.net/jdk/pull/2752

13 61

Method references in annotations
by Julian Ruppel 04 Apr '24

04 Apr '24

Hi, being aware that there has been a discussion quite some time ago ( http://mail.openjdk.java.net/pipermail/lambda-dev/2011-August/003768.html) I wanted to come up again with this topic as this feature would be beneficial especially for framework developers who wants to appoint behaviour to annotations. The following snippet shows what I want to vote for. @MyAnnotation(method = MyClass::myMethod)private String myVariable; This would be far more type-safe compared to using string literals to find the method via reflection. - Julian

2 2

RFR: 8263135: unique_ptr should not be used for types that are not pointers
by Yasumasa Suenaga 25 Aug '23

25 Aug '23

I saw error during jpackage compilation with VS 2019 (16.9.0) as following (on Japanese locale): c:\progra~2\micros~2\2019\commun~1\vc\tools\msvc\1428~1.299\include\utility(604): error C2440: '=': '_Other' から '_Ty' に変換できません。 with [ _Other=nullptr ] and [ _Ty=unsigned long ] c:\progra~2\micros~2\2019\commun~1\vc\tools\msvc\1428~1.299\include\utility(604): note: ネイティブの nullptr はブールに変換するか、または reinterpret_cast を使用して整数型に変換することのみが可能です c:\progra~2\micros~2\2019\commun~1\vc\tools\msvc\1428~1.299\include\memory(3423): note: コンパイル対象の関数テンプレートインスタンス化 '_Ty std::exchange<_Ty2,nullptr>(_Ty &,_Other &&) noexcept(false)' のリファレンスを確認してください with [ _Ty=unsigned long, _Ty2=unsigned long, _Other=nullptr ] c:\progra~2\micros~2\2019\commun~1\vc\tools\msvc\1428~1.299\include\memory(3422): note: クラステンプレートメンバー関数 'unsigned long std::unique_ptr<MSIHANDLE,msi::MsiHandleDeleter>::release(void) noexcept' のコンパイル中 d:\github-forked\jdk\src\jdk.jpackage\windows\native\common\MsiDb.cpp(237): note: コンパイル対象の関数テンプレートインスタンス化 'unsigned long std::unique_ptr<MSIHANDLE,msi::MsiHandleDeleter>::release(void) noexcept' のリファレンスを確認してください d:\github-forked\jdk\src\jdk.jpackage\windows\native\common\MsiDb.h(119): note: コンパイル対象のクラステンプレートインスタンス化 'std::unique_ptr<MSIHANDLE,msi::MsiHandleDeleter>' のリファレンスを確認してください `UniqueMSIHANDLE` is declared in MsiUtils.h as `unique_ptr` for `MSIHANDLE`. `MSIHANDLE` seems to be declared as synonym for `unsigned long`, not a pointer type. I think `MSIHANDLE` does not need to handle as `unique_ptr` if it releases at d'tor of the class which holds it (`Database`, `DatabaseRecord`). ------------- Commit messages: - 8263135: unique_ptr should not be used for types that are not pointers Changes: https://git.openjdk.java.net/jdk/pull/2858/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2858&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8263135 Stats: 77 lines in 4 files changed: 14 ins; 36 del; 27 mod Patch: https://git.openjdk.java.net/jdk/pull/2858.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2858/head:pull/2858 PR: https://git.openjdk.java.net/jdk/pull/2858

5 8

Re: RFR: 8252204: AArch64: Implement SHA3 accelerator/intrinsic [v11]
by Fei Yang 02 Aug '23

02 Aug '23

> Contributed-by: ard.biesheuvel(a)linaro.org, dongbo4(a)huawei.com > > This added an intrinsic for SHA3 using aarch64 v8.2 SHA3 Crypto Extensions. > Reference implementation for core SHA-3 transform using ARMv8.2 Crypto Extensions: > https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/arch/… > > Trivial adaptation in SHA3. implCompress is needed for the purpose of adding the intrinsic. > For SHA3, we need to pass one extra parameter "digestLength" to the stub for the calculation of block size. > "digestLength" is also used in for the EOR loop before keccak to differentiate different SHA3 variants. > > We added jtreg tests for SHA3 and used QEMU system emulator which supports SHA3 instructions to test the functionality. > Patch passed jtreg tier1-3 tests with QEMU system emulator. > Also verified with jtreg tier1-3 tests without SHA3 instructions on aarch64-linux-gnu and x86_64-linux-gnu, to make sure that there's no regression. > > We used one existing JMH test for performance test: test/micro/org/openjdk/bench/java/security/MessageDigests.java > We measured the performance benefit with an aarch64 cycle-accurate simulator. > Patch delivers 20% - 40% performance improvement depending on specific SHA3 digest length and size of the message. > > For now, this feature will not be enabled automatically for aarch64. We can auto-enable this when it is fully tested on real hardware. But for the above testing purposes, this is auto-enabled when the corresponding hardware feature is detected. Fei Yang has updated the pull request incrementally with one additional commit since the last revision: Add if (isJDK16OrHigher()) check for SHA3 in CheckGraalIntrinsics.java ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/207/files - new: https://git.openjdk.java.net/jdk/pull/207/files/d32c8ad7..b43f9197 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=207&range=10 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=207&range=09-10 Stats: 4 lines in 1 file changed: 3 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/207.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/207/head:pull/207 PR: https://git.openjdk.java.net/jdk/pull/207

4 5

RFR: 8245527: LDAP Channel Binding support for Java GSS/Kerberos
by Alexey Bakhtin 01 Aug '22

01 Aug '22

Hi, Plaese review JDK-8245527 fix which implements LDAP Channel Binding support for Java GSS/Kerberos. Initial review is available at core-devs: https://mail.openjdk.java.net/pipermail/core-libs-dev/2020-August/068197.ht… This version removes "tls-unique" CB type from the list of possible channel binding types. The only supported type is "tls-server-end-point" CSR is also updated : https://bugs.openjdk.java.net/browse/JDK-8247311 Thank you Alexey ------------- Commit messages: - 8245527: LDAP Channel Binding support for Java GSS/Kerberos Changes: https://git.openjdk.java.net/jdk/pull/278/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=278&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8245527 Stats: 536 lines in 10 files changed: 524 ins; 0 del; 12 mod Patch: https://git.openjdk.java.net/jdk/pull/278.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/278/head:pull/278 PR: https://git.openjdk.java.net/jdk/pull/278

5 13

RFR: 8257733: Move module-specific data from make to respective module
by Magnus Ihse Bursie 21 Mar '22

21 Mar '22

A lot (but not all) of the data in make/data is tied to a specific module. For instance, the publicsuffixlist is used by java.base, and fontconfig by java.desktop. (A few directories, like mainmanifest, is *actually* used by make for the whole build.) These data files should move to the module they belong to. The are, after all, "source code" for that module that is "compiler" into resulting deliverables, for that module. (But the "source code" language is not Java or C, but typically a highly domain specific language or data format, and the "compilation" is, often, a specialized transformation.) This misplacement of the data directory is most visible at code review time. When such data is changed, most of the time build-dev (or the new build label) is involved, even though this has nothing to do with the build. While this is annoying, a worse problem is if the actual team that needs to review the patch (i.e., the team owning the module) is missed in the review. ------------- Commit messages: - Update references in test - Step 2: Update references - First stage, move actual data files Changes: https://git.openjdk.java.net/jdk/pull/1611/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1611&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8257733 Stats: 78 lines in 1575 files changed: 3 ins; 1 del; 74 mod Patch: https://git.openjdk.java.net/jdk/pull/1611.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1611/head:pull/1611 PR: https://git.openjdk.java.net/jdk/pull/1611

13 79

RFR: 8256018: Adler32/CRC32/CRC32C missing reachabilityFence
by Lance Andersen 09 Mar '22

09 Mar '22

Hi, Please review the fix for JDK-8256018 which addresses the issue that the update(ByteBuffer) methods of Adler32, CRC32, and CRC32C should use Reference.reachabilityFence to ensure that direct byte buffer are kept kept alive when they are accessed directly. The Mach5 jdk-tier1, jdk-tier2, jdk-tier3 as well as the jck:api/java_util/zip,jck:api/java_util/jar continue to run clean. Best Lance ------------- Commit messages: - Adler32/CRC32/CRC32C missing reachabilityFence Changes: https://git.openjdk.java.net/jdk/pull/1149/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1149&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8256018 Stats: 23 lines in 3 files changed: 16 ins; 0 del; 7 mod Patch: https://git.openjdk.java.net/jdk/pull/1149.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1149/head:pull/1149 PR: https://git.openjdk.java.net/jdk/pull/1149

4 6

RFR: 4890732: GZIPOutputStream doesn't support, in fact thwarts, use of optional GZIP fields
by Lin Zang 30 Sep '21

30 Sep '21

4890732: GZIPOutputStream doesn't support, in fact thwarts, use of optional GZIP fields ------------- Commit messages: - remove trailing spaces - 4890732: support optional GZIP fields in GZIPOutputStream Changes: https://git.openjdk.java.net/jdk/pull/3072/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3072&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-4890732 Stats: 184 lines in 1 file changed: 184 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/3072.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3072/head:pull/3072 PR: https://git.openjdk.java.net/jdk/pull/3072

5 46

RFR: 8253702: BigSur java/lang/System/OsVersionTest.java: 10.16 != 11.0
by Roger Riggs 24 Sep '21

24 Sep '21

On Mac Os X, the OSVersionTest detected a difference in the version number reported in the os.version property and the version number provided by `sw_vers -productVersion`. When the java runtime is built with XCode 11.3, the os.version is reported as 10.16 though the current version numbering is 11.nnn. The workaround is to derive the os.version number from the ProductBuildVersion. When the toolchain is updated to XCode 12.nnn it can be removed. The workaround is enabled only when the environment variable SYSTEM_VERSION_COMPAT is unset. When the SYSTEM_VERSION_COMPAT is set in the environment the version number is reported as reported by Mac OS X. ------------- Commit messages: - 8253702: BigSur java/lang/System/OsVersionTest.java: 10.16 != 11.0 Changes: https://git.openjdk.java.net/jdk/pull/2530/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2530&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8253702 Stats: 30 lines in 1 file changed: 21 ins; 2 del; 7 mod Patch: https://git.openjdk.java.net/jdk/pull/2530.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2530/head:pull/2530 PR: https://git.openjdk.java.net/jdk/pull/2530

5 20

RFR: 8248862: Implement Enhanced Pseudo-Random Number Generators
by Jim Laskey 14 Sep '21

14 Sep '21

This PR is to introduce a new random number API for the JDK. The primary API is found in RandomGenerator and RandomGeneratorFactory. Further description can be found in the JEP https://openjdk.java.net/jeps/356 . javadoc can be found at http://cr.openjdk.java.net/~jlaskey/prng/doc/api/java.base/java/util/random… old PR: https://github.com/openjdk/jdk/pull/1273 ------------- Commit messages: - 8248862: Implement Enhanced Pseudo-Random Number Generators - 8248862: Implement Enhanced Pseudo-Random Number Generators - 8248862: Implement Enhanced Pseudo-Random Number Generators - 8248862: Implement Enhanced Pseudo-Random Number Generators - 8248862: Implement Enhanced Pseudo-Random Number Generators - 8248862; Implement Enhanced Pseudo-Random Number Generators - 8248862: Implement Enhanced Pseudo-Random Number Generators - 8248862: Implement Enhanced Pseudo-Random Number Generators - 8248862: Implement Enhanced Pseudo-Random Number Generators - 8248862: Implement Enhanced Pseudo-Random Number Generators - ... and 15 more: https://git.openjdk.java.net/jdk/compare/f7517386...2b3e4ed7 Changes: https://git.openjdk.java.net/jdk/pull/1292/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1292&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8248862 Stats: 13319 lines in 25 files changed: 11110 ins; 2132 del; 77 mod Patch: https://git.openjdk.java.net/jdk/pull/1292.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1292/head:pull/1292 PR: https://git.openjdk.java.net/jdk/pull/1292

14 110