From michel.trudeau at oracle.com  Mon May  5 20:19:28 2025
From: michel.trudeau at oracle.com (Michel Trudeau)
Date: Mon, 5 May 2025 20:19:28 +0000
Subject: JavaDoc: NPE in java.net.http.HttpHeaders
In-Reply-To: <Osz5cwLv8dCufch8gyhKOQf-jqglf72M1rNOEiLPtWbFrQwwUNo6ump8KA3rCi5ZaTGtWiIFQgII55g50WurfP6rvKumwWyfIgGZGVwckCo=@protonmail.com>
References: <Osz5cwLv8dCufch8gyhKOQf-jqglf72M1rNOEiLPtWbFrQwwUNo6ump8KA3rCi5ZaTGtWiIFQgII55g50WurfP6rvKumwWyfIgGZGVwckCo=@protonmail.com>
Message-ID: <MW4PR10MB5837DF40625B519272021FC7ED8E2@MW4PR10MB5837.namprd10.prod.outlook.com>



From: core-libs-dev <core-libs-dev-retn at openjdk.org> on behalf of Steffen Nie?ing <zuniquex at protonmail.com>
Date: Monday, May 5, 2025 at 1:05?PM
To: core-libs-dev at openjdk.org <core-libs-dev at openjdk.org>
Subject: JavaDoc: NPE in java.net.http.HttpHeaders
Hello,

recently I've discovered that the JavaDoc of the instance methods of java.net.http.HttpHeaders lacks the throws declarations for NullPointerExceptions. The static creator method `of` contains such a declaration. So the snippet `HttpHeaders.of(null, null)` is documented to throw an NPE, while the snippet `HttpHeaders.of(Map.of(), (k, v) -> true).firstValue(null)` currently isn't.

I'd propose to add the missing JavaDoc throws declarations to the #allValues(String), #firstValueAsLong(String) and #firstValue(String) methods as they all can throw an NPE through `requireNonNull(name);` in the allValues method.

If there's interest in this change, I'd appreciate if anyone would like to sponsor me on this one.

Cheers,
Steffen
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/javadoc-dev/attachments/20250505/94a8269e/attachment.htm>

From hannesw at openjdk.org  Tue May  6 15:03:27 2025
From: hannesw at openjdk.org (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=)
Date: Tue, 6 May 2025 15:03:27 GMT
Subject: RFR: 8356276: JavaScript error in script.js after JDK-8348282
Message-ID: <aivEYFhxzPBoU0o1eDKVRamdCpI5QYMyt20bkDgCq3w=.f7578ad2-9523-4406-af13-db1aeab7764b@github.com>

Please review a simple fix to avoid a JavaScript error in API docs when syntax highlighting is not enabled. 

The fix consists in replacing `(hljs)` with `(typeof hljs !== "undefined")` in the `if` statement as the former throws a `TypeError` if `hljs` is undefined.  The `try-catch` wrapper around `hljs.highlightAll()` is just added to be on the safe side, and the change in `Head.java` is just cleanup to preserve the separateion of .css and .js files.

Labeled `noreg-hard` as we do not have a way to test the script in browser. I manually tested the fix in multiple browsers.

-------------

Commit messages:
 - JDK-8356276: JavaScript error in script.js after JDK-8348282

Changes: https://git.openjdk.org/jdk/pull/25069/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25069&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8356276
  Stats: 10 lines in 2 files changed: 7 ins; 1 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/25069.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25069/head:pull/25069

PR: https://git.openjdk.org/jdk/pull/25069

From liach at openjdk.org  Tue May  6 15:19:14 2025
From: liach at openjdk.org (Chen Liang)
Date: Tue, 6 May 2025 15:19:14 GMT
Subject: RFR: 8356276: JavaScript error in script.js after JDK-8348282
In-Reply-To: <aivEYFhxzPBoU0o1eDKVRamdCpI5QYMyt20bkDgCq3w=.f7578ad2-9523-4406-af13-db1aeab7764b@github.com>
References: <aivEYFhxzPBoU0o1eDKVRamdCpI5QYMyt20bkDgCq3w=.f7578ad2-9523-4406-af13-db1aeab7764b@github.com>
Message-ID: <ph0k8m9_wrjWP0hgzZZ_QNSBBvEB-0A2iM6ENk4-vEk=.4dd6390d-39d2-4051-8c8f-c2100c1b7783@github.com>

On Tue, 6 May 2025 14:57:20 GMT, Hannes Walln?fer <hannesw at openjdk.org> wrote:

> Please review a simple fix to avoid a JavaScript error in API docs when syntax highlighting is not enabled. 
> 
> The fix consists in replacing `(hljs)` with `(typeof hljs !== "undefined")` in the `if` statement as the former throws a `TypeError` if `hljs` is undefined.  The `try-catch` wrapper around `hljs.highlightAll()` is just added to be on the safe side, and the change in `Head.java` is just cleanup to preserve the separateion of .css and .js files.
> 
> Labeled `noreg-hard` as we do not have a way to test the script in browser. I manually tested the fix in multiple browsers.

The js part looks good. Is the Java code just trivial cleanup and doesn't affect correctness of this patch?

-------------

Marked as reviewed by liach (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25069#pullrequestreview-2818673892

From hannesw at openjdk.org  Tue May  6 15:25:26 2025
From: hannesw at openjdk.org (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=)
Date: Tue, 6 May 2025 15:25:26 GMT
Subject: RFR: 8356276: JavaScript error in script.js after JDK-8348282
In-Reply-To: <ph0k8m9_wrjWP0hgzZZ_QNSBBvEB-0A2iM6ENk4-vEk=.4dd6390d-39d2-4051-8c8f-c2100c1b7783@github.com>
References: <aivEYFhxzPBoU0o1eDKVRamdCpI5QYMyt20bkDgCq3w=.f7578ad2-9523-4406-af13-db1aeab7764b@github.com>
 <ph0k8m9_wrjWP0hgzZZ_QNSBBvEB-0A2iM6ENk4-vEk=.4dd6390d-39d2-4051-8c8f-c2100c1b7783@github.com>
Message-ID: <sLrUaPnMyfDwFtK4xiXKrdez7Duq8ntGZ77ypqp9si0=.95e7d85b-e74a-41d7-a870-a92b37fd2411@github.com>

On Tue, 6 May 2025 15:16:16 GMT, Chen Liang <liach at openjdk.org> wrote:

> The js part looks good. Is the Java code just trivial cleanup and doesn't affect correctness of this patch?

Exactly, it's just to copy CSS and JS files each in their own method. 
Thanks for the quick review!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25069#issuecomment-2855008389

From hannesw at openjdk.org  Tue May  6 16:04:29 2025
From: hannesw at openjdk.org (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=)
Date: Tue, 6 May 2025 16:04:29 GMT
Subject: Integrated: 8356276: JavaScript error in script.js after JDK-8348282
In-Reply-To: <aivEYFhxzPBoU0o1eDKVRamdCpI5QYMyt20bkDgCq3w=.f7578ad2-9523-4406-af13-db1aeab7764b@github.com>
References: <aivEYFhxzPBoU0o1eDKVRamdCpI5QYMyt20bkDgCq3w=.f7578ad2-9523-4406-af13-db1aeab7764b@github.com>
Message-ID: <emxnuvYO-pcFhxhLXVWzmwUTytM9idUPJ_JGSBs7dEg=.3b22c341-63b9-4f7e-9941-1ebea01e52bb@github.com>

On Tue, 6 May 2025 14:57:20 GMT, Hannes Walln?fer <hannesw at openjdk.org> wrote:

> Please review a simple fix to avoid a JavaScript error in API docs when syntax highlighting is not enabled. 
> 
> The fix consists in replacing `(hljs)` with `(typeof hljs !== "undefined")` in the `if` statement as the former throws a `TypeError` if `hljs` is undefined.  The `try-catch` wrapper around `hljs.highlightAll()` is just added to be on the safe side, and the change in `Head.java` is just cleanup to preserve the separateion of .css and .js files.
> 
> Labeled `noreg-hard` as we do not have a way to test the script in browser. I manually tested the fix in multiple browsers.

This pull request has now been integrated.

Changeset: 9477c422
Author:    Hannes Walln?fer <hannesw at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/9477c42215a219ef8d8f44f19506692f6efc82c0
Stats:     10 lines in 2 files changed: 7 ins; 1 del; 2 mod

8356276: JavaScript error in script.js after JDK-8348282

Reviewed-by: liach

-------------

PR: https://git.openjdk.org/jdk/pull/25069

From nbenalla at openjdk.org  Thu May  8 15:02:35 2025
From: nbenalla at openjdk.org (Nizar Benalla)
Date: Thu, 8 May 2025 15:02:35 GMT
Subject: RFR: 8177100: APIs duplicated in JavaDoc
Message-ID: <0NrLP37RZ6I7ytBxcNyNFReQVvgu-6p_-HbSbHW9ZRM=.c7fd5ae4-8c8d-48ea-8349-5c92a2f78c71@github.com>

Please review this patch to fix a bug where a method can be documented multiple times 
Consider these 4 classes

                    A       (interface)
                   / \
                  /   \
(abstract class)  C     B   ( interface)
                  \   /
                   \ /
                    D       (class)


Where `A` declares `testA()`, `C` implements it `public final void testA()`, `B` extends `A` but does *not* override it, `D` extends `C` and implements `B`

In the generated javadoc, `testA()` is documented twice.

![Screenshot 2025-05-08 at 15 51 19](https://github.com/user-attachments/assets/46538e61-1546-4128-8041-296d8491406f)

After the patch, `testA()` is only documented once:

![Screenshot 2025-05-08 at 15 52 16](https://github.com/user-attachments/assets/a6b86a21-7104-460c-8f3f-36cee5962eed)

-------------

Commit messages:
 - merge methods from invisible supetypes

Changes: https://git.openjdk.org/jdk/pull/25123/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25123&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8177100
  Stats: 114 lines in 2 files changed: 111 ins; 1 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/25123.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25123/head:pull/25123

PR: https://git.openjdk.org/jdk/pull/25123

From lkorinth at openjdk.org  Thu May  8 15:02:42 2025
From: lkorinth at openjdk.org (Leo Korinth)
Date: Thu, 8 May 2025 15:02:42 GMT
Subject: RFR: 8356171: Increase timeout for testcases as preparation for change
 of default timeout factor
Message-ID: <WCuOwzU4kPjno7_Ptc1SQN6KY6MEejJlVEQKhZhqgjo=.259ff478-ab46-4d31-aa4a-c4fffb8d54a7@github.com>

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 change (it will finally be changed to 1.0 in JDK-8260555). The next commit excludes some junit/testng tests where I can currently not change the timeout factor (CODETOOLS-7903961). Both these commits will be reverted before integrating the change. I will also apply copyright updates after the review.

In addition to changing the timeout factor, I am also using a library call to parse the timeout factor from the java properties (I can not use the library function everywhere as jtreg does not allow me to add @library notations to non testcase files).

My approach has been to run all test, and afterwards updating those that fails due to a timeout factor. The amount of updated testcases is huge, and my strategy has been to quadruple the timeout if I could not directly see that less was needed (thus the timeout will be the same after JDK-8260555 is implemented). In a few places I have added a bit more timeout so that it will work with the 0.7 timeout factor.

These fixes have been created when I have plown through testcases:
JDK-8352719: Add an equals sign to the modules statement
JDK-8352709: Remove bad timing annotations from WhileOpTest.java
JDK-8352074: Test MemoryLeak.java seems not to test what it is supposed to test
CODETOOLS-7903937: JTREG uses timeout factor on socket timeout but not on KEEPALIVE
CODETOOLS-7903961: Make default timeout configurable

Sometime in the future I will also fix:
8260555: Change the default TIMEOUT_FACTOR from 4 to 1

for which I am awaiting:
CODETOOLS-7903961 that is fixed in jtreg 7.6, but we are still running 7.5.1+1

*After the review I will revert the two first commits, and update the copyrights*

-------------

Commit messages:
 - 8356171: Increase timeout for testcases as preparation for change of default timeout factor
 - Fix some tests that need an upgrade of JTREG --- REVERT THIS LATER
 - 8260555

Changes: https://git.openjdk.org/jdk/pull/25122/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25122&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8356171
  Stats: 556 lines in 272 files changed: 59 ins; 96 del; 401 mod
  Patch: https://git.openjdk.org/jdk/pull/25122.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25122/head:pull/25122

PR: https://git.openjdk.org/jdk/pull/25122

From liach at openjdk.org  Thu May  8 15:09:54 2025
From: liach at openjdk.org (Chen Liang)
Date: Thu, 8 May 2025 15:09:54 GMT
Subject: RFR: 8177100: APIs duplicated in JavaDoc
In-Reply-To: <0NrLP37RZ6I7ytBxcNyNFReQVvgu-6p_-HbSbHW9ZRM=.c7fd5ae4-8c8d-48ea-8349-5c92a2f78c71@github.com>
References: <0NrLP37RZ6I7ytBxcNyNFReQVvgu-6p_-HbSbHW9ZRM=.c7fd5ae4-8c8d-48ea-8349-5c92a2f78c71@github.com>
Message-ID: <6c3fN9sIYYZfVtmZxkQ5onxBLl_t0aqL_kXxQD2BQAI=.45425562-1856-49f9-8050-df085d9b4615@github.com>

On Thu, 8 May 2025 14:53:41 GMT, Nizar Benalla <nbenalla at openjdk.org> wrote:

> Please review this patch to fix a bug where a method can be documented multiple times 
> Consider these 4 classes
> 
>                     A       (interface)
>                    / \
>                   /   \
> (abstract class)  C     B   ( interface)
>                   \   /
>                    \ /
>                     D       (class)
> 
> 
> Where `A` declares `testA()`, `C` implements it `public final void testA()`, `B` extends `A` but does *not* override it, `D` extends `C` and implements `B`
> 
> In the generated javadoc, `testA()` is documented twice.
> 
> ![Screenshot 2025-05-08 at 15 51 19](https://github.com/user-attachments/assets/46538e61-1546-4128-8041-296d8491406f)
> 
> After the patch, `testA()` is only documented once:
> 
> ![Screenshot 2025-05-08 at 15 52 16](https://github.com/user-attachments/assets/a6b86a21-7104-460c-8f3f-36cee5962eed)

src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/util/VisibleMemberTable.java line 691:

> 689:         if (inInterface) {
> 690:             List<ExecutableElement> list = overriddenByTable.get(inheritedMethod);
> 691:             if (list != null) {

Can't we change this to `if (list != null && !list.isEmpty) return false;`?

Comments can be to update the overall block comment to indicate that there is no contention - when a method overrides multiple superinterfaces' methods, including when it is final from superclasses, the superclass method always prevails due to method resolution rules in Java. All interface methods have low resolution priority.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25123#discussion_r2079913557

From nbenalla at openjdk.org  Thu May  8 16:03:54 2025
From: nbenalla at openjdk.org (Nizar Benalla)
Date: Thu, 8 May 2025 16:03:54 GMT
Subject: RFR: 8177100: APIs duplicated in JavaDoc
In-Reply-To: <6c3fN9sIYYZfVtmZxkQ5onxBLl_t0aqL_kXxQD2BQAI=.45425562-1856-49f9-8050-df085d9b4615@github.com>
References: <0NrLP37RZ6I7ytBxcNyNFReQVvgu-6p_-HbSbHW9ZRM=.c7fd5ae4-8c8d-48ea-8349-5c92a2f78c71@github.com>
 <6c3fN9sIYYZfVtmZxkQ5onxBLl_t0aqL_kXxQD2BQAI=.45425562-1856-49f9-8050-df085d9b4615@github.com>
Message-ID: <lB7ckgyFhfDerm5ZPBM5aJmt8pC7pL2c-ZN4JDt7vf8=.cbd2c1f9-ddec-48dc-82e9-987995bb58b3@github.com>

On Thu, 8 May 2025 15:07:15 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Please review this patch to fix a bug where a method can be documented multiple times 
>> Consider these 4 classes
>> 
>>                     A       (interface)
>>                    / \
>>                   /   \
>> (abstract class)  C     B   ( interface)
>>                   \   /
>>                    \ /
>>                     D       (class)
>> 
>> 
>> Where `A` declares `testA()`, `C` implements it `public final void testA()`, `B` extends `A` but does *not* override it, `D` extends `C` and implements `B`
>> 
>> In the generated javadoc, `testA()` is documented twice.
>> 
>> ![Screenshot 2025-05-08 at 15 51 19](https://github.com/user-attachments/assets/46538e61-1546-4128-8041-296d8491406f)
>> 
>> After the patch, `testA()` is only documented once:
>> 
>> ![Screenshot 2025-05-08 at 15 52 16](https://github.com/user-attachments/assets/a6b86a21-7104-460c-8f3f-36cee5962eed)
>
> src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/util/VisibleMemberTable.java line 691:
> 
>> 689:         if (inInterface) {
>> 690:             List<ExecutableElement> list = overriddenByTable.get(inheritedMethod);
>> 691:             if (list != null) {
> 
> Can't we change this to `if (list != null && !list.isEmpty) return false;`?
> 
> Comments can be to update the overall block comment to indicate that there is no contention - when a method overrides multiple superinterfaces' methods, including when it is final from superclasses, the superclass method always prevails due to method resolution rules in Java. All interface methods have low resolution priority.

I think this simplification works just fine.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25123#discussion_r2080018316

From stefank at openjdk.org  Thu May  8 16:09:00 2025
From: stefank at openjdk.org (Stefan Karlsson)
Date: Thu, 8 May 2025 16:09:00 GMT
Subject: RFR: 8356171: Increase timeout for testcases as preparation for
 change of default timeout factor
In-Reply-To: <WCuOwzU4kPjno7_Ptc1SQN6KY6MEejJlVEQKhZhqgjo=.259ff478-ab46-4d31-aa4a-c4fffb8d54a7@github.com>
References: <WCuOwzU4kPjno7_Ptc1SQN6KY6MEejJlVEQKhZhqgjo=.259ff478-ab46-4d31-aa4a-c4fffb8d54a7@github.com>
Message-ID: <2nBGcIjZC03ee74o34IXFgtoEVTAkQV-xXEC28_oFbI=.da57d5a4-4546-4566-aa79-cacce01562d7@github.com>

On Thu, 8 May 2025 14:51:24 GMT, Leo Korinth <lkorinth at openjdk.org> 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 change (it will finally be changed to 1.0 in JDK-8260555). The next commit excludes some junit/testng tests where I can currently not change the timeout factor (CODETOOLS-7903961). Both these commits will be reverted before integrating the change. I will also apply copyright updates after the review.
> 
> In addition to changing the timeout factor, I am also using a library call to parse the timeout factor from the java properties (I can not use the library function everywhere as jtreg does not allow me to add @library notations to non testcase files).
> 
> My approach has been to run all test, and afterwards updating those that fails due to a timeout factor. The amount of updated testcases is huge, and my strategy has been to quadruple the timeout if I could not directly see that less was needed (thus the timeout will be the same after JDK-8260555 is implemented). In a few places I have added a bit more timeout so that it will work with the 0.7 timeout factor.
> 
> These fixes have been created when I have plown through testcases:
> JDK-8352719: Add an equals sign to the modules statement
> JDK-8352709: Remove bad timing annotations from WhileOpTest.java
> JDK-8352074: Test MemoryLeak.java seems not to test what it is supposed to test
> CODETOOLS-7903937: JTREG uses timeout factor on socket timeout but not on KEEPALIVE
> CODETOOLS-7903961: Make default timeout configurable
> 
> Sometime in the future I will also fix:
> 8260555: Change the default TIMEOUT_FACTOR from 4 to 1
> 
> for which I am awaiting:
> CODETOOLS-7903961 that is fixed in jtreg 7.6, but we are still running 7.5.1+1
> 
> *After the review I will revert the two first commits, and update the copyrights*

Thanks for tackling this! I look forward to the day when you change TIMEOUT_FACTOR to be 1 by default. I think that will reduce confusion.

I made a cursory look through some GC files and I think that looked good.

doc/testing.md line 385:

> 383: (`-timeoutFactor`). Also, some test cases that programmatically wait a
> 384: certain amount of time will apply this factor. If we run in
> 385: interpreted mode (`-Xcomp`), [RunTest.gmk](../make/RunTests.gmk)

Maybe
Suggestion:

interpreted mode (`-Xint`), [RunTest.gmk](../make/RunTests.gmk)

-------------

PR Review: https://git.openjdk.org/jdk/pull/25122#pullrequestreview-2825661242
PR Review Comment: https://git.openjdk.org/jdk/pull/25122#discussion_r2080028720

From dfuchs at openjdk.org  Thu May  8 16:28:53 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Thu, 8 May 2025 16:28:53 GMT
Subject: RFR: 8356171: Increase timeout for testcases as preparation for
 change of default timeout factor
In-Reply-To: <WCuOwzU4kPjno7_Ptc1SQN6KY6MEejJlVEQKhZhqgjo=.259ff478-ab46-4d31-aa4a-c4fffb8d54a7@github.com>
References: <WCuOwzU4kPjno7_Ptc1SQN6KY6MEejJlVEQKhZhqgjo=.259ff478-ab46-4d31-aa4a-c4fffb8d54a7@github.com>
Message-ID: <VKBSy10yl0qvIk0P_JQb3KGFkmaDEtWYzncAlEW7VV8=.bd136181-45be-437e-b684-2ad16ac419b5@github.com>

On Thu, 8 May 2025 14:51:24 GMT, Leo Korinth <lkorinth at openjdk.org> 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 change (it will finally be changed to 1.0 in JDK-8260555). The next commit excludes some junit/testng tests where I can currently not change the timeout factor (CODETOOLS-7903961). Both these commits will be reverted before integrating the change. I will also apply copyright updates after the review.
> 
> In addition to changing the timeout factor, I am also using a library call to parse the timeout factor from the java properties (I can not use the library function everywhere as jtreg does not allow me to add @library notations to non testcase files).
> 
> My approach has been to run all test, and afterwards updating those that fails due to a timeout factor. The amount of updated testcases is huge, and my strategy has been to quadruple the timeout if I could not directly see that less was needed (thus the timeout will be the same after JDK-8260555 is implemented). In a few places I have added a bit more timeout so that it will work with the 0.7 timeout factor.
> 
> These fixes have been created when I have plown through testcases:
> JDK-8352719: Add an equals sign to the modules statement
> JDK-8352709: Remove bad timing annotations from WhileOpTest.java
> JDK-8352074: Test MemoryLeak.java seems not to test what it is supposed to test
> CODETOOLS-7903937: JTREG uses timeout factor on socket timeout but not on KEEPALIVE
> CODETOOLS-7903961: Make default timeout configurable
> 
> Sometime in the future I will also fix:
> 8260555: Change the default TIMEOUT_FACTOR from 4 to 1
> 
> for which I am awaiting:
> CODETOOLS-7903961 that is fixed in jtreg 7.6, but we are still running 7.5.1+1
> 
> *After the review I will revert the two first commits, and update the copyrights*

@lkorinth have you run all the tiers where the old default timeout factor of 4 applied?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25122#issuecomment-2863633579

From lkorinth at openjdk.org  Thu May  8 16:45:56 2025
From: lkorinth at openjdk.org (Leo Korinth)
Date: Thu, 8 May 2025 16:45:56 GMT
Subject: RFR: 8356171: Increase timeout for testcases as preparation for
 change of default timeout factor
In-Reply-To: <WCuOwzU4kPjno7_Ptc1SQN6KY6MEejJlVEQKhZhqgjo=.259ff478-ab46-4d31-aa4a-c4fffb8d54a7@github.com>
References: <WCuOwzU4kPjno7_Ptc1SQN6KY6MEejJlVEQKhZhqgjo=.259ff478-ab46-4d31-aa4a-c4fffb8d54a7@github.com>
Message-ID: <N027ImJIxB-7XV_sMWQf9VR2KTnUK6Fq8Tmkn8uXNYg=.f2a0f896-88a1-4702-adef-4514c9e155c1@github.com>

On Thu, 8 May 2025 14:51:24 GMT, Leo Korinth <lkorinth at openjdk.org> 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 change (it will finally be changed to 1.0 in JDK-8260555). The next commit excludes some junit/testng tests where I can currently not change the timeout factor (CODETOOLS-7903961). Both these commits will be reverted before integrating the change. I will also apply copyright updates after the review.
> 
> In addition to changing the timeout factor, I am also using a library call to parse the timeout factor from the java properties (I can not use the library function everywhere as jtreg does not allow me to add @library notations to non testcase files).
> 
> My approach has been to run all test, and afterwards updating those that fails due to a timeout factor. The amount of updated testcases is huge, and my strategy has been to quadruple the timeout if I could not directly see that less was needed (thus the timeout will be the same after JDK-8260555 is implemented). In a few places I have added a bit more timeout so that it will work with the 0.7 timeout factor.
> 
> These fixes have been created when I have plown through testcases:
> JDK-8352719: Add an equals sign to the modules statement
> JDK-8352709: Remove bad timing annotations from WhileOpTest.java
> JDK-8352074: Test MemoryLeak.java seems not to test what it is supposed to test
> CODETOOLS-7903937: JTREG uses timeout factor on socket timeout but not on KEEPALIVE
> CODETOOLS-7903961: Make default timeout configurable
> 
> Sometime in the future I will also fix:
> 8260555: Change the default TIMEOUT_FACTOR from 4 to 1
> 
> for which I am awaiting:
> CODETOOLS-7903961 that is fixed in jtreg 7.6, but we are still running 7.5.1+1
> 
> *After the review I will revert the two first commits, and update the copyrights*

Before this version, I had run tiers 1-8, with 11 fails.

** DONE 01 serviceability/jvmti/vthread/SuspendResume2/SuspendResume2.java#debug 700
** DONE 02 jdk/internal/platform/docker/TestUseContainerSupport.java OTHER
** DONE 03 tools/javac/util/IteratorsTest.java 480
** DONE 04 java/math/BigInteger/LargeValueExceptions.java 480
** DONE 05 vmTestbase/gc/gctests/WeakReference/weak004/weak004.java OTHER
** DONE 06 compiler/loopstripmining/CheckLoopStripMining.java OTHER
** DONE 07 sun/security/tools/keytool/fakecacerts/TrustedCert.java 480
** DONE 08 jdk/internal/platform/docker/TestUseContainerSupport.java OTHER
** DONE 09 containers/docker/TestJFRNetworkEvents.java OTHER
** DONE 10 java/foreign/TestMismatch.java 480
** DONE 11 linux-riscv64-open-cmp-baseline-linux-x64-build-796 OTHER

Six of those seems not related to my changes (marked `OTHER`),  five  I have updated for this run with new timeout.

I have fixed the timeouts and rebased (I had one conflict), and I am now again running tier1-8. It will take time, and it looks like I will have more (unrelated) fails this time.

After I revert the two first commits and go back to a timeout factor of 4, I will run tier 1-8 again.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25122#issuecomment-2863670496
PR Comment: https://git.openjdk.org/jdk/pull/25122#issuecomment-2863675379

From lkorinth at openjdk.org  Thu May  8 17:06:02 2025
From: lkorinth at openjdk.org (Leo Korinth)
Date: Thu, 8 May 2025 17:06:02 GMT
Subject: RFR: 8356171: Increase timeout for testcases as preparation for
 change of default timeout factor
In-Reply-To: <2nBGcIjZC03ee74o34IXFgtoEVTAkQV-xXEC28_oFbI=.da57d5a4-4546-4566-aa79-cacce01562d7@github.com>
References: <WCuOwzU4kPjno7_Ptc1SQN6KY6MEejJlVEQKhZhqgjo=.259ff478-ab46-4d31-aa4a-c4fffb8d54a7@github.com>
 <2nBGcIjZC03ee74o34IXFgtoEVTAkQV-xXEC28_oFbI=.da57d5a4-4546-4566-aa79-cacce01562d7@github.com>
Message-ID: <KviAqsI-z3Gh_lbVlBACoM9sv01Z9SH-VFHwQBWfguw=.90eea9c8-c960-4d77-8649-50f80d5c57ff@github.com>

On Thu, 8 May 2025 16:04:53 GMT, Stefan Karlsson <stefank at openjdk.org> 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 change (it will finally be changed to 1.0 in JDK-8260555). The next commit excludes some junit/testng tests where I can currently not change the timeout factor (CODETOOLS-7903961). Both these commits will be reverted before integrating the change. I will also apply copyright updates after the review.
>> 
>> In addition to changing the timeout factor, I am also using a library call to parse the timeout factor from the java properties (I can not use the library function everywhere as jtreg does not allow me to add @library notations to non testcase files).
>> 
>> My approach has been to run all test, and afterwards updating those that fails due to a timeout factor. The amount of updated testcases is huge, and my strategy has been to quadruple the timeout if I could not directly see that less was needed (thus the timeout will be the same after JDK-8260555 is implemented). In a few places I have added a bit more timeout so that it will work with the 0.7 timeout factor.
>> 
>> These fixes have been created when I have plown through testcases:
>> JDK-8352719: Add an equals sign to the modules statement
>> JDK-8352709: Remove bad timing annotations from WhileOpTest.java
>> JDK-8352074: Test MemoryLeak.java seems not to test what it is supposed to test
>> CODETOOLS-7903937: JTREG uses timeout factor on socket timeout but not on KEEPALIVE
>> CODETOOLS-7903961: Make default timeout configurable
>> 
>> Sometime in the future I will also fix:
>> 8260555: Change the default TIMEOUT_FACTOR from 4 to 1
>> 
>> for which I am awaiting:
>> CODETOOLS-7903961 that is fixed in jtreg 7.6, but we are still running 7.5.1+1
>> 
>> *After the review I will revert the two first commits, and update the copyrights*
>
> doc/testing.md line 385:
> 
>> 383: (`-timeoutFactor`). Also, some test cases that programmatically wait a
>> 384: certain amount of time will apply this factor. If we run in
>> 385: interpreted mode (`-Xcomp`), [RunTest.gmk](../make/RunTests.gmk)
> 
> Maybe
> Suggestion:
> 
> interpreted mode (`-Xint`), [RunTest.gmk](../make/RunTests.gmk)

Thanks for catching this fault of mine. I will update the text and change `interpreted mode`, as it is really `-Xcomp` we are looking at in the RunTest.gmk.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25122#discussion_r2080117016

From dfuchs at openjdk.org  Thu May  8 17:43:54 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Thu, 8 May 2025 17:43:54 GMT
Subject: RFR: 8356171: Increase timeout for testcases as preparation for
 change of default timeout factor
In-Reply-To: <WCuOwzU4kPjno7_Ptc1SQN6KY6MEejJlVEQKhZhqgjo=.259ff478-ab46-4d31-aa4a-c4fffb8d54a7@github.com>
References: <WCuOwzU4kPjno7_Ptc1SQN6KY6MEejJlVEQKhZhqgjo=.259ff478-ab46-4d31-aa4a-c4fffb8d54a7@github.com>
Message-ID: <Jcf97xCR7qOc2AP78rYPfx8LZPloVRpb9a1xfyJyNIY=.873b34c4-e4cf-4b79-b819-66a40ad71cde@github.com>

On Thu, 8 May 2025 14:51:24 GMT, Leo Korinth <lkorinth at openjdk.org> 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 change (it will finally be changed to 1.0 in JDK-8260555). The next commit excludes some junit/testng tests where I can currently not change the timeout factor (CODETOOLS-7903961). Both these commits will be reverted before integrating the change. I will also apply copyright updates after the review.
> 
> In addition to changing the timeout factor, I am also using a library call to parse the timeout factor from the java properties (I can not use the library function everywhere as jtreg does not allow me to add @library notations to non testcase files).
> 
> My approach has been to run all test, and afterwards updating those that fails due to a timeout factor. The amount of updated testcases is huge, and my strategy has been to quadruple the timeout if I could not directly see that less was needed (thus the timeout will be the same after JDK-8260555 is implemented). In a few places I have added a bit more timeout so that it will work with the 0.7 timeout factor.
> 
> These fixes have been created when I have plown through testcases:
> JDK-8352719: Add an equals sign to the modules statement
> JDK-8352709: Remove bad timing annotations from WhileOpTest.java
> JDK-8352074: Test MemoryLeak.java seems not to test what it is supposed to test
> CODETOOLS-7903937: JTREG uses timeout factor on socket timeout but not on KEEPALIVE
> CODETOOLS-7903961: Make default timeout configurable
> 
> Sometime in the future I will also fix:
> 8260555: Change the default TIMEOUT_FACTOR from 4 to 1
> 
> for which I am awaiting:
> CODETOOLS-7903961 that is fixed in jtreg 7.6, but we are still running 7.5.1+1
> 
> *After the review I will revert the two first commits, and update the copyrights*

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` is timing out intermittently on windows.
It would be good to flush out any such intermittent failures before this PR is integrated.
This might require multiple runs before we can get confidence.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25122#issuecomment-2863805648

From prr at openjdk.org  Thu May  8 20:02:52 2025
From: prr at openjdk.org (Phil Race)
Date: Thu, 8 May 2025 20:02:52 GMT
Subject: RFR: 8356171: Increase timeout for testcases as preparation for
 change of default timeout factor
In-Reply-To: <WCuOwzU4kPjno7_Ptc1SQN6KY6MEejJlVEQKhZhqgjo=.259ff478-ab46-4d31-aa4a-c4fffb8d54a7@github.com>
References: <WCuOwzU4kPjno7_Ptc1SQN6KY6MEejJlVEQKhZhqgjo=.259ff478-ab46-4d31-aa4a-c4fffb8d54a7@github.com>
Message-ID: <qUtOWdQzhA2aCO21XPrr2pdtKwJ-n_qDvTY2UprQmJQ=.3f11dd7d-5d0c-47a8-9b1c-2cdfbf3f542b@github.com>

On Thu, 8 May 2025 14:51:24 GMT, Leo Korinth <lkorinth at openjdk.org> 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 change (it will finally be changed to 1.0 in JDK-8260555). The next commit excludes some junit/testng tests where I can currently not change the timeout factor (CODETOOLS-7903961). Both these commits will be reverted before integrating the change. I will also apply copyright updates after the review.
> 
> In addition to changing the timeout factor, I am also using a library call to parse the timeout factor from the java properties (I can not use the library function everywhere as jtreg does not allow me to add @library notations to non testcase files).
> 
> My approach has been to run all test, and afterwards updating those that fails due to a timeout factor. The amount of updated testcases is huge, and my strategy has been to quadruple the timeout if I could not directly see that less was needed (thus the timeout will be the same after JDK-8260555 is implemented). In a few places I have added a bit more timeout so that it will work with the 0.7 timeout factor.
> 
> These fixes have been created when I have plown through testcases:
> JDK-8352719: Add an equals sign to the modules statement
> JDK-8352709: Remove bad timing annotations from WhileOpTest.java
> JDK-8352074: Test MemoryLeak.java seems not to test what it is supposed to test
> CODETOOLS-7903937: JTREG uses timeout factor on socket timeout but not on KEEPALIVE
> CODETOOLS-7903961: Make default timeout configurable
> 
> Sometime in the future I will also fix:
> 8260555: Change the default TIMEOUT_FACTOR from 4 to 1
> 
> for which I am awaiting:
> CODETOOLS-7903961 that is fixed in jtreg 7.6, but we are still running 7.5.1+1
> 
> *After the review I will revert the two first commits, and update the copyrights*

test/jdk/java/awt/font/NumericShaper/MTTest.java

- * @run main/timeout=300/othervm MTTest
+ * @run main/timeout=1200/othervm MTTest

I'm puzzling over why you saw this test fail with timeout = 300 .. or perhaps you saw it fail with 0.7 ? Which would amount to 210 seconds .. that might just be enough to cause it to fail because if you look at the whole test you'll see it wants the core loops of the test to run for 180 seconds.

https://openjdk.github.io/cr/?repo=jdk&pr=25122&range=00#new-144-test/jdk/java/awt/font/NumericShaper/MTTest.java

So 300 was fine, and 1200 isn't needed.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25122#issuecomment-2864133534

From lmesnik at openjdk.org  Thu May  8 23:12:52 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Thu, 8 May 2025 23:12:52 GMT
Subject: RFR: 8356171: Increase timeout for testcases as preparation for
 change of default timeout factor
In-Reply-To: <KviAqsI-z3Gh_lbVlBACoM9sv01Z9SH-VFHwQBWfguw=.90eea9c8-c960-4d77-8649-50f80d5c57ff@github.com>
References: <WCuOwzU4kPjno7_Ptc1SQN6KY6MEejJlVEQKhZhqgjo=.259ff478-ab46-4d31-aa4a-c4fffb8d54a7@github.com>
 <2nBGcIjZC03ee74o34IXFgtoEVTAkQV-xXEC28_oFbI=.da57d5a4-4546-4566-aa79-cacce01562d7@github.com>
 <KviAqsI-z3Gh_lbVlBACoM9sv01Z9SH-VFHwQBWfguw=.90eea9c8-c960-4d77-8649-50f80d5c57ff@github.com>
Message-ID: <inHeApQE1qTo35yQi6vzs6LYuATsr8NxmEMOU_1x_5c=.6ea734d1-63f2-47dc-a245-23d3233c76e4@github.com>

On Thu, 8 May 2025 17:03:03 GMT, Leo Korinth <lkorinth at openjdk.org> wrote:

>> doc/testing.md line 385:
>> 
>>> 383: (`-timeoutFactor`). Also, some test cases that programmatically wait a
>>> 384: certain amount of time will apply this factor. If we run in
>>> 385: interpreted mode (`-Xcomp`), [RunTest.gmk](../make/RunTests.gmk)
>> 
>> Maybe
>> Suggestion:
>> 
>> interpreted mode (`-Xint`), [RunTest.gmk](../make/RunTests.gmk)
>
> Thanks for catching this fault of mine. I will update the text and change `interpreted mode`, as it is really `-Xcomp` we are looking at in the RunTest.gmk.

yep, let use Xcomp, the Xint is not really supported, a lot of tests might start failing

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25122#discussion_r2080606853

From lmesnik at openjdk.org  Fri May  9 00:55:54 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Fri, 9 May 2025 00:55:54 GMT
Subject: RFR: 8356171: Increase timeout for testcases as preparation for
 change of default timeout factor
In-Reply-To: <N027ImJIxB-7XV_sMWQf9VR2KTnUK6Fq8Tmkn8uXNYg=.f2a0f896-88a1-4702-adef-4514c9e155c1@github.com>
References: <WCuOwzU4kPjno7_Ptc1SQN6KY6MEejJlVEQKhZhqgjo=.259ff478-ab46-4d31-aa4a-c4fffb8d54a7@github.com>
 <N027ImJIxB-7XV_sMWQf9VR2KTnUK6Fq8Tmkn8uXNYg=.f2a0f896-88a1-4702-adef-4514c9e155c1@github.com>
Message-ID: <2oUdV1ca6y_cEHL3kTptk3jAlwCwnvsLGhRIAhVEUo8=.010c2226-c5ec-4508-be7f-90d244b2b7dc@github.com>

On Thu, 8 May 2025 16:43:10 GMT, Leo Korinth <lkorinth at openjdk.org> 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 change (it will finally be changed to 1.0 in JDK-8260555). The next commit excludes some junit/testng tests where I can currently not change the timeout factor (CODETOOLS-7903961). Both these commits will be reverted before integrating the change. I will also apply copyright updates after the review.
>> 
>> In addition to changing the timeout factor, I am also using a library call to parse the timeout factor from the java properties (I can not use the library function everywhere as jtreg does not allow me to add @library notations to non testcase files).
>> 
>> My approach has been to run all test, and afterwards updating those that fails due to a timeout factor. The amount of updated testcases is huge, and my strategy has been to quadruple the timeout if I could not directly see that less was needed (thus the timeout will be the same after JDK-8260555 is implemented). In a few places I have added a bit more timeout so that it will work with the 0.7 timeout factor.
>> 
>> These fixes have been created when I have plown through testcases:
>> JDK-8352719: Add an equals sign to the modules statement
>> JDK-8352709: Remove bad timing annotations from WhileOpTest.java
>> JDK-8352074: Test MemoryLeak.java seems not to test what it is supposed to test
>> CODETOOLS-7903937: JTREG uses timeout factor on socket timeout but not on KEEPALIVE
>> CODETOOLS-7903961: Make default timeout configurable
>> 
>> Sometime in the future I will also fix:
>> 8260555: Change the default TIMEOUT_FACTOR from 4 to 1
>> 
>> for which I am awaiting:
>> CODETOOLS-7903961 that is fixed in jtreg 7.6, but we are still running 7.5.1+1
>> 
>> *After the review I will revert the two first commits, and update the copyrights*
>
> After I revert the two first commits and go back to a timeout factor of 4, I will run tier 1-8 again.

@lkorinth Can you please proposed fix for https://bugs.openjdk.org/browse/JDK-8260555 to make it more clear the complete goal of the fix.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25122#issuecomment-2864795990

From dholmes at openjdk.org  Fri May  9 04:57:50 2025
From: dholmes at openjdk.org (David Holmes)
Date: Fri, 9 May 2025 04:57:50 GMT
Subject: RFR: 8356171: Increase timeout for testcases as preparation for
 change of default timeout factor
In-Reply-To: <WCuOwzU4kPjno7_Ptc1SQN6KY6MEejJlVEQKhZhqgjo=.259ff478-ab46-4d31-aa4a-c4fffb8d54a7@github.com>
References: <WCuOwzU4kPjno7_Ptc1SQN6KY6MEejJlVEQKhZhqgjo=.259ff478-ab46-4d31-aa4a-c4fffb8d54a7@github.com>
Message-ID: <RY1U1_FEDrD_vm1RnfRFeQXKYhrm9frg1hkGnCFd5EE=.47796bf1-4b49-4572-9ea3-f8e43f0d350b@github.com>

On Thu, 8 May 2025 14:51:24 GMT, Leo Korinth <lkorinth at openjdk.org> 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 change (it will finally be changed to 1.0 in JDK-8260555). The next commit excludes some junit/testng tests where I can currently not change the timeout factor (CODETOOLS-7903961). Both these commits will be reverted before integrating the change. I will also apply copyright updates after the review.
> 
> In addition to changing the timeout factor, I am also using a library call to parse the timeout factor from the java properties (I can not use the library function everywhere as jtreg does not allow me to add @library notations to non testcase files).
> 
> My approach has been to run all test, and afterwards updating those that fails due to a timeout factor. The amount of updated testcases is huge, and my strategy has been to quadruple the timeout if I could not directly see that less was needed (thus the timeout will be the same after JDK-8260555 is implemented). In a few places I have added a bit more timeout so that it will work with the 0.7 timeout factor.
> 
> These fixes have been created when I have plown through testcases:
> JDK-8352719: Add an equals sign to the modules statement
> JDK-8352709: Remove bad timing annotations from WhileOpTest.java
> JDK-8352074: Test MemoryLeak.java seems not to test what it is supposed to test
> CODETOOLS-7903937: JTREG uses timeout factor on socket timeout but not on KEEPALIVE
> CODETOOLS-7903961: Make default timeout configurable
> 
> Sometime in the future I will also fix:
> 8260555: Change the default TIMEOUT_FACTOR from 4 to 1
> 
> for which I am awaiting:
> CODETOOLS-7903961 that is fixed in jtreg 7.6, but we are still running 7.5.1+1
> 
> *After the review I will revert the two first commits, and update the copyrights*

My biggest concern with this change is that potentially any test that implicitly uses the default timeout, and which passes with no problem with a factor of 4, may now need to have an explicit timeout set due to the factor of 1. I see this change in a number of tests (default timeout of 120s expressed as a new timeout of 480s to maintain equivalence**), but how many times did you run the tiers? I fear that the gatekeepers will be playing timeout whack-a-mole once these changes are put in.

** though another option would be to update the jtreg default timeout instead.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25122#issuecomment-2865099247

From dfuchs at openjdk.org  Fri May  9 07:18:52 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Fri, 9 May 2025 07:18:52 GMT
Subject: RFR: 8356171: Increase timeout for testcases as preparation for
 change of default timeout factor
In-Reply-To: <Jcf97xCR7qOc2AP78rYPfx8LZPloVRpb9a1xfyJyNIY=.873b34c4-e4cf-4b79-b819-66a40ad71cde@github.com>
References: <WCuOwzU4kPjno7_Ptc1SQN6KY6MEejJlVEQKhZhqgjo=.259ff478-ab46-4d31-aa4a-c4fffb8d54a7@github.com>
 <Jcf97xCR7qOc2AP78rYPfx8LZPloVRpb9a1xfyJyNIY=.873b34c4-e4cf-4b79-b819-66a40ad71cde@github.com>
Message-ID: <bwBKVa6r3t5CTOTZK1pErpB1hgFdzm9X4TUj1K3HoLc=.cd421890-b1a2-48d7-832e-914bee047375@github.com>

On Thu, 8 May 2025 17:41:02 GMT, Daniel Fuchs <dfuchs at openjdk.org> 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` is timing out intermittently on windows.
> It would be good to flush out any such intermittent failures before this PR is integrated.
> This might require multiple runs before we can get confidence.

Results came back - another intermittent timeout failure (much more frequent) observed in:
`java/net/httpclient/CancelledResponse.java` on macOS x64

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25122#issuecomment-2865413003

From cstein at openjdk.org  Fri May  9 07:36:51 2025
From: cstein at openjdk.org (Christian Stein)
Date: Fri, 9 May 2025 07:36:51 GMT
Subject: RFR: 8356171: Increase timeout for testcases as preparation for
 change of default timeout factor
In-Reply-To: <RY1U1_FEDrD_vm1RnfRFeQXKYhrm9frg1hkGnCFd5EE=.47796bf1-4b49-4572-9ea3-f8e43f0d350b@github.com>
References: <WCuOwzU4kPjno7_Ptc1SQN6KY6MEejJlVEQKhZhqgjo=.259ff478-ab46-4d31-aa4a-c4fffb8d54a7@github.com>
 <RY1U1_FEDrD_vm1RnfRFeQXKYhrm9frg1hkGnCFd5EE=.47796bf1-4b49-4572-9ea3-f8e43f0d350b@github.com>
Message-ID: <P_bn9YLGadoCvpQ4U3pQCWqa_FgbqOs_Smf_TRfTUxw=.5db4086c-fef8-437b-aa77-26124ea44177@github.com>

On Fri, 9 May 2025 04:54:52 GMT, David Holmes <dholmes at openjdk.org> wrote:

> [...]
> ** though another option would be to update the jtreg default timeout instead.

And affect all other tests, too? I'd rather let the default stay on the former hard-coded 120s value.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25122#issuecomment-2865469908

From alanb at openjdk.org  Fri May  9 08:12:52 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 9 May 2025 08:12:52 GMT
Subject: RFR: 8356171: Increase timeout for testcases as preparation for
 change of default timeout factor
In-Reply-To: <N027ImJIxB-7XV_sMWQf9VR2KTnUK6Fq8Tmkn8uXNYg=.f2a0f896-88a1-4702-adef-4514c9e155c1@github.com>
References: <WCuOwzU4kPjno7_Ptc1SQN6KY6MEejJlVEQKhZhqgjo=.259ff478-ab46-4d31-aa4a-c4fffb8d54a7@github.com>
 <N027ImJIxB-7XV_sMWQf9VR2KTnUK6Fq8Tmkn8uXNYg=.f2a0f896-88a1-4702-adef-4514c9e155c1@github.com>
Message-ID: <togAOydR2ZGmRMpEDKHz7PXzdWIRLYaU6sFIlHUXUw4=.cdb2a446-5f7c-438e-8f1e-2d8bad8c9327@github.com>

On Thu, 8 May 2025 16:43:10 GMT, Leo Korinth <lkorinth at openjdk.org> 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 change (it will finally be changed to 1.0 in JDK-8260555). The next commit excludes some junit/testng tests where I can currently not change the timeout factor (CODETOOLS-7903961). Both these commits will be reverted before integrating the change. I will also apply copyright updates after the review.
>> 
>> In addition to changing the timeout factor, I am also using a library call to parse the timeout factor from the java properties (I can not use the library function everywhere as jtreg does not allow me to add @library notations to non testcase files).
>> 
>> My approach has been to run all test, and afterwards updating those that fails due to a timeout factor. The amount of updated testcases is huge, and my strategy has been to quadruple the timeout if I could not directly see that less was needed (thus the timeout will be the same after JDK-8260555 is implemented). In a few places I have added a bit more timeout so that it will work with the 0.7 timeout factor.
>> 
>> These fixes have been created when I have plown through testcases:
>> JDK-8352719: Add an equals sign to the modules statement
>> JDK-8352709: Remove bad timing annotations from WhileOpTest.java
>> JDK-8352074: Test MemoryLeak.java seems not to test what it is supposed to test
>> CODETOOLS-7903937: JTREG uses timeout factor on socket timeout but not on KEEPALIVE
>> CODETOOLS-7903961: Make default timeout configurable
>> 
>> Sometime in the future I will also fix:
>> 8260555: Change the default TIMEOUT_FACTOR from 4 to 1
>> 
>> for which I am awaiting:
>> CODETOOLS-7903961 that is fixed in jtreg 7.6, but we are still running 7.5.1+1
>> 
>> *After the review I will revert the two first commits, and update the copyrights*
>
> After I revert the two first commits and go back to a timeout factor of 4, I will run tier 1-8 again.

@lkorinth Moving to a TIMEOUT_FACTOR of 1 seems a good goal. Would it be possible to expand a bit on what repeat testing was done to identify the tests to add /timeout ?  If I read it correctly, any tests using /timeout=N have been to bumped to 4*N so no change. Most tests don't use /timeout so I assume many runs were done to identify the tests that would timeout with if there was no scaling. Test machines vary, as does the test execution times when running concurrently with other tests, so I think it would help if you could say a bit more, even to confirm that it was many test runs.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25122#issuecomment-2865581927

From lkorinth at openjdk.org  Fri May  9 08:32:55 2025
From: lkorinth at openjdk.org (Leo Korinth)
Date: Fri, 9 May 2025 08:32:55 GMT
Subject: RFR: 8356171: Increase timeout for testcases as preparation for
 change of default timeout factor
In-Reply-To: <WCuOwzU4kPjno7_Ptc1SQN6KY6MEejJlVEQKhZhqgjo=.259ff478-ab46-4d31-aa4a-c4fffb8d54a7@github.com>
References: <WCuOwzU4kPjno7_Ptc1SQN6KY6MEejJlVEQKhZhqgjo=.259ff478-ab46-4d31-aa4a-c4fffb8d54a7@github.com>
Message-ID: <uabWdORniwCo0BELgwEHL9xwszL7WvN02cMLTu253K4=.de2529aa-23d2-4c86-9133-504f4146c93e@github.com>

On Thu, 8 May 2025 14:51:24 GMT, Leo Korinth <lkorinth at openjdk.org> 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 change (it will finally be changed to 1.0 in JDK-8260555). The next commit excludes some junit/testng tests where I can currently not change the timeout factor (CODETOOLS-7903961). Both these commits will be reverted before integrating the change. I will also apply copyright updates after the review.
> 
> In addition to changing the timeout factor, I am also using a library call to parse the timeout factor from the java properties (I can not use the library function everywhere as jtreg does not allow me to add @library notations to non testcase files).
> 
> My approach has been to run all test, and afterwards updating those that fails due to a timeout factor. The amount of updated testcases is huge, and my strategy has been to quadruple the timeout if I could not directly see that less was needed (thus the timeout will be the same after JDK-8260555 is implemented). In a few places I have added a bit more timeout so that it will work with the 0.7 timeout factor.
> 
> These fixes have been created when I have plown through testcases:
> JDK-8352719: Add an equals sign to the modules statement
> JDK-8352709: Remove bad timing annotations from WhileOpTest.java
> JDK-8352074: Test MemoryLeak.java seems not to test what it is supposed to test
> CODETOOLS-7903937: JTREG uses timeout factor on socket timeout but not on KEEPALIVE
> CODETOOLS-7903961: Make default timeout configurable
> 
> Sometime in the future I will also fix:
> 8260555: Change the default TIMEOUT_FACTOR from 4 to 1
> 
> for which I am awaiting:
> CODETOOLS-7903961 that is fixed in jtreg 7.6, but we are still running 7.5.1+1
> 
> *After the review I will revert the two first commits, and update the copyrights*

I feel almost all of the comments raised here are for me changing the timeout factor to `1`. I will try to answer those questions here as well, but note that the timeout factor is not to be changed to `1` in this pull request and will remain 4, so excluding bugs I might have introduced, tiers would --- if anything --- be running more stable after the change as I have only increased timeouts.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25122#issuecomment-2865644966

From lkorinth at openjdk.org  Fri May  9 08:42:58 2025
From: lkorinth at openjdk.org (Leo Korinth)
Date: Fri, 9 May 2025 08:42:58 GMT
Subject: RFR: 8356171: Increase timeout for testcases as preparation for
 change of default timeout factor
In-Reply-To: <bwBKVa6r3t5CTOTZK1pErpB1hgFdzm9X4TUj1K3HoLc=.cd421890-b1a2-48d7-832e-914bee047375@github.com>
References: <WCuOwzU4kPjno7_Ptc1SQN6KY6MEejJlVEQKhZhqgjo=.259ff478-ab46-4d31-aa4a-c4fffb8d54a7@github.com>
 <Jcf97xCR7qOc2AP78rYPfx8LZPloVRpb9a1xfyJyNIY=.873b34c4-e4cf-4b79-b819-66a40ad71cde@github.com>
 <bwBKVa6r3t5CTOTZK1pErpB1hgFdzm9X4TUj1K3HoLc=.cd421890-b1a2-48d7-832e-914bee047375@github.com>
Message-ID: <PMQVll64pUTOaANd4itfY08A95oDXdFxCjWFdsbXNws=.081897dc-31ce-476d-929a-283b6735c492@github.com>

On Fri, 9 May 2025 07:14:11 GMT, Daniel Fuchs <dfuchs at openjdk.org> 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` is timing out intermittently on windows. It would be good to flush out any such intermittent failures before this PR is integrated. This might require multiple runs before we can get confidence.

My change of timeout factor to `0.7` is only temporal, as I said: it will be reverted to `4` before integration. Naturally, a few test cases will timeout when I do this /temporal/ change, hopefully `java/net/httpclient/RedirectTimeoutTest.java` will behave well with a timeout factor of `1` instead of `0.7`, but note that I will revert the timeout factor to `4` before integration. 

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 but not on KEEPALIVE)

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25122#issuecomment-2865685066

From stefank at openjdk.org  Fri May  9 08:48:51 2025
From: stefank at openjdk.org (Stefan Karlsson)
Date: Fri, 9 May 2025 08:48:51 GMT
Subject: RFR: 8356171: Increase timeout for testcases as preparation for
 change of default timeout factor
In-Reply-To: <PMQVll64pUTOaANd4itfY08A95oDXdFxCjWFdsbXNws=.081897dc-31ce-476d-929a-283b6735c492@github.com>
References: <WCuOwzU4kPjno7_Ptc1SQN6KY6MEejJlVEQKhZhqgjo=.259ff478-ab46-4d31-aa4a-c4fffb8d54a7@github.com>
 <Jcf97xCR7qOc2AP78rYPfx8LZPloVRpb9a1xfyJyNIY=.873b34c4-e4cf-4b79-b819-66a40ad71cde@github.com>
 <bwBKVa6r3t5CTOTZK1pErpB1hgFdzm9X4TUj1K3HoLc=.cd421890-b1a2-48d7-832e-914bee047375@github.com>
 <PMQVll64pUTOaANd4itfY08A95oDXdFxCjWFdsbXNws=.081897dc-31ce-476d-929a-283b6735c492@github.com>
Message-ID: <1Sa3h-gkyVwOLDdj_wJdFohAGYbhYhbAYIaqHCmW7oY=.3b58c23d-cf55-421b-aeec-e149809826f2@github.com>

On Fri, 9 May 2025 08:40:44 GMT, Leo Korinth <lkorinth at openjdk.org> wrote:

> My change of timeout factor to 0.7 is only temporal, as I said: it will be reverted to 4 before integration.

Is really worth reverting back to 4 instead of trying to get jtreg released with CODETOOLS-7903961 and then integrate this change with a timeout factor of 1?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25122#issuecomment-2865697701

From lkorinth at openjdk.org  Fri May  9 09:02:55 2025
From: lkorinth at openjdk.org (Leo Korinth)
Date: Fri, 9 May 2025 09:02:55 GMT
Subject: RFR: 8356171: Increase timeout for testcases as preparation for
 change of default timeout factor
In-Reply-To: <qUtOWdQzhA2aCO21XPrr2pdtKwJ-n_qDvTY2UprQmJQ=.3f11dd7d-5d0c-47a8-9b1c-2cdfbf3f542b@github.com>
References: <WCuOwzU4kPjno7_Ptc1SQN6KY6MEejJlVEQKhZhqgjo=.259ff478-ab46-4d31-aa4a-c4fffb8d54a7@github.com>
 <qUtOWdQzhA2aCO21XPrr2pdtKwJ-n_qDvTY2UprQmJQ=.3f11dd7d-5d0c-47a8-9b1c-2cdfbf3f542b@github.com>
Message-ID: <0AKC-4omm-W24u11ifhGm8Do8_5sqwPMJz6q3A71FNE=.f4209d38-51d6-4eda-b11e-d670e5ee5575@github.com>

On Thu, 8 May 2025 20:00:21 GMT, Phil Race <prr at openjdk.org> wrote:

> test/jdk/java/awt/font/NumericShaper/MTTest.java
> 
>     * * @run main/timeout=300/othervm MTTest
> 
> 
>     * * @run main/timeout=1200/othervm MTTest
> 
> 
> I'm puzzling over why you saw this test fail with timeout = 300 .. or perhaps you saw it fail with 0.7 ? Which would amount to 210 seconds .. that might just be enough to cause it to fail because if you look at the whole test you'll see it wants the core loops of the test to run for 180 seconds.
> 
> https://openjdk.github.io/cr/?repo=jdk&pr=25122&range=00#new-144-test/jdk/java/awt/font/NumericShaper/MTTest.java
> 
> So 300 was fine, and 1200 isn't needed.

I started with a timeout factor less than `0.7` but I got hindered by CODETOOLS-7903937. That is probably the reason. Maybe I should change the timeout to 400? I think it is reasonable to handle a timeout factor somewhat less than 1 to weed out tight test cases. But maybe 300 is good enough?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25122#issuecomment-2865742871

From lkorinth at openjdk.org  Fri May  9 09:12:19 2025
From: lkorinth at openjdk.org (Leo Korinth)
Date: Fri, 9 May 2025 09:12:19 GMT
Subject: RFR: 8356171: Increase timeout for testcases as preparation for
 change of default timeout factor
In-Reply-To: <0AKC-4omm-W24u11ifhGm8Do8_5sqwPMJz6q3A71FNE=.f4209d38-51d6-4eda-b11e-d670e5ee5575@github.com>
References: <WCuOwzU4kPjno7_Ptc1SQN6KY6MEejJlVEQKhZhqgjo=.259ff478-ab46-4d31-aa4a-c4fffb8d54a7@github.com>
 <qUtOWdQzhA2aCO21XPrr2pdtKwJ-n_qDvTY2UprQmJQ=.3f11dd7d-5d0c-47a8-9b1c-2cdfbf3f542b@github.com>
 <0AKC-4omm-W24u11ifhGm8Do8_5sqwPMJz6q3A71FNE=.f4209d38-51d6-4eda-b11e-d670e5ee5575@github.com>
Message-ID: <3-AQ92Sgr9tDJIWDO5OX43uBDLndiDN_3jyRj5t2z6Q=.af7cef0d-c447-4401-b4e0-e11a9bdba35b@github.com>

On Fri, 9 May 2025 08:58:15 GMT, Leo Korinth <lkorinth at openjdk.org> wrote:

>> test/jdk/java/awt/font/NumericShaper/MTTest.java
>> 
>> - * @run main/timeout=300/othervm MTTest
>> + * @run main/timeout=1200/othervm MTTest
>> 
>> I'm puzzling over why you saw this test fail with timeout = 300 .. or perhaps you saw it fail with 0.7 ? Which would amount to 210 seconds .. that might just be enough to cause it to fail because if you look at the whole test you'll see it wants the core loops of the test to run for 180 seconds.
>> 
>> https://openjdk.github.io/cr/?repo=jdk&pr=25122&range=00#new-144-test/jdk/java/awt/font/NumericShaper/MTTest.java
>> 
>> So 300 was fine, and 1200 isn't needed.
>
>> test/jdk/java/awt/font/NumericShaper/MTTest.java
>> 
>>     * * @run main/timeout=300/othervm MTTest
>> 
>> 
>>     * * @run main/timeout=1200/othervm MTTest
>> 
>> 
>> I'm puzzling over why you saw this test fail with timeout = 300 .. or perhaps you saw it fail with 0.7 ? Which would amount to 210 seconds .. that might just be enough to cause it to fail because if you look at the whole test you'll see it wants the core loops of the test to run for 180 seconds.
>> 
>> https://openjdk.github.io/cr/?repo=jdk&pr=25122&range=00#new-144-test/jdk/java/awt/font/NumericShaper/MTTest.java
>> 
>> So 300 was fine, and 1200 isn't needed.
> 
> I started with a timeout factor less than `0.7` but I got hindered by CODETOOLS-7903937. That is probably the reason. Maybe I should change the timeout to 400? I think it is reasonable to handle a timeout factor somewhat less than 1 to weed out tight test cases. But maybe 300 is good enough?

> @lkorinth Moving to a TIMEOUT_FACTOR of 1 seems a good goal. Would it be possible to expand a bit on what repeat testing was done to identify the tests to add /timeout ? If I read it correctly, any tests using /timeout=N have been to bumped to 4*N so no change if the scaling is adjusted in the future. Most tests don't use /timeout so I assume many runs were done to identify the tests that would timeout with if there was no scaling. Test machines vary, as does the test execution times when running concurrently with other tests, so I think it would help if you could say a bit more, even to confirm that it was many test runs.

The code was run as it currently looks (with a timeout factor of `0.7`), what timeout factor do you think I should use to test, and for how many times?

At the moment I am awaiting jtreg 7.6, I therefore guess the timeout factor change to `1` will happen after the fork.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25122#issuecomment-2865784064

From cstein at openjdk.org  Fri May  9 09:15:51 2025
From: cstein at openjdk.org (Christian Stein)
Date: Fri, 9 May 2025 09:15:51 GMT
Subject: RFR: 8356171: Increase timeout for testcases as preparation for
 change of default timeout factor
In-Reply-To: <3-AQ92Sgr9tDJIWDO5OX43uBDLndiDN_3jyRj5t2z6Q=.af7cef0d-c447-4401-b4e0-e11a9bdba35b@github.com>
References: <WCuOwzU4kPjno7_Ptc1SQN6KY6MEejJlVEQKhZhqgjo=.259ff478-ab46-4d31-aa4a-c4fffb8d54a7@github.com>
 <qUtOWdQzhA2aCO21XPrr2pdtKwJ-n_qDvTY2UprQmJQ=.3f11dd7d-5d0c-47a8-9b1c-2cdfbf3f542b@github.com>
 <0AKC-4omm-W24u11ifhGm8Do8_5sqwPMJz6q3A71FNE=.f4209d38-51d6-4eda-b11e-d670e5ee5575@github.com>
 <3-AQ92Sgr9tDJIWDO5OX43uBDLndiDN_3jyRj5t2z6Q=.af7cef0d-c447-4401-b4e0-e11a9bdba35b@github.com>
Message-ID: <LWO7Q1kcmK2ygzbo5WovS47Dbuj_vfNTrTCvtPe8eLs=.4247df94-1d6d-4be7-bd56-77257bea18f7@github.com>

On Fri, 9 May 2025 09:09:34 GMT, Leo Korinth <lkorinth at openjdk.org> wrote:

> At the moment I am awaiting jtreg 7.6, I therefore guess the timeout factor change to 1 will happen after the fork.

Note, that I moved the timeout configuration feature to `jtreg` 7.5.2 - which will be released soon.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25122#issuecomment-2865793769

From lkorinth at openjdk.org  Fri May  9 09:15:52 2025
From: lkorinth at openjdk.org (Leo Korinth)
Date: Fri, 9 May 2025 09:15:52 GMT
Subject: RFR: 8356171: Increase timeout for testcases as preparation for
 change of default timeout factor
In-Reply-To: <1Sa3h-gkyVwOLDdj_wJdFohAGYbhYhbAYIaqHCmW7oY=.3b58c23d-cf55-421b-aeec-e149809826f2@github.com>
References: <WCuOwzU4kPjno7_Ptc1SQN6KY6MEejJlVEQKhZhqgjo=.259ff478-ab46-4d31-aa4a-c4fffb8d54a7@github.com>
 <Jcf97xCR7qOc2AP78rYPfx8LZPloVRpb9a1xfyJyNIY=.873b34c4-e4cf-4b79-b819-66a40ad71cde@github.com>
 <bwBKVa6r3t5CTOTZK1pErpB1hgFdzm9X4TUj1K3HoLc=.cd421890-b1a2-48d7-832e-914bee047375@github.com>
 <PMQVll64pUTOaANd4itfY08A95oDXdFxCjWFdsbXNws=.081897dc-31ce-476d-929a-283b6735c492@github.com>
 <1Sa3h-gkyVwOLDdj_wJdFohAGYbhYhbAYIaqHCmW7oY=.3b58c23d-cf55-421b-aeec-e149809826f2@github.com>
Message-ID: <SmaG9WzhdR3hL3bZpPNbC6_0GYx9sQ9knU4WJUqk614=.9de2872d-396f-425c-8096-1d0b725e27d2@github.com>

On Fri, 9 May 2025 08:45:48 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

> > My change of timeout factor to 0.7 is only temporal, as I said: it will be reverted to 4 before integration.
> 
> Is really worth reverting back to 4 instead of trying to get jtreg released with CODETOOLS-7903961 and then integrate this change with a timeout factor of 1?

I think it is worth doing in two steps. First I do not want to postpone these limited changes, and second if I would have problems with JDK-8260555, it would be nice if those changes would be smaller and easier to revert.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25122#issuecomment-2865794195

From stefank at openjdk.org  Fri May  9 09:19:51 2025
From: stefank at openjdk.org (Stefan Karlsson)
Date: Fri, 9 May 2025 09:19:51 GMT
Subject: RFR: 8356171: Increase timeout for testcases as preparation for
 change of default timeout factor
In-Reply-To: <SmaG9WzhdR3hL3bZpPNbC6_0GYx9sQ9knU4WJUqk614=.9de2872d-396f-425c-8096-1d0b725e27d2@github.com>
References: <WCuOwzU4kPjno7_Ptc1SQN6KY6MEejJlVEQKhZhqgjo=.259ff478-ab46-4d31-aa4a-c4fffb8d54a7@github.com>
 <Jcf97xCR7qOc2AP78rYPfx8LZPloVRpb9a1xfyJyNIY=.873b34c4-e4cf-4b79-b819-66a40ad71cde@github.com>
 <bwBKVa6r3t5CTOTZK1pErpB1hgFdzm9X4TUj1K3HoLc=.cd421890-b1a2-48d7-832e-914bee047375@github.com>
 <PMQVll64pUTOaANd4itfY08A95oDXdFxCjWFdsbXNws=.081897dc-31ce-476d-929a-283b6735c492@github.com>
 <1Sa3h-gkyVwOLDdj_wJdFohAGYbhYhbAYIaqHCmW7oY=.3b58c23d-cf55-421b-aeec-e149809826f2@github.com>
 <SmaG9WzhdR3hL3bZpPNbC6_0GYx9sQ9knU4WJUqk614=.9de2872d-396f-425c-8096-1d0b725e27d2@github.com>
Message-ID: <rN9e2v3Ja1Kz4w4CsS6pDyFKNs88tAacAG4wiwWaK6w=.abf1d75b-861b-4de9-8e7b-61deca3e5e05@github.com>

On Fri, 9 May 2025 09:13:41 GMT, Leo Korinth <lkorinth at openjdk.org> wrote:

> > > My change of timeout factor to 0.7 is only temporal, as I said: it will be reverted to 4 before integration.
> > 
> > 
> > Is really worth reverting back to 4 instead of trying to get jtreg released with CODETOOLS-7903961 and then integrate this change with a timeout factor of 1?
> 
> I think it is worth doing in two steps. First I do not want to postpone these limited changes, and second if I would have problems with JDK-8260555, it would be nice if those changes would be smaller and easier to revert.

I understand the risk of being blocked on JDK-8260555, but frankly, if someone wants to block the change from 4 to 1 I'm not sure this PR is worth doing. We have enough groups represented in this PR so let's ask here: is anyone is opposing the idea of JDK-8260555?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25122#issuecomment-2865804474

From dfuchs at openjdk.org  Fri May  9 09:33:52 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Fri, 9 May 2025 09:33:52 GMT
Subject: RFR: 8356171: Increase timeout for testcases as preparation for
 change of default timeout factor
In-Reply-To: <PMQVll64pUTOaANd4itfY08A95oDXdFxCjWFdsbXNws=.081897dc-31ce-476d-929a-283b6735c492@github.com>
References: <WCuOwzU4kPjno7_Ptc1SQN6KY6MEejJlVEQKhZhqgjo=.259ff478-ab46-4d31-aa4a-c4fffb8d54a7@github.com>
 <Jcf97xCR7qOc2AP78rYPfx8LZPloVRpb9a1xfyJyNIY=.873b34c4-e4cf-4b79-b819-66a40ad71cde@github.com>
 <bwBKVa6r3t5CTOTZK1pErpB1hgFdzm9X4TUj1K3HoLc=.cd421890-b1a2-48d7-832e-914bee047375@github.com>
 <PMQVll64pUTOaANd4itfY08A95oDXdFxCjWFdsbXNws=.081897dc-31ce-476d-929a-283b6735c492@github.com>
Message-ID: <vhPQ5uxCX4mkm_a34_Elnbjxazr49tOXu_ezw8YbY_g=.81d3c926-7a82-4f4a-95b2-336c63350801@github.com>

On Fri, 9 May 2025 08:40:44 GMT, Leo Korinth <lkorinth at openjdk.org> 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 but not on KEEPALIVE)

Yes - I understand. My point is that there are probably more tests that will need an extended timeout than those that you have already modified. And we want to find out which before the actual change from 4 to 1.0. IMO if a test fails intermittently with 0.7, it's a good indication that it might continue failling intermittently with 1.0, and therefore it should be updated in this PR too.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25122#issuecomment-2865849069

From nbenalla at openjdk.org  Fri May  9 11:39:44 2025
From: nbenalla at openjdk.org (Nizar Benalla)
Date: Fri, 9 May 2025 11:39:44 GMT
Subject: RFR: 8177100: APIs duplicated in JavaDoc [v2]
In-Reply-To: <0NrLP37RZ6I7ytBxcNyNFReQVvgu-6p_-HbSbHW9ZRM=.c7fd5ae4-8c8d-48ea-8349-5c92a2f78c71@github.com>
References: <0NrLP37RZ6I7ytBxcNyNFReQVvgu-6p_-HbSbHW9ZRM=.c7fd5ae4-8c8d-48ea-8349-5c92a2f78c71@github.com>
Message-ID: <q8VIalvUGO_j9CNKh2AjZLNcu3gEzZCQbQu7eohE7jE=.ac756b58-8077-4594-b7ea-1854effb915c@github.com>

> Please review this patch to fix a bug where a method can be documented multiple times 
> Consider these 4 classes
> 
>                     A       (interface)
>                    / \
>                   /   \
> (abstract class)  C     B   ( interface)
>                   \   /
>                    \ /
>                     D       (class)
> 
> 
> Where `A` declares `testA()`, `C` implements it `public final void testA()`, `B` extends `A` but does *not* override it, `D` extends `C` and implements `B`
> 
> In the generated javadoc, `testA()` is documented twice.
> 
> ![Screenshot 2025-05-08 at 15 51 19](https://github.com/user-attachments/assets/46538e61-1546-4128-8041-296d8491406f)
> 
> After the patch, `testA()` is only documented once:
> 
> ![Screenshot 2025-05-08 at 15 52 16](https://github.com/user-attachments/assets/a6b86a21-7104-460c-8f3f-36cee5962eed)

Nizar Benalla has updated the pull request incrementally with one additional commit since the last revision:

  simplify check

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/25123/files
  - new: https://git.openjdk.org/jdk/pull/25123/files/4a55b006..41578ad2

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25123&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25123&range=00-01

  Stats: 19 lines in 1 file changed: 0 ins; 11 del; 8 mod
  Patch: https://git.openjdk.org/jdk/pull/25123.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25123/head:pull/25123

PR: https://git.openjdk.org/jdk/pull/25123

From liach at openjdk.org  Fri May  9 12:19:54 2025
From: liach at openjdk.org (Chen Liang)
Date: Fri, 9 May 2025 12:19:54 GMT
Subject: RFR: 8177100: APIs duplicated in JavaDoc [v2]
In-Reply-To: <q8VIalvUGO_j9CNKh2AjZLNcu3gEzZCQbQu7eohE7jE=.ac756b58-8077-4594-b7ea-1854effb915c@github.com>
References: <0NrLP37RZ6I7ytBxcNyNFReQVvgu-6p_-HbSbHW9ZRM=.c7fd5ae4-8c8d-48ea-8349-5c92a2f78c71@github.com>
 <q8VIalvUGO_j9CNKh2AjZLNcu3gEzZCQbQu7eohE7jE=.ac756b58-8077-4594-b7ea-1854effb915c@github.com>
Message-ID: <hCzvzj1RXyuYvh65yGYk1jAEeZrLBQVOc9RZiETM-_4=.9be797d9-1e15-4866-b6d9-2db72e620e48@github.com>

On Fri, 9 May 2025 11:39:44 GMT, Nizar Benalla <nbenalla at openjdk.org> wrote:

>> Please review this patch to fix a bug where a method can be documented multiple times 
>> Consider these 4 classes
>> 
>>                     A       (interface)
>>                    / \
>>                   /   \
>> (abstract class)  C     B   ( interface)
>>                   \   /
>>                    \ /
>>                     D       (class)
>> 
>> 
>> Where `A` declares `testA()`, `C` implements it `public final void testA()`, `B` extends `A` but does *not* override it, `D` extends `C` and implements `B`
>> 
>> In the generated javadoc, `testA()` is documented twice.
>> 
>> ![Screenshot 2025-05-08 at 15 51 19](https://github.com/user-attachments/assets/46538e61-1546-4128-8041-296d8491406f)
>> 
>> After the patch, `testA()` is only documented once:
>> 
>> ![Screenshot 2025-05-08 at 15 52 16](https://github.com/user-attachments/assets/a6b86a21-7104-460c-8f3f-36cee5962eed)
>
> Nizar Benalla has updated the pull request incrementally with one additional commit since the last revision:
> 
>   simplify check

Looks good, thanks!

-------------

Marked as reviewed by liach (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25123#pullrequestreview-2828096917

From dholmes at openjdk.org  Fri May  9 12:21:54 2025
From: dholmes at openjdk.org (David Holmes)
Date: Fri, 9 May 2025 12:21:54 GMT
Subject: RFR: 8356171: Increase timeout for testcases as preparation for
 change of default timeout factor
In-Reply-To: <WCuOwzU4kPjno7_Ptc1SQN6KY6MEejJlVEQKhZhqgjo=.259ff478-ab46-4d31-aa4a-c4fffb8d54a7@github.com>
References: <WCuOwzU4kPjno7_Ptc1SQN6KY6MEejJlVEQKhZhqgjo=.259ff478-ab46-4d31-aa4a-c4fffb8d54a7@github.com>
Message-ID: <3CKLh1TDhqMNxlWyINFVMAI6MGe_s2rJrgnfzXYpx2M=.ab9a5cb5-9671-4b90-ba81-83f65b82cd6d@github.com>

On Thu, 8 May 2025 14:51:24 GMT, Leo Korinth <lkorinth at openjdk.org> 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 change (it will finally be changed to 1.0 in JDK-8260555). The next commit excludes some junit/testng tests where I can currently not change the timeout factor (CODETOOLS-7903961). Both these commits will be reverted before integrating the change. I will also apply copyright updates after the review.
> 
> In addition to changing the timeout factor, I am also using a library call to parse the timeout factor from the java properties (I can not use the library function everywhere as jtreg does not allow me to add @library notations to non testcase files).
> 
> My approach has been to run all test, and afterwards updating those that fails due to a timeout factor. The amount of updated testcases is huge, and my strategy has been to quadruple the timeout if I could not directly see that less was needed (thus the timeout will be the same after JDK-8260555 is implemented). In a few places I have added a bit more timeout so that it will work with the 0.7 timeout factor.
> 
> These fixes have been created when I have plown through testcases:
> JDK-8352719: Add an equals sign to the modules statement
> JDK-8352709: Remove bad timing annotations from WhileOpTest.java
> JDK-8352074: Test MemoryLeak.java seems not to test what it is supposed to test
> CODETOOLS-7903937: JTREG uses timeout factor on socket timeout but not on KEEPALIVE
> CODETOOLS-7903961: Make default timeout configurable
> 
> Sometime in the future I will also fix:
> 8260555: Change the default TIMEOUT_FACTOR from 4 to 1
> 
> for which I am awaiting:
> CODETOOLS-7903961 that is fixed in jtreg 7.6, but we are still running 7.5.1+1
> 
> *After the review I will revert the two first commits, and update the copyrights*

I saw this PR as preparation for the change of the timeout factor so they could be reviewed distinctly and then integrated close together. So it is natural that people are querying how the proposed changes will work with that change - in particular if it will require explicit timeouts to be added to a lot of tests that don't presently have them.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25122#issuecomment-2866338479

From hannesw at openjdk.org  Fri May  9 12:45:51 2025
From: hannesw at openjdk.org (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=)
Date: Fri, 9 May 2025 12:45:51 GMT
Subject: RFR: 8177100: APIs duplicated in JavaDoc [v2]
In-Reply-To: <q8VIalvUGO_j9CNKh2AjZLNcu3gEzZCQbQu7eohE7jE=.ac756b58-8077-4594-b7ea-1854effb915c@github.com>
References: <0NrLP37RZ6I7ytBxcNyNFReQVvgu-6p_-HbSbHW9ZRM=.c7fd5ae4-8c8d-48ea-8349-5c92a2f78c71@github.com>
 <q8VIalvUGO_j9CNKh2AjZLNcu3gEzZCQbQu7eohE7jE=.ac756b58-8077-4594-b7ea-1854effb915c@github.com>
Message-ID: <2u-MWHrsSrN-L6emu0P-Zd_ius8srN8Ms_ofUZOTm78=.f6cee5f4-dd3f-44a6-b150-6c9bfe039520@github.com>

On Fri, 9 May 2025 11:39:44 GMT, Nizar Benalla <nbenalla at openjdk.org> wrote:

>> Please review this patch to fix a bug where a method can be documented multiple times 
>> Consider these 4 classes
>> 
>>                     A       (interface)
>>                    / \
>>                   /   \
>> (abstract class)  C     B   ( interface)
>>                   \   /
>>                    \ /
>>                     D       (class)
>> 
>> 
>> Where `A` declares `testA()`, `C` implements it `public final void testA()`, `B` extends `A` but does *not* override it, `D` extends `C` and implements `B`
>> 
>> In the generated javadoc, `testA()` is documented twice.
>> 
>> ![Screenshot 2025-05-08 at 15 51 19](https://github.com/user-attachments/assets/46538e61-1546-4128-8041-296d8491406f)
>> 
>> After the patch, `testA()` is only documented once:
>> 
>> ![Screenshot 2025-05-08 at 15 52 16](https://github.com/user-attachments/assets/a6b86a21-7104-460c-8f3f-36cee5962eed)
>
> Nizar Benalla has updated the pull request incrementally with one additional commit since the last revision:
> 
>   simplify check

I'm not sure about this. @nizarbenalla have you tested whether this changes the output for JDK docs?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25123#issuecomment-2866404957

From hannesw at openjdk.org  Fri May  9 12:51:52 2025
From: hannesw at openjdk.org (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=)
Date: Fri, 9 May 2025 12:51:52 GMT
Subject: RFR: 8177100: APIs duplicated in JavaDoc [v2]
In-Reply-To: <q8VIalvUGO_j9CNKh2AjZLNcu3gEzZCQbQu7eohE7jE=.ac756b58-8077-4594-b7ea-1854effb915c@github.com>
References: <0NrLP37RZ6I7ytBxcNyNFReQVvgu-6p_-HbSbHW9ZRM=.c7fd5ae4-8c8d-48ea-8349-5c92a2f78c71@github.com>
 <q8VIalvUGO_j9CNKh2AjZLNcu3gEzZCQbQu7eohE7jE=.ac756b58-8077-4594-b7ea-1854effb915c@github.com>
Message-ID: <qCl6vsdj05p2Bg5WfrrIpDbMjE6JHC9jeoIHRu5WrZ8=.75391818-9a1f-4a08-bbf0-8cf46d663643@github.com>

On Fri, 9 May 2025 11:39:44 GMT, Nizar Benalla <nbenalla at openjdk.org> wrote:

>> Please review this patch to fix a bug where a method can be documented multiple times 
>> Consider these 4 classes
>> 
>>                     A       (interface)
>>                    / \
>>                   /   \
>> (abstract class)  C     B   ( interface)
>>                   \   /
>>                    \ /
>>                     D       (class)
>> 
>> 
>> Where `A` declares `testA()`, `C` implements it `public final void testA()`, `B` extends `A` but does *not* override it, `D` extends `C` and implements `B`
>> 
>> In the generated javadoc, `testA()` is documented twice.
>> 
>> ![Screenshot 2025-05-08 at 15 51 19](https://github.com/user-attachments/assets/46538e61-1546-4128-8041-296d8491406f)
>> 
>> After the patch, `testA()` is only documented once:
>> 
>> ![Screenshot 2025-05-08 at 15 52 16](https://github.com/user-attachments/assets/a6b86a21-7104-460c-8f3f-36cee5962eed)
>
> Nizar Benalla has updated the pull request incrementally with one additional commit since the last revision:
> 
>   simplify check

There's a problem with character encoding in this patch, please do not integrate: 


 /Users/runner/work/jdk/jdk/src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/util/VisibleMemberTable.java:681: error: unmappable character (0x80) for encoding ascii
        // Multiple-Inheritance: No Contention. In Java???s method resolution,

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25123#issuecomment-2866421010

From lkorinth at openjdk.org  Fri May  9 12:51:52 2025
From: lkorinth at openjdk.org (Leo Korinth)
Date: Fri, 9 May 2025 12:51:52 GMT
Subject: RFR: 8356171: Increase timeout for testcases as preparation for
 change of default timeout factor
In-Reply-To: <WCuOwzU4kPjno7_Ptc1SQN6KY6MEejJlVEQKhZhqgjo=.259ff478-ab46-4d31-aa4a-c4fffb8d54a7@github.com>
References: <WCuOwzU4kPjno7_Ptc1SQN6KY6MEejJlVEQKhZhqgjo=.259ff478-ab46-4d31-aa4a-c4fffb8d54a7@github.com>
Message-ID: <d4WeSYdxBsFQG_bsWZgsyGDKPbRL5ks8pTVVkck5foc=.5f39ab1e-bbab-483c-8b19-568c6e5a80e4@github.com>

On Thu, 8 May 2025 14:51:24 GMT, Leo Korinth <lkorinth at openjdk.org> 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 change (it will finally be changed to 1.0 in JDK-8260555). The next commit excludes some junit/testng tests where I can currently not change the timeout factor (CODETOOLS-7903961). Both these commits will be reverted before integrating the change. I will also apply copyright updates after the review.
> 
> In addition to changing the timeout factor, I am also using a library call to parse the timeout factor from the java properties (I can not use the library function everywhere as jtreg does not allow me to add @library notations to non testcase files).
> 
> My approach has been to run all test, and afterwards updating those that fails due to a timeout factor. The amount of updated testcases is huge, and my strategy has been to quadruple the timeout if I could not directly see that less was needed (thus the timeout will be the same after JDK-8260555 is implemented). In a few places I have added a bit more timeout so that it will work with the 0.7 timeout factor.
> 
> These fixes have been created when I have plown through testcases:
> JDK-8352719: Add an equals sign to the modules statement
> JDK-8352709: Remove bad timing annotations from WhileOpTest.java
> JDK-8352074: Test MemoryLeak.java seems not to test what it is supposed to test
> CODETOOLS-7903937: JTREG uses timeout factor on socket timeout but not on KEEPALIVE
> CODETOOLS-7903961: Make default timeout configurable
> 
> Sometime in the future I will also fix:
> 8260555: Change the default TIMEOUT_FACTOR from 4 to 1
> 
> for which I am awaiting:
> CODETOOLS-7903961 that is fixed in jtreg 7.6, but we are still running 7.5.1+1
> 
> *After the review I will revert the two first commits, and update the copyrights*

Every time I rerun the tests, some new testcase fails on timeouts. Even worse is that I get quite a few /totally unrelated/ test failures every time because I am running 8 tiers.  I could probably change the timeout factor to 0.6 to weed out some more tests faster, but I can not use a timeout factor of 0.5 or less because of CODETOOLS-7903937.

Every 0.1 percent corresponds to 12 seconds. So in absolute measurements I have a margin of 36 seconds now if I would go to a timeout factor of 1. I am also a bit afraid of having too big of a margin --- it will force me to convert possible huge amount of new test cases.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25122#issuecomment-2866421573

From lkorinth at openjdk.org  Fri May  9 13:06:01 2025
From: lkorinth at openjdk.org (Leo Korinth)
Date: Fri, 9 May 2025 13:06:01 GMT
Subject: RFR: 8356171: Increase timeout for testcases as preparation for
 change of default timeout factor
In-Reply-To: <WCuOwzU4kPjno7_Ptc1SQN6KY6MEejJlVEQKhZhqgjo=.259ff478-ab46-4d31-aa4a-c4fffb8d54a7@github.com>
References: <WCuOwzU4kPjno7_Ptc1SQN6KY6MEejJlVEQKhZhqgjo=.259ff478-ab46-4d31-aa4a-c4fffb8d54a7@github.com>
Message-ID: <zfwQsPX7kHwfbD2VUx3dhQwyy1VjAsb-yITfpShYhLM=.2c91dacc-78e2-4393-a7c5-b196fb5be962@github.com>

On Thu, 8 May 2025 14:51:24 GMT, Leo Korinth <lkorinth at openjdk.org> 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 change (it will finally be changed to 1.0 in JDK-8260555). The next commit excludes some junit/testng tests where I can currently not change the timeout factor (CODETOOLS-7903961). Both these commits will be reverted before integrating the change. I will also apply copyright updates after the review.
> 
> In addition to changing the timeout factor, I am also using a library call to parse the timeout factor from the java properties (I can not use the library function everywhere as jtreg does not allow me to add @library notations to non testcase files).
> 
> My approach has been to run all test, and afterwards updating those that fails due to a timeout factor. The amount of updated testcases is huge, and my strategy has been to quadruple the timeout if I could not directly see that less was needed (thus the timeout will be the same after JDK-8260555 is implemented). In a few places I have added a bit more timeout so that it will work with the 0.7 timeout factor.
> 
> These fixes have been created when I have plown through testcases:
> JDK-8352719: Add an equals sign to the modules statement
> JDK-8352709: Remove bad timing annotations from WhileOpTest.java
> JDK-8352074: Test MemoryLeak.java seems not to test what it is supposed to test
> CODETOOLS-7903937: JTREG uses timeout factor on socket timeout but not on KEEPALIVE
> CODETOOLS-7903961: Make default timeout configurable
> 
> Sometime in the future I will also fix:
> 8260555: Change the default TIMEOUT_FACTOR from 4 to 1
> 
> for which I am awaiting:
> CODETOOLS-7903961 that is fixed in jtreg 7.6, but we are still running 7.5.1+1
> 
> *After the review I will revert the two first commits, and update the copyrights*

Changing the timeout factor might be preferable to do after the fork.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25122#issuecomment-2866463008

From hannesw at openjdk.org  Fri May  9 13:22:52 2025
From: hannesw at openjdk.org (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=)
Date: Fri, 9 May 2025 13:22:52 GMT
Subject: RFR: 8177100: APIs duplicated in JavaDoc [v2]
In-Reply-To: <q8VIalvUGO_j9CNKh2AjZLNcu3gEzZCQbQu7eohE7jE=.ac756b58-8077-4594-b7ea-1854effb915c@github.com>
References: <0NrLP37RZ6I7ytBxcNyNFReQVvgu-6p_-HbSbHW9ZRM=.c7fd5ae4-8c8d-48ea-8349-5c92a2f78c71@github.com>
 <q8VIalvUGO_j9CNKh2AjZLNcu3gEzZCQbQu7eohE7jE=.ac756b58-8077-4594-b7ea-1854effb915c@github.com>
Message-ID: <FHnfkMusN8W3ndKMRyVpdOQ-S-a0BGKm4UYi_afD_I8=.0f078810-7888-48de-bbd7-d0b9eda26874@github.com>

On Fri, 9 May 2025 11:39:44 GMT, Nizar Benalla <nbenalla at openjdk.org> wrote:

>> Please review this patch to fix a bug where a method can be documented multiple times 
>> Consider these 4 classes
>> 
>>                     A       (interface)
>>                    / \
>>                   /   \
>> (abstract class)  C     B   ( interface)
>>                   \   /
>>                    \ /
>>                     D       (class)
>> 
>> 
>> Where `A` declares `testA()`, `C` implements it `public final void testA()`, `B` extends `A` but does *not* override it, `D` extends `C` and implements `B`
>> 
>> In the generated javadoc, `testA()` is documented twice.
>> 
>> ![Screenshot 2025-05-08 at 15 51 19](https://github.com/user-attachments/assets/46538e61-1546-4128-8041-296d8491406f)
>> 
>> After the patch, `testA()` is only documented once:
>> 
>> ![Screenshot 2025-05-08 at 15 52 16](https://github.com/user-attachments/assets/a6b86a21-7104-460c-8f3f-36cee5962eed)
>
> Nizar Benalla has updated the pull request incrementally with one additional commit since the last revision:
> 
>   simplify check

As I suspected, this removes methods from the "Methods declared in interface XY" sections. For example, in the `java.lang.StringBuilder` doc page section for methods declared in `java.lang.CharSequence` it removes all methods except `isEmpty()`.  So this is not the right place to fix this. I think we should only eliminate these overridden methods if they are to be documented in the subclass (when the declaring class is undocumented).

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25123#issuecomment-2866519308

From nbenalla at openjdk.org  Fri May  9 13:28:35 2025
From: nbenalla at openjdk.org (Nizar Benalla)
Date: Fri, 9 May 2025 13:28:35 GMT
Subject: RFR: 8177100: APIs duplicated in JavaDoc [v3]
In-Reply-To: <0NrLP37RZ6I7ytBxcNyNFReQVvgu-6p_-HbSbHW9ZRM=.c7fd5ae4-8c8d-48ea-8349-5c92a2f78c71@github.com>
References: <0NrLP37RZ6I7ytBxcNyNFReQVvgu-6p_-HbSbHW9ZRM=.c7fd5ae4-8c8d-48ea-8349-5c92a2f78c71@github.com>
Message-ID: <NHHeb_zZjehcDy6EWPFsjkSz8J1sYmzyx7gwe105yCI=.933d35c4-fdc6-43da-b48d-395c7b9d1417@github.com>

> Please review this patch to fix a bug where a method can be documented multiple times 
> Consider these 4 classes
> 
>                     A       (interface)
>                    / \
>                   /   \
> (abstract class)  C     B   ( interface)
>                   \   /
>                    \ /
>                     D       (class)
> 
> 
> Where `A` declares `testA()`, `C` implements it `public final void testA()`, `B` extends `A` but does *not* override it, `D` extends `C` and implements `B`
> 
> In the generated javadoc, `testA()` is documented twice.
> 
> ![Screenshot 2025-05-08 at 15 51 19](https://github.com/user-attachments/assets/46538e61-1546-4128-8041-296d8491406f)
> 
> After the patch, `testA()` is only documented once:
> 
> ![Screenshot 2025-05-08 at 15 52 16](https://github.com/user-attachments/assets/a6b86a21-7104-460c-8f3f-36cee5962eed)

Nizar Benalla has updated the pull request incrementally with one additional commit since the last revision:

  fix comment

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/25123/files
  - new: https://git.openjdk.org/jdk/pull/25123/files/41578ad2..8d300463

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25123&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25123&range=01-02

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/25123.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25123/head:pull/25123

PR: https://git.openjdk.org/jdk/pull/25123

From hannesw at openjdk.org  Fri May  9 15:24:39 2025
From: hannesw at openjdk.org (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=)
Date: Fri, 9 May 2025 15:24:39 GMT
Subject: RFR: 8350920: Allow inherited member summaries to be viewed inline
 [v6]
In-Reply-To: <dX1QjYZMvLqrR9bS1YLuvpWlXWTcCo56grLUDgh59Pg=.f908cdb2-911a-4ca3-b86e-a07d86a92a6e@github.com>
References: <dX1QjYZMvLqrR9bS1YLuvpWlXWTcCo56grLUDgh59Pg=.f908cdb2-911a-4ca3-b86e-a07d86a92a6e@github.com>
Message-ID: <QYJ1xKshpFxGNx4IHFqQjOdIjiVIGbkx86aQ8yBb0sM=.9398f5da-f87c-4bf1-9201-55363f9eecdf@github.com>

> Please review an enhancement to allow switching between the traditional condensed footnote-style summary and the summary table format for inherited members (types, fields, methods and properties) that are inherited from included types. You can test the feature in [the doc bundle I uploaded][apidocs] or watch the short screencast below.
> 
> [apidocs]: https://cr.openjdk.org/~hannesw/8350920/api.00/java.base/module-summary.html
> 
> https://github.com/user-attachments/assets/0aaa1f8b-c18b-4922-b704-2b2cdc05ca79
> 
> I added two new protected methods to the `AbstractMemberWriter` class, `createInheritedSummaryTable` and `getInheritedSummaryId`. Otherwise this is mostly reusing existing functionality (we already had the feature to display the signature of an inherited method in the context of the current class).
> 
> The writers for non-inheritable members such as constructors or enum constants were simplified a bit by implementing formerly abstract methods in `AbstractMemberWriter` as concrete methods throwing `UnsupportedOperationException` so they don't have to be implemented as empty methods in these writers.
> 
> The UI to switch between member list presentations is implemented in `script.js.template`. If no summary list presentation is available (because the supertype is not part of the documentation bundle) nothing changes in the UI.
> 
> I added a `stripTags()` method to `Content` to return the plain text content with HTML tags stripped that could be used in a few other places. The patch also adds two new vector graphics files called right.svg and down.svg for the right and downwards pointing angle.

Hannes Walln?fer has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains eight commits:

 - Fix test
 - Merge branch 'master' into JDK-8350920
 - Merge branch 'master' into JDK-8350920
 - Review feedback: replace local implementations of Content.stripTags()
 - Merge branch 'master' into JDK-8350920
 - Merge branch 'master' into JDK-8350920
 - Add svg files
 - 8350920: Allow inherited member summaries to be viewed inline

-------------

Changes: https://git.openjdk.org/jdk/pull/23967/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23967&range=05
  Stats: 566 lines in 30 files changed: 410 ins; 92 del; 64 mod
  Patch: https://git.openjdk.org/jdk/pull/23967.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23967/head:pull/23967

PR: https://git.openjdk.org/jdk/pull/23967

From prr at openjdk.org  Fri May  9 19:24:53 2025
From: prr at openjdk.org (Phil Race)
Date: Fri, 9 May 2025 19:24:53 GMT
Subject: RFR: 8356171: Increase timeout for testcases as preparation for
 change of default timeout factor
In-Reply-To: <0AKC-4omm-W24u11ifhGm8Do8_5sqwPMJz6q3A71FNE=.f4209d38-51d6-4eda-b11e-d670e5ee5575@github.com>
References: <WCuOwzU4kPjno7_Ptc1SQN6KY6MEejJlVEQKhZhqgjo=.259ff478-ab46-4d31-aa4a-c4fffb8d54a7@github.com>
 <qUtOWdQzhA2aCO21XPrr2pdtKwJ-n_qDvTY2UprQmJQ=.3f11dd7d-5d0c-47a8-9b1c-2cdfbf3f542b@github.com>
 <0AKC-4omm-W24u11ifhGm8Do8_5sqwPMJz6q3A71FNE=.f4209d38-51d6-4eda-b11e-d670e5ee5575@github.com>
Message-ID: <tWgLVluDO0fcZ3e9N1V1GU6rmEcz-tyTVkNuJdr06Pw=.749ad3d3-b55a-486b-8d74-40091899e657@github.com>

On Fri, 9 May 2025 08:58:15 GMT, Leo Korinth <lkorinth at openjdk.org> wrote:

> > test/jdk/java/awt/font/NumericShaper/MTTest.java
> > ```
> > * * @run main/timeout=300/othervm MTTest
> > 
> > 
> > * * @run main/timeout=1200/othervm MTTest
> > ```
> > 
> > 
> >     
> >       
> >     
> > 
> >       
> >     
> > 
> >     
> >   
> > I'm puzzling over why you saw this test fail with timeout = 300 .. or perhaps you saw it fail with 0.7 ? Which would amount to 210 seconds .. that might just be enough to cause it to fail because if you look at the whole test you'll see it wants the core loops of the test to run for 180 seconds.
> > https://openjdk.github.io/cr/?repo=jdk&pr=25122&range=00#new-144-test/jdk/java/awt/font/NumericShaper/MTTest.java
> > So 300 was fine, and 1200 isn't needed.
> 
> I started with a timeout factor less than `0.7` but I got hindered by CODETOOLS-7903937. That is probably the reason. Maybe I should change the timeout to 400? I think it is reasonable to handle a timeout factor somewhat less than 1 to weed out tight test cases. But maybe 300 is good enough?

I think 300 is correct for this test. Setting the timeout factor to < 1 is an interesting experiment but I don't think tests that timeout in such a case are automatic candidates to have an increased time out and this one shows why.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25122#issuecomment-2867676176

From nbenalla at openjdk.org  Mon May 12 12:57:10 2025
From: nbenalla at openjdk.org (Nizar Benalla)
Date: Mon, 12 May 2025 12:57:10 GMT
Subject: RFR: 8177100: APIs duplicated in JavaDoc [v4]
In-Reply-To: <0NrLP37RZ6I7ytBxcNyNFReQVvgu-6p_-HbSbHW9ZRM=.c7fd5ae4-8c8d-48ea-8349-5c92a2f78c71@github.com>
References: <0NrLP37RZ6I7ytBxcNyNFReQVvgu-6p_-HbSbHW9ZRM=.c7fd5ae4-8c8d-48ea-8349-5c92a2f78c71@github.com>
Message-ID: <z1G6AmSl5Zu4jTv8FqkbMaLCMTpzmhq_KSQjaNZKRdE=.794bdee5-e029-41ee-9bdf-76749ecdd4e4@github.com>

> Please review this patch to fix a bug where a method can be documented multiple times 
> Consider these 4 classes
> 
>                     A       (interface)
>                    / \
>                   /   \
> (abstract class)  C     B   ( interface)
>                   \   /
>                    \ /
>                     D       (class)
> 
> 
> Where `A` declares `testA()`, `C` implements it `public final void testA()`, `B` extends `A` but does *not* override it, `D` extends `C` and implements `B`
> 
> In the generated javadoc, `testA()` is documented twice.
> 
> ![Screenshot 2025-05-08 at 15 51 19](https://github.com/user-attachments/assets/46538e61-1546-4128-8041-296d8491406f)
> 
> After the patch, `testA()` is only documented once:
> 
> ![Screenshot 2025-05-08 at 15 52 16](https://github.com/user-attachments/assets/a6b86a21-7104-460c-8f3f-36cee5962eed)

Nizar Benalla 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 seven additional commits since the last revision:

 - update javadoc
 - Merge branch 'master' into duplicate-APIs
 - new approach - make sure there is no negative effect on JDK doc output
 - revert VisibleMemberTable back to master
 - fix comment
 - simplify check
 - merge methods from invisible supetypes

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/25123/files
  - new: https://git.openjdk.org/jdk/pull/25123/files/8d300463..c7b62698

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25123&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25123&range=02-03

  Stats: 7613 lines in 417 files changed: 4786 ins; 1488 del; 1339 mod
  Patch: https://git.openjdk.org/jdk/pull/25123.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25123/head:pull/25123

PR: https://git.openjdk.org/jdk/pull/25123

From nbenalla at openjdk.org  Mon May 12 12:59:55 2025
From: nbenalla at openjdk.org (Nizar Benalla)
Date: Mon, 12 May 2025 12:59:55 GMT
Subject: RFR: 8177100: APIs duplicated in JavaDoc [v4]
In-Reply-To: <z1G6AmSl5Zu4jTv8FqkbMaLCMTpzmhq_KSQjaNZKRdE=.794bdee5-e029-41ee-9bdf-76749ecdd4e4@github.com>
References: <0NrLP37RZ6I7ytBxcNyNFReQVvgu-6p_-HbSbHW9ZRM=.c7fd5ae4-8c8d-48ea-8349-5c92a2f78c71@github.com>
 <z1G6AmSl5Zu4jTv8FqkbMaLCMTpzmhq_KSQjaNZKRdE=.794bdee5-e029-41ee-9bdf-76749ecdd4e4@github.com>
Message-ID: <Nx7gEEkmayzvAEj_I89RuPBY0ctwGgIZ1yXjIbpKGuo=.cd0097e2-6959-4789-8bcb-23150318a9f4@github.com>

On Mon, 12 May 2025 12:57:10 GMT, Nizar Benalla <nbenalla at openjdk.org> wrote:

>> Please review this patch to fix a bug where a method can be documented multiple times 
>> Consider these 4 classes
>> 
>>                     A       (interface)
>>                    / \
>>                   /   \
>> (abstract class)  C     B   ( interface)
>>                   \   /
>>                    \ /
>>                     D       (class)
>> 
>> 
>> Where `A` declares `testA()`, `C` implements it `public final void testA()`, `B` extends `A` but does *not* override it, `D` extends `C` and implements `B`
>> 
>> In the generated javadoc, `testA()` is documented twice.
>> 
>> ![Screenshot 2025-05-08 at 15 51 19](https://github.com/user-attachments/assets/46538e61-1546-4128-8041-296d8491406f)
>> 
>> After the patch, `testA()` is only documented once:
>> 
>> ![Screenshot 2025-05-08 at 15 52 16](https://github.com/user-attachments/assets/a6b86a21-7104-460c-8f3f-36cee5962eed)
>
> Nizar Benalla 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 seven additional commits since the last revision:
> 
>  - update javadoc
>  - Merge branch 'master' into duplicate-APIs
>  - new approach - make sure there is no negative effect on JDK doc output
>  - revert VisibleMemberTable back to master
>  - fix comment
>  - simplify check
>  - merge methods from invisible supetypes

Hannes suggested in offline discussion where the check can be instead of the old approach.
I have checked that there is no change in the current JDK doc build after applying this patch.

Thanks for catching this oversight during the review.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25123#issuecomment-2872460059

From nbenalla at openjdk.org  Mon May 12 13:35:57 2025
From: nbenalla at openjdk.org (Nizar Benalla)
Date: Mon, 12 May 2025 13:35:57 GMT
Subject: RFR: 8177100: APIs duplicated in JavaDoc [v4]
In-Reply-To: <z1G6AmSl5Zu4jTv8FqkbMaLCMTpzmhq_KSQjaNZKRdE=.794bdee5-e029-41ee-9bdf-76749ecdd4e4@github.com>
References: <0NrLP37RZ6I7ytBxcNyNFReQVvgu-6p_-HbSbHW9ZRM=.c7fd5ae4-8c8d-48ea-8349-5c92a2f78c71@github.com>
 <z1G6AmSl5Zu4jTv8FqkbMaLCMTpzmhq_KSQjaNZKRdE=.794bdee5-e029-41ee-9bdf-76749ecdd4e4@github.com>
Message-ID: <zCcGv-j-4xlns8VHkpQDx1XOcpth7y2Vt7gvPmscilA=.2a214574-d231-4bfd-a435-0e6159fb7151@github.com>

On Mon, 12 May 2025 12:57:10 GMT, Nizar Benalla <nbenalla at openjdk.org> wrote:

>> Please review this patch to fix a bug where a method can be documented multiple times 
>> Consider these 4 classes
>> 
>>                     A       (interface)
>>                    / \
>>                   /   \
>> (abstract class)  C     B   ( interface)
>>                   \   /
>>                    \ /
>>                     D       (class)
>> 
>> 
>> Where `A` declares `testA()`, `C` implements it `public final void testA()`, `B` extends `A` but does *not* override it, `D` extends `C` and implements `B`
>> 
>> In the generated javadoc, `testA()` is documented twice.
>> 
>> ![Screenshot 2025-05-08 at 15 51 19](https://github.com/user-attachments/assets/46538e61-1546-4128-8041-296d8491406f)
>> 
>> After the patch, `testA()` is only documented once:
>> 
>> ![Screenshot 2025-05-08 at 15 52 16](https://github.com/user-attachments/assets/a6b86a21-7104-460c-8f3f-36cee5962eed)
>
> Nizar Benalla 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 seven additional commits since the last revision:
> 
>  - update javadoc
>  - Merge branch 'master' into duplicate-APIs
>  - new approach - make sure there is no negative effect on JDK doc output
>  - revert VisibleMemberTable back to master
>  - fix comment
>  - simplify check
>  - merge methods from invisible supetypes

Please don't review this yet, I plan on pushing an other update.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25123#issuecomment-2872603471

From nbenalla at openjdk.org  Mon May 12 14:46:39 2025
From: nbenalla at openjdk.org (Nizar Benalla)
Date: Mon, 12 May 2025 14:46:39 GMT
Subject: RFR: 8177100: APIs duplicated in JavaDoc [v5]
In-Reply-To: <0NrLP37RZ6I7ytBxcNyNFReQVvgu-6p_-HbSbHW9ZRM=.c7fd5ae4-8c8d-48ea-8349-5c92a2f78c71@github.com>
References: <0NrLP37RZ6I7ytBxcNyNFReQVvgu-6p_-HbSbHW9ZRM=.c7fd5ae4-8c8d-48ea-8349-5c92a2f78c71@github.com>
Message-ID: <ElIABs31HAnHeRHN6ig3xhxskyQrnLL3oTyUGKKoAvA=.c6840203-0723-4908-9c40-26fc24272c09@github.com>

> Please review this patch to fix a bug where a method can be documented multiple times 
> Consider these 4 classes
> 
>                     A       (interface)
>                    / \
>                   /   \
> (abstract class)  C     B   ( interface)
>                   \   /
>                    \ /
>                     D       (class)
> 
> 
> Where `A` declares `testA()`, `C` implements it `public final void testA()`, `B` extends `A` but does *not* override it, `D` extends `C` and implements `B`
> 
> In the generated javadoc, `testA()` is documented twice.
> 
> ![Screenshot 2025-05-08 at 15 51 19](https://github.com/user-attachments/assets/46538e61-1546-4128-8041-296d8491406f)
> 
> After the patch, `testA()` is only documented once:
> 
> ![Screenshot 2025-05-08 at 15 52 16](https://github.com/user-attachments/assets/a6b86a21-7104-460c-8f3f-36cee5962eed)

Nizar Benalla has updated the pull request incrementally with one additional commit since the last revision:

  rename test to be more accurate and simplify code

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/25123/files
  - new: https://git.openjdk.org/jdk/pull/25123/files/c7b62698..4c645c7b

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25123&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25123&range=03-04

  Stats: 24 lines in 2 files changed: 1 ins; 10 del; 13 mod
  Patch: https://git.openjdk.org/jdk/pull/25123.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25123/head:pull/25123

PR: https://git.openjdk.org/jdk/pull/25123

From nbenalla at openjdk.org  Mon May 12 15:42:52 2025
From: nbenalla at openjdk.org (Nizar Benalla)
Date: Mon, 12 May 2025 15:42:52 GMT
Subject: RFR: 8177100: APIs duplicated in JavaDoc [v5]
In-Reply-To: <ElIABs31HAnHeRHN6ig3xhxskyQrnLL3oTyUGKKoAvA=.c6840203-0723-4908-9c40-26fc24272c09@github.com>
References: <0NrLP37RZ6I7ytBxcNyNFReQVvgu-6p_-HbSbHW9ZRM=.c7fd5ae4-8c8d-48ea-8349-5c92a2f78c71@github.com>
 <ElIABs31HAnHeRHN6ig3xhxskyQrnLL3oTyUGKKoAvA=.c6840203-0723-4908-9c40-26fc24272c09@github.com>
Message-ID: <PWfndqEbxEt-Fbs7IDZpiHr_NJwAVzWO3e-C5nTitD8=.856d09a1-9d7b-4440-94af-4c900ff5d2ba@github.com>

On Mon, 12 May 2025 14:46:39 GMT, Nizar Benalla <nbenalla at openjdk.org> wrote:

>> Please review this patch to fix a bug where a method can be documented multiple times 
>> Consider these 4 classes
>> 
>>                     A       (interface)
>>                    / \
>>                   /   \
>> (abstract class)  C     B   ( interface)
>>                   \   /
>>                    \ /
>>                     D       (class)
>> 
>> 
>> Where `A` declares `testA()`, `C` implements it `public final void testA()`, `B` extends `A` but does *not* override it, `D` extends `C` and implements `B`
>> 
>> In the generated javadoc, `testA()` is documented twice.
>> 
>> ![Screenshot 2025-05-08 at 15 51 19](https://github.com/user-attachments/assets/46538e61-1546-4128-8041-296d8491406f)
>> 
>> After the patch, `testA()` is only documented once:
>> 
>> ![Screenshot 2025-05-08 at 15 52 16](https://github.com/user-attachments/assets/a6b86a21-7104-460c-8f3f-36cee5962eed)
>
> Nizar Benalla has updated the pull request incrementally with one additional commit since the last revision:
> 
>   rename test to be more accurate and simplify code

I've updated the test as the name was not accurate, and simplified the code in `VisibleMemberTable`

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25123#issuecomment-2873069050

From nbenalla at openjdk.org  Tue May 13 11:03:46 2025
From: nbenalla at openjdk.org (Nizar Benalla)
Date: Tue, 13 May 2025 11:03:46 GMT
Subject: RFR: 8139744: Types referred in @link/@linkplain tags are not always
 hyperlinks
Message-ID: <8jpSUqhl0kuV3xBG5zrZSRq07fTXoHEtfjiYbg2rxQg=.76d4d253-9890-4f8e-853c-bf7fef95d577@github.com>

Please review this patch to emit a new warning if the reference element cannot be linked. This is intended to prevent links to private member in the JDK docs (see https://bugs.openjdk.org/browse/JDK-8310868).

Here is a [clear example](https://download.java.net/java/early_access/jdk25/docs/api/java.base/java/net/Socket.html#shutdownOutput()) of this bug:

<img width="1071" alt="Screenshot 2025-05-12 at 16 55 26" src="https://github.com/user-attachments/assets/9bbca975-7f41-4970-9735-95906b402534" />

We should link to `sInputShutdown()` instead.


Some private fields are [documented](https://download.java.net/java/early_access/jdk25/docs/api/serialized-form.html#java.awt.Frame) on the Serialization page if the class is serializable. After this patch, warnings will be emitted if a there is an incorrect link in their javadoc. 

Similar to the image below where the there is no hypertext and the link is rendered as plain text, because the linked method is private.
<img width="422" alt="Screenshot 2025-05-12 at 16 53 56" src="https://github.com/user-attachments/assets/847a2acc-f289-4048-b239-77baa87a01ea" />

This bug can also creep in later without the author noticing, if they add a new method and javadoc matches it instead.


Note: This PR can only be integrated after all site bugs are fixed in [JDK-8356549.](https://bugs.openjdk.org/browse/JDK-8356549)

-------------

Commit messages:
 - emit warning for incorrect {@link/@linkplain} tags

Changes: https://git.openjdk.org/jdk/pull/25187/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25187&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8139744
  Stats: 112 lines in 3 files changed: 111 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/25187.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25187/head:pull/25187

PR: https://git.openjdk.org/jdk/pull/25187

From hannesw at openjdk.org  Tue May 13 13:21:05 2025
From: hannesw at openjdk.org (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=)
Date: Tue, 13 May 2025 13:21:05 GMT
Subject: RFR: 8328848: Inaccuracy in the documentation of the -group option
Message-ID: <DfqH6RrQXPHHUf1uBCVbOTVEARdVEjk2maT-64sVK10=.a7af9f0e-f623-4c60-a846-12fc20f664b4@github.com>

Please review a documentation fix in the `javadoc` man page to document that the `-group` option can be used with packages or modules depending on documented code. 

Although the help output of the `javadoc` tool already included this fact I replaced the abstract term "elements" with "packages or modules" to make it a bit more concrete.

-------------

Commit messages:
 - JDK-8328848: Inaccuracy in the documentation of the -group option

Changes: https://git.openjdk.org/jdk/pull/25212/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25212&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8328848
  Stats: 4 lines in 2 files changed: 1 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/25212.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25212/head:pull/25212

PR: https://git.openjdk.org/jdk/pull/25212

From nbenalla at openjdk.org  Tue May 13 15:03:39 2025
From: nbenalla at openjdk.org (Nizar Benalla)
Date: Tue, 13 May 2025 15:03:39 GMT
Subject: RFR: 8343054: Add support for a new `@info` javadoc block tag for API
 guidance
Message-ID: <yKct1t4-TsBaqCmE9Fg38tdIEtVeJP8V5NIbPL-7yk0=.3fd8a9ea-a3f3-4c75-97c2-0eefe53d2603@github.com>

This PR adds a new `@info` block tag to javadoc, it can be used to document general guidance for APIs.

Tests will be added to this patch later, CSR is still under review.

TIA

-------------

Commit messages:
 - implement `@info` javadoc block tag

Changes: https://git.openjdk.org/jdk/pull/25215/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25215&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8343054
  Stats: 285 lines in 21 files changed: 267 ins; 1 del; 17 mod
  Patch: https://git.openjdk.org/jdk/pull/25215.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25215/head:pull/25215

PR: https://git.openjdk.org/jdk/pull/25215

From nbenalla at openjdk.org  Tue May 13 15:44:56 2025
From: nbenalla at openjdk.org (Nizar Benalla)
Date: Tue, 13 May 2025 15:44:56 GMT
Subject: RFR: 8341736: Add support for a new `@info` javadoc block tag for
 API guidance
In-Reply-To: <yKct1t4-TsBaqCmE9Fg38tdIEtVeJP8V5NIbPL-7yk0=.3fd8a9ea-a3f3-4c75-97c2-0eefe53d2603@github.com>
References: <yKct1t4-TsBaqCmE9Fg38tdIEtVeJP8V5NIbPL-7yk0=.3fd8a9ea-a3f3-4c75-97c2-0eefe53d2603@github.com>
Message-ID: <6isbbhUbONVsAbKC-LZEh9O5ZB9kv6R1F2xeHtuwHrs=.98aaf3c1-2c31-4d37-9ce0-2f9ea606edcf@github.com>

On Tue, 13 May 2025 14:58:27 GMT, Nizar Benalla <nbenalla at openjdk.org> wrote:

> This PR adds a new `@info` block tag to javadoc, it can be used to document general guidance for APIs.
> 
> Tests will be added to this patch later, CSR is still under review.
> 
> TIA

Closing this for now.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25215#issuecomment-2877016683

From nbenalla at openjdk.org  Tue May 13 15:44:57 2025
From: nbenalla at openjdk.org (Nizar Benalla)
Date: Tue, 13 May 2025 15:44:57 GMT
Subject: Withdrawn: 8341736: Add support for a new `@info` javadoc block tag
 for API guidance
In-Reply-To: <yKct1t4-TsBaqCmE9Fg38tdIEtVeJP8V5NIbPL-7yk0=.3fd8a9ea-a3f3-4c75-97c2-0eefe53d2603@github.com>
References: <yKct1t4-TsBaqCmE9Fg38tdIEtVeJP8V5NIbPL-7yk0=.3fd8a9ea-a3f3-4c75-97c2-0eefe53d2603@github.com>
Message-ID: <RjSMoEKisxpNMXUEI3xnIW8SsF8eDqFwGPe-IUIzMjM=.3cd333f0-7b68-48ab-b79f-3de4f0d6e799@github.com>

On Tue, 13 May 2025 14:58:27 GMT, Nizar Benalla <nbenalla at openjdk.org> wrote:

> This PR adds a new `@info` block tag to javadoc, it can be used to document general guidance for APIs.
> 
> Tests will be added to this patch later, CSR is still under review.
> 
> TIA

This pull request has been closed without being integrated.

-------------

PR: https://git.openjdk.org/jdk/pull/25215

From hannesw at openjdk.org  Wed May 14 12:06:32 2025
From: hannesw at openjdk.org (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=)
Date: Wed, 14 May 2025 12:06:32 GMT
Subject: RFR: 8355933: Change section title for permanent APIs affected by
 preview features
Message-ID: <SHdEESRjx-smAuXitX4uNMVDhY0gmdMrMjtuk7hWK8Y=.e06e8985-65ed-41cb-9b49-3416953ab9d8@github.com>

Please review a change of how preview-related notes on permanent APIs are presented in the Preview API page. The section title changes to "Permanent APIs affected by Preview Features", and the section is rendered below the preview API summary tables rather than above.

In order to show the permanent API notes below the other tables I had to change the way extra content is added to API summary pages. The extra content hook methods we had before always displayed extra content before ordinary API summaries (such as terminally deprecated APIs on the Deprecated API page). The new code replaces these hook methods with methods that generate parts of the page and can be overridden in subclasses to add content before or after the default content.

I did not structure summary tables into separate preview and permanent API hierarchies as suggested, as that would have made the UI much more complex both visually and functionally.

-------------

Commit messages:
 - 8355933: Change section title for permanent APIs affected by preview features

Changes: https://git.openjdk.org/jdk/pull/25224/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25224&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8355933
  Stats: 83 lines in 8 files changed: 24 ins; 19 del; 40 mod
  Patch: https://git.openjdk.org/jdk/pull/25224.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25224/head:pull/25224

PR: https://git.openjdk.org/jdk/pull/25224

From ihse at openjdk.org  Wed May 14 14:28:10 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Wed, 14 May 2025 14:28:10 GMT
Subject: RFR: 8356977: UTF-8 cleanups
Message-ID: <s4znWc8WCK3liY8YOhRldnBN7yPJr8m-doBeEArSHd0=.0632ae03-da95-4bd5-865f-e8276544bed5@github.com>

I found a few other places in the code that can be cleaned up after the conversion to UTF-8.

-------------

Commit messages:
 - Replace uncessary unicode characters with ASCII in instructions, and fix typo
 - Seems like typos in the comments
 - Fix unicode sequences in comments (previously missed)

Changes: https://git.openjdk.org/jdk/pull/25228/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25228&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8356977
  Stats: 21 lines in 16 files changed: 0 ins; 0 del; 21 mod
  Patch: https://git.openjdk.org/jdk/pull/25228.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25228/head:pull/25228

PR: https://git.openjdk.org/jdk/pull/25228

From lkorinth at openjdk.org  Thu May 15 09:20:03 2025
From: lkorinth at openjdk.org (Leo Korinth)
Date: Thu, 15 May 2025 09:20:03 GMT
Subject: RFR: 8356171: Increase timeout for testcases as preparation for
 change of default timeout factor
In-Reply-To: <WCuOwzU4kPjno7_Ptc1SQN6KY6MEejJlVEQKhZhqgjo=.259ff478-ab46-4d31-aa4a-c4fffb8d54a7@github.com>
References: <WCuOwzU4kPjno7_Ptc1SQN6KY6MEejJlVEQKhZhqgjo=.259ff478-ab46-4d31-aa4a-c4fffb8d54a7@github.com>
Message-ID: <ExI4OcZ4H03w2Kmpe35WuEynczPvNAcXjCFY4cd6ldg=.1be29db4-e6a7-4376-93d9-94c05587c721@github.com>

On Thu, 8 May 2025 14:51:24 GMT, Leo Korinth <lkorinth at openjdk.org> 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 change (it will finally be changed to 1.0 in JDK-8260555). The next commit excludes some junit/testng tests where I can currently not change the timeout factor (CODETOOLS-7903961). Both these commits will be reverted before integrating the change. I will also apply copyright updates after the review.
> 
> In addition to changing the timeout factor, I am also using a library call to parse the timeout factor from the java properties (I can not use the library function everywhere as jtreg does not allow me to add @library notations to non testcase files).
> 
> My approach has been to run all test, and afterwards updating those that fails due to a timeout factor. The amount of updated testcases is huge, and my strategy has been to quadruple the timeout if I could not directly see that less was needed (thus the timeout will be the same after JDK-8260555 is implemented). In a few places I have added a bit more timeout so that it will work with the 0.7 timeout factor.
> 
> These fixes have been created when I have plown through testcases:
> JDK-8352719: Add an equals sign to the modules statement
> JDK-8352709: Remove bad timing annotations from WhileOpTest.java
> JDK-8352074: Test MemoryLeak.java seems not to test what it is supposed to test
> CODETOOLS-7903937: JTREG uses timeout factor on socket timeout but not on KEEPALIVE
> CODETOOLS-7903961: Make default timeout configurable
> 
> Sometime in the future I will also fix:
> 8260555: Change the default TIMEOUT_FACTOR from 4 to 1
> 
> for which I am awaiting:
> CODETOOLS-7903961 that is fixed in jtreg 7.6, but we are still running 7.5.1+1
> 
> *After the review I will revert the two first commits, and update the copyrights*

After an offline discussion, we agreed to wait a bit with this change.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25122#issuecomment-2883137218

From lkorinth at openjdk.org  Thu May 15 09:20:03 2025
From: lkorinth at openjdk.org (Leo Korinth)
Date: Thu, 15 May 2025 09:20:03 GMT
Subject: Withdrawn: 8356171: Increase timeout for testcases as preparation for
 change of default timeout factor
In-Reply-To: <WCuOwzU4kPjno7_Ptc1SQN6KY6MEejJlVEQKhZhqgjo=.259ff478-ab46-4d31-aa4a-c4fffb8d54a7@github.com>
References: <WCuOwzU4kPjno7_Ptc1SQN6KY6MEejJlVEQKhZhqgjo=.259ff478-ab46-4d31-aa4a-c4fffb8d54a7@github.com>
Message-ID: <LrGk5ztc6aRY4EQjv-mVBVaNIVBhvjY-SQD1ZkUD5d4=.dba136cb-acc9-4d18-9112-41f62464a65f@github.com>

On Thu, 8 May 2025 14:51:24 GMT, Leo Korinth <lkorinth at openjdk.org> 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 change (it will finally be changed to 1.0 in JDK-8260555). The next commit excludes some junit/testng tests where I can currently not change the timeout factor (CODETOOLS-7903961). Both these commits will be reverted before integrating the change. I will also apply copyright updates after the review.
> 
> In addition to changing the timeout factor, I am also using a library call to parse the timeout factor from the java properties (I can not use the library function everywhere as jtreg does not allow me to add @library notations to non testcase files).
> 
> My approach has been to run all test, and afterwards updating those that fails due to a timeout factor. The amount of updated testcases is huge, and my strategy has been to quadruple the timeout if I could not directly see that less was needed (thus the timeout will be the same after JDK-8260555 is implemented). In a few places I have added a bit more timeout so that it will work with the 0.7 timeout factor.
> 
> These fixes have been created when I have plown through testcases:
> JDK-8352719: Add an equals sign to the modules statement
> JDK-8352709: Remove bad timing annotations from WhileOpTest.java
> JDK-8352074: Test MemoryLeak.java seems not to test what it is supposed to test
> CODETOOLS-7903937: JTREG uses timeout factor on socket timeout but not on KEEPALIVE
> CODETOOLS-7903961: Make default timeout configurable
> 
> Sometime in the future I will also fix:
> 8260555: Change the default TIMEOUT_FACTOR from 4 to 1
> 
> for which I am awaiting:
> CODETOOLS-7903961 that is fixed in jtreg 7.6, but we are still running 7.5.1+1
> 
> *After the review I will revert the two first commits, and update the copyrights*

This pull request has been closed without being integrated.

-------------

PR: https://git.openjdk.org/jdk/pull/25122

From naoto at openjdk.org  Thu May 15 18:32:53 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 15 May 2025 18:32:53 GMT
Subject: RFR: 8356977: UTF-8 cleanups
In-Reply-To: <s4znWc8WCK3liY8YOhRldnBN7yPJr8m-doBeEArSHd0=.0632ae03-da95-4bd5-865f-e8276544bed5@github.com>
References: <s4znWc8WCK3liY8YOhRldnBN7yPJr8m-doBeEArSHd0=.0632ae03-da95-4bd5-865f-e8276544bed5@github.com>
Message-ID: <5oMrogxJyi1_OsPAGntbPTiR5aCIFOTuDSUTKOv7wyo=.b715c9d2-0cdd-4585-a262-bdbe5a72a5fa@github.com>

On Wed, 14 May 2025 14:23:31 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> I found a few other places in the code that can be cleaned up after the conversion to UTF-8.

test/jdk/sun/text/resources/LocaleDataTest.java line 106:

> 104:  *        FormatData/fr_FR/MonthNames/0=janvier
> 105:  *        FormatData/fr_FR/MonthNames/1=f?vrier
> 106:  *        LocaleNames/fr_FR/US=?tats-Unis

This test data (LocaleData.cldr) is explicitly encoded in ISO-8859-1 with unicode escapes for characters outside of it. So only changing these ones in comment does not seem correct.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25228#discussion_r2091757029

From chen.l.liang at oracle.com  Fri May 16 13:51:45 2025
From: chen.l.liang at oracle.com (Chen Liang)
Date: Fri, 16 May 2025 13:51:45 +0000
Subject: JDK-8356411
In-Reply-To: <CAJ0D3QQiRDk0hhMS3DA7V67Hcm9MOh=L-e0_0J2hcpZLtbB8+Q@mail.gmail.com>
References: <CAJ0D3QQiRDk0hhMS3DA7V67Hcm9MOh=L-e0_0J2hcpZLtbB8+Q@mail.gmail.com>
Message-ID: <SJ2PR10MB7669448043A4D508572B984FA293A@SJ2PR10MB7669.namprd10.prod.outlook.com>

CC'ing the javadoc-dev list too.
________________________________
From: compiler-dev <compiler-dev-retn at openjdk.org> on behalf of David Thompson <davthomp at redhat.com>
Sent: Friday, May 16, 2025 8:21 AM
To: compiler-dev at openjdk.org <compiler-dev at openjdk.org>
Cc: Hannes Wallnoefer <hannes.wallnoefer at oracle.com>
Subject: JDK-8356411

Hello,

I've started looking at JDK-8356411. I've narrowed it down to `MarkdownTransformer` (in particular `Lower.flushText`) not taking into account that the leading whitespace has been stripped from the markdown text following the `@see` tag (and probably other similar tags). I've been working on a fix for this but don't have anything working yet.

I've noticed that Hannes Wallnoefer has been assigned this issue. Is it worthwhile for me to continue investigating?

Thanks,

--
David Thompson
they/she/he
Devtools at Red Hat
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/javadoc-dev/attachments/20250516/3152cf36/attachment.htm>

From hannes.wallnoefer at oracle.com  Fri May 16 13:54:47 2025
From: hannes.wallnoefer at oracle.com (Hannes Wallnoefer)
Date: Fri, 16 May 2025 13:54:47 +0000
Subject: [External] : JDK-8356411
In-Reply-To: <CAJ0D3QQiRDk0hhMS3DA7V67Hcm9MOh=L-e0_0J2hcpZLtbB8+Q@mail.gmail.com>
References: <CAJ0D3QQiRDk0hhMS3DA7V67Hcm9MOh=L-e0_0J2hcpZLtbB8+Q@mail.gmail.com>
Message-ID: <0FE6F539-FE52-4FFD-B0E8-7A3D20B82264@oracle.com>

Hi David, 

I haven?t looked into this bug yet, but I suspected it might have something to do with stripping whitespace. 

I plan to look into the issue soon, but if you?re interested in getting the issue fixed you are certainly welcome to continue investigating..

Hannes

> On 16.05.2025, at 15:21, David Thompson <davthomp at redhat.com> wrote:
> 
> Hello,
> 
> I've started looking at JDK-8356411. I've narrowed it down to `MarkdownTransformer` (in particular `Lower.flushText`) not taking into account that the leading whitespace has been stripped from the markdown text following the `@see` tag (and probably other similar tags). I've been working on a fix for this but don't have anything working yet.
> 
> I've noticed that Hannes Wallnoefer has been assigned this issue. Is it worthwhile for me to continue investigating?
> 
> Thanks,
> 
> --
> David Thompson
> they/she/he
> Devtools at Red Hat


From hannesw at openjdk.org  Tue May 20 13:55:42 2025
From: hannesw at openjdk.org (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=)
Date: Tue, 20 May 2025 13:55:42 GMT
Subject: RFR: 8338833: Error on reference not found for a snippet target
Message-ID: <AdMoPYN4lvs5SZgfdCSu5TDTUfnzLLvPtGI-FCfDfnI=.5c63e039-758a-4eb2-a96e-e01ded023cb7@github.com>

Please review a trivial fix to generate an error when a link in a snippet has an invalid target.

-------------

Commit messages:
 - 8338833: Error on reference not found for a snippet target

Changes: https://git.openjdk.org/jdk/pull/25329/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25329&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8338833
  Stats: 49 lines in 2 files changed: 46 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/25329.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25329/head:pull/25329

PR: https://git.openjdk.org/jdk/pull/25329

From prappo at openjdk.org  Wed May 21 07:37:51 2025
From: prappo at openjdk.org (Pavel Rappo)
Date: Wed, 21 May 2025 07:37:51 GMT
Subject: RFR: 8338833: Error on reference not found for a snippet target
In-Reply-To: <AdMoPYN4lvs5SZgfdCSu5TDTUfnzLLvPtGI-FCfDfnI=.5c63e039-758a-4eb2-a96e-e01ded023cb7@github.com>
References: <AdMoPYN4lvs5SZgfdCSu5TDTUfnzLLvPtGI-FCfDfnI=.5c63e039-758a-4eb2-a96e-e01ded023cb7@github.com>
Message-ID: <te5ZcQEK6Y97-UTPdp0md33JkPj93PE627apCZwUvhM=.8347393d-d048-47cb-a84a-0e12b6fa4185@github.com>

On Tue, 20 May 2025 13:49:37 GMT, Hannes Walln?fer <hannesw at openjdk.org> wrote:

> Please review a trivial fix to generate an error when a link in a snippet has an invalid target.

Marked as reviewed by prappo (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/25329#pullrequestreview-2856632833

From hannesw at openjdk.org  Wed May 21 10:06:36 2025
From: hannesw at openjdk.org (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=)
Date: Wed, 21 May 2025 10:06:36 GMT
Subject: RFR: 8338833: Error on reference not found for a snippet target
 [v2]
In-Reply-To: <AdMoPYN4lvs5SZgfdCSu5TDTUfnzLLvPtGI-FCfDfnI=.5c63e039-758a-4eb2-a96e-e01ded023cb7@github.com>
References: <AdMoPYN4lvs5SZgfdCSu5TDTUfnzLLvPtGI-FCfDfnI=.5c63e039-758a-4eb2-a96e-e01ded023cb7@github.com>
Message-ID: <D5sgZt8_l9MyzKJ0EGVFhwvuxPgESPadNT9z_nGY7rE=.ce057d32-aafd-4f71-b397-6742dc8046db@github.com>

> Please review a trivial fix to generate an error when a link in a snippet has an invalid target.

Hannes Walln?fer has updated the pull request incrementally with one additional commit since the last revision:

  Remove assert that prevents invalid tag markup and rename variable

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/25329/files
  - new: https://git.openjdk.org/jdk/pull/25329/files/1e220061..dfd43e23

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25329&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25329&range=00-01

  Stats: 6 lines in 1 file changed: 0 ins; 1 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/25329.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25329/head:pull/25329

PR: https://git.openjdk.org/jdk/pull/25329

From hannesw at openjdk.org  Wed May 21 10:08:51 2025
From: hannesw at openjdk.org (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=)
Date: Wed, 21 May 2025 10:08:51 GMT
Subject: RFR: 8338833: Error on reference not found for a snippet target
 [v2]
In-Reply-To: <te5ZcQEK6Y97-UTPdp0md33JkPj93PE627apCZwUvhM=.8347393d-d048-47cb-a84a-0e12b6fa4185@github.com>
References: <AdMoPYN4lvs5SZgfdCSu5TDTUfnzLLvPtGI-FCfDfnI=.5c63e039-758a-4eb2-a96e-e01ded023cb7@github.com>
 <te5ZcQEK6Y97-UTPdp0md33JkPj93PE627apCZwUvhM=.8347393d-d048-47cb-a84a-0e12b6fa4185@github.com>
Message-ID: <Zt2fleaCu1FkhipOCJKBdIKQyHRM-UpJZaXjJVoSlSI=.0c884bfb-a65a-42ed-a73e-fdae1e6c6992@github.com>

On Wed, 21 May 2025 07:35:12 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> Hannes Walln?fer has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Remove assert that prevents invalid tag markup and rename variable
>
> Marked as reviewed by prappo (Reviewer).

Thanks for the review, @pavelrappo! 

Unfortunately, my initial commit wasn't complete, I also had to remove an assert that would trigger with invalid reference (the `linkSeeReferenceOutput` method should be called with `null` reference, it generates the invalid tag markup).

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25329#issuecomment-2897381925

From hannesw at openjdk.org  Wed May 21 11:20:08 2025
From: hannesw at openjdk.org (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=)
Date: Wed, 21 May 2025 11:20:08 GMT
Subject: RFR: 8357452: Remove code span highlight in JavaDoc default stylesheet
Message-ID: <AFdt2S67rI0mFB-Lf0lYPUmSu-kBxGrTYbutKrUs8bc=.246b4adc-d05a-4092-bc8f-5da1d77ceeb2@github.com>

Please review a simple change to remove highlighting of code spans (background and padding) in the default JavaDoc stylesheet.

-------------

Commit messages:
 - 8357452: Remove code span highlight in JavaDoc default stylesheet

Changes: https://git.openjdk.org/jdk/pull/25349/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25349&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8357452
  Stats: 11 lines in 1 file changed: 0 ins; 11 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/25349.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25349/head:pull/25349

PR: https://git.openjdk.org/jdk/pull/25349

From hannesw at openjdk.org  Wed May 21 12:42:39 2025
From: hannesw at openjdk.org (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=)
Date: Wed, 21 May 2025 12:42:39 GMT
Subject: RFR: 8357458: Missing Highlight.js license file
Message-ID: <sdYdoeEnTocJ1HskRPb3vIi2CGlS3C69YnjHLhxRdi0=.6c996437-ebfe-40bc-9297-8f9f8011d435@github.com>

Please review a change to add the missing license file for Highlight.js required for the `--syntax-highlight` option. This also updates the tests for legal files and library versions to handle the file correctly.

-------------

Commit messages:
 - 8357458: Missing Highlight.js license file

Changes: https://git.openjdk.org/jdk/pull/25352/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25352&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8357458
  Stats: 69 lines in 4 files changed: 51 ins; 0 del; 18 mod
  Patch: https://git.openjdk.org/jdk/pull/25352.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25352/head:pull/25352

PR: https://git.openjdk.org/jdk/pull/25352

From prappo at openjdk.org  Wed May 21 14:05:54 2025
From: prappo at openjdk.org (Pavel Rappo)
Date: Wed, 21 May 2025 14:05:54 GMT
Subject: RFR: 8338833: Error on reference not found for a snippet target
 [v2]
In-Reply-To: <D5sgZt8_l9MyzKJ0EGVFhwvuxPgESPadNT9z_nGY7rE=.ce057d32-aafd-4f71-b397-6742dc8046db@github.com>
References: <AdMoPYN4lvs5SZgfdCSu5TDTUfnzLLvPtGI-FCfDfnI=.5c63e039-758a-4eb2-a96e-e01ded023cb7@github.com>
 <D5sgZt8_l9MyzKJ0EGVFhwvuxPgESPadNT9z_nGY7rE=.ce057d32-aafd-4f71-b397-6742dc8046db@github.com>
Message-ID: <UJDiCGTy5a33k1VTrk4-oy2JvGxpgGSwcCuP9h8RSfs=.b8102a18-ce3e-4913-9d95-95ae9f792b04@github.com>

On Wed, 21 May 2025 10:06:36 GMT, Hannes Walln?fer <hannesw at openjdk.org> wrote:

>> Please review a trivial fix to generate an error when a link in a snippet has an invalid target.
>
> Hannes Walln?fer has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove assert that prevents invalid tag markup and rename variable

Marked as reviewed by prappo (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/25329#pullrequestreview-2857869499

From hannesw at openjdk.org  Wed May 21 14:40:00 2025
From: hannesw at openjdk.org (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=)
Date: Wed, 21 May 2025 14:40:00 GMT
Subject: Integrated: 8338833: Error on reference not found for a snippet target
In-Reply-To: <AdMoPYN4lvs5SZgfdCSu5TDTUfnzLLvPtGI-FCfDfnI=.5c63e039-758a-4eb2-a96e-e01ded023cb7@github.com>
References: <AdMoPYN4lvs5SZgfdCSu5TDTUfnzLLvPtGI-FCfDfnI=.5c63e039-758a-4eb2-a96e-e01ded023cb7@github.com>
Message-ID: <CwUolWLjwuzT1EyMQFsN3LUfWEnGEzYOKM4_RL3dkLw=.4f879b93-acce-4a54-b124-35b946c28c00@github.com>

On Tue, 20 May 2025 13:49:37 GMT, Hannes Walln?fer <hannesw at openjdk.org> wrote:

> Please review a trivial fix to generate an error when a link in a snippet has an invalid target.

This pull request has now been integrated.

Changeset: 254713ab
Author:    Hannes Walln?fer <hannesw at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/254713ab598f186fd31484a48a6dfebaeb752920
Stats:     55 lines in 2 files changed: 46 ins; 1 del; 8 mod

8338833: Error on reference not found for a snippet target

Reviewed-by: prappo

-------------

PR: https://git.openjdk.org/jdk/pull/25329

From nbenalla at openjdk.org  Wed May 21 16:13:52 2025
From: nbenalla at openjdk.org (Nizar Benalla)
Date: Wed, 21 May 2025 16:13:52 GMT
Subject: RFR: 8357452: Remove code span highlight in JavaDoc default
 stylesheet
In-Reply-To: <AFdt2S67rI0mFB-Lf0lYPUmSu-kBxGrTYbutKrUs8bc=.246b4adc-d05a-4092-bc8f-5da1d77ceeb2@github.com>
References: <AFdt2S67rI0mFB-Lf0lYPUmSu-kBxGrTYbutKrUs8bc=.246b4adc-d05a-4092-bc8f-5da1d77ceeb2@github.com>
Message-ID: <D6BEYICN9o6Dsf3PukBZg8czDRyCA3HztvaN3rEa2g4=.841f019c-c403-449c-9482-55815b441670@github.com>

On Wed, 21 May 2025 11:14:59 GMT, Hannes Walln?fer <hannesw at openjdk.org> wrote:

> Please review a simple change to remove highlighting of code spans (background and padding) in the default JavaDoc stylesheet.

I think this looks trivially good.

-------------

Marked as reviewed by nbenalla (Committer).

PR Review: https://git.openjdk.org/jdk/pull/25349#pullrequestreview-2858382768

From jjg at openjdk.org  Wed May 21 16:50:58 2025
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Wed, 21 May 2025 16:50:58 GMT
Subject: RFR: 8357452: Remove code span highlight in JavaDoc default
 stylesheet
In-Reply-To: <AFdt2S67rI0mFB-Lf0lYPUmSu-kBxGrTYbutKrUs8bc=.246b4adc-d05a-4092-bc8f-5da1d77ceeb2@github.com>
References: <AFdt2S67rI0mFB-Lf0lYPUmSu-kBxGrTYbutKrUs8bc=.246b4adc-d05a-4092-bc8f-5da1d77ceeb2@github.com>
Message-ID: <bGJfAyMqc1HtFdXWODF9Vep25ig9ND6ZEq4gEP83UpA=.f2a0436d-2780-4e78-91a9-035e79526241@github.com>

On Wed, 21 May 2025 11:14:59 GMT, Hannes Walln?fer <hannesw at openjdk.org> wrote:

> Please review a simple change to remove highlighting of code spans (background and padding) in the default JavaDoc stylesheet.

Marked as reviewed by jjg (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/25349#pullrequestreview-2858487042

From liach at openjdk.org  Wed May 21 17:03:50 2025
From: liach at openjdk.org (Chen Liang)
Date: Wed, 21 May 2025 17:03:50 GMT
Subject: RFR: 8357452: Remove code span highlight in JavaDoc default
 stylesheet
In-Reply-To: <AFdt2S67rI0mFB-Lf0lYPUmSu-kBxGrTYbutKrUs8bc=.246b4adc-d05a-4092-bc8f-5da1d77ceeb2@github.com>
References: <AFdt2S67rI0mFB-Lf0lYPUmSu-kBxGrTYbutKrUs8bc=.246b4adc-d05a-4092-bc8f-5da1d77ceeb2@github.com>
Message-ID: <MSQB1xB-3a1AMKlGu26dWXFC8a5FFf10XYE7EXreAiU=.267bc943-28f9-42b3-978f-ceaba8145d45@github.com>

On Wed, 21 May 2025 11:14:59 GMT, Hannes Walln?fer <hannesw at openjdk.org> wrote:

> Please review a simple change to remove highlighting of code spans (background and padding) in the default JavaDoc stylesheet.

Marked as reviewed by liach (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/25349#pullrequestreview-2858521270

From hannesw at openjdk.org  Wed May 21 17:24:06 2025
From: hannesw at openjdk.org (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=)
Date: Wed, 21 May 2025 17:24:06 GMT
Subject: Integrated: 8357452: Remove code span highlight in JavaDoc default
 stylesheet
In-Reply-To: <AFdt2S67rI0mFB-Lf0lYPUmSu-kBxGrTYbutKrUs8bc=.246b4adc-d05a-4092-bc8f-5da1d77ceeb2@github.com>
References: <AFdt2S67rI0mFB-Lf0lYPUmSu-kBxGrTYbutKrUs8bc=.246b4adc-d05a-4092-bc8f-5da1d77ceeb2@github.com>
Message-ID: <GMvnIo67PVn5hBZfRy2IyJf-DnLkgwPvypebA-i5WlI=.796ea829-a047-49d1-a553-71aa3935ed45@github.com>

On Wed, 21 May 2025 11:14:59 GMT, Hannes Walln?fer <hannesw at openjdk.org> wrote:

> Please review a simple change to remove highlighting of code spans (background and padding) in the default JavaDoc stylesheet.

This pull request has now been integrated.

Changeset: f1eead60
Author:    Hannes Walln?fer <hannesw at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/f1eead60358fb919a94c7a91e61d1e54f04e584a
Stats:     11 lines in 1 file changed: 0 ins; 11 del; 0 mod

8357452: Remove code span highlight in JavaDoc default stylesheet

Reviewed-by: nbenalla, jjg, liach

-------------

PR: https://git.openjdk.org/jdk/pull/25349

From hannesw at openjdk.org  Wed May 21 20:05:08 2025
From: hannesw at openjdk.org (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=)
Date: Wed, 21 May 2025 20:05:08 GMT
Subject: RFR: 8357458: Missing Highlight.js license file [v2]
In-Reply-To: <sdYdoeEnTocJ1HskRPb3vIi2CGlS3C69YnjHLhxRdi0=.6c996437-ebfe-40bc-9297-8f9f8011d435@github.com>
References: <sdYdoeEnTocJ1HskRPb3vIi2CGlS3C69YnjHLhxRdi0=.6c996437-ebfe-40bc-9297-8f9f8011d435@github.com>
Message-ID: <mE8OyD-p_w9dycsYfMhbBlCoNAfur3zduTcI_qMjV_k=.c0060a4b-e794-4199-896c-99af3eb4bcd4@github.com>

> Please review a change to add the missing license file for Highlight.js required for the `--syntax-highlight` option. This also updates the tests for legal files and library versions to handle the file correctly.

Hannes Walln?fer has updated the pull request incrementally with one additional commit since the last revision:

  Capitalize license heading

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/25352/files
  - new: https://git.openjdk.org/jdk/pull/25352/files/d4a66674..79427e74

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25352&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25352&range=00-01

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/25352.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25352/head:pull/25352

PR: https://git.openjdk.org/jdk/pull/25352

From vyazici at openjdk.org  Wed May 21 21:02:04 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Wed, 21 May 2025 21:02:04 GMT
Subject: RFR: 8356893: Use "stdin.encoding" for reading System.in with
 InputStreamReader/Scanner
Message-ID: <zUY_JnCeV8WBNrslGu4i4KYk4k1Rg0WbfO0WBPqjFwE=.19a8dc0b-2ea0-4db4-870d-8309c84619ed@github.com>

There are several locations in the JDK source where `System.in` and `FileDescriptor.in` is read with `InputStreamReader` and `Scanner` using the default charset. As recommended by the recently merged [JDK-8356420](https://bugs.openjdk.org/browse/JDK-8356420), this PR replaces the default charset with the one provided by the `stdin.encoding` system property.

### Fixing strategy

* Where it is obvious that `System.in` is passed to `InputStreamReader`/`Scanner` ctors, `stdin.encoding` is employed fixed.
* Where the `InputStream` passed to `InputStreamReader`/`Scanner` ctors is difficult to determine if it can ever be `System.in`, `assert` expressions are placed.
* Where the odds of receiving `System.in` are low, yet it is technically possible (e.g., `Process::getInputStream`, `URL::openConnection`, `Class::getResourceAsStream`), nothing is done.

@naotoj was kind enough to guide me in this PR, and stated `assert` expressions can be skipped, since they are many ways one can circumvent those checks; wrapping `System.in`, usage of `System::setIn`, etc. Yet we decided to leave them as is to collect feedback from other reviewers too.

### Scanning strategy

The following ~alien technology~ advanced static analysis tools are used to scan the code for potentially affected places:


# Perl is used for multi-line matching
find . -name "*.java" -exec perl -0777 -ne 'my $r = (/(InputStreamReader|Scanner)(\s*System.in)/) ? 0 : 1; exit $r' {} ; -print
git grep -H 'FileDescriptor.in' "*.java"


All calls to `InputStreamReader::new` and `Scanner::new` are checked too.

### Problems encountered

1. Due to either irregular, or non-existent license header, could not update the copyright year for following classes:

    ```
    DOMImplementationRegistry 
    InputRC 
    ListingErrorHandler 
    PandocFilter 
    ```
2. Could not employ `stdin.encoding` in `PandocFilter`, since the bootstrap VM running that class returns empty for that system property

-------------

Commit messages:
 - Use `stdin.encoding` in `InputStreamReader` and `Scanner` instantiations

Changes: https://git.openjdk.org/jdk/pull/25368/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25368&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8356893
  Stats: 244 lines in 58 files changed: 111 ins; 20 del; 113 mod
  Patch: https://git.openjdk.org/jdk/pull/25368.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25368/head:pull/25368

PR: https://git.openjdk.org/jdk/pull/25368

From rriggs at openjdk.org  Wed May 21 21:39:53 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Wed, 21 May 2025 21:39:53 GMT
Subject: RFR: 8356893: Use "stdin.encoding" for reading System.in with
 InputStreamReader/Scanner
In-Reply-To: <zUY_JnCeV8WBNrslGu4i4KYk4k1Rg0WbfO0WBPqjFwE=.19a8dc0b-2ea0-4db4-870d-8309c84619ed@github.com>
References: <zUY_JnCeV8WBNrslGu4i4KYk4k1Rg0WbfO0WBPqjFwE=.19a8dc0b-2ea0-4db4-870d-8309c84619ed@github.com>
Message-ID: <h1r8vY73RNYPmo58IlsyLRRdsji4zlhxTaaSZiM8434=.8a644894-d0e6-4fb6-8650-2432bc738341@github.com>

On Wed, 21 May 2025 20:56:31 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

> There are several locations in the JDK source where `System.in` and `FileDescriptor.in` is read with `InputStreamReader` and `Scanner` using the default charset. As recommended by the recently merged [JDK-8356420](https://bugs.openjdk.org/browse/JDK-8356420), this PR replaces the default charset with the one provided by the `stdin.encoding` system property.
> 
> ### Fixing strategy
> 
> * Where it is obvious that `System.in` is passed to `InputStreamReader`/`Scanner` ctors, `stdin.encoding` is employed fixed.
> * Where the `InputStream` passed to `InputStreamReader`/`Scanner` ctors is difficult to determine if it can ever be `System.in`, `assert` expressions are placed.
> * Where the odds of receiving `System.in` are low, yet it is technically possible (e.g., `Process::getInputStream`, `URL::openConnection`, `Class::getResourceAsStream`), nothing is done.
> 
> @naotoj was kind enough to guide me in this PR, and stated `assert` expressions can be skipped, since they are many ways one can circumvent those checks; wrapping `System.in`, usage of `System::setIn`, etc. Yet we decided to leave them as is to collect feedback from other reviewers too.
> 
> ### Scanning strategy
> 
> The following ~alien technology~ advanced static analysis tools are used to scan the code for potentially affected places:
> 
> 
> # Perl is used for multi-line matching
> find . -name "*.java" -exec perl -0777 -ne 'my $r = (/(InputStreamReader|Scanner)(\s*System.in)/) ? 0 : 1; exit $r' {} ; -print
> git grep -H 'FileDescriptor.in' "*.java"
> 
> 
> All calls to `InputStreamReader::new` and `Scanner::new` are checked too.
> 
> ### Problems encountered
> 
> 1. Due to either irregular, or non-existent license header, could not update the copyright year for following classes:
> 
>     ```
>     DOMImplementationRegistry 
>     InputRC 
>     ListingErrorHandler 
>     PandocFilter 
>     ```
> 2. Could not employ `stdin.encoding` in `PandocFilter`, since the bootstrap VM running that class returns empty for that system property

There too many changes in too many different areas to be in a single PR.
Please break it down by review areas.  Client, core libs, tools, etc.

-------------

PR Review: https://git.openjdk.org/jdk/pull/25368#pullrequestreview-2859185030

From alanb at openjdk.org  Thu May 22 05:54:52 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 22 May 2025 05:54:52 GMT
Subject: RFR: 8356893: Use "stdin.encoding" for reading System.in with
 InputStreamReader/Scanner
In-Reply-To: <zUY_JnCeV8WBNrslGu4i4KYk4k1Rg0WbfO0WBPqjFwE=.19a8dc0b-2ea0-4db4-870d-8309c84619ed@github.com>
References: <zUY_JnCeV8WBNrslGu4i4KYk4k1Rg0WbfO0WBPqjFwE=.19a8dc0b-2ea0-4db4-870d-8309c84619ed@github.com>
Message-ID: <wrtUfsbfcWNXz5eMaykcIbLOPC5019cvCsig_cLn7L4=.bd0dab1a-ad1e-465c-852b-8fb66d81f401@github.com>

On Wed, 21 May 2025 20:56:31 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

> There are several locations in the JDK source where `System.in` and `FileDescriptor.in` is read with `InputStreamReader` and `Scanner` using the default charset. As recommended by the recently merged [JDK-8356420](https://bugs.openjdk.org/browse/JDK-8356420), this PR replaces the default charset with the one provided by the `stdin.encoding` system property.
> 
> ### Fixing strategy
> 
> * Where it is obvious that `System.in` is passed to `InputStreamReader`/`Scanner` ctors, `stdin.encoding` is employed fixed.
> * Where the `InputStream` passed to `InputStreamReader`/`Scanner` ctors is difficult to determine if it can ever be `System.in`, `assert` expressions are placed.
> * Where the odds of receiving `System.in` are low, yet it is technically possible (e.g., `Process::getInputStream`, `URL::openConnection`, `Class::getResourceAsStream`), nothing is done.
> 
> @naotoj was kind enough to guide me in this PR, and stated `assert` expressions can be skipped, since they are many ways one can circumvent those checks; wrapping `System.in`, usage of `System::setIn`, etc. Yet we decided to leave them as is to collect feedback from other reviewers too.
> 
> ### Scanning strategy
> 
> The following ~alien technology~ advanced static analysis tools are used to scan the code for potentially affected places:
> 
> 
> # Perl is used for multi-line matching
> find . -name "*.java" -exec perl -0777 -ne 'my $r = (/(InputStreamReader|Scanner)(\s*System.in)/) ? 0 : 1; exit $r' {} ; -print
> git grep -H 'FileDescriptor.in' "*.java"
> 
> 
> All calls to `InputStreamReader::new` and `Scanner::new` are checked too.
> 
> ### Problems encountered
> 
> 1. Due to either irregular, or non-existent license header, could not update the copyright year for following classes:
> 
>     ```
>     DOMImplementationRegistry 
>     InputRC 
>     ListingErrorHandler 
>     PandocFilter 
>     ```
> 2. Could not employ `stdin.encoding` in `PandocFilter`, since the bootstrap VM running that class returns empty for that system property

javax.swing.text.DefaultEditorKit.read(InputStream ...)  is one example changed in the PR. If that is changed to special case System.in then it will require a spec change. It also means that `read(System.in)` will behave differently to say `new BufferedInputStream(System.in)`.  From a quick scan, I suspect changes that impact the APIs will need to dropped from the PR, maybe replaced with spec clarification to document the charset that is actually used. In the DefaultEditorKit.read example it might direct folks to the read(Reader ..) method so that code can control which charset to use.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25368#issuecomment-2899998753

From vyazici at openjdk.org  Thu May 22 07:59:09 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Thu, 22 May 2025 07:59:09 GMT
Subject: RFR: 8356893: Use "stdin.encoding" for reading System.in with
 InputStreamReader/Scanner
In-Reply-To: <h1r8vY73RNYPmo58IlsyLRRdsji4zlhxTaaSZiM8434=.8a644894-d0e6-4fb6-8650-2432bc738341@github.com>
References: <zUY_JnCeV8WBNrslGu4i4KYk4k1Rg0WbfO0WBPqjFwE=.19a8dc0b-2ea0-4db4-870d-8309c84619ed@github.com>
 <h1r8vY73RNYPmo58IlsyLRRdsji4zlhxTaaSZiM8434=.8a644894-d0e6-4fb6-8650-2432bc738341@github.com>
Message-ID: <JR9YcwtR6e9rtwHNRjzrc_f3vDzGlX5P7HbsynNMOmQ=.58dcd998-ff73-4547-b619-1ba8fa12bd7d@github.com>

On Wed, 21 May 2025 21:37:07 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> There are several locations in the JDK source where `System.in` and `FileDescriptor.in` is read with `InputStreamReader` and `Scanner` using the default charset. As recommended by the recently merged [JDK-8356420](https://bugs.openjdk.org/browse/JDK-8356420), this PR replaces the default charset with the one provided by the `stdin.encoding` system property.
>> 
>> ### Fixing strategy
>> 
>> * Where it is obvious that `System.in` is passed to `InputStreamReader`/`Scanner` ctors, `stdin.encoding` is employed fixed.
>> * Where the `InputStream` passed to `InputStreamReader`/`Scanner` ctors is difficult to determine if it can ever be `System.in`, `assert` expressions are placed.
>> * Where the odds of receiving `System.in` are low, yet it is technically possible (e.g., `Process::getInputStream`, `URL::openConnection`, `Class::getResourceAsStream`), nothing is done.
>> 
>> @naotoj was kind enough to guide me in this PR, and stated `assert` expressions can be skipped, since they are many ways one can circumvent those checks; wrapping `System.in`, usage of `System::setIn`, etc. Yet we decided to leave them as is to collect feedback from other reviewers too.
>> 
>> ### Scanning strategy
>> 
>> The following ~alien technology~ advanced static analysis tools are used to scan the code for potentially affected places:
>> 
>> 
>> # Perl is used for multi-line matching
>> find . -name "*.java" -exec perl -0777 -ne 'my $r = (/(InputStreamReader|Scanner)(\s*System.in)/) ? 0 : 1; exit $r' {} ; -print
>> git grep -H 'FileDescriptor.in' "*.java"
>> 
>> 
>> All calls to `InputStreamReader::new` and `Scanner::new` are checked too.
>> 
>> ### Problems encountered
>> 
>> 1. Due to either irregular, or non-existent license header, could not update the copyright year for following classes:
>> 
>>     ```
>>     DOMImplementationRegistry 
>>     InputRC 
>>     ListingErrorHandler 
>>     PandocFilter 
>>     ```
>> 2. Could not employ `stdin.encoding` in `PandocFilter`, since the bootstrap VM running that class returns empty for that system property
>
> There too many changes in too many different areas to be in a single PR.
> Please break it down by review areas.  Client, core libs, tools, etc.

@RogerRiggs, @AlanBateman, thanks so much for the quick review. I see your points. I will

1. withdraw this PR,
2. convert certain changes to spec clarifications,
3. and break it down to multiple PRs.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25368#issuecomment-2900262422

From vyazici at openjdk.org  Thu May 22 07:59:10 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Thu, 22 May 2025 07:59:10 GMT
Subject: Withdrawn: 8356893: Use "stdin.encoding" for reading System.in with
 InputStreamReader/Scanner
In-Reply-To: <zUY_JnCeV8WBNrslGu4i4KYk4k1Rg0WbfO0WBPqjFwE=.19a8dc0b-2ea0-4db4-870d-8309c84619ed@github.com>
References: <zUY_JnCeV8WBNrslGu4i4KYk4k1Rg0WbfO0WBPqjFwE=.19a8dc0b-2ea0-4db4-870d-8309c84619ed@github.com>
Message-ID: <cRfyJRr23DS3mw4U7XMBE6rBHXIWxlQiEcNpKG-wZBw=.6a7bcbb9-9cb6-45dc-8ce6-40fefbd328ff@github.com>

On Wed, 21 May 2025 20:56:31 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

> There are several locations in the JDK source where `System.in` and `FileDescriptor.in` is read with `InputStreamReader` and `Scanner` using the default charset. As recommended by the recently merged [JDK-8356420](https://bugs.openjdk.org/browse/JDK-8356420), this PR replaces the default charset with the one provided by the `stdin.encoding` system property.
> 
> ### Fixing strategy
> 
> * Where it is obvious that `System.in` is passed to `InputStreamReader`/`Scanner` ctors, `stdin.encoding` is employed fixed.
> * Where the `InputStream` passed to `InputStreamReader`/`Scanner` ctors is difficult to determine if it can ever be `System.in`, `assert` expressions are placed.
> * Where the odds of receiving `System.in` are low, yet it is technically possible (e.g., `Process::getInputStream`, `URL::openConnection`, `Class::getResourceAsStream`), nothing is done.
> 
> @naotoj was kind enough to guide me in this PR, and stated `assert` expressions can be skipped, since they are many ways one can circumvent those checks; wrapping `System.in`, usage of `System::setIn`, etc. Yet we decided to leave them as is to collect feedback from other reviewers too.
> 
> ### Scanning strategy
> 
> The following ~alien technology~ advanced static analysis tools are used to scan the code for potentially affected places:
> 
> 
> # Perl is used for multi-line matching
> find . -name "*.java" -exec perl -0777 -ne 'my $r = (/(InputStreamReader|Scanner)(\s*System.in)/) ? 0 : 1; exit $r' {} ; -print
> git grep -H 'FileDescriptor.in' "*.java"
> 
> 
> All calls to `InputStreamReader::new` and `Scanner::new` are checked too.
> 
> ### Problems encountered
> 
> 1. Due to either irregular, or non-existent license header, could not update the copyright year for following classes:
> 
>     ```
>     DOMImplementationRegistry 
>     InputRC 
>     ListingErrorHandler 
>     PandocFilter 
>     ```
> 2. Could not employ `stdin.encoding` in `PandocFilter`, since the bootstrap VM running that class returns empty for that system property

This pull request has been closed without being integrated.

-------------

PR: https://git.openjdk.org/jdk/pull/25368

From prr at openjdk.org  Thu May 22 21:45:52 2025
From: prr at openjdk.org (Phil Race)
Date: Thu, 22 May 2025 21:45:52 GMT
Subject: RFR: 8356977: UTF-8 cleanups
In-Reply-To: <s4znWc8WCK3liY8YOhRldnBN7yPJr8m-doBeEArSHd0=.0632ae03-da95-4bd5-865f-e8276544bed5@github.com>
References: <s4znWc8WCK3liY8YOhRldnBN7yPJr8m-doBeEArSHd0=.0632ae03-da95-4bd5-865f-e8276544bed5@github.com>
Message-ID: <jO8_Rg8XVb6CjtA56LiKdFLPBpcVW4pYYeI-u6jQxVc=.6110d5d2-c1c9-4aa5-8cdf-244d54eab5fd@github.com>

On Wed, 14 May 2025 14:23:31 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> I found a few other places in the code that can be cleaned up after the conversion to UTF-8.

src/java.desktop/share/classes/java/awt/MenuShortcut.java line 49:

> 47:  * For example, a menu shortcut for "Ctrl+cyrillic ef" is created by
> 48:  * <p>
> 49:  * <code>MenuShortcut ms = new MenuShortcut(KeyEvent.getExtendedKeyCodeForChar('?'), false);</code>

This is javadoc inJava SE specification. As is the Action case below.
I can't think of any actual harm from this change, so OK,  but I am not seeing why it is needed.

test/jdk/java/awt/font/TextLayout/RotFontBoundsTest.java line 63:

> 61: 
> 62:     private static final String INSTRUCTIONS =
> 63:             "A string \u201C" + TEXT + "\u201D is drawn at eight different "

I really don't like these tests being changed. It isn't part of the JDK build.
People compile these in all sorts of locales.
Please revert all the changes in the client tests.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25228#discussion_r2103439338
PR Review Comment: https://git.openjdk.org/jdk/pull/25228#discussion_r2103431874

From ihse at openjdk.org  Mon May 26 07:47:02 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 26 May 2025 07:47:02 GMT
Subject: RFR: 8356977: UTF-8 cleanups
In-Reply-To: <5oMrogxJyi1_OsPAGntbPTiR5aCIFOTuDSUTKOv7wyo=.b715c9d2-0cdd-4585-a262-bdbe5a72a5fa@github.com>
References: <s4znWc8WCK3liY8YOhRldnBN7yPJr8m-doBeEArSHd0=.0632ae03-da95-4bd5-865f-e8276544bed5@github.com>
 <5oMrogxJyi1_OsPAGntbPTiR5aCIFOTuDSUTKOv7wyo=.b715c9d2-0cdd-4585-a262-bdbe5a72a5fa@github.com>
Message-ID: <lt8vg3M1QU-xbe_E0l4n1j9V9sM_0VsM8kOt11Mk1L0=.d6e6845c-ff78-45f2-8f8e-6a40b9e12ba1@github.com>

On Thu, 15 May 2025 18:30:28 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> I found a few other places in the code that can be cleaned up after the conversion to UTF-8.
>
> test/jdk/sun/text/resources/LocaleDataTest.java line 106:
> 
>> 104:  *        FormatData/fr_FR/MonthNames/0=janvier
>> 105:  *        FormatData/fr_FR/MonthNames/1=f?vrier
>> 106:  *        LocaleNames/fr_FR/US=?tats-Unis
> 
> This test data (LocaleData.cldr) is explicitly encoded in ISO-8859-1 with unicode escapes for characters outside of it. So only changing these ones in comment does not seem correct.

ISO-8859-1 does not sound good, and got me worried. But in fact it seems like the file is pure ASCII, and that is fine. 

However, if the file should ever be changed to include actual ISO-8859-1 encoding, this might break if tools assume it is UTF-8-encoding, since not all ISO-8859-1 encodings are valid UTF-8.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25228#discussion_r2106755160

From ihse at openjdk.org  Mon May 26 08:20:19 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 26 May 2025 08:20:19 GMT
Subject: RFR: 8356977: UTF-8 cleanups [v2]
In-Reply-To: <s4znWc8WCK3liY8YOhRldnBN7yPJr8m-doBeEArSHd0=.0632ae03-da95-4bd5-865f-e8276544bed5@github.com>
References: <s4znWc8WCK3liY8YOhRldnBN7yPJr8m-doBeEArSHd0=.0632ae03-da95-4bd5-865f-e8276544bed5@github.com>
Message-ID: <QDrGzqvDzyZaQMSG3oplXlRSGMmGAMsQPeNnu8G4msU=.5f385862-0ca1-4b20-a31d-0c9e142728b7@github.com>

> I found a few other places in the code that can be cleaned up after the conversion to UTF-8.

Magnus Ihse Bursie has updated the pull request incrementally with two additional commits since the last revision:

 - Restore MenuShortcut.java
 - Restore LocaleDataTest.java

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/25228/files
  - new: https://git.openjdk.org/jdk/pull/25228/files/9c904992..7184e685

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25228&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25228&range=00-01

  Stats: 4 lines in 2 files changed: 0 ins; 0 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/25228.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25228/head:pull/25228

PR: https://git.openjdk.org/jdk/pull/25228

From ihse at openjdk.org  Mon May 26 08:20:46 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 26 May 2025 08:20:46 GMT
Subject: RFR: 8356977: UTF-8 cleanups [v2]
In-Reply-To: <jO8_Rg8XVb6CjtA56LiKdFLPBpcVW4pYYeI-u6jQxVc=.6110d5d2-c1c9-4aa5-8cdf-244d54eab5fd@github.com>
References: <s4znWc8WCK3liY8YOhRldnBN7yPJr8m-doBeEArSHd0=.0632ae03-da95-4bd5-865f-e8276544bed5@github.com>
 <jO8_Rg8XVb6CjtA56LiKdFLPBpcVW4pYYeI-u6jQxVc=.6110d5d2-c1c9-4aa5-8cdf-244d54eab5fd@github.com>
Message-ID: <7ThvxIdX5OQ98gW8wZwPjX00teKmjP1qm1DT8olo-30=.64a982f0-92fc-46da-af79-8c3696e99258@github.com>

On Thu, 22 May 2025 21:43:20 GMT, Phil Race <prr at openjdk.org> wrote:

>> Magnus Ihse Bursie has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Restore MenuShortcut.java
>>  - Restore LocaleDataTest.java
>
> src/java.desktop/share/classes/java/awt/MenuShortcut.java line 49:
> 
>> 47:  * For example, a menu shortcut for "Ctrl+cyrillic ef" is created by
>> 48:  * <p>
>> 49:  * <code>MenuShortcut ms = new MenuShortcut(KeyEvent.getExtendedKeyCodeForChar('?'), false);</code>
> 
> This is javadoc inJava SE specification. As is the Action case below.
> I can't think of any actual harm from this change, so OK,  but I am not seeing why it is needed.

The resulting Javadoc html files will contain the same character before and after this fix, so there is no specification change. 

I did this since I thought it increased readability of the source code, but I can just as well revert it.

> test/jdk/java/awt/font/TextLayout/RotFontBoundsTest.java line 63:
> 
>> 61: 
>> 62:     private static final String INSTRUCTIONS =
>> 63:             "A string \u201C" + TEXT + "\u201D is drawn at eight different "
> 
> I really don't like these tests being changed. It isn't part of the JDK build.
> People compile these in all sorts of locales.
> Please revert all the changes in the client tests.

Just a clarification. What I did was convert curly quotes and an em dash to normal ASCII quotes and an ASCII hyphen, just as it is in all other `INSTRUCTIONS` in the tests. This is similar to what was done in JDK-8354273 and JDK-8354213, and should have been made as part of those PRs if I only had noticed this place by then.

The user's locale should not really matter. When have stringent locale requirements for building, and automatically setup the correct locale while building. I don't think the locale will matter at runtime either, but it n the rare case that it should matter, then pure ASCII would be prefer, wouldn't it?

Let me know if you still want me to revert it.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25228#discussion_r2106769659
PR Review Comment: https://git.openjdk.org/jdk/pull/25228#discussion_r2106791184

From ihse at openjdk.org  Mon May 26 08:21:16 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 26 May 2025 08:21:16 GMT
Subject: RFR: 8356977: UTF-8 cleanups [v2]
In-Reply-To: <QDrGzqvDzyZaQMSG3oplXlRSGMmGAMsQPeNnu8G4msU=.5f385862-0ca1-4b20-a31d-0c9e142728b7@github.com>
References: <s4znWc8WCK3liY8YOhRldnBN7yPJr8m-doBeEArSHd0=.0632ae03-da95-4bd5-865f-e8276544bed5@github.com>
 <QDrGzqvDzyZaQMSG3oplXlRSGMmGAMsQPeNnu8G4msU=.5f385862-0ca1-4b20-a31d-0c9e142728b7@github.com>
Message-ID: <_lcOdATdXG3Y_jW5Tl0xJkrVZ-hoWs-2U7Cp3NvQtqk=.eea31f34-72c6-4acd-bce9-38ab18c41509@github.com>

On Mon, 26 May 2025 08:10:19 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> I found a few other places in the code that can be cleaned up after the conversion to UTF-8.
>
> Magnus Ihse Bursie has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Restore MenuShortcut.java
>  - Restore LocaleDataTest.java

test/jdk/java/awt/event/KeyEvent/KeyTyped/EscapeKeyTyped.java line 90:

> 88:                 printKey(e);
> 89:                 int keychar = e.getKeyChar();
> 90:                 if (keychar == 27) { // Escape character is 27 or \u001b

@prrace I think this is an actual bug. `\u0021` codes to `!`, and I don't think that is what was meant. Do you still want me to revert it?

test/jdk/java/awt/print/RemotePrinterStatusRefresh/RemotePrinterStatusRefresh.java line 188:

> 186:                     +          "\"After\" lists.\n"
> 187:                     + "              Added printers are highlighted with "
> 188:                     +               "green color, removed ones \u2014 with "

@prrace This too seems like a bug, or rather a typo. The text currently reads `Added printers are highlighted with green color, removed ones ? with red color.`. The Em dash does not make any sense to me, and seems to be a copy paste error.

Do you still want me to revert it?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25228#discussion_r2106774492
PR Review Comment: https://git.openjdk.org/jdk/pull/25228#discussion_r2106778974

From hannesw at openjdk.org  Mon May 26 16:57:04 2025
From: hannesw at openjdk.org (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=)
Date: Mon, 26 May 2025 16:57:04 GMT
Subject: RFR: 8357796: Stylesheet adjustments after JDK-8357452
Message-ID: <L4k3Fe7FKURlJXvWK3ZZnjxCDInkNjupSqvLhHbG18E=.449a8f72-3edc-4887-a8b3-53622eb78036@github.com>

Please review a simple stylesheet change to adjust for the removal of code span highlights in [JDK-8357452](https://bugs.openjdk.org/browse/JDK-8357452).

Both of the (subtle) changes undone in this PR were introduced with code span highlights and are no longer needed.

-------------

Commit messages:
 - JDK-8357796: Stylesheet adjustments after JDK-8357452

Changes: https://git.openjdk.org/jdk/pull/25454/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25454&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8357796
  Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/25454.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25454/head:pull/25454

PR: https://git.openjdk.org/jdk/pull/25454

From hannesw at openjdk.org  Tue May 27 14:44:06 2025
From: hannesw at openjdk.org (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=)
Date: Tue, 27 May 2025 14:44:06 GMT
Subject: RFR: 8357869: Remove PreviewNote taglet in its current form
Message-ID: <8O-UPcN2nsoo_Q9O07HKK-N6jaC0B4CLC9kJxKF84O4=.8218f638-09cf-47ec-b1d9-d3bb3b794773@github.com>

Please review a change to remove the `PreviewNote` build taglet as it did not pass CSR. This is a partial (build changes) undo of  [JDK-8346109](https://bugs.openjdk.org/browse/JDK-8346109). 

The taglet is planned to be reintroduced at a later date in a redesigned form.

-------------

Commit messages:
 - JDK-8357869: Remove PreviewNote taglet in its current form

Changes: https://git.openjdk.org/jdk/pull/25467/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25467&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8357869
  Stats: 129 lines in 2 files changed: 0 ins; 129 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/25467.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25467/head:pull/25467

PR: https://git.openjdk.org/jdk/pull/25467

From hannesw at openjdk.org  Tue May 27 14:52:58 2025
From: hannesw at openjdk.org (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=)
Date: Tue, 27 May 2025 14:52:58 GMT
Subject: Withdrawn: 8355933: Change section title for permanent APIs affected
 by preview features
In-Reply-To: <SHdEESRjx-smAuXitX4uNMVDhY0gmdMrMjtuk7hWK8Y=.e06e8985-65ed-41cb-9b49-3416953ab9d8@github.com>
References: <SHdEESRjx-smAuXitX4uNMVDhY0gmdMrMjtuk7hWK8Y=.e06e8985-65ed-41cb-9b49-3416953ab9d8@github.com>
Message-ID: <9DaFRZjnWDghtx279ZjxVkrd1ZHp1p33npzPPuQbeSc=.ad14bd85-20c2-45d3-b872-b2f379439f4c@github.com>

On Wed, 14 May 2025 12:01:40 GMT, Hannes Walln?fer <hannesw at openjdk.org> wrote:

> Please review a change of how preview-related notes on permanent APIs are presented in the Preview API page. The section title changes to "Permanent APIs affected by Preview Features", and the section is rendered below the preview API summary tables rather than above.
> 
> In order to show the permanent API notes below the other tables I had to change the way extra content is added to API summary pages. The extra content hook methods we had before always displayed extra content before ordinary API summaries (such as terminally deprecated APIs on the Deprecated API page). The new code replaces these hook methods with methods that generate parts of the page and can be overridden in subclasses to add content before or after the default content.
> 
> I did not structure summary tables into separate preview and permanent API hierarchies as suggested, as that would have made the UI much more complex both visually and functionally.

This pull request has been closed without being integrated.

-------------

PR: https://git.openjdk.org/jdk/pull/25224

From naoto at openjdk.org  Tue May 27 16:37:56 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 27 May 2025 16:37:56 GMT
Subject: RFR: 8356977: UTF-8 cleanups [v2]
In-Reply-To: <lt8vg3M1QU-xbe_E0l4n1j9V9sM_0VsM8kOt11Mk1L0=.d6e6845c-ff78-45f2-8f8e-6a40b9e12ba1@github.com>
References: <s4znWc8WCK3liY8YOhRldnBN7yPJr8m-doBeEArSHd0=.0632ae03-da95-4bd5-865f-e8276544bed5@github.com>
 <5oMrogxJyi1_OsPAGntbPTiR5aCIFOTuDSUTKOv7wyo=.b715c9d2-0cdd-4585-a262-bdbe5a72a5fa@github.com>
 <lt8vg3M1QU-xbe_E0l4n1j9V9sM_0VsM8kOt11Mk1L0=.d6e6845c-ff78-45f2-8f8e-6a40b9e12ba1@github.com>
Message-ID: <rUvIFs4xs4inLQJ40ELv5mF0_MjWmQMrZ5VTSmltBnk=.80b73a56-2930-4ce3-ace5-c25766698954@github.com>

On Mon, 26 May 2025 07:44:30 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> test/jdk/sun/text/resources/LocaleDataTest.java line 106:
>> 
>>> 104:  *        FormatData/fr_FR/MonthNames/0=janvier
>>> 105:  *        FormatData/fr_FR/MonthNames/1=f?vrier
>>> 106:  *        LocaleNames/fr_FR/US=?tats-Unis
>> 
>> This test data (LocaleData.cldr) is explicitly encoded in ISO-8859-1 with unicode escapes for characters outside of it. So only changing these ones in comment does not seem correct.
>
> ISO-8859-1 does not sound good, and got me worried. But in fact it seems like the file is pure ASCII, and that is fine. 
> 
> However, if the file should ever be changed to include actual ISO-8859-1 encoding, this might break if tools assume it is UTF-8-encoding, since not all ISO-8859-1 encodings are valid UTF-8.

Thanks. Filed an issue to change the encoding in the test to UTF-8: https://bugs.openjdk.org/browse/JDK-8357882

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25228#discussion_r2109668481

From erikj at openjdk.org  Tue May 27 19:14:06 2025
From: erikj at openjdk.org (Erik Joelsson)
Date: Tue, 27 May 2025 19:14:06 GMT
Subject: RFR: 8357869: Remove PreviewNote taglet in its current form
In-Reply-To: <8O-UPcN2nsoo_Q9O07HKK-N6jaC0B4CLC9kJxKF84O4=.8218f638-09cf-47ec-b1d9-d3bb3b794773@github.com>
References: <8O-UPcN2nsoo_Q9O07HKK-N6jaC0B4CLC9kJxKF84O4=.8218f638-09cf-47ec-b1d9-d3bb3b794773@github.com>
Message-ID: <thdrqH6jZIVOpmxXgEaILMpCcxA3uGQ3ZC_QPRfveBA=.69c912b7-031e-4ec1-9166-ea0d68a11f85@github.com>

On Tue, 27 May 2025 14:38:53 GMT, Hannes Walln?fer <hannesw at openjdk.org> wrote:

> Please review a change to remove the `PreviewNote` build taglet as it did not pass CSR. This is a partial (build changes) undo of  [JDK-8346109](https://bugs.openjdk.org/browse/JDK-8346109). 
> 
> The taglet is planned to be reintroduced at a later date in a redesigned form.

Marked as reviewed by erikj (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/25467#pullrequestreview-2872285298

From ihse at openjdk.org  Tue May 27 22:41:52 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Tue, 27 May 2025 22:41:52 GMT
Subject: RFR: 8357869: Remove PreviewNote taglet in its current form
In-Reply-To: <8O-UPcN2nsoo_Q9O07HKK-N6jaC0B4CLC9kJxKF84O4=.8218f638-09cf-47ec-b1d9-d3bb3b794773@github.com>
References: <8O-UPcN2nsoo_Q9O07HKK-N6jaC0B4CLC9kJxKF84O4=.8218f638-09cf-47ec-b1d9-d3bb3b794773@github.com>
Message-ID: <04UjdATURCiMYfEnQyr5UmWi5WmL-Cs2CSv5GuxOnJM=.31efecf4-cb4a-4bd3-b997-3de2cab1c5cc@github.com>

On Tue, 27 May 2025 14:38:53 GMT, Hannes Walln?fer <hannesw at openjdk.org> wrote:

> Please review a change to remove the `PreviewNote` build taglet as it did not pass CSR. This is a partial (build changes) undo of  [JDK-8346109](https://bugs.openjdk.org/browse/JDK-8346109). 
> 
> The taglet is planned to be reintroduced at a later date in a redesigned form.

Can you really keep the changes to TestPreview.java from JDK-8346109?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25467#issuecomment-2914346710

From hannesw at openjdk.org  Wed May 28 08:40:06 2025
From: hannesw at openjdk.org (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=)
Date: Wed, 28 May 2025 08:40:06 GMT
Subject: RFR: 8350920: Allow inherited member summaries to be viewed inline
 [v6]
In-Reply-To: <QYJ1xKshpFxGNx4IHFqQjOdIjiVIGbkx86aQ8yBb0sM=.9398f5da-f87c-4bf1-9201-55363f9eecdf@github.com>
References: <dX1QjYZMvLqrR9bS1YLuvpWlXWTcCo56grLUDgh59Pg=.f908cdb2-911a-4ca3-b86e-a07d86a92a6e@github.com>
 <QYJ1xKshpFxGNx4IHFqQjOdIjiVIGbkx86aQ8yBb0sM=.9398f5da-f87c-4bf1-9201-55363f9eecdf@github.com>
Message-ID: <uM1QFgmDKr1gQlgQZF0485o3mnrSXosdcjdRTefUt4Q=.ebd4516e-4fa6-48c2-9933-e521e26b4bcc@github.com>

On Fri, 9 May 2025 15:24:39 GMT, Hannes Walln?fer <hannesw at openjdk.org> wrote:

>> Please review an enhancement to allow switching between the traditional condensed footnote-style summary and the summary table format for inherited members (types, fields, methods and properties) that are inherited from included types. You can test the feature in [the doc bundle I uploaded][apidocs] or watch the short screencast below.
>> 
>> [apidocs]: https://cr.openjdk.org/~hannesw/8350920/api.00/java.base/module-summary.html
>> 
>> https://github.com/user-attachments/assets/0aaa1f8b-c18b-4922-b704-2b2cdc05ca79
>> 
>> I added two new protected methods to the `AbstractMemberWriter` class, `createInheritedSummaryTable` and `getInheritedSummaryId`. Otherwise this is mostly reusing existing functionality (we already had the feature to display the signature of an inherited method in the context of the current class).
>> 
>> The writers for non-inheritable members such as constructors or enum constants were simplified a bit by implementing formerly abstract methods in `AbstractMemberWriter` as concrete methods throwing `UnsupportedOperationException` so they don't have to be implemented as empty methods in these writers.
>> 
>> The UI to switch between member list presentations is implemented in `script.js.template`. If no summary list presentation is available (because the supertype is not part of the documentation bundle) nothing changes in the UI.
>> 
>> I added a `stripTags()` method to `Content` to return the plain text content with HTML tags stripped that could be used in a few other places. The patch also adds two new vector graphics files called right.svg and down.svg for the right and downwards pointing angle.
>
> Hannes Walln?fer has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains eight commits:
> 
>  - Fix test
>  - Merge branch 'master' into JDK-8350920
>  - Merge branch 'master' into JDK-8350920
>  - Review feedback: replace local implementations of Content.stripTags()
>  - Merge branch 'master' into JDK-8350920
>  - Merge branch 'master' into JDK-8350920
>  - Add svg files
>  - 8350920: Allow inherited member summaries to be viewed inline

Deferred to 26

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23967#issuecomment-2915461016

From hannesw at openjdk.org  Wed May 28 08:40:07 2025
From: hannesw at openjdk.org (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=)
Date: Wed, 28 May 2025 08:40:07 GMT
Subject: Withdrawn: 8350920: Allow inherited member summaries to be viewed
 inline
In-Reply-To: <dX1QjYZMvLqrR9bS1YLuvpWlXWTcCo56grLUDgh59Pg=.f908cdb2-911a-4ca3-b86e-a07d86a92a6e@github.com>
References: <dX1QjYZMvLqrR9bS1YLuvpWlXWTcCo56grLUDgh59Pg=.f908cdb2-911a-4ca3-b86e-a07d86a92a6e@github.com>
Message-ID: <cA9tbPw9bi7Rib7-7yq-AJXbkgYFxgUdkj19g7lDLiA=.1a1b6e3d-af81-4e8d-926b-dfa9285ee81b@github.com>

On Mon, 10 Mar 2025 15:41:58 GMT, Hannes Walln?fer <hannesw at openjdk.org> wrote:

> Please review an enhancement to allow switching between the traditional condensed footnote-style summary and the summary table format for inherited members (types, fields, methods and properties) that are inherited from included types. You can test the feature in [the doc bundle I uploaded][apidocs] or watch the short screencast below.
> 
> [apidocs]: https://cr.openjdk.org/~hannesw/8350920/api.00/java.base/module-summary.html
> 
> https://github.com/user-attachments/assets/0aaa1f8b-c18b-4922-b704-2b2cdc05ca79
> 
> I added two new protected methods to the `AbstractMemberWriter` class, `createInheritedSummaryTable` and `getInheritedSummaryId`. Otherwise this is mostly reusing existing functionality (we already had the feature to display the signature of an inherited method in the context of the current class).
> 
> The writers for non-inheritable members such as constructors or enum constants were simplified a bit by implementing formerly abstract methods in `AbstractMemberWriter` as concrete methods throwing `UnsupportedOperationException` so they don't have to be implemented as empty methods in these writers.
> 
> The UI to switch between member list presentations is implemented in `script.js.template`. If no summary list presentation is available (because the supertype is not part of the documentation bundle) nothing changes in the UI.
> 
> I added a `stripTags()` method to `Content` to return the plain text content with HTML tags stripped that could be used in a few other places. The patch also adds two new vector graphics files called right.svg and down.svg for the right and downwards pointing angle.

This pull request has been closed without being integrated.

-------------

PR: https://git.openjdk.org/jdk/pull/23967

From hannesw at openjdk.org  Wed May 28 09:24:53 2025
From: hannesw at openjdk.org (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=)
Date: Wed, 28 May 2025 09:24:53 GMT
Subject: RFR: 8357869: Remove PreviewNote taglet in its current form
In-Reply-To: <04UjdATURCiMYfEnQyr5UmWi5WmL-Cs2CSv5GuxOnJM=.31efecf4-cb4a-4bd3-b997-3de2cab1c5cc@github.com>
References: <8O-UPcN2nsoo_Q9O07HKK-N6jaC0B4CLC9kJxKF84O4=.8218f638-09cf-47ec-b1d9-d3bb3b794773@github.com>
 <04UjdATURCiMYfEnQyr5UmWi5WmL-Cs2CSv5GuxOnJM=.31efecf4-cb4a-4bd3-b997-3de2cab1c5cc@github.com>
Message-ID: <kWXzpVwnceqX_AXuw10r3RX9gGdDwkyyur__HI2r8gM=.d1722a3e-3c59-422b-a499-9f1fbd8f3135@github.com>

On Tue, 27 May 2025 22:38:58 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> Can you really keep the changes to TestPreview.java from JDK-8346109?

Yes, the test does not rely on the JDK build taglet, it uses the javadoc `-tag` option to register a generic tag. More importantly, the internal JavaDoc changes in JDK-8346109 (which were not subject to CSR) include refactorings and improvements which are also required for other issues I'm working on.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25467#issuecomment-2915600389

From hannesw at openjdk.org  Wed May 28 09:49:59 2025
From: hannesw at openjdk.org (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=)
Date: Wed, 28 May 2025 09:49:59 GMT
Subject: Integrated: 8357869: Remove PreviewNote taglet in its current form
In-Reply-To: <8O-UPcN2nsoo_Q9O07HKK-N6jaC0B4CLC9kJxKF84O4=.8218f638-09cf-47ec-b1d9-d3bb3b794773@github.com>
References: <8O-UPcN2nsoo_Q9O07HKK-N6jaC0B4CLC9kJxKF84O4=.8218f638-09cf-47ec-b1d9-d3bb3b794773@github.com>
Message-ID: <pjOEzLZTzTjqQkptP-DeDEOjFcyX8X849UwwY6UoZ_I=.d6491307-1d64-416b-876f-8d720a9691ac@github.com>

On Tue, 27 May 2025 14:38:53 GMT, Hannes Walln?fer <hannesw at openjdk.org> wrote:

> Please review a change to remove the `PreviewNote` build taglet as it did not pass CSR. This is a partial (build changes) undo of  [JDK-8346109](https://bugs.openjdk.org/browse/JDK-8346109). 
> 
> The taglet is planned to be reintroduced at a later date in a redesigned form.

This pull request has now been integrated.

Changeset: 39714b60
Author:    Hannes Walln?fer <hannesw at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/39714b603040f1619f5e0e2a13ea8a90bb993c27
Stats:     129 lines in 2 files changed: 0 ins; 129 del; 0 mod

8357869: Remove PreviewNote taglet in its current form

Reviewed-by: erikj

-------------

PR: https://git.openjdk.org/jdk/pull/25467

From hannesw at openjdk.org  Wed May 28 13:50:00 2025
From: hannesw at openjdk.org (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=)
Date: Wed, 28 May 2025 13:50:00 GMT
Subject: RFR: 8177100: APIs duplicated in JavaDoc [v5]
In-Reply-To: <ElIABs31HAnHeRHN6ig3xhxskyQrnLL3oTyUGKKoAvA=.c6840203-0723-4908-9c40-26fc24272c09@github.com>
References: <0NrLP37RZ6I7ytBxcNyNFReQVvgu-6p_-HbSbHW9ZRM=.c7fd5ae4-8c8d-48ea-8349-5c92a2f78c71@github.com>
 <ElIABs31HAnHeRHN6ig3xhxskyQrnLL3oTyUGKKoAvA=.c6840203-0723-4908-9c40-26fc24272c09@github.com>
Message-ID: <XpuFwpPnp4f3KAF1e5yv8be6JlSYk8UYMtZ-ztp7dCM=.0d77b760-7315-41f7-8cc1-331b709b529f@github.com>

On Mon, 12 May 2025 14:46:39 GMT, Nizar Benalla <nbenalla at openjdk.org> wrote:

>> Please review this patch to fix a bug where a method can be documented multiple times 
>> Consider these 4 classes
>> 
>>                     A       (interface)
>>                    / \
>>                   /   \
>> (abstract class)  C     B   ( interface)
>>                   \   /
>>                    \ /
>>                     D       (class)
>> 
>> 
>> Where `A` declares `testA()`, `C` implements it `public final void testA()`, `B` extends `A` but does *not* override it, `D` extends `C` and implements `B`
>> 
>> In the generated javadoc, `testA()` is documented twice.
>> 
>> ![Screenshot 2025-05-08 at 15 51 19](https://github.com/user-attachments/assets/46538e61-1546-4128-8041-296d8491406f)
>> 
>> After the patch, `testA()` is only documented once:
>> 
>> ![Screenshot 2025-05-08 at 15 52 16](https://github.com/user-attachments/assets/a6b86a21-7104-460c-8f3f-36cee5962eed)
>
> Nizar Benalla has updated the pull request incrementally with one additional commit since the last revision:
> 
>   rename test to be more accurate and simplify code

I have to apologize for my previous review. When I noticed that JDK documentation had changed, my knee-jerk reaction was that the fix was wrong. But it is indeed the current documentation that is wrong. 

For example in [StringBuilder](https://docs.oracle.com/en/java/javase/24/docs/api/java.base/java/lang/StringBuilder.html#methods-inherited-from-class-java.lang.Object), the methods overridden in the hidden `AbstractStringBuilder` class should not be shown as declared in `CharSequence` as they are documented is if they were local methods in `StringBuilder.

Similarly (but without the hidden superclass), the `equals` and `hashCode` methods in [HashMap](https://docs.oracle.com/en/java/javase/24/docs/api/java.base/java/util/HashMap.html#methods-inherited-from-class-java.util.AbstractMap) should not be documented as declared in interface `Map`, but only in `AbstractMap` where they override the default implementation.

So your first solution (in the simplified form) was actually correct after all.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25123#issuecomment-2916427310

From prr at openjdk.org  Wed May 28 20:55:03 2025
From: prr at openjdk.org (Phil Race)
Date: Wed, 28 May 2025 20:55:03 GMT
Subject: RFR: 8356977: UTF-8 cleanups [v2]
In-Reply-To: <_lcOdATdXG3Y_jW5Tl0xJkrVZ-hoWs-2U7Cp3NvQtqk=.eea31f34-72c6-4acd-bce9-38ab18c41509@github.com>
References: <s4znWc8WCK3liY8YOhRldnBN7yPJr8m-doBeEArSHd0=.0632ae03-da95-4bd5-865f-e8276544bed5@github.com>
 <QDrGzqvDzyZaQMSG3oplXlRSGMmGAMsQPeNnu8G4msU=.5f385862-0ca1-4b20-a31d-0c9e142728b7@github.com>
 <_lcOdATdXG3Y_jW5Tl0xJkrVZ-hoWs-2U7Cp3NvQtqk=.eea31f34-72c6-4acd-bce9-38ab18c41509@github.com>
Message-ID: <Dq8Agr8pnvykN7oNGPzTQnNO77rhD_M8j1caxF-mY4M=.867b19b6-ce18-4656-b52b-4fd5ec84d834@github.com>

On Mon, 26 May 2025 07:55:52 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Magnus Ihse Bursie has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Restore MenuShortcut.java
>>  - Restore LocaleDataTest.java
>
> test/jdk/java/awt/event/KeyEvent/KeyTyped/EscapeKeyTyped.java line 90:
> 
>> 88:                 printKey(e);
>> 89:                 int keychar = e.getKeyChar();
>> 90:                 if (keychar == 27) { // Escape character is 27 or \u001b
> 
> @prrace I think this is an actual bug. `\u0021` codes to `!`, and I don't think that is what was meant. Do you still want me to revert it?

You are right, that's a typo. Keep your change.
And I don't know why the code uses literal 27 instead of KeyEvent.VK_ESCAPE .. but that's not your problem.

https://docs.oracle.com/en/java/javase/21/docs/api/constant-values.html#java.awt.event.KeyEvent.VK_ESCAPE

> test/jdk/java/awt/print/RemotePrinterStatusRefresh/RemotePrinterStatusRefresh.java line 188:
> 
>> 186:                     +          "\"After\" lists.\n"
>> 187:                     + "              Added printers are highlighted with "
>> 188:                     +               "green color, removed ones \u2014 with "
> 
> @prrace This too seems like a bug, or rather a typo. The text currently reads `Added printers are highlighted with green color, removed ones ? with red color.`. The Em dash does not make any sense to me, and seems to be a copy paste error.
> 
> Do you still want me to revert it?

I agree. Keep your change.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25228#discussion_r2112722311
PR Review Comment: https://git.openjdk.org/jdk/pull/25228#discussion_r2112731040

From prr at openjdk.org  Wed May 28 20:55:04 2025
From: prr at openjdk.org (Phil Race)
Date: Wed, 28 May 2025 20:55:04 GMT
Subject: RFR: 8356977: UTF-8 cleanups [v2]
In-Reply-To: <7ThvxIdX5OQ98gW8wZwPjX00teKmjP1qm1DT8olo-30=.64a982f0-92fc-46da-af79-8c3696e99258@github.com>
References: <s4znWc8WCK3liY8YOhRldnBN7yPJr8m-doBeEArSHd0=.0632ae03-da95-4bd5-865f-e8276544bed5@github.com>
 <jO8_Rg8XVb6CjtA56LiKdFLPBpcVW4pYYeI-u6jQxVc=.6110d5d2-c1c9-4aa5-8cdf-244d54eab5fd@github.com>
 <7ThvxIdX5OQ98gW8wZwPjX00teKmjP1qm1DT8olo-30=.64a982f0-92fc-46da-af79-8c3696e99258@github.com>
Message-ID: <BW-jmv0CMo_qRngDZcLpY3s8yH_WYkD_YyhGiDyDeVU=.5292f832-a0ab-4a8f-9792-6c8005697e45@github.com>

On Mon, 26 May 2025 08:07:19 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> test/jdk/java/awt/font/TextLayout/RotFontBoundsTest.java line 63:
>> 
>>> 61: 
>>> 62:     private static final String INSTRUCTIONS =
>>> 63:             "A string \u201C" + TEXT + "\u201D is drawn at eight different "
>> 
>> I really don't like these tests being changed. It isn't part of the JDK build.
>> People compile these in all sorts of locales.
>> Please revert all the changes in the client tests.
>
> Just a clarification. What I did was convert curly quotes and an em dash to normal ASCII quotes and an ASCII hyphen, just as it is in all other `INSTRUCTIONS` in the tests. This is similar to what was done in JDK-8354273 and JDK-8354213, and should have been made as part of those PRs if I only had noticed this place by then.
> 
> The user's locale should not really matter. When have stringent locale requirements for building, and automatically setup the correct locale while building. I don't think the locale will matter at runtime either, but it n the rare case that it should matter, then pure ASCII would be prefer, wouldn't it?
> 
> Let me know if you still want me to revert it.

I'd like this reverted.
People *build* these tests in their local repos using javac and whatever their locale is.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25228#discussion_r2112728971

From jlahoda at openjdk.org  Thu May 29 08:54:54 2025
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Thu, 29 May 2025 08:54:54 GMT
Subject: RFR: 8357458: Missing Highlight.js license file [v2]
In-Reply-To: <mE8OyD-p_w9dycsYfMhbBlCoNAfur3zduTcI_qMjV_k=.c0060a4b-e794-4199-896c-99af3eb4bcd4@github.com>
References: <sdYdoeEnTocJ1HskRPb3vIi2CGlS3C69YnjHLhxRdi0=.6c996437-ebfe-40bc-9297-8f9f8011d435@github.com>
 <mE8OyD-p_w9dycsYfMhbBlCoNAfur3zduTcI_qMjV_k=.c0060a4b-e794-4199-896c-99af3eb4bcd4@github.com>
Message-ID: <xKsmImjCk8JWKWUKEgsEXrAQu2ORBuNAikD4O08HN2M=.2c7e2351-3a93-440a-afaa-dfe4b82c2470@github.com>

On Wed, 21 May 2025 20:05:08 GMT, Hannes Walln?fer <hannesw at openjdk.org> wrote:

>> Please review a change to add the missing license file for [Highlight.js](https://github.com/highlightjs/highlight.js) required for the `--syntax-highlight` option. This also updates the tests for legal files and library versions to handle the file correctly.
>
> Hannes Walln?fer has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Capitalize license heading

Looks good to me.

-------------

Marked as reviewed by jlahoda (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25352#pullrequestreview-2877575595

From hannesw at openjdk.org  Thu May 29 09:21:57 2025
From: hannesw at openjdk.org (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=)
Date: Thu, 29 May 2025 09:21:57 GMT
Subject: Integrated: 8357458: Missing Highlight.js license file
In-Reply-To: <sdYdoeEnTocJ1HskRPb3vIi2CGlS3C69YnjHLhxRdi0=.6c996437-ebfe-40bc-9297-8f9f8011d435@github.com>
References: <sdYdoeEnTocJ1HskRPb3vIi2CGlS3C69YnjHLhxRdi0=.6c996437-ebfe-40bc-9297-8f9f8011d435@github.com>
Message-ID: <XWKog5byLa_Raaji4EdnhyzYj1mfxoW0VkJqVF16Au4=.a15a70ab-dc36-4b27-9c92-aebd14d7f16e@github.com>

On Wed, 21 May 2025 12:37:03 GMT, Hannes Walln?fer <hannesw at openjdk.org> wrote:

> Please review a change to add the missing license file for [Highlight.js](https://github.com/highlightjs/highlight.js) required for the `--syntax-highlight` option. This also updates the tests for legal files and library versions to handle the file correctly.

This pull request has now been integrated.

Changeset: a2743bab
Author:    Hannes Walln?fer <hannesw at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/a2743bab4fd203b0791cf47e617c1a95b05ab3cc
Stats:     69 lines in 4 files changed: 51 ins; 0 del; 18 mod

8357458: Missing Highlight.js license file

Reviewed-by: jlahoda

-------------

PR: https://git.openjdk.org/jdk/pull/25352

From weijun at openjdk.org  Thu May 29 17:07:58 2025
From: weijun at openjdk.org (Weijun Wang)
Date: Thu, 29 May 2025 17:07:58 GMT
Subject: RFR: 8357796: Stylesheet adjustments after JDK-8357452
In-Reply-To: <L4k3Fe7FKURlJXvWK3ZZnjxCDInkNjupSqvLhHbG18E=.449a8f72-3edc-4887-a8b3-53622eb78036@github.com>
References: <L4k3Fe7FKURlJXvWK3ZZnjxCDInkNjupSqvLhHbG18E=.449a8f72-3edc-4887-a8b3-53622eb78036@github.com>
Message-ID: <e4DcUXQsFYQTqG1joEXaxR5pq18INeladwdKK12qVr8=.a9786aa1-a356-4e80-ac7a-53a53474a3bd@github.com>

On Mon, 26 May 2025 16:52:13 GMT, Hannes Walln?fer <hannesw at openjdk.org> wrote:

> Please review a simple stylesheet change to adjust for the removal of code span highlights in [JDK-8357452](https://bugs.openjdk.org/browse/JDK-8357452).
> 
> Both of the (subtle) changes undone in this PR were introduced with code span highlights and are no longer needed.

I wish there were screenshots showing what has changed.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25454#issuecomment-2920026799

From rriggs at openjdk.org  Thu May 29 17:16:50 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Thu, 29 May 2025 17:16:50 GMT
Subject: RFR: 8357796: Stylesheet adjustments after JDK-8357452
In-Reply-To: <L4k3Fe7FKURlJXvWK3ZZnjxCDInkNjupSqvLhHbG18E=.449a8f72-3edc-4887-a8b3-53622eb78036@github.com>
References: <L4k3Fe7FKURlJXvWK3ZZnjxCDInkNjupSqvLhHbG18E=.449a8f72-3edc-4887-a8b3-53622eb78036@github.com>
Message-ID: <KX8CgKdG4nzdykozmbkOU0oHkns8bEGcPlFgKvHB49I=.701c42ab-53a3-4b6f-a3b8-fcb35711fe3c@github.com>

On Mon, 26 May 2025 16:52:13 GMT, Hannes Walln?fer <hannesw at openjdk.org> wrote:

> Please review a simple stylesheet change to adjust for the removal of code span highlights in [JDK-8357452](https://bugs.openjdk.org/browse/JDK-8357452).
> 
> Both of the (subtle) changes undone in this PR were introduced with code span highlights and are no longer needed.

Looks ok, it would be good to have another reviewer.

-------------

Marked as reviewed by rriggs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25454#pullrequestreview-2879029940

From prr at openjdk.org  Thu May 29 19:08:54 2025
From: prr at openjdk.org (Phil Race)
Date: Thu, 29 May 2025 19:08:54 GMT
Subject: RFR: 8356977: UTF-8 cleanups [v2]
In-Reply-To: <QDrGzqvDzyZaQMSG3oplXlRSGMmGAMsQPeNnu8G4msU=.5f385862-0ca1-4b20-a31d-0c9e142728b7@github.com>
References: <s4znWc8WCK3liY8YOhRldnBN7yPJr8m-doBeEArSHd0=.0632ae03-da95-4bd5-865f-e8276544bed5@github.com>
 <QDrGzqvDzyZaQMSG3oplXlRSGMmGAMsQPeNnu8G4msU=.5f385862-0ca1-4b20-a31d-0c9e142728b7@github.com>
Message-ID: <dVw-4Yl3AI2y1kYAwY1rgjjRrqCSiIVv2UN-UHuJtB0=.81a20509-7795-4ad7-b7c9-f42970d65318@github.com>

On Mon, 26 May 2025 08:20:19 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> I found a few other places in the code that can be cleaned up after the conversion to UTF-8.
>
> Magnus Ihse Bursie has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Restore MenuShortcut.java
>  - Restore LocaleDataTest.java

Approving client changes

-------------

Marked as reviewed by prr (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25228#pullrequestreview-2879326497

From mbaesken at openjdk.org  Fri May 30 09:56:04 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Fri, 30 May 2025 09:56:04 GMT
Subject: RFR: 8358136: Make
 langtools/jdk/javadoc/doclet/testLinkOption/TestRedirectLinks.java
 intermittent
Message-ID: <ngpvzxYtSAnoIl-BHFrfhhjq5JWTUspQ49I9LY0efBc=.633adceb-d094-41b0-bd1a-4b0cc6ce426c@github.com>

Make langtools/jdk/javadoc/doclet/testLinkOption/TestRedirectLinks.java intermittent, add the respective keyword.
The test fails sometimes, see e.g. JDK-8338439 .

-------------

Commit messages:
 - JDK-8358136

Changes: https://git.openjdk.org/jdk/pull/25540/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25540&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8358136
  Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/25540.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25540/head:pull/25540

PR: https://git.openjdk.org/jdk/pull/25540

From jpai at openjdk.org  Fri May 30 10:17:52 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Fri, 30 May 2025 10:17:52 GMT
Subject: RFR: 8358136: Make
 langtools/jdk/javadoc/doclet/testLinkOption/TestRedirectLinks.java
 intermittent
In-Reply-To: <ngpvzxYtSAnoIl-BHFrfhhjq5JWTUspQ49I9LY0efBc=.633adceb-d094-41b0-bd1a-4b0cc6ce426c@github.com>
References: <ngpvzxYtSAnoIl-BHFrfhhjq5JWTUspQ49I9LY0efBc=.633adceb-d094-41b0-bd1a-4b0cc6ce426c@github.com>
Message-ID: <48kuSnOEf3Y6PxLr3iWKoXzEtwDHiHmZbbQpvnLNKVY=.822dc047-7b43-42c7-a79b-7447296d11a7@github.com>

On Fri, 30 May 2025 09:51:23 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> Make langtools/jdk/javadoc/doclet/testLinkOption/TestRedirectLinks.java intermittent, add the respective keyword.
> The test fails sometimes, see e.g. JDK-8338439 .

Looks OK and trivial to me.

-------------

Marked as reviewed by jpai (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25540#pullrequestreview-2880863301

From nbenalla at openjdk.org  Fri May 30 17:00:50 2025
From: nbenalla at openjdk.org (Nizar Benalla)
Date: Fri, 30 May 2025 17:00:50 GMT
Subject: RFR: 8358136: Make
 langtools/jdk/javadoc/doclet/testLinkOption/TestRedirectLinks.java
 intermittent
In-Reply-To: <ngpvzxYtSAnoIl-BHFrfhhjq5JWTUspQ49I9LY0efBc=.633adceb-d094-41b0-bd1a-4b0cc6ce426c@github.com>
References: <ngpvzxYtSAnoIl-BHFrfhhjq5JWTUspQ49I9LY0efBc=.633adceb-d094-41b0-bd1a-4b0cc6ce426c@github.com>
Message-ID: <uBbWdpGEZQJCHsX3p7IRBLg4gjBu0Y7lwNVxVV9laGI=.3a0c148f-9b30-492e-a105-f0854c97b994@github.com>

On Fri, 30 May 2025 09:51:23 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> Make langtools/jdk/javadoc/doclet/testLinkOption/TestRedirectLinks.java intermittent, add the respective keyword.
> The test fails sometimes, see e.g. JDK-8338439 .

Code change makes sense.

-------------

Marked as reviewed by nbenalla (Committer).

PR Review: https://git.openjdk.org/jdk/pull/25540#pullrequestreview-2881910176

From syan at openjdk.org  Sat May 31 03:45:55 2025
From: syan at openjdk.org (SendaoYan)
Date: Sat, 31 May 2025 03:45:55 GMT
Subject: RFR: 8358136: Make
 langtools/jdk/javadoc/doclet/testLinkOption/TestRedirectLinks.java
 intermittent
In-Reply-To: <ngpvzxYtSAnoIl-BHFrfhhjq5JWTUspQ49I9LY0efBc=.633adceb-d094-41b0-bd1a-4b0cc6ce426c@github.com>
References: <ngpvzxYtSAnoIl-BHFrfhhjq5JWTUspQ49I9LY0efBc=.633adceb-d094-41b0-bd1a-4b0cc6ce426c@github.com>
Message-ID: <aOSUYu5HqYSy5SJHNHNaev1O1ZTr8Kr0NVLVXthGLJs=.34134c42-103f-4455-b44b-761c9c57cadf@github.com>

On Fri, 30 May 2025 09:51:23 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> Make langtools/jdk/javadoc/doclet/testLinkOption/TestRedirectLinks.java intermittent, add the respective keyword.
> The test fails sometimes, see e.g. JDK-8338439 .

Marked as reviewed by syan (Committer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/25540#pullrequestreview-2883256159