JDK-6299235 : User-localized resource files not found after perf optimization for awt/swing resources
  • Type: Bug
  • Component: core-libs
  • Sub-Component: java.util:i18n
  • Affected Version: 6
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • OS: windows_xp
  • CPU: x86
  • Submitted: 2005-07-20
  • Updated: 2015-07-14
  • Resolved: 2005-08-15
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.
JDK 6
6 b48Fixed
Related Reports
Relates :  
JDK-6280517 - Performance: Using ResourceBundle.Control API to speed up the resource bundle search
Description
FULL PRODUCT VERSION :
java version "1.6.0-ea"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.6.0-ea-b43)
Java HotSpot(TM) Client VM (build 1.6.0-ea-b43, mixed mode, sharing)

A DESCRIPTION OF THE PROBLEM :
I have supporting localization of standart Swing dialogs in russian language for distributing with our product. In previous version of JDK you can use both '.class' and '.properties' format of resource. For samplifity we used '.properties' format, but in Mustang this is not working - only '.class' format are supported.

The root of the problem is code in sun.util.CoreResourceBundleControl, which are used in Swing to load bundles:

public List getFormats(String s) {
  return java.util.ResourceBundle.Control.FORMAT_CLASS;
}

If this is intentional change of the behavoir, then documentation should be updated.



REPRODUCIBILITY :
This bug can be reproduced always.

CUSTOMER SUBMITTED WORKAROUND :
Use '.class' format of resource bundles

Release Regression From : 5.0u3
The above release value was the last known release where this 
bug was known to work. Since then there has been a regression.
###@###.### 2005-07-20 10:40:59 GMT
Comments
EVALUATION I would like let the submitter know that overriding any sun.* class files, even though it is a properties file is not a safe thing to do since there is no guarantee that will continue working in the subsequent releases.
12-08-2005
EVALUATION To fall back to the current behavior, I think it may not be a good idea to override "getFormat(String baseName)" in CoreResourceBundleControl. So for our own provided awt/swing resources, CoreResourceBundleControl will tell the ResourceBundle to look up the resources from a certain list of locales returned from CoreReesourceBundleControl.getCandidateLocales and it will be found in class file format. If the outside people would like to provide their own resources in properties file format, ResourceBundle code will first fail to find the resource in class file format and then if not succeed, they are going to search properties file. In which case, they won't be benifit from the optimization put in bug 6280517. So the fix is to remove the overrided method of "getFormat(...)" from CoreResourceBundleControl class. ###@###.### 2005-07-20 21:31:02 GMT
20-07-2005