[citation needed] The term continues an acronym pattern to coin retronyms for constructs that do not use fancy new features: Ideally speaking, a POJO is a Java object not bound by any restriction other than those forced by the Java Language Specification; i.e. a POJO should not have to However, due to technical difficulties and other reasons, many software products or frameworks described as POJO-compliant actually still require the use of prespecified annotations for features such as persistence to work properly.
A JavaBean is a 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.
The following shows an example of a JavaServer Faces (JSF) component having a bidirectional binding to a POJO's property: The definition of the POJO can be as follows: Because of the JavaBean naming conventions the single "someProperty" reference can be automatically translated to the "getSomeProperty()" (or "isSomeProperty()" if the property is of Boolean type) method for getting a value, and to the "setSomeProperty(String)" method for setting a value.
The addition of those tools help alleviate the boilerplate, which in turn reduces the bugs frequency and maintenance cost .
Aspect-oriented programming (AOP) frameworks then transparently add cross-cutting concerns like persistence, transactions, security, and so on.
Instead, the programmer declares in an external XML file which EJB services should be added to the bean: 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.