Spring Native

good morning good afternoon and good evening thanks for joining us welcome to this and intermediate and advanced breakout track on on day two of spring one my name is adit apathy and i'm the spring product marketing manager here at vmware today in this track we'll dive deep again into some of the most important topics for the spring community right now to kick things off this morning we have spring native uh as you're all aware spring native was launched in beta in march this year and the project has seen some fantastic growth and community support we've got 2 000 plus stars on github and more than 250 folks already so thank you next up we'll hear from sebastian de luis who's a spring framework committer and a key member of the spring native team on what the team has been up to this year thanks for the introduction and hello everybody i'm sebastian dolez i'm a spring farmer committer i have been involved in the web and reactive support i have been introducing the kotlin support in spring applications and i have created an experimental project sprinkle which is basically about exploring how to build spring application with functional constructs and today i'm here to talk about spring native let me share the slides okay so um usual disclaimer because what i'm going to present is work in progress likely to change and mainly shared for informational purposes feel free to join the discussion make sure you have already registered on spring1.io go to spring1.slack.com and join the session.spring native channel and at the end of the session we will share a link to the q a session let's begin this presentation by a little flashback in march some members of the spring team and on something special it was done by myself andy clement who is a director at spring and who is evenly involved in spring native technical aspects brian closer spring boot and spring farmer committer jen schoder from spring data riya stein from swing security and david sayer spring boot and spring club co-founder what we announced in march was spring native beta that was a way for us to um to share that spring native and native support for spring boot application has reached a certain level of maturity in terms of footprint in terms of native compatibility and it was also the opportunity to add spring native to start that spring the diode to a low and easy start for spring boot native applications and honestly the feedback was huge more than 50 000 views on youtube a lot of activity on twitter and other social media and we got plenty feedback and pull requests of people spring developers contributing to the project so thanks a lot for that so let's uh talk about what is spring native in summary spring native provides better support for compiling spring boot applications to native executables with graph am providing a new way to deploy spring good applications that then run extremely efficiently so that's really about runtime efficiency i'm not here to say that native fits every needs gvm and native are complementary and offer different tradeoffs so while the gvm shines in terms of build time maturity and performances native is hard to beat in terms of startup time and memory footprint and it really depends of your context and your workload for example in term of performances here uh latency and throughput if you have a cloud instance with a lot of cpu and memory sure gvm will be faster because it performed more built more runtime optimizations but if you are running that on a very memory constrained machine with low cpu native could be faster because it will give less memory and more power to um to your application in terms of it memory for example so it really depends typical use cases i would like to share today are the following the first one is sustainability because native allowed to run your spring boot applications with smaller and cheaper instances in the cloud so it's good for the planet and it's also cheaper for you so that's interesting the second use case is kubernetes native low light outputs and in terms of scalability for example if you are using native applications with scanative which allow to go scale to xero and only start containers when you are receiving requests i think the native characteristics like instant startup allowed to scale up and scale down very fast and are very good fit with kennedy the third use case is obviously serverless that require instant startup so that's a no-brainer and the last one is microservices because when you are splitting your system into multiple microservices with the gvm you are going to pay a tax because basically each instance with the gvm infrastructure will consume quite a lot of memory with native the cost of splitting a system into multiple microservices will be less an issue our goal in summary is to allow springboot developers to compile their springboot applications to native executable with as few changes as possible it will require some changes so for example updating your builds or maybe upgrading your springboard version but we we really target to allow you to benefit of native with the minimum modification in your applications there are various challenges and uh on graveyard side some gvm features are not supported on native so for example it's not possible to generate a bytecode at runtime there is no class lazy loading native is super efficient low memory consumption but every classes or resources are loaded at startup while the gvm we will lazy load the classes as they are used that may change in the future but for now that's how native behaves another important point is that native executables compiled with grav vm support reflection proxies resources etc but that need to be configured at build time because while the gvm is super dynamic and do a lot of things at one time on native much more stuff need to be defined at build time so that's uh that's a challenge gvm libraries are mostly untested or native uh so uh it's a it's a it's a challenge because each framework needs to provide the native support do the testing part and obviously it's just integration testing level it's uh it's less uh it provides less quality than a proper native testing for each project compatibility versus footprint is a kind of eternal battle because native image is initially super efficient but there is currently an effort to make it more compatible with the existing gvm to reduce the differences between the gvm and the native ecosystem and avoid to have two super different flavors of java and usually when you increase compatibility that's impacting the footprint so we try uh the graveyam team ourselves and others to find the right trade-off between those two characteristics and the last challenging point is long build time you will see with concrete figures that native builds are much longer on spring side run time reflection used with the annotation based problems model is a challenge because it's fully supported by guava native but it requires explicit configuration so that's a challenge in term of compatibility and it's impacting the memory footprint because uh reflection and native is costly so you may want to limit that the second point is that spring really care about api backward compatibility so we want to support native without breaking our current contracts and programming model in order to allow you to not modify your application to go native the last point is that all the work that we have done until now on spring native is based on spring boot 2 and spring for mark 5 so no major architectural changes so that was a challenge to do that without changing framework and good let's now have a deeper look about how you you could start your next springboot native application so your native journey starts on stardust spangletio i'm sure josh will be happy about that you go to this website you can add the spring native dependency that is available in the in the regular field and you notice that it's also available in popular ides so intelligent id like in this screenshot visual studio code netbeans or eclipse one of the big edit value of this star.spring.io integration is that the build will be configured automatically to support to support native application that means that it's going to configure the required plugins on both maven and gradle as the required dependency and configure spring boot to be able to generate container images that will contain a native executable you can also see that there is a generated app.md file that will provide you some getting started instruction to compile your native application and also some links to the documentation speaking about the documentation spring native provide a complete reference documentation the most interesting sections are getting started because that explains really how you should start and the support section that will list all the supported dependencies which are known to be supported on native there are two main ways of building a native executable with spring native the first one is based on bill packs build packs or cloud native build packs are already supported in spring boots that's how you can build containers images with your springboot application and the jvm and what we have done is that we have added native support to buildpacks in order to create container images that contain a native executable created from your spring good applications it does not require any grav vm native image compiler installed locally only docker is required and it the build will happen inside the container and will produce a linux based container image x86 is supported and arm support is a work in progress you can follow this issue for more information but that's more for yeah deployment if you want to work more as a developer you will likely use native build tools native build tools started as a collaboration between spring and guard vm teams and recently the micronut teams have joined us it's maven and gradle plugins that allow to compile your application using a local locally installed native image compiler and also it provides a native testing support which is super important it produces a native executable of the of your the same architecture of your os so if you are linux it will produce a linux executable same for mac os and windows no cross compilation is supported but if you need cross compilation build packs reports and the future arm support may be an answer to that question now let's see concretely how to use that with gradle for example you you type gradle boot build image will be built backs or gradle native build with native build tools and this will build a native version of your spring boot applications if you are if you have configured correctly spring native that will work out of the box if you are using the supported dependencies you can see that the native image compiler is run on on both sides but at the right it's running directly on your os and at the left it's running inside the container the native build takes some time like i said it's it's a small application and you you saw it it took a few seconds um at the at the right with native build tools and a native executable is just is just created on your machine and at the left with buildbacks a container image is deployed locally and then you can run both so while compilation text times startup is almost instant so at the right with native build tools we are just running the native executable and at the left with buildbacks we are using docker run with the name of the produced container image to run it and you can see that startup is almost instant here we are starting this spring application in less than eight milliseconds and even with bigger application the startup is is not more than a few milliseconds so that really scale with your application it's not just a demo for the three-party language we support both java and kotlin for kotlin you should use kotlin 1.5 or superior and this is the current scope of the spring uh support that we provide so this is the list basically of the actuators that we we support so we we support uh spring boot actuators various spring data modules are supported ls6 elasticsearch gdbc gpa neo4j l2tbc and release and we have support for various other parts of the spring ecosystem like air sockets spring security both webflux add and spring mvc are supported there is a support for testing we are going to see that more in detail a value sprint cloud project has supported log back is supported with some limitation and we have a wavefront supported as well obviously this list of dependencies will increase over time and that's just the beginning of the story now i said previously that there is some native configuration to make graveyard native image compiler aware of reflection resources and proxies this is how it look likes you have this reflect dash configism uh place in a in a predefined directory on your classpath and native image will automatically read that to know that for example this class or this field or this method or this constructor need to be accessed effectively and for resources and proxies that basically the same but that's that's not super nice to write that's why spring native is generating that automatically for the dependencies that that we support now what what should you do when you are using a dependency from your company or a dependency which is not yet supported you can write this kind of file if you want but we also provide a more convenient convenient way to add native support for your libraries if needed if you are using some features that require explicit configuration it's those native annotations so basically you are using those annotations on your spring boot application or configuration and that will allow you to specify that you want to add a specific native image command line runner option you can specify with ads type in reflection or access to class resources when that's required when you are using asm for example you can specify additional resources uh out of the box we are adding everything that is in src main resources and src test resources but if you have a resource for example in one of your dependencies and that's not supported yet you can specify that with that kind of annotation and same for gdcap proxy on interfaces serialization and with graph vm you have also the possibility to initialize some classes at real time so we provide some annotation to specify that but be careful about that it can quickly become a compatibility nightmare so please use build time initialization not frequently so uh let's now talk about the recent announcement we did the first one and a very important one is native testing support so uh thanks to the collaboration with the guavm team [Music] on native build tools we are now able to provide gradle and maven support for native testing so concretely that's based on g unit 5 and with sam brennan who is a spring framework and g-unit contributor we are currently backporting and contributing some of those features directly in the unit 5.8 the goal is to be able to compile your junit 5 tests as a native executable and then the g-unit launcher is directly run from from this launcher and that will generate the regular report test file that will print the output of the test and with that you are able to test your application including with integration tests on native and also that's a game changer for library authors who want to provide native support and that allows them to to test their library some features are not supported for example mokito which is evd based on bytecode generation at runtime is not supported but we are currently discussing that with the grav vm team and there is some plan to um to fix that but for now yeah mokito and and and similar stuff are not supported yet another feature that we wanted to provide because like i said at the beginning we want to uh limit as much as possible the amount of modification to run your springboot application on native um typically when we are using proxies on interfaces those are jdk dynamic processes that's supported by gradle native image we just have to provide configuration for that and that works but what about proxies on classes for example see this example of spring security with annotation like pre-authorized on a class or if you are using a transactional annotation on a class it's not supported by design by the graveyard native image compiler so on-declement implemented aot ahead of time proxy generation so instead of creating this proxy at runtime like we will do it with cgelib on regular jvm runtime we are doing we are going to modify the bytecode at build time in order to create this proxy and then this kind of use case is supported out of the box you don't have to modify your application it should be detected automatically but if we miss something you can totally use at iot proxy ins to specify that a new feature that we provide in the upcoming 10.11 release is buildback support for compression so bendpak now supports upx compression which allows to reduce the size of the native executable by a factor of four and compression takes some time but native image build already takes a long time so i'm not sure that's a big deal and more surprising at runtime the startup is usually faster with the compressed version because the compression is more than compensated by less io so for now in the upcoming release you will just have to enable a flag bp binary compression method in order to trigger this new feature and we are going to see concrete figures uh about the impact of this uh this compression support now let's talk about ahead of time transformation and i think this is the most important topic we are going to talk about today so um spring iot and maven gradle plugins perform powerful build time transformation on spring boot application to improve the efficiency on native and potentially on the gvm too that's very important because uh we started this spring native journey by adding ins in order to allow a springboot application run in order to specify the reflection the proxies etc but nowadays we try to go uh one step further and modify ad build times spring boot applications in order to run uh not natively on native because it will still require some configuration but run a native with less configuration better compatibility with native and a lower footprint so uh here is a diagram that explains how you could compile a spring boot application to native with our new infrastructure and how that works so as usual you have your spring boot application sources and you are going to compile it to application by code thanks to javascript usually that's done via the maven or gradle plugins but here instead of directly passing that to native image compiler we are going to invoke the spring aot plugin so spring iot plugin is a plugin that is applying in parallel of the current spring boot one and is going to generate sources ahead of time and it's going to generate those sources based on various uh knowledge of your application so you see that it take and input the application by code for example then these rta sources are compiled with javascript so we have a two-step compilation and the output is an iot bytecode with the linked sources and the native configuration and those three elements application by code iot bytecode and native configuration are feeding the native image compiler in order to generate this native executable the work that we did during the summer and we especially stefan nicole and brian kozel who did an amazing work during this summer is to process spring application contact bins at build time we are not going to start the application application context at build time because that makes no sense but we are doing we are going to create it analyze it and generate a modified version that will be more efficient so really big congrats to stefan and ryan for for this work and let's have a deeper look on the architecture of this supercharged spring iot plugin so if we go more in detail in input you have the application by card we have talked about that previously you have the class path so typically the dependencies that your project are using and here springboot had already it basically introduced a closed world assumption for the jvm ecosystem used in a wide manner and native image is is doing the same but in native image it's mandatory everything in term of dependencies is fixed at build time so we can take advantage of that knowledge to provide additional optimization uh in input we have also spring factories so spring factories are basically spring plug-in mechanism it's similar to service loader but with some spring related features and we are going to use that in inputs also we are going to use your application properties like application.properties or application.tml in order to understand the configuration of your application at least the one that we can analyze at build time because you can still provide additional configuration at at runtime then we have this spring iot plugin that's a new version that will be available in our upcoming d11 version we begin by doing an iot application context processing so the context is created with the various bins but not started we perform at conditional filtering so add conditional we are going to see that more in detail with the sample add conditional is the mechanism that allows springboot to know what part of the configuration is required for your application and what parts of those configuration are not required and this this process is typically done at runtime in a very efficient manner but here we are going one step further because we do it during the build and the output of that will be an optimized source code generated for your application and an optimized native configuration that will be generated based on the knowledge of the class path of the various configuration of your application and also it will use the native hint that you could provide on your application and also the ones that we are chipping out of the box with pregnancy we then compile those generate source code with javascript and also we are doing this iot proxy generation at build time the output of what the plugin is generating are the programmatic spring factories the programmatic application context the byte code with aot proxies and the native configuration we are now going to compare a regular spring boot runtime like you do it today to the spring boot runtime in aot mode so let's talk about how things works currently so you have your spring application you are going to in your main you you type spinningrt.run for example and what happens at runtime is that the springfactory's file is read so you have a springfactories example at the left where you can see that for a specific interface we provide various implementation that's the plugin system behind spring and those spring factories file are provided with spring boot dependencies or via third party libraries sometimes this is obviously done by reflection because this this file is like a property file and also there is a filtering of the configuration classes that is done via asm class reading so at the right you have an example of one spring boot auto configuration but you have this one is specific to json b but you have a lot of others and have a look to this add conditional cl add conditioner and class add conditional and resources add conditional and missing bin annotations those are the information that allows spring boots to know if this sort of configuration should be taken in account for this application or not we have done a lot of optimization in springboot to make that super fast at runtime but that still happens on time in this mode so a quick filtering is done via ism and then for the the retained candidates springboat is using reflection to load the configuration classes and uh create the relevant bins also cglib is used to generate proxies when required like i showed previously now let's have a look how that works when you are using the spring iot plugin before here your spring application is going to use directly the programmatic spring factories that you can see at the left two main differences the first one is that a very few or no reflection is involved because that's directly using functional constructs like lambdas and metal references so that's a good fit for native because native could understand automatically out of the box without any native configuration this kind of construct so better compatibility and also a smaller footprint because no reflection means a lower footprint and the the other point but the very important point is that this programmatic spring factories is is really customized for your application it only contains the bits related to your application then at the right you can see that we have this programmatic application context stamper so instead of analyzing the various configurations etc we are going to bootstrap the spring application context using lambdas and method references so same then for programmatic spring factories the fact that we are using functional constructs for creating the application context it's going to give out of the box native compatibility no reflection involved and also we have done a lot of pre-processing because we have processed the add conditional spring boot annotation at build time at least not most of them and so uh it's expected to be to be faster no need for reading class resources if we need to do that with asm we can do that at build time and also no bad code generation since that's not supported by native but that also happened on the jvm directly is directly used the iot generated by code with required proxies so to summarize our spring ahead of time strategy move most configuration reflection from time to build time it's not about removing reflection because reflection is needed when you are using uh when you are using annotation based powering model it's more about moving reflection from runtime to build time when that's possible we don't uh need to remove totally defection because a lot of libraries are using reflection and uh i think it's totally enough for spring to for itself move all or most reflection at build time and then just use what the ecosystem ecosystem is using and not try to to do that work instead the ecosystem it also allowed to reduce the amount of spring infrastructure required at runtime because with this iot mode we are just using a very simple generic application context variant we don't need all the annotation processing etc so that's that's that's nice because we are using less class from string at runtime uh maven and gradle plugins are doing source generation that's super important for us because we want to keep good debuggability so we are generating generating the sources and we are generating the byte code we are compiling the sources to have both sources and by code including for the generated bits we have explored annotation post processors but they were by design too limited for our needs so that's why we are not using them and so at runtime aot mode is mandatory and native because we are really uh we are really using that to provide our native support to reduce the amount of native configuration and it is optional on the gvm currently it is enabled when you are using the aot plugin during the build and then at one time when you are using the dash d spring iot equals true flag to enable that so let's now see uh data points because i think that's super super important let's begin by the native drawback the the the long build time so uh in in those figures i'm going to compare command line runner which is a springboard sample which just prints something on the command line webmv systemcat it's a spring mvc application a spring boot with spring mvc with stem-cat application with address controller endpoint and pet clinic gdbc which is the gdbc variant of our famous pet clinic sample so closer to a real world application on the gvm compilation take a few seconds as usual on native you see that it takes here between one and three minutes because yeah native compilation takes more time but you can see that between the currently released uh spring native.10 version and the upcoming spring native dot 11 version we have done some progress because when we remove reflection and when we do more optimization for example a better java 11 support or things like that we are reducing the build time so really the way to reduce the build time is to provide less bytecode to compile to the native image compiler and the graph vm team is doing some optimization and on spring side we we are doing some optimization as well next let's have a look to the container image size even if that's not the most important metric on gvm side if you are building a container image with springboot build image it will ship a gvm version in your container and the bytecode and the dependencies and so you can see the the size of the container image is around 200 megabytes with the gvm be aware that we are working on some optimization to use a thinner operating system layer to reduce this amount but currently this is what you are and then with spring native you can see that we have smaller container images because we are using a very tiny operating system base layer and we are just shipping the native executable no need to ship the wall gvm and no need to to ships dependencies etc and last point with upx compression you can see that we have very small containers so for example for the pet clinic the tech clinic application we have a container image that is less than 50 megabytes that include the operating system and the java spring and your application bits compile into native executables so i think that's a that's a pretty nice figure if we do a deep dive into a minimal native container image you can see that you have a base layer for the operating system which is only 17 megabytes 17 megabytes yeah it's containing gdpc it's containing openssl and a few other libraries but just that and here you have a spring boot plus spring mvc and tomcat application compressed with via opex and built with native image compiler and you can see that it's only 15 megabytes so pretty pretty smooth and optimized now probably the most interesting point the memory footprint so here i compare various flavor of our spring boot applications for the gvm i'm just running so this is a benchmark on mac because a result can vary a lot between platform but here that's a mac so um if you run your springboot application following the guidelines of deployment so it's an exploded springboot application you are going to have these figures so for example for [Music] for petronic you have 245 megabytes of memory consumption and this is the rss memory so this is the total amount of memory not just the hip the total amount of memory consumed by the related java thread on your operating system now it's interesting that even without compiling to native just with the gbm with the aot mode on the gvm we observe a significant decrease of at least 10 percent of memory consumption for the very same application so that's that's interesting because uh we have not yet begin to work on gvm specific optimization uh it's just the aot mode that we have built for native and it provides some interesting improvement in term of a memory footprint on the gbr then on the native side you can see that we have a pretty pretty low footprint and you can see that we did pretty nice improvements between our current release and the upcoming one and we will continue to do that so those improvements are due to two things the first one is the better java 11 support we have been collaborating with the guard vm team because java java 11 native images were bigger than java 8. so we had a great collaboration on that and thanks thanks to them for fixing that and also this is the outcome of the the new iot mode which is more more efficient basically and those results are likely to be even better in our upcoming release because we are going to leverage guavam 21.3 which provides some pretty significant optimization and reflection more on that later startup time here i guess that's a no-brainer a native is the winner but again you can see that on the gvm with this new iot mode we we observe a 10 percent minimum gain in time of startup time on the regular gvm so if you combine that with other gvm improvements i think that could be an interesting point to to to explore and on native uh the new iot modes uh with the application context created and analyzed at build time allow faster builds but yeah it's faster but it's still a few milliseconds but that's that's always nice to be able to start even faster especially for bigger application with a lot of configuration i think that will be even even more uh interesting now let's talk about gravion 21.3 guar vm 21.3 will be released in october and it provides major improvements to reflection supports it also introduces the java 17 support which is super interesting because that's the new lts version and it will remove the java 8 support so don't be afraid you can still compile your java 8 application using the java 11 distribution of native image for example but i think that was really needed to remove the java 8 support because native was super super difficult to maintain for the graveyard team on this platform and it's important to be to be able to move forward because in more recent version of java there is some native related improvements that make it much much easier to support native our coping.11 release will be based on guavam 21.3 current snapshots are still based on gravim21.2 and we provide both java 11 and 17 support let's now talk about the improvements in term of reflection so a new feature of guavam 21.3 will be to distinguish between invoked and query reflection method to allow better efficiency because currently when you configure reflection on graph vm it's going to provide the reflection metadata like annotations and also create some proxies to allow invoking reflectively methods or constructor and there was no possibility to differentiate those two use case and by allowing to do that the graph vm team was about to measure up to 20 percent footprint reduction with spring applications so we are excited to be able to to leverage this new feature reachability based native configuration is also super important it's allowed to reduce the amount of build-time classinessization which was previously the main way to reduce the native image size but that's a dead end in term of compatibility from my point of view and i think most of the graviam teams share that so this proposal is about adding a one type reachable predicate that allows you to make a reflection entry of the gravim native image configuration only active when a certain type is reached by the native image static analysis and that's super powerful because that allows you with static configuration to take advantage of the of this static analysis and that should allow um to switch everything to runtime initialization with low footprint and avoid the issue or begin to avoid the issue of real-time class initialization so that's uh that's super promising for for the compatibility and the footprint of native libraries last point for a simpler reflection course that where arguments are constants those simpler calls will be automatically inline that means no extra memory is needed for reflection and no configuration is required for this reflection call because they are directly in line during the build so i think that's that's pretty promising that does not work where the arguments are dynamic so it has some limitation but for some use cases that enable some interesting improvements in terms of compatibility and footprint now let's finish with uh with the roadmap so our next release will be spring native that 11 the key feature are this iot application context the grav vm 21.3 with reflection optimization java java 11 and 17 support it will be based on springboot 2.6 and it will provide upx compression for container images will be published shortly and uh it will be released the same time than spring good to that sixth during during november now a very interesting point vmware tanzu has end-to-end native support so vmware and belsoft now have a support agreement in place that provides end-to-end native support to vmware tanzania customers the liberal canadian image kids liberal liberica native image kit is a native image distribution maintained and created by belsoft and it is based on the grav vm community edition and library kjdk and it will be used in native buildbacks as of spring native.11. on the user side no change you are still using the same native image command but that allows us to provide native support end to end and that's consistent with jesus jvm side because there the bell stuff library cajde car was already used so that's uh that provide a consistent story on both gvm and native and fixes and enhancement will be contributed upstream to the graveyard project we continue to have a great collaboration with the grad vm team and that will allow us uh with beltsev to contribute more to the low-level stack of native image as announced by your gandering the keynote the future of spring native is first-class native support in springboard freelance so i think this is the most important point spring native will remain better and will get merged uh gradually in the next generation that we are starting to build right now uh more detail about that first uh i i had previously hinted that will happen but now we have a clear road map with some dates so spring farmer six milestone one will be available q4 this year the rc1 will be available q3 next year and the ga will be available q4 next year with springboot3.org following after that and don't be afraid we will provide a smooth migration path from spring native from using spring boot with spring native to spring native free which will provide out of the box native support and i share with you here a small a detailed uh architecture that will likely change as we implement it but basically on guava side we are going to continue contributing on native build tools for the maven and gradle plugins we are going to introduce uh and work with the graph vm team on a native configuration repository for libraries and that will use the gradle 21 the next release of guard vm the 22.6 packet of build packs will continue to match your native bin packs and the springboot 3 is where the native support will really come with iot support in maven and gradle plugins springfarmer 6 will provide the basis for the iot transformation engine and native phonational support nk enablers and each spring portfolio projects will provide aot transformations and medieval native ins if needed the goals are really seamless integration in spring boots increase native support so supporting more libraries also a better quality because there will be much more testing and not just integration testing runtime efficiency via iot transformation for both native and gvm so even if you stick to gvm i think that's interesting and a java 17 baseline because uh it's uh it's better to leverage the latest java version for that again this java 17 baseline will allow to compile uh most of the previous uh version of java so if your projects are using java 8 or java 11 it uh most of them will compile but we we want to to put to to leverage all the new features that provided by java 17 and be able to evolve faster but no no no not maintaining too much uh java version support for native the collaboration with guava and team continued to increase and i'm sharing again this quote by thomas weslinger and i'm super happy about the work we do with the guard vm team uh with thomas team and a big thanks to uh virgin vajnavic we are collaborating we have a great collaboration with this team and we will continue to to collaborate with them um an example of this native configuration is the upcoming native configuration repository so native configuration for gm libraries the goal remains direct inclusion in those libraries and the testing capabilities will help but for the libraries that are not yet ready to include the native configuration we are going to collaborate with the grail vm team on a native configuration repository that will allow to provide a native configuration for a specific library if it does not provide a native support yet all non-spring native aims will be moved to this repository and will be directly used by springboot3 and we will provide guidelines on how to craft native configuration how to test that and some advice about yeah some best practices basically there will be an automatic testing of those support in order to be able to test when a new version of a library is released if the native configuration is still relevant or not so in summary we are really building a framework for the next decade and that's why we are working on the stuff the spring team is fully committed to build a strong java native ecosystem and we you can use spring native today to compile your spring good application to native executable and then when spring boot free will be released with this iot optimization and native support it will benefit to millions of spring good application and you will be able to leverage that with a better compatibility even more optimized footprint and full support on that okay i would like to say thank you and you can contact me at s dollars on twitter if you have some questions and i think we are going to share we are going to share the q a session link on slack and then we could you could ask me questions awesome i hope you all really enjoyed sebastian session it was packed with so much detail from a recap on native to recent announcements performance statistics gal vm and a future roadmap i'm not sure what was it that he did not speak about if you have questions for sebastian he'll be available on zoom right now and you'll find a link to that zoom on your slack the q a will also continue on slack for some more time so make sure you catch both of those things next up yesterday if you saw our rsoc at keynote you'll remember that we showed you all of those r socket frames which are passing through canva canva if you're not aware is a 15 billion dollar company that builds a virtual a visual design app that is collaborative and that app uses our socket let's hear from sergey selivanikov from canva on how to create a collaborative applications at scale using our socket

Channel: SpringDeveloper

Views: 1,827

Rating: 5 out of 5

Keywords: Modernization/Refactoring, Testing

Id: TXyg6Nm4ZpQ

Length: 51min 45sec (3105 seconds)

Published: Wed Sep 22 2021