Re: RFR: 8264091: Use the blessed modifier order in java.logging

2021-03-23 Thread Iris Clark
On Tue, 23 Mar 2021 21:41:32 GMT, Alex Blewitt wrote: > 8264091: Use the blessed modifier order in java.logging Marked as reviewed by iris (Reviewer). - PR: https://git.openjdk.java.net/jdk/pull/3163

Re: RFR: 8264091: Use the blessed modifier order in java.logging

2021-03-23 Thread Lance Andersen
On Tue, 23 Mar 2021 21:41:32 GMT, Alex Blewitt wrote: > 8264091: Use the blessed modifier order in java.logging Marked as reviewed by lancea (Reviewer). - PR: https://git.openjdk.java.net/jdk/pull/3163

Re: RFR: 8264029: Replace uses of StringBuffer with StringBuilder in java.base

2021-03-23 Thread Pavel Rappo
On Tue, 23 Mar 2021 20:44:17 GMT, Andrey Turbanov wrote: >> src/java.base/share/classes/java/lang/invoke/MethodHandleImpl.java line 1954: >> >>> 1952: for (int i = 0; i < 4; ++i) { >>> 1953: if (i > 0) { >>> 1954: sb.append(" "); >> >>

Integrated: JDK-8264055: backout JDK-8248904 in order to resubmit with additional attribution.

2021-03-23 Thread Andy Herrick
On Tue, 23 Mar 2021 17:09:20 GMT, Andy Herrick wrote: > We are backing out the fix to "JDK-8248904 Add support to jpackage for the > Mac App Store " in order to resubmit with added contributor attribution for > Erwin Morrhey > This is the backout. This pull request has now been integrated.

RFR: 8264091: Use the blessed modifier order in java.logging

2021-03-23 Thread Alex Blewitt
8264091: Use the blessed modifier order in java.logging - Commit messages: - 8264091: Use the blessed modifier order in java.logging Changes: https://git.openjdk.java.net/jdk/pull/3163/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk=3163=00 Issue:

Re: RFR: JDK-8264055: backout JDK-8248904 in order to resubmit with additional attribution.

2021-03-23 Thread Alexey Semenyuk
On Tue, 23 Mar 2021 17:09:20 GMT, Andy Herrick wrote: > We are backing out the fix to "JDK-8248904 Add support to jpackage for the > Mac App Store " in order to resubmit with added contributor attribution for > Erwin Morrhey > This is the backout. Marked as reviewed by asemenyuk (Reviewer).

Integrated: 8263903: Use Cleaner instead of finalize to auto stop Timer thread

2021-03-23 Thread Kim Barrett
On Sun, 21 Mar 2021 03:53:24 GMT, Kim Barrett wrote: > Please review this change to java.util.Timer, replacing the use of deprecated > finalization-based cleanup with use of java.lang.ref.Cleaner. > > In addition, Timer.cancel now cancels any later execution of the the no > longer relevant

Re: RFR: 8263903: Use Cleaner instead of finalize to auto stop Timer thread [v4]

2021-03-23 Thread Kim Barrett
> Please review this change to java.util.Timer, replacing the use of deprecated > finalization-based cleanup with use of java.lang.ref.Cleaner. > > In addition, Timer.cancel now cancels any later execution of the the no > longer relevant cleanup. > > Testing: > mach5 tier1 > New AutoStop test

Re: RFR: 8263903: Use Cleaner instead of finalize to auto stop Timer thread [v3]

2021-03-23 Thread Kim Barrett
On Tue, 23 Mar 2021 18:36:24 GMT, Brent Christian wrote: >> Kim Barrett has updated the pull request incrementally with one additional >> commit since the last revision: >> >> make ThreadReaper constructor non-public > > Marked as reviewed by bchristi (Reviewer). Thanks all for reviews.

Re: RFR: 8264029: Replace uses of StringBuffer with StringBuilder in java.base

2021-03-23 Thread Andrey Turbanov
On Tue, 23 Mar 2021 12:38:06 GMT, Pavel Rappo wrote: >> Found by IntelliJ IDEA inspection `Java | Java language level migration aids >> | Java 5 | 'StringBuffer' may be 'StringBuilder'` >> As suggested in >> https://github.com/openjdk/jdk/pull/1507#issuecomment-757369003 I've created >>

Re: RFR: JDK-8264055: backout JDK-8248904 in order to resubmit with additional attribution.

2021-03-23 Thread Victor Dyakov
On Tue, 23 Mar 2021 19:40:38 GMT, Kevin Rushforth wrote: >>> Looks good, although i see the following wasn't backed out: >>> >>> ``` >>> src/jdk.jpackage/macosx/classes/jdk/jpackage/internal/resources/JavaApp.icns >>> ``` >> >> yes - look again - it was renamed back to java.icns (the 12'th or

Re: RFR: JDK-8264055: backout JDK-8248904 in order to resubmit with additional attribution.

2021-03-23 Thread Victor Dyakov
On Tue, 23 Mar 2021 20:42:22 GMT, Victor Dyakov wrote: >> As long as there are no transient build/test failures, it will be fine. I >> was just comparing the results with what `git revert >> 11c8c78c47f21fcd87a5969a859b5c4fced5e47d` generated and noticed this >> difference. > > @sashamatveev

Re: RFR: JDK-8264055: backout JDK-8248904 in order to resubmit with additional attribution.

2021-03-23 Thread Kevin Rushforth
On Tue, 23 Mar 2021 18:17:00 GMT, Andy Herrick wrote: >> Looks good, although i see the following wasn't backed out: >> >> src/jdk.jpackage/macosx/classes/jdk/jpackage/internal/resources/JavaApp.icns >> >> If this is intentional, then no need to worry about it. > >> Looks good, although i see

Re: RFR: 8263903: Use Cleaner instead of finalize to auto stop Timer thread [v3]

2021-03-23 Thread Brent Christian
On Tue, 23 Mar 2021 01:03:55 GMT, Kim Barrett wrote: >> Please review this change to java.util.Timer, replacing the use of >> deprecated finalization-based cleanup with use of java.lang.ref.Cleaner. >> >> In addition, Timer.cancel now cancels any later execution of the the no >> longer

Re: RFR: 8264019: Use the blessed modifier order in java.xml

2021-03-23 Thread Alex Blewitt
On Tue, 23 Mar 2021 17:19:10 GMT, Joe Wang wrote: >> The JDK's copy of the xalan and xerces code has diverged significantly from >> upstream so maybe this change is okay, Joe Wang can say. > > Hi Alex, thanks for looking into this. As Alan mentioned, these code came > from Apache, while we've

Withdrawn: 8264019: Use the blessed modifier order in java.xml

2021-03-23 Thread Alex Blewitt
On Fri, 19 Mar 2021 16:17:40 GMT, Alex Blewitt wrote: > As a subtask of JDK-8263854 this cleans up the `java.xml` module to used the > blessed modifier order. This pull request has been closed without being integrated. - PR: https://git.openjdk.java.net/jdk/pull/3091

Re: RFR: JDK-8264055: backout JDK-8248904 in order to resubmit with additional attribution.

2021-03-23 Thread Andy Herrick
On Tue, 23 Mar 2021 17:55:24 GMT, Kevin Rushforth wrote: > Looks good, although i see the following wasn't backed out: > > ``` > src/jdk.jpackage/macosx/classes/jdk/jpackage/internal/resources/JavaApp.icns > ``` yes - look again - it was renamed back to java.icns (the 12'th or 22 files

Re: Looking for a starter task. Maybe JDK-8253396 (Please add `not()` method to `java.util.function.BiPredicate`)?

2021-03-23 Thread Johannes Kuhn
Hi and welcome. I would not consider JDK-8253396 (Please add `not()` method to `java.util.function.BiPredicate`) a good starter bug. Generally, any bug that tries to add new APIs are hard, and require a lot of time and effort. While the implementation of

Re: RFR: JDK-8264055: backout JDK-8248904 in order to resubmit with additional attribution.

2021-03-23 Thread Kevin Rushforth
On Tue, 23 Mar 2021 17:09:20 GMT, Andy Herrick wrote: > We are backing out the fix to "JDK-8248904 Add support to jpackage for the > Mac App Store " in order to resubmit with added contributor attribution for > Erwin Morrhey > This is the backout. Looks good, although i see the following

Re: RFR: 8263903: Use Cleaner instead of finalize to auto stop Timer thread [v3]

2021-03-23 Thread Mandy Chung
On Tue, 23 Mar 2021 01:03:55 GMT, Kim Barrett wrote: >> Please review this change to java.util.Timer, replacing the use of >> deprecated finalization-based cleanup with use of java.lang.ref.Cleaner. >> >> In addition, Timer.cancel now cancels any later execution of the the no >> longer

Re: RFR: 8264019: Use the blessed modifier order in java.xml

2021-03-23 Thread Joe Wang
On Tue, 23 Mar 2021 07:24:47 GMT, Alan Bateman wrote: >> Sure, here it is: https://bugs.openjdk.java.net/browse/JDK-8264019 > > The JDK's copy of the xalan and xerces code has diverged significantly from > upstream so maybe this change is okay, Joe Wang can say. Hi Alex, thanks for looking

RFR: JDK-8264055: backout JDK-8248904 in order to resubmit with additional attribution.

2021-03-23 Thread Andy Herrick
We are backing out the fix to "JDK-8248904 Add support to jpackage for the Mac App Store " in order to resubmit with added contributor attribution for Erwin Morrhey This is the backout. - Commit messages: - JDK-8264055: backout JDK-8248904 in order to resubmit with additional

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

2021-03-23 Thread Andrew Haley
On Tue, 23 Mar 2021 16:20:47 GMT, Ludovic Henry wrote: >> Anton Kozlov has updated the pull request with a new target base due to a >> merge or a rebase. The pull request now contains 115 commits: >> >> - Merge branch 'master' into jdk-macos >> - JDK-8262491: bsd_aarch64 part >> -

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

2021-03-23 Thread Ludovic Henry
On Mon, 22 Mar 2021 12:50:14 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

Integrated: 8251942: PrintStream specification is not clear which flush method is automatically invoked

2021-03-23 Thread Brian Burkhalter
On Wed, 10 Mar 2021 23:03:03 GMT, Brian Burkhalter wrote: > Please review this minor change to the specification of > `java.io.PrintStream`. The longstanding behavior for flushing is to invoke > the `flush()` method of the underlying `OutputStream` rather than its > override but this was not

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

2021-03-23 Thread Monica Beckwith
On Mon, 22 Mar 2021 12:50:14 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

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

2021-03-23 Thread Monica Beckwith
On Tue, 23 Mar 2021 14:01:12 GMT, Vladimir Kempik wrote: > > > [ Back-porting this patch to JDK 11] depends on the will of openjdk11 > > > maintainers to accept this (and few other, like jep-388, as we depend on > > > it) contribution. > > > > > > To the extent that 11u has fixed policies :)

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

2021-03-23 Thread Vladimir Kempik
On Tue, 23 Mar 2021 13:58:03 GMT, Andrew Haley wrote: > > [ Back-porting this patch to JDK 11] depends on the will of openjdk11 > > maintainers to accept this (and few other, like jep-388, as we depend on > > it) contribution. > > To the extent that 11u has fixed policies :) we definitely

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

2021-03-23 Thread Andrew Haley
On Tue, 23 Mar 2021 13:54:24 GMT, Andrew Haley wrote: >> Anton Kozlov has updated the pull request with a new target base due to a >> merge or a rebase. The pull request now contains 115 commits: >> >> - Merge branch 'master' into jdk-macos >> - JDK-8262491: bsd_aarch64 part >> -

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

2021-03-23 Thread Andrew Haley
On Mon, 22 Mar 2021 12:50:14 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

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

2021-03-23 Thread Vladimir Kempik
On Tue, 23 Mar 2021 13:26:19 GMT, Anton Kozlov wrote: >> Build changes still look good. Hope you can get this done now! :) > >> > No, no, no! I am not suggesting you change anything else, just that >> > you do not define contentless macros. You might as well define it >> > to be something, and

Re: RFR: 8263903: Use Cleaner instead of finalize to auto stop Timer thread [v3]

2021-03-23 Thread Roger Riggs
On Tue, 23 Mar 2021 01:03:55 GMT, Kim Barrett wrote: >> Please review this change to java.util.Timer, replacing the use of >> deprecated finalization-based cleanup with use of java.lang.ref.Cleaner. >> >> In addition, Timer.cancel now cancels any later execution of the the no >> longer

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

2021-03-23 Thread Anton Kozlov
On Tue, 23 Mar 2021 12:49:34 GMT, Magnus Ihse Bursie wrote: >> Anton Kozlov has updated the pull request with a new target base due to a >> merge or a rebase. The pull request now contains 115 commits: >> >> - Merge branch 'master' into jdk-macos >> - JDK-8262491: bsd_aarch64 part >> -

Integrated: 8264032: Improve thread safety of Runtime.version()

2021-03-23 Thread Andrey Turbanov
On Tue, 23 Feb 2021 13:23:44 GMT, Andrey Turbanov wrote: > Avoid double-read non volatile static field This pull request has now been integrated. Changeset: 23353626 Author:Andrey Turbanov Committer: Aleksey Shipilev URL: https://git.openjdk.java.net/jdk/commit/23353626 Stats:

Re: RFR: 8264032: Improve thread safety of Runtime.version()

2021-03-23 Thread Alan Bateman
On Tue, 23 Feb 2021 13:23:44 GMT, Andrey Turbanov wrote: > Avoid double-read non volatile static field Marked as reviewed by alanb (Reviewer). - PR: https://git.openjdk.java.net/jdk/pull/2691

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

2021-03-23 Thread Erik Joelsson
On Mon, 22 Mar 2021 12:50:14 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

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

2021-03-23 Thread Magnus Ihse Bursie
On Mon, 22 Mar 2021 12:50:14 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

Re: RFR: 8264029: Replace uses of StringBuffer with StringBuilder in java.base

2021-03-23 Thread Pavel Rappo
On Wed, 10 Mar 2021 19:47:00 GMT, Andrey Turbanov wrote: > Found by IntelliJ IDEA inspection `Java | Java language level migration aids > | Java 5 | 'StringBuffer' may be 'StringBuilder'` > As suggested in > https://github.com/openjdk/jdk/pull/1507#issuecomment-757369003 I've created >

Re: RFR: 8264032: Improve thread safety of Runtime.version()

2021-03-23 Thread liach
On Tue, 23 Feb 2021 16:46:06 GMT, Andrey Turbanov wrote: > There are 2 separate reads of fields. First can return non-null value, while > second still can get null Can this really happen? If this `version` field has been updated, its value is definitely no longer `null`. And before the

Re: RFR: 8264032: Improve thread safety of Runtime.version()

2021-03-23 Thread Andrey Turbanov
On Tue, 23 Feb 2021 16:59:45 GMT, liach wrote: >>>This shouldn't be a problem. >> >> What do you mean by "this"? Double racy read? >> There are 2 separate reads of fields. First can return non-null value, while >> second still can get `null` > >> There are 2 separate reads of fields. First

RFR: 8264032: Improve thread safety of Runtime.version()

2021-03-23 Thread Andrey Turbanov
Avoid double-read non volatile static field - Commit messages: - [PATCH] Thread-safe initialization of Runtime.version Changes: https://git.openjdk.java.net/jdk/pull/2691/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk=2691=00 Issue:

Re: RFR: 8264032: Improve thread safety of Runtime.version()

2021-03-23 Thread Andrey Turbanov
On Tue, 23 Feb 2021 16:13:21 GMT, liach wrote: >This shouldn't be a problem. What do you mean by "this"? Double racy read? There are 2 separate reads of fields. First can return non-null value, while second still can get `null` > src/java.base/share/classes/java/lang/Runtime.java line 824: >

Re: RFR: 8264032: Improve thread safety of Runtime.version()

2021-03-23 Thread Aleksey Shipilev
On Tue, 23 Feb 2021 13:23:44 GMT, Andrey Turbanov wrote: > Avoid double-read non volatile static field This looks fine to me. I created the bug for this: https://bugs.openjdk.java.net/browse/JDK-8264032 -- please change the PR synopsis to "8264032: Improve thread safety of

Re: RFR: 8264032: Improve thread safety of Runtime.version()

2021-03-23 Thread liach
On Tue, 23 Feb 2021 13:23:44 GMT, Andrey Turbanov wrote: > Avoid double-read non volatile static field This shouldn't be a problem. Version is a pojo and value based, and the computed result may be different instances but would return `true` for `equals` and should have no problems

RFR: 8264029: Replace uses of StringBuffer with StringBuilder in java.base

2021-03-23 Thread Andrey Turbanov
Found by IntelliJ IDEA inspection `Java | Java language level migration aids | Java 5 | 'StringBuffer' may be 'StringBuilder'` As suggested in https://github.com/openjdk/jdk/pull/1507#issuecomment-757369003 I've created separate PR for module `java.base` Similar cleanup in the past -

Re: RFR: 8264029: Replace uses of StringBuffer with StringBuilder in java.base

2021-03-23 Thread Aleksey Shipilev
On Wed, 10 Mar 2021 19:47:00 GMT, Andrey Turbanov wrote: > Found by IntelliJ IDEA inspection `Java | Java language level migration aids > | Java 5 | 'StringBuffer' may be 'StringBuilder'` > As suggested in > https://github.com/openjdk/jdk/pull/1507#issuecomment-757369003 I've created >

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

2021-03-23 Thread Jim Laskey
> 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 found at >

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

2021-03-23 Thread Vladimir Kempik
On Tue, 23 Mar 2021 09:54:16 GMT, Andrew Haley wrote: > So, where are we up to now? Are we done yet? Hello we would like to get approval for the final version we have now and then integrate this pr as soon as Mark will target it to jdk17 - PR:

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

2021-03-23 Thread Andrew Haley
On Fri, 12 Mar 2021 16:32:10 GMT, Andrew Haley wrote: >> Anton Kozlov has updated the pull request with a new target base due to a >> merge or a rebase. The pull request now contains 105 commits: >> >> - Merge commit 'refs/pull/11/head' of https://github.com/AntonKozlov/jdk >> into jdk-macos

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

2021-03-23 Thread Andrew Haley
On Tue, 23 Mar 2021 09:53:54 GMT, Andrew Haley wrote: >>> @theRealAph, could you elaborate on what is need to be done for [#2200 >>> (review)](https://github.com/openjdk/jdk/pull/2200#pullrequestreview-600597066). >> >> I think that what you've got now is fine. > >> _Mailing list message from

Re: RFR: 8263968: CDS: java/lang/ModuleLayer.EMPTY_LAYER should be singleton [v2]

2021-03-23 Thread Alan Bateman
On Tue, 23 Mar 2021 08:04:09 GMT, Aleksei Voitylov wrote: >> With CDS and G1, test api/java_lang/ModuleLayer/Boot.html fails in JDK 16. >> >> After JDK-8253081 with CDS enabled two instances of empty layer appear in >> the runtime. One comes from default initialization of >>

Re: RFR: 8263968: CDS: java/lang/ModuleLayer.EMPTY_LAYER should be singleton [v2]

2021-03-23 Thread Aleksei Voitylov
On Tue, 23 Mar 2021 06:47:50 GMT, Alan Bateman wrote: >> Aleksei Voitylov has updated the pull request incrementally with one >> additional commit since the last revision: >> >> fix style > > src/java.base/share/classes/java/lang/ModuleLayer.java line 156: > >> 154: >> 155: static { >>

Re: RFR: 8263968: CDS: java/lang/ModuleLayer.EMPTY_LAYER should be singleton [v2]

2021-03-23 Thread Aleksei Voitylov
> With CDS and G1, test api/java_lang/ModuleLayer/Boot.html fails in JDK 16. > > After JDK-8253081 with CDS enabled two instances of empty layer appear in the > runtime. One comes from default initialization of > java/lang/ModuleLayer.EMPTY_LAYER, another one comes from CDS archive and is >

Re: RFR: 8264019: Use the blessed modifier order in java.xml

2021-03-23 Thread Alan Bateman
On Tue, 23 Mar 2021 06:53:03 GMT, Aleksey Shipilev wrote: >> @shipilev would you mind creating a bug for me please? > > Sure, here it is: https://bugs.openjdk.java.net/browse/JDK-8264019 The JDK's copy of the xalan and xerces code has diverged significantly from upstream so maybe this change

Re: RFR: 8264019: Use the blessed modifier order in java.xml

2021-03-23 Thread Alex Blewitt
On Fri, 19 Mar 2021 23:40:00 GMT, Alex Blewitt wrote: >> As a subtask of JDK-8263854 this cleans up the `java.xml` module to used the >> blessed modifier order. > > Would someone mind creating a bug for me under the parent bug JDK-8263854? @shipilev would you mind creating a bug for me

Re: RFR: 8264019: Use the blessed modifier order in java.xml

2021-03-23 Thread Aleksey Shipilev
On Mon, 22 Mar 2021 20:55:55 GMT, Alex Blewitt wrote: >> Would someone mind creating a bug for me under the parent bug JDK-8263854? > > @shipilev would you mind creating a bug for me please? Sure, here it is: https://bugs.openjdk.java.net/browse/JDK-8264019 - PR:

Re: RFR: 8264019: Use the blessed modifier order in java.xml

2021-03-23 Thread Alex Blewitt
On Fri, 19 Mar 2021 16:17:40 GMT, Alex Blewitt wrote: > As a subtask of JDK-8263854 this cleans up the `java.xml` module to used the > blessed modifier order. Would someone mind creating a bug for me under the parent bug JDK-8263854? - PR:

RFR: 8264019: Use the blessed modifier order in java.xml

2021-03-23 Thread Alex Blewitt
As a subtask of JDK-8263854 this cleans up the `java.xml` module to used the blessed modifier order. - Commit messages: - Reordered final static to static final - Use the blessed modifier order in java.xml Changes: https://git.openjdk.java.net/jdk/pull/3091/files Webrev:

Integrated: 8261673: Move javadoc for the lookup mechanism to module-info

2021-03-23 Thread Joe Wang
On Tue, 16 Mar 2021 00:52:24 GMT, Joe Wang wrote: > Consolidate and move javadoc for the lookup mechanism to the module summary. This pull request has now been integrated. Changeset: 289d48ae Author:Joe Wang URL: https://git.openjdk.java.net/jdk/commit/289d48ae Stats: 602 lines

Re: RFR: 8263903: Use Cleaner instead of finalize to auto stop Timer thread [v3]

2021-03-23 Thread Alan Bateman
On Tue, 23 Mar 2021 01:03:55 GMT, Kim Barrett wrote: >> Please review this change to java.util.Timer, replacing the use of >> deprecated finalization-based cleanup with use of java.lang.ref.Cleaner. >> >> In addition, Timer.cancel now cancels any later execution of the the no >> longer

Re: RFR: 8263968: CDS: java/lang/ModuleLayer.EMPTY_LAYER should be singleton

2021-03-23 Thread Alan Bateman
On Mon, 22 Mar 2021 19:40:19 GMT, Aleksei Voitylov wrote: > With CDS and G1, test api/java_lang/ModuleLayer/Boot.html fails in JDK 16. > > After JDK-8253081 with CDS enabled two instances of empty layer appear in the > runtime. One comes from default initialization of >