<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" <mandy.chung at oracle.com 
> <mailto:mandy.chung at oracle.com>> 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
>
>