Bug 62996

Summary: Unit tests fail in TestExcelStyleDateFormatter for locale zh_CN (Zulu JDK)
Product: POI Reporter: Axel Howind <axel>
Component: POI OverallAssignee: POI Developers List <dev>
Status: RESOLVED FIXED    
Severity: normal    
Priority: P2    
Version: 4.0.0-FINAL   
Target Milestone: ---   
Hardware: PC   
OS: All   
Attachments: Fix for compilation on JDK 11 without tweaking locale properties

Description Axel Howind 2018-12-10 06:54:42 UTC 
Running `ant test` fails like this:

Testcase: test60369 took 0.013 sec
	FAILED
Failed testDates for locale zh, provider: null and date Sat Jan 12 00:00:00 CET 1980, having: 1月 expected:<19968> but was:<57345>
junit.framework.AssertionFailedError: Failed testDates for locale zh, provider: null and date Sat Jan 12 00:00:00 CET 1980, having: 1月 expected:<19968> but was:<57345>
	at org.apache.poi.ss.usermodel.TestExcelStyleDateFormatter.test60369(TestExcelStyleDateFormatter.java:82)
	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
	at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)

This might even be dependent on the JDK used. I have tried with Zulu OpenJDK:
openjdk version "11.0.1" 2018-10-16 LTS
OpenJDK Runtime Environment Zulu11.2+3 (build 11.0.1+13-LTS)
OpenJDK 64-Bit Server VM Zulu11.2+3 (build 11.0.1+13-LTS, mixed mode)


This issue seems to be the same as #60369 but this time with a chinese locale. The test checks the first character of the month name, in this case "一月“ where '一' is the chinese character for 1 (one). The actual result is "1月". Both are common in China (hey, this is the first time studying chines comes in handy while working with POI). There's an answer to a question on stackoverflow suggesting that it's implementation defined which characters are used for month names in this case.

I don't know what Excel does, and if it differs between Excel and/or operating system versions, so this test should either be changed to accept both values for the chinese locale or POI has to produce an output consistent with Excel.

Related: #51847, #60369

#51847: https://bz.apache.org/bugzilla/show_bug.cgi?id=51847
#60369: https://bz.apache.org/bugzilla/show_bug.cgi?id=60369
Stackoverflow: https://stackoverflow.com/questions/24862866/dateformatsymbols-behavior-is-different-between-android-and-jre-1-7
Comment 1 Axel Howind 2018-12-10 15:16:27 UTC 
Created attachment 36318 [details]
Fix for compilation on JDK 11 without tweaking locale properties

I have now tested with Zulu, Oracle's OpenJDK build and Oracle JDK. Test fails with all three different JDKs in version 11.0.1. The exact version is actually 11.0.1+13 for all three JDKs.

The test code already accounts for different characters to be used in chinese. It is done using this check:

    /**
     * Depending on the JRE version, the provider setting and the locale, a different result
     * is expected and selected via an index
     */
    private int localeIndex(Locale locale) {
        final String provider = System.getProperty("java.locale.providers");
        return jreVersion < 12 ||
            !locale.equals (Locale.CHINESE) ||
            (provider != null && provider.startsWith("JRE"))
            ? 0 : 1;
    }

I have also seen in the Jenkins [logs](https://builds.apache.org/view/P/view/POI/job/POI-DSL-1.11/19/consoleFull) that the locale providers are overridden:
-Djava.locale.providers=JRE,CLDR

Now consider the description of the [LocaleServiceProvider](https://docs.oracle.com/en/java/javase/11/docs/api/java.base/java/util/spi/LocaleServiceProvider.html):

> Java Runtime Environment provides the following four locale providers:
> 
> "CLDR": A provider based on Unicode Consortium's CLDR Project.
> "COMPAT": represents the locale sensitive services that is compatible with the prior JDK releases up to JDK8 (same as JDK8's "JRE").
> "SPI": represents the locale sensitive services implementing the subclasses of this LocaleServiceProvider class.
> "HOST": A provider that reflects the user's custom settings in the underlying operating system. This provider may not be available, depending on the Java Runtime Environment implementation.
> "JRE": represents a synonym to "COMPAT". This name is deprecated and will be removed in the future release of JDK.

What happens is that the Jenkins build explicitly tells (by means of -D...) the LocaleProvider to be consistent with prior Java versions (i.e. before JDK 8). 

This patch should fix JDK 11 builds (and hopefully not break any others) without setting `java.locale.providers`.

**Note:** Depending on current build options, the `-Djava.locale.providers=...`has to be removed from the build.
Comment 2 PJ Fanning 2018-12-10 15:46:47 UTC 
trying change - via https://svn.apache.org/viewvc?view=revision&revision=1848591
Comment 3 Dominik Stadler 2018-12-21 07:40:31 UTC 
The suggested patch seems to be applied now, so we should be fine here, or?

Thus resolving this, please reopen if there is more work necessary here.