Following previous advice from support, we have packaged the parser and viewer modules in a standalone Java app, the main goal being to avoid crashing the app server when document conversion crashes.
Versions used : 25.9 for viewer and 25.5 for parser.
The resulting module has been working just fine until recently, when a NoClassDefFoundError exception started being raised.
java.lang.ClassNotFoundException: com.groupdocs.parser.licensing.License
at java.net.URLClassLoader.findClass(URLClassLoader.java:387) ~[na:1.8.0_382]
at java.lang.ClassLoader.loadClass(ClassLoader.java:418) ~[na:1.8.0_382]
at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:352) ~[na:1.8.0_382]
After verifying that the class is really there and other attemps at finding the cause failed, we found that the problem seems to be caused by the JVM version :
- JVMs below 1.8.0_372 work just fine
- JVMs above 1.8.0_382 raise the exception
… all using the same app jar; also, the viewer module doeswn’t seem impacted by this; all other document conversions do not raise the exception.
Any help is appeciated.
@stefanu123
What is happening
A java.lang.NoClassDefFoundError (or the underlying ClassNotFoundException) can occur even when the required .class file is physically present in the JAR. In your case the class com.groupdocs.parser.licensing.License is included in the parser JAR, but the runtime cannot locate it [1].
Possible causes to investigate
-
Verify the JAR content – Open the parser JAR (or the shaded “app‑all.jar”) with a zip tool and confirm that com/groupdocs/parser/licensing/License.class is present and has the expected name.
-
Check shading / relocation – If you use a shading plugin (e.g., Gradle shadowJar or Maven shade), ensure that the parser JAR is included unchanged and that no relocate rules affect the com.groupdocs.parser.* packages.
-
Class‑loader usage – Make sure both Viewer and Parser are loaded by the same application class‑loader (the default AppClassLoader). Avoid creating a separate URLClassLoader for one of the modules unless its parent is the same as the one that loaded the other module.
-
Library version alignment – The Viewer 25.9 and Parser 25.5 come from different release cycles. While they often work together, using matching versions (e.g., upgrading the Parser to 25.9) can eliminate edge‑case incompatibilities.
-
Test on the specific JDK – Run the application with the JDK version that shows the failure (1.8.0_382). If the error disappears after applying the steps above, the issue was related to the build or class‑loading configuration.
-
Temporary mitigation – If you cannot change the build immediately, you can run the application on a JDK 8 version that previously worked (≤ 1.8.0_371) or isolate the parser in a separate process invoked via ProcessBuilder.
Next steps
- Re‑package the application following the suggestions above and test on JDK 1.8.0_382.
- If the problem persists, please provide the full stack trace (including any “Caused by” sections) and the exact shading/packaging configuration you are using, so we can look for a more specific incompatibility.
@stefanu123
We have opened the following new ticket(s) in our internal issue tracking system and will deliver their fixes according to the terms mentioned in Free Support Policies.
Issue ID(s): PARSERJAVA-480
You can obtain Paid Support Services if you need support on a priority basis, along with the direct access to our Paid Support management team.
Hi @stefanu123,
Thank you for the detailed report - the JVM versions you narrowed it down to were the key. We have reproduced the problem with GroupDocs.Parser for Java 25.5 and found the cause.
Why it happens
Up to version 26.5 the groupdocs-parser jar was signed with jarsigner, which stores a digest for every entry of the jar in META-INF/MANIFEST.MF. The library has about 146,000 entries, so in 25.5 that file is 19.3 MB.
The July 2023 Java security update (8u381 / 8u382, and also 11.0.20, 17.0.8 and every newer release, including Java 21) limits the size of signature-related files in a jar to 16 MB. A larger file makes the JVM refuse to open the jar, and the class path loader skips such a jar without reporting why. That is why the class is in the jar but cannot be found, and why it works on 8u372 and fails on 8u382. GroupDocs.Viewer is not affected because its signature files stay under the limit.
Workaround for 25.5
Raise the limit with a JVM option when you start the standalone application:
-Djdk.jar.maxSignatureFileSize=20000000
The value is in bytes and has to be larger than the 19.3 MB manifest. We verified that with this option com.groupdocs.parser.licensing.License loads from the 25.5 jar on Java 17 and Java 21. If you cannot change the command line, the option can also be passed through the JAVA_TOOL_OPTIONS environment variable.
Permanent fix
Starting with GroupDocs.Parser for Java 26.9 the jar is no longer signed with jarsigner. It is published with a detached GPG signature (groupdocs-parser-26.9.jar.asc) instead, so its manifest is tiny and it loads on current Java versions without any extra option. We checked the published 26.9 jar on Java 8, 17, 21 and 22.
The issue is tracked as PARSERJAVA-480 and is now resolved.
Please let us know if you still see the error with the option above or with 26.9.