Spring Tools 4 and IDE Innovation, with Martin Lippert (Ep. 97)

Episode 82 · 54:20 · SRT · archive.org · all Tanzu Talk

As I was mentioning before we were recording, I moved my office downstairs. And, you know, the audio quality can be a little mixed because we've got the wood flooring down here. But I do have a carpet underneath this. So here we are recording. Do you two, does it sound any different than usual? No, I mean, it sounds, I think, grittier, earthier. Earthier. You know, we're really getting the real Coté now. I am closer to the earth. What I found out is that on the side of my house is very popular with squirrels. They come over there a lot and they just mess around. I guess they're looking for things. I don't know how they find anything to eat in the gravel we have out there. But, you know, I guess when you're a squirrel, you eat whatever you can find. Yeah, I feel like we're going to have new guest stars on this podcast now. Squirrels. Well, you know, we've already had lots of cameos of my children beating on the door trying to get access to me. They just, you know, at the ages of four and eight, I don't think you understand, like, Daddy needs to make money so you can have toys. It hasn't quite gone through. We'll see. Maybe when they get to Civics, they'll learn that. It'll be good. Well, anyways, why don't you briefly introduce yourself, guest? Sure. My name is Martin. I work on the Spring team at Pivotal. And the purpose of my work here is I work on the tooling. So I work on IDE plugins to make Spring developers happy during the day and hacking on their Spring apps. And that's what I'm working all day. Tools. You know, we'll come back to you in just a little bit. We have a few brief news items. And feel free to chime in. Or as I like to tell people, it's always a good time to catch up on your email if you're not interested in that. Maybe in the tooling world, you do a little competitive analysis of what else is going on out there. I don't know. Whatever you do. But first up, related, there's a brand new huge release in Spring Boot 2.0. Now, Richard, what is in this huge release? Man, it is big. It is the first. I mean, Spring Boot releases constantly.

There's always these milestone releases, and there's always point releases. But this is the first kind of 1.0 is back in 2014. So this is the first major, major release in these four years. And so this brings in Spring Framework 5. I think we've had discussions of that in the podcast back in August, September when that came out. This gives reactive programming, gives a new Java baseline for Java 8, supports Java 9, some backwards compatibility stuff, also some breaking changes in some small areas. But just a number of big improvements to the framework, some refactoring. So if you're a Spring developer, I was looking at the stats this morning. Devs are going crazy on start.spring.io, building new projects with 2.0. So big milestone. A lot of these other projects are now updating to support 2.0. And yeah, that's a great next step that we'll be building on top of from here. Yeah, I was catching up on one of your recordings of your talk at SpringOne platform, Martin. And as you say, people are cuckoo for the Spring Boot. And that seems to be a major driver of the tools that you've been working on recently as well. Oh, yeah, yeah, totally. Yeah, we work a lot on improving the Spring Boot support in the tools because people really, really love the Spring Boot experience. And we try to make it even easier, right, in the tools to just get a running boot app, including the start at Spring.io integration and getting a Spring Boot app up and running in your favorite IDE in just a second or just a minute, right? So that's, yeah, the people love the experience. I like that idea there. It's preventing developers from getting another cup of coffee because it operates too quickly. It's sort of addressing the health. You know, I've been reading recently that one of the things that makes you live longer, maybe I shouldn't be reading these listicles, was like drinking coffee. And I don't – it's hard to figure out if that's a cause or a correlation or whatever. Like maybe if you live longer, you, like, get tired, so you need more coffee. I don't know. But there has to be some limit of how much you should drink a day.

I haven't found it yet, but it must exist where it starts to become unhealthy. So if anyone knows that, I would appreciate the details. That would be good to know. I mean, you and I haven't – we haven't talked about the bacon maybe killing us storyline as well, which seems like that's hitting both of us pretty hard right now. Now, is that actually – is that out now or are you just making that out? Yeah, I saw it last week. It's like nitrates or something, which I think all of us are willing to say that our life is worth a little – I mean, I'm okay maybe going a little earlier, but with a life full of bacon. Yeah. Man, that's – talk about a tradeoff. You're going to need some Monte Carlo simulations to figure that one out. That's a hard one. Go study stats so you can understand exactly what probability is. It's very confusing. Well, speaking of things that are confusing. So I think – was this over the weekend? Like GitHub had a huge, as they say, DDoS, which is not an old operating system. It's a distributed denial of service attack. And like if I remember the little bit of reading, like they handled it pretty well, as I recall. Like it didn't bring down the complete development community. But, you know, what I always wonder with these things is like are they being like held hostage, like to have ransom? Or like is that the only reason you do a DDoS attack nowadays, like of a commercial entity? Or is it just like, you know, I just want to – I accidentally asked Alexa to do the wrong thing. Yeah, it's a good question. I mean, I don't know for sure. Sometimes you see those as response to like, hey, this site is hosting things we don't like. So therefore, we try to take the site down. Or you're trying to do, you know, ransom stuff. Or you're just trying to prove that you can. But, I mean, in their case, they were handling an almost comical amount of traffic. It was whatever, a terabyte per second coming in. And I think they resolved the whole thing in about 10 minutes by working with upstream providers. And, you know, the reason I listed that in the news was mainly because, again, I think we talked last week when we talked with Molly about security. And it can be easy to kind of leave out the DDoS concerns because you're just thinking, again, about patching or you think about, you know, traditional security stuff. But taking your system offline and having kind of these breach points is a factor in security.

So thinking through yourself and maybe playing some of those games internally with your mission-critical apps to see how would we respond to a DDoS attack is probably a good exercise for a Friday afternoon for your teams if you don't already do that. Yeah, every time I see some, like, I guess you would call it security attack like that, like, I just think, like, man, wouldn't it be terrible if you're just like, I just want to be online so people can order dumplings for me. And the next thing you know, you're worrying about people, like, mining Bitcoin on your server or something. Like, it's just sort of like all these annoyances you need to put up. I guess you would use some other service nowadays to sell your dumplings or whatever. But it just seems like a lot of hassle that you would have to put up with. But you probably don't need, like, a huge DDoS attack defense. You'd be fine. So then also in the news, I like the way you characterize this. You were like a strangely positive piece from the register where our friends over at VMware had their, I guess, their quarterly call last week. And one, there were a couple, there was all sorts of interesting stuff in there, I'm sure. But relative, relevant to our interests around here, they were saying that there's been a fair amount. And, you know, for as new as it is, I'm sure a fair amount is fair compared to, like, zero or one. So there's been a lot of incoming interest in how they would use their networking stuff NSX along with pivotal container services. And, you know, being a former analyst, I went and formally did a little channel check with our own people and asked how many, I don't know, inquiries and questions for POSs there are. And, yeah, there's a good amount that people have said people are interested in, which I think it's fair to say in a very favorable way that, like, yeah, everyone's interested, sort of in everyone minus one situation. I'm sure there's people who are not interested, but there's been a lot of incoming requests about it. And then also, as highlighted in the article, it's a favorite thing of people who watch acquisitions to know if a thing has paid off or not.

And I haven't really paid attention to NSX, but it says they're at a run rate of $1.6 billion. So one would assume that they've been approaching that. So I guess the investment has paid off more than enough. But, yeah, remember software-defined networking? That was a thing, right? No one really says that anymore. SDN. Yeah, well, now they're paying for it versus just putting it in white papers and things like that. So clearly, people are buying it like crazy. And I think, again, I found this interesting because, on one hand, you know, it's easy to, I don't know, armchair quarterback and say VMware has no future in this cloud-centric world. And, you know, hey, VMs are giving way to functions and containers. And, like, everyone likes to figure out how these existing companies are going to go pass away at some point. In this case, I don't know, VMware, even the LREG article, right? I mean, it was the VMware might have cracked the container market. Like, maybe, hey, maybe these big software companies are actually good at software and they keep finding new ways to apply it to modern technology. In VMware's case, look, they've got another billion-dollar business for networking. Hopefully, they have another one with PKS with us. I don't know. Good to see that, you know, networking matters. It makes things easier, especially when it's software-defined. And PKS is clearly solving a big problem in VMware's market space. So that all seems like good news. Yeah, I should track down who the headline writers are over there and send them a warning. They're like, don't let this happen again. Positive headline. No good. Yeah. No, I mean, I was waiting to see the comments or something. Like, where is the negativity in this article? It wasn't even in the comments. So I don't know what's going on. Well, you know, related to that, and then we'll close off about talking about our buddies over at VMware. I forget the stats off the top of my head, but I remember a couple years ago, or maybe a year ago, seeing that their mix of revenue had shifted enough that, like, it's not like, you know, 80% or 90% based on selling vSphere and stuff. So there's plenty of portfolio-wise, they seem to be managing revenue sources, which is encouraging, you know, for all of us, but for that company as well.

So speaking of things people freak out on behalf of VMware about, whether it's neater or not, over at RedMonk, Stephen O'Grady wrote a, for him, uncharacteristically brief piece. I was rereading it this morning, and that's the first thought I had is like, wow, this is really short, which I only mean in a positive, jesting way, I guess. But he was essentially, it was sort of on its own, an interesting statement, but basically yet another in the series of Kubernetes has won and so forth and so on. But he was, you know, positing that it was, as is RedMonk theory, the developers who had driven that a lot. And I think, you know, that's a fine posit, but I think more interesting was the ensuing, like, miniature discussion about it in the Twitter world, where all great conversations occur nowadays. And I think there was a good clarification that O'Grady made based on people heckling him. The heckling being that, like, oh, Kubernetes is for operations people, so developers are in no way responsible for that. And, of course, Stephen was like, you know, in so much as, what is it, 280 characters now? Sort of like, well, I forget what he exactly wrote. You know, I could bring it up and read it, but that's tedious. Essentially saying, well, developers contributed a huge amount to this because when they were containerizing their things, that helped drive even more need for Kubernetes. And I think that's a fair way of looking at it, that if something like Docker hadn't come along and had all these developers excited about how much they could package their applications, then the, you know, the need for a Kubernetes would have been a little weirder. But I think more related to my interests, like, I don't know, I think across, like, across, I think over the last six months or so, I have been noticing this trend of people essentially saying, like,

if you're a developer, you shouldn't need to worry about Kubernetes, which is, I don't know if I, like, you know, was having some sort of, like, I had, like, some blackout drunk weekend or a stroke or something. But I feel like the last two years of Kubernetes was, like, driven a huge amount by developers being interested in it and talking about their phrases. And so I've been trying to, like, narrow down a way of investigating this more. And I thought I should put together a talk. And, of course, there's going to be alliteration and all C's were replaced by K's. I mean, that's, like, the way it's going to go. But it should be something like Kubernetes for the confused, where it's sort of, like, a non-technical overview of, like, what this thing is and if you should use it and how to think about fitting it into the way that you do things. So as often with my presentations, I have no idea what would be in it. It just seems like it would be a good talk. So if there's anyone out there who was confused at some point and de-confused themselves, it would be nice to hear from them. And, you know, we'll see if I actually do this. One of my rules is, like, you should never promise to do anything until it's done because often you will never actually do it and then it's embarrassing. But anyways, you know, I'll go talk to people that I know, but it'd be good to get input from others because, you know, I was sketching this out. And one way of putting it, I don't know if this is true at all, but just one way of putting it is, like, just to arbitrarily pick a number. In the future, it seems like it would be the case, and I keep hedging this, that something like the following would be true. Only 5,000 people in the world need to know how to run Kubernetes. And, again, I don't know if that's the right number, but, like, you probably need, like, let's say 50 people at the top three cloud providers. Let's say 100, right, who are running all these Kubernetes things. And then if we take the assumption that, like, let's take the global 2,000 and let's say 50% of them are going to run their own Kubernetes cluster

for awesome, perfectly good reasons, and they only need, like, 100 people. Now, I can't actually do math, so I don't know if that adds up to 5,000. But, like, you know, you get the idea that, like, if there are not that many big Kubernetes clusters running in the world, then, like, how many people actually need to know about it, which then would validate the criticism that developers shouldn't care about this stuff. But it is, I guess, in comparison, it would be interesting to know how many, what do they call them, Vexperts? How many Vexperts are out there? And then you could look at, like, really expensive, like, hyper-converged infrastructure clusters and see how many are out there. But, I don't know, it would be interesting to find out, like, all right, so if Kelsey Hightower says developers don't need to know about Kubernetes, is that true? And then if that's true, who should know about it, and how do they need to be thinking about it? Which I'm sure I'll get some corrections on what was said where or whatever. But, anyways, I could use some help on that. That's a good take. It just seems like it's a maturity model question. Like, right now, developers have to care because they have to drag operators into it. And then operators, I mean, to your point, like, if, it seems like if in 10 years from now, it's still a primitive that developers are using, we've done it wrong. Like, by then, it's a commodity and a platform. Just like, arguably now, what, is there 10 companies in the world that should build their own application platform? It's just, what are you doing? Like, why would you do that? So, it's the same thing here, right? In 10 years, why in the world would a developer still be interacting with Kubernetes? You're going to interact with the abstractions on top of it. It's still always about velocity. It's still always about delivering. I think it's a necessity when a technology comes out that you have to get into the guts of it, especially as you're championing it within your organization. But at some point, why am I still in the guts? That's probably not where the value is. So, I think it's just a maturity stage. Of course, right now, there's all sorts of people who need to know it and are getting deep in it. I just hope that's not the case a few years from now. Yeah, you know, that reminds me of, like, in the, I don't know what the mid-late 2000s is,

but in the mid-late 2000s, there was, I remember when the word virtualization would come up, you had to ask if it was type 1, 2, or 3, or para-virtualization or whatever type of virtualization, which at the time, as you say, was, like, nice to know, but nowadays, no one cares, right? Like, it's just virtualization. It doesn't really, and that could, it's probably largely because, like, one of them went out as the dominant way of doing stuff, but it was much discussion of the type of virtualization you were using when ultimately the outcome you wanted was irrelevant. And then, you know, relevant to our interest, I'm also always reminded of something I always noticed at Java 1 when I would go, which was, like, it's sort of, it's not paradoxically, but much, much to, much against the problem that Java was always trying to solve, which is sort of, like, developers should not care broadly, right? I remember the JVM tuning talks always had, like, standing room only line out the door, and it always seemed to me that, like, man, if you've got to tune your JVM that much, something's going wrong. Like, it's supposed to, like, take care of all this for me, but, man, people loved all those, like, dot capital X flags and all that stuff. I mean, it's a history of computing stuff. I mean, I just finished reading Showstoppers. It was the story of how Microsoft had to rush to build Windows NT, and it was really an awesome book, but it was, again, the story of, like, back then you're still figuring out kernel questions, you know, all these people trying to figure out, to your point, all these really low-level details, and even by the end, it's like, I'm just trying to build apps on Windows. Like, I don't want to deal with the kernel. I don't want to, you know, I think this is just always, right? Things get introduced. You have to know the guts. They mature. Smart companies bake them into platforms, which then people can get back to the work they should be doing. Yeah, yeah. So, Martin, it sounds like you've spent a lot of time optimizing the VM, or at least you've seen people do it.

Yeah. I also remember these long lines in front of the full-packed rooms at Java 1 and reading long lists of all these flags for the JVM and trying to figure out what these 50 different garbage collectors could do or should do or what they are going, why they're going crazy on my IDE session, things like that. Yeah, I also remember those times. Mm, the garbage collectors. That was a good story. Yeah. Yeah, you know, that was one of the early instances of snarky developers that they would call something garbage. There must have been some more technical term for it, but that's the one that stuck. Well, so on that topic, back to yourself and Spring Tools. So I think, I mean, let's start with, like, the newest thing. So Spring Tools 4 came out, like, as a way of introducing what Spring Tools is, but also kind of talking about the dramatic shift in it. Like, what's the deal with Spring Tools 4? I mean, it's a pretty, like, monumental release, right? But what makes it so? Yeah, I think, so it's not really a release. It's a public beta at the moment, right? So the release is going to be GA, I think, in the middle or second half of the year. But it's a pretty dramatic shift. In the past, we worked on, let's say, IDE plugins to support Spring developers for specific IDEs. And we, as a team, focused on Eclipse, was kind of the most favorite Java IDE back then. And we wrote plugins for Eclipse and really learned a lot about these Eclipse APIs and implemented those Spring Tools for the Eclipse IDE in a way that they were tightly integrated into Eclipse. They knew everything about Eclipse. They really, they really, they were really deeply integrated with the existing Eclipse IDE, right? And we worked on that for,

I don't know, maybe for 10 years or so. And then over the years, it was clear that in the old days, there was kind of Eclipse as the main, main Java IDE. And then there was IntelliJ from JetBrains as kind of the second IDE. But nowadays, it's, people choose different tools all the way down, right? They do Eclipse IDE, they use Eclipse IDE for Java development. They use IntelliJ. They use Atom, they use Sublime Text, they use whatever, whatever they want, right? So it's, and one of the reasons for that is that they, they do not only hack Java code all day, right? They work on HTML stuff, on JavaScript things and so on. So they, they really pick and choose those tools. So we thought about, hmm, what should we do with, in this landscape for, for supporting Spring developers, right? Because the IntelliJ stuff, IntelliJ guys, they have, they have great Spring support. So that's, that's good. So we don't really have to care about how to support IntelliJ for Spring developers. But what about, what about the Eclipse, the future of the Eclipse IDE? What about all the other tools that people are starting to use? So we, we thought about that for a long time and took a, took a look at all the different, different tools people start to use, like these lightweight editors on the one side and these big heavyweight integrated development environments on the other side and then the, the new kids on the block like the, the cloud IDEs. Is that maybe something we should take a look at? And, and while we were doing that, we figured out that we should really focus on what is important to us. and important to us is supporting people who hack Spring apps independent of which tool they choose to do that. And we thought about how, how should, how should we do that? And then

we, we, we came along with Visual Studio Code that came out roughly at the same time. and the, the Microsoft guys working on Visual Studio Code, interestingly, kind of the, the same team that did the Eclipse work back in the old days. Sort of the same, the same group of people or maybe a sub team of that sub group. and this Visual Studio Code approach was really, really interesting to us because they, they, they invented sort of a new architecture for these language tooling for how to support different languages, right? They were not focused on Spring or certain frameworks, but they were focusing on how can we support TypeScript, how can we support JavaScript, how can we support C Sharp and things like that. And they came up with a really interesting idea. what they call these, these language servers. And we, we adopted that and sort of started to rewrite all of the Spring tooling on top of these new architecture which, which allows us now to implement the Spring tooling just once like all these content assist and validations and hover helps and all these, these kind of things that makes your life easier as a Spring app developer. And we can just write that once in a language of our choice. In this case, of course, we like Java, right? To do Spring tooling and we can deliver that and support different IDEs and different clients at the same time. We can put the same stuff into Eclipse. We can put the same stuff into VS Code and into Atom and maybe in the future into, I don't know, 10 other IDEs or lightweight editors or whatever. so that was, that's kind of the big architectural shift behind the scenes that really allows us now to support all the different IDEs

and all the different lightweight editors that are out there in the world and we don't have to take care anymore about all the details of the internal Eclipse APIs and all the details about one specific IDE and then if someone else comes along saying, hey, can you support VS Code? Say, oh yeah, now we have to rewrite everything in, let's say, TypeScript and yeah, let's start from scratch and rewrite Spring tooling in TypeScript and then the next guy comes along and says, oh, can you support Atom? Oh yeah, yeah, let's go and rewrite all the Spring tooling in JavaScript and use all the different specific Atom APIs for example so we don't need to do that and we can support we can implement stuff just once and support all the different different ideas and that was kind of the the groundbreaking architectural change behind the scenes that drove us and made us think about, hey, let's sort of start from scratch, pick the best ideas that we had in the past, think about even new ideas, how to support Spring developers and do something new and something radical that makes your life as a Spring app developer even easier in the future and you can choose the tools you want, the tools that you love and you can still work on Spring apps and Java apps and get an awesome experience out of that. So it seems like there's sort of a shift of like we'll bring Spring tools to you in whatever environment you're in and you know, as y'all joked about, I don't think y'all are shipping with Emacs and VI support, but in theory, such things could be easily added for, I guess, people who don't have better things to do with their life. There are actually people

working on these integrations for the language service stuff for those editors. I think it's a long list of maybe 20 or 30 different what they call clients like the editors or the IDEs that are going to support that and I think I saw even Emacs and Vim on that list. We'll have to get James Weaver on my team. He likes adding things to the Google Home thing, asking it to tell music. We'll see if he can work on getting Spring tools on there. He can do some voice programming. What did you call them? Not the language server, but the servers behind it. It is the language server. See, I was paying attention, but I just have a lot of self doubt. What is this language server concept without reverse engineering it so much? What does it do and where does it run and how does it fit into things? What is that? Even though it's called language server, it hasn't really anything to do with a big server machine or with an application server running in the cloud somewhere. Nothing to do with that. Don't get confused with the term server thing in here. The main idea behind this language server architecture is that you make a split between the client, which is the IDE or the editor, the lightweight editor, and the client doesn't know anything about the language you're working on. It only knows about, let's say, syntax highlighting using a text-made grammar file or something like that, but it has no idea about the real language understanding or building abstract syntax trees or doing compiling or doing content assist things. All these smarts are not done by the client anymore. The client is really kind of a dumb, lightweight, fast editor that does syntax highlighting and nothing else,

more or less. And to get these nice and smart and language-specific features into this editor, the editor talks to a separate process that's running on your machine, side by side with the editor, but it's a separate process and it talks to that process and tells the process, hey, I have a specific process, for example, for Java, which is the Java language server that's running on your machine as a sub-process of the editor and it talks to that and tells the process, hey, look, I work on this project, on this file, can you give me content assist? My cursor is sitting at line 20 at character 4. Can you give me, please, content assist? And then the language server does the real work. The language server knows how to analyze a specific language, knows how to do content assist, to do validations and errors and highlighting things and all these nice little smarts that make your life so nice and so easy when you use these language aware tools, but they're not really baked into the editor, right? They're running in separate processes. And that's a really smart idea because they put a protocol and then you find the protocol between these two processes, which is the language server protocol. That's kind of sending JSON messages forth and back between these two sides. And that makes it so nice because now you can start thinking about, hey, I can hack my language server in the language of my choice so I don't have to take care to implement my Java language server in TypeScript, which would be kind of crazy, right? It would be strange. I can implement that in Java. And, oh, I want to implement my C-sharp language server. Oh, I can just reuse what's there and it's written in C-sharp and run that and it talks the protocol and sends the JSON messages forth and back and does

all these heavy language analysis in a language of its choice and reusing the libraries that are already there because many languages already come with sort of parsers and ASTs and things like that. And you can just do that in separate processes and separate projects and that's really, really, really nice. It makes your life as someone who is focusing on a language, for example, or in our case, on a framework makes it life really easy. You can just pick a language, you can implement your language server, you need to talk the protocol, but that's all, and then you don't have to take care about the client at all, about the editor experience, about the IDE around that. You can really focus on that and that's really a great, great step forward. The main question I had when I was looking at this is it seems like you're going to have to re-implement a bunch of stuff across all these various editors, but like you're saying, I guess, I don't know, to summarize in my own weird way, nowadays, if you want to actually have the services that you would need for doing an IDE, you don't have to rely on all single process in memory stuff and therefore it basically being all in the same programming language unless you like to challenge yourself. But instead, you can just run, get a little, your SDK of Languagocity, your language server, can actually be just like its own little independent process that gets run and it's cool. It's not like having to make orbs and JNDI things and stuff like that. You sort of finally cracked the old object oriented thing of we're going to have these objects that send messages to each other and then we can win lots of points by allowing them to be ignorant of each other and reuse them and we can go home early or something because we got lots of reuse. But I think another

effect of it as you're saying is you can go into all these other different editors whether it's Visual Studio or Eclipse or Vim even or all these things and you don't have to have someone in E-List go implement all this stuff or C or whatever it is they do over there for the Emacs land and you can help out more people I guess which that seems nice. So yeah yeah. Absolutely. I remember the I know a lot of folks in the Eclipse community especially also the guys hacking the C development tooling for Eclipse right and they really went down and implementing parsers and building ASTs implementing everything in Java for C and C++ which was really really really crazy at that time because nowadays it's all there right you use Clang or whatever and you get everything out of that but there was no way to reuse that in an IDE like Eclipse because you had to implement everything in Java and everything had to run in the same process and things like that and that's really a dramatic step forward I think from my point of view it's really cool yeah when you look at that tools landscape Martin do you see people using some of these IDEs differently now I mean I've used the plugin for spring tool suite I've used the one for code and I guess there's different reasons I use each one of those but do you see the difference between how devs everyday devs approach IDEs are they using more lightweight editors and that's why they like things like Adam is that just for quick scratch projects versus their real enterprise stuff and then hey some people are even using browser IDE sort of stuff so what do you think of the landscape is it one reason we're trying to support kind of wherever you are is because wherever you are is changing or how do you see that that shaken out I think what I've seen is that people really they choose the tools that they love that make

sense to them to do their daily development and I think in the old days the big let's say the enterprise java developers I'm pretty sure they all use big heavyweight integrated IDEs and if you take a look at the javascript folks out there they really try to stay away from all these big heavyweight IDEs and they use lightweight editors they use atom and VS code and even sublime text and things like that and some people for some people it even makes sense to use a cloud IDE because they don't want to set stuff up and they just want to open the browser and get everything integrated it so I see that people really use different tools for different purposes and they even switch forth and back between the tools some people use an Eclipse IDE for doing Java development and at the moment I see a shift towards more lightweight editors more lightweight environments because people are sick of the IDE consuming 100% of your 8 core CPU all the time situations and eating up all your memory things they tend to like more lightweight tools but would also like to do Java tooling so they prefer to do something like VS code with a Java editing experience which is pretty nice these days you can do real stuff in there and then other folks also they go back to the IDE experience and say no we want to get these kind of these all tightly integrated environment with these heavyweight refactorings and a huge feature set that you really benefit from so I think it really depends on the project on the team that you're working on on the environment you're sitting in which tool which IDE which cloud IDE which lightweight editor really makes sense to you and I see

people use they use all of that right with the cloud IDE I think it's a little bit different I think it's interesting because there are certain situations where cloud IDE really makes a lot of sense right because you don't have to set every developer machine up and configure everything and run everything locally and things like that you can just press a button or open a browser and you get everything in there but I haven't really seen the big enterprise Java developers the real developers hacking on the code on the day-to-day base I haven't really seen people really loving these cloud IDEs to work on the code on the day-to-day base that's an interesting case and I think there are various reasons for that but that's I think one of the reasons why cloud IDEs are not really from my point of view not really replacing desktop IDEs for example or replacing lightweight editors but they are kind of an additional part of the game that makes sense for certain situations and not for others so I'm interested in so when I used the new spring tools and you know given I don't get paid to code anymore thank goodness is you know yes sure things like type ahead are helpful and even manifest editing for a Java app or pulling in dependencies whatever do we have any telemetry in spring tools that tells us hopefully anonymously what people what people are using or what capabilities in spring tools are they taking advantage of or are we just kind of doing it anecdotally based on what devs tell us yeah we basically do that anecdotally what devs tell us we had telemetry built into the spring tool suite several years ago and we used that to a certain degree but it's really it's really hard to get that right and to make that anonymous and sometimes people don't really like these tools calling home and sending

data across the network to some random location so we don't really do that anymore so we rip that out of the tools we do that anecdotally what people tell us and what feedback do we get when we go to conferences and talk to the community so I think that's the main data point for us and what we think makes sense because the good thing is that we have all the spring experts on board so they can also give us feedback and tell us what's great and what's maybe not well so you know for those people who haven't actually programmed or used an IDE in a while that may or may not be someone like me but what are the crazy fun things that IDEs do for you nowadays and to tell you contextualize like back when this theoretic person a friend of mine used to actually program you know like being I think the two most amazing things were like you could refactor things easily like do huge refactorings and of course code completion was cool but then there was also like the ability to actually like run your applications to debug them all on your desktop and like you know basically tracing through them was always an evolving exciting thing but like are there other exciting what's been going on innovation wise in IDE land that's relatively bonkers I think one of the I think the refactoring landscape is still highly interesting and highly usable for developers so there are even more refactorings out there where you can extract methods and refactor across projects and even record refactorings to apply them later to clients of you for example so which is interesting if you don't have all the projects in your workspace or on your machine right

so you can record your refactorings and if someone else use your project they can apply them that's kind of an interesting case for these refactorings and the debugging support I think is getting better and better over time I think it's one of the challenges that are ahead of us at the moment and I haven't seen an IDE that really solves that is if you take a look at the new Spring 5 reactive story and all these reactive ways of doing things with these lambda styles things going to be interesting to see what IDEs are going to do to support you debugging that for example and going into these nested structures and these lambda expressions and things like that I think that's the area where I see most of the innovation going on in the next wave of versions in the IDEs I code run better in production like in production this method you're in right now there's a lot of time spent in it and maybe too much time so just if only there were to use some pop economics term there's like nudge that you get in your code that like this is a very important part of the code based on how often it executes in production and it also takes a long time to execute would be an interesting way of focusing your attention on something and then of course running actual real world data through a system and processes to see what it looks like but I don't know I don't

yeah but I think one of the pieces in that story is to take a look at a running app and integrating that with the IDE story and I think that's very interesting that's what IDE typically don't do they analyze code and they do these code analysis and trying to find references in the code and things like that but usually they don't have an idea what's going on if you run the app and there are being injected and things like that that's going on at runtime there's a lot of stuff going on at runtime that the IDE has no idea about and it can try to imagine what might happen at runtime by looking at the code but it's in the end it's not the same right it's definitely not the same as if you would run run your spring ever for example one of the things that we tried to do in the spring tools for initiative with the new tools is to integrate that right to say hey we have these spring boot actuators that give us data from live running spring boot applications so and if you have the same project in the workspace why not merge that and visualize the information that's coming from the real running spring app on your machine for example when you debug that when you just run it and integrate that into your source code so yeah that's what we have already that's what we have kind of the first step for that at least right I think there are maybe 50 more features we can implement for that but the basic steps already working you can see your code and you can hover you can see hover is appearing in your code like an overlay and these hovers show you oh this bean is active at runtime this class being injected into these five other classes in your running spring boot application and these five other classes are defined

over here and you can just navigate and jump to those definitions and see really what's going on at runtime and I think that that's really interesting and going beyond what's what's in the what's in the source code analysis landscape that you usually do to get these continences and validations scenarios and warnings and parsing to work and I think that's really interesting it's one of the cool features that I really like in the spring tools for and we're just at the beginning it's really just the beginning but it's really interesting you can see stuff like you have conditionals for example you have conditional annotations that you say oh this bean should only be active if and then you have some random expression or if a class is on the class path or if a property is set or whatever and of course by looking at the code you don't really have an idea about is it really going to be active at runtime or maybe not and if you run the app and there's a magic hover appearing in your code and exactly that annotation tells you this conditional annotation succeeded at runtime because it found the expression or it found the class or the property was set or hey this condition didn't succeed it failed because of and then you get a reason why this condition failed at one time directly in your source code and I really love that I guess the point of all these tools of course besides making you rich and famous which is not trivial is helping our devs actually build software better faster any dev we're just trying to get you apps in production faster so you're learning faster adding value all that stuff so how do you feel that life cycle is at this point dev can go to for example start.spring.io build a project pull it into their IDE iterate on it add some unique functionality hopefully CF push it but honestly push it anywhere push

it to Azure push it to Kubernetes whatever and then hopefully debug in production if they need to with whatever tooling the platform provides where do you feel like there's any gaps in that process where we'd like to continue to see that get better or do you feel like the dev lifecycle experience in Spring is getting to be in a good place I think the dev lifecycle in Spring is going to be in a good place I thing at the moment what you can already do if you download for example the Spring Tool Suite 4 or IntelliJ or similar tools is you can really do something like you don't even need to open up a browser for start at spring.io you can just click a button and you get all these options so you can get from zero from downloading the tool to running boot on your machine that does the request mapping or something like that you can go there in under a minute maybe and if you want to push that to CF for example you can also do that from directly within your IDE in another minute right you just click and select new CF target there's direct Cloud Founder integration for example you're there and if something goes wrong you can even directly debug that app running on Cloud Foundry for example from your IDE's debugger having all these kind of step into and step over and take a look at all the variables and expressions and whatever you you can get that experience by pressing another button and start that in debug mode and then maybe it takes a little bit longer because repushing the app takes a bit longer depending on where your PCF or CF instance is running but you really you get this overall experience in really fast and nice way I think one of the

interesting challenges that are ahead of us is if you think about these microservice world and doing cloud native applications on cloud environments one of the interesting questions is hey if you you're working on that with a team right and you have I don't know five people on a team working on maybe 20 30 maybe 100 microservices on the whole system and of course I don't want to install everything locally on my machine right to test everything and every developer is everything on his local machine and then I push everything to my local instance or not local but to my personal space on Cloud Foundry to test everything in my space and my colleagues have the same so it's all duplicated and then there's another duplicated integration thing for everybody in the team I think it's going to be an interesting question how you can mix these environments a little bit for example that I can say hey I have these integration setting on my CF on my cloud runtime where I have my 100 microservices running and I want to hack on these two services for example just on these two not on the other ones just on these two so I put these two into my workspace into my machine and I hack on them and then they use everything else running on the cloud like all the data services all the databases all the messaging services all the other services that the colleagues build and things like that and I can use all of that and still just have these two microservices that I really care about running on my machine I think that could be really cool and we have prototypes already running that's what's really interesting it's not really kind of production ready that you can ship and use but I think it's going to be really interesting especially

if you think about the other way around if you think about I'm hacking on this on this service that's running on my local laptop right so I can debug in real time and do all these hacky things without re-pushing or debugging on the cloud I can really do the stuff on my machine but my service is being used by another service that's running on the cloud so there's other service on the cloud should call my service that's running on my machine through maybe through some kind of tunneling mechanism or whatever however that works under the hood and I get the full microservice combinations and they call each other experience but a certain set of these services are running on my local machine because they are in development on my machine and I think that's going to be an interesting case because at the moment you don't really have a good solution for that and I think it's going to be a challenge for developers when they work in teams and work on many microservices and these big cloud native applications and there are good ideas out there how to solve that but that's going to be an interesting challenge this has been a very in depth overview it's good stuff before we wrap up if people want to check into more of this or figure out what you're up to follow you around the internet obviously in a non-creepy way but where would you point them to the twitter handle I think you I think you will put them on the show notes somewhere and there is there's a twitter handle for the spring tools called at spring tools for I think we'll put that in the show notes too there's of course the spring blog where we usually announce new releases and things like that and all the stuff that we work on all the tools are

open source on github so if you use them if you have feedback for us and we would really love to hear from you if you have feedback and user tools and ideas for additional things that we can do or stuff that doesn't work or things like that file issues on github it's all open source right it's all there so that would be really cool and also as you mentioned will that will probably be around much more and has evolved a lot it's you know because you don't want to learn an IDE and then have it go away so look at all those wacky key combinations and stuff so it's nice that it's had that stability for so long yeah absolutely all right well great well thanks for being on that was good stuff and as always this has been pivotal conversations there's a link to the rss feed but you can add it wherever you want and various other things and you know you should check out our other podcast pivotal insights that's also in soundcloud very good podcast it's fun they got the same sort of thing going on there where they have a wacky person and a you know a Richard I'll leave it as an exercise for the reader to figure out who the mature professional smart person is and who the wacky person is you know it's a good duo to have and usually every Thursday except for today because that was late well for the previous episode if you're calling about pets for seniors usually every Thursday we post the show notes over on pivotal.io slash podcast and with that we'll see everyone next time bye bye

Tanzu Talk · 🍕 Get more pizza.