Re: RFR [16]: 8250665 : Wrong translation for the month of May in ar_JO, ar_LB and ar_SY
Thank you Naoto, pushed. -Leo On 8/7/20 2:18 AM, naoto.s...@oracle.com wrote: Looks good to me. Naoto On 8/6/20 9:47 AM, li.ji...@oracle.com wrote: Hi, Pls review the fix for month names in COMPAT provider data for ar_JO/LB/SY. Customer reported some month names are incorrect in JDK8 code according to latest CLDR definition. Bug: https://bugs.openjdk.java.net/browse/JDK-8250665 Webrev: http://cr.openjdk.java.net/~ljiang/8250665/webrev.00/ Passed the tier1 and tier2 test cases. Thanks, Leo
RFR [16]: 8250665 : Wrong translation for the month of May in ar_JO, ar_LB and ar_SY
Hi, Pls review the fix for month names in COMPAT provider data for ar_JO/LB/SY. Customer reported some month names are incorrect in JDK8 code according to latest CLDR definition. Bug: https://bugs.openjdk.java.net/browse/JDK-8250665 Webrev: http://cr.openjdk.java.net/~ljiang/8250665/webrev.00/ Passed the tier1 and tier2 test cases. Thanks, Leo
Re: RFR: 8249086: JDK 15 L10n resource file update - msg drop 10
Thank you Naoto! The patch was pushed into jdk/jdk15. Thanks, Leo On 7/9/20 3:53 AM, naoto.s...@oracle.com wrote: Hi Leo, Looks good to me. Naoto On 7/8/20 10:58 AM, li.ji...@oracle.com wrote: Hi, Pls review the l10n resource files update for JDK 15 msg drop 10. Bug: https://bugs.openjdk.java.net/browse/JDK-8249086 Webrev: http://cr.openjdk.java.net/~ljiang/8249086/read/ Thanks, Leo
RFR: 8249086: JDK 15 L10n resource file update - msg drop 10
Hi, Pls review the l10n resource files update for JDK 15 msg drop 10. Bug: https://bugs.openjdk.java.net/browse/JDK-8249086 Webrev: http://cr.openjdk.java.net/~ljiang/8249086/read/ Thanks, Leo
Re: [14] RFR (l10n) 8238377 : JDK 14 L10n resource files update - msg drop 20
Hi Naoto, Seems the tool parsed the version and encoding attributes, and wrote back with the values. Actually I don't know how they works, but since this is a minor issue from t9n tool side, I had added a post-edit script to fix the xml version/encoding line and the CR dos format issue. http://cr.openjdk.java.net/~ljiang/8238377/webrev.01/read/ Thanks, Leo On 2/4/20 12:45 AM, naoto.s...@oracle.com wrote: Hi Leo, On 2/3/20 7:21 AM, li.ji...@oracle.com wrote: Hi Naoto, For wxl file, the mentioned problems are not issue. 1. The wxl files are only working for window installer, so DOS format is good for these files, or even better. CRs should not be in source files in the OpenJDK repository. Here is the quote from jcheck (http://openjdk.java.net/projects/code-tools/jcheck/): "Changeset comments and source files do not contain tabs, carriage returns, or trailing spaces;" 2. The localized wxl is generated by t9n system, so they may normalize (in their standard) the text. If we keep the double quotes, they would be converted to single quote again in next round of msg drop. I have checked the other wxl files in our repo, same as the line1 in this review. If the tool is normalizing as such, why the second line was not affected? It keeps the spaces and double quotes as they are. Naoto Thanks, Leo On 2/3/20 11:07 PM, naoto.s...@oracle.com wrote: Hi Leo, Those .properties files look good to me. For those two .wxl files: - Files seem to be saved in DOS format (contains CR/LFs as new lines). - Line no. 1 is incorrectly modified. Includes unnecessary spaces, and double quotes are changed to single quotes. Naoto On 2/2/20 7:46 PM, li.ji...@oracle.com wrote: Hi, Please review the update for L10n resource files in JDK 14 msg drop 20. In this fix, we cover l10n resource files for the MSI installer of jpackage and the latest update from jdeps and jshell. https://bugs.openjdk.java.net/browse/JDK-8238377 http://cr.openjdk.java.net/~ljiang/8238377/webrev/read/ Thanks, Leo
Re: [14] RFR (l10n) 8238377 : JDK 14 L10n resource files update - msg drop 20
Hi Naoto, For wxl file, the mentioned problems are not issue. 1. The wxl files are only working for window installer, so DOS format is good for these files, or even better. 2. The localized wxl is generated by t9n system, so they may normalize (in their standard) the text. If we keep the double quotes, they would be converted to single quote again in next round of msg drop. I have checked the other wxl files in our repo, same as the line1 in this review. Thanks, Leo On 2/3/20 11:07 PM, naoto.s...@oracle.com wrote: Hi Leo, Those .properties files look good to me. For those two .wxl files: - Files seem to be saved in DOS format (contains CR/LFs as new lines). - Line no. 1 is incorrectly modified. Includes unnecessary spaces, and double quotes are changed to single quotes. Naoto On 2/2/20 7:46 PM, li.ji...@oracle.com wrote: Hi, Please review the update for L10n resource files in JDK 14 msg drop 20. In this fix, we cover l10n resource files for the MSI installer of jpackage and the latest update from jdeps and jshell. https://bugs.openjdk.java.net/browse/JDK-8238377 http://cr.openjdk.java.net/~ljiang/8238377/webrev/read/ Thanks, Leo
[14] RFR (l10n) 8238377 : JDK 14 L10n resource files update - msg drop 20
Hi, Please review the update for L10n resource files in JDK 14 msg drop 20. In this fix, we cover l10n resource files for the MSI installer of jpackage and the latest update from jdeps and jshell. https://bugs.openjdk.java.net/browse/JDK-8238377 http://cr.openjdk.java.net/~ljiang/8238377/webrev/read/ Thanks, Leo
Re: RFR: 8237465: JDK 14 L10N resource files update - msg drop 10
Hi Naoto, Thank you for reviewing. The eol characters were removed by t9n system, if I correct the format manually the next time we run the msg drop it would be back. Considering we need to kick off the next msg drop soon, I prefer not to fix it this time. Regards, Leo On 1/18/20 2:31 AM, naoto.s...@oracle.com wrote: Hi Leo, The l10n files for HelpResources_*.properties in jpackage discard the format in the original English resource file where lines are nicely aligned. Can you please preserve the format? Also, I find it odd to observe duplicated String literals in every XPATHErrorResources_*.java files. I think they should only be in the base resource bundles, but I guess that's in the original xml code and not l10n related. Naoto On 1/17/20 3:31 AM, li.ji...@oracle.com wrote: Hi, Please review the L10N resource files update for JDK 14 msg drop 10. https://bugs.openjdk.java.net/browse/JDK-8237465 http://cr.openjdk.java.net/~ljiang/8237465/webrev/read/ This is the first msg drop for JDK 14 L10N resources files update, so this webrev would cover most of update for JDK 14. We still have the msg drop 20 in the next days, so pls commit the l10n related changes before Jan 23rd. After msg drop 20, we kick off the msg drop 30 only if necessary, showstopper only. Note: some resource changes in preview features, like Record, Pattern Matching, are supported in this msg drop, also some new resource files for jpackager were added. Thanks, Leo
RFR: 8237465: JDK 14 L10N resource files update - msg drop 10
Hi, Please review the L10N resource files update for JDK 14 msg drop 10. https://bugs.openjdk.java.net/browse/JDK-8237465 http://cr.openjdk.java.net/~ljiang/8237465/webrev/read/ This is the first msg drop for JDK 14 L10N resources files update, so this webrev would cover most of update for JDK 14. We still have the msg drop 20 in the next days, so pls commit the l10n related changes before Jan 23rd. After msg drop 20, we kick off the msg drop 30 only if necessary, showstopper only. Note: some resource changes in preview features, like Record, Pattern Matching, are supported in this msg drop, also some new resource files for jpackager were added. Thanks, Leo
RFR: 8228778: JDK 13 L10n resource files update - msg drop 20
Hi, Please help to review the update of L10n resource files in JDK13 msg drop 20. Bug: https://bugs.openjdk.java.net/browse/JDK-8228778 Webrev: http://cr.openjdk.java.net/~ljiang/8228778/webrev/read/ Thanks, Leo
RFR: 8228623 : Update copyright year to 2019 for several java properties file
Hi, Please review this trivial change to correct the copyright year in several java properties file. I updated the copyright year in English, Simplified Chinese and Japanese resource files. Bug: https://bugs.openjdk.java.net/browse/JDK-8228623 Webrev: http://cr.openjdk.java.net/~ljiang/8228623/webrev/ Thanks, Leo
Re: RFR: 8228397: Missing license copyright header in some resource properties files
Thank you for your reviewing. Updated the webrev: http://cr.openjdk.java.net/~ljiang/8228397/webrev.01/ I know the update is trivial, if no more suggestion I will push the patch tomorrow. Thanks, Leo On 7/23/19 3:55 AM, Mandy Chung wrote: Hi Leo, Thanks for adding the copyright and license header. The patch looks okay assuming you will separate the legal notices from the existing comment block in JFC properties files. Mandy On 7/22/19 9:23 AM, li.ji...@oracle.com wrote: Hi all, Please review this change. We found the license copyright header are missing in some resource properties files, some of them are very old and no hg log since code forest consolidation. In this change, I added the license copyright header in the English and its localized resource files. Bug: https://bugs.openjdk.java.net/browse/JDK-8228397 Webrev: http://cr.openjdk.java.net/~ljiang/8228397/webrev.00/ Thanks, Leo
RFR: 8228397: Missing license copyright header in some resource properties files
Hi all, Please review this change. We found the license copyright header are missing in some resource properties files, some of them are very old and no hg log since code forest consolidation. In this change, I added the license copyright header in the English and its localized resource files. Bug: https://bugs.openjdk.java.net/browse/JDK-8228397 Webrev: http://cr.openjdk.java.net/~ljiang/8228397/webrev.00/ 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: 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
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: 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: RFR of JDK-8214431: tests failed because can not find removed library folder at test/jdk/lib/testlibrary/jdk/testlibrary
Just read the webrev, already covered :) -Leo On 11/28/18 9:09 PM, li.ji...@oracle.com wrote: Hi Hamlin, You can find some tests under sun/management/jmxremote/ failed on this issue too. Thanks, Leo On 11/28/18 7:15 PM, Hamlin Li wrote: Hi David, Thank a lot for double checking the usage of testlibrary. I have updated the patch, http://cr.openjdk.java.net/~mli/8214431/webrev.00/ Thank you -Hamlin On 2018/11/28 6:24 PM, David Holmes wrote: Hi Hamlin, I see a lot more tests that look like they may be affected: ./jdk/com/sun/tools/attach/TempDirTest.java: * @run build jdk.testlibrary.* Application RunnerUtil ./jdk/com/sun/tools/attach/PermissionTest.java: * @run build jdk.testlibrary.* Application ./jdk/com/sun/tools/attach/BasicTests.java: * @run build jdk.testlibrary.* Agent BadAgent RedefineAgent Application RedefineDummy RunnerUtil ./jdk/com/sun/tools/attach/ProviderTest.java: * @run build jdk.testlibrary.* SimpleProvider ./jdk/com/sun/jdi/ProcessAttachTest.java: * @build jdk.testlibrary.* ProcessAttachTest ./jdk/java/lang/Thread/ThreadStateTest.java: * @build jdk.testlibrary.* ./jdk/java/lang/management/MemoryMXBean/CollectionUsageThreshold.java: * @build jdk.testlibrary.* CollectionUsageThreshold MemoryUtil RunUtil ./jdk/java/lang/management/MemoryMXBean/ResetPeakMemoryUsage.java: * @build jdk.testlibrary.* ResetPeakMemoryUsage MemoryUtil RunUtil ./jdk/java/lang/management/ThreadMXBean/ThreadMXBeanStateTest.java: * @build jdk.testlibrary.* ./jdk/sun/management/jmxremote/startstop/JMXStatusTest.java: * @build jdk.testlibrary.* PortAllocator TestApp ManagementAgentJcmd ./jdk/sun/management/jmxremote/startstop/JMXStatusPerfCountersTest.java: * @build jdk.testlibrary.* PortAllocator TestApp ManagementAgentJcmd ./jdk/sun/management/jmxremote/bootstrap/SSLConfigFilePermissionTest.java: * @build jdk.testlibrary.* jdk.test.lib.Platform Dummy AbstractFilePermissionTest ./jdk/sun/management/jmxremote/bootstrap/PasswordFilePermissionTest.java: * @build jdk.testlibrary.* jdk.test.lib.Platform AbstractFilePermissionTest Dummy Cheers, David - On 28/11/2018 8:14 pm, Hamlin Li wrote: Would you please review the following patch? This is a regression by JDK-8211975. bug: https://bugs.openjdk.java.net/browse/JDK-8214431 patch at the bottom. Thank you -Hamlin diff -r 70adb0f573a7 test/jdk/com/sun/jdi/ProcessAttachTest.java --- a/test/jdk/com/sun/jdi/ProcessAttachTest.java Wed Nov 28 15:34:43 2018 +0800 +++ b/test/jdk/com/sun/jdi/ProcessAttachTest.java Wed Nov 28 18:13:49 2018 +0800 @@ -38,11 +38,10 @@ * @bug 4527279 * @summary Unit test for ProcessAttachingConnector * - * @library /lib/testlibrary * @library /test/lib * @modules java.management * jdk.jdi - * @build jdk.testlibrary.* ProcessAttachTest + * @build ProcessAttachTest * @run driver ProcessAttachTest */ diff -r 70adb0f573a7 test/jdk/java/lang/Thread/ThreadStateTest.java --- a/test/jdk/java/lang/Thread/ThreadStateTest.java Wed Nov 28 15:34:43 2018 +0800 +++ b/test/jdk/java/lang/Thread/ThreadStateTest.java Wed Nov 28 18:13:49 2018 +0800 @@ -30,9 +30,7 @@ * Thread.getState(). * * @author Mandy Chung - * @library /lib/testlibrary * @library /test/lib - * @build jdk.testlibrary.* * @build jdk.test.lib.LockFreeLogger * @build ThreadStateTest ThreadStateController * @run main/othervm -Xmixed ThreadStateTest
Re: RFR of JDK-8214431: tests failed because can not find removed library folder at test/jdk/lib/testlibrary/jdk/testlibrary
Hi Hamlin, You can find some tests under sun/management/jmxremote/ failed on this issue too. Thanks, Leo On 11/28/18 7:15 PM, Hamlin Li wrote: Hi David, Thank a lot for double checking the usage of testlibrary. I have updated the patch, http://cr.openjdk.java.net/~mli/8214431/webrev.00/ Thank you -Hamlin On 2018/11/28 6:24 PM, David Holmes wrote: Hi Hamlin, I see a lot more tests that look like they may be affected: ./jdk/com/sun/tools/attach/TempDirTest.java: * @run build jdk.testlibrary.* Application RunnerUtil ./jdk/com/sun/tools/attach/PermissionTest.java: * @run build jdk.testlibrary.* Application ./jdk/com/sun/tools/attach/BasicTests.java: * @run build jdk.testlibrary.* Agent BadAgent RedefineAgent Application RedefineDummy RunnerUtil ./jdk/com/sun/tools/attach/ProviderTest.java: * @run build jdk.testlibrary.* SimpleProvider ./jdk/com/sun/jdi/ProcessAttachTest.java: * @build jdk.testlibrary.* ProcessAttachTest ./jdk/java/lang/Thread/ThreadStateTest.java: * @build jdk.testlibrary.* ./jdk/java/lang/management/MemoryMXBean/CollectionUsageThreshold.java: * @build jdk.testlibrary.* CollectionUsageThreshold MemoryUtil RunUtil ./jdk/java/lang/management/MemoryMXBean/ResetPeakMemoryUsage.java: * @build jdk.testlibrary.* ResetPeakMemoryUsage MemoryUtil RunUtil ./jdk/java/lang/management/ThreadMXBean/ThreadMXBeanStateTest.java: * @build jdk.testlibrary.* ./jdk/sun/management/jmxremote/startstop/JMXStatusTest.java: * @build jdk.testlibrary.* PortAllocator TestApp ManagementAgentJcmd ./jdk/sun/management/jmxremote/startstop/JMXStatusPerfCountersTest.java: * @build jdk.testlibrary.* PortAllocator TestApp ManagementAgentJcmd ./jdk/sun/management/jmxremote/bootstrap/SSLConfigFilePermissionTest.java: * @build jdk.testlibrary.* jdk.test.lib.Platform Dummy AbstractFilePermissionTest ./jdk/sun/management/jmxremote/bootstrap/PasswordFilePermissionTest.java: * @build jdk.testlibrary.* jdk.test.lib.Platform AbstractFilePermissionTest Dummy Cheers, David - On 28/11/2018 8:14 pm, Hamlin Li wrote: Would you please review the following patch? This is a regression by JDK-8211975. bug: https://bugs.openjdk.java.net/browse/JDK-8214431 patch at the bottom. Thank you -Hamlin diff -r 70adb0f573a7 test/jdk/com/sun/jdi/ProcessAttachTest.java --- a/test/jdk/com/sun/jdi/ProcessAttachTest.java Wed Nov 28 15:34:43 2018 +0800 +++ b/test/jdk/com/sun/jdi/ProcessAttachTest.java Wed Nov 28 18:13:49 2018 +0800 @@ -38,11 +38,10 @@ * @bug 4527279 * @summary Unit test for ProcessAttachingConnector * - * @library /lib/testlibrary * @library /test/lib * @modules java.management * jdk.jdi - * @build jdk.testlibrary.* ProcessAttachTest + * @build ProcessAttachTest * @run driver ProcessAttachTest */ diff -r 70adb0f573a7 test/jdk/java/lang/Thread/ThreadStateTest.java --- a/test/jdk/java/lang/Thread/ThreadStateTest.java Wed Nov 28 15:34:43 2018 +0800 +++ b/test/jdk/java/lang/Thread/ThreadStateTest.java Wed Nov 28 18:13:49 2018 +0800 @@ -30,9 +30,7 @@ * Thread.getState(). * * @author Mandy Chung - * @library /lib/testlibrary * @library /test/lib - * @build jdk.testlibrary.* * @build jdk.test.lib.LockFreeLogger * @build ThreadStateTest ThreadStateController * @run main/othervm -Xmixed ThreadStateTest
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
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
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
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
