Bug 53494 - CellFormat throws NPE for date formats with locale codes
Summary: CellFormat throws NPE for date formats with locale codes
Status: RESOLVED LATER
Alias: None
Product: POI
Classification: Unclassified
Component: HSSF (show other bugs)
Version: 3.9-FINAL
Hardware: PC All
: P2 normal (vote)
Target Milestone: ---
Assignee: POI Developers List
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2012-07-02 02:36 UTC by Trejkaz (pen name)
Modified: 2016-06-09 06:38 UTC (History)
0 users



Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Trejkaz (pen name) 2012-07-02 02:36:19 UTC
A cell format such as:

    [$-409]mmmm dd yyyy  h:mm AM/PM

should format explicitly in English. A cell format such as:

    [$-804]mmmm dd yyyy  h:mm AM/PM

should format in Chinese (although in an inappropriate order for Chinese.)

When I do this using POI though, CellFormat.apply(double) or CellFormat.apply(Cell) throw NullPointerException for both formats.
Comment 1 Nick Burch 2012-07-02 09:21:20 UTC
Could you try with a recent nightly build / svn checkout? There was a fix for locales in formats a few weeks ago, which may have solved this too.

If the problem still remains with a recent build, could you please post the full stacktrace, and ideally a unit test that highlights the problem?
Comment 2 Trejkaz (pen name) 2012-07-02 23:06:56 UTC
Current trunk build seems to be broken.

/Data/Projects/vendor/poi/trunk/build.xml:412: taskdef class org.apache.xmlbeans.impl.tool.XMLBean cannot be found
 using the classloader AntClassLoader[/Data/Projects/vendor/poi/trunk/ooxml-lib/xmlbeans-2.3.0.jar:/Data/Projects/vendor/poi/trunk/ooxml-lib/stax-api-1.0.1.jar]

Searching on Google found a post which suggests that xmlbeans-2.3.0.jar might be corrupt. It is in fact corrupt, but after deleting it, another corrupt copy is downloaded the next time I run the build. :/
Comment 3 Nick Burch 2012-07-02 23:18:08 UTC
Could you perhaps have a broken webproxy in front of you, which is wrecking your downloads?

I'd suggest you either download the jar manually, or download an older binary/source release and grab a known good jar out of that
Comment 4 Trejkaz (pen name) 2012-07-02 23:21:56 UTC
Manually downloaded that file and another one which the build downloaded a corrupt copy of. And no, there is no web proxy in front of me at all. There might be one in front of the mirror server which the build is downloading from.

Looks like the issue still occurs (same NullPointerException.)
Comment 5 Nick Burch 2012-07-02 23:26:58 UTC
Any chance of the full stacktrace so we can see where the NPE is triggered, and ideally also a unit test?
Comment 6 Trejkaz (pen name) 2012-07-02 23:52:57 UTC
    @Test
    public void testCellFormatDateLocales() throws Exception
    {
        CellFormat englishFormat = CellFormat.getInstance("[$-409]mmmm dd yyyy  h:mm AM/PM");
        assertThat(englishFormat.apply(26995.477777777778).text, is(equalTo("November 27 1973  11:28 AM")));

        CellFormat chineseFormat = CellFormat.getInstance("[$-804]mmmm dd yyyy  h:mm AM/PM");
        assertThat(chineseFormat.apply(26995.477777777778).text, is(equalTo("\u5341\u4E00\u6708 27 1973  11:28 \u4E0A\u5348")));
    }

This should be enough to reproduce it. I'm not 100% sure if the expected text is exactly correct because I took this double value from the debugger while our own test was running and floating point often ruins precision...
Comment 7 Trejkaz (pen name) 2013-02-05 06:11:56 UTC
Still occurs in 3.9, but the stack trace is different now, now the NPE is in CellFormat.getApplicableFormatPart(CellFormat.java:365)
Comment 8 Nick Burch 2014-07-30 19:02:17 UTC
Thanks for the test

I've added a slightly modified form in r1614741, which shows that trunk is now able to parse these style of formats without error
Comment 9 Trejkaz (pen name) 2016-06-09 06:38:58 UTC
We now get a different problem on the exact same test case we posted in the comment here, but I'll open a new ticket about it, since it at least isn't a NPE anymore.