[20+] fix warning 'The constructor Locale is deprecated since version 20'

[jukzi]

No description provided.

[github-actions]

Test Results

 1 755 files  ±0   1 755 suites  ±0   1h 42m 20s ⏱️ + 4m 35s
 4 170 tests ±0   4 148 ✅ ±0   22 💤 ±0  0 ❌ ±0 
13 107 runs  ±0  12 943 ✅ ±0  164 💤 ±0  0 ❌ ±0 

Results for commit cfa271b. ± Comparison against base commit 023ee35.

♻️ This comment has been updated with latest results.

[jukzi]

i guess this has to wait until BREE>=20

[mihnita]

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, or sr-Latn-RS.
• No Unicode extensions (en-US-u-hc-h23, or ar-u-nu-latn)
• No "real variant" (for example de-CH-1996 or ca_ES_VALENCIA)

https://www.rfc-editor.org/rfc/bcp/bcp47.txt

[jukzi]

• 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.

[mihnita]

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.

[jukzi]

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.

[jukzi]

@akurtakov how do we handle PRs where upgrading BREEE shows new warnings? here 30 * "The constructor URL(URL, String) is deprecated since version 20"

[akurtakov]

As long as the person merging/contributing plans to work on these new failures in the short term it should be fine as having huge PRs is also not nice for review. E.g. I merged #1676 and I'm now cleaning up after myself #1682.
I understand there will be cases that would not be fixable in the short term but these should be the exception not the norm.

[jukzi]

I had already tried to work on URL(URL, String) but it introduced more regression then doing good. I think its because eclipse typically uses whitespace in URLs instead of %20 (#35).

[akurtakov]

Getting rid of legacy mistakes is very lengthy process and most of the time it is not straightforward find and replace but requires some rearrangement of the code to make it better.
As there is no "silver bullet" - take an instanceof a problem, figure out a proper fix /repeat is what gives better results in so many ways like easier to figure what exactly broke, smaller patch to revert (if/when it comes to that) , easier to get suggestions on PR and learn smth (more people will look at a smaller patch and grasp it and will give up on huge one, @HannesWell gave me a very good suggestion in one such "minor PR" that I just make use of now to fix the ant.tests.ui warnings too) .
It's really slow this way and requires extra effort (I know it very well!) but it also generates less mistakes and helps us preserve the stability expected from Eclipse Platform while still advancing the project.
P.S. I would never chose this approach for leaf project like https://github.com/eclipse-linuxtools/org.eclipse.linuxtools/ but being in different place in the stack requires (totally) different workflow.

[merks]

Yes, every time I see people wanting to replace the old URL constructor I need to warn them that it can and generally does cause problems because of URI being fussy about characters like the space and URL not caring at all. In EMF I just gave up on that and introduced this method so that the warning is in one place and if it ever needs to be fixed (they are not marked at to be removed) can be fixed in that one place:

  /**
   * Creates a URL.
   * @param literal the url literal.
   * @return the corresponding new URL.
   * @throws MalformedURLException
   *
   * @since 2.40
   */
  public static URL newURL(String literal) throws MalformedURLException
  {
    @SuppressWarnings("deprecation")
    URL url = new URL(literal);
    return url;
  }

[jukzi]

introduced this method so that the warning is in one place

seems legit to me

[laeubi]

Getting rid of legacy mistakes is very lengthy process and most of the time it is not straightforward find and replace but requires some rearrangement of the code to make it better.

I can only strongly second that. "Upgrading" to java 21 (or any future version) is not replacing one string constant with another it should include:

1. Update project setting and JRE / BREE is just the simplest preparation
2. Apply new cleanups so we can get rid of old code and really benefit from the upgrade
3. Fix new warnings to not leave that daunting task to other for a quick win.

regarding the URL problem, the main issue is that URL is used where URI or even Path has to be used, String concatenation is used instead of proper resolve and escaping. So the best is to take the change to evaluate those places if an URL is really needed and properly used.

Beside that we have several URIUtil / URLUtil already in platform lingering around.