Interview with Craig Russell on JPA 2.0

Craig Russell
JPA-Teaserpicture

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?

Craig Russell: The JPA work-in-progress makes
substantial improvements to the original, but there is still work
to be done. All of the JPA implementations, as well as JDO,
continue to add features that might become part of the JPA
standard. For example, with JDO 2.3, developers can create object
models out of thin air, dynamically create the implementation
classes, dynamically create the database schema and
object-to-database mapping metadata, and run programs with the
newly-created persistent objects. And improvements to the usage of
JPA with scripting languages like Ruby and JavaScript are areas to
improve.

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?

Craig Russell: Persistence is still very
interesting as well as challenging. I have the opportunity to work
with systems architects, marketing folks, software engineers,
support and sales engineers, sales folks, and customers. In the
persistence arena, I started working on hierarchical databases
before object databases, relational databases, and key-value
stores. I’ve programmed in assembler, C, C++, Smalltalk, APL, and
Java, and I’m learning Ruby and JavaScript. No matter what language
you use, persistence is a requirement for any interesting
application. And the language and API you use with your database
has a lot to do with how easy and enjoyable it is. I like to think
that my main mission is to make it easy to build robust, scalable
persistence applications, and there’s always a new database, a new
language, and a new way of thinking about the problem to solve.

Author
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. He was the architect of the Container Managed Persistence component of the J2EE Reference Implementation and Sun Java System Application Server. Craig is co-author of the definitive work, Java Data Objects, published by O'Reilly.
Comments
comments powered by Disqus