What is the difference between a JavaBean and a POJO?

Question

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.

Cuxhaven

JavaBean spec.: oracle.com/java/technologies/javase/javabeans-spec.html – Innovate

Answer 1

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.

Jefferson

Note that a JavaBean can be and usually is a POJO and many POJOs are actually JavaBeans. – Doctrinal

No, by the definition of POJO a Java Bean is not a POJO because to be considered a Java Bean a class must follow certain coding conventions (e.g. have a no-arg constructor, have methods that start with the words "get" and/or "set") or be distributed with a BeanInfo class. – Ecdysiast

Because these are conventions, I think you can successfully argue that a bean can be a POJO (e.g. you're not inheriting from a JavaBean interface or similar) – Jefferson

The JavaBeans spec fails to define a JavaBean other than very loosely as a "reusable software component" (or some such). It doesn't have to have a no-arg constructor, does not need methods starting with "get" or "set", does not need to be serialisable, doesn't even need to be a class. – Sair

In mathematical terms, we can say that Javabeans form a subset of POJO, because, specific constraints put on a POJO makes it a Javabean. – Playboy

The interface name is Serializable, not Serialisable. Not sure why half the edits on this post were changing between the two. – Kellar

I was indicating that you can serialise it, and not referring to the interface name (it would be capitalised if so) – Jefferson

The word is spelled "serializable" (that's why the interface is spelled that way). The alternate spelling with an 's' instead of a 'z' is not often used in these applications, and only convolutes beginners' understanding. – Dogmatic

@BrianAgnew Java bean implements serializable and POJO is a simple class that will not implement any interface. Is that mean? Java Bean is not a POJO. – Andres

Answer 2

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.

Kappenne

I thought POJOs can't implement Serializable. – Dram

"the JavaBean class must have a no-arg constructor;" also add public here – Busiek

A JavaBean is serializable and that is why a JavaBean is NOT a POJO. – Bosomed

Answer 3

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.

http://www.martinfowler.com/bliki/POJO.html

Merrymaking

Answer 4

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.

Homochromous

I'm wondering, they say that there is no business logic in our POJO classes, and they are exactly the same as our Entity classes, as you said. But most programmers add methods to do some CRUD operations in our Entity classes. Isn't that against the rule? – Schluter

This isn't 100% correct - the point of the term POJO means that you could load and run it on any JVM; there aren't any external dependencies. – Innovate

Answer 5

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

Bayonet

Answer 6

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.

Galeiform

Answer 7

Java beans are special type of POJOs.

Specialities listed below with reason

Wormwood

Answer 8

POJOS with certain conventions (getter/setter,public no-arg constructor ,private variables) and are in action(ex. being used for reading data by form) are JAVABEANS.

Panier

Answer 9

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.

Gemini

Answer 10

All Pojo(s) are JavaBean(s), but not the opposite.

---

What is POJO?

1. A POJO has no naming convention for properties or methods. We don't follow any real convention for constructing, accessing, modifying the class's state.

   Example:

    public class Pojo {
   
     public String firstname;
     public String LASTName;
   
     public String name() {
        return this.firstname + " " + this.LASTName;
     }
    }
   

   here, I could have replaced firstname by first_name or Firstname or by any noun and the same with the variable LASTName.

The term has most likely gained widespread acceptance because of the need for a common and easily understood term that contrasts with complicated object frameworks.[2]

---

Reflection using POJO.

it may limit a framework's ability to favor convention over configuration, understand how to use the class, and augment its functionality.[1]

  List<String> propertyNames =
                Arrays.stream(PropertyUtils.getPropertyDescriptors(Pojo.class))
                        .map(PropertyDescriptor::getDisplayName)
                        .collect(Collectors.toList());
        System.out.println(propertyNames);

If we use Third Party Libraries PropertyUtils for reflection we may face issues, as this will result in

[]

---

What is Java Beans?

A JavaBean is still a POJO but introduces a strict set of rules around how we implement it:

• Access levels – our properties are private and we expose getters and setters.
  
• Method names – our getters and setters follow the getX and setX convention (in the case of a boolean, isX can be used for a getter)
  
• Default Constructor – a no-argument constructor must be present so an instance can be created without providing arguments, for example during deserialization
  
• Serializable – implementing the Serializable interface allows us to store the state.

Example:

@Getter
@Setter
 class Pojo implements Serializable {
    public String firstName;
    public String lastName;
}

Reflection using Java Bean.

If we again use third party Libraries such as `PropertyUtils` for reflection the result will be different

[firstName,lastName]

Belk