Integrated: 8284161: Implementation of Virtual Threads (Preview)

2022-05-07 Thread Alan Bateman
On Fri, 8 Apr 2022 13:43:39 GMT, Alan Bateman wrote: > This is the implementation of JEP 425: Virtual Threads (Preview). > > We will refresh this PR periodically to pick up changes and fixes from the > loom repo. > > Most of the new mechanisms in the HotSpot VM are disabled by default and > r

Re: RFR: 8286294 : ForkJoinPool.commonPool().close() spins [v3]

2022-05-07 Thread Doug Lea
> Changes ForkJoinPool.close spec and code to trap close as a no-op if called > on common pool Doug Lea has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains

Re: RFR: 8286294 : ForkJoinPool.commonPool().close() spins [v4]

2022-05-07 Thread Doug Lea
> Changes ForkJoinPool.close spec and code to trap close as a no-op if called > on common pool Doug Lea has updated the pull request incrementally with three additional commits since the last revision: - Accommodate restrictive SecurityManagers - merge with loom updates Merge remote-tracki

Re: RFR: 8262889: Compiler implementation for Record Patterns [v3]

2022-05-07 Thread Jan Lahoda
> 8262889: Compiler implementation for Record Patterns > > A first version of a patch that introduces record patterns into javac as a > preview feature. For the specification, please see: > http://cr.openjdk.java.net/~gbierman/jep427+405/jep427+405-20220426/specs/patterns-switch-record-patterns-j

Re: RFR: 8283689: Update the foreign linker VM implementation [v4]

2022-05-07 Thread Jorn Vernee
> Hi, > > This PR updates the VM implementation of the foreign linker, by bringing over > commits from the panama-foreign repo. > > This is split off from the main JEP integration for 19, since we have limited > resources to handle this. As such, this PR might fall over to 20. > > I've written

Re: RFR: 8283689: Update the foreign linker VM implementation [v5]

2022-05-07 Thread Jorn Vernee
> Hi, > > This PR updates the VM implementation of the foreign linker, by bringing over > commits from the panama-foreign repo. > > This is split off from the main JEP integration for 19, since we have limited > resources to handle this. As such, this PR might fall over to 20. > > I've written

Re: RFR: 8283689: Update the foreign linker VM implementation [v6]

2022-05-07 Thread Jorn Vernee
> Hi, > > This PR updates the VM implementation of the foreign linker, by bringing over > commits from the panama-foreign repo. > > This is split off from the main JEP integration for 19, since we have limited > resources to handle this. As such, this PR might fall over to 20. > > I've written

Re: RFR: 8283689: Update the foreign linker VM implementation [v4]

2022-05-07 Thread Jorn Vernee
On Sat, 7 May 2022 12:51:12 GMT, Jorn Vernee wrote: >> Hi, >> >> This PR updates the VM implementation of the foreign linker, by bringing >> over commits from the panama-foreign repo. >> >> This is split off from the main JEP integration for 19, since we have >> limited resources to handle th

Re: RFR: 8286294 : ForkJoinPool.commonPool().close() spins [v4]

2022-05-07 Thread Martin Buchholz
On Sat, 7 May 2022 11:29:32 GMT, Doug Lea wrote: >> Changes ForkJoinPool.close spec and code to trap close as a no-op if called >> on common pool > > Doug Lea has updated the pull request incrementally with three additional > commits since the last revision: > > - Accommodate restrictive Secu

Re: RFR: 8286294 : ForkJoinPool.commonPool().close() spins [v4]

2022-05-07 Thread Martin Buchholz
On Sat, 7 May 2022 11:29:32 GMT, Doug Lea wrote: >> Changes ForkJoinPool.close spec and code to trap close as a no-op if called >> on common pool > > Doug Lea has updated the pull request incrementally with three additional > commits since the last revision: > > - Accommodate restrictive Secu

Re: RFR: JDK-6725221 Standardize obtaining boolean properties with defaults

2022-05-07 Thread Phil Race
On Thu, 5 May 2022 16:49:07 GMT, Mark Powers wrote: > JDK-6725221 Standardize obtaining boolean properties with defaults I did wonder why it has security-libs as the sub-category and if the intent was not what we see here. - PR: https://git.openjdk.java.net/jdk/pull/8559

Deprecating java.util.Date, java.util.Calendar and java.text.DateFormat and their subclasses

2022-05-07 Thread Victor Williams Stafusa da Silva
The java.time package was released in Java 8, far back in 2014, more than 8 years ago. It has been a long time since then. Before that, we had the dreadful infamous java.util.Date, java.util.Calendar, java.text.DateFormat and their subclasses java.sql.Date, java.sql.Time, java.sql.Timestamp, java.u

Re: RFR: JDK-6725221 Standardize obtaining boolean properties with defaults

2022-05-07 Thread Alan Bateman
On Sun, 8 May 2022 02:22:08 GMT, Phil Race wrote: > I did wonder why it has security-libs as the sub-category and if the intent > was not what we see here. I suspect the JBS issue was initially created to to look at the usages of getProperty in the security code but it has been extended. The i

Re: RFR: 8286294 : ForkJoinPool.commonPool().close() spins [v4]

2022-05-07 Thread Martin Buchholz
On Sat, 7 May 2022 11:29:32 GMT, Doug Lea wrote: >> Changes ForkJoinPool.close spec and code to trap close as a no-op if called >> on common pool > > Doug Lea has updated the pull request incrementally with three additional > commits since the last revision: > > - Accommodate restrictive Secu

Why does we still need StrictMath?

2022-05-07 Thread Victor Williams Stafusa da Silva
JEP 306 was already delivered some time ago. And with it, we get rid of the need of that nasty strictfp and the need to have both loose FP and strict FP. However, the class java.lang.StrictMath is still around as a normal class, almost mirroring java.lang.Math, and I really can't understand why.