The Spring Blog

News and Events

Amsterdam Java Meetup Q307, September 21st

It’s time for the next Java Meetup again. I decided to postpone the 7th installment of this quarterly event in Amsterdam until right after summer, because most people here in The Netherlands take a couple of weeks off in August or so.

I’ve looked at our internal schedules and it seems September 21st is the only day left in September, so I hope it fits with other people’s schedules as well.

We’ll be doing it at the same location as last April’s meetup, as this is pretty convenient for us and everybody seems to be fine with it. The first Java Meetup ever was held in my favorite Amsterdam hangout, the Wijnand & Fockinck, but we quickly realized this is way too small to accommodate for 50 to 100 people and moved to the Jaren.


Debunking myths: proxies impact performance

In a recent blog entry Marc Logemann touches on the subject of proxy performance. In his entry he asks for a white paper by ‘the Spring guys’. I don’t want to spend (p)ages and (p)ages on discussing the differences up to the nanosecond between proxies and byte code weaving mechanisms, but I do think it’s valuable to re-iterate once again what the differences are and whether or not this discussion matters at all.

What are proxies and why do we use them?

Let’s first shortly revisit what proxies are used for (in general, and in Spring). According the Gang of Four (GoF) book on Design Patterns a proxy is a surrogate object or placeholder for another object to control access to it. Because the proxy sits in between the caller of an object and the real object itself, it can decide to prevent the real (or target) object from being invoked, or do something before the target object is invoked.


Grails and Maven: a Marriage of Inconvenience


Grails seems to be going from strength to strength, and it looks like it definitely “has legs”, as they say. I am quite interested in stretching those legs a little outside the web application arena. If you are aware of my work on Spring Batch, you will probably be able to guess where that might take me. But for this article I wanted to just share some experiences I’ve had with the basic, low-level deployment and build of a Grails application.

I have a love/hate relationship with Maven 2, and I am learning to love Grails, but sadly the two do not play particularly well together. It would be really nice to see tighter integration. Maven is not always everything we want it to be, but there are some things that really make it worthwhile. It is a standard of sorts (love it or hate it) so when I download a project from somewhere I already know how to build it, what its dependencies are and where the documentation is. Grails has some of the same features, and in fact includes its own quite sophisticated build tool based on Groovy scripting of Ant. Maybe there is a middle way, where we can have the best of both worlds?


Setter injection versus constructor injection and the use of @Required

A couple of month ago, we start publishing polls on asking people to provide their feedback about Spring, some of its features and how they are using those features. The first question I posted was whether or not people were checking required dependencies and if so, what mechanisms they used. I quickly followed up on this question asking the community what transaction management strategy it used.

To my delight when I first checked the results, back in March, a lot of people told us by voting in the first poll that they were using the @Required annotation. The second poll–on transaction management, quickly showed that a lot of people were using the @Transactional annotation. Below you can find some of the results of the poll about checking required dependencies. Together with the poll on transaction management (about 30% of all respondents are using the @Transactional annotation to demarcate transaction boundaries) they consistently show that people are using Spring 2.0 a lot, which was very good news for us. Because upgrading an application that uses Spring 1.x to use Spring 2.0 shouldn’t be any issue, we really hoped people would not stick to Spring 1.x and in fact, people massively upgraded.


Java EE 6 Gets it Right

The Java EE 6 proposal (JSR 316) was published today. I believe that this will be the most important revision of the platform since it was released nearly 10 years ago, and that it should be welcomed by users of the technology. Interface21 is happy to be a supporter of this JSR, and I am looking forward to contributing to it.

Java EE (known as J2EE for most of its history) has played a valuable role in creating a market for Java middleware. However, over those 10 years, important issues have emerged with the platform, such as:


Is Open Source Dying? Case Not Proven

Michael Hickins recently published a piece on eWeek entitled Is Open Source Dying? The title drew me in, and no doubt plenty of other folk too. But the article doesn’t prove the case, although it contains some interesting points that merit discussion.

Most of the article concerns speculation about the experience of government with open source, and the motives of vendors such as IBM. I prefer to judge companies and individuals by their actions, rather than speculation about their motives, and there is plenty of evidence that IBM, for example, takes open source very seriously. There’s plenty of open source in WebSphere, for example.


So should you still use Spring's HibernateTemplate and/or JpaTemplate??

I was reading an article by Vigil Bose on TSS the other day and saw the usage of the HibernateDaoSupport class. Since this is no longer a recommended way of using Hibernate from Spring, I thought I might as well just blog about it another time.

With the advent of Spring 2.0, it has become possible to start using the Hibernate Session API directly again. The question is whether or not it is wise to abandon the use of the HibernateTemplate when working with Hibernate, or any other template-based approaches Spring features.


Code samples from SpringOne 'Beyond the obvious' talk

Last week at SpringOne, Alef and I gave a talk on dealing with complex applications using Spring. Complexity in this case was considered both at the structural and dynamic level. As for the structural part of the talk, I covered that one in my previous blog posting. The dynamic part explained some possible solutions to deal with differences between your deployment environments. (testing, acceptance, production, etc.)
A lot of people asked me if I could provide them with the source of the demonstrations I gave during the talk. I’ve attached the sources to this blog entry and will explain briefly how this all works. Hopefully the talk itself will eventually become available on later this year, so you can get some more background information on the topic.


The Power of Batch

In the last session of SpringOne yesterday, Dave Syer, Scott Wintermute, Lucas Ward and Wayne Lund all presented on Spring Batch. I didn’t actually attend (since I had an early cab ride), but I stuck my head in and was yet again astounded by the amount of interest.

Back at JavaOne we had an immense amount of interest in this solution as well, with plenty of visitors calling by the booth to quiz us about batch.

It’s all too easy in this world of Ajax and Rich Internet Applications to forget that a large number (a majority maybe?) of large scale enterprise applications are batch-oriented. Batch is like the dirty little secret that Java tries to hide from the world - but no more!