I have heard and read a lot about POJOS and wanted to know whether i am correct by saying
"POJO classes are those which do not extend any other class nor they implement any interface."
Is it true Or my understanding is insufficient?
No. POJO class can implement any interface, or implement no interface. It can extend any class (note any user-defined class extends some other class, probably java.lang.Object). The sense of the notion of POJO is that it has not to implement specific interface or extend specific class, as it was usual in early persistent libraries.
POJO classes encapsulate data. They model the real life entities that the application deals with. POJOs should never have business logic. The whole ideas of using POJOs is to decouple business logic from data
In that case POJO classes are merely place holders for data?If this is it then what are the benefits of using POJOS anywhere else?
What i mean to say is do POJOs have other uses as well?
The above two posts seem contradictory
If a pojo implements an interface,doesn't that mean it contains business logic of some kind?
The abbreviation POJO means "Plain Old Java Object". It's just a Java class without anything special.
Where this comes from has to do with the history of Java EE.
In older versions of Java EE it was quite complicated to create an Entity Bean (one of the kinds of EJBs) - you had to make a class that extends javax.ejb.EntityBean, which had to implement a number of special methods such as ejbCreate, ejbRemove, ejbLoad, ejbStore etc.
Some people thought this was way too complicated and so they started working on their own alternative frameworks, notably the Spring Framework and Hibernate, to make things easier. One of the main points of these frameworks is that to use them, you don't need to extend special superclasses or interfaces or implement special methods like you had to when you were writing old-style EJBs. Instead, you could just write "POJOs" (Plain Old Java Objects) - just simple classes that don't have to be tied to the framework very tightly. Look, for example, at how Hibernate and JPA work nowadays - your entity classes don't need to extend any special classes or interfaces or implement any special methods; you use annotations such as @Entity instead.
So the name "POJO" was invented to show the difference between old-style EJBs and simple Java classes.
Technically, POJOs as a concept are as old as programming. At the very core, a POJO is nothing but a composite type. It's a programmer defined data type created by combining primitive data types and other composite data types. COBOL had it since it was invented. Pascal always had it. C has Struct.
It's when OOP started out, people started putting business logic together with composite types, which in some cases made things less flexible. That's when POJOs were "invented". Probably by some old fogey shaking his fists at EJBs thinking that things were so much simpler in COBOL.
POJOs are called by many many names. DTOs, Value objects, composite data types. They are all the same thing
Here A is simple object which is independent. B is a Special obj since B is extending/implementing C. So B object gets some more meaning from C and B is restrictive to follow the rules from C. and B is tightly coupled with distributed framework. Hence B object is not POJO from its definition.
Code using class A object reference does not have to know anything about the type of it, and It can be used with many frameworks.
So a POJO should not have to 1) extend prespecified classes and 2) Implement prespecified interfaces.
JavaBean is a example of POJO that is serializable, has a no-argument constructor, and allows access to properties using getter and setter methods that follow a simple naming convention.
POJO purely focuses on business logic and has no dependencies on (enterprise) frameworks. It means it has the code for business logic but how this instance is created, Which service(EJB..) this object belongs to and what are its special characteristics( Stateful/Stateless) it has will be decided by the frameworks by using external xml file.
Example 1: JAXB is the service to represent java object as XML; These java objects are simple and come up with default constructor getters and setters.
Example 2: Hibernate where simple java class will be used to represent a Table. columns will be its instances.
Example 3: REST services. In REST services we will have Service Layer and Dao Layer to perform some operations over DB. So Dao will have vendor specific queries and operations. Service Layer will be responsible to call Which DAO layer to perform DB operations. Create or Update API(methods) of DAO will be take POJOs as arguments, and update that POJOs and insert/update in to DB. These POJOs (Java class) will have only states(instance variables) of each column and its getters and setters.
In practice, some people find annotations elegant, while they see XML as verbose, ugly and hard to maintain, yet others find annotations pollute the POJO model. Thus, as an alternative to XML, many frameworks (e.g. Spring, EJB and JPA) allow annotations to be used instead or in addition to XML:
Advantages: Decoupling the application code from the infrastructure frameworks is one of the many benefits of using POJOs. Using POJOs future proofs your application's business logic by decoupling it from volatile, constantly evolving infrastructure frameworks. Upgrading to a new version or switching to a different framework becomes easier and less risky. POJOs also make testing easier, which simplifies and accelerates development. Your business logic will be clearer and simpler because it won't be tangled with the infrastructure code