FAQ
+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 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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org

Search Discussions

Discussion Posts

Previous

Follow ups

Related Discussions

Discussion Navigation
viewthread | post
posts ‹ prev | 6 of 9 | next ›
Discussion Overview
groupdev @
categoriestomcat
postedJan 2, '11 at 11:27p
activeJan 17, '11 at 3:08a
posts9
users5
websitetomcat.apache.org
irc#tomcat

People

Translate

site design / logo © 2021 Grokbase