From hannesw at openjdk.org Tue Dec 2 14:13:52 2025 From: hannesw at openjdk.org (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=) Date: Tue, 2 Dec 2025 14:13:52 GMT Subject: RFR: 8372708: Javadoc ignores "-locale" and uses default locale for all messages and texts Message-ID: Please review a simple change to make the JavaDoc `-locale` option work with English language locales when the system default is a non-English locale supported by JavaDoc. The problem is that root resource bundles such as `standard.properties` are not recognized as English, and [java.util.ResourceBundle][1] will use the system default locale as fallback before returning the root bundle. [1]: https://docs.oracle.com/en/java/javase/25/docs/api/java.base/java/util/ResourceBundle.html#default_behavior The solution is to provide empty English resource bundles that will use the root bundles as parents. An alternative would be to use a [ResourceBundleProvider][2], but I think the added complexity is not justified for this case. Also, we can't use [ResourceBundle.Control][3] in a named module. [2]: https://docs.oracle.com/en/java/javase/25/docs/api/java.base/java/util/spi/ResourceBundleProvider.html [3]: https://docs.oracle.com/en/java/javase/25/docs/api/java.base/java/util/ResourceBundle.Control.html#getNoFallbackControl(java.util.List) The test runs JavaDoc with all combinations of supported locales for default locale and `-locale` option, making sure the console output uses the default locale while generated docuentation adheres to the `-locale` option. ------------- Commit messages: - 8372708: Javadoc ignores "-locale" and uses default locale for all messages and texts Changes: https://git.openjdk.org/jdk/pull/28603/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28603&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8372708 Stats: 162 lines in 3 files changed: 162 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/28603.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28603/head:pull/28603 PR: https://git.openjdk.org/jdk/pull/28603 From cushon at openjdk.org Tue Dec 2 16:12:58 2025 From: cushon at openjdk.org (Liam Miller-Cushon) Date: Tue, 2 Dec 2025 16:12:58 GMT Subject: RFR: 8372948: Store end positions directly in JCTree Message-ID: This change adds a field to `JCTree` to store end positions, instead of using a separate `EndPosTable` map. See also [this compile-dev@ thread](https://mail.openjdk.org/pipermail/compiler-dev/2025-November/032254.html). I performed the refactoring in stages, preserving existing semantics at each step. There are two known places where this changes existing behaviour that are reflected in changes to tests: * `test/langtools/tools/javac/api/TestJavacTask_Lock.java` - this test asserts that calling `JavacTask#parse` first and then calling `#call` or `#parse` second will fail. The assertion that the test is currently expecting is thrown when the `EndPosTable` gets set a second time, and this change means that no longer results in an exception. If desired `JavacTask#parse` could be updated to explicitly check if it is called twice and fail, instead of indirectly relying on the `EndPosTable` for that. * `test/langtools/tools/javac/diags/DiagnosticGetEndPosition.java` - there's a comment that 'ideally would be "0", but the positions are not fully set yet', and with the new approach the end position is available to the test, so it resolves the comment ------------- Commit messages: - 8372948: Store end positions directly in JCTree Changes: https://git.openjdk.org/jdk/pull/28610/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28610&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8372948 Stats: 563 lines in 33 files changed: 7 ins; 437 del; 119 mod Patch: https://git.openjdk.org/jdk/pull/28610.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28610/head:pull/28610 PR: https://git.openjdk.org/jdk/pull/28610 From liach at openjdk.org Tue Dec 2 16:17:09 2025 From: liach at openjdk.org (Chen Liang) Date: Tue, 2 Dec 2025 16:17:09 GMT Subject: RFR: 8372708: Javadoc ignores "-locale" and uses default locale for all messages and texts In-Reply-To: References: Message-ID: On Tue, 2 Dec 2025 14:05:10 GMT, Hannes Walln?fer wrote: > Please review a simple change to make the JavaDoc `-locale` option work with English language locales when the system default is a non-English locale supported by JavaDoc. The problem is that root resource bundles such as `standard.properties` are not recognized as English, and [java.util.ResourceBundle][1] will use the system default locale as fallback before returning the root bundle. > > [1]: https://docs.oracle.com/en/java/javase/25/docs/api/java.base/java/util/ResourceBundle.html#default_behavior > > The solution is to provide empty English resource bundles that will use the root bundles as parents. An alternative would be to use a [ResourceBundleProvider][2], but I think the added complexity is not justified for this case. Also, we can't use [ResourceBundle.Control][3] in a named module. > > [2]: https://docs.oracle.com/en/java/javase/25/docs/api/java.base/java/util/spi/ResourceBundleProvider.html > [3]: https://docs.oracle.com/en/java/javase/25/docs/api/java.base/java/util/ResourceBundle.Control.html#getNoFallbackControl(java.util.List) > > The test runs JavaDoc with all combinations of supported locales for default locale and `-locale` option, making sure the console output uses the default locale while generated docuentation adheres to the `-locale` option. I assume things like `-locale jp` doesn't work right now in an English environment too, right? ------------- Marked as reviewed by liach (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/28603#pullrequestreview-3531003259 From jjg3 at pobox.com Tue Dec 2 16:19:04 2025 From: jjg3 at pobox.com (Jonathan Gibbons) Date: Tue, 02 Dec 2025 08:19:04 -0800 Subject: RFR: 8372948: Store end positions directly in JCTree In-Reply-To: References: Message-ID: <639ae9cc-527a-40f5-88fb-a5ade5d48ea7@app.fastmail.com> Without looking in detail at this specific proposal, I wonder if you considered the alternative to only store end positions in the subtypes of JCTree that actually "need" them. In other words, you only need store end positions in tree nodes that "end" in a lexical token and not in a child tree node. Effectively, you only need store the end position in tree nodes that would otherwise have entries in the EndPosTable. -- Jon On Tue, Dec 2, 2025, at 8:12 AM, Liam Miller-Cushon wrote: > This change adds a field to `JCTree` to store end positions, instead of using a separate `EndPosTable` map. See also [this compile-dev@ thread](https://mail.openjdk.org/pipermail/compiler-dev/2025-November/032254.html). > > I performed the refactoring in stages, preserving existing semantics at each step. > > There are two known places where this changes existing behaviour that are reflected in changes to tests: > > * `test/langtools/tools/javac/api/TestJavacTask_Lock.java` - this test asserts that calling `JavacTask#parse` first and then calling `#call` or `#parse` second will fail. The assertion that the test is currently expecting is thrown when the `EndPosTable` gets set a second time, and this change means that no longer results in an exception. If desired `JavacTask#parse` could be updated to explicitly check if it is called twice and fail, instead of indirectly relying on the `EndPosTable` for that. > > * `test/langtools/tools/javac/diags/DiagnosticGetEndPosition.java` - there's a comment that 'ideally would be "0", but the positions are not fully set yet', and with the new approach the end position is available to the test, so it resolves the comment > > ------------- > > Commit messages: > - 8372948: Store end positions directly in JCTree > > Changes: https://git.openjdk.org/jdk/pull/28610/files > Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28610&range=00 > Issue: https://bugs.openjdk.org/browse/JDK-8372948 > Stats: 563 lines in 33 files changed: 7 ins; 437 del; 119 mod > Patch: https://git.openjdk.org/jdk/pull/28610.diff > Fetch: git fetch https://git.openjdk.org/jdk.git pull/28610/head:pull/28610 > > PR: https://git.openjdk.org/jdk/pull/28610 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hannesw at openjdk.org Tue Dec 2 16:22:36 2025 From: hannesw at openjdk.org (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=) Date: Tue, 2 Dec 2025 16:22:36 GMT Subject: RFR: 8372708: Javadoc ignores "-locale" and uses default locale for all messages and texts In-Reply-To: References: Message-ID: On Tue, 2 Dec 2025 16:14:11 GMT, Chen Liang wrote: > I assume things like -locale jp doesn't work right now in an English environment too, right? `-locale jp` does work, because resource files are explicitly named, such as `doclets_jp.properties`. It's only the English ones that don't work. Thanks for reviewing! ------------- PR Comment: https://git.openjdk.org/jdk/pull/28603#issuecomment-3602886995 From hannesw at openjdk.org Tue Dec 2 16:25:59 2025 From: hannesw at openjdk.org (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=) Date: Tue, 2 Dec 2025 16:25:59 GMT Subject: Integrated: 8372708: Javadoc ignores "-locale" and uses default locale for all messages and texts In-Reply-To: References: Message-ID: <0lzAoUvRRtf-g8vd5NxSgOqKLUkz1hgE0EcLwBDOE-8=.b4eb4b37-2d99-4a09-9938-66d430165c08@github.com> On Tue, 2 Dec 2025 14:05:10 GMT, Hannes Walln?fer wrote: > Please review a simple change to make the JavaDoc `-locale` option work with English language locales when the system default is a non-English locale supported by JavaDoc. The problem is that root resource bundles such as `standard.properties` are not recognized as English, and [java.util.ResourceBundle][1] will use the system default locale as fallback before returning the root bundle. > > [1]: https://docs.oracle.com/en/java/javase/25/docs/api/java.base/java/util/ResourceBundle.html#default_behavior > > The solution is to provide empty English resource bundles that will use the root bundles as parents. An alternative would be to use a [ResourceBundleProvider][2], but I think the added complexity is not justified for this case. Also, we can't use [ResourceBundle.Control][3] in a named module. > > [2]: https://docs.oracle.com/en/java/javase/25/docs/api/java.base/java/util/spi/ResourceBundleProvider.html > [3]: https://docs.oracle.com/en/java/javase/25/docs/api/java.base/java/util/ResourceBundle.Control.html#getNoFallbackControl(java.util.List) > > The test runs JavaDoc with all combinations of supported locales for default locale and `-locale` option, making sure the console output uses the default locale while generated docuentation adheres to the `-locale` option. This pull request has now been integrated. Changeset: 37d8e05e Author: Hannes Walln?fer URL: https://git.openjdk.org/jdk/commit/37d8e05eccc959b5b5e04b3da848f7de9220b00c Stats: 162 lines in 3 files changed: 162 ins; 0 del; 0 mod 8372708: Javadoc ignores "-locale" and uses default locale for all messages and texts Reviewed-by: liach ------------- PR: https://git.openjdk.org/jdk/pull/28603 From cushon at openjdk.org Tue Dec 2 16:30:49 2025 From: cushon at openjdk.org (Liam Miller-Cushon) Date: Tue, 2 Dec 2025 16:30:49 GMT Subject: RFR: 8372948: Store end positions directly in JCTree In-Reply-To: <639ae9cc-527a-40f5-88fb-a5ade5d48ea7@app.fastmail.com> References: <639ae9cc-527a-40f5-88fb-a5ade5d48ea7@app.fastmail.com> Message-ID: On Tue, 2 Dec 2025 16:21:21 GMT, Jonathan Gibbons wrote: > Without looking in detail at this specific proposal, I wonder if you considered the alternative to only store end positions in the subtypes of JCTree that actually "need" them. In other words, you only need store end positions in tree nodes that "end" in a lexical token and not in a child tree node. Effectively, you only need store the end position in tree nodes that would otherwise have entries in the EndPosTable. Good question--I hadn't investigated that option. It seems do-able, perhaps with a shared interface for subtypes that needed end positions to simplify the handling of them. What tradeoffs do you see here, would only declaring the field on trees that need it be mostly about saving memory? Also is that unique to end positions? Or could javac potentially avoid storing start positions for nodes that don't start with a lexical token as well? ------------- PR Comment: https://git.openjdk.org/jdk/pull/28610#issuecomment-3602921946 From jjg3 at pobox.com Tue Dec 2 16:36:30 2025 From: jjg3 at pobox.com (Jonathan Gibbons) Date: Tue, 02 Dec 2025 08:36:30 -0800 Subject: RFR: 8372948: Store end positions directly in JCTree In-Reply-To: References: <639ae9cc-527a-40f5-88fb-a5ade5d48ea7@app.fastmail.com> Message-ID: > What tradeoffs do you see here, would only declaring the field on trees that need it be mostly about saving memory? Probably, yes, as well as just being a closer equivalent to the existing code. >Also is that unique to end positions? Or could javac potentially avoid storing start positions for nodes that don't start with a lexical token as well? Every JCTree node already has a 'pos' field, representing the position of the first character that is unique to the tree node. That means it is the 'start' position for those nodes that begin with a lexical token, and so no additional field is necessary. The asymmetry between start and end positions is indicative of why there is only an EndPosTable, without any need for a StartPosTable. -- Jon On Tue, Dec 2, 2025, at 8:30 AM, Liam Miller-Cushon wrote: > On Tue, 2 Dec 2025 16:21:21 GMT, Jonathan Gibbons wrote: > > > Without looking in detail at this specific proposal, I wonder if you considered the alternative to only store end positions in the subtypes of JCTree that actually "need" them. In other words, you only need store end positions in tree nodes that "end" in a lexical token and not in a child tree node. Effectively, you only need store the end position in tree nodes that would otherwise have entries in the EndPosTable. > > Good question--I hadn't investigated that option. It seems do-able, perhaps with a shared interface for subtypes that needed end positions to simplify the handling of them. > > What tradeoffs do you see here, would only declaring the field on trees that need it be mostly about saving memory? > > Also is that unique to end positions? Or could javac potentially avoid storing start positions for nodes that don't start with a lexical token as well? > > ------------- > > PR Comment: https://git.openjdk.org/jdk/pull/28610#issuecomment-3602921946 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jjg3 at pobox.com Tue Dec 2 16:41:56 2025 From: jjg3 at pobox.com (Jonathan Gibbons) Date: Tue, 02 Dec 2025 08:41:56 -0800 Subject: RFR: 8372948: Store end positions directly in JCTree In-Reply-To: References: <639ae9cc-527a-40f5-88fb-a5ade5d48ea7@app.fastmail.com> Message-ID: <4b6f2678-9e0c-44fe-88f0-239c1aee290d@app.fastmail.com> I'm not sure a shared interface gets you anything significant, since you cannot inherit a shared field that way. Instead, you could have a `setEndPos` on `JCTree` that is a no-op on subtypes that do not need it, and which sets a locally declared field on subtypes that do need it. -- Jon On Tue, Dec 2, 2025, at 8:30 AM, Liam Miller-Cushon wrote: > Good question--I hadn't investigated that option. It seems do-able, perhaps with a shared interface for subtypes that needed end positions to simplify the handling of them. -------------- next part -------------- An HTML attachment was scrubbed... URL: From cushon at openjdk.org Wed Dec 3 09:47:11 2025 From: cushon at openjdk.org (Liam Miller-Cushon) Date: Wed, 3 Dec 2025 09:47:11 GMT Subject: RFR: 8372948: Store end positions directly in JCTree In-Reply-To: <4b6f2678-9e0c-44fe-88f0-239c1aee290d@app.fastmail.com> References: <4b6f2678-9e0c-44fe-88f0-239c1aee290d@app.fastmail.com> Message-ID: On Tue, 2 Dec 2025 16:43:43 GMT, Jonathan Gibbons wrote: > I'm not sure a shared interface gets you anything significant, since you cannot inherit a shared field that way. Partly I was thinking the interface could make helpers that set end positions type safe, e.g. for the `storeEnd` method in `JavacParser` if we could write something like: protected T storeEnd(T tree, int endpos) { ... } But there are other places that store end positions on a `JCTree` instead of a specific subtype, so that approach only goes so far. > Instead, you could have a `setEndPos` on `JCTree` that is a no-op on subtypes that do not need it, and which sets a locally declared field on subtypes that do need it. I think the set of trees that end positions are stored for is: `JCAnnotation`, `JCArrayAccess`, `JCArrayTypeTree`, `JCAssert`, `JCAssign`, `JCBinary`, `JCBindingPattern`, `JCBlock`, `JCBreak`, `JCCase`, `JCClassDecl`, `JCConstantCaseLabel`, `JCContinue`, `JCDefaultCaseLabel`, `JCDoWhileLoop`, `JCExports`, `JCExpressionStatement`, `JCFieldAccess`, `JCIdent`, `JCIf`, `JCImport`, `JCLambda`, `JCLiteral`, `JCMemberReference`, `JCMethodDecl`, `JCMethodInvocation`, `JCModifiers`, `JCModuleDecl`, `JCNewArray`, `JCNewClass`, `JCOpens`, `JCPackageDecl`, `JCParens`, `JCPatternCaseLabel`, `JCPrimitiveTypeTree`, `JCProvides`, `JCRequires`, `JCReturn`, `JCSkip`, `JCSwitch`, `JCThrow`, `JCTypeApply`, `JCTypeParameter`, `JCTypeUnion`, `JCUnary`, `JCUses`, `JCVariableDecl`, `JCWildcard`, `TypeBoundKind` I got that by instrumenting `SimpleEndPosTable` and building the JDK, it's possible it missed a few. And then we could add the following snippet to all of those classes: private int endpos; public int getEndPos() { return endpos; } public void setEndPos(int endpso) { this.endpos = endpos; } My feeling is that perhaps it's worth the extra memory to not have to duplicate that code for all of those `JCTree`s, and also to avoid the risk of trying to store end positions on trees that don't support it. But I am open to making those changes if there's a preference for it. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28610#issuecomment-3605955451 From mcimadamore at openjdk.org Wed Dec 3 19:13:30 2025 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Wed, 3 Dec 2025 19:13:30 GMT Subject: RFR: 8372948: Store end positions directly in JCTree In-Reply-To: References: <4b6f2678-9e0c-44fe-88f0-239c1aee290d@app.fastmail.com> Message-ID: On Wed, 3 Dec 2025 09:44:44 GMT, Liam Miller-Cushon wrote: > > My feeling is that perhaps it's worth the extra memory to not have to duplicate that code for all of those `JCTree`s, and also to avoid the risk of trying to store end positions on trees that don't support it. But I am open to making those changes if there's a preference for it. I tend to agree with your assessment. Having code duplication is kind of bad, unless we can somehow "common" the code -- and that's is probably possible, but not straightforward due the JCStatement vs. JCExpression split (and also JCFunctionalExpression). Also, it's hard to estimate which trees might need this... for instance the trees you show in your analysis don't include some patterns (e.g. record patterns), but that's just because probably there's no record pattern in the JDK, not because the end pos is not useful there. If we exclude JCSkip and maybe LetExpr (as that's only used by the backend), I'm not sure there's much stuff that actually doesn't require an end position? Perhaps with some keywords like `break`, `continue`, ... we might be able to infer the end pos (given it's just start pos + number of chars in the keyword). But not sure how much we are willing to bend the code for special cases like these? One more interesting experiment could be to try to enable end position in all trees, then run the JDK build and compare with mainline, to see what the memory usage looks like (maybe enabling `-verbose:gc` and looking where it peaks). ------------- PR Comment: https://git.openjdk.org/jdk/pull/28610#issuecomment-3608408811 From jjg3 at pobox.com Wed Dec 3 19:54:34 2025 From: jjg3 at pobox.com (Jonathan Gibbons) Date: Wed, 03 Dec 2025 11:54:34 -0800 Subject: RFR: 8372948: Store end positions directly in JCTree In-Reply-To: References: <4b6f2678-9e0c-44fe-88f0-239c1aee290d@app.fastmail.com> Message-ID: On Wed, Dec 3, 2025, at 1:47 AM, Liam Miller-Cushon wrote: > My feeling is that perhaps it's worth the extra memory to not have to duplicate that code for all of those `JCTree`s, and also to avoid the risk of trying to store end positions on trees that don't support it. But I am open to making those changes if there's a preference for it. Yeah, you've done the analysis I think I would have done. And, it does seem l;ke there has been a fundamental shift in the desire/need to keep end positions around since times past. Simplicity says to go with a field in every JCTree these days. A more informed opinion would probably require more detailed analysis. I note that you can offset the space of the endPos fields that are not strictly required against the savings of the EndPosTable itself. I also wonder, just for curiousity sake, whether this would help with some of the (uncommon) problem cases in the existing situation, where the endPos of a non-terminal end element might not be the endPos of the entire tree -- IIRC, the issue was with C-style array declarations. The one test I would suggest to add (if necessary) in the "tree position" set of tests would be to verify that the new field is set in all applicable cases, with maybe some thought being given to synthetic nodes. -- Jon -------------- next part -------------- An HTML attachment was scrubbed... URL: From jjg3 at pobox.com Wed Dec 3 19:56:45 2025 From: jjg3 at pobox.com (Jonathan Gibbons) Date: Wed, 03 Dec 2025 11:56:45 -0800 Subject: RFR: 8372948: Store end positions directly in JCTree In-Reply-To: References: <4b6f2678-9e0c-44fe-88f0-239c1aee290d@app.fastmail.com> Message-ID: <2ad5ebc7-9d1a-4eb1-affe-ee04a1db9919@app.fastmail.com> On Wed, Dec 3, 2025, at 11:13 AM, Maurizio Cimadamore wrote: > Perhaps with some keywords like `break`, `continue`, ... we might be able to infer the end pos (given it's just start pos + number of chars in the keyword). But not sure how much we are willing to bend the code for special cases like these? Doesn't the endPos records the position of the semicolon, not the end of the keyword? -- Jon -------------- next part -------------- An HTML attachment was scrubbed... URL: From jjg3 at pobox.com Wed Dec 3 20:02:46 2025 From: jjg3 at pobox.com (Jonathan Gibbons) Date: Wed, 03 Dec 2025 12:02:46 -0800 Subject: RFR: 8372948: Store end positions directly in JCTree In-Reply-To: <2ad5ebc7-9d1a-4eb1-affe-ee04a1db9919@app.fastmail.com> References: <4b6f2678-9e0c-44fe-88f0-239c1aee290d@app.fastmail.com> <2ad5ebc7-9d1a-4eb1-affe-ee04a1db9919@app.fastmail.com> Message-ID: <7eb48261-03f9-448f-9124-496ad2e06e9b@app.fastmail.com> On Wed, Dec 3, 2025, at 11:56 AM, Jonathan Gibbons wrote: > > > On Wed, Dec 3, 2025, at 11:13 AM, Maurizio Cimadamore wrote: >> Perhaps with some keywords like `break`, `continue`, ... we might be able to infer the end pos (given it's just start pos + number of chars in the keyword). But not sure how much we are willing to bend the code for special cases like these? > > Doesn't the endPos records the position of the semicolon, not the end of the keyword? > > -- Jon A useful heuristic is to check the `visit...` methods in `JCPretty`. If there is a call to `print(String)` or `print(char)` before the `} catch (IOException` then the node should have an endPos. In other words, an endPos is required for all nodes that end in a specific lexical token. For example, compare this from `visitLambda` printExpr(tree.body); } catch (IOException e) { and this from `visitParens` print(')'); } catch (IOException e) { -------------- next part -------------- An HTML attachment was scrubbed... URL: From cushon at openjdk.org Thu Dec 4 14:09:26 2025 From: cushon at openjdk.org (Liam Miller-Cushon) Date: Thu, 4 Dec 2025 14:09:26 GMT Subject: RFR: 8372948: Store end positions directly in JCTree In-Reply-To: References: <4b6f2678-9e0c-44fe-88f0-239c1aee290d@app.fastmail.com> Message-ID: On Wed, 3 Dec 2025 19:11:14 GMT, Maurizio Cimadamore wrote: > One more interesting experiment could be to try to enable end position in all trees, then run the JDK build and compare with mainline, to see what the memory usage looks like (maybe enabling -verbose:gc and looking where it peaks). I attempted this experiment. I ran configure with `--disable-javac-server` and added `-verbose:gc` to the javac args with the change below. Then I made trivial edits to `src/java.base/share/classes/java/lang/String.java` and rebuilt. With this PR the output was something like Compiling up to 3385 files for java.base [0.003s][info][gc] Using G1 [0.239s][info][gc] GC(0) Pause Young (Normal) (G1 Evacuation Pause) 34M->4M(64M) 2.704ms [0.415s][info][gc] GC(1) Pause Young (Normal) (G1 Evacuation Pause) 31M->10M(64M) 4.419ms [0.531s][info][gc] GC(2) Pause Young (Normal) (G1 Evacuation Pause) 37M->16M(64M) 4.672ms [0.568s][info][gc] GC(3) Pause Young (Concurrent Start) (Metadata GC Threshold) 24M->18M(64M) 2.825ms [0.568s][info][gc] GC(4) Concurrent Mark Cycle [0.573s][info][gc] GC(4) Pause Remark 19M->19M(64M) 1.349ms [0.575s][info][gc] GC(4) Pause Cleanup 19M->19M(64M) 0.007ms [0.575s][info][gc] GC(4) Concurrent Mark Cycle 6.227ms And without these changes, it looks like it peaked at 36M instead of 37M [info][gc] GC(2) Pause Young (Normal) (G1 Evacuation Pause) 36M->16M(64M) --- diff --git a/make/common/JavaCompilation.gmk b/make/common/JavaCompilation.gmk index 33f5d10535a..e9a800bce5a 100644 --- a/make/common/JavaCompilation.gmk +++ b/make/common/JavaCompilation.gmk @@ -254,7 +254,7 @@ define SetupJavaCompilationBody javacserver.Main --conf=$$($1_JAVAC_SERVER_CONFIG) else # No javac server - $1_JAVAC := $$(INTERIM_LANGTOOLS_ARGS) -m jdk.compiler.interim/com.sun.tools.javac.Main + $1_JAVAC := -verbose:gc $$(INTERIM_LANGTOOLS_ARGS) -m jdk.compiler.interim/com.sun.tools.javac.Main ifeq ($$($1_SMALL_JAVA), true) $1_JAVAC_CMD := $$(JAVA_SMALL) $$($1_JAVA_FLAGS) $$($1_JAVAC) ------------- PR Comment: https://git.openjdk.org/jdk/pull/28610#issuecomment-3612431977 From cushon at openjdk.org Tue Dec 9 20:49:50 2025 From: cushon at openjdk.org (Liam Miller-Cushon) Date: Tue, 9 Dec 2025 20:49:50 GMT Subject: RFR: 8372948: Store end positions directly in JCTree [v2] In-Reply-To: References: Message-ID: <4Z4TrcNpEYWdduRS8Z11mQGMmbb1Qqwka_RcYuW7H7U=.b6b71c6f-b815-4c14-b27c-a149b05a3253@github.com> > This change adds a field to `JCTree` to store end positions, instead of using a separate `EndPosTable` map. See also [this compile-dev@ thread](https://mail.openjdk.org/pipermail/compiler-dev/2025-November/032254.html). > > I performed the refactoring in stages, preserving existing semantics at each step. > > There are two known places where this changes existing behaviour that are reflected in changes to tests: > > * `test/langtools/tools/javac/api/TestJavacTask_Lock.java` - this test asserts that calling `JavacTask#parse` first and then calling `#call` or `#parse` second will fail. The assertion that the test is currently expecting is thrown when the `EndPosTable` gets set a second time, and this change means that no longer results in an exception. If desired `JavacTask#parse` could be updated to explicitly check if it is called twice and fail, instead of indirectly relying on the `EndPosTable` for that. > > * `test/langtools/tools/javac/diags/DiagnosticGetEndPosition.java` - there's a comment that 'ideally would be "0", but the positions are not fully set yet', and with the new approach the end position is available to the test, so it resolves the comment Liam Miller-Cushon 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 three additional commits since the last revision: - Update assertion for test/langtools/tools/javac/diags/DiagnosticGetEndPosition.java - Merge remote-tracking branch 'origin/master' into JDK-8372948 - 8372948: Store end positions directly in JCTree ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28610/files - new: https://git.openjdk.org/jdk/pull/28610/files/cd10d5a0..0c8e996c Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28610&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28610&range=00-01 Stats: 25966 lines in 503 files changed: 17838 ins; 6154 del; 1974 mod Patch: https://git.openjdk.org/jdk/pull/28610.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28610/head:pull/28610 PR: https://git.openjdk.org/jdk/pull/28610 From cushon at openjdk.org Tue Dec 9 23:00:59 2025 From: cushon at openjdk.org (Liam Miller-Cushon) Date: Tue, 9 Dec 2025 23:00:59 GMT Subject: RFR: 8372948: Store end positions directly in JCTree [v3] In-Reply-To: References: Message-ID: > This change adds a field to `JCTree` to store end positions, instead of using a separate `EndPosTable` map. See also [this compile-dev@ thread](https://mail.openjdk.org/pipermail/compiler-dev/2025-November/032254.html). > > I performed the refactoring in stages, preserving existing semantics at each step. > > There are two known places where this changes existing behaviour that are reflected in changes to tests: > > * `test/langtools/tools/javac/api/TestJavacTask_Lock.java` - this test asserts that calling `JavacTask#parse` first and then calling `#call` or `#parse` second will fail. The assertion that the test is currently expecting is thrown when the `EndPosTable` gets set a second time, and this change means that no longer results in an exception. If desired `JavacTask#parse` could be updated to explicitly check if it is called twice and fail, instead of indirectly relying on the `EndPosTable` for that. > > * `test/langtools/tools/javac/diags/DiagnosticGetEndPosition.java` - there's a comment that 'ideally would be "0", but the positions are not fully set yet', and with the new approach the end position is available to the test, so it resolves the comment Liam Miller-Cushon has updated the pull request incrementally with one additional commit since the last revision: Debug DiagnosticGetEndPosition.java on windows ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28610/files - new: https://git.openjdk.org/jdk/pull/28610/files/0c8e996c..6c5665cb Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28610&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28610&range=01-02 Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/28610.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28610/head:pull/28610 PR: https://git.openjdk.org/jdk/pull/28610 From cushon at openjdk.org Wed Dec 10 01:06:53 2025 From: cushon at openjdk.org (Liam Miller-Cushon) Date: Wed, 10 Dec 2025 01:06:53 GMT Subject: RFR: 8372948: Store end positions directly in JCTree [v4] In-Reply-To: References: Message-ID: > This change adds a field to `JCTree` to store end positions, instead of using a separate `EndPosTable` map. See also [this compile-dev@ thread](https://mail.openjdk.org/pipermail/compiler-dev/2025-November/032254.html). > > I performed the refactoring in stages, preserving existing semantics at each step. > > There are two known places where this changes existing behaviour that are reflected in changes to tests: > > * `test/langtools/tools/javac/api/TestJavacTask_Lock.java` - this test asserts that calling `JavacTask#parse` first and then calling `#call` or `#parse` second will fail. The assertion that the test is currently expecting is thrown when the `EndPosTable` gets set a second time, and this change means that no longer results in an exception. If desired `JavacTask#parse` could be updated to explicitly check if it is called twice and fail, instead of indirectly relying on the `EndPosTable` for that. > > * `test/langtools/tools/javac/diags/DiagnosticGetEndPosition.java` - there's a comment that 'ideally would be "0", but the positions are not fully set yet', and with the new approach the end position is available to the test, so it resolves the comment Liam Miller-Cushon has updated the pull request incrementally with one additional commit since the last revision: Fix DiagnosticGetEndPosition on windows ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28610/files - new: https://git.openjdk.org/jdk/pull/28610/files/6c5665cb..a86c0446 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28610&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28610&range=02-03 Stats: 7 lines in 1 file changed: 2 ins; 0 del; 5 mod Patch: https://git.openjdk.org/jdk/pull/28610.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28610/head:pull/28610 PR: https://git.openjdk.org/jdk/pull/28610 From vyazici at openjdk.org Thu Dec 11 12:25:21 2025 From: vyazici at openjdk.org (Volkan Yazici) Date: Thu, 11 Dec 2025 12:25:21 GMT Subject: RFR: 8372661: Add a null-safe static factory method to "jdk.test.lib.net.SimpleSSLContext" Message-ID: Overhauls `SimpleSSLContext` to remove the need for null checks at the call site, and to accept a key store file search path, which removes the need to copy-paste `SimpleSSLContext` just to change the search path. ### Tips for reviewers 1. Start from `SimpleSSLContext.java` 2. See how `test/jdk/java/net/httpclient/whitebox/java.net.http/jdk/internal/net/http/SimpleSSLContext.java` is renamed to `test/jdk/java/net/httpclient/whitebox/java.net.http/jdk/internal/net/http/SimpleSSLContextWhiteboxAdapter.java` and how `@compile/module=java.net.http .../SimpleSSLContext.java` JTreg tag is used to inject `SimpleSSLContext` ------------- Commit messages: - Overhaul `SimpleSSLContext` and its usages Changes: https://git.openjdk.org/jdk/pull/28765/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28765&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8372661 Stats: 1131 lines in 205 files changed: 83 ins; 712 del; 336 mod Patch: https://git.openjdk.org/jdk/pull/28765.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28765/head:pull/28765 PR: https://git.openjdk.org/jdk/pull/28765 From vyazici at openjdk.org Thu Dec 11 12:25:22 2025 From: vyazici at openjdk.org (Volkan Yazici) Date: Thu, 11 Dec 2025 12:25:22 GMT Subject: RFR: 8372661: Add a null-safe static factory method to "jdk.test.lib.net.SimpleSSLContext" In-Reply-To: References: Message-ID: <-_8Armb1O6HfaLmE8DIlpWHLR1cxUpNvJr2uruKX8ho=.ebd3c950-5e39-4300-ae1c-2baadcaeaf98@github.com> On Thu, 11 Dec 2025 09:45:54 GMT, Volkan Yazici wrote: > Overhauls `SimpleSSLContext` to remove the need for null checks at the call site, and to accept a key store file search path, which removes the need to copy-paste `SimpleSSLContext` just to change the search path. > > ### Tips for reviewers > > 1. Start from `SimpleSSLContext.java` > 2. See how `test/jdk/java/net/httpclient/whitebox/java.net.http/jdk/internal/net/http/SimpleSSLContext.java` is renamed to `test/jdk/java/net/httpclient/whitebox/java.net.http/jdk/internal/net/http/SimpleSSLContextWhiteboxAdapter.java` and how `@compile/module=java.net.http .../SimpleSSLContext.java` JTreg tag is used to inject `SimpleSSLContext` Tier1-2 is clear on 326fd60e352. test/lib/jdk/test/lib/net/SimpleSSLContext.java line 1: > 1: /* [JDK-8372661] suggests `newSSLContext` as the method name, though I opted for `findSSLContext` and `loadSSLContext` method names, because 1. `newSSLContext` clashes with IDEs auto-completion when one types `ClassName.new` 2. `findSSLContext` makes the intent more clear, because we indeed search for a key store file, and then load it 3. `loadSSLContext` makes the intent more clear, because it only and only tries to load an `SSLContext` from the provided key store file; it doesn't do a search or anything else. [JDK-8372661]: https://bugs.openjdk.org/browse/JDK-8372661 test/lib/jdk/test/lib/net/SimpleSSLContext.java line 77: > 75: * one cannot be loaded > 76: */ > 77: public static SSLContext findSSLContext(String keyStoreFileRelPath, String protocol) { This is made public to enable loading a key store file from alternative locations, which is required by whitebox tests. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28765#issuecomment-3641655710 PR Review Comment: https://git.openjdk.org/jdk/pull/28765#discussion_r2609917169 PR Review Comment: https://git.openjdk.org/jdk/pull/28765#discussion_r2609927102 From dfuchs at openjdk.org Thu Dec 11 13:06:36 2025 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Thu, 11 Dec 2025 13:06:36 GMT Subject: RFR: 8372661: Add a null-safe static factory method to "jdk.test.lib.net.SimpleSSLContext" In-Reply-To: References: Message-ID: On Thu, 11 Dec 2025 09:45:54 GMT, Volkan Yazici wrote: > Overhauls `SimpleSSLContext` to remove the need for null checks at the call site, and to accept a key store file search path, which removes the need to copy-paste `SimpleSSLContext` just to change the search path. > > ### Tips for reviewers > > 1. Start from `SimpleSSLContext.java` > 2. See how `test/jdk/java/net/httpclient/whitebox/java.net.http/jdk/internal/net/http/SimpleSSLContext.java` is renamed to `test/jdk/java/net/httpclient/whitebox/java.net.http/jdk/internal/net/http/SimpleSSLContextWhiteboxAdapter.java` and how `@compile/module=java.net.http .../SimpleSSLContext.java` JTreg tag is used to inject `SimpleSSLContext` I would prefer to split this PR into two fixes: - a first fix that simply adds the new API to SimpleSSLContext, without removing the old API. - a second fix that do all the rest: remove the old API and update the tests. This would allow us to easily backport the first fix, and new tests would not need adaptation when they are later being backported provided that the first fix has been backported first. You could enjoy using dependent PRs for this :-) ------------- PR Comment: https://git.openjdk.org/jdk/pull/28765#issuecomment-3641822078 From hannes.wallnoefer at oracle.com Thu Dec 11 16:30:26 2025 From: hannes.wallnoefer at oracle.com (Hannes Wallnoefer) Date: Thu, 11 Dec 2025 16:30:26 +0000 Subject: Feature Request -- Add tooltip on hover for the textboxes and their labels In-Reply-To: References: Message-ID: <3CEBC756-EA23-45A4-8262-F38469313979@oracle.com> Hello David, Sorry for the late reply. I think your suggestion makes sense. Another element that could benefit from tooltips are the links in the breadcrumbs navigation. I?ve filed an issue for this: https://bugs.openjdk.org/browse/JDK-8373526 Hannes On 22.11.2025, at 22:02, David Alayachew wrote: Hello @javadoc-dev at openjdk.org, I have poor vision, which means I constantly have the scale set to a high percentage on my screen. Furthermore, I use Windows Magnifier (press WindowsKey simultaneously with "+" or "-" to try it out yourself!) to zoom in further, if the OS and browser zoom is not enough. Browser zoom tends to break most websites, so that's usually my last resort. Most of the Javadoc page either has word wrap or scroll bars to accomodate me, which are acceptable compromises. However, the 2 textboxes on the top right (Search documentation) and top left (Filter contents) tend to be cut off, such that their directions ("type /"and "type .", respectively) are not visible or cut off for me. In order to read them, I have to zoom my browser all the way out, then zoom my Windows Magnifier all the way in, causing me to mess up my presets, making things very inconvenient. Could we add tooltips to both text boxes, such that, on hover, they show, via tooltip, the directions? I'm fine if the tooltip is only active if the directions are cut off, like they are for me. Thank you for your time and consideration. David Alayachew -------------- next part -------------- An HTML attachment was scrubbed... URL: From vyazici at openjdk.org Thu Dec 11 18:13:26 2025 From: vyazici at openjdk.org (Volkan Yazici) Date: Thu, 11 Dec 2025 18:13:26 GMT Subject: RFR: 8372661: Add a null-safe static factory method to "jdk.test.lib.net.SimpleSSLContext" [v2] In-Reply-To: References: Message-ID: > Overhauls `SimpleSSLContext` to remove the need for null checks at the call site, and to accept a key store file search path, which removes the need to copy-paste `SimpleSSLContext` just to change the search path. > > ### Tips for reviewers > > 1. Start from `SimpleSSLContext.java` > 2. See how `test/jdk/java/net/httpclient/whitebox/java.net.http/jdk/internal/net/http/SimpleSSLContext.java` is renamed to `test/jdk/java/net/httpclient/whitebox/java.net.http/jdk/internal/net/http/SimpleSSLContextWhiteboxAdapter.java` and how `@compile/module=java.net.http .../SimpleSSLContext.java` JTreg tag is used to inject `SimpleSSLContext` Volkan Yazici has updated the pull request incrementally with one additional commit since the last revision: Reverted all changes and only kept `SimpleSSLContext` enhancements ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28765/files - new: https://git.openjdk.org/jdk/pull/28765/files/326fd60e..d4c9b312 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28765&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28765&range=00-01 Stats: 1093 lines in 205 files changed: 734 ins; 54 del; 305 mod Patch: https://git.openjdk.org/jdk/pull/28765.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28765/head:pull/28765 PR: https://git.openjdk.org/jdk/pull/28765 From vyazici at openjdk.org Thu Dec 11 18:17:49 2025 From: vyazici at openjdk.org (Volkan Yazici) Date: Thu, 11 Dec 2025 18:17:49 GMT Subject: RFR: 8372661: Add a null-safe static factory method to "jdk.test.lib.net.SimpleSSLContext" In-Reply-To: References: Message-ID: On Thu, 11 Dec 2025 13:01:53 GMT, Daniel Fuchs wrote: >> Overhauls `SimpleSSLContext` to remove the need for null checks at the call site, and to accept a key store file search path, which removes the need to copy-paste `SimpleSSLContext` just to change the search path. >> >> ### Tips for reviewers >> >> 1. Start from `SimpleSSLContext.java` >> 2. See how `test/jdk/java/net/httpclient/whitebox/java.net.http/jdk/internal/net/http/SimpleSSLContext.java` is renamed to `test/jdk/java/net/httpclient/whitebox/java.net.http/jdk/internal/net/http/SimpleSSLContextWhiteboxAdapter.java` and how `@compile/module=java.net.http .../SimpleSSLContext.java` JTreg tag is used to inject `SimpleSSLContext` > > I would prefer to split this PR into two fixes: > > - a first fix that simply adds the new API to SimpleSSLContext, without removing the old API. > - a second fix that do all the rest: remove the old API and update the tests. > > This would allow us to easily backport the first fix, and new tests would not need adaptation when they are later being backported provided that the first fix has been backported first. > > You could enjoy using dependent PRs for this :-) @dfuch, I've updated the ticket and this PR as follows: 1. Pushed d4c9b3129fc reverting all changes and only keeping `SimpleSSLContext` enhancements, and updated the parent ticket description (i.e., [JDK-8372661]) to reflect this. 2. Created [JDK-8373515] for migrating `test/jdk/java/net/httpclient/` 3. Created [JDK-8373537] for migrating `test/jdk/com/sun/net/httpserver/` 4. Created [JDK-8373538] for migrating the rest, and removing the unused `SimpleSSLContext` methods [JDK-8372661]: https://bugs.openjdk.org/browse/JDK-8372661 [JDK-8373515]: https://bugs.openjdk.org/browse/JDK-8373515 [JDK-8373537]: https://bugs.openjdk.org/browse/JDK-8373537 [JDK-8373538]: https://bugs.openjdk.org/browse/JDK-8373538 ------------- PR Comment: https://git.openjdk.org/jdk/pull/28765#issuecomment-3643196386 From davidalayachew at gmail.com Fri Dec 12 20:54:27 2025 From: davidalayachew at gmail.com (David Alayachew) Date: Fri, 12 Dec 2025 15:54:27 -0500 Subject: Feature Request -- Add tooltip on hover for the textboxes and their labels In-Reply-To: <3CEBC756-EA23-45A4-8262-F38469313979@oracle.com> References: <3CEBC756-EA23-45A4-8262-F38469313979@oracle.com> Message-ID: Ty vm @Hannes Wallnoefer , the jbs issue looks great. On Thu, Dec 11, 2025, 11:30?AM Hannes Wallnoefer < hannes.wallnoefer at oracle.com> wrote: > Hello David, > > Sorry for the late reply. I think your suggestion makes sense. Another > element that could benefit from tooltips are the links in the breadcrumbs > navigation. > > I?ve filed an issue for this: https://bugs.openjdk.org/browse/JDK-8373526 > > Hannes > > > On 22.11.2025, at 22:02, David Alayachew wrote: > > Hello @javadoc-dev at openjdk.org , > > I have poor vision, which means I constantly have the scale set to a high > percentage on my screen. Furthermore, I use Windows Magnifier (press > WindowsKey simultaneously with "+" or "-" to try it out yourself!) to zoom > in further, if the OS and browser zoom is not enough. Browser zoom tends to > break most websites, so that's usually my last resort. > > Most of the Javadoc page either has word wrap or scroll bars to accomodate > me, which are acceptable compromises. > > However, the 2 textboxes on the top right (Search documentation) and top > left (Filter contents) tend to be cut off, such that their directions > ("type /"and "type .", respectively) are not visible or cut off for me. > > In order to read them, I have to zoom my browser all the way out, then > zoom my Windows Magnifier all the way in, causing me to mess up my presets, > making things very inconvenient. > > Could we add tooltips to both text boxes, such that, on hover, they show, > via tooltip, the directions? I'm fine if the tooltip is only active if the > directions are cut off, like they are for me. > > Thank you for your time and consideration. > David Alayachew > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dnguyen at openjdk.org Fri Dec 12 21:40:21 2025 From: dnguyen at openjdk.org (Damon Nguyen) Date: Fri, 12 Dec 2025 21:40:21 GMT Subject: RFR: 8373119: JDK 26 RDP1 L10n resource files update Message-ID: Open l10n drop. Files have been updated with translated versions. ------------- Commit messages: - Fix single quote - Initial commit Changes: https://git.openjdk.org/jdk/pull/28802/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28802&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8373119 Stats: 1141 lines in 52 files changed: 706 ins; 159 del; 276 mod Patch: https://git.openjdk.org/jdk/pull/28802.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28802/head:pull/28802 PR: https://git.openjdk.org/jdk/pull/28802 From dnguyen at openjdk.org Fri Dec 12 21:40:23 2025 From: dnguyen at openjdk.org (Damon Nguyen) Date: Fri, 12 Dec 2025 21:40:23 GMT Subject: RFR: 8373119: JDK 26 RDP1 L10n resource files update In-Reply-To: References: Message-ID: On Fri, 12 Dec 2025 20:43:36 GMT, Damon Nguyen wrote: > Open l10n drop. Files have been updated with translated versions. src/java.base/share/classes/sun/security/util/resources/security_de.properties line 46: > 44: invalid.null.action.provided=Ung?ltige Nullaktion angegeben > 45: invalid.null.Class.provided=Ung?ltige Nullklasse angegeben > 46: Subject.=Subject:\n This change reverts what was previously changed in the last l10n drop. There was a request to change word "Subject" to "Subjekt" at the time, and this was manually adjusted. This issue was brought up to the translation team but was ultimately rejected. So, to align with upstream, I will leave this as is. src/jdk.compiler/share/classes/com/sun/tools/javac/resources/javac_zh_CN.properties line 209: > 207: javac.opt.prefer=??????, ??????????????????? > 208: # L10N: do not localize: ''preview'' > 209: javac.opt.preview=?????????\n???????lint ???\n?? -source ? --release ????? I have spotted that this Chinese localization is missing the ''preview'' mentioned in the above comment. I will submit this issue to the localization team. If the fix comes in time, I will add it to this drop. Otherwise, I will add it to the next possible drop. Alternatively, if anyone has a suggestion for how to correct this, I'm open to incorporate it. src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/resources/doclets_de.properties line 230: > 228: doclet.search_in_documentation=In Dokumentation suchen > 229: doclet.search_reset=Zur?cksetzen > 230: doclet.Member=Member Similar to above with security.properties, this change was brought up to the localization team and rejected. I intend to keep this as is for the same reason. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28802#discussion_r2615537125 PR Review Comment: https://git.openjdk.org/jdk/pull/28802#discussion_r2615533659 PR Review Comment: https://git.openjdk.org/jdk/pull/28802#discussion_r2615538518 From naoto at openjdk.org Fri Dec 12 22:07:51 2025 From: naoto at openjdk.org (Naoto Sato) Date: Fri, 12 Dec 2025 22:07:51 GMT Subject: RFR: 8373119: JDK 26 RDP1 L10n resource files update In-Reply-To: References: Message-ID: On Fri, 12 Dec 2025 20:45:34 GMT, Damon Nguyen wrote: >> Open l10n drop. Files have been updated with translated versions. > > src/jdk.compiler/share/classes/com/sun/tools/javac/resources/javac_zh_CN.properties line 209: > >> 207: javac.opt.prefer=??????, ??????????????????? >> 208: # L10N: do not localize: ''preview'' >> 209: javac.opt.preview=?????????\n???????lint ???\n?? -source ? --release ????? > > I have spotted that this Chinese localization is missing the ''preview'' mentioned in the above comment. I will submit this issue to the localization team. If the fix comes in time, I will add it to this drop. Otherwise, I will add it to the next possible drop. Alternatively, if anyone has a suggestion for how to correct this, I'm open to incorporate it. Since this is an apparent l10n mistake, I'd just replace "??" with ''preview'' ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28802#discussion_r2615696431 From dnguyen at openjdk.org Fri Dec 12 22:34:10 2025 From: dnguyen at openjdk.org (Damon Nguyen) Date: Fri, 12 Dec 2025 22:34:10 GMT Subject: RFR: 8373119: JDK 26 RDP1 L10n resource files update [v2] In-Reply-To: References: Message-ID: > Open l10n drop. Files have been updated with translated versions. Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision: Revert Chinese preview change ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28802/files - new: https://git.openjdk.org/jdk/pull/28802/files/6a280e17..83100f94 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28802&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28802&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/28802.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28802/head:pull/28802 PR: https://git.openjdk.org/jdk/pull/28802 From dnguyen at openjdk.org Fri Dec 12 22:34:12 2025 From: dnguyen at openjdk.org (Damon Nguyen) Date: Fri, 12 Dec 2025 22:34:12 GMT Subject: RFR: 8373119: JDK 26 RDP1 L10n resource files update [v2] In-Reply-To: References: Message-ID: <4jc-NxobKK8qRpYSujoOwgvRw7kj4mZVbkNnaf6X--I=.77f68671-384e-4168-9bd6-71566817ad55@github.com> On Fri, 12 Dec 2025 22:04:36 GMT, Naoto Sato wrote: >> src/jdk.compiler/share/classes/com/sun/tools/javac/resources/javac_zh_CN.properties line 209: >> >>> 207: javac.opt.prefer=??????, ??????????????????? >>> 208: # L10N: do not localize: ''preview'' >>> 209: javac.opt.preview=?????????\n???????lint ???\n?? -source ? --release ????? >> >> I have spotted that this Chinese localization is missing the ''preview'' mentioned in the above comment. I will submit this issue to the localization team. If the fix comes in time, I will add it to this drop. Otherwise, I will add it to the next possible drop. Alternatively, if anyone has a suggestion for how to correct this, I'm open to incorporate it. > > Since this is an apparent l10n mistake, I'd just replace "??" with ''preview'' Thanks. Updated! ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28802#discussion_r2615744326 From jlu at openjdk.org Fri Dec 12 22:51:52 2025 From: jlu at openjdk.org (Justin Lu) Date: Fri, 12 Dec 2025 22:51:52 GMT Subject: RFR: 8373119: JDK 26 RDP1 L10n resource files update [v2] In-Reply-To: References: Message-ID: On Fri, 12 Dec 2025 22:34:10 GMT, Damon Nguyen wrote: >> Open l10n drop. Files have been updated with translated versions. > > Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision: > > Revert Chinese preview change Identified some errors/inconsistencies you might bring to the translation team. src/jdk.compiler/share/classes/com/sun/tools/javac/resources/javac_de.properties line 63: > 61: javac.opt.source=Liefert Quellkompatibilit?t mit dem angegebenen Release von Java SE.\nUnterst?tzte Releases: \n {0} > 62: javac.opt.Werror=Kompilierung beenden, wenn Warnungen auftreten > 63: javac.opt.arg.Werror=(,)* This value is translated for `de`, but not for `ja` or `zh_CN`. It would be ideal for to have consistency. src/jdk.jlink/share/classes/jdk/tools/jlink/resources/plugins_de.properties line 173: > 171: plugin.opt.disable-plugin=\ --disable-plugin Deaktiviert das angegebene Plug-in > 172: > 173: plugin.opt.compress=\ --compress Komprimiert alle Ressourcen im Ausgabeimage:\n Zul?ssige Werte:\n zip-'{0-9}', wobei "zip-0" f?r keine Komprimierung\n und "zip-9" f?r die beste Komprimierung steht.\n Standardwert ist "zip-6."\n Veraltete Werte, die in einem zuk?nftigen Release entfernt werden:\n 0: Keine Komprimierung. Verwenden Sie stattdessen "zip-0".\n 1: Gemeinsame Verwendung konstanter Zeichenfolgen\n 2: ZIP. Verwenden Sie stattdessen "zip-6". `` is translated here, but untouched in `ja` and `zh_CN`. Also it is odd the period was inserted within the `"zip-6"` string. -> `"zip-6."` ------------- PR Review: https://git.openjdk.org/jdk/pull/28802#pullrequestreview-3573817418 PR Review Comment: https://git.openjdk.org/jdk/pull/28802#discussion_r2615760993 PR Review Comment: https://git.openjdk.org/jdk/pull/28802#discussion_r2615770109 From dnguyen at openjdk.org Fri Dec 12 23:00:55 2025 From: dnguyen at openjdk.org (Damon Nguyen) Date: Fri, 12 Dec 2025 23:00:55 GMT Subject: RFR: 8373119: JDK 26 RDP1 L10n resource files update [v2] In-Reply-To: References: Message-ID: On Fri, 12 Dec 2025 22:38:34 GMT, Justin Lu wrote: >> Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision: >> >> Revert Chinese preview change > > src/jdk.compiler/share/classes/com/sun/tools/javac/resources/javac_de.properties line 63: > >> 61: javac.opt.source=Liefert Quellkompatibilit?t mit dem angegebenen Release von Java SE.\nUnterst?tzte Releases: \n {0} >> 62: javac.opt.Werror=Kompilierung beenden, wenn Warnungen auftreten >> 63: javac.opt.arg.Werror=(,)* > > This value is translated for `de`, but not for `ja` or `zh_CN`. It would be ideal for to have consistency. Thanks for finding this. I agree. I'll report this to the translation team so the Japanese and Chinese versions can be picked up as well. If it's not fixed in time for this drop, I'll include it in the next drop. > src/jdk.jlink/share/classes/jdk/tools/jlink/resources/plugins_de.properties line 173: > >> 171: plugin.opt.disable-plugin=\ --disable-plugin Deaktiviert das angegebene Plug-in >> 172: >> 173: plugin.opt.compress=\ --compress Komprimiert alle Ressourcen im Ausgabeimage:\n Zul?ssige Werte:\n zip-'{0-9}', wobei "zip-0" f?r keine Komprimierung\n und "zip-9" f?r die beste Komprimierung steht.\n Standardwert ist "zip-6."\n Veraltete Werte, die in einem zuk?nftigen Release entfernt werden:\n 0: Keine Komprimierung. Verwenden Sie stattdessen "zip-0".\n 1: Gemeinsame Verwendung konstanter Zeichenfolgen\n 2: ZIP. Verwenden Sie stattdessen "zip-6". > > `` is translated here, but untouched in `ja` and `zh_CN`. Also it is odd the period was inserted within the `"zip-6"` string. -> `"zip-6."` The extra period is definitely strange. Like with above, I'll report this as well under the same issue since it seems to only be for Japanese and Chinese again. Thanks. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28802#discussion_r2615791381 PR Review Comment: https://git.openjdk.org/jdk/pull/28802#discussion_r2615792622 From weijun at openjdk.org Fri Dec 12 23:53:59 2025 From: weijun at openjdk.org (Weijun Wang) Date: Fri, 12 Dec 2025 23:53:59 GMT Subject: RFR: 8373119: JDK 26 RDP1 L10n resource files update [v2] In-Reply-To: References: Message-ID: On Fri, 12 Dec 2025 22:34:10 GMT, Damon Nguyen wrote: >> Open l10n drop. Files have been updated with translated versions. > > Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision: > > Revert Chinese preview change src/java.base/share/classes/sun/launcher/resources/launcher_zh_CN.properties line 53: > 51: java.launcher.cls.error4=??: ???? {0} ??? LinkageError\n\t{1} > 52: java.launcher.cls.error5=??: ??????? {0}\n??: {1}: {2} > 53: java.launcher.cls.error6=????? {0} ???? non-private ??????\n?????????? private???????\n public {0}() Shall we translate "non-private" into Chinese? src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler_zh_CN.properties line 1637: > 1635: # 0: symbol, 1: file object > 1636: # lint: classfile > 1637: compiler.warn.inconsistent.inner.classes={1} ? {0} ? InnerClasses ?????????\n??????? {0} ???? {1}? I am a little unsure of this. The English value has "({1} may need to be recompiled with {0})", which can be interpreted as "compiling 1 along with 0" but the Chinese translation sounds like "compiling 1 using 0". I tried to find where this is used but cannot. src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/resources/doclets_zh_CN.properties line 251: > 249: doclet.filter_table_of_contents=???? > 250: doclet.filter_reset=?? > 251: doclet.sort_table_of_contents=???????????????? Seems incorrectly copied from line 244. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28802#discussion_r2615834067 PR Review Comment: https://git.openjdk.org/jdk/pull/28802#discussion_r2615850080 PR Review Comment: https://git.openjdk.org/jdk/pull/28802#discussion_r2615854313 From asemenyuk at openjdk.org Sat Dec 13 04:01:51 2025 From: asemenyuk at openjdk.org (Alexey Semenyuk) Date: Sat, 13 Dec 2025 04:01:51 GMT Subject: RFR: 8373119: JDK 26 RDP1 L10n resource files update [v2] In-Reply-To: References: Message-ID: On Fri, 12 Dec 2025 22:34:10 GMT, Damon Nguyen wrote: >> Open l10n drop. Files have been updated with translated versions. > > Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision: > > Revert Chinese preview change Marked as reviewed by asemenyuk (Reviewer). jpackage changes look good: all keys are in place and translated. Can't comment on translations, though. I don't speak any of these languages. ------------- PR Review: https://git.openjdk.org/jdk/pull/28802#pullrequestreview-3574161659 PR Comment: https://git.openjdk.org/jdk/pull/28802#issuecomment-3648886796 From dnguyen at openjdk.org Mon Dec 15 18:57:21 2025 From: dnguyen at openjdk.org (Damon Nguyen) Date: Mon, 15 Dec 2025 18:57:21 GMT Subject: RFR: 8373119: JDK 26 RDP1 L10n resource files update [v2] In-Reply-To: References: Message-ID: On Fri, 12 Dec 2025 23:39:10 GMT, Weijun Wang wrote: >> Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision: >> >> Revert Chinese preview change > > src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/resources/doclets_zh_CN.properties line 251: > >> 249: doclet.filter_table_of_contents=???? >> 250: doclet.filter_reset=?? >> 251: doclet.sort_table_of_contents=???????????????? > > Seems incorrectly copied from line 244. This was what I got back from the translation team. When looking at the English file's changes, the two values are "Sort member details lexicographically" and "Sort member details in lexicographical order". Even though the wording is slightly different, these phrases mean the same thing, so the Chinese translation being the same makes sense to me. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28802#discussion_r2620487307 From dnguyen at openjdk.org Mon Dec 15 19:04:38 2025 From: dnguyen at openjdk.org (Damon Nguyen) Date: Mon, 15 Dec 2025 19:04:38 GMT Subject: RFR: 8373119: JDK 26 RDP1 L10n resource files update [v2] In-Reply-To: References: Message-ID: On Fri, 12 Dec 2025 23:35:29 GMT, Weijun Wang wrote: >> Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision: >> >> Revert Chinese preview change > > src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler_zh_CN.properties line 1637: > >> 1635: # 0: symbol, 1: file object >> 1636: # lint: classfile >> 1637: compiler.warn.inconsistent.inner.classes={1} ? {0} ? InnerClasses ?????????\n??????? {0} ???? {1}? > > I am a little unsure of this. The English value has "({1} may need to be recompiled with {0})", which can be interpreted as "compiling 1 along with 0" but the Chinese translation sounds like "compiling 1 using 0". I tried to find where this is used but cannot. @liach Do you happen to know what the intent is here? I see you have reviewed this area before and I would appreciate the review. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28802#discussion_r2620503781 From dnguyen at openjdk.org Mon Dec 15 19:08:26 2025 From: dnguyen at openjdk.org (Damon Nguyen) Date: Mon, 15 Dec 2025 19:08:26 GMT Subject: RFR: 8373119: JDK 26 RDP1 L10n resource files update [v2] In-Reply-To: References: Message-ID: <1ufR9UxA6vUcmh-4Fw6virbi19_MTZDT8egy1g6kCYc=.f3fba997-7339-4348-8378-7f0fb58b1df4@github.com> On Fri, 12 Dec 2025 23:25:19 GMT, Weijun Wang wrote: >> Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision: >> >> Revert Chinese preview change > > src/java.base/share/classes/sun/launcher/resources/launcher_zh_CN.properties line 53: > >> 51: java.launcher.cls.error4=??: ???? {0} ??? LinkageError\n\t{1} >> 52: java.launcher.cls.error5=??: ??????? {0}\n??: {1}: {2} >> 53: java.launcher.cls.error6=????? {0} ???? non-private ??????\n?????????? private???????\n public {0}() > > Shall we translate "non-private" into Chinese? I believe we should. I will submit this issue to the translation team and have it fixed in the next drop. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28802#discussion_r2620512600 From henryjen at openjdk.org Mon Dec 15 19:23:47 2025 From: henryjen at openjdk.org (Henry Jen) Date: Mon, 15 Dec 2025 19:23:47 GMT Subject: RFR: 8373119: JDK 26 RDP1 L10n resource files update [v2] In-Reply-To: References: Message-ID: On Fri, 12 Dec 2025 22:34:10 GMT, Damon Nguyen wrote: >> Open l10n drop. Files have been updated with translated versions. > > Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision: > > Revert Chinese preview change jlink changes for zh_CN looks good to me. ------------- PR Review: https://git.openjdk.org/jdk/pull/28802#pullrequestreview-3579751484 From jlu at openjdk.org Mon Dec 15 19:23:51 2025 From: jlu at openjdk.org (Justin Lu) Date: Mon, 15 Dec 2025 19:23:51 GMT Subject: RFR: 8373119: JDK 26 RDP1 L10n resource files update [v2] In-Reply-To: <1ufR9UxA6vUcmh-4Fw6virbi19_MTZDT8egy1g6kCYc=.f3fba997-7339-4348-8378-7f0fb58b1df4@github.com> References: <1ufR9UxA6vUcmh-4Fw6virbi19_MTZDT8egy1g6kCYc=.f3fba997-7339-4348-8378-7f0fb58b1df4@github.com> Message-ID: On Mon, 15 Dec 2025 19:05:31 GMT, Damon Nguyen wrote: >> src/java.base/share/classes/sun/launcher/resources/launcher_zh_CN.properties line 53: >> >>> 51: java.launcher.cls.error4=??: ???? {0} ??? LinkageError\n\t{1} >>> 52: java.launcher.cls.error5=??: ??????? {0}\n??: {1}: {2} >>> 53: java.launcher.cls.error6=????? {0} ???? non-private ??????\n?????????? private???????\n public {0}() >> >> Shall we translate "non-private" into Chinese? > > I believe we should. I will submit this issue to the translation team and have it fixed in the next drop. I don't see a reason why this change should occur since there was no corresponding change in the original file for this time frame. Is the change just reverting "non-private" and "private"? We might just spot revert this change here (and still notify the translation team). "`?????????????\n?????????? private`" might be better than the original translation, since `private` remains untranslated. Otherwise reverting back to the original is fine with me as well. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28802#discussion_r2620551384 From liach at openjdk.org Mon Dec 15 19:23:54 2025 From: liach at openjdk.org (Chen Liang) Date: Mon, 15 Dec 2025 19:23:54 GMT Subject: RFR: 8373119: JDK 26 RDP1 L10n resource files update [v2] In-Reply-To: References: Message-ID: <5DQ6UsA2li8t_hE1dZ1jkXCRUuHXCituWpRS5o3OSa0=.583404a8-ec75-4527-be3d-577a1d0fed0e@github.com> On Fri, 12 Dec 2025 22:34:10 GMT, Damon Nguyen wrote: >> Open l10n drop. Files have been updated with translated versions. > > Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision: > > Revert Chinese preview change src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler_zh_CN.properties line 295: > 293: > 294: # 0: symbol or name > 295: compiler.err.cant.ref.before.ctor.called=? {0} ???????????????? The original term "appear" is translated to "show" incorrectly. Google translate for single term "appear" recommends "??" which is more accurate. Same below. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28802#discussion_r2620524204 From liach at openjdk.org Mon Dec 15 19:23:58 2025 From: liach at openjdk.org (Chen Liang) Date: Mon, 15 Dec 2025 19:23:58 GMT Subject: RFR: 8373119: JDK 26 RDP1 L10n resource files update [v2] In-Reply-To: References: Message-ID: <0YsBpAfeZNmhzrtYthdcn9t-eScYEh1vd3fFMfPpgCQ=.4639ac8d-6736-4084-81cd-bd6933d4fd78@github.com> On Mon, 15 Dec 2025 19:01:43 GMT, Damon Nguyen wrote: >> src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler_zh_CN.properties line 1637: >> >>> 1635: # 0: symbol, 1: file object >>> 1636: # lint: classfile >>> 1637: compiler.warn.inconsistent.inner.classes={1} ? {0} ? InnerClasses ?????????\n??????? {0} ???? {1}? >> >> I am a little unsure of this. The English value has "({1} may need to be recompiled with {0})", which can be interpreted as "compiling 1 along with 0" but the Chinese translation sounds like "compiling 1 using 0". I tried to find where this is used but cannot. > > @liach Do you happen to know what the intent is here? I see you have reviewed this area before and I would appreciate the review. The intent is "{1} may need to be recompiled against the up-to-date {0} class-file dependency". Also the original English term is not exactly accurate - It should have been "InnerClasses attribute **entry** for {0} in {1} inconsistent with source code". An unfortunate miss there. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28802#discussion_r2620532834 From weijun at openjdk.org Mon Dec 15 19:40:39 2025 From: weijun at openjdk.org (Weijun Wang) Date: Mon, 15 Dec 2025 19:40:39 GMT Subject: RFR: 8373119: JDK 26 RDP1 L10n resource files update [v2] In-Reply-To: <0YsBpAfeZNmhzrtYthdcn9t-eScYEh1vd3fFMfPpgCQ=.4639ac8d-6736-4084-81cd-bd6933d4fd78@github.com> References: <0YsBpAfeZNmhzrtYthdcn9t-eScYEh1vd3fFMfPpgCQ=.4639ac8d-6736-4084-81cd-bd6933d4fd78@github.com> Message-ID: <6KlIqi_J9HjtMk-iU_A_6xZFpVVpAm12IOaKE_AE1a8=.3c22e23a-b9d3-41d5-af4a-f1a6098d3f3a@github.com> On Mon, 15 Dec 2025 19:14:15 GMT, Chen Liang wrote: >> @liach Do you happen to know what the intent is here? I see you have reviewed this area before and I would appreciate the review. > > The intent is "{1} may need to be recompiled against the up-to-date {0} class-file dependency". > > Also the original English term is not exactly accurate - It should have been "InnerClasses attribute **entry** for {0} in {1} inconsistent with source code". An unfortunate miss there. So the Chinese translation is still not precise and it should be something like "??"? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28802#discussion_r2620604434 From weijun at openjdk.org Mon Dec 15 19:40:42 2025 From: weijun at openjdk.org (Weijun Wang) Date: Mon, 15 Dec 2025 19:40:42 GMT Subject: RFR: 8373119: JDK 26 RDP1 L10n resource files update [v2] In-Reply-To: References: Message-ID: <8YltPZBYyGhar7kqYOwbYElAKLTjMRXQNo9GUvUy0aM=.d6d3aba4-1f0b-4bad-a2d3-6881cfdceba6@github.com> On Mon, 15 Dec 2025 18:55:00 GMT, Damon Nguyen wrote: >> src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/resources/doclets_zh_CN.properties line 251: >> >>> 249: doclet.filter_table_of_contents=???? >>> 250: doclet.filter_reset=?? >>> 251: doclet.sort_table_of_contents=???????????????? >> >> Seems incorrectly copied from line 244. > > This was what I got back from the translation team. When looking at the English file's changes, the two values are "Sort member details lexicographically" and "Sort member details in lexicographical order". Even though the wording is slightly different, these phrases mean the same thing, so the Chinese translation being the same makes sense to me. Yes, you're right. I only noticed the key names are very different and thought the values should not be the same. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28802#discussion_r2620594909 From dnguyen at openjdk.org Mon Dec 15 19:46:17 2025 From: dnguyen at openjdk.org (Damon Nguyen) Date: Mon, 15 Dec 2025 19:46:17 GMT Subject: RFR: 8373119: JDK 26 RDP1 L10n resource files update [v2] In-Reply-To: References: <1ufR9UxA6vUcmh-4Fw6virbi19_MTZDT8egy1g6kCYc=.f3fba997-7339-4348-8378-7f0fb58b1df4@github.com> Message-ID: On Mon, 15 Dec 2025 19:20:44 GMT, Justin Lu wrote: >> I believe we should. I will submit this issue to the translation team and have it fixed in the next drop. > > I don't see a reason why this change should occur since there was no corresponding change in the original file for this time frame. Is the change just reverting "non-private" and "private"? We might just spot revert this change here (and still notify the translation team). > > "`?????????????\n?????????? private`" might be better than the original translation, since `private` remains untranslated. Otherwise reverting back to the original is fine with me as well. Good catch. I'm going with this option since it doesn't make sense. to update this line anyway when the original file didn't change this line. I'll submit the issue about these words not being translated nonetheless. Thanks! ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28802#discussion_r2620616201 From weijun at openjdk.org Mon Dec 15 19:46:18 2025 From: weijun at openjdk.org (Weijun Wang) Date: Mon, 15 Dec 2025 19:46:18 GMT Subject: RFR: 8373119: JDK 26 RDP1 L10n resource files update [v2] In-Reply-To: References: <1ufR9UxA6vUcmh-4Fw6virbi19_MTZDT8egy1g6kCYc=.f3fba997-7339-4348-8378-7f0fb58b1df4@github.com> Message-ID: On Mon, 15 Dec 2025 19:42:35 GMT, Damon Nguyen wrote: >> I don't see a reason why this change should occur since there was no corresponding change in the original file for this time frame. Is the change just reverting "non-private" and "private"? We might just spot revert this change here (and still notify the translation team). >> >> "`?????????????\n?????????? private`" might be better than the original translation, since `private` remains untranslated. Otherwise reverting back to the original is fine with me as well. > > Good catch. I'm going with this option since it doesn't make sense. to update this line anyway when the original file didn't change this line. I'll submit the issue about these words not being translated nonetheless. Thanks! I guess someone has complained that the 2nd "private" should not be translated. The problem in this PR is that both "non-private" and "private" are back to English. I think the 2nd should not be translated but the 1st should, or, at least it can be written as "?private?. Keeping a "non-" in Chinese looks strange. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28802#discussion_r2620619056 From dnguyen at openjdk.org Mon Dec 15 19:52:35 2025 From: dnguyen at openjdk.org (Damon Nguyen) Date: Mon, 15 Dec 2025 19:52:35 GMT Subject: RFR: 8373119: JDK 26 RDP1 L10n resource files update [v3] In-Reply-To: References: Message-ID: <_t7T8S2_DaWKwPJncyWMNexDfL6xdRRr12AMG7nU5ww=.0d8369ac-a6a8-433f-827e-15360e3263d0@github.com> > Open l10n drop. Files have been updated with translated versions. Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision: Spot revert Chinese translation ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28802/files - new: https://git.openjdk.org/jdk/pull/28802/files/83100f94..1a5ebb91 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28802&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28802&range=01-02 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/28802.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28802/head:pull/28802 PR: https://git.openjdk.org/jdk/pull/28802 From liach at openjdk.org Mon Dec 15 19:52:37 2025 From: liach at openjdk.org (Chen Liang) Date: Mon, 15 Dec 2025 19:52:37 GMT Subject: RFR: 8373119: JDK 26 RDP1 L10n resource files update [v2] In-Reply-To: <6KlIqi_J9HjtMk-iU_A_6xZFpVVpAm12IOaKE_AE1a8=.3c22e23a-b9d3-41d5-af4a-f1a6098d3f3a@github.com> References: <0YsBpAfeZNmhzrtYthdcn9t-eScYEh1vd3fFMfPpgCQ=.4639ac8d-6736-4084-81cd-bd6933d4fd78@github.com> <6KlIqi_J9HjtMk-iU_A_6xZFpVVpAm12IOaKE_AE1a8=.3c22e23a-b9d3-41d5-af4a-f1a6098d3f3a@github.com> Message-ID: <_KVY1o8jncsmNAqFViGyvlxo08R-Y2Uw1y6U25E-Gb8=.0c9f2ffe-faf2-4dd7-81a5-546e3ddbeefe@github.com> On Mon, 15 Dec 2025 19:37:45 GMT, Weijun Wang wrote: >> The intent is "{1} may need to be recompiled against the up-to-date {0} class-file dependency". >> >> Also the original English term is not exactly accurate - It should have been "InnerClasses attribute **entry** for {0} in {1} inconsistent with source code". An unfortunate miss there. > > So the Chinese translation is still not precise and it should be something like "??"? Uhh not quite... I don't know what's the translation term for recompile {1} with the latest {0} in classpath. So compiling {1} using {0} kind of makes sense. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28802#discussion_r2620629526 From weijun at openjdk.org Mon Dec 15 20:37:43 2025 From: weijun at openjdk.org (Weijun Wang) Date: Mon, 15 Dec 2025 20:37:43 GMT Subject: RFR: 8373119: JDK 26 RDP1 L10n resource files update [v2] In-Reply-To: <_KVY1o8jncsmNAqFViGyvlxo08R-Y2Uw1y6U25E-Gb8=.0c9f2ffe-faf2-4dd7-81a5-546e3ddbeefe@github.com> References: <0YsBpAfeZNmhzrtYthdcn9t-eScYEh1vd3fFMfPpgCQ=.4639ac8d-6736-4084-81cd-bd6933d4fd78@github.com> <6KlIqi_J9HjtMk-iU_A_6xZFpVVpAm12IOaKE_AE1a8=.3c22e23a-b9d3-41d5-af4a-f1a6098d3f3a@github.com> <_KVY1o8jncsmNAqFViGyvlxo08R-Y2Uw1y6U25E-Gb8=.0c9f2ffe-faf2-4dd7-81a5-546e3ddbeefe@github.com> Message-ID: On Mon, 15 Dec 2025 19:48:07 GMT, Chen Liang wrote: >> So the Chinese translation is still not precise and it should be something like "??"? > > Uhh not quite... I don't know what's the translation term for recompile {1} with the latest {0} in classpath. So compiling {1} using {0} kind of makes sense. OK, so the current translation is good enough. I have no more objection then. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28802#discussion_r2620758924 From almatvee at openjdk.org Mon Dec 15 21:10:16 2025 From: almatvee at openjdk.org (Alexander Matveev) Date: Mon, 15 Dec 2025 21:10:16 GMT Subject: RFR: 8373119: JDK 26 RDP1 L10n resource files update [v3] In-Reply-To: <_t7T8S2_DaWKwPJncyWMNexDfL6xdRRr12AMG7nU5ww=.0d8369ac-a6a8-433f-827e-15360e3263d0@github.com> References: <_t7T8S2_DaWKwPJncyWMNexDfL6xdRRr12AMG7nU5ww=.0d8369ac-a6a8-433f-827e-15360e3263d0@github.com> Message-ID: On Mon, 15 Dec 2025 19:52:35 GMT, Damon Nguyen wrote: >> Open l10n drop. Files have been updated with translated versions. > > Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision: > > Spot revert Chinese translation Marked as reviewed by almatvee (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/28802#pullrequestreview-3580154697 From jlu at openjdk.org Mon Dec 15 21:16:08 2025 From: jlu at openjdk.org (Justin Lu) Date: Mon, 15 Dec 2025 21:16:08 GMT Subject: RFR: 8373119: JDK 26 RDP1 L10n resource files update [v3] In-Reply-To: <_t7T8S2_DaWKwPJncyWMNexDfL6xdRRr12AMG7nU5ww=.0d8369ac-a6a8-433f-827e-15360e3263d0@github.com> References: <_t7T8S2_DaWKwPJncyWMNexDfL6xdRRr12AMG7nU5ww=.0d8369ac-a6a8-433f-827e-15360e3263d0@github.com> Message-ID: On Mon, 15 Dec 2025 19:52:35 GMT, Damon Nguyen wrote: >> Open l10n drop. Files have been updated with translated versions. > > Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision: > > Spot revert Chinese translation src/java.base/share/classes/sun/launcher/resources/launcher_zh_CN.properties line 53: > 51: java.launcher.cls.error4=??: ???? {0} ??? LinkageError\n\t{1} > 52: java.launcher.cls.error5=??: ??????? {0}\n??: {1}: {2} > 53: java.launcher.cls.error6=????? {0} ?????????????\n???????????????????\n public {0}() Translating "non-private" looks good, but we might leave the second "private" untranslated, since the original intent for that one is being used as a Java keyword. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28802#discussion_r2620866475 From dnguyen at openjdk.org Mon Dec 15 21:32:24 2025 From: dnguyen at openjdk.org (Damon Nguyen) Date: Mon, 15 Dec 2025 21:32:24 GMT Subject: RFR: 8373119: JDK 26 RDP1 L10n resource files update [v4] In-Reply-To: References: Message-ID: > Open l10n drop. Files have been updated with translated versions. Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision: Revert private keyword ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28802/files - new: https://git.openjdk.org/jdk/pull/28802/files/1a5ebb91..4f80e7e4 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28802&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28802&range=02-03 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/28802.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28802/head:pull/28802 PR: https://git.openjdk.org/jdk/pull/28802 From dnguyen at openjdk.org Mon Dec 15 21:32:26 2025 From: dnguyen at openjdk.org (Damon Nguyen) Date: Mon, 15 Dec 2025 21:32:26 GMT Subject: RFR: 8373119: JDK 26 RDP1 L10n resource files update [v2] In-Reply-To: References: <1ufR9UxA6vUcmh-4Fw6virbi19_MTZDT8egy1g6kCYc=.f3fba997-7339-4348-8378-7f0fb58b1df4@github.com> Message-ID: On Mon, 15 Dec 2025 19:43:46 GMT, Weijun Wang wrote: >> Good catch. I'm going with this option since it doesn't make sense. to update this line anyway when the original file didn't change this line. I'll submit the issue about these words not being translated nonetheless. Thanks! > > I guess someone has complained that the 2nd "private" should not be translated. The problem in this PR is that both "non-private" and "private" are back to English. I think the 2nd should not be translated but the 1st should, or, at least it can be written as "?private?. Keeping a "non-" in Chinese looks strange. Agreed. I have reverted the second private back to the not-translated version. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28802#discussion_r2620910384 From dnguyen at openjdk.org Mon Dec 15 21:39:42 2025 From: dnguyen at openjdk.org (Damon Nguyen) Date: Mon, 15 Dec 2025 21:39:42 GMT Subject: RFR: 8373119: JDK 26 RDP1 L10n resource files update [v3] In-Reply-To: References: <_t7T8S2_DaWKwPJncyWMNexDfL6xdRRr12AMG7nU5ww=.0d8369ac-a6a8-433f-827e-15360e3263d0@github.com> Message-ID: On Mon, 15 Dec 2025 21:13:07 GMT, Justin Lu wrote: >> Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision: >> >> Spot revert Chinese translation > > src/java.base/share/classes/sun/launcher/resources/launcher_zh_CN.properties line 53: > >> 51: java.launcher.cls.error4=??: ???? {0} ??? LinkageError\n\t{1} >> 52: java.launcher.cls.error5=??: ??????? {0}\n??: {1}: {2} >> 53: java.launcher.cls.error6=????? {0} ?????????????\n???????????????????\n public {0}() > > Translating "non-private" looks good, but we might leave the second "private" untranslated, since the original intent for that one is being used as a Java keyword. Weijun brought up the same thing above. This has been updated. Thanks! ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28802#discussion_r2620933892 From dnguyen at openjdk.org Mon Dec 15 21:39:46 2025 From: dnguyen at openjdk.org (Damon Nguyen) Date: Mon, 15 Dec 2025 21:39:46 GMT Subject: RFR: 8373119: JDK 26 RDP1 L10n resource files update [v2] In-Reply-To: <5DQ6UsA2li8t_hE1dZ1jkXCRUuHXCituWpRS5o3OSa0=.583404a8-ec75-4527-be3d-577a1d0fed0e@github.com> References: <5DQ6UsA2li8t_hE1dZ1jkXCRUuHXCituWpRS5o3OSa0=.583404a8-ec75-4527-be3d-577a1d0fed0e@github.com> Message-ID: On Mon, 15 Dec 2025 19:10:35 GMT, Chen Liang wrote: >> Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision: >> >> Revert Chinese preview change > > src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler_zh_CN.properties line 295: > >> 293: >> 294: # 0: symbol or name >> 295: compiler.err.cant.ref.before.ctor.called=? {0} ???????????????? > > The original term "appear" is translated to "show" incorrectly. Google translate for single term "appear" recommends "??" which is more accurate. Same below. I will note and file this to the translation team as well. In the past, similar issues occurred where more accurate words exist, but sometimes they do not update the translations anyway due to there being no functional issue from their perspective. However, I will update this in the next drop if they do fix it. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28802#discussion_r2620931705 From jlu at openjdk.org Mon Dec 15 22:31:59 2025 From: jlu at openjdk.org (Justin Lu) Date: Mon, 15 Dec 2025 22:31:59 GMT Subject: RFR: 8373119: JDK 26 RDP1 L10n resource files update [v4] In-Reply-To: References: Message-ID: <6Ucr0pTs8y0eZTZsnO5sK0wHVPDlKk5nw7V0idjibCo=.2abee019-c538-4647-b01b-5875a9c65804@github.com> On Mon, 15 Dec 2025 21:32:24 GMT, Damon Nguyen wrote: >> Open l10n drop. Files have been updated with translated versions. > > Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision: > > Revert private keyword Looks like you addressed the concerns that were possible to resolve, and will file the rest with the translation team. LGTM. ------------- Marked as reviewed by jlu (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/28802#pullrequestreview-3580442012 From dnguyen at openjdk.org Tue Dec 16 21:22:17 2025 From: dnguyen at openjdk.org (Damon Nguyen) Date: Tue, 16 Dec 2025 21:22:17 GMT Subject: Integrated: 8373119: JDK 26 RDP1 L10n resource files update In-Reply-To: References: Message-ID: On Fri, 12 Dec 2025 20:43:36 GMT, Damon Nguyen wrote: > Open l10n drop. Files have been updated with translated versions. This pull request has now been integrated. Changeset: fb99ba6c Author: Damon Nguyen URL: https://git.openjdk.org/jdk/commit/fb99ba6ccd6e6d7a0e717a1b9f2a80402af5c661 Stats: 1141 lines in 52 files changed: 706 ins; 159 del; 276 mod 8373119: JDK 26 RDP1 L10n resource files update Reviewed-by: jlu, asemenyuk, almatvee ------------- PR: https://git.openjdk.org/jdk/pull/28802 From dnguyen at openjdk.org Tue Dec 16 22:05:04 2025 From: dnguyen at openjdk.org (Damon Nguyen) Date: Tue, 16 Dec 2025 22:05:04 GMT Subject: [jdk26] RFR: 8373119: JDK 26 RDP1 L10n resource files update Message-ID: Hi all, This pull request contains a backport of commit [fb99ba6c](https://github.com/openjdk/jdk/commit/fb99ba6ccd6e6d7a0e717a1b9f2a80402af5c661) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository. The commit being backported was authored by Damon Nguyen on 16 Dec 2025 and was reviewed by Justin Lu, Alexey Semenyuk and Alexander Matveev. Thanks! ------------- Commit messages: - Backport fb99ba6ccd6e6d7a0e717a1b9f2a80402af5c661 Changes: https://git.openjdk.org/jdk/pull/28854/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28854&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8373119 Stats: 1141 lines in 52 files changed: 706 ins; 159 del; 276 mod Patch: https://git.openjdk.org/jdk/pull/28854.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28854/head:pull/28854 PR: https://git.openjdk.org/jdk/pull/28854 From jlu at openjdk.org Tue Dec 16 22:23:32 2025 From: jlu at openjdk.org (Justin Lu) Date: Tue, 16 Dec 2025 22:23:32 GMT Subject: [jdk26] RFR: 8373119: JDK 26 RDP1 L10n resource files update In-Reply-To: References: Message-ID: On Tue, 16 Dec 2025 21:52:52 GMT, Damon Nguyen wrote: > Hi all, > > This pull request contains a backport of commit [fb99ba6c](https://github.com/openjdk/jdk/commit/fb99ba6ccd6e6d7a0e717a1b9f2a80402af5c661) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository. > > The commit being backported was authored by Damon Nguyen on 16 Dec 2025 and was reviewed by Justin Lu, Alexey Semenyuk and Alexander Matveev. > > Thanks! Marked as reviewed by jlu (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/28854#pullrequestreview-3585197804 From hannesw at openjdk.org Wed Dec 17 08:52:41 2025 From: hannesw at openjdk.org (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=) Date: Wed, 17 Dec 2025 08:52:41 GMT Subject: RFR: 8309748: Improve host selection in `External Specifications` page Message-ID: Please review a change to improve selection by host name in the External Specifications page. After trying a list of checkboxes as used in the API summary pages and finding it not a suitable solution, I found that a select/dropdown menu works best for this page. - [New external specs page](https://cr.openjdk.org/~hannesw/8309748/api.00/external-specs.html) - [Old external specs page](https://docs.oracle.com/en/java/javase/25/docs/api/external-specs.html) for comparsion I also updated `@spec` tags in `java.lang.Character` to point to `www.unicode.org` rather than `unicode.org` to avoid a `unicode.org` entry in the host list (other `@spec` tags use the `www.unicode.org` host name). The short `unicode.org` URL is still used elsewhere in the `java.lang.Character` class, I can update those links to the canonical host name as well if desired. ------------- Commit messages: - 8309748: Improve host selection in `External Specifications` page Changes: https://git.openjdk.org/jdk/pull/28863/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28863&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8309748 Stats: 97 lines in 5 files changed: 71 ins; 3 del; 23 mod Patch: https://git.openjdk.org/jdk/pull/28863.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28863/head:pull/28863 PR: https://git.openjdk.org/jdk/pull/28863 From hannesw at openjdk.org Wed Dec 17 12:24:22 2025 From: hannesw at openjdk.org (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=) Date: Wed, 17 Dec 2025 12:24:22 GMT Subject: RFR: 8309748: Improve host selection in `External Specifications` page [v2] In-Reply-To: References: Message-ID: > Please review a change to improve selection by host name in the External Specifications page. After trying a list of checkboxes as used in the API summary pages and finding it not a suitable solution, I found that a select/dropdown menu works best for this page. > > - [New external specs page](https://cr.openjdk.org/~hannesw/8309748/api.00/external-specs.html) > - [Old external specs page](https://docs.oracle.com/en/java/javase/25/docs/api/external-specs.html) for comparsion > > I also updated `@spec` tags in `java.lang.Character` to point to `www.unicode.org` rather than `unicode.org` to avoid a `unicode.org` entry in the host list (other `@spec` tags use the `www.unicode.org` host name). The short `unicode.org` URL is still used elsewhere in the `java.lang.Character` class, I can update those links to the canonical host name as well if desired. Hannes Walln?fer has updated the pull request incrementally with one additional commit since the last revision: Remove pointless parentheses ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28863/files - new: https://git.openjdk.org/jdk/pull/28863/files/4587271c..fe88df58 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28863&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28863&range=00-01 Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/28863.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28863/head:pull/28863 PR: https://git.openjdk.org/jdk/pull/28863 From dlsmith at openjdk.org Wed Dec 17 20:19:51 2025 From: dlsmith at openjdk.org (Dan Smith) Date: Wed, 17 Dec 2025 20:19:51 GMT Subject: RFR: 8373909: JSpec and ToolGuide taglets use incorrect relative path Message-ID: Fixing the JSpec and ToolGuide taglets so that they produce correct links, no matter what file the tag appears in. This is a workaround solution, sharing the necessary info via a ThreadLocal public static field in an internal API. See [JDK-8373922](https://bugs.openjdk.org/browse/JDK-8373922) for an API enhancement request that would make this possible without relying on internal API. ------------- Commit messages: - whitespace fixes - restore test/docs/ProblemList.txt (to be fixed with different issue) - Simplified command line - clarifying exceptions/comment - Merge branch 'main' into 8373909 - use same convention in ToolGuide, tidying up - Share current path with JSpec to get accurate links to root Changes: https://git.openjdk.org/jdk/pull/28878/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28878&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8373909 Stats: 84 lines in 4 files changed: 18 ins; 54 del; 12 mod Patch: https://git.openjdk.org/jdk/pull/28878.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28878/head:pull/28878 PR: https://git.openjdk.org/jdk/pull/28878 From dlsmith at openjdk.org Wed Dec 17 20:19:51 2025 From: dlsmith at openjdk.org (Dan Smith) Date: Wed, 17 Dec 2025 20:19:51 GMT Subject: RFR: 8373909: JSpec and ToolGuide taglets use incorrect relative path In-Reply-To: References: Message-ID: On Wed, 17 Dec 2025 20:09:44 GMT, Dan Smith wrote: > Fixing the JSpec and ToolGuide taglets so that they produce correct links, no matter what file the tag appears in. > > This is a workaround solution, sharing the necessary info via a ThreadLocal public static field in an internal API. See [JDK-8373922](https://bugs.openjdk.org/browse/JDK-8373922) for an API enhancement request that would make this possible without relying on internal API. Planning to integrate this into 27 and create a backport to 26 The relevant test is jdk/javadoc/doccheck/checks/jdkCheckLinks.java, which is currently problem-listed and will be turned back on via [JDK-8370249](https://bugs.openjdk.org/browse/JDK-8370249). It fails before this fix, passes afterwards (when I take it off the problem list). ------------- PR Comment: https://git.openjdk.org/jdk/pull/28878#issuecomment-3666990146 PR Comment: https://git.openjdk.org/jdk/pull/28878#issuecomment-3666997982 From liach at openjdk.org Wed Dec 17 22:24:29 2025 From: liach at openjdk.org (Chen Liang) Date: Wed, 17 Dec 2025 22:24:29 GMT Subject: RFR: 8373909: JSpec and ToolGuide taglets use incorrect relative path In-Reply-To: References: Message-ID: <1KxEaV2_Vb7eYbY7bxDjRr8-rKMuafP9MZLy54-JMiY=.9928bc76-c78d-4a26-a0cb-ba1569cfc012@github.com> On Wed, 17 Dec 2025 20:09:44 GMT, Dan Smith wrote: > Fixing the JSpec and ToolGuide taglets so that they produce correct links, no matter what file the tag appears in. > > This is a workaround solution, sharing the necessary info via a ThreadLocal public static field in an internal API. See [JDK-8373922](https://bugs.openjdk.org/browse/JDK-8373922) for an API enhancement request that would make this possible without relying on internal API. Marked as reviewed by liach (Reviewer). I checked whether we can make the taglet compile against jdk.javadoc and use the field directly - don't think it's worth the make system hassle. make/jdk/src/classes/build/tools/taglet/JSpec.java line 188: > 186: try { > 187: Class c = Class.forName("jdk.javadoc.internal.doclets.formats.html.HtmlDocletWriter"); > 188: ThreadLocal tl = (ThreadLocal) c.getField("CURRENT_PATH").get(null); I hope the performance overhead of repeated reflective lookup is acceptable... Ideally we should keep the `Field` in a static final variable. ------------- PR Review: https://git.openjdk.org/jdk/pull/28878#pullrequestreview-3589915819 PR Comment: https://git.openjdk.org/jdk/pull/28878#issuecomment-3667435436 PR Review Comment: https://git.openjdk.org/jdk/pull/28878#discussion_r2628841220 From dnguyen at openjdk.org Wed Dec 17 22:41:09 2025 From: dnguyen at openjdk.org (Damon Nguyen) Date: Wed, 17 Dec 2025 22:41:09 GMT Subject: [jdk26] Integrated: 8373119: JDK 26 RDP1 L10n resource files update In-Reply-To: References: Message-ID: On Tue, 16 Dec 2025 21:52:52 GMT, Damon Nguyen wrote: > Hi all, > > This pull request contains a backport of commit [fb99ba6c](https://github.com/openjdk/jdk/commit/fb99ba6ccd6e6d7a0e717a1b9f2a80402af5c661) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository. > > The commit being backported was authored by Damon Nguyen on 16 Dec 2025 and was reviewed by Justin Lu, Alexey Semenyuk and Alexander Matveev. > > Thanks! This pull request has now been integrated. Changeset: d94b2a11 Author: Damon Nguyen URL: https://git.openjdk.org/jdk/commit/d94b2a11818e0c3321188ab831b4bce6d7ca7ddf Stats: 1141 lines in 52 files changed: 706 ins; 159 del; 276 mod 8373119: JDK 26 RDP1 L10n resource files update Reviewed-by: jlu Backport-of: fb99ba6ccd6e6d7a0e717a1b9f2a80402af5c661 ------------- PR: https://git.openjdk.org/jdk/pull/28854 From dlsmith at openjdk.org Thu Dec 18 01:18:28 2025 From: dlsmith at openjdk.org (Dan Smith) Date: Thu, 18 Dec 2025 01:18:28 GMT Subject: RFR: 8373909: JSpec and ToolGuide taglets use incorrect relative path [v2] In-Reply-To: References: Message-ID: > Fixing the JSpec and ToolGuide taglets so that they produce correct links, no matter what file the tag appears in. > > This is a workaround solution, sharing the necessary info via a ThreadLocal public static field in an internal API. See [JDK-8373922](https://bugs.openjdk.org/browse/JDK-8373922) for an API enhancement request that would make this possible without relying on internal API. Dan Smith has updated the pull request incrementally with one additional commit since the last revision: Factor out reflection code to run just once ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28878/files - new: https://git.openjdk.org/jdk/pull/28878/files/1ad28fa3..180eea30 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28878&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28878&range=00-01 Stats: 28 lines in 2 files changed: 16 ins; 0 del; 12 mod Patch: https://git.openjdk.org/jdk/pull/28878.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28878/head:pull/28878 PR: https://git.openjdk.org/jdk/pull/28878 From dlsmith at openjdk.org Thu Dec 18 01:18:30 2025 From: dlsmith at openjdk.org (Dan Smith) Date: Thu, 18 Dec 2025 01:18:30 GMT Subject: RFR: 8373909: JSpec and ToolGuide taglets use incorrect relative path [v2] In-Reply-To: <1KxEaV2_Vb7eYbY7bxDjRr8-rKMuafP9MZLy54-JMiY=.9928bc76-c78d-4a26-a0cb-ba1569cfc012@github.com> References: <1KxEaV2_Vb7eYbY7bxDjRr8-rKMuafP9MZLy54-JMiY=.9928bc76-c78d-4a26-a0cb-ba1569cfc012@github.com> Message-ID: <_wm1y59io2hHw_WZZ8F3Vrk4qT80401pIzC-TTP4Rwo=.23fdb948-d735-458a-8b3e-7a70e468c675@github.com> On Wed, 17 Dec 2025 22:19:44 GMT, Chen Liang wrote: >> Dan Smith has updated the pull request incrementally with one additional commit since the last revision: >> >> Factor out reflection code to run just once > > make/jdk/src/classes/build/tools/taglet/JSpec.java line 188: > >> 186: try { >> 187: Class c = Class.forName("jdk.javadoc.internal.doclets.formats.html.HtmlDocletWriter"); >> 188: ThreadLocal tl = (ThreadLocal) c.getField("CURRENT_PATH").get(null); > > I hope the performance overhead of repeated reflective lookup is acceptable... Ideally we should keep the `Field` in a static final variable. Ok, fair point (although n is fairly small). Pushed an update that caches the ThreadLocal in a static field. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28878#discussion_r2629146943 From liach at openjdk.org Thu Dec 18 01:38:08 2025 From: liach at openjdk.org (Chen Liang) Date: Thu, 18 Dec 2025 01:38:08 GMT Subject: RFR: 8373909: JSpec and ToolGuide taglets use incorrect relative path [v2] In-Reply-To: References: Message-ID: <5wpGsV7BEXOG9r7accumrpYi-kYbaqgNjedG8Qhwpvk=.caf2b750-0bd5-4c0f-a543-836618950ea0@github.com> On Thu, 18 Dec 2025 01:18:28 GMT, Dan Smith wrote: >> Fixing the JSpec and ToolGuide taglets so that they produce correct links, no matter what file the tag appears in. >> >> This is a workaround solution, sharing the necessary info via a ThreadLocal public static field in an internal API. See [JDK-8373922](https://bugs.openjdk.org/browse/JDK-8373922) for an API enhancement request that would make this possible without relying on internal API. > > Dan Smith has updated the pull request incrementally with one additional commit since the last revision: > > Factor out reflection code to run just once Good ------------- Marked as reviewed by liach (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/28878#pullrequestreview-3590319330 From hannesw at openjdk.org Thu Dec 18 10:18:02 2025 From: hannesw at openjdk.org (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=) Date: Thu, 18 Dec 2025 10:18:02 GMT Subject: RFR: 8373909: JSpec and ToolGuide taglets use incorrect relative path [v2] In-Reply-To: References: Message-ID: <4t3k3JLeVzLR4VRrEf02ZQB9BCkflIbHgUtGcISrXf0=.b3bcc140-bb22-4b20-b326-a46afb903328@github.com> On Thu, 18 Dec 2025 01:18:28 GMT, Dan Smith wrote: >> Fixing the JSpec and ToolGuide taglets so that they produce correct links, no matter what file the tag appears in. >> >> This is a workaround solution, sharing the necessary info via a ThreadLocal public static field in an internal API. See [JDK-8373922](https://bugs.openjdk.org/browse/JDK-8373922) for an API enhancement request that would make this possible without relying on internal API. > > Dan Smith has updated the pull request incrementally with one additional commit since the last revision: > > Factor out reflection code to run just once Looks good. ------------- Marked as reviewed by hannesw (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/28878#pullrequestreview-3591955306 From dlsmith at openjdk.org Thu Dec 18 17:24:53 2025 From: dlsmith at openjdk.org (Dan Smith) Date: Thu, 18 Dec 2025 17:24:53 GMT Subject: Integrated: 8373909: JSpec and ToolGuide taglets use incorrect relative path In-Reply-To: References: Message-ID: On Wed, 17 Dec 2025 20:09:44 GMT, Dan Smith wrote: > Fixing the JSpec and ToolGuide taglets so that they produce correct links, no matter what file the tag appears in. > > This is a workaround solution, sharing the necessary info via a ThreadLocal public static field in an internal API. See [JDK-8373922](https://bugs.openjdk.org/browse/JDK-8373922) for an API enhancement request that would make this possible without relying on internal API. This pull request has now been integrated. Changeset: 0b271240 Author: Dan Smith URL: https://git.openjdk.org/jdk/commit/0b2712400b55d4a512db225d090c2f06f01f7f1f Stats: 94 lines in 4 files changed: 28 ins; 48 del; 18 mod 8373909: JSpec and ToolGuide taglets use incorrect relative path Reviewed-by: liach, hannesw ------------- PR: https://git.openjdk.org/jdk/pull/28878 From dlsmith at openjdk.org Thu Dec 18 17:31:08 2025 From: dlsmith at openjdk.org (Dan Smith) Date: Thu, 18 Dec 2025 17:31:08 GMT Subject: [jdk26] RFR: 8373909: JSpec and ToolGuide taglets use incorrect relative path Message-ID: This pull request contains a backport of commit [0b271240](https://github.com/openjdk/jdk/commit/0b2712400b55d4a512db225d090c2f06f01f7f1f) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository. The commit being backported was authored by Dan Smith on 18 Dec 2025 and was reviewed by Chen Liang and Hannes Walln?fer. ------------- Commit messages: - Backport 0b2712400b55d4a512db225d090c2f06f01f7f1f Changes: https://git.openjdk.org/jdk/pull/28902/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28902&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8373909 Stats: 94 lines in 4 files changed: 28 ins; 48 del; 18 mod Patch: https://git.openjdk.org/jdk/pull/28902.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28902/head:pull/28902 PR: https://git.openjdk.org/jdk/pull/28902 From liach at openjdk.org Thu Dec 18 17:46:49 2025 From: liach at openjdk.org (Chen Liang) Date: Thu, 18 Dec 2025 17:46:49 GMT Subject: [jdk26] RFR: 8373909: JSpec and ToolGuide taglets use incorrect relative path In-Reply-To: References: Message-ID: On Thu, 18 Dec 2025 17:23:06 GMT, Dan Smith wrote: > This pull request contains a backport of commit [0b271240](https://github.com/openjdk/jdk/commit/0b2712400b55d4a512db225d090c2f06f01f7f1f) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository. > > The commit being backported was authored by Dan Smith on 18 Dec 2025 and was reviewed by Chen Liang and Hannes Walln?fer. Marked as reviewed by liach (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/28902#pullrequestreview-3594190033 From dlsmith at openjdk.org Thu Dec 18 17:59:07 2025 From: dlsmith at openjdk.org (Dan Smith) Date: Thu, 18 Dec 2025 17:59:07 GMT Subject: [jdk26] Integrated: 8373909: JSpec and ToolGuide taglets use incorrect relative path In-Reply-To: References: Message-ID: On Thu, 18 Dec 2025 17:23:06 GMT, Dan Smith wrote: > This pull request contains a backport of commit [0b271240](https://github.com/openjdk/jdk/commit/0b2712400b55d4a512db225d090c2f06f01f7f1f) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository. > > The commit being backported was authored by Dan Smith on 18 Dec 2025 and was reviewed by Chen Liang and Hannes Walln?fer. This pull request has now been integrated. Changeset: fb7d25d7 Author: Dan Smith URL: https://git.openjdk.org/jdk/commit/fb7d25d73f7bfe8cbae3a9b051f8a1b0c4a51e01 Stats: 94 lines in 4 files changed: 28 ins; 48 del; 18 mod 8373909: JSpec and ToolGuide taglets use incorrect relative path Reviewed-by: liach Backport-of: 0b2712400b55d4a512db225d090c2f06f01f7f1f ------------- PR: https://git.openjdk.org/jdk/pull/28902 From dlsmith at openjdk.org Thu Dec 18 21:35:45 2025 From: dlsmith at openjdk.org (Dan Smith) Date: Thu, 18 Dec 2025 21:35:45 GMT Subject: RFR: 8374044: Docs build fails: Cannot determine current path Message-ID: Adding the needed -XDaccessInternalAPI to the alternate "reference" list of javadoc args. ------------- Commit messages: - 8374044: Docs build fails: Cannot determine current path Changes: https://git.openjdk.org/jdk/pull/28909/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28909&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8374044 Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/28909.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28909/head:pull/28909 PR: https://git.openjdk.org/jdk/pull/28909 From liach at openjdk.org Thu Dec 18 21:35:45 2025 From: liach at openjdk.org (Chen Liang) Date: Thu, 18 Dec 2025 21:35:45 GMT Subject: RFR: 8374044: Docs build fails: Cannot determine current path In-Reply-To: References: Message-ID: On Thu, 18 Dec 2025 21:26:37 GMT, Dan Smith wrote: > Adding the needed -XDaccessInternalAPI to the alternate "reference" list of javadoc args. @irisclark Since you are known for using docs-reference to compare the specdiff between Java SE releases, can you review this? ------------- PR Comment: https://git.openjdk.org/jdk/pull/28909#issuecomment-3672348274 From dholmes at openjdk.org Thu Dec 18 21:39:05 2025 From: dholmes at openjdk.org (David Holmes) Date: Thu, 18 Dec 2025 21:39:05 GMT Subject: RFR: 8374044: Docs build fails: Cannot determine current path In-Reply-To: References: Message-ID: On Thu, 18 Dec 2025 21:26:37 GMT, Dan Smith wrote: > Adding the needed -XDaccessInternalAPI to the alternate "reference" list of javadoc args. Marked as reviewed by dholmes (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/28909#pullrequestreview-3595165370 From dlsmith at openjdk.org Thu Dec 18 21:43:54 2025 From: dlsmith at openjdk.org (Dan Smith) Date: Thu, 18 Dec 2025 21:43:54 GMT Subject: Integrated: 8374044: Docs build fails: Cannot determine current path In-Reply-To: References: Message-ID: On Thu, 18 Dec 2025 21:26:37 GMT, Dan Smith wrote: > Adding the needed -XDaccessInternalAPI to the alternate "reference" list of javadoc args. This pull request has now been integrated. Changeset: f88cbfb8 Author: Dan Smith URL: https://git.openjdk.org/jdk/commit/f88cbfb8c6b320f773f8d8c3cdf2598d117c5521 Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod 8374044: Docs build fails: Cannot determine current path Reviewed-by: dholmes ------------- PR: https://git.openjdk.org/jdk/pull/28909 From dlsmith at openjdk.org Thu Dec 18 23:23:30 2025 From: dlsmith at openjdk.org (Dan Smith) Date: Thu, 18 Dec 2025 23:23:30 GMT Subject: [jdk26] RFR: 8374044: Docs build fails: Cannot determine current path Message-ID: <0f00fWkkZAqRRMIsOjzmCYr9JZQbb-1fFS3xsU4dHn4=.3cf28651-6df6-44d5-aa7d-f2ab35422f04@github.com> This pull request contains a backport of commit [f88cbfb8](https://github.com/openjdk/jdk/commit/f88cbfb8c6b320f773f8d8c3cdf2598d117c5521) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository. The commit being backported was authored by Dan Smith on 18 Dec 2025 and was reviewed by David Holmes. ------------- Commit messages: - Backport f88cbfb8c6b320f773f8d8c3cdf2598d117c5521 Changes: https://git.openjdk.org/jdk/pull/28913/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28913&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8374044 Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/28913.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28913/head:pull/28913 PR: https://git.openjdk.org/jdk/pull/28913 From dholmes at openjdk.org Thu Dec 18 23:33:21 2025 From: dholmes at openjdk.org (David Holmes) Date: Thu, 18 Dec 2025 23:33:21 GMT Subject: [jdk26] RFR: 8374044: Docs build fails: Cannot determine current path In-Reply-To: <0f00fWkkZAqRRMIsOjzmCYr9JZQbb-1fFS3xsU4dHn4=.3cf28651-6df6-44d5-aa7d-f2ab35422f04@github.com> References: <0f00fWkkZAqRRMIsOjzmCYr9JZQbb-1fFS3xsU4dHn4=.3cf28651-6df6-44d5-aa7d-f2ab35422f04@github.com> Message-ID: <-AB8ROpCePXzQ8cGm4qfMiz8WxvyEjapRiq6Xkz8nko=.389a3c64-bff4-4f2b-8a32-497bfcd9d2f9@github.com> On Thu, 18 Dec 2025 23:16:50 GMT, Dan Smith wrote: > This pull request contains a backport of commit [f88cbfb8](https://github.com/openjdk/jdk/commit/f88cbfb8c6b320f773f8d8c3cdf2598d117c5521) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository. > > The commit being backported was authored by Dan Smith on 18 Dec 2025 and was reviewed by David Holmes. Marked as reviewed by dholmes (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/28913#pullrequestreview-3595656478 From dlsmith at openjdk.org Thu Dec 18 23:33:21 2025 From: dlsmith at openjdk.org (Dan Smith) Date: Thu, 18 Dec 2025 23:33:21 GMT Subject: [jdk26] Integrated: 8374044: Docs build fails: Cannot determine current path In-Reply-To: <0f00fWkkZAqRRMIsOjzmCYr9JZQbb-1fFS3xsU4dHn4=.3cf28651-6df6-44d5-aa7d-f2ab35422f04@github.com> References: <0f00fWkkZAqRRMIsOjzmCYr9JZQbb-1fFS3xsU4dHn4=.3cf28651-6df6-44d5-aa7d-f2ab35422f04@github.com> Message-ID: On Thu, 18 Dec 2025 23:16:50 GMT, Dan Smith wrote: > This pull request contains a backport of commit [f88cbfb8](https://github.com/openjdk/jdk/commit/f88cbfb8c6b320f773f8d8c3cdf2598d117c5521) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository. > > The commit being backported was authored by Dan Smith on 18 Dec 2025 and was reviewed by David Holmes. This pull request has now been integrated. Changeset: 17b6eb45 Author: Dan Smith URL: https://git.openjdk.org/jdk/commit/17b6eb45e589cee565395cf6490ea296edfbbbb3 Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod 8374044: Docs build fails: Cannot determine current path Reviewed-by: dholmes Backport-of: f88cbfb8c6b320f773f8d8c3cdf2598d117c5521 ------------- PR: https://git.openjdk.org/jdk/pull/28913 From vyazici at openjdk.org Fri Dec 19 13:04:06 2025 From: vyazici at openjdk.org (Volkan Yazici) Date: Fri, 19 Dec 2025 13:04:06 GMT Subject: RFR: 8373538: Migrate all tests to null-safe "SimpleSSLContext" methods Message-ID: 1. [JDK-8372661] introduced null-safe static factory methods to `SimpleSSLContext` 2. [JDK-8373515] migrated `test/jdk/java/net/httpclient/` to these new methods 3. [JDK-8373537] migrated `test/jdk/com/sun/net/httpserver/` to these new methods 4. This PR migrates all remaining `SimpleSSLContext` usages, *and* removes nullable `SimpleSSLContext` factory methods [JDK-8372661]: https://bugs.openjdk.org/browse/JDK-8372661 [JDK-8373515]: https://bugs.openjdk.org/browse/JDK-8373515 [JDK-8373537]: https://bugs.openjdk.org/browse/JDK-8373537 ------------- Commit messages: - Merge remote-tracking branch 'upstream/master' into simpleSslRest - Restore all non-`httpclient`, non-`httpserver` changes in `test/` - Make sure `get()` returns the same instance - Reverted all changes and only kept `SimpleSSLContext` enhancements - Overhaul `SimpleSSLContext` and its usages Changes: https://git.openjdk.org/jdk/pull/28905/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28905&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8373538 Stats: 63 lines in 11 files changed: 0 ins; 39 del; 24 mod Patch: https://git.openjdk.org/jdk/pull/28905.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28905/head:pull/28905 PR: https://git.openjdk.org/jdk/pull/28905 From myankelevich at openjdk.org Fri Dec 19 15:55:31 2025 From: myankelevich at openjdk.org (Mikhail Yankelevich) Date: Fri, 19 Dec 2025 15:55:31 GMT Subject: RFR: 8373538: Migrate all tests to null-safe "SimpleSSLContext" methods In-Reply-To: References: Message-ID: On Thu, 18 Dec 2025 18:32:57 GMT, Volkan Yazici wrote: > 1. [JDK-8372661] introduced null-safe static factory methods to `SimpleSSLContext` > 2. [JDK-8373515] migrated `test/jdk/java/net/httpclient/` to these new methods > 3. [JDK-8373537] migrated `test/jdk/com/sun/net/httpserver/` to these new methods > 4. This PR migrates all remaining `SimpleSSLContext` usages, *and* removes nullable `SimpleSSLContext` factory methods > > [JDK-8372661]: https://bugs.openjdk.org/browse/JDK-8372661 > [JDK-8373515]: https://bugs.openjdk.org/browse/JDK-8373515 > [JDK-8373537]: https://bugs.openjdk.org/browse/JDK-8373537 test/lib/jdk/test/lib/net/SimpleSSLContext.java line 30: > 28: import java.util.*; > 29: import java.io.*; > 30: import java.security.*; nit: Could you please convert wildcard imports? test/lib/jdk/test/lib/net/SimpleSSLContext.java line 42: > 40: private static final String DEFAULT_KEY_STORE_FILE_REL_PATH = "jdk/test/lib/net/testkeys"; > 41: > 42: private SimpleSSLContext() {} Is there any particular reason for an empty constructor here? Can't you just remove it? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28905#discussion_r2635519481 PR Review Comment: https://git.openjdk.org/jdk/pull/28905#discussion_r2635516135 From vyazici at openjdk.org Fri Dec 19 17:37:23 2025 From: vyazici at openjdk.org (Volkan Yazici) Date: Fri, 19 Dec 2025 17:37:23 GMT Subject: RFR: 8373538: Migrate all tests to null-safe "SimpleSSLContext" methods [v2] In-Reply-To: References: Message-ID: > 1. [JDK-8372661] introduced null-safe static factory methods to `SimpleSSLContext` > 2. [JDK-8373515] migrated `test/jdk/java/net/httpclient/` to these new methods > 3. [JDK-8373537] migrated `test/jdk/com/sun/net/httpserver/` to these new methods > 4. This PR migrates all remaining `SimpleSSLContext` usages, *and* removes nullable `SimpleSSLContext` factory methods > > [JDK-8372661]: https://bugs.openjdk.org/browse/JDK-8372661 > [JDK-8373515]: https://bugs.openjdk.org/browse/JDK-8373515 > [JDK-8373537]: https://bugs.openjdk.org/browse/JDK-8373537 Volkan Yazici has updated the pull request incrementally with one additional commit since the last revision: Remove wildcard imports ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28905/files - new: https://git.openjdk.org/jdk/pull/28905/files/ad954627..fced195e Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28905&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28905&range=00-01 Stats: 8 lines in 1 file changed: 4 ins; 0 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/28905.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28905/head:pull/28905 PR: https://git.openjdk.org/jdk/pull/28905 From vyazici at openjdk.org Fri Dec 19 17:37:25 2025 From: vyazici at openjdk.org (Volkan Yazici) Date: Fri, 19 Dec 2025 17:37:25 GMT Subject: RFR: 8373538: Migrate all tests to null-safe "SimpleSSLContext" methods [v2] In-Reply-To: References: Message-ID: On Fri, 19 Dec 2025 15:51:55 GMT, Mikhail Yankelevich wrote: >> Volkan Yazici has updated the pull request incrementally with one additional commit since the last revision: >> >> Remove wildcard imports > > test/lib/jdk/test/lib/net/SimpleSSLContext.java line 30: > >> 28: import java.util.*; >> 29: import java.io.*; >> 30: import java.security.*; > > nit: Could you please convert wildcard imports? I had tried to stick to the existing import convention to minimize the diff. Changed as requested in fced195e07f. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28905#discussion_r2635812587 From vyazici at openjdk.org Fri Dec 19 17:40:16 2025 From: vyazici at openjdk.org (Volkan Yazici) Date: Fri, 19 Dec 2025 17:40:16 GMT Subject: RFR: 8373538: Migrate all tests to null-safe "SimpleSSLContext" methods [v2] In-Reply-To: References: Message-ID: On Fri, 19 Dec 2025 15:50:45 GMT, Mikhail Yankelevich wrote: >> Volkan Yazici has updated the pull request incrementally with one additional commit since the last revision: >> >> Remove wildcard imports > > test/lib/jdk/test/lib/net/SimpleSSLContext.java line 42: > >> 40: private static final String DEFAULT_KEY_STORE_FILE_REL_PATH = "jdk/test/lib/net/testkeys"; >> 41: >> 42: private SimpleSSLContext() {} > > Is there any particular reason for an empty constructor here? Can't you just remove it? To indicate that this is a singleton and should not be instantiated. I would have preferred using an `enum` (as advised by Joshua Bloch in _"Effective Java"_), but that is a foreign practice in the OpenJDK code base, AFAICT, hence, I refrained from it. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28905#discussion_r2635821557 From nbenalla at openjdk.org Sun Dec 21 14:53:48 2025 From: nbenalla at openjdk.org (Nizar Benalla) Date: Sun, 21 Dec 2025 14:53:48 GMT Subject: RFR: 8372801: tools/sincechecker/modules/java.base/JavaBaseCheckSince.java fails with JDK 27 Message-ID: The test no longer needs to be problem listed now that the symbol information has caught up and is up to date. This PR has a dependency on https://github.com/openjdk/jdk/pull/28944, I want them integrate them in order. ------------- Depends on: https://git.openjdk.org/jdk/pull/28944 Commit messages: - remove JavaBaseCheckSince from ProblemList Changes: https://git.openjdk.org/jdk/pull/28945/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28945&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8372801 Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/28945.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28945/head:pull/28945 PR: https://git.openjdk.org/jdk/pull/28945 From liach at openjdk.org Tue Dec 23 19:40:02 2025 From: liach at openjdk.org (Chen Liang) Date: Tue, 23 Dec 2025 19:40:02 GMT Subject: RFR: 8372801: tools/sincechecker/modules/java.base/JavaBaseCheckSince.java fails with JDK 27 In-Reply-To: References: Message-ID: On Sun, 21 Dec 2025 14:06:00 GMT, Nizar Benalla wrote: > The test no longer needs to be problem listed now that the symbol information has caught up and is up to date. > This PR has a dependency on https://github.com/openjdk/jdk/pull/28944, I want them integrate them in order. Marked as reviewed by liach (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/28945#pullrequestreview-3609131169 From serb at openjdk.org Wed Dec 24 05:53:12 2025 From: serb at openjdk.org (Sergey Bylokhov) Date: Wed, 24 Dec 2025 05:53:12 GMT Subject: RFR: 8374323: Update copyright year to 2025 for the build system in files where it was missed Message-ID: The copyright year in ".github" and "make" files updated in 2025 has been bumped to 2025. The next command can be run (on top of this PR) to verify that each file had prior commits in 2025: `git diff HEAD~1 --name-only | while read f; do git log HEAD~1 --since="2025-01-01" --oneline -- "$f" | head -1 | grep -q . || echo "NOT IN 2025: $f"; done` ------------- Commit messages: - 8374323: Update copyright year to 2025 for the build system in files where it was missed Changes: https://git.openjdk.org/jdk/pull/28977/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28977&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8374323 Stats: 27 lines in 27 files changed: 0 ins; 0 del; 27 mod Patch: https://git.openjdk.org/jdk/pull/28977.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28977/head:pull/28977 PR: https://git.openjdk.org/jdk/pull/28977 From serb at openjdk.org Wed Dec 24 06:25:33 2025 From: serb at openjdk.org (Sergey Bylokhov) Date: Wed, 24 Dec 2025 06:25:33 GMT Subject: RFR: 8374324: Update copyright year to 2025 for jdk.compiler in files where it was missed Message-ID: The copyright year in "jdk.compiler" files updated in 2025 has been bumped to 2025. The next command can be run (on top of this PR) to verify that each file had prior commits in 2025: `git diff HEAD~1 --name-only | while read f; do git log HEAD~1 --since="2025-01-01" --oneline -- "$f" | head -1 | grep -q . || echo "NOT IN 2025: $f"; done` ------------- Commit messages: - 8374324: Update copyright year to 2025 for jdk.compiler in files where it was missed Changes: https://git.openjdk.org/jdk/pull/28978/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28978&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8374324 Stats: 25 lines in 25 files changed: 0 ins; 0 del; 25 mod Patch: https://git.openjdk.org/jdk/pull/28978.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28978/head:pull/28978 PR: https://git.openjdk.org/jdk/pull/28978 From erikj at openjdk.org Wed Dec 24 14:12:54 2025 From: erikj at openjdk.org (Erik Joelsson) Date: Wed, 24 Dec 2025 14:12:54 GMT Subject: RFR: 8374323: Update copyright year to 2025 for the build system in files where it was missed In-Reply-To: References: Message-ID: <2awegKC1Dbg0kV4MaNfVkewrwOdSUYouXy2DSat9Hjs=.0809c886-b279-4edb-9757-97cd062056f5@github.com> On Wed, 24 Dec 2025 05:15:48 GMT, Sergey Bylokhov wrote: > The copyright year in ".github" and "make" files updated in 2025 has been bumped to 2025. > > The next command can be run (on top of this PR) to verify that each file had prior commits in 2025: > > `git diff HEAD~1 --name-only | while read f; do git log HEAD~1 --since="2025-01-01" --oneline -- "$f" | head -1 | grep -q . || echo "NOT IN 2025: $f"; done` make/scripts/compare-logger.sh line 3: > 1: #!/bin/bash > 2: # > 3: # Copyright (c) 2012, 2025, Oracle and/or its affiliates. All rights reserved. This file was only renamed. Not sure if that counts. I understand that this is auto generated, so I'm fine with this if you are. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28977#discussion_r2645759728 From nbenalla at openjdk.org Wed Dec 24 14:50:56 2025 From: nbenalla at openjdk.org (Nizar Benalla) Date: Wed, 24 Dec 2025 14:50:56 GMT Subject: RFR: 8372801: tools/sincechecker/modules/java.base/JavaBaseCheckSince.java fails with JDK 27 [v2] In-Reply-To: References: Message-ID: > The test no longer needs to be problem listed now that the symbol information has caught up and is up to date. > This PR has a dependency on https://github.com/openjdk/jdk/pull/28944, I want them integrate them in order. 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. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28945/files - new: https://git.openjdk.org/jdk/pull/28945/files/cdf8e3e9..cdf8e3e9 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28945&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28945&range=00-01 Stats: 0 lines in 0 files changed: 0 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/28945.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28945/head:pull/28945 PR: https://git.openjdk.org/jdk/pull/28945 From nbenalla at openjdk.org Wed Dec 24 14:50:57 2025 From: nbenalla at openjdk.org (Nizar Benalla) Date: Wed, 24 Dec 2025 14:50:57 GMT Subject: Integrated: 8372801: tools/sincechecker/modules/java.base/JavaBaseCheckSince.java fails with JDK 27 In-Reply-To: References: Message-ID: On Sun, 21 Dec 2025 14:06:00 GMT, Nizar Benalla wrote: > The test no longer needs to be problem listed now that the symbol information has caught up and is up to date. > This PR has a dependency on https://github.com/openjdk/jdk/pull/28944, I want them integrate them in order. This pull request has now been integrated. Changeset: 98b7792a Author: Nizar Benalla URL: https://git.openjdk.org/jdk/commit/98b7792a072380978b09fda4ec194f333d2ce7e3 Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod 8372801: tools/sincechecker/modules/java.base/JavaBaseCheckSince.java fails with JDK 27 Reviewed-by: liach ------------- PR: https://git.openjdk.org/jdk/pull/28945 From erikj at openjdk.org Wed Dec 24 15:47:00 2025 From: erikj at openjdk.org (Erik Joelsson) Date: Wed, 24 Dec 2025 15:47:00 GMT Subject: RFR: 8374323: Update copyright year to 2025 for the build system in files where it was missed In-Reply-To: References: Message-ID: On Wed, 24 Dec 2025 05:15:48 GMT, Sergey Bylokhov wrote: > The copyright year in ".github" and "make" files updated in 2025 has been bumped to 2025. > > The next command can be run (on top of this PR) to verify that each file had prior commits in 2025: > > `git diff HEAD~1 --name-only | while read f; do git log HEAD~1 --since="2025-01-01" --oneline -- "$f" | head -1 | grep -q . || echo "NOT IN 2025: $f"; done` Marked as reviewed by erikj (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/28977#pullrequestreview-3611268445 From serb at openjdk.org Thu Dec 25 07:29:05 2025 From: serb at openjdk.org (Sergey Bylokhov) Date: Thu, 25 Dec 2025 07:29:05 GMT Subject: Integrated: 8374323: Update copyright year to 2025 for the build system in files where it was missed In-Reply-To: References: Message-ID: On Wed, 24 Dec 2025 05:15:48 GMT, Sergey Bylokhov wrote: > The copyright year in ".github" and "make" files updated in 2025 has been bumped to 2025. > > The next command can be run (on top of this PR) to verify that each file had prior commits in 2025: > > `git diff HEAD~1 --name-only | while read f; do git log HEAD~1 --since="2025-01-01" --oneline -- "$f" | head -1 | grep -q . || echo "NOT IN 2025: $f"; done` This pull request has now been integrated. Changeset: 534c33d0 Author: Sergey Bylokhov URL: https://git.openjdk.org/jdk/commit/534c33d0ef7daa0d0d5b56a1101b4c9d47a48049 Stats: 27 lines in 27 files changed: 0 ins; 0 del; 27 mod 8374323: Update copyright year to 2025 for the build system in files where it was missed Reviewed-by: erikj ------------- PR: https://git.openjdk.org/jdk/pull/28977 From serb at openjdk.org Thu Dec 25 08:20:38 2025 From: serb at openjdk.org (Sergey Bylokhov) Date: Thu, 25 Dec 2025 08:20:38 GMT Subject: RFR: 8374354: Update copyright year to 2025 for jdk.javadoc in files where it was missed Message-ID: The copyright year in "jdk.javadoc" files updated in 2025 has been bumped to 2025. The next command can be run (on top of this PR) to verify that each file had prior commits in 2025: `git diff HEAD~1 --name-only | while read f; do git log HEAD~1 --since="2025-01-01" --oneline -- "$f" | head -1 | grep -q . || echo "NOT IN 2025: $f"; done` ------------- Commit messages: - 8374354: Update copyright year to 2025 for jdk.javadoc in files where it was missed Changes: https://git.openjdk.org/jdk/pull/28990/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28990&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8374354 Stats: 16 lines in 16 files changed: 0 ins; 0 del; 16 mod Patch: https://git.openjdk.org/jdk/pull/28990.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28990/head:pull/28990 PR: https://git.openjdk.org/jdk/pull/28990 From liach at openjdk.org Thu Dec 25 17:24:02 2025 From: liach at openjdk.org (Chen Liang) Date: Thu, 25 Dec 2025 17:24:02 GMT Subject: RFR: 8374354: Update copyright year to 2025 for jdk.javadoc in files where it was missed In-Reply-To: References: Message-ID: <9QQkZnpwjvHj1qRP4zQmygSYx1agzmiHxwryvsClYxw=.6b2fbe00-c7c4-402c-9d15-7413fd2556a1@github.com> On Thu, 25 Dec 2025 07:10:00 GMT, Sergey Bylokhov wrote: > The copyright year in "jdk.javadoc" files updated in 2025 has been bumped to 2025. > > The next command can be run (on top of this PR) to verify that each file had prior commits in 2025: > > `git diff HEAD~1 --name-only | while read f; do git log HEAD~1 --since="2025-01-01" --oneline -- "$f" | head -1 | grep -q . || echo "NOT IN 2025: $f"; done` https://github.com/openjdk/jdk/tree/master/test/langtools/jdk/javadoc is also considered javadoc maintenance area. You can check that directory too. I recommend moving all these update copyright for 2025 JBS issues to be subtasks of a main issue. These tickets are currently scattered around and hard to track. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28990#issuecomment-3691618563 From serb at openjdk.org Thu Dec 25 22:41:50 2025 From: serb at openjdk.org (Sergey Bylokhov) Date: Thu, 25 Dec 2025 22:41:50 GMT Subject: RFR: 8374354: Update copyright year to 2025 for jdk.javadoc in files where it was missed In-Reply-To: <9QQkZnpwjvHj1qRP4zQmygSYx1agzmiHxwryvsClYxw=.6b2fbe00-c7c4-402c-9d15-7413fd2556a1@github.com> References: <9QQkZnpwjvHj1qRP4zQmygSYx1agzmiHxwryvsClYxw=.6b2fbe00-c7c4-402c-9d15-7413fd2556a1@github.com> Message-ID: On Thu, 25 Dec 2025 17:21:40 GMT, Chen Liang wrote: >https://github.com/openjdk/jdk/tree/master/test/langtools/jdk/javadoc is also considered javadoc maintenance area. You can check that directory too. There is a small number of tests that need to be updated in test/langtools here and there. I?ve extracted the largest part into https://github.com/openjdk/jdk/pull/28989 and will handle all the remaining ones in another single PR. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28990#issuecomment-3691792818 From liach at openjdk.org Thu Dec 25 23:21:55 2025 From: liach at openjdk.org (Chen Liang) Date: Thu, 25 Dec 2025 23:21:55 GMT Subject: RFR: 8374354: Update copyright year to 2025 for jdk.javadoc in files where it was missed In-Reply-To: References: Message-ID: On Thu, 25 Dec 2025 07:10:00 GMT, Sergey Bylokhov wrote: > The copyright year in "jdk.javadoc" files updated in 2025 has been bumped to 2025. > > The next command can be run (on top of this PR) to verify that each file had prior commits in 2025: > > `git diff HEAD~1 --name-only | while read f; do git log HEAD~1 --since="2025-01-01" --oneline -- "$f" | head -1 | grep -q . || echo "NOT IN 2025: $f"; done` Thanks for the explanation, and thank you for organizing this effort with subtasks. ------------- Marked as reviewed by liach (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/28990#pullrequestreview-3612562694 From serb at openjdk.org Fri Dec 26 03:50:00 2025 From: serb at openjdk.org (Sergey Bylokhov) Date: Fri, 26 Dec 2025 03:50:00 GMT Subject: Integrated: 8374354: Update copyright year to 2025 for jdk.javadoc in files where it was missed In-Reply-To: References: Message-ID: <2NPdlmcRE994v0G5BoSy8jgbmgtU4w2la7kvwaJgH_Q=.53c606ab-49c4-46fb-86ae-88af9e34d79b@github.com> On Thu, 25 Dec 2025 07:10:00 GMT, Sergey Bylokhov wrote: > The copyright year in "jdk.javadoc" files updated in 2025 has been bumped to 2025. > > The next command can be run (on top of this PR) to verify that each file had prior commits in 2025: > > `git diff HEAD~1 --name-only | while read f; do git log HEAD~1 --since="2025-01-01" --oneline -- "$f" | head -1 | grep -q . || echo "NOT IN 2025: $f"; done` This pull request has now been integrated. Changeset: 3e6170c5 Author: Sergey Bylokhov URL: https://git.openjdk.org/jdk/commit/3e6170c5be95f92a209c58928be487e8a9f97287 Stats: 16 lines in 16 files changed: 0 ins; 0 del; 16 mod 8374354: Update copyright year to 2025 for jdk.javadoc in files where it was missed Reviewed-by: liach ------------- PR: https://git.openjdk.org/jdk/pull/28990 From serb at openjdk.org Tue Dec 30 12:34:15 2025 From: serb at openjdk.org (Sergey Bylokhov) Date: Tue, 30 Dec 2025 12:34:15 GMT Subject: RFR: 8374383: Update the copyright year to 2025 in the remaining files under test/ where it was missed Message-ID: The copyright year in test/* files updated in 2025 has been bumped to 2025. Updates to some tests in the test/langtools/jdk/javadoc/ group are skipped because some tests depend on exact output. The next command can be run (on top of this PR) to verify that each file had prior commits in 2025: `git diff origin/master --name-only | while read f; do git log origin/master --since="2025-01-01" --oneline -- "$f" | head -1 | grep -q . || echo "NOT IN 2025: $f"; done` ------------- Commit messages: - revert langtools/jdk/javadoc/doclet/testSourceTab/SingleTab - 8374383: Update the copyright year to 2025 in the remaining files under test/ where it was missed. Changes: https://git.openjdk.org/jdk/pull/29006/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29006&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8374383 Stats: 76 lines in 76 files changed: 0 ins; 0 del; 76 mod Patch: https://git.openjdk.org/jdk/pull/29006.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29006/head:pull/29006 PR: https://git.openjdk.org/jdk/pull/29006 From jpai at openjdk.org Wed Dec 31 04:52:50 2025 From: jpai at openjdk.org (Jaikiran Pai) Date: Wed, 31 Dec 2025 04:52:50 GMT Subject: RFR: 8374383: Update the copyright year to 2025 in the remaining files under test/ where it was missed In-Reply-To: References: Message-ID: On Mon, 29 Dec 2025 22:27:22 GMT, Sergey Bylokhov wrote: > The copyright year in test/* files updated in 2025 has been bumped to 2025. > > Updates to some tests in the test/langtools/jdk/javadoc/ group are skipped because some tests depend on exact output. > > The next command can be run (on top of this PR) to verify that each file had prior commits in 2025: > > `git diff origin/master --name-only | while read f; do git log origin/master --since="2025-01-01" --oneline -- "$f" | head -1 | grep -q . || echo "NOT IN 2025: $f"; done` Looks OK to me. I did a trivial verification that the files updated in this PR were indeed updated in 2025. ------------- Marked as reviewed by jpai (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/29006#pullrequestreview-3620246101 From serb at openjdk.org Wed Dec 31 10:09:05 2025 From: serb at openjdk.org (Sergey Bylokhov) Date: Wed, 31 Dec 2025 10:09:05 GMT Subject: Integrated: 8374383: Update the copyright year to 2025 in the remaining files under test/ where it was missed In-Reply-To: References: Message-ID: On Mon, 29 Dec 2025 22:27:22 GMT, Sergey Bylokhov wrote: > The copyright year in test/* files updated in 2025 has been bumped to 2025. > > Updates to some tests in the test/langtools/jdk/javadoc/ group are skipped because some tests depend on exact output. > > The next command can be run (on top of this PR) to verify that each file had prior commits in 2025: > > `git diff origin/master --name-only | while read f; do git log origin/master --since="2025-01-01" --oneline -- "$f" | head -1 | grep -q . || echo "NOT IN 2025: $f"; done` This pull request has now been integrated. Changeset: c6246d58 Author: Sergey Bylokhov URL: https://git.openjdk.org/jdk/commit/c6246d58f72942b66cb0632186366f0b99402306 Stats: 76 lines in 76 files changed: 0 ins; 0 del; 76 mod 8374383: Update the copyright year to 2025 in the remaining files under test/ where it was missed Reviewed-by: jpai ------------- PR: https://git.openjdk.org/jdk/pull/29006 From serb at openjdk.org Wed Dec 31 17:19:57 2025 From: serb at openjdk.org (Sergey Bylokhov) Date: Wed, 31 Dec 2025 17:19:57 GMT Subject: RFR: 8374324: Update copyright year to 2025 for jdk.compiler in files where it was missed In-Reply-To: References: Message-ID: <1eMGo8vAH6LB8h38LNpDQZmK4KgA-RAMrKnMHNG47VM=.88e0097d-2dbb-41e1-adcc-cd40d14a65c0@github.com> On Wed, 24 Dec 2025 05:56:04 GMT, Sergey Bylokhov wrote: > The copyright year in "jdk.compiler" files updated in 2025 has been bumped to 2025. > > The next command can be run (on top of this PR) to verify that each file had prior commits in 2025: > > `git diff HEAD~1 --name-only | while read f; do git log HEAD~1 --since="2025-01-01" --oneline -- "$f" | head -1 | grep -q . || echo "NOT IN 2025: $f"; done` Looking for volunteers to review this patch. It cannot be integrated in 2026. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28978#issuecomment-3702546566