Analysis of startup logs of LimeWire has led to sun.util.resources.LocaleData as one of the remaining reasons for opening jar files on the boot class path. Examination of the code indicates that if the static method getAvailableLocales() is ever called, a huge startup time penalty will be incurred in which the boot and extension class paths will be manually parsed and all jar files opened and iterated to find all localized variants of the "sun.text.resources.FormatData" properties. This problem was known and documented in 4361102 but the work was only made more lazy instead of being eliminated.

It is not clear whether this method is actually being called during LimeWire's startup (there are other reasons why LocaleData causes jar files to be opened, which will be documented in a separate bug), but the method is called by the class sun/util/LocaleServiceProviderPool.java, which was added very recently, so it is clearly intended to be used.

LocaleData.getAvailableLocales() should return a precomputed list generated during build time of the JDK. It is referencing a Sun-internal properties file for which the list of localizations is known ahead of time.

###@###.### 2005-06-30 23:37:25 GMT