Re: Inconsistency in Constructor.getGenericParameterTypes()

2021-02-26 Thread Joe Darcy
Hello Oliver, This is long-standing if surprising and under-documented behavior. The getGenericFoo methods, when generic type information is present, give a source-level view of the element. At a source level, the implicit outer this parameter is not present and thus omitted by

Re: RFR: 8173970: jar tool should have a way to extract to a directory

2021-02-26 Thread Jaikiran Pai
On 27/02/21 1:17 am, Lance Andersen wrote: I believe this would also warrant a CSR to be created as well as updates to the jar man page. I haven't created a CSR before, so I will need some guidance on that part. Is it usually created after all the implementation details have been

Re: RFR: 8248862: Implement Enhanced Pseudo-Random Number Generators [v25]

2021-02-26 Thread Roger Riggs
On Tue, 23 Feb 2021 16:47:59 GMT, Jim Laskey wrote: >> 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

Re: RFR: 8248862: Implement Enhanced Pseudo-Random Number Generators [v3]

2021-02-26 Thread Roger Riggs
On Wed, 25 Nov 2020 16:22:32 GMT, Jim Laskey wrote: >> src/java.base/share/classes/java/util/random/RandomGeneratorFactory.java >> line 106: >> >>> 104: * Map of provider classes. >>> 105: */ >>> 106: private static volatile Map>> RandomGenerator>> factoryMap; >> >> should be

Re: Inconsistency in Constructor.getGenericParameterTypes()

2021-02-26 Thread Oliver Drotbohm
Hi Joe, thanks for the explanation. We switched to rather iterating over ….getParameters() and take it from there. Do you think it makes sense to leave a note about this in the Javadoc? Cheers, Ollie > Am 26.02.2021 um 22:38 schrieb Joe Darcy : > > Hello Oliver, > > This is long-standing if

Re: RFR: 8262096: Vector API fails to work due to VectorShape initialization exception [v5]

2021-02-26 Thread Jie Fu
> Hi all, > > Vector API fails to work when: > - case 1: MaxVectorSize is set to <=8, or > - case 2: C2 is disabled > > The reason is that {max/preferred} VectorShape initialization fails in both > cases. > And the root cause is that VectorSupport_GetMaxLaneCount [1] returns > unreasonable

Re: RFR: 8173970: jar tool should have a way to extract to a directory

2021-02-26 Thread Jaikiran Pai
Hello Lance, On 27/02/21 1:17 am, Lance Andersen wrote: p.s. I think it would be useful in the future to start the discussion on core-libs-dev prior to creating a PR (or leave it as a draft PR) for a feature request. Thank you for that input, I'll keep that in mind for any similar work in

Re: RFR: 6323374: (coll) Optimize Collections.unmodifiable* and synchronized* [v5]

2021-02-26 Thread Stuart Marks
On Fri, 26 Feb 2021 20:15:19 GMT, Ian Graves wrote: >> Modify the `unmodifiable*` methods in `java.util.Collections` to be >> idempotent. That is, when given an immutable collection from >> `java.util.ImmutableCollections` or `java.util.Collections`, these methods >> will return the reference

Re: RFR: 8262096: Vector API fails to work due to VectorShape initialization exception [v4]

2021-02-26 Thread Jie Fu
On Fri, 26 Feb 2021 15:48:18 GMT, Vladimir Ivanov wrote: > > I'd like to keep DoubleVector.SPECIES_PREFERRED.length() <= > > VectorSupport.getMaxLaneCount(double.class) for Java programmers since the > > VectorSupport_GetMaxLaneCount is used to implement a Java API. > > It doesn't make much

Re: RFR: JDK-8262199: issue in jli args.c [v5]

2021-02-26 Thread Alan Bateman
On Fri, 26 Feb 2021 08:31:00 GMT, Matthias Baesken wrote: >> Sonar reports a finding in args.c, where a file check is done . >> Stat performs a check on file, and later fopen is called on the file . >> >> The coding could be slightly rewritten so that the potential issue is >> removed (however

Re: RFR: JDK-8262199: issue in jli args.c [v5]

2021-02-26 Thread Matthias Baesken
> Sonar reports a finding in args.c, where a file check is done . > Stat performs a check on file, and later fopen is called on the file . > > The coding could be slightly rewritten so that the potential issue is removed > (however I do not think that it is such a big issue). Matthias Baesken

Re: RFR: JDK-8262199: issue in jli args.c [v3]

2021-02-26 Thread Matthias Baesken
On Thu, 25 Feb 2021 17:46:42 GMT, Christoph Langer wrote: >> I think that did not work because it does not fit the param types of >> reportAndExit but I can simplify it otherwise. > > Ah, I see. > Maybe it's a bit bike-sheddy but as you're using reportAndExit only twice > now, wouldn't it be

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

2021-02-26 Thread Peter Levart
On Thu, 25 Feb 2021 15:37:39 GMT, Aleksey Shipilev wrote: >> Attila Szegedi has refreshed the contents of this pull request, and previous >> commits have been removed. The incremental views will show differences >> compared to the previous content of the PR. > > The good test would be trying

Re: RFR: 8261670: Add javadoc for the XML processing limits [v3]

2021-02-26 Thread Joe Wang
> Add the documentation for XML processing limits to module summary. The limits > were previously documented in Java tutorial and guide. Joe Wang has updated the pull request incrementally with one additional commit since the last revision: s/NumericFormatException/NumberFormatException,

Re: RFR: JDK-8262199: issue in jli args.c [v5]

2021-02-26 Thread Christoph Langer
On Fri, 26 Feb 2021 08:31:00 GMT, Matthias Baesken wrote: >> Sonar reports a finding in args.c, where a file check is done . >> Stat performs a check on file, and later fopen is called on the file . >> >> The coding could be slightly rewritten so that the potential issue is >> removed (however

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

2021-02-26 Thread Anton Kozlov
> 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 new calling convention (subtasks > JDK-8253817, JDK-8253818)

Re: RFR: 8261670: Add javadoc for the XML processing limits [v3]

2021-02-26 Thread Lance Andersen
On Fri, 26 Feb 2021 08:04:02 GMT, Joe Wang wrote: >> Add the documentation for XML processing limits to module summary. The >> limits were previously documented in Java tutorial and guide. > > Joe Wang has updated the pull request incrementally with one additional > commit since the last

Integrated: JDK-8262199: issue in jli args.c

2021-02-26 Thread Matthias Baesken
On Tue, 23 Feb 2021 13:58:03 GMT, Matthias Baesken wrote: > Sonar reports a finding in args.c, where a file check is done . > Stat performs a check on file, and later fopen is called on the file . > > The coding could be slightly rewritten so that the potential issue is removed > (however I do

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

2021-02-26 Thread Vladimir Kempik
On Tue, 2 Feb 2021 23:07:08 GMT, Daniel D. Daugherty wrote: >> Anton Kozlov has updated the pull request incrementally with one additional >> commit since the last revision: >> >> support macos_aarch64 in hsdis > > src/java.base/macosx/native/libjli/java_md_macosx.m line 210: > >> 208:

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

2021-02-26 Thread Anton Kozlov
> 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 new calling convention (subtasks > JDK-8253817, JDK-8253818)

Re: RFR: 8248862: Implement Enhanced Pseudo-Random Number Generators

2021-02-26 Thread Jim Laskey
On Mon, 4 Jan 2021 13:54:14 GMT, Jim Laskey wrote: >> 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

Re: RFR: 8248862: Implement Enhanced Pseudo-Random Number Generators

2021-02-26 Thread Rémi Forax
On Fri, 26 Feb 2021 13:13:19 GMT, Jim Laskey wrote: >> Stayin' alive > > Looking for some final code reviews. I still don't like the fact that the factory uses reflection but i don't see how to do better - PR: https://git.openjdk.java.net/jdk/pull/1292

Inconsistency in Constructor.getGenericParameterTypes()

2021-02-26 Thread Oliver Drotbohm
Previously sent to the wrong list. Sorry for the double post. Von: Oliver Drotbohm Betreff: Inconsistency in Constructor.getGenericParameterTypes() Datum: 25. Februar 2021 um 10:03:12 MEZ An: jdk-...@openjdk.java.net Hi all, we've just ran into the following issue: for a non-static, generic

Re: RFR: 8262096: Vector API fails to work due to VectorShape initialization exception [v4]

2021-02-26 Thread Vladimir Ivanov
On Fri, 26 Feb 2021 02:38:00 GMT, Jie Fu wrote: >> Hi all, >> >> Vector API fails to work when: >> - case 1: MaxVectorSize is set to <=8, or >> - case 2: C2 is disabled >> >> The reason is that {max/preferred} VectorShape initialization fails in both >> cases. >> And the root cause is that

Re: RFR: 8261670: Add javadoc for the XML processing limits [v3]

2021-02-26 Thread Iris Clark
On Fri, 26 Feb 2021 08:04:02 GMT, Joe Wang wrote: >> Add the documentation for XML processing limits to module summary. The >> limits were previously documented in Java tutorial and guide. > > Joe Wang has updated the pull request incrementally with one additional > commit since the last

Re: RFR: 8262096: Vector API fails to work due to VectorShape initialization exception [v4]

2021-02-26 Thread Vladimir Ivanov
On Fri, 26 Feb 2021 15:37:08 GMT, Jie Fu wrote: > I'd like to keep DoubleVector.SPECIES_PREFERRED.length() <= > VectorSupport.getMaxLaneCount(double.class) for Java programmers since the > VectorSupport_GetMaxLaneCount is used to implement a Java API. It doesn't make much sense to me.

Re: RFR: 8261670: Add javadoc for the XML processing limits [v3]

2021-02-26 Thread Naoto Sato
On Fri, 26 Feb 2021 08:04:02 GMT, Joe Wang wrote: >> Add the documentation for XML processing limits to module summary. The >> limits were previously documented in Java tutorial and guide. > > Joe Wang has updated the pull request incrementally with one additional > commit since the last

RFR: 8260869: Test java/foreign/TestHandshake.java fails intermittently

2021-02-26 Thread Maurizio Cimadamore
This simple fix reduces the amount of concurrency on the foreign memory TestHandshake test. As this test spins a new accessor thread for each available processors, on machines which feature an high number of available processors (because of multi-threading), and which are slower in forking new

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

2021-02-26 Thread daniel . daugherty
On 2/26/21 7:55 AM, Vladimir Kempik wrote: On Tue, 2 Feb 2021 23:07:08 GMT, Daniel D. Daugherty wrote: Anton Kozlov has updated the pull request incrementally with one additional commit since the last revision: support macos_aarch64 in hsdis

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

2021-02-26 Thread erik . joelsson
On 2021-02-26 06:37, daniel.daughe...@oracle.com wrote: On 2/26/21 7:55 AM, Vladimir Kempik wrote: On Tue, 2 Feb 2021 23:07:08 GMT, Daniel D. Daugherty wrote: Anton Kozlov has updated the pull request incrementally with one additional commit since the last revision:    support

Re: RFR: 8262096: Vector API fails to work due to VectorShape initialization exception [v4]

2021-02-26 Thread Jie Fu
On Fri, 26 Feb 2021 13:55:15 GMT, Vladimir Ivanov wrote: > IMO the fix should be in > `src/jdk.incubator.vector/share/classes/jdk/incubator/vector/VectorShape.java`. > > JVM does the right job when it signals vector support is absent (by returning > `-1`). > > `jdk.incubator.vector`

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

2021-02-26 Thread Anton Kozlov
> 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 new calling convention (subtasks > JDK-8253817, JDK-8253818)

Re: RFR: 6323374: (coll) Optimize Collections.unmodifiable* and synchronized* [v5]

2021-02-26 Thread Ian Graves
> Modify the `unmodifiable*` methods in `java.util.Collections` to be > idempotent. That is, when given an immutable collection from > `java.util.ImmutableCollections` or `java.util.Collections`, these methods > will return the reference instead of creating a new immutable collection that >

Re: RFR: 6323374: (coll) Optimize Collections.unmodifiable* and synchronized* [v4]

2021-02-26 Thread Ian Graves
On Wed, 24 Feb 2021 01:58:48 GMT, Stuart Marks wrote: >>> Is there any behavior change here that merits a CSR review? >> >> Yes. See my comments in the bug report: >> >>

Re: RFR: 8173970: jar tool should have a way to extract to a directory

2021-02-26 Thread Lance Andersen
Hi Jaikiran, Thank you for the proposed patch. Assuming there is consensus to add support for this enhancement, I think we need to discuss what is the correct option. The jar tool borrows -C from tar for creating/updating a jar and the -C option is also a valid option when extracting files

RFR: 8173970: jar tool should have a way to extract to a directory

2021-02-26 Thread Jaikiran Pai
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

RFR: JDK-8262471: Fix coding style in src/java.base/share/classes/java/lang/CharacterDataPrivateUse.java

2021-02-26 Thread Christoph Göttschkes
Please review this small patch which fixes the coding style of CharacterDataPrivateUse.java - Commit messages: - Fixes coding style. Changes: https://git.openjdk.java.net/jdk/pull/2754/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk=2754=00 Issue:

Re: RFR: 8260869: Test java/foreign/TestHandshake.java fails intermittently

2021-02-26 Thread Paul Sandoz
On Fri, 26 Feb 2021 14:25:09 GMT, Maurizio Cimadamore wrote: > This simple fix reduces the amount of concurrency on the foreign memory > TestHandshake test. As this test spins a new accessor thread for each > available processors, on machines which feature an high number of available >