Bio Juergen Hoeller is co-founder of the Spring framework and has been the most active Spring developer since the open source project began from Rod's Interface21 framework back in February 2003. Juergen is an experienced consultant, with expertise in web apps, transaction management, O/R mapping technologies, and lightweight remoting.
QCon is a conference that is organized by the community, for the community.The result is a high quality conference experience where a tremendous amount of attention and investment has gone into having the best content on the most important topics presented by the leaders in our community.QCon is designed with the technical depth and enterprise focus of interest to technical team leads, architects, and project managers.
1. This is Charles Humble and I am here with Juergen Hoeller, the project lead of the Spring Framework. Juergen, I’d like to start by talking about some of the features in Spring 3.1. Can you tell us a bit about Spring Cache?
Caching is certainly one of the key themes that we are setting. Caching has some history; it’s a long term issue. We meant to do a caching abstraction for a long, long time and we are finally taking the opportunity, in Spring 3.1, to actually deliver it. The idea is not so much that we are providing an abstraction for the cache providers themselves, it’s more about access patterns, so that the typical interaction with a cache that an application does is available through a Spring abstraction in the form of a cache manager and a cache abstraction, typical arrangement, [supporting] key value pairs, cache regions, so, those kind of concepts. We not only provide the abstraction, we also go into the declarative caching space where we provide annotations and an interception facility. We call it cache annotation driven, it’s a bit like TX annotation driven for the transaction space, where when you call a method, the framework would intercept the call, just check whether there is a value in the cache and retrieve that value instead of calling the method, based on annotations, so in an annotation driven model.
That’s really what we aim to deliver and the cache abstraction is basically the back end behind those access facilities. The actual implementations of the SPI will only provide Ehcache out of the box as a reference implementation, kind of, and we rely on external projects, some of them run by ourselves, to deliver adaptors for commercial cache providers; because most of them are commercial.
The reason why we are introducing this now is partly because distributed caching is becoming a topic again. Of course, it’s not really a new space, but now with the Cloud movements, Cloud platforms, Platforms as a Service, distributed caching becomes a topic once again. Products such as GemFire, Coherence, they are ideal back ends for this kind of model that we are providing here. And there will be out of the box adaptors for those, in some form, but not as part of the Spring Framework project itself.
Yes. There is a quite natural relationship since we are kind of targeting the same space. Caching providers are to some degree used as data stores in some form. Today distributed caching provides us with persistent store in particular. And in Spring Data we aim for talking to the more obvious examples for alternative data stores, like Redis and Mongo, where we provide Spring’s template style access classes for those kinds of data stores. So, there is certainly a relationship in some form, but a technical separation where we just say those products are supported over there in Spring Data, more the kind of database-like access patterns and, use case wise, if we are talking more about cache oriented access patterns then that’s part of the cache abstraction. And of course, many of the alternative data stores they don’t actually use a key value model. So we have the Neo4J, as a graph database.
There are different ways of talking to those data stores. So Spring Data is not really an abstraction. It’s a collection of support packages for those individual access models that those data stores have. It’s not really trying to abstract them, it’s trying to natively expose them for Spring based applications.
Yes; it’s something we’ve been following. We are kind of waiting for it - we have been waiting for it to some degree. But, as of Spring 3.1 we basically said, it wasn’t part of EE6. There was no attempt to go into the caching space, so, we’re providing our own cache abstraction for the time being and it looks like we’ll actually turn this into a quite sophisticated long term offering, even if JSR 107 comes along in some form, probably in a reinvented form actually. I don’t think that the old JSR is going to be revived as it is; it’s going to be a new approach to caching as part of EE7 I suppose, and we’ll make sure that things integrate nicely on top of our caching abstraction, behind the caching abstraction probably more importantly, like we do in other areas.
We’ll certainly make sure that we can adapt nicely, and I don’t see any show stoppers in that space, because the caching space, from an access pattern perspective, is well understood. I would hope that this is quite a natural fit, once it comes along; which is probably Spring 3.3 timeframe - in that kind of ballpark.
Spring Batch is a project that I personally always consider when introducing new core facilities, because Spring Batch has special ways of using Spring, or a special use of Spring facilities, that maybe the traditional Spring based web application doesn’t use that much. So things like the task executors, task schedulers, all of the concurrent programming facilities in Spring; and some of them will actually be extended and reinvented to some degree with Java 7 in mind, for the Fork/Join framework and so forth. So for some of those things we really plan to expose them in some form, or make good use of them in Spring Batch, so that’s my primary consideration at the moment.
The Spring Batch model, the programming configuration model, I think is well understood and well accepted. But I see a lot of potential, in particular for Spring Batch, to make good use of things like Fork/Join underneath, to expose it, to translate its own step model to it. So that’s the relationship that we usually do. Spring Framework provides some core facilities, already with some use cases in mind, and some of the other Spring projects, such as Spring Integration and Spring Batch, then consume them; integrate them into their world. In that sense I would certainly expect Spring 3.1 based releases of Spring Integration and Spring Batch quite soon to follow after the Spring Framework 3.1 release.
There are quite a few. I mean Fork/Join is probably the most important, the one with the strongest impact, because it’s a programming model, user level facility where people will have to reinvent, or to reconsider, the ways that they are implementing their algorithms. But there are other pieces, such as the try-with-resources class and the autocloseable interface behind it. We are considering to use that or expose that in some form for some of the Spring classes, so that we would provide some Framework classes that can be used with a try-with-resources class. So there are some things we do consider. There is JDBC 4.1, but well, that’s not really that major a step, but we’ll make sure that our JDBC adaptors, we have a couple, where we actually provide decorators for JDBC, that they are JDBC 4.1 ready. So we’ll do a comprehensive Java 7 upgrade, but from a user experience I am pretty sure that the Fork/Join framework and possibly try-with-resources, that’s the two things that users will care about.
There was actually one further thing that I would have loved to see in Java 7, in that space, and that’s the date/time API, which, unfortunately, didn’t officially make Java 7. I hope for inclusion in Java 8 and for an independent release in the meantime because it’s actually really good stuff; and Java.util.Date and code they need some love, some competition, some reinvention and the date/time API is a good start there. And it would have been something that, once it’s released, we’d immediately adopt it into Spring’s programming model, just like we did with Bean Validation, with JSR 303 (it’s the same kind of thing); we’d immediately support it. For the time being we’ll have to stick to Joda-Time, even on Java 7.
Conversations, historically, they’ve been associated with Web Flow. So we, of course, had Spring Web Flow with its navigation model, and a conversation model that goes with it, basically driven by the flow navigation model, quite strongly, and that’s actually some of the origin of what we are doing in Spring 3.1, easing Web Flow: more of the motivation than the actual code possibly. Some of the other influence here comes from the JSF space, where in JSF there are several conversation extensions: MyFaces Orchestra, for example; some less well known ones; then there’s of course the one in CDI, which is quite JSF-oriented. We’re trying to provide some common ground in this space basically, so Spring 3.1 is not trying to go into the Web Flow domain. It’s going to provide a foundational conversation management facility that Web Flow would use, that Web Flow would delegate to, more of a conversation store abstraction, with the management of a current conversation, this notion of a current conversation.
As far as we understand right now that’s about everything we really need to provide in order to have some interoperability between like a Web Flow managed conversation and possibly a JSF conversation or a conversation that’s being used with the Spring MVC. So use case wise, there’s Web Flow, there’s JSF conversations (pretty well understood in the meantime) and, from a Spring MVC perspective, we have a session attribute store mechanism, managed session attributes in Spring MVC, and we’d also like to integrate that part with a more flexible conversation management arrangement in some form. We have yet to actually finalize the arrangement there.
The most important use case is that people want window isolation. So, with Spring MVC it’s probably the single biggest demand or request that we’re getting in that space. Session attributes by default, they are being stored to the HTTP session, which means all of the windows, all of the tabs that you have in the same browser store, basically talk to the same session. If you have the same form open in several tabs, all of them share the same session attribute that they store their data into. So, having an isolation between window tabs and window browsers for several independent form conversations, that’s a request from Spring MVC users, and it’s part of our agenda here that we are trying to provide a first class solution for that particular problem. So it’s really several pieces that together form a conversation management theme for Spring 3.1.
And in that sense it’s somewhat like CDI and Seam conversations possibly, but only one of those three perspectives. The MVC perspective and the Web Flow perspective are pretty independent and actually are quite different in several respects. So, we’ll see. Our mission is to find, identify the common ground, and build it into the Spring core.
I followed the evolution of the CDI specification quite closely and it has an interesting history. It started actually in a quite different form than what we actually got in the end. Its original mission was to develop a conversation scope, the very original mission, to develop a conversation scope between JSF and EJB3, and JSF-EJB3 integration overall was also part of the mission. But in the end it’s actually a quite rich dependency injection model in its own right. Several interesting ideas in there; quite a few ones that are not unlike things that Spring has been doing, since the Spring 2.5 days in particular. There is, of course common ground as well here, so the state of things basically is that JSR 330 defines the common dependency injection annotations that are supported by Spring 3.0 and 3.1 and at the same time, also, supported by CDI containers: that’s @inject, @qualifier, the provider interface, so the core parts of the dependency injection model.
But, on top of that, of course CDI adds quite a few things: an eventing model, a special scoping model. There are a couple of things that design-wise go different ways from Spring, but I would argue if you have a good understanding of Spring, of dependency injection, but also of Bean scoping, that this translates quite nicely onto CDI and vice versa. So moving between the two worlds shouldn’t be too hard. They just go different design directions; they have different design tradeoffs that just naturally evolved over time. There are several things I disagree with in CDI, but I’m sure there are several things that CDI designers disagree with in Spring’s design, so I think that’s a fair situation to be in. We have no closer plans with CDI at this point, although we do actually keep watching it.
But we are following JSR 330’s evolution very closely and for Java EE7 it looks like there will be a revision, at least a 1.1 revision, of the core dependency injection specification and people can certainly expect an implementation of that, support for that, in Spring in a very timely manner.
Just a couple of days apart.
We have been following, not only CDI, but the entire Java EE 6 specification quite closely and it’s not a coincidence that Spring 3.0 went GA a couple of days after the Java EE6 specification release. So we have been following the evolution of several specifications, not least of it all JPA 2.0, JSF 2.0, of course JSR 330 and JSR 303, the Bean Validation specification. Those four are the most interesting pieces from a Spring perspective in EE6. Well, they are actually quite independent. I mean JSR 303 has independent implementations, can be included into any kind of application very nicely. So can JSR 330 - dependency injection annotations, and the JPA 2.0 Provider is also usable in many environments, so that may be part of the reason why we care about those and we immediately supported those after their specifications have been finalized; actually before they all delivered production quality reference implementations.
There are other parts of EE6 such as Servlet 3.0 that we just tested against, but that we hadn’t had dedicated support for. And in Spring 3.1 we’re actually closing that gap so Spring 3.1, as one of its themes, has Servlet 3.0 support, which means support for the Servlet 3.0 configuration model in particular. There’s a really interesting alternative to web.xml driven bootstrapping in Servlet 3.0 - the servlet container initializer model - and that’s a really nice fit for Spring’s Java based configuration model. So, we’re trying to provide a seamless experience here, basically a non-XML configuration experience, for Servlet 3.0 users in combination with Spring 3.1, and that’s going to be a really nice fit. So other than that, well, Java EE6 had, of course, JAX-RS and a couple of other interesting specifications that can be used with Spring very nicely, although Spring itself doesn’t actually have any specific JAX-RS support.
The reason is quite simple: all the mainstream JAX-RS providers out there provide Spring support themselves. So, you will get Spring support for Jersey, you will get Spring support in RESTEasy. There is nothing to do, on the Spring Framework side, in order to be a good citizen in the JAX-RS world.So, I would say that Spring 3.x has a really good Java EE6 story, both from using several EE6 level specifications independently, but also for running an entire Spring application on a Java EE6 server, which, from a Spring perspective is a nice bundling of all those specifications, and some providers, out of the box. You get a JPA 2.0 provider, a JSR 303 provider, a Servlet 3.0 container.
That’s like a really nice foundation for the Spring 3 programming model to sit on top of. That’s the way that we see this, and GlassFish for example, GlassFish 3.0, 3.1, it’s a great server for Spring based applications from that perspective, and it’s the one that we test against. We even have dedicated GlassFish load time weaving support, so it’s a really good fit for Spring-based applications.
10. One of the things that is being talked about in the context of Java EE7 is the problem of multi-tenancy, so running the same application on a variety of different environments, be that an App Server, or a private Cloud, or a public Cloud. Does that problem arise in Spring?
We have yet to understand what the EE7 specifications will do about multi-tenancy, because from my perspective, there is pretty good isolation between applications in the Java EE world and also in the Cloud platforms, the Platforms as a Service as we have them today: Google App engine, Amazon Elastic BeanStalk; they all use the war deployment units, and basically manage an isolation container around war files at run time and it seems to get them pretty far. At this point Spring-based applications are like really great citizens within a war file. In many ways, Spring is the framework of choice for war-based deployment and, as far as we know at this point, there is nothing specific for us to do in order to participate in any kind of isolation model that a servlet container would be providing.
If there is something that comes along, that we can do, where for example the application may provide some configuration context to the container in order to identify some kind of isolation level to other applications, if there is something we can do, we will do it. But the Java EE 7 specifications have yet to deliver a more concrete model in that space.
11. I have the impression that Spring is reluctant to get involved in the standardization process. Generally you follow the standards, and you’ll follow them pretty closely, but I don’t see a lot of involvement from Spring in the standardization process. Is that a fair comment?
It’s certainly a fair impression to get, although historically and say more JCP internally, it’s not exactly how things worked. But yes, in terms of concrete participation, JSR 303 we did participate. Although it was strongly driven by Bob Lea, of course, with great working relationships with Bob Lea; we’ve been co-specification lead, but, fair enough, Bob Lea certainly was the primary driver. We have been following several other specs, even with people on the expert groups, such as JSF 2.0, for example. Whether we had a strong design impact, well maybe less than others I am sure, because JSF has also a couple of drivers that just really move the specification forward and most of the expert group is listening; and with JSF 2.1 and 2.2, that’s basically still the case. We are actively involved and there are actually discussions in what form we could add some more concrete work to JSF 2.2.
But, from my perspective, we take specifications as they develop, we follow them from an early stage on. We don’t necessarily need to influence them; we are just trying to make sure that things play nicely with the Spring programming model. That’s really our most important mission. For some specific areas, I personally really care about standardization: constraint annotations, where, I mean that’s really creeping into the very heart of the domain model, so those guys should be standardized; dependency injection, in the form of @inject and qualifiers, it’s a great fit for standardization. If it was for me to choose a stereotype model, like Spring has with @component and custom stereotypes on that basis, a flexible core stereotype arrangement as part of the JSR 330 or JSR 250, I’d immediately adopt that.
There are some more specific things where I would personally be interested in standardization, but overall Spring really provides its own programming and configuration model that needs to live and breathe independently. So Spring really selectively adds standardized parts to its world, but itself, it shouldn’t actually be standardized in any form from my perspective. It should rather be a good citizen with all those standards that are around it and be a kind of glue together, a flexible glue between several standardized parts out there. And that’s what it actually is at the moment. That’s basically its positioning.
Rough dates, yes; for Spring 3.1 actually quite concrete dates. We are now working towards milestone 2; there are just two milestones planned, so RC1 is planned right afterwards, and 2 in April, RC1, end of May, I would say, the GA target date is end of June. I would hope that we actually make that. It’s not up to us though; once we go release candidate, it’s up to the general user community to tell us whether we need more release candidates before going GA. So, roughly end of Q2, for Spring 3.1, and Spring 3.2 is supposed to follow quite quickly, which basically means early 2012. Certainly more quickly than we used to deliver major releases after the previous one. Java 7 goes out in Q3 this year, so Spring 3.2 is quite strongly driven by Java 7, because the central theme is Java 7 support in that release. So whenever we feel that the Java 7 mission has been accomplished from a Spring perspective, that’s when we’ll release Spring 3.2. But I would say early next year; chances are really good for that.
We also have Java 8 in mind already to some degree. Java 7, Java 8 they have been split. Java 8 is kind of the leftovers that didn’t make it into Java 7 and there are several design implications coming from the Java 8 language features that are quite clear already, where basically the JDK team deliver the quite concrete proposal, like closures being compiled against what they call a single abstract method type. So, there are some design implications, some design considerations, that we take into account for Spring 3.1, 3.2 already, so that we’re basically preparing for the language enhancements in Java 8 already. But that’s basically ahead of the game, because Java 8 won’t be released before, well, the end of 2012, early 2013 more realistically; so we’re really preparing for it. That’s the plan that we have at the moment. I’m pretty sure that the Spring 3.3 release will follow around the time that Java EE 7, Java 8 comes along, at the latest.
But we only really have a concrete plan for like 12 months ahead usually. This world, the Java space, the Java industry is moving quite quickly, so it’s quite hard to tell what the considerations will be in a year’s time. We’re very flexible, very agile in our release planning. We really listen to what people want us to deliver and we are trying to deliver it in time. At the right time. That’s not necessarily always the time when specifications are being finalized. The right time is usually when people start adopting some of the specifications, when they really start adopting some of the reference implementations. With Java 7 chances are good that people actually will adopt it quite quickly. Underneath Tomcat, for example, using OpenJDK 7 with Tomcat 7 on top should be a quite straightforward migration from OpenJDK6, so I would hope that at least parts of the Java space will be able to upgrade to Java 7 quite quickly.
That’s why we will be delivering a Spring 3.2 release with Java 7 support quite quickly, because we expect that adoption to be, well, better than it used to be at least. With, you know, Java 5 and Java 6 it took years before the industry really caught up with it. I would hope it won’t take years before Java 7 becomes mainstream.
Slight typos in the transcript
great interview. There are some minor typos in the transcript: In section ""What are your views on CDI since you’ve mentioned it?" there's "Spring 3.5" which probably has to be 2.5, as well as "add Inject, add qualifier" should rather be "@Inject, @Qualifier".
Re: Slight typos in the transcript
Re: Slight typos in the transcript
Same remark for the answer about the involvement in the standardization process: "add inject", "add components".
Otherwise, nice interview. And the text transcript is very useful when you are waiting some code compilation ending... ;-)
Re: Slight typos in the transcript
Gosh - didn't do a great job on this transcript.
Thanks for letting us know,
Hieu Lam Tri
Re: Nice Interview