填坑记: 古董项目Apache POI 依赖异常排除

当你看到NoSuchMethodError的时候，不要慌，深呼吸，这可能只是JAR包版本的问题…

引子：一个平静的周二下午

那是一个看似平常的周二下午，系统运行良好，开发团队在有条不紊地推进着新功能的开发。突然，测试环境中的报表导出功能失效了，用户反馈页面卡住，后台日志疯狂刷屏：

java.lang.NoSuchMethodError: 'byte[] org.apache.poi.util.IOUtils.peekFirstNBytes(java.io.InputStream, int)'

作为职业填坑人，我看到这个错误的第一反应是：“这是依赖不对？”

错误分析：深入错误堆栈的兔子洞

先来仔细分析一下错误信息：

Caused by: java.lang.NoSuchMethodError: 'byte[] org.apache.poi.util.IOUtils.peekFirstNBytes(java.io.InputStream, int)'at org.apache.poi.poifs.filesystem.FileMagic.valueOf(FileMagic.java:209)at org.apache.poi.openxml4j.opc.internal.ZipHelper.verifyZipHeader(ZipHelper.java:143)at org.apache.poi.openxml4j.opc.internal.ZipHelper.openZipStream(ZipHelper.java:175)at org.apache.poi.openxml4j.opc.ZipPackage.<init>(ZipPackage.java:130)at org.apache.poi.openxml4j.opc.OPCPackage.open(OPCPackage.java:319)at ca.terrasoft.poi.POIUtil.openFile(POIUtil.java:57)

从堆栈可以看出：

系统试图调用IOUtils.peekFirstNBytes方法
该方法在运行时的类路径中不存在
错误发生在处理Excel文件时（看调用链包含openFile和ZipPackage）

这应该是一个典型的JAR包版本不一致问题。简单说，代码期望调用的方法在运行时环境中找不到，通常是因为编译时使用的库版本与运行时加载的版本不同。

侦探工作：寻找证据

由于项目是一个20年前的古董JSP项目，没有使用Maven、Gradle等现代构建工具，所有依赖都直接堆在WEB-INF/lib目录下。我们只能通过手动和脚本方式排查依赖。

直接检查WEB-INF/lib目录

$ ls -la /webapps/myapp/WEB-INF/lib/poi-*.jar
.....
-rw-r--r-- 1 tomcat tomcat 2758112 May 10 14:32 poi-5.2.3.jar

表面上看，POI的版本是5.2.3，应该没问题,会不会是某个古董jar中可能有依赖老版本poi，那咋整? 一个一个去翻所有jar包? 嗯嗯，这好像不是码农该做的事。

终极武器：编写诊断JSP页面

为了更详细地了解web容器中类加载情况，直接整一个简单的诊断页面：

<%@ page import="java.net.URL" %>
<%@ page import="java.util.Enumeration" %>
<%@ page import="java.io.File" %>
<%@ page contentType="text/html;charset=UTF-8" language="java" %>
<html>
<head><title>Classpath Info</title></head>
<body>
<h1>Classpath Information</h1>
<h2>Finding POI libraries:</h2>
<ul><%// 查找指定类的位置try {Class<?> clazz = Class.forName("org.apache.poi.util.IOUtils");out.println("<li>IOUtils class found at: " + clazz.getProtectionDomain().getCodeSource().getLocation() + "</li>");// 查找方法是否存在try {clazz.getDeclaredMethod("peekFirstNBytes", java.io.InputStream.class, int.class);out.println("<li>peekFirstNBytes method exists!</li>");} catch (NoSuchMethodException e) {out.println("<li>peekFirstNBytes method NOT found!</li>");}} catch (Exception e) {out.println("<li>Error: " + e.getMessage() + "</li>");}%>
</ul><h2>All POI related JARs:</h2>
<ul><%ClassLoader cl = Thread.currentThread().getContextClassLoader();try {Enumeration<URL> resources = cl.getResources("META-INF/MANIFEST.MF");while (resources.hasMoreElements()) {URL url = resources.nextElement();String path = url.getPath();if (path.contains("poi")) {out.println("<li>" + path + "</li>");}}} catch (Exception e) {out.println("<li>Error: " + e.getMessage() + "</li>");}%>
</ul>
</body>
</html>

运行后，页面输出：

IOUtils class found at: file:/Users/xdev/workdir/myProject/classes/artifacts/myProject_war_exploded/WEB-INF/lib/tm-extractors.jar
* peekFirstNBytes method NOT found! .

这说明，虽然我们有poi-5.2.3.jar，但实际被加载的IOUtils类却来自tm-extractors.jar！

版本考古学：揭开历史的面纱

进一步到Maven仓库查询tm-extractors.jar（https://mvnrepository.com/artifact/org.textmining/tm-extractors/0.4），发现它自带了poi-2.5.1.jar，而且tm-extractors的发布时间非常久远。

也就是说，tm-extractors.jar中自带的老版本POI类覆盖了新版本POI的类加载，导致我们即使有poi-5.2.3.jar，实际运行时却用的是2.5.1的实现，自然没有peekFirstNBytes方法。