AbstractMethodError on XSSFColor.getStoredRGB() when using custom fill color with Poiji 4.1.1 on classpath

1 day ago 1
ARTICLE AD BOX

Problem

I'm trying to set a custom hex color (#00458D) on Excel header cells using Apache POI in a Spring Boot project. The only approach that works without throwing an error is using an indexed color:

headerStyle.setFillForegroundColor(IndexedColors.DARK_BLUE.getIndex()); headerStyle.setFillPattern(FillPatternType.SOLID_FOREGROUND);

But I need the exact color #00458D, so I tried the following:

Attempt 1 : ARGB hex:

XSSFColor myColor = new XSSFColor(); myColor.setARGBHex("ff00458d"); headerStyle.setFillForegroundColor(myColor);

Attempt 2 : java.awt.Color:

headerStyle.setFillForegroundColor(new XSSFColor(new java.awt.Color(0, 69, 141), new DefaultIndexedColorMap())); headerStyle.setFillPattern(FillPatternType.SOLID_FOREGROUND);

Attempt 3 : byte array with IndexedColorMap:

IndexedColorMap colorMap = sheet.getWorkbook().getStylesSource().getIndexedColors(); XSSFColor color = new XSSFColor(new byte[]{0, 69, (byte)141}, colorMap); headerStyle.setFillForegroundColor(color); headerStyle.setFillPattern(FillPatternType.SOLID_FOREGROUND);

All three throw the same error:

java.lang.AbstractMethodError: Receiver class org.apache.poi.xssf.usermodel.XSSFColor does not define or inherit an implementation of the resolved method 'abstract byte[] getStoredRGB()' of abstract class org.apache.poi.ss.usermodel.ExtendedColor. at org.apache.poi.ss.usermodel.ExtendedColor.getRGBOrARGB(ExtendedColor.java:100) at org.apache.poi.xssf.usermodel.XSSFColor.getARGB(XSSFColor.java:203) at org.apache.poi.xssf.usermodel.XSSFColor.sameARGB(XSSFColor.java:392) at org.apache.poi.xssf.usermodel.XSSFColor.equals(XSSFColor.java:423) at org.apache.poi.xssf.usermodel.extensions.XSSFCellFill.equals(XSSFCellFill.java:186) at org.apache.poi.xssf.model.StylesTable.putFill(StylesTable.java:529) at org.apache.poi.xssf.usermodel.XSSFCellStyle.setFillPattern(XSSFCellStyle.java:1002)

Root Cause (I think)

I have Poiji 4.1.1 on the classpath:

<dependency> <groupId>com.github.ozlerhakan</groupId> <artifactId>poiji</artifactId> <version>4.1.1</version> <scope>compile</scope> </dependency>

Poiji bundles its own Apache POI jars internally. This creates a classpath conflict — at runtime, the XSSFColor from Poiji's older bundled POI gets loaded, which does not implement getStoredRGB() that was added as an abstract method in the newer ExtendedColor class. So any attempt to instantiate XSSFColor with a custom RGB color triggers this AbstractMethodError inside setFillPattern().


Constraint

I know the clean fix is to add POI exclusions to the Poiji dependency:

<exclusions> <exclusion> <groupId>org.apache.poi</groupId> <artifactId>poi</artifactId> </exclusion> <exclusion> <groupId>org.apache.poi</groupId> <artifactId>poi-ooxml</artifactId> </exclusion> </exclusions>

However, this is a large existing project with a lot of Excel functionality already built and in production. Changing the dependency configuration is not an option right now.


Question

Is there any way to apply a custom RGB color (#00458D) to an XSSFCellStyle fill that completely avoids instantiating XSSFColor — for example through raw CTFill / CTStylesheet XML manipulation or any other approach — so the classpath version conflict is never triggered?

Any help is appreciated.

Read Entire Article