Why Did My Excel Export Suddenly Fail? Debugging EasyPOI & Apache POI Version Conflicts

Background

After taking over the development and maintenance of the Insurance "One‑Line Voice" platform, the first issue encountered was that the event‑to‑Excel export feature stopped working after a recent deployment.

Problem Description

The platform uses easypoi together with apache‑poi to generate Excel files. The feature worked until tasks created after 2024‑04‑12 12:04:39 began failing.

Investigation

3.1 Investigation Process

The failure appeared shortly after a deployment, suggesting the new code caused the issue. However, the changed code had nothing to do with the Excel export logic.

Log inspection revealed an exception:

cn.afterturn.easypoi.exception.excel.ExcelExportException: Excel导出错误
    at cn.afterturn.easypoi.excel.export.ExcelExportService.createSheet(ExcelExportService.java:118)
    ...
Caused by: java.lang.NoSuchMethodError: org.apache.poi.ss.usermodel.CellStyle.setAlignment(S)V
    at cn.afterturn.easypoi.excel.export.styler.ExcelExportStylerDefaultImpl.stringNoneStyle(ExcelExportStylerDefaultImpl.java:69)
    ...

3.2 Dependency Details

The project uses the following Maven dependencies:

<dependency>
  <groupId>org.apache.poi</groupId>
  <artifactId>poi</artifactId>
  <version>4.0.1</version>
</dependency>
<dependency>
  <groupId>org.apache.poi</groupId>
  <artifactId>poi-ooxml</artifactId>
  <version>4.0.1</version>
</dependency>
<dependency>
  <groupId>cn.afterturn</groupId>
  <artifactId>easypoi-spring-boot-starter</artifactId>
  <version>4.0.0</version>
  <exclusions>
    <exclusion>
      <artifactId>guava</artifactId>
      <groupId>com.google.guava</groupId>
    </exclusion>
  </exclusions>
</dependency>

A transitive dependency forced easypoi-base to version 3.2, which contains code that expects older POI constants that were removed in newer POI releases.

The root cause was identified as a Maven build command using the -U flag, which forces snapshot dependencies to be refreshed, unintentionally pulling in newer POI artifacts that lacked the expected constants.

Resolution

4.1 First Upgrade Attempt

Attempting to downgrade POI caused additional compatibility problems, so the team upgraded to easypoi 4.5.0 and apache‑poi 5.0.0. This introduced a new set of errors.

4.2 Second Failure

After the upgrade, intermittent tasks hung and logs showed another NoSuchMethodError related to CTFont.addNewFamily():

2024-06-25 20:38:04.730 ERROR ... java.lang.NoSuchMethodError: org.openxmlformats.schemas.spreadsheetml.x2006.main.CTFont.addNewFamily()Lorg/openxmlformats/schemas/spreadsheetml/x2006/main/CTFontFamily;
    at org.apache.poi.xssf.usermodel.XSSFFont.setFamily(XSSFFont.java:635)
    ...

The conflict stemmed from two POI artifacts: poi‑ooxml‑lite:5.0.0 and poi‑ooxml‑schemas:4.1.1. The method exists only in the newer artifact, causing inconsistent behavior between local and production environments.

By forcing the application to use the poi‑ooxml‑schemas version locally, the error could be reproduced, confirming the dependency clash.

4.3 Final Fix

The solution was to align all POI‑related dependencies to compatible versions. Referring to the official easypoi 4.5.0 POM, the team settled on easypoi 4.5.0 together with apache‑poi 4.1.1, ensuring that the transitive POI libraries matched the expected API.

After updating the pom.xml with these versions and redeploying, the Excel export functionality worked reliably.