<i18n dev> ResourceBundleControlProvider replacement for java 9?
mandy.chung at oracle.com
Sat Jan 13 19:35:48 UTC 2018
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.
> 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" <mandy.chung at oracle.com
> <mailto:mandy.chung at oracle.com>> 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.
> 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
>>>> 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.
>> 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
>> One migration solution is to use ResourceBundleProvider. The
>> steps it takes are
>> (1) define a SPI for each bundle named
>> (2) reuse your existing Control.newBundle implementation to
>> 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.
More information about the i18n-dev