Sure. I have been serving as the Spring Project lead for more than years, almost 12 years in the meantime and that is what I keep doing. I am currently in charge of managing the Spring Framework for the next generation, having evolved to 4.0 and now from 4.1 to 4.2 transition.
It is an interesting question, but since the interest rate reaction in the recent years was interesting in its own right. In many of the things that we have been doing, we have seen very, very positive reactions. At the same time, there are, say, certain voices in the industry who already have their vested interest in calling the Spring legacy or chose your negative term of the season. But my take on this is very different anyway. With Spring we are basically on ignition. We have a certain philosophy in how we evolve the framework . The framework has a strong assumption that infrastructure is basically there, not necessarily the developer’s choice. It is kind of one the fundamental principles: decoupled from the infrastructure, which means to a large audiences out there having to deploy the existing infrastructure. Our challenge, our value add is basically that we are allowing them to get the most out of the infrastructure that they have.
Spring brings very recent, very modern programming module styles onto, say, older infrastructure. That is something that we have always been doing and I would argue it is even more important these days now in 2014, 2015. It is more important than it used to be 10 years ago since what we are seeing in the industry is an increasing disconnect between what you find installed in production and what is being advertised as the latest kind of specifications these days. At this very point, most people have a 2009 era - Java EE 6 environment in some form. Spring Framework 4.1 is basically a late 2014 framework that should bring in very recent spice into that environment. It really spices up the environment to a very modern day web input module in particular, perfectly capable of running on 2009 era infrastructure, but not being stuck on the 2009 era programming concepts and programming limitations.
So, that is something we just keep doing. Every year basically, new infrastructure comes into the picture, but old infrastructure does not go away. So, we make sure that we run perfectly well on most recent infrastructure and we just preserve our ability to add the value of Spring to older data centers, all kinds of infrastructure. That is still very true, that is basically the one part of my thinking about this is that the values that Spring is providing apply even more than before and the other one is, connected to the talk I have given here at VOXXED Days, is the strong design philosophy behind Spring, even down to the very details. I could spend hours discussing the design philosophy behind specific Spring programming module concepts, between the choices we have made, the trade-offs we have made. There is always a little bit of history involved, but mostly it is specifically designed to be a comprehensive and coherent model for the present generation.
The idea behind it is that we are independently crafting a programming and configuration model that does not just follow along some common ground that somebody established somewhere. We rather had our own vision about it and evolve it based on our own vision. I find it pretty important these days, right? It is a diversity in the Java ecosystem which really adds value to that very ecosystem itself in its own right and we would like to just keep pulling towards our own vision there. We are often facing the question of specifications for specific purposes. Sometimes this is the answer when we are going our own ways, because this is our own vision is suddenly different from what may end up in specification documents. So we keep evolving Spring the way we did it for the past 10 years, for the same reasons, for very similar reasons that still very much apply.
Rags' full question: That might lead to the next question which is at the other extreme. It seems like Spring ecosystem keeps growing and growing in a way that there is Spring Batch, there is Spring Boot, there is Spring Cloud, there is Spring data, there is – you name it, right? So, give me an internal perspective – how do you pick like a particular Spring project? And give me the other side: I am a developer – how the heck do I keep track of all this?
Perfectly valid question. The one part of the story is why we are splitting our efforts into those projects. This has primarily to do with team structures and release cycles. We tend to set up a new project. If it is likely to have its own pace, it’s own release cycle, if it tracks third party efforts of someone like our Hadoop offering for example Hadoop.like bound to release cycles of the party products, then we just give it its life on its own, its release cycle of its own, not revving it along with the old framework. It started like that. In the mean time we have a lot of those efforts. Each of those projects has its own project team – that is the second part of the picture. Now Spring Framework has its own team, there is a dedicated Spring data team, there is a Spring integration team, somebody els for Batch and so forth.
They are kind of around a dedicated group of people – the first thing that they think about when they wake up in the morning is that very project that they are assigned to. There is a lot of stability to those teams, so mostly those projects are evolved by the same people who originally conceived them. So, the end result of course is quite a landscape. If you look at the project.spring.io page, there are quite a few projects on there, some nested ones even with Spring Data. So, if you approached this ecosystem from an outside perspective, it might look quite scary maybe – Oh, there is so much going on there! Of course, we have the more recent efforts like Spring Boot, the Spring IO Platform, our start.spring.io web - that we have recently accomplished. These go a long way towards mitigating a few of those concerns where we are providing unified dependency management either for our own projects and for associated third party projects.
So, it is rather easy to get started these days by using our IO Platform where you get started with a version arrangement that is known to work and where quite a few of the Spring projects, like our Spring modules, are being kind of driven in implicitly, where you do not have to consider the purpose of each and every one of those projects, where they are kind of brought into your project on a demand basis. As you declare in need for a certain feature, the dependent modules come in. So, those are efforts from the past year of two to quite some degree making it easier to use those projects from a more unified angle. In terms of the further evolution, it has proven to be very useful, both to us and to the community to have independent projects. So we are not trying to merge projects, we are just trying to kind of unify the evolution and dependency arrangements between those projects. That seems to be the best possible compromise for us.
The connection to Cloud Foundry has some history in the meantime already. It is mostly, for start, a Java perspective, a Java application development perspective for Cloud Foundry where Spring is the recommended, promoted programming model for that kind of perspective and for good reasons. The inherent ability in Spring to adapt to the infrastructure given in any kind of target environment – it applies perfectly naturally to a Cloud environment, and Cloud Foundry is a perfect example for this where the ways of managing the infrastructure there, how it is exposed to the application, is just quite different from traditional environments. Spring has no problem at all adapting to those and for that it presented itself as a natural choice. The efforts that we are spending in terms of a synergy between the two is in particular making sure that Spring kind of allows you to take the benefits that the Cloud Foundry has to offer and to actually expose them to the best possible degree in your Java based, Spring based environment. We do not believe in abstracting infrastructure, in kind of dumbing it down, avoiding to be all the same. We believe that certain kinds of infrastructure, Cloud Foundry in particular, have certain strengths that really need to be exposed. You need to make best possible use of those features and those capabilities and many efforts in Spring go in the same direction: smaller deployment units suggested by Boot, we even have a dedicated Spring Cloud offering in the meantime. There are dedicated Clouds support of some sort, but I find it actually more interesting to look at the more subtle effects of what we are doing and the different kinds of applications architectures, the different kinds of communication arrangements between the parts of the system. That is the impact that Cloud environments bring onto the table and different kinds of messaging solutions, messaging mechanisms and in Spring land we are trying to make sure that whatever we do with the programming module, it can naturally translate to that kind of infrastructure. And that is perfect input. It is the sort of input that is the best possible solution that you can come up with for a framework, if you are challenged from different sides, with very different requirements. So, it is what we keep doing.
Rags: So, in a large part, they are complementary to each other.
Absolutely. The idea behind Spring as a navigation framework is exactly that it stops where middleware begins and Cloud Foundry is basically a middleware arrangement on a flexible deployment platform so there is perfect separation of responsibilities there.
I should say that I am not an expert on Play, so I do not claim any kind of particular expertise there. However, I have seen that feedback, I have heard such comments. It is to some degree related to any kind of Java based solution. There seems to be an audience out there who is really very much into Play and in particular, also Scala, the language. From my perspective, where we see our mainstream audience is a quite some different place. So I do not see any immediate overlap there. There seems to be a very specific audience that is attracted by Play and by all means, Play and the underlying infrastructure that uts trying to support are great pieces of engineering. No doubt about it. There is perfectly valid value in those frameworks. I am personally just not sure whether stylistically and structurally, the model that has been used there, that has been kind of imposed onto applications there is that attractive to, say, more like a traditionally Java-minded audience.
So, in that sense, the mission is a bit different. What we are trying to do in Spring is to take people where they are in the main stream and try to softly move them on to a more modern variant of doing things. We are not making radical jumps and we are not making radical breakages because that would mean we would lose people. We would like to keep pulling them along. The interest also is going to be different from a framework arrangement such as in Play where you say “Let’s start from scratch”, even in Play 2.0 – “Let’s start from scratch once again and just see what we end up with”. So, from my perspective, I personally really appreciate such efforts, such technical efforts. They are really inspiring and I mean I admire quite a bit of engineering achievement, but it is a different focus and a different mission in that what Spring is doing. So in that sense, they do not really compete against each other. I would rather see them as kind of being attractive to specific audiences and they do not necessarily overlap that much.
The micro-services term. I personally prefer not to use it, frankly, since it is a bit of an overloaded term. There is a lot of meaning attached to it, depending on who uses it. But in terms of what it means, in terms of the trends, the impact that it has are very much appreciate it since it kind of makes us refocus on smaller units of deployment, on a different granularity that we are wondering about deployment units at the level of an operating system level container where a lot of consequences follow from it. It is very different from your traditional Java application server arrangement where you would think there is one JVM which owns the machine, right? And it does not want any other processes left or right. In a micro-services architecture, you have a very, very different layout, even at the operating system level.
In terms of the impact onto the programming model in Spring or in Java, the impact is not as radical as one might assume and a lot of the concepts that have been very popular in Java and in Spring in particular, they are apply very naturally in micro-services architecture but there is, of course, always baggage to provide towards specific modules and what we are doing in Spring Boot is very natural fit, I would say, with micro-services architectures, since Boot kind of naturally suggests smaller set contained units of deployment bringing in their HTTP engine and bringing in quite a bit of infrastructure through dependency management in kind of one deployment unit which kind of very naturally translates onto a micro-service architecture. But that is really the level that we are operating on, right? To some degree, that is quite orthogonal to how the operating system arrangement works. So in terms of Docker we do not really need to be very specific about supporting that kind of architecture. It kind of naturally fits, if you follow the same kinds of rules, both at the programming model in Java and in your deployment arrangements. So, I see a strong synergy between where that industry trend is going and between where we are going, but the connection is actually not that tight. It does not have to be. The value came in provided with a kind of loose alignment in terms of where we are going.
Five years from now? It is a little bit different than the way I typically go about planning. I tend to use an iteration of more like 2 to 3 years, since that is pretty predictable in terms of the Java ecosystem with other major factors in the Java ecosystem are going. Where we are currently at, is already the end result of such one result, of such a planning exercise is for Spring framework 4 initially. It had already taken that kind of perspective onto the industry. There was Java 8 coming, Java E 7 back in terms of the specs, messaging oriented architectures, web sockets becoming a topic. We consolidated many of those factors and trends in selecting what then became the Spring Framework 4.0 version and we keep evolving it on that basis. The immediate plans are currently towards the 4.2 iteration which, while a typical Spring feature release, it brings a lot of things into the picture, but many of those are subtle refinements. In terms of the more major themes - for example, we are working towards first class support for HTML 5 Server-Sent events in the Spring web layer, the Spring Web input model It is going to be a dedicated way of expressing a Server-Sent events end point using Spring.We are revising Spring’s web support towards ….., towards a kind of comprehensive core support, cross-origin handling. We are revising our HTTP caching arrangement – Spring always had support for HTTP level cache instructions and responses and this is going to get an overhaul towards a more modern day default handling of the typical cache headers and in particular making sure that the configuration is as consistent as it can be across Spring’s different input methods. The container is going to get a little of an overhaul as well. We are going to experiment a little with our @Bean model, the configuration class model. There are a couple of interesting ideas of what we can do with @Bean models and Java 8 default methods and interfaces and there is a couple of ideas where we are trying to turn prototypes into complete features in the 4.2 time frame. And there is actually a specification that we are tracking – JSR 354 Money and Currency which we find a pretty interesting specification along the lines of the java.time, the Java 8. It is a kind of rethinking of the java.util.currency, right?
Modern day currency and modeling and monetary units and monetary amounts. This looks like a great spec to me and it is currently a release candidate. Specs. is going to final very soon. So, we would like to support it in our data finding formatting features, out of the box, just like we do for the Java 8 time support. So that is also on the road map for 4.2. And it is all supposed to wrap up in a generally available release by July 1. That is the current plan. So it is a rather short iteration. We are using short iterations these days in order to deliver new features at a slightly different pace than we used to. We had more feature releases, we phase out the previous maintenance releases more quickly than before. So we are kind of preferring new minor feature releases over extended maintenance feature releases these days. So 4.1 followed after about 10 months after 4.0, 4.2 follows after another 10 months later for 4.1. That seems to be a fine iteration from where we are at the moment and we are going to continue along those lines so that next year the big topics are going to be JDK 9 which is going to be released like in the first half of next year. So, it is going to be very likely a Spring Framework 4.3 iteration, kind of tracking JDK 9 and providing some early support for other specs in that time frame. For example, Server 4.0 is something that we are really, really keen on - we are really interested in. So there is a couple of efforts that are a part of the Java EE8 umbrella that we will have already for some of this stuff. Beyond that, we have loose plans for a kind of major revision – a Spring 5.0 that would be, but those are a little bit further out.
So, I do not have a concrete time frame yet, but not in the next one and a half years, I would say. Spring Framework 5 would certainly be Java 8 based, so it would be a Java 8+ version of the framework. Across the code base, it would try to rethink some of the historical SPI arrangements towards a more Java 8 oriented perspective. So there are a couple of things that are definitely must haves. We will not do a Spring 5.0 from any older versions of Java. If there is a new major version, it is going to be Java 8+ based. But pragmatically, of course, we know that the industry is largely on Java 7, quite a few on Java 6 still so, our pragmatic plans are to extend the Spring framework 4.x phase, with minor feature releases for quite a few years. We are in the business of providing value to real live challenges out there in production, so in our release plan we will very much following those needs and the ability for the industry to rev up to newer versions of the infrastructure allows us to revise the framework on top of, Java 8+, for instance and not only that.
Rags:
That is a great summary, I think. Good luck in your efforts going forward and now that Spring is always a big thing in the enterprise and with trying to reach out to the older versions of Java, I think is always a good thing. But, like you said, you may have to move on at some point. So, that might be a good time to say thank you again and we will do it again next time. Thank you.