Java NoClassDefFoundError exception for GroupDocs parser module

GroupDocs.Parser Product Family
,
1

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.

2

@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

  1. 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.

  2. 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.

  3. 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.

  4. 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.

  5. 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.

  6. 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.