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

[Yoshito Umaoka]

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