Keynote: Introducing Spring Framework 6

um well good morning everyone um I'm glad I'm I'm that I have the opportunity to stand in front of you here uh in front of this beautiful location uh and I'll kick off this morning with uh a pretty Broad and pretty dense uh overview not only of what we are doing in spring from book six not only the state of uh the spring framework world but very much so the state of the Java ecosystem overall so there will be plenty of topics that I am going to touch upon um just um and highlighting what we are doing now in integration with uh the open jdk projects with larger Java ecosystem efforts and not only the state of uh end of 2022 now but very much the state of 2023 uh so uh there are several projects that we intend to pick up in the course of the spring from like sixth generation and this is very very much my tagline today so I um for a few introductory words on on on the history of things because it's very much about the present afterwards um spring framework six of course is already the sixth generation of this framework and the uh the previous generations we we are very careful in terms of uh actually making a major version jump so we only really do so if there is a major Baseline to upgrade to a major uh kind of not necessarily re-architecture but realignment of the framework with its ecosystem with its platform the Java runtime with its developer tooling from the Java compiler to everything else that is in use for for typical Java based projects these days so the first generation got launched in 2004 in term in in terms of its General availability uh and we've only reached the sixth generation in like uh well counting from there in like 18 18 plus years so uh we are very really very careful and somewhat conservative in making a major version jump so let's actually see whether this works yeah so where are we uh right now this is what's in production this is what we recommend to to be in production right now uh it's the spring framework 53x um generation as the cool framework underneath springboot 2.7 so uh it's very much coupled these days with a corresponding spring boot Generations the spring framework itself the cool framework is what we traditionally call the spring fabric is a a broad umbrella broad foundation for everything that happens on top in the spring portfolio so uh just to see the relationship spring boot is what you typically use as your entry point as your means of setup and configuration spring framework is the cool foundation and there are several other projects in between spring data Spring Security you name it so where are we platform wise springform 53x is uh very much a jdk8 baseline Arrangement which is the state-of-the-art the state of the industry it has been the state of the industry for many years really jdk8 is one of the most important most widely used generations of java out there and it's uh in in terms of our spring framework Arrangement it's coupled to uh Java ee as we used to know it in the Java X namespace that the continuation of the traditional Java ee apis that would be served for the dough for example uh jpa to the to that one um Java x dot server Java x dot persistence will get to that that is the traditional Arrangement that we come from that that is where all the systems out there basically are or can can be at the very moment spring for MC5 had a couple of major themes already uh introducing reactive programming um we are going to pick up on that in in a moment reactive programming from our perspective is a tool a stylistic approach towards maximizing the use of your resources in your runtime system so uh modern day spring framework is very much about um using what you have to the best possible degree the most efficient way of using the the given resources of any particular system any particular service and to some degree this uh shines through through the programming model up to the application development uh to to another degree uh we can also optimize within the framework so transparent to the application without without much impact on the programming model what we've been launching yesterday uh just just a day ago is spring framework 6.0 so it's the general availability of the initial release in the spring framework sixth generation what I'm going to talk about now is really spring from X6 degeneration more than 600 audio release but I'm going to refer to the status of where we are in terms of uh what's actually being shipped what's up next uh in in more detail so where where is the spring perfect sixth generation Baseline it's really a pretty high Baseline we are requiring jdk 17 now so we're really taking a a totally modern perspective we are taking the latest jdk long-term support release as our Baseline jdk 17 has been released in September last year so it's a bit more than a year old um on an equally important note we are transcending the barrier uh to Jakarta E9 and onwards um living in the Jakarta namespace Java ee has turned into Jakarta ee all the apis in there in particular the ones that we care about like servlets the persistence API Bean validation all those apis now live in the Jakarta namespace basically the same API is the same structure initially just a different namespace owned by the eclipse foundation and not by Oracle anymore uh and evolved within a community Arrangement at the eclipse foundation so this this has some impact that we're going to explore a bit and there's a couple of major themes two of which I'm I chose to highlight here the themes that we uh chose for spring framework six ourselves um the ahead of time processing a a pretty General approach towards shifting certain computations and preparations to the build time as opposed to doing them at runtime simpatically about improving startup time to some degree also about improving resource consumption memory consumption at runtime and the another topic we're going to touch upon is virtual threats that's an open jdk project a new variant of threads that will get out of the jdk so um last but not least this is the foundation for spring boot 3 as a the generation of the third generation of spring Boots Spring framework 6.0 being the foundation for spring boot 3.0 at the very end I'll explain a little how how further releases are going to align there all right so let's put it into a timeline um if the jdk 17 Baseline may sound a little high uh initially keep in mind that we are launching springform x6.ga now basically yesterday um in November 2022 jdk 17 is already a bit more than a year old not only that there is jdk 18 in the meantime that's jdk 19 in the meantime 19 being important because it includes the first preview of virtual threats there will be jdk 20 in just a couple of months and in less than a year 10 months from now there will be jdk 21 and this will already be the next long term support release of the jdk so uh in case this this Arrangement sounds a a little compact here it did actually change initially there every every three years there would be a long-term support release of the jdk this has been changed to to shortened to two years every two years there will be a long-term support release 17 and 21 using this model for the first time so spring from x6.1 I can preview so much already is planned to be released in November 2023 a year from now this will already be a world where jdk 21 is available as the then current long-term support release and from their perspective jdk 17 almost sounds like a conservative Baseline already doesn't it it's then the previous Baseline already all right um just a few a few highlights of uh not what uh uh swing family six itself but this does but what jdk 17 provides as a baseline arrangement for us um if you'd like to explore this in more detail there's plenty of resources out there the most important part is the jdk 17 as a cumulative feature set Beyond Java 8 basically you know between jdk8 and jdk 17 a lot has happened at the language level um at the core Library level even in the type system with the introduction of what's called now record types records and uh as a rather minor feature classes and uh well the introduction of the module system and the evolution of the modular system from there all of these Java platform features can shine through to Spring framework applications I strongly recommend embracing them so part of the reason at least to the degree that they make sense to your for your purposes part of the reason why we have such a high Baseline is because we really want to expose all the goodness in Java 17 and higher to your applications I admit we also want to expose it to our framework so Java 17 as a core Foundation as a core reference a baseline also allows the framework itself the framework code base the framework apis to take maximum benefits from jdk 17 features there's a few features that are more important to us than others say a record into a records integration for example for data binding um language usage is mostly transparent using new language features against spring framework apis uh works just as is in most cases for the module system if you choose to use it we do dedicated module path scanning in springform work six now rather than standard class path scanning but looking at these the module system has the least impact really the biggest value to be reaped to be Unleashed in the in terms of the Java platform features is certainly in the language and in the core libraries and with records if you choose to make them a part of your model so this is empowering our ability to evolve the framework very much as well in particular as a baseline for further uh for further Evolution we are going to remain compatible with jdk 17 but there will be there is already 19 there will be 21 next year we are putting ourselves as framework providers into a position where we can evolve from where we are now to embracing not really key 19 to embracing in particular jdk 21 is the next long-term support release and there's quite a bit on it already uh in in those release already in those releases that we um are picking up that we are already providing some some early uh support for that you cannot already experiment with if you're using jdk 19. um as of jdk 21 we expect some of those features to become standard production features in the jdk because initially they are all previews like virtual thread is still a preview feature um and in terms of our timeline in Springfield 6.1 we expect jdk 21 features to be fully supported this has a bit of impact if you think about the perspective that I'm taking here you really should be seeing a spring framework releases spring boot releases as well of course and jdk releases Java releases as sort of going along with each other going along together so um when you're considering upgrading to Spring framework 6.0 now to 6.1 next year consider upgrading your jdk as well you have to initially for jdk 17 if you're not there yet but say for springform with 6.1xt why not consider an upgrade to jdk21 along with it you can do it at your own pace you don't have to do it initially but I strongly recommend making jdk upgrades a part of your upgrade plan next to Spring framework upgrades it's a different model now we get the new jdk release every half year so you're falling behind pretty quickly if you stay on a particular GDK release for too long talking about Jakarta ee a bit more there's uh the aforementioned namespace change from java X to Jakarta it's not particularly exciting I'll be very Frank about that very open it's also not exciting to us it's a migration that we have to do because the further API Evolution the further evolution of the served API the persistence API the bean validation API is only going to happen in the now Jakarta namespaced variants called Jakarta E9 and higher by staying on Java ee8 you're basically locked to the Past Forever Without further evolution in Springfield five to three it's you can still do this for as long as there's a maintenance arrangement for it for everything that you are using but really going forward using the latest generations of providers you have to move on to the Jakarta namespace to Jakarta E9 to Jakarta E10 there's there is no choice it's a major hurdle we have to overcome it's a compatibility wise the the strongest impact uh from Springfield five to three to six to those actually here because we are making that jump in that very generation now even here as well just as with jdk 17. Jakarta ee9 may be the Baseline but what you should really be focusing on is Jakarta ee10 already Jakarta E10 got released uh just like a a month or two ago so it is already available Jakarta E10 as a set of apis wouldn't be all that exciting from a spring perspective the more important part is those are the apis of choice for certain providers for certain third-party infrastructure that spring applications typically integrate with say Tonka 10 it's based on Jakarta E9 Tonka 10.1 is even based on on Jakarta ee10 already on servlet 6. so they're making those moves pretty quickly tender though was Jakarta E9 based lived for a year in the bit it's already end of life you have to be using Tomcat 10.1 now and it's Jakarta ee10 based that's the new world of API Evolution that we're in the jdk moves forward more quickly Jakarta EE and the providers implementing it they also move forward more quickly than uh before JD 12 is still an alpha but will also be a servlet 6 Jakarta E10 release undertose available hibernate RM 6.1 um a major factor a major part of a spring-based application stack going forward if you're doing persistence with hibernate you will be you you want to be using hibernate 6.1 at this point that's also what spring boot 3 will come with which is based on of course jakarta.presistance implementing the jpa 3.1 apis from Jakarta E10 already the world has been moving on uh Beyond Java E8 so we even Jakarta E9 sort of will also beyond that already Jakarta E10 with actual new features in it is already available and I highly recommend doing a straight upgrade from where you are to Jakarta ee-10 along with spring framework 6. um Jakarta E9 as a side note has basically been a feature free repackaging it's the same apis no new features just neutral Carter namespace easy migration Jakarta ee10 is the first release in the Jakarta namespace with actual new features all right where are we to summarize it a little what I mentioned in side notes Springfield lives in a world where jdk 17 is the Baseline 18 and 19 are available Jakarta E9 is the Baseline 10 is already available you may choose which of those three jdks you you may run your spring six applications on you may choose between Jakarta e 9 and 10 apis I wouldn't actually see it at that level I would choose between providers that happen to implement Jakarta e9010 so don't focus on the apis focus on the providers you want to be using Tomcat 10.1 the latest version of Tomcat comes with servlet 6 Jakarta tendon you want to be using hibernet or m6.1 jpa 3.1 Jakarta A10 devil that's the perspective we should be using going forward the API level Jakarta API level just comes with it next year I fast forward from now in Springfield 6.1 we will be living in living in a world where jdk 21 is the new LTS release we'll be releasing spring framework 6.1 against then a support range of two Java LTS versions 17 and 21. and by all um predictive uh ability that I I can have right now Jakarta E10 will be uh in widespread use by then almost exclusively we don't expect basically anyone to be using the Jakarta E9 API level next year take the anyone with a grain of salt right but uh say 80 90 percent of uh of Integrations out there will be at the Jakarta ER 10 level jd-12 hopefully being final by then um does Tom get JD undertow hibernate hibernate validator everything uh is established in their Jakarta E10 based Editions so a quick coming back to the timeline where you're already realizing we're we're specifically talking about this window of time this window of opportunity between Springfield 6.1 and uh 6.0 and 6.1 very much um because that's where a lot of exciting things are going to come out of preview out of alpha into production um with springform X6 total we we are in a perfect position to pick up everything that it will be coming over the next 12 months immediately we set the foundation uh to up to a degree where we can Embrace things as they are being released as they go out of preview all right let's move on to the next major thing to aot um aot stands for ahead of time um it's a convenient term to refer to any further steps taken at build time you're basically running the Java compiler and typically at this point you're you're packaging your application for deployment right afterwards aut is about further steps in between the Java compiler then a couple of aot steps then you package your application into a deployment unit the Java compiler traditionally produces pretty a pretty simple Arrangement really not very optimized it leaves most optimizations and most assumptions to be made leaves them up to the runtime environment that's very much a Java tradition Java has always been working like this the Java virtual machine is very good at optimizing itself at runtime warming up on Startup warming up against some initial requests and then being highly optimized for the particular usage scenario that the application runs in this can be very optimal for long-running systems long-running services it can be sub-optimal if you're starting a Java process only for a limited execution time and then shutting it down again which includes of course any form of dynamic scaling in in deployments in Cloud deployments where uh certain in additional instances of java Based Services are being started dynamically they might be running for maybe just a couple of minutes they might be torn down before ever reaching their Peak Performance optimizations at runtime so uh there's different scenarios out there that we deploy Java applications to in this world and um aot is a tool in the toolbox to optimize for specific characteristics for specific kinds of deployment units you're basically saying I'm willing to take further steps at build time making further stronger assumptions at build time or locking down my applications and certain assumptions about it at build time reducing the dynamic part of it reducing the flexibility of adapting to the runtime environment in favor of optimizing startup time in favor of a smaller deployment unit in some cases in favor of a reduced memory footprint in quite a few cases so this this kind of framing works for many kinds of the prominent Arrangements standard jvm-based deployments can benefit from aot processing you run it on a standard hotspot jvm but it starts up more quickly this can be nice it's less flexible in terms of discovering further classes or photo plugins on the class path and so forth but it's it starts up more quickly so how does this work um specifically for the other elephant for the elephant in the room the other topic there the other major topic gravity and Native executables it uh aot processing is de facto a precondition for turning a spring-based application into a gradual native executable you must run the aot steps you must make the assumptions that aot brings turning your bin definitions into a more lockdown Arrangement producing a ton of runtime hints before the native image tool comes in before ground VM basically takes the output of this and turns it into a native executable it is a mandatory step in between so since we've gone into that already in gravian this is being called a closed World assumption you basically lock down the classes that are visible to the application you lock down the resources the files that are visible to the application in the current spring aot Arrangement you lock down assumptions about profiles and conditions you basically pre-evaluate everything that is relevant to your application configuration in order to produce a a tighter deployment unit that is able to be turned into a native image this the aforementioned runtime hints coming with it that is also a precondition from gravim specifically in order to produce a native image you basically turn a uh a very specific variant of the jvm that is able to do very specific things into a native platform executable this step requires knowledge of every proxy that you're creating every reflection step that you're trying to take because the native image will only include what uh what you told it to include if you tell it if you don't give it any reflection hints there won't be any reflective capabilities in it it can do Java Reflection it can do Dynamic proxies but it needs to be told so at build time this is part of what spring aot does for you it analyzes a spring application infers all those runtime hints and feeds them into the gravian native image afterwards That's the Way Spring boot does it in terms of a build arrangement for gralvium Native images basically they take springform X6 lets it analyze the application with a partial startup derives all the sorts of runtime hits from it feeds them into the native image tool and that's quality and do its job so ground VM is the current reference point for everything we we are talking about but uh there is in parallel to that or in the background of it there is an open GDK project called project Laden the um this project is a sort of standardization of the approach that growlvm is taking it's actually um a little different in many ways it's meant to identify certain uh kinds of trade-offs that you can make for Java based applications with an incremental approach where you you're willing to accept further constraints for your deployment unit um um for Less flexibility or you choose weaker constraints more runtime flexibility it's basically a choice along different trade-offs that you can make and a grand VM style closed World constraint is really the end of that Spectrum the the strongest constraints you could enforce for for the tightest deployment unit that you can produce now this hasn't actually been um producing any concrete results yet it's an ongoing project um but since uh ground VM the ground VM Community Edition releases are now aligned to be aligned with open jdk releases as of next year we expect closer alignment also between Laden and intro album here this as a as a another topic really about related topic there's another exciting project talking about open jdk projects called crack um this is also a effectively and ahead of time step that you're taking but it works in a different way you're not running traditional aot steps and feeding them into a native image tool you're doing something quite different you bootstrap your application you let it warm up so you've got a running jvm with a spring based application in it then you kind of stop it for a checkpoint and you take a sort of snapshot of the runtime jvm as you've encountered it as you found it when it was fully bootstrapped when it was initially warmed up you take a snapshot and uh afterwards you can kind of restore the state of the jvm at that checkpoint uh very quickly so you you do an initial bootstrap take that snapshot store that snapshot on on disk or you may even distribute it and in the cloud-based Arrangement every single instance of your service can then bootstrap from that snapshot this this has this is also a preview project um mostly run by ESU not by Oracle um producing some pretty exciting initial results so uh What uh what Project Crack can already accomplish in the early stages that it is in right now is actually pretty impressive it's not as tight as minimal a deployment unit as a gradient native images but it can dramatically improve startup time on a regular jvm bootstrap so this this is sort of an approach that we explore in parallel next to a gradient native images there's also Project Crack for very efficient deployment from a pre-warmed up Snapshot on pretty much a traditional hotspot jvm without any further constraints I mean obviously there are constraints here as well because the application started up in a spring application evaluated its conditions made its assumptions it's fully bootstrapped so it's fully configured so you're effectively also taking away certain flexibility certain Dynamic capabilities but you end up running on a hotspot jvm which can do everything in hotspot jvm can do no constraints in terms of proxy generation runtime class generation or anything like that so it's a different approach towards the same goal you're taking a spring-based application you take some steps at build time you're producing some kind of deployment unit that has some constraints in it but it's more efficient when you're actually trying to bootstrap it and I'm not giving numbers here because numbers are very temporary they change every month they things evolve it's in the early stages so no numbers here but it's a dramatic Factor you can start a spring-based application that used to take 5 or 10 seconds in a totally sub-second time right in 0.5 seconds very much even less than that it's even some for Samsung areas close to what an uh gradient native image can do so both of them don't just improve startup Time by 10 or 20 percent they dramatically improve startup Time by a factor of 10 20 in some scenarios even up to a degree of 50 times faster than before just to drop some numbers out there right the concrete measures are only to be taken against concrete services if you want to know what impact this can have this early previews of all of these you can try it against the concrete service a concrete system a concrete application that you're building and see what kind of difference it actually makes for your concrete scenario I can almost guarantee there will be improvements uh the degree of those improvements has to be evaluated for each individual system and service to be deployed so where are we with this um well I'm talking I've already been referring to previous all the time so uh you may um you may already expect that quite a bit of this still has to come together in Springfield 6.0 what we can do right now what we are shipping with production support right now is the spring aot arrangement pre-processing of a spring-based application context at build time for a more efficient start of at runtime and for input to the ground VM native image tool in particular this is Steve foundation for spring boot threes build arrangement in Spring boot 3.0 um it's from a technical perspective designed for any kind of deployment Arrangement jvm or brow VM or even in combination with crack um but it's at present very much used uh designed for and used with gravity and Native images gravian2020.3 the latest Cloud VM release is a totally fine production Arrangement that can be used right now so if you if you have a short time frame for a production deployment this is what's already available or in combination with springboot 3.0 it will be available when springboot 3.0 goes generally available next week so spring boot 3.0 will be final in in a week's time from now this is available for immediate usage fast forward by by a year in the springform x6.1 time frame um we we already see third evolution from there ground VM will do a release with every open jdk release every half year so there will be aligned releases uh with um at least starting from jdk 21 we expect an aligned ground VM release supporting the the same Java level released at the same time same support Arrangements around it um we'll see where the other openshtk projects go through but from where we stand right now we also expect the crack project to be final in that time frame we'll see it's run by Azul it's ready when it's ready we'll pick it up when it's ready uh and we work with the assumption that it will be ready for for our spring premise 6.1 time frame next year um of course all of these all of this these approaches are only as good as they can be used for a complete stack it's not good enough that in an isolated spring application context works with it it really needs to work with a complete spring boot stack with Tomcat or Chetty inside uh with hibernate involved with everything that you're typically using so if we're talking about production here we really mean production availability for a complete modern Java stack with springform X6 and springboot 3 on it all right coming back to the timeline for a quick uh deep breath and moving on from here to our next topic of choice um virtual threats also very Timely because it has been shipping as a preview feature for the first time as a regular open jdk preview feature for the first time in jdk 19 September this year September 2022. so it's uh it's a preview feature which means it only works with dash dash enable Dash preview uh in Java C and when bootstrapping the jvm but it's already pretty complete from our perspective it does everything it advertises virtual threats are a kind of rethinking of what we traditionally know as a Java threat a Java ranked threat uh in in recent uh for in recent history always meant an operating system for it every time you're setting up a threat pool or starting a new thread the jvm would really start an operating system for it for you virtual threads are a different kind of threat entirely managed within the jvm using a sort of pool of limited pool of operating system threads in the background think like a fork joint pool as many operating operating system threads as there are CPU cores or I think reactor scheduling like an interactive system a very limited pool tied to the number of CPU cores available and then the virtual threats in within the jvm are meant to be attached to operating system threads as needed whenever they need to perform some actual work they attach to some operating system thread and they're being detached again when they are when they are blocked when they are pausing when they have nothing to do the basic idea behind virtual threats is that in many Java based systems and spring-based applications say spring MVC applications spring data applications are a very typical example if you're using blocking apis blocking data access apis whenever you ask for a certain element to be loaded from the database you're really blocking you're waiting for the database to drive it to do its work the database to return its results when the results arrived your initial threat that performed the call continues from there that's exactly the scenario that virtual threads have been designed for whenever a virtual thread blocks implicitly whenever it triggers an i o operation that blocks it automatically detaches from the operating system thread and makes the underlying operating system thread available for other virtual threats to perform work on this allows a much higher number of virtual threats to be run on a jvm than we ever would have worked with before of course and with some trade-offs involved as well um you need to pre-analyze the application that you're building but for a typical web application a typical servlet based web application typical spring MVC verification the assumptions for virtual threats are pretty much met in their entirety you've got blocking apis in the servlet world for input streams and output streams you're typically interacting with blocking database drivers underneath um so once again this needs to be evaluated against concrete applications against concrete services for concrete numbers we do expect significant benefits for a typical spring MVC database driven application from the use of virtual threats this can be experimented with in previous already it's pretty straightforward to set it up and to test it we don't expect much performance benefit from between jdk 19 and 21. basically virtual threats either they work for you they are in preview still but I didn't work for you or they don't for your particular system it's not about further optimizations uh it's about the basic assumptions that virtual threats make whether they make sense for your purposes The Sweet Spot here is there are typically no changes to the application code base we're talking about standard server-based applications Standard Spring MVC applications standard database or M hibernate whatever interactions no changes to the application code base but implicit scalability benefits from a virtual thread setup the only thing you have to tweak is basically your Tomcat setup your JD setup your spring boot setup in order to make the Callback threads virtual another scenario just to not exclusively talk about web applications here another scenario is messaging applications where say Springs GMS listener containers the messages and containers they use blocking they scale up and JMS is a blocking API for most purposes for the most flexible purposes we're using it for so uh whenever it hits a blocking spot there virtual threads are a perfect fit I expect it to be a perfect perfect fit there as well or of course for a stronger usage of scheduling Chrome triggered or event triggered execution of asynchronous threats that in turn perform database operations again maybe so all of these are at least in terms of our current prediction they are a good fit for virtual threats um for the completeness of the picture and of the understanding of how which effects work imagine a different scenario no database drivers involved purely cpu-bound computation like a scheduling thread a web application thread that does everything from in-memory data structures no blocking no date no i o no database interactions that basically means no benefits from virtual threats if you have a totally CPU bound application without any blocking i o operations you you may switch to Virtual threads but you won't see any benefits because the operating system threads all doing the work no blocking nothing that jvm can do for you in terms of further scalability so virtual threats are are not a magic tool they are a pretty simple decoupling of virtual of threads within the jvm from operating system threads for scenarios where threads are oftentimes blocked all right um nonetheless we expect a ton of sweetness to come out of the virtual thread Arrangement and there's an obvious question that kind of suggests itself here and I can only really quickly touch upon it um is this related to reactive programming isn't this sort of the same idea that we are using a limited number of operating system threats and then we we net the runtime system use those to the best possible effect with reactor and reactive systems it's it's about callback based approaches where the callbacks are only triggered when data is actually ready to be processed and otherwise they are kind of waiting to be called indeed it's a different way of a different perspective of of accomplishing the same the same efficiency goals you're trying to maximize the use of your runtime resources in particular also of your CPU resources reactive programming and the style that comes with it naturally lets you optimize that that usage whereas with virtual threats you're basically programming in a sort of imperative way with blocking apis and you reap the runtime benefits implicitly the runtime system sort of does the underlying attaching and detaching from operating system threads for you so um in a in a world of project loom in a world of virtual threats reactive programming turns primarily into a stylistic question are you doing stream based processing reactive streams reactive programming is a natural fit for your needs for your processing style for your development style stream based processing is what reactive streams naturally are about if rather you have a traditional database bound crowd application where the only use of reactive programming that you consider is for scalability purposes that that's exactly when virtual threats suggest itself as a solution to the problem for you so taking existing imperative spring MVC applications typically to a to a scenario of higher scalability that's what virtual threats can be useful for in the spring world Spring web flux remains in parallel as a reactive streams processing architecture also very good at runtime efficiency but not immediately benefit benefiting from virtual threats the same way it's a different approach towards the same runtime efficiency so where are we with this um we've already got experimental setups that can be found on on our blog for setting up a spring frame X6 and spring boot 3 based application with virtual threats uh it's a little bit of configuration not much at all that sets up Tomcat with a virtual thread based connector initially and for scheduling purposes a spring executive with virtual threats very straightforward to do I just just a few lines of code in the configuration class really in Spring boot 3. um the rest of the work is kind of underneath the covers because there's a there's a few things I haven't been talking about and I don't have the time to talk about like how does the decoupling of threats works the attaching and reattaching there's um there's there's reasons why a thread can remain pinned to an operating system threat where virtual threats basically don't work as a decoupled model if you do too much synchronization synchronization at the wrong points synchronization around i o operations you won't be able to reap the full benefits of retrofits and to something radius it's not so much about your application code it's mostly about the Frameworks the database drivers hibernate and so forth underneath the covers the web service even they internally need to optimize or have had a need to optimize their locking Arrangements in order to be what's often called Loom friendly virtual threads friendly most of this work has happened already as of spring framework 6 as of Tomcat 10.1 as of the most recent generations of database drivers out there most of that work has happened already we expect this to be complete by well by the time of string from a six at one basically virtual threads are still in preview anyway so uh all of this work in the ecosystem goes on in parallel on our end on everybody else's end um we are under the assumption that uh project Loom virtual threats can go out of preview in open jdk 21 for the next long-term support release there's no guarantee for that it's not in our hands that's a decision that the open jdk team needs to make if it's not 21 maybe it's 22 or 23. um obviously would be nice if it's 21 already but we'll be doing whatever we can even if this decision is being made late in the game we are going to do everything we can to provide first class support for it in the spring framework 6.x generation we expect it to happen for 6.1 uh we'll basically do it whenever it's in our hands to do it um this means out of the box configuration options mostly so in springboard 3 you would basically just say I want an embedded Target with a virtual thread callback model thank you all right so very simple configuration Flags configuration facilities for setting up a spring-based application with virtual threads so at the moment it's a bit of a manual process still we expect this to become very convenient all right one one further relationship here right we picked it up we pick up virtual threads right after 19 introducing where they got introduced as a preview and we expect them to be shipped in 21 ideally uh which would allow us to pick them up in our 6.1 release all very closely aligned although on a very tight schedule now um I've been talking so much about the um these specific themes you may already figure that those are topics that have been with us for an extended period we have been working on spring aot on ground native images for several years with early adopter projects like spring native before now with first class features in Springfield 3 in the initial releases um so these these are very much projects with a lot of history already a lot of lessons learned we've been focusing strongly on Spring aot to some degree in more recent times experimenting with virtual threats this year on a very recent note also with Project Crack which only really started uh coming together in a spring boot ready form now a couple of months ago to not long ago at all reflects our Focus the priorities very much but of course at the same time we spent uh time with features we refine every corner of the framework we revisit the entire application application framework code base we do many things in many areas at many levels um at springform X6 level so to wrap this up I'm also going to take just a little bit of time of further things that we did in the spring framework 6.0 release and mostly unrelated to Spring aot and to Virtual threads or other major topics even unrelated to the baselining in most cases um what else happened um of course we get ideas as we work on things so it's not totally unrelated but uh it's totally usable on its own uh we do Java pins property determination with a different algorithm now it's configurably it's by default a different algorithm you can switch back if you need to which is significantly faster even for standard jvm bootstrapping uh and reduces the memory footprint on Startup for a standard jvm application without aot processing any regular spring bootstrap just upgrade to springform x6.0 you'll get it automatically no further steps to be taken for runtime class definitions we use a complete own Fork of cglib now so the this Arrangement that we use to produce proxies specific spring proxies configuration subclasses and all of that stuff in Springfield X6 is now totally in our hands and optimized for our purposes um ready to do spring aot but also ready to do the best job that it can for a standard springform XX bootstrap on the standard hotspot GPM for you when we go to class path scanning we have a different class of scanning algorithm now if you start up a spring-based application and you let it search for your ad controller at repository classes and so forth in your class path it uses a different algorithm now based on Java nio which is a bit more efficient than it used to be and on The Mod in on the module system if you deploy your application as modules partially or incompleteness we use a different algorithm again so a module provided application deployment unit we search with a module path scanning API now this is not only about runtime efficiently efficient efficiency it's also about correctness about us seeing the full picture of the resources that you ship in your deployment unit so as a side note in module paths modules can be patched for example with patching it's not so clear what you're actually seeing it not seeing um there's well-defined and highly efficient algorithms for that now in place that work for any standard jvm deployment so no no build time steps just bootstrap your application this is what's in action now and more happened and I can only really touch upon it very briefly here even more happened in the web application space we took the opportunity in Spring framework six to revisit a ton of things that we meant to revision revisit for for a number of years there's the HTTP interface clients now uh to be featured later today I imagine uh that came out of existing Arrangements that we had before in the spring portfolio but are now a first class feature at Spring framework level there's the spring MBC and spring weblog support for RFC 7807 problem details a standard way of reporting problems that occurred during processing an HTTP request back to the client this is now in as a standard feature out of the box we have we Revisited our HTTP status code handling it's um now more flexible and um well more obvious how we process non-standard HTTP status codes in particular there's a different implementation totally different implementation for multi-part processing reactive multiple processing in Spring web flux now which has many benefits of its own but yeah it's a different algorithm so that we are still learning with a few of those we are still learning about verifying hearing from here but remember that most of those have had exposure to Spring framework six milestones for about a year already so most of those have been pretty well tested in early adopter scenarios across our portfolio around our portfolio already so in that sense they are not really um Express estimate sound here the reactive web client has jdk 11 HTTP client integration underneath the covers if you choose so has an alternative backend to Apache HTTP clients that we traditionally use there and we have the start of a new observability Arrangement a major topic of its own right that I haven't really been featuring much today but this will turn into a major effort over the next few years we started now with a a minimal but common API for capturing traces and metrics in spring-based Stacks based on micrometer micrometer 1.10 release underneath the covers we have an initial implementation for our web clients for rest template and web cloud and directive web client where you can see this in action we expect this to go significantly further from there not just at the core framework level it's actually mostly a spring boot topic but as you can see here observability is a cross-cutting concern uh every component in the stack needs to participate in it and there are many components at Spring framework level that potentially can contribute to the observability experience in a typical spring boot setup and this is only um the gist of what we can what we do here there's plenty uh coming um even in 6.1 we haven't made a choice yet of what we focus on but we have a few ideas uh just to highlight one here that I mentioned we are considering doing an imperative version of our reactive web client sort of a successor of rest template that uses the same program a similar programming model style as web client uses it a functional style a builder Style um but it's entirely imperative underneath the covers so uses imperative HTTP connect interactions um no reactor no reactive processing that's why we call it Loom friendly so what we're really working towards in the web stack is still effectively two variations of the web stick a highly optimized imperative spring MVC stack and a highly optimized spring webflux reactive stack side by side similar programming model basically same Arrangement same alignments where we can have them but a choice that you can make so if you if you're taking a spring from X6 based application and you want a virtual threat friendly spring MVC stack there's basically no reactive programming involved that you need to expose yourself to if you don't want to and there's no reactive components in in the stack it's a totally streamlined servlet based virtual thread imperative step the other stack the weblog stack is reactive from the bottom up there's a reactor current underneath the covers reactive drivers around the directive web server on it that's the spring reflex stack highly optimized in its own uh in its own right so this is a spring framework 5 strategy that we chose we continue along those lines and we continue to optimize both variations of the stack and to minimize the footprint of each of those Stacks um in springform X6 going forward all right so um springform X6 is of course now available as of yesterday uh just highlighting a specific thing here the relationship to Spring boot releases it's not that different really from Spring framework 5 but uh just making it obvious here again springform x6.ga released now is the will be the current release bring from x60x releases until November next year when spring framework 6.1 is meant to supersede it in the meantime you will get two spring boot feature releases springboard 3.0 next week spring boot 3.1 in May next year so you basically get a spring boot feature released every half year a spring framework which released every year so um Every Spring framework generation is expected to remain um a foundation for two spring boot Generations it was the same way for uh recent spring from MC5 releases all right and of course uh also noted here always production ready on the then available GDK long-term support releases best effort supported on all GDK releases in between and since so uh formerly speaking for production environments for support reasons for support considerations you may want to choose the LTS releases but we support all the other jdk releases in between and after as well on the best effort with the best effort model in the open source world last but not least for the a bit of a visual impression of our support arrangement to give you an idea of how this works spring framework 53x has an extended support period this is the open source support period this is the additional commercial time frame um with the the yellow boxes so you can see that spring comic53x has a pretty extended support phase overall as the last feature release in the spring framework 5 generation that's the way we are seeing these things in Spring framework 6 we are starting a new generation with initial feature releases coming sort of in in a yearly in yearly succession springform X 6.0 is uh is now well this the snapshot has been taking like a month ago but uh it is now available it's within its open support range it will have a commercial support range but it will get superseded by springform x 6.1 rather soon there is an overlap in the open source support range there is a longer overlap in the commercial support range but we really mean you to move forward from Springfield six to though to springform x 6.1 as you see fit so whenever you're ready it doesn't there's a window of of time that we we bake into those support time frames but we really mean you to move on from 6.0 to 6.1 and 106.2 and so forth from from there um commercial support time frame is always attached but there is none with the length of the 5vx release only the last spring framework 6.x feature generation that might be say a six to three as well it might be a six foot five we don't know how long how far we're going to take this only the last of those will then receive the additional extension of the support time frame that you're seeing in 53x here all right so that's pretty much all I had for you today um this is where we are this is where we are this is where we have just been moving to this is what we are already working on for your enjoyment uh next year um please join the right move move forward with us make make the leap over to Springfield with the jdk Baseline the Jakarta Baseline and all of these things for a start even if you don't even if you're not considering usage of any of the totally new features yet this is a significant step that you can take to prepare yourself for everything that you can then choose to adopt and for everything that there is in Springfield already for everything that will materialize over next year towards Springfield x 6.1 once you made the upgrade to the initial Spring Public 6 generation everything is at your fingertips everything is ready to be adopted when you have a need for it when you see yourself benefiting from it so we highly recommend taking that jump upgrading the entire infrastructure spring from work itself Springwood the jdk Tom kit hibernate putting yourself into a position to adopt all the goodness that follows from there as you see fit at your own pace all right so that's pretty much the end of my storyline for today um thanks for your attention I'm a round of questions

Channel: SpringDeveloper

Views: 28,024

Keywords: Web Development (Interest), spring, pivotal, Web Application (Industry) Web Application Framework (Software Genre), Java (Programming Language), Spring Framework, Software Developer (Project Role), Java (Software), Weblogic, IBM WebSphere Application Server (Software), IBM WebSphere (Software), WildFly (Software), JBoss (Venture Funded Company), cloud foundry, spring boot, spring cloud

Id: mitWK_DwKGs

Length: 63min 4sec (3784 seconds)

Published: Thu Dec 08 2022