-
Bug
-
Resolution: Fixed
-
P3
-
1.1
-
b53
-
x86
-
windows_95
Name: bb33257 Date: 11/25/97
We have an architectural anomaly in ResourceBundle and its
children that should be cleaned up in JDK 1.2. Unfortunately, it
requires API changes.
The basic issue is this: ResourceBundle has built into it the
concept of inheritance. ResourceBundle.getObject() is written to
automatically search the bundle's parent for any resources it
doesn't find-- subclasses override a different method,
handleGetObject(), to perform the search in the current object,
so all subclasses of ResourceBundle get this inheritance behavior
for free.
The problem is that ResourceBundle.getKeys() is not architected
similarly. Semantically, getKeys() should return a list of all
keys that can be passed to that bundle's getObject() method
without getting a MissingResourceException. But
ResourceBundle.getKeys() is abstract, placing the burden of
handling the inheritance behavior on the subclass. This is
inconsistent with the design of getObject(), will force a fair
amount of redundant code to be written, and is potentially
error-prone. We need to go to something which is parallel to the
way getObject()/handleGetObject() is done and which puts the
responsibility for handling inheritance in ResourceBundle rather
than in the subclasses.
======================================================================
We have an architectural anomaly in ResourceBundle and its
children that should be cleaned up in JDK 1.2. Unfortunately, it
requires API changes.
The basic issue is this: ResourceBundle has built into it the
concept of inheritance. ResourceBundle.getObject() is written to
automatically search the bundle's parent for any resources it
doesn't find-- subclasses override a different method,
handleGetObject(), to perform the search in the current object,
so all subclasses of ResourceBundle get this inheritance behavior
for free.
The problem is that ResourceBundle.getKeys() is not architected
similarly. Semantically, getKeys() should return a list of all
keys that can be passed to that bundle's getObject() method
without getting a MissingResourceException. But
ResourceBundle.getKeys() is abstract, placing the burden of
handling the inheritance behavior on the subclass. This is
inconsistent with the design of getObject(), will force a fair
amount of redundant code to be written, and is potentially
error-prone. We need to go to something which is parallel to the
way getObject()/handleGetObject() is done and which puts the
responsibility for handling inheritance in ResourceBundle rather
than in the subclasses.
======================================================================