spring-native

spring-native copied to clipboard

I wondered how the actual development process would look like, given that building a fresh Spring Boot project without any other code takes up to 8 minutes on my machine. (2017 MacBook Pro i5)

I tried to only enable the Spring AOT Gradle Plugin only on the CI and run the normal Jar for development purposes. Is this actually something that is viable?

Whats the best way?

Thanks!

I wondered how the actual development process would look like, given that building a fresh Spring Boot without any other code project takes up to 8 minutes on my machine. (2017 MacBook Pro i5)

I tried to only enable the Spring AOT Gradle Plugin only on the CI and run the normal Jar for development purposes. Is this actually something that is viable?

Whats the best way?

Thanks!

Great question @itsandreramon !

I would say that for now, it makes the most sense to think of building native as a CI/CD build task like you suggested, rather than something that you would do for every local code change. That's what my process looks like anyway. I build and work with normal JARs and non-native Docker images where possible and then go for a full native-image build later when I'm ready to deploy to staging or perform cross-system integration tests.

Plus, there's already some great stuff in the Spring developer tools that can speed up your workflow, so that regular way of working will still be the most popular route in my opinion.

In the future though, who knows? Maybe someday, building native Java applications with GraalVM will be fast enough that you really don't notice the difference over a regular non-native build. Fingers crossed :crossed_fingers:

Indeed that's a great question, I think the strategy we tend to promote is to favor regular Dev XP on the JVM in order to benefit from the fast feedback loop, but with the Spring AOT plugin enabled, that's why we don't put it in a specific profile. Spring AOT and related native support allow you to exercise the "native friendly code path" on the JVM in order to have the same code that runs on native and JVM, with the native configuration being the main difference between both. Devtools are not yet supported with Spring AOT, but we are working on that, see #532.

So in the end, as suggested by @benwilcock, the regular workflow should be close to the JVM one using Spring AOT in native mode. You will check initially locally then on the CI/CD platform that the app runs fine on native with the upcoming native testing capabilities (see #22) and create a native container image if that's fine.

Let's turn this into a documentation issue to document that properly when the blocking issues will be resolved.

Spring Native is now superseded by Spring Boot 3 official native support, see the related reference documentation for more details.

As a consequence, I am closing this issue, and recommend trying your use case with latest Spring Boot 3 version. If you still experience the issue reported here, please open an issue directly on the related Spring project (Spring Framework, Data, Security, Boot, Cloud, etc.) with a reproducer.

Thanks for your contribution on the experimental Spring Native project, we hope you will enjoy the official native support introduced by Spring Boot 3.