[20+] fix warning 'The constructor Locale is deprecated since version 20' #1406
Conversation
Test Results 1 728 files - 6 1 728 suites - 6 1h 28m 38s ⏱️ + 3m 49s Results for commit 2a1bf40. ± Comparison against base commit fda6401. This pull request removes 1 test.♻️ This comment has been updated with latest results. |
jukzi
changed the title
|
i guess this has to wait until BREE>=20 |
| public static Locale getDefaultLocale() { | ||
| String nl = getNL(); | ||
| // sanity test | ||
| if (nl == null) | ||
| return Locale.getDefault(); | ||
|
|
||
|
|
||
| // break the string into tokens to get the Locale object |
There was a problem hiding this comment.
I would suggest a more correct way of creating a locale:
Locale.forLanguageTag(localeId.replace('_', '-'))
See here for some details:
https://errorprone.info/bugpattern/UnsafeLocaleUsage
Should never use the Locale.toString(), the Locale constructor and Locale.of now (that I didn't know about).
- They don't support standard BCP 47 locale identifiers, including very common ones that have scripts. For example
zh-Hant, orsr-Latn-RS. - No Unicode extensions (
en-US-u-hc-h23, orar-u-nu-latn) - No "real variant" (for example
de-CH-1996orca_ES_VALENCIA)
There was a problem hiding this comment.
- They don't support standard BCP 47 locale identifiers
Hi @mihnita, thanks for the qualified comment. However introducing BCP 47 would change the documented behavior. That is not what this PR is about. As far as i understand this code reflects the Localization defined by OSGi in https://docs.osgi.org/specification/osgi.core/8.0.0/framework.module.html#framework.module.localization chapter 3.11, which defines only language, country, variant
See also https://github.com/eclipse-platform/eclipse.platform.releng.aggregator/blob/72743b4569d5f8d522fd93f4a8875077d32e1fc3/eclipse.platform.common/bundles/org.eclipse.platform.doc.isv/reference/misc/runtime-options.html#L721 ff
NL values should follow the standard Java locale naming conventions. i could not find any reference that BCP 47 encoding can or should be used or that anybody missed a certain local feature beside language, country, variant.
There was a problem hiding this comment.
You are right, if this applies to resource bundles.
It is really unfortunate that OSGi went with language+region+variant.
This system cannot represent certain locales that are currently in use. For example sr-Cyrl-RS vs sr-Latn-RS (Serbian in Cyrillic / Latin script, in Serbia).
I was not aware of this, and I am quite disappointed to see it. :-(
NL values should follow the standard Java locale naming conventions. i could not find any reference that BCP 47 encoding can or should be used or that anybody missed a certain local feature beside language, country, variant.
I think the Java locales are very much about BCP 47 these days:
The Locale class implements IETF BCP 47 which is composed of RFC 4647 "Matching of Language Tags" and RFC 5646 "Tags for Identifying Languages" with support for the LDML (UTS#35, "Unicode Locale Data Markup Language") BCP 47-compatible extensions for locale data exchange.
...
A Locale object logically consists of the fields described below:
... language, script, country (region), variant, extensions
...
Because of these issues, it is recommended that clients migrate away from constructing non-conforming locales and use the forLanguageTag and Locale.Builder APIs instead. Clients desiring a string representation of the complete locale can then always rely on toLanguageTag for this purpose.
...
Java's default resource bundle lookup mechanism also implements this mapping, so that resources can be named using either convention, see ResourceBundle.Control.
...
https://docs.oracle.com/en/java/javase/21/docs/api/java.base/java/util/Locale.html
Note especially "it is recommended that clients migrate away from constructing non-conforming locales and use the forLanguageTag and Locale.Builder APIs instead."
I have no idea why Java would add a factory method (of) that takes the legacy style lang + region + variant.
And why, even if the Java Locale says "resources can be named using either convention", OSGi went "the legacy way" :-(
And if it is indeed about OSGi resources, there might be problems in some cases, as there is no way to cleanly map between BCP 47 and lang+region+variant.
For example if my default locale is sr-Latn-RS, what will be the lang+region+variant equivalent? (see the "Compatibility" section in the Locale documentation.)
TLDR: if this is strictly about resources, and more precise about OSGi resources, then you change is OK as is.
Maybe add a comment.
If it is about something else, then probably BCP 47 is still the best.
There was a problem hiding this comment.
OSGi went "the legacy way"
I am sure OSGI is open for improvements. If there is any backward compatible way to support both lang+region+variant and BCP47 we could also just apply it here.
No description provided.