OK, I will clarify the method description of getBundle(String, Locale,
Module) as follows:
diff -r 290145dc2c96
src/java.base/share/classes/java/util/ResourceBundle.java
--- a/src/java.base/share/classes/java/util/ResourceBundle.java
+++ b/src/java.base/share/classes/java/util/ResourceBundle.java
@@ -972,7 +972,11 @@
* equivalent to calling {@link #getBundle(String, Locale,
ClassLoader)
* getBundle(baseName, targetLocale, module.getClassLoader()} to load
* resource bundles that are visible to the class loader of the given
- * unnamed module.
+ * unnamed module. The <a href="#default_behavior">default behavior</a>
+ * of resource bundle loading can be modified with custom {@link
+ * ResourceBundleControlProvider} implementations. Refer to the
+ * description of <a href="#modify_default_behavior">modifying the
default
+ * behavior</a>.
*
* @param baseName the base name of the resource bundle,
* a fully qualified class name
Naoto
On 01/23/2017 10:51 AM, Mandy Chung wrote:
On Jan 23, 2017, at 9:14 AM, Naoto Sato <naoto.s...@oracle.com> wrote:
http://cr.openjdk.java.net/~naoto/8172365/webrev.05/
The fix is to reinstate the code that has been removed with 8171189,
with modification to load implementations with ServiceLoader.load()
method. That way, SPI implementations can be searched on application's
class path.
This change is reasonable. The custom control provider can only be used for
loading of resource bundles in unnamed modules which maintains JDK 8 behavior.
For the getBundle factory methods taking Module parameter, I suggest to explain
the spec to clarify that the custom control provider will be used to load the
resource bundle if the specified module is unnamed module.
Otherwise looks good.
Mandy
