JDK-4416354 : Design flaw in java.util.ResourceBundle
  • Type: Enhancement
  • Component: core-libs
  • Sub-Component: java.util:i18n
  • Affected Version: 1.3.0
  • Priority: P3
  • Status: Closed
  • Resolution: Duplicate
  • OS: generic
  • CPU: generic
  • Submitted: 2001-02-16
  • Updated: 2001-02-22
  • Resolved: 2001-02-22
Related Reports
Duplicate :  
Description

Name: ssT124754			Date: 02/16/2001


java version "1.2.3"

There is a flaw in the implementations of ResourceBundle and
PropertyResourceBundle which makes it difficult to extend ResourceBundle while
leveraging its bundle-finding code.

I needed to extend ResourceBundle to make a class which
locates and loads XML files (in much the same way that a
PropertyResourceBundle finds and loads .properties files).

I assumed that studying the implementation of PropertyResourceBundle
would yield the "right" way to implement this, one which leverages
as much of the existing framework as possible.

I was disappointed to discover that the functionality which SHOULD be
implemented in PropertyResourceBundle is actually hard-coded into the base
class, ResourceBundle. Consider the implementation
of ResourceBundle.findBundle():

            // Next search for a Properties file.
            searchName = baseFileName + localeStr + ".properties";
	    final String resName = searchName;

The implementation makes it difficult to extend ResourceBundle without
duplicating a fair amount of the base class's code. Sun has the luxury of
tweaking the base class to get desired functionality in subclasses, but a Java
developer does not.
 
I imagine this was done because the ResourceBundle class does not expose the
granular functionality that would allow subclasses to leverage and extend the
bundle-finding logic. The findBundle() method is rather long and I think it
could be broken up and exposed without violating any representation invariants.
(Review ID: 117103) 
======================================================================

Comments
WORK AROUND Name: ssT124754 Date: 02/16/2001 Cut and paste this code into your own implementations? Not sure... ======================================================================
11-06-2004

EVALUATION Substantially the same request as 4403721. norbert.lindenberg@Eng 2001-02-22
22-02-2001