<i18n dev> ResourceBundleControlProvider replacement for java 9?
mandy chung
mandy.chung at oracle.com
Fri Jan 12 19:07:50 UTC 2018
Hi Romain,
I expect no impact to the translation process. Can you give an example
of one resource bundle and its packaged artifact and where the localized
bundles are packaged?
As Naoto suggests, it would be helpful to migrate one resource bundle to
ResourceBundleProvider as an exercise that will provide insight the
migration cost you are concerned about.
Mandy
On 1/12/18 11:01 AM, Naoto Sato wrote:
> 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