Re: RFR: 8261621: Delegate Unicode history from JLS to j.l.Character [v2]

2021-02-21 Thread David Holmes
On 20/02/2021 12:00 am, Naoto Sato wrote: On Thu, 18 Feb 2021 14:49:20 GMT, Roger Riggs wrote: The table is informative and should not be construed as specification. The wording "has supported" should be sufficient. If this is not specification then doesn't that imply that any provider of

Re: RFR: 8259800: timeout in tck test testForkJoin(ForkJoinPool8Test) [v2]

2021-02-21 Thread David Holmes
On Sun, 21 Feb 2021 23:22:00 GMT, Doug Lea wrote: >> This addresses interactions between parallelism-0 and new shutdown support >> in https://bugs.openjdk.java.net/browse/JDK-8259800 > > Doug Lea has updated the pull request incrementally with one additional > commit since the last revision: >

Re: RFR: 8259800: timeout in tck test testForkJoin(ForkJoinPool8Test) [v2]

2021-02-21 Thread Doug Lea
> This addresses interactions between parallelism-0 and new shutdown support in > https://bugs.openjdk.java.net/browse/JDK-8259800 Doug Lea has updated the pull request incrementally with one additional commit since the last revision: JDK-8259800 - Changes: - all: https://git.

Re: RFR: 8259800: timeout in tck test testForkJoin(ForkJoinPool8Test)

2021-02-21 Thread Martin Buchholz
On Sat, 20 Feb 2021 14:17:16 GMT, Doug Lea wrote: > This addresses interactions between parallelism-0 and new shutdown support in > https://bugs.openjdk.java.net/browse/JDK-8259800 Marked as reviewed by martin (Reviewer). - PR: https://git.openjdk.java.net/jdk/pull/2661

Re: Class.getRecordComponents security checks

2021-02-21 Thread Remi Forax
- Mail original - > De: "Attila Szegedi" > À: "core-libs-dev" > Envoyé: Dimanche 21 Février 2021 21:14:48 > Objet: Class.getRecordComponents security checks > Hey folks, > > Why are security checks for Class.getRecordComponents as strict as those for > e.g. getDeclaredMethods? I would’v

Class.getRecordComponents security checks

2021-02-21 Thread Attila Szegedi
Hey folks, Why are security checks for Class.getRecordComponents as strict as those for e.g. getDeclaredMethods? I would’ve expected they’d be as strict as those for e.g. getMethods. Specifically, the difference is the: > “the caller's class loader is not the same as the class loader of this cl

Integrated: 8261290: Improve error message for NumberFormatException on null input

2021-02-21 Thread Joe Darcy
On Sat, 20 Feb 2021 21:44:12 GMT, Joe Darcy wrote: > In Integer and Long, several of the parsing methods are specified to throw > NumberFormatException on a null input rather than an NPE. That behavior is > not proposed to be modified. However, I think it is reasonable for the > NumberFormatEx

Re: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v18]

2021-02-21 Thread Phil Race
On Wed, 17 Feb 2021 12:36:10 GMT, Anton Kozlov wrote: >> Please review the implementation of JEP 391: macOS/AArch64 Port. >> >> It's heavily based on existing ports to linux/aarch64, macos/x86_64, and >> windows/aarch64. >> >> Major changes are in: >> * src/hotspot/cpu/aarch64: support of the

Re: RFR: 8261290: Improve error message for NumberFormatException on null input

2021-02-21 Thread Alan Bateman
On Sat, 20 Feb 2021 21:44:12 GMT, Joe Darcy wrote: > In Integer and Long, several of the parsing methods are specified to throw > NumberFormatException on a null input rather than an NPE. That behavior is > not proposed to be modified. However, I think it is reasonable for the > NumberFormatEx

Re: RFR: 8261483: jdk/dynalink/TypeConverterFactoryMemoryLeakTest.java failed with "AssertionError: Should have GCd a method handle by now"

2021-02-21 Thread Attila Szegedi
On Fri, 19 Feb 2021 11:22:57 GMT, Peter Levart wrote: >I would like 1st to understand why the MH created in the >TestLinker.convertToType is actually GCed at all. The whole original issue was about allowing these objects to be GCd 😄. Short story: because all data is scoped to objects created wi

Re: RFR: 8261290: Improve error message for NumberFormatException on null input

2021-02-21 Thread Attila Szegedi
On Sat, 20 Feb 2021 21:44:12 GMT, Joe Darcy wrote: > In Integer and Long, several of the parsing methods are specified to throw > NumberFormatException on a null input rather than an NPE. That behavior is > not proposed to be modified. However, I think it is reasonable for the > NumberFormatEx