JDK-8190696 : ResourceBundleControlProvider no more usable
  • Type: Enhancement
  • Component: core-libs
  • Sub-Component: java.util:i18n
  • Affected Version: 9
  • Priority: P3
  • Status: Resolved
  • Resolution: Not an Issue
  • OS: generic
  • CPU: generic
  • Submitted: 2017-11-02
  • Updated: 2018-11-30
  • Resolved: 2017-11-03
Related Reports
Relates :  
JDK-8193680 - Migration issues due to ResourceBundleControlProvider no more being usable in JDK 9
Description
FULL PRODUCT VERSION :
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)

A DESCRIPTION OF THE PROBLEM :
java.util.spi.ResourceBundleControlProvider made possible to plug some custom logic to load the resource bundles in Java 8.

In Java 9 and with named modules this is no more possible without changing all the code making impossible to migrate some code and to cover the same features (before you were able to switch the way bundles were loaded without modifying caller code).

This is a huge regression blocking Java 9 migrating and there is no real reason it is not possible. Can you please ensure it is still possible to override the way the bundles are loaded without any code change?

I didn't find any valid reason to have the isNamed test injava.util.ResourceBundle#getDefaultControl(java.lang.Module, java.lang.String) and it would be fixing the regressin to remove the test and always call ResourceBundleControlProviderHolder.getControl.

Thanks,
Romain

REGRESSION.  Last worked in version 8u162

ADDITIONAL REGRESSION INFORMATION: 
Implement a ResourceBundleControlProvider hardcoding a custom bundle in provider.jar, then create a module (module.jar) using java.util.ResourceBundle#getBundle(java.lang.String) for instance and name this module. Run module.jar code with whatever JVM setup and see that  the custom bundle is never loaded.


REPRODUCIBILITY :
This bug can be reproduced always.
Comments
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
Additional Information from submitter: Small addition: Java 9 introduced the new ResourceBundleProvider but it doesn't cover the same scope than ResourceBundleControlProvider: 1. you must create a provider class from the bundle name (so no way to use an implementation globally 2. you must register in your module-info the implementation as a SPI (uses XProvider + provides XProvider with XProvider) Except this looks complicated for what it finally does it also completely remove the ability to plug a custom resolution strategy globally and transparently. However the API is simpler to implement so allowing to plug globally this new provider can be a solution too. Also having a fallback between both can be nice and add some backward compatibility too.
24-11-2017
ResourceBundleControlProvider was disabled in named modules, due to Jigsaw's resource encapsulation requirement: http://openjdk.java.net/projects/jigsaw/spec/reqs/#resource-encapsulation A workaround is to keep the provider implementation in an unnamed module, then put the jar file on application's classpath.
03-11-2017