I'm not sure about the difference. I'm using Hibernate and, in some books, they use JavaBean and POJO as an interchangeable term. I want to know if there is a difference, not just in the Hibernate context, but as general concepts.
222
votes
9 Answers
266
votes
A JavaBean follows certain conventions. Getter/setter naming, having a public default constructor, being serialisable etc. See JavaBeans Conventions for more details.
A POJO (plain-old-Java-object) isn't rigorously defined. It's a Java object that doesn't have a requirement to implement a particular interface or derive from a particular base class, or make use of particular annotations in order to be compatible with a given framework, and can be any arbitrary (often relatively simple) Java object.
113
votes
All JavaBeans are POJOs but not all POJOs are JavaBeans.
A JavaBean is a Java object that satisfies certain programming conventions:
- the JavaBean class must implement either Serializable or Externalizable;
- the JavaBean class must have a public no-arg constructor;
- all JavaBean properties must have public setter and getter methods (as appropriate);
- all JavaBean instance variables should be private.
26
votes
According to Martin Fowler a POJO is an object which encapsulates Business Logic while a Bean (except for the definition already stated in other answers) is little more than a container for holding data and the operations available on the object merely set and get data.
The term was coined while Rebecca Parsons, Josh MacKenzie and I were preparing for a talk at a conference in September 2000. In the talk we were pointing out the many benefits of encoding business logic into regular java objects rather than using Entity Beans. We wondered why people were so against using regular objects in their systems and concluded that it was because simple objects lacked a fancy name. So we gave them one, and it's caught on very nicely.
9
votes
Pojo - Plain old java object
pojo class is an ordinary class without any specialties,class totally loosely coupled from technology/framework.the class does not implements from technology/framework and does not extends from technology/framework api that class is called pojo class.
pojo class can implements interfaces and extend classes but the super class or interface should not be an technology/framework.
Examples :
1.
class ABC{
----
}
ABC class not implementing or extending from technology/framework that's why this is pojo class.
2.
class ABC extends HttpServlet{
---
}
ABC class extending from servlet technology api that's why this is not a pojo class.
3.
class ABC implements java.rmi.Remote{
----
}
ABC class implements from rmi api that's why this is not a pojo class.
4.
class ABC implements java.io.Serializable{
---
}
this interface is part of java language not a part of technology/framework.so this is pojo class.
5.
class ABC extends Thread{
--
}
here thread is also class of java language so this is also a pojo class.
6.
class ABC extends Test{
--
}
if Test class extends or implements from technologies/framework then ABC is also not a pojo class because it inherits the properties of Test class. if Test class is not a pojo class then ABC class also not a pojo class.
7.
now this point is an exceptional case
@Entity
class ABC{
--
}
@Entity is an annotation given by hibernate api or jpa api but still we can call this class as pojo class.
class with annotations given from technology/framework is called pojo class by this exceptional case.
7
votes
POJO: If the class can be executed with underlying JDK,without any other external third party libraries support then its called POJO
JavaBean: If class only contains attributes with accessors(setters and getters) those are called javabeans.Java beans generally will not contain any bussiness logic rather those are used for holding some data in it.
All Javabeans are POJOs but all POJO are not Javabeans
2
votes
In summary: similarities and differences are:
java beans: Pojo:
-must extends serializable -no need to extends or implement.
or externalizable.
-must have public class . - must have public class
-must have private instance variables. -can have any access specifier variables.
-must have public setter and getter method. - may or may not have setter or getter method.
-must have no-arg constructor. - can have constructor with agruments.
All JAVA Beans are POJO but not all POJOs are JAVA Beans.
1
votes
1
votes
You've seen the formal definitions above, for all they are worth.
But don't get too hung up on definitions. Let's just look more at the sense of things here.
JavaBeans are used in Enterprise Java applications, where users frequently access data and/or application code remotely, i.e. from a server (via web or private network) via a network. The data involved must therefore be streamed in serial format into or out of the users' computers - hence the need for Java EE objects to implement the interface Serializable. This much of a JavaBean's nature is no different to Java SE application objects whose data is read in from, or written out to, a file system. Using Java classes reliably over a network from a range of user machine/OS combinations also demands the adoption of conventions for their handling. Hence the requirement for implementing these classes as public, with private attributes, a no-argument constructor and standardised getters and setters.
Java EE applications will also use classes other than those that were implemented as JavaBeans. These could be used in processing input data or organizing output data but will not be used for objects transferred over a network. Hence the above considerations need not be applied to them bar that the be valid as Java objects. These latter classes are referred to as POJOs - Plain Old Java Objects.
All in all, you could see Java Beans as just Java objects adapted for use over a network.
There's an awful lot of hype - and no small amount of humbug - in the software world since 1995.
