Re: RFR: 8341792: Fix ExceptionOccurred in java.security.jgss
On Wed, 9 Oct 2024 16:22:13 GMT, Weijun Wang wrote: > Switch to `ExceptionCheck`. > > This is a part of an umbrella bug [JDK-8341542 JNI uses of > ExceptionOccurred() treated as if function returns a > bool](https://bugs.openjdk.org/browse/JDK-8341542). Marked as reviewed by jlu (Committer). - PR Review: https://git.openjdk.org/jdk/pull/21424#pullrequestreview-2358217762
Re: RFR: 8341792: Fix ExceptionOccurred in java.security.jgss
On Wed, 9 Oct 2024 16:22:13 GMT, Weijun Wang wrote:
> Switch to `ExceptionCheck`.
>
> This is a part of an umbrella bug [JDK-8341542 JNI uses of
> ExceptionOccurred() treated as if function returns a
> bool](https://bugs.openjdk.org/browse/JDK-8341542).
src/java.security.jgss/macosx/native/libosxkrb5/SCDynamicStoreConfig.m line 54:
> 52: CHECK_NULL(jm_Config_refresh);
> 53: (*env)->CallStaticVoidMethod(env, jc_Config, jm_Config_refresh);
> 54: if ((*env)->ExceptionOccurred(env) != NULL) {
I believe we can keep the original behavior if you want to, because its being
compared to `NULL` and not as a boolean.
> Returns the exception object that is currently in the process of being
> thrown, or NULL if no exception is currently being thrown.
But the new code might read better. So I guess it is just preference.
-
PR Review Comment: https://git.openjdk.org/jdk/pull/21424#discussion_r1793895480
Integrated: 8339735: Remove references to Applet in core-libs/security APIs
On Tue, 17 Sep 2024 23:14:16 GMT, Justin Lu wrote: > Please review this PR which removes occurrences of 'applet' within the > corelibs specification. Applet has been deprecated since JDK9, and may be a > confusing term for new Java developers, so it should be removed from the > documentation. > > Primarily, usages where 'applet' is used interchangeably with 'application' > are removed. > This change does not include removal of usages in a historical sense. For > example, something such as > > > * @apiNote > * Thread groups provided a way in early Java releases to group threads and > provide > * a form of job control for threads. Thread groups supported the > isolation > * of applets and defined methods intended for diagnostic purposes. It should > be > * rare for new applications to create ThreadGroups and interact with this > API. > > > in _src/java.base/share/classes/java/lang/ThreadGroup.java_. > Please see the JBS issue comments for further reasoning on why other > occurrences were not removed. This pull request has now been integrated. Changeset: 5f3e7aa8 Author:Justin Lu URL: https://git.openjdk.org/jdk/commit/5f3e7aa83348edafb83480ce67d0c58c46e11b24 Stats: 19 lines in 7 files changed: 0 ins; 1 del; 18 mod 8339735: Remove references to Applet in core-libs/security APIs Reviewed-by: coffeys, naoto, iris, rriggs, lancea, mullan - PR: https://git.openjdk.org/jdk/pull/21046
Re: RFR: 8339735: Remove references to Applet in core-libs/security APIs [v2]
On Wed, 18 Sep 2024 17:59:40 GMT, Justin Lu wrote: >> Please review this PR which removes occurrences of 'applet' within the >> corelibs specification. Applet has been deprecated since JDK9, and may be a >> confusing term for new Java developers, so it should be removed from the >> documentation. >> >> Primarily, usages where 'applet' is used interchangeably with 'application' >> are removed. >> This change does not include removal of usages in a historical sense. For >> example, something such as >> >> >> * @apiNote >> * Thread groups provided a way in early Java releases to group threads and >> provide >> * a form of job control for threads. Thread groups supported the >> isolation >> * of applets and defined methods intended for diagnostic purposes. It >> should be >> * rare for new applications to create ThreadGroups and interact with this >> API. >> >> >> in _src/java.base/share/classes/java/lang/ThreadGroup.java_. >> Please see the JBS issue comments for further reasoning on why other >> occurrences were not removed. > > Justin Lu has updated the pull request incrementally with one additional > commit since the last revision: > > reflect review comments Thanks for the reviews! - PR Comment: https://git.openjdk.org/jdk/pull/21046#issuecomment-2361455381
Re: RFR: 8339735: Remove references to Applet in core-libs/security APIs [v2]
> Please review this PR which removes occurrences of 'applet' within the > corelibs specification. Applet has been deprecated since JDK9, and may be a > confusing term for new Java developers, so it should be removed from the > documentation. > > Primarily, usages where 'applet' is used interchangeably with 'application' > are removed. > This change does not include removal of usages in a historical sense. For > example, something such as > > > * @apiNote > * Thread groups provided a way in early Java releases to group threads and > provide > * a form of job control for threads. Thread groups supported the > isolation > * of applets and defined methods intended for diagnostic purposes. It should > be > * rare for new applications to create ThreadGroups and interact with this > API. > > > in _src/java.base/share/classes/java/lang/ThreadGroup.java_. > Please see the JBS issue comments for further reasoning on why other > occurrences were not removed. Justin Lu has updated the pull request incrementally with one additional commit since the last revision: reflect review comments - Changes: - all: https://git.openjdk.org/jdk/pull/21046/files - new: https://git.openjdk.org/jdk/pull/21046/files/731e4ee1..19d6b725 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=21046&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21046&range=00-01 Stats: 3 lines in 2 files changed: 0 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/21046.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/21046/head:pull/21046 PR: https://git.openjdk.org/jdk/pull/21046
Re: RFR: 8339735: Remove references to Applet in core-libs/security APIs [v2]
On Wed, 18 Sep 2024 06:52:17 GMT, Alan Bateman wrote: >> `repaint()` could be substituted with another arbitrary method name to >> highlight some work this thread has to perform. >> >> given the thread name `blink`, perhaps we could just use `blink()` in this >> example. > > Don't waste too much time on the "Java Thread Primitive Deprecation" page. > The last remnant is the no-arg Thread.stop method which throws UOE > unconditionally. Once that is removed then the doc-file pages will be removed > too. Kept it simple and simply replaced with Sean's suggestion of `blink()`. - PR Review Comment: https://git.openjdk.org/jdk/pull/21046#discussion_r1765481816
Re: RFR: 8339735: Remove references to Applet in core-libs/security APIs [v2]
On Wed, 18 Sep 2024 06:53:27 GMT, Alan Bateman wrote: >> Justin Lu has updated the pull request incrementally with one additional >> commit since the last revision: >> >> reflect review comments > > src/java.base/share/classes/java/nio/charset/spi/CharsetProvider.java line 39: > >> 37: * implementation classes. Charset providers may be installed in an >> instance >> 38: * of the Java platform as extensions. Providers may also be made >> available by >> 39: * adding them to the application class path or by some other > > They can also be deployed on the application module path, maybe need a > separate JBS issue to clarify that part of the spec, and add a test. Filed https://bugs.openjdk.org/browse/JDK-8340404 to handle this. - PR Review Comment: https://git.openjdk.org/jdk/pull/21046#discussion_r1765481753
RFR: 8339735: Remove references to Applet in core-libs/security APIs
Please review this PR which removes occurrences of 'applet' within the corelibs specification. Applet has been deprecated since JDK9, and may be a confusing term for new Java developers, so it should be removed from the documentation. Primarily, usages where 'applet' is used interchangeably with 'application' are removed. This change does not include removal of usages in a historical sense. For example, something such as * @apiNote * Thread groups provided a way in early Java releases to group threads and provide * a form of job control for threads. Thread groups supported the isolation * of applets and defined methods intended for diagnostic purposes. It should be * rare for new applications to create ThreadGroups and interact with this API. in _src/java.base/share/classes/java/lang/ThreadGroup.java_. Please see the JBS issue comments for further reasoning on why other occurrences were not removed. - Commit messages: - init Changes: https://git.openjdk.org/jdk/pull/21046/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21046&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8339735 Stats: 17 lines in 7 files changed: 0 ins; 1 del; 16 mod Patch: https://git.openjdk.org/jdk/pull/21046.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/21046/head:pull/21046 PR: https://git.openjdk.org/jdk/pull/21046
Integrated: 8301991: Convert l10n properties resource bundles to UTF-8 native
On Tue, 12 Sep 2023 21:57:31 GMT, Justin Lu wrote: > JDK .properties files still use ISO-8859-1 encoding with escape sequences. It > would improve readability to see the native characters instead of escape > sequences (especially for the L10n process). The majority of files changed > are localized resource files. > > This change converts the Unicode escape sequences in the JDK .properties > files (both in src and test) to UTF-8 native characters. Additionally, the > build logic is adjusted to read the .properties files in UTF-8 while > generating the ListResourceBundle files. > > The only escape sequence not converted was `\u0020` as this is used to denote > intentional trailing white space. (E.g. `key=This is the value:\u0020`) > > The conversion was done using native2ascii with options `-reverse -encoding > UTF-8`. > > If this PR is integrated, the IDE default encoding for .properties files need > to be updated to UTF-8. (IntelliJ IDEA locks .properties files as ISO-8859-1 > unless manually changed). This pull request has now been integrated. Changeset: b55e418a Author:Justin Lu URL: https://git.openjdk.org/jdk/commit/b55e418a077791b39992042411cde97f68dc39fe Stats: 28964 lines in 488 files changed: 12 ins; 0 del; 28952 mod 8301991: Convert l10n properties resource bundles to UTF-8 native Reviewed-by: naoto - PR: https://git.openjdk.org/jdk/pull/15694
Re: RFR: 8301991: Convert l10n properties resource bundles to UTF-8 native [v2]
On Wed, 13 Sep 2023 18:12:15 GMT, Naoto Sato wrote: > Looks good to me, although I did not look at each l10n file, but sampled > some. Thanks for tackling this conversion. Thanks for the review; (In addition to testing), I ran a script to verify only white space escape sequences exist in JDK .properties files. (Excluding escape sequences in test files that should remain as is for the purpose of the test) - PR Comment: https://git.openjdk.org/jdk/pull/15694#issuecomment-1718139807
Re: RFR: 8301991: Convert l10n properties resource bundles to UTF-8 native [v2]
> JDK .properties files still use ISO-8859-1 encoding with escape sequences. It > would improve readability to see the native characters instead of escape > sequences (especially for the L10n process). The majority of files changed > are localized resource files. > > This change converts the Unicode escape sequences in the JDK .properties > files (both in src and test) to UTF-8 native characters. Additionally, the > build logic is adjusted to read the .properties files in UTF-8 while > generating the ListResourceBundle files. > > The only escape sequence not converted was `\u0020` as this is used to denote > intentional trailing white space. (E.g. `key=This is the value:\u0020`) > > The conversion was done using native2ascii with options `-reverse -encoding > UTF-8`. > > If this PR is integrated, the IDE default encoding for .properties files need > to be updated to UTF-8. (IntelliJ IDEA locks .properties files as ISO-8859-1 > unless manually changed). Justin Lu has updated the pull request incrementally with one additional commit since the last revision: Replace InputStreamReader with BufferedReader - Changes: - all: https://git.openjdk.org/jdk/pull/15694/files - new: https://git.openjdk.org/jdk/pull/15694/files/0f3698a5..ceb48bbe Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=15694&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15694&range=00-01 Stats: 18 lines in 2 files changed: 6 ins; 8 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/15694.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15694/head:pull/15694 PR: https://git.openjdk.org/jdk/pull/15694
RFR: 8301991: Convert l10n properties resource bundles to UTF-8 native
JDK .properties files still use ISO-8859-1 encoding with escape sequences. It would improve readability to see the native characters instead of escape sequences (especially for the L10n process). The majority of files changed are localized resource files. This change converts the Unicode escape sequences in the JDK .properties files (both in src and test) to UTF-8 native characters. Additionally, the build logic is adjusted to read the .properties files in UTF-8 while generating the ListResourceBundle files. The only escape sequence not converted was `\u0020` as this is used to denote intentional trailing white space. (E.g. `key=This is the value:\u0020`) The conversion was done using native2ascii with options `-reverse -encoding UTF-8`. If this PR is integrated, the IDE default encoding for .properties files need to be updated to UTF-8. (IntelliJ IDEA locks .properties files as ISO-8859-1 unless manually changed). - Commit messages: - Update header / copyright for CurrencyFormat - Adjust CurrencyFormat test to read in .properties with UTF-8 - Convert unicode escape sequences to native - Add clarifying comment in Bug6204853 for lack of conversion - Read JDK properties files in UTF-8 during build process for LRB Changes: https://git.openjdk.org/jdk/pull/15694/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15694&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8301991 Stats: 28966 lines in 488 files changed: 14 ins; 0 del; 28952 mod Patch: https://git.openjdk.org/jdk/pull/15694.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15694/head:pull/15694 PR: https://git.openjdk.org/jdk/pull/15694
Integrated: 8311081: KeytoolReaderP12Test.java fail on localized Windows platform
On Fri, 7 Jul 2023 18:58:02 GMT, Justin Lu wrote: > Please review this PR which addresses `KeytoolReaderP12Test.java` failing for > non-English locale users. > > This test checks output from keytool, but fails on finding the value 'alias > name' for non-English locale users. This is because 'alias name' is a > localized value. (For example, in `ja` this is '別名'). > > To fix the failing issue, the keytool process should be ran with > `-J-Duser.language=en -J-Duser.country=US`. This pull request has now been integrated. Changeset: b4b2fecb Author:Justin Lu URL: https://git.openjdk.org/jdk/commit/b4b2fecb42d9f14d73e8d79a9e59dee4d697f9cf Stats: 6 lines in 1 file changed: 3 ins; 0 del; 3 mod 8311081: KeytoolReaderP12Test.java fail on localized Windows platform Reviewed-by: lancea, jpai, weijun - PR: https://git.openjdk.org/jdk/pull/14806
Re: RFR: 8311081: KeytoolReaderP12Test.java fail on localized Windows platform
On Fri, 7 Jul 2023 18:58:02 GMT, Justin Lu wrote: > Please review this PR which addresses `KeytoolReaderP12Test.java` failing for > non-English locale users. > > This test checks output from keytool, but fails on finding the value 'alias > name' for non-English locale users. This is because 'alias name' is a > localized value. (For example, in `ja` this is '別名'). > > To fix the failing issue, the keytool process should be ran with > `-J-Duser.language=en -J-Duser.country=US`. I have updated the fix so that `executeKeytoolCommand()` itself always sets the English locale params, as `executeKeytoolCommand()` is not used in any sort of intentional localized testing. - PR Comment: https://git.openjdk.org/jdk/pull/14806#issuecomment-1634678111
Re: RFR: 8311081: KeytoolReaderP12Test.java fail on localized Windows platform [v2]
> Please review this PR which addresses `KeytoolReaderP12Test.java` failing for > non-English locale users. > > This test checks output from keytool, but fails on finding the value 'alias > name' for non-English locale users. This is because 'alias name' is a > localized value. (For example, in `ja` this is '別名'). > > To fix the failing issue, the keytool process should be ran with > `-J-Duser.language=en -J-Duser.country=US`. Justin Lu has updated the pull request incrementally with two additional commits since the last revision: - Revert spacing changes to KeytoolReaderP12Test.java - Move English locale params to executeKeytoolCommand - Changes: - all: https://git.openjdk.org/jdk/pull/14806/files - new: https://git.openjdk.org/jdk/pull/14806/files/57765c77..452a603d Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=14806&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14806&range=00-01 Stats: 18 lines in 2 files changed: 3 ins; 4 del; 11 mod Patch: https://git.openjdk.org/jdk/pull/14806.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/14806/head:pull/14806 PR: https://git.openjdk.org/jdk/pull/14806
RFR: 8311081: KeytoolReaderP12Test.java fail on localized Windows platform
Please review this PR which addresses `KeytoolReaderP12Test.java` failing for non-English locale users. This test checks output from keytool, but fails on finding the value 'alias name' for non-English locale users. This is because 'alias name' is a localized value. (For example, in `ja` this is '別名'). To fix the failing issue, the keytool process should be ran with `-J-Duser.language=en -J-Duser.country=US`. - Commit messages: - Launch processes in English/US locale Changes: https://git.openjdk.org/jdk/pull/14806/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14806&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8311081 Stats: 12 lines in 1 file changed: 4 ins; 0 del; 8 mod Patch: https://git.openjdk.org/jdk/pull/14806.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/14806/head:pull/14806 PR: https://git.openjdk.org/jdk/pull/14806
Integrated: 8309632: JDK 21 RDP1 L10n resource files update
On Mon, 12 Jun 2023 21:21:05 GMT, Justin Lu wrote: > Please review this PR which updates the JDK's localized resources since the > previous L10n translation drop (1/26). > > To help with reviewing the changes, @jonathan-gibbons created a tool which > displays the localized changes next to the original file's changes in UTF-8 > native. Those files can be viewed [here](https://cr.openjdk.org/~jlu/output/) > > For example, > > src="https://github.com/openjdk/jdk21/assets/67398801/e68a48a8-916e-4860-afb0-526924c6a3d3";> > > > Please note that the HTML files only apply to .properties, and not .java > resources. This pull request has now been integrated. Changeset: a1c1d97a Author:Justin Lu URL: https://git.openjdk.org/jdk21/commit/a1c1d97a4e07bae872b5608b4d8d8f85195edd82 Stats: 460 lines in 50 files changed: 279 ins; 48 del; 133 mod 8309632: JDK 21 RDP1 L10n resource files update Reviewed-by: naoto Backport-of: 81bfd78901ff540ad0355a466cfad097e701028a - PR: https://git.openjdk.org/jdk21/pull/11
Re: RFR: 8309632: JDK 21 RDP1 L10n resource files update [v2]
> Please review this PR which updates the JDK's localized resources since the > previous L10n translation drop (1/26). > > To help with reviewing the changes, @jonathan-gibbons created a tool which > displays the localized changes next to the original file's changes in UTF-8 > native. Those files can be viewed [here](https://cr.openjdk.org/~jlu/output/) > > For example, > > src="https://github.com/openjdk/jdk21/assets/67398801/e68a48a8-916e-4860-afb0-526924c6a3d3";> > > > Please note that the HTML files only apply to .properties, and not .java > resources. Justin Lu has updated the pull request incrementally with five additional commits since the last revision: - Review: correct previous commit, remove 标 as well - Review: Remove 本机 from 'javac.opt.Xlint.desc.output-file-clash' for zh_CN - Review: Use old 'err.crash' zh_CN value - Review: use Naoto's recommended ja values - Revert 'main.help.opt.any.file' value for _de - Changes: - all: https://git.openjdk.org/jdk21/pull/11/files - new: https://git.openjdk.org/jdk21/pull/11/files/13b8b309..a2e52373 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk21&pr=11&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk21&pr=11&range=00-01 Stats: 8 lines in 5 files changed: 0 ins; 0 del; 8 mod Patch: https://git.openjdk.org/jdk21/pull/11.diff Fetch: git fetch https://git.openjdk.org/jdk21.git pull/11/head:pull/11 PR: https://git.openjdk.org/jdk21/pull/11
Re: RFR: 8309632: JDK 21 RDP1 L10n resource files update
On Thu, 15 Jun 2023 21:06:32 GMT, Kevin Rushforth wrote: > Is the patch expected to be the same as in jdk mainline? I see some > differences between the two patches (which is why Skara didn't mark it as > "clean") Hi Kevin, yes it is. I still need to grab the changes from mainline and include them in this PR. - PR Comment: https://git.openjdk.org/jdk21/pull/11#issuecomment-1593728784
Integrated: 8309632: JDK 21 RDP1 L10n resource files update
On Mon, 12 Jun 2023 22:00:01 GMT, Justin Lu wrote: > Please review this PR which updates the JDK's localized resources since the > previous L10n translation drop (1/26). > > To help with reviewing the changes, @jonathan-gibbons created a tool which > displays the localized changes next to the original file's changes in UTF-8 > native. Those files can be viewed [here](https://cr.openjdk.org/~jlu/output/) > > For example, > > src="https://github.com/openjdk/jdk21/assets/67398801/e68a48a8-916e-4860-afb0-526924c6a3d3";> > > > Please note that the HTML files only apply to .properties, and not .java > resources. This pull request has now been integrated. Changeset: 81bfd789 Author:Justin Lu URL: https://git.openjdk.org/jdk/commit/81bfd78901ff540ad0355a466cfad097e701028a Stats: 460 lines in 50 files changed: 279 ins; 48 del; 133 mod 8309632: JDK 21 RDP1 L10n resource files update Reviewed-by: naoto - PR: https://git.openjdk.org/jdk/pull/14430
Re: RFR: 8309632: JDK 21 RDP1 L10n resource files update [v2]
On Tue, 13 Jun 2023 18:50:42 GMT, Justin Lu wrote:
>> src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler_de.properties
>> line 140:
>>
>>> 138:
>>> 139: # 0: type, 1: name
>>> 140: compiler.err.annotation.unrecognized.attribute.name=Annotation @{0}
>>> weist das unbekannte Attribut "{1}" auf
>>
>> Is it intentional to replace single quotes with double quotes? It is done in
>> several locations in this file, but other languages keep using single quotes
>> as in the source English resource file.
>
> I will consult the language specialist on this. I remember in previous
> discussions that certain languages would format punctuation differently, but
> let me ask about this specific instance.
The language specialist confirmed the double quotes are locale specific for de.
-
PR Review Comment: https://git.openjdk.org/jdk/pull/14430#discussion_r1229881212
Re: RFR: 8309632: JDK 21 RDP1 L10n resource files update [v2]
On Tue, 13 Jun 2023 20:56:31 GMT, Weijun Wang wrote: >> Justin Lu has updated the pull request incrementally with one additional >> commit since the last revision: >> >> Revert 'main.help.opt.any.file' value for _de > > Some comments: > > - `src/java.base/share/classes/sun/launcher/resources/launcher` > > `非 private`. "private" should be translated, just like the "static" in the > 2nd box. > > - `src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler` > > `compiler.err.annotation.unrecognized.attribute.name`: Here "annotation" is > translated to "注释"? How do you translate "comment"? > > `compiler.err.enum.label.must.be.enum.constant`: "constant" should be > translated. > > `compiler.warn.possible.this.escape`, > `compiler.warn.possible.this.escape.location`: "escape" might not mean "转义". > It's more like its original meaning "run away" or "referenced". > > > - `src/jdk.compiler/share/classes/com/sun/tools/javac/resources/javac`: > > `javac.opt.Xlint.desc.output-file-clash`: "native header files" is translated > into "本机标头文件". The "本机" is strange, I'd rather just say "头文件" as there is no > non-native header file. > > - `src/jdk.jdeps/share/classes/com/sun/tools/javap/resources/javap` > > I don't think the new translation is better than the old one. Thank you for the review @wangweij, I have addressed these recommendations > * `src/jdk.compiler/share/classes/com/sun/tools/javac/resources/javac`: > > > `javac.opt.Xlint.desc.output-file-clash`: "native header files" is translated > into "本机标头文件". The "本机" is strange, I'd rather just say "头文件" as there is no > non-native header file. > > * `src/jdk.jdeps/share/classes/com/sun/tools/javap/resources/javap` > > > I don't think the new translation is better than the old one. For the other comments, I will bring them to the language specialist for updated translations. Ideally we can get those in for this translation drop, but if not, they can go in during the second translation drop during RDP2. I am also hesitant to make too many manual changes, as they will just get overwritten by the tool in the future, so it's best to get it fixed in the tool first. - PR Comment: https://git.openjdk.org/jdk/pull/14430#issuecomment-1590087839
Re: RFR: 8309632: JDK 21 RDP1 L10n resource files update [v4]
> Please review this PR which updates the JDK's localized resources since the > previous L10n translation drop (1/26). > > To help with reviewing the changes, @jonathan-gibbons created a tool which > displays the localized changes next to the original file's changes in UTF-8 > native. Those files can be viewed [here](https://cr.openjdk.org/~jlu/output/) > > For example, > > src="https://github.com/openjdk/jdk21/assets/67398801/e68a48a8-916e-4860-afb0-526924c6a3d3";> > > > Please note that the HTML files only apply to .properties, and not .java > resources. Justin Lu has updated the pull request incrementally with three additional commits since the last revision: - Review: correct previous commit, remove 标 as well - Review: Remove 本机 from 'javac.opt.Xlint.desc.output-file-clash' for zh_CN - Review: Use old 'err.crash' zh_CN value - Changes: - all: https://git.openjdk.org/jdk/pull/14430/files - new: https://git.openjdk.org/jdk/pull/14430/files/7801eefb..f7c06512 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=14430&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14430&range=02-03 Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/14430.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/14430/head:pull/14430 PR: https://git.openjdk.org/jdk/pull/14430
Re: RFR: 8309632: JDK 21 RDP1 L10n resource files update [v2]
On Tue, 13 Jun 2023 19:59:28 GMT, Naoto Sato wrote: >> Justin Lu has updated the pull request incrementally with one additional >> commit since the last revision: >> >> Revert 'main.help.opt.any.file' value for _de > > src/java.desktop/macosx/classes/com/apple/laf/resources/aqua_ja.properties > line 63: > >> 61: >> FileChooser.newFolderExistsError.textAndMnemonic=\u305D\u306E\u540D\u524D\u306F\u3059\u3067\u306B\u4F7F\u7528\u3055\u308C\u3066\u3044\u307E\u3059 >> 62: FileChooser.chooseButton.textAndMnemonic=\u9078\u629E >> 63: >> FileChooser.chooseButtonToolTip.textAndMnemonic=\u9078\u629E\u3057\u305F\u30D5\u30A1\u30A4\u30EB\u3092\u8FFD\u52A0\u3057\u307E\u3059 > > Suggestion: > > FileChooser.chooseButtonToolTip.textAndMnemonic=\u9078\u629e\u3055\u308c\u3066\u3044\u308b\u30d5\u30a1\u30a4\u30eb\u3092\u9078\u629e\u3057\u307e\u3059 Thank you Naoto, all your recommended translations have been updated. The HTML diffs have also been updated as well. - PR Review Comment: https://git.openjdk.org/jdk/pull/14430#discussion_r1228692234
Re: RFR: 8309632: JDK 21 RDP1 L10n resource files update [v3]
> Please review this PR which updates the JDK's localized resources since the > previous L10n translation drop (1/26). > > To help with reviewing the changes, @jonathan-gibbons created a tool which > displays the localized changes next to the original file's changes in UTF-8 > native. Those files can be viewed [here](https://cr.openjdk.org/~jlu/output/) > > For example, > > src="https://github.com/openjdk/jdk21/assets/67398801/e68a48a8-916e-4860-afb0-526924c6a3d3";> > > > Please note that the HTML files only apply to .properties, and not .java > resources. Justin Lu has updated the pull request incrementally with one additional commit since the last revision: Review: use Naoto's recommended ja values - Changes: - all: https://git.openjdk.org/jdk/pull/14430/files - new: https://git.openjdk.org/jdk/pull/14430/files/8ee7bf88..7801eefb Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=14430&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14430&range=01-02 Stats: 5 lines in 2 files changed: 0 ins; 0 del; 5 mod Patch: https://git.openjdk.org/jdk/pull/14430.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/14430/head:pull/14430 PR: https://git.openjdk.org/jdk/pull/14430
Re: RFR: 8309632: JDK 21 RDP1 L10n resource files update [v2]
On Tue, 13 Jun 2023 18:13:12 GMT, Naoto Sato wrote:
>> Justin Lu has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Revert 'main.help.opt.any.file' value for _de
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler_de.properties
> line 140:
>
>> 138:
>> 139: # 0: type, 1: name
>> 140: compiler.err.annotation.unrecognized.attribute.name=Annotation @{0}
>> weist das unbekannte Attribut "{1}" auf
>
> Is it intentional to replace single quotes with double quotes? It is done in
> several locations in this file, but other languages keep using single quotes
> as in the source English resource file.
I will consult the language specialist on this. I remember in previous
discussions that certain languages would format punctuation differently, but
let ask about this specific instance.
> src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler_ja.properties
> line 959:
>
>> 957:
>> 958:
>> compiler.err.text.block.template.is.not.well.formed=\u30C6\u30AD\u30B9\u30C8\u30FB\u30D6\u30ED\u30C3\u30AF\u30FB\u30C6\u30F3\u30D7\u30EC\u30FC\u30C8\u304C\u6574\u5F62\u5F0F\u3067\u306F\u3042\u308A\u307E\u305B\u3093
>> 959:
>
> The translation of "well-formed" is incorrect. It is not 整数式
For translations that are incorrect, I can file a bug against the tool. Such a
fix would probably not happen soon, can you suggest an alternative for now?
-
PR Review Comment: https://git.openjdk.org/jdk/pull/14430#discussion_r1228567669
PR Review Comment: https://git.openjdk.org/jdk/pull/14430#discussion_r1228570665
Re: RFR: 8309632: JDK 21 RDP1 L10n resource files update [v2]
On Mon, 12 Jun 2023 22:17:25 GMT, Eirik Bjorsnos wrote: >> Justin Lu has updated the pull request incrementally with one additional >> commit since the last revision: >> >> Revert 'main.help.opt.any.file' value for _de > > src/jdk.jartool/share/classes/sun/tools/jar/resources/jar_de.properties line > 115: > >> 113: main.help.opt.main.validate=\ --validate Validiert den >> Inhalt des JAR-Archivs. Diese Option\n >> validiert, dass die von einem Multi-Release-JAR-Archiv\n >> exportierte API \u00FCber die verschiedenen Releaseversionen\n >> hinweg konsistent ist. >> 114: main.help.opt.any=\ In jedem Modus g\u00FCltige >> Vorgangsmodifikatoren:\n\n -C DIR Zum angegebenen >> Verzeichnis wechseln und die folgende\n Datei >> aufnehmen >> 115: main.help.opt.any.file=\ -f, --file=FILEDer Name der >> Archivdatei. Wenn Sie dies lauslassen, wird entweder stdin oder\n >> stdout verwendet, je nach Vorgang\n --release VERSION >> Speichert alle der folgenden Dateien in einem versionierten >> Verzeichnis\n der JAR-Datei (d.h. >> META-INF/versions/VERSION/) > > This change looks suspicious to me. The English word used is “omitted”. > “Auslassen” is to “Leave out”, while “lauslassen” is to “let go”. A native > German speaker should confirm, I have only high school level German.. Thanks for catching that. The translation tool incorrectly translated this, and we had manually fixed it with `Auslassen` in the last translation drop. This was an instance of the tool simply overwriting it this time. Will file a bug against the translation tool regarding this, to prevent it in future translation drops. - PR Review Comment: https://git.openjdk.org/jdk/pull/14430#discussion_r1227305807
Re: RFR: 8309632: JDK 21 RDP1 L10n resource files update [v2]
> Please review this PR which updates the JDK's localized resources since the > previous L10n translation drop (1/26). > > To help with reviewing the changes, @jonathan-gibbons created a tool which > displays the localized changes next to the original file's changes in UTF-8 > native. Those files can be viewed [here](https://cr.openjdk.org/~jlu/output/) > > For example, > > src="https://github.com/openjdk/jdk21/assets/67398801/e68a48a8-916e-4860-afb0-526924c6a3d3";> > > > Please note that the HTML files only apply to .properties, and not .java > resources. Justin Lu has updated the pull request incrementally with one additional commit since the last revision: Revert 'main.help.opt.any.file' value for _de - Changes: - all: https://git.openjdk.org/jdk/pull/14430/files - new: https://git.openjdk.org/jdk/pull/14430/files/ee072231..8ee7bf88 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=14430&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14430&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/14430.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/14430/head:pull/14430 PR: https://git.openjdk.org/jdk/pull/14430
Re: RFR: 8309632: JDK 21 RDP1 L10n resource files update
On Mon, 12 Jun 2023 22:00:01 GMT, Justin Lu wrote: > Please review this PR which updates the JDK's localized resources since the > previous L10n translation drop (1/26). > > To help with reviewing the changes, @jonathan-gibbons created a tool which > displays the localized changes next to the original file's changes in UTF-8 > native. Those files can be viewed [here](https://cr.openjdk.org/~jlu/output/) > > For example, > > src="https://github.com/openjdk/jdk21/assets/67398801/e68a48a8-916e-4860-afb0-526924c6a3d3";> > > > Please note that the HTML files only apply to .properties, and not .java > resources. @naotoj @wangweij @sormuras could you please review the changes that affect the languages you are familiar with when you have the chance. Please use the HTML files for this, as they will be in UTF-8 native and not unicode escaped sequences. @prrace @jonathan-gibbons @pavelrappo @lahodaj @wangweij @igraves @AlanBateman @eirbjo could you please review the modules / changes you are familiar with, thank you. - PR Comment: https://git.openjdk.org/jdk/pull/14430#issuecomment-1588180092
RFR: 8309632: JDK 21 RDP1 L10n resource files update
Please review this PR which updates the JDK's localized resources since the previous L10n translation drop (1/26). To help with reviewing the changes, @jonathan-gibbons created a tool which displays the localized changes next to the original file's changes in UTF-8 native. Those files can be viewed [here](https://cr.openjdk.org/~jlu/output/) For example, https://github.com/openjdk/jdk21/assets/67398801/e68a48a8-916e-4860-afb0-526924c6a3d3";> Please note that the HTML files only apply to .properties, and not .java resources. - Commit messages: - Merge remote-tracking branch 'justinJDK21/JDK21-RDP1-L10nDrop' into JDK21-L10NDrop-RDP1 - Revert tool's un-translation of 'exception-type' for zh-CN - Move localized currencynames.properties to jdk.localedata - Apply trailing WS tool patch - Remove extra quotes in 'main.usage' values - Revert WinResources changing of 'resource.wxl-file-name' value - Revert MsiInstallerStrings culture value changes - Apply JDK21 Open translation patch Changes: https://git.openjdk.org/jdk/pull/14430/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14430&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8309632 Stats: 462 lines in 51 files changed: 279 ins; 48 del; 135 mod Patch: https://git.openjdk.org/jdk/pull/14430.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/14430/head:pull/14430 PR: https://git.openjdk.org/jdk/pull/14430
Re: RFR: 8309632: JDK 21 RDP1 L10n resource files update
On Mon, 12 Jun 2023 21:42:24 GMT, Kevin Rushforth wrote: >> @prrace @jonathan-gibbons @pavelrappo @lahodaj @wangweij @igraves >> @AlanBateman @eirbjo could you please review the modules / changes you are >> familiar with, thank you. > > @justin-curtis-lu Unless there is a strong reason to do otherwise, Please > submit a PR against jdk mainline first. Then, once that is integrated, you > can proceed with this PR as a backport to JDK 21. > > See: https://mail.openjdk.org/pipermail/jdk-dev/2023-June/007894.html @kevinrushforth Thanks for the reminder, will make the change in ML first. - PR Comment: https://git.openjdk.org/jdk21/pull/11#issuecomment-1588156115
Re: RFR: 8309632: JDK 21 RDP1 L10n resource files update
On Mon, 12 Jun 2023 21:21:05 GMT, Justin Lu wrote: > Please review this PR which updates the JDK's localized resources since the > previous L10n translation drop (1/26). > > To help with reviewing the changes, @jonathan-gibbons created a tool which > displays the localized changes next to the original file's changes in UTF-8 > native. Those files can be viewed [here](https://cr.openjdk.org/~jlu/output/) > > For example, > > src="https://github.com/openjdk/jdk21/assets/67398801/e68a48a8-916e-4860-afb0-526924c6a3d3";> > > > Please note that the HTML files only apply to .properties, and not .java > resources. @prrace @jonathan-gibbons @pavelrappo @lahodaj @wangweij @igraves @AlanBateman @eirbjo could you please review the modules / changes you are familiar with, thank you. - PR Comment: https://git.openjdk.org/jdk21/pull/11#issuecomment-1588130775
Re: RFR: 8309632: JDK 21 RDP1 L10n resource files update
On Mon, 12 Jun 2023 21:21:05 GMT, Justin Lu wrote: > Please review this PR which updates the JDK's localized resources since the > previous L10n translation drop (1/26). > > To help with reviewing the changes, @jonathan-gibbons created a tool which > displays the localized changes next to the original file's changes in UTF-8 > native. Those files can be viewed [here](https://cr.openjdk.org/~jlu/output/) > > For example, > > src="https://github.com/openjdk/jdk21/assets/67398801/e68a48a8-916e-4860-afb0-526924c6a3d3";> > > > Please note that the HTML files only apply to .properties, and not .java > resources. @naotoj @wangweij @sormuras could you please review the changes that affect the languages you are familiar with when you have the chance. Please use the HTML files for this, as they will be in UTF-8 native and not unicode escaped sequences. - PR Comment: https://git.openjdk.org/jdk21/pull/11#issuecomment-1588123540
RFR: 8309632: JDK 21 RDP1 L10n resource files update
Please review this PR which updates the JDK's localized resources since the previous L10n translation drop (1/26). To help with reviewing the changes, @jonathan-gibbons created a tool which displays the localized changes next to the original file's changes in UTF-8 native. Those files can be viewed [here](https://cr.openjdk.org/~jlu/output/) For example, https://github.com/openjdk/jdk21/assets/67398801/e68a48a8-916e-4860-afb0-526924c6a3d3";> Please note that the HTML files only apply to .properties, and not .java resources. - Commit messages: - Revert tool's un-translation of 'exception-type' for zh-CN - Move localized currencynames.properties to jdk.localedata - Apply trailing WS tool patch - Remove extra quotes in 'main.usage' values - Revert WinResources changing of 'resource.wxl-file-name' value - Revert MsiInstallerStrings culture value changes - Apply JDK21 Open translation patch Changes: https://git.openjdk.org/jdk21/pull/11/files Webrev: https://webrevs.openjdk.org/?repo=jdk21&pr=11&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8309632 Stats: 462 lines in 51 files changed: 279 ins; 48 del; 135 mod Patch: https://git.openjdk.org/jdk21/pull/11.diff Fetch: git fetch https://git.openjdk.org/jdk21.git pull/11/head:pull/11 PR: https://git.openjdk.org/jdk21/pull/11
Re: RFR: 8308016: Use snippets in java.io package
On Fri, 12 May 2023 16:17:38 GMT, Brian Burkhalter wrote:
> Replace `{@code ...}` patterns and the like with `{@snippet
> lang=java : ...}`.
src/java.base/share/classes/java/io/Console.java line 124:
> 122: * if (con != null) {
> 123: * Scanner sc = new Scanner(con.reader());
> 124: * ...
I'm not sure how you feel about this, but when I have been converting ``
blocks to `@snippet`, I usually try to get rid of non code. Since snippet
allows user's to copy the example code, I feel like it's redudant to leave in
non code, since they will likely delete it anyways.
-
PR Review Comment: https://git.openjdk.org/jdk/pull/13957#discussion_r1192635740
Re: RFR: 8301991: Convert l10n properties resource bundles to UTF-8 native [v6]
On Thu, 11 May 2023 20:21:57 GMT, Justin Lu wrote: >> This PR converts Unicode sequences to UTF-8 native in .properties file. >> (Excluding the Unicode space and tab sequence). The conversion was done >> using native2ascii. >> >> In addition, the build logic is adjusted to support reading in the >> .properties files as UTF-8 during the conversion from .properties file to >> .java ListResourceBundle file. > > Justin Lu has updated the pull request with a new target base due to a merge > or a rebase. The pull request now contains 16 commits: > > - Convert the merged master changes to UTF-8 > - Merge master and fix conflicts > - Close streams when finished loading into props > - Adjust CF test to read in with UTF-8 to fix failing test > - Reconvert CS.properties to UTF-8 > - Revert all changes to CurrencySymbols.properties > - Bug6204853 should not be converted > - Copyright year for CompileProperties > - Redo translation for CS.properties > - Spot convert CurrencySymbols.properties > - ... and 6 more: https://git.openjdk.org/jdk/compare/4386d42d...f15b373a Wondering if anyone has any thoughts on the consequences of this PR, in relation to Intellj's (and other IDEs) default encoding for .properties files. Intellj sets the default encoding for .properties files to ISO-8859-1, which would be the wrong encoding if the .properties files are converted to UTF-8 native. This would cause certain key,values to be skewed when represented in the file. Although the default file-encoding for .properties can be switched to UTF-8, it is not the default. Wondering what some solutions/thoughts to this are. - PR Comment: https://git.openjdk.org/jdk/pull/12726#issuecomment-1544708830
Re: RFR: 8301991: Convert l10n properties resource bundles to UTF-8 native [v6]
> This PR converts Unicode sequences to UTF-8 native in .properties file. > (Excluding the Unicode space and tab sequence). The conversion was done using > native2ascii. > > In addition, the build logic is adjusted to support reading in the > .properties files as UTF-8 during the conversion from .properties file to > .java ListResourceBundle file. Justin Lu has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 16 commits: - Convert the merged master changes to UTF-8 - Merge master and fix conflicts - Close streams when finished loading into props - Adjust CF test to read in with UTF-8 to fix failing test - Reconvert CS.properties to UTF-8 - Revert all changes to CurrencySymbols.properties - Bug6204853 should not be converted - Copyright year for CompileProperties - Redo translation for CS.properties - Spot convert CurrencySymbols.properties - ... and 6 more: https://git.openjdk.org/jdk/compare/4386d42d...f15b373a - Changes: https://git.openjdk.org/jdk/pull/12726/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12726&range=05 Stats: 28877 lines in 493 files changed: 14 ins; 1 del; 28862 mod Patch: https://git.openjdk.org/jdk/pull/12726.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/12726/head:pull/12726 PR: https://git.openjdk.org/jdk/pull/12726
Re: RFR: 8301991: Convert l10n properties resource bundles to UTF-8 native [v5]
On Fri, 17 Mar 2023 22:27:48 GMT, Justin Lu wrote: >> This PR converts Unicode sequences to UTF-8 native in .properties file. >> (Excluding the Unicode space and tab sequence). The conversion was done >> using native2ascii. >> >> In addition, the build logic is adjusted to support reading in the >> .properties files as UTF-8 during the conversion from .properties file to >> .java ListResourceBundle file. > > Justin Lu has updated the pull request incrementally with one additional > commit since the last revision: > > Close streams when finished loading into props Something thing to consider is that Intellj defaults .properties files to ISO 8859-1. https://www.jetbrains.com/help/idea/properties-files.html#encoding So users of Intellj / (other IDEs that default to ISO 8859-1 for .properties files) will need to change the default encoding to utf-8 for such files. Or ideally, the respective IDEs can change their default encoding for .properties files if this change is integrated. - PR Comment: https://git.openjdk.org/jdk/pull/12726#issuecomment-1492640306
Re: RFR: 8301991: Convert l10n properties resource bundles to UTF-8 native [v5]
> This PR converts Unicode sequences to UTF-8 native in .properties file. > (Excluding the Unicode space and tab sequence). The conversion was done using > native2ascii. > > In addition, the build logic is adjusted to support reading in the > .properties files as UTF-8 during the conversion from .properties file to > .java ListResourceBundle file. Justin Lu has updated the pull request incrementally with one additional commit since the last revision: Close streams when finished loading into props - Changes: - all: https://git.openjdk.org/jdk/pull/12726/files - new: https://git.openjdk.org/jdk/pull/12726/files/007c78a7..19b91e6b Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=12726&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12726&range=03-04 Stats: 15 lines in 3 files changed: 6 ins; 1 del; 8 mod Patch: https://git.openjdk.org/jdk/pull/12726.diff Fetch: git fetch https://git.openjdk.org/jdk pull/12726/head:pull/12726 PR: https://git.openjdk.org/jdk/pull/12726
Re: RFR: 8301991: Convert l10n properties resource bundles to UTF-8 native [v4]
> This PR converts Unicode sequences to UTF-8 native in .properties file. > (Excluding the Unicode space and tab sequence). The conversion was done using > native2ascii. > > In addition, the build logic is adjusted to support reading in the > .properties files as UTF-8 during the conversion from .properties file to > .java ListResourceBundle file. Justin Lu has updated the pull request incrementally with one additional commit since the last revision: Adjust CF test to read in with UTF-8 to fix failing test - Changes: - all: https://git.openjdk.org/jdk/pull/12726/files - new: https://git.openjdk.org/jdk/pull/12726/files/7119830b..007c78a7 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=12726&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12726&range=02-03 Stats: 3 lines in 1 file changed: 2 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/12726.diff Fetch: git fetch https://git.openjdk.org/jdk pull/12726/head:pull/12726 PR: https://git.openjdk.org/jdk/pull/12726
Re: RFR: 8301991: Convert l10n properties resource bundles to UTF-8 native [v3]
On Thu, 16 Mar 2023 18:31:23 GMT, Justin Lu wrote: >> This PR converts Unicode sequences to UTF-8 native in .properties file. >> (Excluding the Unicode space and tab sequence). The conversion was done >> using native2ascii. >> >> In addition, the build logic is adjusted to support reading in the >> .properties files as UTF-8 during the conversion from .properties file to >> .java ListResourceBundle file. > > Justin Lu has updated the pull request incrementally with two additional > commits since the last revision: > > - Reconvert CS.properties to UTF-8 > - Revert all changes to CurrencySymbols.properties test/jdk/java/text/Format/NumberFormat/CurrencySymbols.properties line 1: > 1: # CurrencySymbols.properties is fully converted to UTF-8 now - PR: https://git.openjdk.org/jdk/pull/12726
Re: RFR: 8301991: Convert l10n properties resource bundles to UTF-8 native [v3]
> This PR converts Unicode sequences to UTF-8 native in .properties file. > (Excluding the Unicode space and tab sequence). The conversion was done using > native2ascii. > > In addition, the build logic is adjusted to support reading in the > .properties files as UTF-8 during the conversion from .properties file to > .java ListResourceBundle file. Justin Lu has updated the pull request incrementally with two additional commits since the last revision: - Reconvert CS.properties to UTF-8 - Revert all changes to CurrencySymbols.properties - Changes: - all: https://git.openjdk.org/jdk/pull/12726/files - new: https://git.openjdk.org/jdk/pull/12726/files/6d6bffe8..7119830b Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=12726&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12726&range=01-02 Stats: 87 lines in 1 file changed: 0 ins; 0 del; 87 mod Patch: https://git.openjdk.org/jdk/pull/12726.diff Fetch: git fetch https://git.openjdk.org/jdk pull/12726/head:pull/12726 PR: https://git.openjdk.org/jdk/pull/12726
Re: RFR: 8301991: Convert l10n properties resource bundles to UTF-8 native [v2]
On Thu, 16 Mar 2023 18:19:29 GMT, Justin Lu wrote: >> This PR converts Unicode sequences to UTF-8 native in .properties file. >> (Excluding the Unicode space and tab sequence). The conversion was done >> using native2ascii. >> >> In addition, the build logic is adjusted to support reading in the >> .properties files as UTF-8 during the conversion from .properties file to >> .java ListResourceBundle file. > > Justin Lu has updated the pull request incrementally with four additional > commits since the last revision: > > - Bug6204853 should not be converted > - Copyright year for CompileProperties > - Redo translation for CS.properties > - Spot convert CurrencySymbols.properties test/jdk/java/text/Format/NumberFormat/CurrencySymbols.properties line 1: > 1: # Conversion did not work as expected, addressing right now. - PR: https://git.openjdk.org/jdk/pull/12726
Re: RFR: 8301991: Convert l10n properties resource bundles to UTF-8 native [v2]
On Wed, 15 Mar 2023 16:18:44 GMT, Archie L. Cobbs wrote: >> Justin Lu has updated the pull request incrementally with four additional >> commits since the last revision: >> >> - Bug6204853 should not be converted >> - Copyright year for CompileProperties >> - Redo translation for CS.properties >> - Spot convert CurrencySymbols.properties > > test/jdk/java/util/ResourceBundle/Bug6204853.properties line 1: > >> 1: # > > This file should probably be excluded because it's used in a test that > relates to UTF-8 encoding (or not) of property files. Thank you, removed the changes for this file - PR: https://git.openjdk.org/jdk/pull/12726
Re: RFR: 8301991: Convert l10n properties resource bundles to UTF-8 native [v2]
On Wed, 15 Mar 2023 20:19:51 GMT, Naoto Sato wrote: >> Justin Lu has updated the pull request incrementally with four additional >> commits since the last revision: >> >> - Bug6204853 should not be converted >> - Copyright year for CompileProperties >> - Redo translation for CS.properties >> - Spot convert CurrencySymbols.properties > > test/jdk/java/text/Format/NumberFormat/CurrencySymbols.properties line 156: > >> 154: zh=\u00A4 >> 155: zh_CN=\uFFE5 >> 156: zh_HK=HK$ > > Why are they not encoded into UTF-8 native? Not sure, thank you for catching it. Working on it right now. - PR: https://git.openjdk.org/jdk/pull/12726
Re: RFR: 8301991: Convert l10n properties resource bundles to UTF-8 native [v2]
> This PR converts Unicode sequences to UTF-8 native in .properties file. > (Excluding the Unicode space and tab sequence). The conversion was done using > native2ascii. > > In addition, the build logic is adjusted to support reading in the > .properties files as UTF-8 during the conversion from .properties file to > .java ListResourceBundle file. Justin Lu has updated the pull request incrementally with four additional commits since the last revision: - Bug6204853 should not be converted - Copyright year for CompileProperties - Redo translation for CS.properties - Spot convert CurrencySymbols.properties - Changes: - all: https://git.openjdk.org/jdk/pull/12726/files - new: https://git.openjdk.org/jdk/pull/12726/files/1e798f24..6d6bffe8 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=12726&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12726&range=00-01 Stats: 92 lines in 4 files changed: 0 ins; 0 del; 92 mod Patch: https://git.openjdk.org/jdk/pull/12726.diff Fetch: git fetch https://git.openjdk.org/jdk pull/12726/head:pull/12726 PR: https://git.openjdk.org/jdk/pull/12726
RFR: 8301991: Convert l10n properties resource bundles to UTF-8 native
This PR converts Unicode sequences to UTF-8 native in .properties file. (Excluding the Unicode space and tab sequence). The conversion was done using native2ascii. In addition, the build logic is adjusted to support reading in the .properties files as UTF-8 during the conversion from .properties file to .java ListResourceBundle file. - Commit messages: - Write to ASCII - Read in .properties as UTF-8, but write to LRB .java as ISO-8859-1 - Compile class with ascii (Not ready to make system wide change) - Toggle UTF-8 for javac option in JavaCompilation.gmk - CompileProperties converts in UTF-8 - Convert .properties from ISO-8859-1 to UTF-8 Changes: https://git.openjdk.org/jdk/pull/12726/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12726&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8301991 Stats: 29093 lines in 490 files changed: 6 ins; 0 del; 29087 mod Patch: https://git.openjdk.org/jdk/pull/12726.diff Fetch: git fetch https://git.openjdk.org/jdk pull/12726/head:pull/12726 PR: https://git.openjdk.org/jdk/pull/12726
Re: RFR: 8301991: Convert l10n properties resource bundles to UTF-8 native
On Tue, 7 Mar 2023 23:15:14 GMT, Jonathan Gibbons wrote:
>> This PR converts Unicode sequences to UTF-8 native in .properties file.
>> (Excluding the Unicode space and tab sequence). The conversion was done
>> using native2ascii.
>>
>> In addition, the build logic is adjusted to support reading in the
>> .properties files as UTF-8 during the conversion from .properties file to
>> .java ListResourceBundle file.
>
> make/langtools/tools/compileproperties/CompileProperties.java line 252:
>
>> 250: try {
>> 251: writer = new BufferedWriter(
>> 252: new OutputStreamWriter(new
>> FileOutputStream(outputPath), StandardCharsets.ISO_8859_1));
>
> Using ISO_8859_1 seems strange.
> Since these are generated files, you could write them as UTF-8 and then
> override the default javac option for ascii when compiling _just_ these files.
>
> Or else just stay with ascii; no one should be looking at these files!
Will stick with your latter solution, as since the .properties files were
converted via native2ascii, it makes sense to write out via ascii.
-
PR: https://git.openjdk.org/jdk/pull/12726
Re: [jdk20] RFR: 8298133: JDK 20 RDP1 L10n resource files update - msgdrop 10
On Thu, 15 Dec 2022 00:58:06 GMT, Justin Lu wrote: >> Open l10n drop >> All tests passed > > src/jdk.jlink/share/classes/jdk/tools/jlink/resources/plugins_zh_CN.properties > line 188: > >> 186: main.plugin.module=\u63D2\u4EF6\u6A21\u5757 >> 187: >> 188: main.plugin.category=\u7C7B\u522B > > As Naoto pointed out, it looks like a trailing space was added by accident. > This is also done in the ja version but for a different value. And no space > was added for any value for the de version. It looks like the translation > drop that Damon is receiving contains random changes. Additionally, there were changes made to plugins.properties in October that were not translated in the translation drop - PR: https://git.openjdk.org/jdk20/pull/35
Re: [jdk20] RFR: 8298133: JDK 20 RDP1 L10n resource files update - msgdrop 10
On Wed, 14 Dec 2022 23:40:52 GMT, Damon Nguyen wrote: > Open l10n drop > All tests passed src/jdk.jlink/share/classes/jdk/tools/jmod/resources/jmod_de.properties line 26: > 24: # > 25: > 26: jmod.description=JMOD-Dateien erstellen und den Inhalt vorhandener > JMOD-Dateien auflisten `jlink.description` was added to `jmod.properties` in May 2022 (Which was before Alisen's drop for JDK19). Shouldn't this have been translated during the 19 drop in August, as opposed to showing up now? - PR: https://git.openjdk.org/jdk20/pull/35
Re: [jdk20] RFR: 8298133: JDK 20 RDP1 L10n resource files update - msgdrop 10
On Wed, 14 Dec 2022 23:40:52 GMT, Damon Nguyen wrote: > Open l10n drop > All tests passed src/jdk.jlink/share/classes/jdk/tools/jlink/resources/plugins_zh_CN.properties line 188: > 186: main.plugin.module=\u63D2\u4EF6\u6A21\u5757 > 187: > 188: main.plugin.category=\u7C7B\u522B As Naoto pointed out, it looks like a trailing space was added by accident. This is also done in the ja version but for a different value. And no space was added for any value for the de version. It looks like the translation drop that Damon is receiving contains random changes. - PR: https://git.openjdk.org/jdk20/pull/35
Re: RFR: 8298045: Fix hidden but significant trailing whitespace in properties files for core-libs code
On Fri, 2 Dec 2022 16:40:51 GMT, Magnus Ihse Bursie wrote:
> According to [the
> specification](https://docs.oracle.com/en/java/javase/19/docs/api/java.base/java/util/Properties.html#load(java.io.Reader))
> trailing whitespaces in the values of properties files are (somewhat
> surprisingly) actually significant.
>
> We have multiple files in the JDK with trailing whitespaces in the values.
> For most of this files, this is likely incorrect and due to oversight, but in
> a few cases it might actually be intended (like "The value is: ").
>
> After a discussion in the PR for
> [JDK-8295729](https://bugs.openjdk.org/browse/JDK-8295729), the consensus was
> to replace valid trailing spaces with the corresponding unicode sequence,
> `\u0020`. (And of course remove non-wanted trailing spaces.)
>
> Doing so has a dual benefit:
>
> 1) It makes it clear to everyone reading the code that there is a trailing
> space and it is intended
>
> 2) It will allow us to remove all actual trailing space characters, and turn
> on the corresponding check in jcheck to keep the properties files, just like
> all other source code files, free of trailing spaces.
>
> Ultimately, the call of whether a trailing space is supposed to be there, or
> is a bug, lies with the respective component teams owning these files. Thus I
> have split up the set of properties files with trailing spaces in several
> groups, to match the JDK teams, and open a JBS issue for each of them. This
> issue is for code I believe belong with the core-libs team.
src/java.sql.rowset/share/classes/com/sun/rowset/RowSetResourceBundle_zh_TW.properties
line 160:
> 158: xmlrch.errupdate =
> \u5EFA\u69CB\u66F4\u65B0\u5217\u6642\u767C\u751F\u932F\u8AA4: {0}
> 159: xmlrch.errupdrow = \u66F4\u65B0\u5217\u6642\u767C\u751F\u932F\u8AA4: {0}
> 160: xmlrch.chars = \u5B57\u5143:\u0020
Likely not needed, since the original and all other l10n versions of
RowSetResourceBundle.properties do not have a trailing space for `xmlrch.chars`
src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XMLMessages.properties
line 24:
> 22:
> 23: BadMessageKey = The error message corresponding to the message
> key can not be found.
> 24: FormatFailed = An internal error occurred while formatting the
> following message:\n\u0020\u0020
Likely a mistake, since as you stated, it is not in the format “foo:\u0020” as
there is a newline before the trailing spaces.
However if intentional it should probably be `FormatFailed = An internal error
occurred while formatting the following message:\n\u0020`
src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XMLMessages.properties
line 139:
> 137: EncodingByteOrderUnsupported = Given byte order for encoding
> \"{0}\" is not supported.
> 138: InvalidByte = Invalid byte {0} of {1}-byte UTF-8 sequence.
> 139: ExpectedByte = Expected byte {0} of {1}-byte UTF-8
> sequence.\u0020\u0020
Same here as well, either a mistake or should be ` ExpectedByte = Expected byte
{0} of {1}-byte UTF-8 sequence.\u0020`
src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XMLMessages.properties
line 219:
> 217: MSG_NOTATION_NAME_REQUIRED_FOR_UNPARSED_ENTITYDECL = The
> notation name is required after \"NDATA\" in the declaration for the entity
> \"{0}\".
> 218: EntityDeclUnterminated = The declaration for the entity \"{0}\"
> must end with ''>''.
> 219: MSG_DUPLICATE_ENTITY_DEFINITION = Entity \"{0}\" is declared more than
> once.\u0020\u0020\u0020\u0020\u0020\u0020\u0020\u0020
Likely not intentional, but if it is then perhaps
`MSG_DUPLICATE_ENTITY_DEFINITION = Entity "{0}" is declared more than
once.\u0009` instead.
-
PR: https://git.openjdk.org/jdk/pull/11489
Re: RFR: 8298045: Fix hidden but significant trailing whitespace in properties files for core-libs code
On Fri, 2 Dec 2022 16:40:51 GMT, Magnus Ihse Bursie wrote: > According to [the > specification](https://docs.oracle.com/en/java/javase/19/docs/api/java.base/java/util/Properties.html#load(java.io.Reader)) > trailing whitespaces in the values of properties files are (somewhat > surprisingly) actually significant. > > We have multiple files in the JDK with trailing whitespaces in the values. > For most of this files, this is likely incorrect and due to oversight, but in > a few cases it might actually be intended (like "The value is: "). > > After a discussion in the PR for > [JDK-8295729](https://bugs.openjdk.org/browse/JDK-8295729), the consensus was > to replace valid trailing spaces with the corresponding unicode sequence, > `\u0020`. (And of course remove non-wanted trailing spaces.) > > Doing so has a dual benefit: > > 1) It makes it clear to everyone reading the code that there is a trailing > space and it is intended > > 2) It will allow us to remove all actual trailing space characters, and turn > on the corresponding check in jcheck to keep the properties files, just like > all other source code files, free of trailing spaces. > > Ultimately, the call of whether a trailing space is supposed to be there, or > is a bug, lies with the respective component teams owning these files. Thus I > have split up the set of properties files with trailing spaces in several > groups, to match the JDK teams, and open a JBS issue for each of them. This > issue is for code I believe belong with the core-libs team. src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XMLMessages_fr.properties line 281: > 279: # Namespaces support > 280: # 4. Using Qualified Names > 281: IllegalQName = L'\u00E9l\u00E9ment ou l'attribut ne correspond > pas \u00E0 la production QName : QName::=(NCName':')?NCName.\u0020 XMLMessages.properties does not have a trailing space for IllegalQName. For consistency with the original, there should probably be no space (unless the original is incorrect). - PR: https://git.openjdk.org/jdk/pull/11489
