<i18n dev> ResourceBundleControlProvider replacement for java 9?

classic Classic list List threaded Threaded
9 messages Options
Reply | Threaded
Open this post in threaded view
|

<i18n dev> ResourceBundleControlProvider replacement for java 9?

Romain Manni-Bucau
Hi guys,

Opened 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> |  Blog
<https://rmannibucau.metawerx.net/> | Old Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau>
Reply | Threaded
Open this post in threaded view
|

Re: <i18n dev> ResourceBundleControlProvider replacement for java 9?

naoto.sato
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.

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/

I hope that would be useful.

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 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> |  Blog
> <https://rmannibucau.metawerx.net/> | Old Blog
> <http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
> LinkedIn <https://www.linkedin.com/in/rmannibucau>
>
Reply | Threaded
Open this post in threaded view
|

Re: <i18n dev> ResourceBundleControlProvider replacement for java 9?

naoto.sato
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" <[hidden email]
> <mailto:[hidden email]>> 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>>
>
>
Reply | Threaded
Open this post in threaded view
|

Re: <i18n dev> ResourceBundleControlProvider replacement for java 9?

naoto.sato
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" <[hidden email]
> <mailto:[hidden email]>> 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" <[hidden email]
>         <mailto:[hidden email]> <mailto:[hidden email]
>         <mailto:[hidden email]>>> 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>>>
>
>
Reply | Threaded
Open this post in threaded view
|

Re: <i18n dev> ResourceBundleControlProvider replacement for java 9?

Mandy Chung
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" <[hidden email]
>> <mailto:[hidden email]>> 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" <[hidden email]
>>         <mailto:[hidden email]> <mailto:[hidden email]
>>         <mailto:[hidden email]>>> 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>>>
>>
>>

Reply | Threaded
Open this post in threaded view
|

Re: <i18n dev> ResourceBundleControlProvider replacement for java 9?

Mandy Chung


On 1/12/18 11:41 AM, Romain Manni-Bucau wrote:

> Hello
>
> Comments inline
>
> Le 12 janv. 2018 20:07, "mandy chung" <[hidden email]
> <mailto:[hidden email]>> a écrit :
>
>     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?
>
>
> Sure
>
> /opt/App/lib
>   |- team1.jar/com.company.team1.service
>   |- team2.jar/com.company.team2.service
>   `- classes/com.company.team3.service
>

Where is the root resource bundle?  Can you give a name and which is the
application calling getBundle("abc")?

Which one you want to migrate as modules?

Mandy

>
> Assuming service packages use a resource bundle.
>
> Now translations are in http://i18n.company.com/translations and the
> team providing the key/values is team4 with no access to team1, team2
> and team3 sources normally.
>
> That is why the only solution I saw was a javaagent or mvn plugin
> repackaging the app to add bundle providers on the fly but it is not
> satisfying compared to java 8 solution :(. It is also not trivial to
> do it at build time since it assumes you know the packages at compile
> time which can not be the case with such an atchitecture, allowing to
> provide translations after a deployment through the service. Doing it
> at runtime requires to create another root classloader since you
> recreate jars...not satisfying too.
>
> Any solution? Is adding a -XsupportControlProviderForNamedModules not
> doable at all?
>

Reply | Threaded
Open this post in threaded view
|

Re: <i18n dev> ResourceBundleControlProvider replacement for java 9?

Mandy Chung
Let me try to see if I understand your situation correctly.


On 1/12/18 12:59 PM, Romain Manni-Bucau wrote:
> All are com.company.*
>
>>
>> Assuming service packages use a resource bundle.
>>

team1, team2, team3 all uses a resource bundle.  Let's say
com.company.team1.service calls
ResourceBundle.getBundle("com.company.resources.Team1").



>>     Now translations are in http://i18n.company.com/translations
>>     <http://i18n.company.com/translations> and the team providing the
>>     key/values is team4 with no access to team1, team2 and team3
>>     sources normally.
>>

team4 provides the key/values of "com.company.resources.Team1". team4
and team1 will agree on the content of this resource bundle e.g. key
names and the value if any text format.

I assume your ResourceBundleControlProvider implementation returns a
Control instance that implements newBundle method to return a
ResourceBundle for
"com.company.resources.Team1".

One migration solution is to use ResourceBundleProvider.  The steps it
takes are
(1) define a SPI for each bundle named
com.company.resources.spi.Team1Provider
(2) reuse your existing Control.newBundle implementation to implement
ResourceBundleProvider::getBundle to return the requested
ResourceBundle.  This assumes in team4 module
(3) when migrating team1.jar to a named module, the module definition
declares uses com.company.resources.spi.Team1Provider

team4 module can have one single provider implementation for more than
one resource bundle.

Does this help?  I can see it takes some amount of work.  How many
resource bundles do your application have?  It'd be good if you give a
try and send us feedback.

Mandy
Reply | Threaded
Open this post in threaded view
|

Re: <i18n dev> ResourceBundleControlProvider replacement for java 9?

Mandy Chung
team1 has a dependency com.company.resources.spi.Team1Provider which can
be in a separate module (say com.company.resources module) and the
provider implementation will be in team4.  i.e. team1 and team4 both
requires com.company.resources module.


Mandy

On 1/12/18 11:14 PM, Romain Manni-Bucau wrote:

> Hi Mandy,
>
> 3 is the blocker because it creates a dependency to team4 which
> shouldnt be visible. It is provided as a container service if you want
> and other teams have no dependency on it. This means if we need to
> upgrade team4 code then the operation team does it and team1, 2, 3 are
> not affected at all.
>
> In terms of costs it must stay the same. I can imagine a light SPI but
> it already breaks this "container service" rule, plus it requires to
> define hundreds of new classes.
>
> Using a custom classloader with no named module can be a short term
> workaround but is broken if modules use module-info only to define a
> SPI for instance.
>
>
> Le 13 janv. 2018 00:21, "mandy chung" <[hidden email]
> <mailto:[hidden email]>> a écrit :
>
>     Let me try to see if I understand your situation correctly.
>
>
>     On 1/12/18 12:59 PM, Romain Manni-Bucau wrote:
>>     All are com.company.*
>>
>>
>>>
>>>     Assuming service packages use a resource bundle.
>>>
>
>     team1, team2, team3 all uses a resource bundle. Let's say
>     com.company.team1.service calls
>     ResourceBundle.getBundle("com.company.resources.Team1").
>
>
>
>>>         Now translations are in http://i18n.company.com/translations
>>>         <http://i18n.company.com/translations> and the team
>>>         providing the key/values is team4 with no access to team1,
>>>         team2 and team3 sources normally.
>>>
>
>     team4 provides the key/values of "com.company.resources.Team1". 
>     team4 and team1 will agree on the content of this resource bundle
>     e.g. key names and the value if any text format.
>
>     I assume your ResourceBundleControlProvider implementation returns
>     a Control instance that implements newBundle method to return a
>     ResourceBundle for
>     "com.company.resources.Team1".
>
>     One migration solution is to use ResourceBundleProvider.  The
>     steps it takes are
>     (1) define a SPI for each bundle named
>     com.company.resources.spi.Team1Provider
>     (2) reuse your existing Control.newBundle implementation to implement
>     ResourceBundleProvider::getBundle to return the requested
>     ResourceBundle. This assumes in team4 module
>     (3) when migrating team1.jar to a named module, the module
>     definition declares uses com.company.resources.spi.Team1Provider
>
>     team4 module can have one single provider implementation for more
>     than one resource bundle.
>
>     Does this help?  I can see it takes some amount of work.  How many
>     resource bundles do your application have?  It'd be good if you
>     give a try and send us feedback.
>
>     Mandy
>
>

Reply | Threaded
Open this post in threaded view
|

Re: <i18n dev> ResourceBundleControlProvider replacement for java 9?

Mandy Chung


On 1/13/18 9:09 AM, Romain Manni-Bucau wrote:
> Which is where it doesnt work at all because team i < 4 should not
> know anything of team4 code and they cant depend on something created
> after they package which is the case today.
>

There must be a contract on the name of the resource bundle and the name
and semantic of the keys.  Such dependency already exists.  I don't
understand why it's critical to avoid any dependency on the new SPI
classes and this new SPI class represents the bundle name you hardcoded
in the code that calls getBundle.

Mandy

> Said otherwise: being transversal is not possible with modules which
> should be fixed IMHO.
>
> Just for my knowledge: why adding a flag is not an option?
>
> Le 13 janv. 2018 18:05, "mandy chung" <[hidden email]
> <mailto:[hidden email]>> a écrit :
>
>     team1 has a dependency com.company.resources.spi.Team1Provider
>     which can be in a separate module (say com.company.resources
>     module) and the provider implementation will be in team4.  i.e.
>     team1 and team4 both requires com.company.resources module.
>
>
>     Mandy
>
>     On 1/12/18 11:14 PM, Romain Manni-Bucau wrote:
>>     Hi Mandy,
>>
>>     3 is the blocker because it creates a dependency to team4 which
>>     shouldnt be visible. It is provided as a container service if you
>>     want and other teams have no dependency on it. This means if we
>>     need to upgrade team4 code then the operation team does it and
>>     team1, 2, 3 are not affected at all.
>>
>>     In terms of costs it must stay the same. I can imagine a light
>>     SPI but it already breaks this "container service" rule, plus it
>>     requires to define hundreds of new classes.
>>
>>     Using a custom classloader with no named module can be a short
>>     term workaround but is broken if modules use module-info only to
>>     define a SPI for instance.
>>
>>
>>     Le 13 janv. 2018 00:21, "mandy chung" <[hidden email]
>>     <mailto:[hidden email]>> a écrit :
>>
>>         Let me try to see if I understand your situation correctly.
>>
>>
>>         On 1/12/18 12:59 PM, Romain Manni-Bucau wrote:
>>>         All are com.company.*
>>>
>>>
>>>>
>>>>         Assuming service packages use a resource bundle.
>>>>
>>
>>         team1, team2, team3 all uses a resource bundle.  Let's say
>>         com.company.team1.service calls
>>         ResourceBundle.getBundle("com.company.resources.Team1").
>>
>>
>>
>>>>             Now translations are in
>>>>             http://i18n.company.com/translations
>>>>             <http://i18n.company.com/translations> and the team
>>>>             providing the key/values is team4 with no access to
>>>>             team1, team2 and team3 sources normally.
>>>>
>>
>>         team4 provides the key/values of
>>         "com.company.resources.Team1".  team4 and team1 will agree on
>>         the content of this resource bundle e.g. key names and the
>>         value if any text format.
>>
>>         I assume your ResourceBundleControlProvider implementation
>>         returns a Control instance that implements newBundle method
>>         to return a ResourceBundle for
>>         "com.company.resources.Team1".
>>
>>         One migration solution is to use ResourceBundleProvider.  The
>>         steps it takes are
>>         (1) define a SPI for each bundle named
>>         com.company.resources.spi.Team1Provider
>>         (2) reuse your existing Control.newBundle implementation to
>>         implement
>>         ResourceBundleProvider::getBundle to return the requested
>>         ResourceBundle.  This assumes in team4 module
>>         (3) when migrating team1.jar to a named module, the module
>>         definition declares uses com.company.resources.spi.Team1Provider
>>
>>         team4 module can have one single provider implementation for
>>         more than one resource bundle.
>>
>>         Does this help?  I can see it takes some amount of work. How
>>         many resource bundles do your application have?  It'd be good
>>         if you give a try and send us feedback.
>>
>>         Mandy
>>
>>
>