Enable native-image builds automatically

[dmikusa]

Describe the Enhancement

With #272 we are looking for a key file, filepath.Join(n.ApplicationPath, "META-INF", "native-image", "argfile"). If that file exists, we could assume that the user wants to have a native-image build and automatically enable native-image builds.

Possible Solution

I'm not sure off hand if we can tie into the BP_NATIVE_IMAGE env variable or if we'd need to modify the buildplan. The native-image buildpack says that if you set native-image-application in the buildplan, it'll trigger a native-image build. One of these two options should work.

Motivation

Right now a user has to manually set BP_NATIVE_IMAGE=true to trigger a native-image build. The presence of this file could be a trigger which we can use to infer user intent and automatically enable a native-image build (or at least flip the default from false to true, a user should still be able to opt-out by forcing BP_NATIVE_IMAGE=false).

[sdeleuze]

As just shared with @pivotal-david-osullivan, @scottfrederick and @wilkinsona, currently this file is not reliable way to detect that a native image build should be built for Boot apps because:

• This file is expected to be created only when --exclude-config parameters are needed (currently only when Netty 4.1 is used), so with Maven this is not a reliable trigger for now.
• We just found a bug in Spring Boot 3.0.0 bootBuildImage always trys to create a native image due to bootJar always adding a META-INF/native-image/argfile to the jar spring-projects/spring-boot#33363 that creates unconditionally an empty argfile even when NBT plugin is not applied, so I asked @pivotal-david-osullivan to rollback this change asap because currently every Boot app running ./gradlew bootBuildImage will attempt to create a native image, even for regular JVM app!

If you decide to move forward on this change, you should probably make sure:

• That enough users are not on Spring Boot 3.0.0 anymore
• That META-INF/native-image/argfile is created unconditionally by Spring Boot 3

I can understand the appeal of moving away from env variables to control the default trigger of a native build, but I am not convinced by this "trick" to create empty argfile to act as a trigger for Buildpacks. A META-INF/MANIFEST.MF entry would maybe be cleaner. It would also have the benefit to avoid Boot 3.0.0 users to be impacted by this critical regression.

[dmikusa]

Thanks @sdeleuze we'll have to wait and see how things play out and cautiously move forward.

[anthonydahanne]

We could revisit this situation with Spring Boot 3.1 introducing Spring-Boot-Aot-Processed: true to the jar of a Spring Boot app if it is ready for use in a native app.
Last failed attempt #279 could be reworked to instead just read this new entry

[scottfrederick]

See spring-projects/spring-boot#35153

[dmikusa]

@anthonydahanne @scottfrederick - Seems reasonable to me as a default. If you've enabled AOT processing, then we try to build a native image app. I do think we need an opt-out though, so we might still need BP_NATIVE_IMAGE that way someone could say BP_NATIVE_IMAGE=false and not have native image run.

[sdeleuze]

We begin to have more use cases for AOT on the JVM, see https://twitter.com/sdeleuze/status/1650396526709993474, and we will likely explore and potentially refine this use case as part of Spring Framework 6.1, so I think I am not in favor of considering that the default for an app with AOT metadata should be native, even with an opt-out option. We IMO need a native specific signal.

[sdeleuze]

As discussed with @wilkinsona, if the behavior remains the same on Spring Boot side by setting BP_NATIVE_IMAGE depending on if Native Build Tools plugin has been applied or not, that's lowers my original concern. Said otherwise, as far as https://github.com/sdeleuze/spring-jvm-aot samples should continue to generate a JVM container after those changes, I am fine.

The remaining lower concern I have is that if in the future we introduce a more first class support for AOT optimizations on the JVM, it would be tempting the use this AOT signal to set -Dspring.aot.enabled=true and get JVM + AOT as the default behvior. If we switch to native with pack by default with AOT processing enabled, that would be a breaking change if we decide to change the behavior in the future. I guess I am a bit afraid we could regret that move later, but up to you to decide.

[scottfrederick]

As described in spring-projects/spring-boot#35205, the manifest attribute that should be used to automatically enable native builds is Spring-Boot-Native-Processed.

[anthonydahanne]

great! so this entry will be in 3.1.0-RC2, right?!

[scottfrederick]

so this entry will be in 3.1.0-RC2, right?!

Yes, that's right.