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
