https://blog.devops-monk.com/tags/native/Recent content in Native on Devops MonkHugoen-usMon, 04 May 2026 00:00:00 +0000https://blog.devops-monk.com/tutorials/java17/foreign-function-memory/Mon, 04 May 2026 00:00:00 +0000https://blog.devops-monk.com/tutorials/java17/foreign-function-memory/Incubator Feature in Java 17 (JEP 412 — First Incubator). Package: jdk.incubator.foreign. Requires --add-modules jdk.incubator.foreign at compile and runtime. This API evolved significantly across Java 18 (JEP 419), 19 (JEP 424), 20 (JEP 434), and was finalized in Java 22 (JEP 454). See the Java 21 article series for the final API. This article covers the Java 17 incubator version and the Project Panama vision. Why Replace JNI? Java Native Interface (JNI) has been the way to call native code from Java since Java 1.https://blog.devops-monk.com/tutorials/java21/foreign-function-memory/Mon, 04 May 2026 00:00:00 +0000https://blog.devops-monk.com/tutorials/java21/foreign-function-memory/Preview Feature in Java 21 — Finalized in Java 22 (JEP 454). The API shown here is the Java 21 preview version; it is nearly identical to the final API. Why Replace JNI? Java Native Interface (JNI) has been the standard way to call native code since Java 1.1. It works but is notoriously painful: Requires writing C wrapper code for every native call Native method signatures must exactly match Java declarations (or you get silent crashes) Memory management is manual — leak native memory once and you have a slow memory leak JNI calls disable JIT optimizations around the call site Debugging native crashes through JNI is extremely difficult The Foreign Function & Memory (FFM) API replaces all of this: call native functions directly from Java, manage native memory safely with automatic lifetime management, and do it without writing a single line of C.https://blog.devops-monk.com/tutorials/spring-boot/spring-boot-graalvm-native/Sun, 03 May 2026 00:00:00 +0000https://blog.devops-monk.com/tutorials/spring-boot/spring-boot-graalvm-native/A regular Spring Boot application takes 2–10 seconds to start. A GraalVM native image of the same application starts in under 100 milliseconds. For serverless functions, batch jobs, and CLI tools, this is the difference between viable and unusable. What Is a Native Image? GraalVM’s native image compiler performs ahead-of-time (AOT) compilation. Instead of shipping a JAR that the JVM interprets at runtime, you ship a standalone executable that: Contains only the code your application actually uses Has no JVM startup overhead Uses much less memory (no JIT compiler, no class metadata) Starts in milliseconds The tradeoff: compile time increases from seconds to minutes.