Hibernate is a powerful technology intended to solve the problem of object/relational persistence. Hibernate 2.1.2 does this quite well, with a large suite of features (as demonstrated in this text). The developers of Hibernate expect future releases of the Hibernate 2.1.x line to provide bug fixes but no major changes. This chapter attempts to give a sense of the direction that will be taken both by Hibernate 3.0 and by the early draft specification of EJB 3.0.
Gavin King, the creator of Hibernate, quite wisely avoids speaking of new features and functionality, but he does offer a preliminary preview of possible future directions for Hibernate 3 in his weblog at http://blog.hibernate.org/cgi-bin/blosxom.cgi/2004/04/02#three. In addition, a Hibernate roadmap has been posted at http://hibernate.bluemars.net/200.html.
To summarize the points made, the following are on the horizon as possible directions for Hibernate 3:
Virtualization: Session-level filtering of data. For example, you may wish to allow only data that belongs to a particular user to be viewed across an entire Web application. The virtualization feature will allow you to specify this at the session, instead of in your application code. This feature will probably be of special interest to Web application developers.
More Complex Relationships: As described in Chapter 7, Hibernate already offers support for a variety of complex relationships. Hibernate 3 will allow the use of a single class for multiple tables, table-per-concrete-class mappings, and the ability to use SQL to specify more complex discriminators.
Representation Independence: Allows a persistence model to be represented using entirely dynamic objects, instead of persistent objects. At some point, you may have realized that most JavaBeans could just as easily be represented by a single object with a single get/set property method (as described by the Apache BeanUtils, http://jakarta.apache.org/commons/beanutils/). This feature allows for a much broader suite of dynamic (i.e., runtime) discovery and manipulation of data.
JDK 1.5 Support: For more information on JDK 1.5, see http://java.sun.com/j2se/. Annotations allow XDoclet-style metadata to be embedded in a Java class file and easily accessed at runtime. Generics allow for more typesafe collections (i.e., less casting, more reliable compile-type checking).
Stored Procedures: This would be quite relevant if you are working on an application with legacy stored procedures.
Event-Driven Design: While the life-cycle methods described in Chapter 6 are reasonable, Hibernate lacks a full event model. Currently, the only way to instrument Hibernate to perform certain tasks is to download the source for Hibernate and add your own hooks—and that is not the ideal situation.
New Parser Implementation: The grammar for HQL (as described in Chapter 8) is not fully documented and can be frustratingly vague in certain areas. Hibernate 3 should include a full grammar for HQL, as well as the ability to map new grammars on top of the existing implementation.
Declarative Session Management: Instead of session management constituting an explicit part of the application, Hibernate 3 will offer the ability to push this sort of detail into Hibernate and the session configuration.
Despite these changes, Hibernate 3 will not require JDK 1.5. As of this writing, Hibernate 3 is not even available as an alpha technology release.
At the present time, only the EJB 3.0 (Summer 2004 Early Draft Specification, http://jcp.org/aboutJava/communityprocess/edr/jsr220/index.html) has been made available. It is intended to obtain feedback from the community, but some probable aspects of the final release (including the clear influence of Hibernate 2.x for relational persistence) are already apparent.
Let's start by highlighting some of the similarities between EJB 3.0 and Hibernate 2.x. First and foremost, EJB 3.0 now bases container-managed persistence on plain old Java objects (POJO) with annotations, much like Hibernate's POJO + mapping file approach. From there, Hibernate's SessionManager and Session have been combined into a single EJB EntityManager class. EJB 3.0 now includes a Query class which allows for page control, similar to that of Hibernate. You are expected to mark one end of an association as inverse. And so on.
Some of the differences between Hibernate and EJB 3.0 are a natural outgrowth of the reliance of EJB 3.0 on Java 2 Standard Edition 5.0 (J2SE 5.0). For example, there is no notion of a Hibernate Configuration class, because EJB 3.0 relies on J2SE 5.0 annotations in lieu of external XML files. Extensions to EJBQL make it look more like HQL, including support for named parameters, fetch, bulk update, and bulk delete. Collection semantics go beyond the support provided in Hibernate, leveraging J2SE 5.0 generics (see JSR 14, http://jcp.org/en/jsr/detail?id=14, for more information on generics).
Some features of EJB 3.0 go significantly beyond what is offered by Hibernate 2.x. These include:
A defined distributed object environment.
Session, Message,andEntityobject distinctions.Additional object semantics and life cycles beyond object/relational persistence.
Security permissions (including method-level security).
Integrated resource-dependency references.
Integrated support for exposing objects as Web services (JSR 181).
A fully defined formal BNF description of the query language (important for robust parser implementations).
From the author's perspective, one of the most interesting advantages of EJB 3.0 as compared to Hibernate 2.1 HQL is the presence of a formal BNF for EJBQL. Backus Naur Form (BNF), as described at http://cui.unige.ch/db-research/Enseignement/analyseinfo/AboutBNF.html, is a formal description of a programming language. By providing a BNF, users can expect to see multiple parsers for a single language, allowing for richer and more innovative tools and solutions. For example, providing a BNF makes it much easier to produce a correct grammar for JavaCC, https://javacc.dev.java.net/. This in turn makes it much easier to produce alternative implementations for EJB 3.0 and to obtain rich support from tools—for example, automatic type-ahead in a text editor.
For a Hibernate developer, the most shocking change when moving to EJB 3.0 is likely to be the reliance on annotations to provide persistence metadata. Simply put, EJB 3.0 development with annotations (per JSR 175, http://jcp.org/en/jsr/detail?id=175) is most similar to Hibernate development with XDoclet (as described in Chapter 3). This eliminates the need for separate XML configuration files because the information is encoded directly in the class files. The formal annotation specification (combined with solid tool support) should alleviate some problems with the current, error-prone nature of XDoclet development, but concerns about embedding database configuration information in Java source remain. The tremendous simplification of the development process may prove able to manage these concerns.
Despite its potential benefits, it will probably be a good while before EJB 3.0 is suitable for production deployment. It requires J2SE 1.5, which as of this writing is still in beta.
Ironically, the best way to get a get a sense of the future is to start working with Hibernate 2.x today. Whatever your future choices may be, including Hibernate 3 or EJB 3.0, Hibernate 2.x will reduce your overall development time, make development more fun, and help you build your skill set for the next generation.