[prev in list] [next in list] [prev in thread] [next in thread] 

List:       openjdk-serviceability-dev
Subject:    Re: RFR: 8282819: Deprecate Locale class constructors
From:       Naoto Sato <naoto () openjdk ! java ! net>
Date:       2022-03-25 16:21:52
Message-ID: WWaUZ9i-O6PCG638nKOBsZabzM2ssK5gzG_SDVattvE=.d63a8f82-17f8-4ed2-bed6-ba717c04b545 () github ! com
[Download RAW message or body]

On Fri, 25 Mar 2022 15:37:36 GMT, Roger Riggs <rriggs@openjdk.org> wrote:

> > Proposing to deprecate the constructors in the `java.util.Locale` class. There is \
> > already a factory method and a builder to return singletons, so there is no need \
> > to have constructors anymore unless one purposefully wants to create `ill-formed` \
> > Locale objects, which is discouraged. We cannot terminally deprecate those \
> > constructors for the compatibility to serialized objects created with older JDKs. \
> > Please see the draft CSR for more detail.
> 
> src/java.base/share/classes/java/util/Locale.java line 245:
> 
> > 243:  * <h4>Factory Method</h4>
> > 244:  *
> > 245:  * <p>The method {@link #forLanguageTag} obtains a {@code Locale}
> 
> The factory name `forLanguageTag` is a bit off-putting, it doesn't seem like the \
> best name for the factory. Yes, it already exists and does what's required but you \
> might get better uptake with a more natural name. 
> Some alternatives:
> - `Locale.of("en_US")` - short and conventional
> - `Locale.ofLanguage("en_US")` - 'of' prefix is used in other factories
> - `Locale.forLanguage("en_US")` - natural but less conventional

I was thinking of a *new* factory method, along the line with Stuart's suggestion, \
something like this:

Locale.of(String... elements)

where elements can either `(lang)`, `(lang, ctry)`, `(lang, ctry, vrnt)`, or `(lang, \
ctry, vrnt, scpt)`. Either element can be an empty string, but cannot be null. These \
elements are *not* language tags, but conventional arguments to constructors, so it \
is compatible (and works as a stop-gap) to the old constructors. This way third \
parties will not have to deal with the boilerplate code mentioned above on migration.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7947


[prev in list] [next in list] [prev in thread] [next in thread]