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

Alan Bateman Alan.Bateman at oracle.com
Fri Jan 6 09:47:17 UTC 2017


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


More information about the i18n-dev mailing list