Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ


Choose your language

InfoQ Homepage News SpringOne 2017 - Day 2 - Juergen Hoeller on Spring's Mission

SpringOne 2017 - Day 2 - Juergen Hoeller on Spring's Mission

The SpringOne Plaform Conference Day 2 keynote was well organized and replete with surprises, including keynotes by SpringFramework lead Juergen Hoeller and Microsoft Distinguished Engineer - one of the Gang of Four - Dr. Erich Gamma, among many notable others.

In 2002, Hoeller cofounded Spring, when as legend has it, he was inspired by a book by Rod Johnson he read over a Christmas break.

Hoeller’s address was consistent with the impassioned message that has permeated the SpringOne conference, a message of collaboration with the technical ecosphere and with the general community, to evolve the SpringFramework for the benefit of all stakeholders.

Some excerpts from his address:

On the challenges of meeting Spring’s responsibility to the industry:

I have had the pleasure and privilege to guide the Spring Framework through so many years and so many iterations, and so many changes in the wider Java ecosystem. We are now in 2017 and moving into 2018 and we are again in the same situation, facing the same challenges; since Spring the framework was never designed to live on an island, it was always a very integrated affair, embracing new generations, embracing relevant infrastructure in the JVM ecosystem.

Keeping up with Java’s new six month release cadence:

At this very moment we had very interesting changes coming our way. In the very core of the Java ecosystem. We have a new JDK 9, we already have it since September. We will actually get a new JDK generation every half year. We really need to let that sink in. We are used to getting a new JDK every three years, three and a half even, and now it's every half year. Of course, the frequency of releasing new features won't change; everybody's human, so it's simply a faster release cadence. We're getting a new JDK 10 drop in March 2018. We're going to get a JDK 11 release drop in September 2018, simply shipping whatever is ready by then. So they are actually minor feature releases in that sense, but they are shipped as major releases, raising the bytecode level in every single JDK iteration, being able to ship new language features in particular, in every one of those iterations. So in that sense they are more than just 9.2 releases; they do bring new language features. JDK 10 for example, is about to send the new local variable declaration our way, so there is a different model of bringing new features in the core JDK libraries, to bring them out at a more reasonable time, basically whenever they are ready. There's always a next JDK iteration coming up in half a year's time, so we are never going to wait for more than half a year to consume them. But there's another side of that coin. A new JDK generation every half year means a new bytecode level, which means tooling needs to be ready to handle a new JDK version; a new bytecode level, every half year. This can be quite a challenge, and quite disruptive to the Java ecosystem. Many tools are based on bytecode generation, possessing libraries such as ASM, CGLib, ByteBuddy, and they historically have not needed to evolve to leniently embrace new JDK generations; they have evolved to be designed for a particular set of JDK versions only, and they had to be updated every single time. So we'll have to change our minds a little; we'll have to design our infrastructure, our bytecode processing, in such a way that a new JDK generation is a totally normal thing. We have JDK 10 now, we'll embrace it; we'll have JDK 11, let's just install it and run our existing infrastructure, existing frameworks, existing libraries on it, and everything should be good. We just have to change our minds towards that model. A particularly important note here - not all of these JDK releases are long term support releases, and long term support is something we really care about; in production we only really want to use generations of the JDK and JVM that have a long term support attached, and we're only going to get the long term support release every three years, according to the current plan. This may change, it's all evolving, but from the current perspective, JDK 9 is not a long-term support branch. JDK 10 won't be either. It's only JDK 11, planned for September of next year, that will be the next long-term support release. So JDK 8 is the current support release, and JDK 11 is the next. This presents a challenge to us of course, we have SpringFramework 5 designed for the JDK 8 baseline, this is very common in the ecosystem; many libraries are Java 8 baseline and in their current generations, they really embrace everything Java 8 has to offer. They are open to being used on newer JDK generations, so basically Java 8 is the reference point for libraries, frameworks, and of course for production environments, and having newer JDK generations is a bit of a bonus at this point.

“From a SpringFramework perspective, we are totally ready to adapt to the runtime environment. So if you take a SpringFramework 5.0x application, run it on JDK 9 it's going to adapt fine, it's already running fine on the JDK 10, and it will run fine on JDK 11. So JDK 8 is great, JDK 9 is fine in terms of adoption, but be ready to embrace JDK 10, and in particular 11 as soon as they come along, if you choose to move beyond the JDK baseline.

On technical collaboration:

Beyond the OpenJDK itself, and all the innovation that is happening in the JDK and the JVM, there are many other interesting efforts out there, and we are involved in quite a few of them. We have a really fine relationship with the Kotlin group at JetBrains for example, and it's a pleasure to work with them. This is a collaboration that is very beneficial in both directions, and many of the recent developments in SpringFramework 5.0 have been inspired by Kotlin. We're not just talking about applications being based on the Kotlin language; we are also talking about all of the inspiration that comes out of Kotlin, that made it back into SpringFramework 5.0 and all of those design decisions; many of the language idioms in Kotlin translate quite nicely to a Java ecosystem. There are certain patterns that are really important in Kotlin, that made total sense in other environments, even in traditional Java 8 environments as well, so in SpringFramework 5, although there are many things coming together, this  will inspire features that we are shipping all across the framework, so that if you choose to use Kotlin as the language to implement your Spring based application, then the Spring framework and its APIs really feel very idiomatic; very Kotlin ready, even beyond the easy parts. We are really going the extra mile to provide first class Kotlin support. This is a very beneficial relationship with the Kotlin group, because we uncovered issues that they fixed for us, so that we could do what we wanted to accomplish, and this is a great example for the kind of cooperation that we're doing.

Another area is reactive streams – project Reactor is really set up to be reactive streams-based, and is kind of a natural part of the reactive streams ecosystem. There is a great relationship there, not only with reactive streams work itself, but with the RxJava team, and with the Lightbend people working on reactive streams. There is great alignment there, in terms of vocabulary, terminology, semantics, and of course agreeing on the reactive streams contract at runtime. But there are so many things coming together, more than just the minimum; we are really trying to align to the best possible degree, making our existing RxJava know-how applicable to applications using project Reactor with Spring workflows.

There is another recent development, EE4j; we're seeing the end of Java EE as we know it, and EE4J is the follow-up model evolving the specifications that used to be developed in the Java Community Process, as what we know as Java EE; all the specifications like the Servlets specification, JPA, Bean Validation, they were all donated to the Eclipse foundation, and they are being managed as part of the EE4j umbrella project. This is a great opportunity for us to get involved in the specifications that we care about. We have a long-standing investment into the Servlet specification, we have been a member of the JPA expert group for so long, we've been integrating Bean Validation for so many years. We just recently started embracing the Json Binding APIs, an alternative to Google Gson. We are taking many individual specifications from this umbrella, and this is in the stages of being set up. Certain processes have yet to be established over there at the Eclipse foundation. But it definitely has the potential for us in particular, to see more frequent minor releases of certain specifications; maybe a JPA 2.3, a Servlet 4.1, not in four years’ time, but maybe next year or 2019, a more reasonable time, simply when all stakeholders agree that it is worth shipping. If Tomcat and Jetty agree that there is an API refinement in Servlet 4 that they want to be shipped as Servlet 4.1, then it should be possible to make that happen in a reasonable timeframe.

“Of course we are engaged in so many efforts, but those are really fine examples where we've already been able to ship a lot of added value or expect to be able to ship further added value in 2018. Kotlin 1.3 Coroutine model, the new use of Reactor anything coming out of EE4j, we will be embracing it in a very timely manner, in the course of 2018 or 2019, whenever things are ready.

Core Spring Framework Roadmap:

From the core SpringFramework perspective, we are ready to continue the mission that we started with SpringFramework 5.0. 5.0 was very theme driven, the whole notion of functional API design, reactive architectures, the reactive web stack, embracing Kotlin as another first-class choice of languages on the JVM. These are very strong, long running, on-going themes. We are technically not at the end of any line here. We started a new generation of the framework, we are going through iterations now, listening to feedback from everybody out there, all the stakeholders; you guys, but of course, the Kotlin group, our Reactor group, so many feedback loops in action here.  And along those lines, our roadmap for 2018 has two iterations planned, even at the core framework level. We intend to drop a SpringFramework 5.1 around end of May/early June 2018, just doing whatever we can at that time. There are quite a few refinements in our backlog on JIRA already, so if you want to have a little bit of insight into what is happening next year in the core framework area, go to our JIRA issue tracker, to the 5.x backlog; there's almost 200 ideas and issues and improvement requests, and if you particularly care about any of those, please vote on them or comment on them, add your perspective to them;  this really influences our prioritization efforts for next year. And even if something can't make 5.1, we intend to have another opportunity, a little bit along the line of the new JDK release cadence, with a SpringFramework 5.2 towards the end of next year; another opportunity to refine the model. Update dependencies to the newest features, embrace new happenings in for example Kotlin, maybe something is coming out of the reactive streams collaboration, towards a reactive JDBC integration API. All those things we're going to pick up whenever they're ready, in the 5.1, 5.2, or possibly 5.3 iteration in 2019.

This is a very ambitious effort, running many things in parallel, so we intend to keep working for you and it's going to be a very exciting year in 2018, and I am personally very much looking forward to seeing what it has to bring.

Rate this Article