XSSFCellStyle::getFontIndex return short and actually cast return of getFontId() (actually int) to short. Moreover, getFontId cast long CTXfImpl::getFontId to int. So in some cases we have double-overflow (long -> int -> short) which cause ArrayIndexOfBoundsException while trying to autoSizeColumns Stacktrace: java.lang.ArrayIndexOutOfBoundsException: -32765 at java.util.ArrayList.elementData(Unknown Source) at java.util.ArrayList.get(Unknown Source) at org.apache.poi.xssf.model.StylesTable.getFontAt(StylesTable.java:204) at org.apache.poi.xssf.usermodel.XSSFWorkbook.getFontAt(XSSFWorkbook.java:809) at org.apache.poi.xssf.usermodel.XSSFWorkbook.getFontAt(XSSFWorkbook.java:106) at org.apache.poi.ss.util.SheetUtil.getCellWidth(SheetUtil.java:124) at org.apache.poi.ss.util.SheetUtil.getColumnWidth(SheetUtil.java:229) at org.apache.poi.xssf.usermodel.XSSFSheet.autoSizeColumn(XSSFSheet.java:398)
I've had a go at creating a unit test for this problem in r1824451, but it isn't triggering the bug, despite creating 50,000 fonts Could you take a look at that test, and suggest what we need to do to re-produce the bug you're seeing?
I independently put together a change to use ints instead of shorts for indexing fonts. https://github.com/apache/poi/pull/102 Still would be good to have a reproducible test case though.
Since the font index value is an xsd:unsignedInt, maybe a long is the appropriate data type. I know Java 8 kinda halfheartedly supports unsigned ints by adding some methods that treat an int as unsigned to the Integer class. maybe that will be sufficient here. It just seems to be a kludge to me. If we go with the Java 8 view of unsigned int we need to make sure to document that the font index is an unsigned int rather than the typical signed int.
Java 8's unsigned int support is not at all nice. We have limitations about supporting long - eg a lot of the XSSF clases used Lists and this has the method `E get(int index);` I would argue that the pragmatic solution is to just support ints and not worry too much about the the fact that max-unsigned-int is aprox twice max-signed-int. It's taken this long for someone to run into the `short` limitation.
Dmytro Sylaiev - could you test with the latest code? Some changes were added to support ints instead of shorts?
Could you please share latest snapshot?
Look at https://builds.apache.org/view/P/view/POI/job/POI-DSL-1.8/lastSuccessfulBuild/artifact/ for latest build results.
added a fix for the junit test via r1839709 and probably fixed the issue via r1839710
The code that is involved in the stacktrace in the original report now uses int and style.getFontIndexAsInt(), so the casting to short does not happen any more. If there is still a problem please report a new bug with a reproducible test-case as reproducing the problem seems to be harder than thought.
See also r1824826