About this talk
In this talk, Martin from the Spring engineering team at Broadcom discusses new tools and features within the Spring framework, Spring Boot, and Spring Data designed to enhance developer productivity. He highlights the release of the latest open-source Spring tools, focusing on the Spring framework 7 and Spring Boot 4. Key features presented include a new logical structure view that helps developers visualize project components and API versioning support that assists with managing multiple REST endpoint versions. Additionally, he introduces the concept of Spring Data AOT, which enables pre-generated repository implementations that simplify debugging processes. Martin explains how the IDE tools provide helpful warnings, quick fixes, and intelligent AI integrations to streamline coding. He concludes with a sneak preview of future developments in AI-assisted coding tools.
Full transcript
Hi. Hey, welcome to the session. Uh, great to see you all here. Uh, my name is Martin. Uh, I come from Hamburg. I work for Broadcom and I work specifically for the Spring engineering team. So part of the team that does the spring framework and spring boot and spring data and all those great great projects and I I guess you are all using some kind of spring
projects in your work I guess right so who's using spring boot whatever something awesome who is already on spring boot 4 yeah who's still on spring boot 35 3 4 3 3 27. Oh, awesome. Okay, let's get going. So, my focus is on the tools. So I work on the ID extensions and all the great stuff that we are trying to do to make you more productive
when you actually use all those great libraries and all those great great um frameworks like Spring Boot, Spring Data and so on to implement applications. So that's basically why I go to work. My goal is to make you more productive, right? I don't want to convince you of any specific IDE, right? I'm not that guy. I'm not that guy saying, "Oh, you have to use whatever Eclipse
or you have to use IntelliJ or whatever in order to kind of use the best tool, whatever." Uh, that's not my goal. My goal is choose the tool that you want to use, the IDE, the environment that you love, and I will be there with you to make you more productive where you are. Um, with certain exceptions, but we will chat about that in a in a
second, right? Because I cannot do everything, right? Of course. Um so uh we released a new version of the open source spring tools the stuff that I'm working on um back in I think November December time frame. So we we always try to kind of support the latest versions that all the projects ship right. So if something new comes along in spring boot or in spring framework
or spring data we try to support this basically bring this front and center for you and support this in the IDE in the best way that's possible. At least we try that and for that I can't really show you everything. Um, of course because we do so much stuff. Uh, I will focus on a few things. Focus on the support for the spring framework 7 and boot
4. A few things. I will show you the new logical structure view which I think is is that's really brand new in the spring tools and it's really awesome. I think I'm really I'm really proud of that. Uh, we talk a little bit about Spring Data AOT. So, who's using Spring Data? Oh, yeah, that's the right talk for you. Uh, and we'll chat a little bit about
some AI extensions at the end. Um, yeah, of course. Right. So, uh, who is using AI coding assistance in one way or the other, whether it's integrated or terminal, whatever, all of you more or less. Yeah. Okay. Perfect. Looks good. So if you want to use the stuff that we are working on. So we do the extensions for VS code, we do the extensions for cursor and
anti-gravity. Um we do the extensions for Eclipse and if you want to download the kind of Eclipse ready to use distribution, we still have that on the website. So you can download that if you use Eclipse, it's kind of a new kind of environment also AI heavily AI enabled. Um you can install the extensions there as well. Uh I don't do the extensions for IntelliJ uh because
we have awesome colleagues at Int Jet Brains and they do all the work for me or basically for you uh to give you the great support in Intelligj already in the ultimate edition for example. They have awesome spring support. So there's nothing left for me to do because my goal is to make you more productive. It's not to compete with anyone or say we do the better
spring support than someone else or something like that. If they do a great job that's awesome. Please use that. Right? If you decide to use a different IDE or VS Code or whatever, then feel free to use the OSS spring tools that we provide and ship. Right? And since I don't really like to kind of just kind of talk about slides and things like that, especially if
the topic is tools, I go to kind of live demos and things like that. It's always a bit scary. Something can go wrong. Something will go wrong most likely. But we will see. Maybe it's a lot of fun at least for you. Maybe uh we will see uh I will use VS Code. You will see similar features across the place uh where we ship the tools. Intellia
has similar things as well. But uh let's let's dive into this, right? And the first thing that I'm pretty sure that that's something that's super obvious, but something that you probably all have written, that's at least my guess. You probably all have written something like controller and then the parent path, right? Someone try. Yeah, I see some heads nodding. Yeah, yeah, yeah. I did that as well.
Uh, of course, uh, this is kind of now nicely presented to you as a warning or in this case even as an error. So I I decided to ship the default thing with an error uh because the attribute in controller rest controller does not refer to the parent path. It refers to the component name. So you now called your named your bean slash owners. But if the
IDE figures out that oh this really looks like a path that you tried to enter here, it flags that. And the nice thing, of course, this this this is stuff that we always like to do as kind of toolsmith folks. Put these squiggly lines everywhere, right? Sometimes they might annoy you. Good news is their preferences. You can enable and disable everything on the preference sites. Every preference
you can individually, every validation you can individually disable or say, oh, I don't hate these these errors showing up. I want this as infos or warnings. You can all control that yourself. And in addition to squiggly lines, we of course also provide always these quick fixes. So we all say, oh yeah, the quick fix is around. You can just turn this into request mapping. Uh move that
over because that's the way you should do it if you want to put your parent path at the class level, right? Okay. But if we dive a little bit little bit into the new features of Spring Boot 7, uh the web MVC and web flux support comes with API versioning. So you can now do something like this and say I support different versions on my REST APIs
on my REST endpoints. So Spring framework and the web MVC support automatically routes kind of the request coming in to the right endpoint. You could for example say okay this method serves everything that's coming from I don't know for version 1.1 plus and beyond. uh every old stuff goes to a different implementation because you're using an old schema or whatever whatever reason you have for the different
versions, right? In the old days, you had to kind of implement it yourself. Now, Spring Boot uh Spring Framework 7 comes with support for that out of the box. Um and we support that in the tooling as well. So you can do something like this but it will tell you this is not enough because you have to configure API versioning support for spring and tell the spring
spring boot or spring framework itself how do you actually want to configure the API versioning. So it tells you there's no API versioning configured so that you don't fall into this trap of oh yeah you put that all across your controllers but then nothing works right or it does not really get routed to the right place. So we try to kind of find those things up front
and of course there's a quick fix and the quick fix allows you to do two different things. It basically allows you to configure this with a uh configurer implementation. So a class that implements web MVC configurer or uh with properties coming from spring boot kind of two options basically. Some people prefer this way some people prefer it a different way. Some people mix and match everything uh
which is also fine. Um so you have quick fixes to do um both ways and there are different kind of mechanisms different resolvers you can enable for these versions say oh I would like to use a path segment like this path you know right this API slashv1 slash and then comes the real path of your thing um or some people like to use requests headers or or
whatever right um so you can basically pick and choose here let me choose this And the quick fix actually in this case goes to the web configuration in your project and adds the corresponding code here to configure the API versioning for you and you're done. Right? Relatively nicely um implemented as a quick fix for you. Uh so the warning goes away. There's a nice little little additional
thing that we did because sometimes um you don't really know where the web configuration is or you forgot about it or it's somewhere hidden in your 100 packages, who knows? So whenever you have controllers in your in your application, there's now a little code lens showing up above the controller that tells you, okay, all your web configuration is found in something like the web config here uh
as an implementation and a little short summary of how your web configuration looks like. So just as kind of a little reminder how your web config looks like above your above each controller and as a plus you can of course click on that and then jump directly to the to the web configuration because that's what maybe you want if you want to take a look at the
details. The same works for the configuration properties. So if you configure that we have properties kind of shows you summary about the the web config properties and allows you to quickly navigate to that. Um we we did not really stop there because there are some things um you can write in Java and that's totally fine right if you if you do that for example if you say
oh let me do something like this right use request header use path segment but kind of what what should the framework now do there's kind of hidden knowledge and the hidden knowledge basically in spring is you can combine ine certain mechanisms for resolving the version. You can for example combine query params and request headers. You can do that but you cannot combine path segments with others. So
there are certain kind of hidden things here but we put that knowledge into the tooling as well. So if you use path segment with some other mechanisms and configure that it basically flags that as an error and saying you cannot do that you should not do that. Same is if you try to do things like uh you do this right so say oh yeah both things tells
you yeah you configure the same strategy multiple times probably also something you should you should avoid doing. So we try to add more knowledge about kind of what goes beyond the language, beyond the semantics of Java, but stuff that we know because we implement the spring stuff and give it to you right away in the in the IDE. So okay um so we looked at those web
API versioning support a little bit. Something that I find really important and some observation that that that I have in mind when I hack on Spring applications is usually that's my assumption maybe I'm wrong but my assumption is when you implement Spring applications you not always think in terms of an interface and a class and and a package and things like that. you probably think in concepts
like oh I have controllers I have services I have repositories I have um DTO's I have configuration classes and things like that so you have these concepts from spring in mind and you implement that in your application and probably you call you name the classes like these concepts like the stereotypes probably classes are called whatever person controller person repository and so on. Um, but wouldn't it be
nice if you would be able to kind of navigate your whole project that way? If you could see your project from that perspective, so that we kind of visualize these concepts right away for your whole project. And this is basically something that we introduced um as something what's called the logical structure view. So it gives you an overview about your project from these stereotype conceptual point of
view so that you know what is inside. Um so if I for example open up pet clinic you see let me increase that is font size okay and back in the last uh perfect don't even see that without my glasses but yeah I should be fine. Um so you see these kind of concepts showing up for pet clinic. to see oh what are all my request mappings
because that's a concept you have in mind right what are all the request mappings what are all the controllers that you have in your project what are all the configuration classes what are all kind of all the repositories that I have and of course you can just navigate to that and then quickly jump between those different things and have these ideas in mind these concepts in mind
when navigating the project maybe you can even use this as a replacement for your file explorer I'm not sure if that's really sufficient and does covers all the cases but it maybe it's worth a try and give us feedback right how useful is that for you and how interesting is that for you um one cool thing about this logical structure view is that it works basically without
you doing anything on the project right it works for spring boots projects out of the box even for spring framework projects without boot out of the box The toolink does just identifies all those things for you that you have in your project. Um, it also supports Spring Modulith out of the box. So in case you use Spring Modulith because you have a kind of giant application, you
split that up into different modules but not going the microservices different projects route but kind of keeping that all in a structured way in inside of the same project and using Spring Modules to do that. The logical structure view recognizes that and takes that into account. This logical structure of your application and in that case it does not show kind of the kind of stereotypes as the
grouping first but it shows you the modules of your project first. Right? That's the first level. So the core uh dashboard drinks whatever those are the modules the domains basically of your of your application. And if you open that up you see all the stereotypes nested. So you can directly see those are the modules and you can take a look inside what's inside of this module. If
you go really deep into these architectural descriptions using onion architecture or hexagonal architecture or or both or whatever um this is supported here as well. So if you configure that in your project those kind of concepts will show up in the logical structure view as well. So you will see that's a module and that's kind of for example the primary port. what's inside of the primary port,
this is the secondary port, what belongs to the secondary port and things like that. If you annotated your application like that, right? This requires that your project uses those things, right? It uses Spring Modulith and probably for those architecture things annotated your elements in your in your applications. If you just have a regular Spring Boot project, there's nothing you need to do. it will just show up
that way with the default stereotypes that we we basically all covered the standard ones from spring. If you if you miss something, let us know, right? File and find an issue and tell us because then we can just fix that and and add that basically. Um but there is there is another way to change that. There are actually three other ways to change this. One is if
you don't want to see all those things, right? Maybe you're just interested in the web stuff or something else. Uh you can configure basically what you want to see, right? You could, for example, say, "Oh, I'm only interested in the web elements, Spring web elements, and it will just show requests, mappings, and controllers." And everything else shows up below others if you just want to focus on
one certain aspect. But maybe if you want to add stuff, it's a little bit too complicated to file an issue to us. And in most of the cases probably we will say no, we don't add that because it's your type that you want to add. Maybe you implement something like your own DTO's, your own stereotypes, your own concepts maybe on top of those spring concepts and you
want to see them in the tree as well which would be the logical consequence right because if you see all the stereotypes all the concepts and you define your own they should show up here as well and there's an option to do that actually so if you use something like J molecules for example let me go to the to the restbox thing um and open the class
DTO Here's a DTO interface defined in restbox in the example project that uses J molecules. J molecules is basically the project that defines the mechanism behind the scenes to declare those stereotypes to define those stereotypes. There are certain components inside where we identify those stereotypes and use that behind the scenes. So if you use J molecules in your project in spring module it it's automatically the case
I guess um but you can also add that to your to your regular spring boot project. If you do that you can do something like like this you just annotate your interface with the J molecule stereotype annotation and if you do that you will see that your DTO's here show up in the tree automatically. So you can just annotate random interface for example and say okay if
you annotate the stereotype it's been taken into account and you see okay this is where all my DDOS's are in my project kind of fairly straightforward right nice thing can just define that and basically basically create the tree the logical structure tree as it fits your needs and but it comes with this with this requirement that you need to add those things as annotations these stereotype annotations
and you need the dependency to J molecules. So if you have that and you're happy with that perfect that's that's great easy way to do it just go. If you don't want that because most of the time I think at least I would not like to do that. I don't want to add dependencies to my project just to make the tooling happy just to make something in
the tooling work right that does not make any sense. If you use J molecules for a good reason in your project do it and you can define those stereotypes and they will just show up automatically and maybe you define those stereotypes anyway because it's great in the source code to see those stereotypes and to visualize them. That's great. Do it. If you don't want to use J
molecules, there's another way to do it because let me just go back to the DTO and disable that again. Uh, quickly refresh. So, we see this is gone again. Um, we can also define stereotypes um with a JSON structure kind of basically the information that J molecules uses behind the scenes as well. We can do that directly. So we can just put a file into the project
saying J molecule stereotypes and usually it's not called sample that's just because I'm preparing this demo. J molecule stereotypes JSON and you add you follow the JSON structure for this and you add your stereotypes in a declarative way. So you basically say okay I have a stereotype that's called DTO that's the ID for that right everything that implements this type is of type DTO it should be
called super DTO and it should be grouped under rest bucks that's kind of the internal grouping which you can enable and disable in the in the tree and just by adding this file to the project without a dependency to J molecules without anything just adding this file this description uh and refreshing the tree, the super DTL show up in the tree and you have basically the same
thing. If you don't opt into the J Molecules library as a dependency but want to do it in a different way for example also kind of share that within your teams um this I think is is is an easy way to do that. Right? If you want to know how exactly the structure looks like the the easiest way for me to do that because I like these
kind of sometimes I just like these kind of copy paste thing but don't tell anyone. Um, you can see how these other standard stereotypes that are included out of the box, how they are defined because if you wonder where the stereotype comes from and why is this element showing up in the tree, you can always go to these kind of open up the definition and that basically
opens up the default definition or the definition that fits to this stereotype node in the tree. So you can always navigate forth and back basically. So you can see how is that for example defined for the request mappings it probably says uh if this is annotated with request mapping then it's kind of display name request mapping and in this group for example and you can mix and
match that you can say if something is annotated or if something implements a certain type or both you can say oh if it's annotated with X or it implements a certain type then it is of this stereotype really easy and straightforward kind of very simple structure. You can define your own groups, but that's kind of a just a side note, right? Cool. Uh, so I really love
that because I can just structure my own put my own things into this tree and they just show up. And by the way, it's just it's also super fast, right? It it really works like magic out of the box. This refreshing the trees and adding stuff. You can even do things like I don't know if I'm let's let's go back over here. As you can see, uh,
request mapping. Let me choose this one. So, if you just change this and press save, it's immediately updated, right? So, it's really always in in sync with your project if you change files. If you change definitions, you should probably press this little little refresh button here, but that's uh that's also quite easy, I think. Cool. logical structure view gives you great overview from a spring and conceptual
perspective of your project. think something really really awesome and if you have any ideas any thoughts anything you're missing please let us know right that's kind of always welcome this feedback is always welcome cool um so looking at let me see I have request mappings here let me go to the repositories for example um repositories in spring are a very specific thing right you just define an
interface and you usually define find these query methods inside of the interface and those query methods um let me maybe jump to the owner repository these query um methods you just define them and that's it usually right you don't need to put in SQL you don't need to put in kind of the exact statement whatever it's all generated by spring data dynamically at runtime so it basically
looks spring data looks at the interface what it needs to implement creates an implementation of this interface at runtime using a proxy mechanism and then it just executes this stuff. And if you ever if you ever did this in the past and you tried to debug you might have ended up in this hell of oh proxy proxy proxy dynamic dynamic proxy dynamic dynamic proxy. I have no
idea where I am because it's always on this meta level, right? It's always on this kind of oh there's some proxy meta generated something, right? It's really weird. Wouldn't it be nice if you could just debug it as if you have written your repository yourself? Your the implementation basically yourself, right? It would just look a lot simpler. And that's why Spring Data introduced a mechanism called Spring
Data AOT. So ahead of time, which means that at build time, Spring Data generates an implementation for this repository as and puts that into the project. So there's no need at runtime to generate repository implementations dynamically using proxies or whatever. It's just compiled Java source code that's being executed at runtime. And in case you do that can configure that in your project later spring boot spring data
versions. Um, if you do that, the nice little side effect is that all this information that Spring Data does and and creates and uses at build time to generate the source code, it gives us for the tooling as well. So, we can use that. For example, we can say, oh, we now know there is an implementation being generated at build time. And you can just go to
the implementation. And then you see this is the source code that spring data generated in as part of the build for this method in the or for the repository implementation. Basically, the interesting thing is this does not there's there's no type hierarchy between those interfaces and the implementation. Don't worry implementation details the magic of Spring Data. The cool thing is the tooling knows that. So the tooling
can just help you directly navigate to the implementation and you see that um maybe sometimes you're not really interested in the exact implementation. So this is super useful if you want to do debugging, right? Because you can just set a breakpoint in the source code. You can just debug as any other Java source codec you have written, right? that I think giant step forward for these debugging
purposes. Maybe debugging is not always kind of the kind of the thing that you do day in day out especially not for spring data repositories. Maybe it's kind of it's a rare case I don't know. Um but sometimes you're interested in this piece. So the stuff that is actually executed against the database as the statement behind the scenes for this query method that you just defined in
the repository interface. And since spring data has to kind of create this statement somehow to put that into this generated source code. We also can use this and display this right above the the method. So whenever you use Spring Data AOT and you write your implement, you write your your interface for the Spring Data repository, the SQL statement that's being executed behind the scenes is just kind
of being being inlined and shown up in the source code automatically for you. So you can see what is the SQL statement that works behind the scenes for this query method that or this this query method that I that I not implemented but defined in the interface, right? I think super useful. It covers all the different different aspects like is SQL or HQL or JPQL or whatever
can do all that. Um just you cannot navigate that but it's just kind of a little kind of reminder about this is this is the exact statement that is going on behind the scenes which I think is sometimes just super interesting and sometimes always useful to see what's really going on. you don't like that statement or maybe you think you can do better or you want to
do a little optimization here and there or you want to define your own statement. So in that case you typically do things like this, right? You add a query annotation and you add your statement. That's fine. That's awesome. Um, the good thing is if you start with this and you want to turn this into the annotation, you can just press the little additional action here that basically
just quick fix, right? Just grabs that, turns it into the annotation and basically converts this. So, it uses that as a plus. You can see this is nicely syntax highlighted. So it's kind of SQL syntax highlighting inside of the JAR class inside of the text block. The text block here is nicely formatted. So it's not just randomly broken into lines. It's broken into lines where it actually
makes sense from a SQL perspective, from the language SQL um perspective. And uh since we like squiggly lines, uh we also kind of validate the SQL statements inside of the annotations for you, right? So if something is wrong, we tell you something is wrong. This is not a valid syntax for SQL statements. Uh same for JPQL, HQL and so on, right? So nice things. And if you
did this and you finally ask yourself, what the hell does the SQL statement even mean? Because I have no clue what this is actually really doing, what this really means because I have never learned SQL. I have no idea about SQL or there's a kind of very special elements. You can ask the AI of course to explain that to you because the AI knows of course everything
and to avoid you kind of copy pasting everything into that there's also a little code showing up that says please explain and this will kind of create the right prompt for you and just dumps that into your chat for your AI assistant in this case kind of copilot which is trying to explain that optimizing tool selection. Yeah, always a good idea. And then it explains what this
SQL statement is all about. Something that we try to do across your source code where we think it makes sense or it could make sense because this is something that's very special to Spring. So if you do for example um spell expressions difficult for me to understand all the spell expressions. You can also say please explain the spell expression for me. By the way, it's all we
also syntax highlight spell expressions and validate that of course, right? Uh things like that. So nice nice stuff. Um using AI a little bit just as a quick quick shortcut to basically save you some typing if you want to explain that. It doesn't really replace your your coding exercise. Um, so those were the things that I wanted to cover about what's what's really new from what we
already do, what we already know, best practices, stuff that we usually do, stuff that we did in the past in a similar way as well for other features, for other versions of the library and so on. Um, but there is a little there there's there's uh there's more one more thing. Um because I also would like to show you a little sneak preview and a little sneak
preview is always a bit risky. Uh and it's especially it's not a promise, right? So we might never ship but it's but it's so it's so interesting that I I I need to show this somewhere, right? So I I just enjoy enjoy showing these kind of things that kind of we work we work on we started to work we started to look into but maybe it does
not really ship in this way. Maybe it ships in different way, maybe we need feedback or we we definitely need more feedback on that and so on before we can before maybe it's get really useful. But it's always it's also interesting. So if you go back in time through the history of the spring tools, I said we always want to meet you where we are, right? So
whatever you choose as your IDE, we try to make you more productive. So in 2004, we started on that journey. It was Spring IDE for Eclipse because Eclipse was the major player in the IDE game back then, right? It was the IDE to use. Everybody was using Eclipse. So, we were at Eclipse. In 2017, this changed because new players came in, new more lightweight IDs appeared. For
example, Visual Studio Code was on the horizon, got kind of reasonable Java support. So, we thought, yeah, that's interesting. we should be there as well. So maybe that's also kind of a new IDE that people like to use more lightweight thing. Um and we rearchitected the spring tools to kind of basically fit those needs to support multiple IDs to be wherever you are to be more flexible
in the future. Right? So that's what we shipped in 2017 or 2018 support for Visual Studio Code. So then Copilot joined the game. So we did these little AI experiments with that. And in 2025, um, we supported Kurser IDE. I'm not sure if that's the right word, but kind of kind of a new IDE that puts the AI assistant front and center and is more created around
this AI assistant also based on VS Code behind the scenes, but kind of that's what people started to use heavily. So there we are. We support you with Spring Tools. The question is 2026. What do people use 2026 anti-gravity? Yeah. Yeah. For example, what else? People use claw code. So they go back to the terminal. Ah, forget about all this this crazy UI stuff. Forget about the
squiggly lines. um and uh use AI assistance on the command line with clot code and the the cool thing is in cloud code you can add plugins. this is the same project that I open up in in VS Code a second ago. Now we are in in clot code and we see plugins installed some Java things and oh spring boot. So now spring tools can be used
in cloud code as well uh with some kind of MCP stuff behind the scenes whatever but let's not talk about all the all the details. So what you can do now with that and it kind of it it changes the perspective a little bit because in the old days if you use VS Code, if you use Eclipse, if you use IntelligJ, whatever, we did all those tools
to basically make you as the programmer as the one writing source code more productive. Now Cloud Code is writing all the source code. Maybe not all of it, but a lot of it. Uh maybe we need clot code a little bit better at writing good spring source code. So that's kind of a new slightly new way of thinking about the tooling that we do. Um but interesting
experiment. So you can now ask for example cloud code is what is the latest version of spring boot? And usually claude I don't know cut off date of the models whatever is at version 3 whatever something but now it you can also already see that it's calling the plugin and it tells you oh yeah yeah the latest it knows about the latest version of spring boot for
example now so it knows about what's the latest and greatest it even knows about the OSS support ends in end of this year the commercial sport ends whatever so it gets some additional information and this information is not secret right you can find that on the web as well on the Spring.io website for projects, but the plug-in kind of makes a little bit more more tasty for
the AI assistant to use those things. Um, and we could can do other things. So let me for example try to do something like open the owner controller Java file tell me what the spring boot language server is thinking about this. Let's see. Always demos with these code assistants is with these AI assistance is always kind of extremely unpredictable. So now it's now the fun begins. So
as you can see it's kind of tries to call the spring tools behind the scenes kind of basically to poke around and see is it kind of delivering hovers? Is it delivering kind of additional information? Is it delivering symbols? So what information does the spring tools reveal about this file and it tells me some stuff for example oh there are different request mappings that I found in
inside of this of this class from the spring tools and there are specific validations basically the same validation that you saw as a user saying oh this version is is weird um you see that showing up in here which is really useful because if I would not do this I've tried that trust me And in the previous demo that I did, it actually exactly happened. Uh, Claude
code just ignored the Sping tools and thought that the version attribute, oh, this belongs to HTTP 1.1. There's something something going on. This this method should only be used with HTTP 1.1 because it just thought, if you can call it thinking, uh, that version is equal to 1.1. Oh, that must refer to HTTP protocol version 1.1, which is totally weird. Right now with the tools, it knows
exactly, oh, this refers to API versioning of Spring Boot and this is maybe what I should tackle. The most impactful issue is the doubled owners prefix. Oh yeah, yeah, yeah, yeah, yeah. The AI is always right. Uh, cool. letter demo clawed code enabled with spring tools. It's just the beginning, right? So, we haven't really figured everything out, but we need to do a lot more in this
space and and and try to figure out what's the best way to kind of educate cla code um a little bit more about to do the right thing from a springy perspective. Um, but we will we will try to do that and with that I would be more than happy to go back to the slides of course uh show you some links where you can find more
information but also a answering questions. Of course I forgot to say you can ask questions anytime which is always kind of a good idea to say that at the end but uh maybe there are questions. No question. Oh yeah, there's a question in the back. >> Oh, the question is whether the cloud code plugin is is a publicly available experiment or whether it's just a kind of
a secret experiment. Um, you can find it. So we so we we >> we so we we we we don't it's not part of any spring tools release yet. So we don't ship that. It's not part of the main branch. There's a branch called claude. No surprise. And you can find the plug-in in this branch and the work that's going on because we do this as kind
of a feature branch and work on that in this branch. Um since we kind of still experimenting a lot with it. Um, so you can try that. There's a nice read me that tells you basically what you can what you can do, but it's also very early and very rough. don't try it out and just tells me, "Oh, nothing works. What's what's going on here?" Uh, so
be prepared to kind of see some very rough stuff in the demo. Of course, I always try to show everything that works, right? And not all the stuff that does not work. Uh, but there's quite a bit of stuff that does not work. But of course you feel all invited to find some stuff in the repository and try it out if you want to and give us
feedback right there and you can even contribute if you want. So the all the open source projects they are open in the open source. So you can contribute stuff if you want to um happy to take a look at that anytime. Does it answer your question? Yeah. Okay cool. There was another hand going up in the back somewhere. >> Yeah. So the question is it really a
question >> a follow followup. So basically you could also contribute general per so you mean things beyond cloud code or Yeah, absolutely. Absolutely. Absolutely. Yeah. If you if you browse things like the the Versal skill repository or other other places on the internet where everybody is writing their own skills and things like that for agents, you will find plenty of things around Spring and Spring Boot and
whatever. There's nothing official from from the Spring team itself yet. Um, and I'm not sure if that will ever be the case. I don't working on something like that, contributing something, there's no guarantee that those contributions will be accepted, of course, because there's always these question, do we want that? Do we not want that? Do we want to kind of keep it keep it separate? Um because
for the spring team as you probably know there's also always this angle on those things of especially for the libraries if we include something if we put something into the library into spring boot into spring framework there's always this expectation that this is supported this will be kind of supported for the next versions this is supported in the open source this is supported and and kept compatible
for for a long time because that's what probably what you like about Spring Boot, right? If you use that for, I don't know, for 5 years, for 10 years, maybe for 20 years, and you were always able to upgrade, you are always able to jump to the next version, it's always maintained, it's always up to date, it's always using the latest technology, can always use it with
the latest JDK and so on. And that's actually a lot of work for the team. So, as soon as we kind of put something to those projects, all those thoughts need to be considered, right? um which makes it sometimes a bit difficult to kind of be always on the latest and greatest on the latest thoughts and the latest experiments. Uh which is also kind of you hear
the let's do it as an experiment and see how how well that goes. Especially in the AI space where the landscape is moving so fast, it's it's really hard to do put something to libraries where you think, oh yeah, this will survive the we will support this for the next five years, something like that, right? It's kind of next five years in the AI space. What are
you thinking about? Um but it's interesting question, but I don't want to to stop you from contributing or from thinking about this. Uh it's more an invitation, but I just want to set expectations, right? So you don't that you're not disappointed if stuff does not directly go in but happy to discuss all the stuff. Yeah. Another question >> yourself using AI for developing the spring tools. >>
Um so the question is whether I use myself cloud code to develop the spring tools. Um, no. >> I I I I'm not I'm not company policywise from the company. I'm not allowed to use spring claw claw code for the stuff. We use a different AI assistant for that. Uh, but I heavily use the AI assistance to develop Spring tools. Yes. nowadays. Yeah, it's in so I
would say every feature that we add to the spring tools and every bug fix that we do on the spring tools nowadays for the spring tools for that project uh is kind of used is done by using AI assistance like cursor or and the models that we use behind cursor. Yeah. So we use cursor inside in inhouse and do >> So the next question would be do
you see future software developer all have AI AI agents as a jar and you don't make an incorrect coding anymore >> um interesting question so the question is I need to repeat that for the recording all the time don't be surprised um whether I think that in the future everybody will use the AI assistant and more that guy will or that that that thing will do the
coding if it kind of covers that question which is kind of the I think the giant elephant in the room that everybody's asking asking himself herself um at at the moment right now uh and I can only speak for for for myself right it's not not speaking for the spring team of what the other spring members are doing or what the other spring projects are doing so
I and of the stuff that I said before about I use cursor stuff every day to to do to to do the coding is just for the spring tools, right? I have no idea about boot and framework and all the other projects. They probably operate slightly different. Um I think you have to use these AI tools nowadays because they make you a lot more productive and a
lot faster doing I I personally don't see them replacing me as a as a software engineer in the near future because I think I still need to kind of at least I myself I still need to review what's going on. Is this the right thing? Does it fit into the project? Is this the right thing to do? Um, and of course I always need to think about
it from a from a structural perspective, from a perspective of is this the right thing to do for the project, right? For my vision of the project, what I think where the project should go to, what should we do, what should we not do? And I always have those thoughts in mind when I think about features, when I think about what to do next, when I think
about how to implement a feature, how does it fit into the structure of the project? very often not only think about in a in a small technical scale, oh I need to change this class and this class and that class but I also have other architectural ideas and thoughts in mind about oh this should be done in the indexing this should be done over here. Oh, this
the indexing should not do XY Z because I know that if we do something in the indexing part of for example the source code analytics right I know that we cannot call an external system we cannot do anything that blocks we cannot do anything that takes long because validation and squiggly lines whatever all that is counted in milliseconds right we cannot do if we do auto completion
we cannot do something that suddenly lets you wait for a second on the autocomp completion. Right? If I give you an auto completion where you need to wait a second, just a second to see the auto completion, you would never use it. Never. Right? You have this feeling about autocomp completion is something that is there immediately without even noticing that something happens on the machine in the
background. And that's what we what we focus on, right? Consensus has to be there immediately, right? And and I have all those thoughts in mind. and what the AI the way that I use the AI what's really good at so if I say I have for example this validation and I want to implement another validation a validation that checks for is this annotation compatible with this is
this on the class and not that the AI is extremely good at that extremely good because it looks at all the other validations that I have and it's basically doing the same than the other validations but slightly different right oh it checks for this ination it does that is doing doing X doing Y and it's really really good at kind of doing this this kind of looking
at what is there and doing something like this it's really extremely good at that even generating this the test cases for that is really really good but I still always have these other thoughts in mind uh and I don't see the IDE having the the AI having that those things in mind yet so that's why I think all these questions about the why and and the what
is not something that I would hand over to the AI yet that's why I see my personal job safety still still secured from at least from that perspective right economy wise you never know but that's different topic um but there are other questions related to that right there's a giant question in this AI space about what the AI what the effect will be if you implement your
your system using an AI assistant over a longer period of time because there are kind of scientific research studies that for example show you that if you if you spend most of your time reviewing code from the AI instead of writing the code yourself, you lose the capabilities to review code over time. So because you're not writing code anymore, you lose over time the ability to judge
code to see if this is the right thing or not. You are able to do this now today because you write code yourself. And you did all this yourself in the past. If you don't do that anymore, you lose this ability. So if you only use the AI coding assistant all the time to do that, you will lose the ability. So one day you will basically be
there and say I cannot even really judge the output of the LLM anymore because you you lost that. So it's and I that's just an observation, right? I'm not sure if that's kind of is good or bad or does it mean anything good or bad in the future or maybe you I don't need to review that anymore. So that's it's all good. I so I I don't
know. I cannot I cannot really judge it whether it's good or bad. But it's just an obs interesting observation. So it's many more questions, right? We can probably discuss for five more days at 10 more conferences about only that, right? Very it's interesting. Cool. Um, thank you all for coming. Hope you enjoyed the session. I hope you have a a great rest of your day and safe
travels home. Thank you.
More from this event
See all 34 talks →
Java: 30 Years and Beyond | Ana Maria Mihalceanu (EN)
39:47
Scaling Data in a Sovereign AI Platform | Johann Strauss & Markus Kett (EN)
49:29
Code Is Cheap. Software Isn’t. | Markus Eisele (EN)
47:23
Building a Digital Product Passport with Java and Cardano | Fabian Bormann (EN)
46:54