Re: 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" > 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" mailto:naoto.s...@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/

     >

     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


>

         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
         ou

Re: 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" > 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" mailto:naoto.s...@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/

>

     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

>

         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
    specifi

Re: 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" > 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?

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

Re: [10] RFR: 8187946 : Support ISO 4217 Amendments 163 and 164

[Leo Jiang]

Hi Naoto,

Thank you for review.

- Added the updates for currency names, removed the cut-over time for STN.
- For compatibility reason, we don't update the historic currencies.

Test passed.

Please find the revised webrev:
http://cr.openjdk.java.net/~ljiang/8187946/webrev.01/

Thanks,
Leo


On 01/13/2018 04:13 AM, Naoto Sato wrote:

Hi Leo,

Here are my comments:

(for amendments 163)

- Names not reflected correctly: "Azerbaijan Manat", "Lao Kip".

(for amendments 164)
- Since it's already passed the transition date for STN, you don't need to use the transition format (at line 
473:CurrencyData.properties)


- Lacking the Philippines currency name change: "Amended currency name for PHILIPPINES (THE): Philippine Piso (instead 
of Peso)"


- Lacking historic currency changes, e.g., ALBANIA-Old_Lek-ALK-008.

Naoto

On 1/12/18 6:51 AM, Leo Jiang wrote:

Hi,

Please review the currency data update to support ISO 4217 Amendments 163 and 
164.

Please refer the pdf files in bug description for details of this update. In short, we need to update the STD to STN 
and its numeric name, as well as adding a cut-over time for them.


Bug:
https://bugs.openjdk.java.net/browse/JDK-8187946

Webrev:
http://cr.openjdk.java.net/~ljiang/8187946/webrev.00/

Built and test passed on Mach5.

Thanks,
Leo