<i18n dev> ResourceBundleControlProvider replacement for java 9?
Naoto Sato
naoto.sato at oracle.com
Fri Jan 12 19:01:13 UTC 2018
I was under the impression that the libraries you mentioned were from
third parties that you cannot get access to the source. Looks like it's
not that case, so I still believe you can migrate your applications and
libraries with ResourceBundleProvider. Would you prototype migrating
your app and see if there is any technical obstacles?
Naoto
On 1/11/18 12:13 PM, Romain Manni-Bucau wrote:
> 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.sato at oracle.com
> <mailto:naoto.sato at 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.sato at oracle.com
> <mailto:naoto.sato at oracle.com> <mailto:naoto.sato at oracle.com
> <mailto:naoto.sato at 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>>>
>
>
More information about the i18n-dev
mailing list