JDK-4655819 : REGRESSION: Collator uses default rules regardless of Locale
  • Type: Bug
  • Component: core-libs
  • Sub-Component: java.text
  • Affected Version: 1.4.0
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • OS: windows_2000
  • CPU: x86
  • Submitted: 2002-03-21
  • Updated: 2002-10-07
  • Resolved: 2002-10-07
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.
Other
1.4.2 mantisFixed
Related Reports
Relates :  
Relates :  
Description

Name: nt126004			Date: 03/20/2002


FULL PRODUCT VERSION :
java version "1.4.0"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.0-b92)
Java HotSpot(TM) Client VM (build 1.4.0-b92, mixed mode)

FULL OPERATING SYSTEM VERSION :
Microsoft Windows 2000 [Version 5.00.2195]


A DESCRIPTION OF THE PROBLEM :
Collator instances are not being created with the
appropriate localized ruleset.  Most of the Locales I created 
collators for only had the default ruleset defining their 
collation behavior.  (I didn't test them all, but the ones 
I tested exhibited this problem)

REGRESSION.  Last worked in version 1.3.1

STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
1.Get a collator via Collator.getInstance(Locale l)
(the locales I tested were JAPAN, US, and CHINESE)
2.Get the rules the collator is using ( (RuleBasedCollator)
collator.getRules();
3.Compare the rules of the locales, I just displayed them
in the system console or in a jsp page

EXPECTED VERSUS ACTUAL BEHAVIOR :
I expect to get a collator populated with a japanese
collation ruleset.  I get a collator instantiated with the
default ruleset only.

ERROR MESSAGES/STACK TRACES THAT OCCUR :
No error messages occured.  I suspect this is because the implementation of
Collator.getInstance() will catch the first ParseException thrown by creating a
localized collator, and will only print a stack trace if creating a collator
with the default ruleset fails.

(BTW I was getting a ParseException when I tried to create my own
RuleBasedCollator using the "CollationElements" retrieved directly from the
Japanese ResourceBundle "LocaleElements".

This bug can be reproduced always.

---------- BEGIN SOURCE ----------
import java.util.*;
import java.text.*;

public class SortUtils {
    private static final HashMap cache = new HashMap(5);
    private SortUtils() {}
    
    static final public Collator getCollator(Locale l) {
        Collator c = (Collator)cache.get(l);
        if (c == null) {
            c = createInstance(l);
            cache.put(l, c);
        }
        
        return c;
    }
    
    static final private Collator createInstance(Locale l) {
        Collator rv = Collator.getInstance(l);
        
        String lang = l.getLanguage();
        if (lang.equals( "ja" ) ) {
            rv.setStrength( Collator.PRIMARY );
        }
        
        return rv;
    }

    //This code will print the default rules when compiled and running under
    //jdk 1.4, but it will print a much lenghtier ruleset for Japanese
    //characters when run under 1.3.1
    static final public void main(String[] args) {
        Collator c = SortUtils.getCollator( Locale.JAPAN );
        System.out.println( "Rules:\n" + ((RuleBasedCollator)c).getRules());
    }
}
---------- END SOURCE ----------

Release Regression From : 1.3.1
The above release value was the last known release where this 
bug was known to work. Since then there has been a regression.

(Review ID: 144250) 
======================================================================

Comments
CONVERTED DATA BugTraq+ Release Management Values COMMIT TO FIX: mantis FIXED IN: mantis INTEGRATED IN: mantis mantis-b03
14-06-2004

EVALUATION Confirmed that their is a ParseException when creating RBTable. ###@###.### 2002-05-07 ==================== Appears to be a problem during rule merging. The default rules get merged with the additional rules. At some point during the merge, ParseException is thrown. ###@###.### 2002-05-15 ==================== ==================== Can fix by putting single quotes around the chars that are decomposable. Do this in the LocaleElements_*.java collation rules. One specific character is the NOT EQUALS (\u2260). It has a decomposition mapping in Unicode 3.0. Although this will allow the Collator to use the rules, it still doesn't fix another problem: where should NOT EQUALS be collated? When comparing strings, the Collator uses decomposed strings. That means that no string will ever have the composed NOT EQUALS char in it...the char will be decomposed. How should this sort? ###@###.### 2002-05-20 =====================
20-05-2002