Kind of. The applications being comple ones involving N teams it
handles all the company code translations which is a lot of libraries
in final applications. Also translation being handled by a specific
team, we cant pollute all jars with properties.
Le 11 janv. 2018 19:33, "Naoto Sato" <naoto.s...@oracle.com
<mailto:naoto.s...@oracle.com>> a écrit :
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> <mailto: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/>
<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>
<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>
<https://twitter.com/rmannibucau
<https://twitter.com/rmannibucau>>> | Blog
<https://rmannibucau.metawerx.net/
<https://rmannibucau.metawerx.net/>
<https://rmannibucau.metawerx.net/
<https://rmannibucau.metawerx.net/>>> | Old Blog
<http://rmannibucau.wordpress.com
<http://rmannibucau.wordpress.com>
<http://rmannibucau.wordpress.com
<http://rmannibucau.wordpress.com>>> | Github
<https://github.com/rmannibucau
<https://github.com/rmannibucau> <https://github.com/rmannibucau
<https://github.com/rmannibucau>>> |
LinkedIn <https://www.linkedin.com/in/rmannibucau
<https://www.linkedin.com/in/rmannibucau>
<https://www.linkedin.com/in/rmannibucau
<https://www.linkedin.com/in/rmannibucau>>>
