Interview with Craig Russell on JPA 2.0
Craig Russell is a senior staff engineer at Sun Microsystems. He is specification lead for Java Data Objects (JSR 12 and 243) and leads the implementation team for its reference implementation and technology compatibility kit. In this interview we asked him about the new JPA 2.0 version, about persistence in general and the future of O/R mapping.
JAXenter: Craig, you’ve been the specification lead of JDO, both versions: 1.0 and 2.0. Now, JDO has become a part of the current JPA (Java Persistence API) Specification.
Craig Russell: Actually, there were a number of features that JDO influenced in the JPA specification that made it easier for users of JPA, including the ability to use Java Domain Objects in very complex environments, the standard use of enhancement technology, and the rejection of SQL Blob and Clob as modeling artifacts. Additionally, some features of JDO, such as collections of basic types, were not incorporated into the first version but are now becoming part of the second version of JPA.
JAXenter: What’s your main focus at work these days?
Craig Russell: I’m working in Java Object Persistence in the MySQL Cluster group at Sun. I’m working with a team to implement an interface to allow direct access to MySQL Cluster from Java, using the Domain Object Model pattern used by JDO and JPA. I also continue to work on the JDO specification, adding features that are important to the community.
JAXenter: After the really noisy persistence wars from the beginning of the millenium it has become a bit quieter today. Now JPA is the standard, and Hibernate, Open JPA and EclipseLink are the dominant implementations. Is everything done in that area or do you still see space for substantial innovation and competition?
JAXenter: JPA is an example that today’s specifications don’t arise from just specifying something; it seems that real innovation comes from real existing and working code – like Hibernate and EclipseLink (formally known as TopLink). What can we learn from this?
Craig Russell: The Java Community Process (JCP), under which both JDO and JPA were developed, promotes what I consider to be best practice for specification-writing. The features of greatest impact in JCP are the requirement to prove that the specification can be implemented, by providing a Reference Implementation, and the requirement that compliant implementations prove that they correctly implement the specification by passing a conformance test. These two features make it very attractive to start from something that’s already implemented.
In the case of JPA, we had the predecessor example of Java EE Container Managed Persistence (CMP), which was a commercial success but technical failure. When the top architects of JDO, TopLink and Hibernate collaborated on a new specification, they had the advantage of substantial working code, community support, and customer bases. So although JPA was completely new in terms of the API, it built on solid design work and practical implementation experience that was lacking in CMP. Another best practice in specification-writing is an open communications plan, so the specification committee doesn’t create in a vacuum. There is a requirement to make interim specification drafts public so all the stakeholders can have their opinions heard before it’s too late for them to make an impact. This is not an original feature of the JCP but was added based on feedback that some expert groups were too closed to outside (public) influence.
JAXenter: There has been quite a bit of criticism around the first version of the JPA Spec because some essential features were lacking. How do you see the efforts around JPA 2?
Craig Russell: The first version of JPA was limited by time constraints. But most of the critical features missing from the first version have been added in the second version. There are certainly items to improve in subsequent versions, but the second version is very usable.
JAXenter: What are the main pitfalls when adopting ORM in your opinion?
Craig Russell: The biggest mistake developers make is giving either the object model or the database schema top billing in the project. These technologies are very different, with different strengths and weaknesses. Successful projects recognize that a perfect database schema might be very difficult to map to objects, and a perfect object model might perform poorly when translated exactly into the database.
JAXenter: Let’s have a look in the Crystal Ball and speculate a little bit about the future of O/R-Mapping. What will O/R-Mapping mean to us in 2 years, in 5 years?
Craig Russell: As standards like JPA and JDO cover more of the feature sets of proprietary implementations, developers will more and more adopt the standard interfaces instead of coding directly to the implementations’ APIs. But there will be features and performance characteristics of the implementations that users will want to take advantage of, so there will still be reasons to choose one implementation platform over another. As users migrate to cloud computing, ORM will be an option on the menu for cloud vendors who will compete by providing users choice of appropriate data access. Some vendors have already decided not to offer direct SQL access to data, choosing instead to offer higher-level abstractions for data. For example, Google’s “menu” for Java AppEngine includes both JDO and JPA to access data stored in BigTable, instead of offering SQL, which can provide spectacularly poor performance on newer distributed data engines for the web.
JAXenter: How do you see the development and adoption of object oriented databases as an alternative to relational storage + orm in the enterprise?
Craig Russell: Object databases will continue to provide attractive price/performance in key niche markets such as telemetry, financial systems, and real-time systems. But object databases are not the only alternative to relational. Column oriented databases, key-value stores, and schema-less document stores, just to name a few, will also play a significant role in many applications. For as far as I can see into the future, relational databases will be the storage medium of choice for OLTP, that is local transactional data access that is tightly bound to application processing. The farther your application is from OLTP, the less you need relational databases. The internet now offers more flexibility in system design, allowing the most appropriate technologies to be combined in a single user experience. From the user’s point of view, an application can be seamless, from browsing a catalog using key phrase searches, to logging into a payment service to purchase an offering, to downloading the purchase via streaming. Each part of the application can be deployed on a different platform, using different quality of service metrics. Many systems will combine a relational database core with caching, application logic, and presentation processors, on centrally-located and distributed systems. Users with smart devices will pose additional challenges to isolate the core from data presentation.
JAXenter: What about other Programming languages and platforms: will we see one day a universal persistence technology, working with (J)Ruby, PHP, Java, .NET?
Craig Russell: You might as well ask if there will ever be a universal programming language! But seriously, new persistence technology starts out being impossibly low-level, but if the benefits of the new technology outweigh the difficulty of using it, higher-level interfaces are built that allow wider adoption. I consider interfaces like JDO and JPA to be mid-level interfaces, that are now successful in presenting a uniform programming model to many different storage models. Higher level interfaces that build entire applications from the domain model are now possible to build. Other approaches to persistence applications like Ruby on Rails (RoR), give you an entire application framework but have limitations that make it a bit awkward to use if the developers don’t completely control the database schema. You might build something like JDO or JPA in RoR, but it might not be as easy to use considering all Aspects of RoR Active Record. There is talk of adding a domain object model approach but that’s not where the mainstream RoR developers are. Microsoft already has their solution to ORM in LINQ. It’s their high-level access for .NET languages and it’s hard to see how a competitive interface would gain much traction in that space.
JAXenter: Craig, you’ve been working on Java Persistence for many years. Is it still interesting?