Bug ID: JDK-4314141 Need full specification of ResourceBundle.getBundle

Type: Bug
Component: core-libs
Sub-Component: java.util:i18n
Affected Version: 1.1,1.1.6,1.2.2,1.3.0

Priority: P4
Status: Resolved
Resolution: Fixed
OS: generic,windows_95,windows_nt
CPU: generic,x86

Submitted: 2000-02-19
Updated: 2000-03-24
Resolved: 2000-03-24

Other
1.4.0 merlinFixed

The specification for java.util.ResourceBundle.getBundle is inadequate,
resulting in differing implementation behavior in various releases of the
JRE/J2RE and numerous bug reports. Here's a summary of the problems:

- The method specifications themselves specify nothing beyond parameter
types and some thrown exceptions. All relevant information is scattered
throughout the class description and even the descriptions of related
classes such as PropertyResourceBundle.

- The documentation doesn't fully specify when and under which conditions
getBundle looks for .properties files. The implemented behavior has
changed between releases, giving rise to several bug reports.

- The specification doesn't explain where and how getBundle looks for
.properties files; and how class loaders and the class path affect the search.

- Parts of the documentation sound like there must be one subclass per
locale; that's not true when .properties files are used.

- The documentation may (and should) be interpreted to say that the base
name passed into getBundle must be a fully qualified class name.
However, it is fuzzy enough that developers have interpreted it to allow
for the path name of a properties file (e.g., "myPackage/MyBundle"). The
implementations did not reject such strings and have, to varying
degrees, been successful at loading properties resource bundles given
such strings.

- The documentation doesn't specify the lookup for requested locales where some of the components (language, country, variant) are empty strings. For example, for Locale("", "", "EURO"), some implementations would look for a bundle with the extension "___EURO", others wouldn't; some would, as a fallback, look for the extension "_", other's wouldn't.

- The documentation does not specify at all how the resource bundle parent
chain is set up, and implementations have varied over time. The
documentation in version 1.2, however, added a note warning that
complete sets of bundles must be provided "or the resource bundle lookup
won't work right". This warning doesn't actually apply to all versions
of the class.

- The documentation is self-contradictory with respect to the
accessibility requirements on resource bundle classes: "[the base class]
must also be accessable by your code; it cannot be a class that is
private to the package where ResourceBundle.getBundle is called.". The
implementation depends on the class being accessible from
java.util.ResourceBundle, that is, public. Developers have complained
about this requirement, but there's no known way for ResourceBundle to
create an instance of a package-private class outside java.util.

- Two of the three getBundle variants declare an unchecked exception using
the throws clause. This is unnecessary and considered poor programming
practice.

- The documentation doesn't mention that results may be cached and the
same resource bundle instances returned repeatedly.

- The class description includes the forward-looking statement "Once
serialization is fully integrated, we will provide another way". Such
statements, even if they did reflect our true intentions, have no place
in a specification.

- The class description includes information about the use of this class
in the implementation of some other classes. Such information has no place
in a specification.

CONVERTED DATA BugTraq+ Release Management Values COMMIT TO FIX: merlin FIXED IN: merlin INTEGRATED IN: merlin
14-06-2004
SUGGESTED FIX From the PropertyResourceBundle description in the Java 2 Platform specification ( http://java.sun.com/products/jdk/1.3/docs/api/java/util/PropertyResourceBundle.html), remove the section starting with "The resource bundle name that you pass..." and ending with "...the desired name". Instead, add a sentence "See ResourceBundle.getBundle for a complete description of the search and instantiation strategy." In the ListResourceBundle description in the Java 2 Platform specification ( http://java.sun.com/products/jdk/1.3/docs/api/java/util/ListResourceBundle.html), change the sample classes MyResource and MyResource_fr to be public. Implementation: The proposed specification largely reflects the implementation in J2RE 1.3. The only change affects the candidate bundle names for requested locales where some of the components (language, country, variant) are empty strings, followed by non-empty strings. For example, for Locale("", "", "EURO"), the implementation in J2RE 1.3 would look for the extensions "___EURO", "__", and "_", while the new specification only allows "___EURO". This change has been implemented by Norbert, and affects six lines of pure Java code. Reviewed by Specification and code changes have been reviewed by Brian Beck. Risk assessment: There are two main risks: 1.compatibility with existing callers that rely on certain undocumented characteristics of currently available implementations that the new specification makes illegal 2.compliance of currently available implementations with the new specification Generally, the new specification tries to minimize compatibility risks at the cost of increased compliance risk. The general rule is that if some previous implementation of the J2RE had succeeded with loading a resource bundle, then the new specification should not prevent this. There are two exceptions to this rule: We don't allow passing in null as the class loader, because this gave callers access to classes they would not otherwise have access to, and thus presented a security issue. In 1.2, null was accepted. We specify to omit candidate bundle names where the final component is null (see "Implementation" for more information). Some, but not all, previous implementations would in some situations attempt to instantiate bundles with these names. Describing in which situations this might happen would complicate the specification even yet more, and it is very unlikely that anybody ever made use of this feature. We have to assume that no currently available implementation fully complies with the new specification. SQE (product testing) impact: Currently available tests for ResourceBundle should continue to work, but the test suite should be enhanced to test the complete specification. A regression test to verify the proposed implementation change exists. Approved by Shuna Wu. JCK (compatibility testing) impact: The JCK should be enhanced to test the complete specification of ResourceBundle.getBundle. Approved by Gauri Sharma: "We do not expect existing tests to be affected, though new tests should be developed to cover new spec. New tests will be developed for JCK-Merlin." Doc impact: The javadoc changes have been reviewed and approved by Doug Kramer and Alan Sommerer. The Tutorial section about the ResourceBundle class at http://java.sun.com/docs/books/tutorial/i18n/resbundle/concept.html should be updated to reflect the change in the introductory paragraphs, that does no longer assume that each member in a resource bundle family is represented by a separate class. Localization impact: None. Internationalization impact: ResourceBundle is a core part of the internationalization support in the Java platform, and the lack of clear documentation for it and the variations in its behavior have been an obstacle in the internationalization efforts of our customers. This change should significantly improve the situation. Security impact: None. Legal impact: None.
11-06-2004
SUGGESTED FIX API Change Request: Need full specification of ResourceBundle.getBundle Problem The specification for java.util.ResourceBundle.getBundle is inadequate, resulting in differing implementation behavior in various releases of the JRE/J2RE and numerous bug reports. Here's a summary of the problems: The method specifications themselves specify nothing beyond parameter types and some thrown exceptions. All relevant information is scattered throughout the class description and even the descriptions of related classes such as PropertyResourceBundle. The documentation doesn't fully specify when under which conditions getBundle looks for .properties files. The implemented behavior has changed between releases, giving rise to several bug reports. The specification doesn't explain where and how getBundle looks for .properties files; and how class loaders and the class path affect the search. Parts of the documentation sound like there must be one subclass per locale; that's not true when .properties files are used. The documentation may (and should) be interpreted to say that the base name passed into getBundle must be a fully qualified class name. However, it is fuzzy enough that developers have interpreted it to allow for the path name of a properties file (e.g., "myPackage/MyBundle"). The implementations did not reject such strings and have, to varying degrees, been successful at loading properties resource bundles given such strings. The documentation doesn't specify the lookup for requested locales where some of the components (language, country, variant) are empty strings. For example, for Locale("", "", "EURO"), some implementations would look for a bundle with the extension "___EURO", others wouldn't; some would, as a fallback, look for the extension "_", other's wouldn't. The documentation does not specify at all how the resource bundle parent chain is set up, and implementations have varied over time. The documentation in version 1.2, however, added a note warning that complete sets of bundles must be provided "or the resource bundle lookup won't work right". This warning doesn't actually apply to all versions of the class. The documentation does not specify whether null may be passed in as the class loader. The implementation in 1.2 allowed this, and then fell back to using the system class loader using the security privileges of ResourceBundle. Since this gave clients access to resources that they would not otherwise have access to, we changed the implementation in 1.3 to disallow null. The documentation is self-contradictory with respect to the accessibility requirements on resource bundle classes: "[the base class] must also be accessable by your code; it cannot be a class that is private to the package where ResourceBundle.getBundle is called.". The implementation depends on the class being accessible from java.util.ResourceBundle, that is, public. Developers have complained about this requirement, but there's no known way for ResourceBundle to create an instance of a package-private class outside java.util. Two of the three getBundle variants declare an unchecked exception using the throws clause. This is unnecessary and considered poor programming practice. On the other hand, the method descriptions don't mention any other exceptions, and don't mention under which cicumstances exceptions are thrown. The documentation doesn't mention that results may be cached and the same resource bundle instances returned repeatedly. The class description includes the forward-looking statement "Once serialization is fully integrated, we will provide another way". Such statements, even if they did reflect our true intentions, have no place in a specification. The class description includes information about the use of this class in the implementation of some other classes. Such information has no place in a specification. RFE 4314141 - Need full specification of ResourceBundle.getBundle Requestors Norbert Lindenberg, three customers. Proposed specification change In the ResourceBundle description in the Java 2 Platform specification ( http://java.sun.com/products/jdk/1.3/docs/api/java/util/ResourceBundle.html), replace the two paragraphs from "One resource bundle is" to "may contain Abbrechen" with: Resource bundles belong to families whose members share a common base name, but whose names also have additional components that identify their locales. For example, the base name of a family of resource bundles might be "MyResources". The family should have a default resource bundle which simply has the same name as its family - "MyResources" - and will be used as the bundle of last resort if a specific locale is not supported. The family can then provide as many locale-specific members as needed, for example a German one named "MyResources_de". Each resource bundle in a family contains the same items, but the items have been translated for the locale represented by that resource bundle. For example, both "MyResources" and "MyResources_de" may have a String that's used on a button for canceling operations. In "MyResources" the String may contain "Cancel" and in "MyResources_de" it may contain "Abbrechen". Remove the following sections: The paragraphs from the one starting "The first argument specifies..." to the one starting "Note: ResourceBundle are used internally...". The paragraph starting "NOTE: You should always supply...". The sentence "(Once serialization is fully integrated, we will provide another way.)". The sentence "Also notice that because you specify an en_GB resource bundle, you also have to provide a default en resource bundle even though it inherits all its data from the root resource bundle." Change the sample classes MyResource and MyResources to be public and not abstract. Change the specification of the ResourceBundle.getBundle methods to be: getBundle public static final ResourceBundle getBundle(String baseName) Gets a resource bundle using the specified base name, the default locale, and the caller's class loader. Calling this method is equivalent to calling getBundle(baseName, Locale.getDefault(), this.getClass().getClassLoader()), except that getClassLoader() is run with the security privileges of ResourceBundle. See getBundle for a complete description of the search and instantiation strategy. Parameters: baseName - the base name of the resource bundle, a fully qualified class name Returns: a resource bundle for the given base name and the default locale Throws: NullPointerException - if baseName is null MissingResourceException - if no resource bundle for the specified base name can be found getBundle public static final ResourceBundle getBundle(String baseName, Locale locale) Gets a resource bundle using the specified base name and locale, and the caller's class loader. Calling this method is equivalent to calling getBundle(baseName, locale, this.getClass().getClassLoader()), except that getClassLoader() is run with the security privileges of ResourceBundle. See getBundle for a complete description of the search and instantiation strategy. Parameters: baseName - the base name of the resource bundle, a fully qualified class name locale - the locale for which a resource bundle is desired Returns: a resource bundle for the given base name and locale Throws: NullPointerException - if baseName or locale is null MissingResourceException - if no resource bundle for the specified base name can be found getBundle public static ResourceBundle getBundle(String baseName, Locale locale, ClassLoader loader) Gets a resource bundle using the specified base name, locale, and class loader. Conceptually, getBundle uses the following strategy for locating and instantiating resource bundles: getBundle uses the base name, the specified locale, and the default locale (obtained from Locale.getDefault) to generate a sequence of candidate bundle names. If the specified locale's language, country, and variant are all empty strings, then the base name is the only candidate bundle name. Otherwise, the following sequence is generated from the attribute values of the specified locale (language1, country1, and variant1) and of the default locale (language2, country2, and variant2): baseName + "_" + language1 + "_" + country1 + "_" + variant1 baseName + "_" + language1 + "_" + country1 baseName + "_" + language1 baseName + "_" + language2 + "_" + country2 + "_" + variant2 baseName + "_" + language2 + "_" + country2 baseName + "_" + language2 baseName Candidate bundle names where the final component is an empty string are omitted. For example, if country1 is an empty string, the second candidate bundle name is omitted. getBundle then iterates over the candidate bundle names to find the first one for which it can instantiate an actual resource bundle. For each candidate bundle name, it attempts to create a resource bundle: First, it attempts to load a class using the candidate bundle name. If such a class can be found and loaded using the specified class loader, is assignment compatible with ResourceBundle, is accessible from ResourceBundle, and can be instantiated, getBundle creates a new instance of this class and uses it as the result resource bundle. Otherwise, getBundle attempts to locate a property resource file. It generates a path name from the candidate bundle name by replacing all "." characters with "/" and appending the string ".properties". It attempts to find a "resource" with this name using ClassLoader.getResource. (Note that a "resource" in the sense of getResource has nothing to do with the contents of a resource bundle, it is just a container of data, such as a file.) If it finds a "resource", it attempts to create a new PropertyResourceBundle instance from its contents. If successful, this instance becomes the result resource bundle. If no result resource bundle has been found, a MissingResourceException is thrown. Once a result resource bundle has been found, its parent chain is instantiated. getBundle iterates over the candidate bundle names that can be obtained by successively removing variant, country, and language (each time with the preceding "_") from the bundle name of the result resource bundle. As above, candidate bundle names where the final component is an empty string are omitted. With each of the candidate bundle names it attempts to instantiate a resource bundle, as described above. Whenever it succeeds, it calls the previously instantiated resource bundle's setParent method with the new resource bundle. Implementations of getBundle may cache instantiated resource bundles and return the same resource bundle instance multiple times. They may also vary the sequence in which resource bundles are instantiated as long as the selection of the result resource bundle and its parent chain are compatible with the description above. The baseName argument should be a fully qualified class name. However, for compatibility with earlier versions, Sun's Java 2 runtime environments do not verify this, and so it is possible to access PropertyResourceBundles by specifying a path name (using "/") instead of a fully qualified class name (using "."). Example: The following class and property files are provided: MyResources.class, MyResources_fr_CH.properties, MyResources_fr_CH.class, MyResources_fr.properties, MyResources_en.properties, MyResources_es_ES.class. The contents of all files are valid (that is, public non-abstract subclasses of ResourceBundle for the ".class" files, syntactically correct ".properties" files). The default locale is Locale("en", "UK"). Calling getBundle with the shown locale argument values instantiates resource bundles from the following sources: Locale("fr", "CH"): result MyResources_fr_CH.class, parent MyResources_fr.properties, parent MyResources.class Locale("fr", "FR"): result MyResources_fr.properties, parent MyResources.class Locale("de", "DE"): result MyResources_en.properties, parent MyResources.class Locale("en", "US"): result MyResources_en.properties, parent MyResources.class Locale("es", "ES"): result MyResources_es_ES.class, parent MyResources.class The file MyResources_fr_CH.properties is never used because it is hidden by MyResources_fr_CH.class. Parameters: baseName - the base name of the resource bundle, a fully qualified class name locale - the locale for which a resource bundle is desired loader - the class loader from which to load the resource bundle Returns: a resource bundle for the given base name and locale Throws: NullPointerException - if baseName, locale, or loader is null MissingResourceException - if no resource bundle for the specified base name can be found Since: 1.2
11-06-2004
EVALUATION Will be fixed in Merlin. norbert.lindenberg@Eng 2000-02-18
18-02-2000

Duplicate :	JDK-4336465 - missing exception information for ResourceBundle.getBundle()
Duplicate :	JDK-4408405 - ResourceBundle.getBundle() doc: state whether Locale or ClassLoader can be null
Duplicate :	JDK-4263567 - ResourceBundle description should mention name of property file
Duplicate :	JDK-4175845 - properties file location (in CLASSPATH) undocumented
Duplicate :	JDK-4028735 - ResourceBundle may have undocumented feature