JSR-175, standardized metadata, may have more potential to simplify configuration of Hibernate than of Struts. Why do I say this?

• Hibernate has a one-to-one relationship between mapped objects and mapping files.
• Shortcomings in XDoclet make it impossible to generate composite-id mappings, so there’s an immediate value-add.
• Unlike Struts, there’s no large configuration file shared by the whole framework. hibernate.properties is small and used only for configuration.
• The mappings are generated at the attribute level, so more of the bindings (return type, etc) can be determined by reflection rather than the user needing to enter them (Xdoclet can generate this).

Let’s take a look at an example (supplemental code will be at the bottom):

@HibernateMapping( table="employees")
public class Employee
{
    private Name name;  //Yes, name as primary key is dumb
    private String job;
    private Date startDate;

    @HibernateCompositeId({
      @HibernateCompositeIdAttribute(name="firstName", column="first_name"),
      @HibernateCompositeIdAttribute(name="lastName", column="last_name")
    })
    public Name getName() { return name;}

    @HibernateAttribute(column="start_date")
    public Date getStartDate() { return startDate; }

    @HibernateAttribute(column="current_job")
    public String getJob() { return job; }

    //The setters go here

In this case, the metadata approach almost matches the line length of the XDoclet tags to accomplish the same task, and as mentioned, exceeds XDoclet’s capabilities in capturing the composite-id in metadata. (Don’t get me wrong, I like and use XDoclet.)

Don’t give me this story about the advantage a separate config file gives you (in this specfic case). There’s 2 main types of change that affect an hbm.xml file – one is changes to the class. That’s where the existing approach can be a pain – you have to add/remove/change the attribute in the class and the mapping. The other case is a database change, which isn’t a trivial thing. The planning that goes into making changes to a production database can certainly include planning to change the metadata and rebuild your app. It could help you if you have different table and column names in your different environments, but that sounds like a recipe for disaster anyhow.

Because annotations can be reflected at runtime, Hibernate could automatically detect @HibernateMapping classes and add them to its Configuration. Clearly, an @Configuration annotation would be needed to specify some configuration parameters, and could even give a limited classpath to search (e.g. com.kischuk.*) to speed the search for persistable classes. The metadata approach also causes at least some constraints on the format of the metadata to be enforced at compile time rather than runtime.

Supporting code follows (4 different interfaces):

public @interface HibernateMapping
{
   String table();
}

public @interface HibernateAttribute
{
    public String column();
}

public @interface HibernateCompositeId
{
    public HibernateCompositeIdAttribute[] value();
}

public @interface HibernateCompositeIdAttribute
{
    public String name();
    public String column();
}