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