A Java® object (instance) is a software component comprising data and functionality (methods) to manipulate the data in a Java® programming environment. It usually has a public default constructor and supports the setting and/or retrieving of all or a part of its data using so-called setter and getter methods, which are often named as: getXXX( ), setXXX( ) or is XXX( ), where XXX identifies the name of a part of its data. A Java® object may also be extended to include metadata, event, and other suitable contents to support application-oriented components, such as Enterprise Java® Bean, Applet, etc. A Plain Old Java® Object (POJO) is a generic kind of Java® object which, besides generic data operations such as setters and getters, does not use nor support the kinds of application-oriented elements described above. More specifically, it does not implement any lifecycle or events, it does not provide any kind of metadata.
The retrieval of data from a database to POJOs presents a set of problems. Here, the database can be a relational database, an object-oriented database, a DB2, an Informix Database, an Oracle Database, a SQL Server, a Sybase Database, a Point Base, and a SQL Server2000, and other suitable database. Many current approaches utilize a high-level query language, such as EJB-QL, which allows queries to be specified against a POJO class without requiring any knowledge of the underlying types of the databases. Such query languages, however, are often not as expressive as SQL, which deters users from using them to begin with. In addition, learning more than one query language and using them efficiently often proves to be difficult for many users.
The persistence of POJOs to a database presents a different set of problems. Due to its generic nature, it is difficult for a POJO to support persistence, i.e., the transfer (map) of data, to an underlying database. Current approaches try to solve this problem by inserting additional methods into the class (type) of POJO, modifying the functionalities of the existing methods in the class, or associating one or more additional descriptive files to specify how the persistence between the POJO and the database should proceed. Such approaches may suffer from several drawbacks:                They are “intrusive”. Since additional methods are introduced and/or the existing methods are modified, the behavior of the POJO may be altered unintentionally.        They are hard to maintain. Organizing and keeping track of all the additional changes and files and making them consistent throughout the process without affecting the normal operation of the POJO can be very difficult and requires a lot of efforts from the users.        They are difficult to use. The additional method changes and files will put a heavy burden on the users, making the persistence of POJO a non-trivial and time consuming task.        
USPTO Backgrounds
USPTO Backgrounds