JDK-8248434 : some newly added locale cannot parse uppercased date string.
  • Type: Bug
  • Component: core-libs
  • Sub-Component: java.text
  • Affected Version: 15
  • Priority: P3
  • Status: Closed
  • Resolution: Fixed
  • OS: generic
  • CPU: generic
  • Submitted: 2020-06-26
  • Updated: 2021-05-25
  • Resolved: 2020-07-23
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 16
16 b08Fixed
Related Reports
CSR :  
Relates :  
Description
A DESCRIPTION OF THE PROBLEM :
Hi.
In your latest jdk15 versions, we found something not quite right.
a related pr is at https://github.com/apache/commons-lang/pull/558
In short, some codes like this cannot pass tests for some Locale like  "ff_LR_#Adlm"
 
BUT in jdk 8-14's all locales can pass the tests, only ones newlly added in jdk15 fails.
I wanna know whether it be by design or just a bug.

REGRESSION : Last worked in version 14.0.1

STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
Run the tests below with Junit.

EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
tests pass
ACTUAL -
tests failed

---------- BEGIN SOURCE ----------
    @Test
    public void java15BuggyLocaleTestAll() throws ParseException {
        for (final Locale locale : Locale.getAvailableLocales()) {
            testSingleLocale(locale);
        }
    }

    @Test
    public void java15BuggyLocaleTest() throws ParseException {
        final String buggyLocaleName = "ff_LR_#Adlm";
        Locale buggyLocale = null;
        for (final Locale locale : Locale.getAvailableLocales()) {
            if (buggyLocaleName.equals(locale.toString())) {
                buggyLocale = locale;
                break;
            }
        }
        if (buggyLocale == null) {
            return;
        }
        testSingleLocale(buggyLocale);
    }

    private void testSingleLocale(Locale locale) throws ParseException {
        final Calendar cal = Calendar.getInstance(GMT);
        cal.clear();
        cal.set(2003, Calendar.FEBRUARY, 10);
        final SimpleDateFormat sdf = new SimpleDateFormat(LONG_FORMAT, locale);
        final String formattedDate = sdf.format(cal.getTime());
        sdf.parse(formattedDate);
        sdf.parse(formattedDate.toUpperCase(locale));
        sdf.parse(formattedDate.toLowerCase(locale));
    }
---------- END SOURCE ----------

FREQUENCY : always



Comments
There has been no response from the submitter after 14 days. Closing the bug.
25-05-2021

Requested the submitter to see if the bug is fixed in the latest build at https://www.oracle.com/java/technologies/javase-jdk16-downloads.html and provide the feedback.
11-05-2021

URL: https://hg.openjdk.java.net/jdk/jdk/rev/2d8c578f1230 User: naoto Date: 2020-07-23 15:57:30 +0000
23-07-2020

Additional Information from Submitter: ============================= You can found the "ff_LR_#Adlm" using following codes: __________ final String buggyLocaleName = "ff_LR_#Adlm"; Locale buggyLocale = null; for (final Locale locale : Locale.getAvailableLocales()) { if (buggyLocaleName.equals(locale.toString())) { buggyLocale = locale; break; } } __________ If in your environment the variable buggyLocale is still null after the loop, then I really have no idea why.
08-07-2020

Decided that it is better to file an RFE for supporting supplementary in String case insensitive operations. New issue is filed as: JDK-8248655. Also, this is not a regression, as ff-Adlm-LR is a new locale in JDK15. Thus removing the regression tag.
01-07-2020

The root cause boils down to the problem with String.regionMatches() with ignoreCase == true, if the string consists of supplementary characters. In this case, characters in Adlam script fail to match case-insensitively. e.g., "\ud83a\udd2e".regionMatches(true, 0, "\ud83a\udd0c", 0, 2) This should return true, because: "\ud83a\udd2e" == 'ADLAM SMALL LETTER O' (U+1E92E) "\ud83a\udd0c" == 'ADLAM CAPITAL LETTER O' (U+1E90C) But in fact, the statement above returns false, despite that "\ud83a\udd2e".toUpperCase(Locale.ROOT).equals("\ud83a\udd0c") Character.toUpperCase(0x1e92e) == 0x1e90c each statement correctly returns true.
28-06-2020

Test with oracle JDK 15 build 29 and open JDK 15 build 29 on win10-x64, this issue can be reproduced. Test case please refer to attachment Test.java
28-06-2020

I was not able to reproduce the issue in Oracle JDK 15. As per https://github.com/apache/commons-lang/pull/558 : "This error is caused by a new added locale (in the latest versions of java15) called "ff_LR_#Adlm"." After iterating over all the locales existing in the JDK, I was not able to find the locale 'ff_LR_Adlm'. Moving it to dev team for further analysis.
27-06-2020