My first blog post - and what a big announcement to make :-)

After a series of Spring 2.1 milestone releases, we've been reviewing the overall set of features that we introduced:

• full Java 6 and Java EE 5 support (JDBC 4.0, JTA 1.1, JavaMail 1.4, JAX-WS 2.0, etc)
• full-featured annotation-driven dependency injection (including support for 'qualifier' annotations)
• support for component scanning in the classpath (autodetecting annotated classes)
• bean name pointcut element in AspectJ pointcut expressions
• built-in support for for AspectJ load-time weaving (based on Spring's LoadTimeWeaver abstraction)
• further XML configuration namespaces ("context", "jms") for maximum convenience
• extended SimpleJdbcTemplate functionality (support for named parameters etc)
• officially certified WebSphere support (support for the WebSphere 6 UOWManager facility etc)
• Spring framework jars are shipped as OSGi-compliant bundles out of the box
• Spring ApplicationContext can be deployed as JCA RAR file (for headless application modules)
• JCA 1.5 message endpoint management (for Spring-managed JMS and CCI message listeners)
• completely revised framework for integration tests (with support for JUnit 4 and TestNG)

as well as many refinements in the details. Almost all of those features are available in the recently released 2.1 M4 already.

We concluded that this goes significantly beyond what we originally planned for Spring 2.1. The version number 2.1, as used for the milestones, does not reflect the significance and the comprehensiveness of the features in this major release.

So I'm pleased to announce that the 2.1 milestones will seamlessly turn into Spring Framework 2.5 as the upcoming major release! Spring 2.5 is scheduled for final release in…

Interface21 got mentioned in testimony before Congress.

Jonathan Silver, a venture capitalist and founder of Core Capital Partners, testified on Thursday against proposed changes in tax rates applying to VCs. One of his arguments was that venture-based companies create jobs across the US:

Where will the next important businesses come from? The truth is, no one knows and that’s why venture capitalists look everywhere, and in all fifty states, for those opportunities. It’s why venture funds have backed Music Nation in New York City and Incept Biosystems in Ann Arbor, Michigan, Interface21 in West Melbourne, Florida, Boston Power in Westborough, Massachusetts and Click Forensics in San Antonio, Texas.

Actually, our headquarters are moving to San Mateo, California. Like many software vendors, we believe that Silicon Valley is the best place to achieve our potential. The largest concentration of our partners is here, and it's a great place to recruit executive talent in the software business. However, Silver's point is still valid. We are creating jobs in Florida--where our web team is based and is currently doing great things with Spring Web Flow…

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…

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.

In other words, proxies can be used as stand-ins for real objects to apply extra behavior to those objects--be it security-related behavior, caching or maybe performance measurements…

Introduction

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…

A couple of month ago, we start publishing polls on www.springframework.org 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…

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:

• The need for a Java EE compliant server to be bloated with a range of functionality that is of little interest to the vast majority of users
• The fact that enterprise requirements have changed since J2EE was envisaged and that a "one size fits all model" is less and less appropriate
• The fact that enterprise Java has been greatly strengthened by the emergence of frameworks (especially in open source) that make developers more productive and their production applications more efficient and maintainable
• New challenges such as Ruby on Rails, and even .NET, showing that, in a time of rapid change and innovation, a cosy 2-3 year release cycle imperils the entire platform

Java EE 6 is an important revision of the platform that has the…

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…

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.

Using Spring XxxTemplates

In Spring 1.0, we introduced a revolutionary way of working with data access APIs that threw checked exceptions. The template approach Spring features along with its transaction synchronization manager and the extensive use of runtime exceptions makes any TCFTC (short for try/catch-finally-try/catch as we coined it back in 2005) often found in data access code entirely obsolete. Below you can see (a simplified version and not entirely precise version of) what Spring's template approach does for you (with specific code snippets that you would otherwise have to write).

Acquisition of connection: If transaction synchronization is active…