May 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: 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: 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: 8291966: SwitchBootstrap.typeSwitch could be faster
by Jan Lahoda 22 Jun '24

22 Jun '24

The pattern matching switches are using a bootstrap method `SwitchBootstrap.typeSwitch` to implement the jumps in the switch. Basically, for a switch like: switch (obj) { case String s when s.isEmpty() -> {} case String s -> {} case CharSequence cs -> {} ... } this method will produce a MethodHandle that will be analyze the provided selector value (`obj` in the example), and will return the case index to which the switch should jump. This method also accepts a (re)start index for the search, which is used to handle guards. For example, if the `s.isEmpty()` guard in the above sample returns false, the matching is restarted on the next case. The current implementation is fairly slow, it basically goes through the labels in a loop. The proposal here is to replace that with a MethodHandle structure like this: obj == null ? -1 : switch (restartIndex) { case 0 -> obj instanceof String ? 0 : obj instanceof CharSequence ? 2 : ... ; case 1 -> obj instanceof String ? 1 : obj instanceof CharSequence ? 2 : ... ; case 2 -> obj instanceof CharSequence ? 2 : ... ; ... default -> <labels-count>; } This appear to run faster than the current implementation, using testcase similar to the one used for https://github.com/openjdk/jdk/pull/9746 , these are the results PatternsOptimizationTest.testLegacyIndyLongSwitch thrpt 25 1515989.562 ± 32047.918 ops/s PatternsOptimizationTest.testHandleIndyLongSwitch thrpt 25 2630707.585 ± 37202.210 ops/s PatternsOptimizationTest.testLegacyIndyShortSwitch thrpt 25 6789310.900 ± 61921.636 ops/s PatternsOptimizationTest.testHandleIndyShortSwitch thrpt 25 10771729.464 ± 69607.467 ops/s The "LegacyIndy" is the current implementation, "HandleIndy" is the one proposed here. The translation in javac used is the one from #9746 in all cases. ------------- Commit messages: - 8291966: SwitchBootstrap.typeSwitch could be faster Changes: https://git.openjdk.org/jdk/pull/9779/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9779&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8291966 Stats: 74 lines in 1 file changed: 50 ins; 4 del; 20 mod Patch: https://git.openjdk.org/jdk/pull/9779.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9779/head:pull/9779 PR: https://git.openjdk.org/jdk/pull/9779

12 27

RFR: 8303133: Update ProcessTols.startProcess(...) to exit early if process exit before linePredicate is printed.
by Leonid Mesnik 05 Jun '24

05 Jun '24

The solution proposed by Stefan K The startProcess() might wait forever for the expected line if the process exits (failed to start). It makes sense to just fail earlier in such cases. The fix also move 'output = new OutputAnalyzer(this.process);' in method xrun() to be able to try to print them in waitFor is failed/interrupted. ------------- Commit messages: - 8303133: Update ProcessTols.startProcess(...) to exit early if process exit before linePredicate is printed. Changes: https://git.openjdk.org/jdk/pull/12751/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12751&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8303133 Stats: 26 lines in 2 files changed: 16 ins; 3 del; 7 mod Patch: https://git.openjdk.org/jdk/pull/12751.diff Fetch: git fetch https://git.openjdk.org/jdk pull/12751/head:pull/12751 PR: https://git.openjdk.org/jdk/pull/12751

4 19

RFR: 8180892: Correct handling of annotations on parameters
by Chen Liang 11 Apr '24

11 Apr '24

This patch aims to correct handling of annotations on parameters with the help of `MethodParameters` attribute, which will be always available once #9862 is integrated. It utilizes and expands upon the existing parameter matching logic present in `Executable::getAllGenericParameterTypes`, and delegate parameter parameterized types, parameter annotation, and parameter type annotation accesses through the matched results, if matching is available. If matching failed, it falls back to existing heuristics that works without `MethodParameters` attributes for annotations, in `Executable::handleParameterNumberMismatch` and `TypeAnnotationParser::buildAnnotatedTypes` (renamed `buildAnnotatedTypesWithHeuristics` in this patch) `ParameterMappingTest` covers these scenarios with class files that have `MethodParameters` or `Signature` attributes stripped or preserved to ensure the new Reflection API implementation works for both class files generated before #9862 and after its integration. Also special thanks to Joe Darcy for reviewing 8304918 (#13183); this brings much convenience to this patch. ------------- Commit messages: - copyright years - Complete ParameterMappingTest to take care of interested scenarios - Merge branch 'master' into param-implicit-mapping - test wip - Introduce base for annotated types if signature is absent but method parameters is present - simplify code with further contracts - Try map parameter content with modifier info Changes: https://git.openjdk.org/jdk/pull/13664/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13664&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8180892 Stats: 636 lines in 7 files changed: 548 ins; 57 del; 31 mod Patch: https://git.openjdk.org/jdk/pull/13664.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13664/head:pull/13664 PR: https://git.openjdk.org/jdk/pull/13664

3 12