Re: RFR: 8260555: Change the default TIMEOUT_FACTOR from 4 to 1 [v4]

2025-08-18 Thread Daniel Fuchs
On Mon, 18 Aug 2025 16:34:21 GMT, Leo Korinth wrote: >> This changes the timeout factor from 4 to 1. Most of the changes add >> timeouts to individual test cases so that I am able to run them with a >> timeout factor of 0.7 (some margin to the checked in factor of one) >> >> In addition to cha

Re: RFR: 8260555: Change the default TIMEOUT_FACTOR from 4 to 1 [v3]

2025-08-18 Thread Daniel Fuchs
On Fri, 15 Aug 2025 11:43:33 GMT, Leo Korinth wrote: >> This changes the timeout factor from 4 to 1. Most of the changes add >> timeouts to individual test cases so that I am able to run them with a >> timeout factor of 0.7 (some margin to the checked in factor of one) >> >> In addition to cha

Re: RFR: 8356171: Increase timeout for testcases as preparation for change of default timeout factor

2025-05-09 Thread Daniel Fuchs
On Fri, 9 May 2025 08:40:44 GMT, Leo Korinth wrote: > The whole idea of running with a timeout factor of `0.7` is to remove > intermittent failures. (I had it close to 0.5 or maybe less to begin with > until I found and reported CODETOOLS-7903937: JTREG uses timeout factor on > socket timeout

Re: RFR: 8356171: Increase timeout for testcases as preparation for change of default timeout factor

2025-05-09 Thread Daniel Fuchs
On Thu, 8 May 2025 17:41:02 GMT, Daniel Fuchs wrote: > Thank you. I have imported your PR locally and running some HTTP client tests > in the CI. > Tests have not finished running - but I already see one intermittent failure: > `java/net/httpclient/RedirectTimeoutTest.java` i

Re: RFR: 8356171: Increase timeout for testcases as preparation for change of default timeout factor

2025-05-08 Thread Daniel Fuchs
On Thu, 8 May 2025 14:51:24 GMT, Leo Korinth wrote: > This change tries to add timeout to individual testcases so that I am able to > run them with a timeout factor of 1 in the future (JDK-8260555). > > The first commit changes the timeout factor to 0.7, so that I can run tests > and test the

Re: RFR: 8356171: Increase timeout for testcases as preparation for change of default timeout factor

2025-05-08 Thread Daniel Fuchs
On Thu, 8 May 2025 14:51:24 GMT, Leo Korinth wrote: > This change tries to add timeout to individual testcases so that I am able to > run them with a timeout factor of 1 in the future (JDK-8260555). > > The first commit changes the timeout factor to 0.7, so that I can run tests > and test the

Re: RFR: 8344056: Use markdown format for man pages

2024-11-14 Thread Daniel Fuchs
On Wed, 13 Nov 2024 17:05:25 GMT, Magnus Ihse Bursie wrote: > Currently, the man pages are stored as troff (a text format) in the open > repo, and a content-wise identical copy is stored as markdown (another text > format) in the closed repo. > > Since markdown is preferred to troff in terms o

Re: RFR: 8338411: Implement JEP 486: Permanently Disable the Security Manager [v6]

2024-11-03 Thread Daniel Fuchs
On Sat, 2 Nov 2024 22:25:06 GMT, ExE Boss wrote: >> Sean Mullan has updated the pull request with a new target base due to a >> merge or a rebase. The pull request now contains 200 commits: >> >> - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411 >> - Modify three RMI tests

Re: RFR: 8338411: Implement JEP 486: Permanently Disable the Security Manager [v5]

2024-10-29 Thread Daniel Fuchs
On Tue, 29 Oct 2024 12:40:59 GMT, Sean Mullan wrote: >> This is the implementation of JEP 486: Permanently Disable the Security >> Manager. See [JEP 486](https://openjdk.org/jeps/486) for more details. The >> [CSR](https://bugs.openjdk.org/browse/JDK-8338412) describes in detail the >> main ch

Re: RFR: 8338411: Implement JEP 486: Permanently Disable the Security Manager [v5]

2024-10-29 Thread Daniel Fuchs
On Tue, 29 Oct 2024 12:40:59 GMT, Sean Mullan wrote: >> This is the implementation of JEP 486: Permanently Disable the Security >> Manager. See [JEP 486](https://openjdk.org/jeps/486) for more details. The >> [CSR](https://bugs.openjdk.org/browse/JDK-8338412) describes in detail the >> main ch

Re: RFR: 8338411: Implement JEP 486: Permanently Disable the Security Manager [v5]

2024-10-29 Thread Daniel Fuchs
On Tue, 29 Oct 2024 12:40:59 GMT, Sean Mullan wrote: >> This is the implementation of JEP 486: Permanently Disable the Security >> Manager. See [JEP 486](https://openjdk.org/jeps/486) for more details. The >> [CSR](https://bugs.openjdk.org/browse/JDK-8338412) describes in detail the >> main ch

Re: RFR: 8338411: Implement JEP 486: Permanently Disable the Security Manager [v5]

2024-10-29 Thread Daniel Fuchs
On Tue, 29 Oct 2024 12:40:59 GMT, Sean Mullan wrote: >> This is the implementation of JEP 486: Permanently Disable the Security >> Manager. See [JEP 486](https://openjdk.org/jeps/486) for more details. The >> [CSR](https://bugs.openjdk.org/browse/JDK-8338412) describes in detail the >> main ch

Re: RFR: 8338411: Implement JEP 486: Permanently Disable the Security Manager [v3]

2024-10-25 Thread Daniel Fuchs
On Thu, 24 Oct 2024 13:19:55 GMT, Sean Mullan wrote: >> This is the implementation of JEP 486: Permanently Disable the Security >> Manager. See [JEP 486](https://openjdk.org/jeps/486) for more details. The >> [CSR](https://bugs.openjdk.org/browse/JDK-8338412) describes in detail the >> main ch

Re: RFR: 8338411: Implement JEP 486: Permanently Disable the Security Manager [v2]

2024-10-23 Thread Daniel Fuchs
On Wed, 23 Oct 2024 11:54:39 GMT, Alan Bateman wrote: >> Sean Mullan has updated the pull request with a new target base due to a >> merge or a rebase. The pull request now contains 97 commits: >> >> - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411 >> - Change apiNote to d

Re: RFR: 8338411: Implement JEP 486: Permanently Disable the Security Manager [v2]

2024-10-22 Thread Daniel Fuchs
On Tue, 22 Oct 2024 11:50:13 GMT, Michael McMahon wrote: >> Sean Mullan has updated the pull request with a new target base due to a >> merge or a rebase. The pull request now contains 97 commits: >> >> - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411 >> - Change apiNote t

Re: RFR: 8338411: Implement JEP 486: Permanently Disable the Security Manager [v2]

2024-10-21 Thread Daniel Fuchs
On Fri, 18 Oct 2024 19:03:30 GMT, Sean Mullan wrote: >> This is the implementation of JEP 486: Permanently Disable the Security >> Manager. See [JEP 486](https://openjdk.org/jeps/486) for more details. The >> [CSR](https://bugs.openjdk.org/browse/JDK-8338412) describes in detail the >> main ch

Re: RFR: 8338411: Implement JEP 486: Permanently Disable the Security Manager [v2]

2024-10-21 Thread Daniel Fuchs
On Fri, 18 Oct 2024 19:03:30 GMT, Sean Mullan wrote: >> This is the implementation of JEP 486: Permanently Disable the Security >> Manager. See [JEP 486](https://openjdk.org/jeps/486) for more details. The >> [CSR](https://bugs.openjdk.org/browse/JDK-8338412) describes in detail the >> main ch

Re: RFR: 8338411: Implement JEP 486: Permanently Disable the Security Manager

2024-10-15 Thread Daniel Fuchs
On Tue, 15 Oct 2024 16:34:40 GMT, Severin Gehwolf wrote: >> This is the implementation of JEP 486: Permanently Disable the Security >> Manager. See [JEP 486](https://openjdk.org/jeps/486) for more details. The >> [CSR](https://bugs.openjdk.org/browse/JDK-8338412) describes in detail the >> mai

Re: RFR: 8338411: Implement JEP 486: Permanently Disable the Security Manager

2024-10-15 Thread Daniel Fuchs
On Tue, 15 Oct 2024 15:21:32 GMT, Alan Bateman wrote: >> src/java.logging/share/classes/java/util/logging/LogManager.java line 2430: >> >>> 2428: @Deprecated(since="17", forRemoval=true) >>> 2429: public void checkAccess() { >>> 2430: throw new SecurityException(); >> >> Though

Re: RFR: 8338411: Implement JEP 486: Permanently Disable the Security Manager

2024-10-15 Thread Daniel Fuchs
On Mon, 14 Oct 2024 13:52:24 GMT, Sean Mullan wrote: > This is the implementation of JEP 486: Permanently Disable the Security > Manager. See [JEP 486](https://openjdk.org/jeps/486) for more details. The > [CSR](https://bugs.openjdk.org/browse/JDK-8338412) describes in detail the > main change

Re: RFR: 8325109: Sort method modifiers in canonical order

2024-02-01 Thread Daniel Fuchs
On Thu, 1 Feb 2024 11:57:04 GMT, Magnus Ihse Bursie wrote: > This is a follow-up on > [JDK-8324053](https://bugs.openjdk.org/browse/JDK-8324053). I have run the > bin/blessed-modifier-order.sh on the entire code base, and manually checked > the result. I have reverted all but these trivial and

Re: [jdk21] RFR: 8300937: Update nroff pages in JDK 21 before RC

2023-07-31 Thread Daniel Fuchs
On Mon, 31 Jul 2023 08:33:07 GMT, David Holmes wrote: > Main changes are to use 21 instead of 21-ea. In addition the following files > contain additional updates from the closed sources: > > - src/java.base/share/man/java.1 > > [JDK-8273131](https://bugs.openjdk.org/browse/JDK-8273131): Updat

Re: RFR: 8285368: Overhaul doc-comment inheritance [v5]

2023-06-08 Thread Daniel Fuchs
On Thu, 8 Jun 2023 09:26:16 GMT, Pavel Rappo wrote: >> Please review this long-awaited change to documentation inheritance. >> >> This change improves "methods comment algorithm" and introduces directed >> documentation inheritance. While "methods comment algorithm" -- automatic >> search for

Re: [jdk20] RFR: 8298133: JDK 20 RDP1 L10n resource files update - msgdrop 10 [v5]

2022-12-16 Thread Daniel Fuchs
On Fri, 16 Dec 2022 09:20:07 GMT, Daniel Fuchs wrote: >> Damon Nguyen has updated the pull request incrementally with one additional >> commit since the last revision: >> >> Revert old translation. Fix lang codes > > src/java.base/share/classes/sun/launcher/re

Re: [jdk20] RFR: 8298133: JDK 20 RDP1 L10n resource files update - msgdrop 10 [v5]

2022-12-16 Thread Daniel Fuchs
On Fri, 16 Dec 2022 03:38:54 GMT, Damon Nguyen wrote: >> Open l10n drop >> All tests passed > > Damon Nguyen has updated the pull request incrementally with one additional > commit since the last revision: > > Revert old translation. Fix lang codes src/java.base/share/classes/sun/launcher/re

Re: RFR: 8296546: Add @spec tags to API [v4]

2022-12-02 Thread Daniel Fuchs
On Thu, 1 Dec 2022 19:36:16 GMT, Jonathan Gibbons wrote: >> Please review a "somewhat automated" change to insert `@spec` tags into doc >> comments, as appropriate, to leverage the recent new javadoc feature to >> generate a new page listing the references to all external specifications >> lis

Re: RFR: 8296546: Add @spec tags to API [v3]

2022-11-23 Thread Daniel Fuchs
On Wed, 23 Nov 2022 18:57:03 GMT, Jonathan Gibbons wrote: >> Please review a "somewhat automated" change to insert `@spec` tags into doc >> comments, as appropriate, to leverage the recent new javadoc feature to >> generate a new page listing the references to all external specifications >> li

Re: RFR: 8296546: Add @spec tags to API [v2]

2022-11-23 Thread Daniel Fuchs
On Tue, 22 Nov 2022 22:04:57 GMT, Jonathan Gibbons wrote: >> Please review a "somewhat automated" change to insert `@spec` tags into doc >> comments, as appropriate, to leverage the recent new javadoc feature to >> generate a new page listing the references to all external specifications >> li

Re: RFR: JDK-8297164: Update troff man pages and CheckManPageOptions.java [v2]

2022-11-21 Thread Daniel Fuchs
On Mon, 21 Nov 2022 17:54:15 GMT, Jonathan Gibbons wrote: >> Please review an update for the troff man pages, following the recent update >> to upgrade to use pandoc 2.19.2 >> (See https://bugs.openjdk.org/browse/JDK-8297165) >> >> In conjunction with this, one javadoc test also needs to be upd

Re: RFR: 8296546: Add @spec tags to API

2022-11-11 Thread Daniel Fuchs
On Fri, 11 Nov 2022 11:45:43 GMT, Lance Andersen wrote: > It would probably be easier for the reviewers and for you if the PR could be > broken out by areas into separate PRs Leaving out the non-public and non-exported classes would also reduce the PR size. - PR: https://git.open

Re: RFR: 8296546: Add @spec tags to API

2022-11-11 Thread Daniel Fuchs
On Thu, 10 Nov 2022 21:56:26 GMT, Jonathan Gibbons wrote: > On the same text but linking to different RFCs: that's tantamount to a bug > somewhere. The spec for `@spec` dictates that the URLs and titles should be > in 1-1 correspondence, and this is supposed to be enforced in the docket. In >

Re: RFR: JDK-8296547: Add @spec tags to API

2022-11-10 Thread Daniel Fuchs
On Thu, 10 Nov 2022 01:10:13 GMT, Jonathan Gibbons wrote: > Please review a "somewhat automated" change to insert `@spec` tags into doc > comments, as appropriate, to leverage the recent new javadoc feature to > generate a new page listing the references to all external specifications > listed

Integrated: 8294241: Deprecate URL public constructors

2022-11-03 Thread Daniel Fuchs
On Wed, 26 Oct 2022 16:00:56 GMT, Daniel Fuchs wrote: > Deprecate URL constructors. Developers are encouraged to use `java.net.URI` > to parse or construct any URL. > > The `java.net.URL` class does not itself encode or decode any URL components > according to the escaping me

Re: RFR: 8294241: Deprecate URL public constructors [v5]

2022-11-03 Thread Daniel Fuchs
Some related > issues will be logged to revisit the calling code. > > The CSR can be reviewed here: https://bugs.openjdk.org/browse/JDK-8295949 Daniel Fuchs has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated chan

Re: RFR: 8294241: Deprecate URL public constructors [v3]

2022-11-03 Thread Daniel Fuchs
On Thu, 3 Nov 2022 07:42:44 GMT, ExE Boss wrote: >> Daniel Fuchs 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 six addi

Re: RFR: 8294241: Deprecate URL public constructors [v4]

2022-11-03 Thread Daniel Fuchs
On Thu, 3 Nov 2022 10:56:28 GMT, Michael McMahon wrote: >> Daniel Fuchs has updated the pull request incrementally with three >> additional commits since the last revision: >> >> - Update src/java.base/share/classes/java/net/URL.java >> >>Co-

Re: RFR: 8294241: Deprecate URL public constructors [v4]

2022-11-03 Thread Daniel Fuchs
Some related > issues will be logged to revisit the calling code. > > The CSR can be reviewed here: https://bugs.openjdk.org/browse/JDK-8295949 Daniel Fuchs has updated the pull request incrementally with three additional commits since the last revision: - Update src/java.base/share/classe

Re: RFR: 8294241: Deprecate URL public constructors [v2]

2022-11-01 Thread Daniel Fuchs
On Tue, 1 Nov 2022 14:47:49 GMT, Alan Bateman wrote: >> Actually... Maybe I could move up the paragraph that says that URL >> constructors are deprecated up here, just after the

title? Would >> that be better? > > Try it, it might be better. I think the main thing is that link brings the


Re: RFR: 8294241: Deprecate URL public constructors [v3]

2022-11-01 Thread Daniel Fuchs
Some related > issues will be logged to revisit the calling code. > > The CSR can be reviewed here: https://bugs.openjdk.org/browse/JDK-8295949 Daniel Fuchs has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated chang

Re: RFR: 8294241: Deprecate URL public constructors [v2]

2022-11-01 Thread Daniel Fuchs
On Tue, 1 Nov 2022 14:10:01 GMT, Daniel Fuchs wrote: >> src/java.base/share/classes/java/net/URL.java line 133: >> >>> 131: * specified. The optional fragment is not inherited. >>> 132: * >>> 133: * Constructing instances of >>> {@code URL}

Re: RFR: 8294241: Deprecate URL public constructors [v2]

2022-11-01 Thread Daniel Fuchs
On Sat, 29 Oct 2022 14:24:09 GMT, Alan Bateman wrote: >> Daniel Fuchs 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 contai

Re: RFR: 8294241: Deprecate URL public constructors [v2]

2022-11-01 Thread Daniel Fuchs
On Sat, 29 Oct 2022 14:17:12 GMT, Alan Bateman wrote: >> Daniel Fuchs 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 contai

Re: RFR: 8294241: Deprecate URL public constructors [v2]

2022-11-01 Thread Daniel Fuchs
On Sat, 29 Oct 2022 14:16:24 GMT, Alan Bateman wrote: >> Daniel Fuchs 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 contai

Re: RFR: 8294241: Deprecate URL public constructors [v2]

2022-11-01 Thread Daniel Fuchs
On Sat, 29 Oct 2022 14:14:22 GMT, Alan Bateman wrote: >> Daniel Fuchs 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 contai

Re: RFR: 8294241: Deprecate URL public constructors [v2]

2022-11-01 Thread Daniel Fuchs
On Mon, 31 Oct 2022 22:00:01 GMT, Phil Race wrote: > Deprecate URL constructors. Developers are encouraged to use java.net.URI to > parse or construct any URL. ... To construct a URL, using URI::toURL should > be preferred. > > You have jumped through some refactoring hoops to be able to apply

Re: RFR: 8295729: Add jcheck whitespace checking for properties files [v3]

2022-11-01 Thread Daniel Fuchs
On Mon, 24 Oct 2022 19:21:07 GMT, Magnus Ihse Bursie wrote: >> Properties files is essentially source code. It should have the same >> whitespace checks as all other source code, so we don't get spurious >> trailing whitespace changes. >> >> With the new Skara jcheck, it is possible to increas

Re: RFR: 8294241: Deprecate URL public constructors [v2]

2022-10-28 Thread Daniel Fuchs
Some related > issues will be logged to revisit the calling code. > > The CSR can be reviewed here: https://bugs.openjdk.org/browse/JDK-8295949 Daniel Fuchs has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated change

Re: RFR: 8294241: Deprecate URL public constructors

2022-10-27 Thread Daniel Fuchs
On Thu, 27 Oct 2022 17:50:37 GMT, Andrey Turbanov wrote: >> Deprecate URL constructors. Developers are encouraged to use `java.net.URI` >> to parse or construct any URL. >> >> The `java.net.URL` class does not itself encode or decode any URL components >> according to the escaping mechanism de

Re: RFR: 8294241: Deprecate URL public constructors

2022-10-27 Thread Daniel Fuchs
On Thu, 27 Oct 2022 17:20:04 GMT, Joe Wang wrote: > Hi Daniel, if it's not a major improvement, we'd like to keep the java.xml > module at the JDK 8 code level. Can we remove the 'var' usage in a few > java.xml classes? No problem - I will make this change when we have settled on a name for th

Re: RFR: 8294241: Deprecate URL public constructors

2022-10-27 Thread Daniel Fuchs
On Thu, 27 Oct 2022 09:17:29 GMT, Michael McMahon wrote: >> Having unnamed local variables[^1] would probably be best for this. >> >> [^1]: https://openjdk.org/jeps/8294349 > > How about `_unused` or `_unused1`, `_unused2` then in the meantime? I'd be happy to make the change. Let's wait to see

Re: RFR: 8294241: Deprecate URL public constructors

2022-10-26 Thread Daniel Fuchs
On Wed, 26 Oct 2022 17:39:56 GMT, Xue-Lei Andrew Fan wrote: >> `URLStreamHandler` really belongs to `java.net.URL`, and is an >> implementation detail of the infrastructure/SPI that makes it possible to >> eventually call `URL::openConnection`. I do not think it would be >> appropriate to have

Re: RFR: 8294241: Deprecate URL public constructors

2022-10-26 Thread Daniel Fuchs
On Wed, 26 Oct 2022 17:09:20 GMT, Xue-Lei Andrew Fan wrote: >> Deprecate URL constructors. Developers are encouraged to use `java.net.URI` >> to parse or construct any URL. >> >> The `java.net.URL` class does not itself encode or decode any URL components >> according to the escaping mechanism

RFR: 8294241: Deprecate URL public constructors

2022-10-26 Thread Daniel Fuchs
Deprecate URL constructors. Developers are encouraged to use `java.net.URI` to parse or construct any URL. The `java.net.URL` class does not itself encode or decode any URL components according to the escaping mechanism defined in RFC2396. It is the responsibility of the caller to encode any fi

Re: RFR: 8294321: Fix typos in files under test/jdk/java, test/jdk/jdk, test/jdk/jni [v2]

2022-09-28 Thread Daniel Fuchs
On Wed, 28 Sep 2022 14:45:54 GMT, Michael Ernst wrote: >> Michael Ernst has updated the pull request with a new target base due to a >> merge or a rebase. The pull request now contains six commits: >> >> - Reinstate typos in Apache code that is copied into the JDK >> - Merge ../jdk-openjdk in

Re: RFR: 8294321: Fix typos in files under test/jdk/java, test/jdk/jdk, test/jdk/jni [v2]

2022-09-28 Thread Daniel Fuchs
On Tue, 27 Sep 2022 23:12:43 GMT, Michael Ernst wrote: > Feel free to break up the pull request if that is what is needed to free it > from red tape. Only you can do that @mernst - PR: https://git.openjdk.org/jdk/pull/10029