Backend Selection

Choose a backend from deployment constraints and measured workload, not from the expectation that native code is always faster.

Path	Best fit	Runtime cost	Ownership
bluetape4k-images	portable filters, transforms, analysis, JVM services	JDK 25; no libvips	JVM values and caller-owned streams
JDK 25 JVips JNI (legacy java21 artifact)	native resize, thumbnail, crop, encode on JDK 25	system libvips and JNI	close every VipsImage
JDK 25 FFM	native processing on a JDK 25 deployment	system libvips and native-access flag	close every image and manage runtime shutdown

Choose Scrimage when

The application needs the broad immutable-image helpers, Java2D drawing, filter DSL, similarity algorithms, OCR input, or a deployment with no native package. It is also the simplest first implementation and the reference path for the basic workshop.

Choose libvips when

The workload is dominated by native-supported resize, crop, thumbnail, or encoding operations and the service can install and monitor libvips. Validate the exact codec on the target host. Library support and the host libvips build are separate facts.

Choose JDK 25 JVips JNI when the application can provide system libvips and wants the legacy JNI binding. Choose JDK 25 FFM when JDK 25 and —enable-native-access=ALL-UNNAMED are part of the deployment contract.

Avoid accidental dual backends

Do not place both native implementations on the normal runtime classpath merely for convenience. Keep the common Vips API at compile time and select one implementation deliberately. A migration can run both in a benchmark or validation environment, but production ownership must remain explicit.

Decide with evidence

Use the repository benchmark as directional evidence, then measure representative images, concurrency, file and network boundaries, and memory in the real service. See performance selection.

Sources

• Release backend overview
• Benchmark documentation