JDK-8193680 : Migration issues due to ResourceBundleControlProvider no more being usable in JDK 9
  • Type: Enhancement
  • Component: core-libs
  • Sub-Component: java.util:i18n
  • Affected Version: 9,10
  • Priority: P3
  • Status: Closed
  • Resolution: Incomplete
  • OS: linux
  • CPU: x86_64
  • Submitted: 2017-12-15
  • Updated: 2018-11-30
  • Resolved: 2017-12-18
Related Reports
Relates :  
Description
FULL PRODUCT VERSION :
Any java 9

java version "9.0.1"
Java(TM) SE Runtime Environment (build 9.0.1+11)
Java HotSpot(TM) 64-Bit Server VM (build 9.0.1+11, mixed mode)

for instance

A DESCRIPTION OF THE PROBLEM :
I'm creating this issue to follow on http://bugs.java.com/bugdatabase/view_bug.do?bug_id=JDK-8190696 which did NOT resolve the bug and abusively closed the ticket.

Factually Java 9 broke a feature for all applications preventing all ALL the code to be migrated on Java 9 and therefore adopt the platform.

There is no technical reason to do that (encapsulation is not technically valid since a custom classloader already breaks it fo rinstance).

This is a significant regression and breakage so please provide a way to fix it and at least a way to plug globally a ResourceBundleProvider (or control provider) to fix that blocking issue.

REGRESSION.  Last worked in version 8u162

STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
Implement a custom ResourceBundleControlProvider and set it up on the JVM.

EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
All ResourceBundle usages - including named modules -  should use the ResourceBundleControlProvider.
ACTUAL -
For named modules it is ignored.

REPRODUCIBILITY :
This bug can be reproduced always.


Comments
Can you ask the submitter to bring their scenario to i18n-dev for discussion? If think they are looking for migration options in the event that they migrate their code to modules.
10-01-2018

From submitter: > "If the submitter is migrating to modules then code using RB.Control will need changes. This is expected, all the details are documented in the ResurceBundle spec." Issue is there is NO migration possible to switch the RB lookup logic on java 9 named modules from outside the module and globally (in a transversal manner). This is the very impacting regression the JVM introduced and should be fixed IMHO.
10-01-2018

The latest information from the submitter suggests it's a dynamic environment. This should work on JDK 9 in the same way as it does in JDK 8 and older releases. There is no evidence in the bug report that there is a regression. I think the submitter is migrating code depending on ResourceBundleControlProvider to modules. This migration will need require changes as there are no plans to support ResourceBundleControlProvider with named modules.
03-01-2018

From submitter: Basically I set on a most of the apps I manage a global provider which reads all the application bundles from either a local directory - but not the classpath - or a rest service. What is important is to not impact the application code and be able to do it tranversally for all modules of all teams of the company. The control part is not much important for me and the java 9 resource bundle provider is cloer to ly need assuming it can be set globally on the jvm and outside modules (not in module info). Let me know if you need more information, the only workaround i thought about is a javaagent generating the resource bundle provider on the fly but it costs too much in term of startup time overhead and jar inspection.
22-12-2017

I agree with Mandy, this is not a regression. If the submitter is using RB.Control with JDK 8 then it should work in JDK 9 when deployed in the same way. If the submitter is migrating to modules then code using RB.Control will need changes. This is expected, all the details are documented in the ResurceBundle spec.
19-12-2017

Close as incomplete for now to request the submitter for describing their use case detailed information. We should re-open it once we receive the information.
18-12-2017

Existing ResourceBundleControlProvider implementation works as in JDK 8 when the code calling ResourceBundle::getBundle is deployed on the class path (or unnamed module). So this is not a regression. This is an enhancement request to support ResourceBundleControlProvider to support migration to modules. There are several ways for RB.getBundle to locate resource bundles in other named modules or locating from class path other than converting to ResourceBundleProvider. Please describe your use case in further details why and how you use ResourceBundleControlProvider. For example, what does the custom Control instance provided by ResourceBundleControlProvider do? Does it alter the candidate locale list? Where does it find the resource bundles? How many resource bundles does your application have?
18-12-2017