Re: [11] RFR: 8202026 8193552 8204269 : ISO 4217 Amendment #165 # 166 #167 Update
Hi Naoto, Pls review the updated code: http://cr.openjdk.java.net/~ljiang/8202026/webrev.02/ - As suggested, clean up the old transition dates. - Update copyright year. - ISO 4217 Amendment #167 was published today, which discards the #166, so withdraw the change for #166 in webrev.02. Bug for #167: https://bugs.openjdk.java.net/browse/JDK-8204269 Test passed on mach5. Thanks, Leo On 26/04/2018 1:00 AM, naoto.s...@oracle.com wrote: Hi Leo, Although JDK11 is slated in 09/2018, enabling amendment 166 now is technically a bug, as it will be effective from June 4. Please use the transition mechanism in make/data/currency/CurrencyData.properties and test/jdk/java/util/Currency/tablea1.txt. OTOH, there are old (past) transition entries. I would clean up those entries, such as: 326 # LATVIA 327 LV=LVL;2013-12-31-22-00-00;EUR in CurrencyData.properties. This applies to tabela1.txt as well. Naoto On 4/24/18 8:52 PM, Leo Jiang wrote: Forgot to mention, the tests in Currency fold are passed on Mach5. -Leo On 04/25/2018 09:33 AM, Leo Jiang wrote: Hi, Please review the changes to address the ISO 4217 Amendment 165 166 update. Bug: https://bugs.openjdk.java.net/browse/JDK-8193552 165 https://bugs.openjdk.java.net/browse/JDK-8202026 166 CR: http://cr.openjdk.java.net/~ljiang/8202026/webrev.00/ Detail: #165 From: MAURITANIA Ouguiya MRO 478 2 To: MAURITANIA Ouguiya MRU 929 2 #166 From: VENEZUELA (BOLIVARIAN REPUBLIC OF) Bolívar VEF 937 2 To: VENEZUELA (BOLIVARIAN REPUBLIC OF) Bolívar Soberano VES 928 2 Thanks, Leo
Re: [11] RFR: 8202026 8193552 8204269 : ISO 4217 Amendment #165 # 166 #167 Update
Hi Naoto, I removed the obsoleted currency LTL and LVL from tablea1.txt, added them into otherCodes in ValidateISO4217.java. new webrev as below: http://cr.openjdk.java.net/~ljiang/8202026/webrev.03/ Thanks, Leo On 05/06/2018 2:27 AM, naoto.s...@oracle.com wrote: Hi Leo, Change looks good. One leftover from the previous: >> in CurrencyData.properties. This applies to tabela1.txt as well. Can you please clean those LV/LT entries in tablea1.txt as well? Naoto On 6/4/18 7:41 AM, li.ji...@oracle.com wrote: Hi Naoto, Pls review the updated code: http://cr.openjdk.java.net/~ljiang/8202026/webrev.02/ - As suggested, clean up the old transition dates. - Update copyright year. - ISO 4217 Amendment #167 was published today, which discards the #166, so withdraw the change for #166 in webrev.02. Bug for #167: https://bugs.openjdk.java.net/browse/JDK-8204269 Test passed on mach5. Thanks, Leo On 26/04/2018 1:00 AM, naoto.s...@oracle.com wrote: Hi Leo, Although JDK11 is slated in 09/2018, enabling amendment 166 now is technically a bug, as it will be effective from June 4. Please use the transition mechanism in make/data/currency/CurrencyData.properties and test/jdk/java/util/Currency/tablea1.txt. OTOH, there are old (past) transition entries. I would clean up those entries, such as: 326 # LATVIA 327 LV=LVL;2013-12-31-22-00-00;EUR in CurrencyData.properties. This applies to tabela1.txt as well. Naoto On 4/24/18 8:52 PM, Leo Jiang wrote: Forgot to mention, the tests in Currency fold are passed on Mach5. -Leo On 04/25/2018 09:33 AM, Leo Jiang wrote: Hi, Please review the changes to address the ISO 4217 Amendment 165 166 update. Bug: https://bugs.openjdk.java.net/browse/JDK-8193552 165 https://bugs.openjdk.java.net/browse/JDK-8202026 166 CR: http://cr.openjdk.java.net/~ljiang/8202026/webrev.00/ Detail: #165 From: MAURITANIA Ouguiya MRO 478 2 To: MAURITANIA Ouguiya MRU 929 2 #166 From: VENEZUELA (BOLIVARIAN REPUBLIC OF) Bolívar VEF 937 2 To: VENEZUELA (BOLIVARIAN REPUBLIC OF) Bolívar Soberano VES 928 2 Thanks, Leo
RFR: 8208746 8209775 : ISO 4217 Amendment #168 #169 Update
Hi, Please review the changes for ISO 4217 Amendment #168 #169. Bugs: https://bugs.openjdk.java.net/browse/JDK-8208746 168 https://bugs.openjdk.java.net/browse/JDK-8209775 169 Only in amendment #168 has real currency data update for Java, but I also updated the data version to #169 for consistent. Changes include: - Update the currency for VENEZUELA (BOLIVARIAN REPUBLIC OF), VES 928 minor 2 - Update the currency name to 'Bolívar Soberano' - Move the currency VEF to historical currencies - Correct the currency name for PHILIPPINES (THE): Philippine Peso (instead of Piso) - Change the country name: SWAZILAND to ESWATINI Webrev: http://cr.openjdk.java.net/~ljiang/8208746/webrev.00/ Build and test passed on mach5 for all platforms. Thanks, Leo
RFR: 8210153 : java/text/Format/NumberFormat/CurrencyFormat.java failed
Hi Naoto, Please review the fix to update the currency symbol for VES. Bug: https://bugs.openjdk.java.net/browse/JDK-8210153 Webrev: http://cr.openjdk.java.net/~ljiang/8210153/webrev/ Built and tier1~tier3 tests passed on mach5. Thanks, Leo
Re: UnicodeDecoder U+FFFE handling
Sounds this request is reasonable since Unicode 7: do not consider the
U+FFFE in the middle of stream as malformed.
FAQ about private use characters and non-characters. [1]
http://www.unicode.org/faq/private_use.html
Q: Are noncharacters invalid in Unicode strings and UTFs?
A: Absolutely not. Noncharacters do not cause a Unicode string to be
ill-formed in any UTF.
Q: So how should libraries and tools handle noncharacters?
A: Library APIs, components, and tool applications (such as low-level
text editors) which handle all Unicode strings should also handle
noncharacters. Often this means simple pass-through, the same way such
an API or tool would handle a reserved unassigned code point.
Thanks
Leo
On 12/24/18 3:06 AM, Clément MATHIEU wrote:
Hi,
I am wondering if UnicodeDecoder handling of U+FFFE is compliant with
current Unicode specification. Supsicious code is:
if (c == REVERSED_MARK) {
// A reversed BOM cannot occur within middle of stream
return CoderResult.malformedForLength(2);
}
Up to Unicode 6.3 Unicode specification said that U+FFFE is a non
character and that non characters "should never been interchanged".
Returning CR_MALFORMED on U+FFFE appears to be correct for Java 8
(Unicode 6.2).
However, Unicode 7 changed that and now says:
Applications are free to use any of these noncharacter code
points internally. They have no standard interpretation when
exchanged outside the context of internal use. However, they are
not illegal in interchange, nor does their presence cause Unicode
text to be ill-formed. [...] They are not prohibited from
occurring in valid Unicode strings which happen to be in
terchanged. [...]. If a noncharacter is received in open
interchange, an application is not required to interpret it in
any way. It is good practice, however, to recognize it as a
noncharacter and to take appropriate action, such as replacing it
with U+FFFD replacement character, to indicate
the problem in the text. It is not recommended to simpl
y delete noncharacter code points from such text, because of
the potential security issues caused by deleting uninterpreted
characters.
See:
- http://www.unicode.org/versions/corrigendum9.html
- https://www.unicode.org/versions/Unicode11.0.0/ch23.pdf (23.7)
Do you think that returning CR_MALFORMED is still OK?
Regards,
Clément MATHIEU
Re: [PATCH] Fix typo in usage for javac
Hi Noriyuki,
Very appreciated to report this typo and contribute the patch.
This typo issue was introduced by the JDK 12 msg drop 10, and into JDK
13 with the forward port. As we need to fix it on translation memory
side first, so we don't fix it on resource files in repo directly.
File a bug: https://bugs.openjdk.java.net/browse/JDK-8216590
The fix would be integrated with JDK 12 msg drop 20, and then fix it in
JDK 13 with forward port.
Thanks,
Leo
On 1/11/19 5:57 PM, 数沢 則征 wrote:
Hi all,
I noticed a typo in the usage of javac(in Japanese).
jdk-13-ea+3
--release
特定のリリース用ににコンパイルします。サポートされているリリース: 7, 8, 9, 10, 11, 13
jdk-13-ea+1
--release
特定のVMバージョン用にコンパイルします。サポートされているターゲット: 7, 8, 9, 10, 11, 13
Patch attached below. Could you please review it.
diff -r e832101ff63c
src/jdk.compiler/share/classes/com/sun/tools/javac/resources/javac_ja.properties
---
a/src/jdk.compiler/share/classes/com/sun/tools/javac/resources/javac_ja.properties
Wed Jan 09 14:46:40 2019 +0100
+++
b/src/jdk.compiler/share/classes/com/sun/tools/javac/resources/javac_ja.properties
Fri Jan 11 18:32:12 2019 +0900
@@ -53,7 +53,7 @@
javac.opt.encoding=\u30BD\u30FC\u30B9\u30FB\u30D5\u30A1\u30A4\u30EB\u304C\u4F7F\u7528\u3059\u308B\u6587\u5B57\u30A8\u30F3\u30B3\u30FC\u30C7\u30A3\u30F3\u30B0\u3092\u6307\u5B9A\u3059\u308B
javac.opt.profile=\u4F7F\u7528\u3055\u308C\u3066\u3044\u308BAPI\u304C\u6307\u5B9A\u3057\u305F\u30D7\u30ED\u30D5\u30A1\u30A4\u30EB\u3067\u4F7F\u7528\u53EF\u80FD\u304B\u3069\u3046\u304B\u3092\u78BA\u8A8D\u3057\u307E\u3059
javac.opt.target=\u7279\u5B9A\u306EVM\u30D0\u30FC\u30B8\u30E7\u30F3\u7528\u306E\u30AF\u30E9\u30B9\u30FB\u30D5\u30A1\u30A4\u30EB\u3092\u751F\u6210\u3057\u307E\u3059\u3002\u30B5\u30DD\u30FC\u30C8\u3055\u308C\u3066\u3044\u308B\u30D0\u30FC\u30B8\u30E7\u30F3:
{0}
-javac.opt.release=\u7279\u5B9A\u306E\u30EA\u30EA\u30FC\u30B9\u7528\u306B\u306B\u30B3\u30F3\u30D1\u30A4\u30EB\u3057\u307E\u3059\u3002\u30B5\u30DD\u30FC\u30C8\u3055\u308C\u3066\u3044\u308B\u30EA\u30EA\u30FC\u30B9:
{0}
+javac.opt.release=\u7279\u5B9A\u306E\u30EA\u30EA\u30FC\u30B9\u7528\u306B\u30B3\u30F3\u30D1\u30A4\u30EB\u3057\u307E\u3059\u3002\u30B5\u30DD\u30FC\u30C8\u3055\u308C\u3066\u3044\u308B\u30EA\u30EA\u30FC\u30B9:
{0}
javac.opt.source=\u6307\u5B9A\u3055\u308C\u305F\u30EA\u30EA\u30FC\u30B9\u3068\u30BD\u30FC\u30B9\u306E\u4E92\u63DB\u6027\u3092\u4FDD\u6301\u3057\u307E\u3059\u3002\u30B5\u30DD\u30FC\u30C8\u3055\u308C\u3066\u3044\u308B\u30EA\u30EA\u30FC\u30B9:
{0}
javac.opt.Werror=\u8B66\u544A\u304C\u767A\u751F\u3057\u305F\u5834\u5408\u306B\u30B3\u30F3\u30D1\u30A4\u30EB\u3092\u7D42\u4E86\u3059\u308B
javac.opt.A=\u6CE8\u91C8\u30D7\u30ED\u30BB\u30C3\u30B5\u306B\u6E21\u3055\u308C\u308B\u30AA\u30D7\u30B7\u30E7\u30F3
Best Regards,
Noriyuki
RFR: 8218781 : Localized names for Japanese Era Reiwa in COMPAT provider
Hi all, Please review the change to update the l10n names for Japanese era Reiwa in JDK COMPAT provider. The l10n names come from the CLDR 35.1, please refer this unicode chart[1] for l10n definitions. Bug: https://bugs.openjdk.java.net/browse/JDK-8218781 Webrev: http://cr.openjdk.java.net/~ljiang/8218781/webrev.00/ In this change, - update the l10n names if they are defined in CLDR 35.1. - update the l10n names to Reiwa, Reiwa, R for FULL, SHORT, NARROW style respectively. - In FormatData_th.java, the localized single character was used for previous eras. But we don't find the corresponding name in CLDR 35.1. Update it to 'R' according to CLDR 35.1. [1] https://www.unicode.org/cldr/charts/latest/by_type/date_&_time.japanese.html Thanks, Leo
Re: RFR: 8218781 : Localized names for Japanese Era Reiwa in COMPAT provider
Hi Naoto, Please review the updated webrev: http://cr.openjdk.java.net/~ljiang/8218781/webrev.01/ In this update, renamed the data provider names and test case name to improve the readability. Thanks, Leo On 5/18/19 12:39 AM, naoto.s...@oracle.com wrote: Hi Leo, Overall looks good. One comment to the test case is that I would avoid using the name "JavaTimeSupplementary" or "JTS", as they are the implementation detail. Actually, a DateTimeFormatException may not necessarily be caused by a missing JavaTimeSupplementary resource in the runtime. Naoto On 5/16/19 9:04 PM, li.ji...@oracle.com wrote: Hi all, Please review the change to update the l10n names for Japanese era Reiwa in JDK COMPAT provider. The l10n names come from the CLDR 35.1, please refer this unicode chart[1] for l10n definitions. Bug: https://bugs.openjdk.java.net/browse/JDK-8218781 Webrev: http://cr.openjdk.java.net/~ljiang/8218781/webrev.00/ In this change, - update the l10n names if they are defined in CLDR 35.1. - update the l10n names to Reiwa, Reiwa, R for FULL, SHORT, NARROW style respectively. - In FormatData_th.java, the localized single character was used for previous eras. But we don't find the corresponding name in CLDR 35.1. Update it to 'R' according to CLDR 35.1. [1] https://www.unicode.org/cldr/charts/latest/by_type/date_&_time.japanese.html Thanks, Leo
Re: RFR: 8218781 : Localized names for Japanese Era Reiwa in COMPAT provider
Thank you, pushed. /Leo On 5/19/19 9:55 PM, naoto.s...@oracle.com wrote: Looks good. Naoto On 5/18/19 6:23 AM, li.ji...@oracle.com wrote: Hi Naoto, Please review the updated webrev: http://cr.openjdk.java.net/~ljiang/8218781/webrev.01/ In this update, renamed the data provider names and test case name to improve the readability. Thanks, Leo On 5/18/19 12:39 AM, naoto.s...@oracle.com wrote: Hi Leo, Overall looks good. One comment to the test case is that I would avoid using the name "JavaTimeSupplementary" or "JTS", as they are the implementation detail. Actually, a DateTimeFormatException may not necessarily be caused by a missing JavaTimeSupplementary resource in the runtime. Naoto On 5/16/19 9:04 PM, li.ji...@oracle.com wrote: Hi all, Please review the change to update the l10n names for Japanese era Reiwa in JDK COMPAT provider. The l10n names come from the CLDR 35.1, please refer this unicode chart[1] for l10n definitions. Bug: https://bugs.openjdk.java.net/browse/JDK-8218781 Webrev: http://cr.openjdk.java.net/~ljiang/8218781/webrev.00/ In this change, - update the l10n names if they are defined in CLDR 35.1. - update the l10n names to Reiwa, Reiwa, R for FULL, SHORT, NARROW style respectively. - In FormatData_th.java, the localized single character was used for previous eras. But we don't find the corresponding name in CLDR 35.1. Update it to 'R' according to CLDR 35.1. [1] https://www.unicode.org/cldr/charts/latest/by_type/date_&_time.japanese.html Thanks, Leo
Re: jtreg test failed with Japanese datetime formatting on win32
This issue should have been fixed by bug JDK-8224142[1]. The fix had been integrated into openjdk8u222. Would you provide the OS version and Java version in your test environment? Kinder reminder, before report the issue and paste the log here, you can search the JBS[2] first. [1] https://bugs.openjdk.java.net/browse/JDK-8224142 [2] https://bugs.openjdk.java.net/ Thanks, Leo On 21/05/2019 11:47 AM, chengjingwei (A) wrote: The failure occurred on windows-32bit platform only. The test case was jdk8u/jdk/test/java/time/test/java/time/format/TestNonIsoFormatter.java Failure message: test test.java.time.format.TestNonIsoFormatter.test_lenientEraYear(Japanese, "Meiji 123", "Heisei 2"): failure java.time.format.DateTimeParseException: Text 'Meiji 123-01-01' could not be parsed at index 0 at java.time.format.DateTimeFormatter.parseResolved0(DateTimeFormatter.java:1949) at java.time.format.DateTimeFormatter.parse(DateTimeFormatter.java:1851) at java.time.LocalDate.parse(LocalDate.java:400) at test.java.time.format.TestNonIsoFormatter.test_lenientEraYear(TestNonIsoFormatter.java:196) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:498) at org.testng.internal.MethodInvocationHelper.invokeMethod(MethodInvocationHelper.java:85) at org.testng.internal.Invoker.invokeMethod(Invoker.java:639) at org.testng.internal.Invoker.invokeTestMethod(Invoker.java:821) at org.testng.internal.Invoker.invokeTestMethods(Invoker.java:1131) at org.testng.internal.TestMethodWorker.invokeTestMethods(TestMethodWorker.java:124) at org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:108) at org.testng.TestRunner.privateRun(TestRunner.java:773) at org.testng.TestRunner.run(TestRunner.java:623) at org.testng.SuiteRunner.runTest(SuiteRunner.java:357) at org.testng.SuiteRunner.runSequentially(SuiteRunner.java:352) at org.testng.SuiteRunner.privateRun(SuiteRunner.java:310) at org.testng.SuiteRunner.run(SuiteRunner.java:259) at org.testng.SuiteRunnerWorker.runSuite(SuiteRunnerWorker.java:52) at org.testng.SuiteRunnerWorker.run(SuiteRunnerWorker.java:86) at org.testng.TestNG.runSuitesSequentially(TestNG.java:1185) at org.testng.TestNG.runSuitesLocally(TestNG.java:1110) at org.testng.TestNG.run(TestNG.java:1018) at com.sun.javatest.regtest.agent.TestNGRunner.main(TestNGRunner.java:94) at com.sun.javatest.regtest.agent.TestNGRunner.main(TestNGRunner.java:54) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:498) at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:127) at java.lang.Thread.run(Thread.java:748) config test.java.time.format.TestNonIsoFormatter.setUp(): success test test.java.time.format.TestNonIsoFormatter.test_lenientEraYear(Japanese, "Showa 65", "Heisei 2"): failure java.time.format.DateTimeParseException: Text 'Showa 65-01-01' could not be parsed at index 0 at java.time.format.DateTimeFormatter.parseResolved0(DateTimeFormatter.java:1949) at java.time.format.DateTimeFormatter.parse(DateTimeFormatter.java:1851) at java.time.LocalDate.parse(LocalDate.java:400) at test.java.time.format.TestNonIsoFormatter.test_lenientEraYear(TestNonIsoFormatter.java:196) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:498) at org.testng.internal.MethodInvocationHelper.invokeMethod(MethodInvocationHelper.java:85) at org.testng.internal.Invoker.invokeMethod(Invoker.java:639) at org.testng.internal.Invoker.invokeTestMethod(Invoker.java:821) at org.testng.internal.Invoker.invokeTestMethods(Invoker.java:1131) at org.testng.internal.TestMethodWorker.invokeTestMethods(TestMethodWorker.java:124) at org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:108) at org.testng.TestRunner.privateRun(TestRunner.java:773) at org.testng.TestRunner.run(TestRunner.java:623) at org.testng.SuiteRunner.runTest(SuiteRunner.java:357) at org.testng.SuiteRunner.runSequentially(SuiteRunner.java:352) at org.testng.SuiteRunner.privateRun(SuiteRunner.java:310) at org.testng.SuiteRunner.run(SuiteRunner.java:259) at org.testng.SuiteRunnerWorker.runSuite(SuiteRunnerWorker.j
