You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@myfaces.apache.org by Yee-Wah Lee <ye...@oracle.com> on 2012/02/24 00:24:24 UTC
[Trinidad] RFC: Raising minimum JDK version for Trinidad plugins
Hi everyone,
I have seen a couple of issues in the maven-i18n-plugin which could be resolved by some code changes + moving to a higher JDK version. My understanding is that the plugins currently need to compile in JDK1.5 as well as 1.6.
1) TRINIDAD-2126 : convertdatetime fails with datestyle=full, th_th or ja_jp_jp locale
https://issues.apache.org/jira/browse/TRINIDAD-2126
The JSLocaleElementsGenerator uses DateFormatSymbols#getEras() to generate era strings like 'BC', 'AD'.
However, in non-Gregorian calendars like Thai Buddhist (th_TH) and Japanese Imperial (ja_JP_JP), these return the translations of 'BC'/'AD' instead of the different eras of the calendar, e.g. ‘Heisei', 'Meiji' for Japanese.
The problem in DateFormatSymbols#getEras() was reported against jdk1.4 (by developer), and fixedin jdk1.6.
http://monaco.us.oracle.com/detail.jsf?cr=4833268
2) Trinidad-2225: Client numberConverter with type=percent fails in tr_TR locale
https://issues.apache.org/jira/browse/TRINIDAD-2225
The JSLocaleElementsGenerator uses DecimalFormat.getPositiveSuffix() to generate the suffix used when formatting percentages. In Turkish locale, percentages are formatted using prefixes.
To detect this case, we will need to send the prefix data down. However, getPositivePrefix() did not always return the correct value, it was fixed for tr_TR locale starting in jdk 6u10 .
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4494727
Because of these two issues, I wanted to get your feedback on moving the minimum version for the plugins to 1.6u10 and up. Any comments?
Thank you,
Yee-Wah Lee
Re: [Trinidad] RFC: Raising minimum JDK version for Trinidad plugins
Posted by Yee-Wah Lee <ye...@oracle.com>.
Hi Scott,
You are right - I should have said when the plugin code is run, during Trinidad compilation. Thanks for catching that. So,
1. Trinidad compile - this needs to be bumped up
2. Trinidad run-time - this should stay the same because we are modifying some client Locale files (Locale_*.js), so only Javascript changes needed to uptake them.
Yee Wah
On 2/24/2012 2:23 PM, Scott O'Bryan wrote:
> I think this sounds reasonable, especially for these bugs. I do have some questions though..
>
> 1) would the minimum version of the JDK need to be bumped up for trinidad as well?
> 2) would these changes only need to be made at compile time, or would the min java version need to be upped for Trinidad runtime as well.
>
> As you know, there are many options here. Of course if this only impacts "compiling" the plugins, I don't see any issues at all.
>
> Scott
>
> On Thu 23 Feb 2012 04:24:24 PM MST, Yee-Wah Lee wrote:
>> Hi everyone,
>>
>> I have seen a couple of issues in the maven-i18n-plugin which could be resolved by some code changes + moving to a higher JDK version. My understanding is that the plugins currently need to compile in JDK1.5 as well as 1.6.
>>
>> 1) TRINIDAD-2126 : convertdatetime fails with datestyle=full, th_th or ja_jp_jp locale
>> https://issues.apache.org/jira/browse/TRINIDAD-2126
>>
>> The JSLocaleElementsGenerator uses DateFormatSymbols#getEras() to generate era strings like 'BC', 'AD'.
>> However, in non-Gregorian calendars like Thai Buddhist (th_TH) and Japanese Imperial (ja_JP_JP), these return the translations of 'BC'/'AD' instead of the different eras of the calendar, e.g. ‘Heisei', 'Meiji' for Japanese.
>>
>> The problem in DateFormatSymbols#getEras() was reported against jdk1.4 (by developer), and fixedin jdk1.6.
>> http://monaco.us.oracle.com/detail.jsf?cr=4833268
>>
>> 2) Trinidad-2225: Client numberConverter with type=percent fails in tr_TR locale
>> https://issues.apache.org/jira/browse/TRINIDAD-2225
>>
>> The JSLocaleElementsGenerator uses DecimalFormat.getPositiveSuffix() to generate the suffix used when formatting percentages. In Turkish locale, percentages are formatted using prefixes.
>>
>> To detect this case, we will need to send the prefix data down. However, getPositivePrefix() did not always return the correct value, it was fixed for tr_TR locale starting in jdk 6u10 .
>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4494727
>>
>> Because of these two issues, I wanted to get your feedback on moving the minimum version for the plugins to 1.6u10 and up. Any comments?
>>
>>
>> Thank you,
>> Yee-Wah Lee
>>
Re: [Trinidad] RFC: Raising minimum JDK version for Trinidad plugins
Posted by Scott O'Bryan <da...@gmail.com>.
I think this sounds reasonable, especially for these bugs. I do have
some questions though..
1) would the minimum version of the JDK need to be bumped up for
trinidad as well?
2) would these changes only need to be made at compile time, or would
the min java version need to be upped for Trinidad runtime as well.
As you know, there are many options here. Of course if this only
impacts "compiling" the plugins, I don't see any issues at all.
Scott
On Thu 23 Feb 2012 04:24:24 PM MST, Yee-Wah Lee wrote:
> Hi everyone,
>
> I have seen a couple of issues in the maven-i18n-plugin which could be
> resolved by some code changes + moving to a higher JDK version. My
> understanding is that the plugins currently need to compile in JDK1.5
> as well as 1.6.
>
> 1) TRINIDAD-2126 : convertdatetime fails with datestyle=full, th_th or
> ja_jp_jp locale
> https://issues.apache.org/jira/browse/TRINIDAD-2126
>
> The JSLocaleElementsGenerator uses DateFormatSymbols#getEras() to
> generate era strings like 'BC', 'AD'.
> However, in non-Gregorian calendars like Thai Buddhist (th_TH) and
> Japanese Imperial (ja_JP_JP), these return the translations of
> 'BC'/'AD' instead of the different eras of the calendar, e.g.
> ‘Heisei', 'Meiji' for Japanese.
>
> The problem in DateFormatSymbols#getEras() was reported against jdk1.4
> (by developer), and fixedin jdk1.6.
> http://monaco.us.oracle.com/detail.jsf?cr=4833268
>
> 2) Trinidad-2225: Client numberConverter with type=percent fails in
> tr_TR locale
> https://issues.apache.org/jira/browse/TRINIDAD-2225
>
> The JSLocaleElementsGenerator uses DecimalFormat.getPositiveSuffix()
> to generate the suffix used when formatting percentages. In Turkish
> locale, percentages are formatted using prefixes.
>
> To detect this case, we will need to send the prefix data down.
> However, getPositivePrefix() did not always return the correct value,
> it was fixed for tr_TR locale starting in jdk 6u10 .
> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4494727
>
> Because of these two issues, I wanted to get your feedback on moving
> the minimum version for the plugins to 1.6u10 and up. Any comments?
>
>
> Thank you,
> Yee-Wah Lee
>