Hi Kito,
No, otherwise we would have had people already complain in a major way ;)
Mojarra already has the change, it is just not specified as required to
be supported.
Thanks!
Kind regards,
Manfred Riem
On 9/2/15, 11:14 AM, Kito Mann wrote:
> +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
> <mailto: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 <mailto: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 <mailto: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 <mailto: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
>>>
>>>
>>>
>>
>