From youdwei at linux.vnet.ibm.com Mon May 7 02:23:22 2012 From: youdwei at linux.vnet.ibm.com (Deven You) Date: Mon, 07 May 2012 17:23:22 +0800 Subject: Incorrect TimeZone display name when DST not applicable / disabled Message-ID: <4FA7948A.9090702@linux.vnet.ibm.com> Hi All, JDK displays incorrect TimeZone display name when DST (Daylight Saving Time) is disable in the native Time Zone settings on Windows XP/2003 platforms and the Time Zone does not support DST. Steps to re-create the problem 1. In the Windows Date and Time Properties dialog, set the time zone to one that uses DST (e.g. Greenwich Mean Time). 2. Disable the 'Automatically adjust clock for Daylight Saving Changes' option. 3. Change the time zone to one that does not use DST (e.g. India Standard Time - (GMT+5:30) Chennai,Kolkata,Mumbai,New Delhi) 4. Compile and run the testcase[1] Observed output: GMT+05:30 Expected output: India Standard Tim There is already a sunbug[2] for this problem, which describes the problem clearly and very detailed. Please refer it for more detail. Here is some descriptions from the sunbug: PROBLEM --------------------------------- Windows provides an option entitled 'Automatically adjust clock for Daylight Saving Changes' box in the native time zone settings. When checked, the clock is automatically adjusted to the daylight savings time if applicable to that particular timezone. More importantly, if this box is unchecked, Windows will ignore any DST timetable in the selected time zone. Now, the JDK's TimeZone class checks the value of the registry value that corresponds to this option, and modifies the default TimeZone's display name accordingly. This is from the evaluation of CR 4296930, describing the fix made for that CR in JDK 1.4.2: -------- When the auto-adjustment is turned off, the platform time zone detection code will create a time zone ID in the "GMT{+|-}hh:mm" form with which a custom TimeZone customer is created. This is because some Windows users turn it off due to incorrect Win32 time zones and choose one based on just the GMT offset. A restriction is that display names are not supported even it just means to use standard time of a correct time zone selection for some other purposes. -------- This makes sense for time zones that do use DST. However, our customers have found that if you disable DST in the Windows options for a time zone that uses it, and then switch to a time zone that doesn't use DST, the option remains disabled (i.e. the underlying registry value retains the value that corresponds to the option being disabled). Under these circumstances the JDK's TimeZone class changes the display name to the "GMT{+|-}hh:mm" format, rather than using the correct name. This is unintuitive, and arguably incorrect. We believe it would be better to query the time zone to see if DST is actually applicable before deciding whether or not to switch to the "GMT{+|-}hh:mm" format. Note that this issue is not applicable to Windows Vista/7 because the relevant registry value is reset each time the native time zone is changed, rather than being retained as it is in Windows XP/2003. I have made a fix which will deal with this situation and avoid the "GMT{+|-}hh:mm" format. [1] http://cr.openjdk.java.net/~littlee/ojdk-557/webrev.00/ [2] http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7094176 Thanks a lot! -- Best Regards, Deven -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/i18n-dev/attachments/20120507/f7ddd61a/attachment.html From youdwei at linux.vnet.ibm.com Wed May 9 23:24:49 2012 From: youdwei at linux.vnet.ibm.com (Deven You) Date: Thu, 10 May 2012 14:24:49 +0800 Subject: Incorrect TimeZone display name when DST not applicable / disabled In-Reply-To: <4FA7948A.9090702@linux.vnet.ibm.com> References: <4FA7948A.9090702@linux.vnet.ibm.com> Message-ID: <4FAB5F31.6010206@linux.vnet.ibm.com> Anyone could take a look? On 05/07/2012 05:23 PM, Deven You wrote: > Hi All, > > JDK displays incorrect TimeZone display name when DST (Daylight Saving > Time) is disable in the native Time Zone settings on Windows XP/2003 > platforms and the Time Zone does not support DST. > > Steps to re-create the problem > > 1. In the Windows Date and Time Properties dialog, set the time zone > to one that uses DST (e.g. Greenwich Mean Time). > 2. Disable the 'Automatically adjust clock for Daylight Saving > Changes' option. > 3. Change the time zone to one that does not use DST (e.g. India > Standard Time - (GMT+5:30) Chennai,Kolkata,Mumbai,New Delhi) > 4. Compile and run the testcase[1] > > Observed output: > GMT+05:30 > > Expected output: > India Standard Tim > > There is already a sunbug[2] for this problem, which describes the > problem clearly and very detailed. Please refer it for more detail. > Here is some descriptions from the sunbug: > > PROBLEM > --------------------------------- > Windows provides an option entitled 'Automatically adjust clock for > Daylight Saving Changes' box in the native time zone settings. When > checked, the clock is automatically adjusted to the daylight savings > time if applicable to that particular timezone. > More importantly, if this box is unchecked, Windows will ignore any > DST timetable in the selected time zone. > > Now, the JDK's TimeZone class checks the value of the registry value > that corresponds to this option, and modifies the default TimeZone's > display name accordingly. This is from the evaluation of CR 4296930, > describing the fix made for that CR in JDK 1.4.2: > > -------- > When the auto-adjustment is turned off, the platform time zone > detection code will create a time zone ID in the "GMT{+|-}hh:mm" form > with which a custom TimeZone customer is created. This is because some > Windows users turn it off due to incorrect Win32 time zones and choose > one based on just the GMT offset. A restriction is that display names > are not supported even it just means to use standard time of a correct > time zone selection for some other purposes. > -------- > > This makes sense for time zones that do use DST. However, our > customers have found that if you disable DST in the Windows options > for a time zone that uses it, and then switch to a time zone that > doesn't use DST, the option remains disabled (i.e. the underlying > registry value retains the value that corresponds to the option being > disabled). > > Under these circumstances the JDK's TimeZone class changes the display > name to the "GMT{+|-}hh:mm" format, rather than using the correct > name. This is unintuitive, and arguably incorrect. > > We believe it would be better to query the time zone to see if DST is > actually applicable before deciding whether or not to switch to the > "GMT{+|-}hh:mm" format. > > Note that this issue is not applicable to Windows Vista/7 because the > relevant registry value is reset each time the native time zone is > changed, rather than being retained as it is in Windows XP/2003. > > > > > I have made a fix which will deal with this situation and avoid the > "GMT{+|-}hh:mm" format. > > [1] http://cr.openjdk.java.net/~littlee/ojdk-557/webrev.00/ > > [2] http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7094176 > > Thanks a lot! > -- > Best Regards, > > Deven -- Best Regards, Deven -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/i18n-dev/attachments/20120510/faa4de25/attachment.html From sean.coffey at oracle.com Thu May 10 02:58:16 2012 From: sean.coffey at oracle.com (=?ISO-8859-1?Q?Se=E1n_Coffey?=) Date: Thu, 10 May 2012 10:58:16 +0100 Subject: RFR : 7167359 (tz) SEGV on solaris if TZ variable not set Message-ID: <4FAB9138.8090405@oracle.com> review request for issue that arose after 7092679 fix. Without a TZ variable set on solaris, there's possibility for SEGV. Simple fix. webrev : http://cr.openjdk.java.net/~coffeys/webrev.7167359.jdk8/ bug : http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7167359 (not visible yet) regards, Sean. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/i18n-dev/attachments/20120510/a1044fd8/attachment.html From masayoshi.okutsu at oracle.com Fri May 11 02:03:10 2012 From: masayoshi.okutsu at oracle.com (Masayoshi Okutsu) Date: Fri, 11 May 2012 18:03:10 +0900 Subject: RFR : 7167359 (tz) SEGV on solaris if TZ variable not set In-Reply-To: <4FAB9138.8090405@oracle.com> References: <4FAB9138.8090405@oracle.com> Message-ID: <4FACD5CE.50009@oracle.com> Looks good. Masayoshi On 5/10/2012 6:58 PM, Se?n Coffey wrote: > review request for issue that arose after 7092679 fix. > > Without a TZ variable set on solaris, there's possibility for SEGV. > Simple fix. > > webrev : http://cr.openjdk.java.net/~coffeys/webrev.7167359.jdk8/ > bug : http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7167359 (not > visible yet) > > regards, > Sean. From masayoshi.okutsu at oracle.com Fri May 11 08:18:44 2012 From: masayoshi.okutsu at oracle.com (Masayoshi Okutsu) Date: Sat, 12 May 2012 00:18:44 +0900 Subject: Incorrect TimeZone display name when DST not applicable / disabled In-Reply-To: <4FA7948A.9090702@linux.vnet.ibm.com> References: <4FA7948A.9090702@linux.vnet.ibm.com> Message-ID: <4FAD2DD4.1020306@oracle.com> An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/i18n-dev/attachments/20120512/ec547d7d/attachment.html From youdwei at linux.vnet.ibm.com Tue May 15 23:09:35 2012 From: youdwei at linux.vnet.ibm.com (Deven You) Date: Wed, 16 May 2012 14:09:35 +0800 Subject: Incorrect TimeZone display name when DST not applicable / disabled In-Reply-To: <4FAD2DD4.1020306@oracle.com> References: <4FA7948A.9090702@linux.vnet.ibm.com> <4FAD2DD4.1020306@oracle.com> Message-ID: <4FB3449F.9020409@linux.vnet.ibm.com> Hi Masayoshi, This fix is only for Time zone which does not support DST. For your first question, the scenario is that when current time zone supports DST and the "Automatically adjust clock for Daylight Saving Changes" option is unchecked. At that time if people change the timezone to one that does not support DST. On Windows XP, the value of "0x1" will be retained for the registry key "DisableAutoDaylightTimeSet" instead of getting reset to "0x0". I think this is a Windows XP limitation. For the second question, this fix only change the "GMT{+|-}hh:mm" to the standard name of a time zone, it is not related to any Time zone which supports DST. Some detail for this fix: 1. On Windows OS like XP/2003, the registry key "DisableAutoDaylightTimeSet" (under HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\TimeZoneInformation) is used to determine if the auto-daylight time adjustment is turned off or not. By default, the value of this registry key will be "0x0". When a user turns off the "Automatically adjust clock for Daylight Saving Time" on the machine for a time zone that supports DST, then the registry value for "DisableAutoDaylightTimeSet" will be set to "0x1". Now when the user switches to a time zone that does not support DST, the value of "0x1" will be retained for the registry key "DisableAutoDaylightTimeSet" instead of getting reset to "0x0". (Note: The "Automatically adjust clock for Daylight Saving Time" is not applicable to time zones that does not support DST, so the registry key "DisableAutoDaylightTimeSet" should always be "0x0".) Hence we see the incorrect output (problem reported in defect 184237/184237.70) 2. On Windows Vista or later OS, a different registry key namely "DynamicDaylightTimeDisabled" (under HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\TimeZoneInformation) is used. The value of the registry key "DynamicDaylightTimeDisabled" will be set to "0x0 by default. It will be set to "0x1" when "Automatically adjust clock for Daylight Saving Time" is disabled on the time zone that supports DST. When the user switches to a time zone that does not support DST, the value of registry key "DynamicDaylightTimeDisabled" automatically gets reset to "0x0". So we don't see the problem with Windows Vista or later OS. 3. tzi.DaylightDate.wMonth is used to check if a time zone supports DST or not. See MSDN[1]: "If the time zone does not support daylight saving time or if the caller needs to disable daylight saving time, the wMonth member in the SYSTEMTIME structure must be zero" This fix use the conjunction of key "DisableAutoDaylightTimeSet" and tzi.DaylightDate.wMonth to determine if a time zone dose support DST. If there is any unclear things please let me know! Thanks a lot! On 05/11/2012 11:18 PM, Masayoshi Okutsu wrote: > Hi Deven, > > Sorry for taking time to respond. > > This is a known restriction of time zone detection on Windows > currently. There used to be a note on this issue with a workaround in > Java SE release notes, but it seems to be gone some time ago. Is there > any reason that the auto-adjust option needs to be kept turned off for > the time zone? > > The fix seems OK for the India Standard Time case. But does the fix > work if a time zone has Dynamic DST and starts observing DST some time > in the future? > > Thanks, > Masayoshi > > On 5/7/2012 6:23 PM, Deven You wrote: >> Hi All, >> >> JDK displays incorrect TimeZone display name when DST (Daylight >> Saving Time) is disable in the native Time Zone settings on Windows >> XP/2003 platforms and the Time Zone does not support DST. >> >> Steps to re-create the problem >> >> 1. In the Windows Date and Time Properties dialog, set the time zone >> to one that uses DST (e.g. Greenwich Mean Time). >> 2. Disable the 'Automatically adjust clock for Daylight Saving >> Changes' option. >> 3. Change the time zone to one that does not use DST (e.g. India >> Standard Time - (GMT+5:30) Chennai,Kolkata,Mumbai,New Delhi) >> 4. Compile and run the testcase[1] >> >> Observed output: >> GMT+05:30 >> >> Expected output: >> India Standard Tim >> >> There is already a sunbug[2] for this problem, which describes the >> problem clearly and very detailed. Please refer it for more detail. >> Here is some descriptions from the sunbug: >> >> PROBLEM >> --------------------------------- >> Windows provides an option entitled 'Automatically adjust clock for >> Daylight Saving Changes' box in the native time zone settings. When >> checked, the clock is automatically adjusted to the daylight savings >> time if applicable to that particular timezone. >> More importantly, if this box is unchecked, Windows will ignore any >> DST timetable in the selected time zone. >> >> Now, the JDK's TimeZone class checks the value of the registry value >> that corresponds to this option, and modifies the default TimeZone's >> display name accordingly. This is from the evaluation of CR 4296930, >> describing the fix made for that CR in JDK 1.4.2: >> >> -------- >> When the auto-adjustment is turned off, the platform time zone >> detection code will create a time zone ID in the "GMT{+|-}hh:mm" form >> with which a custom TimeZone customer is created. This is because >> some Windows users turn it off due to incorrect Win32 time zones and >> choose one based on just the GMT offset. A restriction is that >> display names are not supported even it just means to use standard >> time of a correct time zone selection for some other purposes. >> -------- >> >> This makes sense for time zones that do use DST. However, our >> customers have found that if you disable DST in the Windows options >> for a time zone that uses it, and then switch to a time zone that >> doesn't use DST, the option remains disabled (i.e. the underlying >> registry value retains the value that corresponds to the option being >> disabled). >> >> Under these circumstances the JDK's TimeZone class changes the >> display name to the "GMT{+|-}hh:mm" format, rather than using the >> correct name. This is unintuitive, and arguably incorrect. >> >> We believe it would be better to query the time zone to see if DST is >> actually applicable before deciding whether or not to switch to the >> "GMT{+|-}hh:mm" format. >> >> Note that this issue is not applicable to Windows Vista/7 because the >> relevant registry value is reset each time the native time zone is >> changed, rather than being retained as it is in Windows XP/2003. >> >> >> >> >> I have made a fix which will deal with this situation and avoid the >> "GMT{+|-}hh:mm" format. >> >> [1] http://cr.openjdk.java.net/~littlee/ojdk-557/webrev.00/ >> >> [2] http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7094176 >> >> Thanks a lot! >> -- >> Best Regards, >> >> Deven -- Best Regards, Deven -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/i18n-dev/attachments/20120516/b5cc60b7/attachment.html From youdwei at linux.vnet.ibm.com Tue May 15 23:44:15 2012 From: youdwei at linux.vnet.ibm.com (Deven You) Date: Wed, 16 May 2012 14:44:15 +0800 Subject: Incorrect TimeZone display name when DST not applicable / disabled In-Reply-To: <4FB3449F.9020409@linux.vnet.ibm.com> References: <4FA7948A.9090702@linux.vnet.ibm.com> <4FAD2DD4.1020306@oracle.com> <4FB3449F.9020409@linux.vnet.ibm.com> Message-ID: <4FB34CBF.20008@linux.vnet.ibm.com> This is the MSDN reference[1] [1] http://msdn.microsoft.com/en-us/library/windows/desktop/ms724253%28v=vs.85%29.aspx On 05/16/2012 02:09 PM, Deven You wrote: > Hi Masayoshi, > > This fix is only for Time zone which does not support DST. > > For your first question, the scenario is that when current time zone > supports DST and the "Automatically adjust clock for Daylight Saving > Changes" option is unchecked. At that time if people change the > timezone to one that does not support DST. > > On Windows XP, the value of "0x1" will be retained for the registry > key "DisableAutoDaylightTimeSet" instead of getting reset to "0x0". I > think this is a Windows XP limitation. > > For the second question, this fix only change the "GMT{+|-}hh:mm" to > the standard name of a time zone, it is not related to any Time zone > which supports DST. > > Some detail for this fix: > > 1. On Windows OS like XP/2003, the registry key > "DisableAutoDaylightTimeSet" (under > HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\TimeZoneInformation) > is used to determine if the auto-daylight time adjustment is turned > off or not. By default, the value of this registry key will be "0x0". > When a user turns off the "Automatically adjust clock for Daylight > Saving Time" on the machine for a time zone that supports DST, then > the registry value for "DisableAutoDaylightTimeSet" will be set to > "0x1". Now when the user switches to a time zone that does not support > DST, the value of "0x1" will be retained for the registry key > "DisableAutoDaylightTimeSet" instead of getting reset to "0x0". (Note: > The "Automatically adjust clock for Daylight Saving Time" is not > applicable to time zones that does not support DST, so the registry > key "DisableAutoDaylightTimeSet" should always be "0x0".) Hence we see > the incorrect output (problem reported in defect 184237/184237.70) > > 2. On Windows Vista or later OS, a different registry key namely > "DynamicDaylightTimeDisabled" (under > HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\TimeZoneInformation) > is used. > The value of the registry key "DynamicDaylightTimeDisabled" will be > set to "0x0 by default. It will be set to "0x1" when "Automatically > adjust clock for Daylight Saving Time" is disabled on the time zone > that supports DST. When the user switches to a time zone that does not > support DST, the value of registry key "DynamicDaylightTimeDisabled" > automatically gets reset to "0x0". So we don't see the problem with > Windows Vista or later OS. > > 3. tzi.DaylightDate.wMonth is used to check if a time zone supports > DST or not. See MSDN[1]: > > "If the time zone does not support daylight saving time or if the > caller needs to disable daylight saving time, the wMonth member in the > SYSTEMTIME structure must be zero" > > This fix use the conjunction of key "DisableAutoDaylightTimeSet" and > tzi.DaylightDate.wMonth to determine if a time zone dose support DST. > > If there is any unclear things please let me know! > > Thanks a lot! > > > On 05/11/2012 11:18 PM, Masayoshi Okutsu wrote: >> Hi Deven, >> >> Sorry for taking time to respond. >> >> This is a known restriction of time zone detection on Windows >> currently. There used to be a note on this issue with a workaround in >> Java SE release notes, but it seems to be gone some time ago. Is >> there any reason that the auto-adjust option needs to be kept turned >> off for the time zone? >> >> The fix seems OK for the India Standard Time case. But does the fix >> work if a time zone has Dynamic DST and starts observing DST some >> time in the future? >> >> Thanks, >> Masayoshi >> >> On 5/7/2012 6:23 PM, Deven You wrote: >>> Hi All, >>> >>> JDK displays incorrect TimeZone display name when DST (Daylight >>> Saving Time) is disable in the native Time Zone settings on Windows >>> XP/2003 platforms and the Time Zone does not support DST. >>> >>> Steps to re-create the problem >>> >>> 1. In the Windows Date and Time Properties dialog, set the time zone >>> to one that uses DST (e.g. Greenwich Mean Time). >>> 2. Disable the 'Automatically adjust clock for Daylight Saving >>> Changes' option. >>> 3. Change the time zone to one that does not use DST (e.g. India >>> Standard Time - (GMT+5:30) Chennai,Kolkata,Mumbai,New Delhi) >>> 4. Compile and run the testcase[1] >>> >>> Observed output: >>> GMT+05:30 >>> >>> Expected output: >>> India Standard Tim >>> >>> There is already a sunbug[2] for this problem, which describes the >>> problem clearly and very detailed. Please refer it for more detail. >>> Here is some descriptions from the sunbug: >>> >>> PROBLEM >>> --------------------------------- >>> Windows provides an option entitled 'Automatically adjust clock for >>> Daylight Saving Changes' box in the native time zone settings. When >>> checked, the clock is automatically adjusted to the daylight savings >>> time if applicable to that particular timezone. >>> More importantly, if this box is unchecked, Windows will ignore any >>> DST timetable in the selected time zone. >>> >>> Now, the JDK's TimeZone class checks the value of the registry value >>> that corresponds to this option, and modifies the default TimeZone's >>> display name accordingly. This is from the evaluation of CR 4296930, >>> describing the fix made for that CR in JDK 1.4.2: >>> >>> -------- >>> When the auto-adjustment is turned off, the platform time zone >>> detection code will create a time zone ID in the "GMT{+|-}hh:mm" >>> form with which a custom TimeZone customer is created. This is >>> because some Windows users turn it off due to incorrect Win32 time >>> zones and choose one based on just the GMT offset. A restriction is >>> that display names are not supported even it just means to use >>> standard time of a correct time zone selection for some other purposes. >>> -------- >>> >>> This makes sense for time zones that do use DST. However, our >>> customers have found that if you disable DST in the Windows options >>> for a time zone that uses it, and then switch to a time zone that >>> doesn't use DST, the option remains disabled (i.e. the underlying >>> registry value retains the value that corresponds to the option >>> being disabled). >>> >>> Under these circumstances the JDK's TimeZone class changes the >>> display name to the "GMT{+|-}hh:mm" format, rather than using the >>> correct name. This is unintuitive, and arguably incorrect. >>> >>> We believe it would be better to query the time zone to see if DST >>> is actually applicable before deciding whether or not to switch to >>> the "GMT{+|-}hh:mm" format. >>> >>> Note that this issue is not applicable to Windows Vista/7 because >>> the relevant registry value is reset each time the native time zone >>> is changed, rather than being retained as it is in Windows XP/2003. >>> >>> >>> >>> >>> I have made a fix which will deal with this situation and avoid the >>> "GMT{+|-}hh:mm" format. >>> >>> [1] http://cr.openjdk.java.net/~littlee/ojdk-557/webrev.00/ >>> >>> [2] http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7094176 >>> >>> Thanks a lot! >>> -- >>> Best Regards, >>> >>> Deven > > > -- > Best Regards, > > Deven -- Best Regards, Deven -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/i18n-dev/attachments/20120516/f69a72e7/attachment-0001.html From masayoshi.okutsu at oracle.com Wed May 16 09:10:02 2012 From: masayoshi.okutsu at oracle.com (Masayoshi Okutsu) Date: Thu, 17 May 2012 01:10:02 +0900 Subject: Incorrect TimeZone display name when DST not applicable / disabled In-Reply-To: <4FB34CBF.20008@linux.vnet.ibm.com> References: <4FA7948A.9090702@linux.vnet.ibm.com> <4FAD2DD4.1020306@oracle.com> <4FB3449F.9020409@linux.vnet.ibm.com> <4FB34CBF.20008@linux.vnet.ibm.com> Message-ID: <4FB3D15A.8090708@oracle.com> An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/i18n-dev/attachments/20120517/f17ffb39/attachment.html From y.umaoka at gmail.com Wed May 16 09:18:11 2012 From: y.umaoka at gmail.com (Yoshito Umaoka) Date: Wed, 16 May 2012 12:18:11 -0400 Subject: Incorrect TimeZone display name when DST not applicable / disabled In-Reply-To: <4FB3D15A.8090708@oracle.com> References: <4FA7948A.9090702@linux.vnet.ibm.com> <4FAD2DD4.1020306@oracle.com> <4FB3449F.9020409@linux.vnet.ibm.com> <4FB34CBF.20008@linux.vnet.ibm.com> <4FB3D15A.8090708@oracle.com> Message-ID: <4FB3D343.2050708@gmail.com> > I thought Windows XP might (internally) use the Dynamic DST data in > the Time Zones registry for supporting any DST rule changes, because > Dynamic DST was introduced for the US DST rule change IIRC. But as far > as I tested, XP seems to ignore Dynamic DST data. If that's the case, > your proposed fix should be good. > As far as I know, the dynamic DST data is used by Windows Vista/2003 server or later Windows versions. The registry data for dynamic DST is included in Windows XP time zone updates, but not used by Windows XP. -Yoshito From youdwei at linux.vnet.ibm.com Wed May 16 20:04:24 2012 From: youdwei at linux.vnet.ibm.com (Deven You) Date: Thu, 17 May 2012 11:04:24 +0800 Subject: Incorrect TimeZone display name when DST not applicable / disabled In-Reply-To: <4FB3D343.2050708@gmail.com> References: <4FA7948A.9090702@linux.vnet.ibm.com> <4FAD2DD4.1020306@oracle.com> <4FB3449F.9020409@linux.vnet.ibm.com> <4FB34CBF.20008@linux.vnet.ibm.com> <4FB3D15A.8090708@oracle.com> <4FB3D343.2050708@gmail.com> Message-ID: <4FB46AB8.6000207@linux.vnet.ibm.com> Hi Masayoshi, I think the workaround is good, but many customers may not know this fact and when they need change the timezone, they just select another time zone which does not support DST and ignore that the auto-adjust option should be checked first. To Yoshito, thanks for your information! On 05/17/2012 12:18 AM, Yoshito Umaoka wrote: > >> I thought Windows XP might (internally) use the Dynamic DST data in >> the Time Zones registry for supporting any DST rule changes, because >> Dynamic DST was introduced for the US DST rule change IIRC. But as >> far as I tested, XP seems to ignore Dynamic DST data. If that's the >> case, your proposed fix should be good. >> > > As far as I know, the dynamic DST data is used by Windows Vista/2003 > server or later Windows versions. > The registry data for dynamic DST is included in Windows XP time zone > updates, but not used by Windows XP. > > -Yoshito > -- Best Regards, Deven From youdwei at linux.vnet.ibm.com Mon May 21 00:41:35 2012 From: youdwei at linux.vnet.ibm.com (Deven You) Date: Mon, 21 May 2012 15:41:35 +0800 Subject: Locale patch for Slovenian date format data: dots are missed in the datetime for Slovanian In-Reply-To: <4F5454A3.6060907@linux.vnet.ibm.com> References: <4F5454A3.6060907@linux.vnet.ibm.com> Message-ID: <4FB9F1AF.5000106@linux.vnet.ibm.com> Hi All, I think this patch is simple and straight forward, is anyone interested in taking a look? Thanks a lot! On 03/05/2012 01:52 PM, Deven wrote: > Hi i18n-devs, > > I find there is a problem in Slovenian Locale. In Slovenian Locale, > days in a date must with a dot '.', like Oct 23rd 2011 will be 23. > oktober 2011. Without the '.', 23 oktober 2011 basically means > Twenty-three of October, instead of the Twenty-third of October. > > Current oracle 6/7/8 all miss the dot '.', so this patch [1] will add > dot after the days to correct the date expression in Slovenian Locale. > > The attached test case [2] shows the the diffrence with/without this > patch. The output of this test case are: > > without this patch: > Ponedeljek, 5 marec 2012 > > with this patch: > Ponedeljek, 5. marec 2012 > > This test case may not be very useful, so I hope anyone can give me > some suggestions about how to refine the test case? > > [1] > http://cr.openjdk.java.net/~youdwei/slovenian_formatData/webrev.00/ > > > [2] SlovenianFormatDataTest.java > > Thanks a lot! > -- Best Regards, Deven From yong.huang at oracle.com Mon May 21 02:27:18 2012 From: yong.huang at oracle.com (Yong Jeffrey Huang) Date: Mon, 21 May 2012 17:27:18 +0800 Subject: Locale patch for Slovenian date format data: dots are missed in the datetime for Slovanian In-Reply-To: <4FB9F1AF.5000106@linux.vnet.ibm.com> References: <4F5454A3.6060907@linux.vnet.ibm.com> <4FB9F1AF.5000106@linux.vnet.ibm.com> Message-ID: <4FBA0A76.40209@oracle.com> Hi Daven, We use the format data in CLDR as the standard. Attached is the sl.xml in CLDR. In your fix, it's better to be "EEEE, dd. MMMM y", // full date pattern "dd. MMMM y", // long date pattern Blow is the format defined in CLDR: - - EEEE, dd. MMMM y - - dd. MMMM y For test case: To fix format data of one locale, you must modify corresponding regression test: jdk/test/sun/text/resources/LocaleData: In the end of the file, add #bug xxxxxx FormatData/sl/DateTimePatterns/4=EEEE, dd. MMMM y FormatData/sl/DateTimePatterns/5=dd. MMMM y jdk/test/sun/text/resources/LocaleDataTest.java: In the end of comments @bug, add the bug number. thanks, Yong On 2012/5/21 15:41, Deven You wrote: > Hi All, > > I think this patch is simple and straight forward, is anyone > interested in taking a look? > > Thanks a lot! > > On 03/05/2012 01:52 PM, Deven wrote: >> Hi i18n-devs, >> >> I find there is a problem in Slovenian Locale. In Slovenian Locale, >> days in a date must with a dot '.', like Oct 23rd 2011 will be 23. >> oktober 2011. Without the '.', 23 oktober 2011 basically means >> Twenty-three of October, instead of the Twenty-third of October. >> >> Current oracle 6/7/8 all miss the dot '.', so this patch [1] will add >> dot after the days to correct the date expression in Slovenian Locale. >> >> The attached test case [2] shows the the diffrence with/without this >> patch. The output of this test case are: >> >> without this patch: >> Ponedeljek, 5 marec 2012 >> >> with this patch: >> Ponedeljek, 5. marec 2012 >> >> This test case may not be very useful, so I hope anyone can give me >> some suggestions about how to refine the test case? >> >> [1] >> http://cr.openjdk.java.net/~youdwei/slovenian_formatData/webrev.00/ >> >> >> [2] SlovenianFormatDataTest.java >> >> Thanks a lot! >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/i18n-dev/attachments/20120521/7296379d/attachment-0001.html -------------- next part -------------- A non-text attachment was scrubbed... Name: sl.xml Type: text/xml Size: 133095 bytes Desc: not available Url : http://mail.openjdk.java.net/pipermail/i18n-dev/attachments/20120521/7296379d/sl-0001.xml From erik.gahlin at oracle.com Mon May 21 04:18:15 2012 From: erik.gahlin at oracle.com (Erik Gahlin) Date: Mon, 21 May 2012 13:18:15 +0200 Subject: RFR: 7017818 NLS: JConsoleResources.java cannot be handled by translation team In-Reply-To: <4FAD3B63.8070501@oracle.com> References: <4FAD23E4.90501@oracle.com> <4FAD3B63.8070501@oracle.com> Message-ID: <4FBA2477.7040101@oracle.com> Thanks Michael, When it comes to ALL CAPs or SturdlyCaps, it's okay if those strings are not translated. Here is an updated webrev. I removed strings that were no longer in use and made some changes to the make-files. http://cr.openjdk.java.net/~egahlin/7017818_4/ /E Michael Fang skrev 2012-05-11 18:16: > Thanks so much Erik for the fix! The messages.properties file look > good. I only reviewed the English *messages.properties* file. WPTG > will re-translate the ja and zh_CN files. They will attempt to > leverage existing translation from *JConsoleResources_xx.java*. > > I have a comments about another translatability rule that WPTG follows: > > By Oracle software development guideline, ALL CAPs or StudlyCaps > strings will not be translated. Examples are: > 19 ACTION_CAPITALIZED=ACTION > 20 ACTION_INFO_CAPITALIZED=ACTION_INFO > 149 MBEAN_INFO=MBeanInfo > 150 MBEAN_NOTIFICATION_INFO=MBeanNotificationInfo > 151 MBEAN_OPERATION_INFO=MBeanOperationInfo > 206 OBJECT_NAME=ObjectName > 231 R_FORWARD_SLASH_W_CAPITALIZED=R/W > > 241 SEQ_NUM=SeqNum > 249 SUMMARY_TAB_HEADER_DATE_TIME_FORMAT=FULL,FULL > > 273 UNKNOWN_CAPITALIZED=UNKNOWN > > If any of the above such as ACTION or UNKNOWN needs to be translated, > they should not be ALL CAPS. The translators will not translate those > lines by default. > > The translators have the ability to see comments (or special requests) > if a comment line is inserted immediately prior to any of the > resources (each resource string and one comment line immediately > before it is stored in translation memory). If you must leave ACTION > or UNKNOWN in CAPS, you can try to insert comments.However, WPTG does > not guarantee they will be followed. > > thanks, > > -michael > > On 12?05?11? 07:36 ??, Erik Gahlin wrote: >> Could you please review? I also need a sponsor. >> >> http://cr.openjdk.java.net/~egahlin/7156518/1_0/ >> >> http://monaco.us.oracle.com/detail.jsf?cr=7017818 >> >> The patch is for JDK8, but it needs to ported to 7u6 before 5/16. >> >> Thanks! >> >> Erik >> >> Changes: >> >> - Moved localization messages to property files, one message per >> line, as needed. >> - Added '&' to messages so mnemonics could be identified. >> - Introduced Message class with static fields corresponding to the >> keys in the property files. >> - Added map for looking up mnemonics. >> >> Testing: >> >> - Verified programmatically that all the messages and mnemonics are >> "compatible" with the previous mechanism, for Chinese, Japanese and >> the default locale. >> - The intention is to run through the GUI to confirm that everything >> looks ok, but I'm waiting for a build. >> >> Other: >> >> - Fixed a typo in the MemoryPoolStat class, the method >> getAfterGcUsage returned this.beforeGCUsage instead of this.afterGcUsage >> - When going through all the code I did some minor clean up that >> should not impact the program flow: >> * removed unused imports. >> * inlined temporary variables holding messages. >> * removed private member variables that were not accessed. >> * removed private methods that were not referenced. >> * removed local variables that were not used. >> * added generic types where needed. >> * static methods are now called statically. >> * added suppress serialization warning where it was needed. >> * removed suppress serialization annotation where it was not needed. >> - In the Message class, the comment "remove? not found in code" will >> be removed once I know those message are not needed for 7u6. >> -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/i18n-dev/attachments/20120521/62f43dec/attachment.html From mandy.chung at oracle.com Mon May 21 14:13:14 2012 From: mandy.chung at oracle.com (Mandy Chung) Date: Mon, 21 May 2012 14:13:14 -0700 Subject: RFR: 7017818 NLS: JConsoleResources.java cannot be handled by translation team In-Reply-To: <4FBA2477.7040101@oracle.com> References: <4FAD23E4.90501@oracle.com> <4FAD3B63.8070501@oracle.com> <4FBA2477.7040101@oracle.com> Message-ID: <4FBAAFEA.6090305@oracle.com> Erik, I like your idea of trying to define the string constants for the keys to benefit from the compiler checking and catch any issue due to typos at compile time. My review comments below. Your webrev includes other cleanup. While it's good to do the simple minor cleanup with this fix, I'd like to the warnings cleanup changes be separated from this patch and done by a separate CR. > * added generic types where needed. > * added suppress serialization warning where it was needed. > * removed suppress serialization annotation where it was not needed. Specifically, I'm concerned with @SuppressWarning("serial"). Tab.java L31 - it should not be suppressed and instead be fixed by defining the serialVersionUID (you can find the value by running serialver tool). Same to XOperations.java and XTable.java. I notice that the current code does suppress "serial" warning that you should check if it should be fixed as well. As for the generics, ProxyClient.java and XTree.java (and maybe some other places). When I saw the use of Iterator, I typically would also suggest to replacethe Iterator and while loop with foreach (L601-617 and L710, 736). Anyway, the warning cleanup deserves a separate CR and review. Below are comments on the change to support translateability. sun/tools/jconsole/resources/Messages.java I suggest to move Messages to sun.tools.jconsole since it's a utility class and conventionally resources are put in a "resources" subpackage (i.e. sun.tools.jconsole.resources in this case). The initializeMessage method uses the field name as the key and initializes its value to its localized message via reflection. Such approach seems strange. Have you considered about defining the constants with the key as the value (i.e. the variable name and its value are the same). Instead of initializing each static field of the Messages class, you can build a map of a key to the localized message + itsmnemonic key (like what you have done in building the MNEMONIC_LOOKUP map - why not change such hash map to map from a string to an object {message+mnemonic}). In that case, the MNEMONIC_LOOKUP doesn't need to be a synchronized map and could be done as the class initialization of Resources class. It would only need to keep Resources.getText(String) method that returns the localized message, e.g. Resources.getText(Messages.HELP_ABOUT_DIALOG_TITLE) I just don't see it's worth the complexity to initialize the static fields via reflection to get rid of a convenience method. It is only my suggestion and I understand that this fix needs to be backport to 7u6. If you agree that replacing this static field initialization logic with a separate map, I'm okay with pushing this approach to 7u6 and push a better fix to jdk8. Or I miss the benefit you were considering :) There are a few names with '_' suffix e.g. L93, 97, 104, 160 and also some names with '__' (L97, 159). Do you want to embed the space of the message in the key name? In any case, the key names with '_' suffix or double underscores '__' is a little confusing. It would be better just to use '_' for separating words of a key name and no need for '_' suffix. The names 'CHART_COLON', 'ERROR_COLON_MBEANS...', 'JCONSOLE_COLON', and the ones with 'COLON' to describe its message with ":" are strange. If ":" was removed from the message in the future, the name would need to be modified to follow this naming convention which is overkill. sun/tools/jconsole/Resources.java L52-54 and also other @param, nit:generally we put the description in the same line as the @param. XOpenTypeViewer.java L255: this doesn't look right - I think it should be Comparable. However, this method has @SuppressWarning("unchecked") and why was this line changed? Did you get other warning? Formatting nits: it's good to go through your changes and fix the formatting nits. The lines need to be updated to aligned, a few examples are: BorderedComponent.java L152 CreateMBeanDialog.java L77-78, 165-167, 169-171 MemoryTab.java L120-121, 126-127 OverviewTab.java L59-60 Plotter.java L319-321, 329-331 I didn't include all and please check the files not mentioned above. On 5/21/2012 4:18 AM, Erik Gahlin wrote: > Thanks Michael, > > When it comes to ALL CAPs or SturdlyCaps, it's okay if those strings > are not translated. > > Here is an updated webrev. I removed strings that were no longer in > use and made some changes to the make-files. > > http://cr.openjdk.java.net/~egahlin/7017818_4/ > > /E > > Michael Fang skrev 2012-05-11 18:16: >> Thanks so much Erik for the fix! The messages.properties file look >> good. I only reviewed the English *messages.properties* file. WPTG >> will re-translate the ja and zh_CN files. They will attempt to >> leverage existing translation from *JConsoleResources_xx.java*. >> >> I have a comments about another translatability rule that WPTG follows: >> >> By Oracle software development guideline, ALL CAPs or StudlyCaps >> strings will not be translated. Examples are: >> 19 ACTION_CAPITALIZED=ACTION >> 20 ACTION_INFO_CAPITALIZED=ACTION_INFO >> 149 MBEAN_INFO=MBeanInfo >> 150 MBEAN_NOTIFICATION_INFO=MBeanNotificationInfo >> 151 MBEAN_OPERATION_INFO=MBeanOperationInfo >> 206 OBJECT_NAME=ObjectName >> 231 R_FORWARD_SLASH_W_CAPITALIZED=R/W >> >> 241 SEQ_NUM=SeqNum >> 249 SUMMARY_TAB_HEADER_DATE_TIME_FORMAT=FULL,FULL >> >> 273 UNKNOWN_CAPITALIZED=UNKNOWN >> >> If any of the above such as ACTION or UNKNOWN needs to be translated, >> they should not be ALL CAPS. The translators will not translate those >> lines by default. >> >> The translators have the ability to see comments (or special >> requests) if a comment line is inserted immediately prior to any of >> the resources (each resource string and one comment line immediately >> before it is stored in translation memory). If you must leave ACTION >> or UNKNOWN in CAPS, you can try to insert comments.However, WPTG does >> not guarantee they will be followed. >> >> thanks, >> >> -michael >> >> On 12?05?11? 07:36 ??, Erik Gahlin wrote: >>> Could you please review? I also need a sponsor. >>> >>> http://cr.openjdk.java.net/~egahlin/7156518/1_0/ >>> >>> http://monaco.us.oracle.com/detail.jsf?cr=7017818 >>> >>> The patch is for JDK8, but it needs to ported to 7u6 before 5/16. >>> >>> Thanks! >>> >>> Erik >>> >>> Changes: >>> >>> - Moved localization messages to property files, one message per >>> line, as needed. >>> - Added '&' to messages so mnemonics could be identified. >>> - Introduced Message class with static fields corresponding to the >>> keys in the property files. >>> - Added map for looking up mnemonics. >>> >>> Testing: >>> >>> - Verified programmatically that all the messages and mnemonics are >>> "compatible" with the previous mechanism, for Chinese, Japanese and >>> the default locale. >>> - The intention is to run through the GUI to confirm that everything >>> looks ok, but I'm waiting for a build. >>> >>> Other: >>> >>> - Fixed a typo in the MemoryPoolStat class, the method >>> getAfterGcUsage returned this.beforeGCUsage instead of >>> this.afterGcUsage >>> - When going through all the code I did some minor clean up that >>> should not impact the program flow: >>> * removed unused imports. >>> * inlined temporary variables holding messages. >>> * removed private member variables that were not accessed. >>> * removed private methods that were not referenced. >>> * removed local variables that were not used. >>> * added generic types where needed. >>> * static methods are now called statically. >>> * added suppress serialization warning where it was needed. >>> * removed suppress serialization annotation where it was not needed. >>> - In the Message class, the comment "remove? not found in code" will >>> be removed once I know those message are not needed for 7u6. >>> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/i18n-dev/attachments/20120521/d712a0df/attachment.html From erik.gahlin at oracle.com Tue May 22 12:40:08 2012 From: erik.gahlin at oracle.com (Erik Gahlin) Date: Tue, 22 May 2012 21:40:08 +0200 Subject: RFR: 7017818 NLS: JConsoleResources.java cannot be handled by translation team In-Reply-To: <4FBAAFEA.6090305@oracle.com> References: <4FAD23E4.90501@oracle.com> <4FAD3B63.8070501@oracle.com> <4FBA2477.7040101@oracle.com> <4FBAAFEA.6090305@oracle.com> Message-ID: <4FBBEB98.50704@oracle.com> Mandy Chung skrev 2012-05-21 23:13: > Erik, > > I like your idea of trying to define the string constants > for the keys to benefit from the compiler checking and > catch any issue due to typos at compile time. My review > comments below. > > Your webrev includes other cleanup. While it's good to > do the simple minor cleanup with this fix, I'd like to > the warnings cleanup changes be separated from this patch > and done by a separate CR. Thanks for reviewing, I got a lot of unused import warnings from the IDE when I changed the Resources class. When I cleaned them up I thought I might as well clean up the others too, so I could more easily see that I had taken care of all the warnings I caused. Same thing with unused member variables and unused methods. Import-statements will not change how the program executes, so I thought it was safe to remove them (no risk of introducing new bugs). > >> * added generic types where needed. >> * added suppress serialization warning where it was needed. >> * removed suppress serialization annotation where it was not needed. > > Specifically, I'm concerned with @SuppressWarning("serial"). > Tab.java L31 - it should not be suppressed and instead be > fixed by defining the serialVersionUID (you can find the > value by running serialver tool). Same to XOperations.java and > XTable.java. I notice that the current code does suppress > "serial" warning that you should check if it should be fixed > as well. I agree, I was trying to get rid of all the warnings so I could see the real problems more easily. Adding serialVersionUID might be beyond the scope of the CR. I can bring back the warnings, if you like, now that I know my code is free of warnings. > > As for the generics, ProxyClient.java and XTree.java (and > maybe some other places). When I saw the use of Iterator, > I typically would also suggest to replacethe Iterator and > while loop with foreach (L601-617 and L710, 736). I agree, I was trying to get rid of all the warnings so I could see the real problems. Foreach is prefered, but I think it's beyond the scope of the CR to replace all those. Also, adding generics doesn't change the byte code and should be safe. Rewritings loops could potentially introduce other bugs and to me there is little benefit. > Anyway, > the warning cleanup deserves a separate CR and review. Breaking it up into seperate patches and CRs will take time. Is it really necessary? I cleaned up the code so I could make the fix more easily. I don't think it's worth the hazzle to create a separate bug and patch. I might as well revert the clean ups. > > Below are comments on the change to support translateability. > > sun/tools/jconsole/resources/Messages.java > I suggest to move Messages to sun.tools.jconsole since > it's a utility class and conventionally resources are put > in a "resources" subpackage (i.e. sun.tools.jconsole.resources > in this case). I think one package private Message class for each package and separate resource files for each package would be the best, but I didn't want this CR to blow up, so I put the Message class where the other Java classes related to resources were before. I can move it to sun.tools.jconsole, if you think that's better. > > The initializeMessage method uses the field name as the > key and initializes its value to its localized message via > reflection. Such approach seems strange. I like to enforce one-to-one mapping between the keys in the property file and the keys used in the Java code. When going through the fields in the Message class, using reflection, I can ensure that all fields have a corresponding property value in the file, and vice versa. With this approrach it's not necessary click through all the GUI to verify that all keys exists in the property file. It's also possible to detect if a value in a property file is no longer in use. The code that does the one-to-one check was removed, but it should probably be added back so similar problems can be catched automatically in the future. > > Have you considered about defining the constants with > the key as the value (i.e. the variable name and its > value are the same). The Java constants can't be the same as the property value since the character you can use for a variable name is limited, for instance a constant can't contain the ':'-character. > Instead of initializing each > static field of the Messages class, you can build > a map of a key to the localized message + itsmnemonic > key (like what you have done in building the MNEMONIC_LOOKUP > map - why not change such hash map to map from a string to > an object {message+mnemonic}). In that case, the MNEMONIC_LOOKUP > doesn't need to be a synchronized map and could be done > as the class initialization of Resources class. > > It would only need to keep > Resources.getText(String) method that returns the localized > message, e.g. > Resources.getText(Messages.HELP_ABOUT_DIALOG_TITLE) > > I just don't see it's worth the complexity to initialize > the static fields via reflection to get rid of a convenience > method. The synchronization is not really needed, if you always use the keys to lookup the messages. The static initializer in the Message class should ensure correct ordering. Looking up messages "dynamically" means you have to trigger all the code in the GUI that needs a translated message to be sure you got things correct. Since there are several hundred messages I think the static-fields-reflection approach is better. > > > It is only my suggestion and I understand that this fix needs > to be backport to 7u6. If you agree that replacing this > static field initialization logic with a separate map, > I'm okay with pushing this approach to 7u6 and push > a better fix to jdk8. Or I miss the benefit you were > considering :) You are missing it :) .. and it's probably because I removed the code that did the actual check :) > > There are a few names with '_' suffix e.g. L93, 97, 104, 160 > and also some names with '__' (L97, 159). Do you want to > embed the space of the message in the key name? In any case, > the key names with '_' suffix or double underscores '__' is > a little confusing. It would be better just to use '_' for > separating words of a key name and no need for '_' suffix. > The names 'CHART_COLON', 'ERROR_COLON_MBEANS...', 'JCONSOLE_COLON', > and the ones with 'COLON' to describe its message with ":" > are strange. If ":" was removed from the message in the > future, the name would need to be modified to follow this > naming convention which is overkill. The keys were generated programmatically. The 'COLON' was needed so I could differentiate between message that looked the same, except for the ':' at the end. The pattern was applied to all messages. Some of those message were removed (since they were no longer in use) I can remove the 'COLON' suffix where it's not needed, same thing with spaces. I will go over the message keys and clean up the names, but they were not that clean before either :) > > sun/tools/jconsole/Resources.java > L52-54 and also other @param, nit:generally we put > the description in the same line as the @param. Will fix! > XOpenTypeViewer.java > L255: this doesn't look right - I think it should be > Comparable. However, this method has > @SuppressWarning("unchecked") and why was this line > changed? Did you get other warning? > CompositeData#get returns Object and because of type erasure it can't be guaranteed to be Comparable without an explicit cast, which I didn't dare to add, so I put in Object. Yes, I got a rawtypes warning on the Comparable. > Formatting nits: it's good to go through your changes and > fix the formatting nits. The lines need to be updated to > aligned, a few examples are: > BorderedComponent.java L152 > CreateMBeanDialog.java L77-78, 165-167, 169-171 > MemoryTab.java L120-121, 126-127 > OverviewTab.java L59-60 > Plotter.java L319-321, 329-331 > > I didn't include all and please check the files not mentioned above. > Will do! > On 5/21/2012 4:18 AM, Erik Gahlin wrote: >> Thanks Michael, >> >> When it comes to ALL CAPs or SturdlyCaps, it's okay if those strings >> are not translated. >> >> Here is an updated webrev. I removed strings that were no longer in >> use and made some changes to the make-files. >> >> http://cr.openjdk.java.net/~egahlin/7017818_4/ >> >> /E >> >> Michael Fang skrev 2012-05-11 18:16: >>> Thanks so much Erik for the fix! The messages.properties file look >>> good. I only reviewed the English *messages.properties* file. WPTG >>> will re-translate the ja and zh_CN files. They will attempt to >>> leverage existing translation from *JConsoleResources_xx.java*. >>> >>> I have a comments about another translatability rule that WPTG follows: >>> >>> By Oracle software development guideline, ALL CAPs or StudlyCaps >>> strings will not be translated. Examples are: >>> 19 ACTION_CAPITALIZED=ACTION >>> 20 ACTION_INFO_CAPITALIZED=ACTION_INFO >>> 149 MBEAN_INFO=MBeanInfo >>> 150 MBEAN_NOTIFICATION_INFO=MBeanNotificationInfo >>> 151 MBEAN_OPERATION_INFO=MBeanOperationInfo >>> 206 OBJECT_NAME=ObjectName >>> 231 R_FORWARD_SLASH_W_CAPITALIZED=R/W >>> >>> 241 SEQ_NUM=SeqNum >>> 249 SUMMARY_TAB_HEADER_DATE_TIME_FORMAT=FULL,FULL >>> >>> 273 UNKNOWN_CAPITALIZED=UNKNOWN >>> >>> If any of the above such as ACTION or UNKNOWN needs to be >>> translated, they should not be ALL CAPS. The translators will not >>> translate those lines by default. >>> >>> The translators have the ability to see comments (or special >>> requests) if a comment line is inserted immediately prior to any of >>> the resources (each resource string and one comment line immediately >>> before it is stored in translation memory). If you must leave ACTION >>> or UNKNOWN in CAPS, you can try to insert comments.However, WPTG >>> does not guarantee they will be followed. >>> >>> thanks, >>> >>> -michael >>> >>> On 12?05?11? 07:36 ??, Erik Gahlin wrote: >>>> Could you please review? I also need a sponsor. >>>> >>>> http://cr.openjdk.java.net/~egahlin/7156518/1_0/ >>>> >>>> http://monaco.us.oracle.com/detail.jsf?cr=7017818 >>>> >>>> The patch is for JDK8, but it needs to ported to 7u6 before 5/16. >>>> >>>> Thanks! >>>> >>>> Erik >>>> >>>> Changes: >>>> >>>> - Moved localization messages to property files, one message per >>>> line, as needed. >>>> - Added '&' to messages so mnemonics could be identified. >>>> - Introduced Message class with static fields corresponding to the >>>> keys in the property files. >>>> - Added map for looking up mnemonics. >>>> >>>> Testing: >>>> >>>> - Verified programmatically that all the messages and mnemonics are >>>> "compatible" with the previous mechanism, for Chinese, Japanese and >>>> the default locale. >>>> - The intention is to run through the GUI to confirm that >>>> everything looks ok, but I'm waiting for a build. >>>> >>>> Other: >>>> >>>> - Fixed a typo in the MemoryPoolStat class, the method >>>> getAfterGcUsage returned this.beforeGCUsage instead of >>>> this.afterGcUsage >>>> - When going through all the code I did some minor clean up that >>>> should not impact the program flow: >>>> * removed unused imports. >>>> * inlined temporary variables holding messages. >>>> * removed private member variables that were not accessed. >>>> * removed private methods that were not referenced. >>>> * removed local variables that were not used. >>>> * added generic types where needed. >>>> * static methods are now called statically. >>>> * added suppress serialization warning where it was needed. >>>> * removed suppress serialization annotation where it was not needed. >>>> - In the Message class, the comment "remove? not found in code" >>>> will be removed once I know those message are not needed for 7u6. >>>> >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/i18n-dev/attachments/20120522/1a50514c/attachment-0001.html From michael.fang at oracle.com Tue May 22 12:58:34 2012 From: michael.fang at oracle.com (Michael Fang) Date: Tue, 22 May 2012 12:58:34 -0700 Subject: RFR: 7017818 NLS: JConsoleResources.java cannot be handled by translation team In-Reply-To: <4FBA2477.7040101@oracle.com> References: <4FAD23E4.90501@oracle.com> <4FAD3B63.8070501@oracle.com> <4FBA2477.7040101@oracle.com> Message-ID: <4FBBEFEA.9050601@oracle.com> Thanks Erik. I have already downloaded the raw message.properties file from the webrev on 5/16 to proceed with the 7u6 translation. I performed a diff with current webrev, and it consists of mostly deleted resources and 1 renamed key CONNECTION_LOST1 => CONNECTION_LOST. I am fine with the changes from l10n perspective. thanks, -michael On 12?05?21? 04:18 ??, Erik Gahlin wrote: > Thanks Michael, > > When it comes to ALL CAPs or SturdlyCaps, it's okay if those strings > are not translated. > > Here is an updated webrev. I removed strings that were no longer in > use and made some changes to the make-files. > > http://cr.openjdk.java.net/~egahlin/7017818_4/ > > /E > > Michael Fang skrev 2012-05-11 18:16: >> Thanks so much Erik for the fix! The messages.properties file look >> good. I only reviewed the English *messages.properties* file. WPTG >> will re-translate the ja and zh_CN files. They will attempt to >> leverage existing translation from *JConsoleResources_xx.java*. >> >> I have a comments about another translatability rule that WPTG follows: >> >> By Oracle software development guideline, ALL CAPs or StudlyCaps >> strings will not be translated. Examples are: >> 19 ACTION_CAPITALIZED=ACTION >> 20 ACTION_INFO_CAPITALIZED=ACTION_INFO >> 149 MBEAN_INFO=MBeanInfo >> 150 MBEAN_NOTIFICATION_INFO=MBeanNotificationInfo >> 151 MBEAN_OPERATION_INFO=MBeanOperationInfo >> 206 OBJECT_NAME=ObjectName >> 231 R_FORWARD_SLASH_W_CAPITALIZED=R/W >> >> 241 SEQ_NUM=SeqNum >> 249 SUMMARY_TAB_HEADER_DATE_TIME_FORMAT=FULL,FULL >> >> 273 UNKNOWN_CAPITALIZED=UNKNOWN >> >> If any of the above such as ACTION or UNKNOWN needs to be translated, >> they should not be ALL CAPS. The translators will not translate those >> lines by default. >> >> The translators have the ability to see comments (or special >> requests) if a comment line is inserted immediately prior to any of >> the resources (each resource string and one comment line immediately >> before it is stored in translation memory). If you must leave ACTION >> or UNKNOWN in CAPS, you can try to insert comments.However, WPTG does >> not guarantee they will be followed. >> >> thanks, >> >> -michael >> >> On 12?05?11? 07:36 ??, Erik Gahlin wrote: >>> Could you please review? I also need a sponsor. >>> >>> http://cr.openjdk.java.net/~egahlin/7156518/1_0/ >>> >>> http://monaco.us.oracle.com/detail.jsf?cr=7017818 >>> >>> The patch is for JDK8, but it needs to ported to 7u6 before 5/16. >>> >>> Thanks! >>> >>> Erik >>> >>> Changes: >>> >>> - Moved localization messages to property files, one message per >>> line, as needed. >>> - Added '&' to messages so mnemonics could be identified. >>> - Introduced Message class with static fields corresponding to the >>> keys in the property files. >>> - Added map for looking up mnemonics. >>> >>> Testing: >>> >>> - Verified programmatically that all the messages and mnemonics are >>> "compatible" with the previous mechanism, for Chinese, Japanese and >>> the default locale. >>> - The intention is to run through the GUI to confirm that everything >>> looks ok, but I'm waiting for a build. >>> >>> Other: >>> >>> - Fixed a typo in the MemoryPoolStat class, the method >>> getAfterGcUsage returned this.beforeGCUsage instead of >>> this.afterGcUsage >>> - When going through all the code I did some minor clean up that >>> should not impact the program flow: >>> * removed unused imports. >>> * inlined temporary variables holding messages. >>> * removed private member variables that were not accessed. >>> * removed private methods that were not referenced. >>> * removed local variables that were not used. >>> * added generic types where needed. >>> * static methods are now called statically. >>> * added suppress serialization warning where it was needed. >>> * removed suppress serialization annotation where it was not needed. >>> - In the Message class, the comment "remove? not found in code" will >>> be removed once I know those message are not needed for 7u6. >>> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/i18n-dev/attachments/20120522/c21fe2bc/attachment.html From mandy.chung at oracle.com Tue May 22 14:49:55 2012 From: mandy.chung at oracle.com (Mandy Chung) Date: Tue, 22 May 2012 14:49:55 -0700 Subject: RFR: 7017818 NLS: JConsoleResources.java cannot be handled by translation team In-Reply-To: <4FBBEB98.50704@oracle.com> References: <4FAD23E4.90501@oracle.com> <4FAD3B63.8070501@oracle.com> <4FBA2477.7040101@oracle.com> <4FBAAFEA.6090305@oracle.com> <4FBBEB98.50704@oracle.com> Message-ID: <4FBC0A03.2000906@oracle.com> Erik, I approve what you have - please go through and fix the formatting nits. I inlined my comment below and you can follow up them later if needed. On 5/22/2012 12:40 PM, Erik Gahlin wrote: > Thanks for reviewing, > > I got a lot of unused import warnings from the IDE when I changed the > Resources class. When I cleaned them up I thought I might as well > clean up the > others too, so I could more easily see that I had taken care of all the > warnings I caused. Same thing with unused member variables and unused > methods. > > Import-statements will not change how the program executes, so I > thought it > was safe to remove them (no risk of introducing new bugs). > > ... >> Anyway, >> the warning cleanup deserves a separate CR and review. > Breaking it up into seperate patches and CRs will take time. Is it really > necessary? I'm okay for this patch to include the removal of unused imports and dead code fixes. The warnings I referred to are the @SuppressedWarnings("serial") and rawtypes changes since it may require a separate pair of eyes to review them. As a general advice, when the number of warnings cleaned up is not small, it's always recommended to separate them as two separate CRs for bug management and backport and it also helps the reviewers :) Since you have made the change along with the fix for this CR, I can understand why you said it will take time. I also understand that you're under a time pressure. I can go with what you have but please consider in the future when to separate the change in a separate CR. > > I cleaned up the code so I could make the fix more easily. I don't > think it's > worth the hazzle to create a separate bug and patch. I might as well > revert > the clean ups. > BTW, backporting to an update release might request not to include the warnings cleanup. I'm not sure the putback approval requirements for 7u6. >> >> Below are comments on the change to support translateability. >> >> sun/tools/jconsole/resources/Messages.java >> I suggest to move Messages to sun.tools.jconsole since >> it's a utility class and conventionally resources are put >> in a "resources" subpackage (i.e. sun.tools.jconsole.resources >> in this case). > I think one package private Message class for each package and separate > resource files for each package would be the best, but I didn't want > this CR to blow up, so I put the Message class where the other Java > classes > related to resources were before. > > I can move it to sun.tools.jconsole, if you think that's better. > I think so so that sun.tools.jconsole.resources.* are resource files. >> >> The initializeMessage method uses the field name as the >> key and initializes its value to its localized message via >> reflection. Such approach seems strange. > I like to enforce one-to-one mapping between the keys in the property > file and > the keys used in the Java code. When going through the fields in the > Message > class, using reflection, I can ensure that all fields have a corresponding > property value in the file, and vice versa. > > With this approrach it's not necessary click through all the GUI to > verify that > all keys exists in the property file. It's also possible to detect if > a value > in a property file is no longer in use. > > The code that does the one-to-one check was removed, but it should > probably be > added back so similar problems can be catched automatically in the future. > >> >> Have you considered about defining the constants with >> the key as the value (i.e. the variable name and its >> value are the same). > The Java constants can't be the same as the property value I meant the key value in messages.properties (not the property value). Essentially variable and the value is the same e.g. static final String ONE_DAY = "ONE_DAY"; >> Instead of initializing each >> static field of the Messages class, you can build >> a map of a key to the localized message + itsmnemonic >> key (like what you have done in building the MNEMONIC_LOOKUP >> map - why not change such hash map to map from a string to >> an object {message+mnemonic}). In that case, the MNEMONIC_LOOKUP >> doesn't need to be a synchronized map and could be done >> as the class initialization of Resources class. >> >> It would only need to keep >> Resources.getText(String) method that returns the localized >> message, e.g. >> Resources.getText(Messages.HELP_ABOUT_DIALOG_TITLE) >> >> I just don't see it's worth the complexity to initialize >> the static fields via reflection to get rid of a convenience >> method. > > The synchronization is not really needed, if you always use the keys to > lookup the messages. The static initializer in the Message class should > ensure correct ordering. > > Looking up messages "dynamically" means you have to trigger all the > code in the GUI that needs a translated message to be sure you got things > correct. Since there are several hundred messages I think the > static-fields-reflection approach is better. > >> >> >> It is only my suggestion and I understand that this fix needs >> to be backport to 7u6. If you agree that replacing this >> static field initialization logic with a separate map, >> I'm okay with pushing this approach to 7u6 and push >> a better fix to jdk8. Or I miss the benefit you were >> considering :) > > You are missing it :) > > .. and it's probably because I removed the code that did the actual > check :) > I agree that checking one-to-one mapping between the keys in the property file and the keys used in the Java code is good. What you need is to compare the list of constants with the keys in messages.properties. Anyway, my suggestion was just to simplify such initialization. You can go with what you have. // >> >> There are a few names with '_' suffix e.g. L93, 97, 104, 160 >> and also some names with '__' (L97, 159). Do you want to >> embed the space of the message in the key name? In any case, >> the key names with '_' suffix or double underscores '__' is >> a little confusing. It would be better just to use '_' for >> separating words of a key name and no need for '_' suffix. >> The names 'CHART_COLON', 'ERROR_COLON_MBEANS...', 'JCONSOLE_COLON', >> and the ones with 'COLON' to describe its message with ":" >> are strange. If ":" was removed from the message in the >> future, the name would need to be modified to follow this >> naming convention which is overkill. > The keys were generated programmatically. > Ah - that's what I guess. > The 'COLON' was needed so I could differentiate between message that > looked > the same, except for the ':' at the end. The pattern was applied to all > messages. Some of those message were removed (since they were no > longer in use) > > I can remove the 'COLON' suffix where it's not needed, same thing > with spaces. > That'd be good since "COLON" and '_' is meaningless w.r.t. the key name. IDE refactoring feature should make this renaming effortless :) > I will go over the message keys and clean up the names, but they were > not that > clean before either :) Thanks. Mandy -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/i18n-dev/attachments/20120522/ce4e4f4b/attachment-0001.html From littlee at linux.vnet.ibm.com Wed May 23 01:03:21 2012 From: littlee at linux.vnet.ibm.com (Charles Lee) Date: Wed, 23 May 2012 16:03:21 +0800 Subject: Fwd: Some differences on Window UDC area In-Reply-To: <4D918382.7070905@linux.vnet.ibm.com> References: <4D8FEFCC.50002@linux.vnet.ibm.com> <4D8FF4AB.2030306@oracle.com> <4D9000B7.8080504@linux.vnet.ibm.com> <4D90A40C.6090802@oracle.com> <4D918382.7070905@linux.vnet.ibm.com> Message-ID: <4FBC99C9.7080508@linux.vnet.ibm.com> Hi guys, We have a simple test case: for (String cname : new String[] { "GBK", "MS936", "GB18030" }) { Charset charset = Charset.forName(cname); System.out.println("charset: " + charset.name()); CharsetEncoder ce = charset.newEncoder(); char[] chars = new char[] { 0xE585, 0xE586, 0xE592 }; CharBuffer cb = CharBuffer.wrap(chars); ByteBuffer bb = ce.encode(cb); for (char c : chars) { System.out.printf("\\u%04x", (int) c); } System.out.print(" -> "); for (byte b : bb.array()) if (b != 0x0) { System.out.printf("\\x%02x", (int) b & 0xFF); } System.out.println(""); } The output is charset: GBK \ue585\ue586\ue592 -> \xa2\xa0\xa2\xab\xa3\x40 charset: x-mswin-936 \ue585\ue586\ue592 -> \xa2\xa0\xa2\xab\xa3\x40 charset: GB18030 \ue585\ue586\ue592 -> \xa2\xa0\xa3\x40\xa3\x4c From the msdn[1], U+E000 -> U+F8FF is in the EUDC scope. So U+E586 is in the EUDC scope. But the mapped code in MS936/GBK is 0xA2AB, it is not in the EUDC scope. With another simple test case, you can find there are more codes that is not mapped right: for (int i = 0xE000; i < 0xE000 + 1894; i++) { String s = new String(new char[] { (char) i }); byte[] bs = s.getBytes("MS936"); int b0 = (int) bs[0] & 0xFF; int b1 = (int) bs[1] & 0xFF; if ((b0 >= 0xAA && b0 <= 0xAF) && (b1 >= 0xA1 && b1 <= 0xFE)) continue; if ((b0 >= 0xF8 && b0 <= 0xFE) && (b1 >= 0xA1 && b1 <= 0xFE)) continue; if ((b0 >= 0xA1 && b0 <= 0xA7) && (b1 >= 0x40 && b1 <= 0xA0)) continue; System.out.printf("\\u%04X -> \\x%02X\\x%02X%n", i, b0, b1); } I have written a generator in C#[2] which outputs the mapping code in GB2312[3] and GB18030[4] in scope U+E000 and U+F8FF to find that most of code are the same. Hereby I suggest we may follow the code from GB2312 and the changed map file in openjdk can be found [5][6]. Would anyone help to take a look on this issue? [1] http://msdn.microsoft.com/en-us/library/windows/desktop/dd317837%28v=vs.85%29.aspx [2] http://cr.openjdk.java.net/~littlee/OJDK-63/webrev.00/Program.cs [3] http://cr.openjdk.java.net/~littlee/OJDK-63/webrev.00/gb2312Map.txt [4] http://cr.openjdk.java.net/~littlee/OJDK-63/webrev.00/gb18030Map.txt [5] http://cr.openjdk.java.net/~littlee/OJDK-63/webrev.00/GBK.map.new [6] http://cr.openjdk.java.net/~littlee/OJDK-63/webrev.00/MS936.map.new P.S: Sorry for the late notice. On 03/29/2011 03:00 PM, Charles Lee wrote: > On 03/28/2011 11:06 PM, Alan Bateman wrote: >> Charles Lee wrote: >>> : >>> >>> It looks similar. How can I find the patch quickly? I notice it says >>> "the list is attached to this CR". Is it CR-6183404? Since cr has >>> the pattern cr.openjdk.java.net/~username/id, how can I know who is >>> the committer to this CR? >> cr.openjdk.java.net is the place where we push webrevs when a patch >> is out for review. I don't think this one is one anyone's list for >> jdk7 and the list attached to the bug is likely the list of incorrect >> mappings. If this is fixed then I assume the fix will update the >> mappings in jdk/make/tools/CharsetMapping/MS936.map. >> >> -Alan > I have output more bytes[1] to see whether other bytes are encoded > correctly. But unfortunately it is not. It is kind of like, on > windows, using ms936, PUA of ms936 use the PUA of gb18030. In > wikipedia, it says gb18030 is compatible with gbk which ms936 > implemented. Can we conclude that ms936 should follow the gb18030's > behavior? > > > [1] 0xE585, 0xE586, 0xE587, 0xE588, 0xE589, 0xE58a, 0xE58b, 0xE58c, > 0xE58d, 0xE58e, 0xE58f, 0xE590, 0xE591, 0xE592, 0xE593, 0xE594, > 0xE595, 0xE596, 0xE597, 0xE598, 0xE599, 0xE59a, 0xE59b, 0xE59c, > 0xE59d, 0xE59e, 0xe79f. > Using MS936 charset, we expect: > \xa2\xa0\xa3\x40\xa3\x41\xa3\x42\xa3\x43\xa3\x44\xa3\x45\xa3\x46\xa3\x47\xa3\x48\xa3\x49\xa3\x4a\xa3\x4b\xa3\x4c\xa3\x4d\xa3\x4e\xa3\x4f\xa3\x50\xa3\x51\xa3\x52\xa3\x53\xa3\x54\xa3\x55\xa3\x56\xa3\x57\xa3\x58\xa6\xfe > but we got: > \xa2\xa0\xa2\xab\xa2\xac\xa2\xad\xa2\xae\xa2\xaf\xa2\xb0\xa2\xe3\xa2\xe4\xa2\xef\xa2\xf0\xa2\xfd\xa2\xfe\xa3\x40\xa3\x41\xa3\x42\xa3\x43\xa3\x44\xa3\x45\xa3\x46\xa3\x47\xa3\x48\xa3\x49\xa3\x4a\xa3\x4b\xa3\x4c\xa7\xa0 -- Yours Charles -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/i18n-dev/attachments/20120523/7f45c034/attachment.html From erik.gahlin at oracle.com Wed May 23 07:01:39 2012 From: erik.gahlin at oracle.com (Erik Gahlin) Date: Wed, 23 May 2012 16:01:39 +0200 Subject: RFR: 7017818 NLS: JConsoleResources.java cannot be handled by translation team In-Reply-To: <4FBBEFEA.9050601@oracle.com> References: <4FAD23E4.90501@oracle.com> <4FAD3B63.8070501@oracle.com> <4FBA2477.7040101@oracle.com> <4FBBEFEA.9050601@oracle.com> Message-ID: <4FBCEDC3.2080605@oracle.com> Michael Fang skrev 2012-05-22 21:58: > Thanks Erik. > > I have already downloaded the raw message.properties file from the > webrev on 5/16 to proceed with the 7u6 translation. > > I performed a diff with current webrev, and it consists of mostly > deleted resources and 1 renamed key CONNECTION_LOST1 => > CONNECTION_LOST. I am fine with the changes from l10n perspective. > That's good to know. I will rename CONNECTION_LOST back to CONNECTION_LOST1 so it will work with the translated texts you get back. I won't add the 1:1 check since you will get more translated mesages then needed. > > -michael > > On 12?05?21? 04:18 ??, Erik Gahlin wrote: >> Thanks Michael, >> >> When it comes to ALL CAPs or SturdlyCaps, it's okay if those strings >> are not translated. >> >> Here is an updated webrev. I removed strings that were no longer in >> use and made some changes to the make-files. >> >> http://cr.openjdk.java.net/~egahlin/7017818_4/ >> >> /E >> >> Michael Fang skrev 2012-05-11 18:16: >>> Thanks so much Erik for the fix! The messages.properties file look >>> good. I only reviewed the English *messages.properties* file. WPTG >>> will re-translate the ja and zh_CN files. They will attempt to >>> leverage existing translation from *JConsoleResources_xx.java*. >>> >>> I have a comments about another translatability rule that WPTG follows: >>> >>> By Oracle software development guideline, ALL CAPs or StudlyCaps >>> strings will not be translated. Examples are: >>> 19 ACTION_CAPITALIZED=ACTION >>> 20 ACTION_INFO_CAPITALIZED=ACTION_INFO >>> 149 MBEAN_INFO=MBeanInfo >>> 150 MBEAN_NOTIFICATION_INFO=MBeanNotificationInfo >>> 151 MBEAN_OPERATION_INFO=MBeanOperationInfo >>> 206 OBJECT_NAME=ObjectName >>> 231 R_FORWARD_SLASH_W_CAPITALIZED=R/W >>> >>> 241 SEQ_NUM=SeqNum >>> 249 SUMMARY_TAB_HEADER_DATE_TIME_FORMAT=FULL,FULL >>> >>> 273 UNKNOWN_CAPITALIZED=UNKNOWN >>> >>> If any of the above such as ACTION or UNKNOWN needs to be >>> translated, they should not be ALL CAPS. The translators will not >>> translate those lines by default. >>> >>> The translators have the ability to see comments (or special >>> requests) if a comment line is inserted immediately prior to any of >>> the resources (each resource string and one comment line immediately >>> before it is stored in translation memory). If you must leave ACTION >>> or UNKNOWN in CAPS, you can try to insert comments.However, WPTG >>> does not guarantee they will be followed. >>> >>> thanks, >>> >>> -michael >>> >>> On 12?05?11? 07:36 ??, Erik Gahlin wrote: >>>> Could you please review? I also need a sponsor. >>>> >>>> http://cr.openjdk.java.net/~egahlin/7156518/1_0/ >>>> >>>> http://monaco.us.oracle.com/detail.jsf?cr=7017818 >>>> >>>> The patch is for JDK8, but it needs to ported to 7u6 before 5/16. >>>> >>>> Thanks! >>>> >>>> Erik >>>> >>>> Changes: >>>> >>>> - Moved localization messages to property files, one message per >>>> line, as needed. >>>> - Added '&' to messages so mnemonics could be identified. >>>> - Introduced Message class with static fields corresponding to the >>>> keys in the property files. >>>> - Added map for looking up mnemonics. >>>> >>>> Testing: >>>> >>>> - Verified programmatically that all the messages and mnemonics are >>>> "compatible" with the previous mechanism, for Chinese, Japanese and >>>> the default locale. >>>> - The intention is to run through the GUI to confirm that >>>> everything looks ok, but I'm waiting for a build. >>>> >>>> Other: >>>> >>>> - Fixed a typo in the MemoryPoolStat class, the method >>>> getAfterGcUsage returned this.beforeGCUsage instead of >>>> this.afterGcUsage >>>> - When going through all the code I did some minor clean up that >>>> should not impact the program flow: >>>> * removed unused imports. >>>> * inlined temporary variables holding messages. >>>> * removed private member variables that were not accessed. >>>> * removed private methods that were not referenced. >>>> * removed local variables that were not used. >>>> * added generic types where needed. >>>> * static methods are now called statically. >>>> * added suppress serialization warning where it was needed. >>>> * removed suppress serialization annotation where it was not needed. >>>> - In the Message class, the comment "remove? not found in code" >>>> will be removed once I know those message are not needed for 7u6. >>>> >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/i18n-dev/attachments/20120523/fc9fa7ec/attachment.html From youdwei at linux.vnet.ibm.com Wed May 23 22:51:23 2012 From: youdwei at linux.vnet.ibm.com (Deven You) Date: Thu, 24 May 2012 13:51:23 +0800 Subject: Locale patch for Slovenian date format data: dots are missed in the datetime for Slovanian In-Reply-To: <4FBA0A76.40209@oracle.com> References: <4F5454A3.6060907@linux.vnet.ibm.com> <4FB9F1AF.5000106@linux.vnet.ibm.com> <4FBA0A76.40209@oracle.com> Message-ID: <4FBDCC5B.1050501@linux.vnet.ibm.com> Hi Jeffrey, I have updated the webrev[1] according to your comments. Please review it. [1] http://cr.openjdk.java.net/~littlee/OJDK-126/webrev.00/ Thanks a lot! On 05/21/2012 05:27 PM, Yong Jeffrey Huang wrote: > Hi Daven, > > We use the format data in CLDR as the standard. Attached is the sl.xml > in CLDR. In your fix, it's better to be > "EEEE, dd. MMMM y", // full date pattern > "dd. MMMM y", // long date pattern > > Blow is the format defined in CLDR: > > - > - > EEEE, dd. MMMM y > > > - > - > dd. MMMM y > > > > For test case: > > To fix format data of one locale, you must modify corresponding > regression test: > > jdk/test/sun/text/resources/LocaleData: > In the end of the file, add > #bug xxxxxx > FormatData/sl/DateTimePatterns/4=EEEE, dd. MMMM y > FormatData/sl/DateTimePatterns/5=dd. MMMM y > > jdk/test/sun/text/resources/LocaleDataTest.java: > In the end of comments @bug, add the bug number. > > thanks, > Yong > > > On 2012/5/21 15:41, Deven You wrote: >> Hi All, >> >> I think this patch is simple and straight forward, is anyone >> interested in taking a look? >> >> Thanks a lot! >> >> On 03/05/2012 01:52 PM, Deven wrote: >>> Hi i18n-devs, >>> >>> I find there is a problem in Slovenian Locale. In Slovenian Locale, >>> days in a date must with a dot '.', like Oct 23rd 2011 will be 23. >>> oktober 2011. Without the '.', 23 oktober 2011 basically means >>> Twenty-three of October, instead of the Twenty-third of October. >>> >>> Current oracle 6/7/8 all miss the dot '.', so this patch [1] will >>> add dot after the days to correct the date expression in Slovenian >>> Locale. >>> >>> The attached test case [2] shows the the diffrence with/without this >>> patch. The output of this test case are: >>> >>> without this patch: >>> Ponedeljek, 5 marec 2012 >>> >>> with this patch: >>> Ponedeljek, 5. marec 2012 >>> >>> This test case may not be very useful, so I hope anyone can give me >>> some suggestions about how to refine the test case? >>> >>> [1] >>> http://cr.openjdk.java.net/~youdwei/slovenian_formatData/webrev.00/ >>> >>> >>> [2] SlovenianFormatDataTest.java >>> >>> Thanks a lot! >>> >> >> > -- Best Regards, Deven -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/i18n-dev/attachments/20120524/028fa58f/attachment.html From youdwei at linux.vnet.ibm.com Wed May 23 22:53:08 2012 From: youdwei at linux.vnet.ibm.com (Deven You) Date: Thu, 24 May 2012 13:53:08 +0800 Subject: Incorrect TimeZone display name when DST not applicable / disabled In-Reply-To: <4FB46AB8.6000207@linux.vnet.ibm.com> References: <4FA7948A.9090702@linux.vnet.ibm.com> <4FAD2DD4.1020306@oracle.com> <4FB3449F.9020409@linux.vnet.ibm.com> <4FB34CBF.20008@linux.vnet.ibm.com> <4FB3D15A.8090708@oracle.com> <4FB3D343.2050708@gmail.com> <4FB46AB8.6000207@linux.vnet.ibm.com> Message-ID: <4FBDCCC4.4060505@linux.vnet.ibm.com> Hi masayoshi, Could you review Yoshito and my replies and see if it is good to you? Thanks a lot! On 05/17/2012 11:04 AM, Deven You wrote: > Hi Masayoshi, > > I think the workaround is good, but many customers may not know this > fact and when they need change the timezone, they just select another > time zone which does not support DST and ignore that the auto-adjust > option should be checked first. > > To Yoshito, thanks for your information! > > On 05/17/2012 12:18 AM, Yoshito Umaoka wrote: >> >>> I thought Windows XP might (internally) use the Dynamic DST data in >>> the Time Zones registry for supporting any DST rule changes, because >>> Dynamic DST was introduced for the US DST rule change IIRC. But as >>> far as I tested, XP seems to ignore Dynamic DST data. If that's the >>> case, your proposed fix should be good. >>> >> >> As far as I know, the dynamic DST data is used by Windows Vista/2003 >> server or later Windows versions. >> The registry data for dynamic DST is included in Windows XP time zone >> updates, but not used by Windows XP. >> >> -Yoshito >> > > -- Best Regards, Deven From yong.huang at oracle.com Wed May 23 23:00:48 2012 From: yong.huang at oracle.com (Yong Jeffrey Huang) Date: Thu, 24 May 2012 14:00:48 +0800 Subject: Locale patch for Slovenian date format data: dots are missed in the datetime for Slovanian In-Reply-To: <4FBDCC5B.1050501@linux.vnet.ibm.com> References: <4F5454A3.6060907@linux.vnet.ibm.com> <4FB9F1AF.5000106@linux.vnet.ibm.com> <4FBA0A76.40209@oracle.com> <4FBDCC5B.1050501@linux.vnet.ibm.com> Message-ID: <4FBDCE90.1060808@oracle.com> Hi Daven, In FormatData_sl.java, the data are 134 "EEEE, dd. MMMM yyyy", // full date pattern 135 "EEEE, dd. MMMM yyyy", // long date pattern I think they should be changed to "EEEE, dd. MMMM y", // full date pattern "dd. MMMM y", // long date pattern the same as what in test file LocaleData. The change in LocaleData and LocaleDataTest.java are good. thanks for fixing the CR. Yong On 2012/5/24 13:51, Deven You wrote: > Hi Jeffrey, > > I have updated the webrev[1] according to your comments. Please review it. > > [1] http://cr.openjdk.java.net/~littlee/OJDK-126/webrev.00/ > > > Thanks a lot! > > On 05/21/2012 05:27 PM, Yong Jeffrey Huang wrote: >> Hi Daven, >> >> We use the format data in CLDR as the standard. Attached is the >> sl.xml in CLDR. In your fix, it's better to be >> "EEEE, dd. MMMM y", // full date pattern >> "dd. MMMM y", // long date pattern >> >> Blow is the format defined in CLDR: >> >> - >> - >> EEEE, dd. MMMM y >> >> >> - >> - >> dd. MMMM y >> >> >> >> For test case: >> >> To fix format data of one locale, you must modify corresponding >> regression test: >> >> jdk/test/sun/text/resources/LocaleData: >> In the end of the file, add >> #bug xxxxxx >> FormatData/sl/DateTimePatterns/4=EEEE, dd. MMMM y >> FormatData/sl/DateTimePatterns/5=dd. MMMM y >> >> jdk/test/sun/text/resources/LocaleDataTest.java: >> In the end of comments @bug, add the bug number. >> >> thanks, >> Yong >> >> >> On 2012/5/21 15:41, Deven You wrote: >>> Hi All, >>> >>> I think this patch is simple and straight forward, is anyone >>> interested in taking a look? >>> >>> Thanks a lot! >>> >>> On 03/05/2012 01:52 PM, Deven wrote: >>>> Hi i18n-devs, >>>> >>>> I find there is a problem in Slovenian Locale. In Slovenian Locale, >>>> days in a date must with a dot '.', like Oct 23rd 2011 will be 23. >>>> oktober 2011. Without the '.', 23 oktober 2011 basically means >>>> Twenty-three of October, instead of the Twenty-third of October. >>>> >>>> Current oracle 6/7/8 all miss the dot '.', so this patch [1] will >>>> add dot after the days to correct the date expression in Slovenian >>>> Locale. >>>> >>>> The attached test case [2] shows the the diffrence with/without >>>> this patch. The output of this test case are: >>>> >>>> without this patch: >>>> Ponedeljek, 5 marec 2012 >>>> >>>> with this patch: >>>> Ponedeljek, 5. marec 2012 >>>> >>>> This test case may not be very useful, so I hope anyone can give me >>>> some suggestions about how to refine the test case? >>>> >>>> [1] >>>> http://cr.openjdk.java.net/~youdwei/slovenian_formatData/webrev.00/ >>>> >>>> >>>> >>>> [2] SlovenianFormatDataTest.java >>>> >>>> Thanks a lot! >>>> >>> >>> >> > > > -- > Best Regards, > > Deven -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/i18n-dev/attachments/20120524/1e4c966f/attachment.html From masayoshi.okutsu at oracle.com Thu May 24 00:48:53 2012 From: masayoshi.okutsu at oracle.com (Masayoshi Okutsu) Date: Thu, 24 May 2012 16:48:53 +0900 Subject: Incorrect TimeZone display name when DST not applicable / disabled In-Reply-To: <4FBDCCC4.4060505@linux.vnet.ibm.com> References: <4FA7948A.9090702@linux.vnet.ibm.com> <4FAD2DD4.1020306@oracle.com> <4FB3449F.9020409@linux.vnet.ibm.com> <4FB34CBF.20008@linux.vnet.ibm.com> <4FB3D15A.8090708@oracle.com> <4FB3D343.2050708@gmail.com> <4FB46AB8.6000207@linux.vnet.ibm.com> <4FBDCCC4.4060505@linux.vnet.ibm.com> Message-ID: <4FBDE7E5.1000103@oracle.com> As I stated before, your proposed fix is good because Windows XP doesn't use the Dynamic DST data. Thanks, Masayoshi On 5/24/2012 2:53 PM, Deven You wrote: > Hi masayoshi, > > Could you review Yoshito and my replies and see if it is good to you? > > Thanks a lot! > On 05/17/2012 11:04 AM, Deven You wrote: >> Hi Masayoshi, >> >> I think the workaround is good, but many customers may not know this >> fact and when they need change the timezone, they just select another >> time zone which does not support DST and ignore that the auto-adjust >> option should be checked first. >> >> To Yoshito, thanks for your information! >> >> On 05/17/2012 12:18 AM, Yoshito Umaoka wrote: >>> >>>> I thought Windows XP might (internally) use the Dynamic DST data in >>>> the Time Zones registry for supporting any DST rule changes, >>>> because Dynamic DST was introduced for the US DST rule change IIRC. >>>> But as far as I tested, XP seems to ignore Dynamic DST data. If >>>> that's the case, your proposed fix should be good. >>>> >>> >>> As far as I know, the dynamic DST data is used by Windows Vista/2003 >>> server or later Windows versions. >>> The registry data for dynamic DST is included in Windows XP time >>> zone updates, but not used by Windows XP. >>> >>> -Yoshito >>> >> >> > > From youdwei at linux.vnet.ibm.com Thu May 24 19:19:59 2012 From: youdwei at linux.vnet.ibm.com (Deven You) Date: Fri, 25 May 2012 10:19:59 +0800 Subject: Locale patch for Slovenian date format data: dots are missed in the datetime for Slovanian In-Reply-To: <4FBDCE90.1060808@oracle.com> References: <4F5454A3.6060907@linux.vnet.ibm.com> <4FB9F1AF.5000106@linux.vnet.ibm.com> <4FBA0A76.40209@oracle.com> <4FBDCC5B.1050501@linux.vnet.ibm.com> <4FBDCE90.1060808@oracle.com> Message-ID: <4FBEEC4F.9080905@linux.vnet.ibm.com> Hi Jffery, Thanks for your comments, I have updated the webrev[1], please review it! [1] http://cr.openjdk.java.net/~littlee/OJDK-126/webrev.02/ Thanks a lot! On 05/24/2012 02:00 PM, Yong Jeffrey Huang wrote: > Hi Daven, > > In FormatData_sl.java, the data are > > 134 "EEEE, dd. MMMM yyyy", // full date pattern > 135 "EEEE, dd. MMMM yyyy", // long date pattern > > I think they should be changed to > > "EEEE, dd. MMMM y", // full date pattern > "dd. MMMM y", // long date pattern > > the same as what in test file LocaleData. > > The change in LocaleData and LocaleDataTest.java are good. > > thanks for fixing the CR. > Yong > > On 2012/5/24 13:51, Deven You wrote: >> Hi Jeffrey, >> >> I have updated the webrev[1] according to your comments. Please >> review it. >> >> [1] http://cr.openjdk.java.net/~littlee/OJDK-126/webrev.00/ >> >> >> Thanks a lot! >> >> On 05/21/2012 05:27 PM, Yong Jeffrey Huang wrote: >>> Hi Daven, >>> >>> We use the format data in CLDR as the standard. Attached is the >>> sl.xml in CLDR. In your fix, it's better to be >>> "EEEE, dd. MMMM y", // full date pattern >>> "dd. MMMM y", // long date pattern >>> >>> Blow is the format defined in CLDR: >>> >>> - >>> - >>> EEEE, dd. MMMM y >>> >>> >>> - >>> - >>> dd. MMMM y >>> >>> >>> >>> For test case: >>> >>> To fix format data of one locale, you must modify corresponding >>> regression test: >>> >>> jdk/test/sun/text/resources/LocaleData: >>> In the end of the file, add >>> #bug xxxxxx >>> FormatData/sl/DateTimePatterns/4=EEEE, dd. MMMM y >>> FormatData/sl/DateTimePatterns/5=dd. MMMM y >>> >>> jdk/test/sun/text/resources/LocaleDataTest.java: >>> In the end of comments @bug, add the bug number. >>> >>> thanks, >>> Yong >>> >>> >>> On 2012/5/21 15:41, Deven You wrote: >>>> Hi All, >>>> >>>> I think this patch is simple and straight forward, is anyone >>>> interested in taking a look? >>>> >>>> Thanks a lot! >>>> >>>> On 03/05/2012 01:52 PM, Deven wrote: >>>>> Hi i18n-devs, >>>>> >>>>> I find there is a problem in Slovenian Locale. In Slovenian >>>>> Locale, days in a date must with a dot '.', like Oct 23rd 2011 >>>>> will be 23. oktober 2011. Without the '.', 23 oktober 2011 >>>>> basically means Twenty-three of October, instead of the >>>>> Twenty-third of October. >>>>> >>>>> Current oracle 6/7/8 all miss the dot '.', so this patch [1] will >>>>> add dot after the days to correct the date expression in Slovenian >>>>> Locale. >>>>> >>>>> The attached test case [2] shows the the diffrence with/without >>>>> this patch. The output of this test case are: >>>>> >>>>> without this patch: >>>>> Ponedeljek, 5 marec 2012 >>>>> >>>>> with this patch: >>>>> Ponedeljek, 5. marec 2012 >>>>> >>>>> This test case may not be very useful, so I hope anyone can give >>>>> me some suggestions about how to refine the test case? >>>>> >>>>> [1] >>>>> http://cr.openjdk.java.net/~youdwei/slovenian_formatData/webrev.00/ >>>>> >>>>> >>>>> [2] SlovenianFormatDataTest.java >>>>> >>>>> Thanks a lot! >>>>> >>>> >>>> >>> >> >> >> -- >> Best Regards, >> >> Deven > -- Best Regards, Deven -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/i18n-dev/attachments/20120525/207ce9ff/attachment.html From yong.huang at oracle.com Thu May 24 19:45:17 2012 From: yong.huang at oracle.com (Yong Jeffrey Huang) Date: Fri, 25 May 2012 10:45:17 +0800 Subject: Locale patch for Slovenian date format data: dots are missed in the datetime for Slovanian In-Reply-To: <4FBEEC4F.9080905@linux.vnet.ibm.com> References: <4F5454A3.6060907@linux.vnet.ibm.com> <4FB9F1AF.5000106@linux.vnet.ibm.com> <4FBA0A76.40209@oracle.com> <4FBDCC5B.1050501@linux.vnet.ibm.com> <4FBDCE90.1060808@oracle.com> <4FBEEC4F.9080905@linux.vnet.ibm.com> Message-ID: <4FBEF23D.9010502@oracle.com> It looks good to me. :-) thanks, Yong On 2012/5/25 10:19, Deven You wrote: > Hi Jffery, > > Thanks for your comments, I have updated the webrev[1], please review it! > > [1] http://cr.openjdk.java.net/~littlee/OJDK-126/webrev.02/ > > > Thanks a lot! > On 05/24/2012 02:00 PM, Yong Jeffrey Huang wrote: >> Hi Daven, >> >> In FormatData_sl.java, the data are >> >> 134 "EEEE, dd. MMMM yyyy", // full date pattern >> 135 "EEEE, dd. MMMM yyyy", // long date pattern >> >> I think they should be changed to >> >> "EEEE, dd. MMMM y", // full date pattern >> "dd. MMMM y", // long date pattern >> >> the same as what in test file LocaleData. >> >> The change in LocaleData and LocaleDataTest.java are good. >> >> thanks for fixing the CR. >> Yong >> >> On 2012/5/24 13:51, Deven You wrote: >>> Hi Jeffrey, >>> >>> I have updated the webrev[1] according to your comments. Please >>> review it. >>> >>> [1] http://cr.openjdk.java.net/~littlee/OJDK-126/webrev.00/ >>> >>> >>> Thanks a lot! >>> >>> On 05/21/2012 05:27 PM, Yong Jeffrey Huang wrote: >>>> Hi Daven, >>>> >>>> We use the format data in CLDR as the standard. Attached is the >>>> sl.xml in CLDR. In your fix, it's better to be >>>> "EEEE, dd. MMMM y", // full date pattern >>>> "dd. MMMM y", // long date pattern >>>> >>>> Blow is the format defined in CLDR: >>>> >>>> - >>>> - >>>> EEEE, dd. MMMM y >>>> >>>> >>>> - >>>> - >>>> dd. MMMM y >>>> >>>> >>>> >>>> For test case: >>>> >>>> To fix format data of one locale, you must modify corresponding >>>> regression test: >>>> >>>> jdk/test/sun/text/resources/LocaleData: >>>> In the end of the file, add >>>> #bug xxxxxx >>>> FormatData/sl/DateTimePatterns/4=EEEE, dd. MMMM y >>>> FormatData/sl/DateTimePatterns/5=dd. MMMM y >>>> >>>> jdk/test/sun/text/resources/LocaleDataTest.java: >>>> In the end of comments @bug, add the bug number. >>>> >>>> thanks, >>>> Yong >>>> >>>> >>>> On 2012/5/21 15:41, Deven You wrote: >>>>> Hi All, >>>>> >>>>> I think this patch is simple and straight forward, is anyone >>>>> interested in taking a look? >>>>> >>>>> Thanks a lot! >>>>> >>>>> On 03/05/2012 01:52 PM, Deven wrote: >>>>>> Hi i18n-devs, >>>>>> >>>>>> I find there is a problem in Slovenian Locale. In Slovenian >>>>>> Locale, days in a date must with a dot '.', like Oct 23rd 2011 >>>>>> will be 23. oktober 2011. Without the '.', 23 oktober 2011 >>>>>> basically means Twenty-three of October, instead of the >>>>>> Twenty-third of October. >>>>>> >>>>>> Current oracle 6/7/8 all miss the dot '.', so this patch [1] will >>>>>> add dot after the days to correct the date expression in >>>>>> Slovenian Locale. >>>>>> >>>>>> The attached test case [2] shows the the diffrence with/without >>>>>> this patch. The output of this test case are: >>>>>> >>>>>> without this patch: >>>>>> Ponedeljek, 5 marec 2012 >>>>>> >>>>>> with this patch: >>>>>> Ponedeljek, 5. marec 2012 >>>>>> >>>>>> This test case may not be very useful, so I hope anyone can give >>>>>> me some suggestions about how to refine the test case? >>>>>> >>>>>> [1] >>>>>> http://cr.openjdk.java.net/~youdwei/slovenian_formatData/webrev.00/ >>>>>> >>>>>> >>>>>> >>>>>> [2] SlovenianFormatDataTest.java >>>>>> >>>>>> Thanks a lot! >>>>>> >>>>> >>>>> >>>> >>> >>> >>> -- >>> Best Regards, >>> >>> Deven >> > > > -- > Best Regards, > > Deven -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/i18n-dev/attachments/20120525/542b2636/attachment.html From littlee at linux.vnet.ibm.com Thu May 24 23:40:05 2012 From: littlee at linux.vnet.ibm.com (Charles Lee) Date: Fri, 25 May 2012 14:40:05 +0800 Subject: Locale patch for Slovenian date format data: dots are missed in the datetime for Slovanian In-Reply-To: <4FBEEC4F.9080905@linux.vnet.ibm.com> References: <4F5454A3.6060907@linux.vnet.ibm.com> <4FB9F1AF.5000106@linux.vnet.ibm.com> <4FBA0A76.40209@oracle.com> <4FBDCC5B.1050501@linux.vnet.ibm.com> <4FBDCE90.1060808@oracle.com> <4FBEEC4F.9080905@linux.vnet.ibm.com> Message-ID: <4FBF2945.1060706@linux.vnet.ibm.com> Hi Deven, The patch is committed @ Changeset: 85696e57d447 Author: youdwei Date: 2012-05-25 14:32 +0800 URL:http://hg.openjdk.java.net/jdk8/tl/jdk/rev/85696e57d447 7171028: dots are missed in the datetime for Slovanian Reviewed-by: yhuang Please verify it and thank you all for reviewing. On 05/25/2012 10:19 AM, Deven You wrote: > Hi Jffery, > > Thanks for your comments, I have updated the webrev[1], please review it! > > [1] http://cr.openjdk.java.net/~littlee/OJDK-126/webrev.02/ > > > Thanks a lot! > On 05/24/2012 02:00 PM, Yong Jeffrey Huang wrote: >> Hi Daven, >> >> In FormatData_sl.java, the data are >> >> 134 "EEEE, dd. MMMM yyyy", // full date pattern >> 135 "EEEE, dd. MMMM yyyy", // long date pattern >> >> I think they should be changed to >> >> "EEEE, dd. MMMM y", // full date pattern >> "dd. MMMM y", // long date pattern >> >> the same as what in test file LocaleData. >> >> The change in LocaleData and LocaleDataTest.java are good. >> >> thanks for fixing the CR. >> Yong >> >> On 2012/5/24 13:51, Deven You wrote: >>> Hi Jeffrey, >>> >>> I have updated the webrev[1] according to your comments. Please >>> review it. >>> >>> [1] http://cr.openjdk.java.net/~littlee/OJDK-126/webrev.00/ >>> >>> >>> Thanks a lot! >>> >>> On 05/21/2012 05:27 PM, Yong Jeffrey Huang wrote: >>>> Hi Daven, >>>> >>>> We use the format data in CLDR as the standard. Attached is the >>>> sl.xml in CLDR. In your fix, it's better to be >>>> "EEEE, dd. MMMM y", // full date pattern >>>> "dd. MMMM y", // long date pattern >>>> >>>> Blow is the format defined in CLDR: >>>> >>>> - >>>> - >>>> EEEE, dd. MMMM y >>>> >>>> >>>> - >>>> - >>>> dd. MMMM y >>>> >>>> >>>> >>>> For test case: >>>> >>>> To fix format data of one locale, you must modify corresponding >>>> regression test: >>>> >>>> jdk/test/sun/text/resources/LocaleData: >>>> In the end of the file, add >>>> #bug xxxxxx >>>> FormatData/sl/DateTimePatterns/4=EEEE, dd. MMMM y >>>> FormatData/sl/DateTimePatterns/5=dd. MMMM y >>>> >>>> jdk/test/sun/text/resources/LocaleDataTest.java: >>>> In the end of comments @bug, add the bug number. >>>> >>>> thanks, >>>> Yong >>>> >>>> >>>> On 2012/5/21 15:41, Deven You wrote: >>>>> Hi All, >>>>> >>>>> I think this patch is simple and straight forward, is anyone >>>>> interested in taking a look? >>>>> >>>>> Thanks a lot! >>>>> >>>>> On 03/05/2012 01:52 PM, Deven wrote: >>>>>> Hi i18n-devs, >>>>>> >>>>>> I find there is a problem in Slovenian Locale. In Slovenian >>>>>> Locale, days in a date must with a dot '.', like Oct 23rd 2011 >>>>>> will be 23. oktober 2011. Without the '.', 23 oktober 2011 >>>>>> basically means Twenty-three of October, instead of the >>>>>> Twenty-third of October. >>>>>> >>>>>> Current oracle 6/7/8 all miss the dot '.', so this patch [1] will >>>>>> add dot after the days to correct the date expression in >>>>>> Slovenian Locale. >>>>>> >>>>>> The attached test case [2] shows the the diffrence with/without >>>>>> this patch. The output of this test case are: >>>>>> >>>>>> without this patch: >>>>>> Ponedeljek, 5 marec 2012 >>>>>> >>>>>> with this patch: >>>>>> Ponedeljek, 5. marec 2012 >>>>>> >>>>>> This test case may not be very useful, so I hope anyone can give >>>>>> me some suggestions about how to refine the test case? >>>>>> >>>>>> [1] >>>>>> http://cr.openjdk.java.net/~youdwei/slovenian_formatData/webrev.00/ >>>>>> >>>>>> >>>>>> >>>>>> [2] SlovenianFormatDataTest.java >>>>>> >>>>>> Thanks a lot! >>>>>> >>>>> >>>>> >>>> >>> >>> >>> -- >>> Best Regards, >>> >>> Deven >> > > > -- > Best Regards, > > Deven -- Yours Charles -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/i18n-dev/attachments/20120525/ec5bfb03/attachment-0001.html From littlee at linux.vnet.ibm.com Thu May 24 23:38:59 2012 From: littlee at linux.vnet.ibm.com (Charles Lee) Date: Fri, 25 May 2012 14:38:59 +0800 Subject: Incorrect TimeZone display name when DST not applicable / disabled In-Reply-To: <4FBDCCC4.4060505@linux.vnet.ibm.com> References: <4FA7948A.9090702@linux.vnet.ibm.com> <4FAD2DD4.1020306@oracle.com> <4FB3449F.9020409@linux.vnet.ibm.com> <4FB34CBF.20008@linux.vnet.ibm.com> <4FB3D15A.8090708@oracle.com> <4FB3D343.2050708@gmail.com> <4FB46AB8.6000207@linux.vnet.ibm.com> <4FBDCCC4.4060505@linux.vnet.ibm.com> Message-ID: <4FBF2903.9050503@linux.vnet.ibm.com> Hi Deven, The patch is committed @ Changeset: 71cf74329a9e Author: youdwei Date: 2012-05-25 13:28 +0800 URL:http://hg.openjdk.java.net/jdk8/tl/jdk/rev/71cf74329a9e 7094176: (tz) Incorrect TimeZone display name when DST not applicable / disabled Reviewed-by: okutsu Please verify it and thank you all for reviewing. On 05/24/2012 01:53 PM, Deven You wrote: > Hi masayoshi, > > Could you review Yoshito and my replies and see if it is good to you? > > Thanks a lot! > On 05/17/2012 11:04 AM, Deven You wrote: >> Hi Masayoshi, >> >> I think the workaround is good, but many customers may not know this >> fact and when they need change the timezone, they just select another >> time zone which does not support DST and ignore that the auto-adjust >> option should be checked first. >> >> To Yoshito, thanks for your information! >> >> On 05/17/2012 12:18 AM, Yoshito Umaoka wrote: >>> >>>> I thought Windows XP might (internally) use the Dynamic DST data in >>>> the Time Zones registry for supporting any DST rule changes, >>>> because Dynamic DST was introduced for the US DST rule change IIRC. >>>> But as far as I tested, XP seems to ignore Dynamic DST data. If >>>> that's the case, your proposed fix should be good. >>>> >>> >>> As far as I know, the dynamic DST data is used by Windows Vista/2003 >>> server or later Windows versions. >>> The registry data for dynamic DST is included in Windows XP time >>> zone updates, but not used by Windows XP. >>> >>> -Yoshito >>> >> >> > > -- Yours Charles From Alan.Bateman at oracle.com Fri May 25 00:27:04 2012 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 25 May 2012 08:27:04 +0100 Subject: hg: jdk8/tl/jdk: 7094176: (tz) Incorrect TimeZone display name when DST not applicable / disabled In-Reply-To: <20120525053212.D046D47505@hg.openjdk.java.net> References: <20120525053212.D046D47505@hg.openjdk.java.net> Message-ID: <4FBF3448.2050602@oracle.com> Deven, The test with this fix seems to be a manual test but doesn't seem to be tagged as such (/manual). I assume this means it will fail on all platforms. Do you mind re-examining it? Masayoshi may have some advice on how configuration like this can be tested. It may be that it's just not possible to test this in an automated way, in which case the path of least pain may be to just remove it. -Alan. On 25/05/2012 06:31, littlee at linux.vnet.ibm.com wrote: > Changeset: 71cf74329a9e > Author: youdwei > Date: 2012-05-25 13:28 +0800 > URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/71cf74329a9e > > 7094176: (tz) Incorrect TimeZone display name when DST not applicable / disabled > Reviewed-by: okutsu > > ! src/windows/native/java/util/TimeZone_md.c > + test/java/util/TimeZone/DstTzTest.java > From youdwei at linux.vnet.ibm.com Fri May 25 00:28:19 2012 From: youdwei at linux.vnet.ibm.com (Deven You) Date: Fri, 25 May 2012 15:28:19 +0800 Subject: Locale patch for Slovenian date format data: dots are missed in the datetime for Slovanian In-Reply-To: <4FBF2945.1060706@linux.vnet.ibm.com> References: <4F5454A3.6060907@linux.vnet.ibm.com> <4FB9F1AF.5000106@linux.vnet.ibm.com> <4FBA0A76.40209@oracle.com> <4FBDCC5B.1050501@linux.vnet.ibm.com> <4FBDCE90.1060808@oracle.com> <4FBEEC4F.9080905@linux.vnet.ibm.com> <4FBF2945.1060706@linux.vnet.ibm.com> Message-ID: <4FBF3493.9020305@linux.vnet.ibm.com> I have verified the change set. Thanks Jeffery and Charles! On 05/25/2012 02:40 PM, Charles Lee wrote: > Hi Deven, > > The patch is committed @ > Changeset: 85696e57d447 > Author: youdwei > Date: 2012-05-25 14:32 +0800 > URL:http://hg.openjdk.java.net/jdk8/tl/jdk/rev/85696e57d447 > > 7171028: dots are missed in the datetime for Slovanian > Reviewed-by: yhuang > > Please verify it and thank you all for reviewing. > > On 05/25/2012 10:19 AM, Deven You wrote: >> Hi Jffery, >> >> Thanks for your comments, I have updated the webrev[1], please review it! >> >> [1] http://cr.openjdk.java.net/~littlee/OJDK-126/webrev.02/ >> >> >> Thanks a lot! >> On 05/24/2012 02:00 PM, Yong Jeffrey Huang wrote: >>> Hi Daven, >>> >>> In FormatData_sl.java, the data are >>> >>> 134 "EEEE, dd. MMMM yyyy", // full date pattern >>> 135 "EEEE, dd. MMMM yyyy", // long date pattern >>> >>> I think they should be changed to >>> >>> "EEEE, dd. MMMM y", // full date pattern >>> "dd. MMMM y", // long date pattern >>> >>> the same as what in test file LocaleData. >>> >>> The change in LocaleData and LocaleDataTest.java are good. >>> >>> thanks for fixing the CR. >>> Yong >>> >>> On 2012/5/24 13:51, Deven You wrote: >>>> Hi Jeffrey, >>>> >>>> I have updated the webrev[1] according to your comments. Please >>>> review it. >>>> >>>> [1] http://cr.openjdk.java.net/~littlee/OJDK-126/webrev.00/ >>>> >>>> >>>> Thanks a lot! >>>> >>>> On 05/21/2012 05:27 PM, Yong Jeffrey Huang wrote: >>>>> Hi Daven, >>>>> >>>>> We use the format data in CLDR as the standard. Attached is the >>>>> sl.xml in CLDR. In your fix, it's better to be >>>>> "EEEE, dd. MMMM y", // full date pattern >>>>> "dd. MMMM y", // long date pattern >>>>> >>>>> Blow is the format defined in CLDR: >>>>> >>>>> - >>>>> - >>>>> EEEE, dd. MMMM y >>>>> >>>>> >>>>> - >>>>> - >>>>> dd. MMMM y >>>>> >>>>> >>>>> >>>>> For test case: >>>>> >>>>> To fix format data of one locale, you must modify corresponding >>>>> regression test: >>>>> >>>>> jdk/test/sun/text/resources/LocaleData: >>>>> In the end of the file, add >>>>> #bug xxxxxx >>>>> FormatData/sl/DateTimePatterns/4=EEEE, dd. MMMM y >>>>> FormatData/sl/DateTimePatterns/5=dd. MMMM y >>>>> >>>>> jdk/test/sun/text/resources/LocaleDataTest.java: >>>>> In the end of comments @bug, add the bug number. >>>>> >>>>> thanks, >>>>> Yong >>>>> >>>>> >>>>> On 2012/5/21 15:41, Deven You wrote: >>>>>> Hi All, >>>>>> >>>>>> I think this patch is simple and straight forward, is anyone >>>>>> interested in taking a look? >>>>>> >>>>>> Thanks a lot! >>>>>> >>>>>> On 03/05/2012 01:52 PM, Deven wrote: >>>>>>> Hi i18n-devs, >>>>>>> >>>>>>> I find there is a problem in Slovenian Locale. In Slovenian >>>>>>> Locale, days in a date must with a dot '.', like Oct 23rd 2011 >>>>>>> will be 23. oktober 2011. Without the '.', 23 oktober 2011 >>>>>>> basically means Twenty-three of October, instead of the >>>>>>> Twenty-third of October. >>>>>>> >>>>>>> Current oracle 6/7/8 all miss the dot '.', so this patch [1] >>>>>>> will add dot after the days to correct the date expression in >>>>>>> Slovenian Locale. >>>>>>> >>>>>>> The attached test case [2] shows the the diffrence with/without >>>>>>> this patch. The output of this test case are: >>>>>>> >>>>>>> without this patch: >>>>>>> Ponedeljek, 5 marec 2012 >>>>>>> >>>>>>> with this patch: >>>>>>> Ponedeljek, 5. marec 2012 >>>>>>> >>>>>>> This test case may not be very useful, so I hope anyone can give >>>>>>> me some suggestions about how to refine the test case? >>>>>>> >>>>>>> [1] >>>>>>> http://cr.openjdk.java.net/~youdwei/slovenian_formatData/webrev.00/ >>>>>>> >>>>>>> >>>>>>> >>>>>>> [2] SlovenianFormatDataTest.java >>>>>>> >>>>>>> Thanks a lot! >>>>>>> >>>>>> >>>>>> >>>>> >>>> >>>> >>>> -- >>>> Best Regards, >>>> >>>> Deven >>> >> >> >> -- >> Best Regards, >> >> Deven > > > -- > Yours Charles -- Best Regards, Deven -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/i18n-dev/attachments/20120525/54dba531/attachment.html From youdwei at linux.vnet.ibm.com Fri May 25 00:28:19 2012 From: youdwei at linux.vnet.ibm.com (Deven You) Date: Fri, 25 May 2012 15:28:19 +0800 Subject: Locale patch for Slovenian date format data: dots are missed in the datetime for Slovanian In-Reply-To: <4FBF2945.1060706@linux.vnet.ibm.com> References: <4F5454A3.6060907@linux.vnet.ibm.com> <4FB9F1AF.5000106@linux.vnet.ibm.com> <4FBA0A76.40209@oracle.com> <4FBDCC5B.1050501@linux.vnet.ibm.com> <4FBDCE90.1060808@oracle.com> <4FBEEC4F.9080905@linux.vnet.ibm.com> <4FBF2945.1060706@linux.vnet.ibm.com> Message-ID: <4FBF3493.9020305@linux.vnet.ibm.com> I have verified the change set. Thanks Jeffery and Charles! On 05/25/2012 02:40 PM, Charles Lee wrote: > Hi Deven, > > The patch is committed @ > Changeset: 85696e57d447 > Author: youdwei > Date: 2012-05-25 14:32 +0800 > URL:http://hg.openjdk.java.net/jdk8/tl/jdk/rev/85696e57d447 > > 7171028: dots are missed in the datetime for Slovanian > Reviewed-by: yhuang > > Please verify it and thank you all for reviewing. > > On 05/25/2012 10:19 AM, Deven You wrote: >> Hi Jffery, >> >> Thanks for your comments, I have updated the webrev[1], please review it! >> >> [1] http://cr.openjdk.java.net/~littlee/OJDK-126/webrev.02/ >> >> >> Thanks a lot! >> On 05/24/2012 02:00 PM, Yong Jeffrey Huang wrote: >>> Hi Daven, >>> >>> In FormatData_sl.java, the data are >>> >>> 134 "EEEE, dd. MMMM yyyy", // full date pattern >>> 135 "EEEE, dd. MMMM yyyy", // long date pattern >>> >>> I think they should be changed to >>> >>> "EEEE, dd. MMMM y", // full date pattern >>> "dd. MMMM y", // long date pattern >>> >>> the same as what in test file LocaleData. >>> >>> The change in LocaleData and LocaleDataTest.java are good. >>> >>> thanks for fixing the CR. >>> Yong >>> >>> On 2012/5/24 13:51, Deven You wrote: >>>> Hi Jeffrey, >>>> >>>> I have updated the webrev[1] according to your comments. Please >>>> review it. >>>> >>>> [1] http://cr.openjdk.java.net/~littlee/OJDK-126/webrev.00/ >>>> >>>> >>>> Thanks a lot! >>>> >>>> On 05/21/2012 05:27 PM, Yong Jeffrey Huang wrote: >>>>> Hi Daven, >>>>> >>>>> We use the format data in CLDR as the standard. Attached is the >>>>> sl.xml in CLDR. In your fix, it's better to be >>>>> "EEEE, dd. MMMM y", // full date pattern >>>>> "dd. MMMM y", // long date pattern >>>>> >>>>> Blow is the format defined in CLDR: >>>>> >>>>> - >>>>> - >>>>> EEEE, dd. MMMM y >>>>> >>>>> >>>>> - >>>>> - >>>>> dd. MMMM y >>>>> >>>>> >>>>> >>>>> For test case: >>>>> >>>>> To fix format data of one locale, you must modify corresponding >>>>> regression test: >>>>> >>>>> jdk/test/sun/text/resources/LocaleData: >>>>> In the end of the file, add >>>>> #bug xxxxxx >>>>> FormatData/sl/DateTimePatterns/4=EEEE, dd. MMMM y >>>>> FormatData/sl/DateTimePatterns/5=dd. MMMM y >>>>> >>>>> jdk/test/sun/text/resources/LocaleDataTest.java: >>>>> In the end of comments @bug, add the bug number. >>>>> >>>>> thanks, >>>>> Yong >>>>> >>>>> >>>>> On 2012/5/21 15:41, Deven You wrote: >>>>>> Hi All, >>>>>> >>>>>> I think this patch is simple and straight forward, is anyone >>>>>> interested in taking a look? >>>>>> >>>>>> Thanks a lot! >>>>>> >>>>>> On 03/05/2012 01:52 PM, Deven wrote: >>>>>>> Hi i18n-devs, >>>>>>> >>>>>>> I find there is a problem in Slovenian Locale. In Slovenian >>>>>>> Locale, days in a date must with a dot '.', like Oct 23rd 2011 >>>>>>> will be 23. oktober 2011. Without the '.', 23 oktober 2011 >>>>>>> basically means Twenty-three of October, instead of the >>>>>>> Twenty-third of October. >>>>>>> >>>>>>> Current oracle 6/7/8 all miss the dot '.', so this patch [1] >>>>>>> will add dot after the days to correct the date expression in >>>>>>> Slovenian Locale. >>>>>>> >>>>>>> The attached test case [2] shows the the diffrence with/without >>>>>>> this patch. The output of this test case are: >>>>>>> >>>>>>> without this patch: >>>>>>> Ponedeljek, 5 marec 2012 >>>>>>> >>>>>>> with this patch: >>>>>>> Ponedeljek, 5. marec 2012 >>>>>>> >>>>>>> This test case may not be very useful, so I hope anyone can give >>>>>>> me some suggestions about how to refine the test case? >>>>>>> >>>>>>> [1] >>>>>>> http://cr.openjdk.java.net/~youdwei/slovenian_formatData/webrev.00/ >>>>>>> >>>>>>> >>>>>>> >>>>>>> [2] SlovenianFormatDataTest.java >>>>>>> >>>>>>> Thanks a lot! >>>>>>> >>>>>> >>>>>> >>>>> >>>> >>>> >>>> -- >>>> Best Regards, >>>> >>>> Deven >>> >> >> >> -- >> Best Regards, >> >> Deven > > > -- > Yours Charles -- Best Regards, Deven -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/i18n-dev/attachments/20120525/54dba531/attachment-0003.html From youdwei at linux.vnet.ibm.com Fri May 25 00:41:25 2012 From: youdwei at linux.vnet.ibm.com (Deven You) Date: Fri, 25 May 2012 15:41:25 +0800 Subject: hg: jdk8/tl/jdk: 7094176: (tz) Incorrect TimeZone display name when DST not applicable / disabled In-Reply-To: <4FBF3448.2050602@oracle.com> References: <20120525053212.D046D47505@hg.openjdk.java.net> <4FBF3448.2050602@oracle.com> Message-ID: <4FBF37A5.1060705@linux.vnet.ibm.com> Hi Alan, Thanks for your reminder, I was going to point that this a manual test case and need someone guide me how to configure it as manual with jtreg. But I missed it by chance. So Masayoshi or someone else, I'd very appreciate if you could guide me how to configure a test case as manual in the jtreg? Thanks a lot! On 05/25/2012 03:27 PM, Alan Bateman wrote: > Deven, > > The test with this fix seems to be a manual test but doesn't seem to > be tagged as such (/manual). I assume this means it will fail on all > platforms. Do you mind re-examining it? Masayoshi may have some advice > on how configuration like this can be tested. It may be that it's just > not possible to test this in an automated way, in which case the path > of least pain may be to just remove it. > > -Alan. > > On 25/05/2012 06:31, littlee at linux.vnet.ibm.com wrote: >> Changeset: 71cf74329a9e >> Author: youdwei >> Date: 2012-05-25 13:28 +0800 >> URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/71cf74329a9e >> >> 7094176: (tz) Incorrect TimeZone display name when DST not applicable >> / disabled >> Reviewed-by: okutsu >> >> ! src/windows/native/java/util/TimeZone_md.c >> + test/java/util/TimeZone/DstTzTest.java >> > -- Best Regards, Deven From masayoshi.okutsu at oracle.com Fri May 25 02:32:37 2012 From: masayoshi.okutsu at oracle.com (Masayoshi Okutsu) Date: Fri, 25 May 2012 18:32:37 +0900 Subject: hg: jdk8/tl/jdk: 7094176: (tz) Incorrect TimeZone display name when DST not applicable / disabled In-Reply-To: <4FBF37A5.1060705@linux.vnet.ibm.com> References: <20120525053212.D046D47505@hg.openjdk.java.net> <4FBF3448.2050602@oracle.com> <4FBF37A5.1060705@linux.vnet.ibm.com> Message-ID: <4FBF51B5.8020908@oracle.com> Hi Deven, Sorry. I didn't review the test case... You can use applet to write a manual test. You will find some manual tests under test/java/awt such as: test/java/awt/TextField/ScrollSelectionTest/ScrollSelectionTest.{html,java} Thanks, Masayoshi On 5/25/2012 4:41 PM, Deven You wrote: > Hi Alan, > > Thanks for your reminder, I was going to point that this a manual test > case and need someone guide me how to configure it as manual with > jtreg. But I missed it by chance. > > So Masayoshi or someone else, I'd very appreciate if you could guide > me how to configure a test case as manual in the jtreg? > > Thanks a lot! > > On 05/25/2012 03:27 PM, Alan Bateman wrote: >> Deven, >> >> The test with this fix seems to be a manual test but doesn't seem to >> be tagged as such (/manual). I assume this means it will fail on all >> platforms. Do you mind re-examining it? Masayoshi may have some >> advice on how configuration like this can be tested. It may be that >> it's just not possible to test this in an automated way, in which >> case the path of least pain may be to just remove it. >> >> -Alan. >> >> On 25/05/2012 06:31, littlee at linux.vnet.ibm.com wrote: >>> Changeset: 71cf74329a9e >>> Author: youdwei >>> Date: 2012-05-25 13:28 +0800 >>> URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/71cf74329a9e >>> >>> 7094176: (tz) Incorrect TimeZone display name when DST not >>> applicable / disabled >>> Reviewed-by: okutsu >>> >>> ! src/windows/native/java/util/TimeZone_md.c >>> + test/java/util/TimeZone/DstTzTest.java >>> >> > > From Alan.Bateman at oracle.com Fri May 25 02:37:17 2012 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 25 May 2012 10:37:17 +0100 Subject: hg: jdk8/tl/jdk: 7094176: (tz) Incorrect TimeZone display name when DST not applicable / disabled In-Reply-To: <4FBF51B5.8020908@oracle.com> References: <20120525053212.D046D47505@hg.openjdk.java.net> <4FBF3448.2050602@oracle.com> <4FBF37A5.1060705@linux.vnet.ibm.com> <4FBF51B5.8020908@oracle.com> Message-ID: <4FBF52CD.6060706@oracle.com> On 25/05/2012 10:32, Masayoshi Okutsu wrote: > Hi Deven, > > Sorry. I didn't review the test case... > > You can use applet to write a manual test. You will find some manual > tests under test/java/awt such as: > > test/java/awt/TextField/ScrollSelectionTest/ScrollSelectionTest.{html,java} > > > Thanks, > Masayoshi Masayoshi - I think we need to strongly discourage adding any manual tests to the java/util/ tree. -Alan. From youdwei at linux.vnet.ibm.com Fri May 25 00:28:19 2012 From: youdwei at linux.vnet.ibm.com (Deven You) Date: Fri, 25 May 2012 15:28:19 +0800 Subject: Locale patch for Slovenian date format data: dots are missed in the datetime for Slovanian In-Reply-To: <4FBF2945.1060706@linux.vnet.ibm.com> References: <4F5454A3.6060907@linux.vnet.ibm.com> <4FB9F1AF.5000106@linux.vnet.ibm.com> <4FBA0A76.40209@oracle.com> <4FBDCC5B.1050501@linux.vnet.ibm.com> <4FBDCE90.1060808@oracle.com> <4FBEEC4F.9080905@linux.vnet.ibm.com> <4FBF2945.1060706@linux.vnet.ibm.com> Message-ID: <4FBF3493.9020305@linux.vnet.ibm.com> I have verified the change set. Thanks Jeffery and Charles! On 05/25/2012 02:40 PM, Charles Lee wrote: > Hi Deven, > > The patch is committed @ > Changeset: 85696e57d447 > Author: youdwei > Date: 2012-05-25 14:32 +0800 > URL:http://hg.openjdk.java.net/jdk8/tl/jdk/rev/85696e57d447 > > 7171028: dots are missed in the datetime for Slovanian > Reviewed-by: yhuang > > Please verify it and thank you all for reviewing. > > On 05/25/2012 10:19 AM, Deven You wrote: >> Hi Jffery, >> >> Thanks for your comments, I have updated the webrev[1], please review it! >> >> [1] http://cr.openjdk.java.net/~littlee/OJDK-126/webrev.02/ >> >> >> Thanks a lot! >> On 05/24/2012 02:00 PM, Yong Jeffrey Huang wrote: >>> Hi Daven, >>> >>> In FormatData_sl.java, the data are >>> >>> 134 "EEEE, dd. MMMM yyyy", // full date pattern >>> 135 "EEEE, dd. MMMM yyyy", // long date pattern >>> >>> I think they should be changed to >>> >>> "EEEE, dd. MMMM y", // full date pattern >>> "dd. MMMM y", // long date pattern >>> >>> the same as what in test file LocaleData. >>> >>> The change in LocaleData and LocaleDataTest.java are good. >>> >>> thanks for fixing the CR. >>> Yong >>> >>> On 2012/5/24 13:51, Deven You wrote: >>>> Hi Jeffrey, >>>> >>>> I have updated the webrev[1] according to your comments. Please >>>> review it. >>>> >>>> [1] http://cr.openjdk.java.net/~littlee/OJDK-126/webrev.00/ >>>> >>>> >>>> Thanks a lot! >>>> >>>> On 05/21/2012 05:27 PM, Yong Jeffrey Huang wrote: >>>>> Hi Daven, >>>>> >>>>> We use the format data in CLDR as the standard. Attached is the >>>>> sl.xml in CLDR. In your fix, it's better to be >>>>> "EEEE, dd. MMMM y", // full date pattern >>>>> "dd. MMMM y", // long date pattern >>>>> >>>>> Blow is the format defined in CLDR: >>>>> >>>>> - >>>>> - >>>>> EEEE, dd. MMMM y >>>>> >>>>> >>>>> - >>>>> - >>>>> dd. MMMM y >>>>> >>>>> >>>>> >>>>> For test case: >>>>> >>>>> To fix format data of one locale, you must modify corresponding >>>>> regression test: >>>>> >>>>> jdk/test/sun/text/resources/LocaleData: >>>>> In the end of the file, add >>>>> #bug xxxxxx >>>>> FormatData/sl/DateTimePatterns/4=EEEE, dd. MMMM y >>>>> FormatData/sl/DateTimePatterns/5=dd. MMMM y >>>>> >>>>> jdk/test/sun/text/resources/LocaleDataTest.java: >>>>> In the end of comments @bug, add the bug number. >>>>> >>>>> thanks, >>>>> Yong >>>>> >>>>> >>>>> On 2012/5/21 15:41, Deven You wrote: >>>>>> Hi All, >>>>>> >>>>>> I think this patch is simple and straight forward, is anyone >>>>>> interested in taking a look? >>>>>> >>>>>> Thanks a lot! >>>>>> >>>>>> On 03/05/2012 01:52 PM, Deven wrote: >>>>>>> Hi i18n-devs, >>>>>>> >>>>>>> I find there is a problem in Slovenian Locale. In Slovenian >>>>>>> Locale, days in a date must with a dot '.', like Oct 23rd 2011 >>>>>>> will be 23. oktober 2011. Without the '.', 23 oktober 2011 >>>>>>> basically means Twenty-three of October, instead of the >>>>>>> Twenty-third of October. >>>>>>> >>>>>>> Current oracle 6/7/8 all miss the dot '.', so this patch [1] >>>>>>> will add dot after the days to correct the date expression in >>>>>>> Slovenian Locale. >>>>>>> >>>>>>> The attached test case [2] shows the the diffrence with/without >>>>>>> this patch. The output of this test case are: >>>>>>> >>>>>>> without this patch: >>>>>>> Ponedeljek, 5 marec 2012 >>>>>>> >>>>>>> with this patch: >>>>>>> Ponedeljek, 5. marec 2012 >>>>>>> >>>>>>> This test case may not be very useful, so I hope anyone can give >>>>>>> me some suggestions about how to refine the test case? >>>>>>> >>>>>>> [1] >>>>>>> http://cr.openjdk.java.net/~youdwei/slovenian_formatData/webrev.00/ >>>>>>> >>>>>>> >>>>>>> >>>>>>> [2] SlovenianFormatDataTest.java >>>>>>> >>>>>>> Thanks a lot! >>>>>>> >>>>>> >>>>>> >>>>> >>>> >>>> >>>> -- >>>> Best Regards, >>>> >>>> Deven >>> >> >> >> -- >> Best Regards, >> >> Deven > > > -- > Yours Charles -- Best Regards, Deven -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/i18n-dev/attachments/20120525/54dba531/attachment-0004.html From masayoshi.okutsu at oracle.com Fri May 25 03:05:30 2012 From: masayoshi.okutsu at oracle.com (Masayoshi Okutsu) Date: Fri, 25 May 2012 19:05:30 +0900 Subject: hg: jdk8/tl/jdk: 7094176: (tz) Incorrect TimeZone display name when DST not applicable / disabled In-Reply-To: <4FBF52CD.6060706@oracle.com> References: <20120525053212.D046D47505@hg.openjdk.java.net> <4FBF3448.2050602@oracle.com> <4FBF37A5.1060705@linux.vnet.ibm.com> <4FBF51B5.8020908@oracle.com> <4FBF52CD.6060706@oracle.com> Message-ID: <4FBF596A.4080300@oracle.com> On 5/25/2012 6:37 PM, Alan Bateman wrote: > On 25/05/2012 10:32, Masayoshi Okutsu wrote: >> Hi Deven, >> >> Sorry. I didn't review the test case... >> >> You can use applet to write a manual test. You will find some manual >> tests under test/java/awt such as: >> >> test/java/awt/TextField/ScrollSelectionTest/ScrollSelectionTest.{html,java} >> >> >> Thanks, >> Masayoshi > Masayoshi - I think we need to strongly discourage adding any manual > tests to the java/util/ tree. Another option would be to write a native program to change the system setup and run a Java program to detect the change. But it requires the administrator privilege and is a bit risky. A test failure may leave a test machine in an unusual state. Any other options? Thanks, Masayoshi From Alan.Bateman at oracle.com Fri May 25 03:53:31 2012 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 25 May 2012 11:53:31 +0100 Subject: hg: jdk8/tl/jdk: 7094176: (tz) Incorrect TimeZone display name when DST not applicable / disabled In-Reply-To: <4FBF596A.4080300@oracle.com> References: <20120525053212.D046D47505@hg.openjdk.java.net> <4FBF3448.2050602@oracle.com> <4FBF37A5.1060705@linux.vnet.ibm.com> <4FBF51B5.8020908@oracle.com> <4FBF52CD.6060706@oracle.com> <4FBF596A.4080300@oracle.com> Message-ID: <4FBF64AB.7000609@oracle.com> On 25/05/2012 11:05, Masayoshi Okutsu wrote: > > Another option would be to write a native program to change the system > setup and run a Java program to detect the change. But it requires the > administrator privilege and is a bit risky. A test failure may leave a > test machine in an unusual state. > > Any other options? Changing the system configuration would also likely cause problems when running tests concurrently. I think the only option is to just remove the test. -Alan. From youdwei at linux.vnet.ibm.com Fri May 25 00:28:19 2012 From: youdwei at linux.vnet.ibm.com (Deven You) Date: Fri, 25 May 2012 15:28:19 +0800 Subject: Locale patch for Slovenian date format data: dots are missed in the datetime for Slovanian In-Reply-To: <4FBF2945.1060706@linux.vnet.ibm.com> References: <4F5454A3.6060907@linux.vnet.ibm.com> <4FB9F1AF.5000106@linux.vnet.ibm.com> <4FBA0A76.40209@oracle.com> <4FBDCC5B.1050501@linux.vnet.ibm.com> <4FBDCE90.1060808@oracle.com> <4FBEEC4F.9080905@linux.vnet.ibm.com> <4FBF2945.1060706@linux.vnet.ibm.com> Message-ID: <4FBF3493.9020305@linux.vnet.ibm.com> I have verified the change set. Thanks Jeffery and Charles! On 05/25/2012 02:40 PM, Charles Lee wrote: > Hi Deven, > > The patch is committed @ > Changeset: 85696e57d447 > Author: youdwei > Date: 2012-05-25 14:32 +0800 > URL:http://hg.openjdk.java.net/jdk8/tl/jdk/rev/85696e57d447 > > 7171028: dots are missed in the datetime for Slovanian > Reviewed-by: yhuang > > Please verify it and thank you all for reviewing. > > On 05/25/2012 10:19 AM, Deven You wrote: >> Hi Jffery, >> >> Thanks for your comments, I have updated the webrev[1], please review it! >> >> [1] http://cr.openjdk.java.net/~littlee/OJDK-126/webrev.02/ >> >> >> Thanks a lot! >> On 05/24/2012 02:00 PM, Yong Jeffrey Huang wrote: >>> Hi Daven, >>> >>> In FormatData_sl.java, the data are >>> >>> 134 "EEEE, dd. MMMM yyyy", // full date pattern >>> 135 "EEEE, dd. MMMM yyyy", // long date pattern >>> >>> I think they should be changed to >>> >>> "EEEE, dd. MMMM y", // full date pattern >>> "dd. MMMM y", // long date pattern >>> >>> the same as what in test file LocaleData. >>> >>> The change in LocaleData and LocaleDataTest.java are good. >>> >>> thanks for fixing the CR. >>> Yong >>> >>> On 2012/5/24 13:51, Deven You wrote: >>>> Hi Jeffrey, >>>> >>>> I have updated the webrev[1] according to your comments. Please >>>> review it. >>>> >>>> [1] http://cr.openjdk.java.net/~littlee/OJDK-126/webrev.00/ >>>> >>>> >>>> Thanks a lot! >>>> >>>> On 05/21/2012 05:27 PM, Yong Jeffrey Huang wrote: >>>>> Hi Daven, >>>>> >>>>> We use the format data in CLDR as the standard. Attached is the >>>>> sl.xml in CLDR. In your fix, it's better to be >>>>> "EEEE, dd. MMMM y", // full date pattern >>>>> "dd. MMMM y", // long date pattern >>>>> >>>>> Blow is the format defined in CLDR: >>>>> >>>>> - >>>>> - >>>>> EEEE, dd. MMMM y >>>>> >>>>> >>>>> - >>>>> - >>>>> dd. MMMM y >>>>> >>>>> >>>>> >>>>> For test case: >>>>> >>>>> To fix format data of one locale, you must modify corresponding >>>>> regression test: >>>>> >>>>> jdk/test/sun/text/resources/LocaleData: >>>>> In the end of the file, add >>>>> #bug xxxxxx >>>>> FormatData/sl/DateTimePatterns/4=EEEE, dd. MMMM y >>>>> FormatData/sl/DateTimePatterns/5=dd. MMMM y >>>>> >>>>> jdk/test/sun/text/resources/LocaleDataTest.java: >>>>> In the end of comments @bug, add the bug number. >>>>> >>>>> thanks, >>>>> Yong >>>>> >>>>> >>>>> On 2012/5/21 15:41, Deven You wrote: >>>>>> Hi All, >>>>>> >>>>>> I think this patch is simple and straight forward, is anyone >>>>>> interested in taking a look? >>>>>> >>>>>> Thanks a lot! >>>>>> >>>>>> On 03/05/2012 01:52 PM, Deven wrote: >>>>>>> Hi i18n-devs, >>>>>>> >>>>>>> I find there is a problem in Slovenian Locale. In Slovenian >>>>>>> Locale, days in a date must with a dot '.', like Oct 23rd 2011 >>>>>>> will be 23. oktober 2011. Without the '.', 23 oktober 2011 >>>>>>> basically means Twenty-three of October, instead of the >>>>>>> Twenty-third of October. >>>>>>> >>>>>>> Current oracle 6/7/8 all miss the dot '.', so this patch [1] >>>>>>> will add dot after the days to correct the date expression in >>>>>>> Slovenian Locale. >>>>>>> >>>>>>> The attached test case [2] shows the the diffrence with/without >>>>>>> this patch. The output of this test case are: >>>>>>> >>>>>>> without this patch: >>>>>>> Ponedeljek, 5 marec 2012 >>>>>>> >>>>>>> with this patch: >>>>>>> Ponedeljek, 5. marec 2012 >>>>>>> >>>>>>> This test case may not be very useful, so I hope anyone can give >>>>>>> me some suggestions about how to refine the test case? >>>>>>> >>>>>>> [1] >>>>>>> http://cr.openjdk.java.net/~youdwei/slovenian_formatData/webrev.00/ >>>>>>> >>>>>>> >>>>>>> >>>>>>> [2] SlovenianFormatDataTest.java >>>>>>> >>>>>>> Thanks a lot! >>>>>>> >>>>>> >>>>>> >>>>> >>>> >>>> >>>> -- >>>> Best Regards, >>>> >>>> Deven >>> >> >> >> -- >> Best Regards, >> >> Deven > > > -- > Yours Charles -- Best Regards, Deven -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/i18n-dev/attachments/20120525/54dba531/attachment-0006.html From dawid.weiss at gmail.com Sun May 27 05:28:13 2012 From: dawid.weiss at gmail.com (Dawid Weiss) Date: Sun, 27 May 2012 14:28:13 +0200 Subject: Empty regexp replaceall and surrogate pairs results in corrupted utf16 Message-ID: Hi, I'm a committer to the Apache Lucene project. We have randomized tests and we hit the following (simplified) scenario: String s1 = "AB\uD840\uDC00C"; String s2 = s1.replaceAll("", "X"); the input contains an extended unicode character (any surrogate pair will do). The pattern is an empty string (in fact, it was randomized as "]|" but it's the same problem so I omit the details). The problem is that after applying this pattern, replaceAll inserts X in between the surrogate pair characters and this results in invalid UTF-16: AB??C XAXBX?X?XCX Is this a bug (where should I file it) or is this something that is an inherent feature of the current implementation? Thanks, Dawid From xueming.shen at oracle.com Tue May 29 23:12:03 2012 From: xueming.shen at oracle.com (Xueming Shen) Date: Tue, 29 May 2012 23:12:03 -0700 Subject: Fwd: Some differences on Window UDC area In-Reply-To: <4FBC99C9.7080508@linux.vnet.ibm.com> References: <4D8FEFCC.50002@linux.vnet.ibm.com> <4D8FF4AB.2030306@oracle.com> <4D9000B7.8080504@linux.vnet.ibm.com> <4D90A40C.6090802@oracle.com> <4D918382.7070905@linux.vnet.ibm.com> <4FBC99C9.7080508@linux.vnet.ibm.com> Message-ID: <4FC5BA33.2000507@oracle.com> Hi Charles, The MS936 charset is long overdue for a update. See CR#6183404. The mapping need to be re-generated from MS's latest 936 table (not, MS936 should just follow MS's mapping table, not GB18030) As noted in MS936.map, the existing mapping table uses 1894 entries from GBK UDC block for EUDC mapping, as suggested by IBM engineer back to 1999, which was a reasonable approach back then. I will try to generate a new MS936 for JDK8. -Sherman On 5/23/2012 1:03 AM, Charles Lee wrote: > Hi guys, > > We have a simple test case: > > for (String cname : new String[] { "GBK", "MS936", "GB18030" }) { > Charset charset = Charset.forName(cname); > System.out.println("charset: " + charset.name()); > CharsetEncoder ce = charset.newEncoder(); > char[] chars = new char[] { 0xE585, 0xE586, 0xE592 }; > CharBuffer cb = CharBuffer.wrap(chars); > ByteBuffer bb = ce.encode(cb); > > for (char c : chars) { > System.out.printf("\\u%04x", (int) c); > } > System.out.print(" -> "); > > for (byte b : bb.array()) > if (b != 0x0) { > System.out.printf("\\x%02x", (int) b & 0xFF); > } > System.out.println(""); > } > > The output is > charset: GBK > \ue585\ue586\ue592 -> \xa2\xa0\xa2\xab\xa3\x40 > charset: x-mswin-936 > \ue585\ue586\ue592 -> \xa2\xa0\xa2\xab\xa3\x40 > charset: GB18030 > \ue585\ue586\ue592 -> \xa2\xa0\xa3\x40\xa3\x4c > > From the msdn[1], U+E000 -> U+F8FF is in the EUDC scope. So U+E586 is > in the EUDC scope. But the mapped code in MS936/GBK is 0xA2AB, it is > not in the EUDC scope. > With another simple test case, you can find there are more codes that > is not mapped right: > > for (int i = 0xE000; i < 0xE000 + 1894; i++) { > String s = new String(new char[] { (char) i }); > byte[] bs = s.getBytes("MS936"); > int b0 = (int) bs[0] & 0xFF; > int b1 = (int) bs[1] & 0xFF; > if ((b0 >= 0xAA && b0 <= 0xAF) && (b1 >= 0xA1 && b1 <= 0xFE)) > continue; > if ((b0 >= 0xF8 && b0 <= 0xFE) && (b1 >= 0xA1 && b1 <= 0xFE)) > continue; > if ((b0 >= 0xA1 && b0 <= 0xA7) && (b1 >= 0x40 && b1 <= 0xA0)) > continue; > System.out.printf("\\u%04X -> \\x%02X\\x%02X%n", i, b0, b1); > } > > > I have written a generator in C#[2] which outputs the mapping code in > GB2312[3] and GB18030[4] in scope U+E000 and U+F8FF to find that most > of code are the same. Hereby I suggest we may follow the code from > GB2312 and the changed map file in openjdk can be found [5][6]. > > Would anyone help to take a look on this issue? > > > > [1] > http://msdn.microsoft.com/en-us/library/windows/desktop/dd317837%28v=vs.85%29.aspx > [2] http://cr.openjdk.java.net/~littlee/OJDK-63/webrev.00/Program.cs > [3] http://cr.openjdk.java.net/~littlee/OJDK-63/webrev.00/gb2312Map.txt > [4] http://cr.openjdk.java.net/~littlee/OJDK-63/webrev.00/gb18030Map.txt > [5] http://cr.openjdk.java.net/~littlee/OJDK-63/webrev.00/GBK.map.new > [6] http://cr.openjdk.java.net/~littlee/OJDK-63/webrev.00/MS936.map.new > > P.S: Sorry for the late notice. > > > On 03/29/2011 03:00 PM, Charles Lee wrote: >> On 03/28/2011 11:06 PM, Alan Bateman wrote: >>> Charles Lee wrote: >>>> : >>>> >>>> It looks similar. How can I find the patch quickly? I notice it >>>> says "the list is attached to this CR". Is it CR-6183404? Since cr >>>> has the pattern cr.openjdk.java.net/~username/id, how can I know >>>> who is the committer to this CR? >>> cr.openjdk.java.net is the place where we push webrevs when a patch >>> is out for review. I don't think this one is one anyone's list for >>> jdk7 and the list attached to the bug is likely the list of >>> incorrect mappings. If this is fixed then I assume the fix will >>> update the mappings in jdk/make/tools/CharsetMapping/MS936.map. >>> >>> -Alan >> I have output more bytes[1] to see whether other bytes are encoded >> correctly. But unfortunately it is not. It is kind of like, on >> windows, using ms936, PUA of ms936 use the PUA of gb18030. In >> wikipedia, it says gb18030 is compatible with gbk which ms936 >> implemented. Can we conclude that ms936 should follow the gb18030's >> behavior? >> >> >> [1] 0xE585, 0xE586, 0xE587, 0xE588, 0xE589, 0xE58a, 0xE58b, 0xE58c, >> 0xE58d, 0xE58e, 0xE58f, 0xE590, 0xE591, 0xE592, 0xE593, 0xE594, >> 0xE595, 0xE596, 0xE597, 0xE598, 0xE599, 0xE59a, 0xE59b, 0xE59c, >> 0xE59d, 0xE59e, 0xe79f. >> Using MS936 charset, we expect: >> \xa2\xa0\xa3\x40\xa3\x41\xa3\x42\xa3\x43\xa3\x44\xa3\x45\xa3\x46\xa3\x47\xa3\x48\xa3\x49\xa3\x4a\xa3\x4b\xa3\x4c\xa3\x4d\xa3\x4e\xa3\x4f\xa3\x50\xa3\x51\xa3\x52\xa3\x53\xa3\x54\xa3\x55\xa3\x56\xa3\x57\xa3\x58\xa6\xfe >> but we got: >> \xa2\xa0\xa2\xab\xa2\xac\xa2\xad\xa2\xae\xa2\xaf\xa2\xb0\xa2\xe3\xa2\xe4\xa2\xef\xa2\xf0\xa2\xfd\xa2\xfe\xa3\x40\xa3\x41\xa3\x42\xa3\x43\xa3\x44\xa3\x45\xa3\x46\xa3\x47\xa3\x48\xa3\x49\xa3\x4a\xa3\x4b\xa3\x4c\xa7\xa0 > > > -- > Yours Charles -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/i18n-dev/attachments/20120529/54772438/attachment.html From littlee at linux.vnet.ibm.com Wed May 30 01:42:23 2012 From: littlee at linux.vnet.ibm.com (Charles Lee) Date: Wed, 30 May 2012 16:42:23 +0800 Subject: Fwd: Some differences on Window UDC area In-Reply-To: <4FC5BA33.2000507@oracle.com> References: <4D8FEFCC.50002@linux.vnet.ibm.com> <4D8FF4AB.2030306@oracle.com> <4D9000B7.8080504@linux.vnet.ibm.com> <4D90A40C.6090802@oracle.com> <4D918382.7070905@linux.vnet.ibm.com> <4FBC99C9.7080508@linux.vnet.ibm.com> <4FC5BA33.2000507@oracle.com> Message-ID: <4FC5DD6F.5050407@linux.vnet.ibm.com> Hi Sherman, Thank you for the info. MS936.map is really out-of-date. Updating it will be very very helpful. On 05/30/2012 02:12 PM, Xueming Shen wrote: > Hi Charles, > > The MS936 charset is long overdue for a update. See CR#6183404. The > mapping need > to be re-generated from MS's latest 936 table (not, MS936 should just > follow MS's mapping > table, not GB18030) As noted in MS936.map, the existing mapping table > uses 1894 entries > from GBK UDC block for EUDC mapping, as suggested by IBM engineer back > to 1999, which > was a reasonable approach back then. > > I will try to generate a new MS936 for JDK8. > > -Sherman > > On 5/23/2012 1:03 AM, Charles Lee wrote: >> Hi guys, >> >> We have a simple test case: >> >> for (String cname : new String[] { "GBK", "MS936", "GB18030" }) { >> Charset charset = Charset.forName(cname); >> System.out.println("charset: " + charset.name()); >> CharsetEncoder ce = charset.newEncoder(); >> char[] chars = new char[] { 0xE585, 0xE586, 0xE592 }; >> CharBuffer cb = CharBuffer.wrap(chars); >> ByteBuffer bb = ce.encode(cb); >> >> for (char c : chars) { >> System.out.printf("\\u%04x", (int) c); >> } >> System.out.print(" -> "); >> >> for (byte b : bb.array()) >> if (b != 0x0) { >> System.out.printf("\\x%02x", (int) b & 0xFF); >> } >> System.out.println(""); >> } >> >> The output is >> charset: GBK >> \ue585\ue586\ue592 -> \xa2\xa0\xa2\xab\xa3\x40 >> charset: x-mswin-936 >> \ue585\ue586\ue592 -> \xa2\xa0\xa2\xab\xa3\x40 >> charset: GB18030 >> \ue585\ue586\ue592 -> \xa2\xa0\xa3\x40\xa3\x4c >> >> From the msdn[1], U+E000 -> U+F8FF is in the EUDC scope. So U+E586 is >> in the EUDC scope. But the mapped code in MS936/GBK is 0xA2AB, it is >> not in the EUDC scope. >> With another simple test case, you can find there are more codes that >> is not mapped right: >> >> for (int i = 0xE000; i < 0xE000 + 1894; i++) { >> String s = new String(new char[] { (char) i }); >> byte[] bs = s.getBytes("MS936"); >> int b0 = (int) bs[0] & 0xFF; >> int b1 = (int) bs[1] & 0xFF; >> if ((b0 >= 0xAA && b0 <= 0xAF) && (b1 >= 0xA1 && b1 <= 0xFE)) >> continue; >> if ((b0 >= 0xF8 && b0 <= 0xFE) && (b1 >= 0xA1 && b1 <= 0xFE)) >> continue; >> if ((b0 >= 0xA1 && b0 <= 0xA7) && (b1 >= 0x40 && b1 <= 0xA0)) >> continue; >> System.out.printf("\\u%04X -> \\x%02X\\x%02X%n", i, b0, b1); >> } >> >> >> I have written a generator in C#[2] which outputs the mapping code in >> GB2312[3] and GB18030[4] in scope U+E000 and U+F8FF to find that most >> of code are the same. Hereby I suggest we may follow the code from >> GB2312 and the changed map file in openjdk can be found [5][6]. >> >> Would anyone help to take a look on this issue? >> >> >> >> [1] >> http://msdn.microsoft.com/en-us/library/windows/desktop/dd317837%28v=vs.85%29.aspx >> [2] http://cr.openjdk.java.net/~littlee/OJDK-63/webrev.00/Program.cs >> [3] http://cr.openjdk.java.net/~littlee/OJDK-63/webrev.00/gb2312Map.txt >> [4] http://cr.openjdk.java.net/~littlee/OJDK-63/webrev.00/gb18030Map.txt >> [5] http://cr.openjdk.java.net/~littlee/OJDK-63/webrev.00/GBK.map.new >> [6] http://cr.openjdk.java.net/~littlee/OJDK-63/webrev.00/MS936.map.new >> >> P.S: Sorry for the late notice. >> >> >> On 03/29/2011 03:00 PM, Charles Lee wrote: >>> On 03/28/2011 11:06 PM, Alan Bateman wrote: >>>> Charles Lee wrote: >>>>> : >>>>> >>>>> It looks similar. How can I find the patch quickly? I notice it >>>>> says "the list is attached to this CR". Is it CR-6183404? Since cr >>>>> has the pattern cr.openjdk.java.net/~username/id, how can I know >>>>> who is the committer to this CR? >>>> cr.openjdk.java.net is the place where we push webrevs when a patch >>>> is out for review. I don't think this one is one anyone's list for >>>> jdk7 and the list attached to the bug is likely the list of >>>> incorrect mappings. If this is fixed then I assume the fix will >>>> update the mappings in jdk/make/tools/CharsetMapping/MS936.map. >>>> >>>> -Alan >>> I have output more bytes[1] to see whether other bytes are encoded >>> correctly. But unfortunately it is not. It is kind of like, on >>> windows, using ms936, PUA of ms936 use the PUA of gb18030. In >>> wikipedia, it says gb18030 is compatible with gbk which ms936 >>> implemented. Can we conclude that ms936 should follow the gb18030's >>> behavior? >>> >>> >>> [1] 0xE585, 0xE586, 0xE587, 0xE588, 0xE589, 0xE58a, 0xE58b, 0xE58c, >>> 0xE58d, 0xE58e, 0xE58f, 0xE590, 0xE591, 0xE592, 0xE593, 0xE594, >>> 0xE595, 0xE596, 0xE597, 0xE598, 0xE599, 0xE59a, 0xE59b, 0xE59c, >>> 0xE59d, 0xE59e, 0xe79f. >>> Using MS936 charset, we expect: >>> \xa2\xa0\xa3\x40\xa3\x41\xa3\x42\xa3\x43\xa3\x44\xa3\x45\xa3\x46\xa3\x47\xa3\x48\xa3\x49\xa3\x4a\xa3\x4b\xa3\x4c\xa3\x4d\xa3\x4e\xa3\x4f\xa3\x50\xa3\x51\xa3\x52\xa3\x53\xa3\x54\xa3\x55\xa3\x56\xa3\x57\xa3\x58\xa6\xfe >>> but we got: >>> \xa2\xa0\xa2\xab\xa2\xac\xa2\xad\xa2\xae\xa2\xaf\xa2\xb0\xa2\xe3\xa2\xe4\xa2\xef\xa2\xf0\xa2\xfd\xa2\xfe\xa3\x40\xa3\x41\xa3\x42\xa3\x43\xa3\x44\xa3\x45\xa3\x46\xa3\x47\xa3\x48\xa3\x49\xa3\x4a\xa3\x4b\xa3\x4c\xa7\xa0 >> >> >> -- >> Yours Charles -- Yours Charles -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/i18n-dev/attachments/20120530/2746624e/attachment-0001.html From xueming.shen at oracle.com Thu May 31 00:25:05 2012 From: xueming.shen at oracle.com (Xueming Shen) Date: Thu, 31 May 2012 00:25:05 -0700 Subject: Fwd: Some differences on Window UDC area In-Reply-To: <4FC5BA33.2000507@oracle.com> References: <4D8FEFCC.50002@linux.vnet.ibm.com> <4D8FF4AB.2030306@oracle.com> <4D9000B7.8080504@linux.vnet.ibm.com> <4D90A40C.6090802@oracle.com> <4D918382.7070905@linux.vnet.ibm.com> <4FBC99C9.7080508@linux.vnet.ibm.com> <4FC5BA33.2000507@oracle.com> Message-ID: <4FC71CD1.5090106@oracle.com> Hi, Here is the webrev for the updated MS936.map change, which updated the mapping entries for 500+ EUDC code points with in range of A140- A7A0. I'm using CR#6183404 http://cr.openjdk.java.net/~sherman/6183404/webrev I re-generated the MS936.b2c and c2b mapping tables via MultiByteToWideChar and WideCharToMultiByte as showed in ms936.c below. http://cr.openjdk.java.net/~sherman/6183404/ms936.c I went through the diff of the newly generated b2c table and the existing MS936.map, it appears the two tables are identical except the 500+ code points of EUDC(PUA) with in range 0xA140-0xA7A0. You can check the "defined" and "undefined" ms936 code points at http://msdn.microsoft.com/en-US/goglobal/cc305153 (click the A1 - A7) The mapping from FUSE at jp.ibm.com (integrated into JDK1.3/1999 via CR#4202893) fills all "user-defined"/undefined code points in this range ( 0xA140 - 0xA7A0) with the code points from Unicode PUA starting from U-E4C6 to U-E79F one by one sequentially (in code point order). However the newly generated mapping table from MultiByteToWideChar and WideCharToMultiByte suggests the actually mapping is to fill the big continuing area first with code points starting from U+E4C6 (sequentially) 0xA140-A1A0 -> U+E4C6 - U+E525 0xA240-A2A0 -> U+E526 - U+E585 0xA340-A3A0 -> U+E586 - U+E5E5 ... 0xA740-A7A0 -> U+E706 - U+E765 then it goes back to fill those "small"/leftover area/spot with the PUA code points started from U+E766, the first is 0xA2AB -> U+E766 ... 0xA6FE -> U+E79F This pattern can be easily observed at http://cr.openjdk.java.net/~sherman/6183404/webrev/make/tools/CharsetMapping/MS936.map.sdiff.html Now the new MS936.map is identical to the mapping used by wctomb and mbtowc, the only exception is the 0xff <-> u+F8F5, which is excluded for now, personally I don't feel comfortable it in. #6183404 also complains some 412 non-UDC characters missing from Java MS936, all these characters are listed at http://cr.openjdk.java.net/~sherman/6183404/CodePage936.pdf A careful check suggested these are the result of incorrect use of WideCharToMultiByte when generating the mapping, it appears these entries are "best fit" result from WideCharToMultiByte when WC_NO_BEST_FIT_CHARS flag is not specified. There might be a compatibility concern of changing these entries, but given (1) they are educ/pua characters/code points (2)it follows MS, and this is a MS charset, I don't think this should stop the update. OK, this is all I got. Please help review (Masoyoshi, Charles) Thanks, -Sherman From littlee at linux.vnet.ibm.com Thu May 31 20:04:27 2012 From: littlee at linux.vnet.ibm.com (Charles Lee) Date: Fri, 01 Jun 2012 11:04:27 +0800 Subject: Fwd: Some differences on Window UDC area In-Reply-To: <4FC71CD1.5090106@oracle.com> References: <4D8FEFCC.50002@linux.vnet.ibm.com> <4D8FF4AB.2030306@oracle.com> <4D9000B7.8080504@linux.vnet.ibm.com> <4D90A40C.6090802@oracle.com> <4D918382.7070905@linux.vnet.ibm.com> <4FBC99C9.7080508@linux.vnet.ibm.com> <4FC5BA33.2000507@oracle.com> <4FC71CD1.5090106@oracle.com> Message-ID: <4FC8313B.5070701@linux.vnet.ibm.com> Hi Sherman, Thank you for bring these out. The change is great because MS936.map is the same as mine :-) What about GBK.map? On 05/31/2012 03:25 PM, Xueming Shen wrote: > Hi, > > Here is the webrev for the updated MS936.map change, which updated > the mapping entries for 500+ EUDC code points with in range of A140- > A7A0. I'm using CR#6183404 > > http://cr.openjdk.java.net/~sherman/6183404/webrev > > I re-generated the MS936.b2c and c2b mapping tables via > MultiByteToWideChar and WideCharToMultiByte as showed in ms936.c > below. > > http://cr.openjdk.java.net/~sherman/6183404/ms936.c > > I went through the diff of the newly generated b2c table and the > existing MS936.map, it appears the two tables are identical except > the 500+ code points of EUDC(PUA) with in range 0xA140-0xA7A0. > > You can check the "defined" and "undefined" ms936 code points at > http://msdn.microsoft.com/en-US/goglobal/cc305153 > (click the A1 - A7) > > The mapping from FUSE at jp.ibm.com (integrated into JDK1.3/1999 via > CR#4202893) fills all "user-defined"/undefined code points in this > range ( 0xA140 - 0xA7A0) with the code points from Unicode PUA > starting from U-E4C6 to U-E79F one by one sequentially (in code > point order). However the newly generated mapping table from > MultiByteToWideChar and WideCharToMultiByte suggests the actually > mapping is to fill the big continuing area first with code points > starting > from U+E4C6 (sequentially) > > 0xA140-A1A0 -> U+E4C6 - U+E525 > 0xA240-A2A0 -> U+E526 - U+E585 > 0xA340-A3A0 -> U+E586 - U+E5E5 > ... > 0xA740-A7A0 -> U+E706 - U+E765 > > then it goes back to fill those "small"/leftover area/spot with the PUA > code points started from U+E766, the first is > > 0xA2AB -> U+E766 > ... > 0xA6FE -> U+E79F > > This pattern can be easily observed at > http://cr.openjdk.java.net/~sherman/6183404/webrev/make/tools/CharsetMapping/MS936.map.sdiff.html > > > Now the new MS936.map is identical to the mapping used by > wctomb and mbtowc, the only exception is the 0xff <-> u+F8F5, > which is excluded for now, personally I don't feel comfortable > it in. > > #6183404 also complains some 412 non-UDC characters missing from Java > MS936, > all these characters are listed at > http://cr.openjdk.java.net/~sherman/6183404/CodePage936.pdf > A careful check suggested these are the result of incorrect use of > WideCharToMultiByte when generating the mapping, it appears > these entries are "best fit" result from WideCharToMultiByte when > WC_NO_BEST_FIT_CHARS flag is not specified. > > There might be a compatibility concern of changing these entries, but > given (1) they are educ/pua characters/code points (2)it follows > MS, and this is a MS charset, I don't think this should stop the > update. > > OK, this is all I got. Please help review (Masoyoshi, Charles) > > Thanks, > -Sherman > > > > -- Yours Charles From xueming.shen at oracle.com Thu May 31 21:47:26 2012 From: xueming.shen at oracle.com (Xueming Shen) Date: Thu, 31 May 2012 21:47:26 -0700 Subject: Fwd: Some differences on Window UDC area In-Reply-To: <4FC8313B.5070701@linux.vnet.ibm.com> References: <4D8FEFCC.50002@linux.vnet.ibm.com> <4D8FF4AB.2030306@oracle.com> <4D9000B7.8080504@linux.vnet.ibm.com> <4D90A40C.6090802@oracle.com> <4D918382.7070905@linux.vnet.ibm.com> <4FBC99C9.7080508@linux.vnet.ibm.com> <4FC5BA33.2000507@oracle.com> <4FC71CD1.5090106@oracle.com> <4FC8313B.5070701@linux.vnet.ibm.com> Message-ID: <4FC8495E.6050108@oracle.com> On 5/31/2012 8:04 PM, Charles Lee wrote: > Hi Sherman, > > Thank you for bring these out. The change is great because MS936.map > is the same as mine :-) > > What about GBK.map? Given how those code points are mapped in GB18030, I would assume they probably should be updated as well. But I'm confirming with our Solaris people to get the mapping table used in their iconv. -Sherman > > On 05/31/2012 03:25 PM, Xueming Shen wrote: >> Hi, >> >> Here is the webrev for the updated MS936.map change, which updated >> the mapping entries for 500+ EUDC code points with in range of A140- >> A7A0. I'm using CR#6183404 >> >> http://cr.openjdk.java.net/~sherman/6183404/webrev >> >> I re-generated the MS936.b2c and c2b mapping tables via >> MultiByteToWideChar and WideCharToMultiByte as showed in ms936.c >> below. >> >> http://cr.openjdk.java.net/~sherman/6183404/ms936.c >> >> I went through the diff of the newly generated b2c table and the >> existing MS936.map, it appears the two tables are identical except >> the 500+ code points of EUDC(PUA) with in range 0xA140-0xA7A0. >> >> You can check the "defined" and "undefined" ms936 code points at >> http://msdn.microsoft.com/en-US/goglobal/cc305153 >> (click the A1 - A7) >> >> The mapping from FUSE at jp.ibm.com (integrated into JDK1.3/1999 via >> CR#4202893) fills all "user-defined"/undefined code points in this >> range ( 0xA140 - 0xA7A0) with the code points from Unicode PUA >> starting from U-E4C6 to U-E79F one by one sequentially (in code >> point order). However the newly generated mapping table from >> MultiByteToWideChar and WideCharToMultiByte suggests the actually >> mapping is to fill the big continuing area first with code points >> starting >> from U+E4C6 (sequentially) >> >> 0xA140-A1A0 -> U+E4C6 - U+E525 >> 0xA240-A2A0 -> U+E526 - U+E585 >> 0xA340-A3A0 -> U+E586 - U+E5E5 >> ... >> 0xA740-A7A0 -> U+E706 - U+E765 >> >> then it goes back to fill those "small"/leftover area/spot with the PUA >> code points started from U+E766, the first is >> >> 0xA2AB -> U+E766 >> ... >> 0xA6FE -> U+E79F >> >> This pattern can be easily observed at >> http://cr.openjdk.java.net/~sherman/6183404/webrev/make/tools/CharsetMapping/MS936.map.sdiff.html >> >> >> Now the new MS936.map is identical to the mapping used by >> wctomb and mbtowc, the only exception is the 0xff <-> u+F8F5, >> which is excluded for now, personally I don't feel comfortable >> it in. >> >> #6183404 also complains some 412 non-UDC characters missing from Java >> MS936, >> all these characters are listed at >> http://cr.openjdk.java.net/~sherman/6183404/CodePage936.pdf >> A careful check suggested these are the result of incorrect use of >> WideCharToMultiByte when generating the mapping, it appears >> these entries are "best fit" result from WideCharToMultiByte when >> WC_NO_BEST_FIT_CHARS flag is not specified. >> >> There might be a compatibility concern of changing these entries, but >> given (1) they are educ/pua characters/code points (2)it follows >> MS, and this is a MS charset, I don't think this should stop the >> update. >> >> OK, this is all I got. Please help review (Masoyoshi, Charles) >> >> Thanks, >> -Sherman >> >> >> >> > >