|
| 1 | +--- |
| 2 | +title: GraalVM Native |
| 3 | +sidebar: |
| 4 | + order: 18.5 |
| 5 | +--- |
| 6 | + |
| 7 | +MyBatis-Plus adds support for GraalVM Native Image, allowing eligible projects to build native executables with faster startup and lower runtime memory usage. |
| 8 | + |
| 9 | +## Feature Overview |
| 10 | + |
| 11 | +- **Native Image build**: Works with GraalVM Native Image to compile an application into a platform-specific native executable. |
| 12 | +- **Spring AOT integration**: In Spring Boot 3 AOT scenarios, framework runtime hints such as reflection and resource access can be registered during build analysis. |
| 13 | +- **Simplified deployment**: The generated artifact can run directly without the full JVM startup flow, making it suitable for cloud native, Serverless, container, and startup-sensitive workloads. |
| 14 | + |
| 15 | +## Prerequisites |
| 16 | + |
| 17 | +- Use a JDK that supports Native Image, such as GraalVM JDK. |
| 18 | +- The project uses Spring Boot 3.x or another build system that supports GraalVM Native Image. |
| 19 | +- The MyBatis-Plus version includes GraalVM Native Image support. |
| 20 | + |
| 21 | +:::note |
| 22 | + |
| 23 | +Native Image performs closed-world analysis at build time. Custom reflection, dynamic proxies, resource files, Mapper XML files, serialization types, and similar project-specific code may still need extra configuration if they are outside the framework's automatic registration scope. |
| 24 | + |
| 25 | +::: |
| 26 | + |
| 27 | +## Build Example |
| 28 | + |
| 29 | +For Maven projects, use Spring Boot Native Build Tools: |
| 30 | + |
| 31 | +```bash |
| 32 | +mvn -Pnative native:compile |
| 33 | +``` |
| 34 | + |
| 35 | +After a successful build, run the generated native executable directly: |
| 36 | + |
| 37 | +```bash |
| 38 | +./target/demo |
| 39 | +``` |
| 40 | + |
| 41 | +To build a container image, use the Spring Boot plugin: |
| 42 | + |
| 43 | +```bash |
| 44 | +mvn -Pnative spring-boot:build-image |
| 45 | +``` |
| 46 | + |
| 47 | +## Notes |
| 48 | + |
| 49 | +- Native image builds usually take much longer than regular JVM Jar builds. Consider configuring a separate CI build task. |
| 50 | +- Dynamic SQL, XML Mapper files, custom TypeHandlers, and custom interceptors can still be used, but make sure the related classes and resources can be analyzed by AOT or explicitly registered. |
| 51 | +- Native executables are tied to the target operating system and CPU architecture, so build them in a matching environment. |
| 52 | +- During development, JVM mode is still recommended for debugging. Run Native Image builds as part of release verification. |
0 commit comments