Re: JEP 416: Missing throws IllegalArgumentException declaration for Method::invoke?

Dear Alan, no issue at all, I just noticed in the API diff and wanted to understand whether this was on purpose. Also Thanks for the background information! -marc > On 11. Nov 2021, at 09:48, Alan Bateman wrote: > > On 11/11/2021 08:21, Marc Hoffmann wrote: >> Hi, >> >> with the

Integrated: 8275197: Remove unused fields in ThaiBuddhistChronology

On Tue, 12 Oct 2021 21:10:12 GMT, Andrey Turbanov wrote: > Remove 3 unused HashMap's. > Reported here > https://mail.openjdk.java.net/pipermail/core-libs-dev/2021-September/081866.html > I did the similar PR to treetenbp and it was merged > https://github.com/ThreeTen/threetenbp/pull/155 This

Re: RFR: 8277015: Use blessed modifier order in Panama code

On Thu, 11 Nov 2021 15:47:11 GMT, Maurizio Cimadamore wrote: >> I ran bin/blessed-modifier-order.sh on source owned by Project Panama. This >> scripts verifies that modifiers are in the "blessed" order, and fixes it >> otherwise. I have manually checked the changes made by the script to make

Re: RFR: 8271515: Integration of JEP 417: Vector API (Third Incubator) [v10]

> This PR improves the performance of vector operations that accept masks on > architectures that support masking in hardware, specifically Intel AVX512 and > ARM SVE. > > On architectures that do not support masking in hardware the same technique > as before is applied to most operations,

Re: RFR: 8277015: Use blessed modifier order in Panama code

On Thu, 11 Nov 2021 14:50:43 GMT, Magnus Ihse Bursie wrote: > I ran bin/blessed-modifier-order.sh on source owned by Project Panama. This > scripts verifies that modifiers are in the "blessed" order, and fixes it > otherwise. I have manually checked the changes made by the script to make >

Re: RFR: 8277015: Use blessed modifier order in Panama code

On Thu, 11 Nov 2021 20:22:25 GMT, Magnus Ihse Bursie wrote: > You could also do this directly in the Panama repo branches. I'll volunteer > to help, if you want. I'll run the script on the PR I've submitted for the Foreign API, and I will update that one - thanks. Perhaps @PaulSandoz can do

Integrated: 8276947: Clarify how DateTimeFormatterBuilder.appendFraction handles value ranges

On Wed, 10 Nov 2021 13:57:21 GMT, Claes Redestad wrote: > This changes the specification of `DateTimeFormatterBuilder.appendFraction` > to more clearly specify that the formatter will throw an exception if you > attempt to print a value outside of the value range of the given field. > Changes

Re: RFR: 8276947: Clarify how DateTimeFormatterBuilder.appendFraction handles value ranges

On Wed, 10 Nov 2021 13:57:21 GMT, Claes Redestad wrote: > This changes the specification of `DateTimeFormatterBuilder.appendFraction` > to more clearly specify that the formatter will throw an exception if you > attempt to print a value outside of the value range of the given field. > Changes

Re: RFR: 8276123: ZipFile::getEntry will not return a file entry when there is a directory entry of the same name within a Zip File [v2]

On Thu, 11 Nov 2021 17:19:04 GMT, Lance Andersen wrote: >> Hi all, >> >> This patch addresses a regression introduced in JDK 15 via JDK-8242959 where >> you can no longer access a file entry contained within a Zip file when there >> is also a directory entry with the same name via

Re: RFR: 8277015: Use blessed modifier order in Panama code

On Thu, 11 Nov 2021 14:50:43 GMT, Magnus Ihse Bursie wrote: > I ran bin/blessed-modifier-order.sh on source owned by Project Panama. This > scripts verifies that modifiers are in the "blessed" order, and fixes it > otherwise. I have manually checked the changes made by the script to make >

Re: RFR: 8277013: Allow creation of module graphs without defining modules to the VM

On Thu, 11 Nov 2021 14:53:13 GMT, Ivan Ristović wrote: > Related JBS issue: https://bugs.openjdk.java.net/browse/JDK-8277013 > > The GraalVM Native Image module support must create the runtime boot-module > layer at image build time; module instances created at build time need to > reflect

RFR: 8277013: Allow creation of module graphs without defining modules to the VM

Related JBS issue: https://bugs.openjdk.java.net/browse/JDK-8277013 The GraalVM Native Image module support must create the runtime boot-module layer at image build time; module instances created at build time need to reflect module relations at runtime, i.e., their opens, reads, and exports.

Re: RFR: 8276123: ZipFile::getEntry will not return a file entry when there is a directory entry of the same name within a Zip File [v2]

On Thu, 11 Nov 2021 12:04:46 GMT, Alan Bateman wrote: >> Lance Andersen has updated the pull request incrementally with one >> additional commit since the last revision: >> >> Address minor review comments > > test/jdk/java/util/zip/ZipFile/ZipFileDuplicateEntryTest.java line 176: > >> 174:

Re: RFR: 8276123: ZipFile::getEntry will not return a file entry when there is a directory entry of the same name within a Zip File [v2]

On Thu, 11 Nov 2021 12:50:30 GMT, Claes Redestad wrote: >> Thank you for that clarification. The "addSlash" param being "false" in the >> call below that comment is what made me think that the comment had a typo. I >> read that code in a bit more detail now and I see what that comment means.

Re: RFR: 8276123: ZipFile::getEntry will not return a file entry when there is a directory entry of the same name within a Zip File [v2]

> Hi all, > > This patch addresses a regression introduced in JDK 15 via JDK-8242959 where > you can no longer access a file entry contained within a Zip file when there > is also a directory entry with the same name via ZipFile:getEntry(). > > Once fixed, the behavior will be consistent

Re: RFR: 8271515: Integration of JEP 417: Vector API (Third Incubator) [v9]

> This PR improves the performance of vector operations that accept masks on > architectures that support masking in hardware, specifically Intel AVX512 and > ARM SVE. > > On architectures that do not support masking in hardware the same technique > as before is applied to most operations,

Re: RFR: 8277015: Use blessed modifier order in Panama code

On Thu, 11 Nov 2021 15:58:06 GMT, Magnus Ihse Bursie wrote: > This is by no means urgent. If it's more convenient for you to wait until > after the refresh, I can certainly do so. I guess there is a chance that after vector and foreign are re-incubated in 18, we might need to do this again.

Re: RFR: 8277015: Use blessed modifier order in Panama code

On Thu, 11 Nov 2021 14:50:43 GMT, Magnus Ihse Bursie wrote: > I ran bin/blessed-modifier-order.sh on source owned by Project Panama. This > scripts verifies that modifiers are in the "blessed" order, and fixes it > otherwise. I have manually checked the changes made by the script to make >

Re: RFR: 8277015: Use blessed modifier order in Panama code

On Thu, 11 Nov 2021 14:50:43 GMT, Magnus Ihse Bursie wrote: > I ran bin/blessed-modifier-order.sh on source owned by Project Panama. This > scripts verifies that modifiers are in the "blessed" order, and fixes it > otherwise. I have manually checked the changes made by the script to make >

Re: RFR: 8277015: Use blessed modifier order in Panama code

Hi Magnus, as we're in the process of integrating new API changes (see [1]) - would it be possible to postpone this? I'd like to minimize merge conflicts, if that makes sense. Thanks Maurizio [1] - https://github.com/openjdk/jdk/pull/5907 On 11/11/2021 14:57, Magnus Ihse Bursie wrote: I

Re: RFR: 8277015: Use blessed modifier order in Panama code

I assume this is relevant for panama-dev as well, but I can't unfortunately tag the issue as such in Github/Skara. (Maybe we should have a mapping for jdk.incubator.vector/foreign -> panama-dev?) /Magnus On 2021-11-11 15:57, Magnus Ihse Bursie wrote: I ran bin/blessed-modifier-order.sh on

RFR: 8277015: Use blessed modifier order in Panama code

I ran bin/blessed-modifier-order.sh on source owned by Project Panama. This scripts verifies that modifiers are in the "blessed" order, and fixes it otherwise. I have manually checked the changes made by the script to make sure they are sound. In this case, while the script did into the

Integrated: 8244202: Implementation of JEP 418: Internet-Address Resolution SPI

On Tue, 5 Oct 2021 12:00:15 GMT, Aleksei Efimov wrote: > This change implements a new service provider interface for host name and > address resolution, so that java.net.InetAddress API can make use of > resolvers other than the platform's built-in resolver. > > The following API classes are

RFR: JDK-8273056 java.util.random does not correctly sample exponential or Gaussian distributions

The modified ziggurat algorithm is not correctly implemented in `java.base/jdk/internal/util/random/RandomSupport.java`. Create a histogram of a million samples using 2000 uniform bins with the following range: Exponential range from 0 to 12. Gaussian range from -8 to 8. This does not pass

Re: RFR: 8275007: Java fails to start with null charset if LC_ALL is set to certain locales [v2]

On Tue, 9 Nov 2021 19:38:01 GMT, Naoto Sato wrote: >> Please review the subject fix. In light of JEP400, Java runtime can/should >> start in UTF-8 charset if the underlying native encoding is not supported. > > Naoto Sato has updated the pull request incrementally with one additional > commit

RFR: JDK-8277003 - JumpableGenerator.rngs() documentation refers to wrong method

Documentation in `RandomGenerator.rngs()` refers to `JumpableGenerator.jump()` when it should be `JumpableGenerator.jumps()` - Commit messages: - 8273792 - JumpableGenerator.rngs() documentation refers to wrong method Changes: https://git.openjdk.java.net/jdk/pull/6352/files

RFR: JDK-8274685 - Documentation suggests there are ArbitrarilyJumpableGenerator when none

"There is also an interface RandomGenerator.ArbitrarilyJumpableGenerator for algorithms that allow jumping along the state cycle by any user-specified distance. In this package, implementations of these interfaces include "Xoroshiro128PlusPlus", and "Xoshiro256PlusPlus" is incorrect.

Re: RFR: 8275063: Implementation of Foreign Function & Memory API (Second incubator) [v23]

> This PR contains the API and implementation changes for JEP-419 [1]. A more > detailed description of such changes, to avoid repetitions during the review > process, is included as a separate comment. > > [1] - https://openjdk.java.net/jeps/419 Maurizio Cimadamore has updated the pull

Re: RFR: 8276123: ZipFile::getEntry will not return a file entry when there is a directory entry of the same name within a Zip File

On Thu, 11 Nov 2021 12:25:38 GMT, Jaikiran Pai wrote: >> Hi Jaikiran, >> >> The comment is correct > > Thank you for that clarification. The "addSlash" param being "false" in the > call below that comment is what made me think that the comment had a typo. I > read that code in a bit more

Re: RFR: 8276123: ZipFile::getEntry will not return a file entry when there is a directory entry of the same name within a Zip File

On Thu, 11 Nov 2021 11:51:31 GMT, Lance Andersen wrote: >> src/java.base/share/classes/java/util/zip/ZipFile.java line 1642: >> >>> 1640: && entry.startsWith(name) && >>> 1641: entry.charAt(entryLen - 1) == '/') { >>> 1642:

Withdrawn: 8275728: Add simple Producer/Consumer microbenchmark for Thread.onSpinWait

On Wed, 10 Nov 2021 18:07:47 GMT, Evgeny Astigeevich wrote: > This is a microbenchmarks to demonstrate `Thread.onSpinWait` can be used to > avoid heavy locks. > The microbenchmark differs from [Gil's original > benchmark](https://github.com/giltene/GilExamples/tree/master/SpinWaitTest) > and

Re: RFR: 8276123: ZipFile::getEntry will not return a file entry when there is a directory entry of the same name within a Zip File

On Wed, 10 Nov 2021 20:51:20 GMT, Lance Andersen wrote: > Hi all, > > This patch addresses a regression introduced in JDK 15 via JDK-8242959 where > you can no longer access a file entry contained within a Zip file when there > is also a directory entry with the same name via

Re: RFR: 8276123: ZipFile::getEntry will not return a file entry when there is a directory entry of the same name within a Zip File

On Thu, 11 Nov 2021 02:14:50 GMT, Jaikiran Pai wrote: >> Hi all, >> >> This patch addresses a regression introduced in JDK 15 via JDK-8242959 where >> you can no longer access a file entry contained within a Zip file when there >> is also a directory entry with the same name via

Re: RFR: 8275007: Java fails to start with null charset if LC_ALL is set to certain locales [v2]

On Tue, 9 Nov 2021 19:38:01 GMT, Naoto Sato wrote: >> Please review the subject fix. In light of JEP400, Java runtime can/should >> start in UTF-8 charset if the underlying native encoding is not supported. > > Naoto Sato has updated the pull request incrementally with one additional > commit

Re: RFR: 8275007: Java fails to start with null charset if LC_ALL is set to certain locales [v2]

On Thu, 11 Nov 2021 09:40:14 GMT, Ichiroh Takiguchi wrote: > I don't have Oracle Linux... I tried to find out unsupported locales by using > following commands. I used RHEL7.9. In your previous post you used env LC_ALL=kk_KZ.pt154 java Hello.java. Would it be possible to repeat that with JDK

Re: RFR: 8244202: Implementation of JEP 418: Internet-Address Resolution SPI [v13]

> This change implements a new service provider interface for host name and > address resolution, so that java.net.InetAddress API can make use of > resolvers other than the platform's built-in resolver. > > The following API classes are added to `java.net.spi` package to facilitate > this: >

Re: RFR: 8275007: Java fails to start with null charset if LC_ALL is set to certain locales [v2]

On Tue, 9 Nov 2021 19:38:01 GMT, Naoto Sato wrote: >> Please review the subject fix. In light of JEP400, Java runtime can/should >> start in UTF-8 charset if the underlying native encoding is not supported. > > Naoto Sato has updated the pull request incrementally with one additional > commit

Re: RFR: 8244202: Implementation of JEP 418: Internet-Address Resolution SPI [v12]

On Wed, 3 Nov 2021 13:23:36 GMT, Aleksei Efimov wrote: >> This change implements a new service provider interface for host name and >> address resolution, so that java.net.InetAddress API can make use of >> resolvers other than the platform's built-in resolver. >> >> The following API classes

Re: JEP 416: Missing throws IllegalArgumentException declaration for Method::invoke?

On 11/11/2021 08:21, Marc Hoffmann wrote: Hi, with the implementation of JEP 416 (https://github.com/openjdk/jdk/commit/c6339cb8a255d387bb182ad20dd69f3d460cf1ed ) the throws declaration for

JEP 416: Missing throws IllegalArgumentException declaration for Method::invoke?

Hi, with the implementation of JEP 416 (https://github.com/openjdk/jdk/commit/c6339cb8a255d387bb182ad20dd69f3d460cf1ed ) the throws declaration for IllegalArgumentException on Method::invoke was removed — while it