The PDFNet SDK Jar File is too Large

Technical Support Apryse SDK
, , ,
1

Question
The PDFNet.jar file included with the PDFNet SDK for Java is quite large (over 150 MB). We’re integrating Apryse into a Spring Boot application using Maven, and the size of this dependency is significantly impacting our build size and deployment efficiency. Is it possible to include only specific modules or packages required for our use case, or is the PDFNet SDK distributed strictly as a single monolithic JAR?

Answer
The PDFNet.jar file is large by design because it bundles native libraries for all supported operating systems—Windows, Linux, and macOS—into a single JAR for convenience and cross‑platform compatibility.
At this time, the Java SDK is distributed as a single monolithic JAR, and individual Java modules cannot be selectively excluded. However, there is an alternative approach if bundle size is a concern.

Using the Lightweight PDFNet.jar
Apryse provides OS‑specific SDK downloads that include a lightweight version of PDFNet.jar. This version does not bundle native libraries, which significantly reduces its size. Instead, native binaries are shipped separately for the target operating system.
Example (Linux):
The lightweight PDFNet.jar is included in the .NET Core (64‑bit) SDK download:

(You’ll find the smaller PDFNet.jar inside this package.)

:wrench: Configuring Native Libraries
When using the lightweight JAR, you must ensure that the native PDFNet library (for example, libPDFNetC.so on Linux) is available on your system and included in your Java library path.
You can find step‑by‑step instructions for configuring the native library path here:

Summary

  • The standard PDFNet.jar is large because it bundles native libraries for multiple operating systems.

  • The Java SDK does not currently support modular or selective packaging.

  • To reduce dependency size, you can use the lightweight PDFNet.jar from an OS‑specific SDK download.

  • Native libraries must then be deployed and referenced separately via the system library path.

This approach works well for production deployments where the target operating system is known and minimizing artifact size is a priority.