RSS Feed Subscribe to RSS Feed


JavaBeans vs Spring beans vs POJOs

The terms JavaBeans, “Spring beans” and POJOs are in widespread use and this article discusses each and the differences between them.


At a basic level, JavaBeans are simply Java classes which adhere to certain coding conventions. For example, classes that

  1. Have a public default (no argument) constructor
  2. allows access to properties using accessor (getter and setter) methods
  3. Implement

More accurately, JavaBeans are classes that adhere to Sun’s JavaBeans spec, first published way back in 1996. A JavaBean was defined as a “software component model” for Java. The idea was that JavaBeans would be reusable software components that could be manipulated visually in a builder tool and that vendors would create and sell JavaBeans that could be composed together into applications by end users. The three most important features of a Java Bean are

  1. the set of properties (named attributes) it exposes
  2. the set of methods it allows other components to call
  3. the set of events it fires (to notify registered listeners of changes)


POJO is an acronym for Plain Old Java Object. The term was coined by Martin Fowler et. al., as a ‘fancy’ way to describe ordinary Java Objects that do not require a framework to use, nor need to be run in a application server environment. It is often used to distinguish simpler, lightweight Java objects from ‘heavyweight’ code like EJBs. The use of these kind of lightweight objects in programming is described in books such as “POJOs in Action” and advocated by frameworks like Spring.

Spring beans

A Spring bean is basically an object managed by Spring. More specifically, it is an object that is instantiated, configured and otherwise managed by a Spring Framework container. Spring beans are defined in a Spring configuration file (or, more recently, by using annotations), instantiated by the Spring container, and then injected into your application.

The reason Spring managed objects are referred to as beans is because in the very early versions, Spring was intended only for use with JavaBeans. That is no longer the case of course: Spring can manage just about any object, even if it doesn’t have JavaBean type characteristics such as default constructors or mutator methods (getters and setters). None the less, the term ‘Spring beans’ has stuck.

Can Spring beans be POJOs? Yes, and they usually are (although they don’t have to be – e.g. Spring can be used with ‘heavyweight’ Java objects, such as EJBs).
Can Spring beans be JavaBeans? As I have said, yes and again they often are but don’t have to be.


Although it have been well over 10 years since the JavaBeans spec was first published, it still carries weight and has influence the development of modern frameworks such as Spring. But while Java objects that have default constructor and use accessor methods for private fields may legitimately be called JavaBeans, the whole “reusable software component that can be manipulated visually in a builder tool” concept isn’t particularly popular anymore.

POJOs, however, are everywhere and the a backlash against the complexities for EJBs has resulted in widespread use of ‘lightweight’ Java programming.

Spring beans are objects created and managed by the Spring framework.

None of the 3 terms discussed are mutually exclusive. A Java object can be a JavaBean, a POJO and a Spring bean all at the same time.

Tags: , , ,

Spring talk canceled

With much reluctance, I have had to cancel my planned Spring presentation at Silicon Valley Code Camp this weekend. I have been knocked out with flu all week and I am still hoarse, so giving a one hour talk is, unfortunately, not an option.
It is a shame as there was a lot of interest in the talk but in this instance can’t be helped.

Tags: ,

CodeCamp 2009: An Introduction to Spring

As I posted about earlier, the Silicon Valley Code Camp 2009 is coming up and this year, I am planning on presenting a session on the Spring framework.

You can find my session details here: An Introduction to Spring.

Tags: ,

Spring and EJB 3 Integration

I attended another excellent SF JUG meeting earlier this month. It was a double billing with Talip Ozturk talking about Hazelcast, an opensource clustering and data distribution platform, and Reza Rehman speaking about EJB3 and Spring Integration.

Reza is the author of EJB3 in Action and an accomplished speaker whom I had the chance to meet at The Server Side Symposium earlier this year, so I was particularly interested in his talk.

Reza gave some background on EJBs and how they have been completely reinvented as part of the latest (EJB3) release, including using 100% annotations (no xml) and making heavy use intelligent defaulting. He also talked about how Spring became popular as an alternative to the heavyweigth approach of the older EJB releases and has thrived through its focus on integration with standards like JPA, JMS, JDBC and JAX-WS.

He then went on to his main point, which was that EJB3 and Spring can now be viewed as complimentary, rather than competing, technologies and he went on to back this up by discussing the integration strategies that can be used, including

  • Embedding Spring inside a Java EE app server
  • Embedding an EJB3 embeddable container withing Tomcat with Spring
  • Enabling Spring @Autowired annotation in EJBs via Interceptors
  • Using EJB3 natively inside Spring using Spring Pitchfork

Reza finished by reiterating the benefits of using Spring and EJBs together to increase ease of coding and vendor neutrality.

Overall, I thought it was an insightful presentation from Reza. I had studied EJBs back in the v2 release as part of the my SCEA certification, and have used Spring in several projects, but this was the first time I had a chance to hear how they can be used together.

I have made Reza’s presentation notes available here, as well as his demo source code available here. You can also follow him on his web site and blog at:

Tags: , ,

TheServerSide Java Symposium – Day 2

Day 2 at TSS Java Symposium.

The highlights of the second day at TSSJS2009 were a couple of interesting talks from Rod Johnson (Mr Spring) and a talk on Groovy from Scott Davis (

I have included links to some of my (limited) notes below, which includes links to the actual presentation slides (PDFs) where available.

Keynote: How Spring Fits into the Java Landscape – Rod Johnson

Spring for the advanced developer – Rod Johnson

The Amazing Grrovy Weight Loss Plan – Scott Davis

Tags: , , ,

TheServerSide Java Symposium – Day 1

Today I’m at the first day of the TheServerSide Java Symposium in Las Vegas. There are about 400 attendees and a dozen or so companies exhibiting. I will try to post some notes about the talks as the day goes on…

Tags: , , , ,

Workflow Management: JBoss’s JBPM

The project I’m currently working on had a requirement for a workflow engine to manage the various process flow options for an order management system. For example, an order can be created, modified, submitted etc and we need to be able to persist and retrieve the process at any stage as we wait for human involvement to move to the next stage. I have been evaluating JBoss’s JBPM. It seems to meet our requirements but has been very difficult to get up and running. Overall it has been a frustrating process so far. The main JBoss JBPM site is at here and theServerSide has a good article on using it with Spring/Hibernate integration.

Tags: , , , , , , ,

Spring talk from Rod Johnson

I attended a talk on Spring on Monday, given by the creator himself, Rod Johnson. He focused mainly on the new annotations features of Spring 2.5 which was interesting, but it was also good to hear an example of how Open Source Software funds itself. Basically SpringSource (of which Rod is CEO) as a company do the vast majority of the code contributions to Spring (and apparently to Tomcat as well), but get their revenue from things like their Enterprise level pay-for offerings such as their SpringSource Enterprise as well as support and training.

The talk was at the Google offices in Mountain View and co-hosted by the San Francisco Java User Group.