Patrick Baumgartner: Lean Spring Boot Applications for the Cloud

This talk focuses on optimizing Spring Boot applications for cloud environments, presented by Patrick Bougourdner, an experienced architect and developer. He highlights the common performance challenges faced when deploying Java applications and shares insights on how to improve application efficiency. The speaker discusses important metrics such as CPU usage, RAM consumption, and container image sizes, emphasizing the need for proper measurement and benchmarking. By using tools like build packs and Java 21, along with strategies like optimizing garbage collection and using lazy initialization for Spring beans, he demonstrates significant enhancements in both startup times and resource utilization. The talk also introduces the Spring Pet Clinic application as a benchmark case, illustrating practical steps for developers to enhance their cloud applications.

[Music] hello welcome back to this new session I'm here with Patrick bound Gardner and uh we are going to talk about springing brute applications so Java world how to build application for the cloud uh Patrick is an experienced architect and developer that he worked on a number of framework belonging to the spring and Java ecosystem and he is actively involved as a software C and A Gile

community so thank you for time thank you for joining us Patrick and I'm going to give you the stage thank you very much luuka so um I'm looking forward to talk to you about um small and lightweight applications for the cloud and probably all of us have like similar issues when we deploy Java applications or spring applications to a cloud environment so um I would love to

now let me see I would love to actually like give you some insights what you can actually improve and like what you can change in your application so usually I say um I'm going to show you things Josh long the spring developer Advocate is not going to show you and I show you also like data or numbers like how things are um pering basically because I did

some benchmarks I measure the things myself so I can actually like see what's going on behind the scenes great so um luuka already introduced me a bit but also like to let you know um as he said I do architecture I do coaching on the job I do development I do reviews and I even do trainings with focus on Spring and besides my day job basically I

also teach at the University of applying Sciences in CK as well so teaching is also like a big thing and as also Luka mentioned before I'm also part of the Java user group and the software development community in syc in general so I'm also heavily involved there in events and on conferences and other things so what is I what's the problem what is this talk about so

because I'm I'm a spring guy since many years I want actually like that my application we have built in the past also perform very well in production so basically in the cloud these days so let's dive into the topic so um you may think of or you may know that people approach you and ask you like how much CPU how much RAM is your application needing in

in the cloud environment well often we don't know so we would have to measure and see like how the application behaves right and then on the other side also like when you deploy things to Cloud it may be is important um how much like container image size you have as well because like that depends on how fast a container image is pulled from the repository and if

you have to push your image like even to like a cloud like Which is far away it may also take some time as well and then on the other hand the question is also like yeah which technology should we use for our Cloud applications you would say obviously if you're like a Java person or a Java developer you will probably say that we are not going to

change like the ecosystem we are not going to change programming language just because it's more performant because we know that like things change a little bit slower in the Java world but they are super super mature so um so it just usually takes some time until the this the Java ecosystem actually like picks up so like for for us which is now very important it's usually like

CPU and RAM as I mentioned before and you can imagine that like SE several Cloud vendor are not even like linear scale like CPU and RAM sometimes you have to like just because you need more RAM also pay for more CPU right and another thing would be like the image size as I mentioned before also like costs more because you need to um provide some traffic you

have some Network bandwidth needed to like send your images around obviously from a application perspective you would say scalability is also very important so that means like Fast startup and maybe graceful shutdown if you have something like an AOS scaler in place another topic would be like data throughput like how much can my application like resist how many user can it deal with and then on the

other hand is like the question how long does it take until the response is sent back right so these are all things we we should have in mind if we deal with our application so we are going to talk about um the spring pet clinic and in my agenda I will just show you like what the spring pet clinic is we do a Baseline and then we

jump into Java optimization spring boot optimization application optimizations other runtimes some conclusions and then in the end some summarized example right so that's actually like what I would go through with you in the next 40ish minutes the spring pet clinic is actually a very simple application and it's a demo or showcase application for a lot of features and it has been used um also for for other

Java Frameworks where they are like try to reimplement the pet cleaning because it's just a good show Showcase with like many different um interaction possibilities for a user so as you can see on the slide and basically like some data is populated so you have some pagination you have some forms you can send the data in and so on and so forth right then actually also like

the pet clinic is also famous because there is a pet clinic community and the pet clinic community might help you when you try to implement something like angler or react with spring boot in the back end right there are other examples out there and the pet clinic is not an official spring ecosystem project or the P clinic community actually it's not official spring it's um Community maintained

so that's why we have that many and even more examples you can try out if you want to for the talk is very important I go with the official pet clinic so the official pet clinic is an official spring frame work or a spring framework ecosystem project and it's based on Spring boot these days it uses caffeine as caching um service side rendering of HTML we have

springing data jpa for the data access we might choose between H2 postest or my SQL for my example I'm using just like H2 let's keep that in mind and for the controllers it uses spring MVC so some good old technology like basically everywhere so be aware of this uh we are just dealing with the official pet clinic then also for the rest of the presentation now if

you want want to optimize obviously um there is a few things to be aware of now before doing experiments I want to narrow down the technology stack we're using we are going to create Docker containers with build packs so something which is native to the spring boot ecosystem anyway even though I I'm I'm always realizing that not many are using build packs to create their containers but

I will use that in my example I use for my base Des the Java jdk 17 so the the Le the latest version of it and also the latest version of spring boot being aware of that in two days spring boot 33 will be released right and then on the other hand also like for testing we use um test containers because that's part of the of the

stack and then actually also um use some migration script to do the DB migration to populate the data into the application which is is basically part of the startup sequence of the application on the other side when we are going to examine the data we will have a look at build time startup time resource usage basically Ram I'm I'm not really counting their CPU because that's a

little bit more complicated to basically like get one number out of it and then actually also like we look at the container image size and also the throughput um of the application so that means basically like how many requests go through um a second for example so just to mention here Bill packs again buildpack is a very nice project which helps me to build Docker containers usually

I mention Bill packs with the pako ecosystem pako is just the implementation build packs is the standard and pako actually like helps me to package any kind of application as you see the logos there into a ER container it will create a very nice stalker container and reduce the the sorry the the cognitive load of a software developer so a software developer does not need to know

how the container is built because they use some standard approaches um to build these container images if you haven't tried it before I will really like encourage you to do so because I think actually like it's the the best way to do the perfect container because build packs help you for example to run your processes without for example a privileged user and other things so usually it's

like very much optimized if you look at the application which starts up so that the spring pet clinic application you will see the locks and in the locks the first 20ish lines or maybe 10ish lines on top this is something which comes actually like from the build packs there is a thing actually used and you can barely see it it's called memory calculator and the meory memory

calculator actually like Tunes already your jvm as you need it as much resources are um allocated for your Docker container like CPU and memory it will use that for example to deal with the parameters for the the the the Heap size and stuff like that what also is visible there is for example that the jvm gets the current CA certificates loaded and also what you would um

realize as well and that's just like below the logo of the pet clinic you would for example also see that there is a a user which is not a root user running the process the user if you can see it is called CNB and then actually also besides that things like spring Cloud bindings are enabled so that means means for example that liveness and Readiness probes for

kubernetes are turned on automatically for you if you use actuator for example so you see actually like very good defaults are there and even defaults which you would have to like set up manually can be actually like calculated dynamically so in other words build packs are thousand times better than your Ro regular Docker file it's more secured and like one other big Advantage is actually like that

build packs are maintained by the build packs community so if the base image and that's usually an Ubuntu Jammy um has a vulnerability it's it's fixed within two to three days because as soon as canonical the company behind Ubuntu is like fixing the the library or like provides a patch or something it gets Upstream directly into build packs so I don't have to care about that I

always can like work with the latest and greatest base image from the buildpack community right so before we actually start and have a look at like how we can optimize our application um I want to share with you a tool I came across where I started preparing for this presentation and it's a tool by Mach Mach actually has added or has created a tool which is called

Spring boot startup report which gives you the possibility to read the data which is anyway recorded when a spring boot application is starting and he visualizes it in a nice nice dashboard so the dashboard which is like available under SL startup report would actually like tell you how long it would take um to create a single beam and then even like the whole tree of that particular

beam so you could actually like see like what long and what doesn't take so long and as you can see also at the magnifier there is a plus and a minus so you can really like drill down and see like which spring beans take very long to to be created that's actually quite interesting if you have the time once have a look at it because I find

it actually surprising because like um I have realized that certain things take longer than I have expected at the bottom of that page you will find also the very famous flame chart you probably know from other tools as well and there you could actually like see from bottom up basically the same structure as you have seen above with the magnifier but here you have the flame charts

and you will see like that certain sections take that amount of time and you could say like for example and that was kind of surprising to me that initializing hibernate and spring data together takes about a fourth to a fifth of the time of the the boot time of your spring boot application it's quite a lot right so um I don't want to say like like let's

get rid of like spring data and hibernate but just like let's be aware of that magic which hibernates makes beside the Magic Spring does of course and takes quite a lot of time so let's start with the benchmarks and there I want to show you that for example when we build the application how long it takes to build the application how long or how big actually like

the image size of the produced artifact will be we'll have a look at the startup time at the memory usage and then actually we also look at the throughput and the latency with using a tool called wrk to so the second version kind of like can deal with latency too and as you see there usually when I do benchmarks I I think it's fair to have a

warm-up pH so that the chit can actually like like jump in optimize the code and then I do a minute of measurement you also see that my envirment has um four virtual CPUs and like one gigabyte of RAM and that might be a little bit too generous comparing to the regular applications we usually deploy right you might be aware of that like people like to have like

a half virtual CPU or a quarter virtual CPU and some are even talking about 0.1 uh virtual CPUs in production but the thing is actually like um the four CPUs for Java applications is basically like the sweet spots to have the application started up the fastest I will tell you also a little bit more about that at the end so I just found out actually like that's

really like the sweet spot and it cannot get really really better by just like doubling the amount of CPU you provide to the right so that's that's like what I measure and um just like to to start with I would love to actually create a Baseline and my Baseline is always marked in the table with the results at the bottom with this little watch so you see

actually like the build time of your spring pet clinic with Java 17 and with the current version of um Java you see 17011 and the Java memory calcul later in place takes about the building of this takes about 67 seconds the image size of the container will be around 358 megabytes the startup time of the application is about 4.5 seconds the RAM usage before we actually like

do the load testing it's 300 megabytes if we put almost 2,000 request a second on the application which um is actually like possible in this kind of setting with my machine um leads to like 400 and almost 70 megabytes RAM usage just right after the load testing and then you see the percentiles at the end of the table uh which actually like explains that like 50% or

um of the requests are within 5 milliseconds you have like 99% are within like 31 milliseconds and if you go even like two decimals after the DOT then you're like within like um 60 milliseconds right so that's that's actually quite good it's it's it's really really nice these numbers I would say so we'll compare this to other things to other optimizations um I think I need to

tell you as well when I run actually like my benchmarks I usually run like 10 benchmarks at a time and then I I take off the Peaks so that means like the the very good um results and the very bad results and I do an average in the end so I know basically like that all of my applications uh runs as many if I'm going to do

that they will all end up in this um numbers basically like kind of a in so like the statistical result would be like really really confiden that most of of the runs would be like this right so um be aware of this also the other thing is actually like I I usually like Benchmark the application 10 times average the things my machine where I do the benchmarking

also has like water cooling so I have consistent water or CPU temperature through the runs and currently like with all the optimizations I do and and try out and get the numbers off actually like my application or or my my whole test Suite runs like for more than a half a day right so it's quite a lot of effort to take all these numbers and then actually

like um bring them into the right format here okay so be aware of um just that's the regular thing then on the other hand let's say we are going to change it we are going to use like jdk 21 and the jdk 21 can be easily changed just by yeah I'm changing a maven property and that would be like the what you see actually on the as

well where I say like minus D Java version equals 21 so I change it and then I just build the container again so that means like the container contains now a Java 21 which actually like means that the container image is slightly bigger build time is around the same startup time you could argue it's actually like a little bit worse um that could be also like a

mistake in my averaging algorithm but what we see as well is is actually like the initial Ram is better throughput is about the same and then also like RAM usage afterwards is slightly higher but if you compare now the percentiles you would actually see that H it gets better towards the end so it seems like Java 21 from a throughput or latency perspective is actually like better

than the Java 17 be aware also and that's really like uh where I struggle sometimes if I see this um every number in the Java version like 2103 if they upgrade to the 21004 the numbers usually like make a huge difference and going back now to Java 17 where we are already on 17011 means like they had quite a lot of time to do some performance Improvement

and that's actually like what I see quite often if I jump back to 21 jumping forward to 22 where we have only 2201 released at the moment you would actually see that um the 2201 well is actually like already a bit better as we can see also from the numbers so in the percentiles on on the lower end actually like it's about the same but it's also

performing better on the higher end so I I'm really curious like what will happen actually like with the next version um of java which has also then um a lot a longer maintenance phase um or let's say like the next version of um Java 21 where Java 21 has a long maintenance phase and then also the next LTS version again usually you see that that the LTS

versions like get way better over time and therefore I have to tell you um it really makes a difference if you upgrade to the latest version of java it's not just about latest and greatest really I personally have to feeling that if the new features in Java have to be published or a new release has to be like um made public they use the time afterwards to

do some cleanup to do some optimizations and the next releas is actually like are way better than actually like the first version of of a a jdk okay so let's have a look at some parameters we can change and obviously there is a parameter called like no very which could actually also like improve the startup time so no verify is an idea where you say all classes

which are low that are not verified so that means like starting up the application will be faster and that's actually like what you see in the in the slide at the bottom right so roughly 4 second startup time compared to four and a half seconds and you also see actually like H we have a better performance and keep in mind um this benchmarks they are just made

with Java 17 so we always compare about Java 17 we always do some optimization on the 17 or if needed on on the newer version right I will let you know but basically like that's why image size and build time is about the same because I just started with the Java tool options parameter which will make this no verified part of the startup of your application okay

so um what about another one which is actually like meant to start up fast right te stop at level one is actually like a parameter which you could use to use the C1 instead of the C2 jit compiler and that means like if you specify this it's really fast at startup because like the G the C1 compiler um does no overhead in the in the optimization so

there is no monitoring and other stuff actually there while as you use actually like the C2 there will be quite a lot of overhead for the monitoring and the profiling and stuff like that for the optimizations so you could actually say like tier dead stop level one means like C1 but if you go for level two and level three and level four you will be in the

range of optimizations and this parameter usually is used for example when you see internally in intell when you just like start up your spring boot app from the IDE that parameter is appended so that your spring boot app starts faster but obviously as we can see actually like with the throughput but also with the um percentiles we see the numbers are just like way too big right

it's really like on the right side 18 seconds for the the basically like the last request coming back so we basically sacrifice um the the performance in the application for a faster startup with this parameter but obviously like for functions or like for rely used applications it just might be good enough okay another thing actually like could be changing the um garbage collector and changing garbage collector

is just like another topic basically and I just thought maybe we can do that easily and I I just added in the Java tool option the parameter for the set garbage collector which is meant as a scalable low latency garbage collector which stops your application maximum 10 milliseconds from working and this one actually like is not very well suited for the kind of applications we do I

mean you could see that we are like with the throughput of the application we are in the same numbers but this garbage collector actually like uses way way more memory and that that's really the thing like here you see like initial Ram is like one gigabyte and then actually like after low test we have like 1.5 gigabyte memory used just like for for the Heap basically okay

so um you see actually like with the regular garbage collector we have in there and with the parameters we add with the memory calculator we are actually and if you're curious about other um parameters I can highly suggest the VM options Explorer from Chris who codes.com so there you can actually see like which different um vendors of the jdk will have which features available and some of

the vendors basically also backport options which are introduced in Java 17 or Java 21 even still to Java 8 right so um if you want to see if your option is available have a look at the AVM options Explorer because I think it's a nice tool to see actually like what possibilities you have with your current jdk or jvm you're running okay so now let's dive into

the topic where we now discuss um like spring Boot optimizations and one thing would be like let's say let's do all the spring beans in a lazy way all the spring beans in a lazy way means actually like they're initialized with the first request more or less or let's say in other way they are initialized when they're used right and you see now um in the example

above that I specify basically spring main lazy initialization to true and I also make sure that spring data jpa repositories are also lazy initials so what does this brain the thing is actually like lazy ization makes the startup faster right we see that with the startup time we see that with the initial Ram consumption and then afterwards when we do the benchmarking we are roughly in the

same area with the numbers and that's actually like what I would expect so if my Benchmark Suite actually like does some warm up all the spring beans are anyway U initialized and when I do the minute measuring afterwards it should behave exactly the same like the the Baseline right so that's what we more or less see we see some numbers which are very very close to the

um expected ones and obviously there might be some differences slightly differences also like on the next slides I would show you the thing is just like I'm not going to cheat the numbers I don't let them make look beautiful I just run 10 times and present you the numbers as you can see that and I will also provide you some additional information what I would expect how

things would would get better right so sometimes you could even say like because we measure things they're like in a similar range I think it's just okay is what we have here but obviously startup is faster be aware of having spring beans lazy that that might be dangerous I mean lazy beans are nice obviously as you have seen for startup but be aware of that when the

spring beans are created they might be created with a different threat other than the main threat of spring boot so therefore your application if there is a misconfiguration won't stop immediately at startup it will just like produces exceptions when you run the application right okay so spring boot has another thing actually like I came across um this is actually like this fixing spring boot config locations config

locations in Spring boot they can be for the property files but also for the yaml files they can be in different places and therefore actually um it really depends like where you place your configuration file or even better you could tell actually spring boots that it shouldn't like load the or try to load the files from four different places it should actually like just pick it up

from a location you have specified so that means like three files four fil system checks versus one and that would mean actually like my startup of the application could be slightly faster and we also see here um well the numbers doesn't show like a huge benefit I would also expect that the benefit is really really small in this case right okay but now let's go to the

next one which is actually like real brave because um I actually say if you don't need spring board actuator don't use it and it's really about if you can afford not to use them don't use them because I want to show you like the big difference like if you see the spring pet clinic with actuators has currently 447 spring beans created with the actuator if you remove

the actuator starter it's just 275 so that's a huge amount of spring beats which which are missing in the second case and you can imagine actually like if you don't have to create 170 spring beans you startup should be like way way faster on the other hand you would also expect that like all the observability features and metrics and tracing and other stuff you know the logging

things if they're not there um the application should also behave a little bit faster so you can see now this also in the results right but obviously that's not a serious um suggestion it's just a thing like if you can afford to don't use it if not well let's deal with it right um You probably have seen that like your ID like your Visual Studio code or

your intellig is actually using jmx to get the datea of your spring boot application right but as you also may know that spring boot actually uses production ready features it really means like jmx is actually not enabled in a container built with um build packs but also like if you run up application in production so I just wanted to tell you actually like I love spring Boot

and pill packs because they just do the right thing and in case you need to enable JX because you deploy not in a kubernetes cluster and you maybe want to expose it in a different way that the dam beans you might still like enable them as you are known to do that like past great okay let's have a look at some application optimizations obviously now we could

talk about things like caching your application properly maybe optimize the queries of your spring data and many other things which are really like special to your application and I try to find like a way how you can optimize your application or your spring boot application in a way so that everyone could actually like do that you know so the the idea is actually like let's get rid

of some dependencies and I came across a very neat project which is actually called the dep clean Maven plugin and the dep clean Maven plugin is actually like from a I think from a Swedish University where they created a tool which is going to like check like the bite code which reads actually like the strings uh for reflection stuff and other things and it can really like

find out what dependencies you are not using application what it does it creates a report and the report was so long I had to add in multiple places like three dots as you can see on the slide just to shorten the section it reports actually like the dependencies where it knows for example it's a transitive dependency it's maybe an unused dependency it's a indirect um transitive dependency

and so on and so forth and obviously um it doesn't know anything about spring boot so there are like some specialities in Spring boot which this tool actually won't find but what I find personally interesting is actually like that it would find things like you're not using jackon at all do you really want to use jack in your application for example the thing is actually just like

because you're using um the spring boot starters these starters are quite opinionated and that means actually like the starters are built in a way that the spring team says probably you're going to use a single um a a single page application you're doing this and that and so on and that's why the dependencies are there so I usually say starters are good to start with but they

are not here to end or finish the the development of the application so that means like the dependency cleanup is really necessary and in my case of the spring pet clinic was really the thing that I could actually like remove um Jackson I could remove even like the websocket dependencies of Tom Cat for example because the application just doesn't use websocket at all right and then actually

like you see also some challenges listed for the dependency cleanup it's basically like all the component and entity scanning I'm spring Bo does or the corresponding Frameworks do then actually like you see also that you cannot deal with text files where for example Auto configurations are listed and you cannot deal with XML files like the spring XML configurations or even the web XML files so you have

to be aware of that there might be some false positives in the report but as you can see like in my example I could strip off like five megabytes in container image size just because I removed some dependencies which are not needed right okay so that's basically the thing there is another topic which is actually like quite interesting uh it's the thing which is called a high

of time processing and I'm not talking about gr native images already I'm talking about that like um the spring configuration can be better automated so in the previous times actually like there was a tool used or available which was called um spring context indexer and now this is the replacement for it so this means like it's build time for component scanning entity scanning and other things actually

like it will be really like optimized right and it will actually be faster because this optimization is in place and um yeah you see now the numbers basically like the generation takes quite a bit longer the image size is bigger and you could also say like we are within the same range of the startup time so I would expect that the numbers are better but it looks

like my machine had also other things to do at that time when measuring I guess I'm not sure but um we would say like we're quite in the same range but we don't need to do component scanning and entity scanning which is a huge Advantage there is another thing actually like probably you don't know it's called jlink where you create a custom runtime for your application which

is actually like quite nice um you would see here some examples how to do it like on the common line because jlink is a Java the jdk tool but there is also possibility to use it inside the the spring boot Maven plug in for the build packs so you can basically tell the build pack actually like to create a customized jdk and you can see on the

image size it's getting way way smaller which is actually a good thing right and if you do it the right way like I would do and you are going to add the modules used manually you can even strip it down more which is actually like a huge Advantage right as you can see as well and we are also like roughly in the same area with the performance

of the application but as I said image size gets smaller right so you see Bill packs are awesome and I hope to see some other things in the future as well in the bill packs because I think of um topics like Craig or app CDs and other things which could be added actually like by the bill team you can actually also go and change um the the

jvm the underlying jvm I till now use liberon which is actually like the the VM supported by the spring wood team and also the the VM usually like shipped with intelligent but now you could actually say oh I'm going to use for example open chain I and that's just like the one liner where I say I use open chain n instead of like the hotspot VM and

you can actually like do that even like uh with parameters as we did before and also you see some numbers where you can see for example like the Quickstar parameter I use for the SQ line there which actually turns out very horrible but it is actually like the thing uh it's like the the chit compiler C1 we have seen on the hotspot then actually like if you

look at the virtualized parameter as mentioned on the slide as well it's getting a bit better but like the default is is like the yeah it's actually like better than that great so um another thing would be actually like using R VM native images no not grvm native images yet but just a regular grow VM and that's used as a jvm for example where the grm is

usually slightly bigger because of all the features it has when running it as a jvm it has a better um jit compiler so the grvm team is currently looking with the um Java jdk Team how to in integrate their um chit into the jdk right so that would be great because we also inherited already from from The Grow VM team for example the compiler which is actually

the grow compiler which you use when you compile your application so um you would see here also like some better numbers just because of the chit that's like the grow VM in the community Edition what is even better actually like with performance and also with the chit is actually like the gral VM the Oracle version of it which is actually called gral VM free so you can

actually use it even in production but it's basically the Oracle distribution whereas the um other example um or like the the thing yeah whereas the other example is just like the Community Edition another idea would be actually like to add new Builders and there are Builders which means like you can actually like take off the parameters or the the the parts for the Ubuntu stuff and so

on right and now we actually do it with this builder for using an Alpine image I have also done that with the par that the Builder actually like for Ubuntu which is a little bit smaller than the the regular one as you can see also on the numbers as well so using different Builders exchanging like the the base image is actually like a quite thing and then

of course what should not be missed here is actually AOG native images because everyone talks about that and how much faster it is what I can tell you is go for the Oracle grow VM native image version because it's so much better than actually like the the other one the community you see that in the numbers and uh usually like it's it's not really that fast um

if you have really really a lot load on your application than the jvm but like for most of the use cases it's very very nice and then there are other things like for example crack where you can snapshot your application or actually like let's jump a little bit further and speed that up and uh what is actually like missing it's part of the virtual threats right so

virtual threats actually like should also like be faster than spawning um Regular threats and that's actually like what you see here for for me actually like using Java 21 and virtual threats with a spring boot app is a no-brainer because it's faster okay so let's go to the summary and I will jump over my conclusion and show you like the the best things at the end so

like the optimizations I just went and actually like optimize the things quite a bit and there you can actually see like using Java 70 and the Builder from bellof um you really like improve the image size quite a bit you have get half like the start startup time you basically like have better memory usage and also throughput and if you think of that one as well having

um Java 21 and the the base um Builder with tiny it's also way smaller the startup time is even faster with all the optimizations and your applications have usually also like a better throughput so um I think that's from my side did I miss something let me know or keep silent but usually I I would love to learn from you as well okay uh thank you very

much for your presentation it's been really super interesting because uh I think that in the Java world and when people look to Java they also miss the point about performances so you definitely cleared out that application can be optimized uh even the the VM can be fine tuned so uh that could be uh super great uh just a question about uh uh using uh on many different

cores on many different clusters a different configuration uh do you think that uh can be it can be scripted it can be uh make automatic just delivering this kind of ofation is is is that possible you think so so actually like the build packs do quite a lot of things automatically right and what what I showed in my presentations these are basically like about 10ish takeaways every

developer can apply tomorrow at work because I think like what you have seen is was not really like um Java parameters to optimize your jvm for for different cases we just went with the defaults because there in most of the cases are very good already because it's optimized for default cases and web applications we write like string in string out basically like that's a common theme so

um yes and then on the other hand also like doing this kind of like um for example J link and other stuff I think it belongs into the pipeline right and also like building the whole images it's part of the pipeline so yes you should actually automate that and usually in my projects I even use like kind of a parent where I inherit this kind of configuration

so like we we do in all the applications I maintain um the same strategy basically and I can even add every time a bit more and I learn and I optimize and so on and so forth okay okay that's that's perfect great Point uh thank you for pointing it out thank you for your presentation uh thank you for you attending to this great session and have a

great conference bye bye bye