From naoto.sato at oracle.com  Wed Jan  4 20:08:37 2017
From: naoto.sato at oracle.com (Naoto Sato)
Date: Wed, 4 Jan 2017 12:08:37 -0800
Subject: <i18n dev> Result: New Internationalization Group Member: Rachna
	Goel
Message-ID: <43d7032b-7366-5d7c-d9ee-0c7639c2c77a@oracle.com>

The vote for Rachna Goel (OpenJDK user name: rgoel) [1] is now closed.

Yes: 0
Veto: 0
Abstain: 0

According to the Bylaws definition of Lazy Consensus, this is sufficient 
to approve the nomination.

Naoto Sato

[1] 
http://mail.openjdk.java.net/pipermail/i18n-dev/2016-December/002231.html

From naoto.sato at oracle.com  Wed Jan  4 20:13:48 2017
From: naoto.sato at oracle.com (Naoto Sato)
Date: Wed, 4 Jan 2017 12:13:48 -0800
Subject: <i18n dev> Result: New Internationalization Group Member: Nishit
	Jain
Message-ID: <7469d33d-76da-435d-86a4-8070af303b74@oracle.com>

The vote for Nishit Jain (OpenJDK user name: nishjain) [1] is now closed.

Yes: 0
Veto: 0
Abstain: 0

According to the Bylaws definition of Lazy Consensus, this is sufficient 
to approve the nomination.

Naoto Sato

[1]
http://mail.openjdk.java.net/pipermail/i18n-dev/2016-December/002232.html

From y.umaoka at gmail.com  Thu Jan  5 22:44:14 2017
From: y.umaoka at gmail.com (Yoshito Umaoka)
Date: Thu, 5 Jan 2017 17:44:14 -0500
Subject: <i18n dev> [9] RFR: 8171189: Deprecate
 ResourceBundleControlProvider for removal
In-Reply-To: <727b5e3b-50a5-d580-4308-4847795346ed@oracle.com>
References: <727b5e3b-50a5-d580-4308-4847795346ed@oracle.com>
Message-ID: <91ea87ab-9a0e-9dd8-fa16-dc8611671bec@gmail.com>

On 12/19/2016 11:28 AM, Naoto Sato wrote:
> Hello,
>
> Please review the fix to the following issue:
>
> https://bugs.openjdk.java.net/browse/JDK-8171189
>
> The proposed fix is located at:
>
> http://cr.openjdk.java.net/~naoto/8171189/webrev.00/
>
> The said SPI utilizes the Java extension mechanism which is now 
> removed from JDK9. To our knowledge, no implementation has been made, 
> including the original requester, so it's best to deprecate this in 
> JDK9 and eventually remove in the future release.
>
> Naoto

Wow..  We utilize ResourceBundleControlProvider SPI and our software 
heavily depends on it [https://github.com/IBM-Bluemix/gp-java-client]. 
This is only the way to inject custom resource loading logic without 
affecting existing code.

Is there any alternative solution allowing us to customize resource 
loading logic without rewriting ResourceBundle consumer code?

-Yoshito


From srl at icu-project.org  Thu Jan  5 22:44:17 2017
From: srl at icu-project.org (Steven R. Loomis)
Date: Thu, 5 Jan 2017 14:44:17 -0800
Subject: <i18n dev> Contents of i18n-dev digest..."
In-Reply-To: <mailman.251.1482167372.12703.i18n-dev@openjdk.java.net>
References: <mailman.251.1482167372.12703.i18n-dev@openjdk.java.net>
Message-ID: <822ba4b9-cd3f-5bf3-c9c8-9c838fca5c1b@icu-project.org>

Please do NOT remove ResourceBundleControlProvider. It is critical for
our product.

We are using this in production in
https://github.com/IBM-Bluemix/gp-java-client/blob/f43d52db0b5c73f3bcfcd2313a397584734f728b/README.md#using-resourcebundlecontrolprovider-spi-java-8-or-later
- so that we can provide seamless resource bundle data without requiring
user code change.


-s


On 12/19/16 9:09 AM, i18n-dev-request at openjdk.java.net wrote:
> Date: Mon, 19 Dec 2016 08:28:13 -0800
> From: Naoto Sato <naoto.sato at oracle.com>
> To: core-libs-dev <core-libs-dev at openjdk.java.net>,	i18n-dev
> 	<i18n-dev at openjdk.java.net>
> Subject: <i18n dev> [9] RFR: 8171189: Deprecate
> 	ResourceBundleControlProvider for removal
> Message-ID: <727b5e3b-50a5-d580-4308-4847795346ed at oracle.com>
> Content-Type: text/plain; charset=utf-8; format=flowed
>
> Hello,
>
> Please review the fix to the following issue:
>
> https://bugs.openjdk.java.net/browse/JDK-8171189
>
> The proposed fix is located at:
>
> http://cr.openjdk.java.net/~naoto/8171189/webrev.00/
>
> The said SPI utilizes the Java extension mechanism which is now removed 
> from JDK9. To our knowledge, no implementation has been made, including 
> the original requester, so it's best to deprecate this in JDK9 and 
> eventually remove in the future release.
>
> Naoto


From nishit.jain at oracle.com  Fri Jan  6 05:36:44 2017
From: nishit.jain at oracle.com (Nishit Jain)
Date: Fri, 6 Jan 2017 11:06:44 +0530
Subject: <i18n dev> Review Request for JDK-8169480: Inconsistencies across
 Format class hierarchy in their API spec...
Message-ID: <ca969369-2ad9-27cc-61fe-36a433e3e88f@oracle.com>

Hi,

Please review the fix for JDK-8169480

Bug: https://bugs.openjdk.java.net/browse/JDK-8169480
Webrev: http://cr.openjdk.java.net/~nishjain/8169480/webrev.06/

Issue: In the Format class hierarchy there are some APIs which are 
inconsistent with regard to their api specification and implementation 
of Exception.
Fix: If the inconsistency is in concrete subclass's API, added the 
proper Exception in @exception tag of the specification.
If the inconsistency is in the abstract API, to maintain behavioural 
compatibility with the existing implementations, added the behaviour 
requirement in the @implSpec tag

Regards,
Nishit Jain

From Alan.Bateman at oracle.com  Fri Jan  6 08:36:39 2017
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Fri, 6 Jan 2017 08:36:39 +0000
Subject: <i18n dev> [9] RFR: 8171189: Deprecate
 ResourceBundleControlProvider for removal
In-Reply-To: <91ea87ab-9a0e-9dd8-fa16-dc8611671bec@gmail.com>
References: <727b5e3b-50a5-d580-4308-4847795346ed@oracle.com>
	<91ea87ab-9a0e-9dd8-fa16-dc8611671bec@gmail.com>
Message-ID: <157e188b-fbf8-7ba3-94e3-90f3393e7267@oracle.com>

On 05/01/2017 22:44, Yoshito Umaoka wrote:

>
> Wow..  We utilize ResourceBundleControlProvider SPI and our software 
> heavily depends on it [https://github.com/IBM-Bluemix/gp-java-client]. 
> This is only the way to inject custom resource loading logic without 
> affecting existing code.
>
Does this project rely on the extension mechanism?

-Alan

From y.umaoka at gmail.com  Fri Jan  6 09:13:51 2017
From: y.umaoka at gmail.com (Yoshito Umaoka)
Date: Fri, 6 Jan 2017 04:13:51 -0500
Subject: <i18n dev> [9] RFR: 8171189: Deprecate
 ResourceBundleControlProvider for removal
In-Reply-To: <157e188b-fbf8-7ba3-94e3-90f3393e7267@oracle.com>
References: <727b5e3b-50a5-d580-4308-4847795346ed@oracle.com>
	<91ea87ab-9a0e-9dd8-fa16-dc8611671bec@gmail.com>
	<157e188b-fbf8-7ba3-94e3-90f3393e7267@oracle.com>
Message-ID: <3ad26605-9bdd-f898-066e-9123816044a7@gmail.com>

On 1/6/2017 3:36 AM, Alan Bateman wrote:
> On 05/01/2017 22:44, Yoshito Umaoka wrote:
>
>>
>> Wow..  We utilize ResourceBundleControlProvider SPI and our software 
>> heavily depends on it 
>> [https://github.com/IBM-Bluemix/gp-java-client]. This is only the way 
>> to inject custom resource loading logic without affecting existing code.
>>
> Does this project rely on the extension mechanism?
>
> -Alan

Yes. See 
https://github.com/IBM-Bluemix/gp-java-client#using-resourcebundlecontrolprovider-spi-java-8-or-later

The jar file contains java.util.spi.ResourceBundleControlProvider 
[https://github.com/IBM-Bluemix/gp-java-client/blob/master/src/main/resources/META-INF/services/java.util.spi.ResourceBundleControlProvider], 
so a consumer of this library just need to drop the jar in the Java's 
extension directory.

We suggest people to take this approach, because it does not require 
existing code changes at all (that means, they can easily enable/disable 
the extended feature with no source code changes). Of course, the 
library works fine if the consumer of this library explicitly specify 
the ResourceBundleControl implementation, but such approach does not 
work well if resource bundles are consumed indirectly.

-Yoshito


From Alan.Bateman at oracle.com  Fri Jan  6 09:47:17 2017
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Fri, 6 Jan 2017 09:47:17 +0000
Subject: <i18n dev> [9] RFR: 8171189: Deprecate
 ResourceBundleControlProvider for removal
In-Reply-To: <3ad26605-9bdd-f898-066e-9123816044a7@gmail.com>
References: <727b5e3b-50a5-d580-4308-4847795346ed@oracle.com>
	<91ea87ab-9a0e-9dd8-fa16-dc8611671bec@gmail.com>
	<157e188b-fbf8-7ba3-94e3-90f3393e7267@oracle.com>
	<3ad26605-9bdd-f898-066e-9123816044a7@gmail.com>
Message-ID: <077af15c-948f-d91a-58c8-3010c9d6311a@oracle.com>

On 06/01/2017 09:13, Yoshito Umaoka wrote:

>
> Yes. See 
> https://github.com/IBM-Bluemix/gp-java-client#using-resourcebundlecontrolprovider-spi-java-8-or-later
>
> The jar file contains java.util.spi.ResourceBundleControlProvider 
> [https://github.com/IBM-Bluemix/gp-java-client/blob/master/src/main/resources/META-INF/services/java.util.spi.ResourceBundleControlProvider], 
> so a consumer of this library just need to drop the jar in the Java's 
> extension directory.
>
> We suggest people to take this approach, because it does not require 
> existing code changes at all (that means, they can easily 
> enable/disable the extended feature with no source code changes). Of 
> course, the library works fine if the consumer of this library 
> explicitly specify the ResourceBundleControl implementation, but such 
> approach does not work well if resource bundles are consumed indirectly.

The extension mechanism has been removed in JDK 9 (since late 2014). The 
details are in JEP 220 [1].

More on this in the MR for JSR 337 [2] (the JSR for Java SE 8) where the 
deprecation of this "feature" was announced. See also the draft EDR for 
JSR 379 [3] (the JSR for Java SE 9) where the extension mechanism is 
listed for removal in Java SE 9.

In general then I don't think we've seen much use of the extension 
mechanism in recent time. In particular the practice of dropping JAR 
files into the JDK ext directory has always been problematic when 
switching/upgrading JDK versions. We have seen a few cases where servers 
are configured to run with -Djava.ext.dirs=... but not many. Since 2014 
then I'm only aware of three complaints because servers won't start when 
they have -Djava.ext.dirs=... on the command line. In two of these cases 
then the directory was empty, meaning there were no extensions so the 
product dropping the property. To help catch these usages (all part of 
the planning to remove this feature) then JDK 8 intrdouced the 
-XX:+CheckEndorsedAndExtDirs option to fail at startup if the property 
is set or there are extensions installed.

I hope you can find an alternative for the usage here, maybe the 
resources can be deployed on the class path instead.

-Alan

[1] http://openjdk.java.net/jeps/220
[2] https://jcp.org/en/jsr/detail?id=337
[3] 
http://mail.openjdk.java.net/pipermail/java-se-9-spec-experts/2016-December/000002.html

From y.umaoka at gmail.com  Fri Jan  6 14:52:42 2017
From: y.umaoka at gmail.com (Yoshito Umaoka)
Date: Fri, 6 Jan 2017 09:52:42 -0500
Subject: <i18n dev> [9] RFR: 8171189: Deprecate
 ResourceBundleControlProvider for removal
In-Reply-To: <077af15c-948f-d91a-58c8-3010c9d6311a@oracle.com>
References: <727b5e3b-50a5-d580-4308-4847795346ed@oracle.com>
	<91ea87ab-9a0e-9dd8-fa16-dc8611671bec@gmail.com>
	<157e188b-fbf8-7ba3-94e3-90f3393e7267@oracle.com>
	<3ad26605-9bdd-f898-066e-9123816044a7@gmail.com>
	<077af15c-948f-d91a-58c8-3010c9d6311a@oracle.com>
Message-ID: <bf9f5a53-4345-ed9a-1387-c7d7a838e032@gmail.com>

On 1/6/2017 4:47 AM, Alan Bateman wrote:
> On 06/01/2017 09:13, Yoshito Umaoka wrote:
>
>>
>> Yes. See 
>> https://github.com/IBM-Bluemix/gp-java-client#using-resourcebundlecontrolprovider-spi-java-8-or-later
>>
>> The jar file contains java.util.spi.ResourceBundleControlProvider 
>> [https://github.com/IBM-Bluemix/gp-java-client/blob/master/src/main/resources/META-INF/services/java.util.spi.ResourceBundleControlProvider], 
>> so a consumer of this library just need to drop the jar in the Java's 
>> extension directory.
>>
>> We suggest people to take this approach, because it does not require 
>> existing code changes at all (that means, they can easily 
>> enable/disable the extended feature with no source code changes). Of 
>> course, the library works fine if the consumer of this library 
>> explicitly specify the ResourceBundleControl implementation, but such 
>> approach does not work well if resource bundles are consumed indirectly.
>
> The extension mechanism has been removed in JDK 9 (since late 2014). 
> The details are in JEP 220 [1].
>
> More on this in the MR for JSR 337 [2] (the JSR for Java SE 8) where 
> the deprecation of this "feature" was announced. See also the draft 
> EDR for JSR 379 [3] (the JSR for Java SE 9) where the extension 
> mechanism is listed for removal in Java SE 9.
>
> In general then I don't think we've seen much use of the extension 
> mechanism in recent time. In particular the practice of dropping JAR 
> files into the JDK ext directory has always been problematic when 
> switching/upgrading JDK versions. We have seen a few cases where 
> servers are configured to run with -Djava.ext.dirs=... but not many. 
> Since 2014 then I'm only aware of three complaints because servers 
> won't start when they have -Djava.ext.dirs=... on the command line. In 
> two of these cases then the directory was empty, meaning there were no 
> extensions so the product dropping the property. To help catch these 
> usages (all part of the planning to remove this feature) then JDK 8 
> intrdouced the -XX:+CheckEndorsedAndExtDirs option to fail at startup 
> if the property is set or there are extensions installed.
>
> I hope you can find an alternative for the usage here, maybe the 
> resources can be deployed on the class path instead.
>
> -Alan
>
> [1] http://openjdk.java.net/jeps/220
> [2] https://jcp.org/en/jsr/detail?id=337
> [3] 
> http://mail.openjdk.java.net/pipermail/java-se-9-spec-experts/2016-December/000002.html

It looks the removal of the extension mechanism is done deal. But, in my 
honest opinion, I could not find any documentation about what public 
APIs currently available in JDK 8 are impacted.

For example, I have been working on ICU project 
[http://site.icu-project.org/] and ICU4J provides the implementation of 
LocaleServiceProvider SPIs for years. We know there are users utilizing 
ICU4J in this way. LocaleServiceProvider also depends on the extension 
mechanism. Does it mean, LocaleServiceProvider implementations are no 
longer supported on Java 9?

For our users' perspective, I think it's OK to use current thread's 
context class loader to look up SPI implementation like 
java.nio.charset.spi.CharsetProvider. But it's really hard to accept the 
removal of Locale/ResourceBundleControl SPIs, because we have quite a 
few users depending on them through our offerings.

 > i18n-dev team

What is your plan for a series of LocaleServiceProvider SPIs? Is it 
possible to change the implementation of LocaleServiceProvider and 
ResourceBundleControlProvider not to use Java's extension mechanism, but 
use context class loader to look up implementation like java.nio SPI 
implementations?

-Yoshito

From naoto.sato at oracle.com  Fri Jan  6 17:52:07 2017
From: naoto.sato at oracle.com (Naoto Sato)
Date: Fri, 6 Jan 2017 09:52:07 -0800
Subject: <i18n dev> [9] RFR: 8171189: Deprecate
 ResourceBundleControlProvider for removal
In-Reply-To: <bf9f5a53-4345-ed9a-1387-c7d7a838e032@gmail.com>
References: <727b5e3b-50a5-d580-4308-4847795346ed@oracle.com>
	<91ea87ab-9a0e-9dd8-fa16-dc8611671bec@gmail.com>
	<157e188b-fbf8-7ba3-94e3-90f3393e7267@oracle.com>
	<3ad26605-9bdd-f898-066e-9123816044a7@gmail.com>
	<077af15c-948f-d91a-58c8-3010c9d6311a@oracle.com>
	<bf9f5a53-4345-ed9a-1387-c7d7a838e032@gmail.com>
Message-ID: <47fd09c1-f529-bb27-1dbd-fefb9edb3c44@oracle.com>

Hi Yoshito,

On 1/6/17 6:52 AM, Yoshito Umaoka wrote:
>> i18n-dev team
>
> What is your plan for a series of LocaleServiceProvider SPIs? Is it
> possible to change the implementation of LocaleServiceProvider and
> ResourceBundleControlProvider not to use Java's extension mechanism, but
> use context class loader to look up implementation like java.nio SPI
> implementations?

LocaleServiceProvider SPIs are already modified to load implementations 
from the classpath. Please take a look at the modified spec [1].

As to the said RBControlProvider, it was unfortunate that it was an 
interface, not an abstract class, so it wasn't possible to check the 
appropriate permission on the construction of instances. Since we could 
not find any implementations (at the time of investigation, including 
the original requester), we decided to deprecate the SPI.

Naoto

[1] 
http://download.java.net/java/jdk9/docs/api/java/util/spi/LocaleServiceProvider.html

From naoto.sato at oracle.com  Fri Jan  6 19:07:24 2017
From: naoto.sato at oracle.com (Naoto Sato)
Date: Fri, 6 Jan 2017 11:07:24 -0800
Subject: <i18n dev> Review Request for JDK-8169480: Inconsistencies
 across Format class hierarchy in their API spec...
In-Reply-To: <ca969369-2ad9-27cc-61fe-36a433e3e88f@oracle.com>
References: <ca969369-2ad9-27cc-61fe-36a433e3e88f@oracle.com>
Message-ID: <a073a756-73cd-752a-1e60-2ae3ee4cc906@oracle.com>

Looks good to me.

Naoto

On 1/5/17 9:36 PM, Nishit Jain wrote:
> Hi,
>
> Please review the fix for JDK-8169480
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8169480
> Webrev: http://cr.openjdk.java.net/~nishjain/8169480/webrev.06/
>
> Issue: In the Format class hierarchy there are some APIs which are
> inconsistent with regard to their api specification and implementation
> of Exception.
> Fix: If the inconsistency is in concrete subclass's API, added the
> proper Exception in @exception tag of the specification.
> If the inconsistency is in the abstract API, to maintain behavioural
> compatibility with the existing implementations, added the behaviour
> requirement in the @implSpec tag
>
> Regards,
> Nishit Jain

From y.umaoka at gmail.com  Fri Jan  6 20:24:25 2017
From: y.umaoka at gmail.com (Yoshito Umaoka)
Date: Fri, 6 Jan 2017 15:24:25 -0500
Subject: <i18n dev> [9] RFR: 8171189: Deprecate
 ResourceBundleControlProvider for removal
In-Reply-To: <47fd09c1-f529-bb27-1dbd-fefb9edb3c44@oracle.com>
References: <727b5e3b-50a5-d580-4308-4847795346ed@oracle.com>
	<91ea87ab-9a0e-9dd8-fa16-dc8611671bec@gmail.com>
	<157e188b-fbf8-7ba3-94e3-90f3393e7267@oracle.com>
	<3ad26605-9bdd-f898-066e-9123816044a7@gmail.com>
	<077af15c-948f-d91a-58c8-3010c9d6311a@oracle.com>
	<bf9f5a53-4345-ed9a-1387-c7d7a838e032@gmail.com>
	<47fd09c1-f529-bb27-1dbd-fefb9edb3c44@oracle.com>
Message-ID: <289ae93d-26ef-4041-f577-927bbbe304fa@gmail.com>

On 1/6/2017 12:52 PM, Naoto Sato wrote:
> Hi Yoshito,
>
> On 1/6/17 6:52 AM, Yoshito Umaoka wrote:
>>> i18n-dev team
>>
>> What is your plan for a series of LocaleServiceProvider SPIs? Is it
>> possible to change the implementation of LocaleServiceProvider and
>> ResourceBundleControlProvider not to use Java's extension mechanism, but
>> use context class loader to look up implementation like java.nio SPI
>> implementations?
>
> LocaleServiceProvider SPIs are already modified to load 
> implementations from the classpath. Please take a look at the modified 
> spec [1].
>
> As to the said RBControlProvider, it was unfortunate that it was an 
> interface, not an abstract class, so it wasn't possible to check the 
> appropriate permission on the construction of instances. Since we 
> could not find any implementations (at the time of investigation, 
> including the original requester), we decided to deprecate the SPI.
>
> Naoto
>
> [1] 
> http://download.java.net/java/jdk9/docs/api/java/util/spi/LocaleServiceProvider.html

Naoto,

OK - it's a good news that LocaleServiceProvider SPIs were already 
updated and continue to work from the classpath. Thanks.

I'm still seeking for a solution replacing the feature provided by 
ResourceBundleControlProvider. I'm fine to use classpath, but want to 
use a custom ResourceBundleControl at runtime by default. Do you have 
any suggestions? I'll also investigate this a little bit on our side.

-Yoshito



From naoto.sato at oracle.com  Fri Jan  6 21:11:07 2017
From: naoto.sato at oracle.com (Naoto Sato)
Date: Fri, 6 Jan 2017 13:11:07 -0800
Subject: <i18n dev> [9] RFR: 8171189: Deprecate
 ResourceBundleControlProvider for removal
In-Reply-To: <289ae93d-26ef-4041-f577-927bbbe304fa@gmail.com>
References: <727b5e3b-50a5-d580-4308-4847795346ed@oracle.com>
	<91ea87ab-9a0e-9dd8-fa16-dc8611671bec@gmail.com>
	<157e188b-fbf8-7ba3-94e3-90f3393e7267@oracle.com>
	<3ad26605-9bdd-f898-066e-9123816044a7@gmail.com>
	<077af15c-948f-d91a-58c8-3010c9d6311a@oracle.com>
	<bf9f5a53-4345-ed9a-1387-c7d7a838e032@gmail.com>
	<47fd09c1-f529-bb27-1dbd-fefb9edb3c44@oracle.com>
	<289ae93d-26ef-4041-f577-927bbbe304fa@gmail.com>
Message-ID: <8a950bf9-f834-6344-6aac-105f13b1abb1@oracle.com>

Opened a new issue for the latter:

https://bugs.openjdk.java.net/browse/JDK-8172365

Naoto

On 1/6/17 12:24 PM, Yoshito Umaoka wrote:
> On 1/6/2017 12:52 PM, Naoto Sato wrote:
>> Hi Yoshito,
>>
>> On 1/6/17 6:52 AM, Yoshito Umaoka wrote:
>>>> i18n-dev team
>>>
>>> What is your plan for a series of LocaleServiceProvider SPIs? Is it
>>> possible to change the implementation of LocaleServiceProvider and
>>> ResourceBundleControlProvider not to use Java's extension mechanism, but
>>> use context class loader to look up implementation like java.nio SPI
>>> implementations?
>>
>> LocaleServiceProvider SPIs are already modified to load
>> implementations from the classpath. Please take a look at the modified
>> spec [1].
>>
>> As to the said RBControlProvider, it was unfortunate that it was an
>> interface, not an abstract class, so it wasn't possible to check the
>> appropriate permission on the construction of instances. Since we
>> could not find any implementations (at the time of investigation,
>> including the original requester), we decided to deprecate the SPI.
>>
>> Naoto
>>
>> [1]
>> http://download.java.net/java/jdk9/docs/api/java/util/spi/LocaleServiceProvider.html
>>
>
> Naoto,
>
> OK - it's a good news that LocaleServiceProvider SPIs were already
> updated and continue to work from the classpath. Thanks.
>
> I'm still seeking for a solution replacing the feature provided by
> ResourceBundleControlProvider. I'm fine to use classpath, but want to
> use a custom ResourceBundleControl at runtime by default. Do you have
> any suggestions? I'll also investigate this a little bit on our side.
>
> -Yoshito
>
>

From y.umaoka at gmail.com  Mon Jan  9 13:49:02 2017
From: y.umaoka at gmail.com (Yoshito Umaoka)
Date: Mon, 9 Jan 2017 08:49:02 -0500
Subject: <i18n dev> [9] RFR: 8171189: Deprecate
 ResourceBundleControlProvider for removal
In-Reply-To: <8a950bf9-f834-6344-6aac-105f13b1abb1@oracle.com>
References: <727b5e3b-50a5-d580-4308-4847795346ed@oracle.com>
	<91ea87ab-9a0e-9dd8-fa16-dc8611671bec@gmail.com>
	<157e188b-fbf8-7ba3-94e3-90f3393e7267@oracle.com>
	<3ad26605-9bdd-f898-066e-9123816044a7@gmail.com>
	<077af15c-948f-d91a-58c8-3010c9d6311a@oracle.com>
	<bf9f5a53-4345-ed9a-1387-c7d7a838e032@gmail.com>
	<47fd09c1-f529-bb27-1dbd-fefb9edb3c44@oracle.com>
	<289ae93d-26ef-4041-f577-927bbbe304fa@gmail.com>
	<8a950bf9-f834-6344-6aac-105f13b1abb1@oracle.com>
Message-ID: <d787442e-3e86-0daa-5900-f44afb1f93ae@gmail.com>

On 1/6/2017 4:11 PM, Naoto Sato wrote:
> Opened a new issue for the latter:
>
> https://bugs.openjdk.java.net/browse/JDK-8172365
>
> Naoto 

Thank you, Sato-san.

-Yoshito

From rachna.goel at oracle.com  Mon Jan 23 07:22:15 2017
From: rachna.goel at oracle.com (Rachna Goel)
Date: Mon, 23 Jan 2017 12:52:15 +0530
Subject: <i18n dev> RFR: 8167273: Calendar.getDisplayNames inconsistent with
 DateFormatSymbols
Message-ID: <f24114b3-25ae-ecff-c02a-32256c615b20@oracle.com>

Hi,

kindly review fix for JDK-8167273.

Bug : https://bugs.openjdk.java.net/browse/JDK-8167273

Patch :http://cr.openjdk.java.net/~rgoel/JDK-8167273/webrev.05/

Fix : Considering GregorianCalendar only, when CLDR is default provider
[ no, no-NO, zh-HK ] have Locale  providers mismatch
problem.  For those locales, specifying equivalence i.e ["no", "no-NO" ] 
:: "nb"
and "zh-HK" :: "zh_Hant_HK" is the preferred way.

For ["qu-EC", "qu-BO", "qu-PE", "qu"] there is not a providers
mismatch. All of them are retrieving resources from CLDR Provider. But 
first era name in those string arrays [narrow
eras and long eras] is empty. Those empty strings have been replaced 
with parentMap strings at build time.

-- 
Thanks,
Rachna


From naoto.sato at oracle.com  Mon Jan 23 17:02:01 2017
From: naoto.sato at oracle.com (Naoto Sato)
Date: Mon, 23 Jan 2017 09:02:01 -0800
Subject: <i18n dev> RFR: 8167273: Calendar.getDisplayNames inconsistent
 with DateFormatSymbols
In-Reply-To: <f24114b3-25ae-ecff-c02a-32256c615b20@oracle.com>
References: <f24114b3-25ae-ecff-c02a-32256c615b20@oracle.com>
Message-ID: <f1b9fe94-5c46-2037-71ab-872d74bd5839@oracle.com>

Looks good to me.

Naoto

On 1/22/17 11:22 PM, Rachna Goel wrote:
> Hi,
>
> kindly review fix for JDK-8167273.
>
> Bug : https://bugs.openjdk.java.net/browse/JDK-8167273
>
> Patch :http://cr.openjdk.java.net/~rgoel/JDK-8167273/webrev.05/
>
> Fix : Considering GregorianCalendar only, when CLDR is default provider
> [ no, no-NO, zh-HK ] have Locale  providers mismatch
> problem.  For those locales, specifying equivalence i.e ["no", "no-NO" ]
> :: "nb"
> and "zh-HK" :: "zh_Hant_HK" is the preferred way.
>
> For ["qu-EC", "qu-BO", "qu-PE", "qu"] there is not a providers
> mismatch. All of them are retrieving resources from CLDR Provider. But
> first era name in those string arrays [narrow
> eras and long eras] is empty. Those empty strings have been replaced
> with parentMap strings at build time.
>

From naoto.sato at oracle.com  Mon Jan 23 17:13:44 2017
From: naoto.sato at oracle.com (Naoto Sato)
Date: Mon, 23 Jan 2017 09:13:44 -0800
Subject: <i18n dev> [9] RFR: 8172365: Provide a better migration path for
 ResourceBundleControlProvider
Message-ID: <441f86fe-25e8-179b-b072-ebe02c8da62d@oracle.com>

Hi,

Please review the changes for the following issue:

https://bugs.openjdk.java.net/browse/JDK-8172365

The proposed fix is located at:

http://cr.openjdk.java.net/~rgoel/JDK-8167273/webrev.05/

The fix is to reinstate the code that has been removed with 8171189, 
with modification to load implementations with ServiceLoader.load() 
method. That way, SPI implementations can be searched on application's 
class path.

Naoto

From naoto.sato at oracle.com  Mon Jan 23 17:14:46 2017
From: naoto.sato at oracle.com (Naoto Sato)
Date: Mon, 23 Jan 2017 09:14:46 -0800
Subject: <i18n dev> [9] RFR: 8172365: Provide a better migration path
 for ResourceBundleControlProvider
In-Reply-To: <441f86fe-25e8-179b-b072-ebe02c8da62d@oracle.com>
References: <441f86fe-25e8-179b-b072-ebe02c8da62d@oracle.com>
Message-ID: <a9cfe32d-456f-2ac5-77bc-c688047ad56b@oracle.com>

Correct link to the changes:

http://cr.openjdk.java.net/~naoto/8172365/webrev.05/

Naoto

On 1/23/17 9:13 AM, Naoto Sato wrote:
> Hi,
>
> Please review the changes for the following issue:
>
> https://bugs.openjdk.java.net/browse/JDK-8172365
>
> The proposed fix is located at:
>
> http://cr.openjdk.java.net/~rgoel/JDK-8167273/webrev.05/
>
> The fix is to reinstate the code that has been removed with 8171189,
> with modification to load implementations with ServiceLoader.load()
> method. That way, SPI implementations can be searched on application's
> class path.
>
> Naoto

From mandy.chung at oracle.com  Mon Jan 23 18:51:40 2017
From: mandy.chung at oracle.com (Mandy Chung)
Date: Mon, 23 Jan 2017 10:51:40 -0800
Subject: <i18n dev> [9] RFR: 8172365: Provide a better migration path
	for ResourceBundleControlProvider
In-Reply-To: <a9cfe32d-456f-2ac5-77bc-c688047ad56b@oracle.com>
References: <441f86fe-25e8-179b-b072-ebe02c8da62d@oracle.com>
	<a9cfe32d-456f-2ac5-77bc-c688047ad56b@oracle.com>
Message-ID: <87DD942F-6FA0-4679-B726-9835F64AACF7@oracle.com>


> On Jan 23, 2017, at 9:14 AM, Naoto Sato <naoto.sato at oracle.com> wrote:
> 
> http://cr.openjdk.java.net/~naoto/8172365/webrev.05/
> 
>> 
>> The fix is to reinstate the code that has been removed with 8171189,
>> with modification to load implementations with ServiceLoader.load()
>> method. That way, SPI implementations can be searched on application's
>> class path.

This change is reasonable.  The custom control provider can only be used for loading of resource bundles in unnamed modules which maintains JDK 8 behavior.

For the getBundle factory methods taking Module parameter, I suggest to explain the spec to clarify that the custom control provider will be used to load the resource bundle if the specified module is unnamed module.

Otherwise looks good.
Mandy

From naoto.sato at oracle.com  Mon Jan 23 21:51:55 2017
From: naoto.sato at oracle.com (Naoto Sato)
Date: Mon, 23 Jan 2017 13:51:55 -0800
Subject: <i18n dev> [9] RFR: 8172365: Provide a better migration path
 for ResourceBundleControlProvider
In-Reply-To: <87DD942F-6FA0-4679-B726-9835F64AACF7@oracle.com>
References: <441f86fe-25e8-179b-b072-ebe02c8da62d@oracle.com>
	<a9cfe32d-456f-2ac5-77bc-c688047ad56b@oracle.com>
	<87DD942F-6FA0-4679-B726-9835F64AACF7@oracle.com>
Message-ID: <f7fe70f0-b479-87cf-6314-1af792319461@oracle.com>

OK, I will clarify the method description of getBundle(String, Locale, 
Module) as follows:

diff -r 290145dc2c96 
src/java.base/share/classes/java/util/ResourceBundle.java
--- a/src/java.base/share/classes/java/util/ResourceBundle.java
+++ b/src/java.base/share/classes/java/util/ResourceBundle.java
@@ -972,7 +972,11 @@
       * equivalent to calling {@link #getBundle(String, Locale, 
ClassLoader)
       * getBundle(baseName, targetLocale, module.getClassLoader()} to load
       * resource bundles that are visible to the class loader of the given
-     * unnamed module.
+     * unnamed module. The <a href="#default_behavior">default behavior</a>
+     * of resource bundle loading can be modified with custom {@link
+     * ResourceBundleControlProvider} implementations. Refer to the
+     * description of <a href="#modify_default_behavior">modifying the 
default
+     * behavior</a>.
       *
       * @param baseName the base name of the resource bundle,
       *                 a fully qualified class name

Naoto

On 01/23/2017 10:51 AM, Mandy Chung wrote:
>
>> On Jan 23, 2017, at 9:14 AM, Naoto Sato <naoto.sato at oracle.com> wrote:
>>
>> http://cr.openjdk.java.net/~naoto/8172365/webrev.05/
>>
>>>
>>> The fix is to reinstate the code that has been removed with 8171189,
>>> with modification to load implementations with ServiceLoader.load()
>>> method. That way, SPI implementations can be searched on application's
>>> class path.
>
> This change is reasonable.  The custom control provider can only be used for loading of resource bundles in unnamed modules which maintains JDK 8 behavior.
>
> For the getBundle factory methods taking Module parameter, I suggest to explain the spec to clarify that the custom control provider will be used to load the resource bundle if the specified module is unnamed module.
>
> Otherwise looks good.
> Mandy
>


From naoto.sato at oracle.com  Mon Jan 23 22:07:24 2017
From: naoto.sato at oracle.com (Naoto Sato)
Date: Mon, 23 Jan 2017 14:07:24 -0800
Subject: <i18n dev> [9] RFR: 8172365: Provide a better migration path
 for ResourceBundleControlProvider
In-Reply-To: <f7fe70f0-b479-87cf-6314-1af792319461@oracle.com>
References: <441f86fe-25e8-179b-b072-ebe02c8da62d@oracle.com>
	<a9cfe32d-456f-2ac5-77bc-c688047ad56b@oracle.com>
	<87DD942F-6FA0-4679-B726-9835F64AACF7@oracle.com>
	<f7fe70f0-b479-87cf-6314-1af792319461@oracle.com>
Message-ID: <3a530274-a02a-e5b5-19e0-bd0ad7d1a91d@oracle.com>

More concise version:

--- a/src/java.base/share/classes/java/util/ResourceBundle.java
+++ b/src/java.base/share/classes/java/util/ResourceBundle.java
@@ -972,7 +972,9 @@
       * equivalent to calling {@link #getBundle(String, Locale, 
ClassLoader)
       * getBundle(baseName, targetLocale, module.getClassLoader()} to load
       * resource bundles that are visible to the class loader of the given
-     * unnamed module.
+     * unnamed module. Custom {@link * ResourceBundleControlProvider}
+     * implementations, if present, will only be invoked if the specified
+     * module is an unnamed module.
       *
       * @param baseName the base name of the resource bundle,
       *                 a fully qualified class name

Naoto

On 01/23/2017 01:51 PM, Naoto Sato wrote:
> OK, I will clarify the method description of getBundle(String, Locale,
> Module) as follows:
>
> diff -r 290145dc2c96
> src/java.base/share/classes/java/util/ResourceBundle.java
> --- a/src/java.base/share/classes/java/util/ResourceBundle.java
> +++ b/src/java.base/share/classes/java/util/ResourceBundle.java
> @@ -972,7 +972,11 @@
>       * equivalent to calling {@link #getBundle(String, Locale,
> ClassLoader)
>       * getBundle(baseName, targetLocale, module.getClassLoader()} to load
>       * resource bundles that are visible to the class loader of the given
> -     * unnamed module.
> +     * unnamed module. The <a href="#default_behavior">default
> behavior</a>
> +     * of resource bundle loading can be modified with custom {@link
> +     * ResourceBundleControlProvider} implementations. Refer to the
> +     * description of <a href="#modify_default_behavior">modifying the
> default
> +     * behavior</a>.
>       *
>       * @param baseName the base name of the resource bundle,
>       *                 a fully qualified class name
>
> Naoto
>
> On 01/23/2017 10:51 AM, Mandy Chung wrote:
>>
>>> On Jan 23, 2017, at 9:14 AM, Naoto Sato <naoto.sato at oracle.com> wrote:
>>>
>>> http://cr.openjdk.java.net/~naoto/8172365/webrev.05/
>>>
>>>>
>>>> The fix is to reinstate the code that has been removed with 8171189,
>>>> with modification to load implementations with ServiceLoader.load()
>>>> method. That way, SPI implementations can be searched on application's
>>>> class path.
>>
>> This change is reasonable.  The custom control provider can only be
>> used for loading of resource bundles in unnamed modules which
>> maintains JDK 8 behavior.
>>
>> For the getBundle factory methods taking Module parameter, I suggest
>> to explain the spec to clarify that the custom control provider will
>> be used to load the resource bundle if the specified module is unnamed
>> module.
>>
>> Otherwise looks good.
>> Mandy
>>
>


From mandy.chung at oracle.com  Tue Jan 24 05:06:27 2017
From: mandy.chung at oracle.com (Mandy Chung)
Date: Mon, 23 Jan 2017 21:06:27 -0800
Subject: <i18n dev> [9] RFR: 8172365: Provide a better migration path
	for ResourceBundleControlProvider
In-Reply-To: <3a530274-a02a-e5b5-19e0-bd0ad7d1a91d@oracle.com>
References: <441f86fe-25e8-179b-b072-ebe02c8da62d@oracle.com>
	<a9cfe32d-456f-2ac5-77bc-c688047ad56b@oracle.com>
	<87DD942F-6FA0-4679-B726-9835F64AACF7@oracle.com>
	<f7fe70f0-b479-87cf-6314-1af792319461@oracle.com>
	<3a530274-a02a-e5b5-19e0-bd0ad7d1a91d@oracle.com>
Message-ID: <C5020D2B-1F90-428A-A2BA-3092BF3B039B@oracle.com>

+1

Mandy

> On Jan 23, 2017, at 2:07 PM, Naoto Sato <naoto.sato at oracle.com> wrote:
> 
> More concise version:
> 
> --- a/src/java.base/share/classes/java/util/ResourceBundle.java
> +++ b/src/java.base/share/classes/java/util/ResourceBundle.java
> @@ -972,7 +972,9 @@
>      * equivalent to calling {@link #getBundle(String, Locale, ClassLoader)
>      * getBundle(baseName, targetLocale, module.getClassLoader()} to load
>      * resource bundles that are visible to the class loader of the given
> -     * unnamed module.
> +     * unnamed module. Custom {@link * ResourceBundleControlProvider}
> +     * implementations, if present, will only be invoked if the specified
> +     * module is an unnamed module.
>      *
>      * @param baseName the base name of the resource bundle,
>      *                 a fully qualified class name
> 
> Naoto
> 
> On 01/23/2017 01:51 PM, Naoto Sato wrote:
>> OK, I will clarify the method description of getBundle(String, Locale,
>> Module) as follows:
>> 
>> diff -r 290145dc2c96
>> src/java.base/share/classes/java/util/ResourceBundle.java
>> --- a/src/java.base/share/classes/java/util/ResourceBundle.java
>> +++ b/src/java.base/share/classes/java/util/ResourceBundle.java
>> @@ -972,7 +972,11 @@
>>      * equivalent to calling {@link #getBundle(String, Locale,
>> ClassLoader)
>>      * getBundle(baseName, targetLocale, module.getClassLoader()} to load
>>      * resource bundles that are visible to the class loader of the given
>> -     * unnamed module.
>> +     * unnamed module. The <a href="#default_behavior">default
>> behavior</a>
>> +     * of resource bundle loading can be modified with custom {@link
>> +     * ResourceBundleControlProvider} implementations. Refer to the
>> +     * description of <a href="#modify_default_behavior">modifying the
>> default
>> +     * behavior</a>.
>>      *
>>      * @param baseName the base name of the resource bundle,
>>      *                 a fully qualified class name
>> 
>> Naoto
>> 
>> On 01/23/2017 10:51 AM, Mandy Chung wrote:
>>> 
>>>> On Jan 23, 2017, at 9:14 AM, Naoto Sato <naoto.sato at oracle.com> wrote:
>>>> 
>>>> http://cr.openjdk.java.net/~naoto/8172365/webrev.05/
>>>> 
>>>>> 
>>>>> The fix is to reinstate the code that has been removed with 8171189,
>>>>> with modification to load implementations with ServiceLoader.load()
>>>>> method. That way, SPI implementations can be searched on application's
>>>>> class path.
>>> 
>>> This change is reasonable.  The custom control provider can only be
>>> used for loading of resource bundles in unnamed modules which
>>> maintains JDK 8 behavior.
>>> 
>>> For the getBundle factory methods taking Module parameter, I suggest
>>> to explain the spec to clarify that the custom control provider will
>>> be used to load the resource bundle if the specified module is unnamed
>>> module.
>>> 
>>> Otherwise looks good.
>>> Mandy
>>> 
>> 
> 


From naoto.sato at oracle.com  Mon Jan 30 21:27:21 2017
From: naoto.sato at oracle.com (Naoto Sato)
Date: Mon, 30 Jan 2017 13:27:21 -0800
Subject: <i18n dev> [9] RFR: 8173423: Wrong display name for supplemental
	Japanese era
Message-ID: <ca940fce-41ab-bf5a-fe70-cf7804a366fe@oracle.com>

Hello,

Please review the fix to the following bug:

https://bugs.openjdk.java.net/browse/JDK-8173423

The proposed fix is located at:

http://cr.openjdk.java.net/~naoto/8173423/webrev.00/

There is a functionality in Japanese Imperial Calendar to supplement a 
new era from system property. The code path from java.time did not 
retrieve the supplemental name before the fix, thus the era number "3" 
was displayed instead. The fix intends to retrieve the correct name, and 
return it to java.time formatters.

Naoto

From xueming.shen at oracle.com  Tue Jan 31 20:32:03 2017
From: xueming.shen at oracle.com (Xueming Shen)
Date: Wed, 1 Feb 2017 04:32:03 +0800
Subject: <i18n dev> [9] RFR: 8173423: Wrong display name for
	supplemental Japanese era
In-Reply-To: <ca940fce-41ab-bf5a-fe70-cf7804a366fe@oracle.com>
References: <ca940fce-41ab-bf5a-fe70-cf7804a366fe@oracle.com>
Message-ID: <29B69144-B558-4194-BE15-3D8C01AB187C@oracle.com>

+1

On Jan 31, 2017, at 5:27 AM, Naoto Sato <naoto.sato at oracle.com> wrote:

Hello,

Please review the fix to the following bug:

https://bugs.openjdk.java.net/browse/JDK-8173423

The proposed fix is located at:

http://cr.openjdk.java.net/~naoto/8173423/webrev.00/

There is a functionality in Japanese Imperial Calendar to supplement a new era from system property. The code path from java.time did not retrieve the supplemental name before the fix, thus the era number "3" was displayed instead. The fix intends to retrieve the correct name, and return it to java.time formatters.

Naoto


From mark.reinhold at oracle.com  Tue Jan 31 23:14:49 2017
From: mark.reinhold at oracle.com (mark.reinhold at oracle.com)
Date: Tue, 31 Jan 2017 15:14:49 -0800
Subject: <i18n dev> OpenJDK Governing Board CFV: New
	Internationalization Group Lead: Naoto Sato
In-Reply-To: <20161221144745.90688689@eggemoggin.niobe.net>
References: <20161221144745.90688689@eggemoggin.niobe.net>
Message-ID: <20170131151449.734176086@eggemoggin.niobe.net>

2016/12/21 14:47:45 -0800, mark.reinhold at oracle.com:
> Naoto Sato was recently voted in as the new Lead of the
> Internationalization Group [1].
> 
> Governing Board members: Please vote on whether to ratify this change,
> as required by the Bylaws [2].  Votes are due in two weeks, by 23:00
> UTC on Wednesday, 4 January 2017.  Votes must be cast in the open by
> replying to this message.

Thank you for your votes.  A majority has voted in favor of ratification.
Naoto Sato is now the Lead of the Internationalization Group.

- Mark