tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Henri Yandell <flame...@gmail.com>
Subject Re: [taglibs] Move to pre-req Java 1.6 for Locale services?
Date Mon, 17 Jan 2011 03:07:30 GMT
*nod*.

Why don't we go ahead and release and leave this for a bugfix/minor
release afterwards?

If we choose to move to JDK 1.6; there will be a 1.5 available for use
that can be branched for serious bugfixes. If we choose to implement
both, we can but it won't hold up any release. It also gives us
something to do after the release so we can move to a release-often
mantra.

Hen

On Sun, Jan 16, 2011 at 1:38 PM, Jeremy Boynes <jboynes@apache.org> wrote:
> It's not really bad code in 1.5 - 1.6 added the ability to dynamically support Locales
with the consequence of needing to scan the classpath for services when the locale is not
provided by the VM. It works fine when there's only a single Locale involved but falls short
when you're trying to best-match one of a set of Locales as there's no way to determine if
fallback has occurred (like you can with ResourceBundle#getLocale()).
>
> Supporting both JVMs can be done - it's just more work refactoring things out from being
built into the tag implementations.
>
> Another alternative would be to use Joda instead of the JVM date/time formatters. That
would also avoid the synchronization issues as Joda is thread safe; the downside is that it's
an external dependency. And we would still need a solution for numbers.
>
> On Jan 16, 2011, at 11:33 AM, Henri Yandell wrote:
>
>> 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 <flamefew@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 <jboynes@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-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
>>
>
>
> ---------------------------------------------------------------------
> 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


Mime
View raw message