<i18n dev> [9] RFR: 8171189: Deprecate ResourceBundleControlProvider for removal

[Naoto Sato]

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