<i18n dev> ResourceBundleControlProvider replacement for java 9?

Naoto Sato naoto.sato at oracle.com
Thu Jan 11 18:31:06 UTC 2018


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>> 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>>
> 
> 


More information about the i18n-dev mailing list