Yesterday GigaSpaces announced the latest release of their Space-Based Architecture, and it's got a new name to go with it too: the GigaSpaces eXtreme Application Platform (XAP). To quote from their press release:

The new release provides a complete middleware platform for managing data, messaging and business logic for applications that require high performance and the ability to scale horizontally across hundreds of machines.

The part of the announcement that caught my eye though was this:

As part of the new product release, GigaSpaces has embraced a much simpler, non-intrusive programming model that allows developers to write their applications in Plain Old Java Objects (POJOs), plain .Net and plain C++ objects. For Java, GigaSpaces is achieving this by supporting the Spring Framework, which is rapidly becoming the de-facto standard in Enterprise Java programming.

It's great to see this kind of recognition, the only slight change I'd make to the statement is to drop the "rapidly becoming" part: the Spring Framework is the de-facto standard in Enterprise Java Programming.

Announcements like this are part of a virtuous circle (described for example by Geoffrey Moore in his book "The Gorilla Game") whereby the pervasiveness of the Spring Framework makes it very compelling for vendors to provide Spring Framework integration in their products, which in turn increases the overall value of Spring. This of course helps to make Spring even more pervasive…

The production of nonsense on open source is a highly competitive field. However, I've just come across something that raises (lowers?) the bar: a post by an OpenLogic blogger entitled What's your time worth?

It's not a long piece, which is handy, as it makes it easier to deconstruct paragraph by paragraph. I'm focusing on enterprise Java, about which I can speak from experience.

The blogger gets to the point right away with a concise statement of why she doesn't understand open source in the enterprise:

Developers that work on open source software typically have day jobs that pay pretty well. So they work on open source software for free and write code during the day for big bucks.

Wow, I thought we'd got beyond this "hobbyist" idea years ago. Let me quote some statistics about Linux, from a 2004 article called Linux is now a Corporate Beast. The emphasis is mine:

Dispelling the perception that Linux is cobbled together by a large cadre of lone hackers working in isolation, the individual in charge of managing the Linux kernel said that most Linux improvements now come from corporations. "People's stereotype [of the typical Linux developer] is of a male computer geek working in his basement writing code in his spare time, purely for the love of his craft. Such people were a significant force up until about five years ago,” said Andrew Morton, whose role is maintaining the Linux kernel in its stable form. Morton said contributions from such enthusiasts, "is waning." Instead, most code is generated by programmers punching the corporate time clock. About 1,000 developers contribute changes to Linux on a regular basis, Morton said. Of those 1,000 developers, about 100 are paid to work on Linux by their employers. And those 100 have contributed about 37,000 of the last 38,000 changes made to the operating system.

That's 97% of commits coming from people paid to work on Linux. And that transformation has corresponded with the increasing penetration of Linux in the enterprise. Looking at the most successful complex projects in enterprise Java, such as Spring, Hibernate and JBoss, shows a similar picture. All of these are overwhelmingly written by developers who work for the companies behind them. Volunteerism plays little part. As a result, those products have exhibited rapid progress.

The post now moves onto economics--or, to be precise, an attempt to argue that the…

I was working on Spring 2.1 stuff this week with Joris. We were preparing a sample using all three ways of doing dependency injection. The sample does not only highlight dependency injection, but also features a back-end based on Hibernate.

Several features in Spring 2.1 require the ASM byte code manipulation framework. Hibernate also uses ASM, through CGLIB. There is a binary incompatibility between ASM 1.5.3 and 2.2.3. The former is used by Hibernate, the latter is used by Spring in various scenarios; specifically in some of the AOP functionality and the new @Autowired features.

UPDATE: read…

Last month I gave a Core Spring training in Turkey. At the end of the course I discussed the architecture for an application that some of the participants were going to build after completing the course. This application would consist of an ear file with several war files inside, and the question came up if it was possible to define a single ApplicationContext that could be used as a shared parent to the WebApplicationContexts of all war files. This context would hold bean definitions for services, DAOs and other beans that were not specific to a single web module.

Actually, Spring makes it…

You may have heard the announcement that Interface21, the company behind Spring, recently raised $10m dollars. Given that we've been around for almost 3 years, and have achieved a lot to date, you might wonder why.

Why did we raise money and what are we going to do with it?

Over the last two years, we've built a great team. Juergen Hoeller, Adrian Colyer, Keith Donald, Colin Sampaleanu, Mark Pollack, Ben Alex, Rob Harrop… It's scary to to start typing that list because I know that I can't include all the talented technologists in this company, and I don't want to imply any ordering of merit…

Doing it again It’s already over 2 years since the idea to launch a European conference dedicated to the ever-growing Spring community was first discussed. After having announced the first (2006) edition of SpringOne at JavaPolis 2005, over 400 people signed up for the conference – over 20% more than we anticipated. SpringOne 2006 was a great success.

Due to the piles of positive feedback we have received after the 2006 edition, with many attendees reacting very positively to the strong focus on Spring and enterprise Java, we decided about 7 months ago to organize a 2007 edition. The…

As most of you already know by now, Spring is not just about XML as lately, a number of 'official' extensions to the core offer alternatives way for configuring the container.

Spring Java Configuration 1.0 M2 was among the products released around JavaOne and, while still marked as a milestone, had an important number of updates and bugfixes:

• the root package has changed to org.springframework.config.java

<li>scoped beans are fully supported</li>

<li>the bean name generation can be customized</li>

<li>the distribution contains a 'transformed' sample (petclinic) which uses XML, JavaConfig and Groovy.</li>

In fact, most of the work done for 1.0 M2 was incorporating the feedback received to the initial announcement…

During a training last week, for the first time, I used the first Release Candidate of Spring Web Services. It's hardly been two weeks since Arjen release RC1 of his precious, so it was very nice to show some of the attendees this new product.

Right before the web services part we did a little JMX and remoting, showing Spring's exporter functionality. As you might know, this allows you to export any Spring-managed bean to a remote endpoint or JMX registry, with just a very little amount of declarative configuration:

<bean id="myService" class="com.mycompany.MyServiceImpl">
    <property name…

With the release of Spring 2.1-m2, some significant changes have been made to the infrastructure of the Spring distribution. Please see the announcement and changelog for the complete list of changes.

Distribution

The distribution has been trimmed from 26 JARs in 2.1-m1 to 17 JARs in 2.1-m2. Take a look at the changelog for the list of files that changed, but from the commit message, here's what's new:

• spring-context.jar includes JMX support and core remoting support (no spring-jmx and spring-remoting jars anymore)
• spring-orm.jar combines all ORM support packages (replaces spring-hibernate, spring-ibatis, spring-jdo, spring-jpa, and spring-toplink jars)
• spring-web.jar contains web-related remoting and ORM classes (for proper use in J2EE EAR deployment structures)
• renamed spring-dao.jar to spring-tx.jar, also containing the JCA support now
• renamed spring-support.jar to spring-context-support.jar
• renamed spring-portlet.jar to spring-webmvc-portlet.jar
• module jar files contain module-specific "spring.handlers" and "spring.schemas" files now

Maven Artifacts

I'm also pleased to announce that starting with the 2.1-m2 release, each Spring module will now have source jars in the Maven repository. The 2.1-m2 Maven artifacts are located in a private snapshot repository at this point, but the final release will be in the main Maven repo. If you would like to start using 2.1-m2 in your Maven project add a repository location to your POM that points at https://springframework.svn.sourceforge.net/svnroot/springframework/repos/repo-snapshots/. If you are using any Maven IDE support, please also download the source jars and open any issues with them at our JIRA.