- GraalVM for JDK 21 (Latest)
- GraalVM for JDK 22 (Early Access)
- GraalVM for JDK 20
- GraalVM for JDK 17
- GraalVM 22.3
- GraalVM 22.2
- GraalVM 22.1
- GraalVM 22.0
- GraalVM 21.3
- Dev Build
- Native Image
- Build Configuration
- Tracing Agent
- Native Image Compatibility and Optimization Guide
- Class Initialization in Native Image
- Static Native Images
- Native Image Options
- Native Image Hosted and Runtime Options
- Native Image C API
- Implementing Native Methods in Java with Native Image
- LLVM Backend for Native Image
- Debug Info Feature
- Points-to Analysis Reports
- Using System Properties in Native Images
- Profile-Guided Optimizations
- Memory Management at Image Run Time
- Generating Heap Dumps from Native Images
- JDK Flight Recorder with Native Image
- JCA Security Services on Native Image
- Dynamic Proxy on Native Image
- Java Native Interface (JNI) on Native Image
- Reflection on Native Image
- Accessing Resources in Native Images
- Logging on Native Image
- URL Protocols on Native Image
- Native Image ARM64 Support
- GraalVM Updater
- Languages References
- Embedding Reference
- Polyglot Programming
Native Image Code Style
Source Code Formatting #
The IDE projects generated with
mx ideinit are configured with strict formatting rules.
In Eclipse, when a file is saved, it is automatically formatted according to these rules.
The rule set has grown over time and proved to be useful, but the rules are open for discussion. The configuration includes special comments which can be used to relax checks in particular regions of code.
Source code formatting can be disabled with special comments:
Comment reformatting can be disabled like this:
Checks with Checkstyle #
Checkstyle is used to verify adherence to the style rules.
It can be run manually with
The default Checkstyle rules are defined in
src/com.oracle.svm.core/.checkstyle_checks.xml and define various special comments, including
//Checkstyle: stop method name check
//Checkstyle: resume method name check
and similar commands for other checks that can be disabled (including general
Of course, ensuring a reasonable use of these comments is a matter for code review.
If a project requires a different set of Checkstyle rules, this can be specified in
mx.substratevm/suite.py by changing the value of the project’s
checkstyle attribute (which, by default, references
Specific code files can be excluded from Checkstyle on a directory granularity with a file
Such an exclusion file must contain one directory per line, with paths relative to the project root.
The file must be explicitly added with
git add because git will ignore it by default.
When pulling a changeset which adds or removes Checkstyle XML files, the IDE might show inappropriate style warnings or errors.
This is resolved by running
mx ideinit and cleaning the affected projects.
IDE Integration #
IDE plugins can be helpful in adhering to style rules. Some examples are:
- Eclipse Checkstyle Plugin: reports Checkstyle violations in Eclipse, making it unnecessary to run
mx checkstylemanually. https://checkstyle.github.io/eclipse-cs/
- IntelliJ Eclipse Code Formatter: formats source files in IntelliJ according to Eclipse IntelliJ rules.
This plugin is automatically configured by
mx ideinit. https://github.com/krasa/EclipseCodeFormatter
- IntelliJ Save Actions to automatically format files before saving them. https://github.com/dubreuia/intellij-plugin-save-actions
See the documentation on IDE integration for further suggestions.