EPISODE 1667

[INTRODUCTION]

[0:00:00] ANNOUNCER: Java is one of the top programming languages used today, and Java code is ubiquitous. A key factor to the overall success of Java is the Spring Framework, which is the most common framework for Java development. Spring is an open-source comprehensive application framework on top of the Java Virtual Machine that provides a consistent programming and configuration model. Ryan Morgan is a Senior Director, and Mark Pollack is a Senior Staff Engineer at VMware Tanzu, a division of Broadcom. They join the show to talk about the origins of Spring, the problems it solves, building APIs for AI models in Java, and much more.

This episode is hosted by Lee Atchison. Lee Atchison is a software architect, author, and thought leader on cloud computing and application modernization. His best-selling book, Architecting for Scale, is an essential resource for technical teams looking to maintain high availability and manage risk in their cloud environments. Lee is the host of his podcast, Modern Digital Business, produced for people looking to build and grow their digital business. Listen at mdb.fm. Follow Lee at softwarearchitectureinsights.com, and see all his content at leeatchison.com.

[INTERVIEW]

[0:01:27] LA: Ryan and Mark, welcome to Software Engineering Daily.

[0:01:30] MP: Hello.

[0:01:31] RM: Thank you, Lee.

[0:01:33] LA: I know VMware was recently acquired by Broadcom, so you're now both actually working for Broadcom. How has that transition been going? At the time of this recording, it's only been a couple of months now, is that correct?

[0:01:46] RM: That's correct. It's been about three months now. I would say that in terms of the overall strategy and mission behind what we've been doing at VMware, all that has transitioned straight into Broadcom as well. Spring remains to be a very important part of the overall application strategy that we have within Tanzu, and it does fit very well into the rest of the application portfolio that Broadcom has.

[0:02:09] LA: Cool. Well, let's start out with an overview of Spring. Let's start with, for people listening who aren't as familiar with Spring, what is Spring, and why is it important?

[0:02:19] RM: Yeah. Spring is a comprehensive language framework on top of the JVM that provides a consistent programming model and configuration model for application developers. I would say, its success is primarily driven by that modularity, and the fact that there’s just a large and vibrant community behind it. We have over 200 different technology starters that we use that can integrate Spring with really any type of third-party system out there. In terms of questions, or community, there's always somebody there that has likely had the same problem as you, and the community can really help drive solutions for developers.

[0:02:57] LA: How did Spring get its start? Am I correct that it's 20 years ago?

[0:03:01] RM: It has been 20 years. Yes. I've been part of the team for about 10 years. Mark has been here a lot longer than I, and maybe Mark, you can give some of the early history.

[0:03:10] MP: Yeah, sure. The very early start was Rod Johnson was the founder of the framework together with Juergen Hoeller. But Rod had created a framework at a consultancy company he was running in response to customers he was serving. He got convinced by someone, not sure who, to make it open source, and that's where he met the second person who was a member of the Spring team, I guess at the time, Juergen Hoeller.

He was very prolific. He was a good businessman and marketer, and wrote many popular books. At the time, there were other frameworks around, and still are, from the Java EE specification. This was presented as a lightweight alternative to some of those specifications. It just resonated very well with Java developers, and continued to grow, and take on different technology stacks as time moved on, because technology doesn't stand still. Those were the initial beginnings.

I guess, common story sometimes in the beginning of open-source projects, it was an itch that he scratched and became popular, because it was a good design and a lot of common need for what he created.

[0:04:29] LA: What was the early adoption like? Was it a fast adoption? It seemed to me that it came into being one day, and suddenly, it was popular the next day. Is that about what happened, or did it take in a while? That you just not hear about it until it was popular?

[0:04:45] MP: It got very popular, I think, quickly. I always remember back to some of these very early server-side conferences, which were held, I think, in Las Vegas. It seemed astonishing to me that on the panel would be Sun, and Oracle, and BEA, and yeah, these companies that are worth hundreds of millions of dollars. Then there's this guy up there basically telling them, everything they're doing is crap. But he's on the stage, right? The conference organizers did do a good job and get the right people there.

I think it took off pretty quickly. Probably within one to two years, it was becoming very common. After it was released to use it in the enterprise, which I think was a very interesting focus, right? Not many open-source projects necessarily are enterprise-focused. That's how I came to be involved in the project. I was working at a company, TIPCO, which is very focused on message-oriented middleware and integration. The specifications for Java, at that time, the J2EE specifications didn't cover this technology.

I wanted to use Java for it and use it in a good way. The Spring Framework was very amenable to change and customization. I couldn't go to Sun and say, “Please, let me add this technology stack into your spec.” Eventually, of course, we had Java message service, but this was many, many years before. That ability to respond to demands in the enterprise, who have real problems to solve and not get caught up in that standardization process, I think drove a lot of the early success. Standardization is important, but probably, there was a wave of over-standardization and slowness, and that slowness is an [inaudible 0:06:36] to technology adoption.

[0:06:40] LA: The growth has been astronomical and has been, is it safe to say primarily driven by enterprise use cases?

[0:06:47] MP: Yes, I would say that.

[0:06:48] RM: Yeah. I think one of the things, Lee, that's been interesting for me, when Spring Boot was released in 2014. It was almost a reinvigoration, I guess, of the community. From that point forward, we've really seen this sustained 50% year-over-year growth, really, over the past five years. It's been pretty remarkable. I would say, that the vast majority of those are those enterprise use cases, where you have large companies like, Netflix, etc., that are depending upon Spring to deliver value.

[0:07:21] LA: What is it about Spring? It's the open-source nature, making attractive for changes by the enterprise, but that by itself isn't enough to cause it to have this level of growth. What is it about Spring that made it better than anything else?

[0:07:36] MP: From the developer point of view, when I first encountered it, it seemed to be really very well-designed, very modular. At that time, there were probably 10 different ways to connect to a database. Everyone, still today, has to connect to databases. The approach that existed at the time, just with the JDK, was very cumbersome. There was a lot of code to write for very little effect. Of all the frameworks that were around, the same relating to data access, Spring provided a lot of value, and which was just very well-designed.

Yeah, just that alone was getting a single app to talk to a database and present a web form and do transactions correctly was a huge win. You could spend weeks trying to do that in that era. I think that underpinning and that focus on design, an ethos that carried over from the book, right? When people contributed, everyone was in the same frame of mind, and got educated along the way.

There's an internal term we use called, yorganization, where Yorgan would review your code, and you might have worked a week on it and said, “This thing is the most perfect piece of code I ever wrote in my life.” Then he'd come along and you'd realize, it was just average. There are certain people who have really super power skills. I'd say, he's one of them that was able to, in a very polite and mentoring way, share his insights and make it so that we could all start to work in that manner and learn his tricks of the trade.

[0:09:19] LA: Yeah. I think it's hard for engineers now to imagine that a framework, a language framework, that makes it – where its primary goal is to make it easy to make database connections would be a big deal, right? Because, of course, you talk to a database. Everything talks to the database.

[0:09:34] MP: The problems change over time. Same thing with Hibernate, came on the scene, using Hibernate together with JDBC, together with the web app. In those very early days, those were major accomplishments that now probably just seemed passé.

[0:09:50] LA: Yeah, yeah. Ryan, when did you come into the scene?

[0:09:55] RM: I joined Spring Source back in 2009. Spring Source acquired an IT management company that I started previously. Then as you moved into Pivotal, my boss decided that he was going to retire. From that point, I've been leading the engineering and product teams for the last 10 years or so. 

[0:10:16] LA: Makes sense. Let's talk about Spring Initializr, which is essentially, a bootstrapping tool for people who want to get started using Spring. I have to believe that that was a major portion of the early adopters’ growth was the fact that it was very easy to get started. Talk to me about Spring Initializr, and for people who are not familiar with it, maybe start out with what is it and what does it do for you?

[0:10:42] MP: Initializr is important, because when you're starting a project, normally you had to figure out what type of project it was and what type of libraries you would need to include in it. You normally would just start from a blank piece of paper. Okay, my build system is Maven. All right, let me create a file called pom.xml. Maybe there was a little wizard in your IDE, but it wasn't much. Then you would search on the web to find some place in the documentation that would say, here's the library dependency you need to add for this functionality. You cut and you paste that and you do this 10 times.

Then invariably, you cut and pasted from something that wasn't consistent. You ended up with a mess. Then half hour later, you were like, “Okay, done. Thanks, great. I compiled nothing, basically. I just have a shell of a project.” Yeah, I'm sure there was, Dave Syer as one who made that. I remember, even I was trying to fool around a little bit at the time, time saving steps and tricks. He came up with the thing that is now Spring Initializr, where you go to a website and it would be very clear what your options were in a typical web form. You can search for these dependencies and say, generate. Then out would come, basically, this shell of a program.

Didn't have any code in it, but at least solved the problem of you picking the right dependencies for what you wanted for your use case. You were off to the races much quicker than you would have been as compared to the previous method I described, which is a hunting and pecking, basically.

[0:12:25] LA: It gave you all the configuration and all the framework. None of the code that you need, but all of the initial default configuration options and things like that, necessary just to get started.

[0:12:34] MP: It's been around a long time. It has a huge success. I've now started another project called Spring CLI, which is more akin to other ecosystems that have something like, Create React app, where it creates the shell of the app, but also includes code. In some way, the next version of Spring Initializr is not web-based, it's CLI-based, but it does a similar thing, but it's more focused on use case that's known and providing you the code for that as well.

I think that's maybe one reason why Spring continues to do well is it tries to improve itself, right? It doesn't just rest on its laurels. Both of these things just get you started going much, much quicker than before. Spring CLI also lets you add functionality to your current project from a sample project. Most people aren't starting from scratch nowadays, especially enterprise. They're starting from brownfield, so to speak. That's another area where we're adding value to help people move quicker. Example with AI, right? You could now add all your dependencies and some sample code to your current project with a small CLI command.

[0:13:51] LA: Makes sense. Let's talk about versions here now, without getting into the very interesting, along with the discussion of Java versioning in general. Spring's recently jumped from using Java 8 to using Java 17 and 21. Java 17 is now the minimum supported version. But enterprises still love Java 8. Why is 17 required?

[0:14:17] RM: In terms of what Mark was saying earlier, just the progression of Spring and continually evolving, we see there's lots of ways that we can drive efficiency and performance and continue to drive all the innovation that's coming from Java back into Spring Framework and Spring Boot. That was the primary reason for doing that. There are a few others. There's the Java X to Jakarta EE migration that happened as well. We made the decision that we want a future proof of Spring developers for the next decade, and we may as well do all these changes at once. That was really the primary point behind that.

[0:14:56] LA: What has the feedback been from enterprises that love Java 8? What have they been saying to this?

[0:15:01] RM: There are a long tail, I'd say, of customers that are stuck on Java 8. I heard one recently, there's a customer on Java 6. There's definitely thought that has to go into, “Do I want to modernize this application or not? What are the risks for doing that?” Overall, I think the feedback has been very positive. Just in terms of upgrading from Java 8 to 17, we've seen customers realize 15% performance improvements, just from doing the upgraded self. That's really no code change at all to your application. It’s a simple dependency update, or a JVM update that gets you there. It's definitely, you have to weigh your options there in terms of the business priorities. From what we've seen, it's been mostly positive.

[0:15:45] LA: Moving from Java 8 to Java 17, obviously, moving from any version to any version for an enterprise can be a difficult challenge. That aside, what are the real technical challenges of moving from Java 8 to Java 17?

[0:15:59] RM: Yes, this is an area where we put a lot of work into it. We've been active contributors into the open rewrite community, to really help automate migrations from Java 8 to Java 17. Mark has also been very involved with that. Maybe I'll let you give your experiences, Mark, of what you've seen.

[0:16:15] MP: Yeah. I guess I have a huge breadth of it, compared to, say, someone Netflix who has thousands of apps to upgrade. Again, to Ryan's point, their motivation was the JVM runs is 20% faster and 20% faster means less bills on Amazon. That means bottom dollar savings, right? It's economic incentive to moving there. In terms of what you have to do, I guess, it's one of those things, it depends, unfortunately, right? What parts of your app are you using, things that almost have no representation now?

Itself, there's a lot of portability and longevity in Spring when it means backward compatibility, but it's not easy. The tools help, but there's no magic button push here and you're done. I won't deny that it's difficult.

[0:17:08] LA: What's an example of the type of thing that they have to do to update? What is one of the big things that catches people up?

[0:17:14] MP: I'll give one example that I just happened to follow. There have been changes in Spring security framework. It involved changing the use of one class to another class. There are all good reasons why these changes were made. Security is clearly an area that has expertise. Most likely the person who wrote that code, when Java 8 was released 10 years ago, he was no longer with the company, right? Who knows what they were thinking really, what they had in mind. Now that you have to upgrade, you have to find someone who also has security expertise.

It's not always just swap this in for that. It's sometimes a rewrite of some level. When you're rewriting something like security, you don’t obviously want to do it, any work haphazardly, but some areas are more critical than others. That's an example of where we have to release notes. Some of the open rewrite recipes help. They don't go all the way. There are some gaps there that we are working on to try to fill, but that's a specific example of the class that you would use to configure spring security is it's just changed, right, for the better at one point, along the same time that the baseline for Java 17 and the Spring framework was done, that was when all these deprecated classes actually got removed, most of them, right?

What good is having a class marked as deprecated, if you never remove it, it's just ceremony to make you feel better at night? At some point, you want to clean up the code base, so it remains maintainable. It was decided this time was like, the big Spring cleaning. Let's get rid of the majority of those things that we held back removing and have clearly told people, deprecated. You compile and you see it there every time you compile. People have learned to ignore that as white noise, basically, over the years. I think it's the right decision. It's hard to justify staying on a 10-year-old version of the JVM eventually.

[0:19:20] LA: Definitely. I mean, you bring up security as a rationale for. That's usually one of the main reasons why it's easy to justify those sorts of required upgrades. When was this requirement made? Was this recently, or was this a while ago, the move to 17?

[0:19:37] RM: Yeah, that was part of the Spring Boot 3.0 release and the Spring Framework 5 release back in, I believe, November of 2020.

[0:19:46] LA: Even that is a few years old now. Is there any thought of requiring a move to 21?

[0:19:53] MP: There's no requirement. 17 is the baseline. There are generations of the JVM, including 21 that will be supported from this same code base.

[0:20:02] LA: But there isn't any inklings, or any thought in the open source community, or within the company walls of moving with 21 being the minimum requirements. Obviously, the need to move from 8 to 17 was important.

[0:20:17] MP: Doesn't seem like there's a need to do that, right? Yeah, it doesn't seem like there's a compelling reason though.

[0:20:23] LA: Java is obviously, it's constantly expanded in capabilities over the years and capabilities and in size. Some people believe that Java is bloated. As such, it's not as useful for modern cloud-based microservice architectures. What do you say to that comment?

[0:20:46] MP: Typical ecosystem posturing. Compile a Node app and look at the bajillion dependencies that have to be aligned to do it. Same thing with Python. They all have weaknesses and strength in different communities, but I don't see it really as being something that is not appropriate for microservices. I'm sure if you said that in an interview at Netflix, they’d just walk you right to the door and say, “Have a nice day.”

[0:21:12] LA: Ryan, do you have maybe a differently worded answer to that question?

[0:21:17] MP: I'm from New York, so that's the nice way of saying things in New York.

[0:21:23] RM: Yeah. I mean, this has been a focus that we've had. I said in the opening, all the work we've been doing recently is around that efficiency theme. There are so many great innovations that are happening, whether that be Project Loom, bringing virtual threads to the JVM. There's work around Project Leyden to bring CDS. These are all things that we're bringing into Spring Boot and Spring Framework to make – and Spring Native, right? We have a new AOT model for Spring Boot 3. What that does is really allows us to be good citizens in the cloud, use less resources.

Really, we have a lot of folks on the team that think a lot about sustainability. We want to make sure that we're good citizens there as well. We don't want to have that moniker of being bloated. At the same time, as Mark says, you have to weigh that along with the efficiencies that you get from using a framework that has really integrations with everything and has that consistent model that drives efficiencies for the team.

[0:22:20] LA: You mentioned Spring Boot 3. I'll be completely honest, I actually don't know an awful lot about that. I know that's important in this, for this efficiency improvement with Java Boot size, etc. Can you talk a little bit more about what Spring Boot 3 actually does?

[0:22:35] RM: Yeah, so maybe I could just step back. We use Spring interchangeably. We have over 50 different projects in the Spring portfolio. Spring Boot, its role is to really wrap all those into a very easy and convenient way to package your applications. In addition, it does dependency management across hundreds, or perhaps even over a thousand different dependencies. Really, it's driving, again, just the overall efficiency for developers.

In terms of the performance and the work that's going in on the efficiency front, that's really across the entire portfolio. It's not just Spring Boot. Spring Boot is just that thin wrapper that makes it very easy for developers to consume.

[0:23:16] LA: Boot is the thing that keeps the rest of the projects working together and running efficiently. How many different tools are part of the Spring portfolio now?

[0:23:27] RM:  There's, I think, roughly 50 different projects.

[0:23:29] LA: One of the newly launched ones is Spring AI, is that correct?

[0:23:34] RM: Yes. We just launched Spring AI and Mark is the lead of that project.

[0:23:37] LA: Mark, why don't you tell me about Spring AI?

[0:23:40] MP: Yeah. So, Spring AI is essentially, the starting point for Java developers to write AI applications. Just going back to the analogy with JDBC, when you start writing applications and see that OpenAI has their API, different API offered by Amazon Bedrock, or other companies, several startups. It wasn't a lot of uniformity around that API. Each one was different, almost like a comparison of database access before the JDBC standard was created. The first focus and design principle that we have in Spring framework is to provide common abstractions over similar technologies. We've done this in the Project Spring data as well, and you can have data access layers and underneath, one could be Mongo, one could be JPA, but they share a common design.

That was basically one of the first areas to tackle was just connecting to one of these models, provided by one of the model providers. Then you start to see, well, what are the common use cases? How can you make those common use cases easier for developers? That's a very similar pattern. You could say it almost about any of these Spring projects, right? It just, when does a certain technology in the ecosystem meet the bar that we should have a dedicated project for that technology?

I felt early on playing with it that this would be something important. I started this, I think, in August last year, I guess, maybe. Something like that. Like, the first little inklings of writing this stuff down. I had already been playing for a few months, but that was when the project really got launched was last summer, end of summer, about.

[0:25:25] LA: It's a way of connecting to existing AI, cloud-based AI tools.

[0:25:31] MP: Right. Making it easy to transition between different vendors. If you want to compare and contrast, you don't have to rewrite your app. Enterprises hate lock-in, right? That's probably their number one, or number two after security. I guess, fear in life is vendor lock-in. This helps alleviate it, but it also provides the productivity to handle common use cases that occur in AI. If you go down the list of each of those 50 projects that we were talking about earlier, or mentioned, you'd see a similar statement. We make this easier than the raw APIs.

Messaging is a very good example. Or, yeah, maybe something even more simple is you talk to the database, you get a result set back. This result set is not a Java object. You have to convert from this data type, the JDBC type, to some domain object that represents your business. How do you do that? We provide that glue that makes that layer very simple. It's the same exact thing, believe it or not, in AI, if you ask it for a response and say, “Please, give me the response in JSON, not text.” Because it’s a computer asking the question, not a human, right? Now you have to convert that JSON into an object that you can use in your system. That's an example of a very traditional step that is a little tricky, believe it or not.

The way you do it is you have to coerce, usually, the AI system and sometimes beg it. Please, give me JSON. Please, please. Please, give me JSON without any preamble saying, here's your JSON. Just the JSON, please, right? That's an example of a simple ease of use case, that now someone doesn't have to write that extra code, or think about how one system converts to JSON versus another. They're all a little bit nuanced.

[0:27:24] LA: Traditionally, or maybe historically might be a better word, when people think about building AI systems, or talking to AI services, they think about using Python to do that. How does Java with Spring AI compare to using native Python for AI application development?

[0:27:43] MP: Yeah, great question. Python is where it's at for AI and ML hardcore people, right? That's where the technology stack started, going back a long time now. The big difference is ChatGPT. The P in GPT stands for pre-trained, right? I'd say, before ChatGPT became so popular, there really wasn't much other choice, because you had to really be an expert in machine learning, or AI to get these systems to work.

Now, I might get it to work, because you probably had to train a model, right? Training a model is not a thing that a Java developer just knows how to do. If you give me a pre-trained model and a simple API, I can call an API. Every Java developer can call an API. That's what they've been doing for years. I'd say, the transition point is really around the fact that the AI solutions that we're writing are the consumer end of it, right? We're going to this pre-trained model with a very easy to use API. Now, we're getting all the benefits of that.

Whereas, let's call it the more underlying level of engineering, where it all originated, still has, of course, Python is its dominant case, but not everyone needs to sit at that level, right? The fact that AI is everywhere means it's going to be in the enterprise. The enterprise is primarily Java. It's just an API call. It's not technically a challenge as it was before.

When I started investigating this, I said, okay, what are the popular frameworks in Python? Line chain is one, llama index is another. You peruse the source code, even use ChatGPT to explain Python code to me. I'm like, “What is this doing? I can't even understand this.” There was this whole meta model that people use, which anyway, whatever. There's all this Python stuff. At par, I'm like, there's nothing here other than basic API calls, and some logic. There was nothing saying, “Oh, I need a master as a PhD in data science in order to rewrite this library for Java.”

A lot of the ideas, of course, came from them. Wasn't done in a vacuum, Spring AI. It was really by studying their code base, studying the problems they were solving. Then taking that inspiration to write it again in Java, but based on idioms that are common in the Java ecosystem, and not idioms that are common in the Python ecosystem. If you did a one-to-one translation, a Java developer would look at it as an unnatural library, from their point of view. For Python people, it's totally fine. That's just the difference between the languages.

[0:30:26] LA: You made the APIs look like a Java API, versus a Python API that's layered into Java.

[0:30:33] MP: Exactly. Yeah. Yeah, there are expected programming patterns that exist in Spring, which is what gives it – we have 50 modules, right? The beauty, going back to the original discussion we had about the design, there's some design principles which I think most people just don't even care about now, actually, when they write libraries, but we care a lot. What that means is every one of those 50 modules in Spring has a familiar look and feel. So, that when you have to move to a new technology that you pick up a new Spring project for, you can get to lay the land very quickly. “Oh, I know that class. Oh, yeah, that's how we do this. Oh, yeah, right.” You can almost skim the docs and get to where you need to go, because of this common design patterns that exist across the different projects.

[0:31:23] LA: Really, when you're trying to compare Python to Java with Spring AI, it's an apple to oranges comparison. Spring AI is really designed for users of AI models that are building enterprise applications in Java. But if you're building AI systems, you're probably already using Python anyway, and you recommend sticking with that. Yeah, yeah.

[0:31:47] MP: Yeah. I mean, I don't have to recommend it, right? That's the way the world is, right? If you go to how these transform models are being trained and created, yeah –

[0:31:55] LA: From Python.

[0:31:56] RM: - that's not Java happening over there. See, we all have to get along. It takes a village, right?

[0:32:02] LA: It sure does. It sure does. In fact, this actually is a good lead into my next question. If you look into what I call modern application development, and what I'm talking about that is I'm talking about mostly the CNCF definition of what a modern application is; Kubernetes, container-based, microservice-based cloud native application, that model for building new applications. That's not a lot of what the core Java user is doing, but it's what a lot of the new development is going into.

Java obviously fits into that environment, and so does Spring. But Java was initially written as a – I remember the original mantra for Java was write once, run anywhere. That was the whole purpose of Java was the ability to write your code and not care where it's run. It's not really the mantra of it anymore, but that's really where it started from.

[0:33:00] MP: Now it's so understood you can do it, no one even questions how it could possibly be any other way. No one's job is to port a C++ application from SunOS to Linux, right? That job category doesn't exist.

[0:33:16] LA: Well, that's another discussion. We can certainly have that conversation coming from an ex-C++ person way back. I’ve been in C++ in a long time, but I used to. I guess, what I'm really coming to is that really, the containers is taking over that model now, right? I mean, the way you build something that is really agnostic of where it's run is you put it into a container. That's the whole mindset behind containers and Kubernetes. That's the whole model behind a cloud native application, and then that whole framework is that. Given that, where does Java fit into that mentality?

[0:33:51] MP: My take is, you can run it whatever you want in a container. You can run COBOL. There's really, in my mind, a separation. The container is just the thing that brings it up and runs on the computer. What's inside the container is whatever you want. Could be assembly line.

[0:34:05] LA: But from a business standpoint, why run Java? What are the advantages of Java in that environment? Other than, obviously, one of the big advantages is there's a lot of Java developers available, right? That's a big advantage. I grant that.

[0:34:18] MP: It's a big advantage, right? Like you said, if I walked into Google and said, “Hey, I want to contribute to the next version of Gemini,” they’d say, “Great. Here, take a test on Python.” They wouldn't ask me about Java. It's just, I think, where each ecosystem's happened to land and banks and big enterprises for whatever reason. I don't know. It'd be interesting to know why. Somehow gravitated to Java early. Probably, because it was easier than C++ at the time, to find people who could write code effectively. Because they're so conservative, once a bank makes a decision, never changes. I guess, we're just living in the legacy of that initial adoption from way back.

[0:34:59] RM: Yeah. There's some advantages there, too, I think, in terms of memory safety and just really putting guardrails around developers. Java does a great job of sandboxing that environment for folks. As Mark said, there's a gigantic ecosystem that makes developers productive. At the end of the day, these large corporations, their largest expense is probably their developers. Making them efficient at what they do is really what drives the bottom line.

[0:35:28] LA: I agree with that. Yet, the banking industry is one of the industries that's moving very rapidly to cloud native applications. Are the advantages of Java going away for them? I'm thinking from the long-term here now. Obviously, Java's not going anywhere in the short-term, right?

[0:35:45] RM: Yeah. We are seeing that. We're seeing these large corporations are very quickly moving to containers. We've done a ton of work in Spring to make Spring work fantastically well in containerized environments. Really, when you think about all those cloud native patterns, a lot of those are really baked into our projects already, right? If you want to do distributed configuration, we have a solution for that. You want to do service discovery, we have patterns and tools for that. Really, those things are abstracted across really any type of environment, right? I think that's what makes Java and Spring really attractive for those use cases.

[0:36:22] MP: Yeah. Interesting question. I'm trying to think, even from your perspective, can you give some example of some other ecosystem that's more cloud native than Java? It's an unusual question from my ears. They're all as native as they want to be, right?

[0:36:38] LA: Well, that's true. I'm thinking, the definition of cloud native as the cloud and compute foundation, CNCF describes. I think, if you talk about languages that are really popular in that community, you're talking about languages like Go. You're talking about lots of other –

[0:36:52] MP: Yeah. There is a big difference. System languages like Go, like Rust, they're not used for writing web apps as effectively, I think, as Java was. Go is probably in the middle, but you can make the argument, and I think it is being made very well in the Rust community. Imagine there was never a memory leak, right? Ever. Super valuable, right? That's why people are really gravitating towards that. I think, yeah, Go came later, obviously. I still think it's not going to easily displace, probably has displaced a little bit the use of Java, but it does feel a little bit more – all of Kubernetes is written in Go, so its primarily claim to fame there is it's a system language. It's what's running the next layer of your computing infrastructure.

I think very early on in the days, people said, “Let's write a database in Java,” right? Then all developers were like, “Oh, that's pretty cool, because I write Java, and now I can look at a database code and it's written in Java, and it's great.” But pretty obvious, Java is not the best language to write a database in. It's really good for writing business apps. I think Go probably has a little bit of that, I don't know. Headiness, well, the underlying infrastructure is in Go, so now that I'm so into knowing the technology of Kubernetes, I'm going to write everything in Go. I don't think a lot of people really write business applications in Go. That doesn't –

[0:38:18] LA: I think you’re right. Yeah.

[0:38:18] MP: I think, the CNCF in, liking Go so much is because it's probably most appropriate for that problem space. What's most appropriate for the problem space of enterprise developers is a different language, a different ecosystem.

[0:38:32] LA: You think that Java and by extension, Spring, is going to be that environment for the foreseeable future? Is that the desire, or at least the belief?

[0:38:43] MP: Yeah. I mean, I don't see why it wouldn't be, but who knows what might change that perception, right? It doesn't feel to me like, there's large abandonment of in the enterprise.

[0:38:55] LA: No, you're right.

[0:38:58] MP: I don't have my finger on the pulse, but I haven't heard the stories of its death.

[0:39:03] LA: Fear of the death has been greatly exaggerated. What's next for your team? What's next for Spring?

[0:39:09] RM: Yeah. This upcoming year, we have a variety of things happening. I'd say, one of the most exciting things is the adoption of Project Leyden. The app CDS, or class data sharing work that's happening. It's ways for you to take your existing Spring application and be able to really realize some of the benefits of this performance work that we've been doing, really without any modifications to your code. Earlier today, we mentioned Spring Native. We mentioned a few other technologies that they help in these cases of faster response time, or faster startup time, less memory use. All of those are pretty involved in terms of what you have to do to make sure your application is ready for that type of environment. Again, we're just trying to follow fast with Java and really ensure that all the great work that's happening in the JVM space is being exposed to the Spring user.

[0:40:05] LA: Where do you see AI in the future that's going on right now, the massive changes in the AI space that have been happening right now, where do you see that in Spring's future beyond Spring AI?

[0:40:18] MP: Yeah. I mean, we've spoken internally about using it for different things, but I don't think we're there yet to make product announcements. I recently saw an advertisement on – I was shopping for a USB charger, one of those battery pack things. On it, had an arrow to the USB port and said, AI USB port. I'm like, “You got to be kidding me.” This is a dumb piece of electronics by any standard definition. I think it's just going to be ubiquitous in the enterprise, because frankly, again, it's going to probably displace certain jobs, or certain types of jobs and drive more efficiency into organizations.

The landscape is changing so fast, it's so hard to make any prediction. It could be the things we're excited about now in terms of techniques to make it understand corporate data that it wasn't trained on. Maybe that would go away, right? It's shocking. I think there's just now a chip out there called GROQ Groq. It's hardware, right? Basically, if you follow that out, it's like, every computer you buy will now be an AI computer. Every phone you buy will have some chip in it, that'll be an AI chip.

It's a big wave. It's really an enormous wave, maybe since mobile in my mind, and maybe before that, the Internet. Who could have predicted what the web was 10 years later, right? When it started in the mid-90s. It's that crazy scale and crazy speed. I've never seen something like this be adopted by every major tech vendor aggressively, practically ever. Amazon, Google, Meta, Microsoft, and of course, OpenAI, which is in some way, financially dependent on Microsoft, they're firing on all cylinders to try and make it seem their platform is the best platform, and infusing it into all their products, into office, into the Google office suite, into Microsoft 365, down into your phones. It seems, yeah, we're probably in the Wild West days right now.

[0:42:27] RM: Yeah. I think there's really two ways of thinking of this. I think the work we've done to date is mainly about trying to enable developers to consume AI, right? Providing those abstractions on top of models and clients prompting, etc. As you think, maybe more into the future, there's work we could do around Spring assistance. Maybe there's ways that we could train models on all the data that we have around Spring to make Spring even easier. If you have a question, we have a repository of information that likely has the answer. That's one area.

Also, to our previous conversation on the challenges of upgrading and moving from one version of Java to the next, or from one version of Spring to the next. We've seen some innovations there. Amazon Q had an announcement this year around being able to have AI-powered upgrades, right? It's all very early. It's hard to tell where it's going to go. But I personally know that developers spend a fair amount of time doing hygiene on their applications, doing upgrades, doing really monotonous things that maybe they shouldn't have to. Maybe we could have that be automated in some way. It'll be interesting to see how quick that comes, but I do think it's coming.

[0:43:39] LA: We're just about out of time here. Ryan, I'm going to let you have the last word here on, where do you think the ecosystem is heading? What's next? Just in general, just your views.

[0:43:52] RM: Yeah. We talked earlier that there's been this constant drum beat of Java is dead, there's the next new thing. Through that, Java is more popular than ever. I would say that Spring is more popular than ever. We're going to continue to invest. We have a very unique and powerful offering that really drives developer productivity. Through that, I think we're going to continue doing that. We're going to continue driving that value for customers and looking forward to the Tanzu work that we have at Broadcom. We're going to be making our Tanzu platform the best place to run Spring, really giving both developers and operators of these platforms really the ability to execute and move very quickly.

[0:44:35] LA: Great. Thank you. Ryan, Mark, this has been a great conversation. I definitely appreciate your time and energy. I want to thank you for joining me today on Software Engineering Daily.

[0:44:45] RM: All right. Thank you very much, Lee.

[0:44:47] MP: My pleasure. Thanks for having us on.

[END]