PurePerformance - Spring: The successful path to an open source project with creator Juergen Hoeller

Episode Date: October 14, 2019

16 years and still growing! Not every open source project has the track history of Spring (www.spring.io), a framework for building modern applications for the java runtime.Juergen Hoeller (@springjuergen), creator of the Spring framework, gives us insights into how he and his team have grown Spring to where it is now. We learn how they have built a developer community, how they deal with feedback, why its important to interact with your users on a regular basis and where the road is heading. Juergen also shares insights on topics such as scalability, performance, concurrency of the framework as well as how the rise of new java runtimes and distributions still keeps him excited about the future of Spring.If you want to learn more visit the Spring Framework’s GitHub project and make sure to read up on the latest blogs on https://spring.io/blog/https://spring.io/https://twitter.com/springjuergenhttps://github.com/spring-projects/spring-framework/

It's time for Pure Performance! Get your stopwatches ready, it's time for Pure Performance with Andy Grabner and Brian Wilson. Hello everybody and welcome to another episode of Pure Performance. My name is Brian Wilson, and as always, is my co-host, the one and only live from... Are you in Austria today? Or I heard you say something about Germany and Frankfurt. So where are you live from today, Andy? Andy Grabner.

Hey, now I'm actually live from Linz, Austria, but I'm actually, you know, what's interesting. I might, I might not be the only one because I know there's another Andreas Grabner who actually is also in IT. He went to school close by and I think we only have like two or three years of difference in age. Wow. So there's another Andreas Grabner out there in the same industry, believe it or not. So, but I am the one that is doing typically the podcast with you. I will never call you the one and only, like I not the one and only brian wilson i'm not the although i would call myself if i had to give myself a title i would call myself the brian wilson because the beach boy is just brian wilson so i'd be like no i'm the brian wilson that's true but anyway i

digress um we've got a we've got a pretty cool guest today don don't we? Yeah, I think it's a man that should not need any introduction, especially for people that are active in the open source community around Java about a certain project that doesn't have to do with winter, neither with fall or summer, but with spring. Oh, that was it. I'm sure it's the first time you heard about that. I don't hear that often. But yeah, I love the connotation with the spring, the season.

And the greenish coloring that we do around it. We really mean it, right? So Jürgen, so we just revealed the secret. It has to do with spring, the spring framework. You are, I mean, just introduce yourself to the world in case people haven't heard about you. Yeah, just in a nutshell, I've been doing what I'm doing for quite a long time.

I've co-founded what became the Spring Framework project back in early 2003. And I've been serving as the core project lead doing the release management, everything around it, and quite a bit of the core development ever since. So I have had my responsibilities, my core responsibilities, for 16 years and counting. And I've been doing lots of things on the side. So I go out there to conferences talking about Spring

and what we're doing at the core Spring framework level. And, of course, there have been a few companies around it. We've had Interface 21 Spring source. We were part of VMware. We are now at Pivotal. So at Pivotal, we have, of course, an entire team working on the Spring open source portfolio. And I've got a team of roughly six people working on the core framework with me.

And plenty of other engineers working on other Spring projects like Spring Data, Spring Boot and Spring Integration. All of those projects have their own dedicated teams. So I'm literally working on the core framework of it all, right? On the core of the stack. And we actually met earlier this year in Krakow in Poland at a conference. At one of those conferences. We said, hey, you know, we live so close to each other

because we both live in the Linz area. And it's just interesting that we typically bump into each other at those conferences. Yeah, that's how it works in this industry. But talking about things and presenting at conferences is a key part of what we're doing. Like any open source project basically is only there to be used out there in the real world by people.

And in order to just keep it going and to motivate people to kind of keep up an interest, to keep upgrading to the latest, talking about it is just a key part of it, right? Development is like actual engineering is only a part of the story, of course. So 16 years and counting. I know it's obviously a success story. I believe, as I said earlier, I believe most of our listeners

that have anything to do with the performance engineering space and are dealing with Java-based applications, they most likely run and are aware of Spring. So let me ask you a question now. I know you're not in marketing, because you clarified this earlier when we did that little check in the beginning.

But what's your elevator pitch? What's your elevator pitch for Spring? What is Spring? What does it do for me in case I'm not using it yet? And I know I kind of throw it into the cold water now. Yeah. But it will be interesting to hear. Oh, I'm totally using it yet? And I know I kind of throw it into the cold water now. Yeah. But it will be interesting to hear. Oh, I'm totally unprepared.

No, I actually am unprepared. I don't usually do elevator pitches, but more like 60-minute pitches. Okay. Engineering pitches. But it is a very sophisticated portfolio of application frameworks. I mean, it is kind of an application development stack for Java, for the JVM, the Java Virtual Machine, with both Java and Kotlin as first class languages these days

and Groovy as well, more on a historic note. But there's still quite a Groovy-minded audience out there. So we basically provide a toolbox of components and the framework arrangements for all the sophistication that is needed out there for modern day application development purposes. And this is a wide range, right? From the good old monoliths of, well, the mid 2000s to modern microservice architectures and even function as a service models, we have quite a range to cover. But of course, we have our traditions.

We have an audience that is kind of evolves with us. And at the same time, we are also very much on the forefront of providing a modern day entry point into the Java ecosystem for an audience that might not have used Java, the JVM or in particular Spring on the JVM before. So it's kind of quite a few challenges,

and I'm right in the middle of it, I suppose. That's pretty cool. What's the, I mean, 16 years, it's amazing, right? Many projects have started and probably never made it to the public light, or let's say critical mass. What's the secret of success then to actually run a project like this? And it's also a little selfish question now because you know that we just launched our own

open source project called Captain. So we are still in year number one, so we'll see where we are in 16 years from now. But what can we learn from somebody like you? Well, man, all the power to you and Daniel Trace for actually being motivated to start a new open source effort.

The open source ecosystem is very diverse. But as you were hinting at, there's so much code written out there, in particular also as open source, that never really goes anywhere. The best code out there not getting picked up and used by anybody is basically in Maine, in Maine, right? Yeah. And I've seen quite a few things come and go, like actually reach mainstream potential at least, and then fade out again, right? I've seen Apache Struts, which was kind of the reference web

framework of the early 2000s. I've seen it rise to enormous popularity and then kind of fade out from there just in the course of a few years. And of course, struts on Spring was a thing for a while, right? We had all those integrations. I was literally there in the buff session at Java 1 2001 where the first proper struts release was announced, right? Where struts went generated available. So I've seen Hibernate, of course,

which is still very popular, grow along the same lines as we have. But it is certainly unusual for an open source project to stay relevant, remain relevant for such a long period. I mean, Java itself dates back to like 95. So that's quite a while. such a long period. I mean, Java itself dates back to like 95, right? So that's quite a while. But we've been a part of Java and the JVM ecosystem and of that story for such a long while ourselves, right?

We started in 2003, and that is basically like roughly just two-thirds of Java's lifetime overall that we've been a part of it, right? Like in the ballpark. I'm always quite amazed myself that it's already been so long. And in order to kind of foresee that such a lifetime, well, it's basically just hoping for the best and doing the best you can, right? But you never know, right? We, I have had those questions in the 2000s,

even by some people around me, like when spring reaches kind of the struts level of popularity, what are you going to do with it then, right? Well, I guess my personal philosophy, the philosophy we have in our team is a bit different there. We see an open source project as kind of an ongoing effort, right? An effort that you're never really done. You need to keep up with the time,

evolve with Java, the language, the JVM infrastructure underneath it, the open source ecosystem around it. You shouldn't get stuck in kind of an architectural vision that you initiated the project with. You really need to kind of reinvent yourself to a degree every couple of years. The part that is probably sort of, if not unique, then at least special around Spring, is that we never really threw everything away and started from scratch.

There are so many projects that kind of keep using the same name, but essentially reinventing to them means rewriting it from scratch. Struts 2, which really was a totally different code base, totally different project arrangement. We've never really done that. So we kind of try to keep the balance between a careful evolution and a mild degree of revolution at the usage model, at the development experience level. This is a fine line to walk without breaking all the integrations that we have, because Spring is a very integrative affair. We have so many integrations with other open source projects,

with commercial infrastructure, with all the application servers of the day out there. Some of them we maintain. Some of them, and actually a lot of them, are maintained by third parties, by the corresponding vendors, by open source volunteers. Anything we do that breaks a wide range of those people out there would backfire quickly.

So that's the fine line, right? So keeping up not only the APIs, but also the SPIs within the framework while you evolve towards a direction that you want to go is the challenge that I'm personally also very up to. Of course, there's always a little bit of an itch, right? What if I was starting this from scratch? Would I do this differently?

Of course, you would always do it differently to some degree. But personally, I really appreciate the challenge of um of evolving and existing arrangements a very sophisticated complex arrangement uh it's a different challenge uh but something i'm personally very up to um it's i i find it exciting to kind of move it forward uh from where it is to where we want to have it, and to take our community with us. If we go in a direction and the community is stuck on some old version of Spring and basically doesn't follow, then we've also failed, right? We've done something wrong.

And we've seen that in the Java space just recently. There's this quite radical change around the OpenJDK release cadence with Java 8 as the last traditional major release, very established out there in the industry. And then there cadence with Java 8 as the last traditional major release, very established out there in the industry. And then there's basically Java 9 and higher. And there's really a bit of a gap, right, in the community there between all the people on Java 8 in production and the more ambitious,

or, well, I don't know how to classify them really, but a different part of the community that has made the jump to Java 9 Tire and follows along and is now on Java 13, recently released and knocks on our door and saying, what about Java 13 compatibility, right? There's really quite a diverse audience out there. And our challenge is to keep all of them happy, right?

Brian, did you want to say something? I'm sorry. Oh, no, I didn't interrupt. But yeah, I did actually have a question. So you mentioned it started in 2003. So I'm going to make a music analogy here because that's more my background. So typically, if you think about like a band, right?

Something that's not a corporate songwriting team, a standard band goes through some growth. They have their early fans. People are keeping them afloat. Then they get more popular. But a lot of people don't hear about them until suddenly they have a breakthrough and they get on the radio or maybe they're on top 40 or something. With Spring, you've been around since 2003. I'm kind of like the grandfather who only hears the hits on the radio, right? So in my position,

we're dealing with monitoring software. So I see what know, in my position, you know, so I'm, you know, we're, we're dealing with, you know, monitoring software. So I see what our customers are using when we go in there. And I'd say, you know, spring really started becoming noticed, at least from my side, from, from the commoner side in the last three or four years, which is a far, that's an interesting observation, far, far, far push out from 2003. You know, this is like an enterprise and all that. But thinking back from 2003 till now, was there a time when sudden,

like was there a performance knee where you kind of hit critical mass and it just started taking off? Or has it just been a really slow, steady, you know, stream of increase? Yeah. What was that compelling moment, that compelling event, something like that?

That's an interesting question to reason about because there have been several points where we had a bit of a jumpstart into the enterprise in particular, but there's also a strong, steady growth. I mean, if we just take the download numbers, basically, they just kept going up. And in the original days, we've always been monitoring them like every morning.

But there have been a few key events. Back like, was that in 2007, when IBM made Spring a first class citizen on the WebSphere stack and kind of had official guidance, like even community pages with how to use Spring and Hibernate on WebSphere application server, that we saw a significant boost of interest from a certain part of the community out there, of course. At that point, when we started really getting into specific fields of enterprise integrations, launching the Spring Integration Project, launching Spring Batch, almost a bit of a unique kind of affair in the open source ecosystem. You only had commercial choices before, commercial development models,

and now you had an open source project for these really enterprise-y areas. That was quite a boost. And of course, and that might explain your observation, Brian, the launch of Spring Boot in like 2013, well, early 2014, when it went GA, Spring Boot, of course, just re-energized the entire community that we already had and also attracted a lot of new people and kind of enabled a lot of different architectural models. So even if we don't call it, we never called it a microservice framework. We don't actually use the term microservice much at all ourselves.

But it turned out to be a really good fit for microservice-oriented architectures. Then, of course, the Spring Cloud project, which we actually mean is a very specific toolbox arrangement for integration with specific cloud providers, also evolved around Spring Boot. So this really brought us to the level that we're in now. And this is, of course, you can't plan for the CEDAW. We had a Spring Boot-like vision even in 2007, 2008, but we couldn't realize it. We couldn't turn it into a product that we really felt comfortable with at the time. We had a few attempts. But it turned out that by 2013, 2014, several kind of ideas and streams of development kind of merged into a foundation for what became Spring Boot.

So yeah, in retrospect, that's probably the key event in recent years that really changed everything. In the meantime, we have just rough indications that we use here, but at least half of the Spring user base out there is using Spring Boot. With newly started projects, it's probably more than half. In the meantime, we have the start.spring.io project generator, which kind of followed right after Boot or along with the launch of Spring Boot.

That turned out to be very popular. Just because you could- It's a great developer experience. I mean, that's what it's in the end comes for me, right? As a framework that allows developers to build better apps faster, new apps faster. Manage the dependencies for them. Yeah, but it's-

Dependency hell. Yeah, it's a great developer experience. And I think that's also, at least that's what I would contribute to one of the success factors. And if you're building a framework for developers how can differentiate to others by giving a first-class developer experience if you can improve productivity and if you if you provide something that actually solves the problem in a very convenient way and if you have a large community obviously that supports it and the tool integrations

i mean that's yeah a lot of ingredients for success it is in uh also an interesting balance there that we are not entirely focused on spring boot but we of course really we recognize it as what it is right the primary entry point the very popular entry point and the very popular kind of stack enabler out there but at the same, we know that we have a quite large audience, both historically and to the day, that builds kind of their own in-house framework variants, distributions that are Spring framework-based, use Spring Security,

maybe Spring Webflow back in the time, and combine it into a sort of in-house framework distribution. They try to use as many open source components as possible, of course, but that was part of what we originally did. Our competition in the mid-2000s, basically, were in-house frameworks most of the time. So we saw a lot of migrations from custom in-house frameworks to spring-based open source stacks that replaced those in-house frameworks,

but they are still oftentimes managed by architectural groups within larger corporations that do their own thing, have their own guidance, their own project templates, their own whatever it is, right? So with everything we're doing in the individual open source projects, both at the spring framework level and others in our portfolio, we know that we also need to keep those arrangements happy. They sometimes make different choices, go different ways from where Spring Boot is or where Spring Boot wants to go.

So that's also kind of interesting for me that at the core framework level, a key part of what we're doing is enabling Spring Boot to do what it so successfully does. But we also need to keep empowering all those other groups out there in all those geographies. We, of course, we know a lot of them. Not everybody tells us that they're doing this, but over those 15 years, a lot of those people got in touch with us in one form or the other, like at our conferences, Spring

One, Spring IO, we often get in touch with them. So it's always interesting to see what people do with a framework if the framework is not all that opinionated. This toolbox philosophy at the core framework level, at the core project level, really is meant to empower such custom arrangements, whereas Spring Boot is a bit more of an opinionated framework with a predefined dependency arrangement with a strong guidance towards certain kinds of architectures. It's a perfect combination for us.

There's a strong, large audience for both of those philosophies. It sounds like, I just wanted to round out on that. You know, when Andy asked about what we can learn about success and all, it sounds like basically what you had said earlier too, about you're not just, you don't just create a project

and then run it in, keep it in maintenance mode, right? It's all about continuing to find new ways to leverage it, new layers to add on top of it, like say Spring Boot or something. And not only that, and I don't remember if you said this during the recording or before the recording, not just creating these things, but getting people out there and talking about

them, getting them to the conferences, getting someone like Josh Long with his crazy sense of humor to go do these Spring Boot demonstrations and really invigorate the crowd and make them laugh and say, hey, that looks easy and incorporate it. So it's a combination of not resting on your laurels, not falling into the temptation of going into maintenance mode, but really just pushing for new things that you can do, new ways you can fit it in, even if it's not the core. Like as you said, microservices were not the core of what you're looking to do,

but it just happened to fit it well. So hey, let's introduce it to microservices concepts and push it out there. And then people say, hey, I can use this for microservices. Great. And I think that's really part of the success. Things turn out to be a good fit, even if you haven't specifically planned for it.

So there's always a degree of luck. We've made a lot of design decisions in the early days that turned out to really match what modern day Java does. Like back in 2004, that timeframe, the template classes that we have, JDBC template, transaction template, those callback models where you pass a callback in and it would execute it under a specific context. With anonymous inner classes in Java, that was always a little bit unpleasant to code, right? But we believed in the model behind it, like this inversion of control arrangement, passing off

callbacks to framework code. And of course, then fast forward to 2014 Java 8 with its functional kind of design that it brought into the Java language, and in particular, into the core Java APIs, it turns out that the exact convention that we've been using for our callback interfaces in 2004 are naturally compatible with the functional interface

conventions that they introduced in Java 8. So you could immediately, without any change to our existing interfaces, you could use them with Lambda expressions and method references if you chose to use Java 8. So sometimes things just fall into place and kind of naturally match because there's a bit of a shared design philosophy that kind of goes together. But it took almost 10 years for that to happen. So that's the part that you certainly can't plan for.

But there's quite a few things you can do, right, that you can actively aim for. And empowering a community to participate in what you're doing. And community means many things. That can be open source contributors, can be students at universities. It can in particular be other companies, right? Partners, small companies, or the largest corporations out there, kind of embracing all the interests and the contributions that they might have and having a fair degree of involvement where basically they can be a stakeholder like everybody else, not like first class stakeholders and second class stakeholders out there, but really trying to treat everybody as kind of a natural citizen of your ecosystem.

That is something we've really been aiming for. We've never really had, fortunately, we've never really had the constraints that we need to kind of work for a particular stack as our primary target. We've always had this kind of very stakeholder level, open source philosophy that we were allowed to work with, even when we've been part of larger corporations like at VMware, or even Pivotless, a reasonably large corporation. And being allowed to wear an open source, a stakeholder-oriented open source hat, when you make decisions around the open source project, when you reach out to the stakeholders, to the community in terms of direction, or in terms of feedback, trying to understand where they are going,

being able to work with all the options that are out there that people are using and not having to prefer a certain option just because it happens to be a key product that a particular corporation is doing. That is an important part. It's a fine line, of course, because at the same time,

an open source project needs to be sponsored. It is effectively a strong form of sponsoring. Open source engineers basically work for the community, but are paid by a company out of a revenue stream that may be very immediate. Like back in the days, it was in our early days, it was trainings that we've been doing, consulting gigs that we are doing, that sort of thing. Our early attempts at subscription models.

These days, it is mostly subscription models. Pivotal with its cloud-native subscription, now the Pivotal Spring Runtime subscription. Those are really subscription models at a larger scale for larger stacks that we are a key part of. We are the entry point into the Java personality of quite a few stacks out there. And the model around it sponsors the open source development underneath. That is, of course, in the early days, in the early 2000s, it was a challenge to come up with a business model that really allows for sustainable open source development.

There were no references, really, where this worked to a particular degree. If we're looking at the modern day Java ecosystem out there, basically everybody does sponsor open source projects, professional open source, as it's sometimes called. Just look at what Red Hat is doing. Pivotless is open source in its DNA from the ground up. Everything that Pivotless is doing basically is open source based there um and even modern day microsoft right everywhere you get uh sponsoring of open source projects that are a natural part of the stacks of the stack products

that are being used out there so that's that's the way we are working today uh but personally that's the part i appreciate most is that we've always had this degree of sponsorship all the way through with different business models around us. Some of them very close to us, some of them rather indirect. But it always worked up to this day. We have a constant stream of engineering sponsorship across 16 years. And that is I'm really grateful for that to have turned out like this. And of course, there has always been a strong support from certain groups, certain companies, certain people that just helped us all the way through.

Open source business models are still not easy, but it's certainly more established now in 2019 than it was like 15 years ago. So it's also a degree of freedom on our end. We are now entirely focused on open source engineering. Occasionally we go out to conferences and talk about things. Occasionally we record podcasts. It's actually not that common, but we are very open source engineering focused. Whereas in the, in the early days, we basically at most, it would be half of your time on open

source engineering. The other half you would do a consulting or trainings or um that was very immediate right literally the very same people kind of uh did the uh did the uh um the customer services that sponsored the the other which is probably also great because you are basically using the framework with your engagements and you were refining it based on what you really saw you know on the floor with the people that you were giving the workshops for or that you helped actually implement new apps. And I think that's... I've done this for quite a few years myself. I wanted to keep it up until I've been told at the very end that we really should separate those roles now.

That was very late in the game, actually, because it's a very, very direct insight, very immediate insight into what people are doing. It's the fastest feedback loop too, right? Oh, yeah. Just sit next to somebody who tries to use your stuff and see where things break for them, right? Where it's not as intuitive as it should be to them. And that feedback loop is still important, but now it's separate roles.

Our developer relations people, like Josh DFO mentioned, Josh Long and his colleagues are, of course, very close to the engineering challenges out there so if we say developer relations it's really very close to the metal he does do more strategic kind of conversations as well of course

but he mostly spends time with people actually coding right and then there's still a very strong feedback loop from their side but i i have a certain love for the that period back then where we we've been very immediately involved with customer projects ourselves cool so i mean what i take back from this conversation and and like the the history now a couple of things uh i mean we because i want i want to learn right i guess i said i'm selfish i want to learn how can we do an open source project maybe listeners that think hey they have a project

internally does it make sense to open source it if to open source it what do we need to take care of i think what i learned is especially if you build frameworks that help you know our software industry developer experience is key uh i also from the spring boot but you said it's a it's a more opinionated approach which means it gives you less freedom, but the still thing is it pushes people into the direction that you think things have to be done. That's also what we do with Captain. It's an opinionated control plane for delivering cloud-native applications and running and doing automated operations. So we kind of went that approach.

I think we are also focusing on developer experience and then now preaching it out there, right? We also get, you know, we're working with companies to get early feedback. I think that's important. That's what I hear as well, because only if you get the feedback, you actually know if you're building the right thing

and then they can direct you. And we get the sponsorship also in our case now from Dynatrace, which is great, right? And essentially, right? Because you've been hinting at it before. It's kind of dropping it out there and turning it into maintenance mode. It's kind of, well, that's a way of getting rid of something, right? But it's not a strategy for a sustainable community.

So it's the initial launch, the initial release of a drop of open source code on GitHub or wherever is a starting point, not the end of the process, right? And I mean, of course, back in our days, that wasn't GitHub, it was SourceForge, right? We set up a SourceForge project with the code that Rod Johnson initially had coming as a download with a book. So no GitHub back then. But of course, we have been on GitHub now for many years. And we are very happy with this engaging model that those platforms have, where it's so easy for people to contribute, sending a pull request. And that's really a very straightforward way of contributing.

But yeah, it worked all the way through for us. We had so many people pointing out typos in the Java doc or wherever, right? Everything is, everything that is easy to fix, right? We just pay attention to also reacting to it. It's kind of the, that's another part that I was personally very keen on is if somebody goes to some lengths to create an issue, a report, or even pointing out a typo, right? Then the minimum we can do is to kind of get back to them, respond. And if it's trivial, straightforward to merge, whatever, then do so in a timely fashion,

right? Not just letting it pile up until you have an unmanageable amount of of thousands of issues and also people lose interest because if they see there's actually nothing happening with the comments with the feedback then you know why contribute why try to contribute if nobody's listening why would they follow up with anything um and there's a there's a degree of um there's of course a loop there as well you can educate your community in a certain direction right to kind of

so that they realize that for certain kinds of reports and issues that are very to the point we immediately merge them whereas others are put into a backlog where a totally different timeline is attached to it and kind of them learning how to present

their case or how to create a report and an issue report, in a way that allows us to immediately merge it. It really showed over the years that the community evolves with us, with our ways of doing things. And sometimes there's a very close relationship to certain contributors. We literally have people that are well-known usual suspects in the community because they've created so many reports and so many pull requests over the years. Sometimes they even come in a batch. Last year, was it last year, there was like 50 pull requests from the same contributor from Russia within like three or four months, maybe. It was even internally called a denial of service attack on me specifically, actually,

because it was very core container oriented. But I didn't see it as that at all. Of course, it is effort on our end to digest all of those. We have to go through every single product request and triage it and merge it. There's effort attached. But that is totally worth it. It helps you increase the quality. Basically, you're driving the product into the right direction to the people that can actually use it. That's what it is. What better kind of feedback can you have than, I have this this specific issue and if you fix it for me,

it's really going to help me. I mean, that's as immediate as it gets, right? So I have a lot of love for those details. Sometimes it is details and sometimes it is an overloaded method that they would really appreciate having at that point or just something minor that is easy enough to do, but really helps them and makes them basically happy, or even in some cases enables a certain integration that otherwise would be awkward to accomplish. So reacting to those and prioritizing those kinds of reports is something we've been explicitly doing almost at any point of the lifetime of the framework. We have our own ideas, our own vision, our own things we really want to get in.

But sometimes we put those on the back burner in certain periods, focusing entirely on user reports, because our strategic vision is just less attached to a particular timeline, whereas somebody creating a report would probably really benefit from getting this in a timely fashion. They might actually have that problem right now. They need a solution soon and they will really appreciate it if

it rolls into the next maintenance release. Maybe two, three, four, five weeks away, right? And not like a year later. I mean, it's interesting. So unfortunately, I'm the only one that can actually see Juergen while he's speaking because I stand half a meter away from him because we're connected with my little headset here. It was interesting because before we started, you said, well, you normally don't do podcasts. You're not really that kind of guy for marketing, right? You're a core engineer.

But it's amazing to see your passion when you move around. That's also why. Exactly. Yeah, no, definitely. That's why I don't want to stop you because you have a lot of, obviously, experience and history with this project and you can give a lot back to the community. And also, I like what you just said, but it is extremely important that people contribute to open source. And this is an encouragement

to everyone that wants to contribute. You know, make sure that you are, you know, giving your pull request, I mean, making your pull request, giving your comments, because that's the way you can actually make an impact, right? And if there are open source projects that are not that well maintained, and you don't see things appear to getting picked up, well, then maybe it was the wrong thing. And then you focus on another community that actually takes you more serious, right?

I think that's what I learned as well. Yeah. And I mean, I'd also add to that, Andy, that, you know, obviously a lot of people, like how do you, you know, myself, I'd be like, oh, well, I don't know what I'm doing. No one's going to take my, my contribution, but submit it. You know, the more you submit, the better you'll get. And maybe you'll get some feedback on them. If the project's being maintained well, they'll probably say, Hey,

we're not going to accept this because of X, Y, and Z. And you improve. And over the course of time, suddenly you start getting into the category where they are getting accepted, and you got to start somewhere. So to your point, just start doing it. And at the same time, to anyone considering such contributions, don't be afraid of submitting it. But also, if there's no immediate reaction, that might not be very telling, right?

It might just mean that there's a lot of issues created and the developers, the engineers are really busy with stuff. So a careful reminder occasionally, just a comment on an issue that might be a couple of months old even, right? A comment that says like, I have that problem. Even from somebody else, I also have that problem. I still have that problem. So all the notes in particular,

if somebody considers creating an issue, just looking through the open issues, somebody might already have reported the same issue. But don't stop at that point. Basically add your context, your perspective, or even just a, yes, I care too. It's a problem for me as well. We actually look at those comments, right?

At least recently updated. We know this if there's a comment and we take them as a form of escalation. Sort of, okay, the more people really care and the more timely this feedback comes in, the higher the chances that we'll take the time to roll it into the next maintenance release. And we really differentiate between our immediate upcoming

release as opposed to the backlog, right? So just a little hint. Any such comments, and in particular from several sites, such comments might put it back into the immediate bunch of issues that we deal with. There are no guarantees, of course. I mean, there's a strong human factor involved. We are not too many people.

We are roughly like six in the core framework group. So obviously it's sometimes like right now, basically, in this period up until our Spring 1 platform conference in early October. It's always very, very, very busy. And there's a chance that comments or issues created now are not going to see a reaction for a week or two or three until after the conference. But we'll get back to it right we're very carefully um managing our issue tracker so that we don't miss anything so if we know that there are certain periods where we can't pay immediate attention uh but then of course the modern day tools that we have for managing an open source project out there really allow us to get back to it.

And GitHub is, of course, also very enabling for others to step in. In the meantime, while we don't quite get to it yet, somebody else might come in and suggest a workaround, or even maybe diving in and suggesting a patch to initiate somebody else report it. So that's all very cool, right? It goes all those ways

immediate reaction from us is we we would like to do it every time but doesn't work out every time uh but the community and uh many common contributors stepping in is equally great so jürgen i mean there's a lot of great stuff that you just talked about we learned a lot about the spring frame with history i'm sure we could go on forever but and i know there's a lot of great stuff that you just talked about. We learned a lot about the spring frame of history. I'm sure we could go on forever. And I know there's some other topics we also want to talk about. We kind of wrote down a little list and maybe glancing over the list. And then, you know, we'll see how deep we go or maybe we'll fill another episode. But what else is going on and is important for you?

The strongest trend that we are seeing, that I'm seeing in the Java ecosystem, is this kind of totally different degree, new degree of energy of innovation that comes in at the runtime level. For the longest time, the Java virtual machine was basically, well, it was there. There were iterations every couple of years. It got a new major release but that was basically it uh innovation was mostly happening on top of the current jvm baseline within within the established baseline in the industry uh but now uh we have a uh a new release model in openjdk a release every half year um that doesn't necessarily mean that there's more happening. It just means we get things a little earlier

and in smaller slices. And this really turned into quite an interesting challenge for us, right, in kind of trying to be a natural citizen with all of those releases. Because as a framework provider, we leave it up to the user, to whoever builds the stack, to the architect, to the deployer, even to some degree, in using the runtime underneath.

So a Spring-based application, a modern-day Spring application, might run on JDK 8, right? Out of the common JDK 8 installations from Oracle and IBM. But it might, at the same time, run on the latest OpenJDK distribution, like? Out there, the common JDK 8 installations from Oracle and IBM. But it might at the same time run on the latest open JDK distribution, like open JDK 13 now. So that's quite interesting, both from a technical perspective and also from a community perspective,

because we generally recommend upgrading to the latest, right? The latest Spring framework version, the latest Spring Boot version. There's a bit of a history in the Java ecosystem that we tend to not necessarily recommend the latest JVMs. It's like, if Java 8 is good enough for you, then just hang on to it.

But there are quite a few reasons why you would want to upgrade. And we are trying to walk that line as well, that fine line between keeping a Java 8-oriented production audience happy, and at the same time, empowering everybody to use the latest Java innovation, right, out of JDK 11 or now JDK 13. And half a year durations are a challenge, right? But it is also a bit of new energy that comes into the ecosystem.

So I totally appreciate that. There's also quite a few performance improvements that came into the runtime. It's kind of, of course, a never-ending topic. You're basically never done optimizing for performance. But the part that I noticed recently, it just reappeared in my mind, it's simply not one size fits all. There are quite a few JVM distributions out there now. There's a standard OpenJDK, there's IBM's OpenJ9, basically a different JVM with the same language and class libraries on top.

There are quite a few different garbage collectors now, all of them first class, like the G1 garbage collector, the Z collector now, or Azul's efforts, and Ashin Andor from Red Hat. And the way that those are presented really indicate what I have in mind here, that they're designed for a particular target audience, a particular target scenario.

So this is not the norm. In Java, in the JVM landscape, we are used to just standard settings, drop it in and go with it. So the same applies to our framework level as well. We are really optimizing for certain target scenarios, even in some cases providing distinct products, projects, initiatives for certain target scenarios, understanding

that everything is a trade-off, right? The configurability that we have at the core framework level or even at the Spring Boot level is a necessity. There are choices made that we need to enable people to make the choices that they need to make. So this opinionated perspective that we've been talking about earlier is kind of a little bit challenged by the need to really specifically adapt to certain scenarios. And the combination of our efforts

is really all strongly going into that direction because in modern day cloud deployment arrangements, it's just a little bit different from the long running monolith. That's why it makes a lot of sense that you're building purposeful, like focused implementations for different runtime scenarios when you just mentioned about the settings and you know what

you can tweak and everything brian this reminded me of an episode we did a couple of weeks ago with the guys from akamas i'm not sure if you heard about them no it doesn't bring about so so what they basically do they have an ai machine learning um like system that is that optimized java applications while they're on the load either either in load testing or in production. They're basically tweaking the different parameters of either the JVM or the different frameworks until they reach a certain performance goal. So basically what they're doing, they're optimizing it for a particular load on a particular application, all these settings. And I think that's an Italian-based company. I call it Akamas, really cool stuff.

Yeah, like besides, besides like your, besides your heaps and all that, he was saying there's like, I think 700 configurations that are available in a JVM. Oh yeah.

So it's like, you know, I only knew about the small handful that you normally see. So the idea is like, yeah, let's let the machines figure it out and tweak all these things

until you find the optimal setting sort of really cool idea. It sounds totally cool. I mean, it is non-trivial to make those choices and to tune for those scenarios. And it doesn't get easier with the different distributions that we have now, right? In Java land, we are now basically going into a linux sort of world where

there are different jvm distributions from different uh different entities out there that can be a very cool thing because it's specifically optimized for certain scenarios but it can also be a bit daunting right when you to a newcomer to a new entrant it's like all those options yeah um and we're right in the middle of it also trying to provide some guidance well it's also not only that for even you coming up to pick but also for a vendor like a framework vendor or like a tool vendor so how do i optimize for all the different platforms do you even test against all of those exactly yeah which ones have support right which ones are going to be popular which ones are not going to be i mean that yeah and the the uh

the most radical one that we're currently dealing with is GraalVM from Oracle itself. Since Oracle, of course, runs OpenJDK, the traditional hotspot arrangement, but GraalVM comes from a different group. Some of them actually based in the very city we're in, in Austria. And for the longest time has been a research project in Oracle Labs and turned into an official Oracle product earlier this year. Mangral VM is many things. It is a replacement for the C1C2 compiler in Hotspot in a regular JVM, but it has some more radical options as well. internally, under certain conditions, a Java application into a native executable, which is, of course, a totally different mode of deploying, of executing.

It's not a regular JVM. It doesn't have regular garbage collection. But it comes with strong benefits, like totally different memory consumption profile, almost immediate startup, because the JVM warm-up phase is basically totally skipped. But there's many things you cannot do. You can't do dynamic class loading. You can't do JVM warm-up phase is basically totally skipped. But there's many things you cannot do. You can't do dynamic class loading. You can't do JVM agents. Dynamic random optimization. Yeah, it cannot dynamically optimize for peak performance.

So there's a bit of a trade-off even in startup performance versus peak performance at this point. Although they are working towards making sure that peak performance is kind of in the same ballpark as on hotspot. But this form of innovation, personally, I find it really inspiring. It is, of course, also a challenge because how would you go about it as a framework provider? Do you pay immediate attention to any such efforts, to any such reports of, hey, this doesn't quite work on OpenG9 or on GraalVM with native images here.

How do I work around this? How do I specifically configure my setup here? We can't take everything into immediate account. But from a technical perspective and from a product management perspective, I find this totally exciting. In trying to adhere to those conventions and allowing people, empowering people to build Spring-based applications under

certain conditions with certain trade-offs and certain limitations for a native image model is as exciting as it was a couple of years ago to make Kotlin a first-class language. I find this exciting from a technical perspective

because it really challenges the framework and the core facilities that we have in interesting ways, but also from a community perspective and kind of not forcing people to use Kotlin or forcing people to do native images or forcing people to be totally cloud-native oriented, but kind of empowering to make those choices and to combine those stack options if it makes sense for them,

if it fits for their purposes, for the architectures that they're aiming for. And it's an exciting time to be in the Java industry, in the JVM ecosystem, because of all of those things happening basically right now and having a mainstream appeal by 2020. Kotlin still has a strong upwards trend. Kotlin now has coroutines as a first-class language feature, something we find really exciting for our reactive stack options. GraalVM is really still a bit of an early adopter product at this point,

but by next year, by this time next year, we might already have seen certain niches, at least in the industry, being very, very focused on what GraalVM can provide to them. So this is just exciting. There's these spikes of innovation from different sides, also from the foundation upwards, are really important for a sustainable community overall, like a Java community as in all the options that the JVM is providing. I think we actually, because you mentioned GraalVM, earlier this year at Dev1 here in Linz,

we had Chris Thalinger from Twitter giving a talk about GraalVM and performance optimization and uh it kind of brings me to another topic that I remember you were mentioning in the beginning before we started our talk performance and scalability you know you are an engineer by heart right you are and and and again this is something that you do just maybe doing me a favor, like doing these podcasts, but it's not your regular day job that you do. But you told me that, you know, when it comes to performance and scalability,

it's basically you who picks up the keyboard and fixing all of these things that are coming in. At least oftentimes it is. Yeah, there's, as you may imagine, in particular in a container-like arrangement in a framework with core facilities where there's a lot of shared infrastructure underneath and a lot of shared metadata being managed, there's concurrency issues all over the place. And not issues as in bugs, but issues as in making decisions to trade off certain optimizations over the other. It's a constant effort. We have been optimizing the internal use of locking and the internal metadata management decisions

are really geared towards a runtime stack out there that is being monitored, right? For our code, our framework facilities to never appear as a hotspot, right? In like contention in lock arrangements. And fortunately, we also have quite a few reporters out there who do exactly optimize for those kinds of scenarios. And they present this on the reports of like,

look in my scenario under these conditions with them dead load, there's actually a little bit of, it's not too bad, but in my scenario, it does show up, right? And we really care even to that degree, where we're trying to optimize anything we can. But of course, there's always a chance that if you optimize it for somebody's case, you're kind of making it worse for somebody else, right? Or you trade off memory consumption over minimizing memory consumption over caching, cache arrangements.

And there's a few things on the JVM that are really hard to optimize performance-wise. Just naturally slow and cumbersome. Annotation retrieval being one of them, something an application never does. But a framework always, a framework with an annotation-based programming model as one of its options, has to, of course,

do annotation retrieval all over the place. And this can be really expensive. And it is something we've been spending a lot of time on recently. So just last year, this year, we kind of really expensive and it is something we've been spending a lot of time on recently so the just last year this year um we kind of re-implemented our entire annotation retrieval arrangement um not necessarily for being for better performance out of the box but for better configurability for better tuning and so the kind of uh we we often refactor towards an arrangement where people can customize things

if they realize if they recognize that certain things are an actual hotspot for them because us making decisions of trade-offs between those performance optimizations is sometimes not the right thing to do leaving it up to whoever builds the stack and whoever tunes the JVM and the entire stack anyway, leaving it up to them, giving them hooks, giving them options in fine-tuning the performance relevant behavior that we have in the core container or in the core web stack is a path that we've been going towards. We'll definitely connect it with the outcome, I guess. I think this is again...

Spring Boot is, of course, many of its options that it has are sort of performance-related or can be, right? Or optimizing startup performance. A recent topic, of course, now in cloud deployments in particular, many services, many instances of

services being bootstrapped, maybe just temporarily even. So optimizing for startup performance in Java in the JVM with a framework or several frameworks on top is totally non-trivial. And that's also why we, of course, are strongly interested in what GradVM native images can provide us. But at the same time, we know that the mainstream

is, of course, on a regular open JDK, so the out-of-the-box performance needs to be optimized for those scenarios. And in terms of what we've been doing recently in Spring Framework 5.1 and 5.2, many of those optimizations, fortunately, turn out to be transparent benefits. Basically, take an existing application, unchanged, upgrade to a newer version of the core framework underneath, and startup is just naturally faster, where some peak performance points are naturally optimized. That is the ideal scenario. We've also learned that in quite a few cases, it does have an impact onto the application's design.

So there's just a degree of performance optimizations where you hit the barrier and you basically need collaboration, cooperation from the application development team where like, no, if you stop doing this in your components,ructure your component and your configuration arrangement just a little, then you might be closer to native image compatibility than you are now. So we also need to educate people a bit that not everything can be a totally transparent optimization refactoring underneath the covers. So part of it is also that we need to provide guidance around it. So you like to optimize for certain performance characteristics. Here's how. Here's the facilities that we have. Some of it is your job.

We can't do it for you. But we can provide guidance, in particular guidance towards using framework facilities where it might not be entirely obvious what kind of performance impact certain design decisions within your component model has. It's some of those things we know, what kind of effort the framework goes through in making that happen. But an application at the application development level,

an application developer might not immediately realize how expensive certain component model options are. So again, another fascinating topic. I think we could talk probably for a long, long time now. I know, and this is typically a question that Brian asks at the end, but I want to actually ask it now. So you are a fountain of information.

And- BRIAN DORSEY- A fountain. FRANCESC CAMPOY FOSTER- Yeah, I mean, I think there's maybe better words for that. But it's like- BRIAN DORSEY- Next time we probably need to do a video so that I can give more of a fountain impression. So what I want to ask, so you are now, by the time of this airs, I think it's probably going to be end of October. You are, how do people know where they can find you?

I know you are on the conference train a little bit, not as much maybe as others, but what's the best way to get in touch with you? Because I think that's important if people have follow-up questions. I am on Twitter. I do read my Twitter profile, but I'm not an active tweeter. So it's kind of a read-only account, but I do read all the notes that I get there and all the references. It's like a Spring, Jurgen, as the Twitter handle. Other than that, the most immediate channel are our open source project references. It's like a spring during as the Twitter handle. Other than that, the most immediate channel are our open source project facilities.

So the forum, the issue tracker, my main means of communication. And of course, there's always email. I know it's old school these days. How dare I suggest email? But we also, we all have public email addresses. It's better than sending notes with pigeons, right?

Like Harry Potter. It is about being able to manage all the everyday communication that comes in. And the issue trackers and all those really focused facilities that we have, in our case, mostly from GitHub, are really a great help in that direction. Internally, we also have Slack, of course, and Slack channels for team communication. We are a distributed team. Most of us work remotely. So we also need to facilitate communication within our team, which, of course, has always

been like this. So we are used to it. But yeah, communication channels around open source projects are a key piece of the puzzle. If even the team has a hard time communicating with each other, it's going to show. FRANCESC CAMPOY FRIEDMANN- Exactly, yeah. That means if you cannot live it internally,

how would you live it externally? That's basically what it is. ANDREAS SUIKAERTMANN- And conferences are, of course, a great way to get a kind of life impression, to get in touch. So I often do both sessions if the conference is off for them or just Q&A sessions after the presentations. That is why I'm going to conferences. Otherwise, I could just record a webinar. But it's this life interaction with people, attendees, listeners, of course, also other speakers,

is a key part of why I occasionally go to conferences. I actually do quite a few. Just not as many as I used to, but I still go to like about 10 conferences a year. Well, that's plenty. So we obviously make sure that we put your Twitter handle and all the links that are relevant on the podcast proceeding so that people can reach out to you. Brian, I know typically you summon the Summaryator, but do you want to give it a try this time?

I'll take a crack at summarizing the first part. How about that? So in terms of if you're starting your own open source project or working on one currently, what we learned from Juergen today is that it's very important to keep pushing the boundaries of what you can be doing. Don't just sit back once you push it out. Keep developing it. Keep adding new features, but also find creative ways that you can fit it into existing things and new things that are coming up because that's the way it's going to be adopted. You can't just throw it out there and hope people recognize how beautiful it is.

It's like any other thing, right? If you're an artist creating music or anything else, you can't just create the, you can just create the project and put it out there, right? If all you care about is satisfying yourself, but if you want people to use it and if you want it to be adopted, you have to get out there, you have to talk about talk about you have to show people how they can use it you have to find

ways it can fit into new and upcoming feature sets that are coming out or new ways that things are to be deployed so with that in mind i'll wrap that up because you know i tend to ramble when i do these things that's about the best i can do in the summary there i like the analogy with the music scene yeah concerts versus conferences right the life interaction oh yeah it's true yeah or even even just even just promoting it on social media like you know you can't just be like oh i'm i'm an artist i'm just going to make my stuff and i'm going to get discovered you're not going to get discovered part of being a successful artist in any realm right is you have to also be a promoter of your own stuff

and building building your community, building your own community and your fan base. Yeah. And growing towards and along with your audience, right? There's also artists, basically, established artists already are at the end of, or far along that line. But for a new coming artist,

you really have to find an audience and kind of grow along with them. I guess the very same is true with an open source project. But it is that commitment that you really need to have when you're into it as a maintainer,

as an engineer on an open source project. You're committing yourself to sustaining and evolving the community along with your technical offering. You can't separate those things. And it requires a strong commitment, long-term commitment. My commitment might be particularly long-term with the 16 years and counting, but it is sort of it's not something you can just throw out. It is something you have to see as several years at least of involvement, of commitment, of guidance, of direction that you're giving. And you don't know where it's going. Maybe it develops a life of its own with other people stepping in and taking key roles in the project.

And you never know. But in particular for the bootstrapping phase, and that can be several years, there's a strong commitment where people expect guidance and direction from the original office, from the original project team. So the last thing that I want to say, I like it that I think you are a perfect example of somebody that sees change as an opportunity and not as a burden. Because a lot of change happening in our industry, which is very exciting. And obviously with your passion to it and driving it forward, it's just phenomenal to see what we can actually do. And that individuals like you have the power to kind of become, I think I'm using one of these marketing terms, the trailblazer that is like, you know, like the lighthouse that is guiding the way, but really seeing the change in technology as an opportunity to build better things, to make us as an industry

better and having the passion that you have just tells me now I understand why you are successful with it. It's very, it's very nice. Thanks. And I know you're very busy with everything that's happening the conference is coming up and you have you know it's your constantly releases and so thanks for taking out an hour of your time um it's thanks for the invitation i totally appreciate it and enjoyed it very much thank you and i know it's an interesting

setting here with us being so close because of our little headsets here. But thank you so much. We'll post a picture later on. We took a selfie. So people can see. I was going to say, it harkens back to the days of Walkmans and couples sharing the music. You'd see them walking close together with one another.

It feels a little bit like it. It feels like it right now. Yeah, exactly. That's what it is. Alright. Alright. Hopefully, we'll That's what it is. All right. All right. Yeah. And hopefully, you know, we'll have you back at some point because there's so much more stuff that, you know, you can share with the community.

It'd be my pleasure. And there's always something new to talk about anyway. Thank you. Thank you. Thank you.