classpath
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Locale initialization error


From: Eric Blake
Subject: Re: Locale initialization error
Date: Thu, 21 Mar 2002 16:01:25 -0700

Patrik Reali wrote:
> 
> Hi!
> 
> I've run into a initialization problem when class java/util/Locale is
> initialized.
> 
> The static initialization of Locale creates many instances of class Locale,
> whose
> constructor calls String.toUpperCase.
> 
>   public Locale(String language, String country, String variant)
>   {
>     this.language = convertLanguage(language);
>     this.country = country.toUpperCase();
>     this.variant = variant.toUpperCase();
>     this.hashcode = (this.language.hashCode() ^ this.country.hashCode()
>                      ^ this.variant.hashCode());
>   }

For these constructors, I tried adding a trusted constructor which does
no capitalization.  I'm still running into a problem here:

private static Locale defaultLocale =
    new Locale(System.getProperty("user.language", ""),
               System.getProperty("user.region", ""),
               System.getProperty("user.variant", ""));

According to the Javadoc of java.lang.System, there is no guarantee that
the properties user.language, user.region, or user.variant exist.  Does
Sun document anywhere that these must exist, or who must supply them? 
Or is it just a VM integration requirement of Classpath?  If the latter,
then is it documented in the Classpath/VM integration guide?

If it is something only used by Classpath, then I think this approach
should solve the bootstrap issue:

public final class Locale implements java.io.Serializable, Cloneable
{
  // NOTE: These static finals must be initialized with the trusted
  // constructor to avoid bootstrap cycles with String.toUpperCase.

  /**
   * Locale which represents the English language.
   */
  public static final Locale ENGLISH = new Locale("en", "", true);

...

  /**
   * Creates a new locale with trusted versions of the strings. This is
   * necessary to avoid bootstrap cycles with String.toUpperCase.
   *
   * @param language lowercase two-letter ISO-639 A2 language code
   * @param country uppercase two-letter ISO-3166 A2 contry code
   * @param ignored just for the type signature
   *
   */
  private Locale(String language, String country, boolean ignored)
  {
    this.language = language;
    this.country = country;
    variant = "";
    hashcode = language.hashCode() ^ country.hashCode();
  }

  private static Locale defaultLocale =
    new Locale(System.getProperty("user.language", ""),
               System.getProperty("user.region", ""), true);


> 
> String.toUpperCase uses the default locale
> 
>   public String toUpperCase()
>   {
>     return toUpperCase(Locale.getDefault());
>   }
> 

We have little choice here, the Javadoc requires this behavior, as well
as a NullPointerException in toUpperCase(null).  If it is still needed,
though, we could add a "bootstrap flag" in String that the VM must set
when bootstrapping is complete. The only use of the locale in
toUpperCase and toLowerCase is to special case two characters in the
Turkish locale.

I just committed my hack shown above - did it do the trick for you? 
(How I wish that I could compile a working VM on cygwin, to answer that
question for myself).

-- 
This signature intentionally left boring.

Eric Blake             address@hidden
  BYU student, free software programmer



reply via email to

[Prev in Thread] Current Thread [Next in Thread]