Pure Java Image Library with No JNI
A pure Java image library with no JNI, no native code, and no platform-specific dependencies.
Problems with most Java image libraries
Most Java image libraries are actually JNI wrappers around native C/C++ libraries, which can cause deployment, compatibility, and maintenance headaches.
Native Libraries Can Break Across Platforms
You use a popular image library like ImageMagick, which is C-based and accessed from Java via JNI. You now need to install native binaries (.dll/.so/.dylib). When deploying to a new server or cloud environment (like AWS Lambda, Docker, Kubernetes), the app crashes because the native library isn't installed, the library version doesn't match, and the OS version isn't compatible.
JNI Bugs Can Crash the JVM
You’re using a JNI wrapper for a C/C++ library. However, native code can cause segmentation faults. One small memory bug in C/C++ can crash the whole JVM, taking down your server. Not to mention that debugging these crashes is much harder than debugging pure Java exceptions.
Harder to Package and Deploy on Different Platforms
You package your app as a Spring Boot .jar or as an AWS Lambda function. Now you can’t ship just one .jar, because you need a complicated build process to bundle native binaries, platform-specific installers, and a more complex CI/CD pipeline.
Updates and Maintenance Pain
You update your JDK from Java 17 to Java 21. Then you realize the JNI binding or native library no longer works and you need to rebuild or update native binaries for the new JDK. Java’s forward compatibility breaks because of external native dependencies.
We replaced all our various image processing code with JDeli, which allowed us to smoothly migrate to Java 11. The support from IDR solutions is just great. Whenever we came across a strange image from our customers which JDeli couldn't read properly, IDR fixed it in less than a day.
Developer in SME Financial Services Company
What Pure Java Image Processing Gives You
Security
While other Java image libraries may bring security risks caused by native codes, JDeli benefits from the JVM's safety mechanisms (bounds checking, sandboxing) as it's a pure Java solution.
Portability
JDeli runs on any platform with a JVM and there's no need to compile native libraries for different platforms or architectures.
No Native Dependencies
No JNI glue code is needed. JDeli solves issues with incompatible native libraries, version mismatches, or missing DLLs/SOs.
Easier Deployment
JDeli packages everything in a single .jar or .war file. You don't need to download special installers, or worry about native library paths.
Ease of Maintenance
Pure Java means your stack uses one language throughout. No context-switching between Java debugging and native library debugging.
Future Proof
Native libraries often break on JDK upgrades. Because JDeli has no native layer, upgrading the JDK does not require rebuilding or replacing binaries.
Trusted by Companies around the World
JDeli Guides
Get started with JDeli and see how it fits into your Java stack.
Frequently Asked Questions
What does "pure Java" mean for an image library?
Pure Java means JDeli is written entirely in Java with no JNI bindings, no native binaries (.dll/.so/.dylib), and no system library requirements. It runs on any standard JVM without platform-specific setup.
Does JDeli require any native libraries or JNI?
No. JDeli has no JNI, no native code, and no system library dependencies. It ships as a plain JAR; add it to your classpath and it works. No .so, .dll, or .dylib files, no LD_LIBRARY_PATH setup, no platform-specific build step.
Does JDeli work in Docker or Kubernetes?
Yes. Because JDeli has no native dependencies, it runs in any JVM environment — Docker containers, Kubernetes pods, and serverless platforms like AWS Lambda — without platform-specific configuration.
How does JDeli handle JDK upgrades?
Pure Java libraries are unaffected by the JNI breakages that can come with JDK upgrades. JDeli follows standard Java compatibility and works across JDK versions without requiring native binary rebuilds.
How does JDeli perform compared to native image libraries?
JDeli is consistently faster than alternatives including native-backed libraries. See the performance comparison for benchmarks.
Is JDeli suitable for air-gapped or high-security environments?
Yes. JDeli makes no network calls during operation. There is no licensing server, no telemetry, and no outbound connectivity requirement, making it suitable for government, defence, and high-security financial deployments.
Handle Images Safer and Simpler with JDeli in Java
1.
2.
3.