<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