August 2023 - 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

RFR: JDK-8266431: Dual-Pivot Quicksort improvements (Radix sort)
by Laurent Bourgès 21 Sep '25

21 Sep '25

* Optimized mixed insertion sort * Optimized insertion sort * Optimized Radix sort * Updated microbenchmark I am going on previous PR by Vladimir Yaroslavskyi: https://github.com/openjdk/jdk/pull/3938 ------------- Commit messages: - JDK-8266431: Dual-Pivot Quicksort improvements (Radix sort) Changes: https://git.openjdk.org/jdk/pull/13568/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13568&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8266431 Stats: 4022 lines in 4 files changed: 1747 ins; 1272 del; 1003 mod Patch: https://git.openjdk.org/jdk/pull/13568.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13568/head:pull/13568 PR: https://git.openjdk.org/jdk/pull/13568

10 105

RFR: 8282429: StringBuilder/StringBuffer.toString() skip compressing for UTF16 strings
by Xin Liu 29 May '25

29 May '25

If AbstractStringBuilder only grow, the inflated value which is encoded in UTF16 can't be compressed. toString() can skip compression in this case. This can save an ArrayAllocation in StringUTF16::compress. java.io.BufferedRead::readLine() is a case that StringBuilder grows only. ------------- Commit messages: - Add a microbenchmark. - 8282429: StringBuilder/StringBuffer.toString() skip compressing for UTF16 strings Changes: https://git.openjdk.java.net/jdk/pull/7671/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7671&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8282429 Stats: 44 lines in 5 files changed: 37 ins; 3 del; 4 mod Patch: https://git.openjdk.java.net/jdk/pull/7671.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7671/head:pull/7671 PR: https://git.openjdk.java.net/jdk/pull/7671

4 22

Re: RFR: 8266013: Unexpected replacement character handling on stateful CharsetEncoder [v2]
by Ichiroh Takiguchi 27 May '25

27 May '25

> When an invalid character is converted by getBytes() method, the character is converted to replacement byte data. > Shift code (SO/SI) may not be added into right place by EBCDIC Mix charset. > EBCDIC Mix charset encoder is stateful encoder. > Shift code should be added by switching character set. > On x-IBM1364, "\u3000\uD800" should be converted to "\x0E\x40\x40\x0F\x6F", but "\x0E\x40\x40\x6F\x0F" > SI is not in right place. > > Also ISO2022 related charsets use escape sequence to switch character set. > But same kind of issue is there. Ichiroh Takiguchi has updated the pull request incrementally with one additional commit since the last revision: 8266013: Unexpected replacement character handling on stateful CharsetEncoder ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3719/files - new: https://git.openjdk.java.net/jdk/pull/3719/files/d6a0a41b..33107e67 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3719&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3719&range=00-01 Stats: 59 lines in 2 files changed: 40 ins; 5 del; 14 mod Patch: https://git.openjdk.java.net/jdk/pull/3719.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3719/head:pull/3719 PR: https://git.openjdk.java.net/jdk/pull/3719

3 3

RFR: 8268829: Provide an optimized way to walk the stack with Class object only
by Mandy Chung 02 May '25

02 May '25

8268829: Provide an optimized way to walk the stack with Class object only `StackWalker::walk` creates one `StackFrame` per frame and the current implementation allocates one `StackFrameInfo` and one `MemberName` objects per frame. Some frameworks like logging may only interest in the Class object but not the method name nor the BCI, for example, filters out its implementation classes to find the caller class. It's similar to `StackWalker::getCallerClass` but allows a predicate to filter out the element. This PR proposes to add `Option.NO_METHOD_INFO` new stack walking option. If no method information is needed, this option can be used such that the stack walker will save the overhead (1) to extract the method information and (2) the memory used for the stack walking. In addition, this can also fix - [8311500](https://bugs.openjdk.org/browse/JDK-8311500): StackWalker.getCallerClass() throws UOE if invoked reflectively Adding `NO_METHOD_TIME` option provides a simple way for existing code, for example logging frameworks, to take advantage of this enhancement with the least change as it can keep the existing implementation in traversing `StackFrame`s. For example: to find the first caller filtering a known list of implementation class, existing code can just add `NO_METHOD_INFO` in the call to `StackWalker::getInstance` to create a stack walker instance: StackWalker walker = StackWalker.getInstance(Option.RETAIN_CLASS_REFERENCE, NO_METHOD_INFO); Optional<Class<?>> callerClass = walker.walk(s -> s.map(StackFrame::getDeclaringClass) .filter(interestingClasses::contains) .findFirst()); If method information is accessed on the `StackFrame`s produced by this stack walker such as `StackFrame::getMethodName`, then `UnsupportedOperationException` will be thrown. The alternative considered is to provide a new API: `<T> T walkClass(Function<? super Stream<Class<?>, ? extends T> function)` In this case, the caller would need to pass a function that takes a stream of `Class` object instead of `StackFrame`. Existing code would have to modify calls to the `walk` method to `walkClass` and the function body. ### Implementation Details If `NO_METHOD_NAME` is set, the implementation creates `ClassFrameInfo[]` buffer that is filled by the VM during stack walking. `ClassFrameInfo` holds the Class instance plus `flags` which indicate if it's caller sensitive or hidden. With this change, `StackWalker::getCallerClass` can also use `ClassFrameInfo[]` buffer to replace the special `Class` buffer and remove the special check in the VM. JDK-8311500 can be fixed in Java. If `NO_METHOD_NAME` is not set, the implementation creates `StackFrameInfo[]` buffer. `StackFrameInfo` is a subclass of `ClassFrameInfo`. It keeps `ResolvedMethodName` and all other method information. ### Performance The memory usage of the data structure (shown by -XX:PrintFieldLayout): | Type | Instance size | | ---- | ------------ | | `ClassFrameInfo` | 24 bytes | | `StackFrameInfo` | 48 bytes | | `ResolvedMethodName` | 24 bytes | | `MemberName` | 48 bytes | | `StackFrameInfo` (old) | 32 bytes | The existing implementation allocates a total of 104 bytes for each frame (`StackFrameInfo` + `MemberName` + `ResolvedMethodName`). The new implementation, without `NO_METHOD_INFO` option, allocates a total of 72 bytes for each frame (`StackFrameInfo` + `ResolvedMethodName`) which saves 30% of the buffer memory. With `NO_METHOD_INFO`, 24 bytes is allocated for each frame (only `ClassFrameInfo` is needed). In addition, it saves the overhead in creating `ResolvedMethodName` object in the VM. The microbenchmark shows that the runtime performance of stack walking with method information is 15-31% faster than the old implementation. Using `NO_METHOD_INFO` option, it is about 21-43% faster compared to traversing the frames without `NO_METHOD_INFO` in the new implementation. #### `StackWalker::getCallerClass` `StackWalkBench::getCallerClass` shows about 30-60 ns degradation. The old implementation creates a `Class` array of size 8 whereas the new implementation which creates a `ClassFrameInfo` array of size 8 initialized with 6 `ClassFrameInfo` elements. The new implementation of `getCallerClass` adds 144 bytes more, which is insignificant. The benefit of this is to do the filtering in Java rather than doing in VM. `StackWalkBench::getCallerClass` includes the cost of setting up the call stack. There is no good way to write a JMH benchmark just to measure the performance of `getCallerClass`. If I measured `getCallerClass` with a standalone benchmark, it shows `getCallerClass` takes roughly about 8500-10000 ns range on my macos-aarch64 machine. The 30-60 ns degradation is negligible. ------------- Commit messages: - fix trailing whitespace - Merge branch 'master' of https://github.com/openjdk/jdk into stackwalker-class - Update LocalLongHelper.java - clean up - Merge branch 'master' of https://github.com/openjdk/jdk into stackwalker-class - Add StackWalker.Option.NO_METHOD_INFO - Merge branch 'master' of https://github.com/openjdk/jdk into stackwalker-class - Merge branch 'master' of https://github.com/openjdk/jdk into stackwalker-class - Merge branch 'master' of https://github.com/openjdk/jdk into stackwalker-class - Merge branch 'master' of https://github.com/openjdk/jdk into stackwalker-class - ... and 3 more: https://git.openjdk.org/jdk/compare/78f74bc8...e9e2b390 Changes: https://git.openjdk.org/jdk/pull/15370/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15370&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8268829 Stats: 1026 lines in 30 files changed: 628 ins; 178 del; 220 mod Patch: https://git.openjdk.org/jdk/pull/15370.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15370/head:pull/15370 PR: https://git.openjdk.org/jdk/pull/15370

13 67

RFR: 8301991: Convert l10n properties resource bundles to UTF-8 native
by Justin Lu 10 Apr '25

10 Apr '25

This PR converts Unicode sequences to UTF-8 native in .properties file. (Excluding the Unicode space and tab sequence). The conversion was done using native2ascii. In addition, the build logic is adjusted to support reading in the .properties files as UTF-8 during the conversion from .properties file to .java ListResourceBundle file. ------------- Commit messages: - Write to ASCII - Read in .properties as UTF-8, but write to LRB .java as ISO-8859-1 - Compile class with ascii (Not ready to make system wide change) - Toggle UTF-8 for javac option in JavaCompilation.gmk - CompileProperties converts in UTF-8 - Convert .properties from ISO-8859-1 to UTF-8 Changes: https://git.openjdk.org/jdk/pull/12726/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12726&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8301991 Stats: 29093 lines in 490 files changed: 6 ins; 0 del; 29087 mod Patch: https://git.openjdk.org/jdk/pull/12726.diff Fetch: git fetch https://git.openjdk.org/jdk pull/12726/head:pull/12726 PR: https://git.openjdk.org/jdk/pull/12726

9 28

RFR: 8311302: Allow for jlinking a custom runtime without packaged modules being present
by Severin Gehwolf 11 Nov '24

11 Nov '24

Please review this patch which adds a "jmodless" jlink mode to the JDK. Fundamentally this patch adds an option to use `jlink` even though your JDK install might not come with the packaged modules (directory `jmods`). This is particularly useful to further reduce the size of a jlinked runtime. After the removal of the concept of a JRE, a common distribution mechanism is still the full JDK with all modules and packaged modules. However, packaged modules can incur an additional size tax. For example in a container scenario it could be useful to have a base JDK container including all modules, but without also delivering the packaged modules. This comes at a size advantage of `~25%`. Such a base JDK container could then be used to `jlink` application specific runtimes, further reducing the size of the application runtime image (App + JDK runtime; as a single image *or* separate bundles, depending on the app being modularized). The basic design of this approach is to add a jlink plugin for tracking non-class and non-resource files of a JDK install. I.e. files which aren't present in the jimage (`lib/modules`). This enables producing a `JmodLessArchive` class which has all the info of what constitutes the final jlinked runtime. Basic usage example: $ diff -u <(./bin/java --list-modules --limit-modules java.se) <(../linux-x86_64-server-release/images/jdk/bin/java --list-modules --limit-modules java.se) $ diff -u <(./bin/java --list-modules --limit-modules java.se) <(../linux-x86_64-server-release/images/jdk/bin/java --list-modules --limit-modules jdk.jlink) $ ls ../linux-x86_64-server-release/images/jdk/jmods java.base.jmod java.net.http.jmod java.sql.rowset.jmod jdk.crypto.ec.jmod jdk.internal.opt.jmod jdk.jdi.jmod jdk.management.agent.jmod jdk.security.auth.jmod java.compiler.jmod java.prefs.jmod java.transaction.xa.jmod jdk.dynalink.jmod jdk.internal.vm.ci.jmod jdk.jdwp.agent.jmod jdk.management.jfr.jmod jdk.security.jgss.jmod java.datatransfer.jmod java.rmi.jmod java.xml.crypto.jmod jdk.editpad.jmod jdk.internal.vm.compiler.jmod jdk.jfr.jmod jdk.management.jmod jdk.unsupported.desktop.jmod java.desktop.jmod java.scripting.jmod java.xml.jmod jdk.hotspot.agent.jmod jdk.internal.vm.compiler.management.jmod jdk.jlink.jmod jdk.naming.dns.jmod jdk.unsupported.jmod java.instrument.jmod java.security.jgss.jmod jdk.accessibility.jmod jdk.httpserver.jmod jdk.jartool.jmod jdk.jpackage.jmod jdk.naming.rmi.jmod jdk.xml.dom.jmod java.logging.jmod java.security.sasl.jmod jdk.attach.jmod jdk.incubator.vector.jmod jdk.javadoc.jmod jdk.jshell.jmod jdk.net.jmod jdk.zipfs.jmod java.management.jmod java.se.jmod jdk.charsets.jmod jdk.internal.ed.jmod jdk.jcmd.jmod jdk.jsobject.jmod jdk.nio.mapmode.jmod java.management.rmi.jmod java.smartcardio.jmod jdk.compiler.jmod jdk.internal.jvmstat.jmod jdk.jconsole.jmod jdk.jstatd.jmod jdk.random.jmod java.naming.jmod java.sql.jmod jdk.crypto.cryptoki.jmod jdk.internal.le.jmod jdk.jdeps.jmod jdk.localedata.jmod jdk.sctp.jmod $ ls jmods ls: cannot access 'jmods': No such file or directory $ ./bin/jlink --version 22-internal $ ./bin/jlink --add-modules java.se --output ../build/java.se-runtime --verbose java.base jrt:/java.base (jmod-less) java.compiler jrt:/java.compiler (jmod-less) java.datatransfer jrt:/java.datatransfer (jmod-less) java.desktop jrt:/java.desktop (jmod-less) java.instrument jrt:/java.instrument (jmod-less) java.logging jrt:/java.logging (jmod-less) java.management jrt:/java.management (jmod-less) java.management.rmi jrt:/java.management.rmi (jmod-less) java.naming jrt:/java.naming (jmod-less) java.net.http jrt:/java.net.http (jmod-less) java.prefs jrt:/java.prefs (jmod-less) java.rmi jrt:/java.rmi (jmod-less) java.scripting jrt:/java.scripting (jmod-less) java.se jrt:/java.se (jmod-less) java.security.jgss jrt:/java.security.jgss (jmod-less) java.security.sasl jrt:/java.security.sasl (jmod-less) java.sql jrt:/java.sql (jmod-less) java.sql.rowset jrt:/java.sql.rowset (jmod-less) java.transaction.xa jrt:/java.transaction.xa (jmod-less) java.xml jrt:/java.xml (jmod-less) java.xml.crypto jrt:/java.xml.crypto (jmod-less) Providers: java.desktop provides java.net.ContentHandlerFactory used by java.base java.base provides java.nio.file.spi.FileSystemProvider used by java.base java.naming provides java.security.Provider used by java.base java.security.jgss provides java.security.Provider used by java.base java.security.sasl provides java.security.Provider used by java.base java.xml.crypto provides java.security.Provider used by java.base java.base provides java.util.random.RandomGenerator used by java.base java.management.rmi provides javax.management.remote.JMXConnectorProvider used by java.management java.management.rmi provides javax.management.remote.JMXConnectorServerProvider used by java.management java.desktop provides javax.print.PrintServiceLookup used by java.desktop java.desktop provides javax.print.StreamPrintServiceFactory used by java.desktop java.management provides javax.security.auth.spi.LoginModule used by java.base java.desktop provides javax.sound.midi.spi.MidiDeviceProvider used by java.desktop java.desktop provides javax.sound.midi.spi.MidiFileReader used by java.desktop java.desktop provides javax.sound.midi.spi.MidiFileWriter used by java.desktop java.desktop provides javax.sound.midi.spi.SoundbankReader used by java.desktop java.desktop provides javax.sound.sampled.spi.AudioFileReader used by java.desktop java.desktop provides javax.sound.sampled.spi.AudioFileWriter used by java.desktop java.desktop provides javax.sound.sampled.spi.FormatConversionProvider used by java.desktop java.desktop provides javax.sound.sampled.spi.MixerProvider used by java.desktop java.logging provides jdk.internal.logger.DefaultLoggerFinder used by java.base java.desktop provides sun.datatransfer.DesktopDatatransferService used by java.datatransfer One nice property of this patch is that it can produce an identical (as in binary identical) `java.se` JDK image in "jmod-less" mode as compared to a regular jlink with packaged modules present. This has been asserted in newly added tests. In order to prevent accidental copy of modified files in the base JDK a checksum mechanism is in place to warn about this when jlinking. This is also asserted in tests. One limitation of this mode is that there is no way to use it for cross-linking (at least currently). That is, a jmod-less `jlink` needs to happen on the same runtime platform the resulting image is intended to get deployed on. Testing: - [x] GHA (including `jdk/tools/jlink` tests). See for example [the latest run](https://github.com/jerboaa/jdk/actions/runs/5477743443) and [here](https://github.com/jerboaa/jdk/actions/runs/5475484765). - [x] Some tests on our internal infra (JDK 17-based). It didn't show any regressions. - [x] Added tests as part of the patch (8 of them). All pass on the major platforms. Thoughts? ------------- Commit messages: - 8311302: Allow for jlinking a custom runtime without packaged modules being present Changes: https://git.openjdk.org/jdk/pull/14787/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14787&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8311302 Stats: 2083 lines in 23 files changed: 2016 ins; 33 del; 34 mod Patch: https://git.openjdk.org/jdk/pull/14787.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/14787/head:pull/14787 PR: https://git.openjdk.org/jdk/pull/14787

7 294

RFR: 8304846: Provide a shared utility to dump generated classes defined via Lookup API
by Mandy Chung 31 Aug '24

31 Aug '24

This implements a shared utility to dump generated classes defined as normal/hidden classes via `Lookup` API. This replaces the implementation in `LambdaMetaFactory` and method handle implementation that dumps the hidden class bytes on disk for debugging. For classes defined via `Lookup::defineClass`, `Lookup::defineHiddenClass` and `Lookup::defineHiddenClassWithClassData`, by default they will be dumped to the path specified in `-Djava.lang.invoke.Lookup.dumpClasses=<dumpDir>` The hidden classes generated for lambdas, `LambdaForms` and method handle implementation use non-default dumper so that they can be controlled via a separate system property and path as in the current implementation. To dump lambda proxy classes, set this system property: -Djdk.internal.lambda.dumpProxyClasses=<dumpDir> To dump LambdaForms and method handle implementation, set this system property: -Djava.lang.invoke.MethodHandle.DUMP_CLASS_FILES=true P.S. `ProxyClassesDumper` is renamed to `ClassFileDumper` but for some reason, it's not shown as rename. ------------- Commit messages: - rename the system property - 8304846: Provide a shared utility to dump generated classes defined via Lookup API Changes: https://git.openjdk.org/jdk/pull/13182/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13182&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8304846 Stats: 636 lines in 10 files changed: 317 ins; 262 del; 57 mod Patch: https://git.openjdk.org/jdk/pull/13182.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13182/head:pull/13182 PR: https://git.openjdk.org/jdk/pull/13182

8 29

RFR: 8289552: Make intrinsic conversions between bit representations of half precision values and floats
by Smita Kamath 09 Aug '24

09 Aug '24

8289552: Make intrinsic conversions between bit representations of half precision values and floats ------------- Commit messages: - Intrinsic conversions between halffloat and floats Changes: https://git.openjdk.org/jdk/pull/9781/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9781&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8289552 Stats: 220 lines in 13 files changed: 212 ins; 5 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/9781.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9781/head:pull/9781 PR: https://git.openjdk.org/jdk/pull/9781

11 81

RFR: 8301341: LinkedTransferQueue does not respect timeout for poll()
by Doug Lea 03 Jul '24

03 Jul '24

This now uses Thread.isVirtual to distinguish spin vs immediate block cases, enabling re-introduction of spin control from the previous version, removing anomalies like this one. ------------- Commit messages: - Use Thread.isVirtual to distinguish spin vs immediate block cases Changes: https://git.openjdk.org/jdk/pull/14317/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14317&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8301341 Stats: 131 lines in 1 file changed: 73 ins; 28 del; 30 mod Patch: https://git.openjdk.org/jdk/pull/14317.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/14317/head:pull/14317 PR: https://git.openjdk.org/jdk/pull/14317

8 41