Bug 46052 - SetLocaleSupport is slow to initialize when many large items are on the classpath
Summary: SetLocaleSupport is slow to initialize when many large items are on the class...
Status: NEW
Alias: None
Product: Taglibs
Classification: Unclassified
Component: Standard Taglib (show other bugs)
Version: 1.1
Hardware: PC Windows XP
: P2 normal (vote)
Target Milestone: ---
Assignee: Tomcat Developers Mailing List
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2008-10-21 14:05 UTC by Aaron Pieper
Modified: 2011-01-01 14:40 UTC (History)
0 users


Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Aaron Pieper 2008-10-21 14:05:33 UTC 
The SetLocaleSupport class has a static initializer block which invokes DateFormat.getAvailableLocales() and NumberFormat.getAvailableLocales(). These operations crawl through all the Jar files on the classpath, and can take several seconds.

Anything to make this run faster would be helpful. Alternatively, maybe we could substitute our own list of Locales so that it wouldn't need search the classpath, when performance is an issue.
Comment 1 Henri Yandell 2009-07-10 00:48:31 UTC 
Maybe some kind of notion of a pluggable DateLocaleFactory and NumberLocaleFactory (insert better names). Seems doable.
Comment 2 Jeremy Boynes 2011-01-01 14:40:29 UTC 
Java6 introduced the java.util.spi.LocaleServiceProvider mechanism as a pluggable mechanism for supporting additional Locales which requires searching the classpath for LocaleServiceProvider implementations when supporting getAvailableLocales(). Prior to 1.6 there was no extension mechanism and getAvailableLocales() only returned the pre-defined Locales supported by the JVM.

The matching algorithm described by LocaleServiceProvider is the same as that defined in the JSTL specification 9.3.2 LocaleLookup. We might be able to resolve this issue by switching to the JVM's implementation.