On Tue, 26 Jul 2022 17:17:46 GMT, Naoto Sato <na...@openjdk.org> wrote:
>> This PR is to propose supporting the `T` extension to the BCP 47 to which >> `java.util.Locale` class conforms. There are two extensions to the BCP 47, >> one is `Unicode Locale Extension` which has been supported since JDK7, the >> other is this `Transformed Content` extension. A CSR has also been drafted. > > Naoto Sato has updated the pull request with a new target base due to a merge > or a rebase. The incremental webrev excludes the unrelated changes brought in > by the merge/rebase. The pull request contains 12 additional commits since > the last revision: > > - Modified javadoc of the transformed conent > - Merge branch 'master' into JDK-8289227-T-ext > - Removed unnecessary `contains()` check > - IllformedLocaleEx -> LocaleSyntaxEx > - SystemProperty tests > - Revived returning Optional > - Some clean-ups, including making Extension a sealed class. > - Bring the specialized methods back > Some documentation fixes > - Using Optional > - FieldSeparators()/FieldSubtag() -> Fields() > - ... and 2 more: https://git.openjdk.org/jdk/compare/59bcd12a...780f712e The basic support for the "t" extension is covered by the existing methods for `Locale.getExtension()` and `Locale.Builder.setExtension`. At least initially, there will be very few developers and applications using transformed content. The transformed content extension syntax is well defined by BCP 47 and applications that need the source language or fields have a well defined format they can parse themselves from the value returned from `getExtension('t')`. I'm concerned about adding API and implementation complexity that may not be used and might accumulate in the JDK without ever being used. The parsing of the source locale and fields is a convenience but not essential to 't' support. I would suggest deferring the APIs for `getTransformedContentFields()` and `getTransformedContentSource()`. ------------- PR: https://git.openjdk.org/jdk/pull/9620
