From lkorinth at openjdk.org Mon Sep 1 08:07:48 2025 From: lkorinth at openjdk.org (Leo Korinth) Date: Mon, 1 Sep 2025 08:07:48 GMT Subject: RFR: 8260555: Change the default TIMEOUT_FACTOR from 4 to 1 [v8] In-Reply-To: References: Message-ID: <1SVkL88-a7Es6cosezvIjvZ63F4nv-2Kut2oKG27Eo8=.f2e2a083-b51d-4df9-ab6e-ec324467ebb9@github.com> > This changes the timeout factor from 4 to 1. Most of the changes add timeouts to individual test cases so that I am able to run them with a timeout factor of 0.7 (some margin to the checked in factor of one) > > In addition to changing the timeout factor, I am also using a library call to parse the timeout factor from the Java properties (I cannot use the library function everywhere as jtreg does not allow me to add @library notations to non test case files). > > My approach has been to run all tests, and afterwards updating those that fail due to the timeout factor. The amount of updated test cases is huge, and my strategy has been to quadruple the timeout if I could not directly see that less was needed. 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 ploughed through test cases: > 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 > > After the review, I will update the copyrights. > > I have run testing tier1-8. The last time with a timeout factor of 1 instead of 0.7. > > I got 4 timing related faults: > 1) runtime/Thread/TestThreadDumpMonitorContention.java > This is probably: https://bugs.openjdk.org/browse/JDK-8361370 > 2) sun/tools/jhsdb/BasicLauncherTest.java > I am unsure about this one, it has not failed on my runs before, even with a timeout factor of 0.7, maybe I was unlucky. > 3) gc/stress/TestReclaimStringsLeaksMemory.java > I updated this to 480 seconds, I finish this fairly fast (~14s) on my not very fast computer, but the Macs that fail are old x86-based ones. > 4) sun/security/ssl/X509KeyManager/CertChecking.java > This is a new test that I got on last rebase. I have added a timeout of 480 to it. > > In addition to these four tests, I have another one "java/lang/ThreadLocal/MemoryLeak.java" that earlier failed with a timeout factor of 0.7 but did not fail in the last run. I will *not* update that test case, because the extra time spent is strange and should be looked at. I have created JDK-8352074 on that test case, and I will probably create another bug describing the timeout I got. > > From the review of the cancelled "8356171: Increase timeout for test cases as preparation for change of... Leo Korinth 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 10 additional commits since the last revision: - new timeouts - Merge branch '_master_jdk' into _8260555 - update copyright - revert added timeout, it is not needed - feedback from Mark Sheppard - update testing.md, remove makefile link, fix bad text - after suggestion from Daniel - added extra timeout for: jdk/internal/vm/Continuation/BasicExt.java#COMP_WINDOW_LENGTH_{1-3}-GC_AFTER_YIELD - After suggestions from Erik and Andrey - 8260555: Change the default TIMEOUT_FACTOR from 4 to 1 ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26749/files - new: https://git.openjdk.org/jdk/pull/26749/files/4b33904a..7ca719c8 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26749&range=07 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26749&range=06-07 Stats: 37788 lines in 1054 files changed: 23834 ins; 9562 del; 4392 mod Patch: https://git.openjdk.org/jdk/pull/26749.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26749/head:pull/26749 PR: https://git.openjdk.org/jdk/pull/26749 From lkorinth at openjdk.org Mon Sep 1 13:21:49 2025 From: lkorinth at openjdk.org (Leo Korinth) Date: Mon, 1 Sep 2025 13:21:49 GMT Subject: RFR: 8260555: Change the default TIMEOUT_FACTOR from 4 to 1 [v9] In-Reply-To: References: Message-ID: > This changes the timeout factor from 4 to 1. Most of the changes add timeouts to individual test cases so that I am able to run them with a timeout factor of 0.7 (some margin to the checked in factor of one) > > In addition to changing the timeout factor, I am also using a library call to parse the timeout factor from the Java properties (I cannot use the library function everywhere as jtreg does not allow me to add @library notations to non test case files). > > My approach has been to run all tests, and afterwards updating those that fail due to the timeout factor. The amount of updated test cases is huge, and my strategy has been to quadruple the timeout if I could not directly see that less was needed. 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 ploughed through test cases: > 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 > > After the review, I will update the copyrights. > > I have run testing tier1-8. The last time with a timeout factor of 1 instead of 0.7. > > I got 4 timing related faults: > 1) runtime/Thread/TestThreadDumpMonitorContention.java > This is probably: https://bugs.openjdk.org/browse/JDK-8361370 > 2) sun/tools/jhsdb/BasicLauncherTest.java > I am unsure about this one, it has not failed on my runs before, even with a timeout factor of 0.7, maybe I was unlucky. > 3) gc/stress/TestReclaimStringsLeaksMemory.java > I updated this to 480 seconds, I finish this fairly fast (~14s) on my not very fast computer, but the Macs that fail are old x86-based ones. > 4) sun/security/ssl/X509KeyManager/CertChecking.java > This is a new test that I got on last rebase. I have added a timeout of 480 to it. > > In addition to these four tests, I have another one "java/lang/ThreadLocal/MemoryLeak.java" that earlier failed with a timeout factor of 0.7 but did not fail in the last run. I will *not* update that test case, because the extra time spent is strange and should be looked at. I have created JDK-8352074 on that test case, and I will probably create another bug describing the timeout I got. > > From the review of the cancelled "8356171: Increase timeout for test cases as preparation for change of... Leo Korinth has updated the pull request incrementally with one additional commit since the last revision: changed both test in GetStackTraceALotWhenBlocking to use timeout of 1200 ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26749/files - new: https://git.openjdk.org/jdk/pull/26749/files/7ca719c8..5c0bcd19 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26749&range=08 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26749&range=07-08 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/26749.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26749/head:pull/26749 PR: https://git.openjdk.org/jdk/pull/26749 From alanb at openjdk.org Mon Sep 1 13:55:46 2025 From: alanb at openjdk.org (Alan Bateman) Date: Mon, 1 Sep 2025 13:55:46 GMT Subject: RFR: 8260555: Change the default TIMEOUT_FACTOR from 4 to 1 [v9] In-Reply-To: References: Message-ID: On Mon, 1 Sep 2025 13:21:49 GMT, Leo Korinth wrote: >> This changes the timeout factor from 4 to 1. Most of the changes add timeouts to individual test cases so that I am able to run them with a timeout factor of 0.7 (some margin to the checked in factor of one) >> >> In addition to changing the timeout factor, I am also using a library call to parse the timeout factor from the Java properties (I cannot use the library function everywhere as jtreg does not allow me to add @library notations to non test case files). >> >> My approach has been to run all tests, and afterwards updating those that fail due to the timeout factor. The amount of updated test cases is huge, and my strategy has been to quadruple the timeout if I could not directly see that less was needed. 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 ploughed through test cases: >> 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 >> >> After the review, I will update the copyrights. >> >> I have run testing tier1-8. The last time with a timeout factor of 1 instead of 0.7. >> >> I got 4 timing related faults: >> 1) runtime/Thread/TestThreadDumpMonitorContention.java >> This is probably: https://bugs.openjdk.org/browse/JDK-8361370 >> 2) sun/tools/jhsdb/BasicLauncherTest.java >> I am unsure about this one, it has not failed on my runs before, even with a timeout factor of 0.7, maybe I was unlucky. >> 3) gc/stress/TestReclaimStringsLeaksMemory.java >> I updated this to 480 seconds, I finish this fairly fast (~14s) on my not very fast computer, but the Macs that fail are old x86-based ones. >> 4) sun/security/ssl/X509KeyManager/CertChecking.java >> This is a new test that I got on last rebase. I have added a timeout of 480 to it. >> >> In addition to these four tests, I have another one "java/lang/ThreadLocal/MemoryLeak.java" that earlier failed with a timeout factor of 0.7 but did not fail in the last run. I will *not* update that test case, because the extra time spent is strange and should be looked at. I have created JDK-8352074 on that test case, and I will probably create another bug describing the timeout I got. >> >> From the review of the cancelled "8356171: ... > > Leo Korinth has updated the pull request incrementally with one additional commit since the last revision: > > changed both test in GetStackTraceALotWhenBlocking to use timeout of 1200 Marked as reviewed by alanb (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/26749#pullrequestreview-3173774701 From lkorinth at openjdk.org Mon Sep 1 16:00:47 2025 From: lkorinth at openjdk.org (Leo Korinth) Date: Mon, 1 Sep 2025 16:00:47 GMT Subject: RFR: 8260555: Change the default TIMEOUT_FACTOR from 4 to 1 [v5] In-Reply-To: References: Message-ID: <9X-5PBm7G1Y8vJ8bw02E501aWdgleLyUWMk3nhSrF08=.bb490a54-e687-49cc-9ecc-df7c051eef18@github.com> On Fri, 22 Aug 2025 15:46:18 GMT, Albert Mingkun Yang wrote: >> Leo Korinth has updated the pull request incrementally with one additional commit since the last revision: >> >> update testing.md, remove makefile link, fix bad text > > test/hotspot/jtreg/serviceability/jvmti/vthread/SuspendResume2/SuspendResume2.java line 31: > >> 29: * @compile SuspendResume2.java >> 30: * @run driver jdk.test.lib.FileInstaller . . >> 31: * @run main/othervm/native/timeout=700 > > Why `700` instead of `480` in this file? I think this is one of the earlier tests that failed with a timeout factor of `0.7` on 480. Later on I doubled it, but here I was a bit more conservative. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26749#discussion_r2314279387 From lkorinth at openjdk.org Mon Sep 1 16:09:44 2025 From: lkorinth at openjdk.org (Leo Korinth) Date: Mon, 1 Sep 2025 16:09:44 GMT Subject: RFR: 8260555: Change the default TIMEOUT_FACTOR from 4 to 1 [v5] In-Reply-To: References: Message-ID: On Mon, 25 Aug 2025 13:48:10 GMT, Albert Mingkun Yang wrote: >> It is a way to give a "4x" lowest value, while not multiplying a 10x factor with four resulting in a 40x factor. I think (but I am not sure) that it would sometime time out if I only used the given timeout factor and not "guarding" with the max(x, 4). > >> while not multiplying a 10x factor with four resulting in a 40x factor. > > Why is that undesirable? The base is `(HOLD_TARGET_TIME + 30000) * 4` and the timeout-factor changes that linearly. Using `max(..., 4)` here may come as a surprise to end users, IMO. Because 40x is a very large timeout factor. I think I might misunderstand you in some way. My change is conservative, and will give a timeout that is not smaller than before (but can be larger if an explicit (non-default) timeout factor less than 4 was used before). Does that make sense, or do I answer something different from what you are asking? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26749#discussion_r2314295263 From lkorinth at openjdk.org Tue Sep 2 07:29:57 2025 From: lkorinth at openjdk.org (Leo Korinth) Date: Tue, 2 Sep 2025 07:29:57 GMT Subject: Integrated: 8260555: Change the default TIMEOUT_FACTOR from 4 to 1 In-Reply-To: References: Message-ID: On Tue, 12 Aug 2025 17:01:41 GMT, Leo Korinth wrote: > This changes the timeout factor from 4 to 1. Most of the changes add timeouts to individual test cases so that I am able to run them with a timeout factor of 0.7 (some margin to the checked in factor of one) > > In addition to changing the timeout factor, I am also using a library call to parse the timeout factor from the Java properties (I cannot use the library function everywhere as jtreg does not allow me to add @library notations to non test case files). > > My approach has been to run all tests, and afterwards updating those that fail due to the timeout factor. The amount of updated test cases is huge, and my strategy has been to quadruple the timeout if I could not directly see that less was needed. 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 ploughed through test cases: > 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 > > After the review, I will update the copyrights. > > I have run testing tier1-8. The last time with a timeout factor of 1 instead of 0.7. > > I got 4 timing related faults: > 1) runtime/Thread/TestThreadDumpMonitorContention.java > This is probably: https://bugs.openjdk.org/browse/JDK-8361370 > 2) sun/tools/jhsdb/BasicLauncherTest.java > I am unsure about this one, it has not failed on my runs before, even with a timeout factor of 0.7, maybe I was unlucky. > 3) gc/stress/TestReclaimStringsLeaksMemory.java > I updated this to 480 seconds, I finish this fairly fast (~14s) on my not very fast computer, but the Macs that fail are old x86-based ones. > 4) sun/security/ssl/X509KeyManager/CertChecking.java > This is a new test that I got on last rebase. I have added a timeout of 480 to it. > > In addition to these four tests, I have another one "java/lang/ThreadLocal/MemoryLeak.java" that earlier failed with a timeout factor of 0.7 but did not fail in the last run. I will *not* update that test case, because the extra time spent is strange and should be looked at. I have created JDK-8352074 on that test case, and I will probably create another bug describing the timeout I got. > > From the review of the cancelled "8356171: Increase timeout for test cases as preparation for change of... This pull request has now been integrated. Changeset: 55e7af05 Author: Leo Korinth URL: https://git.openjdk.org/jdk/commit/55e7af0560335ef69af072cee60956cf8e6d00a1 Stats: 901 lines in 342 files changed: 51 ins; 91 del; 759 mod 8260555: Change the default TIMEOUT_FACTOR from 4 to 1 Reviewed-by: alanb, sspitsyn, lmesnik, ihse ------------- PR: https://git.openjdk.org/jdk/pull/26749 From davidalayachew at gmail.com Mon Sep 1 17:24:32 2025 From: davidalayachew at gmail.com (David Alayachew) Date: Mon, 1 Sep 2025 13:24:32 -0400 Subject: Some feedback on Search Results Page Message-ID: Hello @javadoc-dev at openjdk.org , If I click "Search" on the top left of Java 24 Javadoc, and then when the page loads, I type in "Subtask", it returns "StructuredTaskScope.Subtask" with blue text. Here is a screenshot. [image: image.png] But if I do the same for Java 25 EA, not only is the columns different, but the text color for the Class Name has changed from Blue to Black. Here is a screenshot. [image: image.png] It is also the same for Java 26 EA. Here is a screenshot. [image: image.png] There's definitely some tradeoffs I can see. For example, I can now see from a glance if it's an interface, a class, an enum, etc. But on the other hand, the "Description" column smushes 2 separate pieces of data together -- class type and package. I would much prefer that these be 2 separate columns, for a total of 3. I also would like it if we could go back to having packages on the left, vs the right. I understand that the class name is what people care about, but since fully qualified names of classes start with packages, then I think it also makes sense to have the packages be the first column. We can keep class type (interface, enum, Exception, etc) as the 3rd column. Finally, can we go back to the blue text? Blue is a nice signifier -- I see blue, and I think hyperlinks. It kind of leads me into right-clicking to open in a new tab, and since the blue pops out compared to the black, my eyes naturally gravitate towards it, making it easier for me to find what I need. These are just a few suggestions from trying out the Java 25 Javadoc over a period of time. I like it, but think it can be better. Thank you for your time and help. David Alayachew -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image.png Type: image/png Size: 59219 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image.png Type: image/png Size: 57496 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image.png Type: image/png Size: 59911 bytes Desc: not available URL: From davidalayachew at gmail.com Mon Sep 1 17:35:42 2025 From: davidalayachew at gmail.com (David Alayachew) Date: Mon, 1 Sep 2025 13:35:42 -0400 Subject: Some feedback on Search Results Page In-Reply-To: References: Message-ID: May also want a 4th column for module, but that's less important. Maybe makes sense to put that behind a toggle. And I want to emphasize, of these suggestions, the splitting up of Description is the most important. That just makes my searching experience more taxing, as the horizontal position of a package name is slightly different for each line, making reading harder. On Mon, Sep 1, 2025 at 1:24?PM David Alayachew wrote: > Hello @javadoc-dev at openjdk.org , > > If I click "Search" on the top left of Java 24 Javadoc, and then when the > page loads, I type in "Subtask", it returns "StructuredTaskScope.Subtask" > with blue text. Here is a screenshot. > > [image: image.png] > > But if I do the same for Java 25 EA, not only is the columns different, > but the text color for the Class Name has changed from Blue to Black. Here > is a screenshot. > > > [image: image.png] > > It is also the same for Java 26 EA. Here is a screenshot. > > [image: image.png] > > There's definitely some tradeoffs I can see. > > For example, I can now see from a glance if it's an interface, a class, an > enum, etc. > > But on the other hand, the "Description" column smushes 2 separate pieces > of data together -- class type and package. I would much prefer that these > be 2 separate columns, for a total of 3. > > I also would like it if we could go back to having packages on the left, > vs the right. I understand that the class name is what people care about, > but since fully qualified names of classes start with packages, then I > think it also makes sense to have the packages be the first column. We can > keep class type (interface, enum, Exception, etc) as the 3rd column. > > Finally, can we go back to the blue text? Blue is a nice signifier -- I > see blue, and I think hyperlinks. It kind of leads me into right-clicking > to open in a new tab, and since the blue pops out compared to the black, my > eyes naturally gravitate towards it, making it easier for me to find what I > need. > > These are just a few suggestions from trying out the Java 25 Javadoc over > a period of time. I like it, but think it can be better. > > Thank you for your time and help. > David Alayachew > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image.png Type: image/png Size: 59219 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image.png Type: image/png Size: 57496 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image.png Type: image/png Size: 59911 bytes Desc: not available URL: From hannes.wallnoefer at oracle.com Tue Sep 2 10:34:42 2025 From: hannes.wallnoefer at oracle.com (Hannes Wallnoefer) Date: Tue, 2 Sep 2025 10:34:42 +0000 Subject: Intermediate Doc Format In-Reply-To: References: Message-ID: <20A26B34-653B-4E1F-8DFD-9780DDD43A5D@oracle.com> Hi Ethan, JavaDoc does support different output formats through the Doclet interface. https://docs.oracle.com/en/java/javase/24/docs/api/jdk.javadoc/jdk/javadoc/doclet/package-summary.html#package-description https://docs.oracle.com/en/java/javase/24/docs/api/jdk.javadoc/jdk/javadoc/doclet/Doclet.html So what you describe should be possible to do with JavaDoc. Hannes On 20.08.2025, at 15:20, Ethan McCue wrote: Apologies in advance for the shallowness of thought. Javadoc takes as input sources and produces as output html. When you get the docs for your JDK it comes with a nice index page documenting all the modules within. https://docs.oracle.com/en/java/javase/24/docs/api/index.html When you make docs for a library, however, it starts to get a lot more split up. Is it at all feasible for javadoc to not produce html as its output but to instead produce a serialized representation of the doc-info extracted from sources? So instead of running javadoc on all the sources in the jdk and then in libraries you could have jmods java.base.jmod/ classes/ ... ... docs/ java.base.docinfo.json other.library/ ... docs/ other.library.docinfo.json And as part of a linkage step produce one mega page with all the javadoc info from all the libraries you are using. -------------- next part -------------- An HTML attachment was scrubbed... URL: From hannes.wallnoefer at oracle.com Tue Sep 2 10:59:52 2025 From: hannes.wallnoefer at oracle.com (Hannes Wallnoefer) Date: Tue, 2 Sep 2025 10:59:52 +0000 Subject: Some feedback on Search Results Page In-Reply-To: References: Message-ID: Thanks for the feedback, David. The main objective for the updated search page in JDK 25 was to make it possible to navigate search results by keyboard (using tab, arrow and return keys). That?s also the reason search results are no longer displayed as blue links. Now the whole result row is the link, which allows you to click anywhere in the row (it still works with right-click and open in new tab). The reorganisation of table columns and content is due to alignment with the navigation bar search field on other pages, which now uses the same two-column format. It used to use a single column format containing only the fully qualified name. As you say, it?s all about tradeoffs. A fully qualified name (or something resembling it) may be quicker to read. The new layout provides more information, and IMO it?s also more aesthetically pleasing, although that?s certainly subjective. I?m open to changes if there?s a clear trend in feedback. Hannes On 01.09.2025, at 19:35, David Alayachew wrote: May also want a 4th column for module, but that's less important. Maybe makes sense to put that behind a toggle. And I want to emphasize, of these suggestions, the splitting up of Description is the most important. That just makes my searching experience more taxing, as the horizontal position of a package name is slightly different for each line, making reading harder. On Mon, Sep 1, 2025 at 1:24?PM David Alayachew > wrote: Hello @javadoc-dev at openjdk.org, If I click "Search" on the top left of Java 24 Javadoc, and then when the page loads, I type in "Subtask", it returns "StructuredTaskScope.Subtask" with blue text. Here is a screenshot. But if I do the same for Java 25 EA, not only is the columns different, but the text color for the Class Name has changed from Blue to Black. Here is a screenshot. It is also the same for Java 26 EA. Here is a screenshot. There's definitely some tradeoffs I can see. For example, I can now see from a glance if it's an interface, a class, an enum, etc. But on the other hand, the "Description" column smushes 2 separate pieces of data together -- class type and package. I would much prefer that these be 2 separate columns, for a total of 3. I also would like it if we could go back to having packages on the left, vs the right. I understand that the class name is what people care about, but since fully qualified names of classes start with packages, then I think it also makes sense to have the packages be the first column. We can keep class type (interface, enum, Exception, etc) as the 3rd column. Finally, can we go back to the blue text? Blue is a nice signifier -- I see blue, and I think hyperlinks. It kind of leads me into right-clicking to open in a new tab, and since the blue pops out compared to the black, my eyes naturally gravitate towards it, making it easier for me to find what I need. These are just a few suggestions from trying out the Java 25 Javadoc over a period of time. I like it, but think it can be better. Thank you for your time and help. David Alayachew -------------- next part -------------- An HTML attachment was scrubbed... URL: From hannes.wallnoefer at oracle.com Tue Sep 2 11:12:20 2025 From: hannes.wallnoefer at oracle.com (Hannes Wallnoefer) Date: Tue, 2 Sep 2025 11:12:20 +0000 Subject: can javadoc have a mode easier and direct design? In-Reply-To: References: Message-ID: <7004F39B-5F1F-4189-AE6E-9AE06CF4C8E4@oracle.com> Hi David, On 20.08.2025, at 01:47, david Grajales wrote: My question is: * Is there any initiative to include more usage examples and concise, code-centric explanations in Javadoc? * Or, is there an alternative official documentation site that already follows this more example-driven approach? Note that this list is about development of the JavaDoc tool, not the content of API documentation. That is the responsibility of the individual libraries that are part of OpenJDK. My impression is that example code in API docs has improved quite a bit over the last years, especially in new APIs, many of them using the new {@snippet} tag. But of course there?s always room for improvement. As to other documentation that is more example-driven you should be able to find tutorials on many APIs, but that is also outside my direct field of activity. Hannes -------------- next part -------------- An HTML attachment was scrubbed... URL: From davidalayachew at gmail.com Tue Sep 2 12:38:49 2025 From: davidalayachew at gmail.com (David Alayachew) Date: Tue, 2 Sep 2025 08:38:49 -0400 Subject: Some feedback on Search Results Page In-Reply-To: References: Message-ID: Thanks Hannes. I understand your logic now about the blue. And yes, there are clear directions on the top. While I might still prefer the blue, that's a mild preference now, after having read your response. I also understand your logic about the 2 columns, but that sounds more like an argument for saying that the 2 displays should be in sync -- not that there shouldn't be a different ordering or compartmentalization of the content. Me personally, I find it easier to parse the contents of a table when each column has a single piece of data. So, I remain unconvinced on this point. But like you said, let's see if others feel similarly. Thank you for your consideration. David Alayachew On Tue, Sep 2, 2025, 6:59?AM Hannes Wallnoefer wrote: > Thanks for the feedback, David. > > The main objective for the updated search page in JDK 25 was to make it > possible to navigate search results by keyboard (using tab, arrow and > return keys). That?s also the reason search results are no longer displayed > as blue links. Now the whole result row is the link, which allows you to > click anywhere in the row (it still works with right-click and open in new > tab). > > The reorganisation of table columns and content is due to alignment with > the navigation bar search field on other pages, which now uses the same > two-column format. It used to use a single column format containing only > the fully qualified name. > > As you say, it?s all about tradeoffs. A fully qualified name (or something > resembling it) may be quicker to read. The new layout provides more > information, and IMO it?s also more aesthetically pleasing, although > that?s certainly subjective. I?m open to changes if there?s a clear trend > in feedback. > > Hannes > > On 01.09.2025, at 19:35, David Alayachew wrote: > > May also want a 4th column for module, but that's less important. Maybe > makes sense to put that behind a toggle. > > And I want to emphasize, of these suggestions, the splitting up of > Description is the most important. That just makes my searching experience > more taxing, as the horizontal position of a package name is slightly > different for each line, making reading harder. > > On Mon, Sep 1, 2025 at 1:24?PM David Alayachew > wrote: > >> Hello @javadoc-dev at openjdk.org , >> >> If I click "Search" on the top left of Java 24 Javadoc, and then when the >> page loads, I type in "Subtask", it returns "StructuredTaskScope.Subtask" >> with blue text. Here is a screenshot. >> >> >> >> But if I do the same for Java 25 EA, not only is the columns different, >> but the text color for the Class Name has changed from Blue to Black. Here >> is a screenshot. >> >> >> >> >> It is also the same for Java 26 EA. Here is a screenshot. >> >> >> >> There's definitely some tradeoffs I can see. >> >> For example, I can now see from a glance if it's an interface, a class, >> an enum, etc. >> >> But on the other hand, the "Description" column smushes 2 separate pieces >> of data together -- class type and package. I would much prefer that these >> be 2 separate columns, for a total of 3. >> >> I also would like it if we could go back to having packages on the left, >> vs the right. I understand that the class name is what people care about, >> but since fully qualified names of classes start with packages, then I >> think it also makes sense to have the packages be the first column. We can >> keep class type (interface, enum, Exception, etc) as the 3rd column. >> >> Finally, can we go back to the blue text? Blue is a nice signifier -- I >> see blue, and I think hyperlinks. It kind of leads me into right-clicking >> to open in a new tab, and since the blue pops out compared to the black, my >> eyes naturally gravitate towards it, making it easier for me to find what I >> need. >> >> These are just a few suggestions from trying out the Java 25 Javadoc over >> a period of time. I like it, but think it can be better. >> >> Thank you for your time and help. >> David Alayachew >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hannesw at openjdk.org Mon Sep 8 13:27:11 2025 From: hannesw at openjdk.org (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=) Date: Mon, 8 Sep 2025 13:27:11 GMT Subject: RFR: 8366278: Form control element ` should contain a label or title to describe it's purpose. Thanks for the fix! Comments/suggestions below. src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/SearchWriter.java line 111: > 109: var select = HtmlTree.of(HtmlTag.SELECT) > 110: .setId(HtmlId.of("search-modules")) > 111: .put(HtmlAttr.TITLE, "search in modules") Should there be an `aria-label` attribute in addition to (or instead of) the `title` attribute? The value of the attribute shoudl be localized, using `contents.getContent("doclet...")` with an appropriate new entry in `standard.properties`. ------------- Changes requested by hannesw (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/26982#pullrequestreview-3196527661 PR Review Comment: https://git.openjdk.org/jdk/pull/26982#discussion_r2330239473 From duke at openjdk.org Mon Sep 8 13:52:16 2025 From: duke at openjdk.org (Pasam Soujanya) Date: Mon, 8 Sep 2025 13:52:16 GMT Subject: RFR: 8366278: Form control element ` should contain a label or title to describe it's purpose. > > src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/SearchWriter.java line 111: > >> 109: var select = HtmlTree.of(HtmlTag.SELECT) >> 110: .setId(HtmlId.of("search-modules")) >> 111: .put(HtmlAttr.TITLE, "search in modules") > > Should there be an `aria-label` attribute in addition to (or instead of) the `title` attribute? > > The value of the attribute shoudl be localized, using `contents.getContent("doclet...")` with an appropriate new entry in `standard.properties`. Sure, will make the changes as suggested. Thank you. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26982#discussion_r2330316123 From duke at openjdk.org Tue Sep 9 05:56:27 2025 From: duke at openjdk.org (Pasam Soujanya) Date: Tue, 9 Sep 2025 05:56:27 GMT Subject: RFR: 8366278: Form control element ` should contain a label or title to describe it's purpose. Pasam Soujanya has updated the pull request incrementally with one additional commit since the last revision: Form control select should have a aria-label ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26982/files - new: https://git.openjdk.org/jdk/pull/26982/files/d5b93115..394c585c Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26982&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26982&range=00-01 Stats: 4 lines in 2 files changed: 3 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/26982.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26982/head:pull/26982 PR: https://git.openjdk.org/jdk/pull/26982 From nbenalla at openjdk.org Tue Sep 9 08:46:26 2025 From: nbenalla at openjdk.org (Nizar Benalla) Date: Tue, 9 Sep 2025 08:46:26 GMT Subject: RFR: 8361366: Allow sorting of member details in lexicographical order [v3] In-Reply-To: References: Message-ID: <-u5saOQpbKNsDiMYL_lOyvl6fdqlU6gInzOqwHWc8yU=.acaf22d9-9214-496e-8578-37e99c77c4fe@github.com> > Please review this patch to add a toggle to order the member details in the table of contents in lexical order. The selected choice is stored and preserved. > > Here is a preview of the new toggle. > > > https://github.com/user-attachments/assets/55c81e4b-5fc0-416e-8946-53aede419640 Nizar Benalla has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains five commits: - Merge branch 'refs/heads/master' into toc-toggle - Merge branch 'master' into toc-toggle # Conflicts: # src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/HtmlDoclet.java - Merge branch 'master' into toc-toggle # Conflicts: # src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/HtmlDoclet.java - make toc.js resilient to being loaded after script.js - add toggle to sort TOC in lexical order ------------- Changes: https://git.openjdk.org/jdk/pull/26322/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26322&range=02 Stats: 148 lines in 12 files changed: 146 ins; 1 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/26322.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26322/head:pull/26322 PR: https://git.openjdk.org/jdk/pull/26322 From nbenalla at openjdk.org Tue Sep 9 09:19:41 2025 From: nbenalla at openjdk.org (Nizar Benalla) Date: Tue, 9 Sep 2025 09:19:41 GMT Subject: RFR: 8361366: Allow sorting of member details in lexicographical order [v4] In-Reply-To: References: Message-ID: > Please review this patch to add a toggle to order the member details in the table of contents in lexical order. The selected choice is stored and preserved. > > Here is a preview of the new toggle. > > > https://github.com/user-attachments/assets/55c81e4b-5fc0-416e-8946-53aede419640 Nizar Benalla has updated the pull request incrementally with one additional commit since the last revision: member details should also be sorted ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26322/files - new: https://git.openjdk.org/jdk/pull/26322/files/00d2b0b0..9ef5d241 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26322&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26322&range=02-03 Stats: 285 lines in 9 files changed: 178 ins; 97 del; 10 mod Patch: https://git.openjdk.org/jdk/pull/26322.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26322/head:pull/26322 PR: https://git.openjdk.org/jdk/pull/26322 From nbenalla at openjdk.org Tue Sep 9 09:26:00 2025 From: nbenalla at openjdk.org (Nizar Benalla) Date: Tue, 9 Sep 2025 09:26:00 GMT Subject: RFR: 8361366: Allow sorting of member details in lexicographical order [v2] In-Reply-To: References: Message-ID: On Thu, 17 Jul 2025 09:19:21 GMT, Hannes Walln?fer wrote: >> This looks good, but there's some room for improvement. >> >> My biggest gripe is that it only reorders the members in the table of contents, but not the member details in the page. Thus, when scrolling through the page, the selection in the TOC jumps around randomly. The idea of the scroll-following TOC is that it mirrors the order of page contents, so both TOC and page contents should be reordered IMO. >> >> I think the icon is not very good at hinting at its function. Some variant of [A-Z sort icon ](https://www.flaticon.com/free-icons/sort-alphabetically) might work better. There should probably be a different icon for non-lexicographic source order, but I'm not sure what that should be. I can help with creating the icons. >> >> Is there a reason for putting the functionality in a new JavaScript file? I agree `script.js` is a bit overloaded and unorderly, but I would prefer cleaning up that existing file instead of adding a new one. > >> both TOC and page contents should be reordered IMO > > Thinking about it some more, I think it should be enough to reorder member details in the main section, and then rebuild the TOC to let it do its thing. @hns I have moved the functionality to `script.js` and updated the logic to sort the member details in the page. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26322#issuecomment-3269712854 From hannesw at openjdk.org Tue Sep 9 10:26:13 2025 From: hannesw at openjdk.org (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=) Date: Tue, 9 Sep 2025 10:26:13 GMT Subject: RFR: 8367007: javadoc generation of JavaFX docs fails after fix for JDK-8350920 Message-ID: Please review a change to fix a regression when documenting inherited JavaFX property members after [JDK-8350920](https://bugs.openjdk.org/browse/JDK-8350920). The wrong `PropertyHelper` instance was used to initialize synthetic doc comments on property members, leading to potentially missing comments. Since using the correct `PropertyHelper` instance would have led to property info being computed multiple times (previously it was only needed in `ClassWriter`), I added caching of `PropertyHelper` instances in the enclosing `PropertyUtils` instance. In the process I also removed some unnecessary fields from `PropertyHelper`, made the property member map lazily initialized, and cleaned up code and doc comments in `PropertyUtils` a bit. The test adds a new subclass to a property-holding class in `TestJavaFX` to make sure inherited property members are documented correctly and no warnings are issued for missing synthetic doc comments. ------------- Commit messages: - 8367007: javadoc generation of JavaFX docs fails after fix for JDK-8350920 Changes: https://git.openjdk.org/jdk/pull/27168/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27168&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8367007 Stats: 104 lines in 5 files changed: 53 ins; 13 del; 38 mod Patch: https://git.openjdk.org/jdk/pull/27168.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27168/head:pull/27168 PR: https://git.openjdk.org/jdk/pull/27168 From duke at openjdk.org Wed Sep 10 10:00:51 2025 From: duke at openjdk.org (Francesco Andreuzzi) Date: Wed, 10 Sep 2025 10:00:51 GMT Subject: RFR: 8367007: javadoc generation of JavaFX docs fails after fix for JDK-8350920 In-Reply-To: References: Message-ID: On Tue, 9 Sep 2025 10:16:42 GMT, Hannes Walln?fer wrote: > Please review a change to fix a regression when documenting inherited JavaFX property members after [JDK-8350920](https://bugs.openjdk.org/browse/JDK-8350920). The wrong `PropertyHelper` instance was used to initialize synthetic doc comments on property members, leading to potentially missing comments. > > Since using the correct `PropertyHelper` instance would have led to property info being computed multiple times (previously it was only needed in `ClassWriter`), I added caching of `PropertyHelper` instances in the enclosing `PropertyUtils` instance. In the process I also removed some unnecessary fields from `PropertyHelper`, made the property member map lazily initialized, and cleaned up code and doc comments in `PropertyUtils` a bit. > > The test adds a new subclass to a property-holding class in `TestJavaFX` to make sure inherited property members are documented correctly and no warnings are issued for missing synthetic doc comments. src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/PropertyUtils.java line 215: > 213: */ > 214: public static class PropertyHelper { > 215: private Map classPropertiesMap = null; What's the added value of having this lazily initialized? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27168#discussion_r2336232003 From hannesw at openjdk.org Wed Sep 10 13:14:05 2025 From: hannesw at openjdk.org (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=) Date: Wed, 10 Sep 2025 13:14:05 GMT Subject: RFR: 8367321: Fix CSS bugs in dark theme Message-ID: Please review a change to fix various problems with the recently introduced dark theme for API docs: - Minimizes flickering when page is loaded with dark theme (best experienced on large pages such as "All Classes") - Fixes link color in table captions of inherited member summaries and class use pages ([before](https://download.java.net/java/early_access/jdk26/docs/api/java.base/java/lang/Exception.html#method-summary) / [after](https://cr.openjdk.org/~hannesw/8366942/api.00/java.base/java/lang/Exception.html#method-summary)) - Fixes section color in Serialized Form page ([before](https://download.java.net/java/early_access/jdk26/docs/api/serialized-form.html) / [after](https://cr.openjdk.org/~hannesw/8366942/api.00/serialized-form.html)) The change also includes some JS and CSS refactoring/cleanup. Generated documentation was tested on Firefox, Chrome and Safari and [can be viewed here](https://cr.openjdk.org/~hannesw/8366942/api.00/java.base/module-summary.html) (module java.base only). ------------- Commit messages: - 8367321: Fix CSS bugs in dark theme Changes: https://git.openjdk.org/jdk/pull/27191/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27191&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8367321 Stats: 69 lines in 4 files changed: 24 ins; 10 del; 35 mod Patch: https://git.openjdk.org/jdk/pull/27191.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27191/head:pull/27191 PR: https://git.openjdk.org/jdk/pull/27191 From hannesw at openjdk.org Wed Sep 10 13:46:11 2025 From: hannesw at openjdk.org (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=) Date: Wed, 10 Sep 2025 13:46:11 GMT Subject: RFR: 8367007: javadoc generation of JavaFX docs fails after fix for JDK-8350920 In-Reply-To: References: Message-ID: On Wed, 10 Sep 2025 09:58:20 GMT, Francesco Andreuzzi wrote: >> Please review a change to fix a regression when documenting inherited JavaFX property members after [JDK-8350920](https://bugs.openjdk.org/browse/JDK-8350920). The wrong `PropertyHelper` instance was used to initialize synthetic doc comments on property members, leading to potentially missing comments. >> >> Since using the correct `PropertyHelper` instance would have led to property info being computed multiple times (previously it was only needed in `ClassWriter`), I added caching of `PropertyHelper` instances in the enclosing `PropertyUtils` instance. In the process I also removed some unnecessary fields from `PropertyHelper`, made the property member map lazily initialized, and cleaned up code and doc comments in `PropertyUtils` a bit. >> >> The test adds a new subclass to a property-holding class in `TestJavaFX` to make sure inherited property members are documented correctly and no warnings are issued for missing synthetic doc comments. > > src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/PropertyUtils.java line 215: > >> 213: */ >> 214: public static class PropertyHelper { >> 215: private Map classPropertiesMap = null; > > What's the added value of having this lazily initialized? Most code bases don't use JavaFX properties at all, and since we're adding caching for these objects the idea is to not waste memory (even though it doesn't matter much). ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27168#discussion_r2336814281 From liach at openjdk.org Wed Sep 10 16:11:48 2025 From: liach at openjdk.org (Chen Liang) Date: Wed, 10 Sep 2025 16:11:48 GMT Subject: RFR: 8367007: javadoc generation of JavaFX docs fails after fix for JDK-8350920 In-Reply-To: References: Message-ID: On Tue, 9 Sep 2025 10:16:42 GMT, Hannes Walln?fer wrote: > Please review a change to fix a regression when documenting inherited JavaFX property members after [JDK-8350920](https://bugs.openjdk.org/browse/JDK-8350920). The wrong `PropertyHelper` instance was used to initialize synthetic doc comments on property members, leading to potentially missing comments. > > Since using the correct `PropertyHelper` instance would have led to property info being computed multiple times (previously it was only needed in `ClassWriter`), I added caching of `PropertyHelper` instances in the enclosing `PropertyUtils` instance. In the process I also removed some unnecessary fields from `PropertyHelper`, made the property member map lazily initialized, and cleaned up code and doc comments in `PropertyUtils` a bit. > > The test adds a new subclass to a property-holding class in `TestJavaFX` to make sure inherited property members are documented correctly and no warnings are issued for missing synthetic doc comments. Looks good. The cleanups in PropertyUtils look mostly trivial. ------------- Marked as reviewed by liach (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/27168#pullrequestreview-3206858413 From nbenalla at openjdk.org Wed Sep 10 16:27:52 2025 From: nbenalla at openjdk.org (Nizar Benalla) Date: Wed, 10 Sep 2025 16:27:52 GMT Subject: RFR: 8367007: javadoc generation of JavaFX docs fails after fix for JDK-8350920 In-Reply-To: References: Message-ID: On Tue, 9 Sep 2025 10:16:42 GMT, Hannes Walln?fer wrote: > Please review a change to fix a regression when documenting inherited JavaFX property members after [JDK-8350920](https://bugs.openjdk.org/browse/JDK-8350920). The wrong `PropertyHelper` instance was used to initialize synthetic doc comments on property members, leading to potentially missing comments. > > Since using the correct `PropertyHelper` instance would have led to property info being computed multiple times (previously it was only needed in `ClassWriter`), I added caching of `PropertyHelper` instances in the enclosing `PropertyUtils` instance. In the process I also removed some unnecessary fields from `PropertyHelper`, made the property member map lazily initialized, and cleaned up code and doc comments in `PropertyUtils` a bit. > > The test adds a new subclass to a property-holding class in `TestJavaFX` to make sure inherited property members are documented correctly and no warnings are issued for missing synthetic doc comments. I think this looks fine. ------------- Marked as reviewed by nbenalla (Committer). PR Review: https://git.openjdk.org/jdk/pull/27168#pullrequestreview-3206909627 From hannesw at openjdk.org Wed Sep 10 16:47:22 2025 From: hannesw at openjdk.org (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=) Date: Wed, 10 Sep 2025 16:47:22 GMT Subject: Integrated: 8367007: javadoc generation of JavaFX docs fails after fix for JDK-8350920 In-Reply-To: References: Message-ID: On Tue, 9 Sep 2025 10:16:42 GMT, Hannes Walln?fer wrote: > Please review a change to fix a regression when documenting inherited JavaFX property members after [JDK-8350920](https://bugs.openjdk.org/browse/JDK-8350920). The wrong `PropertyHelper` instance was used to initialize synthetic doc comments on property members, leading to potentially missing comments. > > Since using the correct `PropertyHelper` instance would have led to property info being computed multiple times (previously it was only needed in `ClassWriter`), I added caching of `PropertyHelper` instances in the enclosing `PropertyUtils` instance. In the process I also removed some unnecessary fields from `PropertyHelper`, made the property member map lazily initialized, and cleaned up code and doc comments in `PropertyUtils` a bit. > > The test adds a new subclass to a property-holding class in `TestJavaFX` to make sure inherited property members are documented correctly and no warnings are issued for missing synthetic doc comments. This pull request has now been integrated. Changeset: af18ff8d Author: Hannes Walln?fer URL: https://git.openjdk.org/jdk/commit/af18ff8d7c8fdd6437304839caa2e49eb34b6caa Stats: 104 lines in 5 files changed: 53 ins; 13 del; 38 mod 8367007: javadoc generation of JavaFX docs fails after fix for JDK-8350920 Reviewed-by: liach, nbenalla ------------- PR: https://git.openjdk.org/jdk/pull/27168 From hannesw at openjdk.org Thu Sep 11 09:55:31 2025 From: hannesw at openjdk.org (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=) Date: Thu, 11 Sep 2025 09:55:31 GMT Subject: RFR: 8366278: Form control element ` should contain a label or title to describe it's purpose. > > Pasam Soujanya has updated the pull request incrementally with one additional commit since the last revision: > > Form control select should have a aria-label src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/resources/standard.properties line 792: > 790: > 791: doclet.searchModules=\ > 792: Search the specified content in the modules. The change looks good regarding the code, but I'm not sure about naming/wording. I think `doclet.selectModule` and "Select the module to search in" would better describe the element. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26982#discussion_r2339863282 From duke at openjdk.org Thu Sep 11 10:09:15 2025 From: duke at openjdk.org (Pasam Soujanya) Date: Thu, 11 Sep 2025 10:09:15 GMT Subject: RFR: 8366278: Form control element ` should contain a label or title to describe it's purpose. Pasam Soujanya has updated the pull request incrementally with one additional commit since the last revision: Form control element should have a aria-label ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26982/files - new: https://git.openjdk.org/jdk/pull/26982/files/394c585c..a6317a03 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26982&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26982&range=01-02 Stats: 3 lines in 2 files changed: 0 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/26982.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26982/head:pull/26982 PR: https://git.openjdk.org/jdk/pull/26982 From duke at openjdk.org Thu Sep 11 10:09:18 2025 From: duke at openjdk.org (Pasam Soujanya) Date: Thu, 11 Sep 2025 10:09:18 GMT Subject: RFR: 8366278: Form control element has no associated label [v3] In-Reply-To: References: <7eK9FqwmyuQgtkc1kXwawl-Ynv2QNVfQ0NYWP6CP1Pg=.4ce7793c-0acb-47c1-8283-8f56aaa2dd6b@github.com> Message-ID: On Thu, 11 Sep 2025 10:09:15 GMT, Pasam Soujanya wrote: >> Associating a meaningful label with every UI control allows the browser and assistive technology to expose and announce the control to a user. Associating a visible label also provides a larger clickable area. >> >> ` has no associated label [v3] In-Reply-To: References: <7eK9FqwmyuQgtkc1kXwawl-Ynv2QNVfQ0NYWP6CP1Pg=.4ce7793c-0acb-47c1-8283-8f56aaa2dd6b@github.com> Message-ID: On Thu, 11 Sep 2025 10:09:15 GMT, Pasam Soujanya wrote: >> Associating a meaningful label with every UI control allows the browser and assistive technology to expose and announce the control to a user. Associating a visible label also provides a larger clickable area. >> >> ` has no associated label In-Reply-To: <7eK9FqwmyuQgtkc1kXwawl-Ynv2QNVfQ0NYWP6CP1Pg=.4ce7793c-0acb-47c1-8283-8f56aaa2dd6b@github.com> References: <7eK9FqwmyuQgtkc1kXwawl-Ynv2QNVfQ0NYWP6CP1Pg=.4ce7793c-0acb-47c1-8283-8f56aaa2dd6b@github.com> Message-ID: On Thu, 28 Aug 2025 10:13:24 GMT, Pasam Soujanya wrote: > Associating a meaningful label with every UI control allows the browser and assistive technology to expose and announce the control to a user. Associating a visible label also provides a larger clickable area. > > ` has no associated label Reviewed-by: hannesw ------------- PR: https://git.openjdk.org/jdk/pull/26982 From nbenalla at openjdk.org Mon Sep 15 10:36:59 2025 From: nbenalla at openjdk.org (Nizar Benalla) Date: Mon, 15 Sep 2025 10:36:59 GMT Subject: RFR: 8361366: Allow sorting of member details in lexicographical order [v4] In-Reply-To: References: Message-ID: On Thu, 11 Sep 2025 10:47:35 GMT, Hannes Walln?fer wrote: > One issue I noticed is that it also sorts section headings in the main description of classes in the TOC, which it shouldn't do. One class where you can see this is java.lang.Thread. Thanks for pointing this out Hannes, I was mostly looking at the HashTable/HashMap classes when testing and didn't notice this. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26322#issuecomment-3291496843