• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Devaka Cooray
  • Liutauras Vilda
  • Jeanne Boyarsky
  • Bear Bibeault
Sheriffs:
  • Paul Clapham
  • Knute Snortum
  • Rob Spoor
Saloon Keepers:
  • Tim Moores
  • Ron McLeod
  • Piet Souris
  • Stephan van Hulst
  • Carey Brown
Bartenders:
  • Tim Holloway
  • Frits Walraven
  • Ganesh Patekar

What's a POJO?

 
Greenhorn
Posts: 2
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi,

Is POJO a generally accepted acronym/abbreviation for plain old Java object as opposed to Java enterprise edition objects/programming?
Or is it better to use JSE as Java standard edition?

Thanks

 
Rancher
Posts: 137
7
IntelliJ IDE Spring Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Jimmyy,

There are several versions of Java:
  • Java Standard Editions (SE)
  • Java Enterprise Edition (JEE)

  • A POJO is a simple java object (i.e. it doesn't extend another class, it does not implement an interface, it doesn't contain any annotations, etc). Basically, the simplest version of a java object.
     
    Saloon Keeper
    Posts: 10434
    223
    • Likes 1
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    Brecht, I fear that's not correct. A POJO is allowed to extend classes, implement interfaces and have annotations applied to it.

    We don't really use the term "POJO" to refer to a specific type of object. We use the term to denote that in a certain context or framework, there are no special requirements that the object has to fulfill in order to be used.

    So, while a class MAY implement an interface and still be a POJO, if it is REQUIRED to implement an interface in order for it to be used in a certain context, it can not be considered a POJO for that context.
     
    Brecht Geeraerts
    Rancher
    Posts: 137
    7
    IntelliJ IDE Spring Java
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    Thank you Stephan, it seems that my own understanding of what a POJO is was not entirely accurate. Your clarification helped a lot.
     
    Rancher
    Posts: 4190
    47
    • Likes 1
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator

    Stephan van Hulst wrote:
    So, while a class MAY implement an interface and still be a POJO, if it is REQUIRED to implement an interface in order for it to be used in a certain context, it can not be considered a POJO for that context.



    As an example, a Servlet.
    In order for it to function in its environment (on an app server) you need to extend HttpServlet.
    Hence they aren't POJOs.
     
    Bartender
    Posts: 20940
    127
    Android Eclipse IDE Tomcat Server Redhat Java Linux
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    Another version of Java is (was?) the Java Micro Edition, intended for small devices, but mostly obsolete now that even the smallest devices are powerful enough to run fairly complete Java implementations (or Dalvik, which is Java as implemented for Android). And if you want to feel really awed, I'm not sure that an early 1980's IBM mainframe could have run even Java Micro Edition (since they maxed out at 16MB of RAM).

    POJOs were developed as a concept fairly early in the life of Java, where it was thought that there would be things like POJO editors, but that didn't pan out.

    On the other hand, many platforms learned to embrace POJOs from hard experience. Both the Struts and Enterprise JavaBeans platforms were based on non-POJO objects. In order to use components on these platforms, you generally had to either extend a subclass, implement interfaces or both. As a result, it was virtually impossible to recycle and re-used those components on other platforms and for that matter to unit-test them outside their intended execution environment. Whereas a POJO can be tested via something like JUnit without any supporting infrastructure outside of the test code itself.

    Another thing that makes POJOs desirable is their ability to be wired together externally by frameworks such as Spring and JavaServer Faces (JSF).

    JavaServer Faces was designed as an alternative to Struts using POJOs. In the case of EJB, they didn't abandon the original architecture but they did extend it to allow for POJO entities, and as a result we got the Java Persistence Architecture (JPA), which can operate either as part of an EJB solution or completely outside of any EJB container - even in stand-alone Java apps.
     
    Brecht Geeraerts
    Rancher
    Posts: 137
    7
    IntelliJ IDE Spring Java
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    It is always nice to read about the history of such things. It is useful to know how things have evolved to what they are today.

    Tim Holloway wrote:... I'm not sure that an early 1980's IBM mainframe could have run even Java Micro Edition (since they maxed out at 16MB of RAM)...

     
    We definitely have come a long way.

    Thanks Tim. Very interesting stuff!
     
    Jimmyy Tom
    Greenhorn
    Posts: 2
    • Likes 1
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    Thank you very much for your clear answers!
     
    With a little knowledge, a cast iron skillet is non-stick and lasts a lifetime.
    • Post Reply Bookmark Topic Watch Topic
    • New Topic
    Boost this thread!