Josh, thanks for informative video! I am getting used to 'elevator music' in ptojects ( to run one project it was necessary to wait for 1,5 minutes for dev mode, the other one required 6 minutes, the third one -- although it was based on microservices approach -- required to wait for one hour for one microservice). What performance do you expect from the mentioned appraches for real life projects (like financial services, governmental services and others)? I wonder if Java developers will have the startup time for their application comparable to some JS frameworks -- where even heavy project is up and running after 5-10 seconds
That was fascinating and informative. Learned heaps. Would have been interesting if you'd applied the same type of timing check on the get all dogs method. I'd like to understand the difference each of those options AOT, AppCDS and GraalVM would have on post startup operations.
hello Josh, thank you for this great video. I see you are using maven instead of gradle. What would you recommend for new spring boot 3.3 and java 21 based projects and why?
Your application is connecting to Postgres. You can't just load a CRaC image and expect the connection to work, right? I'm sure you'd have to take the snapshot before your app connects to anything, correct?
Will it work with the same smoothie if an application has huge custom configuration properties amount? Like an property which enabling something or disabling some bunch of beans in the application
Thanks for the video, very informative as always. One correction: you wanted to never init the db, but set spring.sql.init.mode to "always" instead of "never"
Issue with these technologies is that they are far from production ready. I haven't yet seen a project which even uses Spring Native. The moment you have to start coding in hints and flags to compile something this will never be adopted.
@@prashoo That is not the concern. The issue is that setting up native build for real production app requires too much effort. Old legacy apps will never be candidate for this anyway, so pointing this out has nothing to do with the situation. This can only be applied to hello world projects with 0 dependencies or only few dependencies which have all those predefined hints, but I cannot imagine regular developer having to spend time writing compiler hints to get their feature working.
I agree. Too little benefit for too much effort. I would love to have less memory consumed by our services (and fast startup is a bonus too). But so many pitfalls on the way that the time a developer needs to spend to make it all work and work stable will cost much more then just buying more memory. I'm not sure GraalVM will ever become an effortless default JVM replacement, as some people are dreaming, because the way it works in its core is incompatible with such an idea. Some projects will really benefit from it (e.g. I can't imagine to write kubectl that requires JVM to start, but with GraalVM - why not?). But most will not. I hope the JVM itself will be improved in the future to the point when all these "workarounds" will just be not required.
Hi Josh, I got stuck here! mvn clean package -DskipTests [ERROR] Failed to execute goal org.springframework.boot:spring-boot-maven-plugin:3.3.1:process-aot (process-aot) on project myservices: Process terminated with exit code: 1 -> [Help 1] Java 21 I believe I am doing something wrong, please help.
Josh, thanks for informative video! I am getting used to 'elevator music' in ptojects ( to run one project it was necessary to wait for 1,5 minutes for dev mode, the other one required 6 minutes, the third one -- although it was based on microservices approach -- required to wait for one hour for one microservice). What performance do you expect from the mentioned appraches for real life projects (like financial services, governmental services and others)? I wonder if Java developers will have the startup time for their application comparable to some JS frameworks -- where even heavy project is up and running after 5-10 seconds
That was fascinating and informative. Learned heaps. Would have been interesting if you'd applied the same type of timing check on the get all dogs method. I'd like to understand the difference each of those options AOT, AppCDS and GraalVM would have on post startup operations.
hello Josh, thank you for this great video. I see you are using maven instead of gradle. What would you recommend for new spring boot 3.3 and java 21 based projects and why?
Your application is connecting to Postgres. You can't just load a CRaC image and expect the connection to work, right? I'm sure you'd have to take the snapshot before your app connects to anything, correct?
Thanks for the video. I think something went wrong cutting the video around the implementation of the Lifecyle around 26:30. ;)
Will it work with the same smoothie if an application has huge custom configuration properties amount? Like an property which enabling something or disabling some bunch of beans in the application
Thanks for the video, very informative as always. One correction: you wanted to never init the db, but set spring.sql.init.mode to "always" instead of "never"
Issue with these technologies is that they are far from production ready. I haven't yet seen a project which even uses Spring Native. The moment you have to start coding in hints and flags to compile something this will never be adopted.
Most of the prod apps are still running java8. How u can expect them to use native?
@@prashoo That is not the concern. The issue is that setting up native build for real production app requires too much effort. Old legacy apps will never be candidate for this anyway, so pointing this out has nothing to do with the situation. This can only be applied to hello world projects with 0 dependencies or only few dependencies which have all those predefined hints, but I cannot imagine regular developer having to spend time writing compiler hints to get their feature working.
I agree. Too little benefit for too much effort. I would love to have less memory consumed by our services (and fast startup is a bonus too). But so many pitfalls on the way that the time a developer needs to spend to make it all work and work stable will cost much more then just buying more memory. I'm not sure GraalVM will ever become an effortless default JVM replacement, as some people are dreaming, because the way it works in its core is incompatible with such an idea. Some projects will really benefit from it (e.g. I can't imagine to write kubectl that requires JVM to start, but with GraalVM - why not?). But most will not. I hope the JVM itself will be improved in the future to the point when all these "workarounds" will just be not required.
This kind of performance at the start is kinda laughable if the database lives on the pc
What's AtomicReference? Since it's final then how it's setting another value inside main method
The reference to the AtomicReference instance is final, the instance itself is mutable. It allows you to change the value thread-safely
Thank you for the video
Hi Josh, I got stuck here!
mvn clean package -DskipTests
[ERROR] Failed to execute goal org.springframework.boot:spring-boot-maven-plugin:3.3.1:process-aot (process-aot) on project myservices: Process terminated with exit code: 1 -> [Help 1]
Java 21
I believe I am doing something wrong, please help.