jsr372-experts@javaserverfaces-spec-public.java.net

[jsr372-experts] Re: [jsr372-experts mirror] Re: [JAVASERVERFACES_SPEC_PUBLIC-1225] DISCUSSION - What to say about BCP47 Support?

From: Kito Mann <kito.mann_at_virtua.com>
Date: Wed, 2 Sep 2015 12:14:20 -0400

+1 in general. Will defaulting to the JDK 7 feature break backwards
compatibility in any way?

___

Kito D. Mann | @kito99 | Author, JSF in Action
Virtua, Inc. | http://www.virtua.com | JSF/Java EE training and consulting
http://www.JSFCentral.com | @jsfcentral
+1 203-998-0403

* Listen to the Enterprise Java Newscast: *http://
<http://blogs.jsfcentral.com/JSFNewscast/>enterprisejavanews.com
<http://ww.enterprisejavanews.com>*
* JSFCentral Interviews Podcast:
http://www.jsfcentral.com/resources/jsfcentralpodcasts/
* Sign up for the JSFCentral Newsletter: http://oi.vresp.com/?fid=ac048d0e17

On Wed, Sep 2, 2015 at 10:59 AM, manfred riem <manfred.riem_at_oracle.com>
wrote:

> Hi all,
>
> OK after reviewing the parsing of <default-locale> / <supported-locales>
> it appears that we allow an additional separator which BCP 47 does not
> allow. So my proposal here is to mandate the BCP 47 is used, but if no
> language is found in the parsed Locale then to default back to the old
> algorithm and use it to get the Locale.
>
> I'll go ahead with adding that to the Javadoc and specification in the
> relevant sections if nobody objects before 8/9.
>
> Thanks!
>
> Kind regards,
> Manfred Riem
>
> On 8/27/15, 5:03 AM, Bauke Scholtz wrote:
>
> I'd say +1 for using Locale#forLanguageTag() anyway. Let the
> language/country interpreting job up to the standard API instead of
> manually doing it.
>
> I only wonder for which cases exactly the old code would work where
> Locale#forLanguageTag() fails. If there's none, we could reduce code.
>
> Cheers, B
>
>
> On Wed, Aug 26, 2015 at 5:47 PM, manfred riem <manfred.riem_at_oracle.com>
> wrote:
>
>> Hi all,
>>
>> The implementation is pretty much already done in Mojarra, but we have
>> not required BCP 47 support as it required JavaSE 7. Now that JSF 2.3 is
>> requiring JavaSE 8 we could easily state it is a requirement.
>>
>> Howerver we do have specification adjustments that need to be done in how
>> <supported-locales> and <default-locale> in faces-config.xml need to be
>> parsed (as that is in the specification).
>>
>> As I said I don't feel strong either way.
>>
>> So far we have one EG member saying +1.
>>
>> Thanks!
>>
>> Kind regards,
>> Manfred Riem
>>
>> On 8/25/15, 10:14 PM, Josh Juneau wrote:
>>
>> No preference on this, but how difficult is the implementation? If this
>> is going to help make the Locale support in JSF more current, then perhaps
>> it is worth the fix.
>>
>> Josh Juneau
>> juneau001_at_gmail.com
>> http://jj-blogger.blogspot.com
>> https://www.apress.com/index.php/author/author/view/id/1866
>>
>>
>> On Tue, Aug 25, 2015 at 8:07 AM, manfred riem <manfred.riem_at_oracle.com>
>> wrote:
>>
>>> Hi all,
>>>
>>> While I do not have a preference if we do not get a response we'll go
>>> with option #1.
>>>
>>> Thanks!
>>>
>>> Kind regards,
>>> Manfred Riem
>>>
>>> On 8/24/15, 11:39 AM, manfred riem wrote:
>>>
>>>> Hi all,
>>>>
>>>> Looking at this issue I think we have 2 options:
>>>>
>>>> 1. Do nothing and let the JSF runtime do what is has done in the past
>>>> (status quo).
>>>> 2. Make it so that when dealing with Locales the
>>>> Locale.forLanguageTag() is consulted first,
>>>> and only if it fails let the old code do its work.
>>>>
>>>> I have no particular preference, so please voice your support for
>>>> either.
>>>>
>>>> Note I like to close the loop on this before 8/31.
>>>>
>>>> Thanks!
>>>>
>>>> Kind regards,
>>>> Manfred Riem
>>>>
>>>>
>>>>
>>
>