April 2021 - core-libs-dev

RFR: 8263668: Update java.time to use instanceof pattern variable
by Patrick Concannon 22 Apr '21

22 Apr '21

Hi, Could someone please review my code for updating the code in the `java.time` package to make use of the `instanceof` pattern variable? Kind regards, Patrick ------------- Commit messages: - Merge remote-tracking branch 'origin/master' into JDK-8263668 - 8263668: Update java.time to use instanceof pattern variable Changes: https://git.openjdk.java.net/jdk/pull/3170/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3170&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8263668 Stats: 170 lines in 34 files changed: 0 ins; 47 del; 123 mod Patch: https://git.openjdk.java.net/jdk/pull/3170.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3170/head:pull/3170 PR: https://git.openjdk.java.net/jdk/pull/3170

13 34

RFC: jdeps output - "jdk8internals" vs "JDK removed internal API" after JDK-8213909
by Aleksei Voitylov 22 Apr '21

22 Apr '21

Hi, JDK-8213909 [1] (since JDK 12, backported into 11.0.11), aside from bringing great additions to transitive module analysis, introduced a slight change in output of jdeps: jdk-11.0.11/bin/jdeps -s reactor-core-3.4.5.jar reactor-core-3.4.5.jar -> jdk8internals reactor-core-3.4.5.jar -> java.base reactor-core-3.4.5.jar -> java.logging reactor-core-3.4.5.jar -> not found jdk-11.0.10/bin/jdeps -s reactor-core-3.4.5.jar reactor-core-3.4.5.jar -> JDK removed internal API reactor-core-3.4.5.jar -> java.base reactor-core-3.4.5.jar -> java.logging reactor-core-3.4.5.jar -> not found Note the difference "jdk8internals" vs "JDK removed internal API", not discussed in the relevant CSR [2] or the review thread [3]. This change is likely to affect some automation systems built around jdeps. Since the change has already landed, I wanted to check if there is a reason behind this naming change, and if "jdk8internals" should be the naming convention the users are expected to standardize their automation on going forward? I would assume most now are used to parsing for "JDK removed internal API" to determine if the project uses any removed APIs (and should probably be using --print-module-deps to feed jlink input), but I also see merit in having a single convention for mainline and CPU releases. -Aleksei [1] https://bugs.openjdk.java.net/browse/JDK-8213909 [2] https://bugs.openjdk.java.net/browse/JDK-8213915 [3] http://mail.openjdk.java.net/pipermail/core-libs-dev/2018-November/056660.h…

2 2

RFR: 8265591: Remove vestiages of intermediate JSR 175 annotation format
by Joe Darcy 22 Apr '21

22 Apr '21

During the recent review of JDK-8228988, I noticed again the comments in the annotation parser about support for the pre-GA annotation format used before JDK 5.0 shipped. During the development of annotations, there was a late change to correct a flaw in the annotation encoding, JDK-5020908. I don't think it is necessary to carry forward support for this transient format any longer and this changeset removes support from both core reflection and javac. Clean runs of relevant test; I gauge this fix as no-reg hard. ------------- Commit messages: - 8265591: Remove vestiages of intermediate JSR 175 annotation format Changes: https://git.openjdk.java.net/jdk/pull/3597/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3597&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8265591 Stats: 24 lines in 2 files changed: 0 ins; 19 del; 5 mod Patch: https://git.openjdk.java.net/jdk/pull/3597.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3597/head:pull/3597 PR: https://git.openjdk.java.net/jdk/pull/3597

2 3

RFR: 8264161: BigDecimal#stripTrailingZeros can throw undocumented ArithmeticException
by Fabian Meumertzheim 22 Apr '21

22 Apr '21

Adds missing @throws declarations for ArithmeticException to the public function java.math.BigDecimal#stripTrailingZeros as well as the private helper functions java.math.BigDecimal#createAndStripZerosToMatchScale(long, int, long) java.math.BigDecimal#createAndStripZerosToMatchScale(BigInteger, int, long) stripTrailingZeros calls one of the two helper functions, both of which can repeatedly decrease the scale by 1 until it underflows. If it does, the call to checkScale will result in an ArithmeticException (overflow). ------------- Commit messages: - 8264161: ArithmeticException not declared for BigDecimal#stripTrailingZeros Changes: https://git.openjdk.java.net/jdk/pull/3189/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3189&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8264161 Stats: 3 lines in 1 file changed: 3 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/3189.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3189/head:pull/3189 PR: https://git.openjdk.java.net/jdk/pull/3189

6 10

Jpackage Mac entitlements
by Michael Hall 22 Apr '21

22 Apr '21

Reverted to Jdk 16 and temporarily couldn’t figure out why AppleScript wasn’t working again. I needed to provide an entitlement. At jpackage 16 I found I needed to do this differently with a <app.name>.entitlements file in the resources directory, as I noticed in the verbose command output. I had previously noticed that jpackage 17 now includes a parameter to provide this. Will both options continue to be supported, resource dir and parm, or will parm become the only supported way at or after 17?

2 2

RFR: 8264514: HexFormat implementation tweaks
by Raffaello Giulietti 22 Apr '21

22 Apr '21

(Changed to new branch in personal fork) Please review these small tweaks. For background information see [1](https://mail.openjdk.java.net/pipermail/core-libs-dev/2021-March/075822.… Greetings Raffaello ------------- Commit messages: - 8264514: HexFormat implementation tweaks Changes: https://git.openjdk.java.net/jdk/pull/3381/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3381&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8264514 Stats: 67 lines in 1 file changed: 10 ins; 26 del; 31 mod Patch: https://git.openjdk.java.net/jdk/pull/3381.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3381/head:pull/3381 PR: https://git.openjdk.java.net/jdk/pull/3381

2 3

RFR: 8265700: Regularize throws clauses in BigDecimal
by Joe Darcy 21 Apr '21

21 Apr '21

Some throws clauses in BigDecimal are uninformative and could be eliminated. A few explicit throws clauses for surprising exceptions could be added. These are spec clarifications rather than spec changes. Follow-up work to https://github.com/openjdk/jdk/pull/3189. ------------- Commit messages: - Add missing space. - 8265700: Regularize throws clauses in BigDecimal Changes: https://git.openjdk.java.net/jdk/pull/3608/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3608&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8265700 Stats: 19 lines in 1 file changed: 7 ins; 12 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/3608.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3608/head:pull/3608 PR: https://git.openjdk.java.net/jdk/pull/3608

2 3

RFR: 8013527: calling MethodHandles.lookup on itself leads to errors
by Mandy Chung 21 Apr '21

21 Apr '21

JDK-8013527: calling MethodHandles.lookup on itself leads to errors JDK-8257874: MethodHandle injected invoker doesn't have necessary private access Johannes Kuhn is also a contributor to this patch. A caller-sensitive method can behave differently depending on the identity of its immediate caller. If a method handle for a caller-sensitive method is requested, this resulting method handle behaves as if it were called from an instruction contained in the lookup class. The current implementation injects a trampoline class (aka the invoker class) which is the caller class invoking such caller-sensitive method handle. It works in all CSMs except `MethodHandles::lookup` because the caller-sensitive behavior depends on the module of the caller class, the class loader of the caller class, the accessibility of the caller class, or the protection domain of the caller class. The invoker class is a hidden class defined in the same runtime package with the same protection domain as the lookup class, which is why the current implementation works for all CSMs except `MethodHandles::lookup` which uses the caller class as the lookup class. Two issues with current implementation: 1. The invoker class only has the package access as the lookup class. It cannot access private members of the lookup class and its nest members. The fix is to make the invoker class as a nestmate of the lookup class. 2. `MethodHandles::lookup` if invoked via a method handle produces a `Lookup` object of an injected invoker class which is a bug. There are two alternatives: - define the invoker class with the lookup class as the class data such that `MethodHandles::lookup` will get the caller class from the class data if it's the injected invoker - Johannes' proposal [1]: detect if an alternate implementation with an additional trailing caller class parameter is present, use the alternate implementation and bind the method handle with the lookup class as the caller class argument. There has been several discussions on the improvement to support caller sensitive methods for example the calling sequences and security implication. I have looked at how each CSM uses the caller class. The second approach (i.e. defining an alternate implementation for a caller-sensitive method taking an additional caller class parameter) does not work for non-static non-final caller-sensitive method. In addition, it is not ideal to pollute the source code to provide an alternatve implementation for all 120+ caller-sensitive methods whereas the injected invoker works for all except `MethodHandles::lookup`. I propose to use both approaches. We can add an alternative implementation for a caller-sensitive method when desirable such as `MethodHandles::lookup` in this PR. For the injected invoker case, one could extract the original lookup class from class data if needed. test/jdk/jdk/internal/reflect/CallerSensitive/CheckCSM.java ensures that no new non-static non-final caller-sensitive method will be added to the JDK. I extend this test to catch that non-static non-final caller-sensitive method cannot have the alternate implementation taking the additional caller class parameter. This fix for JDK-8013527 is needed by the prototype for JDK-6824466 I'm working on. [1] https://mail.openjdk.java.net/pipermail/core-libs-dev/2021-January/073184.h… ------------- Commit messages: - clean up whitespace - revise the helper method - clean up - JDK-8013527: calling MethodHandles.lookup on itself leads to errors Changes: https://git.openjdk.java.net/jdk/pull/2367/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2367&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8013527 Stats: 662 lines in 10 files changed: 620 ins; 9 del; 33 mod Patch: https://git.openjdk.java.net/jdk/pull/2367.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2367/head:pull/2367 PR: https://git.openjdk.java.net/jdk/pull/2367

3 10

RFR: 8265237: String.join and StringJoiner can be improved further
by Peter Levart 21 Apr '21

21 Apr '21

While JDK-8148937 improved StringJoiner class by replacing internal use of getChars that copies out characters from String elements into a char[] array with StringBuilder which is somehow more optimal, the improvement was marginal in speed (0% ... 10%) and mainly for smaller strings, while GC was reduced by about 50% in average per operation. Initial attempt to tackle that issue was more involved, but was later discarded because it was apparently using too much internal String details in code that lives outside String and outside java.lang package. But there is another way to package such "intimate" code - we can put it into String itself and just call it from StringJoiner. This PR is an attempt at doing just that. It introduces new package-private method in `java.lang.String` which is then used from both pubic static `String.join` methods as well as from `java.util.StringJoiner` (via SharedSecrets). The improvements can be seen by running the following JMH benchmark: https://gist.github.com/plevart/86ac7fc6d4541dbc08256cde544019ce The comparative results are here: https://jmh.morethan.io/?gist=7eb421cf7982456a2962269137f71c15 The jmh-result.json files are here: https://gist.github.com/plevart/7eb421cf7982456a2962269137f71c15 Improvement in speed ranges from 8% (for small strings) to 200% (for long strings), while creation of garbage has been further reduced to an almost garbage-free operation. So WDYT? ------------- Commit messages: - Make JavaLangAccess JLA field private static final - Alternative String.join Changes: https://git.openjdk.java.net/jdk/pull/3501/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3501&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8265237 Stats: 97 lines in 4 files changed: 61 ins; 18 del; 18 mod Patch: https://git.openjdk.java.net/jdk/pull/3501.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3501/head:pull/3501 PR: https://git.openjdk.java.net/jdk/pull/3501

5 18

RFR: 8265421: java/lang/String/StringRepeat.java test is missing a memory requirement
by Christoph Göttschkes 21 Apr '21

21 Apr '21

Please review the following patch, which fixes the mentioned test case for memory constrained devices. This can be tested on a linux based development machine, using systemd as follows: $ systemd-run --user --scope -p MemoryMax=800M -p MemorySwapMax=0 /usr/bin/make TEST="test/jdk/java/lang/String/StringRepeat.java" run-test I split up the test case in a part which only executes the small repeat counts, and in one part which executes the huge repeat count. The second part is guarded by a requirement, so it is only executed if enough memory is available. ------------- Commit messages: - Adds a second test instance which executes the huge repeat count. Changes: https://git.openjdk.java.net/jdk/pull/3566/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3566&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8265421 Stats: 18 lines in 1 file changed: 13 ins; 1 del; 4 mod Patch: https://git.openjdk.java.net/jdk/pull/3566.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3566/head:pull/3566 PR: https://git.openjdk.java.net/jdk/pull/3566

4 9