Red Hat

In Relation To

The Hibernate team blog on everything data.

Hibernate Tools Alpha 4 released

Posted by    |       |    Tagged as

The new updated version of the Hibernate Tools ( project includes significant updates to the Eclipse editors, plugings, and wizards, as well as a unified and convenient Ant task for integration of the tools in your regular builds.

See for a visual mini-tour of the new features.

Ant task documentation is at

Current (Contextual) Sessions

Posted by    |       |    Tagged as

New to Hibernate 3.0.1 is the SessionFactory.getCurrentSession() method. It allows application developers to delegate tracking of current sessions to Hibernate itself. This is fairly trivial functionality, but stuff just about any user of Hibernate had to implement themselves, or rely on third party stuff to do for them. Let's take a look at how this is implemented in Hibernate and how it might be useful.

Context Scope

I said that SessionFactory.getCurrentSession() tracks the current session on behalf of the application developer. What exactly does that mean? What is the scope in which a session is considered current? The transaction! More specifically, a JTA transaction.

Another dimension to scoping the current session is to which factory it belongs. Because Hibernate implements this internal to the SessionFactory, the current sessions are inherently tracked by that given factory. Internally, the SessionFactory maintains a Map of sessions keyed by JTA transaction. There is little overhead in this since the Map is built lazily, and only utilized during getCurrentSession() calls: if you don't use this feature, the map is never even built.

Example Usage

Imagine a simple scenario coordinating efforts between three DAOs:

public Bid myExposedCmtEjbServiceMethod(Long itemId, Double amount) {
    ItemDAO itemDAO = new ItemDAO( getSessionFactory() );
    BidDAO bidDAO = new BidDAO( getSessionFactory() );
    UserDAO userDAO = new UserDAO( getSessionFactory() );

    Item item = itemDAO.load( itemId );
    User bidder = userDAO.load( getCurrentUsername() );
    return bidDAO.create( item, amount, user );

How should each of the DAOs utilize the same session to perform their work? The typical pattern is to use ThreadLocals or similiar contextual storage (perhaps a JBoss TransactionLocal) to maintain the current session within that context. Furthermore, how do we know when this current session should be cleaned up?

The usual pattern to implement these functionalities is that a top-level service/method is defined as the service controller which is responsible for opening a session at the start, binding it to the contextual storage (so other collaborators can find it), and cleaning up the session at the end of the service processing. A slight twist on this is to use method interception to apply those behaviours (or aspects) on top of the service controller method. Either way, this can be a lot of work to setup requiring that we either:

  • modify all the service controller points to perform the open-bind-cleanup functionality
  • wrapping all our services (sometimes spuriously) in proxies so that we can intercept the method execution and apply those behavioural aspects

So instead, lets look at using the SessionFactory.getCurrentSession() approach:

public class ItemDAO {
    private SessionFactory sf;

    public ItemDAO(SessionFactory sf) { this.sf = sf; }

    public Item load(Long itemId) {
        return ( Item ) sf.getCurrentSession().load( Item.class, itemId );


Here, each of the DAO collaborators simply use the getCurrentSession() method; the things collaborating with the DAOs do not need to perform anything extra and we do not need to generate proxies and method interceptors just to apply the notion of contextual sessions.

So now, by using getCurrentSession() we can easily scope the notion of a current session to the JTA transaction and reuse the same session throughout that JTA transaction. But how do we clean up the session? And how do we manage flushing of the session state with the database?

Auto flush and close

Two new configuration options introduced in Hibernate3 are extremely powerful, especially when combined with the SessionFactory.getCurrentSession(). Both of these are available in the JTA environments, as well as scenarios where application is utilizing the Hibernate transaction-abstraction API.

The first is flush_before_completion, which forces a flush of the session just prior to transaction completion (think Synchronization.beforeCompletion()...). With this setting enabled, we do not have to worry about flushing the session after we are done in order to synchronize in-memory state with the database; Hibernate does it for us (just prior the transaction commit).

The second is auto_close_session, which forces the session to be closed after transaction completion. In JTA environments, this setting has an additional effect; it forces Hibernate to release JDBC connections much more aggresively. Basically, Hibernate will obtain a connection, use it, and then immediately release it back to the datasource. This allows better integration into JTA environments which implement some form of connection containment check (i.e. the JBoss CachedConnectionManager).


All of these together allow application developers to free themselves from managing session lifecycle and have Hibernate do it for them.

Position vacant: Hibernate consultant for JBoss

Posted by    |       |    Tagged as

JBoss, Inc is looking to hire a full-time Hibernate consultant based in the United States to help deliver Hibernate-related onsite consulting and training. We're looking for someone with significant experience building enterprise applications using Hibernate. JBoss knowledge is useful but not essential. Please send resumes to

Hibernate 3.0 presentations

Posted by    |       |    Tagged as Hibernate ORM

I recently spoke at TheServerSideJavaSymposium and at the New England JUG. My presentations, which cover some new ideas implemented in Hibernate 3.0 are now online:

I find it quite hard to talk about HB3, because there is simply so much new stuff, and a lot of it is somewhat obscure. It's really difficult to communicate what a big step forward this is for us.

Versant Spam

Posted by    |       |    Tagged as

For several months, Versant, an old-school OODBMS vendor with a collapsing market cap, has been making any number of false claims about Hibernate in online webinars and sales presentations. I went so far as to write a blog refuting their claims, but then held back on publishing it because I thought they didn't deserve the attention. They've now resorted to mass emailings of a document with many false claims about Hibernate, and we've decided we need to respond for the record.

(If you haven't been bothered by Versant's spam, or knew to treat it with extreme suspicion, you probably don't need to bother reading any further.)

I'll answer the claims of the document, point by point. I won't bother arguing that Hibernate is better or Versant is better or whatever. Instead, as always, I encourage potential users to try out both products, and see which one works best for them.

A caveat: some of the claims were true of Hibernate 2.1 but not of Hibernate 3.0 (UPDATE: about 10 of ca. 40 false statements). But the document I am responding to was sent out a full two weeks after the release of Hibernate 3.0 rc1, the first production-ready release of Hibernate3. I think it is a reasonable expectation that competitive material refer to the latest current production ready release, and not to previous versions, especially given that all of the new features were available for the past six months in beta releases of Hibernate, and are fully documented in the Hibernate3 feature list, which has also been available for months. If Versant were curious, it would have been easy to establish the existence of these new features. Projects performing product evaluations now are interested in the capabilities of Hibernate 3.0, not Hibernate 2.1.

Hibernate has drawn a lot of attention in the Java community as a solution for transparent 
persistence with Java based applications. The big deal seems to be that it is free...

No, the big deal is that It Works. In practice.

Hibernate was responsible for popularizing ORM technology in Java, and helped create a market which Versant now hopes to exploit as it's bread and butter object database technology continues to fail in the marketplace. However, it is unlikely that a company which has spent many years trying to convince the world that relational technology is broken will now be able to reinvent itself as a credible vendor of object/relational mapping technology. Especially when there are at least three vendors who are already far, far better positioned in this space and have products with greater maturity and much larger user bases - none of whom has a history of hating relational databases.

This paper points out the pitfalls of the Hibernate solution while showing how JDO implementations,
specifically Versant Open Access JDO, addresses those pitfalls. Where appropriate, it discusses the
strong points of Hibernate in order to give a fair analysis for the informed reader.

Oh, puh-lease. Hibernate has oodles of features that Versant Open Access JDO does not have, none of which are mentioned in the document that follows.

More importantly, the tools available to the developer using Versant Open Access - JDO and/or most
other JDO vendors, are several orders of magnitude better than what's available with Hibernate

How did they measure several orders of magnitude better? With a tape measure? Did they actually research the efficiency of a Hibernate team vs. a Versant team and discover that the Versant team was a thousand or thousands of times faster at creating a domain model? Or is the author simply making stuff up?

I'll actually concede the point that our toolset can be improved. That's why we now have a fulltime development team led by Max Andersen working on building an ambitious suite of open source Eclipse plugins for Hibernate and EJB 3.0. A preview release of some of the plugins is available here:

This is a major strategic initiative for JBoss, so expect this stuff to get very slick, very fast.

In fact, if you go to the Middlegen website and look at their ( online Middlegen demonstration ) , 
you will see that they are showing CMP, JDO & Struts not Hibernate. So, you can imagine the amount 
of support you get from the technical leads of those open source initiatives for the Hibernate 

David Channon, a member of the Hibernate team, has been responsible for maintaining and supporting the Hibernate middlegen plugin. I'm sure that Hibernate users will vouch for the value of David's helpful support. His current Hibernate Forum posting count is about 1300 - most of this is free support related to Middlegen. (David's posting count is a quarter of the total postings on the Versant JDO forum.)

(Actually, Middlegen based reverse engineering is being end of lifed, and a brand new eclipse-based reverse engineering plugin is now available, in the Hibernate Tools preview release.)

When it comes to things like monitoring and performance tuning, you are left completely to your own
devices because Hibernate offers nothing to help.

This is not true, Hibernate 3.0 offers sophisticated JMX monitoring functionality, and oodles of options for performance tuning.

In Hibernate, there are no visual tools for editing meta data or relational mapping that come out of 
the box. 

Hibernate Tools provides a Hibernate mapping file editor with auto-completion for class, property, table and column names as an eclipse plugin. This is the fastest and most efficient way to create mapping documents available, much more efficient than the clunky visual tools we have tried. In addition Hibernate now supports EJB 3.0 annotation-based mappings, which are even easier to use.

The lifecycle states in Hibernate are not only insufficient, but also incomplete in their

Oh really? Got any argument to back this up?

Oh, here we go, one example...

For example, the update callback in Hibernate which is used to notify when an
objects state has changed and is going to be updated in the database is only called when the object is
a transient object and being sent back for update. It is not called on any change of a persistent object
that will cause an update to the database. 

This shows that the writer of the document does not really know Hibernate. The Lifecycle.onUpdate() callback is used to notify the application when a detached object is becoming managed via a call to update(). There is a completely different callback - Interceptor.onFlushDirty() - which is used to notify the application that a SQL UPDATE is about to occur. I'm not sure why the author could not find this callback, which is heavily documented and well-understood in the community.

To clear up any doubts about the lifecycle model defined by Hibernate: the model is identical to the lifecycle used by TopLink and standardized by JSR-220 (EJB 3.0).

Also, the create callback is not called when identity is managed by the database's native key generation 
which is the most common form of key generation (for example: Identity tables in DB2 and Sequences in 

This is simply not true. The author obviously never tried it.

The following summarizes the Hibernate coding impositions.
1. You need to add an identity attribute and methods to your classes ( getId( ) , setId( ) ). Note
that this is not strictly mandatory, but you must implement these if using the Hibernate
disconnected model capabilities. 

It is always useful to be able to get access to the primary key of a persistent instance. This is not a limitation, it's a feature.

The disconnected model in Hibernate is a limited form of the attach/detach capabilities found 
in JDO.

The capabilities found in JDO 2.0 (which did not exist in JDO 1.0) were inspired by Hibernate, and by my criticisms of JDO. To describe Hibernate's capabilities as a limited form is disingeneous and misleading. The detach/reattach model is slightly different, but we think that our capabilities are more powerful and easier to use.

2. Your classes must implement Java Beans style accessors for all persistent attributes. There
are no such restrictions in JDO.

This is simply not true. Hibernate does not require getters and setters, as is clearly described in many places on the Hibernate website.

3. Because of Hibernates runtime proxy generation through the use of CGLIB, calls to getClass
can return the wrong type, so if you need to access the class of an object you have to use
Hibernate static methods. Hibernate.getClass( foo ) instead of the traditional foo.getClass( )

Big deal. How is this an imposition?

If you /really/ want to be able to use getClass(), you can use instance variable interception instead of proxying for lazy fetching in Hibernate 3.0. Of course, we do not expect any Hibernate users to go this route, since proxies are simply more convenient for most people.

4. Application Identity classes with composite id's must implement Serializable. This is only
required if you want the class itself to manage identity rather than creating an identity class.
This is also a restriction in Versant Open Access JDO. The common practice is to use an
application identity class and this bullet is included mainly for completeness.

Wow, is this possible? Does Versant Open Access JDO have limitations? Surely not!

5. Polymorphic classes should implement hashcode and equals methods. This is only required if
the objects are going to be accessed by multiple sessions and the shared cache is enabled. If
you do not plan for this up front and then decide to scale later on and add application servers
and clustering, something that should be an administrative task, suddenly your business logic
might not be working properly and you won't even know it's a problem until you have many
logical errors in your data.

This is all either incorrect or incomprehensible. The only time you need to implement equals() and hashCode() on persistent classes is if you plan to put instances in a HashSet, and this is a requirement of the Java Set contract, not of Hibernate.

6. Collections must be referenced as Interface types only. You cannot refer to a concrete
implementation class of the interface. Versant Open Access JDO does not have this

This restriction is a good coding practice. There is no reason to code to ArrayList instead of List; good OO practice exhorts us to code to interfaces.

If, for some bizarre reason, you need to code to concrete collection implementations, Hibernate3 provides an extension point so you can do this. No Hibernate user has ever asked for support for concrete collection classes, so we did not bother implementing this as a standard feature.

You would think that Versant would actually try to discover real problems that real Hibernate users experience in practice, instead of coming up with red herrings like this.

7. Hibernate does not guarantee the order of loading attributes in your class, so your setter
methods cannot reference other attributes within your class. This is because the setter
methods are used at runtime when loading an object from the database and it is possible that
you are accessing a field that is not loaded yet.

This is not correct, Hibernate guarantees that attributes are populated (either via setters, or direct instance variable access) in the order they are listed in the mapping document.

It is worth pointing out that Hibernate uses checked exceptions. 

Hibernate 3.0 has an unchecked exception model.

However, it is not clear why there is any exception handling at all in Hibernate. The
reason is as stated in the Hibernate documentation, Hibernate cannot guarantee the state of the
Hibernate Session if any kind of exception occurs.

Correct, this is the same as TopLink, and different to some JDO implementations. I'm currently discussing with Mike Keith (Oracle) and Patrick Linskey (Solarmetric) to understand if there are any good cases for allowing recoverable exceptions in the EJB 3.0 spec, and if we find some (Patrick seems to believe there are some), we will of course implement that in Hibernate.

I'm open minded about this; I realise that there are some complex and subtle issues here. However, it is useful to observe that the two most mature, most used, non-designed-by-committee ORM solutions in the world (Hibernate and TopLink), never found a compelling need to support recoverable exceptions. On occasion, users have asked that certain exceptions be recoverable, but I have always been able to offer satisfactory alternative approaches to their problem.

If you want to move a deterministic set of objects to another tier, you have to resolve these yourself.
Each object must have been loaded from the database before you can detach (close the Hibernate
session), so you must touch each object to cause it to initialize. For collections, you would have to
use a static method Hibernate.initialize(). 

This is not correct, all Hibernate query facilities give you a way to easily specify which associations will be fetched before detaching the object graph. You most certainly do not need to traverse the object graph calling initialize().

Once you've sent the objects to the disconnected tier, you need to be very careful not to traverse 
relationships outside of the disconnected graph or you will get a fatal exception. 

On the contrary, the exception is not fatal, hence this behavior is exactly the same as Versant's.

Once you've changed the objects, then when you send them back you must either
individually call update( ) on each object or configure cascading meta data. 
Once again, using cascading meta data does not work through collections. 

This is not correct. You can easily enable cascade on a collection.

So, in most cases you will be forced to implement this yourself. In addition, Hibernate does not know which 
fields have changed or if the object has really been updated. By default, when you call update( ) it will 
perform an UPDATE operation of the object even if it has not changed. This means that configuring meta data to
automatically call the update will ALWAYS do an update operation even if the object has not
changed. If you have triggers defined in the database this will lead to false triggers. 

There is an option called select-before-update which apparently the writer was not aware of, even though it is thoroughly documented.

Hibernate provides a way to work around this inadequacy ONLY if you are using optimistic transactions with
the version/timestamp option.  You can call a method to check if the object has changed prior to
actually doing the update. However, since Hibernate does not track dirty fields, it must do a field by
field comparison of all fields to determine what needs to be updated. This has obvious performance

None of this is correct, and I have no idea what the author is talking about. Hibernate does not have any such functionality. Instead it has the simple switch mentioned above.

To say that the Hibernate detach behavior is flawed is an understatement. 

To say that the author of this document does not understand Hibernate's detach behavior is a massive understatement.

Note that Hibernate 3.0 fully supports the persist()/merge() lifecycle defined by JSR-220 (EJB 3.0).

Hibernate, out of the box, uses EHCache for their level 2 cache which is not clusterable. This is
another open source product that has difficulty staying in sync with product updates. 

This is absolutely not true. EHCache (which stood for Easy Hibernate Cache) was established at my urging by Greg Luck from Thoughtworks. Greg heavily tests EHCache against the latest release of Hibernate before every release of EHCache, and we are in regular email contact. There has never, ever been a problem with staying in sync. I'm not even sure what staying in sync means; perhaps the author is not aware of the software development notion of a published API, which helps different software components work together.

They used to support JCS cache, but have deprecated it's use and who knows how long EHCache will last.

EHCache is a fork of Apache JCS, and was created to fix several bugs in JCS. JCS was deprecated a full two years ago! This is pure dishonest FUD. There are no plans at all to drop support for EHCache. And even if there were, what exactly is the problem here? The whole point of the pluggable cache architecture is that the application has no dependency to the cache implementation, which is completely swappable at deployment time.

Hibernate does support two different cluster caches ( SwarmCache and JBoss TreeCache ). However,
none of their clustered cache implementations support query caching, so by introducing these
clustered caching solutions you introduce a potential performance degradation.

This is not true, the Hibernate query cache works with JBoss Cache, as per the Hibernate documentation.

Hibernate does query caching by using a system level caching option must be enabled, and then in
addition, individual queries must be configured to cache their results. Also, no referenced objects are
cached, only their OIDs. So far, this is pretty consistent with Versant Open Access JDO. However,
since only oids are cached, query caching is really only useful if using the second level shared cache.
In fact this is stated explicitly in the Hibernate documentation. However, the only shared caches that
support clustering do not support query caching. Versant Open Access JDO does not have this

Except for JBoss Cache, which supports query caching. Oh, woops, that explodes the whole claim.

CGLIB Side effects:
Hibernate cannot not properly implement polymorphism due to it's runtime byte code generation.

This is simply not correct, all Hibernate queries and association mappings fully support polymorphism.

What is meant here is that you cannot query on a super class and then cast to the subclass type or a
similar type of operation. Subclass casting is not allowed. 

This is not correct, it is trivial to use the get() method to perform a typecast in the very rare case that business logic needs to perform typecasts.

By the way, the whole point of polymorphism is that you do not need to do typecasts, so the author has a mistaken understanding of what polymorphism is all about if he/she thinks that support for polymorphism means support for typecasting.

Also, you cannot use any Final class or any class that has Final methods. Of course, if these things 
are important to you then you can get them back by not using the runtime proxies and reverting to 
the old reflection model.

What is a capitalized Final? Does the author mean the Java final keyword? If so, he/she is partially correct: a final class cannot be proxied (unless it implements an interface), in which case you can use instance variable interception for lazy loading (just like Versant) if you really want to. In practice, no Hibernate users care about this.

(We actually implemented instance variable interception, not in response to requests from users, but rather to neutralize this as point of FUD by commercial vendors like Versant.)

Finally, something that I have not fully comprehended the implications of: If any resources are 
initialized in a constructor or initializer method, then those resources will also be held by the 
proxy. I think that there may be no way to release these resources when the actual object is flushed 
or committed/evicted from the cache.

What is this person on about here? Apparently the author drifted into pure la la speculation land at this point!

Does not support semantics of the collection like iteration ordering on LinkedLists, but it does
not go into detail and list which of these semantics are unsupported in the documentation.

Hibernate certainly does support the iteration order of a List, apparently the author misunderstood some comment in the Hibernate documentation.

Hibernate3 provides the UserCollectionType extension point which may be used to support any damn collection and collection semantics you like.

One to many associations that do not use a JOIN table and have a NOT_NULL constraint on the
key will fail on commit if there is no bi-directional association defined in the model. So, you
must have a bi-directional association if the key has a NOT_NULL constraint.

Not true in Hibernate 3.0.

Hibernate does not support one to many collections where the many is an indexed collection.
Also a restriction in Versant Open Access JDO.

Not true in Hibernate 3.0.

Ooops, did we just spot a feature of Hibernate that Versant does not have? How could that possibly be?

Hibernate supports Flat, Vertical and Horizontal inheritance mapping. 
Flat mapping has a restriction that none of the columns in a subclass can have a NOT_NULL constraint. 

Yes, this is true in every ORM implementation.

We do not have any restrictions on constraints for Flat mapping. 

On the contrary, it is simply impossible that a subclass attribute could be non-null in the single table or Flat mapping strategy. Apparently the author does not even know his own product. It /is/ possible to enforce correct nullability semantics using a database CHECK constraint, and Hibernate supports this in its DDL export functionality.

Horizontal mapping does not support polymorphic associations which would necessitate multiple 
queries across concrete tables. 

Not true in Hibernate 3.0, Hibernate3 can use an SQL UNION, and this allows, among other things, polymorphic associations.

Also, Hibernate uses a top down approach to inheritance mapping. This means that
subclasses inherit their supers mapping strategy. The implications are that you cannot combine
mapping strategies for a set of subclasses from a common superclass. For example, a class that drives
two subclasses cannot map one of the subclasses vertically and the other flat.

Not true in Hibernate 3.0. Flat and Vertical can be chosen freely selected for particular subclasses.

Today, Versant Open Access JDO supports Flat and Vertical mapping only.

Ah, so, Hibernate's inheritance support is more flexible. Imagine that.

Versant Open Access JDO supports polymorphic associations in all supported mapping strategies.

As does Hibernate3, and, as we have observed, Hibernate supports a whole extra inheritance mapping strategy that Versant does not yet have.

Database Constraints:
Hibernate does not know how to order insert statements to deal with NOT_NULL constraints on
foreign key columns. 

This is not correct. When cascade persist or cascade save is enabled, Hibernate correctly orders INSERTs.

We did not specifically address performance in the above, except to reference the Hibernate
move from a purely reflective to a runtime byte code enhancement model. The issues of taking
this later approach due to performance problems in the former is something well documented in
the Hibernate manuals. If you crawl the web looking for more information on performance, you
will find that there are several benchmarks done where JDO vendors out perform Hibernate.

Blah blah. I've seen benchmarks where Hibernate wins. I've seen benchmarks where TopLink wins. I've seen benchmarks where CMP wins. In our experience, the winning solution is usually the one which is best understood by the benchmarkers. (My own benchmarks against a leading JDO solution show Hibernate winning on most measures, but I don't claim this as a general result.)

Besides this vague claim, the author does not have the courage to actually come out and claim that Versant Open Access JDO is actually faster than Hibernate, which presumably means that Versant does not actually believe it is. This is one point where we are in agreement.

The above has addressed many of the misconceptions found in the Hibernate community
regarding Hibernates superiority over JDO. I think that from a technical perspective, there is a
strong case that those misconceptions are completely unfounded.

Actually, the above was a long list of false statements and half-truths, written by someone who did not know very much about Hibernate, beyond some apparently superficial reading of the user manual.

Furthermore, I have to ask, are any of these issues to do with real problems managing real data in real enterprise applications? Very few of the interesting questions in ORM are even addressed in this document. What facilities does Versant have for dealing with complex legacy data? For working with temporal, regional or permissioned data? For allowing full overriding of any generated SQL? For calling database-specific functionality from the query language? For handling dynamic queries on search screens? For producing XML or mapping dynamic entity definitions? For extensibility? For efficient association fetching? How many users are really using Versant Open Access JDO in anger? Hibernate can boast tens of thousands of satisfied users; why should they start paying for a closed source solution to a problem which is now very effectively solved by free software?

Rod Johnson: "neither I nor any of my colleagues have a sense of humor"

Posted by    |       |    Tagged as

We got dissed by a Spring developer!

But Rod, you'd make /such/ a great Egghead! Well ... if you didn't take youself so damn seriously, that is ;-)

While we're on the topic, who else has noticed that Rod has a double-phallic name?

Hibernate 3.0 released!

Posted by    |       |    Tagged as Hibernate ORM

Hibernate 3.0 is the world's most sophisticated ORXM (Object/Relational/XML Mapping) solution. Hibernate3 makes it easier than ever before for Java applications to interact with persistent data, allowing a single definition of the transformation between various in-memory representations of the entity data and the relational schema, even in the case of very complex legacy schemas and schemas for historical data or data with visibility rules. Hibernate3 also provides the most comprehensive object/relational query functionality, with three full-featured query facilities: Hibernate Query Language, the newly enhanced Hibernate Criteria Query API, and enhanced support for queries expressed in the native SQL dialect of the database.

Compared to Hibernate 2.1 - the most popular object/relational mapping solution in any language - Hibernate 3.0 offers:

  • Much more flexible O/R mapping: support for exotic association and inheritance mappings, and greater flexibility when working with legacy data.
  • Hibernate3 filters: a unique feature for working with temporal (historical), regional or permissioned data.
  • Unprecendented flexibility for mixing handwritten and generated SQL within a single application or even a single entity: full support for derived entities and attributes defined in the mapping document, full support for overriding any generated SQL statement with handwritten SQL, support for stored procedures.
  • Object/Relational/XML mapping: query XML directly from the database for reporting, replicate data between databases via intermediate XML, externalize entity data as XML when interacting with remote systems.
  • Enhanced ease of use: better defaulting, an unchecked exceptions model, simplified natural (and composite) key support, simplified CMT integration.
  • Enhanced Criteria query API: with full support for projection/aggregation and subselects.
  • Runtime performance monitoring: via JMX or local Java API, including a second-level cache browser.
  • Brand new AST-based HQL parser: bulk update/delete enhancement, better syntax validation.
  • JBoss EJB 3.0 preview: support for annotation-based O/R mappings, full support for EJB-QL 3.0, support for EJB 3.0 persist()/merge() lifecycle, JACC-based security model.
  • Hibernate Tools preview: a full suite of Eclipse plugins for working with Hibernate 3.0, including mapping editor, interactive query prototyping, schema reverse engineering tool.
  • Many new extension points: including a new, extensible, event-driven architecture
  • Documentation enhancements.
  • Brand new test suite, including many useful examples of exotic Hibernate mappings.

A full list of new features may be found at:

Download link:

The Hibernate 3.0 core is 68,549 lines of Java code together with 27,948 lines of unit tests, all freely available under the LGPL, and has been in development for well over a year. We would like to thank the many people who contributed to this release!

The Hibernate Team,

  • Max Rydahl Andersen, JBoss Inc
  • Christian Bauer, JBoss Inc
  • Emmanuel Bernard
  • David Channon
  • Joshua Davis
  • Steve Ebersole, JBoss Inc
  • Michael Gloegl
  • Gavin King, JBoss Inc
  • Anthony Patricio

EJB 3.0 EDR2

Posted by    |       |    Tagged as

Cedric beat me to this, but if you missed his announcement, the EJB 3.0 second early draft is available. The most interesting new stuff to me is:

  • the new callback listener/interceptor architecture
  • the separate document dealing with entity beans that will evolve into a complete specification out-of-container operation of the entity manager (the persistence engine)
  • native SQL queries
  • definition of interoperability with legacy EJB 2.1 clients and servers
  • complete specification of the semantics of association mappings
  • complete specification of the semantics of EJBQL

There is also an example of what the XML-based ORM metadata might look like. This is intended to spark discussion and is certainly not final at this stage.

Of course, there are many other revisions compared to EDR1. (Those were just the ones I could think of now.)

The goals for a next draft include

  • API for obtaining an EntityManager outside the container
  • more complete definition of XML-based deployment descriptors

Before I go, I can't overemphasize how important the new @Interceptor stuff is - for a long time we've been unable to extend the basic set of EJB services in a portable way. Yes, you could do it in JBoss, using JBoss-specific APIs, and in WebLogic using BEA-specific APIs, but that just isn't good enough! One immediate consequence of this new feature is that people will be able to build /EJB frameworks/. I anticipate a whole new marketplace for open source addons to EJB, just like there is a profusion of web-tier frameworks today. But unlike web-tier frameworks, the architecture lends itself to combining different extensions in the same application! It's interesting; the original EJB vision was for a marketplace of reuseable /application components/, which didn't eventuate. /This/ feature will further foster the availability of reuseable /infrastructure services/, which actually /has/ worked in practice (though it hasn't worked so well for EJB).


Hibernate Annotations alpha1

Posted by    |       |    Tagged as

We just released the brand new Hibernate Annotations module as an alpha version. This module provides the Hibernate facilities to declare Hibernate O/R mapping metadata through JDK 5.0 metadata annotations (instead of XML mapping files or XDoclet preprocessing). We have implemented the EJB3 (JSR-220) O/R metadata annotations defined in the early draft 1 of the spec. This set of annotations covers all common mappings cases.

Next step for us is to provide custom annotations to cover Hibernate specific features while following the EJB3 spec evolutions.

This tool is designed for easy-of-dev and quick application development (mapping metadata in the sources, no preprocessing step, configuration by exception minimizing the metadata declarations). Give a try to this new programming model. Feedbacks are welcome, especially on the Hibernate specific features you want to see covered by annotations.

Download it and have a look at the tutorial and the comprehensive test suite. It will give some good samples.

Hibernate 3.0 goes beta

Posted by    |       |    Tagged as Hibernate ORM

We just released Hibernate 3.0 beta 1. I've no time to list all the many changes since the alpha was released four months ago, let alone everything that is new in Hibernate3, which has been in development for over a year now.

The most exciting new thing from our point of view is the new AST-based HQL parser, written by Joshua Davis. It uses 3 ANTLR grammars to transform HQL/EJBQL to SQL. The work on this is not quite finished, but almost all legacy tests pass. You can try out the new query parser by setting


I'll try to get Joshua to blog about the design of the parser (very cool stuff).

back to top