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.

JavaBeans

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 java.io.Serializable

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

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.

Summary

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: JavaBeans, POJO, spring, Sun

Details of the new Sun Java Programmer Plus Certification

I posted previously about the new Sun certification exam announced at Java One, but there weren’t many details at the time. However, I found this blog post which points to Sun’s web site where they announce and give details of the new Sun Java Programmer Plus Certification. Apparently is will launch on July 22. No word on when the old SCJP will be retired, but I suspect it will be soon. Sun say that they will “provide a public notification of at least 90 days in advance of any exam retirement”.

Tags: Certification, Oracle, Sun

Is Sun’s Java Certification Model changing?

Although I was unfortunately unable to attend Java One last month, I did spot this post on TheServerSide about how Sun announced the Java Certification process may be changing from a rote memorization approach to a more hands-on coding approach.

As someone who has taken the SCJP and SCEA exams, and blogged about it’s pros and cons, I am interested to hear about any changes or improvements.

Unfortunately the only info on the web I can find is this blog posting linked to from the article. There doesn’t seem to be anything posted on the certification part of Sun’s web site. If anyone has any information of the new format, I’d love to hear it!

Tags: Certification, Sun

JavaFX Plugin for Eclipse – too buggy?

After attending a meetup on JavaFX last month, I have been trying to get more familiar with the technology. I know that NetBeans is the ‘recommended‘ IDE for JavaFX, but I am an Eclipse devotee and thought that surely anything NetBeans can do Eclipse can do. Not in this case it seems.

Some simple JavaFX script just don’t seem to work with the Eclipse plugin. For example, the following snippet:

Stage {
    title: "Nodes"
    scene: Scene {
        fill: Color.LIGHTBLUE
        width: 220
        height: 170
    }
}

Causes the following error:

incompatible types found: integer required: com.sun.javafx.runtime.location.FloatVariable

The same snippet compiled and ran straight off when I tried it before in NetBeans.

The only posting on it I could find is here. I took the advice and downgraded to JavaFX 1.0, which seems to have done the trick for now. If anyone out there has any suggestions on better solutions/fixes, I would love to hear them.

This isn’t the first time I’ve spotted some better GUI related functionality in NetBeans than in Eclipse (e.g. I briefly mentioned the NetBeans GUI Builder tool a while ago). There is no chance of me stopping using Eclipse completely, but maybe I will start using both…

Tags: eclipse, ide, JavaFX, netbeans, Sun

JavaFX Meetup

I attended another one of the excellent San Francisco JUG meetings tonight. This time the topic was Java FX and WidgetFX. Java FX is Sun’s new platform for delivering Rich Internet Applications (RIAs), competing in the same space as Adobe’s Flex and Microsoft’s Silverlight.

It is a fairly new technology with the first 1.0 release of the Desktop platform just happening last December. The Sun web site seems to show the Mobile platform as being available now too. Wen Huang from Sun talked about the planned 1.1 release, but was strangely coy when asked about the ‘TV platform’ that is also planned. He mentioned a tie in with Sony and Bluray so I guess we an expect more details on that in the near future.

Wen explained that JavaFX is built on top of Java, in that it runs on top of the Java Plugin and hence it can access to all the usual Java libraries.

Doris Chen, a Staff engineer and technology evangelist at Sun, then took over the presentation and got a little more technical. She quickly walked us through a couple of demos involving animation and videos in the form of puzzle games. It did look pretty cool. She also demonstrated how Java FX apps could be dragged out of the browser and continue to run independently, even when the browser was then closed. This is possible due to each widget running in its own Java VM, independent of the browser. I did notice those annoying Certificate security warnings popping up during the demo startup though which made me wonder… Would using JavaFX be as seamless for the end user as Flash, or would there be security, download, startup and plugin compatibility issues that applet usage sometimes involved?

Next up, Stephen Chin took over. Stephen is the co-author of a soon to be published book called Pro JavaFX book. He is also closely involved with two open source JavaFX libraries, JFXtras and WidgetFX. He walked us through a couple of code examples. The things that jumped out at me most about JavaFX were

• the declarative construct used for creating objects, which I am not too familiar with (similar to the Scala approach maybe?)
• extensive use of a ‘bind’ operator which seems to ensure that variable value changes get reflected in the UI
• JavaFX doesn’t seem to throw many exceptions, instead it tries to handle them as gracefully as possible
• It is a Functional language: Functions are first class entities that can be assigned to variables, passed in and returned from functions

The class finished with Stephen walking us through some hands on examples, using NetBeans (Update: see my comment at the end of this article on the JavaFX Eclipse plugin) and both WidgetFX and JFXtras.

Overall, I thought the presentations were very good and provided a great overview, and some of the details, of JavaFX. For me personally though, none of the projects I am currently working on have a requirement for ‘rich’, multimedia type content, but it would be nice to create a few more mundane desktop type JavaFX GUIs to see how it fares compared to the Swing GUIs I have created in the past.

I do have some concerns about how to integrate JavaFX GUIs with the web tier and backend. Doris Chen tonight mentioned JSON integration, but there were less details on how JavaFX would integrate with model-2 MVC libraries like Spring MVC or Struts. I will definitely watch the JavaFX space closely to see how widely accepted it becomes, but I am also interested in learning more about other Java GUI technologies that I haven’t had too much exposure to yet, such as JSF and Facelets. Perhaps in another JUG meetup soon…

Tags: JavaFX, netbeans, RIAs, Sun