As an alternative - can we implement this such that it uses this in Java6 and falls back to the old bad code in 1.5 and before?
On Tue, Jan 11, 2011 at 1:43 AM, Henri Yandell <flame...@gmail.com> wrote: > +1, Java 1.5 is EOL as you say. > > While Oracle are in the business of supporting the old versions when > it gets painful, we're not. > > Hen > > On Sun, Jan 2, 2011 at 3:27 PM, Jeremy Boynes <jboy...@apache.org> wrote: >> In Java6 support was added for LocaleServiceProviders that extend the >> Locales supported by the java.text formatters. This causes #46052 as >> getAvailableLocales() now needs to scan the entire classpath rather than >> just return the Locales built in to the JRE. It also means we cannot >> continue to cache the returned set of Locales if the taglib is shared >> between different applications (for example, in a JavaEE6 environment where >> the taglibs are supplied by the container) as it will now vary with context >> ClassLoader. >> >> The java.text getInstance() methods work around this by not scanning the >> classpath if a match is found with one of the built-in providers. We can use >> this method directly if the context only requires a single Locale (either >> because we are using application-specified Locales, or because the request >> only specified a single one, or because multiple ones in the request match >> the resolution order (e.g. Firefox's "en-us,en"). >> >> However, where a request specifies multiple Locales with different prefixes, >> we still need to perform the matching ourselves as the JRE will *always* >> match something (at least the ROOT Locale) but we cannot tell which. If we >> stick to using the 1.5 level API we will trigger the uncacheable classpath >> scan on 1.6 level VMs; however, 1.6 provides the >> ServiceLoader#loadInstalled() API which can be used to determine the locales >> installed in the JRE and hence avoid the application classpath scan for JRE >> supplied locales (which are likely to be the most commonly used). >> >> As most users are likely to be running on 1.6 and we've not actually >> released a version needing 1.5 and Sun's 1.5 is generally end-of-lifed, I'd >> like to propose solving this with the 1.6 APIs and making it a >> pre-requisite. Any issue with this? >> >> Cheers >> Jeremy >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org >> For additional commands, e-mail: dev-h...@tomcat.apache.org >> >> > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
