What is the difference between JavaBean and POJO?

28

I'm new to java and I have this doubt. I looked in various places on the internet and asked several JAVA programmers friends but none could clearly explain the difference between the two.

What's the difference between JavaBean and POJO?

    
asked by anonymous 26.06.2014 / 22:16

1 answer

23

Plain Old Java Object

- is simply a denomination given to a "normal" object, without anything special. It has its fields, methods, builders, etc., but does not necessarily follow any pre-set patterns.

As the Java language evolved, automated tools emerged to interface with your 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 those tools.

One example is JavaBeans, which at the time I studied were meant to make it easier to create graphical user interfaces (I do not know what it's like today, or if that goal went forward - I have not worked with Java for years) . A JavaBean needs both of these:

  • Follow a very rigid convention, including a parameterless constructor and methods to get and assign values to your fields ("getters and setters") with a naming and signature pattern (ie number and types of parameters and return value);

  • Use an auxiliary class - BeanDescriptor or something - to describe the class structure to the tools that work with Beans, if you could not use the above convention. (which "kills" a lot of the benefits of working with beans)

  • Another format is EJB - Enterprise JavaBeans - in this case focused on a Service Oriented Architecture (SOA) , if I'm not mistaken. And whenever a new tool came up - for example, to do object-relational mapping - it was common to require a different, sometimes conflicting, pattern.

    Faced with this multiplicity of patterns, and the problems that this entailed, we tried to make code-coding tools flexible enough to accept any format regardless of pattern. In the absence of a proper name to describe this characteristic, the term POJO was used to express the idea that "for my tool to deal with its class it does not need to have anything special, any simple object serves".

    For that reason, to say that any object is a POJO (for example, all JavaBean is a POJO, but not every POJO is a JavaBean) although technically correct does not mean a lot ... On the other hand, tool X deals with POJOs speaks 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.

        
    26.06.2014 / 22:45