30
I’m new to Java, and I have that question. I searched several places on the internet and asked several friends JAVA programmers but none could explain to me clearly what the difference between the two.
What is the difference between Javabean and POJO?
26
POJO - Plain Old Java Object - is simply a name given to a "normal" object with nothing special. It has its fields, its methods, its builders, etc, but does not follow [necessarily] any pre-established pattern.
As the Java language evolved, automated tools were created to interface with its code declaratively and/or visually, without the need to write code manually. Often these tools required - to perform their function - that the classes involved were written in a very specific way, otherwise they would not be compatible with these tools.
One example is the Javabeans, which at the time I studied had the objective of facilitating the creation of graphical user interfaces (I don’t know what it is today, nor if this goal went forward - because I haven’t worked with Java for years). A Javabean needs both:
Follow a very strict convention, including a constructor with no parameters and methods to obtain and assign values to its fields ("getters and setters") with a naming and signature pattern (i.e. number and parameter types and return value);
Use an auxiliary class - Beandescriptor or something - to describe the structure of the class to the tools that work with Beans, if the above convention could not be used. (which "kills" much of the advantages of working with Beans)
Another format are the EJB - Enterprise Javabeans - in this case focused on a service-oriented architecture (SOA), if I’m not mistaken. And whenever a new tool appeared - for example, to do object-relational mapping - it was common to require a different, sometimes conflicting pattern.
Faced with this multiplicity of standards, and the problems that this entailed, it started to try to make the tools that handle code flexible enough to accept any format, regardless of pattern. In the absence of a proper name to describe this characteristic, the term POJO was coined, to express the idea that "for my tool to deal with your class does not need to have anything special, any simple object serves".
For this reason, say that any object is a POJO (for example, all Javabean is a POJO, but not all POJO is a Javabean) although technically correct does not mean much... On the other hand, to say that the X tool deals with Pojos talks a lot about the flexibility of this tool: because no matter what format your classes are in, it claims to be able to handle them. It is from this perspective that you should interpret the term "POJO", whenever you see it.
Excellent answer! I managed to understand. Thank you very much.
Exactly! Unfortunately there is a lot of confusion because the term bean is extremely overloaded on the Java platform. Even some frameworks have also appropriated the term. We have JSF with the Managed Beans, the Spring Beans and so on. Sometimes people use the term bean for everything, then the confusion only gets worse. For example, imagine explaining a scenario where a Managed bean calls a Enterprise java bean or spring bean, passing as argument a POJO annotated bean validation.
Yeah, these people want to pun around with everything... Java Bean, Ruby Gem, Python Egg...
@mgibsonbr had never understood Python Egg or Ruby Gem until now! Cocoa pod is also pun?
Browser other questions tagged java java-bean pojo
You are not signed in. Login or sign up in order to post.
Possible answer to the question about Beans and on pogo
– Caputo
@Caputo The Javabean part, I believe the linked question answers. But there seems to be no reference to POJO here at Sopt, so I think the question should be kept.
– mgibsonbr
@mgibsonbr I agree yes and even for there to be a relationship between them the question is valid. I only added the links because I had no time to answer and could help the OP while answers do not arise.
– Caputo