United StatesChange Country, Oracle Worldwide Web Sites Communities I am a... I want to...
JDK-4655819 : REGRESSION: Collator uses default rules regardless of Locale

Details
Type:
Bug
Submit Date:
2002-03-21
Status:
Resolved
Updated Date:
2002-10-07
Project Name:
JDK
Resolved Date:
2002-10-07
Component:
core-libs
OS:
windows_2000
Sub-Component:
java.text
CPU:
x86
Priority:
P3
Resolution:
Fixed
Affected Versions:
1.4.0
Fixed Versions:
1.4.2 (mantis)

Related Reports
Relates:
Relates:

Sub Tasks

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
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
=====================
                                     
2002-05-20
CONVERTED DATA

BugTraq+ Release Management Values

COMMIT TO FIX:
mantis

FIXED IN:
mantis

INTEGRATED IN:
mantis
mantis-b03


                                     
2004-06-14



Hardware and Software, Engineered to Work Together