嵌入IBM i RPGIV的iText代码关闭文档时触发空指针异常求助

Let's break down this issue step by step, since the exception stack trace gives us some key clues that point away from a core iText problem and toward the IBM i RPGIV/JNI integration layer:

Key Observations from the Exception Stack #

Exception in thread "main"# START NON-TRANSLATABLEjava.lang.NullPointerException at java.lang.String.compareToIgnoreCase(String.java:603) at java.io.BufferedOutputStream.flushBuffer(BufferedOutputStream.java:94) at java.io.BufferedOutputStream.flush(BufferedOutputStream.java:152) at com.itextpdf.text.pdf.OutputStreamCounter.flush(OutputStreamCounter.java:89) at com.itextpdf.text.DocWriter.close(DocWriter.java:233) at com.itextpdf.text.pdf.PdfWriter.close(PdfWriter.java:1341) at com.itextpdf.text.pdf.PdfDocument.close(PdfDocument.java:901) at com.itextpdf.text.Document.close(Document.java:415)

• First, the # START NON-TRANSLATABLE marker is specific to IBM i's character set translation infrastructure—this immediately flags that the problem is tied to how RPGIV/JNI is handling encoding conversion between UTF-8 (used by iText) and EBCDIC (IBM i's native charset).
• The NPE occurs in String.compareToIgnoreCase, but the call chain starts in BufferedOutputStream.flushBuffer. This is not standard JDK behavior: the default BufferedOutputStream implementation does not invoke string comparison logic during flushing. This means the BufferedOutputStream instance in your environment is likely a custom IBM i-specific implementation that adds charset translation hooks, and one of the string variables used in that translation logic is null.

Why This Is Unlikely to Be a Core iText Issue #

iText's core classes like OutputStreamCounter, DocWriter, and PdfWriter only delegate to the underlying OutputStream for flush/close operations. They do not perform any string comparison logic themselves, nor do they interact with IBM i's translation markers like # START NON-TRANSLATABLE. In standard Java environments, closing an iText document never triggers this type of exception.

Recommended Troubleshooting Steps #

• Validate the OutputStream from RPGIV: The root cause is almost certainly in the stream you're passing to PdfWriter from RPGIV. Test by replacing the RPGIV-provided stream with a pure Java FileOutputStream (bypassing RPGIV/JNI) and see if the close operation works without exceptions. If it does, the problem is isolated to your RPGIV stream wrapper.
• Check for Uninitialized String Variables in Translation Logic: IBM i's charset translation layer may be using a string (e.g., a charset name) that's not properly initialized in your RPGIV code. Look for any code that handles encoding conversion between EBCDIC and UTF-8, and ensure all string parameters are non-null.
• Explicitly Set JVM Charset Parameters: Try launching your Java process with explicit encoding flags, e.g., -Dfile.encoding=UTF-8 or -Dibm.stream.nio.charset=IBM-1047 (adjust to your EBCDIC variant) to see if this resolves the null reference in translation.
• Review IBM i Documentation for # START NON-TRANSLATABLE: This marker is used to indicate sections of data that should not be converted between charsets. Ensure your RPGIV code isn't incorrectly inserting this marker into the stream, or that the translation layer isn't misinterpreting iText's binary PDF output as translatable text (PDF is binary, not plain text, so charset translation should not be applied to it at all).

内容的提问来源于stack exchange，提问作者Jorge Ubeda