So your use case of RBControlProvider is basically to direct third party
libraries, not the application itself, to load their resource bundles as
your app desires? What kind of alteration does your Control do to the
original loading?
Naoto
On 1/10/18 9:49 PM, Romain Manni-Bucau wrote:
Hello Naoto,
Some comments inline
Le 11 janv. 2018 01:40, "Naoto Sato" <naoto.s...@oracle.com
<mailto:naoto.s...@oracle.com>> a écrit :
Hi Romain,
The idea of ResourceBundleControlProvider that silently intercepts
getBundle of every application on the system is not well fit with
the module system, especially in terms of resource encapsulation.
That's one of the reasons behind the decision to disable
ResourceBundle.Control in named modules. It still works fine with
unnamed modules so it's not a regression per se.
Well, being said unamed modules have been introduced to mitigate the
breakage java 9 modules do, not being able to migrate is a functional
regression (as "i can't implement it natively anymore").
Also note that it prevents applications to upgrade dependencies if they
now use a module-info and therefore breaks the original implementation.
Technically there is no blocker to support the java 8 API too so maybe a
JVM flag to support it in named module could be acceptable?
As you noted below, ResourceBundleProvider serves as the migration
path for applications that control the loading of resource bundles
in named modules. I'd suggest trying to migrate your application
using the interface. Although you need to implement this new
interface, the contents of your existing resource bundles shouldn't
be affected by this migration. Mandy has updated the javadoc (not in
jdk10, but in the current jdk repository) with this issue:
http://cr.openjdk.java.net/~mchung/jdk11/webrevs/8193767/
<http://cr.openjdk.java.net/~mchung/jdk11/webrevs/8193767/>
I hope that would be useful.
Only way to be functionally equivalent I see - hope I miss another way -
is to implement a javaagent or init before the actual main and check all
jars to unpack/pack them adding the new provider which defeats
completely the original feature which can plug a lookup strategy
globally *for the app/JVM* without having to modify libraries packaging.
Naoto
On 1/10/18 12:48 AM, Romain Manni-Bucau wrote:
Hi guys,
Opened
https://bugs.java.com/bugdatabase/view_bug.do?bug_id=JDK-8193680
<https://bugs.java.com/bugdatabase/view_bug.do?bug_id=JDK-8193680>
and
it got closed - not fully sure what was missing - but I got the
recommandation to contact that list on that topic.
The issue is simple: java 8 introduced
ResourceBundleControlProvider which
is really nice and allows to replace the resource bundle lookup
for all the
app transparently. Concretely in my case I get the translations
from a rest
service in one case or - as a fallback - from a specific folder
on the
filesystem. You will note that both are outside the application.
I didn't find a way to migrate my application to named modules
because
there is no replacement for that feature in java 9 if you are
outside
unamed modules. The ResourceBundleProvider was looking like a good
candidate but is too impacting and requires to modify the bundle
itself.
Any way to avoid functional regressions and migrate to java 9
named modules?
Thanks,
Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau
<https://twitter.com/rmannibucau>> | Blog
<https://rmannibucau.metawerx.net/
<https://rmannibucau.metawerx.net/>> | Old Blog
<http://rmannibucau.wordpress.com
<http://rmannibucau.wordpress.com>> | Github
<https://github.com/rmannibucau <https://github.com/rmannibucau>> |
LinkedIn <https://www.linkedin.com/in/rmannibucau
<https://www.linkedin.com/in/rmannibucau>>
