Spring Graal Native 0.6.0 已经发布，这是一个实验性项目，旨在简化 Spring 应用程序构建 GraalVM 原生镜像的过程

Spring Graal Native 0.6.0 的官方文档和相关资料中并未明确列出其支持的具体操作系统。不过，我们可以从 GraalVM 的支持范围来推测 Spring Graal Native 0.6.0 的兼容性。

推测支持的操作系统

Spring Graal Native 0.6.0 依赖于 GraalVM 的 Native Image 功能，因此其支持的操作系统范围与 GraalVM 的支持范围一致：

• Linux：
  • x86_64 架构：完全支持。
  • AArch64 架构：自 GraalVM 21.0 起支持，但存在一些限制。
• macOS：完全支持。
• Windows：完全支持，但需要安装 Microsoft Visual C++ (MSVC) 并使用 x64 Native Tools Command Prompt。

注意事项

• 依赖 GraalVM 版本：Spring Graal Native 0.6.0 支持 GraalVM 20.0.0。
• 具体限制：在 AArch64 架构上，必须禁用 -R:[+|-]WriteableCodeCache，不支持 musl 作为 C 标准库，且不支持 G1 垃圾收集器。

如果需要更详细的支持信息，建议参考 GraalVM 的官方文档或 Spring Graal Native 的 GitHub 仓库。

Spring Graal Native 0.6.0 发布

Spring Graal Native 0.6.0 已经发布，这是一个实验性项目，旨在简化 Spring 应用程序构建 GraalVM 原生镜像的过程。以下是该版本的主要特点和相关信息：

主要功能

• 支持 GraalVM 20.0.0：Spring Graal Native 0.6.0 支持 GraalVM 20.0.0。
• 支持 Spring Boot 2.3.0.M3：该项目与 Spring Boot 2.3.0.M3 兼容。
• 静态化分析：通过静态化分析，确保所有可能在运行时使用的代码都在编译阶段被处理，从而实现快速启动。
• 优化性能：原生编译的应用程序通常具有更好的内存管理和更低的 CPU 使用率。

使用方法

• 依赖配置：在 Maven 项目中，可以通过添加以下依赖来使用 Spring Graal Native：

  <dependency>
      <groupId>org.springframework.experimental</groupId>
      <artifactId>spring-graal-native</artifactId>
      <version>0.6.0.RELEASE</version>
  </dependency>
  

• 构建配置：在 pom.xml 中配置 GraalVM 的 native-image-maven-plugin 插件，以生成原生镜像。

示例项目

• 示例代码：Spring Graal Native 提供了多个示例项目，展示如何使用该技术构建原生镜像。

状态和未来计划

• 项目状态：目前该项目处于 alpha 阶段，主要工作集中在软件设计和当前示例的支持上。
• 未来计划：后续将支持更广泛的应用范围，并优化效率（镜像大小、内存占用）和性能。

资源和文档

• 文档：Spring Graal Native 0.6.0 的文档可以在 Maven Repository 上找到。
• 示例和集成测试：项目包含多个示例，这些示例也用作集成测试。

注意事项

• 实验性项目：Spring Graal Native 仍处于实验阶段，可能存在一些不稳定因素和限制。
• 社区合作：Spring 团队与 GraalVM 团队合作，通过在 GraalVM 的问题跟踪器中提交问题，以提高原生镜像的生产就绪性。

Spring Graal Native 0.6.0 的发布为开发者提供了更多构建高性能、低资源占用的 Spring 应用程序的选项。随着项目的不断发展，其功能和兼容性有望进一步提升。

The Spring team have just released version 0.6.0 of the spring-graal-native project. This project is intended to make it easier for anyone trying to build GraalVM native images of their Spring applications.

For a deep dive on native images with Spring, please see the Devoxx talk by Sébastien Deleuze.

In this blog post we’ll talk about what has changed since then and point you to some key resources enabling you to try it out! This project is in the spring-projects-experimental github org, indicating it is a work in progress, but we have a number of sample applications showing the kinds of technology that are already working and lots of documentation on how to experiment with your own apps.
What is a GraalVM native image?

Just as a quick refresher, GraalVM is an umbrella project that can be used for a number of purposes but the key aspect we’re going to look at here is running JVM code as native images. Once compiled to a platform specific native-image applications should have very fast startup and a more reliable memory profile (no JIT causing memory spikes at the beginning).

When creating an image the native-image building tools need to know information about your application, for example what resources are being loaded, what types might be getting reflected upon and whether types can be safely initialized as the image is built or must be initialized later at runtime. This information enables the native-image tool to try and build an optimal image for the application.

There are actually a few ways to collect and communicate this configuration:

Some libraries include it directly inside their distributions, as fixed .json files (e.g. netty)
A third party feature (in GraalVM terms) participates in the build process and computes the information and passes it through to native-image via an API. A key aspect of the spring-graal-native project is the feature it contains. This feature understands how Spring Boot applications operate, applies that knowledge to the particular application being built and passes the results on to the native-image build process. It can make very dynamic decisions as it can operate on closed world assumptions, knowing the classpath is complete/fixed when the image build occurs..
An agent, supplied with GraalVM, can collect the configuration data that will be necessary whilst the application runs normally (as a JVM application) and then those files are picked up by a subsequent native-image build step.

Each of these approaches for computing configuration has pros and cons. For example the agent can only collect information on code paths that are exercised whilst the application is running, but it will certainly create an optimal set of precisely what is needed (in terms of resources/reflective-access). On the other hand the feature doesn’t create a totally optimal configuration because it doesn’t run the application so has to allow for certain code paths that might or might-not be taken, but being part of the build process enables a feature to do Spring specific optimizations like eagerly evaluate conditional configuration. When the native-image build runs the full classpath is known and so @ConditionalOnClass checks can be performed at that time and if they fail that configuration can be discarded and not even looked at when the resulting image launches.

We have been working hard on all these fronts attempting to improve the ecosystem so that we can move to a world where things just work. There is some way still to go! We’re digging into Tomcat to make the configuration as easy to pickup as it is with netty. With the GraalVM team, we have been ensuring there is nothing in Spring Boot applications that trips up native-image construction (necessitating fixes on both sides) and improving the spring-graal-native feature to better understand a wider variety of Spring applications. We have also been helping to ensure the agent collector is not missing anything. The current set of issues we are working through with the GraalVM team is actually tracked here.

Since the demos given at Spring One Platform 2019 and Devoxx, the feature has learned more about Boot, the agent is missing less, GraalVM is more compatible, the resulting image sizes have fallen, the image build times have improved and we’re including even more sample projects demonstrating what is working.
How can I try it?

There are numerous sample projects here including even a PetClinic (of course!) and samples related documentation here on how to play around with them. There are samples using Netty, Tomcat, Spring MVC, Spring WebFlux, JPA, Spring Cloud Function, kotlin, etc. What might you see?

. ____ _ __ _ _
/\ / ’ __ _ () __ __ _ \ \ \
( ( )__ | '_ | '| | ’ / ` | \ \ \
\/ )| |)| | | | | || (| | ) ) ) )
’ || .__|| ||| |_, | / / / /
=========||==============|/=////
:: Spring Boot ::
…
INFO: Started TomcatApplication in 0.044 seconds (JVM running for 0.62)

For applying it to your own projects, the documentation describes all the steps to either run it with the feature, or the agent, or a hybrid mode involving both. The hybrid model is sometimes the best of both worlds as the agent can catch something the feature might miss and vice versa.
What do I do when it doesn’t work?

The process isn’t super smooth yet, this is more work to be done in many areas. Both the team working on the feature and the GraalVM team have been working to improve the diagnostics so that when it does go wrong you can still make progress and understand what to do next. It is unlikely some random application will work first time, but for anyone committed to working through the issues, many applications will work. Your application might be using a library not yet encountered in our testing. It may be using some Spring behaviour that the feature hasn’t been taught about yet. It may go wrong at image build time or at runtime when the compiled image is launched. There is a troubleshooting page here that discusses some of the common problems and how to go about addressing them. Hitting something else? Please raise an issue on the project.

Within the spring-graal-native project is a configuration sub project which tries to encapsulate knowledge about Spring Boot behaviour in an easily extensible form. For example, it encodes that a particular import selector might cause the need for reflective access to a particular type. The feature itself is driven by this encapsulated knowledge and if you discover the knowledge is currently insufficient please feel free to enhance it and contribute back to the project to build out that knowledge, see the extensibility guide.

There are also some subtitutions included in the spring-graal-native project, a substitution is a GraalVM term for making a change to an existing class at image build time that currently doesn’t work well when included in a native-image. Over time the plan is still to eliminate these and work with the projects containing these problematic classes to get them into a ideal form that will work inside or outside of a native-image.

Although spring-graal-native is Spring focused, obviously a Spring project typically includes many third party dependencies. Many of these do not include the necessary configuration yet and so our feature is ‘covering for them’ as best as it can. Wherever possible our plan continues to be working with these dependency providers to help them craft their ideal native-image configuration and then it will simply be picked up automatically by a native-image build. The GraalVM agent does offer a nice approach to try and deal with code that is missing configuration.
The road ahead

Is all the work happening just in this experimental feature? Far from it. A number of enhancements have gone into Spring to ensure it operates properly when built into a native-image. For example, in Spring Framework the @Configuration proxyBeanMethods attribute in Spring Framework 5.2 enables applications to run without CGLIB proxies (the native-image process can only support JDK proxies). We also refactored some classloading in Spring Boot condition processing to use a different approach because the agent wasn’t able to catch the original form of loading.

More of these enhancements are to follow. There is more to teach the feature, whilst in core Spring there is still too much being done at startup time which we can push to build time and which will have a serious impact on the memory needs of a built native image. These improvements will benefit not only applications built into native-images but also applications run on a regular JVM. Things are only going to get better! Thanks to the GraalVM team for supporting us in this work. To track our progress, keep an eye on the project.