JDK-4303146 : (rb) RFE:ResourceBundle should allow developers to define their own search strategies
  • Type: Enhancement
  • Component: core-libs
  • Sub-Component: java.util:i18n
  • Affected Version: 5.0,6
  • Priority: P4
  • Status: Resolved
  • Resolution: Fixed
  • OS:
    generic,linux_redhat_7.2,solaris_8,windows_nt,windows_2000,windows_xp generic,linux_redhat_7.2,solaris_8,windows_nt,windows_2000,windows_xp
  • CPU: generic,x86,sparc
  • Submitted: 2000-01-07
  • Updated: 2005-05-23
  • Resolved: 2005-05-23
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
6 b38Fixed
Related Reports
Duplicate :  
Duplicate :  
Duplicate :  
Duplicate :  
Duplicate :  
Duplicate :  
Duplicate :  
Duplicate :  
Relates :  
Relates :  
Relates :  
ResourceBundle currently searches for classes/property files using a hard-coded, static algorithm based on the name of the ResourceBundle and the appropriate Locale. It searches for bundles by concatenating various permutations of the Locale identifier to the classname. 

Some developers would like the ability to define their own search strategies. For example, they would like to search for bundles in different packages, using the same bundle name. For example, getBundle("MyBundle", Locale.US) might look for this class in the following way:
1. search for packageA.res.en_US.MyBundle
2. then packageA.res.en.MyBundle
3. packageA.res.<default  locale>.MyBundle
4. etc.
3. then packageA.res.MyBundle

Or perhaps they would like the bundles to exist in a database structure of some kind.

EVALUATION Consider post 1.4. john.oconner@Eng 2001-03-08 Name: nl37777 Date: 11/12/2002 Two other concrete examples have come up: - The JavaServer Pages Standard Tag Library has specified and implemented its own lookup strategy, which takes into consideration multiple request locales (coming from the browser), an application-defined fallback locale, but not the JRE's default locale. - A number of developers have indicated that they use property resource bundles only and therefore don't want the overhead of looking for class-based resource bundles first. ====================================================================== A problem is that the current spec doesn't clarify the difference between the search paths of loading bundles and finding a resource in getObject (and its friends). Because a ResourceBundle can't have mutiple parents (i.e., multiple getObject paths), a resulting ResourceBundle may not have an expected getObject path. For example, if the path "zh_TW" -> base bundle is requested but "zh_TW" has been loaded as zh_TW -> zh -> base bundle, the loaded zh_TW bundle isn't what's been requested. Also, the current spec allows a loaded bundle to set up its own parent(s). Should getBundle be able to change the setup? ###@###.### 2004-06-01 Introduced new nested class ResourceBundle.Control that allows you to customize the bundle lookup. Please refer to its API doc for detail. ###@###.### 2005-05-17 03:01:54 GMT

CONVERTED DATA BugTraq+ Release Management Values COMMIT TO FIX: mustang