From hannesw at openjdk.org Wed Oct 1 10:17:48 2025 From: hannesw at openjdk.org (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=) Date: Wed, 1 Oct 2025 10:17:48 GMT Subject: RFR: 8361366: Allow sorting of member details in lexicographical order [v4] In-Reply-To: References:

Message-ID: On Tue, 30 Sep 2025 15:26:19 GMT, Nizar Benalla wrote: >> src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/resources/script.js.template line 26: >> >>> 24: >>> 25: const sortLexicalLabel = "Sort lexicographically"; >>> 26: const sortSourceLabel = "Sort by source order"; >> >> These should be localized messages as the ones in the preceding lines. > > I avoided adding these in doclet.properties because they would be unused in the java code and may otherwise trip `CheckResourceKeys` That should not be a problem, `CheckResourceKeys` has a mechanism to check resource use in `script.js.template`: https://github.com/openjdk/jdk/blob/master/test/langtools/jdk/javadoc/tool/CheckResourceKeys.java#L209-L220 ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26322#discussion_r2394084668 From hannesw at openjdk.org Fri Oct 3 11:12:33 2025 From: hannesw at openjdk.org (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=) Date: Fri, 3 Oct 2025 11:12:33 GMT Subject: RFR: 8276966: Improve diagnostic output for the mismatching parts of a hybrid snippet Message-ID: Please review a trivial change to improve the error output for hybrid snippets with mismatching inline and external snippet text. Since the logging code drops trailing blank lines, differences in trailing whitespace were not displayed properly. By adding a terminal separator we make sure trailing blank lines are not discarded. This makes it also easier to see where the snippet diff ends. Old output: ----------------- inline ------------------- inline snippet ----------------- external ----------------- external snippet New output: ----------------- inline ------------------- inline snippet ----------------- external ----------------- external snippet -------------------------------------------- ------------- Commit messages: - 8276966: Improve diagnostic output for the mismatching parts of a hybrid snippet Changes: https://git.openjdk.org/jdk/pull/27621/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27621&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8276966 Stats: 4 lines in 2 files changed: 3 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/27621.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27621/head:pull/27621 PR: https://git.openjdk.org/jdk/pull/27621 From prappo at openjdk.org Fri Oct 3 13:26:12 2025 From: prappo at openjdk.org (Pavel Rappo) Date: Fri, 3 Oct 2025 13:26:12 GMT Subject: RFR: 8276966: Improve diagnostic output for the mismatching parts of a hybrid snippet In-Reply-To: References: Message-ID: On Fri, 3 Oct 2025 11:07:02 GMT, Hannes Walln?fer wrote: > Please review a trivial change to improve the error output for hybrid snippets with mismatching inline and external snippet text. > > Since the logging code drops trailing blank lines, differences in trailing whitespace were not displayed properly. See [JDK-8304408](https://bugs.openjdk.org/browse/JDK-8304408) for an example where this occurs. By adding a terminal separator we make sure trailing blank lines are not discarded. This makes it also easier to see where the snippet diff ends. > > Old output: > > > ----------------- inline ------------------- > inline snippet > ----------------- external ----------------- > external snippet > > > New output: > > > ----------------- inline ------------------- > inline snippet > ----------------- external ----------------- > external snippet > -------------------------------------------- Does it make sense to add a test for this assertion? > By adding a terminal separator we make sure trailing blank lines are not discarded. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27621#issuecomment-3365674029 From liach at openjdk.org Fri Oct 3 14:39:27 2025 From: liach at openjdk.org (Chen Liang) Date: Fri, 3 Oct 2025 14:39:27 GMT Subject: RFR: 8367610: Test tools/sincechecker/modules/java.base/JavaBaseCheckSince.java timed out on Windows In-Reply-To: References: Message-ID: On Tue, 23 Sep 2025 14:00:24 GMT, Nizar Benalla wrote: > Timeout after "8260555: Change the default TIMEOUT_FACTOR from 4 to 1" > > The test usually runs in 30 seconds but it seems to be struggling sometimes with the 120 second timeout. Marked as reviewed by liach (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/27453#pullrequestreview-3299347843 From hannesw at openjdk.org Fri Oct 3 14:45:19 2025 From: hannesw at openjdk.org (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=) Date: Fri, 3 Oct 2025 14:45:19 GMT Subject: RFR: 8276966: Improve diagnostic output for the mismatching parts of a hybrid snippet [v2] In-Reply-To: References: Message-ID: > Please review a trivial change to improve the error output for hybrid snippets with mismatching inline and external snippet text. > > Since the logging code drops trailing blank lines, differences in trailing whitespace were not displayed properly. See [JDK-8304408](https://bugs.openjdk.org/browse/JDK-8304408) for an example where this occurs. By adding a terminal separator we make sure trailing blank lines are not discarded. This makes it also easier to see where the snippet diff ends. > > Old output: > > > ----------------- inline ------------------- > inline snippet > ----------------- external ----------------- > external snippet > > > New output: > > > ----------------- inline ------------------- > inline snippet > ----------------- external ----------------- > external snippet > -------------------------------------------- Hannes Walln?fer has updated the pull request incrementally with one additional commit since the last revision: Add test ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27621/files - new: https://git.openjdk.org/jdk/pull/27621/files/4b353ef9..ad95230d Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27621&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27621&range=00-01 Stats: 11 lines in 1 file changed: 8 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/27621.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27621/head:pull/27621 PR: https://git.openjdk.org/jdk/pull/27621 From hannesw at openjdk.org Fri Oct 3 14:45:19 2025 From: hannesw at openjdk.org (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=) Date: Fri, 3 Oct 2025 14:45:19 GMT Subject: RFR: 8276966: Improve diagnostic output for the mismatching parts of a hybrid snippet In-Reply-To: References:

Message-ID: On Fri, 3 Oct 2025 13:23:52 GMT, Pavel Rappo wrote: > Does it make sense to add a test for this assertion? > > > By adding a terminal separator we make sure trailing blank lines are not discarded. Definitely a good idea! Luckily we already have a hybrid snippet mismatch test with a trailing blank line, so I added a check for the correct output. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27621#issuecomment-3365980341 From prappo at openjdk.org Fri Oct 3 14:59:27 2025 From: prappo at openjdk.org (Pavel Rappo) Date: Fri, 3 Oct 2025 14:59:27 GMT Subject: RFR: 8276966: Improve diagnostic output for the mismatching parts of a hybrid snippet [v2] In-Reply-To: References:

Message-ID: On Fri, 3 Oct 2025 14:45:19 GMT, Hannes Walln?fer wrote: >> Please review a trivial change to improve the error output for hybrid snippets with mismatching inline and external snippet text. >> >> Since the logging code drops trailing blank lines, differences in trailing whitespace were not displayed properly. See [JDK-8304408](https://bugs.openjdk.org/browse/JDK-8304408) for an example where this occurs. By adding a terminal separator we make sure trailing blank lines are not discarded. This makes it also easier to see where the snippet diff ends. >> >> Old output: >> >> >> ----------------- inline ------------------- >> inline snippet >> ----------------- external ----------------- >> external snippet >> >> >> New output: >> >> >> ----------------- inline ------------------- >> inline snippet >> ----------------- external ----------------- >> external snippet >> -------------------------------------------- > > Hannes Walln?fer has updated the pull request incrementally with one additional commit since the last revision: > > Add test Thanks, Pavel! ------------- PR Comment: https://git.openjdk.org/jdk/pull/27621#issuecomment-3366259872 From hannesw at openjdk.org Fri Oct 3 15:56:32 2025 From: hannesw at openjdk.org (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=) Date: Fri, 3 Oct 2025 15:56:32 GMT Subject: Integrated: 8276966: Improve diagnostic output for the mismatching parts of a hybrid snippet In-Reply-To: References: Message-ID: On Fri, 3 Oct 2025 11:07:02 GMT, Hannes Walln?fer wrote: > Please review a trivial change to improve the error output for hybrid snippets with mismatching inline and external snippet text. > > Since the logging code drops trailing blank lines, differences in trailing whitespace were not displayed properly. See [JDK-8304408](https://bugs.openjdk.org/browse/JDK-8304408) for an example where this occurs. By adding a terminal separator we make sure trailing blank lines are not discarded. This makes it also easier to see where the snippet diff ends. > > Old output: > > > ----------------- inline ------------------- > inline snippet > ----------------- external ----------------- > external snippet > > > New output: > > > ----------------- inline ------------------- > inline snippet > ----------------- external ----------------- > external snippet > -------------------------------------------- This pull request has now been integrated. Changeset: f81c7c59 Author: Hannes Walln?fer URL: https://git.openjdk.org/jdk/commit/f81c7c592bbc9f5575ed41e41d12f54cbfc5e4aa Stats: 15 lines in 2 files changed: 11 ins; 0 del; 4 mod 8276966: Improve diagnostic output for the mismatching parts of a hybrid snippet Reviewed-by: prappo ------------- PR: https://git.openjdk.org/jdk/pull/27621 From sherman at openjdk.org Fri Oct 3 19:10:20 2025 From: sherman at openjdk.org (Xueming Shen) Date: Fri, 3 Oct 2025 19:10:20 GMT Subject: RFR: 8365675: Add String Unicode Case-Folding Support Message-ID: ### Summary Case folding is a key operation for case-insensitive matching (e.g., string equality, regex matching), where the goal is to eliminate case distinctions without applying locale or language specific conversions. Currently, the JDK does not expose a direct API for Unicode-compliant case folding. Developers now rely on methods such as: **String.equalsIgnoreCase(String)** - Unicode-aware, locale-independent. - Implementation uses Character.toLowerCase(Character.toUpperCase(int)) per code point. - Limited: does not support 1:M mapping defined in Unicode case folding. **Character.toLowerCase(int) / Character.toUpperCase(int)** - Locale-independent, single code point only. - No support for 1:M mappings. **String.toLowerCase(Locale.ROOT) / String.toUpperCase(Locale.ROOT)** - Based on Unicode SpecialCasing.txt, supports 1:M mappings. - Intended primarily for presentation/display, not structural case-insensitive matching. - Requires full string conversion before comparison, which is less efficient and not intended for structural matching. **1:M mapping example, U+00DF (?)** - String.toUpperCase(Locale.ROOT, "?") ? "SS" - Case folding produces "ss", matching Unicode caseless comparison rules. jshell> "\u00df".equalsIgnoreCase("ss") $22 ==> false jshell> "\u00df".toUpperCase(Locale.ROOT).toLowerCase(Locale.ROOT).equals("ss") $24 ==> true ### Motivation & Direction Add Unicode standard-compliant case-less comparison methods to the String class, enabling & improving reliable and efficient Unicode-aware/compliant case-insensitive matching. - Unicode-compliant **full** case folding. - Simpler, stable and more efficient case-less matching without workarounds. - Brings Java's string comparison handling in line with other programming languages/libraries. This PR proposes to introduce the following comparison methods in `String` class - boolean equalsFoldCase(String anotherString) - int compareToFoldCase(String anotherString) - Comparator UNICODE_CASEFOLD_ORDER These methods are intended to be the preferred choice when Unicode-compliant case-less matching is required. *Note: An early draft also proposed a String.toCaseFold() method returning a new case-folded string. However, during review this was considered error-prone, as the resulting string could easily be mistaken for a general transformation like toLowerCase() and then passed into APIs where case-folding semantics are not appropriate. ### The New API /** * Compares this {@code String} to another {@code String} for equality, * using Unicode case folding. Two strings are considered equal * by this method if their case-folded forms are identical. *

* Case folding is defined by the Unicode Standard in * CaseFolding.txt, * including 1:M mappings. For example, {@code "Ma?e".equalsFoldCase("MASSE")} * returns {@code true}, since the character {@code U+00DF} (sharp s) folds * to {@code "ss"}. *

* Case folding is locale-independent and language-neutral, unlike * locale-sensitive transformations such as {@link #toLowerCase()} or * {@link #toUpperCase()}. It is intended for caseless matching, * searching, and indexing. * * @apiNote * This method is the Unicode-compliant alternative to * {@link #equalsIgnoreCase(String)}. It implements full case folding as * defined by the Unicode Standard, which may differ from the simpler * per-character mapping performed by {@code equalsIgnoreCase}. * For example: *

{@snippet lang=java :
     * String a = "Ma?e";
     * String b = "MASSE";
     * boolean equalsFoldCase = a.equalsFoldCase(b);       // returns true
     * boolean equalsIgnoreCase = a.equalsIgnoreCase(b);   // returns false
     * }

* * @param anotherString * The {@code String} to compare this {@code String} against * * @return {@code true} if the given object is not {@code null} and represents * the same sequence of characters as this string under Unicode case * folding; {@code false} otherwise. * * @see #compareToFoldCase(String) * @see #equalsIgnoreCase(String) * @since 26 */ public boolean equalsFoldCase(String anotherString) /** * Compares two strings lexicographically using Unicode case folding. * This method returns an integer whose sign is that of calling {@code compareTo} * on the Unicode case folded version of the strings. Unicode Case folding * eliminates differences in case according to the Unicode Standard, using the * mappings defined in * CaseFolding.txt, * including 1:M mappings, such as {@code"?"} ? {@code }"ss"}. *

* Case folding is a locale-independent, language-neutral form of case mapping, * primarily intended for caseless matching. Unlike {@link #compareToIgnoreCase(String)}, * which applies a simpler locale-insensitive uppercase mapping. This method * follows the Unicode full case folding, providing stable and * consistent results across all environments. *

* Note that this method does not take locale into account, and may * produce results that differ from locale-sensitive ordering. Use * {@link java.text.Collator} for locale-sensitive comparison. * * @apiNote * This method is the Unicode-compliant alternative to * {@link #compareToIgnoreCase(String)}. It implements the full case folding * as defined by the Unicode Standard, which may differ from the simpler * per-character mapping performed by {@code compareToIgnoreCase}. * For example: *

{@snippet lang=java :
     * String a = "Ma?e";
     * String b = "MASSE";
     * int cmpFoldCase = a.compareToFoldCase(b);     // returns 0
     * int cmpIgnoreCase = a.compareToIgnoreCase(b); // returns > 0
     * }

* * @param str the {@code String} to be compared. * @return a negative integer, zero, or a positive integer as the specified * String is greater than, equal to, or less than this String, * ignoring case considerations by case folding. * @see #equalsFoldCase(String) * @see #compareToIgnoreCase(String) * @see java.text.Collator * @since 26 */ public int compareToFoldCase(String str) /** * A Comparator that orders {@code String} objects as by * {@link #compareToFoldCase(String) compareToFoldCase()}. * * @see #compareToFoldCase(String) * @since 26 */ public static final Comparator UNICODE_CASEFOLD_ORDER; ### Usage Examples Sharp s (U+00DF) case-folds to "ss" "stra?e".equalsIgnoreCase("strasse"); // false "stra?e".compareToIgnoreCase("strasse"); // != 0 "stra?e".equalsFoldCase("strasse"); // true ### Performance The JMH microbenchmark StringCompareToIgnoreCase has been updated to compare performance of compareToFoldCase with the existing compareToIgnoreCase(). Benchmark Mode Cnt Score Error Units StringCompareToIgnoreCase.asciiGreekLower avgt 15 20.195 ? 0.300 ns/op StringCompareToIgnoreCase.asciiGreekLowerCF avgt 15 11.051 ? 0.254 ns/op StringCompareToIgnoreCase.asciiGreekUpperLower avgt 15 6.035 ? 0.047 ns/op StringCompareToIgnoreCase.asciiGreekUpperLowerCF avgt 15 14.786 ? 0.382 ns/op StringCompareToIgnoreCase.asciiLower avgt 15 17.688 ? 1.396 ns/op StringCompareToIgnoreCase.asciiLowerCF avgt 15 44.552 ? 0.155 ns/op StringCompareToIgnoreCase.asciiUpperLower avgt 15 13.069 ? 0.487 ns/op StringCompareToIgnoreCase.asciiUpperLowerCF avgt 15 58.684 ? 0.274 ns/op StringCompareToIgnoreCase.greekLower avgt 15 20.642 ? 0.082 ns/op StringCompareToIgnoreCase.greekLowerCF avgt 15 7.255 ? 0.271 ns/op StringCompareToIgnoreCase.greekUpperLower avgt 15 5.737 ? 0.013 ns/op StringCompareToIgnoreCase.greekUpperLowerCF avgt 15 11.100 ? 1.147 ns/op StringCompareToIgnoreCase.lower avgt 15 20.192 ? 0.044 ns/op StringCompareToIgnoreCase.lowerrCF avgt 15 11.257 ? 0.259 ns/op StringCompareToIgnoreCase.supLower avgt 15 54.801 ? 0.415 ns/op StringCompareToIgnoreCase.supLowerCF avgt 15 15.207 ? 0.418 ns/op StringCompareToIgnoreCase.supUpperLower avgt 15 14.431 ? 0.188 ns/op StringCompareToIgnoreCase.supUpperLowerCF avgt 15 19.149 ? 0.985 ns/op StringCompareToIgnoreCase.upperLower avgt 15 5.650 ? 0.051 ns/op StringCompareToIgnoreCase.upperLowerCF avgt 15 14.338 ? 0.352 ns/op StringCompareToIgnoreCase.utf16SubLower avgt 15 14.774 ? 0.200 ns/op StringCompareToIgnoreCase.utf16SubLowerCF avgt 15 2.669 ? 0.041 ns/op StringCompareToIgnoreCase.utf16SupUpperLower avgt 15 16.250 ? 0.099 ns/op StringCompareToIgnoreCase.utf16SupUpperLowerCF avgt 15 11.524 ? 0.327 ns/op ### Refs [Unicode Standard 5.18.4 Caseless Matching](https://www.unicode.org/versions/latest/core-spec/chapter-5/#G21790) [Unicode? Standard Annex #44: 5.6 Case and Case Mapping](https://www.unicode.org/reports/tr44/#Casemapping) [Unicode Technical Standard #18: Unicode Regular Expressions RL1.5: Simple Loose Matches](https://www.unicode.org/reports/tr18/#Simple_Loose_Matches) [Unicode SpecialCasing.txt](https://www.unicode.org/Public/UCD/latest/ucd/SpecialCasing.txt) [Unicode CaseFolding.txt](https://www.unicode.org/Public/UCD/latest/ucd/CaseFolding.txt) ### Other Languages **Python string.casefold()** The str.casefold() method in Python returns a casefolded version of a string. Casefolding is a more aggressive form of lowercasing, designed to remove all case distinctions in a string, particularly for the purpose of caseless string comparisons. **Perl?s fc()** Returns the casefolded version of EXPR. This is the internal function implementing the \F escape in double-quoted strings. Casefolding is the process of mapping strings to a form where case differences are erased; comparing two strings in their casefolded form is effectively a way of asking if two strings are equal, regardless of case. Perl only implements the full form of casefolding, but you can access the simple folds using "casefold()" in Unicode::UCD] ad "prop_invmap()" in Unicode::UCD]. **ICU4J UCharacter.foldCase (Java)** Purpose: Provides extensions to the standard Java Character class, including support for more Unicode properties and handling of supplementary characters (code points beyond U+FFFF). Method Signature (String based): public static String foldCase(String str, int options) Method Signature (CharSequence & Appendable based): public static A foldCase(CharSequence src, A dest, int options, Edits edits) Key Features: Case Folding: Converts a string to its case-folded equivalent. Locale Independent: Case folding in UCharacter.foldCase is generally not dependent on locale settings. Context Insensitive: The mapping of a character is not affected by surrounding characters. Turkic Option: An option exists to include or exclude special mappings for Turkish/Azerbaijani text. Result Length: The resulting string can be longer or shorter than the original. Edits Recording: Allows for recording of edits for index mapping, styled text, and getting only changes. **u_strFoldCase (C/C++)** A lower-level C API function for case folding a string. Case Folding Options: Similar options as UCharacter.foldCase for controlling case folding behavior. Availability: Found in the ustring.h and unistr.h headers in the ICU4C library. ------------- Commit messages: - 8365675: Add String Unicode Case-Folding Support Changes: https://git.openjdk.org/jdk/pull/26892/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26892&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8365675 Stats: 1279 lines in 12 files changed: 1116 ins; 137 del; 26 mod Patch: https://git.openjdk.org/jdk/pull/26892.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26892/head:pull/26892 PR: https://git.openjdk.org/jdk/pull/26892 From nbenalla at openjdk.org Mon Oct 6 12:01:45 2025 From: nbenalla at openjdk.org (Nizar Benalla) Date: Mon, 6 Oct 2025 12:01:45 GMT Subject: RFR: 8361366: Allow sorting of member details in lexicographical order [v4] In-Reply-To: References:

Message-ID: <5bOTZcVOjEQ7v8Ku5elrUOB1YbOGwIKTkKSQBdEqqpw=.7c8eb9b6-248a-464c-8425-00f7b4d0b0e5@github.com> On Wed, 1 Oct 2025 10:15:29 GMT, Hannes Walln?fer wrote: >> I avoided adding these in doclet.properties because they would be unused in the java code and may otherwise trip `CheckResourceKeys` > > That should not be a problem, `CheckResourceKeys` has a mechanism to check resource use in `script.js.template`: > > https://github.com/openjdk/jdk/blob/master/test/langtools/jdk/javadoc/tool/CheckResourceKeys.java#L209-L220 Thank you Hannes, I missed this detail. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26322#discussion_r2405926633 From nbenalla at openjdk.org Mon Oct 6 13:36:07 2025 From: nbenalla at openjdk.org (Nizar Benalla) Date: Mon, 6 Oct 2025 13:36:07 GMT Subject: RFR: 8367610: Test tools/sincechecker/modules/java.base/JavaBaseCheckSince.java timed out on Windows In-Reply-To: References: Message-ID: <3RkRFRXkSh_EieXR21oNHcu-RTtck24C1j1gZj9pOUA=.fb9d3178-c0c5-47fc-93e5-9b01ccd12ac3@github.com> On Tue, 23 Sep 2025 14:00:24 GMT, Nizar Benalla wrote: > Timeout after "8260555: Change the default TIMEOUT_FACTOR from 4 to 1" > > The test usually runs in 30 seconds but it seems to be struggling sometimes with the 120 second timeout. Thank you for the review Chen ------------- PR Comment: https://git.openjdk.org/jdk/pull/27453#issuecomment-3371670672 From nbenalla at openjdk.org Mon Oct 6 13:36:08 2025 From: nbenalla at openjdk.org (Nizar Benalla) Date: Mon, 6 Oct 2025 13:36:08 GMT Subject: Integrated: 8367610: Test tools/sincechecker/modules/java.base/JavaBaseCheckSince.java timed out on Windows In-Reply-To: References: Message-ID: <5NeZt_ywyrJ5CAIZ5OaGq41Mtbbur9HG2nnilS-DcSc=.068da565-0ef2-4861-b9e3-0fb38869f1dc@github.com> On Tue, 23 Sep 2025 14:00:24 GMT, Nizar Benalla wrote: > Timeout after "8260555: Change the default TIMEOUT_FACTOR from 4 to 1" > > The test usually runs in 30 seconds but it seems to be struggling sometimes with the 120 second timeout. This pull request has now been integrated. Changeset: e3320a9d Author: Nizar Benalla URL: https://git.openjdk.org/jdk/commit/e3320a9df592a06c466ae9158d8f173921679952 Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod 8367610: Test tools/sincechecker/modules/java.base/JavaBaseCheckSince.java timed out on Windows Reviewed-by: liach ------------- PR: https://git.openjdk.org/jdk/pull/27453 From liach at openjdk.org Tue Oct 7 15:10:56 2025 From: liach at openjdk.org (Chen Liang) Date: Tue, 7 Oct 2025 15:10:56 GMT Subject: RFR: 8367321: Fix CSS bugs in dark theme [v2] In-Reply-To: References:

Message-ID: On Mon, 13 Oct 2025 14:27:56 GMT, Nizar Benalla wrote: >> 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 eight commits: > > - Merge branch 'master' into toc-toggle > > # Conflicts: > # src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/resources/stylesheet.css > - improve implementation based on feedback > - member details should also be sorted > - 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 I couldn't include a `cr.openjdk` link due to some issues with uploading. I have updated the PR to fix the issues that were brought up in the review (sorting section headers, adding a visual cue etc) Here is what the button looks like now if it is selected. Screenshot 2025-10-13 at 15 26 56

------------- PR Comment: https://git.openjdk.org/jdk/pull/26322#issuecomment-3397766876 From hannesw at openjdk.org Mon Oct 13 15:28:34 2025 From: hannesw at openjdk.org (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=) Date: Mon, 13 Oct 2025 15:28:34 GMT Subject: RFR: 8361366: Allow sorting of member details in lexicographical order [v5] In-Reply-To: References:

Message-ID: <4u5woLjIrHsTeEBcB78QUX7sMTX5vH00smkONQKuIL0=.b9224b27-206d-4be1-9c44-b59d6e190010@github.com> On Tue, 14 Oct 2025 16:26:24 GMT, Nizar Benalla wrote: >> 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: > > remove redundant css Changes requested by hannesw (Reviewer). src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/resources/doclets.properties line 255: > 253: doclet.table_of_contents=Table of contents > 254: doclet.Sort_lexicographically=Sort lexicographically > 255: doclet.Sort_by_source_order=Sort by source order Would be nice to add what is being sorted: "Sort member details lexicographically/by source order". src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/resources/doclets.properties line 261: > 259: doclet.filter_table_of_contents=Filter table of contents > 260: doclet.filter_reset=Reset > 261: doclet.sort_table_of_contents=Sort table of contents members in lexicographical order I think "table of contents members" should be replaced with "member details". ------------- PR Review: https://git.openjdk.org/jdk/pull/26322#pullrequestreview-3340107914 PR Review Comment: https://git.openjdk.org/jdk/pull/26322#discussion_r2432367296 PR Review Comment: https://git.openjdk.org/jdk/pull/26322#discussion_r2432370495 From hannesw at openjdk.org Wed Oct 15 13:14:35 2025 From: hannesw at openjdk.org (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=) Date: Wed, 15 Oct 2025 13:14:35 GMT Subject: RFR: 8361366: Allow sorting of member details in lexicographical order [v7] In-Reply-To: References:

Message-ID: On Tue, 14 Oct 2025 16:26:24 GMT, Nizar Benalla wrote: >> 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: > > remove redundant css src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/resources/script.js.template line 808: > 806: reorderMemberDetailsAlpha(); > 807: allTocNavs().forEach(sortTocAlpha); > 808: initSectionData(); prevHash = null; handleScroll(); We should not set `prefHash = null` here and in the method below. It causes the TOC to scroll even if the viewed section has not changed, which is not useful. Imagine a user loading a class page, scrolling the TOC down to method details, realizing that method details are sorted in source order, and clicking the "Sort" button. Moving the TOC back up to the beginning is not useful, it should remain at its current position. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26322#discussion_r2432548173 From nbenalla at openjdk.org Fri Oct 17 09:31:41 2025 From: nbenalla at openjdk.org (Nizar Benalla) Date: Fri, 17 Oct 2025 09:31:41 GMT Subject: RFR: 8361366: Allow sorting of member details in lexicographical order [v8] 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 with a new target base due to a merge or a rebase. The pull request now contains 12 commits: - -simplify approach -TOC shouldn't scroll if viewed section hasn't changed -add event listener directly to button - Merge branch 'master' into toc-toggle - remove redundant css - prevent sidebar from moving by adding a transparent border - Merge branch 'master' into toc-toggle # Conflicts: # src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/resources/stylesheet.css - improve implementation based on feedback - member details should also be sorted - 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 - ... and 2 more: https://git.openjdk.org/jdk/compare/1af37e5c...424e3854 ------------- Changes: https://git.openjdk.org/jdk/pull/26322/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26322&range=07 Stats: 252 lines in 10 files changed: 250 ins; 2 del; 0 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 Fri Oct 17 09:34:10 2025 From: nbenalla at openjdk.org (Nizar Benalla) Date: Fri, 17 Oct 2025 09:34:10 GMT Subject: RFR: 8361366: Allow sorting of member details in lexicographical order [v7] In-Reply-To: <4u5woLjIrHsTeEBcB78QUX7sMTX5vH00smkONQKuIL0=.b9224b27-206d-4be1-9c44-b59d6e190010@github.com> References:

<4u5woLjIrHsTeEBcB78QUX7sMTX5vH00smkONQKuIL0=.b9224b27-206d-4be1-9c44-b59d6e190010@github.com> Message-ID: On Wed, 15 Oct 2025 12:27:10 GMT, Hannes Walln?fer wrote: >> Nizar Benalla has updated the pull request incrementally with one additional commit since the last revision: >> >> remove redundant css > > src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/resources/doclets.properties line 255: > >> 253: doclet.table_of_contents=Table of contents >> 254: doclet.Sort_lexicographically=Sort lexicographically >> 255: doclet.Sort_by_source_order=Sort by source order > > Would be nice to add what is being sorted: "Sort member details lexicographically/by source order". Good catch, I'll add it. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26322#discussion_r2439020132 From nbenalla at openjdk.org Fri Oct 17 10:22:15 2025 From: nbenalla at openjdk.org (Nizar Benalla) Date: Fri, 17 Oct 2025 10:22:15 GMT Subject: RFR: 8361366: Allow sorting of member details in lexicographical order [v9] In-Reply-To: References: Message-ID: <4WybhYTMdKjH83WrxHuvElK_YcnTRwhET3HzhjQlsYM=.a80d02c1-ed91-4f85-8b60-42b73d0d0c63@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 incrementally with one additional commit since the last revision: button A-Z text needs to be white on mobile dark theme ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26322/files - new: https://git.openjdk.org/jdk/pull/26322/files/424e3854..2ca5aa2b Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26322&range=08 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26322&range=07-08 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 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 Fri Oct 17 10:27:31 2025 From: nbenalla at openjdk.org (Nizar Benalla) Date: Fri, 17 Oct 2025 10:27:31 GMT Subject: RFR: 8361366: Allow sorting of member details in lexicographical order [v7] In-Reply-To: References:

Message-ID: On Wed, 22 Oct 2025 18:07:37 GMT, Liam Miller-Cushon wrote: >> Hi, please consider this fix for a crash with `-Xdoclint` and type annotations. It is a generalization of a previous fix for [JDK-8266082](https://bugs.openjdk.org/browse/JDK-8266082). > > Liam Miller-Cushon has updated the pull request incrementally with one additional commit since the last revision: > > Update another affected test Looks good to me, except for the test tweak as @vicente-romero-oracle suggests. Thanks! ------------- PR Comment: https://git.openjdk.org/jdk/pull/27901#issuecomment-3460103262 From cushon at openjdk.org Wed Oct 29 07:39:23 2025 From: cushon at openjdk.org (Liam Miller-Cushon) Date: Wed, 29 Oct 2025 07:39:23 GMT Subject: RFR: 8370237: AssertionError in Annotate.fromAnnotations with -Xdoclint and type annotations [v3] In-Reply-To: References: Message-ID: > Hi, please consider this fix for a crash with `-Xdoclint` and type annotations. It is a generalization of a previous fix for [JDK-8266082](https://bugs.openjdk.org/browse/JDK-8266082). Liam Miller-Cushon has updated the pull request incrementally with one additional commit since the last revision: Fix typo in test ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27901/files - new: https://git.openjdk.org/jdk/pull/27901/files/a99313bc..6af3b250 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27901&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27901&range=01-02 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/27901.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27901/head:pull/27901 PR: https://git.openjdk.org/jdk/pull/27901 From cushon at openjdk.org Wed Oct 29 07:39:25 2025 From: cushon at openjdk.org (Liam Miller-Cushon) Date: Wed, 29 Oct 2025 07:39:25 GMT Subject: RFR: 8370237: AssertionError in Annotate.fromAnnotations with -Xdoclint and type annotations [v2] In-Reply-To: References:

Message-ID: <1r8w1AZVc9ICVqs2TiRbQ0JpRxTPu61OD5Nj7tph5IA=.922c4514-4d81-4629-a489-b52c7c6ecda9@github.com> On Tue, 28 Oct 2025 18:57:32 GMT, Vicente Romero wrote: >> Liam Miller-Cushon has updated the pull request incrementally with one additional commit since the last revision: >> >> Update another affected test > > test/langtools/tools/doclint/CrashInTypeAnnotateTest.java line 18: > >> 16: @interface A {} >> 17: >> 18: /** {@link List<@Nullable String>} > > shouldn't this be: `{@link List<@A String>}`? Thanks, fixed. This test was reproducing the crash even with the typo to use the wrong annotation, but definitely better not to rely on that. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27901#discussion_r2471998613 From jlahoda at openjdk.org Wed Oct 29 08:16:08 2025 From: jlahoda at openjdk.org (Jan Lahoda) Date: Wed, 29 Oct 2025 08:16:08 GMT Subject: RFR: 8370237: AssertionError in Annotate.fromAnnotations with -Xdoclint and type annotations [v3] In-Reply-To: References: