Introduction to Java Data Objects (JDO)
Developer.com content and product recommendations are editorially independent. We may make money when you click on links to our partners. Learn More.
Java Data Objects (JDO) is a specification developed to enable transparent persistence of Java objects. It is a high-level API that allows applications to store Java objects in a transactional data store by following defined standards. Examples of traditional data stores are databases and files. This API can be used to access data on platforms such as desktops, servers, and embedded systems. JDO implementations can also be made to support cell phone, PDA, and other wireless technologies. In addition, JDO provides a means for treating data stored in a relational database as Java objects. JDO provides a standard means to define transactional semantics associated with these objects.
JDO was created under the direction of the Java Community Process and is documented as Java Specification Request 12 (JSAR 12). A group of experts from various companies were led by Craig Russell of Sun Microsystems and developed this specification. This began in 1999 and the final version (version 1.0) was released on April 30, 2002. Like many other Java technologies, Sun Microsystems has released a specification and a reference implementation. In addition, vendors are creating products to be compatible with JDO. Table 1 lists some of these vendors.
| Table 1: JDO Vendors | ||
|---|---|---|
| Company | Product | Web Site Address |
| SolarMetric | Kodo JDO Enterprise Edition, Kodo JDO Standard Edition | www.solarmetric.com |
| Poet Software Corporation | FastObjects | www.fastobjects.com |
| LiBeLIS | LiDO | www.libelis.com |
| Hemisphere Technologies | JDO Genie | www.hemtech.co.za/jdo |
| ObjectFrontier Inc. | FrontierSuite for JDO | www.objectfrontier.com |
| Versant | Versant enJin | www.versant.com |
| Sun Microsystems, Inc. | Reference Implementation | www.java.sun.com |
| Object Industries GmbH | JRelay | www.objectindustries.com |
JDO is also designed to easily be plugged into application servers. This allows JDO to accomplish many of the same functions provided by CMP entity EJBs. That is the ability to separate the JDBC and SQL code necessary to access the data stores from the objects that the program works with.
In this article, we will provide you with an overview of JDO and what it is used for. We will compare it to existing technologies and explain its role. We will discuss some of the reasons why JDO has been slow to be adopted into widespread mainstream use. We will also explain some of the exciting features that JDO offers which may allow it to enter widespread use.
Most new technologies are introduced to solve a specific problem. We will begin by explaining the problem that JDO seeks to solve.
The Problem
In object-oriented programming, when utilizing Java, data is transient, meaning that it usually only resides in memory and will be destroyed when the application ends. In developing many applications, this is a problem because a requirement or goal is for the data to remain persistent—meaning continuing to exist outside of the (single) application instance. Traditional data stores such as databases, files systems, and so forth are generally used for persisting data. In relational databases, data is stored in tables containing columns. Relationships are created between these tables. In Java, an object-oriented language, data is manipulated as objects. Clearly defined relationships between Java objects and database structures do not exist. As a result, programmers must create relationships between objects being utilized in their applications and the data stores the data actually resides in. Examples of existing options for persisting data include JDBC, SQLJ, EJBs, and java.util.Serializable.
Introduction to JDO
JDO allows developers to persist Java objects into traditional data stores. It supports transactions, queries, and the management of an object cache. JDO provides for transparent persistence for Java objects with an API that is independent of the underlying data store. JDO allows you to very easily store regular Java classes. JDOQL is used to query the database, which uses a Java-like syntax that can quickly be adopted by those familiar with Java. Together these features improve developer productivity. An added benefit is code portability across data stores and JDO implementations. To see an example of how JDO allows you to process data in terms of objects, consider the following example.
We will create a very simple student database. This database will contain the name, address, and department for each student. The actual class that you will use with JDO is simply a regular Java class that contains all of the attributes that you would like to store or the student. This class would look something like this:
public class Student < private String name; private String address; private String studentID; private String department; public Student(String name, String address, String studentID, String department) < this.name = name; this.address = address; this.studentID = studentID; this.department = department; >public String getName() < return name; >public String getAddress() < return address; >public String getStudentID() < return studentID; >public String getDepartment() < return department; >public void setName(String name) < this.name = name; >public void setAddress(String address) < this.address = address; >public void setStudentID(String studentID) < this.studentID = studentID; >public void setDepartment(String department) < this.department = department; >>
This object could be queried by using a JDOQL filter. Such a filter might look something like this:
String filter = "name.startsWith(n)";
This query would look for every name that starts with the parameter n. The parameter n would be provided to the query before it ran. The syntax of JDOQL matches Java’s syntax fairly closely. You are able to use the Java string functions as part of your query.
JDO is a technology that may replace other existing technologies that accomplish similar tasks. The two most obvious technologies are entity EJBs and JDBC. We will now compare JDO to these technologies.
JDO versus EJB
Since the introduction of JDO, there has been speculation that JDO might replace entity beans. To understand this assertion, let’s first examine exactly what an entity bean really is. Entity beans fall into two categories: container-managed persistence, called CMP beans; and bean-managed persistence, called BMP beans. BMP entity beans contain code that can store the bean contents to a permanent data store. BMP beans tend to be independent, and do not form direct relationships with other BMP beans. It is not likely that BMP beans will be replaced by JDO, as a BMP bean makes direct use of JDBC. This violates the design principal of JDO shielding the user from JDBC coding.
CMP beans allow the container to manage persistence. The container is whatever Web or application server is executing the bean. In this model, the bean contains no actual serialization code, such as JDBC. The container handles all actual storage and retrieval. CMP beans can also form the typical many-to-many and one-to-many relationships with other CMP beans.
As you can see, the role of a CMP bean is very similar to that of JDO. Both JDO and CMP allow you to persist at an object level and not have to worry about the details of how the objects are actually stored. JDO and CMP will also handle all of the relationships between objects. But will JDO actually replace CMP?
First, you must look at the actual growth of CMP. CMP entity beans have yet to gain widespread support. Most of the EJB growth has been in the area of session and stateless EJBs. CMP seems to suffer from some of the same issues as JDO when it comes to widespread acceptance. This is that both CMP and JDO separate the programmer too far from what is actually happening at a SQL level. For complex queries, a CMP or JDO programmer may spend much time trying to figure out how the SQL query is being generated. Many programmers would rather have just programmed SQL in the first place.
However, despite any shortcomings of CMP or JDO, JDO may make sense for programmers who have already made the jump to CMP. JDO does many of the same things as CMP, and likely makes sense as a CMP replacement if your project is using JDO overall. Like many debates in the IT industry, the debate of CMP or JDO will likely remain as long as there is CMP and JDO.
JDO versus JDBC/SQL
JDO does not really seek to replace JDBC in the same sense that it might CMP. JDO can really be thought of as a layer on top of JDBC—at least for the foreseeable future. In most instances of JDO, you specify a JDBC data source that references the database that JDO is going be accessing. So, the question of JDO versus JDBC is more a case of whether you should be using JDBC directly or allowing JDO to use it for you.
There is much praise and criticism for JDO replacing JDBC. On one hand, JDO frees the programmer from having to construct SQL statements and retrieve result sets into individual data objects. If you consider that most JDBC queries are executed to populate Java objects, JDO makes a great deal of sense. Rather than executing queries and copying fields from your JDBC result sets into Java objects, this is all taken care of by JDO.
The criticism comes in the amount of overhead that JDO creates to do this. JDO must take a JDOQL query string and convert it into the correct SQL statement. Then, this SQL statement is submitted to the database, the results are retrieved, and then are stored into their respective objects. If there is a large number of relationships among the objects, it is very easy to cause JDO to access considerably more data than you needed. The performance argument will likely never be solved. JDBC is always going to be faster than JDO because it is more direct. It is up to you to decide whether the flexibility of JDO is worth the performance hit.
Another feature of JDO that receives much criticism and praise is the possibility of JDO replacing SQL. When using JDBC, you must use SQL to construct your queries. JDO uses JDOQL. JDOQL is based more upon Java than SQL. On one hand, JDOQL can be much easier to construct than SQL, especially for simple queries. On the other hand, you are not likely to find many programmers who currently know JDOQL. Because JDO does not seem to have caught on industry-wide at this point, this problem may continue for some time. Most programmers are already familiar with SQL and senior-level IT programmers are capable of producing complex, highly optimized, SQL queries. For many such programmers, a middle-level tool such as JDO that automatically creates queries, is an unwelcome step. Furthermore, SQL is a cross-platform, all-encompassing query language. JDOQL is locked into the world of Java. Ultimately, SQL may be replaced, but it seems more likely that the widespread replacement of SQL would be at the hand of a less vendor-specific technology.
Conclusions
Like most new technologies, you will find many opinions that are both for and against JDO. You must cut through marketing hype and understand what it will do for your core development process. At this point, it is difficult to state the future of JDO. We see it as a very promising technology that has come far for a first version.
The following are Web sites that contain additional information about JDO:
| Java Community Process:JSAR12 | www.jcp.org/en/jsr/detail?id=12 |
| Java Community Process | www.jcp.org |
| JDO Central | www.JDOCentral.com |
| Sun Microsystems, Inc. | www.java.sun.com |
About the Authors
L. Oliver is a member of TDWI (Data Warehousing Institute) and PMI (Project
Management Institute). She has experience as an IT Director, Programmer,
Senior Systems Analyst, Project Manager, and a Data Architect/Data
Architect Lead. She has experience in the Financial Services Industry and
a strong background in relational database design. She is currently working
as a Data Architect on a Data Warehousing Project.