I heard about FindBugs(tm) while listening to one of the Java Posse podcast. Since Hibernate Annotations and Hibernate EntityManager are very close to their respective final releases, I decided to give it a shot.

FindBugs(tm) is basically a static code analyser that tries to find bugs in your code through some pattern recognition. I have been working in the past with both static and dynamic code analysers and I have been pretty disappointed by their false positive ratios (basically a non-bug considered as a bug), and the complexity of their set up process. FindBugs was a refreshing experience.

The cool stuff about it is, well, there are several cool stuffs:

• it's a no brainer to set up and run

• the amount of false positive is surprisingly low

• it works at the bytecode level, so you don't have to have the source code (more later)

Set up and Run

I haven't read the documentation, just downloaded the package and run the .bat file. A couple of clicks and I was analysing Hibernate Annotations and Hibernate EntityManager . No fancy Ant integration required (you can, but you don't have to), no fancy IDE dependency (you can, but you don't have to), no fancy command line requiring you to RTFM (you can, ahem you should, but you don't have to). The provided GUI does the job pretty smoothly, even if a package filtering feature would have been really cool (more later).

A pretty low false positive ratio

THE thing that usually kills such a product is the amount of false positive bug claims. You end up scanning hundreds of warnings without paying attention to them and trash the whole product after 30 minutes. FindBugs has a pretty low false positive ratio, which is very good. And if the warning end up being a false positive, there are usually some good reasons that worth a second look at your code. I must admit I am pretty proud of me ;-) Of course in HAN and HEM, I found some bugs and suboptimal constructs (no worries, I fixed them), but much less than my expectations.

Work at the bytecode level

That is probably what makes it easy to use (and hard to develop), FindBugs(tm) works at the bytecode level, not the source level (it highlights the source line if the sources are available). So pointing a jar or a directory containing your compiled classes is enough. Actually what I did, was pointing to my project root directory, and the job was done.

So while analysing Hibernate Annotations and Hibernate EntityManager , I ended up analysing a bunch of jars (Oh Filter, where art thou?), and I can tell you some guys out there should take a look at FindBugs(tm) , this include a bunch of JDBC drivers and well known in-memory Database backed by some big company(ies) ;-)

Give it a try

It's free, it's easy to set up, it's going to take two hours of your time and save you much more.

I've seen lot's of people writing (or using) third party abstraction frameworks on top of ORM solutions like Hibernate so that they can potentially get rid of one ORM engine to another (or even an other technology). Such frameworks are even considered by some architectsas a must-have.

Praiseworthy, but raising more issues than fixing ones. When you abstract technologies like Hibernate to make them portable, you end up sacrificing lot's of power and functionalities. Simply because semantics are slightly different from one engine to an other.

Let's play with statistics:

• in 1% of the applications, the need for a switch from one ORM engine to an other arise

• in 99% of the applications, the need for one or several advanced features of ORM arise

You should focus on using and knowing your ORM engine and not on spending time in writing (or using) an abstraction framework.

When using abstraction frameworks you haven't written, other kind of problems actually show up.

When your ORM engine introduce new APIs or new features, you have to wait for the abstraction framework to release accordingly making you dependent on someone else's agenda.

You no longer know (either by heart or at all) the actual method abstraction (or semantic alteration) introduced on top of your ORM engine. This user learnt it the hard way (and he is unfortunately not alone), Spring's /HibernateTemplate/ wraps the Hibernate methods without even giving you a hint about the actual semantic.

The only proper abstraction between an ORM engine and another is a common specification they adhere to. This is one of the reasons why JPA (EJB 3.0) has been introduced. Why is it the only way? Because a specification describes in a very detailed way the common semantic the various ORM engines have to follow.

So please, think twice before using some random proprietary abstraction framework (open source or not). They usually bring no value add but increasing bug areas... Specifications are here to solve the engine abstraction problem (but once again, this is a concern in very few applications).

PS in case someone is misleading, I'm not arguing against DAO layers

EJB3 XML mapping files

The latest release of Hibernate EntityManager (3.1.0 beta8) now support EJB3 XML mapping files (aka deployment descriptors). While annotations are considered a huge step forward for development ease-of-use and productivity, some folks out there stayed concerned about the ability to split metadata from the code. This is now supported in Hibernate Annotations (3.1.0 beta 10) and Hibernate EntityManager in a standard manner. You can partially overrides java annotations or you can write all you metadata through XML. The easiest solution is to add META-INF/orm.xml in your ejb-jar or persistence jar. This file is automatically taken into account by the persistence provider. Alternatively you can add a <mapping-file/> element to your persistence.xml file. Here is a sample for EJB3 XML file

<?xml version="1.0" encoding="UTF-8"?>
<entity-mappings xmlns="[=>http://java.sun.com/xml/ns/persistence/orm]"
               [=>xmlns:xsi=]"=>http://www.w3.org/2001/XMLSchema-instance"
               [=>xsi:schemaLocation=]"=>http://java.sun.com/xml/ns/persistence/orm orm_1_0.xsd"
               version="1.0">
  <package>org.hibernate.test</package>
  <entity class="Car" metadata-complete="true" access="PROPERTY">
      <table name="CARS"/>
      <named-query name="carsByManufacturer">
          <query>select c from Car c where c.manufacturer = :manufacturer</query>
          <hint name="org.hibernate.timeout" value="200"/>
      </named-query>
      <attributes>
          <id name="id">
              <generated-value strategy="AUTO"/>
              <column name="car_id"/>
          </id>
          <basic name="category" optional="false">
              <enumerated>STRING</enumerated>
          </basic>
          <many-to-one name="manufacturer">
              <join-column name="manufacturer_fk"/>
          </one-to-many>
      </attributes>
  </entity>
</entity-mappings>

Glassfish integration

I have been working with the Glassfish team for some times now to make sure Hibernate EntityManager integrates well with Glassfish. Now that the specification has been frozen, the integration is working very smoothly:

• download Glassfish b43 and above

• download Hibernate EntityManager

• download Hibernate Core (for HEM 3.1.0 beta 8, you will need Hibernate 3.2 CR1)

• copy the required hibernate (and third party libs) into $glassfish_home/lib

• adjust your persistence.xml file to use Hibernate EntityManager

<persistence version="1.0">
    <persistence-unit name="pu">
        <provider>org.hibernate.ejb.HibernatePersistence</provider>
        <!-- JNDI name of the database resource to use -->
        <jta-data-source>jdbc/sqlserver</jta-data-source>
        <properties>
            <!-- drop and create tables at deployment if needed -->
            <property name="hibernate.hbm2ddl.auto" value="create-drop"/>
        </properties>
    </persistence-unit>
</persistence>

That's it! Glassfish sets the appropriate Transaction Manager Strategy and Hibernate can guess the appropriate Dialect for most common databases.

Hibernate EntityManager is know to run in all up-to-date EJB3 implementations. Of course, it runs smoothly in JBoss EJB3 and JBoss Embeddable EJB3 .

Mapping of Maps

This has been a long time requested feature, it is now available, you can map you associations using Map<Element, ...> or Map<Embeddable, ...> using an explicit key column(s)

The Hibernate team is please to announce Hibernate EntityManager 3.1beta6 and Hibernate Annotations 3.1beta8, a compliant implementation of the latest and greatest EJB3 Proposed Final Draft.

What's new in the spec and in Hibernate's implementation:

• cleaner way to persist enums

• enhancement round queries including support for scalar and composite primary keys in native queries

• implicit entity access type depending on the @Id annotation position

• callbacks and entity listeners inheritance in an entity hierarchy

• more natural annotation design (better separation of concern for some features)

• possibility to have mapped superclasses or even non mapped superclasses in between two entities in the hierarchy

• support for long conversation programmatic model

• enhanced locking API

• multiple persistence unit declaration per jar file

• possibility to disable entities autodiscovery in jar files

• .par extension no longer needed

Check it out

Hibernate 3.1.1 has been released earlier this week. This maintenance release focused on bugfixes and improvements, especially regarding:

• SQL Server support

• DML-style HQL (UPDATE, DELETE, INSERT INTO... SELECT)

• Native Query support

• Connection handling

For details check out the release notes

Hibernate 3.1 introduced non OLTP features as well as better environment integration:

• Custom strategy for session handling through CurrentSessionContext including 2 default implementations (JTA based and ThreadLocal based session handling)

• more natural and aggressive connection handling in J2EE and J2SE environments

• command-oriented API (StatelessSession API) for operations on huge number of objects

• bulk UPDATE, DELETE, INSERT INTO ... SELECT for multi table entities

• extra lazy collections for huge collection handling

• use of join fetch on collection through scrollable resultsets through break processing

• database generated properties (including database timestamps)

• additional ON clauses for joins

• dirty checking short-cuts for instrumented classes

Downloads are available here