You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@wicket.apache.org by "Damian Golda (JIRA)" <ji...@apache.org> on 2008/06/10 12:04:46 UTC

[jira] Updated: (WICKET-1692) on Java 6+ DatePicker.localize should use DateFormatSymbols.getInstance(Locale) instead of new DateFormatSymbols(Locale) to support DateFormatSymbolsProviders

     [ https://issues.apache.org/jira/browse/WICKET-1692?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Damian Golda updated WICKET-1692:
---------------------------------

    Description: 
Java 6.0 introduces very usefull possibility to add providers for Locale specific classes from java.text - for example for DateFormatSymbols it may be installed DateFormatSymbolsProvider.

Unfortunately such providers are ignored when DateFormatSymbols are created using constructor DateFormatSymbols(Locale) as it's used in DatePicker.localize method.

Javadoc says clearly:
"This constructor can only construct instances for the locales supported by the Java runtime environment, not for those supported by installed DateFormatSymbolsProvider implementations. For full locale coverage, use the getInstance method. "

So please change DatePicker to support custom DateFormatSymbolsProviders.

My proposal:

protected void localize(Map widgetProperties)
{
  DateFormatSymbols dfSymbols = new DateFormatSymbols(getLocale());
  try
  {
    // try to use JDK 6 DateFormatSymbols.getInstance(Locale) 
    Method getInstanceMethod = DateFormatSymbols.getMethod("getInstance", new Class[] { Locale.class});
    dfSymbols = (DateFormatSymbols)getInstanceMethod.invoke(null, new Object[] { getLocale() });
  }catch(NoSuchMethodException e) {
    // pre JDK 6 - ignore
  }catch(IllegalAccessException e) {
    // pre JDK 6 - ignore
  }catch(IllegalArgumentException e) {
    // pre JDK 6 - ignore
  }catch(InvocationTargetException e) {
    // pre JDK 6 - ignore
  }



  was:
Java 6.0 introduces very usefull possibility to add providers for Locale specific classes from java.text - for example for DateFormatSymbols it may be installed DateFormatSymbolsProvider.

Unfortunately such providers are ignored when DateFormatSymbols are created using constructor DateFormatSymbols(Locale) as it's used in DatePicker.localize method.

Javadoc says clearly:
"This constructor can only construct instances for the locales supported by the Java runtime environment, not for those supported by installed DateFormatSymbolsProvider implementations. For full locale coverage, use the getInstance method. "

So please change DatePicker to support custom DateFormatSymbolsProviders.

My proposal:

protected void localize(Map widgetProperties)
{
  DateFormatSymbols dfSymbols = new DateFormatSymbols(getLocale());
  try
  {
    // try to use JDK 6 DateFormatSymbols.getInstance(Locale) 
    Method getInstanceMethod = DateFormatSymbols.getMethod("getInstance", new Class[] { Locale.class});
    dfSymbols = (DateFormatSymbols)getInstanceMethod.invoke(null, new Object[] { locale});
  }catch(NoSuchMethodException e) {
    // pre JDK 6 - ignore
  }catch(IllegalAccessException e) {
    // pre JDK 6 - ignore
  }catch(IllegalArgumentException e) {
    // pre JDK 6 - ignore
  }catch(InvocationTargetException e) {
    // pre JDK 6 - ignore
  }




> on Java 6+ DatePicker.localize should use DateFormatSymbols.getInstance(Locale) instead of new DateFormatSymbols(Locale)  to support DateFormatSymbolsProviders
> ---------------------------------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: WICKET-1692
>                 URL: https://issues.apache.org/jira/browse/WICKET-1692
>             Project: Wicket
>          Issue Type: Improvement
>          Components: wicket-extensions
>    Affects Versions: 1.3.3
>         Environment: Sun JDK 1.6.0
>            Reporter: Damian Golda
>
> Java 6.0 introduces very usefull possibility to add providers for Locale specific classes from java.text - for example for DateFormatSymbols it may be installed DateFormatSymbolsProvider.
> Unfortunately such providers are ignored when DateFormatSymbols are created using constructor DateFormatSymbols(Locale) as it's used in DatePicker.localize method.
> Javadoc says clearly:
> "This constructor can only construct instances for the locales supported by the Java runtime environment, not for those supported by installed DateFormatSymbolsProvider implementations. For full locale coverage, use the getInstance method. "
> So please change DatePicker to support custom DateFormatSymbolsProviders.
> My proposal:
> protected void localize(Map widgetProperties)
> {
>   DateFormatSymbols dfSymbols = new DateFormatSymbols(getLocale());
>   try
>   {
>     // try to use JDK 6 DateFormatSymbols.getInstance(Locale) 
>     Method getInstanceMethod = DateFormatSymbols.getMethod("getInstance", new Class[] { Locale.class});
>     dfSymbols = (DateFormatSymbols)getInstanceMethod.invoke(null, new Object[] { getLocale() });
>   }catch(NoSuchMethodException e) {
>     // pre JDK 6 - ignore
>   }catch(IllegalAccessException e) {
>     // pre JDK 6 - ignore
>   }catch(IllegalArgumentException e) {
>     // pre JDK 6 - ignore
>   }catch(InvocationTargetException e) {
>     // pre JDK 6 - ignore
>   }

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.